Re: [Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
On Fri, 2010-02-26 at 09:26 +0300, Anton Gorlov wrote:
As surprising as it might seem, I did read ./configure --help, which
says this to be exact:
--with-gd-libs=LDFLAGS linker flags for the gd library
${LDFLAGS} != ${LIBS}
Would you please elaborate?
Thanks!
--
Sincerely yours,
Yury V. Zaytsev
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi!
It seems that the previous RHEL / Fedora maintainers just wiped out
nut_check_libhal.m4 completely to replace it with
HAL_CALLOUTS_PATH=${libexecdir}
HAL_FDI_PATH=${datadir}/hal/fdi/information/20thirdparty
and did autoreconf in the SPEC. We can no longer do this, because
autoconf that it shipped with RHEL is too old. The options are to find
out the reason why it fails, do autoreconf on another machine to make a
patch or move files manually in the SPEC.
On my host
[build...@servinet libexec]$ pkg-config --silence-errors --variable=libexecdir
hal
returns nothing, but
[...@servinet ~]$ if (test -d /usr/lib64/hal); then echo 1; fi
1
[...@servinet ~]$ if (test -d /usr/libexec); then echo 1; fi
1
So apparently Debian line takes precedence over the Redhat line (which
turns out to be useless). The next test for OpenSuse, by the way, will
only work on 32-bit platforms, because the lib path is hardcoded and
apparently will fail anyway, because they do have /usr/libexec.
Therefore, I suspect that the detection logic in nut_check_libhal.m4 is
broken. Is it indeed the case or I have to read some magic files for
enlightenment?
I would suggest to swap the order of Debian and Redhat lines and for
Redhat check against the existence of /etc/redhat-release which is
guaranteed to be there on all RH distributions.
I am no Suse or Debian expert.
--
Sincerely yours,
Yury V. Zaytsev
On Thu, 2010-02-25 at 19:18 +0100, Yury V. Zaytsev wrote:
Hi!
Is there any particular reason why NUT installs hal addons to
/usr/lib64/hal/hald-addon-bcmxcp_usb
/usr/lib64/hal/hald-addon-megatec_usb
/usr/lib64/hal/hald-addon-tripplite_usb
/usr/lib64/hal/hald-addon-usbhid-ups
Instead of /usr/libexec/hald-addon-* where they should actually be
placed on RHEL systems?
Is there a way to change this behavior with a ./configure option?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi!
This is the expanded configure line as set by the %configure script:
./configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu
--program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --with-user=nut --with-group=uucp
--with-statepath=/var/run/nut --with-pidpath=/var/run/nut
--with-altpidpath=/var/run/nut --sysconfdir=/etc/ups
--with-cgipath=/var/www/nut-cgi-bin --with-drvpath=/sbin --with-all
--with-ipv6 --with-pkgconfig-dir=/usr/lib64/pkgconfig --disable-static
As you can see, I am doing it exactly the correct way around:
--libdir=/usr/lib64 --libexecdir=/usr/libexec
How is this possible, assuming your messages are correct?
config.log: http://paste.ubuntu.com/384374/
Note this:
configure:7803: checking for libhal Callouts path
configure:7814: result: /usr/lib64/hal
Shockingly, line 7814 is
# For Debian
HAL_CALLOUTS_PATH=${libdir}/hal
{ $as_echo $as_me:${as_lineno-$LINENO}:
result: ${HAL_CALLOUTS_PATH} 5
$as_echo ${HAL_CALLOUTS_PATH} 6; }
Nonsense?
--
Sincerely yours,
Yury V. Zaytsev
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools 2.4.3 - docs patch
Hi! Please find a trivial documentation patch attached. -- Sincerely yours, Yury V. Zaytsev On Tue, 2010-02-23 at 11:47 +0100, Arnaud Quette wrote: Network UPS Tools version 2.4.3 has been released. http://www.networkupstools.org/ Note: this is only a bugfix release that only solves the regression on IPv6 activation. Direct access: - Download: http://www.networkupstools.org/source/2.4/nut-2.4.3.tar.gz - News: http://www.networkupstools.org/source/2.4/new-2.4.3.txt - ChangeLog: http://www.networkupstools.org/source/2.4/ChangeLog the NUT team ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser --- nut-2.4.3/docs/cables/ge-imv-victron.txt.old 2010-02-24 13:47:59.0 +0100 +++ nut-2.4.3/docs/cables/ge-imv-victron.txt 2010-02-24 13:48:16.0 +0100 @@ -10,7 +10,7 @@ Driver: victronups (newvictronups) -UPS PC 9 pin [2~connector +UPS PC 9 pin connector 1 - 3 2 - 2 5 - 5 GND ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi guys! I'm desperately trying to update the package we ship at RPMForge and bump NUT from v2.4.1 to v2.4.3. Unfortunately, it does not seem to be an easy task by any means. I was first trying to use ./configure which is bundled with NUT. It didn't work, because the following check was introduced in nut-2.4.3/m4/nut_check_libgd.m4 for some reason: AC_SEARCH_LIBS(gdImagePng, gd, [], [nut_have_libgd=no]) and it always fail no matter whether GD is installed or not (in fact, it is installed and previous checks report that the headers are there and usable). I removed this check and did autoreconf -vfi but it needs newer autoconf that comes with RHEL. Fine, I did it with 2.63 installed in /usr/local. Now ./configure works fine, but if fails to compile on the clean machine with the following message: if gcc -DHAVE_CONFIG_H -I. -I. -I../include-I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --para then mv -f .deps/common.Tpo .deps/common.Po; else rm -f .deps/common.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include-I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --para then mv -f .deps/state.Tpo .deps/state.Po; else rm -f .deps/state.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include-I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --para then mv -f .deps/upsconf.Tpo .deps/upsconf.Po; else rm -f .deps/upsconf.Tpo; exit 1; fi if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../include-I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOU then mv -f .deps/parseconf.Tpo .deps/parseconf.Plo; else rm -f .deps/parseconf.Tpo; exit 1; fi ../libtool: line 813: X--tag=CC: command not found ../libtool: line 846: libtool: ignoring unknown tag : command not found ../libtool: line 813: X--mode=compile: command not found ../libtool: line 979: *** Warning: inferring the mode of operation is deprecated.: command not found ../libtool: line 980: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../libtool: line 1123: Xgcc: command not found ../libtool: line 1123: X-DHAVE_CONFIG_H: command not found ../libtool: line 1123: X-I.: command not found ../libtool: line 1123: X-I.: command not found ../libtool: line 1123: X-I../include: No such file or directory ../libtool: line 1123: X-I../include: No such file or directory ../libtool: line 1123: X-O2: command not found ../libtool: line 1123: X-g: command not found ../libtool: line 1123: X-pipe: command not found ../libtool: line 1123: X-Wall: command not found ../libtool: line 1123: X-Wp,-D_FORTIFY_SOURCE=2: command not found ../libtool: line 1123: X-fexceptions: command not found ../libtool: line 1123: X-fstack-protector: command not found OK, it seems that it needs re-libtoolizing with native libtool, because libtool is to old: [...@servinet nut-2.4.3]$ libtoolize --force --copy You should update your `aclocal.m4' by running aclocal. Fine, I run aclocal and relibtoolize. This time is says nothing, but compilation gives the same error as above. Now I'm stuck! Please help. P.S. Also, I'm getting the following warning: configure: WARNING: unrecognized options: --with-linux-hiddev Does anybody have a clue what happened to this option? Thanks! -- Sincerely yours, Yury V. Zaytsev
Re: [Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi Charles! Thank you very much for your help!!! On Thu, 2010-02-25 at 08:33 -0500, Charles Lepple wrote: The drivers have been gone for a while; however, the option was only recently removed. Then, I guess, I can safely remove it from the SPEC! In what concerns the other problem, I've got a little bit further by removing the bundled libtool stuff altogether: rm m4/lt* m4/libtool.m4 and doing autoreconf -vfi However, another problem popped up: http://paste.ubuntu.com/383680/ which is caused by this line here: /bin/sh ../libtool --tag=CC --mode=link gcc -I../include -I/usr/kerberos/include -I/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -Wsign-compare -o upsimage.cgi upsimage.o cgilib.o ../common/libcommon.a libupsclient.la -L/usr/kerberos/lib64 -lssl -lcrypto -ldl -lz yes Obviously, GD support still gives me headache. This idiotic yes popping out of nowhere is exactly the reason why the ./configure script bundled with NUT was failing... Looks like it's setting the link flag for GD to yes instead for -lgd for some reason. I have no experience with autotools, so I don't even have an idea where to look for the clues :-( -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools 2.4.3 - compile on RHEL5
Hi! Is there any particular reason why NUT installs hal addons to /usr/lib64/hal/hald-addon-bcmxcp_usb /usr/lib64/hal/hald-addon-megatec_usb /usr/lib64/hal/hald-addon-tripplite_usb /usr/lib64/hal/hald-addon-usbhid-ups Instead of /usr/libexec/hald-addon-* where they should actually be placed on RHEL systems? Is there a way to change this behavior with a ./configure option? -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Megatec driver floods logs #2 mail notifications
On Tue, 2009-12-29 at 15:20 +0100, Arjen de Korte wrote: Citeren Yury V. Zaytsev y...@shurup.com: Please keep the list traffic on the list so that the others can benefit. But please note that the messages are in English. If it is in Russian, feel free to take it off-list. Or rather use Google translate to translate it into English. I don't want to speak for the others (but probably it's still the case for most, that's why this list is still around), but personally I don't have time to provide free private support to anyone. Season greetings! -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Megatec driver floods logs #2 mail notifications
Hi! Please keep the list traffic on the list so that the others can benefit. 1) Be sure that an MTA is installed and working: mail -s Test y...@mail.com EOF Test! EOF 2) Be sure that the script has correct permissions: chmod ugo+x /mnt/data/scripts/ups-notifier 3) Be sure that it actually works: /mnt/data/scripts/ups-notifier lineup /mnt/data/scripts/ups-notifier linedown /mnt/data/scripts/ups-notifier lineup You should get only 2 e-mails! 4) Be sure that your configuration is correct: upsmon.conf: # ZYV NOTIFYCMD /usr/sbin/upssched # ZYV NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC upssched.conf: CMDSCRIPT /mnt/data/scripts/ups-notifier # ZYV PIPEFN /var/run/nut/upssched.pipe LOCKFN /var/run/nut/upssched.lock # ZYV # The timers, here 3 min after the ONBATT (ups on battery) event AT ONBATT * START-TIMER linedown 180 # Cancel the countdown is power is back AT ONLINE * CANCEL-TIMER linedown AT ONLINE * EXECUTE lineup HTH, -- Sincerely yours, Yury V. Zaytsev On Tue, 2009-12-29 at 19:14 +0800, Михаил wrote: Юрий! Подскажите , какие изменения нужно сделать в upsmon.conf , чтобы ваш скрипт выполнялся? указал путь к скрипту- NOTIFYCMD /sw/sbin/notifyme Я убрал коммет в строках: ___ NOTIFYFLAG ONLINE SYSLOG NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC __ И подправил скрипт под себя, должен работать. Проверяю так - выдергиваю вилку ( питание ups из сети) , спустя минуту вставляю обратно. В консоли появляется сообщение Broadcast Message from _mdnsrespon...@mihails-power-mac-g4.local (no tty) at 18:48 ULAT... UPS su620i...@localhost:3493 on battery Broadcast Message from _mdnsrespon...@mihails-power-mac-g4.local (no tty) at 18:52 ULAT... UPS su620i...@localhost:3493 on line power _ но письмо не приходит. Спасибо. Михаил pano@gmail.com On 29 Dec 2009, at 05:38, Yury V. Zaytsev wrote: On Mon, 2009-12-28 at 22:02 +0100, Arjen de Korte wrote: This is trivial to script. Create an empty file somewhere your CMDSCRIPT has write access to when the 'linedown' timer elapses (ie, when you send the warning mail). In your 'lineup' event check for the presence of this file. If it is there, you need to send a message that the power is back and remove the file. You can improve this above, by also checking the age of the file (to prevent triggering on stale files that are accidentally left behind). Hi! Thanks for the ideas! Please find my implementation attached. Hopefully it will be of use to someone... at least now it's googleable :-) -- Sincerely yours, Yury V. Zaytsev ups-notifier___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] My previous post (lengthy, lots of tarace output)
On Tue, 2009-12-29 at 16:29 -0500, Gene Heskett wrote: Just pulled the 2.4.1 tarball, fedora 10 is EOL'd 2.2.2 is it in rpms, and even rpmfind was helpless. I'll put it in before I screw with this again. I've commited the SPEC for EL4/EL5 to RPMForge few days ago. Not sure which distribution are you running though. -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Megatec driver floods logs #2 mail notifications
Hi there! I'm a n00b NUT user trying to get it running on RHEL5 and actually do something useful for me. Few questions: 1) I want it to notify me by email on power loss and power back events. I can't find any sample scripts for this purpose... Where shall I look for them? 2) So far, I've backported the package from Fedora and got my Ablerex running (previously used with Upsilon / Megatec on a Windows server). The major problem so far is that it keeps flooding my logs just as someone reported last year: http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.org/msg03762.html Is there a way to somehow mute these messages? upsc able...@localhost battery.charge: 95.0 battery.voltage: 13.50 battery.voltage.nominal: 12.0 driver.name: megatec driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.4.1 driver.version.internal: 1.6 input.frequency: 49.0 input.frequency.nominal: 50.0 input.voltage: 232.0 input.voltage.fault: 195.0 input.voltage.maximum: 233.0 input.voltage.minimum: 22.0 input.voltage.nominal: 230.0 output.voltage: 232.0 ups.beeper.status: disabled ups.delay.shutdown: 0 ups.delay.start: 2 ups.load: 17.0 ups.mfr: - ups.model: -- VS000361 ups.serial: unknown ups.status: OL ups.temperature: 30.0 ups.type: standby Dec 28 13:02:46 calculon megatec[17799]: Communications with UPS lost: No status from UPS. Dec 28 13:02:47 calculon megatec[17799]: Communications with UPS re-established Dec 28 13:05:09 calculon megatec[17799]: Communications with UPS lost: No status from UPS. Dec 28 13:05:09 calculon megatec[17799]: Communications with UPS re-established Thanks! -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Megatec driver floods logs #2 mail notifications
Hi! On Mon, 2009-12-28 at 08:26 -0500, Justin Piszcz wrote: For no. 1: I'm actually trying to make use of upssched to avoid notifications for short outages like ~ 1 minute or so. So far I've added two lines: # The timers, here 60 sec after the ONBATT (ups on battery) event AT ONBATT * START-TIMER onbatt 60 # Cancel the countdown is power is back AT ONLINE * CANCEL-TIMER onbatt As far as I understand, my CMDSCRIPT /mnt/data/scripts/ups-notifier will get triggered with onbatt parameter if the outage lasts more than 60 seconds, but I would like it to be triggered if, say when the power comes back online within a reasonable amount of time and the shutdown is canceled to inform everybody that there's no need to rush to the lab. Is there a way to achieve these two goals at the same time? Thanks! -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Make UPS switch the load on after power back
Hi! I have finally set up NUT more or less the way I want it to work, but after live testing, it turned out that the UPS (Ablerex VS000361, serially connected using megatec driver) does not switch on the load after the shutdown has been initiated completed and power came back on. Is there any magic command that I'm missing that I have to issue to instruct the unit to switch the load back on when power comes back? Thanks! -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Megatec driver floods logs #2 mail notifications
Hi! On Mon, 2009-12-28 at 20:54 +0100, Arjen de Korte wrote: I don't understand what you mean with first and second goal. Please make a timeline with events and what you want to happen at each point in time. OK, I will try to put it the other way around :-) (let's assume that the UPS battery is fully charged for clarity) 1) If the power goes down but then comes back within 1-3 minutes do nothing (don't send emails etc.) 2) If the power goes down for longer then 3 minutes send a power down e-mail. 3) If the power comes back send a power back e-mail and cancel shutdown. 4) If the power does not come back and the battery is drained (in my tests in can last for ~15 minutes) shutdown the machine and hope for the best. So far I was not able to achieve this by simple means. So I settled with the following setup: # The timers, here 3 min after the ONBATT (ups on battery) event AT ONBATT * START-TIMER linedown 180 # Cancel the countdown is power is back AT ONLINE * CANCEL-TIMER linedown AT ONLINE * EXECUTE lineup It sends a power back e-mail no matter what, but probably we can live with it. Thanks! -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Megatec driver floods logs #2 mail notifications
On Mon, 2009-12-28 at 22:02 +0100, Arjen de Korte wrote: This is trivial to script. Create an empty file somewhere your CMDSCRIPT has write access to when the 'linedown' timer elapses (ie, when you send the warning mail). In your 'lineup' event check for the presence of this file. If it is there, you need to send a message that the power is back and remove the file. You can improve this above, by also checking the age of the file (to prevent triggering on stale files that are accidentally left behind). Hi! Thanks for the ideas! Please find my implementation attached. Hopefully it will be of use to someone... at least now it's googleable :-) -- Sincerely yours, Yury V. Zaytsev ups-notifier Description: application/shellscript ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Downloads are not available
Hi guys! I'm trying to get NUT into RPMForge and confusingly enough, it turns out that the code downloads are not available from the official website: http://new.networkupstools.org/download.html [build...@servinet SOURCES]$ wget http://www.networkupstools.org/source/2.4/nut-2.4.1.tar.gz --2009-12-25 13:26:23-- http://www.networkupstools.org/source/2.4/nut-2.4.1.tar.gz Resolving www.networkupstools.org... 217.70.184.38 Connecting to www.networkupstools.org|217.70.184.38|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://new.networkupstools.org/source/2.4/nut-2.4.1.tar.gz [following] --2009-12-25 13:26:28-- http://new.networkupstools.org/source/2.4/nut-2.4.1.tar.gz Resolving new.networkupstools.org... 62.50.131.18 Connecting to new.networkupstools.org|62.50.131.18|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-12-25 13:26:29 ERROR 404: Not Found. I know that for now I can rip the sources of some of the SRPMs floating around etc. but I guess this is something that is ought to be fixed ASAP. Thanks! -- Sincerely yours, Yury V. Zaytsev ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
