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@xxxxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review