A few days ago I posted:
> We are running SunOS4.1.3 (Solaris 1.1) on our systems;
> in /etc/rc.local on our server we have included the entry
>
> if [ -f /usr/etc/rpc.yppasswdd ]; then
> /usr/etc/rpc.yppasswdd /etc/passwd -m DIR=/etc passwd
> echo -n ' yppasswdd'
> fi
>
> this starts up the daemon and allows users on clients to modify their
> password on the NIS-server. It does not, however, immediately
> propagate the new passwd as it is supposed to be, when the -m option
> is given.
My question wasn't really exact, but I got correct answers anyway:
in rc.local we were using the command line
rpc.yppasswdd /etc/passwd -m DIR=/etc passwd
Changing it to
/usr/etc/rpc.yppasswdd /etc/passwd -m DIR=/etc passwd
(full command path) solved our problem. It is a bug in rpc.yppasswdd
which becomes effective when passing command-line-arguments to `make'.
Also other solutions were recommended, plus I got one valuable advice;
here is a summary:
> This is a known bug: yppasswdd messes up the arguments to make.
> The fix is to change your rcp.yppasswdd command.
> rpc.yppasswdd /etc/passwd.yp -nosingle -m passwd
> ^^^^^^^^^
>
> Solution 2 as summarized by Michael Sullivan
>
> There is a bug in rpc.yppasswdd in that when it invokes make, it passes
> to make its entire command line instead of just the argument after the
> -m. Make then interprets rpc.yppasswdd as a target, which it doesn't
> know how to make so it gives up.
>
> The workaround is to run rpc.yppasswdd with its full pathname:
>
> /usr/etc/rpc.yppasswdd /etc/passwd.yp -m passwd
>
> The entire command line will still be passed to make, but this way, due
> to the absolute path name, make will identify /usr/etc/rpc.yppasswdd
> as an existing file, and consider it to be up to date since there it has
> no dependencies (the same happens for /etc/passwd.yp). The -m option
> seems to be ignored by make.
> One remark: It is wise not to use /etc/passwd as source of your NIS-maps,
> because that will make the password of root, bin etc. available to NIS.
> You might not want to do this for security-reasons.
Thanks to:
mario@dca.fee.unicamp.br
xikito@ifi.unicamp.br
mclay@cfdlab.ae.utexas.edu
Richard.Feuerriegel@ag.auburn.edu
daneel@Trantor.DSO.gov.SG
Jacques.Beigbeder@ens.ens.fr
cfoley@arsenic.cray.com
thole%CS.RULIMBURG.NL@rusvm1.rus.uni-stuttgart.de
Cheers
E.Canver
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:53 CDT