Thanks Brandon and Takashi
Unfortunately I cannot test this until I get home (on vacation which I am
breaking doing this and sadly the next email I send to the group)Š I can
try this on my return to the office (but at that point the upgrade wave
that we are currently doing will reach the NIS
Bill,
You can check your NIS password map by ypcat passwd command
on your NIS client. Second field should be hashed password of
13 characters.
I am not sure whether the issue below is related to your case or not.
In the NIS/NFS environment in SL, we noticed NSF mount problems accrued
starting
Ypwich -m matches 1:1 as well. As I said I am hoping to get rid of this
problem when all machines in our fleet jump to SL 6.5 in the next couple
weeks.
Bill
On 8/1/14, 17:19 MDT, Steve Rikli s...@genyosha.net wrote:
You mentioned you're using shadow passwd in your reply to Gilbert in
this
On Sun, Aug 3, 2014 at 2:26 PM, Capehart, William J
william.capeh...@sdsmt.edu wrote:
Ypwich -m matches 1:1 as well. As I said I am hoping to get rid of this
problem when all machines in our fleet jump to SL 6.5 in the next couple
weeks.
Bill
Bill,
Your problem might be due to the fact
What login method is failing? Login from console? ssh? other?
does /var/log/secure give you anything as far as error messages? It
should. Is kerberos involved here or do you have hashed
passwords in the NIS map?
Steve Timm
On Fri, 1 Aug 2014, Capehart, William J wrote:
Steve:
Normally
If you believe you have the configs straight at this point, as initial
troubleshooting steps e.g. I would compare the outputs of these commands
on the working and non-working NIS client systems:
grep ^passwd: /etc/nsswitch.conf
ypwhich
ypmatch NISuser passwd
Your logs indicate password
Do you have shadow passwords? Is there a difference in the way Mandriva
handled those than how SL does? Are you generating a shadow.byname map,
a passwd.adjunct.byname map, or both?
The NIS code has some odd tweaks in it to implement shadow password
support in ways that are
