--- EHNANCEMENT SUGGESTION (SO NO "EMERGE --INFO" INCLUDED/NEEDED) --- So I was wondering why I got cron mails telling me that my aide-database doesn't exist why still getting the regular mails from aide -C's output as it should be. The annoying thing was, that these irregular cron-mails were bounced messages from localhost.de (and not localhost) and I still couldn't get what was wrong until I found the cron-script installed by Aide. This script uses /bin/mail for dispatching the messages and somehow /bin/mail expands "localhost" to "localhost.de" while using postfix directly does it right. Anyways, my suggestion would be to make the installation of the cron-script optional, maybe via a useflag. Reproducible: Always Steps to Reproduce: n/a Actual Results: n/a Expected Results: n/a n/a
A use flag for installing one plaintext file plain sucks, we just recently got rid of USE=udev which was doing the same pointless thing. Why don't you configure your local mail correctly, use INSTALL_MASK or delete the cronscript if you don't want it?
(In reply to comment #1) > Why don't you configure your local mail correctly It is configured correctly. Unfortunately mailx seems to have the idea that mail-addresses in the form of user@host are incorrect and appends some tld to the host-part. I haven't found the origin for this expanding behaviour yet (I even straced it). As I wrote: Postfix, ping and everything else I could use resolve "localhost" correctly to 127.0.0.1 -- only mailx fails. >, use INSTALL_MASK Never heard of this one, I will have a look at it. > or delete the cronscript if you don't want it? because portage/etc-update would put it there, again leading me to the same problem once aide gets upgraded.
(In reply to comment #2) > (In reply to comment #1) > It is configured correctly. Unfortunately mailx seems to have the idea that > mail-addresses in the form of user@host are incorrect and appends some tld to > the host-part. File a bug about mailx. Meanwhile user@host. (the trailing dot is important) should work-around this broken behaviour.
INSTALL_MASK solved this problem. I am blocking the script now. > File a bug about mailx. Meanwhile user@host. (the trailing dot is important) > should work-around this broken behaviour. Why should I configure something (i.e. the Aide-Cronjob) I do not want to use at all? ;) I don't care about mailx since I do not use it. Instead, aide should probably utilize a sane and more forgiving MUA instead of mailx. The well known sendmail-symlink-wrapper magic could help, although I have to admit that I do not know how the various MTAs handle it.
The ebuild shouldn't be installing a script for cron to execute at all. It is fine to provide an example script and put it somewhere with the documentation or something where someone can copy it into place if they want, but it is troubling to have a daily cron job just show up when you install aide. It is also troubling to have to install a run-time dependency (which pulls in it's own dependencies) just for a script that really shouldn't be installed by default. I vote for installing the script into /usr/share/doc/aide-0.13.1/example or something, maybe put in an elog saying that it is there, and remove virtual/mailx from RDEPEND.
I would agree that installation of a default script is not really appropriate in this case. Filesystem integrity checking is complicated enough that a one-size-fits-all script is probably not going to do the job, particularly at large deployments. It is rather nonintuitive to install this utility and suddenly discover processes running out of cron and extraneous mail showing up, particularly if you were using an earlier version and already had your own infrastructure in place. I think providing an example script would be a much better approach. Thanks...
Removed /etc/cron.daily/aide in 0.13.1-r1
It looks like you forgot to remove virtual/mailx from RDEPEND.
