Changing a password

[Novosielski, Ryan]

This is only a Werewulf question insofar as this works on non-Warewulf chroots, so I have to assume something is different or left out and there may be an alternate means.

If I chroot to the Werewulf chroot and run passwd to try to change root’s password, I get:

[root@master /]# passwd
Changing password for user root.
passwd: Authentication token manipulation error

I looked at an strace and it initially seems to care that /dev isn’t present. So I did a bind mount of /dev into the right place. I still get the same thing, though. The end of the strace is:

stat("/dev/mem", {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
stat("/dev/vga_arbiter", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 63), ...}) = 0
getdents(4, /* 0 entries */, 32768) = 0
close(4) = 0
sendto(3, "X\0\0\0T\4\5\0\2\0\0\0\0\0\0\0op=change passwo"..., 88, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 88
poll([{fd=3, events=POLLIN}], 1, 500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "$\0\0\0\2\0\0\0\2\0\0\0Z;\0\0\0\0\0\0X\0\0\0T\4\5\0\2\0\0\0"..., 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
recvfrom(3, "$\0\0\0\2\0\0\0\2\0\0\0Z;\0\0\0\0\0\0X\0\0\0T\4\5\0\2\0\0\0"..., 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/Linux-PAM.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "passwd: Authentication token man"..., 48passwd: Authentication token manipulation error
) = 48
munmap(0x7f1e98274000, 2101296) = 0
exit_group(1) = ?
+++ exited with 1 +++

Any other ideas?

--
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | novo...@rutgers.edu - 973/972.0922 (2x0922)
|| \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
`'

[Meij, Henk]

stateless setup? that probably means VNFS is not mounted in chroot env

would it not be easier to just change the hash in CHROOT/etc/shadow (obtain the hash by setting password on a test account on local host) or set the password in /etc/password and refresh the database if provisioned from there.

-Henk

________________________________________
From: Novosielski, Ryan [novo...@ca.rutgers.edu]
Sent: Wednesday, January 06, 2016 1:58 PM
To: ware...@lbl.gov
Subject: [Warewulf] Changing a password

--
You received this message because you are subscribed to the Google Groups "Warewulf" group.
To unsubscribe from this group and stop receiving emails from it, send an email to warewulf+u...@lbl.gov.
To post to this group, send email to ware...@lbl.gov.
To view this discussion on the web visit https://groups.google.com/a/lbl.gov/d/msgid/warewulf/A0628155-AFBD-420C-9135-C1A1B9707CED%40ca.rutgers.edu.
For more options, visit https://groups.google.com/a/lbl.gov/d/optout.

[Tim Copeland]

when working inside chroots this is what I generally use.

mount -o bind /proc ${CHROOTDIR}/proc/
mount -o bind /dev ${CHROOTDIR}/dev/
mount -o bind /dev/pts ${CHROOTDIR}/dev/pts
mount -o bind /sys ${CHROOTDIR}/sys

hope this helps
Cheers
Tim

[Novosielski, Ryan]

Doesn’t help in this case. I tried something similar (minus devpts). I don’t think that it was ever required for just using passwd in my past experiences though.

> --
> You received this message because you are subscribed to the Google Groups "Warewulf" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to warewulf+u...@lbl.gov.
> To post to this group, send email to ware...@lbl.gov.

> To view this discussion on the web visit https://groups.google.com/a/lbl.gov/d/msgid/warewulf/1452109441.4363.4.camel%40Criterion-Digital.lan.criteriondigital.org.

> For more options, visit https://groups.google.com/a/lbl.gov/d/optout.

[Novosielski, Ryan]

I don’t think that’s it, actually — won’t work on a node either. So maybe I’ve done something else wrong. This does work on my previous cluster, with RedHat 5. This one is CentOS 7.

Yeah, that’s a pretty good workaround. I guess I was wondering if there was a Werewulf way (I remember the provisioning script I believe asked me what I wanted to the node password to be — I could be wrong), or if anyone knew why this was happening. It’s not /easier/ necessarily to do it the way you described, but sounds like it will work, in any case. An explanation for why what I’m doing doesn’t work would be good though.

[Tim Copeland]

double check perms on file to ensure is writable..?

[Jason Stover]

On Wed, Jan 6, 2016 at 1:50 PM, Novosielski, Ryan
<novo...@ca.rutgers.edu> wrote:
> I don’t think that’s it, actually — won’t work on a node either. So maybe I’ve done something else wrong. This does work on my previous cluster, with RedHat 5. This one is CentOS 7.
>

I just tested on an SL7 image I have and running passwd works fine
from a chroot.

-J

[Gregory M. Kurtzer]

Hi Ryan,

Several things come to mind to check:

1. Check the root entry in /etc/shadow, and possibly manually reset it to: "root::::::::" (8 colons)

2. Check permissions on /etc/shadow (should be 600)

3. Check the root entry in /etc/passwd and make sure it is of the format: "root:x:0:0:root:/root:/bin/bash"

4. Check the permissions on /etc/passwd (should be 644)

5. If selinux is installed, reset selinux contexts for /etc/shadow: "restorecon -v /etc/shadow" (or try disabling selinux for testing)

6. Make sure /usr/bin/passwd is indeed setuid root (4755)

Let me know if any of those help!

--
You received this message because you are subscribed to the Google Groups "Warewulf" group.
To unsubscribe from this group and stop receiving emails from it, send an email to warewulf+u...@lbl.gov.
To post to this group, send email to ware...@lbl.gov.

To view this discussion on the web visit https://groups.google.com/a/lbl.gov/d/msgid/warewulf/A0628155-AFBD-420C-9135-C1A1B9707CED%40ca.rutgers.edu.

For more options, visit https://groups.google.com/a/lbl.gov/d/optout.

--

Gregory M. Kurtzer
Technical Lead and HPC Systems Architect
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720

[Novosielski, Ryan]

On Jan 6, 2016, at 20:11, Gregory M. Kurtzer <gmku...@lbl.gov> wrote:

Hi Ryan,

Several things come to mind to check:

1. Check the root entry in /etc/shadow, and possibly manually reset it to: "root::::::::" (8 colons)

So passwd -d worked, oddly enough. 

2. Check permissions on /etc/shadow (should be 600)

My permissions both on the master and my nodes are 000. I know, weird. But it works fine somehow on the master. I've not checked other CentOS 7 machines to see if this is weird or not. 

3. Check the root entry in /etc/passwd and make sure it is of the format: "root:x:0:0:root:/root:/bin/bash"

I didn't check but will. I think it's normal though. 

4. Check the permissions on /etc/passwd (should be 644)

This one is right. 

5. If selinux is installed, reset selinux contexts for /etc/shadow: "restorecon -v /etc/shadow" (or try disabling selinux for testing)

I did chcon and changed the context on the chroot to match the master's contexts because it occurred to me that I have enforcing on on both the head/master node and login node (would restorecon work on a chroot directory? It would probably apply some /var hierarchy or something in my case, yeah?). I then disabled it briefly to see if it helped, but no dice. I also set the context on /usr/bin/passwd to be safe. 

6. Make sure /usr/bin/passwd is indeed setuid root (4755)

I noticed this was not right either. It didn't help. I am curious how it got not right. 

To view this discussion on the web visit https://groups.google.com/a/lbl.gov/d/msgid/warewulf/CAN7etTyoZaNdr4UR-xRJ6KX0YOs9fa%3DNSZ_fbDPW%2BVL6XZgdTg%40mail.gmail.com.

[Jason Stover]

"My permissions both on the master and my nodes are 000"

That's normal now days. A root process ignores those pesky file
permissions (I mean, you can just change the permission anyway).

Are there any major differences between the RPMs installed on the
master and nodes, or are they using the same image? Couldn't say
anything about selinux... I run away from that thing and hide.

-J

> https://groups.google.com/a/lbl.gov/d/msgid/warewulf/E5F43B5E-C859-4D18-A6E2-FFC5CF2A8E30%40ca.rutgers.edu.

[Gregory M. Kurtzer]

My last suggestion would be to try and create a new VNFS of the same type, and see if the problem persists there...

To view this discussion on the web visit https://groups.google.com/a/lbl.gov/d/msgid/warewulf/E5F43B5E-C859-4D18-A6E2-FFC5CF2A8E30%40ca.rutgers.edu.

For more options, visit https://groups.google.com/a/lbl.gov/d/optout.

[Novosielski, Ryan]

Definitely will try; that was my next thought. Thanks.

> On Jan 7, 2016, at 4:51 PM, Gregory M. Kurtzer <gmku...@lbl.gov> wrote:
>
> My last suggestion would be to try and create a new VNFS of the same type, and see if the problem persists there...