Remember the date! On May 18th of 2020, PAM got added to the Slackware-current core. In case that makes you worry, wonder or causes you to ponder leaving Slackware behind, don’t let this change scare you. PAM has come a long way, it is safe and in Slackware, it is not getting in your way. You won’t have to change a single thing to your computer except installing three new packages (slackpkg install-new) before you reboot. Adding PAM should finally remove the self-imposed writer’s block in Patrick’s mind and open the path to long-awaited renewals in the KDE and XFCE areas.
Ever since these packages were added to /testing, I have been using PAM on my own desktop and laptop, both running Slackware64-current with KDE Plasma5 on top, and the desktop computer also running on Nvidia’s binary drivers. Not a single issue was found here.
Read the announcement:
Mon May 18 19:17:21 UTC 2020
Greetings! After three months in /testing, the PAM merge into the main tree
is now complete. When updating, be sure to install the new pam, cracklib, and
libpwquality packages or you may find yourself locked out of your machine.
Otherwise, these changes should be completely transparent and you shouldn’t
notice any obvious operational differences. Be careful if you make any changes
in /etc/pam.d/ – leaving an extra console logged in while testing PAM config
changes is a recommended standard procedure. Thanks again to Robby Workman,
Vincent Batts, Phantom X, and ivandi for help implementing this. It’s not
done yet and there will be more fine-tuning of the config files, but now we
can move on to build some other updates. Enjoy!
I have already updated my own repositories that are touched by PAM:
- KTOWN
The ‘latest’ and ‘testing’ repositories are now identical and contain the PAM-ified packages.
It won’t matter which of the two you had configured, you’ll get the PAM-fied packages regardless. If you already were using the PAM from Slackware’s testing combined with my ktown ‘testing’ repository, then there’s nothing you have to change.
If you did not use PAM before, you will have to do a reinstall of the following ‘ktown’ packages which are the only ones that want to use PAM: kscreenlocker, plasma-workspace and sddm-qt5. And don’t forget to install the new kwallet-pam package. - MULTILIB
I have added ‘compat32’ versions of cracklib, libpwquality and pam, the three packages that got added to Slackware-current today.
And for completeness’ sake, I have also updated the “icu4c-compat” package in my regular repository, just like I did for “boost-compat” last week. Note that these two “compat” packages have no relation to the multilib “compat32” packages!
The boost-compat, icu4c-compat and poppler-compat packages in my regular repository contain older versions of the boost/icu4c/poppler libraries and some of your 3rd party packages (libreoffice!!!) may still need them until their packager does a recompile.
Enjoy! Eric
For whatever reason, I was expecting that whenever the day did arrive, OpenPAM would be chosen instead of Linux-PAM.
¯\_(?)_/¯
Thanks Eric!
The upgrade was flawless with your instructions. I had not yet begun to use the new pam packages. But since it was rolled into the tree, I blasted on full speed ahead. I must confess that I had tried this in VBox last week. I didn’t get that one quite right, and I know what to do to fix that now….. 🙂
Thanks for the heads-up and the icu4c package Eric!
Eric, you’re a marvel! When reading Pat’s changelog of yesterday I wondered what the adding of PAM would mean for a multilib system. Was about to ask here which new compat32 packages were necessary, only to find that you already had upgraded/added everything related in your multilib repo. Heartfelt thanks.
Replenishing your beer fund via PayPal seems to be called for (avoid Corona, though 😉 )
And stay safe.
Bad news for me. I hoped till the last minute that Pat will change his decision. I’m certainly not going to leave Slackware (staying on 14.2 for now). Actually I’m thinking about the creation of PAM-free Slackware fork. Or does any exist already? Unfortunately I don’t have any experience in distro-maintenance, so any help is welcome. I’m ready to do all the compilation and file hosting on my side. Let me know if anybody is eager to help. Thanks.
Good luck is all i can say.
To be honest, the switch to PAM doesn’t really make any big changes as you expected. It happened in the background and most issues have been tackled during this three months by Pat and the rest of the team + contributors. It’s been a nice seamless merge.
Thanks Willy.
I’m aware that the changes aren’t really noticeable… for the user. I’m concerned not about how PAM affects users, but on how it affects OS itself. This adds an extra layer of authentication/complexity. It goes against KISS principles imho.
And I certainly don’t underestimate all that work which was done. My taste just differs in this decision.
Thanks Eric! I’ve been using the PAMified version since PAM landing in testing. Not a single issue so far.
After upgrading the current ChangeLog.txt files, large bold print might highlight the critical necessity of re-installing plasma-workspace. As far as this naive user can tell, there is no difference between pam/no-pam. I do not have to get smart on pam administration. In keeping with Slackware tradition, everything just works!
Thank you for all the behind-the-scenes work that went into making this happen.
As for an unnecessary no-pam version, just use the sources to re-compile each of the pamified packages enumerated in ChangeLog.txt. Simply comment out the pammy bits in each of the SlackBuild scripts.
PS https://mirrors.slackware.com/slackware/slackware64-current/source/
Among the upgraded packages is kde/kde-workspace. There is no kde-workspace in KTOWN. Is it safe to `removepkg kde-workspace`?
You’re certainly late to the party, or you are someone who does not understand README-encrypted files…
This line has been part of the ktown README for ages:
# removepkg kde-workspace
Thanks for pointing that out. I gotta start reading README files and manuals one of these days….
I think that it is also necessary to replace the cracklib and libpwquality of ktown with those of slackware-current.
Yes that was an oversight. I will remove those two today.
Please also remove PyQt5 and python-enum34 from ktown. Thanks
I think that Pat mistakenly removed python-enum34 because it is still required when building PyQt5 with support for python2. And the PyQt5 package, both mine and the one in Slackware, contains python2 libraries.
Thanks Eric for clarification. I missed the changelog entry on 1st May when python-enum34 was removed from Slackware.
Sorry for the distraction.
python-enum34 is actually included in the python2-module-collection package. Pat moved all the python2 module parts into a single package as these will not be updated.
‘brotli’ is in current also, now 😉
Indeed, I realize now that the brotli package was removed from my ktown repository along with hyphen, woff2, qt5-webkit and socat three months ago, but I forgot to remove them from my regular package repository.
I will do that today.
Just an FYI that the “upgrade” to PAM has gone very smoothly for me so far. The only functional difference I’ve seen is not having to enter my password a second time in Kwallet after logging in. Now THAT is an improvement. 😉
It seems all *.asc files have wrong md5 checksum.
Nothing can be installed with slackpkg.
For every package it reports: ERROR – Package not installed! md5sum error!
Also check fails when verifying with CHECKSUMS.md5
It would help if you told me what repository you are talking about.
Also, try a “slackpkg update gpg”.
Sorry.
KTOWN. Latest (and testing).
update gpg does not help.
md5sum is actually wrong for .asc files
tail +13 CHECKSUMS.md5 | md5sum –check:
./deps/PyQt5-5.13.2-x86_64-2alien.txz.asc: FAILED
./deps/accountsservice-0.6.55-x86_64-1alien.txz.asc: FAILED
./deps/grantlee-5.2.0-x86_64-1alien.txz.asc: FAILED
./deps/kdsoap-1.9.0-x86_64-1alien.txz.asc: FAILED
./deps/mlt-6.20.0-x86_64-1alien.txz.asc: FAILED
./kde/applications-extra/calligra-3.2.0-x86_64-1alien.txz.asc: FAILED
./kde/applications-extra/kdiagram-2.7.0-x86_64-1alien.txz.asc: FAILED
./kde/applications-extra/kpmcore-4.1.0-x86_64-1alien.txz.asc: FAILED
….
On my mirror server (slackware.nl aka bear.alienbase.nl) I do not see your issue, all files check ‘OK’:
root@bear:/mirrors/alien-kde/current/latest/x86_64# tail +13 CHECKSUMS.md5 | md5sum –check |grep -v OK
root@bear:/mirrors/alien-kde/current/latest/x86_64#
root@bear:/mirrors/alien-kde/current/latest/x86# tail +13 CHECKSUMS.md5 | md5sum –check |grep -v OK
root@bear:/mirrors/alien-kde/current/latest/x86#
root@bear:/mirrors/alien-kde/current/testing/x86_64# tail +13 CHECKSUMS.md5 | md5sum –check |grep -v OK
root@bear:/mirrors/alien-kde/current/testing/x86_64#
It’s seems it’s problem with mirror.
I was using slackware.uk/people/alien-kde, bear.alienbase.nl is OK.
I’ll use this mirror from now on, in the past it was slow, slackware.uk was much faster.
Thank you.
I’ve asked the slackware.uk maintainer to check his mirror of my repository. This is fixable of course.
As far as I can tell, the slackware.uk mirror problem has been fixed. I was able earlier tonight to ‘slackpkg reinstall’ kscreenlocker, plasma-workspace and sddm-qt5, which I was previously unable to do for the same reason mentioned by davjohn. Thanks as always, Eric.
I have upgraded to a PAMmed system and everything works fine except for one thing: if I select automatic connection for SDDM in KDE’s System Settings, which allows to automatically log in with a particular user, I get an Authentification failed by PAM in the SDDM log, while logging in with the same user manually works fine from SDDM.
Does anyone else have this issue?
A workaround to allow autologin with SDDM is discussed at LQ: https://www.linuxquestions.org/questions/slackware-14/pam-about-to-be-merged-in-current-4175675326/page11.html#post6126005
Hope this helps
Thanks. However, these conf files do not really seem to be endorsed by Eric, not even talking about Pat. I’d prefer to have an approach that Eric is fine with and which keeps the general philosophy of his packages. Some of Eric’s answers seem to imply that the current settings should allow autologin when using non-privileged users, which is exactly what I want to do, I’m not interested in autologin as root. So I thought that maybe I did something wrong in my updates.
I am not against modifying the PAM configurations for SDDM, in fact I am looking at making them more in line with the files Pat added for KDM. That will mean, dropping the login stack and merely using the system-auth stack. With that, also the pam_securetty module will no longer be denying logins for root.
And then I’ll add a commented-out line showing you how to properly secure your box because I still think logging into a graphical desktop as root is unwise. But… everybody is allowed to shoot himself in the foot. I am not responsible for others hacking your computer.
Hi!
tried to start wayland session, but got empty screen with blinking cursor (I am running X with NVidia proprietary driver 440.100)
Hello,
I did succeed to lock me out by forgetting to run slackpkg install-new 🙁
Could you please give me a hint where to look for a solution. My search until now was unsuccessful.
Best regards,
Serban
Hi Serban
That’s unfortunate but you’re not the first one to forget to install a crucial package…
The common solution is to boot your computer using a Slackware install medium, download the missing package, mount your Slackware disk partition(s) under a directory like /mnt and install the downloaded package with a command like:
# ROOT=/mnt upgradepkg –install-new /path/to/package.t?z
A good option for a bootable Slackware medium is a Slackware Live variant; after it boots you should have a working internet connection in the Live environment,plus a browser you can use to locate and download whatever packages you are missing and need to install.
Hi Eric
And thank you very much! This message is written from the box I had gotten locked out from 🙂
Best regards,
Serban
Hi Eric,
it seems we are closer to a new stable, and this sounds like: we are waiting for the new stable Plasma5 (DE stable) to release a new version for Slackware. If this is true should we expect to switch to Wayland (stable)? Will Xfce be deprecated? I am a happy user of Xfce and my choice is guided by its lower resource consumption and its Spartan (minimal) approach, as opposed to the modern (looks like a monolith) Kde environment. Has this improved with the new plasma? I am thinking of moving to the current and possibly a new stable, and to Kde. Please reassure me:)
Wayland will *not* be the new default in Slackware and of course XFCE will *not* be deprecated.
KDE Plasma5 is about as light on resources as XFCE. Feel free to try a Live ISO or wait until Plasma5 goes out of testing and replaces KDE4 in slackware-current.
Hi Eric,
is there a reason that your poppler-compat package hasn’t been upgraded since October last year or is it just oversight? With each poppler-20.x upgrades for -current since October this year, people post on LQ about various issues they’ve encountered. Not me, though – I’ve used your buildscript and created my own refreshed -compat package.
There was no need for an update until now, Since Pat took over ktown and branded it vtown, he recompiled relevant Plasma5 packages (well, only okular is affected) against his poppler updates – except this last time. But that is something you should expect when running Slackware-current – sometimes things break and you get to re-assemble the pieces.
I have updated the poppler-compat package but I don’t expect that too many packages outside Slackware will need it.
Got it! Thanks for the upgraded package.
I always suspect that poppler .so bumps may create issues with some pdf viewers, that’s why I’ve made my own -compat packages – better safe than sorry.