Discussion:
Gnome3 on Fedora 16 (Again)
Mick Farmer
2012-04-17 18:22:00 UTC
Permalink
Dear GLLUGers,

Two questions for those with more experience than me.

1. Do I need the initial ramdisk? How can I disable it?

2. How do I get my name to appear on the sign in dialogue? At present
I have to go through the "Not listed" sequence by hand.

Your help is much appreciated.

Regards,

Mick

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Alain Williams
2012-04-17 18:58:43 UTC
Permalink
Post by Mick Farmer
Dear GLLUGers,
Two questions for those with more experience than me.
1. Do I need the initial ramdisk? How can I disable it?
It is part of the boot process, it is automatically built when a new kernel is
installed. The point is that the generic kernels don't have the drivers for your
hard disk, ... - these are loaded as modules. This is good because it allows the
generic kernel to run on a wide variety of hardware without being bloated with
lots of drivers that will never be used on your particular machine.
Problem is: how does the kernel load the hard disk driver from the hard disk
before it has loaded the driver for the hard disk. The initrd (ram disk) is
built to contain drivers to get the system running -- it is loaded when the
kernel is by the BIOS.

Summary: You need it.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
John Winters
2012-04-17 18:35:55 UTC
Permalink
Post by Mick Farmer
Dear GLLUGers,
Two questions for those with more experience than me.
1. Do I need the initial ramdisk? How can I disable it?
I'm not familiar with Fedora, but usually the purpose of an initial
ramdisk is to allow the use of a generic kernel with lots of loadable
modules. The initrd provides somewhere from which to load whatever
modules are needed by your particular hardware configuration.

You can get rid of it by building your own kernel with all the required
drivers compiled in rather than being loaded as modules.

The question arises though - why do you want to?

John
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Stuart Sears
2012-04-17 19:25:09 UTC
Permalink
Post by John Winters
Post by Mick Farmer
Dear GLLUGers,
Two questions for those with more experience than me.
1. Do I need the initial ramdisk? How can I disable it?
I'm not familiar with Fedora, but usually the purpose of an initial
ramdisk is to allow the use of a generic kernel with lots of loadable
modules. The initrd provides somewhere from which to load whatever
modules are needed by your particular hardware configuration.
You can get rid of it by building your own kernel with all the required
drivers compiled in rather than being loaded as modules.
The question arises though - why do you want to?
I think it was just a misunderstanding of what the initrd is for.

On any modern distro it is moderately insane to build your own kernel :)
(outside of specialist edge cases and just pure curiosity)

Stuart
--
Stuart Sears RHCA etc. "It's today!" said Piglet. "My favourite day,"
said Pooh.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
DL Neil
2012-04-17 22:50:05 UTC
Permalink
Mick,
Post by Mick Farmer
2. How do I get my name to appear on the sign in dialogue? At present
I have to go through the "Not listed" sequence by hand.
How did you do that? What is your "not listed" userNM?

As part of the load-from-CD/DVD process not only is the Root user
created but Anaconda expects you to create a user-user account. This
should appear within the list on the log-in dialog box.

NB The root user is, by default at least, banned from logging-in.

If you haven't already (as above, 'Anaconda') try manually creating a
new user/account (Users and Groups in Gnome, or maybe you'll need to SU
from the cmdLN - depending upon your user privileges) to see if that
(newly created) user will list appropriately...
--
Regards,
=dn
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Mick Farmer
2012-04-17 23:45:29 UTC
Permalink
Dear dn,

I've inherited my username from Fedora 14 before I upgraded to Fedora
16. My uid/gid is 500/500.

I used useradd to add user test to my system. The default uid/gid
created was 1000/1000. When I activated the sign in menu, that user was
offered.

So, how does the sign in process decide who can be included in the sign
in menu from all the user names in /etc/passwd? uid/gid? /home entry?
something else?

I hope someone out there knows the answer!

Regards,

Mick


--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
DL Neil
2012-04-18 01:13:36 UTC
Permalink
Mick,
Post by Mick Farmer
Dear dn,
I've inherited my username from Fedora 14 before I upgraded to Fedora
16. My uid/gid is 500/500.
I used useradd to add user test to my system. The default uid/gid
created was 1000/1000. When I activated the sign in menu, that user was
offered.
I remember reading in the Release Notes (one of the recent Fred
releases) something about expanding the lower-numbered UID/GUID
allocations from a 'pool' of 500 up to 1,000.
Post by Mick Farmer
So, how does the sign in process decide who can be included in the sign
in menu from all the user names in /etc/passwd? uid/gid? /home entry?
something else?
Perhaps the above has something to do with it - that and the fact that
you came the 'upgrade' route (cf a fresh installation). At the same
time, the guys working on id, authentication, and authorisation may have
(exclusively) implemented the new regime...

FWIW my clean install's 'first user' does indeed have a UID of 1000.

Apparently there was no concept of 'translating' old id allocs to the
new scheme. I wonder if there is a post-fact conversion-package?

(haven't looked at migration facilities/concerns - am usually too
chicken to upgrade between releases, and simply let YUM do its thing or
(re-)start a new m/c with 'fresh')
Post by Mick Farmer
I hope someone out there knows the answer!
I'm a cynic from way-back, so guessed it might be something to do with
"once was true, no longer is" coupled with a dose of "left hand...right
hand".

A more believable (and factual) explanation is above my pay-grade...
--
Regards,
=dn
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
John Edwards
2012-04-18 08:42:12 UTC
Permalink
Hi
Post by DL Neil
Post by Mick Farmer
Dear dn,
I've inherited my username from Fedora 14 before I upgraded to Fedora
16. My uid/gid is 500/500.
I used useradd to add user test to my system. The default uid/gid
created was 1000/1000. When I activated the sign in menu, that user was
offered.
I remember reading in the Release Notes (one of the recent Fred
releases) something about expanding the lower-numbered UID/GUID
allocations from a 'pool' of 500 up to 1,000.
Post by Mick Farmer
So, how does the sign in process decide who can be included in the sign
in menu from all the user names in /etc/passwd? uid/gid? /home entry?
something else?
Perhaps the above has something to do with it - that and the fact
that you came the 'upgrade' route (cf a fresh installation). At the
same time, the guys working on id, authentication, and authorisation
may have (exclusively) implemented the new regime...
FWIW my clean install's 'first user' does indeed have a UID of 1000.
Apparently there was no concept of 'translating' old id allocs to
the new scheme. I wonder if there is a post-fact conversion-package?
Changing the UID and GID of a logged in user it not an easy process,
and if that user is the only one with sudo privileges if it likely
to end up with a broken system.

Here are a couple of options:

A) Try setting the value for "MinimalUID" in gdm.conf back to 500.
On old versions of gdm this is /etc/gdm/gdm.conf, but on newer
versions that have /etc/gdm/custom.conf you should put your
changes there. Add "MinimalUID=500" in the "[greeter]" section.

This may mean that new "system" user accounts will eventually appear
in the login list. If you are the only user of the machine you can
easily ignore them.

B) Change your UID from 500 to 1001 (assuming that it UID is not
used), and probably also your GID as well. Likely to be safer in the
long term, but carries a small amount of risk to it.

Steps are:
1) Make sure that you can login to the text console as the root user.
2) Logout of everything as your normal user.
3) As root run 'usermod -u 1001 <your_username>'
4) As root run 'groupmod -u 1001 <your_username>'
5) As root run 'find / -uid -exec 501 chown 1001 "{}" \;'
6) As root run 'find / -gid -exec 501 chgrp 1001 "{}" \;'
7) Log back in as your normal user.


Note that I've not tried either options on Fedora
only Debian/Ubuntu, so some steps may be different.
--
#---------------------------------------------------------#
| John Edwards Email: ***@cornerstonelinux.co.uk |
#---------------------------------------------------------#
John Edwards
2012-04-18 09:03:08 UTC
Permalink
On Wed, Apr 18, 2012 at 09:42:12AM +0100, John Edwards wrote:
<snip>
Post by John Edwards
B) Change your UID from 500 to 1001 (assuming that it UID is not
used), and probably also your GID as well. Likely to be safer in the
long term, but carries a small amount of risk to it.
1) Make sure that you can login to the text console as the root user.
2) Logout of everything as your normal user.
3) As root run 'usermod -u 1001 <your_username>'
4) As root run 'groupmod -u 1001 <your_username>'
The "-u" option in the groupmod should of course be "-g" for GID:
'groupmod -g 1001 <your_username>'

This is assuming that RedHat/Fedora still creates a group for every
user with the GID equal to the UID.
Post by John Edwards
5) As root run 'find / -uid -exec 501 chown 1001 "{}" \;'
Another typo:
find / -uid 501 -exec chown 1001 "{}" \;
Post by John Edwards
6) As root run 'find / -gid -exec 501 chgrp 1001 "{}" \;'
Another typo:
find / -gid 501 -exec chgrp 1001 "{}" \;
Post by John Edwards
7) Log back in as your normal user.
8) Realise that you shouldn't trust code sent via the Internet.


ps. If you have a lot of files then the 'find' commands will take a
long time, because chown/chgrp is called separately for every file.
This might be speeded up by piping the list of files to xargs with
something like:
find / -gid 501 -print0 | xargs -r0 chgrp 1001

But I sometimes meet problems with files with special characters in
them when doing this, usually created by Windows clients via Samba.
--
#---------------------------------------------------------#
| John Edwards Email: ***@cornerstonelinux.co.uk |
#---------------------------------------------------------#
Stuart Sears
2012-04-18 09:06:33 UTC
Permalink
Post by John Edwards
<snip>
Post by John Edwards
B) Change your UID from 500 to 1001 (assuming that it UID is not
used), and probably also your GID as well. Likely to be safer in the
long term, but carries a small amount of risk to it.
1) Make sure that you can login to the text console as the root user.
2) Logout of everything as your normal user.
3) As root run 'usermod -u 1001 <your_username>'
4) As root run 'groupmod -u 1001 <your_username>'
'groupmod -g 1001 <your_username>'
This is assuming that RedHat/Fedora still creates a group for every
user with the GID equal to the UID.
Post by John Edwards
5) As root run 'find / -uid -exec 501 chown 1001 "{}" \;'
find / -uid 501 -exec chown 1001 "{}" \;
Post by John Edwards
6) As root run 'find / -gid -exec 501 chgrp 1001 "{}" \;'
find / -gid 501 -exec chgrp 1001 "{}" \;
Post by John Edwards
7) Log back in as your normal user.
8) Realise that you shouldn't trust code sent via the Internet.
ps. If you have a lot of files then the 'find' commands will take a
long time, because chown/chgrp is called separately for every file.
This might be speeded up by piping the list of files to xargs with
find / -gid 501 -print0 | xargs -r0 chgrp 1001
But I sometimes meet problems with files with special characters in
them when doing this, usually created by Windows clients via Samba.
--
Stuart Sears RHCA etc.
"It's today!" said Piglet.
"My favourite day," said Pooh.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Stuart Sears
2012-04-18 09:49:20 UTC
Permalink
Apologies for the double-posting. My idiocy with this webmail--
interface :)
Post by John Edwards
<snip>
Post by John Edwards
B) Change your UID from 500 to 1001 (assuming that it UID is not
used), and probably also your GID as well. Likely to be safer in the
long term, but carries a small amount of risk to it.
1) Make sure that you can login to the text console as the root user.
2) Logout of everything as your normal user.
3) As root run 'usermod -u 1001 <your_username>'
4) As root run 'groupmod -u 1001 <your_username>'
'groupmod -g 1001 <your_username>'
This is assuming that RedHat/Fedora still creates a group for every
user with the GID equal to the UID.
They do.
Post by John Edwards
Post by John Edwards
5) As root run 'find / -uid -exec 501 chown 1001 "{}" \;'
find / -uid 501 -exec chown 1001 "{}" \;
Post by John Edwards
6) As root run 'find / -gid -exec 501 chgrp 1001 "{}" \;'
find / -gid 501 -exec chgrp 1001 "{}" \;
Post by John Edwards
7) Log back in as your normal user.
8) Realise that you shouldn't trust code sent via the Internet.
:)

Indeed. Lookup the commands and check that the options do what we
claim.
RTFM as the old adage goes.
Post by John Edwards
ps. If you have a lot of files then the 'find' commands will take a
long time, because chown/chgrp is called separately for every file.
This might be speeded up by piping the list of files to xargs with
find / -gid 501 -print0 | xargs -r0 chgrp 1001
But I sometimes meet problems with files with special characters in
them when doing this, usually created by Windows clients via Samba.
A few notes on the (very sensible) procedure outlined above:

At first, I would probably only concern myself with /home/$username,
/tmp and /var/tmp
as those are the only parts of the filesystem to which non-privileged
users have write access by default.
That would enable you to login as the newly modified user account and
then use sudo or su to fix anything else.

Also, at no point does the advice cover changing the primary GID of
your user to 1001, which would also be required.

so you could just do (as root)
1. groupmod -g 1001 yourusername
(the group first, otherwise the following would probably complain that
there is no group with gid 1001)

2. usermod -a -G 500 -u 1001 -g 1001 yourusername
(this also adds your new user to the primary group of the old one -
this should allow access to
any files that haven't been converted by the rest of the commands. You
do end up with an orphaned group though.)

4. find /tmp /var/tmp /home -uid 500 -print0 | xargs -r0 chown -v
username:
(the trailing : automatically uses the new user's primary group. If you
don't want that, don't use it. :) )

5. find /tmp /var/tmp /home -gid 500 -print0 | xargs -r0 chgrp -v
newusername

6. logout of the root terminal and (probably, to be sure there are no
sessions lying about with the old UID/GID) reboot.

7. login after the reboot, which should work just fine. if not, login
as root on the terminal and work out why :)

Then if you want to check the entire filesystem, you can do it in a
graphical terminal while doing other things.


Stuart
(waiting for the mistakes that he has inevitably made to be pointed
out)
--
Stuart Sears RHCA etc.
"It's today!" said Piglet.
"My favourite day," said Pooh.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
John Edwards
2012-04-18 11:05:17 UTC
Permalink
On Wed, Apr 18, 2012 at 10:49:20AM +0100, Stuart Sears wrote:
<snip>
Post by Stuart Sears
At first, I would probably only concern myself with /home/$username,
/tmp and /var/tmp
as those are the only parts of the filesystem to which
non-privileged users have write access by default.
Mostly true. There are lots of little places in /var that can still
have user-owned files, for example /var/spool/mail or /var/mail. Some
systems place shared files in /srv (for things like Samba or Apache).
/opt and /usr/local can also be used by non-distribution packages.
Post by Stuart Sears
That would enable you to login as the newly modified user account
and then use sudo or su to fix anything else.
Also, at no point does the advice cover changing the primary GID of
your user to 1001, which would also be required.
<snip>

Quite right, I missed that one out as well. Thanks for fixing it.

I really should remember not to reply in the morning before I had a
good cup of tea or coffee.


Back to Fedora. It seems odd that the Release Notes says that on
upgraded systems new users will still UID starting in the 500 range
because login.defs is not update:
https://docs.fedoraproject.org/en-US/Fedora/16/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#id3021598

Which seems odd, because then the default gdm configuration will not
show the new usernames in it's user list.
--
#---------------------------------------------------------#
| John Edwards Email: ***@cornerstonelinux.co.uk |
#---------------------------------------------------------#
Nix
2012-04-18 13:12:52 UTC
Permalink
Post by John Edwards
This might be speeded up by piping the list of files to xargs with
find / -gid 501 -print0 | xargs -r0 chgrp 1001
But I sometimes meet problems with files with special characters in
them when doing this, usually created by Windows clients via Samba.
*That* should only happen if chgrp is buggy. What characters were these?
What version of coreutils? (Maybe we can whip up a testcase...)
--
NULL && (void)
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
John Edwards
2012-04-18 14:06:22 UTC
Permalink
Post by Nix
Post by John Edwards
This might be speeded up by piping the list of files to xargs with
find / -gid 501 -print0 | xargs -r0 chgrp 1001
But I sometimes meet problems with files with special characters in
them when doing this, usually created by Windows clients via Samba.
*That* should only happen if chgrp is buggy. What characters were these?
What version of coreutils? (Maybe we can whip up a testcase...)
Sorry it was several years ago, so I should have used the past tense.
The details are long gone from my memory and the server in question
has probably gone to Silicon Heaven by now (along with it's files).

I'm also slightly nervous about piping data to things like chown and
chmod (and rm!) without checking the data myself. The xargs man page
does now say that for -0 the "quotes and backslash are not special
(every character is taken literally)" so I hope it is now safe.

I've got an Ubuntu laptop where I really should fix the UIDs, so I may
try the xargs pipe there.
--
#---------------------------------------------------------#
| John Edwards Email: ***@cornerstonelinux.co.uk |
#---------------------------------------------------------#
Nix
2012-04-18 14:08:37 UTC
Permalink
Post by John Edwards
Post by Nix
Post by John Edwards
This might be speeded up by piping the list of files to xargs with
find / -gid 501 -print0 | xargs -r0 chgrp 1001
But I sometimes meet problems with files with special characters in
them when doing this, usually created by Windows clients via Samba.
*That* should only happen if chgrp is buggy. What characters were these?
What version of coreutils? (Maybe we can whip up a testcase...)
Sorry it was several years ago, so I should have used the past tense.
The details are long gone from my memory and the server in question
has probably gone to Silicon Heaven by now (along with it's files).
That's what I thought, but it was worth a try!
Post by John Edwards
I'm also slightly nervous about piping data to things like chown and
chmod (and rm!) without checking the data myself. The xargs man page
does now say that for -0 the "quotes and backslash are not special
(every character is taken literally)" so I hope it is now safe.
It's been safe for ages: this is why -0 was implemented. Before that,
sure, linefeeds were risky, but not e.g. other shell metacharacters (the
shell never gets to look at that datastream, and the commands get
exec()ed directly by xargs without getting the shell involved either).
--
NULL && (void)
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Chris Bell
2012-04-18 09:18:30 UTC
Permalink
Post by John Edwards
Changing the UID and GID of a logged in user it not an easy process,
and if that user is the only one with sudo privileges if it likely
to end up with a broken system.
My first attempts with Linux gave an initial UID 100, which soon changed.
I try to keep the UID for each user consistent across my local network, so I
always create a throw-away initial user, then create real users starting
from a much higher specified UID, edit the group permissions as required for
the real users, then delete the original throw-away user.
--
Chris Bell www.chrisbell.org.uk
Microsoft sells you Windows ... Linux gives you the whole house.

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Loading...