ebuild log for sys-apps/baselayout-2.0.1 on evolone.org WARN: postinst The following users have non-existent shells! apache - /usr/sbin/nologin cron - /usr/sbin/nologin ldap - /usr/sbin/nologin postfix - /usr/sbin/nologin sshd - /usr/sbin/nologin Reproducible: Didn't try Actual Results: Reports incorrect information. Expected Results: Reports correct information, or nothing since it isn't an error, even if correctly reported. Also, another offered this opinion: The ebuild should have checked that a) the account does not have a shell and b) the account uid falls in the range of system accounts as per login.defs and c) therefore issued no postinst
Nope. Valid in this case is explicitly non-existant shells in the shell field. Even system users should have a valid shell. In this case /sbin/nologin (no /usr). Otherwise the pam_shells or other checks may fail.
fix your /etc/passwd then
(In reply to comment #2) > fix your /etc/passwd then > Like is mentioned here? http://bugs.gentoo.org/215698 I'd also note that the message, "The following users have non-existent shells" is just about as useful as no message at all... did I assign them shells? You should blame something (sys-apps/shadow) and as well suggest a fix in the message if it's such a trivial thing. This is why I asked about it on the mailing list and submitted a bug at the suggestion of another there. And sure enough, there's already a similar bug... against the offending package, with a fix. (And the suggestion not to annoy the users with it, IOW to fix it at the ebuild level, but no matter that, I suppose.) I think the elog messages should be informative, not cryptic and terse. (This isn't Windows, after all.) Perhaps the same principle should apply to replies from developers to users who are trying to help you make a better (read, more useful or user-friendly) product. Also, shouldn't this be resolved as a duplicate of http://bugs.gentoo.org/215698 -- since the problem seems to have originated there -- rather than as invalid?
the changes will not be automated: - we do not go modifying critical files on the fly, to easy to screw things up - people run tripwire and such to watch critical changes - people run cfgengine and such to push out critical files - people do not store files in /etc/passwd but use ldap/etc... for auth - people could have set the shell to something else on purpose but that location is now gone or it was a typo - people could create their own /usr/sbin/nologin to use rather than /sbin/nologin and for the same reason, we cant interpret the meaning of the missing shells
