[arch-general] PAM 1.3.1 -> 1.5.1 did pam_tally get removed?
Hi. This might be suited for the newbie corner, but I'm testing my luck with the mailing list for the first time. I can't remember if I've added the following to /etc/pam.d/system-login or not: auth required pam_tally2.so onerr=succeed file=/var/log/tallylog The reason why I'm asking is because after a system upgrade, that line has now disappeared. And I did not see anything on the archlinux bulletin board about a pam change. The tally logs still appear to update however, just not through the system-login config. Best wishes: Anton Hvornum
I can't remember if I've added the following to /etc/pam.d/system-login or not:
auth required pam_tally2.so onerr=succeed file=/var/log/tallylog
The line was changed by https://github.com/archlinux/svntogit-packages/commit/7afa3fb3a9e74c27f4c2af... to auth required pam_faillock.so onerr=succeed file=/var/log/tallylog and pam_faillock was moved to /etc/pam.d/system-auth by https://github.com/archlinux/svntogit-packages/commit/2d5af94ae55a5c98837ce9...
That would answer my issue yesterday, but raises another question. What dictates if something is worthy of being put on the bulletin board on the main website? I added 2FA way back when to /etc/pam.d/system-login and that meant that pacman placed a .pacnew file alongside the modified system-login (as expected) on upgrade. But the notification about this got lost in the sea of packages which is on me of course. But seeing as this is a modification to a system critical file can (and did) cause a complete lockout of accounts on the machine due to `auth required` being the keywords put in place. I would have expected this to be on the bulletin board about possible manual intervention required. Perhaps I just missed it under another title? Best wishes: Anton Hvornum On Mon, Feb 22, 2021 at 12:57 PM Björn Fries via arch-general <arch-general@lists.archlinux.org> wrote:
I can't remember if I've added the following to /etc/pam.d/system-login or not:
auth required pam_tally2.so onerr=succeed file=/var/log/tallylog
The line was changed by https://github.com/archlinux/svntogit-packages/commit/7afa3fb3a9e74c27f4c2af...
to
auth required pam_faillock.so onerr=succeed file=/var/log/tallylog
and pam_faillock was moved to /etc/pam.d/system-auth by https://github.com/archlinux/svntogit-packages/commit/2d5af94ae55a5c98837ce9...
On Mon, 22 Feb 2021 13:58:36 +0100 Anton Hvornum via arch-general <arch-general@lists.archlinux.org> wrote:
What dictates if something is worthy of being put on the bulletin board on the main website?
Something out of the ordinary. Merging .pacnew files is a normal, standard part of system updates.
On 2021-02-22 13:58:36, Anton Hvornum via arch-general wrote:
That would answer my issue yesterday, but raises another question.
What dictates if something is worthy of being put on the bulletin board on the main website?
I added 2FA way back when to /etc/pam.d/system-login and that meant that pacman placed a .pacnew file alongside the modified system-login (as expected) on upgrade. But the notification about this got lost in the sea of packages which is on me of course. But seeing as this is a modification to a system critical file can (and did) cause a complete lockout of accounts on the machine due to `auth required` being the keywords put in place. I would have expected this to be on the bulletin board about possible manual intervention required.
These days I don't pacman -Syu, I have a script that: - checks the news - runs -Syu - runs pacdiff It's saved me a lot of hassle, but doesn't catch everything. For me, I would use an option that allowed pacman to 'pause' on messages (like post install stuff) to give me time to read them.
Ben Oliver via arch-general <arch-general@lists.archlinux.org> wrote:
On 2021-02-22 13:58:36, Anton Hvornum via arch-general wrote:
That would answer my issue yesterday, but raises another question.
What dictates if something is worthy of being put on the bulletin board on the main website?
I added 2FA way back when to /etc/pam.d/system-login and that meant that pacman placed a .pacnew file alongside the modified system-login (as expected) on upgrade. But the notification about this got lost in the sea of packages which is on me of course. But seeing as this is a modification to a system critical file can (and did) cause a complete lockout of accounts on the machine due to `auth required` being the keywords put in place. I would have expected this to be on the bulletin board about possible manual intervention required.
These days I don't pacman -Syu, I have a script that:
- checks the news - runs -Syu - runs pacdiff
pacmatic, from community, addresses the first 2 points. And partially the third. I am not its author, or maintainer, or something. -- u34
It's saved me a lot of hassle, but doesn't catch everything.
For me, I would use an option that allowed pacman to 'pause' on messages (like post install stuff) to give me time to read them.
On 2/22/21 6:58 AM, Anton Hvornum via arch-general wrote:
I added 2FA way back when to /etc/pam.d/system-login and that meant that pacman placed a .pacnew file alongside the modified system-login (as expected) on upgrade. But the notification about this got lost in the sea of packages which is on me of course. But seeing as this is a modification to a system critical file can (and did) cause a complete lockout of accounts on the machine due to `auth required` being the keywords put in place. I would have expected this to be on the bulletin board about possible manual intervention required.
Arch does a fantastic job in doing all that it does in a rolling release, so don't take this the wrong way, but I do agree with Anton a bit here. Over the years (12 now), there have been 4-5 times that an update with pacman -Syu has left me with either a critical server package in need of an immediate day long learn and reconfigure session, or a change has left remote adminned machines unreachable. (considering the 100's of thousands of package upgrades over those 12 years, those are quite good stats) But if there is any way to do a double-check on system critical or server critical packages and drop a note if some type of breakage or immediate attention will be needed would be welcomed. I know, I know, in a perfect-world we would have all the manpower desired to look at ever aspect up potential adverse impacts and would all be informed of each upcoming change, but we live in the real-world and there will be some changes that hit some harder than others. I can't see the user solution being building different systems to pre-check if pacman -Syu is advisable. The Arch way has always been that only current systems fully updated by pacman -Syu are supported and throughout the wiki, etc.. the advice being "make sure you do a pacman -Syu before ..." We should ensure, to the greatest extent possible, that (1.) pacman -Syu remains the safe, gold-standard on how updates are done, and (2.) make a good effort to note any changes likely to cause problems on archlinux.org. It's hard to make what is already done well, better, but there is always room for improvement. -- David C. Rankin, J.D.,P.E.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On Tue, 23 Feb 2021, David C. Rankin via arch-general wrote:
On 2/22/21 6:58 AM, Anton Hvornum via arch-general wrote:
I added 2FA way back when to /etc/pam.d/system-login and that meant that pacman placed a .pacnew file alongside the modified system-login (as expected) on upgrade. But the notification about this got lost in the sea of packages which is on me of course. But seeing as this is a modification to a system critical file can (and did) cause a complete lockout of accounts on the machine due to `auth required` being the keywords put in place. I would have expected this to be on the bulletin board about possible manual intervention required.
Arch does a fantastic job in doing all that it does in a rolling release, so don't take this the wrong way, but I do agree with Anton a bit here. Over the years (12 now), there have been 4-5 times that an update with pacman -Syu has left me with either a critical server package in need of an immediate day long learn and reconfigure session, or a change has left remote adminned machines unreachable.
I have been there too, and there are some things I do (besides checking the news and running pacdiff) which will help: 1. Use some wrapper around pacman, which gives me an "emergency" shell, in case the system becomes unreachable (think: new ssh connections being rejected due to some change in ssh). 2. Revert the update if I really need the system *now* and cannot invest the time *now* to repair whatever was broken. 3. Do the update when noone desperately needs the machine (Once, I did a reboot of the lab server in the morning and it decided it will fsck the data raid which took over an hour ... fun, fun, fun) 4. Build my own packages with as many depends=(libfoo.so) dependencies instead of depends=(foo) as possible, so already `pacman -Syu` will complain about broken linking. Here, I want to say a big THANKS to arch package maintainers for including more and more provides=(libfoo.so) into official PKGBUILDs! [ ... snip ... ] regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmA13fwACgkQCu7JB1Xa e1pEyg//XFPNPM9CC6EemJJe8WJUqC7Rb3n6FXX+TmjqA4dU9zPzi+ku6dGkfDVY mpl6FDwKx0MHxj7mHKfvvR9K5lJ0sebV80dKuoNQcszJjDkDqed3OUxtG/jLvRpR CvXy1IF0iRs63GaIph5GQBd8TInA7vY+DZPEtvIKV/vACpTd3VmUIyrfBAODDtMP 9U90nGKiNOqwUeozPqXAw9+P3TIQHCJwA9cAaKn2eXbpqZfrCiaOxas5wjMXG0uK utg70AUsl9K4jCv0RJOnFKbFPbu41FITH69xRjAw28V5s3cdDtFWVh3R1wLWxVVs hlC1vWv1NAP/qJ4dezTsTqfuuTErhQQ4oLB65WAR3DJ8eNpygJgZm6U7DqvlEzhH 7ixj8oxub4DfsRJ+19Kh3BDEkNFlAuckHlPLYcviO6SGAauYb8IA3vuYZDrFs/u/ NOidL7R6AytjCWBbL8JhxRENYaVxViPCQnocZyRFxMLCoR84jFGdpQRUSG+gMeD3 bsuP8W5NUn1GpQvP7ae6FbUeefPTPdwkQBklNQrFcxq0EXMPiXQAxsKnODqsbE5R QpefIMdfiyCwWLetSHXukDceA0vgpBMIROn06vOg9AjwdxIX5XqAYqlGBQBEkz7n QJH1TZ0bBhMX9Ot0czfT++COdiLSzkkrR1unX7WoWfkFwi0nMhA= =G+cB -----END PGP SIGNATURE-----
participants (7)
-
Anton Hvornum
-
Ben Oliver
-
Björn Fries
-
David C. Rankin
-
Doug Newgard
-
Erich Eckner
-
u34＠net9.ga