1 |
Mark Creamer posted <433744A2.8030604@××××××××.net>, excerpted below, on |
2 |
Sun, 25 Sep 2005 19:45:22 -0500: |
3 |
|
4 |
> Although I'm getting better at dealing with the post update |
5 |
> configuration problems that always occur, I didn't know how to deal with |
6 |
> these. This time around, about 25 or so files in /etc/pam.d need |
7 |
> updating. My usual method is to look at the original and proposed |
8 |
> updated file in kdiff3, as that is much simpler to view than in |
9 |
> dispatch-conf (at least for me). But in this case, these files are all |
10 |
> locked, so kdiff3 cannot open them for viewing. |
11 |
> |
12 |
> So maybe someone just knows... |
13 |
> a. is it safe to just update all these files and not worry about it |
14 |
> b. is there a way that I can get kdiff3 to display them so I can see |
15 |
> what's changing |
16 |
> c. are these the type of files that should be protected from ever |
17 |
> changing during an update |
18 |
|
19 |
I believe (but am not sure so it'd be best to check it out) that the |
20 |
changes have to do with making the PAM configuration gentoo-bsd |
21 |
compatible. That project has been underway for a a month or six weeks |
22 |
now, I'd say, but the updates are likely just now going stable (I'm on |
23 |
~amd64 so of course I've processed most of them already). If these are |
24 |
indeed the changes you are seeing, they'll be of the nature of one PAM |
25 |
module replaced by a slightly different config, and all 25-ish files will |
26 |
have the same basic changes. They should be safe to just upgrade, but I |
27 |
ALWAYS look at the changes being made anyway, just to see what's going on |
28 |
(which combined with my following the action on the dev list, is the |
29 |
reason I know about this in the first place). |
30 |
|
31 |
The files are showing up "locked" due to permissions. Apparently, you are |
32 |
running kdiff3 as your normal user. While most config files would be |
33 |
world-readable, PAM stands for Pluggable Authentication Methods, and is |
34 |
for just that -- authentication, therefore security. Thus, it's not wise |
35 |
for these files to be world readable, and they aren't. |
36 |
|
37 |
The solution, therefore, is to view the files either from root, or using |
38 |
sudo (if you have it set up appropriately, of course). If you don't |
39 |
have sudo set up (if you do, you'd probably have figured this out |
40 |
already), you should be able to do this using kdiff3 by launching |
41 |
konsole, su-ing to root, then launching kdiff3 from the root shell in |
42 |
konsole (either loading the files after launch or adding them to the |
43 |
command line as appropriate, as well). I don't have kdiff3 setup, but |
44 |
I've been using a root shell session in konsole for system management |
45 |
since I switched to Linux, back on Mandrake, some four years ago, IIRC. |
46 |
Normally, it "just works", with KDE handling all the Xauth stuff that |
47 |
would otherwise be needed automatically, behind the scenes, transparently, |
48 |
from the user's perspective. |
49 |
|
50 |
Very few files (fstab being one) should be protected from /ever/ changing |
51 |
during an update. Most config files, even the ones you've customized, |
52 |
will need to be looked at, possibly in parallel with examining the |
53 |
documentation for the new version, to see if the configuration method and |
54 |
parameters have changed. If they have and you keep the old version, |
55 |
whatever the config is for may not start at next boot, or may start but |
56 |
not be configured for proper operation. Thus, even nearly entirely |
57 |
customized config files (the CUPS config comes to mind) should normally be |
58 |
diffed, to see what has changed and whether you need to reconfigure your |
59 |
customization to match the changes. |
60 |
|
61 |
FWIW, if you're interested in a book that'll jump-start your understanding |
62 |
of a Linux system and its standard config files, take a look at O'Reilly's |
63 |
"Running Linux". It's a $40 (US) book, some 6-700 pages, but it's well |
64 |
worth it, designed much like a text book, covering how Linux works and is |
65 |
configured. Back when I got serious about Linux (when it became obvious |
66 |
MS was going to do stuff with eXPrivacy I couldn't accept, so if I were to |
67 |
upgrade from '98, it'd have to be to Linux, since I couldn't upgrade to |
68 |
eXPrivacy), I asked a bunch of Linux folks what the best book on the |
69 |
subject was if I wanted to really grok Linux and be able to use and |
70 |
configure it at the same power user level as I could MSWormOS. This book |
71 |
came up several times, so I bought it. It was worth every penny and then |
72 |
some, as I figure it saved me the equivalent of three full months of |
73 |
40-hour weeks worth (thus, 13 weeks x 40 hours, 520 hours, how much is |
74 |
three months of full-time work worth to YOU? Probably several grand in |
75 |
any case -- the $40 was chump change for what I got out of it!) of SERIOUS |
76 |
WORK, bumbling around on my own. Given that you are already running |
77 |
Gentoo, it likely won't be quite so dramatic for you, but let's put it |
78 |
this way, having mastered it, permissions issues like yours above, and |
79 |
their resolutions, should be fairly self evident. You won't have to ask |
80 |
people about things like that any more. |
81 |
|
82 |
-- |
83 |
Duncan - List replies preferred. No HTML msgs. |
84 |
"Every nonfree program has a lord, a master -- |
85 |
and if you use the program, he is your master." Richard Stallman in |
86 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
87 |
|
88 |
|
89 |
-- |
90 |
gentoo-amd64@g.o mailing list |