> While I appreciate the replies, I think I'm not explaining properly... > > When my PXE clients boot, they don't get to the login prompt. > This has happened before, on a previous PXE image, and it was a PAM > problem... 1. what, exactly was the problem last time? 2. how are you sure that it is the same problem? Not seeing a login prompt could be caused by a large number of different things. > I don't need passwordless login or userless login... All I really need > is for the client to boot to the point where the "controller" machine > can rlogin into it. So you need it to start the rlogin daemon? This seems to be a separate problem from it not given you a local login prompt. > Each client should boot, map an smb share, and set up rlogin. From the > smb share, it runs a series of perl scripts. The "controller" is the > machine that will rlogin to the client and initiate these scripts. > There's no need for anyone to be on the console, except for possible > troubleshooting... Why do you need the controller to run the perl scripts? Why can't you just add the appropriate lines to the start up scripts so that they are run automatically by the client on boot? Failing that, running sshd on the client machines and setting up public keys in the client and controller root accounts will give you a scriptable, password-less login from the controller to the clients. I'd hazard a guess that the user base of OpenSSH is several orders of magnitude higher than that of rlogin so the code should hopefully be more robust, better maintained and more reliable. > I don't need/want any GUI on the system at all, but I need parts of > xorg to get the scanpci executable needed by some of our perl > scripts... PAM is used by a number of X applications, including XDM et al. but is independant of it. Whether or not you need xorg is irrelevant for setting up PAM. > The problem is that the machine doesn't get that far in the boot > process. It gets to "Running /sbin/init" and stops... This sounds like a problem with the boot scripts not with PAM. > I can change it to runlevel 1, and can molest it somewhat, but there's > not a lot to do since it's 95% read-only... > > I get "Authentication token manipulation error" when trying to change > the root password with passwd. Are you sure that /etc is writeable? If not that would explain this error. strace-ing the passwd process may also help identify the problem. > I had Googled the problem a few weeks ago, and the solution I foundwas > to comment out a line from the /etc/pam.d/ folder. But, like a dummy, > I didn't bookmark the link, and haven't been able to find it since. > Now, it's been over a week, and the PXE machines still aren't > booting... > > So I think that, rather than wasting more time trying to fight with > PAM, I just want it gone. We need *NO* security whatsoever. It's a > VERY contained network we're running this on... OK, a few points: 1. Make sure that the actual problem is to do with PAM otherwise you will end up wasting more time. In general PAM functions only get called when a user tries to authenicate themselves, thus it is, IMHO, unlikely that this is the cause of yoru system not booting. 2. Disabling PAM is relatively easy, someone has already posted step by step instructions on how to do this. 3. Completely removing PAM from the system is not easy as a number of applications have been compiled to need it. If you are really serious about doing so then every application that has a dependancy on libpam.so ( see ldd(1) ) will have to be recompiled. It is almost certainly better practise to re-compile every package that contains one of these applications. Doing so is a non trivial amount of work and once you've finished, it is questionable on whether what you are running is still Fedora, which may or may not void the certification of your software. HTH Cheers, - Martin _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
