SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
from what I known, the required Slackware knowledge, skills and efforts are so high, that I do not see others than Mr. Hameleers or Darth Vader, able of doing it.
That strikes me as odd, where is Darth Vader's community output (meaning code/usable work, not forum posts) that suggests they'd be up for maintaining an entire distro?
So what's going to be needed on the user's end when the change happens? life as usual? Anything to keep in mind so we're not locked out after the first reboot? Or is PAM not that way anymore?
All I'd suggest is, after you've applied the PAM packages, before logging out, swap to another console, altgr-sysrq k¹ to kill the existing getty and start a new one, and then make sure you can login as root.
It's a little over cautious, but if you find you can no longer login, you've at least got your original session from which to fix it.
--
¹ under no circumstances do altgr-sysrq k on tty1! Use one of the others.
That strikes me as odd, where is Darth Vader's community output (meaning code/usable work, not forum posts) that suggests they'd be up for maintaining an entire distro?
The Internet memories are really short, right?
Well, from what I known, what Darth Vader did, together with his merry men:
- a i586 fork/port of Slackware, with dependency resolution and all system utilities written in Qt3, including a graphical installer like YaST and with a partition manager in pair with GParted of that era: DARKSTAR Linux
- a pure x86_64 fork/port of Slackware, having also similar graphical tools and looking quite similar with today Slackware64: Bluewhite64 Linux
- a fork of Slackware, for pre-installation and with similar graphical tools - there I am not quite sure, but looks like a company from Germany shipped computers with "easys Linux" preinstalled.
All that happened while the epoch of Slackware 12.x with the exclusive architecture: i486, and when you people was quite busy to bash about PAM like you do today about systemd.
But, yeah - he did both i586 and x86_64 Slackware long years before to appear the Slackware's official variants. Honestly, you can consider him that had been visionary.
And still Slackware does not show any signs of graphical system utilities or dependency resolution within the package tools...
Last edited by LuckyCyborg; 05-15-2020 at 07:04 PM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,157
Rep:
Quote:
Originally Posted by GazL
All I'd suggest is, after you've applied the PAM packages, before logging out, swap to another console, altgr-sysrq k¹ to kill the existing getty and start a new one, and then make sure you can login as root.
It's a little over cautious, but if you find you can no longer login, you've at least got your original session from which to fix it.......
Perhaps I don't understand the question, but I've had all the PAM packages installed for quite sometime and it is all transparent to me. As I don't use PAM I don't notice a bit of difference in the operation of the machine.
I'm looking forward to this, but am also lazy when it comes to learning new things at the moment. So my question is... is there any need to reconfigure already working services in the near future? (for example postfix, dovecot, sshd, netatalk etc)? or will most of these keep running as before without reconfiguration/modification?
In my use case (regular desktop user with AlienBob's Plasma 5 and LibreOffice) using PAM was without trouble. I have PAM since Pat enabled it in testing.
Probably a silly question but
Could one just create a pam configure module that allows everything?
Would this neutralize pam and leave existing security in place?
[FLAME SUIT ON]
John
Well, from what I known, what Darth Vader did, together with his merry men:
- a i586 fork/port of Slackware, with dependency resolution and all system utilities written in Qt3, including a graphical installer like YaST and with a partition manager in pair with GParted of that era: DARKSTAR Linux
- a pure x86_64 fork/port of Slackware, having also similar graphical tools and looking quite similar with today Slackware64: Bluewhite64 Linux
- a fork of Slackware, for pre-installation and with similar graphical tools - there I am not quite sure, but looks like a company from Germany shipped computers with "easys Linux" preinstalled.
Good stuff, I wasn't aware that he'd worked on a fork (although no doubt there's been lots of Slackware forks). But where's the code? All I found is a bunch of broken links on Distrowatch/LQ.
Quote:
Originally Posted by LuckyCyborg
All that happened while the epoch of Slackware 12.x with the exclusive architecture: i486, and when you people was quite busy to bash about PAM like you do today about systemd.
I don't know who "you people" are, but I've personally never been against PAM in Slackware.
Quote:
Originally Posted by LuckyCyborg
But, yeah - he did both i586 and x86_64 Slackware long years before to appear the Slackware's official variants. Honestly, you can consider him that had been visionary.
Dunno, seems like all this is over a decade before I started using Slackware, and looks like there's nothing left behind of any of it. I mean I take your point that he did real work, that's cool, but with that history I wouldn't be jumping on board with any forks.
Quote:
Originally Posted by LuckyCyborg
And still Slackware does not show any signs of graphical system utilities or dependency resolution within the package tools...
So what's going to be needed on the user's end when the change happens? life as usual? Anything to keep in mind so we're not locked out after the first reboot? Or is PAM not that way anymore?
Based on Pat's default config, I don't think we need to worry about that. He didn't make any mention of it when it landed in testing/ and I haven't noticed any posts about major issues (just some suggestions on config options for certain aspects, like connecting to a domain controller). If the testing found that certain things should be done to ensure a lockout won't happen, I'd imagine Pat would include it in the changelog announcement (definitely not the time to blindly be doing slackpkg upgrade-all without reading through the changelog.
For reference, here's the relevant bit from the changelog entry that introduced PAM to testing/
Code:
Hey folks! PAM has finally landed in /testing. Some here wanted it to go
right into the main tree immediately, and in a more normal development cycle
I'd have been inclined to agree (it is -current, after all). But it's
probably better for it to appear in /testing first, to make sure we didn't
miss any bugs and also to serve as a warning shot that we'll be shaking up
the tree pretty good over the next few weeks. I'd like to see this merged
into the main tree in a day or two, so any testing is greatly appreciated.
Switching to the PAM packages (or reverting from them) is as easy as
installing all of them with upgradepkg --install-new, and if reverting then
remove the three leftover _pam packages. After reverting, a bit of residue
will remain in /etc/pam.d/ and /etc/security/ which can either be manually
deleted or simply ignored. While there are many more features available in
PAM compared with plain shadow, out of the box about the only noticable
change is the use of cracklib and libpwquality to check the quality of a
user-supplied password. Hopefully having PAM and krb5 will get us on track
to having proper Active Directory integration as well as using code paths
that are likely better audited these days. The attack surface *might* be
bigger, but it's also a lot better scrutinized.
Thanks to Robby Workman and Vincent Batts who did most of the initial heavy
lifting on the core PAM packages as a side project for many years. Thanks
also to Phantom X whose PAM related SlackBuilds were a valuable reference.
And thanks as well to ivandi - I learned a lot from the SlackMATE build
scripts and was even occasionally thankful for the amusing ways you would
kick my ass on LQ. ;-) You're more than welcome to let us know where we've
messed up this time.
Quote:
Originally Posted by LuckyCyborg
The Internet memories are really short, right?
I've been using Slackware for close to 2 decades now. I had never heard of Darkstar except for posts on this forum and that was only in the last year or two before Darth got banned.
Quote:
Originally Posted by LuckyCyborg
All that happened while the epoch of Slackware 12.x with the exclusive architecture: i486, and when you people was quite busy to bash about PAM like you do today about systemd.
Exclusive architecture that allowed Slackware to run on older hardware and that didn't prevent it from running on newer hardware. There are things that Pat prioritizes, and compatibility with a wide range of systems is one of them.
Quote:
Originally Posted by LuckyCyborg
But, yeah - he did both i586 and x86_64 Slackware long years before to appear the Slackware's official variants. Honestly, you can consider him that had been visionary.
Visionary? Because he used newer architectures? Yeah, I'm sure nobody ever suspected Slackware wouldn't have a 64bit release at some point... /s
Would you call someone visionary now if they were to recompile 32bit Slackware and offer it as an i686? (Currently only 10 packages in 32bit -current are built for i686)
At this point, I suspect you either worship Darth or you are Darth (I've long suspected the latter)... I've never seen someone talk about someone with such high praise that has basically nothing to show for it now. As was pointed out above, nothing remains of Darkstar except for a couple of reviews and the occasionally mention on this forum.
Quote:
Originally Posted by LuckyCyborg
And still Slackware does not show any signs of graphical system utilities or dependency resolution within the package tools...
Not many are clamoring for these "features". I'd prefer they stay out of Slackware. If you need dependency resolution, there's tons of other distros you can pick from. Full install is easy enough and space is cheap (even on NVMe drives).
Wow I never knew Darth created Blue/White64. I ran that for around a year and a half before Slackware proper released a 64 bit version. I guess you could say his 64 bit version of Slackware brought me to love Slackware as I have for over a decade. I feel I should mention that Blue/White64 was flawless, whether that was because of his work or the Slackware base I can't say. Really wish I had known Blue/White was his back when he was posting here I would have certainly made an effort to thank him.
On Pam I have no opinion, Just wait and see how it works out.
Last edited by itsgregman; 05-16-2020 at 12:41 AM.
I'm in it for the long haul. I'm looking forward to XFCE 4.14 and KDE-plasma.
Yeah -- road trip!
Quote:
And still Slackware does not show any signs of graphical system utilities or dependency resolution within the package tools
GUI tools have been requested through the years. Probably will never happen in Slackware, but I've learned to never outguess or predict Pat. The Salix folks have some GUI tools that are compatible with Slackware parent.
Dependency resolution always has been hotly debated. The long presumption is a full install, which is the default presumption with slackbuilds.org too. I don't see dependency resolution happening unless there is a dramatic surge in the user base and there is a huge official repository with compiled binaries.
Quote:
I've had all the PAM packages installed for quite sometime and it is all transparent to me. As I don't use PAM I don't notice a bit of difference in the operation of the machine.
As someone who has moved on from the "hobby" of grokking OS internals years ago,
I would ask, could someone sum up the "why" certain things like PAM "have to" be added
to a given OS? Simply upstream depends/demands?
And, not to release the Kraken, but how possible is it that "things" could happen "upstream" that mandate a similar "merging" of "something" else, something....with a "d" on the end?
..barring a simple "we're doing it" from our BDFL, what outside force(s) could necessitate in a technical sense, this kind of thing?
TIA
Perhaps I don't understand the question, but I've had all the PAM packages installed for quite sometime and it is all transparent to me. As I don't use PAM I don't notice a bit of difference in the operation of the machine.
Yeah, I doubt anyone will have any problems, I was just sharing an old sysadmin's life lesson, i.e. whenever you change anything related to login, ensure you can still login, before you logout.
There are some slight differences I noticed, but I doubt most people will spot them, or care.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
