[comp.sys.sun] Problem with creating users with SNAP

mmorse@z.nsf.gov (Michael H. Morse) (03/30/89)

I am having a problem with SNAP in that it no longer will create a user.
I am running on the master yellow page server.  The message I receive is
as follows:

   The program cannot prepare changes to this user's
   entries in the Yellow Pages database.

I have tried a complete rebuild of the YP databases as suggested in the
release notes for 4.0.1.  (I am running 4.0.2 pre-release.) The manual
method described in 386i Advanced Administration and modified in the Admin
release notes works just fine, so I know there's nothing obviously wrong
with the data in YP.

Has anybody seen this problem and solved it?

--Mike

Michael Morse                           Internet: mmorse@note.nsf.gov
National Science Foundation               BITNET: mmorse@NSF
                                       Telephone: (202) 357-7659

mmorse@z.nsf.gov (Michael H. Morse) (04/21/89)

I have discovered the answer to this question I posted:

>    I am having a problem with SNAP in that it no longer will create a 
> user.  I am running on the master yellow page server.  The message I
> receive is as follows:

>    The program cannot prepare changes to this user's
>    entries in the Yellow Pages database.

>    I have tried a complete rebuild of the YP databases as suggested
> in the release notes for 4.0.1.  (I am running 4.0.2 pre-release.)  
> The manual method described in 386i Advanced Administration and
> modified in the Admin release notes works just fine, so I know there's
> nothing obviously wrong with the data in YP.

>    Has anybody seen this problem and solved it?

By looking back through my change log, and backing out each change, I was
able to determine the problem and the solution.  I had edited
/etc/ypaliases myself (outside of SNAP) and a line that should have been:

    users:usera,userb,userc

had been "enhanced" (by me) to:

     users: usera, userb, userc

When I removed the spaces SNAP stopped complaining.

[flame on]
I spent about three full days on this problem.  How long would it have
taken some SUN developer to have written code that ignored whitespace?
How long would it have taken to write an error message that at least
mentioned which Yellow Pages file contained the "error"?  Frankly, this
is just ridiculously sloppy development!
[flame off]

The moral of the story is that SNAP is incredibly picky about what it
finds in the files that it uses, and very parsimonious with error
information.  To give the developers the benefit of the doubt, let's
assume they were under intense time pressure.  Keep meticulous records of
any changes you make to the yellow pages files.


--Mike

Michael Morse                           Internet: mmorse@note.nsf.gov
National Science Foundation               BITNET: mmorse@NSF
                                       Telephone: (202) 357-7659

pat@decwrl.dec.com (Pat Lashley) (04/27/89)

mmorse@z.nsf.gov (Michael H. Morse) writes:
>X-Sun-Spots-Digest: Volume 7, Issue 214, message 9 of 13
>
>I am having a problem with SNAP in that it no longer will create a user.
>I am running on the master yellow page server.  The message I receive is
>as follows:
>
>   The program cannot prepare changes to this user's
>   entries in the Yellow Pages database.
>
>I have tried a complete rebuild of the YP databases as suggested in the
>release notes for 4.0.1.  (I am running 4.0.2 pre-release.) The manual
>method described in 386i Advanced Administration and modified in the Admin
>release notes works just fine, so I know there's nothing obviously wrong
>with the data in YP.

I haven't found any documentation of exactly what SNAP expects/requires,
but here are a few things to check:

	1) Is there an existing entry or reference to that username in any of:
		a) /etc/ypaliases
		b) /etc/auto.home
		c) /etc/yppasswd
		3) /etc/ypgroup

	2) Does the primary group for that user have valid entries in all
	   of the above mentioned files ?  (You can further test for group
	   validity by attempting to modify the group entry.  i.e. add a
	   new default secondary group.)

	3) Does the home directory (/files/home/GROUPNAME/USERNAME) already
	   exist ?  (I think that this usually generates a different
	   message, but check -everything-.)

Hope that this helps...
-Pat

Copyright (c) 1989 PM Lashley under the terms of the GNU General Public License
PMLashley	...{sun | megatest | sts | zygot}!cohesive!kla!pat
<<< I haven't lost my mind.  It's backed up on tape somewhere... >>>

tim@prism.llnl.gov (Tim Voss) (04/27/89)

>>>
>>>I am having a problem with SNAP in that it no longer will create a user.
>>>I am running on the master yellow page server.  The message I receive is
>>>as follows:
>>>
>>>   The program cannot prepare changes to this user's
>>>   entries in the Yellow Pages database.
>>>
>>>I have tried a complete rebuild of the YP databases as suggested in the
>>>release notes for 4.0.1.  (I am running 4.0.2 pre-release.) The manual
>>>method described in 386i Advanced Administration and modified in the Admin
>>>release notes works just fine, so I know there's nothing obviously wrong
>>>with the data in YP.
>>>
>>>Has anybody seen this problem and solved it?
>>>
>>>--Mike
>>>
>>>Michael Morse                           Internet: mmorse@note.nsf.gov
>>>National Science Foundation               BITNET: mmorse@NSF

Yes - seen it. Worked around it!
I noticed that SNAP seems to get stuck in a funny state, where it has
trouble doing almost anything - creating users is just one example.
After some experimenting, I resolved the problems by:
	quiting SNAP (get the thing out of memory)
	restarting SNAP.

Here's one other little discovery:

	DON'T use the group 'Wheel' if you are going to add users!

	i.e. If you are a member of the wheel group, and you try to add
	a new user (via SNAP) - that user's home directory does NOT
	get exported ! (Who knows what-else might be wrong with
	the new acct you create.  I noticed other problems which will
	plague users added in this way).
	Bottom line:  DON'T use the group 'Wheel' for SNAP administration.

--Tim Voss
Lawrence Livermore National Lab
tim@prism.llnl.gov