I posted a four part request for help that concerned the installation
of NIS on a system that previously used files for the info sources.
The original questions I had were:
**************************************************************
1. The most pressing problem I am having at the moment is I keep getting
the following error when I attempt to do things like rebuild the aliases
database or create a new account using Solstice, all on the master server
running Sol2.5.1:
"couldn't find server for map: aliases"
or when rebuilding the aliases database:
/var/yp/methcenter/mail.aliases: 5 aliases, longest 16 bytes, 89 bytes total
/usr/lib/netsvc/yp/mkalias /var/yp/`domainname`/mail.aliases /var/yp/`domainname`/mail.byaddr;
updated aliases
2. I had to change all the users home directories paths from:
/x/y/home/username
to
/home/username
in order to get the home directories mounted on the slave and the other
client machine.
3. ypwhich on my slave server always gives the slave machine. Shouldn't
it be directed to the master?
4. I assume that Solstice can be used to create new accounts under NIS-
one must then make the databases and push them- right?
Thanks and I will summerize.
-craig
**************************************************************
Well the solution to Ques #1 was to upgrade the OS on the slave server
to 2.5.1, the same as that on the master server. Once I did this, that
problem went away. sigh....
What I ended up doing for #2 was to specify the new users actual home
directory path ( i.e. /x/y/home/username ) when using Solstice/User
Manager and enable the auto-home option. This then creates a
/etc/YP/auto_home entry with the actual path listed while the
/etc/YP/passwd has /home/username as their path.
Ques #3 turned out to be correct- no action was needed.
Ques #4 led me to place a service order with SUN since Solstice was
not generating the correct files when I was attempting to add a
new user. By accident I found out that the root partition on the
master NIS server was all owned by SMTP. After finding an article
on SunSolve that said this user was unnecessary, I commented out
the user in /etc/passwd and /etc/YP/passwd, rebooted, and root
was then owned by root. If anyone can comment on how the entire
partition might have got SMTP ownership, I would really like to know.
Once I got the correct ownership on /, Solstice works perfectly-
updating the NIS maps and puching them out to the slave.
Thanks to the following for their efforts!!
**************************************************************
From: cathy@mercury.stm.com (Cathy Hargrave)
check the options that you used with ypbind. the nskit offers the -broadcast
option that is not available under sun os. a lot of our nis problems disappeared
when we discontinued using that option. this won't solve your problems, but
it may be a contributory factor.
********************************************************
From: Dave Zavatson <dhzavatson@ucdavis.edu>
Answer to Question 1:
Looks like you do not have a mail.aliases map on skip to begin with.
Try 'ypxfr -h masterserver mail.aliases' on the slave server skip.
Answer to Question 2:
Is what right? That you had to change the path names? You shouldn't have
to change path names at all. It all depends on how your file systems are
mounted. If in addition to starting NIS you also changed home mount points,
then yes, you'd have to change the home dir field in the password file.
Answer to Question 3:
No. ypwhich shows to which NIS server you current host is bound. There is
nothing wrong with a system binding to itself. If you did not want the slave
server handleing NIS calls, then it would not be a slave. N'est pas? ypwhich
does not show any kind of slave/master relationship, merely which host is
currently handleing NIS calls on the system. Do a 'ypwhich -m' to see
which system is the 'master' for all your maps.
Answer to Question 4:
Can't help there. I avoid Solstice. What little playing around I did
indicated that it would update either local, NIS, or NIS+ databases. I am
not sure whether it automatically pushes or not.
**************************************************************
From: nobroin@esoc.esa.de (Niall O Broin - Gray Wizard)
Hi Craig,
I don't have answers for all your problems, but I've a few pointers :-
> 2. I had to change all the users home directories paths from:
>
> /x/y/home/username
>
> to
>
> /home/username
This is the standard way Solaris works. It's of course posssible to make it
work otherwise but you'll have to alter your auto.XXX files.
> in order to get the home directories mounted on the slave and the other
> client machine. Without that change, when a user logged in they were
> put in root. Is this right?
> I read nothing about this in the NIS Answerbook or the O'Reilly text.
Well, it's really nothing to do with NIS except that you're probably using NIS
to distribute the automounter maps. And while I really like the O'Reilly book,
it has now become sadly out of date W.R.T. NFS nad NIS as implemented under
Solaris 2.5.
> 3. ypwitch on my slave server always gives the slave machine. Shouldn't
> it be directed to the master?
I presume you mean ypwhich :-) and no, it shouldn't be directed anywhere, as
such. It will point to which ever machine the relevant client finds first
during bootup. It was the case that lower powered machines which were slave
servers would often bind to a server other than themselves, as during bootup,
they were under such load that they would get a response from another machine
faster than from themselves, but it's dependent on a lot of things. BTW, the
behaviour you're getting is the behaviour you want - there have been previous
questions asking how to do just that :-) The reason for that is that if a
slave server binds to the master server, and the master server goes down, the
slave server may become unavailable because it can't find its NIS server. If
the slave server is serving itself, this of course doesn't happen.
>
> 4. I assume that Solstice can be used to create new accounts under NIS-
> one must then make the databases and push them- right?
How have you found Solstice ? I used it under 2.5 and it was so crappy I
abandoned it. Sun claimed that the version shipped with 2.5.1 had fixes for
the problems I reported, but once bitten, twice shy, as the saying goes.
**************************************************************
From: Arolovitch Alan <alan@macs.biu.ac.il>
Answer to Question 1:
I had similar syndroms with 8.7.* sendmail interacting with NIS
strangely. you need to check that if that's non-Sun sendmail
whether it is configured with DBM & NDBM database format support.
Otherwise it creates /etc/mail/aliases in format which cannot
be propagated by NIS.
You may also change yp makefile in /var/yp and specify '-v'
flag to yppush program there to obtain more details on problematic
stage.
Answer to Question 3:
no. ypbind searches /var/yp/binding/`domainname`/ypservers for list of
NIS servers and if the file does not exist issues a broadcast.
Naturally slave server would answer the broadcast faster than master -
it is the same computer. If you specifically want the slave to be bound
to master do 'ypinit -c' on client and fill in NIS servers list, with
master server 1st. However, once all the maps are propagated correctly
from the master there's no difference.
**************************************************************
From: Dave Zavatson <dhzavatson@ucdavis.edu>
> > Is what right? That you had to change the path names? You shouldn't have
> > to change path names at all. It all depends on how your file systems are
> > mounted. If in addition to starting NIS you also changed home mount points,
> > then yes, you'd have to change the home dir field in the password file.
>
> NO- I did nothing to the original paths of the users. If they logged into
> the server, all was well and they got put in their home directories. But
> when they attempted to log into the client, they were put in root. Once I
> changed their paths in /etc/passwd on the NIS master server and pushed the
> maps, they could log into the client and have their home directory follow.
>
> (Remember, prior to the install of NIS, these user accounts were made
> on both the server and the client and since auto-home was picked when the
> account was created on the client, their home dirctory got mounted. Once
> NIS was running, this automount did not work so I tried including auto-home
> and auto-master in the maps but that didn't help either. At some point in
> the process, I noticed that my home directory was following me even though
> it exists on a machine outside of the network I was working on. The only
> difference between my account and the regular users of the network was my
> path was /home/clg while theirs was /bony_disk1/home/username. Did I stumble
> upon something here- do home dirs have to be in /export/home for NIS to
> work??
It does sound like you had an automounter problem. When you started NIS,
each user ended up with the same passwd entry on all systems. This is no
problem if they all had the same home path in each local passwd file, which
it sounds like they did. The location of the home has absolutely no bearing
on whether NIS will work or not. NIS only distributes information.
automounter is another story. It relies on /etc/auto_home, /etc/auto_master,
and the NIS maps auto.home and auto.master if you have +auto_home and
+auto_master in those files respectively. It also relies on file systems
being exported properly. If you tell system-a to mount system-b:/home,
but /home is not in system-b:/etc/dfs/dfstab, then it won't work.
If you want to track this down, I'd try mounting the filesystems manually.
If the mountpoint was /bony_disk1/, then try mounting it on the client
as /mnt or something. I mean, on the client which automounts the home from
a remote system, do a 'mount remote_system:/bony_disk1 /mnt. That will
tell you more specific errors than automounter will. If you get permission
problems, then look at the remote's dfstab. If you can mount it, then
look at your automounter setup. run automount -v to remount any filesystems
afet you make config changes.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:05 CDT