main inclusion report

- upstream == debian, so it's strange that the activity status is that different
- the package done by debian is outdated (2.2.0); please update to the 2.2.1 release for hardy
  see http://www.networkupstools.org/source/2.2/ChangeLog
- the shared libraries should be split out into its own binary package; there is at least one more
  package build-depending on net-dev.

- ubuntu-security, please could you provide a source code review of the server part?

guys,

first; it's a pleasure to see this since I wasn't aware of ;-)
I took the liberty to complete it a bit the report.

some more notes:
- 2.2.1 packages are underway (should be done by the end of this
week). I've been busy with many things upstream... and real life

> - the shared libraries should be split out into its own binary package; there is at least one more
> package build-depending on net-dev.

yup, wmnut. none else (for the moment)
but no shared link. static only.

you should also:
- have a look at that one:
https://blueprints.edge.launchpad.net/ubuntu/+spec/integrated-usb-ups-support

- know that when I'm done with completing the above, I'll get back on
the NUT config side: a library and an helper that will allow the easy
creation of NUT config GUIs (debconf and others)

cheers,
Arnaud
--
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

I've uploaded nut 2.2.1-1 yesterday in Debian.
I've logged a sync request too:
https://bugs.edge.launchpad.net/ubuntu/+source/nut/+bug/185565

Arnaud,

I was curious as to why the Debian packaging doesn't do the 'security domains' as listed in:
http://www.networkupstools.org/faq/

or even the chrooting as in:
http://www.networkupstools.org/doc/2.2.0/chroot.html

Hi Jamie,

2008/2/8, Jamie Strandboge <email address hidden>:
> Arnaud,
>
> I was curious as to why the Debian packaging doesn't do the 'security domains' as listed in:
> http://www.networkupstools.org/faq/
>
> or even the chrooting as in:
> http://www.networkupstools.org/doc/2.2.0/chroot.html

well, the answers would be: because...
- the security scheme of the current debs are inherited from the
previous maintainer,
- no users have explicitly expressed the need (or wish) of more
security hardening by default,
- I've not had yet the time to cleanly complete these packages (need
debconf, cdbs refactoring, security hardening), nor received help to
do so,
- I've dedicated most of my time upstream (you might want to have a
look at my launchpad wiki),
- ...

You have missed that one ;-)
"Completely unprivileged upsmon" (to drop the remaining root privs)
http://www.networkupstools.org/doc/2.2.0/ideas.html

In fact, I have the NPS project linked to the packaging
standardization and improvement. I've explicitly added a security
hardening comment:
https://alioth.debian.org/pm/?group_id=30602

So, if you're interested in helping, you're more than welcome ;-)

reconfirmed with Martin; we should address Jamie's concerns and the "Completely unprivileged upsmon" before inclusion in main.

well, that will have to wait for NUT 2.4, so HH+1...

Please see https://wiki.ubuntu.com/MainInclusionReportNut for details on my (very) high-level audit.

just some comments to ease your audit:
- all the mentioned functions (upslog*, upsdebug*, fatal*) point to
vupslog, and vupslog use only numbered copy functions,
- we centralize as much as possible such kind of functions to manage
the security and reliability of NUT,
- we enforce in general the use of numbered copy,
- I've just started to formalize our QA effort:
http://test.networkupstools.org/Documentation/UserManual/QualityAssurance
Not much there yet, but it will expose our many effort to enhance NUT
quality in general.

I hope this helps.

Thanks, Arnaud for the report improvements, and Jamie for the security review. The packages, as well as the current level of proactive security seems adequate to me.

Since this package is likely to need some real maintenance and support, I'd like to get some commitments on this before approval.

 - Server team, does any of you have an UPS for testing and developing this package?
 - Server team, please put a commitment here that we have the necessary manpower to support, develop, and fix this package in the next 5 years of Hardy's life.
 - Arnaud, do you happen to be interested in helping with the maintenance in Ubuntu, too? (e. g. have a look at the bug reports, etc.)

Thank you!

fellows,

2008/2/20, Martin Pitt <email address hidden>:
> Thanks, Arnaud for the report improvements, and Jamie for the security
> review.

you're welcome ;-)

> The packages, as well as the current level of proactive security
> seems adequate to me.
>
> Since this package is likely to need some real maintenance and support,
> I'd like to get some commitments on this before approval.
>
> - Server team, does any of you have an UPS for testing and developing this package?

I can check for some UPS providing if needed...

> - Server team, please put a commitment here that we have the necessary manpower to support, develop, and fix this package in the next 5 years of Hardy's life.
> - Arnaud, do you happen to be interested in helping with the maintenance in Ubuntu, too? (e. g. have a look at the bug reports, etc.)

I'm trying to help NUT improvement and integration everywhere, and
most of all on Debian and Ubuntu... so, yes I'm interested in.

Arnaud
--
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

I have an APC SmartUPS-700 and access to a Tripplite (post hardy).

Hi Pitti,

Yes we do have UPSes for testing, and we will be supporting this for 5 years since its apart of the ServerPackageRevew spec.

Thanks
chuck

if somebody needs an MGE (and possibly a Powerware), please let me know.

For the recall, the former is the official NUT sponsor, and the only
UPS manufacturer 100 % pro FLOSS. And the latter might come soon (I'm
working hardly on this).

Arnaud

Cool package!

I've had an APC BackUPS ES with a usb since 2002 but never even hooked it up, assuming that was for a Windows world only. I'm glad to have emerged from the darkness. I managed to get it monitoring working well with this package, though I have a few suggestions that I hope can be solved in the packaging installation scripts.

1) I'd suggest the sample scripts installed in their proper locations in /etc/nut/ , with the proper ownership and permissions (nut:nut, 600). These samples can have everything commented out. They don't have to be functional, as long as they don't produce security holes.
root@foo:/# ls -alF /etc/nut/
total 44
drwxr-xr-x 2 nut nut 4096 2008-02-21 16:37 ./
drwxr-xr-x 131 root root 12288 2008-02-21 16:13 ../
-rw------- 1 nut nut 3741 2008-02-21 15:14 ups.conf
-rw------- 1 nut nut 2012 2008-02-21 14:26 upsd.conf
-rw------- 1 nut nut 2422 2008-02-21 15:26 upsd.users
-rw------- 1 nut nut 11950 2008-02-21 15:45 upsmon.conf
-rw------- 1 nut nut 3901 2008-02-21 16:37 upssched.conf

2) Why is /usr/share/doc/nut/examples/upsmon.conf.sample.gz compressed but none of the others? It's bigger, but not huge.

3) I see /etc/init.d/nut and then /etc/init.d/ups-monitor symlinks to -> /etc/init.d/nut ... Why the duplication?

4) Speaking of init scripts, I did have to a couple of lines to my /etc/rc.local that would be nice to have in the init scripts (upstart, as it may be):
/usr/bin/upsdrvctl start apc
/usr/sbin/upsd
/usr/sbin/upsmon

As a reference, I found this howto to be very, very useful for my APC UPS.
http://www.mathstat.dal.ca/~selinger/ups/backups.html

Changing status as Martin's questions seems to have been answered.

Fellows,

Following our discussion of last friday with Nick, I've quickly
created a test-nut.py for the QA Regression Testing (master branch).

I've already explained the general idea to Nick, but for the others,
here is a quick brief:
- NUT provides a dummy driver (dummy-ups) that loads its data from an
upsc output (or create a base set of data otherwise).
- the idea for regression testing is to create a base NUT config,
using dummy-ups, and to start the 3 NUT layers (driver, upsd and
upsmon)
- then you check that the daemons (dummy-ups, upsd and upsmon) are started,
- then you try to get some data (using upsc)
- then you inject a data change in the driver layer (like changing
"ups.status" to "OB", using upsrw), and you verify the data
propagation in the client layer (the same layer as upsmon, still using
upsc)

This is very basic for now, but allows to validate the general NUT
architecture non regression.
I'll look into adding more things in the future, but it's already a
good starting point.

what delivery method would you prefer (I tried logging a bug, but it's void)...

-- Arnaud

2008/2/21, Dustin Kirkland <email address hidden>:
> Cool package!

thanks

> I've had an APC BackUPS ES with a usb since 2002 but never even hooked
> it up, assuming that was for a Windows world only. I'm glad to have
> emerged from the darkness. I managed to get it monitoring working well
> with this package, though I have a few suggestions that I hope can be
> solved in the packaging installation scripts.
>
> 1) I'd suggest the sample scripts installed in their proper locations in /etc/nut/ , with the proper ownership and permissions (nut:nut, 600). These samples can have everything commented out. They don't have to be functional, as long as they don't produce security holes.
> root@foo:/# ls -alF /etc/nut/
> total 44
> drwxr-xr-x 2 nut nut 4096 2008-02-21 16:37 ./
> drwxr-xr-x 131 root root 12288 2008-02-21 16:13 ../
> -rw------- 1 nut nut 3741 2008-02-21 15:14 ups.conf
> -rw------- 1 nut nut 2012 2008-02-21 14:26 upsd.conf
> -rw------- 1 nut nut 2422 2008-02-21 15:26 upsd.users
> -rw------- 1 nut nut 11950 2008-02-21 15:45 upsmon.conf
> -rw------- 1 nut nut 3901 2008-02-21 16:37 upssched.conf

there are many things underway for the configuration handling.
check the MIR audit for my comments

> 2) Why is /usr/share/doc/nut/examples/upsmon.conf.sample.gz compressed
> but none of the others? It's bigger, but not huge.

bug

> 3) I see /etc/init.d/nut and then /etc/init.d/ups-monitor symlinks to ->
> /etc/init.d/nut ... Why the duplication?

this is due to the ups-monitor role, offered by various packages (nut,
apcupsd, ...)
One method to rule them all...

> 4) Speaking of init scripts, I did have to a couple of lines to my /etc/rc.local that would be nice to have in the init scripts (upstart, as it may be):
> /usr/bin/upsdrvctl start apc
> /usr/sbin/upsd
> /usr/sbin/upsmon

this is already done by the nut init script. But you might have missed
/etc/default/nut
in general, have a look at /usr/share/doc/README.Debian for instructions.

though I still have to make this script lsb compliant, and to check
for upstart possible enhancement

> As a reference, I found this howto to be very, very useful for my APC UPS.
> http://www.mathstat.dal.ca/~selinger/ups/backups.html

yup, Peter is (though somehow retired currently) a member of the NUT team.
Note that the doc rewritte is underway using the new web Wiki infra
(test.networkupstools.org)
And also that the Integrated Power Management will make it easy for
USB UPS owners:
https://blueprints.edge.launchpad.net/ubuntu/+spec/integrated-usb-ups-support

-- Arnaud

Arnaud Quette wrote:
> Following our discussion of last friday with Nick, I've quickly
> created a test-nut.py for the QA Regression Testing (master branch).
[...]
> what delivery method would you prefer (I tried logging a bug, but it's
> void)...

I believe you should just:
- create a new branch in [1]
bzr branch
http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master

- push your changes when done
bzr push
bzr+ssh://<email address hidden>/~aquette/qa-regression-testing/nut-aquette

- request merging in the Launchpad bug by specifying the bzr branch url

That should do it :)

[1]https://code.launchpad.net/qa-regression-testing/

that did indeed ;-)
code committed.
the only remaining point is the bug: I'm not sure to understand you.
Should I add a comment on the present bug or? The "QA Regression
Testing does not use Launchpad as its bug tracker."

The branch is as located as per your comment:
https://code.edge.launchpad.net/~aquette/qa-regression-testing/nut-aquette
so http://bazaar.launchpad.net/~aquette/qa-regression-testing/nut-aquette

cheers,
-- Arnaud

I added your branch to this bug. Thanks a lot!

2008/2/27, Nick Barcet:
> I added your branch to this bug. Thanks a lot!

ok, I now see the light, thanks ;-)

-- Arnaud

Thanks everyone! nut approved and promoted.

I asked Kees and Jamie to review and merge the test script.

Oh, and please seed the package to somewhere, so that it stays in main.

Merged test-nut.py into qa-regression-testing

kudos fellows.
I really like working with you ;-)
expect some new features and a better integration for HH+1...