sendmail and NIS managed aliases problem

sendmail and NIS managed aliases problem

Post by L. Scott Emmo » Thu, 27 Aug 1992 06:49:14




>The handling of the alias map by NIS in 3.1 is broken  it ignores it and
>instead consults only the local file ie /usr/lib/aliases.
>It is not necessary to have any NIS token in the alias file. The
>way it should work is that the local file is consulted first before the
>NIS map is used. IBM have supplied a fix for 3.2 but I am as yet unable
>to comment on whether or not this has fixed the problem.

Thanks for the response. We'll get the fix for 3.2, and see if that
helps. I find it rather disconcerting that 3.2 was shipped with such
major bugs: i.e. software that just plain doesn't work. Was it even
tested before being shipped?

Regarding tokens, It seems the O'Reilly & Associates, Inc book
"Managing NFS and NIS" (April, 1992) disagrees with AIX regarding
tokens. For example:

Token for               AIX             from O'Reilly & Assoc

passwd                  +::0:0::        +:*:0:0:::
group                   +:              +:*:*
aliases                 <none>            +

So, which format is the "standard" NIS format? Is it relatively
vendorindependent, is Hal Stern (author of Managing NFS and NIS)
wrong and/or confused, or has AIX broken from the "standard"??

Thanks for your help,

                           L. Scott Emmons
                      CableData  Research Center
                     csusac.csus.edu!cdsac!scotte

 
 
 

sendmail and NIS managed aliases problem

Post by Michael Richards » Thu, 27 Aug 1992 12:20:28




>>The handling of the alias map by NIS in 3.1 is broken  it ignores it and

  3.1 NIS also ``forgets'' to consult the local password file. If an
NIS server is not available, (like, because the network isn't there or
the interface becomes foobar for some reason) then you can't login at
all. Boot from tape. Moral: be very wary about letting 3.1.x machines
run ypbind...

Quote:>>instead consults only the local file ie /usr/lib/aliases.
>>It is not necessary to have any NIS token in the alias file. The
>>way it should work is that the local file is consulted first before the
>>NIS map is used. IBM have supplied a fix for 3.2 but I am as yet unable
>>to comment on whether or not this has fixed the problem.

  I got the patch. Yes, it works quite well. I've noticed that I
occasionally need to be do a refresh -s sendmail on clients, but I
haven't tracked that down, nor have I seen it lately.

Quote:>major bugs: i.e. software that just plain doesn't work. Was it even
>tested before being shipped?

  As if IBM is the only one that does this :-)

Quote:>Token for           AIX             from O'Reilly & Assoc

>passwd                      +::0:0::        +:*:0:0:::
>group                       +:              +:*:*
>aliases                     <none>            +

  Yes, it is confusing. Does the 3.2 fixed sendmail ever look at the
local aliases?

Quote:>wrong and/or confused, or has AIX broken from the "standard"??

--
  :!mcr!:           | #include <ansi-std/disclaimer.h>  +1 613 592 5780


 
 
 

sendmail and NIS managed aliases problem

Post by Mark W. East » Fri, 28 Aug 1992 00:12:00



>     3.1 NIS also ``forgets'' to consult the local password file. If an
>   NIS server is not available, (like, because the network isn't there or
>   the interface becomes foobar for some reason) then you can't login at
>   all. Boot from tape. Moral: be very wary about letting 3.1.x machines
>   run ypbind...

You should be able to overcome this by making the 3.1.x machine a
client of itself.

Quote:>   >Token for            AIX             from O'Reilly & Assoc

>   >passwd                       +::0:0::        +:*:0:0:::
>   >group                        +:              +:*:*
>   >aliases                      <none>            +

I believe the answer has to do with security and not just NIS.
Placing "+:" or "+::" on many systems means that anyone can sign in to
root as "+" with no password.
--

----------------------------------------------------------------    /|  -
Mark W. Easter            FlightSafety International               / | /|
Staff Engineer            Simulation Systems Division         -----------
Computer Systems Group    Broken Arrow, Oklahoma 74012    Flight   \ |  

                   "You wreck 'em - we'll rack 'em"                      
----------------------------------------------------------------------------

 
 
 

sendmail and NIS managed aliases problem

Post by Curt Finch 903 2F021 c.. » Fri, 28 Aug 1992 00:23:46



>3.1 NIS also ``forgets'' to consult the local password file. If an
>NIS server is not available, (like, because the network isn't there or
>the interface becomes foobar for some reason) then you can't login at
>all. Boot from tape. Moral: be very wary about letting 3.1.x machines
>run ypbind...

Not true.
It always looks in the local /etc/passwd file first, up until it finds
a '+' or a '-' there.

Most people hang anyway trying to log in as root (root is before the
'+') because they are serving the /etc/group file also.  The only way
the system can determine root's grouplist is to read the whole
/etc/group file and the entire NIS group map, (if there's a '+' in
/etc/group.)  There's really no way to fix this.

There was a bug in 3.1 where it would try to bind anyway, (and hang if
the server was dead,) even for root with no NIS group serving.  That
should be fixed in 3.2 and in 2007 or 2008, (i forget which.)

Moral:  Don't be wary, just run the latest stuff.
--

My views are unrelated to those of IBM     |        Austin, TX
  Social Security isn't a retirement plan.  It's middle class welfare.

 
 
 

sendmail and NIS managed aliases problem

Post by Ian Mor » Fri, 28 Aug 1992 19:32:30



Quote:

>Regarding tokens, It seems the O'Reilly & Associates, Inc book
>"Managing NFS and NIS" (April, 1992) disagrees with AIX regarding
>tokens. For example:

>Token for           AIX             from O'Reilly & Assoc

>passwd                      +::0:0::        +:*:0:0:::
>group                       +:              +:*:*
>aliases                     <none>            +

>So, which format is the "standard" NIS format? Is it relatively
>vendorindependent, is Hal Stern (author of Managing NFS and NIS)
>wrong and/or confused, or has AIX broken from the "standard"??

All NIS clients on our network do not require a token in the alias
file, machines include Dec Ultrix, DG AViiON, RS6000, HP, Siemens.
I can only assume that the book is wrong. IBM haven't broken the
standard they simply ignore it!

Quote:>                       L. Scott Emmons
>                  CableData  Research Center
>                 csusac.csus.edu!cdsac!scotte

--


ICS Computing Group Ltd.      UUCP:      ...{uknet,uunet,mcsun}!icsbelf!ianm
Belfast, N. Ireland.          Fidonet:   2:440/59.5 & 2:257/10.1

 
 
 

sendmail and NIS managed aliases problem

Post by Ian Mor » Fri, 28 Aug 1992 21:50:04




>There was a bug in 3.1 where it would try to bind anyway, (and hang if
>the server was dead,) even for root with no NIS group serving.  That
>should be fixed in 3.2 and in 2007 or 2008, (i forget which.)

>Moral:  Don't be wary, just run the latest stuff.

Is there a deeply buried menu option in SMIT for handling the
addition of NIS users to the passwd file, or does all NIS management
have to be done via raw editing of the various /etc files?


>My views are unrelated to those of IBM     |        Austin, TX
>  Social Security isn't a retirement plan.  It's middle class welfare.

--


ICS Computing Group Ltd.      UUCP:      ...{uknet,uunet,mcsun}!icsbelf!ianm
Belfast, N. Ireland.          Fidonet:   2:440/59.5 & 2:257/10.1

 
 
 

sendmail and NIS managed aliases problem

Post by Michael Richards » Wed, 02 Sep 1992 04:50:40




>>3.1 NIS also ``forgets'' to consult the local password file. If an
>Not true.
>It always looks in the local /etc/passwd file first, up until it finds
>a '+' or a '-' there.

  Fine, it is rather hard to determine where it is getting hung if one
can't get in at all.

Quote:>'+') because they are serving the /etc/group file also.  The only way
>the system can determine root's grouplist is to read the whole
>/etc/group file and the entire NIS group map, (if there's a '+' in
>/etc/group.)  There's really no way to fix this.

  Sure there is, don't read the group list for root.
  I am pretty sure I have been able to login as root when NIS is dead
on a 3.2 machine, btw.

Quote:>There was a bug in 3.1 where it would try to bind anyway, (and hang if
>the server was dead,) even for root with no NIS group serving.  That
>should be fixed in 3.2 and in 2007 or 2008, (i forget which.)

  3.2 fixes it. We have customers still at 3.1.5, so we have to keep some
3.1.5 machines around. I'd move them to 3.2 if I could.

--
  :!mcr!:           | #include <ansi-std/disclaimer.h>  +1 613 592 5780

 
 
 

sendmail and NIS managed aliases problem

Post by Charles J McGui » Thu, 03 Sep 1992 22:23:20


        .
        .

Quote:>  Sure there is, don't read the group list for root.
>  I am pretty sure I have been able to login as root when NIS is dead
>on a 3.2 machine, btw.

Not true, at least from my 3.2 machines. The only way I can have root
login to a client when NIS is dead is to remove the +: from /etc/group.

Charlie McGuire
Computer Science Dept.
The University of Montana

 
 
 

sendmail and NIS managed aliases problem

Post by Curt Finch 903 2F021 c.. » Sat, 05 Sep 1992 07:48:50






>>  Sure there is, don't read the group list for root.

If we did this, wouldn't we be nonstandard in the industry?
Isn't that what people * about most often with AIX, (for
        example qdaemon.)

So you're advocating we never read root's grouplist?  Or just don't
read it when no NIS server can be found? (which means your login
would hang for 1 minute and then work, and then what would you do
if the NIS server came back halfway through the login, etc.....)

I'm not saying it's impossible, I'm just asking...

What would YOU do?  How would YOU solve these problems?

Quote:>>  I am pretty sure I have been able to login as root when NIS is dead
>>on a 3.2 machine, btw.
>Not true, at least from my 3.2 machines. The only way I can have root
>login is if there's not + in /etc/group.

Exactly.  Industry standard behaviour I believe.
--
--

My views are unrelated to those of IBM     |        Austin, TX
 FICA doesn't help the poor.  It mostly goes to old people with incomes >$40k.
 
 
 

sendmail and NIS managed aliases problem

Post by Michael Richards » Sun, 06 Sep 1992 00:47:03



Quote:>If we did this, wouldn't we be nonstandard in the industry?

  It is one thing to be non-standard. It is quite another thing to be
to horibly complex that that I daren't leave its configuration to mere
mortals:

Quote:>Isn't that what people * about most often with AIX, (for
>    example qdaemon.)

  and it can't even figure out what kind of file I fed it and do the
appropriate thing. Users don't care if it is postscript or text, or...
they just want it printed.

Quote:>So you're advocating we never read root's grouplist?  Or just don't

  It hardly matters does it? Root can access the files anyway. Users
shouldn't be logging in as root anyway --- except to fix the system.
For routine maintenance su would be preferred.
  And while you are looking at NIS and passwd/login: *any* root user's password,
(not just the one named `root') should be valid when changing unknown
passwords. We'd like to do away with the user `root' anyway, we
already have 4 or 5 rootblah accounts for the people that need to have
root access. That way we don't have to share passwords, and when
someone leaves, we don't need to change everyone's root password.
  Also, that /etc/security/login stuff looks rather usefull --- too
bad it can't be NIS'ed (probably in a seperate map)
  These two options, should be just that: options.

Quote:>read it when no NIS server can be found? (which means your login
>would hang for 1 minute and then work, and then what would you do
>if the NIS server came back halfway through the login, etc.....)

  Logout and log back in. Please, don't forget to think just because
naive user wouldn't know to do in situation X. The naive user is
screwed if they wind up having to worry about it anyway.
  What if the NIS server isn't coming back because machine has got the
wrong IP address configured? E.g. a new admin person came along, set things
up, did an ifconfig, bashed /etc/hosts, started NIS, and then came
back after a powerfailure? "SMIT? What's that?", they say.
  What if there is no ethernet card anymore?

Quote:>What would YOU do?  How would YOU solve these problems?

  Always let root login on the console.

Quote:>>login is if there's not + in /etc/group.

  Having `+' in /etc/group is too usefull to me. Having NIS is too
usefull. 3.1.5 won't let a user login if the group that /etc/passwd
says they belong to doesn't exist or they aren't listed in that group.
3.2 gives a `setgroups' error, which it ignores.

Quote:>Exactly.  Industry standard behaviour I believe.

  How about:
    a) interlocked (dialin/dialout) modem ports
    b) real man pages. info belongs on a CD if you've got a player.
    c) a usable (from the admin point of view) / partition under 3.2.
 I shouldn't need /usr mounted. 3.2 was a step backward compared to 3.1.5.
    d) BSD lpr,lpd
    e) normal system daemons --- I'd like to be able to forget about
ODM when dealing with inetd, and friends. I have no idea how ODM's
version of /etc/services and the NIS version interact. I just know
that they complicate my life, not simplify it.

>--

>My views are unrelated to those of IBM     |        Austin, TX
> FICA doesn't help the poor.  It mostly goes to old people with incomes >$40k.

--
  :!mcr!:           | #include <ansi-std/disclaimer.h>  +1 613 592 5780

 
 
 

1. Solaris 2.6 NIS /sendmail 8.9.1a aliases problem -- fyi

Greetings.  I thought I would pass this on.  Having recently upgraded
everything in sight I discovered that my NIS server could no longer make
the mail.aliases NIS maps.  Apparently the "sendmail -bi" line in the
NIS Makefile was creating a NEWDB database file,and "mkalias" couldn't
understand it.  At least, that is what it looked like was happening.
This was 'corrupting' the yp map data base and basically breaking
everything.

I got a tip from the Sun bug report 1262695, and changed my
/var/yp/Makefile to read as the following, and now it works.
(By the way, beware of cut/paste breaking the lines if you copy this
using cut & paste!)

aliases.time: $(ALIASES)


 $(MKALIAS) $(YPDBDIR)/$(DOM)/mail.aliases
$(YPDBDIR)/$(DOM)/mail.byaddr;







Department of Computer Science                          504-280-7190
University of New Orleans                               504-280-7228
(fax)
New Orleans, LA  70148                                  504-723-6953
(pcs)

2. im unable to setup ttySx

3. Problem sendmail 8.9.3 and constructing NIS aliases database

4. Printcap entry for Panasonic KX-2023

5. Problem -- Auto Rebuild of Sendmail Aliases (8.9.0, Solaris, NIS)

6. xrn binary from tsx-11: no scroll bars?

7. SENDMAIL problem: Aliasing non-local names in /etc/mail/aliases

8. gmake-ing auto-generated headers

9. script alias problem - Re: apache alias and script alias problem

10. NIS/aliases and sendmail.8.8.5

11. how to get HP-UX sendmail to look at NIS aliases?

12. Sendmail loops and NIS aliases

13. sendmail ignores NIS aliases map