>> >You mean "sounds to me like your machine wasn't completely configured
>> >BY SYSINST."  Yes, that's why I'm raising the issues.
>> 
>> sysinst isn't something i know all that much about.  i do, however,
>> know how i want my machines to behave, so i check all sorts of things
>> and tweak stuff manually all the time.  as to what sysinst does, or
>> how much it should or should not, i can't say.
>> 
><rant>
>When I first tried to come back from OpenBSD last Sept with 1.6, sysinst 
>didn't match its documentation.  I wrote up a long list of problems, and 
>some of them were fixed.

good.  feedback always helps.

>Now, I find that nobody seems to have noticed that sysinst has been 
>improperly configuring systems for months....  Yet, NetBSD has a list 
>dedicated to working on the installer?

not the installer, per se, though that's part of it.  tech-install is
involved in all the installation efforts.  sysinst isn't involved in
all of those.  fwtw.

>OpenBSD may have its problems, but the installer got better with every 
>release.  People actually use it!  It matches the documentation, and 
>the documentation is printed in every CD jacket.  Jeez o' Pete....
></rant>

good rant.  :)

>> >> > (A) PR install/21998
>> >> >
>> so you also want sysinst to do minor mta configuration and enable the
>> mta?  i'm not trying to be argumentative here, just trying to pin down
>> the points of contention.
> 
>In order for the system to be functional, sysinst has to enable a 
>default MTA.  It does.  Badly.

that all depends on what functionality you need.  if i had a laptop
that i used for nothing other than as an mp3 player, i wouldn't
consider mail an important part of it.  outside of the nightly and
weekly outputs, mail probably isn't a large part of a lot of systems.

>> >The sysinst needs to build a working and secure system.  Running
>> >internal security should be part of the default install -- of course!
>> 
>> sure.
> 
>Glad we agree.

me too.

>> >> >     Anyway, I'm thinking my approach would be a marked change of
>> >> >     policy, timely for a 2.0 release, that warrants wide discussion.
>
>And I meant *wide* discussion.  Is it time to change to postfix as the 
>default MTA?

could be, but to do so would be contentious.  for me, personally, i'd
grumble about getting money in the mail again, but that's story of a
different dead horse.

>> >> > (B) PR install/21999
>> >> >
>> ><quote>
>> >The sysinst adds a obviously unneccessary duplicate localhost line,
>> 
>> a duplicate localhost line doesn't hurt anyone...
> 
>True.  But that was an obvious place to modify the code simply, in 3 
>lines, with all the correct variables already in place, replacing a 
>minor redundancy with something useful.

okay, granted, but i still don't think that putting a record for
localhost.whatever.your.domain.is.now in the hosts file is all that
productive.  it might seem so in the short run, but over time it may
end up causing different problems.

>> actually, there is already a localhost zone that contains the
>> localhost name.  
>
>No.  Red herring.  It's not turned on by default, and therefore not 
>relevant to this discussion.

actually, no.  if you were using a local nameserver on your own
machine, some of these things that we've been discussing would not be
problems.

>> >Seems that "localhost.dom.ain" is not the same as 127.0.0.1 to me?!?!
>> 
>> particularly if "localhost.dom.ain" isn't in the dns.  it really ought
>> to be in the dns.
> 
>What DNS?  A standalone system has no DNS.  A workstation has no DNS. 

but your machine has access to dns.  if that dns is configured
wrongly, then it needs to be fixed.  otoh, if you don't want dns
access, you should not have configured your machine to use it.

>The DNS is maintained outside the box, and therefore is not a good 
>candidate for expection of a reliable and secure link to 127.0.0.1!

fine, but if you ask the dns for the ptr record for
1.0.0.127.in-addr.arpa and it says localhost.ying.tong.wibble.i.po,
you can't expect that we can fix it.  if you want that ptr record to
say localhost, you have to make sure it says localhost.

>> >Therefore, it is certainly possible (and therefore perversely likely)
>> >that the DNS zone "dom.ain." could have a record such as:
>> >           localhost      IN      A       10.10.10.10
>> >
>> >This would certainly intercept all the localhost traffic for the zone,
>> >at least in the current install, which expands all "localhost" to "localhost.dom.ain."
>> 
>> now here's where i'm getting confused.  do you mean literally
>> "localhost.dom.ain" or localhost.my.domain.name.whatever.it.is?
> 
>(sigh) localhost.my.domain.name.whatever.it.is

okay.

>> for what it's worth, i'm much in favor of the latter (the record being
>> in the dns, but not with the wrong address), but not the latter.
> 
>Can you see why this is a security issue?  How do you "enforce" this? 

if you don't trust the dns, use your own servers.  if you're using the
dns and you're not using your own servers, you're clearly making that
choice.

>Can you see how all root traffic would be intercepted?

no.

>> the problem with putting the localhost.dom.ain record in the hosts
>> file is that if your domain switches (as it will if you shift between
>> dhcp zones in wireless restaurants and cafes, etc), then your mail
>> will still suffer.  just not today.  tomorrow.  or the next day.  what
>
>Of course, that's true of the only other line in the hosts file.  So, 
>keeping these types of changes in the same place is pretty reasonable.

actually, keeping the hosts file as small as possible so that you
don't have other weird problems later is a better idea, imho.  dns was
invented for a reason.  the hosts file doesn't scale, and doesn't
change when people need it to.

imho, solaris is even worse at this.  on a given solaris box, i can
arrange for telnet, ssh, nslookup, and traceroute to the host called
"foo" all to resolve to different addresses.  i wouldn't exactly
consider that to be a feature.

>> sendmail ought to be doing is converting the "@localhost" portion to
>> "@fully.qualified.host.name", which it should already know, so that
>> your local mail gets delivered locally.
> 
>Great!  How?

well, first of all, sendmail needs to know that it's real name is
dreamer.citi.umich.edu.  it seems to know this from the log entries
that you posted.  secondly, it needs to know that localhost is another
name by which it might find itself being called.  the $w class in the
stock sendmail.cf tells it this, so that's also covered.
incidentally, your log entries don't show it trying to deliver mail to
root@localhost.citi.umich.edu, only to root.

Jun 27 03:23:30 dreamer sendmail[13580]: h5R7NUNE013580: from=root, size=347, class=0, nrcpts=1, msgid=<200306270723.h5R7NUNE013580@dreamer.citi.umich.edu>, relay=root@localhost
Jun 27 03:23:30 dreamer sendmail[13580]: h5R7NUNE013580: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30084, relay=localhost.citi.umich.edu. [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by localhost.citi.umich.edu.

all i see is "to=root", "ctladdr=root (0/0)", and "from=root".  that's
fine.  in fact, the only instance of localhost.citi.umich.edu is in
the "relay" tags, and that occurs because the submit.cf says this:

	D{MTAHost}[localhost]

so the local collection instance of sendmail that accepted the daily
and security outputs looks up localhost, gets 127.0.0.1, and then
looks up 127.0.0.1 in order to put what should be a canonicalized name
in the log entries.  it just so happens that the dns server you're
configured to talk to doesn't respond with "localhost", but instead
tells you "localhost.citi.umich.edu".  imho, that needs to be fixed.

>All we know is it doesn't do this now.  I'm proposing a fix to what it 
>actually does, not to some other possibility.

if you go fix your dns, we can move on to debating fixed points.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."