Good day,
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
It is auto boot if from boot or later.
Now as root I change the owner and group -R. This is annoying . Is there a way to make it stick please. Thanks Johan S
On Sun, 2011-07-03 at 17:49 +0200, Johan Scheepers wrote:
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
But are those "johan" user accounts on each system using the same numerical user ID? If they're not, that's your problem. The OS doesn't care what name is associated with an ID, it's the ID that it works with.
By default, with Red Hat -derived Linuxes, the first user created is (usually) 500. So, for instance, if you've installed Fedora over and over, the first username you create will have uid=500. And if that first user is always johan, it'll be 500. But, if you'd created other users first, or in different orders, they'll have different numbers.
Other OSs, such as some Debian-derived ones, start with a user ID of 1000 (last time I used one, or was it BSD?). So it gets messier the more different OSs you install.
It is possible to create users with specific IDs, but that can still be a problem with multi-boot system. Fedora, et cetera, consider IDs below 500 system IDs, and 500 and higher user IDs. Debian, used 1000 as the threshold.
Johan Scheepers wrote:
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
I had that, too, a long time ago. It came from experimenting with Debian, Ubunto and others and using the same username on those other non-Fedora systems. What I did was not really a solution. Since I am a confirmed Fedoristo, I simply do not mount my home/Documents partition to alien systems.
On 07/03/2011 10:55 AM, Petrus de Calguarium wrote:
Johan Scheepers wrote:
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
I had that, too, a long time ago. It came from experimenting with Debian, Ubunto and others and using the same username on those other non-Fedora systems. What I did was not really a solution. Since I am a confirmed Fedoristo, I simply do not mount my home/Documents partition to alien systems.
Johan, can you check /etc/passwd to see if the number of your uid belongs to user johan and check /etc/group to see if there is a group named johan and what it's gid is?
On 03/07/2011 20:01, JD wrote:
On 07/03/2011 10:55 AM, Petrus de Calguarium wrote:
Johan Scheepers wrote:
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
I had that, too, a long time ago. It came from experimenting with Debian, Ubunto and others and using the same username on those other non-Fedora systems. What I did was not really a solution. Since I am a confirmed Fedoristo, I simply do not mount my home/Documents partition to alien systems.
Johan, can you check /etc/passwd to see if the number of your uid belongs to user johan and check /etc/group to see if there is a group named johan and what it's gid is?
Machine one..johan 1000:1000 Machine two ..johan 500:500
On 07/03/2011 11:09 AM, Johan Scheepers wrote:
On 03/07/2011 20:01, JD wrote:
On 07/03/2011 10:55 AM, Petrus de Calguarium wrote:
Johan Scheepers wrote:
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
I had that, too, a long time ago. It came from experimenting with Debian, Ubunto and others and using the same username on those other non-Fedora systems. What I did was not really a solution. Since I am a confirmed Fedoristo, I simply do not mount my home/Documents partition to alien systems.
Johan, can you check /etc/passwd to see if the number of your uid belongs to user johan and check /etc/group to see if there is a group named johan and what it's gid is?
Machine one..johan 1000:1000 Machine two ..johan 500:500
OK! now we are getting somewhere. Is your same home account mounted by both machines? (I assume that it is).
if you ls -ld $HOME
and you get johan johan for UID and GID ownership, then on that machine, your home dir's UID and GID numbers match the numbers in the password file and the group file.
If not, then your home directory and it's contents belong to the user whose UI and GID match the password and group files in /etc.
On the machine that displays numbers, you need to become root and modify the uid and gid of user johan.
If you cannot become root, then you can have some more work to do:
1. On the machine where you CAN become root, then become root, and execute /usr/bin/system-config-users and in the GUI modify the UID and GID of user johan to match the numbers on the other machine. This means that after you finish the modification, you have to be sure that the /etc/passwd and /etc/group have the right numbers for UID and GID and they match the other machine.
2. as root, execute the command: chmod -R johan:johan ~johan
On some versions of linux, the command takes the form chmod -R johan.johan ~johan
On some other linux'es both variations work.
JD wrote:
Machine one..johan 1000:1000 Machine two ..johan 500:500
This is the problem I had with Debian and friends.
Fedora starts users at 500, while Debian&c uses 1000. So, if you use the same username on both, you now have the same user with both 500 and 1000 uid. When you log back into fedora (at least that is what happened to me), my stuff is now changed to user 500, or was it 501. It was a real mess! And the problem with Debian systems is that I could not find a way to get users to start at 500, so as to be the same as Fedora. It was a mess, so I decided no longer to mount user data to non-Fodora systems.
On 07/03/2011 02:26 PM, Petrus de Calguarium wrote:
JD wrote:
Machine one..johan 1000:1000 Machine two ..johan 500:500
This is the problem I had with Debian and friends.
Fedora starts users at 500, while Debian&c uses 1000. So, if you use the same username on both, you now have the same user with both 500 and 1000 uid. When you log back into fedora (at least that is what happened to me), my stuff is now changed to user 500, or was it 501. It was a real mess! And the problem with Debian systems is that I could not find a way to get users to start at 500, so as to be the same as Fedora. It was a mess, so I decided no longer to mount user data to non-Fodora systems.
I think you have exposed a very interesting problem. It means that if, for example, /home was created on separate partition on a fedora machine, and you decide to share that home mount point with other linux/es /, (many people have multiple versions of linux installed on same machine), then there will be this incompatibility as far as uid's and gid's are concerned.
I wonder why the distros do not agree to starting with the same uid/gid number for first user account.
Perhaps it is the drive to be different :)
On Sun, 2011-07-03 at 14:46 -0700, JD wrote:
I think you have exposed a very interesting problem.
It would be interesting if the problem hadn't been known about for the last 20 or 30 years, i.e. since Unix systems started being networked in large numbers.
This is exactly the reason Sun created NIS (formerly called Yellow Pages). Using NIS a set of machines can keep user ids and other info in sync. Nowadays LDAP is also used for this, as is Active Directory in the Windows world.
Unfortunately for people with only a couple of machines on their home network, these are usually too much trouble to set up, so the only solution is manually to keep UIDs/GIDs consistent across machines.
poc
On Sun, 2011-07-03 at 19:25 -0430, Patrick O'Callaghan wrote:
On Sun, 2011-07-03 at 14:46 -0700, JD wrote:
I think you have exposed a very interesting problem.
It would be interesting if the problem hadn't been known about for the last 20 or 30 years, i.e. since Unix systems started being networked in large numbers.
This is exactly the reason Sun created NIS (formerly called Yellow Pages). Using NIS a set of machines can keep user ids and other info in sync. Nowadays LDAP is also used for this, as is Active Directory in the Windows world.
Unfortunately for people with only a couple of machines on their home network, these are usually too much trouble to set up, so the only solution is manually to keep UIDs/GIDs consistent across machines.
poc
Yeah... NIS would be a bit overkill for a single user case.
I used to play on multiple distros (a *lot*), split right down the middle between Debian- and RPM-based systems. The solution to this is pretty simple for a single-user (or very few user) system. Every time you create a user on any system, specify the UID & GID explicitly, and always use UIDs/GIDs <= 1000. Fedora doesn't care if you have a UID much higher than 500, but Debian does care if your UID is lower than 1000 (in fact, the man page for "useradd" on Fedora even says that 1000 is the standard, Fedora just doesn't actually follow that).
So an example for me could be:
useradd -u 1001 -g 1001 i-yagami
So long as I use that same command to add myself to every system, no conflicts occur anywhere. On the other hand, if I add a new system and just enter "useradd i-yagami" (or use a GUI tool to add a user without declaring the uid/gid manually) then the account will either have a uid and gid of 1000 or 500, but either way my real /home/i-yagami folder will not be the place my new, mistaken home gets created and the permissions of the real home folder from within the new system will simply say 1001:1001.
I don't really like the idea of passing the shadow and passwd files around between systems or doing a lot of pipeline magic to fix inconsistencies between such files across distros. The problem is that different distros/systems handle user creation differently and you can be unexpectedly missing things or having weird minor trouble with your shared home folder. So going through the explicit "useradd -u # -g # [name]" process was the easiest way for me and its anything but a burden when dealing with a handful of users.
?? ?? wrote:
Every time you create a user on any system, specify the UID & GID explicitly, and always use UIDs/GIDs <= 1000. Fedora doesn't care if you have a UID much higher than 500, but Debian does care if your UID is lower than 1000 (in fact, the man page for "useradd" on Fedora even says that 1000 is the standard, Fedora just doesn't actually follow that).
So an example for me could be:
useradd -u 1001 -g 1001 i-yagami
So long as I use that same command to add myself to every system, no conflicts occur anywhere. On the other hand, if I add a new system and just enter "useradd i-yagami" (or use a GUI tool to add a user without declaring the uid/gid manually) then the account will either have a uid and gid of 1000 or 500, but either way my real /home/i-yagami folder will not be the place my new, mistaken home gets created and the permissions of the real home folder from within the new system will simply say 1001:1001.
This is well put :-) I believe you meant to say that you always choose UIDs/GIDs >= 1000.
I thought of changing my already existing Fedora UID:GID to 1000, but it was too much trouble, since I rarely spend more that a few logins in other systems, just to have a look, when some cool new feature hasn't yet hit Fedora. This happens rarely in the last couple of years, with Fedora having taken the lead. 1000:1000 would solve everything.
This is well put :-) I believe you meant to say that you always choose UIDs/GIDs >= 1000.
Indeed I did... that sort of typo is the kind that leaves a sleepy coder scratching his head sometimes ヽ(ｏ`皿′ｏ)ﾉ
I'm glad you got the idea anyway. I've found this to be a simple solution for tiny environments.
On the other hand, once you get a bunch of users, learning how to administer directory and authentication services is an enormous step forward (of course, it is also an enormous amount to learn at first, too -- but just the first time).
-Iwao
夜神 岩男 wrote:
This is well put :-) I believe you meant to say that you always choose UIDs/GIDs >= 1000.
Indeed I did... that sort of typo is the kind that leaves a sleepy coder scratching his head sometimes ヽ(ｏ`皿′ｏ)ﾉ
I'm glad you got the idea anyway. I've found this to be a simple solution for tiny environments.
On the other hand, once you get a bunch of users, learning how to administer directory and authentication services is an enormous step forward (of course, it is also an enormous amount to learn at first, too -- but just the first time).
Thanks for explaining it. I knew that changing the UID:GID to 1000 would have been sufficient, but I was not sure whether that would cause a need for further adjustments or not. And, since Fedora is my 'working' system, I really didn't want to dig any deep pits there. It is good to know that it is really that easy. Perhaps I will give some other distros a more serious try once in a while (but I do like Fedora, and have been with this distro for 11-12 years now, so I am not really into relearning all the /etc file locations, repos, installation stuff, etc.).
On 7/3/2011 6:43 PM, 夜神 岩男 wrote:
[...]
Fedora doesn't care if you have a UID much higher than 500, but Debian does care if your UID is lower than 1000 (in fact, the man page for "useradd" on Fedora even says that 1000 is the standard, Fedora just doesn't actually follow that).
[scratching head in bewilderment ...]
This seems like at least a documentation bug as the headache of a change between versions sounds too grim
You suggest using useradd with explicit number rather than default or the gui. How does one get around the initial user that the Fedora install packages needs created? Or does one create a scratch there, use useradd for a real user, and delete the scratch?
On 07/03/2011 08:38 PM, Paul Allen Newell wrote:
On 7/3/2011 6:43 PM, 夜神 岩男 wrote:
[...]
Fedora doesn't care if you have a UID much higher than 500, but Debian does care if your UID is lower than 1000 (in fact, the man page for "useradd" on Fedora even says that 1000 is the standard, Fedora just doesn't actually follow that).
[scratching head in bewilderment ...]
This seems like at least a documentation bug as the headache of a change between versions sounds too grim
You suggest using useradd with explicit number rather than default or the gui. How does one get around the initial user that the Fedora install packages needs created? Or does one create a scratch there, use useradd for a real user, and delete the scratch?
How about just modifying the user's uid gid (while su'ed to root): usermod -u NEW-UID -g NEW-GID LoginName chown -R NEW-UID.NEW-GID ~LoginName exit su shell Log out and log back in.
On 7/3/2011 8:59 PM, JD wrote:
How about just modifying the user's uid gid (while su'ed to root): usermod -u NEW-UID -g NEW-GID LoginName chown -R NEW-UID.NEW-GID ~LoginName exit su shell Log out and log back in.
I was assuming that uid shouldn't be changed once committed to a user (this was from 1980's and may be incorrect now ... or even back then but I didn't know it)?
On 07/03/2011 09:09 PM, Paul Allen Newell wrote:
On 7/3/2011 8:59 PM, JD wrote:
How about just modifying the user's uid gid (while su'ed to root): usermod -u NEW-UID -g NEW-GID LoginName chown -R NEW-UID.NEW-GID ~LoginName exit su shell Log out and log back in.
I was assuming that uid shouldn't be changed once committed to a user (this was from 1980's and may be incorrect now ... or even back then but I didn't know it)?
Yes you can change UID and GID. I was stating it within the context of user has just installed Linux, and just logged in for the first time. This would be the time to open a terminal (gnome terminal), and su to root and runt the command. You can actually do it at any time, but I thought that you would want the UID and GID to match your other linux distro, so at first login would be a good time to do it.
On 7/3/2011 9:19 PM, JD wrote:
On 07/03/2011 09:09 PM, Paul Allen Newell wrote:
On 7/3/2011 8:59 PM, JD wrote:
How about just modifying the user's uid gid (while su'ed to root): usermod -u NEW-UID -g NEW-GID LoginName chown -R NEW-UID.NEW-GID ~LoginName exit su shell Log out and log back in.
I was assuming that uid shouldn't be changed once committed to a user (this was from 1980's and may be incorrect now ... or even back then but I didn't know it)?
Yes you can change UID and GID. I was stating it within the context of user has just installed Linux, and just logged in for the first time. This would be the time to open a terminal (gnome terminal), and su to root and runt the command. You can actually do it at any time, but I thought that you would want the UID and GID to match your other linux distro, so at first login would be a good time to do it.
Yes, intent would be to do it immediately after install with first login. I asked the question outside of that context as I wanted to be clear on changing UID and GID anytime
Thanks, Paul
On 07/04/2011 03:59 AM, JD wrote: <>
How about just modifying the user's uid gid (while su'ed to root): usermod -u NEW-UID -g NEW-GID LoginName chown -R NEW-UID.NEW-GID ~LoginName
from "USERMOD(8)"
-g, --gid GROUP The group name or number of the user’s new initial login group. The group name must exist. A group number must refer to an already existing group. The default group number is 1.
therefore, "GROUPADD(8)" to create group first.
also, if "/etc/login.defs" has a GID_MIN set higher than desired, "-K" must be used;
from "GROUPADD(8)"
-K KEY=VALUE Overrides /etc/login.defs defaults (GID_MIN, GID_MAX and others). Multiple -K options can be specified.
see 'man' or 'info' pages for "USERMOD(8)" and "GROUPADD(8)".
On Sun, Jul 3, 2011 at 11:59 PM, JD jd1008@gmail.com wrote:
How about just modifying the user's uid gid (while su'ed to root):
You won't be able to change a user's UID while that user's logged in.
On Mon, 2011-07-04 at 02:55 -0400, Tom H wrote:
On Sun, Jul 3, 2011 at 11:59 PM, JD jd1008@gmail.com wrote:
How about just modifying the user's uid gid (while su'ed to root):
You won't be able to change a user's UID while that user's logged in.
Yes you will, except that since his running processes will continue under the old UID until they terminate, the user will almost immediately start getting weird errors until he logs out and in again.
poc
On Sun, 2011-07-03 at 20:38 -0700, Paul Allen Newell wrote:
On 7/3/2011 6:43 PM, 夜神 岩男 wrote:
[...]
Fedora doesn't care if you have a UID much higher than 500, but Debian does care if your UID is lower than 1000 (in fact, the man page for "useradd" on Fedora even says that 1000 is the standard, Fedora just doesn't actually follow that).
[scratching head in bewilderment ...]
This seems like at least a documentation bug as the headache of a change between versions sounds too grim
You suggest using useradd with explicit number rather than default or the gui. How does one get around the initial user that the Fedora install packages needs created? Or does one create a scratch there, use useradd for a real user, and delete the scratch?
I think you are referring to the user that is created when firstboot is flagged as true? In a GUI environment this is when you reboot the system after an Anaconda install from a disk (it works a bit differently on a PXE install or a minimal install) and it shows a welcome screen with a prompt for a new user?
Creating that first user throught the firstboot dialogue isn't required, it is just a nice way to get the ball rolling. You can <ctrl><alt><f2> to the next tty and login as root right then yourself and reboot again, now skipping the firstboot process and nothing will be broken in the system -- you will just have to manually add the first user because GDM will not have a method available for you to log in now (I believe root logins through GDM are disabled by default still?).
Anyway, your options are to disregard creating that firstboot prompted user (a prompt I rarely see since I tend to install across the network via PXE boot -- which boots to a text configurature for networking and some other things, and then boots to runlevel 3 by default with no user accounts created) or just create a trash user account you won't use or delete later. Its up to you, really -- none of the useradd schenanigans you play are going to hurt the system in any way as long as they are >= 500 on Fedora and >= 1000 on Debian.
On 7/3/2011 9:33 PM, 夜神 岩男 wrote:
On Sun, 2011-07-03 at 20:38 -0700, Paul Allen Newell wrote: [...]
Creating that first user throught the firstboot dialogue isn't required, it is just a nice way to get the ball rolling. You can<ctrl><alt><f2> to the next tty and login as root right then yourself and reboot again, now skipping the firstboot process and nothing will be broken in the system -- you will just have to manually add the first user because GDM will not have a method available for you to log in now (I believe root logins through GDM are disabled by default still?).
Without a default user given that one can't log in a root, I don't see how I can get into "a user" that I can su -l from.
Anyway, your options are to disregard creating that firstboot prompted user (a prompt I rarely see since I tend to install across the network via PXE boot -- which boots to a text configurature for networking and some other things, and then boots to runlevel 3 by default with no user accounts created) or just create a trash user account you won't use or delete later. Its up to you, really -- none of the useradd schenanigans you play are going to hurt the system in any way as long as they are>= 500 on Fedora and>= 1000 on Debian.
Friends run different Linuxes (is that the right plural?) and I'd prefer to have a pid/gid that is valid on both. Never bumped into issue before but my needs for Linux are changing and this might be an issue in the future, so I wanted to know what to do.
It sounds easier to do a scratch then play with runlevels, but I appreciate knowing there is a bypass if I want to figure out a way to boot into root (I presume runlevels?)
Thanks, Paul
On Sun, 2011-07-03 at 21:42 -0700, Paul Allen Newell wrote:
On 7/3/2011 9:33 PM, 夜神 岩男 wrote:
On Sun, 2011-07-03 at 20:38 -0700, Paul Allen Newell wrote: [...]
Creating that first user throught the firstboot dialogue isn't required, it is just a nice way to get the ball rolling. You can<ctrl><alt><f2> to the next tty and login as root right then yourself and reboot again, now skipping the firstboot process and nothing will be broken in the system -- you will just have to manually add the first user because GDM will not have a method available for you to log in now (I believe root logins through GDM are disabled by default still?).
Without a default user given that one can't log in a root, I don't see how I can get into "a user" that I can su -l from.
The root account already exists, and you can log directly into it from a text login prompt. You just can't do it through GDM, so you will have to hop to another tty by hitting <ctrl>+<alt>+<f2> or boot to runlevel 3 (or the equivalent now that we are in the opening days or systemd). In this case you are not "su -" to anything, you really are logged in as root.
Anyway, your options are to disregard creating that firstboot prompted user (a prompt I rarely see since I tend to install across the network via PXE boot -- which boots to a text configurature for networking and some other things, and then boots to runlevel 3 by default with no user accounts created) or just create a trash user account you won't use or delete later. Its up to you, really -- none of the useradd schenanigans you play are going to hurt the system in any way as long as they are>= 500 on Fedora and>= 1000 on Debian.
Friends run different Linuxes (is that the right plural?) and I'd prefer to have a pid/gid that is valid on both. Never bumped into issue before but my needs for Linux are changing and this might be an issue in the future, so I wanted to know what to do.
Any UID/GID >= 1000 will do in that case. So far Debian based distros are the ones that require this, and since Fedora has no problems handling it everything works just fine (at least for me so far). You will get some weird things happening if you share your actual home folder dot files, though -- Ubuntu does weird things and Fedora now does (other) weird things and they don't always agree -- so you can find bizaar artifacts from one settings style in the other. But that is survivable, just weird. (The way around this involves segregating your data from your dotfiles and mounting different /home partition locations on different distros and mounting data holding directories from somewhere else -- due to Unix filesystem magic it all looks the same to the user, but it keeps idiosyncracies between distros cleanly segregated, which is nice. As long as the UIDs are all the same and acceptable to all distros, you won't notice a thing.)
It sounds easier to do a scratch then play with runlevels, but I appreciate knowing there is a bypass if I want to figure out a way to boot into root (I presume runlevels?)
After you mess with this a bit yourself you'll see how easy it all is. All this talk is fun, but you'll really get it when you sit down and play with your own toys. The things you discover will help you a lot when it comes to removable media you've formatted to ext3/4 or something similar -- or package prebuilds that have bizaar UIDs owning files (Drupal contains several packages in their binary distro that are owned by UID 6336 by mistake).
-Iwao
On 7/3/2011 9:56 PM, 夜神 岩男 wrote:
The root account already exists, and you can log directly into it from a text login prompt. You just can't do it through GDM, so you will have to hop to another tty by hitting<ctrl>+<alt>+<f2> or boot to runlevel 3 (or the equivalent now that we are in the opening days or systemd). In this case you are not "su -" to anything, you really are logged in as root.
I will try learning how to boot runlevel 3 as an educational exercise ... scratch account still seems easiest
[...]
-Iwao
Thanks for the info! Paul
On Sun, 2011-07-03 at 21:42 -0700, Paul Allen Newell wrote:
Friends run different Linuxes (is that the right plural?) and I'd prefer to have a pid/gid that is valid on both. Never bumped into issue before but my needs for Linux are changing and this might be an issue in the future, so I wanted to know what to do.
If you simply mean being able to understand how each system works, then fine. But if you mean that you're going to share discs, or other storage devices, or NFS mounts, between different people's computers. You're going to have to manually work out, between all of you, which user IDs you're going to use, so you're consistent across all of your computers and installations.
On 7/4/2011 2:26 AM, Tim wrote:
If you simply mean being able to understand how each system works, then fine. But if you mean that you're going to share discs, or other storage devices, or NFS mounts, between different people's computers. You're going to have to manually work out, between all of you, which user IDs you're going to use, so you're consistent across all of your computers and installations.
Understood and have always kept such in mind in the past. The issue of 500 vs 1000 was the new bit I learned from this thread and need to add to the process.
Thanks, Paul
On 07/04/2011 09:09 PM, Paul Allen Newell wrote: <>
The issue of 500 vs 1000 was the new bit I learned from this thread and need to add to the process.
another to add, if you are a user on multi systems on multi machines and you wish to log into other machines, user name, id's, _and_ password need to be same.
On 7/4/2011 3:34 PM, g wrote:
On 07/04/2011 09:09 PM, Paul Allen Newell wrote: <>
The issue of 500 vs 1000 was the new bit I learned from this thread and need to add to the process.
another to add, if you are a user on multi systems on multi machines and you wish to log into other machines, user name, id's, _and_ password need to be same.
Learned that one near 30 years ago.
Heck, I have a hard enough time remembering one passwd (joke ... not serious)
On Mon, 2011-07-04 at 22:34 +0000, g wrote:
if you are a user on multi systems on multi machines and you wish to log into other machines, user name, id's, _and_ password need to be same.
Um, no, generally the passwords don't need to be the same. You just need to be able to log in.
On 7/4/2011 9:06 PM, Tim wrote:
On Mon, 2011-07-04 at 22:34 +0000, g wrote:
if you are a user on multi systems on multi machines and you wish to log into other machines, user name, id's, _and_ password need to be same.
Um, no, generally the passwords don't need to be the same. You just need to be able to log in.
I remember getting burned by different passwds for same user back in the 1980's ... can't remember the specifics. Though I am certain things have gotten much better in dealing with networks and protocols, I thought there was still some reason why passwd should be the same?
On Mon, 2011-07-04 at 21:20 -0700, Paul Allen Newell wrote:
On 7/4/2011 9:06 PM, Tim wrote:
On Mon, 2011-07-04 at 22:34 +0000, g wrote:
if you are a user on multi systems on multi machines and you wish to log into other machines, user name, id's, _and_ password need to be same.
Um, no, generally the passwords don't need to be the same. You just need to be able to log in.
I remember getting burned by different passwds for same user back in the 1980's ... can't remember the specifics. Though I am certain things have gotten much better in dealing with networks and protocols, I thought there was still some reason why passwd should be the same?
You may be thinking of the r* commands (rcp, rsh, ...) but I can't be bothered looking up the details. They are frowned on nowadays in any case.
poc
On 7/4/2011 9:26 PM, Patrick O'Callaghan wrote:
You may be thinking of the r* commands (rcp, rsh, ...) but I can't be bothered looking up the details. They are frowned on nowadays in any case.
poc
Maybe as that was "convention" back then ... its all s* commands now and I suppose that having to provide passwd on the transaction covers different passwd?
Not worth looking up details as I thought r* commands were worse than frowned on ...
Thanks, Paul
On Mon, 2011-07-04 at 21:20 -0700, Paul Allen Newell wrote:
I remember getting burned by different passwds for same user back in the 1980's ... can't remember the specifics. Though I am certain things have gotten much better in dealing with networks and protocols, I thought there was still some reason why passwd should be the same?
Perhaps with Samba shares, and automatic reconnections since last accessing them?
But I can't think of anything that requires passwords be the same on each, or even for any way for the other side to be able to tell that you've used the same password as it has stored. Generally, it's can you logon or not, however that's achieved.
There's the simplicity of only having to remember one password, versus the handing someone else your logon credentials on a plate to go hacking you everywhere...
Windows SMB used to be a great one for that. Try to connect to a shared resource that requires a password, or simply discover a new one that's been shared to your LAN, and Windows would helpfully send your username and password to see if they'd do. Way back in the olden days of Win95/98, they'd often be sent in plain text.
very useful thread, i've just sync all my data between my various "linuxes" :-) let's see how arch will work with uid/gid 500/500 :)
Thanks, Daniele
On Tue, 2011-07-05 at 10:48 +0200, Daniele Guerrieri wrote:
very useful thread, i've just sync all my data between my various "linuxes" :-) let's see how arch will work with uid/gid 500/500 :)
Thanks, Daniele
Its a good idea to use UID sets >= 1000. Everything based on Debian considered <= 999 to be reserved as per policy: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 So this means anything you ever touch that is Debian based most likely considers UID 500 to be within the dynamically allocated system UID range.
-Iwao
On Mon, 2011-07-04 at 13:33 +0900, 夜神 岩男 wrote:
Creating that first user throught the firstboot dialogue isn't required, it is just a nice way to get the ball rolling.
A suggestion: For your first user, don't create *your* user account, set up a test user to play with. Set up your account, separately.
Having a spare test user account, already set up, will come in handy when you have to debug some problem (later on) with your own account.
On 3 July 2011 22:46, JD jd1008@gmail.com wrote:
On 07/03/2011 02:26 PM, Petrus de Calguarium wrote:
JD wrote:
Machine one..johan 1000:1000 Machine two ..johan 500:500
This is the problem I had with Debian and friends.
Fedora starts users at 500, while Debian&c uses 1000. So, if you use the same username on both, you now have the same user with both 500 and 1000 uid. When you log back into fedora (at least that is what happened to me), my stuff is now changed to user 500, or was it 501. It was a real mess! And the problem with Debian systems is that I could not find a way to get users to start at 500, so as to be the same as Fedora. It was a mess, so I decided no longer to mount user data to non-Fodora systems.
I think you have exposed a very interesting problem. It means that if, for example, /home was created on separate partition on a fedora machine, and you decide to share that home mount point with other linux/es /, (many people have multiple versions of linux installed on same machine), then there will be this incompatibility as far as uid's and gid's are concerned.
I wonder why the distros do not agree to starting with the same uid/gid number for first user account.
It wouldn't really help: what happens when you have multiple users on each system (and even for a home desktop system this isn't unusual)? You just have to keep the account ID synced when you create them, which is usually quite easy, but does require you to be aware of the need to do it. Even more of an issue once you start dealing with NFS. As Patrick O'Callaghan says then you start thinking about LDAP etc., but it's a pain to set up and doesn't address the situation of multi-boot systems (though that's a small number). In theory installers could check this stuff and offer to synchronise uids for you (GIDs might be a bit more of a problem since lower ones are often used for system things, room for some standardisation there if it hasn't already happened, but those things tend to be restricted to /etc and other directories that wouldn't be shared anyway). I wonder if there are similar problems with Selinux contexts or if those are standardised enough to start with (and, again, the funny ones will probably not be in directories shared between systems).
On 07/03/2011 09:26 PM, Petrus de Calguarium wrote: <>
It was a real mess! And the problem with Debian systems is that I could not find a way to get users to start at 500, so as to be the same as Fedora.
check for file '/etc/login.defs'.
if not present as 'login.defs', you might find it in '/etc' by running;
grep -i uid *
grep -i gid *
Petrus de Calguarium:
It was a real mess! And the problem with Debian systems is that I could not find a way to get users to start at 500, so as to be the same as Fedora.
g:
check for file '/etc/login.defs'.
if not present as 'login.defs', you might find it in '/etc' by running;
grep -i uid *
grep -i gid *
If you're going to change defaults, for where user IDs start from. You want to move Fedora's up to start at 1000, not Debian's down to start from 500. Because each distro considers user IDs below their threshold to be system/application IDs, and treats them differently. You don't want to assign a user ID to a number that the OS thinks belongs to a system ID. It's not the same thing as inappropriately running as the root user, but it's the same kind of operating mistake. For multi-system compatibility, you're best to treat user and group IDs of 500 to 999 as no-mans land, and leave them unused.
Of course, if you feel like further system surgery, you could change the threshold that the system thinks is the separation between system and group IDs, *as* *well* *as* changing the lowest number the user-add functions will start counting from. They're two different things. But it's easier to just start users out from user and group ID 1000+.
On 07/04/2011 09:35 AM, Tim wrote: <>
If you're going to change defaults, for where user IDs start from. You want to move Fedora's up to start at 1000, not Debian's down to start from 500.
Because each distro considers user IDs below their threshold to be system/application IDs, and treats them differently.
in what way?
ria, with fedora, red hat and clones, i have set up myself and special users [admin type] between 500 and 999. regular users, ie, data entry, to be 1000 and up.
in unix systems, admin type users where set up 1000 -> 1999 and regular users as 2000 and up.
no special reason other than this is what i was told to do years ago. i do not recall if a reason was given other than just to do it.
You don't want to assign a user ID to a number that the OS thinks belongs to a system ID.
so you are saying fedora, red hat and clones, have it wrong?
<>
But it's easier to just start users out from user and group ID 1000+.
you change fedora's 'login.defs' in your installations? what else?
On 03/07/2011 20:25, JD wrote:
On 07/03/2011 11:09 AM, Johan Scheepers wrote:
On 03/07/2011 20:01, JD wrote:
On 07/03/2011 10:55 AM, Petrus de Calguarium wrote:
Johan Scheepers wrote:
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
I had that, too, a long time ago. It came from experimenting with Debian, Ubunto and others and using the same username on those other non-Fedora systems. What I did was not really a solution. Since I am a confirmed Fedoristo, I simply do not mount my home/Documents partition to alien systems.
Johan, can you check /etc/passwd to see if the number of your uid belongs to user johan and check /etc/group to see if there is a group named johan and what it's gid is?
Machine one..johan 1000:1000 Machine two ..johan 500:500
OK! now we are getting somewhere. Is your same home account mounted by both machines? (I assume that it is).
if you ls -ld $HOME
and you get johan johan for UID and GID ownership, then on that machine, your home dir's UID and GID numbers match the numbers in the password file and the group file.
If not, then your home directory and it's contents belong to the user whose UI and GID match the password and group files in /etc.
On the machine that displays numbers, you need to become root and modify the uid and gid of user johan.
If you cannot become root, then you can have some more work to do:
- On the machine where you CAN become root, then become root, and
execute /usr/bin/system-config-users
File not existing
and in the GUI modify the UID and GID of user johan to match the numbers on the other machine. This means that after you finish the modification, you have to be sure that the /etc/passwd and /etc/group have the right numbers for UID and GID and they match the other machine.
as root, execute the command: chmod -R johan:johan ~johan
On some versions of linux, the command takes the form chmod -R johan.johan ~johan
On some other linux'es both variations work.
Thanks to all who jumped in. There seem to be a lot of interest. Hi JD.. I used your advice with some modifications. First it is not a different machine but different distro's on same machine. Distro one being my main distro and was already..
johan@johan:~$ id uid=1000(johan) gid=1000(johan) groups=1000(johan),4(adm),20(dialout),24(cdrom),46(plugdev),112(lpadmin),120(admin), 122(sambashare) johan@johan:~$
so distro two needed changing because it was 500. Booted in distro 2 and as root.. Gedit
/etc/passwd and changed appropriate line to read.. . johan:x:1000:1000:Johan Scheepers:/home/johan:/bin/bash
and then gedit.. /etc/group
and changed appropriate line to..
johan:x:1000:
Then in /home/johan did.... chown johan ~johan chgrp johan ~johan
Logged out / in and was OK.
Rebooted 5 times both ways and permissions stayed put.
Now reading all the responses it seems there is more than one way to do this.
Again thanks to all. Johan S
On 4 July 2011 08:45, Johan Scheepers johansche@telkomsa.net wrote:
On 03/07/2011 20:25, JD wrote:
On 07/03/2011 11:09 AM, Johan Scheepers wrote:
On 03/07/2011 20:01, JD wrote:
On 07/03/2011 10:55 AM, Petrus de Calguarium wrote:
Johan Scheepers wrote:
A bit late replying, but some things others may find useful.
I have a multiple boot internal drive (different linux flavors)(excluding windows).
Have a external usb drive for backup between these different systems.
can you check /etc/passwd to see if the number of your uid belongs to user johan and check /etc/group to see if there is a group named johan and what it's gid is?
Machine one..johan 1000:1000 Machine two ..johan 500:500
On the machine that displays numbers, you need to become root and modify the uid and gid of user johan.
If you cannot become root, then you can have some more work to do:
- On the machine where you CAN become root, then become root, and
execute /usr/bin/system-config-users
File not existing
You might not have had it installed, I think it's listed as 'user management'. But basically just an interface to modify /etc/passwd and /etc/group
and in the GUI modify the UID and GID of user johan to match the numbers on the other machine. This means that after you finish the modification, you have to be sure that the /etc/passwd and /etc/group have the right numbers for UID and GID and they match the other machine.
- as root, execute the command:
chmod -R johan:johan ~johan
On some versions of linux, the command takes the form chmod -R johan.johan ~johan
On some other linux'es both variations work.
Then in /home/johan did.... chown johan ~johan chgrp johan ~johan
Logged out / in and was OK.
Rebooted 5 times both ways and permissions stayed put.
I'd hope so...
Now reading all the responses it seems there is more than one way to do this.
Actually there's only one way (line up the UIDs) and a few different tools to achieve it. What I'm replying about is actually this:
Then in /home/johan did.... chown johan ~johan chgrp johan ~johan
What this is doing is relabelling your home dir. ~johan expands in Bash to johan's home directory, so effectively these lines read: chown johan /home/johan chgrp johan /home/johan Because of this it doesn't really matter which directory you're in when you run it. Strictly speaking it doesn't do what we want, which is to re-map the UID and GID from old to new ones. And it doesn't recursively label (unless chown/chmod are aliased to -R in your setup?). You could do chown johan /home/johan -R chgrp johan /home/johan -R But this is still labelling based on location, fairly sensible for your home directory, but you might have non-johan group files in there for whatever reason and also might have other shared data areas with files of different owners and groups. For this reason chown has the --from option: --from=CURRENT_OWNER:CURRENT_GROUP
This allows you to recursively re-label paths (the entire file tree if you want) according to current group/owner: Change owner: chown johan --from 1000 -R /
Change group (using chown, N.B. ':'): chown :johan --from :1001 -R / I've used 1001 to illustrate the user's old GID (1001) might not have been the same as the old UID (1000), but it usually will be.
Both of these recursively do the root filesystem. N.B. symbolic links not followed without giving -L. (Is it possible to have symbolic links outside / in Linux? Don't think so.)
On 07/03/2011 08:49 AM, Johan Scheepers wrote:
Now booting in a different flavor the permissions change to numbers.
My normal permission is johan johan. I am the only user at home.
I think you're slightly confused here. What's changing isn't the permissions but the way the system reports the owner of the files. The system tracks that by the numeric userid and converts that to a name when displaying the information, because that's easier for humans to understand. Different distros start numbering normal users at different places and if your various installations use different numbering, they're going to think that files created in a different distro were created by a user they have no record of, so they can't display a name, only a number. Using chown to change this will work, but as soon as you go back to the distro you were using when you created them, you'll have to do it again. It's possible to set things so that your user has the same numeric userid in all of your installations, and if you do that, you'll have what you want.
On 07/03/2011 03:49 PM, Johan Scheepers wrote: <>
Now as root I change the owner and group -R. This is annoying . Is there a way to make it stick please.
in addition to tim's post;
actually, it is _file_ and _directory_ permissions, not hd permissions.
linux has a file '/etc/login.defs, to define *site-specific* configurations.
run;
man login.defs or info login.defs
for further information.
in 'login.defs' file, you will fine 4 definitions; "UID_MIN", "UID_MAX", and, "GID_MIN", "GID_MAX", as per man/info.
fedora and red hat use '500' for uid and gid minimum value, and, obviously, ubuntu uses a different value.
to maintain assignment compatability between 'flavors', *all* "flavors" need to have same values in 'login.defs', which i would suggest setting to '500', as most "flavors" start with '500'.
as root user with each non fedora or red hat "flavor";
cd to '/etc' directory and backup and edit 'login.defs' to new minimum value of '500'.
next, backup and edit files 'group' and 'passwd', changing old gid and uid to new value for "user".
cd to '/home' and issue command;
chown -R usrname:usrname usrname-directory
because you will probably have files elsewhere, use command;
find / -user old-user-id -print | xargs -0 /bin/chown new-id:new-id
this can takes some time, so if you know you have no files other than under '/home', change above to;
find /home -user old-user-id -print | xargs -0 /bin/chown new-id:new-id
examples for above commands;
chown -R johans:johans johans or find / -user 1000 -print | xargs -0 /bin/chown johans:johans or find /home -user 1000 -print | xargs -0 /bin/chown johans:johans
before using any of above, first read 'man' or 'info' for commands;
login.defs, chown, find, xargs
to be sure you understand what will happen.
hth.
-
Daniele Guerrieri -
g -
Ian Malone -
JD -
Joe Zeff -
Johan Scheepers -
Patrick O'Callaghan -
Paul Allen Newell -
Peter G. -
Tim -
Tom H -
夜神 岩男