© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
> Er, how is it silent when pam-auth-update asks you a question?
Silent, in the sense that when you run p-a-u, it doesn't indicate that the common-* files have been modified in any way; it just presents you with the same checkbox-list of profiles. You leave everything as-is, hit OK, look at the file, and the option you had just added is gone.
(Not that I'm keen on the ability for p-a-u to preserve module options---that means I have to guess what the tool does if the options change in a profile, and it has to "merge" that change with hand-modified options in common-*. Even worse if it asks the user what to do; how do you even word that question without confusing most people?)
> That seems to me like the best way to do things at scale.
I don't want to forgo p-a-u. It's beneficial for single users and admins, yes, but it's a boon to large sites as well, because it reduces your entire PAM configuration from four arbitrary freeform "script" files (in which any mistakes can have major consequences) to a short vector of enabled/disabled PAM profiles. If a user wants to install something that hooks into the PAM stack that isn't already in the image (let's say, ConsoleKit), they don't have to hand-edit/merge anything, or come running for support when they inevitably break PAM and lock themselves out; they just check a new box. This is why I never considered hand-tuning common-*, and instead went with a custom profile. It's far better to wedge a new piece into p-a-u, than to toss p-a-u altogether and hand-maintain everything the old-fashioned way. (I can hardly even stand working with Debian Lenny anymore because it doesn't have this. That's how big an improvement it's been for me.)
> We can certainly try to make it work more smoothly for you, but it does feel like you're creating extra work for yourself in a few places.
As I see it, custom profiles and hand-editing auto-generated files are "extra work," and I'm trying to laze my way away from that! :-)
> Debian Bug#429692. There's no progress on it so far as I know.
Just #include functionality? That seems overly modest (packages would still have to modify an existing file, they can't just drop a file into a directory), but still an improvement over what we have now. *push* *goad* *cajole*