Hello again, fellow sys admins.

I have been assigned to migrate the directory services from an old
SunOS 4.1.3 box to a supported, stable server. This is so old that it
is still referred to as yp (Yellow Pages?), which from what I
understand is simply the old name for NIS. It is serving out yp
services to a variety of servers and OS; from Solaris 2.8 to IBM AIX,
to NeXT machines (if you can believe that)....

I have never worked with yp or NIS before. Essentially, what I though
would be the best method would be to simply initialize a new slave
server, then promote it to be the 'master'. I've got the O'Reilly book
'Managing NFS and NIS'; I think it is the 1st edition, but I'm using it
to get a grasp of the concepts.

I'd appreciate input or suggestions on the following questions:

- IS yp and NIS the same product? I notice that we're running ypbind,
use all the 'ypxxxx" commands. The NIS manual refers to it being a
renamed product, but will I have compatibility issues?

- Can someone shed any light or offer any suggestions on a migration
plan, and/or versions of NIS to use/avoid?

- What, if any, benefits would I gain by skipping to NIS+ ?  If they
are many, would I be better serverd by migrating the yp maps to an NIS
master server, THEN upgrading everything to NIS+?

As always, thanks in advance; I don't know what I'd do without thos
venue...


Joe D.

In comp.unix.solaris Joe D. <newbie_from_newbie@yahoo.com> wrote:
> Hello again, fellow sys admins.
> 
> I have been assigned to migrate the directory services from an old
> SunOS 4.1.3 box to a supported, stable server. This is so old that it
> is still referred to as yp (Yellow Pages?), which from what I
> understand is simply the old name for NIS. It is serving out yp
> services to a variety of servers and OS; from Solaris 2.8 to IBM AIX,
> to NeXT machines (if you can believe that)....
> 
> I have never worked with yp or NIS before. Essentially, what I though
> would be the best method would be to simply initialize a new slave
> server, then promote it to be the 'master'. I've got the O'Reilly book
> 'Managing NFS and NIS'; I think it is the 1st edition, but I'm using it
> to get a grasp of the concepts.
> 
> I'd appreciate input or suggestions on the following questions:
> 
> - IS yp and NIS the same product? I notice that we're running ypbind,
> use all the 'ypxxxx" commands. The NIS manual refers to it being a
> renamed product, but will I have compatibility issues?

No problems. They're the same product, and the name change was for legal
reasons (I believe BT owned a trademark on "Yellow Pages")

> - What, if any, benefits would I gain by skipping to NIS+ ?  If they
> are many, would I be better serverd by migrating the yp maps to an NIS
> master server, THEN upgrading everything to NIS+?

Don't move to NIS+. Not now, not ever.
On the one hand, it has very little in common with NIS other than the name.
You don't really migrate from NIS to NIS+, you redeploy.
Secondly, it's end-of-life. If you're moving away from NIS, you'll probably
want to go to LDAP. Fair warning, though--don't start that process until
you're done a lot of research, because LDAP is an enormous and complex world.

NIS is very simple to work with. Everything is based on flat files, including
the configuration data itself (all conveniently located in /var/yp/Makefile).
If you haven't administered a naming service and NIS meets your needs, I'd
worry about building a new server for that first and not worrying about
migration until much later.

Colin

Joe D. wrote:
> - IS yp and NIS the same product? I notice that we're running ypbind,
> use all the 'ypxxxx" commands. The NIS manual refers to it being a
> renamed product, but will I have compatibility issues?

Joe,  Yes.  No.

> - Can someone shed any light or offer any suggestions on a migration
> plan, and/or versions of NIS to use/avoid?

If you're staying on Solaris,  just go to Solaris 10.

> - What, if any, benefits would I gain by skipping to NIS+ ?  If they

None.  Even if NIS+ wasn't already EOL'ed, it is an abomination
to admin.  I upgraded a previous employer the other direction
(NIS+ -> NIS), one of the *best* admin moves I ever made.  :-)

1) You need to know for *all* your existing clients if they
    broadcast for servers or use a static list.  The latter is
    a little more secure  in a hostile environment, but a
    slight pain-in-the-rear for you; you will have to become
    very proficient in modifying those lists.

    Given your very mixed client set, you may well have both.

2) If you don't have a slave server at all right now, create one.
    Confirm (by yanking the network cable on the master
    server during off-hours) that each of your client types will
    successfully switch.  This is not as painless as you would
    think; typically requires an rsh to each client to wake it up
    and a minute or two for it to give up and switch.

3) Confirm that the slave server successfully updates from the master.

4) On your new master-server-to-be, create a new master server from
    the old master server data, with a completely different domainname.
    You'll probably have makefile work to do.  The only client bound to
    this guy will be itself.  Confirm that you can update all the maps,
    and that all the maps work.

5) Make one last update of the map sources from the old master to
    new master.  Shut down the old master.  Force all the clients
    to rebind to the slave; you can live off this indefinitely as long
    as you don't need to update a map.

6) Change the domainname of the new server to the real domainname,
    and restart.  Force at least one client to bind to the new master
    server.

7) Shutdown NIS on the slave server and wipe out all YP data.
    Re-ypinit the slave server to the new master.  Confirm that
    updates from the new master all work.

You can skip a lot of the intermediate steps if you can afford to
just shut the whole floor down for a Saturday.  You can't skip
1) and 4), though!

Hello Joe,

Joe D. schrieb/wrote:

> I have been assigned to migrate the directory services from an old
> SunOS 4.1.3 box to a supported, stable server. This is so old that it
> is still referred to as yp (Yellow Pages?), which from what I
> understand is simply the old name for NIS. 

Exactly.

> It is serving out yp
> services to a variety of servers and OS; from Solaris 2.8 to IBM AIX,
> to NeXT machines (if you can believe that)....

Oh, I can. ;-)

> I have never worked with yp or NIS before. Essentially, what I though
> would be the best method would be to simply initialize a new slave
> server, then promote it to be the 'master'.

Yes, I think that would be one solution.

> I've got the O'Reilly book
> 'Managing NFS and NIS'; I think it is the 1st edition, but I'm using it
> to get a grasp of the concepts.
>
> I'd appreciate input or suggestions on the following questions:
>
> - IS yp and NIS the same product? 

It is.

> I notice that we're running ypbind,
> use all the 'ypxxxx" commands. The NIS manual refers to it being a
> renamed product, but will I have compatibility issues?
>
> - Can someone shed any light or offer any suggestions on a migration
> plan, and/or versions of NIS to use/avoid?

I recently had to do a migration from an AIX NIS server to a linux
machine.
What I did was writing some simple shell scripts that took the output
of "ypcat passwd" on the old server, "awk-ed" out the real user
entries and put them together in the right manner to form the lines
for (a) /etc/passwd and (b) /etc/shadow.
We just had to add the resulting files to the new system's /etc/shadow
respectively /etc/passwd and fire up the build of the NIS maps.
What was left to do was copying the users' HOMEs onto the new server.

> - What, if any, benefits would I gain by skipping to NIS+ ?  If they
> are many, would I be better serverd by migrating the yp maps to an NIS
> master server, THEN upgrading everything to NIS+?

I'm not that familiar with the differences between NIS and NIS+, but
I'm sure somebody else here is. ;-)

Regards,
Christian
-- 
Christian Schmidt | Germany | ChriSchmiLi@gmx.de
No HTML Mails, please!!
De eene hett 'n Rittergut, de annere ritt 'n Gitter rut.

jayl-news@accelerant.net wrote:
> Joe D. wrote:
> 
>>- IS yp and NIS the same product? I notice that we're running ypbind,
>>use all the 'ypxxxx" commands. The NIS manual refers to it being a
>>renamed product, but will I have compatibility issues?
> 
> 
> Joe,  Yes.  No.
> 
> 
>>- Can someone shed any light or offer any suggestions on a migration
>>plan, and/or versions of NIS to use/avoid?
> 
> 
> If you're staying on Solaris,  just go to Solaris 10.
> 
> 
>>- What, if any, benefits would I gain by skipping to NIS+ ?  If they
> 
> 
> None.  Even if NIS+ wasn't already EOL'ed, it is an abomination
> to admin.  I upgraded a previous employer the other direction
> (NIS+ -> NIS), one of the *best* admin moves I ever made.  :-)
> 
> 1) You need to know for *all* your existing clients if they
>     broadcast for servers or use a static list.  The latter is
>     a little more secure  in a hostile environment, but a
>     slight pain-in-the-rear for you; you will have to become
>     very proficient in modifying those lists.
> 
>     Given your very mixed client set, you may well have both.
> 
> 2) If you don't have a slave server at all right now, create one.
>     Confirm (by yanking the network cable on the master
>     server during off-hours) that each of your client types will
>     successfully switch.  This is not as painless as you would
>     think; typically requires an rsh to each client to wake it up
>     and a minute or two for it to give up and switch.
> 
> 3) Confirm that the slave server successfully updates from the master.
> 
> 4) On your new master-server-to-be, create a new master server from
>     the old master server data, with a completely different domainname.
>     You'll probably have makefile work to do.  The only client bound to
>     this guy will be itself.  Confirm that you can update all the maps,
>     and that all the maps work.
> 
> 5) Make one last update of the map sources from the old master to
>     new master.  Shut down the old master.  Force all the clients
>     to rebind to the slave; you can live off this indefinitely as long
>     as you don't need to update a map.
> 
> 6) Change the domainname of the new server to the real domainname,
>     and restart.  Force at least one client to bind to the new master
>     server.
> 
> 7) Shutdown NIS on the slave server and wipe out all YP data.
>     Re-ypinit the slave server to the new master.  Confirm that
>     updates from the new master all work.
> 
> You can skip a lot of the intermediate steps if you can afford to
> just shut the whole floor down for a Saturday.  You can't skip
> 1) and 4), though!
> 

an add on to nis would be some C2 security,
    to hide password strings etc.
    http://docs.sun.com search for passwd.adjunct
    see section "Using NIS with C2 Security"
    $ ypcat passwd will then not echo password strings,
    just ## in the pw field.
/Jorgen

jayl-news@accelerant.net wrote:
> Joe D. wrote:
>> - What, if any, benefits would I gain by skipping to NIS+ ?  If they
> 
> None.  Even if NIS+ wasn't already EOL'ed, it is an abomination
> to admin.  I upgraded a previous employer the other direction
> (NIS+ -> NIS), one of the *best* admin moves I ever made.  :-)

NIS+ isn't *that* bad.  It does have quite a learning curve, and
when I was learning it, at least, Sun's documentation wasn't that
great.  But it works fine once you've learned it and set it up.

> 1) You need to know for *all* your existing clients if they
>     broadcast for servers or use a static list.  The latter is
>     a little more secure  in a hostile environment, but a
>     slight pain-in-the-rear for you; you will have to become
>     very proficient in modifying those lists.
> 
>     Given your very mixed client set, you may well have both.

That's true, although personally I would try not to change the
list of servers very much.

Instead, I would create in the DNS a set of hostnames for NIS servers
(like nis-master, nis-slave1, nis-slave2, etc.), and if it's necessary
to move the NIS service around to different servers, just move it
and then change the DNS stuff so that the clients point to the new
servers without clients' configuration files needing to be changed.

> 2) If you don't have a slave server at all right now, create one.
>     Confirm (by yanking the network cable on the master
>     server during off-hours) that each of your client types will
>     successfully switch.  This is not as painless as you would
>     think; typically requires an rsh to each client to wake it up
>     and a minute or two for it to give up and switch.
> 
> 3) Confirm that the slave server successfully updates from the master.
> 
> 4) On your new master-server-to-be, create a new master server from
>     the old master server data, with a completely different domainname.
>     You'll probably have makefile work to do.  The only client bound to
>     this guy will be itself.  Confirm that you can update all the maps,
>     and that all the maps work.
> 
> 5) Make one last update of the map sources from the old master to
>     new master.  Shut down the old master.  Force all the clients
>     to rebind to the slave; you can live off this indefinitely as long
>     as you don't need to update a map.
> 
> 6) Change the domainname of the new server to the real domainname,
>     and restart.  Force at least one client to bind to the new master
>     server.
> 
> 7) Shutdown NIS on the slave server and wipe out all YP data.
>     Re-ypinit the slave server to the new master.  Confirm that
>     updates from the new master all work.

While I agree this process should work, wouldn't it be about 1000
times easier just to create a new NIS master server with the same
domain name and the same source files (passwd, group, auto_home, etc.),
and set it up as a master server but just don't point clients at it
for a while?  Then when you're confident you've got everything moved
over, you should be able to just point the clients at the new system,
or if you want, you could even replace the old master with the new
master by changing IP addresses.  Yes, there will be a little bit
of downtime, but with proper planning, it only has to be as much
time as is needed to do a couple of "ifconfig" commands (and wait
for the arp caches to pick up the changes).

   - Logan

[I don't like this amount of crossposting, so I'll set followups]
Jorgen Moquist <jorgen.moquist@n.o.s.p.a.m.mailbox.swipnet.se> writes:

> an add on to nis would be some C2 security,
>    to hide password strings etc.
>    http://docs.sun.com search for passwd.adjunct
>    see section "Using NIS with C2 Security"
>    $ ypcat passwd will then not echo password strings,
>    just ## in the pw field.

        So has anyone tried this?  How well does it work?  Who gets to
ypcat 'passwd.adjunct' and get the better information; and how is it
restricted?  Are there any weird tricks that would be needed to use this
kind of trick on a multi-platform system?

                            - Tim Skirvin (tskirvin@ks.uiuc.edu)
-- 
   Theoretical and Computational    http://www.ks.uiuc.edu/~tskirvin/
Biophysics, Beckman Institute, UIUC    Senior Systems Administrator

In <tskirvin.20060501154457$5355@cairo.ks.uiuc.edu> tskirvin@killfile.org (Tim Skirvin) writes:

>[I don't like this amount of crossposting, so I'll set followups]
>Jorgen Moquist <jorgen.moquist@n.o.s.p.a.m.mailbox.swipnet.se> writes:

>> an add on to nis would be some C2 security,
>>    to hide password strings etc.
>>    http://docs.sun.com search for passwd.adjunct
>>    see section "Using NIS with C2 Security"
>>    $ ypcat passwd will then not echo password strings,
>>    just ## in the pw field.

>        So has anyone tried this?  How well does it work?  Who gets to
>ypcat 'passwd.adjunct' and get the better information; and how is it
>restricted?  Are there any weird tricks that would be needed to use this
>kind of trick on a multi-platform system?

We've been using it for years, under SunOS 4 and Solaris...

	$ ypmatch mills passwd
	mills:##mills:10700:104:Gary Mills:/home/myhome/mills:/bin/ksh
	$ ypmatch mills passwd.adjunct.byname
	Can't match key mills in map passwd.adjunct.byname.  Reason: no such map in server's domain.
	# ypmatch mills passwd.adjunct.byname
	mills:ghrJfzIfOcqr6:::::

The restriction is on the server side, and can be applied to other NIS
maps, such as shadow.byname if you have that one.  The server still has
to trust root on the client.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

tskirvin@killfile.org (Tim Skirvin) writes:
>[I don't like this amount of crossposting, so I'll set followups]
>Jorgen Moquist <jorgen.moquist@n.o.s.p.a.m.mailbox.swipnet.se> writes:

>> an add on to nis would be some C2 security,
>>    to hide password strings etc.
>>    http://docs.sun.com search for passwd.adjunct
>>    see section "Using NIS with C2 Security"
>>    $ ypcat passwd will then not echo password strings,
>>    just ## in the pw field.

>        So has anyone tried this?  How well does it work?  Who gets to
>ypcat 'passwd.adjunct' and get the better information; and how is it
>restricted?  Are there any weird tricks that would be needed to use this
>kind of trick on a multi-platform system?

Yes, it works very well on Sun. Has for ages (I originally did it on
SunOS v4.1.x). You have to be root on a NIS member to be able to see
the passwd.adjunct map (so don't let any random box be a NIS member
that you don't control). The restriction isn't very secure in this day
and age, but works well if you control everything on the segment that
you do NIS on. 

Unfortunatly, nobody else has implemented C2 Security NIS to the best
of my knowledge, so it'll only work for Solaris NIS only. Last time I
tried it, non C2 NIS worked fine to many platforms (ie. linux/FreeBSD/NeXT) 
but nobody else did anything with the C2 NIS maps. 

jayl-n;

Thanks. Yes, oddly enough, moving to Solaris 10 was just thrown at me
as well; will be my first experience with the OS. I'll be hitting the
books, I guess, but in the interim, is there any specific reason you
mention this in this post?  ie; is there something in Solaris 10 that
replaces NIS or I would need to be aware of (such as incompatibility,
specific configuration gotchas, etc?).

And again, thanks to you (and all responders to my post). It's great to
have a resource such as this to fall back on. I always try to find the
answer myself, but often times, posting here gets me specifics.

Sincerely;

Joe D.

In comp.unix.solaris Joe D. <newbie_from_newbie@yahoo.com> wrote:
> jayl-n;
> 
> Thanks. Yes, oddly enough, moving to Solaris 10 was just thrown at me
> as well; will be my first experience with the OS. I'll be hitting the
> books, I guess, but in the interim, is there any specific reason you
> mention this in this post?  ie; is there something in Solaris 10 that
> replaces NIS or I would need to be aware of (such as incompatibility,
> specific configuration gotchas, etc?).

From a NIS point of view, the only change is that Solaris 10 uses SMF
instead of /etc/init.d/* startup scripts. Put the files in place, and then
enable the services as necessary. ('svcs -a | egrep -i nis' will list them
all).

> And again, thanks to you (and all responders to my post). It's great to
> have a resource such as this to fall back on. I always try to find the
> answer myself, but often times, posting here gets me specifics.

This group is always happy to help people who are willing to learn.

Colin