Migrating from yp to NIS - Unix

This is a discussion on Migrating from yp to NIS - Unix ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Migrating from yp to NIS

  1. Migrating from yp to NIS

    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.


  2. Re: Migrating from yp to NIS

    In comp.unix.solaris Joe D. 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

  3. Re: Migrating from yp to NIS

    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!


  4. Re: Migrating from yp to NIS

    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

  5. Re: Migrating from yp to NIS

    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

  6. Re: Migrating from yp to NIS

    [I don't like this amount of crossposting, so I'll set followups]
    Jorgen Moquist 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

  7. Re: Migrating from yp to NIS

    In tskirvin@killfile.org (Tim Skirvin) writes:

    >[I don't like this amount of crossposting, so I'll set followups]
    >Jorgen Moquist 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-

  8. Re: Migrating from yp to NIS

    tskirvin@killfile.org (Tim Skirvin) writes:
    >[I don't like this amount of crossposting, so I'll set followups]
    >Jorgen Moquist 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.


  9. Re: Migrating from yp to NIS

    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.


  10. Re: Migrating from yp to NIS

    In comp.unix.solaris Joe D. 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

+ Reply to Thread