Re: NIS Problems in Migrating to SL
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 server and it too will be running SL). Thanks, Bill On 8/4/14, 02:46 EDT, Takashi ichihara ichih...@rarfaxp.riken.go.jp wrote: 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 from SL6.3 and still exist in SL6.5. The nfs mount in SL6.3, 6.4, 6.5 (also CentOS 6.3-6.5) would not map the user ids correctly. Specific uids become 99(nobody) on the NFS(NFS4) client of SL 6.3-6.5. The issue was idmapd had cached the incorrect ids from the faulty configuration, and no fixing of the configuration would sort it. The command to fix this is nfsidmap -c (clear cache). Regards, Takashi http://serverfault.com/questions/364613/centos-6-ldap-nfs-file-ownership-i s-stuck-on-nobody (14/08/04 8:01), Brandon Vincent wrote: 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 that Mandriva 2009 can use tcb as an alternative to /etc/shadow. http://www.openwall.com/tcb/ Hashes generated from tcb are not compatible with the traditional pam_unix.so found in almost every other GNU/Linux distribution. Can you verify on the NIS server that your hashes are stored in the traditional /etc/shadow format? Brandon Vincent
Re: NIS Problems in Migrating to SL
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 from SL6.3 and still exist in SL6.5. The nfs mount in SL6.3, 6.4, 6.5 (also CentOS 6.3-6.5) would not map the user ids correctly. Specific uids become 99(nobody) on the NFS(NFS4) client of SL 6.3-6.5. The issue was idmapd had cached the incorrect ids from the faulty configuration, and no fixing of the configuration would sort it. The command to fix this is nfsidmap -c (clear cache). Regards, Takashi http://serverfault.com/questions/364613/centos-6-ldap-nfs-file-ownership-is-stuck-on-nobody (14/08/04 8:01), Brandon Vincent wrote: 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 that Mandriva 2009 can use tcb as an alternative to /etc/shadow. http://www.openwall.com/tcb/ Hashes generated from tcb are not compatible with the traditional pam_unix.so found in almost every other GNU/Linux distribution. Can you verify on the NIS server that your hashes are stored in the traditional /etc/shadow format? Brandon Vincent
Re: NIS Problems in Migrating to SL
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 thread -- what does that look like in each nsswitch.conf ? I'd expect it to be files nis as well, but it's a good thing to check. Gilbert's other questions about shadow.byname et al NIS maps are also good to check. You can see all the NIS maps provided by the NIS server with 'ypwhich -m'. sr. On Fri, Aug 01, 2014 at 11:07:35PM +, Capehart, William J wrote: The nsswitch, ypwich and ypmatch lines match 1:1, There are only file and nis for the passwd entry on this list. Compat or nis+ isn?t there. Bill On 8/1/14, 16:02 MDT, Steve Rikli s...@genyosha.net wrote: 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 failure, and assuming you're typing the same password correctly in both attempts, that implies the passwd map entry for NISuser isn't correctly in-place on your failing NIS client. We don't see error retrieving information about user NISuser or similar log message, which is an indicator the NIS passwd map is available on your NIS client, but not the password itself. But we don't yet know why. Perhaps a + or compat situation in /etc/passwd and nsswitch.conf? /speculation Cheers, sr. On Fri, Aug 01, 2014 at 09:46:56PM +, Capehart, William J wrote: I am using a login via ssh Here is the secure log material for my test USR Aug 1 21:26:20 client unix_chkpwd[6558]: password check failed for user (NISuser) Aug 1 21:26:20 client sshd[6556]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=remote.host.name user=jtorres Aug 1 21:26:22 client sshd[6556]: Failed password for NISuser from remote.host.up.address port 65500 ssh2 From a fellow Mandriva box the same request meets as follows. Aug 1 21:32:15 client sshd[7595]: Accepted password for NISuser from remote.host.up.address port 54278 ssh2 Passwords should be hashed. I am not using keberos (or at least I don???t think it???s in the mix). once again, despite what you see above the id command yield the correct uid and gid information for the test user Bill On 8/1/14, 15:20 MDT, Steven Timm t...@fnal.gov wrote: 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 I do all the pieces normally but I followed your guidance: authconfig --enablenis ???nisserver=(server.name.goes.here) ???nisdomain=(mydomain) --update As root, id on one of my test accounts worked. As root, su on the same test account worked. ??nis?? has indeed been through the /etc/nsswitch.conf file all along. Bill On 8/1/14, 14:51 MDT, Steven Timm t...@fnal.gov wrote: did you go into the system setup utility and enable NIS authentication? (or use authconfig from the command line). That's the best way to ensure that PAM is configured correctly to use NIS and that's likely the problem. (does id on a yp user name work?) (does su to a yp user name work?) does nis appear in /etc/nsswitch.conf? (setup will do that). Steve Timm \On Fri, 1 Aug 2014, Capehart, William J wrote: We are in the process of migrating to SL 6.5 from Mandriva and things have been manageable until (of course) today. The NIS server is still under Mandriva (yp-serve is 2.22, ypbind is 1.29.91) On the client to be in SL 6.5 the ypbind is 1.20.4. NIS works on the fellow Mandriva machine clients but when used on the SL machine The username and groups get carried over and match the uids ypcat gives the correct responses for the arguments passwd and groups BUT I get permission denied errors when logging in. (That is sort of a deal breaker). Beyond this point is there any troubleshooting advise here? Thanks Much, Bill -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing -- Steven C. Timm, Ph.D
Re: NIS Problems in Migrating to SL
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 that Mandriva 2009 can use tcb as an alternative to /etc/shadow. http://www.openwall.com/tcb/ Hashes generated from tcb are not compatible with the traditional pam_unix.so found in almost every other GNU/Linux distribution. Can you verify on the NIS server that your hashes are stored in the traditional /etc/shadow format? Brandon Vincent
Re: NIS Problems in Migrating to SL
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 I do all the pieces normally but I followed your guidance: authconfig --enablenis ‹nisserver=(server.name.goes.here) ‹nisdomain=(mydomain) --update As root, id on one of my test accounts worked. As root, su on the same test account worked. ³nis² has indeed been through the /etc/nsswitch.conf file all along. Bill On 8/1/14, 14:51 MDT, Steven Timm t...@fnal.gov wrote: did you go into the system setup utility and enable NIS authentication? (or use authconfig from the command line). That's the best way to ensure that PAM is configured correctly to use NIS and that's likely the problem. (does id on a yp user name work?) (does su to a yp user name work?) does nis appear in /etc/nsswitch.conf? (setup will do that). Steve Timm \On Fri, 1 Aug 2014, Capehart, William J wrote: We are in the process of migrating to SL 6.5 from Mandriva and things have been manageable until (of course) today. The NIS server is still under Mandriva (yp-serve is 2.22, ypbind is 1.29.91) On the client to be in SL 6.5 the ypbind is 1.20.4. NIS works on the fellow Mandriva machine clients but when used on the SL machine The username and groups get carried over and match the uids ypcat gives the correct responses for the arguments passwd and groups BUT I get permission denied errors when logging in. (That is sort of a deal breaker). Beyond this point is there any troubleshooting advise here? Thanks Much, Bill -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing
Re: NIS Problems in Migrating to SL
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 failure, and assuming you're typing the same password correctly in both attempts, that implies the passwd map entry for NISuser isn't correctly in-place on your failing NIS client. We don't see error retrieving information about user NISuser or similar log message, which is an indicator the NIS passwd map is available on your NIS client, but not the password itself. But we don't yet know why. Perhaps a + or compat situation in /etc/passwd and nsswitch.conf? /speculation Cheers, sr. On Fri, Aug 01, 2014 at 09:46:56PM +, Capehart, William J wrote: I am using a login via ssh Here is the secure log material for my test USR Aug 1 21:26:20 client unix_chkpwd[6558]: password check failed for user (NISuser) Aug 1 21:26:20 client sshd[6556]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=remote.host.name user=jtorres Aug 1 21:26:22 client sshd[6556]: Failed password for NISuser from remote.host.up.address port 65500 ssh2 From a fellow Mandriva box the same request meets as follows. Aug 1 21:32:15 client sshd[7595]: Accepted password for NISuser from remote.host.up.address port 54278 ssh2 Passwords should be hashed. I am not using keberos (or at least I don???t think it???s in the mix). once again, despite what you see above the id command yield the correct uid and gid information for the test user Bill On 8/1/14, 15:20 MDT, Steven Timm t...@fnal.gov wrote: 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 I do all the pieces normally but I followed your guidance: authconfig --enablenis ???nisserver=(server.name.goes.here) ???nisdomain=(mydomain) --update As root, id on one of my test accounts worked. As root, su on the same test account worked. ??nis?? has indeed been through the /etc/nsswitch.conf file all along. Bill On 8/1/14, 14:51 MDT, Steven Timm t...@fnal.gov wrote: did you go into the system setup utility and enable NIS authentication? (or use authconfig from the command line). That's the best way to ensure that PAM is configured correctly to use NIS and that's likely the problem. (does id on a yp user name work?) (does su to a yp user name work?) does nis appear in /etc/nsswitch.conf? (setup will do that). Steve Timm \On Fri, 1 Aug 2014, Capehart, William J wrote: We are in the process of migrating to SL 6.5 from Mandriva and things have been manageable until (of course) today. The NIS server is still under Mandriva (yp-serve is 2.22, ypbind is 1.29.91) On the client to be in SL 6.5 the ypbind is 1.20.4. NIS works on the fellow Mandriva machine clients but when used on the SL machine The username and groups get carried over and match the uids ypcat gives the correct responses for the arguments passwd and groups BUT I get permission denied errors when logging in. (That is sort of a deal breaker). Beyond this point is there any troubleshooting advise here? Thanks Much, Bill -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing
Re: NIS Problems in Migrating to SL
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 backward-compatible with Solaris systems. I'm wondering if you're running into a problem with that? Gilbert On 01/08/2014 4:46 PM, Capehart, William J wrote: I am using a login via ssh Here is the secure log material for my test USR Aug 1 21:26:20 client unix_chkpwd[6558]: password check failed for user (NISuser) Aug 1 21:26:20 client sshd[6556]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=remote.host.name user=jtorres Aug 1 21:26:22 client sshd[6556]: Failed password for NISuser from remote.host.up.address port 65500 ssh2 From a fellow Mandriva box the same request meets as follows. Aug 1 21:32:15 client sshd[7595]: Accepted password for NISuser from remote.host.up.address port 54278 ssh2 Passwords should be hashed. I am not using keberos (or at least I don’t think it’s in the mix). once again, despite what you see above the id command yield the correct uid and gid information for the test user Bill On 8/1/14, 15:20 MDT, Steven Timm t...@fnal.gov wrote: 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 I do all the pieces normally but I followed your guidance: authconfig --enablenis ‹nisserver=(server.name.goes.here) ‹nisdomain=(mydomain) --update As root, id on one of my test accounts worked. As root, su on the same test account worked. ³nis² has indeed been through the /etc/nsswitch.conf file all along. Bill On 8/1/14, 14:51 MDT, Steven Timm t...@fnal.gov wrote: did you go into the system setup utility and enable NIS authentication? (or use authconfig from the command line). That's the best way to ensure that PAM is configured correctly to use NIS and that's likely the problem. (does id on a yp user name work?) (does su to a yp user name work?) does nis appear in /etc/nsswitch.conf? (setup will do that). Steve Timm \On Fri, 1 Aug 2014, Capehart, William J wrote: We are in the process of migrating to SL 6.5 from Mandriva and things have been manageable until (of course) today. The NIS server is still under Mandriva (yp-serve is 2.22, ypbind is 1.29.91) On the client to be in SL 6.5 the ypbind is 1.20.4. NIS works on the fellow Mandriva machine clients but when used on the SL machine The username and groups get carried over and match the uids ypcat gives the correct responses for the arguments passwd and groups BUT I get permission denied errors when logging in. (That is sort of a deal breaker). Beyond this point is there any troubleshooting advise here? Thanks Much, Bill -- Gilbert E. Detillieux E-mail: gede...@cs.umanitoba.ca Dept. of Computer Science Web:http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax:(204)474-7609
