[gentoo-amd64] dispatch-conf confusion

[gentoo-amd64] dispatch-conf confusion

[Mark Creamer]

Although I'm getting better at dealing with the post update 
configuration problems that always occur, I didn't know how to deal with 
these. This time around, about 25 or so files in /etc/pam.d need 
updating. My usual method is to look at the original and proposed 
updated file in kdiff3, as that is much simpler to view than in 
dispatch-conf (at least for me). But in this case, these files are all 
locked, so kdiff3 cannot open them for viewing.

So maybe someone just knows...
    a. is it safe to just update all these files and not worry about it
    b. is there a way that I can get kdiff3 to display them so I can see 
what's changing
    c. are these the type of files that should be protected from ever 
changing during an update

Thanks for any advice...
Mark
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: dispatch-conf confusion

[Duncan]

Mark Creamer posted <433744A2.8030604@adelphia.net>, excerpted below,  on
Sun, 25 Sep 2005 19:45:22 -0500:

> Although I'm getting better at dealing with the post update 
> configuration problems that always occur, I didn't know how to deal with 
> these. This time around, about 25 or so files in /etc/pam.d need 
> updating. My usual method is to look at the original and proposed 
> updated file in kdiff3, as that is much simpler to view than in 
> dispatch-conf (at least for me). But in this case, these files are all 
> locked, so kdiff3 cannot open them for viewing.
> 
> So maybe someone just knows...
>     a. is it safe to just update all these files and not worry about it
>     b. is there a way that I can get kdiff3 to display them so I can see 
> what's changing
>     c. are these the type of files that should be protected from ever 
> changing during an update

I believe (but am not sure so it'd be best to check it out) that the
changes have to do with making the PAM configuration gentoo-bsd
compatible.  That project has been underway for a a month or six weeks
now, I'd say, but the updates are likely just now going stable (I'm on
~amd64 so of course I've processed most of them already).  If these are
indeed the changes you are seeing, they'll be of the nature of one PAM
module replaced by a slightly different config, and all 25-ish files will
have the same basic changes.  They should be safe to just upgrade, but I
ALWAYS look at the changes being made anyway, just to see what's going on
(which combined with my following the action on the dev list, is the
reason I know about this in the first place).

The files are showing up "locked" due to permissions.  Apparently, you are
running kdiff3 as your normal user.  While most config files would be
world-readable, PAM stands for Pluggable Authentication Methods, and is
for just that -- authentication, therefore security.  Thus, it's not wise
for these files to be world readable, and they aren't.

The solution, therefore, is to view the files either from root, or using
sudo (if you have it set up appropriately, of course).  If you don't
have sudo set up (if you do, you'd probably have figured this out
already), you should be able to do this using kdiff3 by launching
konsole, su-ing to root, then launching kdiff3 from the root shell in
konsole (either loading the files after launch or adding them to the
command line as appropriate, as well).  I don't have kdiff3 setup, but
I've been using a root shell session in konsole for system management
since I switched to Linux, back on Mandrake, some four years ago, IIRC. 
Normally, it "just works", with KDE handling all the Xauth stuff that
would otherwise be needed automatically, behind the scenes, transparently,
from the user's perspective.

Very few files (fstab being one) should be protected from /ever/ changing
during an update.  Most config files, even the ones you've customized,
will need to be looked at, possibly in parallel with examining the
documentation for the new version, to see if the configuration method and
parameters  have changed.  If they have and you keep the old version,
whatever the config is for may not start at next boot, or may start but
not be configured for proper operation.  Thus, even nearly entirely
customized config files (the CUPS config comes to mind) should normally be
diffed, to see what has changed and whether you need to reconfigure your
customization to match the changes.

FWIW, if you're interested in a book that'll jump-start your understanding
of a Linux system and its standard config files, take a look at O'Reilly's
"Running Linux".  It's a $40 (US) book, some 6-700 pages, but it's well
worth it, designed much like a text book, covering how Linux works and is
configured.  Back when I got serious about Linux (when it became obvious
MS was going to do stuff with eXPrivacy I couldn't accept, so if I were to
upgrade from '98, it'd have to be to Linux, since I couldn't upgrade to
eXPrivacy), I asked a bunch of Linux folks what the best book on the
subject was if I wanted to really grok Linux and be able to use and
configure it at the same power user level as I could MSWormOS.  This book
came up several times, so I bought it.  It was worth every penny and then
some, as I figure it saved me the equivalent of three full months of
40-hour weeks worth (thus, 13 weeks x 40 hours, 520 hours, how much is
three months of full-time work worth to YOU?  Probably several grand in
any case -- the $40 was chump change for what I got out of it!) of SERIOUS
WORK, bumbling around on my own. Given that you are already running
Gentoo, it likely won't be quite so dramatic for you, but let's put it
this way, having mastered it, permissions issues like yours above, and
their resolutions, should be fairly self evident. You won't have to ask
people about things like that any more.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: dispatch-conf confusion

[Mark Creamer]

Duncan wrote:

>Mark Creamer posted <433744A2.8030604@adelphia.net>, excerpted below,  on
>Sun, 25 Sep 2005 19:45:22 -0500:
>
>  
>
>>Although I'm getting better at dealing with the post update 
>>configuration problems that always occur, I didn't know how to deal with 
>>these. This time around, about 25 or so files in /etc/pam.d need 
>>updating. My usual method is to look at the original and proposed 
>>updated file in kdiff3, as that is much simpler to view than in 
>>dispatch-conf (at least for me). But in this case, these files are all 
>>locked, so kdiff3 cannot open them for viewing.
>>
>>So maybe someone just knows...
>>    a. is it safe to just update all these files and not worry about it
>>    b. is there a way that I can get kdiff3 to display them so I can see 
>>what's changing
>>    c. are these the type of files that should be protected from ever 
>>changing during an update
>>    
>>
>
>I believe (but am not sure so it'd be best to check it out) that the
>changes have to do with making the PAM configuration gentoo-bsd
>compatible.  That project has been underway for a a month or six weeks
>now, I'd say, but the updates are likely just now going stable (I'm on
>~amd64 so of course I've processed most of them already).  If these are
>indeed the changes you are seeing, they'll be of the nature of one PAM
>module replaced by a slightly different config, and all 25-ish files will
>have the same basic changes.  They should be safe to just upgrade, but I
>ALWAYS look at the changes being made anyway, just to see what's going on
>(which combined with my following the action on the dev list, is the
>reason I know about this in the first place).
>
>The files are showing up "locked" due to permissions.  Apparently, you are
>running kdiff3 as your normal user.  While most config files would be
>world-readable, PAM stands for Pluggable Authentication Methods, and is
>for just that -- authentication, therefore security.  Thus, it's not wise
>for these files to be world readable, and they aren't.
>
>The solution, therefore, is to view the files either from root, or using
>sudo (if you have it set up appropriately, of course).  If you don't
>have sudo set up (if you do, you'd probably have figured this out
>already), you should be able to do this using kdiff3 by launching
>konsole, su-ing to root, then launching kdiff3 from the root shell in
>konsole (either loading the files after launch or adding them to the
>command line as appropriate, as well).  I don't have kdiff3 setup, but
>I've been using a root shell session in konsole for system management
>since I switched to Linux, back on Mandrake, some four years ago, IIRC. 
>Normally, it "just works", with KDE handling all the Xauth stuff that
>would otherwise be needed automatically, behind the scenes, transparently,
>from the user's perspective.
>
>Very few files (fstab being one) should be protected from /ever/ changing
>during an update.  Most config files, even the ones you've customized,
>will need to be looked at, possibly in parallel with examining the
>documentation for the new version, to see if the configuration method and
>parameters  have changed.  If they have and you keep the old version,
>whatever the config is for may not start at next boot, or may start but
>not be configured for proper operation.  Thus, even nearly entirely
>customized config files (the CUPS config comes to mind) should normally be
>diffed, to see what has changed and whether you need to reconfigure your
>customization to match the changes.
>
>FWIW, if you're interested in a book that'll jump-start your understanding
>of a Linux system and its standard config files, take a look at O'Reilly's
>"Running Linux".  It's a $40 (US) book, some 6-700 pages, but it's well
>worth it, designed much like a text book, covering how Linux works and is
>configured.  Back when I got serious about Linux (when it became obvious
>MS was going to do stuff with eXPrivacy I couldn't accept, so if I were to
>upgrade from '98, it'd have to be to Linux, since I couldn't upgrade to
>eXPrivacy), I asked a bunch of Linux folks what the best book on the
>subject was if I wanted to really grok Linux and be able to use and
>configure it at the same power user level as I could MSWormOS.  This book
>came up several times, so I bought it.  It was worth every penny and then
>some, as I figure it saved me the equivalent of three full months of
>40-hour weeks worth (thus, 13 weeks x 40 hours, 520 hours, how much is
>three months of full-time work worth to YOU?  Probably several grand in
>any case -- the $40 was chump change for what I got out of it!) of SERIOUS
>WORK, bumbling around on my own. Given that you are already running
>Gentoo, it likely won't be quite so dramatic for you, but let's put it
>this way, having mastered it, permissions issues like yours above, and
>their resolutions, should be fairly self evident. You won't have to ask
>people about things like that any more.
>
>  
>
Thanks Duncan for taking the time for such a clear and thoughtful 
explanation. You're a great asset to this list.
Regards,
Mark
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: dispatch-conf confusion

[Tom Martin]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

In addition to what Duncan said, I'd recommend app-portage/cfg-update.
It is non-interactive, and simply overwrites files that haven not been
modified by the user, and leaves files that have well alone. This isn't
always what's desired, but it can be a useful tool in some
circumstances.

Tom

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]