public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: dispatch-conf confusion
Date: Mon, 26 Sep 2005 01:59:25 -0700	[thread overview]
Message-ID: <pan.2005.09.26.08.59.24.927018@cox.net> (raw)
In-Reply-To: 433744A2.8030604@adelphia.net

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



  reply	other threads:[~2005-09-26  9:04 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 ` Duncan [this message]
2005-09-26 11:09   ` [gentoo-amd64] " Mark Creamer
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=pan.2005.09.26.08.59.24.927018@cox.net \
    --to=1i5t5.duncan@cox.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