this week, a new feature was merged into the NUT development tree: beside of the historical OpenSSL support (for more than 10 years), NUT now also provides SSL features using Mozilla NSS. I've already posted a lengthy mail on the NUT developers list. But there are still a few things to be told:

• for legal reasons, I won't detail, NUT (GPL v2+), can't be linked on OpenSSL without exiting from the 'main' Debian repository. Thus, NUT packages in Debian (and derivatives) don't provide NUT crypto features!

• to me, NSS has some advantages, compared to OpenSSL. Among these, NSS is distributed under 3 licenses, including GPL. So it will fix the situation for NUT in Debian! But there will be more things to come with NSS, such as client authentication, and more security for infrastructure power management.

• other distros (mainly Redhat and Suse) have attempted (and are still attempting) to consolidate crypto features, using NSS. Debian has not taken any decision on this topic though. NUT now offers the choice between OpenSSL and Mozilla NSS.

• NSS support will be officially available with NUT 2.8.0. There is currently no release date since we're committed to a features set, not a release date. Some would say Debian old school. Everything would be different with more manpower, as everywhere else in our Free land...

For the braves who want to test, here is a small procedure, adapted to Debian. We will use an existing installation, and overwrite upsd, upsmon, libupsclient and few more. Beware that it will obviously breaks the MD5 sums of your nut packages!

• install NUT, if it's not already done:

# apt-get install nut

• download the source snapshot, and uncompress it:

$ tar xzvf nut-trunk-r3751.tar.gz

• install NSS development files:

# apt-get install libnss3-dev 

• change to NUT source directory and configure it using --with-nss, to force using NSS. For Debian, the following flags are needed:

./configure --without-all --with-nss \
        --prefix=/ --sysconfdir=/etc/nut  \
        --with-statepath=/var/run/nut \
        --with-altpidpath=/var/run/nut \
        --with-drvpath=/lib/nut \
        --with-pidpath=/var/run/nut \
        --datadir=/usr/share/nut \
        --with-pkgconfig-dir=/usr/lib/pkgconfig \
        --with-user=nut --with-group=nut

• now compile and install:

$ make && make install

• refer to the documentation, NSS backend usage chapter, for detailed configuration and usage instructions.

• if you're looking for a nice user interface to manage your certificate, check Firefox Key Manager or Fedora nss-gui.

• Enjoy

Before concluding, here is the traditional thank you guys:

• Emilien Kia, who developed the NSS support in NUT,
• Fr d ric Boh , for the validation testing,
• Charles Lepple, for handling the merge from github to our Alioth Subversion repository,
• and Eaton for sponsoring this development.

As a conclusion, cryptography integration and usability is still not on par with other proprietary OS. I would love to see the crypto situation improving in Debian (and friends obviously). So this was just my 2 cents (nuts ;-)) to the cause... cheers,
-- Arno

in this series of articles, I will be talking in depth about power management through the NUT project, its packaging on Debian, how to use it in general and how I see it being part of the GreenIT thing. So, let's start with an introduction: NUT is a Free Software (GPL v2+ and 3 to be precise), originally created for power protection using UPS, from home to data-centers:
To shortly describe the main features, I would say that NUT:

• has the most comprehensive list of supported devices: 127 manufacturers and thousands of devices,
• is modular and flexible, to address all possible use cases,
• weight a few hundreds Kb,
• runs on any system, is packaged for the major ones, and is bundled with most (if not all) Linux,
• provides tons of features,
• is network oriented: you can access uniquely devices all around the world, in a secured way,
• is optimized for integration and interfacing,
• is supported by many 3rd party software,
• is already embedded in several devices, found in home, enterprises and datacenters.

NUT used to stand for Network UPS Tools. That is, a software for talking to your UPS and shutting down your systems when needed. This definition is a bit limited nowadays, since NUT supports 4 types of power device:

• UPS, obviously, since the origin.
• PDU (power distribution units), for 4 years. These are somehow big intelligent power switches, that you find in datacenters. These allow to switch on and off specific outlets and / or to measure power consumptions. The latter is more interesting for Green IT and PUE calculation. But this is the topic of another article
• SCD (solar controller device), for more than 2 years. NUT only supports 1 SCD (IVT SCD series), but support for another can be very easily added.
• PSU (power supply unit), for more than a year. This support is limited to server PSU, that are IPMI compatible.
• meters and gensets are also new device types that are considered. Meters would provide more measurement capabilities, still mainly for PUE calculation, while gensets.

Considering this, is the name Network UPS Tools still suitable? Not really! But the acronym NUT is well known! So, for the time being, I just stick using it, and focus on other more important things, until a better opportunity (ideas and comments are welcome!). That said, what can you do exactly with NUT? Currently, you can:

• monitor and manage UPS(s) that protect(s) your system(s), with no redundancy limitation,
• manage your PDU, to power on / off your systems (not servers directly!), and measure power consumptions,
• monitor and manage your servers power supplies, power these on / off, and measure power consumption.
• monitor all these links of the powerchain, that feed your servers.
• discover all USB, SNMP and IPMI supported devices, locally or on the network.

All the above is available in a standardized way:

• the manufacturer name will always be in the variable called device.mfr. The first outlet will always be outlet.1, whatever the device is (UPS or PDU here),
• Tons of command line tools, libraries / language bindings and software are available to help in NUT integration! You can even make your own NUT client implementation very easily and quickly (experiences reports are ~ 2 hours).

Well, this is already a long and dense post, so I will stop there for today. In the next post, we will have a deeper dive into using NUT, for various use cases: submit yours if you can cheers,
-- Arno

I have this bunch of Dell R610, with iDrac6 Express management cards. I used these, among other things, for developing IPMI support in NUT and working on Infrastructure & Cloud power management. But that's the topic of another post (still, if you're interested in, check this and that). The thing is that this "IPMI" monitoring development has been limited to local support (Ie, power supplies can't be monitored remotely by the nut-ipmipsu driver), due to an issue : any attempt to enable IPMI access over the network was miserably failing! Well, these attempts were limited to a couple of 15 minutes runs, without plain motivation, almost a year ago. The various firmwares were up to date (iDrac 1.70, ...) , everything was running and configured fine, locally. But still... no IPMI available through the network! Looking on the Net, I've learned that many Dell customers with iDrac Express cards, were having the same issue. Dell support seems to have replaced tons of motherboards! There, I switched to other things, and time has passed.... A good year later (last week), I decided that it was time to get back on this. And I've found the solution there Incredible: this was due to a 'bug' in the Broadcom NetXtreme II LoM (LAN on Motherboad) firmware! I've not had time to dig this issue in depth, but here is a base explanation, for what it's worth: Some LoM initial self tests are failing. Thus, the LoM are not switched to the managed mode, and can't actually be available for BMC management (thus no IPMI over the network). In my case, the tests were wrongly failing at 'A07', a test which tries to establish a Gigabit connection! Strangely, all these servers are connected on a Gb switch! Not a fully satisfactory answer, but that said, there is a solution, and I've not much time to pour into this investigation (comments may always change my mind though!). So here is a comprehensive procedure to fix this, from your Linux system, and using FreeDOS:

• Get a USB key, at least 1,44 Mb (damn!), but a good old 32Gb will also do the trick
• Open a terminal and format the USB key (WARNING: this will ERASE all data on the key! You've been warned. Really!)

$ mkfs.msdos /dev/sdX1

Note: 'X' is to be replaced by the exact name of your USB key. An hint: call 'tail -f /var/log/syslog" and unplug / replug your USB key. You will see some entries like "...sdb Attached SCSI removable disk". So, there, it's "sdb".

• Download a FreeDOS image
• Now use qemu to create the DOS boot disk on your USB key (replace 'X' again!):

$ qemu -boot a -fda balder10.img -hda /dev/sdX A:\> sys c: A:\> xcopy /E /N a: c:

Note that you will need "root" privileges.

• (Optional) You can check the bootability with:

$ qemu -hda /dev/sdX

• Download Broadcom DOS utilities there
• Unzip this archive (self extract)

$ unzip Bcom_LAN_14.2.x_DOSUtilities_A03.exe

• Copy only 'Userdiag/NetXtremeII/uxdiag.exe' to your USB key.
• Plug the key in your server, and reboot it
• Press F11 to enter the BIOS boot sequence,
• Select the default entry, and press Enter. Once the system is booted, type:

c:\ uxdiag -t abcd mfw 1

• Reboot your system, and enjoy your *working* IPMI access over the network

For what it's worth (again), I just hope that it will be useful to others... I will now prepare another post using using FreeIPMI to manage your servers, the GNU way... cheers,
-- Arno Thanks to Jordi Clariana, his enlightening post, Daniel for this one, Aur lien was motivating me again in solving this iDrac Express issue and Al Chu (FreeIPMI project leader) for all his invaluable help on IPMI.

Hey fellows Debian lovers, and old friends reading this, after more than a decade serving Debian, our greatest and beloved OS, I've finally decided to start blogging. Please, bear with me, I'm still very new at blogging. Thus, constructive comments and mails are welcome So here we actually go with the usual 'quick introduction post': I'm Arnaud Quette, 36 years old, and Debian developer since 2001. I'm leading the upstream project called 'NUT' (Network UPS Tools project) since 2005, and I'm a Free Software hacker since 1997 (incomplete list of contribs and linkedIn profile). I'm working at Eaton, a Debian partner participating in the power protection of our Debian infrastructure (FTP masters and Alioth). If you're a Debian admin, and feel Eaton can help, drop me a mail. My main Opensource contribution, for some years, is to lead 'NUT', and the related power management developments and distribution. As such, I also ensure that all this work lands finely in Debian, and is useful and reliable to users. In the past, I've also been working on some Media Center packages (Coherence UPnP, moovida, LIRC, ...), Synaptics touchpads app and some more. Here is the current list of maintained and co-maintained packages, though not up to date. It's not always that easy to balance between upstream lead and the numerous developments on one hand, and Debian packaging and support on the other hand... Not counting real life and the many others responsibilities I have. Just forgive me for the time it has taken (and is still taking, sometimes) to update my various packages. Just remember that I'm always doing my best So dear Planet Debian readers, I'll be bothering you with some news on power management and GreenIT in Debian. There will be both upstream and Debian developments and releases info, so that you all can react. There may probably be some diversion, on other Debian related topics, one way or another... All this will depend on your feedback, and the balance with my available time and pleasure to share with you these few tech bits. cheers,
Arnaud