search for: iow

...ained > to reboot when power returns and have no ups fitted, were NOT rebooted > as evidenced by their reported uptimes, one of which shows a 144 day > uptime. So why should this have been logged via a -wall bc to every > login it is servicing? > > There was no power failure IOW. The thing is that many UPS models will report "on battery" when the voltage fluctuates out of range, but a switching power supply might still be able to coast through it-- especially if the supply is oversized for the load at the time of the abnormality. Since both "outages"...

..., 3 other machines that are trained to reboot when power returns and have no ups fitted, were NOT rebooted as evidenced by their reported uptimes, one of which shows a 144 day uptime. So why should this have been logged via a -wall bc to every login it is servicing? There was no power failure IOW. Enquiring minds want to know. Maybe this is why it was so cheap, it has buggy firmware? Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law,...

On Tue, 7 Jan 2020, Gene Heskett wrote: > ● nut-monitor.service - Network UPS Tools - power device monitor and > shutdown controller > Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; > vendor preset: enabled) > Active: failed (Result: protocol) since Tue 2020-01-07 07:19:19 EST; > 116ms ago > Process: 32343 ExecStart=/sbin/upsmon (code=exited,

On Thursday 09 January 2020 16:59:12 Charles Lepple wrote: > On Jan 9, 2020, at 4:39 PM, Gene Heskett <gheskett at shentel.net> wrote: > > So for starters, what's the best ./configure command line? > > There’s this page for matching the layout of an existing Debian > install: > https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Ra

On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: > > input.transfer.high: 0 ???? Shouldn't these two be something real ???? > input.transfer.low: 0 ???? ditto Known issue, but only cosmetic: https://github.com/networkupstools/nut/issues/482

On Friday 10 January 2020 20:43:55 Gene Heskett wrote: > On Friday 10 January 2020 19:04:11 Charles Lepple wrote: > > On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: > > > input.transfer.high: 0 ???? Shouldn't these two be something real > > > ???? input.transfer.low: 0 ???? ditto > > > > Known issue, but only cosmetic: > >

On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > >> >> Instant return, logging this: > in /tmp/info > >> 0.000000 Error: too many non-option arguments. Try -h for help. >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 > > This I assumed was with nut-server and nut-client, both stopped, which > they

On Sunday 12 January 2020 12:09:04 Gene Heskett wrote: > On Sunday 12 January 2020 11:14:13 Charles Lepple wrote: > > On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > > >> Instant return, logging this: > > > > > > in /tmp/info > > > > > >> 0.000000 Error: too many non-option arguments. Try -h for > > >> help. Network

On Monday 13 January 2020 22:42:46 Charles Lepple wrote: > On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT > >>> tree, which has the command line amended to not generate that "too > >>> many non-option arguments" error. Also, I wanted it to use the > >>> existing

On Jan 21, 2020, at 7:50 AM, Gene Heskett <gheskett at shentel.net> wrote: > > Now I've got another of those WTF questions. This ups doesn't ID itself > the same to an lsusb as it does to upsc. > From an lsusb: > Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The two IDs are vendor (VID) and product (PID). lsusb looks them up in a text

On Jan 21, 2020, at 10:34 PM, Gene Heskett wrote: > > On Tuesday 21 January 2020 19:52:01 Charles Lepple wrote: > >> sudo lsusb -v -d 0764:0501 > copious output, containing this: > idVendor 0x0764 Cyber Power System, Inc. > idProduct 0x0501 CP1500 AVR UPS > bcdDevice 0.01 > iManufacturer 3 CPS > iProduct

On Saturday 11 January 2020 17:00:19 Charles Lepple wrote: > On Jan 11, 2020, at 3:50 PM, Gene Heskett wrote: > >> The problem is further downstream. Even after you map HID names to > >> NUT names, then you run into the fact that CPS and NUT are > >> interpreting the HID Report Descriptor differently. (Some details > >> here:

On Wednesday 08 January 2020 12:01:08 Gene Heskett wrote: > On Wednesday 08 January 2020 09:37:10 Roger Price wrote: > > On Tue, 7 Jan 2020, Gene Heskett wrote: > > > ● nut-monitor.service - Network UPS Tools - power device monitor > > > and shutdown controller > > > Loaded: loaded (/lib/systemd/system/nut-monitor.service; > > > enabled; vendor

On Tuesday 21 January 2020 19:52:01 Charles Lepple wrote: > sudo lsusb -v -d 0764:0501 copious output, containing this: idVendor 0x0764 Cyber Power System, Inc. idProduct 0x0501 CP1500 AVR UPS bcdDevice 0.01 iManufacturer 3 CPS iProduct 1 CP625HGa I take it that this is evidence they don't follow the spec to the letter.

On Friday 10 January 2020 07:28:13 Charles Lepple wrote: > On Jan 9, 2020, at 5:51 PM, Gene Heskett wrote: > > On Thursday 09 January 2020 16:59:12 Charles Lepple wrote: > >> On Jan 9, 2020, at 4:39 PM, Gene Heskett <gheskett at shentel.net> wrote: > >>> So for starters, what's the best ./configure command line? > >> > >> There’s this

I wonder if it is possible to set up an encrypted "file container" on a CentOS VPS? I am the root user of the VPS but the hosting company also has access to the VPS and thus all files. Is it possible to create a LUKS-container on the VPS and those files only be accessible by me? IOW, most of the file system on the VPS would be regular file system but the container could be used by me as needed. This would allow the VPS to reboot normally, I could ssh in normally etc etc. I would rsync files as needed to this LUKS-container though.

On Friday 10 January 2020 07:52:47 Gene Heskett wrote: > > Not sure where that message is coming from, but glad it worked with > > the newer aclocal. (Did you use the release tarball, or a Git > > checkout?) > > Release 2.7.4 tarball. Docs are years out of date, man pages claim > 2.7.3 dated in 2015... But it works, and thats what counts. :) Got it wired up and

...lathe. I am also the caretaker for my bride of 30 years who is in the later stages of COPD. So I can't leave her unattended for too long. One of the advantages of outliving all ones enemies. ;-) I've got another project going that will take some steel cutting and welding, outside work IOW, to fix a hoist over a milling machine, to pick up an 85kg machining accessory and place it on (or off) the mills table. But todays project is to finish up the laundry. People keep telling me I should act my age (85). I refuse. But it might take me a little longer than it did 60 years ago. Ch...

On Sunday 12 January 2020 11:14:13 Charles Lepple wrote: > On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > >> Instant return, logging this: > > > > in /tmp/info > > > >> 0.000000 Error: too many non-option arguments. Try -h for > >> help. Network UPS Tools - Generic HID driver 0.41 (2.7.4) > >> USB communication driver 0.33 >

On Saturday 11 January 2020 15:12:17 Charles Lepple wrote: > On Jan 11, 2020, at 1:58 AM, Gene Heskett wrote: > > On Friday 10 January 2020 20:43:55 Gene Heskett wrote: > >> On Friday 10 January 2020 19:04:11 Charles Lepple wrote: > >>> On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: > >>>> input.transfer.high: 0 ???? Shouldn't these two be