Date: Wed, 30 Apr 2003 10:32:32 +0000 From: =?iso-8859-1?q?=C2ngelo=20Rodrigues?= <amr@fccn.pt> To: "Neeraj Arora" <Neeraj.Arora@ems.rmit.edu.au>, <dnelson@allantgroup.com> Cc: freebsd-questions@freebsd.org Subject: Re: Sincronize /etc/passwd and /etc/yp/passwd.master Message-ID: <200304301032.32925.amr@fccn.pt> In-Reply-To: <seb01357.081@ems.rmit.edu.au> References: <seb01357.081@ems.rmit.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 30 April 2003 08:17, Neeraj Arora wrote: > You can force your nis server machine to act as a nis client to itself; > look in the handbook for the section that says something similar to 'ni= s > servers which are nis clients too'. The server is a very complex machine so, I have to keep all local users i= n the=20 file /etc/master.passwd and I can't implement a solution of this kind :(=20 > > You will have to maintain a different master.passwd, passwd and group f= ile > for yp. Then update the Makefile in /var/yp to accomodate the path for > yp-related master.passwd, group and passwd files. > > Use pw(8) with the -V option (to specify location to the yp-related fil= es) > to update, delete and modify user and groups. This will update only the > files in the seperate directory (specified after the -V option) and not > touch your local system database. On the local database keep only root, > system and one user who is member of the group wheel. The rest will be > sourced from/by yp (the server is a client to itself). > > The above applies only to the nis server. > > The clients are configured as normal. Thus, all accept root and the loc= al > user who is member of the group wheel, will need to use passwd to updat= e > their passwd, on all machines seperately; while users existing only on = the > nis database will need to use yppasswd to update their passwd; no matte= r > which machine they are logged on from. > > Hope this helps. > > Regards, > Neeraj > > >>> =C2ngelo Rodrigues <amr@fccn.pt> 04/30/03 00:44 AM >>> > > Hi again, > > My problem is simple. I'm trying to install a central login/password sy= stem > but I want to find a way to sincronize /etc/master.passwd and > /var/yp/master.passwd without having to force all local users to run tw= o > commands, passwd and yppasswd. > It has been suggested me to make a simbolic link from=20 > /var/yp/master.passwd to /etc/master.passwd. This is a possible solutio= n > but, this will force the server's root user to be the client's root use= r > so, I won't be able to access to any client when the network is down. > I think any client should have at least one local user to avoid this > critical situation. > Do you have any ideia about this? > > Regards, > > On Tuesday 29 April 2003 11:37, Neeraj Arora wrote: > > Hmm...needed to search the trash for your original post before replyi= ng > > is it...??? > > > > And I did it....I think amidst the replies I got the impression that = you > > werent able to direct the home directory to the correct one when the > > machine was not the nis server machine. > > > > Well cleared up now... > > > > Sorry about that...:^) > > > > So is your problem solved??? Or would you like to state it again in a > > clean way (your problem (undeleted) minus all the replies that have b= een > > made by now...:^) > > > > Regards, > > Neeraj > > > > >>> =C2ngelo Rodrigues <amr@fccn.pt> 04/29/03 20:59 PM >>> > > > > Hi, > > > > I think you have made a series confusion!!! I don't want to use any f= ile > > server, I just want to use a centralized system of login/password. > > Please, read all messages to understand all point. > > > > Regards, > > > > On Tuesday 29 April 2003 10:31, Neeraj Arora wrote: > > > Please refer to the email below (that I am replying to) before read= ing > > > what I write... > > > > > > /var/yp/master.passwd is not to be a softlink or symbolic link to > > > /etc/master.passwd According the documentation (handbook I think), > > > /var/yp/master.passwd is a copy of /etc/master.passwd without the r= oot, > > > system and one user who is also the member of group wheel. > > > > > > One can use amd (automount daemon) to have all users have their hom= e > > > directories in /home, while the directories inside /home are themse= lves > > > mounted when needed according to the amd map supplied by nis. On th= e > > > fileserver or the nfs server system, one could have different > > > directories for different machines depending on any one or a > > > combination of the os/hostname/ipaddress/network/etc. of the mounti= ng > > > machine. > > > > > > So if the fileserver had /allhomedirs and in that had ./linux, and > > > ./freebsd and in each of them ./tom ./dick and ./harry; a linux cli= ent > > > would end up providing /allhomedirs/linux/<user> at /home/<user> wh= ile > > > a freebsd client would do the same by providing > > > /allhomedirs/freebsd/<user> at /home/<user>. > > > > > > This will allow the entries in the /var/yp/master.passwd and > > > /var/yp/passwd to remain untouched when produced as nis maps for > > > different clients/hosts. Same can be done by mounting the appropria= te > > > shell binary from a fileserver using amd maps while the path for th= e > > > shell can still remain only /path/shell or /usr/local/bin/bash; for > > > linux clients the > > > /usr/local/whatever is mounted from /allusrlocaldirs/linux/whatever= and > > > for freebsd it is mounted from /allusrlocaldirs/freebsd/whatever. > > > > > > One might not need to overwrite any field produced by nis on a clie= nt > > > machine. > > > > > > Personally I feel, the less the configuration differences in differ= ent > > > client machines, the better. > > > > > > Hope I havent got off the point completely...:-\ > > > > > > Regards, > > > Neeraj > > > > > > >>> =C2ngelo Rodrigues <amr@fccn.pt> 04/29/03 20:08 PM >>> > > > > > > On Monday 28 April 2003 17:39, Dan Nelson wrote: > > > > In the last episode (Apr 28), ^Angelo Rodrigues said: > > > > > On Monday 28 April 2003 16:22, Matthew Seaman wrote: > > > > > > On Mon, Apr 28, 2003 at 05:06:36PM +0000, ^Angelo Rodrigues w= rote: > > > > > > > On Monday 28 April 2003 15:48, Dan Nelson wrote: > > > > > > > > You want the same password; why wouldn't you want the sam= e > > > > > > > > homedir and shell also? All our NIS users have their hom= edir > > > > > > > > set to /net/homedirmachine/home/username. > > > > > > > > > > > > > > But my server users are distributed betwen /home and /homea= pp > > > > > > > and this method will force the same thing in the clients. > > > > > > > > > > > > You can selectively override part of a NIS password database > > > > > > entry by using NIS magic tokens in the local passwd file --- = see > > > > > > passwd(5). For instance, user 'fred' might have home director= y > > > > > > /home/fred in the NIS database, but you can override that in = a > > > > > > client machine to /users/fred by putting: > > > > > > > > > > > > +fred::::::::/users/fred: > > > > > > > > > > > > into /etc/master.passwd on the client. All of the other fiel= ds > > > > > > are inherited from the NIS database. > > > > > > > > > > This could be a solution :) > > > > > > > > Standardizing the name of the homedir would make your job a lot > > > > easier. Can you make symlinks in /home so that every user whose > > > > homedir is in /homeapp can use /home/user also? Then the user's = home > > > > is > > > > "/home/user" no matter what machine he logs into. > > > > > > But there's still a little problem... As the /var/yp/master.passwd = is a > > > softlink to /etc/master.passwd, the server's root user will be the = same > > > in the client so, the client won't have any local user. This can ca= use > > > some series problems when the network is down. The client machine > > > should have at least some local users to avoid this kind of problem= =2E > > > > > > Regards, --=20 =C2ngelo Rodrigues - amr@fccn.pt=20 FCCN - Funda=E7=E3o para a Computa=E7=E3o Cient=EDfica Nacional Av. Brasil, 101 1700-066 Lisboa - Portugal Tel: +351 218440100 Fax: +351 218472167 -----------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304301032.32925.amr>