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
next prev parent 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