public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mark Creamer <mcreamer@adelphia.net>
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64]  Re: dispatch-conf confusion
Date: Mon, 26 Sep 2005 06:09:50 -0500	[thread overview]
Message-ID: <4337D6FE.4040902@adelphia.net> (raw)
In-Reply-To: <pan.2005.09.26.08.59.24.927018@cox.net>

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



  reply	other threads:[~2005-09-26 11:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-26  0:45 [gentoo-amd64] dispatch-conf confusion Mark Creamer
2005-09-26  8:59 ` [gentoo-amd64] " Duncan
2005-09-26 11:09   ` Mark Creamer [this message]
2005-09-26 16:50     ` Tom Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4337D6FE.4040902@adelphia.net \
    --to=mcreamer@adelphia.net \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox