You are not logged in.
┌─[arch-ck ~] └─╼ pacman -Qo /etc/pam.d/login /etc/pam.d/login is owned by util-linux 2.21.2-3
https://projects.archlinux.org/svntogit … util-linux
pam-login ==> /etc/pam.d/login(.pacnew)
Thanks Psykorgasm - no idea why my brain skipped right to assuming it was pambase without checking!
Offline
I replaced the file and it seems to be going ok.
Shouldn't this be in the news or something since you have to replace the file manually??
Offline
Shouldn't this be in the news or something since you have to replace the file manually??
You are always expected to manage your .pac* files; there is nothing newsworthy about that...
Offline
OK i am new to arch and its the first time i encountered something like this
I thought it was similar to the filesystem thing that was in the news.
Offline
You are always expected to manage your .pac* files; there is nothing newsworthy about that...
The problem in this case is that this is not a typical merge. The new file is totally different and since it changes rarely I didn’t know if I had to keep something from the old file. (I have no idea what PAM is and if something can change the file, like for example the “group” file can be changed.)
Last edited by stqn (2012-07-07 12:40:29)
Offline
(I have no idea what PAM is and if something can change the file, like for example the “group” file can be changed.)
Not to single you out here, but you just made clear what I think has been the trouble with this update for just about everyone in this thread. Those of us who handled the update with no problem know PAM at least a little bit, allowing us to make sense of the difference between the old and new files. From where such more experienced users stand, it was hard to understand where all of your confusion came from.
PAM is an important piece of infrastructure that's worth knowing at least a little about - after all, if you break it, you won't be able to log in, or you won't be able to keep bad guys out. There are two useful manpages here: pam(8), which explains the concepts, so you know what PAM is, and pam.conf(5), which explains the syntax of the files in /etc/pam.d. (There are also individual manpages for the various pam_* modules that are listed in those pam.d files.) Please be good Arch users and read these pages - the more of us here that are knowledgeable, the better off this community will be.
Offline
I have replaced the file and rebooted without issue. The script is just becoming more modular, all the stuff removed is in the included scripts.
Thanks for the heads-up!
I was using /etc/pam.d/login to load ecryptfs modules:
auth required pam_ecryptfs.so unwrap
password required pam_ecryptfs.so
I followed the modules in new /etc/pam.d/login and added the above modules in /etc/pam.d/system-auth:
auth required pam_env.so
auth required pam_unix.so try_first_pass nullok
auth required pam_ecryptfs.so unwrap
auth optional pam_permit.so
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so
password required pam_ecryptfs.so
password required pam_unix.so try_first_pass nullok sha512 shadow
password optional pam_permit.so
session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_permit.so
And everything is working fine...!
Offline
Archer777, thanks for the contribution! Do you mind if I copy that to the wiki?
Allow me to ask why you didn't add this line:
session optional pam_ecryptfs.so unwrap
And also, why do you have "required" and not "optional"?
Last edited by turion (2012-07-09 16:46:37)
Offline
I have
auth required pam_ecryptfs.so unwrap
password required pam_ecryptfs.so
session required pam_ecryptfs.so unwrap
I also had to add
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
@turion - I read pam.d(5) but I'm still not sure why it should be "optional".
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Archer777, thanks for the contribution! Do you mind if I copy that to the wiki?
Glad I could help. Yes you can add it to wiki but remember that I'm using ecryptfs to encrypt the entire $Home, whereas wiki only covers the encryption of a private directory.
Allow me to ask why you didn't add this line:
session optional pam_ecryptfs.so unwrap
And also, why do you have "required" and not "optional"?
I followed eCryptfs and $HOME guide, I hope it will answer your questions.
Offline
I must admit, I'm little bit confused with this one too. Wouldn't be less error prone to indicate whether .pacnew should be merged or replaced? With /etc/pam.d/login I'm still not sure if I need other lines from my old file. I know we should manage this ourselves but not everyone here are uber-geeks, little section on forum with latests .pacnews could be nice for instance "/etc/gshadow.pacnew - we just added lock group, in case you don't have it allready add this", people create those threads anyway so official ones could save some confusion and lower the noise (I think)
Offline
Unless I'm missing something, wouldn't you only have gotten a pacnew for /etc/pam.d/login if you had manually changed something previously in that file?
Offline
Unless I'm missing something, wouldn't you only have gotten a pacnew for /etc/pam.d/login if you had manually changed something previously in that file?
Correct. I was talking about earlier upgrade (/etc/gshadow and /etc/group) which also bring some confusion on the board.
Offline
You only get the .pacnew if you've altered the original, right?
So whatever changes you made to the original should indicate what you might need to change in the new version...
That is, you can't need the old *default* lines. If you did, so would people who'd never edited the old defaults at all. But they obviously don't because the new version will have replaced their old version silently.
So just focus on any changes you made to the defaults and see if you need to integrate any of those into the new version. Forget about the differences between the old defaults and the new defaults.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
You only get the .pacnew if you've altered the original, right?
I don’t remember ever touching that “login” file but still got the .pacnew…
Offline
cfr wrote:You only get the .pacnew if you've altered the original, right?
I don’t remember ever touching that “login” file but still got the .pacnew…
OK, I stopped understanding this problem.
If /etc/pam.d/login used to belong to shadow and now belongs to util-linux, then why do we get a .pacnew at all? I would imagine that shadow is updated 1st (otherwise there would be a file conflict) which leads to removal of login and, since it was in backup() and altered, creation of a .pacsave. The new login (from util-linux) would install as-is, and the user would have to put settings from login.pacsave back in... Where am I wrong?
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
If /etc/pam.d/login used to belong to shadow and now belongs to util-linux, then why do we get a .pacnew at all?
I'm not sure but this comes up occasionally. I typically resolve it by deleting the old file and re-installing the owning package, otherwise you end up with useless pacnew files every upgrade.
Offline