Future: fhs 2.3 compliance for fc3
Stephen Smoogen
smoogen at lanl.gov
Fri Apr 2 19:23:16 UTC 2004
On Fri, 2 Apr 2004, Havoc Pennington wrote:
>On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
>> Once upon a time, Jeremy Katz <katzj at redhat.com> said:
>> > Heh, that's just sick. How about my statement holding for when the
>> > clients are set up correctly? :-) (ie, if you don't use local sendmail
>> > and just do smtp, then local /var/spool isn't needed)
>>
>> Way too many programs expect to be able to call /usr/sbin/sendmail to
>> assume everything will use SMTP. And really, that is how it should be;
>> why should every program be required to have an SMTP client built-in?
>>
>> The nice thing about that is that you are pretty much guaranteed that
>> you can send mail at any time, even if the network is down. Sendmail
>> (or another local mailer) will queue the mail locally and send it when
>> it can. It is not a good idea to have things like cron jobs get stuck
>> or lose their output because a remote SMTP server was unreachable.
>
>I think we have to assume that a managed read-only OS image sort of
>deployment would have some limitations in possible configurations and
>what apps could do. After all the whole point is to lock things down.
>
>One setup would be that each user has an outgoing mail queue in their
>home directory, since homedir already has to be writeable by the user
>and gets backed up and so forth. Surely you could provide a
>/usr/sbin/sendmail that worked this way.
>
>A queue in /var is suboptimal because it partially defeats the purpose
>of the deployment model - it leaves per-machine state to be corrupted,
>backed up, hacked, etc.
>
How is printing done? How do cron jobs mail when a services home
directory may not exist and the shell is nologin? Not trying to poke
holes as much as think things out-loud. I wonder if queues should go
under /var at all?
--
Stephen John Smoogen smoogen at lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --
More information about the fedora-devel-list
mailing list