[Bug 211319] Review Request: andutteye-client - Andutteye Software Suite Monitoring agent

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: andutteye-client - Andutteye Software Suite Monitoring agent


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211319





------- Additional Comments From faucamp at csir.co.za  2006-11-17 05:01 EST -------
Many improvements! :-) This is really coming along well.
Your 2 questions:
 > The agent is running as the normal andutteye user and dont have permission to
> create and append to a log file under /var/log. What approach should i use to
> over come that?

You can create the log file during %install (using touch or something similar),
and change its ownership to the andutteye user, or you can create a "andutteye"
or "andutteyed" subdir in /var/log, with ownership set to the andutteyed user;
in this case you can simply own the directory itself in %files. 

You also need to create a entry in /etc/logrotate.d to control the size of the
log file(s); this can also be used to set ownership/permissions, etc (look at
existing configurations in /etc/logrotate.d for examples; yum has a simple but
effective entry, ppp as well).

> The andutteye user should have /sbin in its PATH so that all statistics can be
> retrived. This is only nessasary if the agent is connected to a AES server
> though. What is the best approach for this?

The user account that gets created should actually be a system account, i.e. not
one that a "normal" user can be used to log in as. You can use something like:
%pre
# Create system account
/usr/sbin/useradd -g andutteye \
     -c "Andutteye Software Suite monitoring server" -r -M -s '' \
     -d %{_localstatedir}/cache/andutteye andutteye &>/dev/null || :

Note the -r flag there (for creating a system account), and setting the home
directory to /var/cache/andutteye. Since this service is then started as a
system account by init, it *should* include /sbin/ in its PATH... Let me know
how it goes - I'm very rusty on this, so if anyone knows better, please advise.

Some other stuff:
* %doc entries: permissions are incorrect (0644, should be 0755)
  - by the way, you can (if you like) place all the doc entries in one %doc
statement, by seperating them with spaces

* Man pages are installed in the wrong location (they are not accessible).
Suggested fix:
%install
  [...snip...]
mkdir -p %{buildroot}%{_mandir}/man1
install -p -m 0755 usr/share/man/man1/* %{buildroot}%{_mandir}/man1
  [...snip...]
%files
  [...snip...]
%{_mandir}/man1/*
  [...snip...]

* I've been delaying mentioning this, but your Source statement needs to have
some sort of information on HOW to obtain the source tarball. Usually this is
done by specifying the full URL where the source file(s) can be downloaded, i.e. 

Source0:
http://www.andutteye.com/download/andutteye-client-%{version}-%{release}.tar.gz

There is a slight problem here, though. I've noticed that you increment a
"release" tag of the source tarball for each successive RPM build (to
synchronize the two releases). This is your choice, of course (you're the
author, after all), but does anything actually change in the tar.gz release? It
would be easier to maintain this package if you leave the "release" tag to
indicate *RPM* releases, and just keep a "version" tag for the tarball (this is
how it usually works, anyhow).

So, in short, how it usually works:
RPM packages foo-1.3-1, foo-1.3-5, foo-1.3-6 all use the same source: foo-1.3.tar.gz
The different "release" tags merely state that something specific to the RPM has
changed, not the upstream program. In this fashion, if the source tarball
changes (say, to foo-1.3.1.tar.gz), the RPM's release tag is reset, so the RPM
package becomes foo-1.3.1-1.tar.gz.
Notice that the release tag only shows changes in the RPM itself (specfile
changes, etc), not changes in the upstream source. And everytime the source
changes, RPM's release tag goes back to 1. 
This is a packaging rule in Fedora, so if you decide to keep the "-release" in
the upstream tarball, you have to put that into your "Version" tag in the spec,
and change the "-" character to something else, perhaps a '.'. In other words,
for the tarball andutteye-client-2.3-7.tar.gz (on the website), the resulting
RPM package should be something like:
andutteye-client-2.3.7-1.noarch.rpm
or
andutteye-client-2.3_7-1.noarch.rpm

* rpmlint isn't silent (run it on the binary rpm, not the .src.rpm :-) ), but a
lot of the output has to do with the andutteye user account, as well as the
man-page stuff. Some interesting entries that need to be addressed:

E: andutteye-client non-readable /etc/andutteye/andutteyed.conf 0640
W: andutteye-client non-conffile-in-etc /etc/andutteye/andutteyed.conf

-- change the permissions for this file, and mark it as %conf in %files

W: andutteye-client service-default-enabled /etc/init.d/andutteyed

-- I don't have enough experience to comment on this. Depending on the service,
it may or may not be a good thing to have this specific service enabled by
default. In your case, I'm leaning towards "ok", but I'm sure your sponsor will
be able to advise you better on this.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.