Bug 658921 - setup should run newaliases in post
setup should run newaliases in post
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-12-01 11:08 EST by Orion Poplawski
Modified: 2010-12-03 10:42 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-03 10:42:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2010-12-01 11:08:08 EST
Description of problem:

Lots of machines are reporting since the 2.8.28-1.fc14 update:

Nov 30 03:21:29 zabbix sendmail[25261]: alias database /etc/aliases.db out of date

I think setup should run /usr/bin/newaliases in %post if it exists.

Version-Release number of selected component (if applicable):
Comment 1 Ondrej Vasik 2010-12-02 03:54:16 EST
Strange... because /etc/aliases was not updated and is marked %config(noreplace) ... It's a bit more difficult to run /usr/bin/newaliases in setup %post, as you don't have bash in the case of setup installation - and due to dependencies only lua scriptlets can be used in setup. So during installation this /usr/bin/newaliases will be not run anyway and in the case of setup package update, there is no added content to /etc/newaliases - it was probably modified by user or another package.
Comment 2 Ondrej Vasik 2010-12-02 05:11:38 EST
In other words - if user or other application modifies the default /etc/aliases, these are responsible for running newaliases (as recommended in default /etc/aliases) or restarting mailserver. I tend to close this NOTABUG.
Comment 3 Orion Poplawski 2010-12-02 10:38:44 EST
I sympathize with the issues, but what triggered the sendmail complaint is the timestamp of the file, which did change.  If this can't be dealt with, I think CANTFIX is the appropriate resolution.

But can't you test if /usr/bin/newaliases is present and run if it is?  Can lua not execute binaries? It's a binary, not a shell script.
Comment 4 Ondrej Vasik 2010-12-02 12:20:14 EST
Of course, it can be handled by lua script ( if posix.access("/usr/bin/newaliases", "x") then os.execute('/usr/bin/newaliases') end ). It should be harmless, but in most cases it is useless (as the update of setup should not change the /etc/aliases file)...
I really don't know why the timestamp changed - as the file itself was not changed for quite a long ... maybe I have some timepreserving issue in setup package. I'll check this...
Comment 5 Ondrej Vasik 2010-12-03 10:42:59 EST
Damned, you are right - git-archive - which is used for building tarballs - throws away timestamps. Ok, I'll run newaliases lua scriptlet part in future until I'll fix the timestamp preserving. Closing this RAWHIDE, if there will be future setup F-14 update, I'll include it there as well.

Note You need to log in before you can comment on or make changes to this bug.