DJA wrote:
Ralph Shumaker wrote:
Excellent detail! And you mentioned a few things that I never would
have thought of on my own. Thank you for taking the time to type it up.
I do have a few questions though:
DJA wrote:
4) *DO NOT* create any user accounts from within the FC installer
unless
you don't mind UID/GID pairs based on some goof ball Redhat lunacy
(IMHO). This is especially true if you are preserving /home and any
apps owned by non-system, non-root users.
Any user you create from within the installer (and also with
System-config-user) will create a UID of n and a GID of n+1,
starting
with UID=501. So the UID/GID list will start 501/502, 503/504,
505/506, etc. Maybe there is some esoteric or security reason for
this, but I like my UID/GID pairs to match e.g. 506/506.
If you create users from within the installer (i.e. using the GUI),
you are given no control over either UID/GID or home directory
locations or names. It's a PITA to fix this after the installation,
especially if the user has already logged in, and even worse if that
user has run X. In fact, you have to be careful in creating users
in System-config-users also, because its defaults make the same
mess.
Use the CLI tool to create the users and groups, and then the GUI
tool to maintain them if you like. If you use the GUI tool to create
new users, make sure you create their group first or you might not
get what you want, and the GUI tool won't let you remove or rename a
group unless you first remove its users. Also the GUI tool doesn't
handle passwords as flexibly.
I created them from the graphical interface (not during the install,
except for maybe the user that was 501 on the old installation).
Before creating *any* of the users on the new install, I noted from
the old install all the user and group info from the users and groups
gui. I had no trouble creating the same sets on the new install. I
did not create groups. It automatically created the groups
(correctly) when I created the users. But, maybe this process was
helped by my having copied /home before doing this. Actually, I do
not recall when I copied /home, whether before or after. I knew each
user's password, so I don't remember if I entered this information
when setting up the users or if it didn't even ask me.
But have you looked at what the corresponding GID actually is for a
given user created with the GUI tool? I prefer the UID and GID
(numerical values) to match.
what does
$ ls -lan /home/
show?
I'm not around that PC. But I did confirm that both the files owner and
group displayed correctly in each user's home directory. Just looking
on my own PC here, where I used the GUI tool to set up the users, the
first user "rafael" has matching UID and GID (500). The second user has
matching also (501). After that, I set up a special group (502). In
hindsight, I probably should have set it up with an unusually high GID.
But I didn't. Much, much later (very recently), I added a third user.
He got UID 502 and GID 503, but only because they each were the next in
line respectively.
I just played with it. It looks like the GUI tool allows me to manually
set either UID *or* GID as low as 500 to higher than 1,000,000,000. I
didn't actually tell it to do it. But the up arrow in the box didn't
cap out as far as I cared to run it up.
04:47:55 $ ls -lan /home/
total 20
drwxr-xr-x 5 0 0 4096 Oct 27 09:58 .
drwxr-xr-x 24 1000 0 4096 Nov 12 20:42 ..
drwx------ 19 501 501 4096 Jan 13 2005 dick
drwx------ 21 502 503 4096 Nov 12 02:19 gvl
drwx------ 52 500 500 4096 Nov 15 04:35 rafael
04:48:05 $
[snip]
6) A re-install is a perfect time to do some repartitioning. I prefer
to switch to the console and run Fdisk for that rather than
Disk Druid, although I prefer Disk Druid for establishing mount
points. I also prefer Disk Druid for setting up Logical Volumes -
which I recommend BTW. I put everything into an LV except /, and
/boot (drat that italicizing notation!).
How does one invoke Disk Druid outside of the install process?
On Fedora, Disk Druid is the GUI app presented to allow the setting up
of partitions and their mount points - it's part of the default
install process.
Instead of using that to repartition, I switch to a console (the F2
console, I think) and run fdisk. When I've made my partitions, I
switch back the the F7 X console and run Disk Druid (still running) to
set mount points.
Are you saying that you even put swap into an LV?
No.
I've never done anything with LVs. Are they easy for the non-initiated?
Fedora's installer makes it pretty easy to do. I recommend reading the
man pages first though so you understand the terminology. Things must
be done in the right order or you don't get what you think you got,
and you'll find things getting rather messy at boot time.
Unfortunately, Disk Druid will let you make such mistakes without
warning.
But Trial and Error are my friends.
They teach me.
And I learn.
Usually.
Unless I die.
And what is the reasoning behind partitioning, anyway? Either I
never understood this, or I have just plain forgotten.
May I assume that when you an installation, you just let the installer
make partitioning decisions for you?
My reasoning? Stuff tends to fill all available space. That includes
hard drives. Every new incarnation of most any Linux distribution
seems to need more and more space on the root partition. I never throw
stuff away so my /home partition is never big enough [1].
And inevitably I make at least one partition way too big at the same
time I make another, more important, partition way too small. Of
course, were I a fortune teller, I could avoid such mistakes, but as
I'm not, LVM is the next best thing.
Nothing you stated here seems to argue against one big partition (aside
from swap). You answer a question I did not ask. You answered: "What
is your reasoning behind partition sizes?" I was not asking about the
reason for sizing the chunks, but rather the reason for chunking it in
the first place.
7) *BACK UP EACH USER'S MOZILLA AND/OR FIREFOX DIRECTORIES AND FILES*.
While FC still includes Mozilla, Firefox and Thunderbird are now the
default browser and email apps, respectively. And they don't
completely migrate existing folders and files from your existing
older Mozilla or Netscape configuration.
I took care of this by selecting Mozilla in the install list. It was
not selected by default, but it was there (fc3).
I was mistaken about this. I recently did a test install of FC3 on my
own PC. I must have downloaded and installed it onto my friend's PC
straightaway. It seemed like it was part of the FC3 install in
not-so-vivid recollection.
You very likely will find some or all of the mail folders missing
for each user in Thunderbird (TB). The data is still intact, but has
to be manually copied from the old .<email_client_folder> to TB.
Make
sure you look at /all/ your existing folders (e.g. Sent, Saved,
In Box, etc.) before you use that account in TB or you'll play hell
trying to merge stuff back in later. I recommend you compress all
existing mail folders before the migration.
Firefox doesn't seem to import Tab Sets reliably from Mozilla.
So you'll have to recreate those again from scratch. I didn't have
any problems with bookmarks.
Is there any advantage to using TB and FF over mozilla?
Personal taste I guess. I think both FF and TB are much more
extensible through the dozens of extensions available for each.
Extensions seem to work better than Plug-ins for Mozilla. And Mozilla
Mail is not, as far as I know, extensible at all.
Please cite examples. Extensible? I guess I assumed Extensible==Plugins.
8) Do a 'yum -y update' immediately after the initial install. This
will
actually take significantly longer with FC1-FC3 than the install.
FC4
is not so bad as there haven't been as many updates, and the default
app list is much smaller.
Don't forget to change the Yum default repository lists to faster
sites. Also, Fedora (Yum?) has changed where it looks for the list
repositories:
[EMAIL PROTECTED] miscellaneous]$ ls -la /etc/yum.repos.d/
total 56
-rw-r--r-- ... 233 Nov 1 2004 fedora-devel.repo
-rw-r--r-- ... 931 May 24 22:21 fedora.repo
-rw-r--r-- ... 280 Nov 1 2004 fedora-updates.repo
-rw-r--r-- ... 282 Nov 1 2004 fedora-updates-testing.repo
These are now pointed to by /etc/yum.conf.
How do I change them to "faster sites"? How do I know what is "faster"?
Use different repositories. For example, mirrors.kernel.org and
livna.org.
I think you again answered a question I did not ask. You answered:
"How do I change them?"
11) If you are moving from RH9 and older, then I see little reason
to go
with anything less than Fedora Core 4 (FC4). If you are overly
cautious, FC3 will do, but FC4 seems more than stable enough for
me,
and I expect FC5 won't be far off now. FC4 also seems to handle
things like USB storage and wireless better.
FC4 did not work on my PC for some reason. IIRC, the install went
smoothly but first boot would freeze. What I do remember vividly is
that the freeze was consistent. The same place, the same info, the
same everything, every time.
At what point did it freeze, and what kind of error?
Memory of this has faded to a mere "I remember having tried it, and the
freeze was absolutely consistent.".
I'll have to try another test install to get any details.
A good place to check is /etc/grub.conf. Make sure it coincides with
entries in /etc/fstab which is where the installer apparently gets its
location for /root when it sets up Grub.
IIRC, I told it not to touch my grub. I did the entry myself. I did
the same for FC3 and a second install of rh9. I know it found it (FC4)
correctly. The error happened while it was trying to load a bunch of
stuff. I'll have to do it again to find out.
[1] I have three ten-inch high stacks of floppy diskettes sitting in
front of my monitor (Save. Look at These More Closely. Recycle).
They've been there for at least three years. I'd throw them away but
I'm not sure if what is on them is important. And I know it'll take
nearly the rest of my free time in life to go through them to find
out. I know this. I've done it at least a dozen times. All that
happens is the diskettes get shuffled from one pile to another.]
Good luck with that.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
