Lacking / wrong documentation for custom building

[davidhq]

Info here: https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu

claims that configure and install as described in the document will install binaries and other files exactly as apt-get install nut would and so this could be used to build from custom commit and then override the correct files from .deb install (apt-get install nut) in a simple way.

There are actually two problems:

• this manual install puts crucial files (binaries and lib) in markedly different locations:

/usr/lib/ups vs /lib/nut (maybe this doesn't happen in all branches but when I tried libusb-1.0+0.1 it did because a) --libexecdir configure options was ignored plus it's specified wrong in the above document --libexecdir=/usr/lib/nut (should probably be --libexecdir=/lib/nut to match .deb install but it would still be ignored for some reason)

commands in /usr/local/ups/bin and /usr/local/ups/sbin vs /bin/ and /sbin

• manual configure and install leaves init scripts /etc/init.d/nut and /etc/init.d/ups-monitor vs much better nut-client.service, nut-driver.service, nut-monitor.service and nut-server.service in /lib/systemd/system with .deb install. It also leaves a symlink for shutdown in /etc/rc6.d which doesn't really work in recent versions of Debian anyway. .deb install does a nice job creating a short script /lib/systemd/system-shutdown/nutshutdown and this is not documented anywhere.

I managed to do clean custom install this way but it's a bit tiresome and had to be discovered by trial and exploration:

• configure and sudo make install as in the document above
• copy /lib/nut and /usr/local/ups to some temporary directory
• sudo make uninstall
• sudo apt-get install nut
• overwrite the entire /lib/nut from temporary directory
• overwrite each of 10 binary files in /bin and /sbin from a saved copy of /usr/local/ups
• clean leftover /etc/init.d scripts from manual install which are not used (or could even cause issues) because .deb install uses systemd scripts
• delete symlink from /etc/rc6.d for the same reason

Am I missing something obvious or is that wiki entry really obsolete / wrong for some reason?

I tried on Debian 9.3 Stretch.

[clepple]

NUT does not have all of the init scripts for each distribution, which is why I recommended not removing the original .deb files.

Also, the Debian packages still include /etc/init.d (this doesn't come from the NUT repository) so you may want to file a bug with Debian. Partial list of files from the .debs: https://packages.debian.org/stretch/amd64/nut-server/filelist and https://packages.debian.org/stretch/amd64/nut-client/filelist

Are you sure you cleaned everything up before re-invoking the ./configure command?

[davidhq]

I now ran make clean before autogen.sh .. complete log is here: https://gist.github.com/davidhq/3caa7ebfaafbf54d48a7c23eb00d6a03

• you can see that indeed it installs things in different locations than .deb package - commands in /usr/local/ups/bin and /usr/local/ups/sbin vs /bin and /sbin
• this time the change --libexecdir=/usr/lib/nut to --libexecdir=/lib/nut was working and library files were installed to /lib/nut, maybe make clean made a difference or something else was wrong before when this option seemed to be ignored but it's not that important and maybe I did something wrong
• I see now that artefacts in /etc/init.d are from .deb install and custom install sets up systemd scripts correctly, thank you for pointing this out, good to see it's problem there and not in the recent source on github

I still think though that this could really be made much clearer - From manual:

You can either run the binaries from the source tree, or run sudo make install to 
overwrite the contents of the NUT .deb files

This part is very misleading. "overwrite" -- this would mean that files are installed in the same locations but as you can see, they aren't. Since systemd scripts do get overwritten, the default install indeed become the manual one but duplicate library files, binary commands and left-over artefacts from .deb remain unless the package is removed.

Reinstalling the .deb files should revert most of the changes, although newly-added NUT 
drivers may be left behind in /lib/nut.

This part is also confusing / not true because the default install according to the configure command in the document is to /usr/lib/nut and for sure doesn't overwrite the .deb install libraries.

Conclusion:

I now see how to successfully install from any commit and the only thing needed from .deb packages is:
sudo apt-get build-dep nut (and then sudo apt-get install libusb-1.0-0-dev for libusb1.0+0.1 branch) and the optimal way is to remove the .deb package if installed, then do manual install. Commands then have to be run with absolute paths since they are not in PATH as with .deb install - this could also confuse new people.

Last suggestion I would have is that here: http://networkupstools.org/docs/user-manual.chunked/ar01s06.html#UPS_shutdown

this example

if (test -f /etc/killpower)
        then
                echo "Killing the power, bye!"
                /usr/local/ups/bin/upsdrvctl shutdown

                sleep 120

                # uh oh... the UPS power-off failed
                # you probably want to reboot here so you don't get stuck!
                # *** see also the section on power races in the FAQ! ***
        fi

is updated to:

#!/bin/sh

if /usr/local/ups/sbin/upsmon -K >/dev/null 2>&1; then
  wait_delay=`/bin/sed -ne 's#^ *POWEROFF_WAIT= *\(.*\)$#\1#p' /etc/nut/nut.conf`

  /usr/local/ups/sbin/upsdrvctl shutdown

  if [ -n "$wait_delay" ] ; then
    /bin/sleep $wait_delay
    # We need to pass --force twice here to bypass systemd and execute the
    # reboot directly ourself.
    /bin/systemctl reboot --force --force
  fi
fi

exit 0

and instead of just "Init script examples are provide in the scripts directory of the NUT source tree, and in the various packages that exist.", it would be great to mention /lib/systemd/system-shutdown/nutshutdown as an example and even if someone is not using systemd, they can learn more or less what is meant and where roughly to find these scripts.

I really needed a lot of time as a beginner to figure this out. Also here someone is mentioning the same:

My investigation revealed that the power kill command is supposed to be 
sent by /lib/systemd/system-shutdown/nutshutdown (which is really 
neither obvious nor documented, as far as I could find, but oh well)...

So thank you for hints and help, through this I managed to get a working system for me and I try to give back a little with these suggestions. Maybe there is still something I overlooked but please take a look and think about it, if you think no changes to the docs are needed at this point, just close the issue and maybe return later when it makes sense.

[davidhq]

Forgot something very important... I tried once again to completely remove nut package and install manually from scratch. The problem I noticed a few days ago is real and still present:

Mar 09 17:20:19 upsdrvctl[1422]: Can't chdir to /var/run/nut: No such file or directory

When I create /var/run/nut

> ls -la /var/run/nut
drwxrwx---  2 root        nut           40 Mar  9 16:35 nut

and restart the services, it works but only until restart when /var/run/nut is missing again for some reason and services cannot start.

I guess I'll have to install nut package again and then navigate around with manual install with all caveats and then it should work... but still: everything is kind of very broken but somehow possible to resolve.

UPDATE:

I think the problem for this particular issue is in systemd scripts, along these lines:

From here:

/var/run/nut should be created by systemd-tmpfiles and it should have 0750 permissions 

there was missing ExecStartPre in nut-driver.service so this issue should be fixed

...

So I'll install the nut package again and investigate systemd scripts, then update them accordingly. I hope then everything works and this is another issue to solve for the team? Or if you confirm, I can provide a pull request for libusb1.0+0.1 branch since this is what I'm trying to make work 100%.

[davidhq]

.deb package does it this way:

$ cat /usr/lib/tmpfiles.d/nut-server.conf
d /run/nut 0770 root nut - -

So for now, I just did the same, not sure how it should be done properly so I won't produce a fix.

Now I have a working system again. I hope this report has been useful.

[clepple]

This part is also confusing / not true because the default install according to the configure command in the document is to /usr/lib/nut and for sure doesn't overwrite the .deb install libraries.

Did anything actually get installed to /usr/lib/nut after fixing the backslashes? The driver path is controlled by another option (--with-drvpath). https://gist.github.com/davidhq/3caa7ebfaafbf54d48a7c23eb00d6a03#file-gistfile1-txt-L1222 <https://gist.github.com/davidhq/3caa7ebfaafbf54d48a7c23eb00d6a03#file-gistfile1-txt-L1222> I am not trying to be difficult, honest. This set of instructions has been used many times on the mailing lists (and the configure command-line originally came from the Debian build logs), so I am trying to figure out what is different about your box. I will try to address some of the other points later.

[davidhq]

Did anything actually get installed to /usr/lib/nut after fixing the backslashes?

yes, but later I used --libexecdir=/lib/nut

The driver path is controlled by another option (--with-drvpath).

I see! Thank you... this doesn't change the comments above but I didn't realize there is this option too... anyway since I used /lib/nut for both drvpath and libexecdir, everything together is there.

Last summary:

• original .dev installation as recommended clashes a bit with manual, some files are left over etc., different locations
• I managed to make it work as described so .deb prior install is not needed anymore when I have to do it again on a different machine

Maybe you should try on a sample debian box...

Thank you for all the help! I'm happy with my setup now.

[2E0PGS]

Am I missing something?

git clone https://github.com/networkupstools/nut.git

cd nut/

./configure
-bash: ./configure: No such file or directory

make
make: *** No targets specified and no makefile found. Stop.

I tried running ./autogen which worked but running the above two commands still don't work.

I cannot even run make clean

I am trying to follow this documentation for building: https://networkupstools.org/docs/user-manual.chunked/ar01s05.html

I also tried after changing to the branch I needed git checkout libusb-1.0+0.1

The above to commands still fail. So does make nut-server, make nut-client, make all, make build

[jimklimov]

The pre-generated configure script is part of a "dist" tarball (typically a release tarball is a copy of make dist result for a particular commit).

The git origin is aimed at developers so you are expected to have common tooling (pkg-config, autotools, compiler, etc.)

Indeed the ./autogen should have created all the needed files, assuming it succeeded (is exit-code 0?)

For a Debian/Ubuntu like system you can start by following .travis.yml and ci_build.sh, they involve both prerequisite package list and commands to run a simple build.

[2E0PGS]

Thanks for filling me in on the blanks I will try the ci_build.sh script or manually try a gcc compile.

[2E0PGS]

On Ubuntu I needed the following:
sudo apt-get install libtool autoconf autotools-dev pkg-config gcc libusb-dev
Perhaps these deps should be documented?

Oh also I had to run autogen as root sudo ./autogen.sh for it to work. Otherwise I would get exit status 1.

Then I could run the generated configure script ./configure --with-usb

Finally make

I think that process could be documented better.

[2E0PGS]

When building from source where are the config files sourced from? My configs in etc/nut/ups.conf for example are ignored by manual builds.

[2E0PGS]

Nevermind it seems to be using the correct config files now.

[2E0PGS]

I custom build wont however pickup my driver Error: Driver not connected

[powerwalker]
    driver = usbhid-ups

It worked fine before with deb package. I tried specifiying the driver location like so but still no luck:

driver = /usr/local/ups/bin/usbhid-ups

[2E0PGS]

sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
Can't claim USB device [06da:ffff]: could not detach kernel driver from interface 0: Operation not permitted
Driver failed to start (exit status=1)
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
Can't claim USB device [06da:ffff]: could not detach kernel driver from interface 0: Operation not permitted
Driver failed to start (exit status=1)

[2E0PGS]

had to run sudo mv /lib/udev/rules.d/{5,6}2-nut-usbups.rules
as per https://askubuntu.com/a/641562 and #140

[2E0PGS]

Finally upsc powerwalker@localhost works and returns data with a custom build.

[clepple]

On Ubuntu I needed the following: sudo apt-get install libtool autoconf autotools-dev pkg-config gcc libusb-dev Perhaps these deps should be documented?

https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu step 3 installs those dependencies.

[2E0PGS]

Is that accessable via the website since thats where I was looking? My appologies since it does atleast exsist.

I did however have to move those udev rules.

[clepple]

Is that accessable via the website since thats where I was looking? My appologies since it does atleast exsist.

It's there in general terms: https://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building

I did however have to move those udev rules.

Maybe sometime later when the process of rebuilding the website is more automated, we can add in all the quirks for each distro. Until then, it's probably going to be general installation instructions on the website, and specifics on Wiki pages that users can update.

[2E0PGS]

Perhaps linking to the Wiki or suggesting people check the Wiki first for community contributed writeups would be a good idea to add to the website.

[2E0PGS]

Also I believe sudo apt-get build-dep nut would only work if the .deb package was installed beforehand.

[clepple]

Also I believe sudo apt-get build-dep would only work if the .deb package was installed beforehand.

"These instructions are intended to help you build a copy of NUT that will partially install over the official .debs" so yes, that is assumed

[2E0PGS]

I think we should provide explicit information of what's needed for people like me who choose to uninstall the deb but leave configs in place or for people who wish to build without a deb perhaps they dont have a deb for their architecture etc. imo the deps should be documented and not rely on another source for that information.