On 10/25/2012 8:42 AM, Richard Kweskin wrote:
Quoting John Hupp:
<snip>
Interesting that you should mention the possibility of things going
pear shaped.
And I'm not saying they have, but they not have not gone by the book.
If at a console I log in as root and then run "passwd -d root," the
output is "passwd: password expiry information changed." Not the
output I would have expected.
If I then run "cat /etc/shadow," the password field is blank and I
can log in at a console as root with no password.
However, if I run my client shutdown command: "ssh -l root <client
IP> shutdown -h now," it requires a password and only accepts the
presumably-deleted password.
So it seems that two authentication mechanisms are somehow being
maintained and can develop a split personality.
I can return to the previously-established root password by logging
in as root with a blank password at a console and running "passwd
root." This heals the split personality, but I'm back where I started.
A Debian user had the same kind of experience with "passwd -d root"
and found that the problem was that PAM was set to use GNOME Keyring
Daemon instead of Unix Authentication, but he did not say how to
check on or configure that, and I have not been able to figure it
out yet. That post is here:
http://forums.debian.net/viewtopic.php?f=5&t=52216
Anyone recognize what's going on?
I am not at all certain but unless you also installed your system in
some unusual way PAM should be fine and shouldn't be messed with.
Again, having said that, the command (as root) that invokes the above
mentioned dialog is
dpkg-reconfigure libpam-runtime
for your own sanity pick cancel on the second window so nothing gets changed!!
(Again guessing - I'm no expert!) having changed the password, the
graphical environment may need logging out of and restarting in order
to get back in sync with the new password. A safer way to test this is
simply change the password to something else simple and then see if
there is an out of sync condition, if yes, log out and log in with new
password and then check - does it still have the split personality?
Richard
Thanks for the PAM command and the reasonable troubleshooting idea.
The idea wasto test for a split personality with a simple/normal root
password. This seemed like a replication of an earlier stage of
accomplishment, where I successfully shut down the LTSP client via "ssh
-l root <client IP> shutdown -h now" after entering the simple/normal
password I initially created when I unlocked the root account. (/Where
I also entered the same "passwd root" command in the //LTSP chroot
environ//ment and then updated the LTSP image/.)
But worth double-checking, and a chance to better document my doings.
So at a terminal command line I ran "sudo passwd root" and created a
simple password. I rebooted. I opened a console with Ctrl-Alt-F1 and
logged into root OK with the same simple password. So far so good.
I booted an LTSP client. Then at a host terminal command line I ran "ssh
-l root <client IP> shutdown -h now," entered the simple password, and
permission was denied.
This little branch of the initial experiment did tell me one thing at
this point: Though users, passwords and authentication seem to be set up
solely on the LTSP host(e.g. setup for a new user account doesn't need
to be duplicated in the LTSP chroot image), there is apparently some
element in play in the LTSP chroot image when a password is changed.
So I entered the LTSP chroot environment, changed the root password to
the same simple password, and updated the image.
I rebooted the host, started up a client, and in the host terminal ran
"ssh -l root <client IP> shutdown -h now," entered the simple password,
and the client shut down. This is the same point I was at earlier, but
I did learn the item noted above, and I found that there was no split
personality when the root password is set in both the host and LTSP
client image.
--------------------
I made another run at accomplishing the same client shutdown with a
passwordless root account. This time, instead of running "sudo passwd
-d root" in a terminal, I started a console (Ctrl-Alt-F1), logged in as
root with the simple password, and ran "passwd -d root." The output, as
before, was "passwd: password expiry information changed." But could
indeed log in to the console as root without a password.
I rebooted, deleted the root password in the LTSP chroot environment,
updated the client image, and rebooted again.
In a host terminal, I ran "ssh -l root <client IP> shutdown -h now," was
prompted for a password, and simply hitting the Enter key yielded
permission denied. I also tried entering the simple password root had
before deleting it, and again, permission denied. So while the result
is not quite the same as before, it still seems to qualify as "split
personalitysyndrome."
** But here was an interesting further development: If I logged into a
console as root and then ran the ssh shutdown command, it workedwith no
prompt for a password!! **
My actual goal here is, for a small LTSP network powered by a UPS, to
shut it down with a script in the event of a power outage. It's not
clear to me that I now have something that will work, but I probably
have enough to try.
But the above split-personality behavior does beg for an explanation!
---------------------
Following up on PAM, running "dpkg-reconfigure libpam-runtime" produced
a window with these selections:
[*] Unix authentication
[*] Winbind NT/Active Directory Authentication
[*] ConsoleKit Session Management
There was no GNOME Keyring Daemon in sight. I don't know if the above
selections are currently installed or proposed for installation --
probably the former -- but I just canceled outof there. But the
explanatory text in the window noted that PAM governs how passwords are
changed, so it may be at the bottom of the split personality thing.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
