Fedora 16 Will Number UIDs From 1000

dotancohen writes "Sharing users between Fedora and Debian-based distros just got a little easier. Beginning with Fedora 16, the Red-Hat based distro will number its human user UIDs starting from 1000, as opposed to the old 500. Though this change is intended to facilitate interoperability with other distros, it risks breaking backward compatibility with older Fedora releases including the newly released Fedora 15."

Comments

Am I the only one

[esocid]

who thinks so what?
I've been a Fedora user since core 5, but I'm on a single use box. Can't you just simply update all the UIDs to add # so they all start at 1000, or is this more complex than I think?

Re:Am I the only one

[swordgeek]

If you're talking about an upgrade, then no. Change the UIDs and all of the files that were owned by the previous UIDs are now orphans.

Nonetheless, this still seems utterly unimportant.

Re:Am I the only one

[Culture20]

You'll need to find / -uid [number] -exec chown [new number]:[new gid] {} \;

Re:Am I the only one

[Jeremiah Cornelius]

Heh.

Don't tell the guys who think Linux is Gnome about the magic keys.

They might take her out for a drive.

Re:Am I the only one

[Culture20]

Forget that. This guy has the real answer. My answer was off the cuff, and I didn't think about files with differing gids.

Re:Am I the only one

[ianare]

An important element is, as often, totally ignored in the summary :

We are not in situation that 500 IDs for system accounts ought to be enough for anybody.
Actually, it was not 500. It was 299 because range 0-200 is for reserved IDs.
There are 799 non reserved IDs for system accounts available after this
change.

Re:Am I the only one

[rthille]

This should use -print0 and -0 on the find and xargs, otherwise it fails on silly paths with spaces or other weird crap in them.
Also, this only solves the issue of who owns the files, not issues related to stupid software with UIDs hard-coded in them...
Really, it's a big problem, but not because the issue is complex, but because people (developers) do stupid stuff and tracking down all the implications and sources of the problems can be difficult.

Re:Am I the only one

[unrtst]

I've been through this. Haven't noticed any other replies in any threads that have had to go through this.

I've got tons of backups and drives and external drives and network filesystems... all with my users uids in the low 500's. I left them there... and IMO, that *should* just work.

The biggest annoying problem I ran into - GDM wouldn't display those logins. They had the same group bindings, but it wouldn't show them. I dug around all over, and couldn't figure out where to change this "low uid" setting... and I haven't seen that posted here either!

I'm perfectly fine with them changing the default... but MAKE IT CONFIGURABLE! It'd just have to be one file in /etc, so one could easily jack with it for migrations. How difficult is that?!? Who knows, maybe it already exists and I just couldn't find it?

As others have mentioned, it's not just file ownership (though that's a significant undertaking when you consider NFS, removable drives, and backups - especially backups). Anything that's honoring this low-uid stuff, and anything that has uid's stored in configs, will need tweaking. Just make it easy to change the default, and this would blow over.

Re:Am I the only one

[jdoff]

Better:

find / -uid 501 -exec chown 1001 {} \;
find / -gid 501 -exec chgrp 1001 {} \;

Or even better would be a short Perl script with a hash mapping old UIDs to new UIDs, and then you only touch each file once, regardless of the number of user accounts on the system.

Re:Am I the only one

[nabsltd]

I'm perfectly fine with them changing the default... but MAKE IT CONFIGURABLE! It'd just have to be one file in /etc, so one could easily jack with it for migrations. How difficult is that?!? Who knows, maybe it already exists and I just couldn't find it?

You mean like /etc/login.defs?

Re:Am I the only one

[icebike]

If you're talking about an upgrade, then no. Change the UIDs and all of the files that were owned by the previous UIDs are now orphans.

Nonetheless, this still seems utterly unimportant.

Well, actually, that's not exactly true.

I've been thru this with other distros in the past, and in-place upgrades are never really a problem as you mention,
because the same users/groups are retained. Therefore no files become orphans.

New users just start higher when they are added. You can also make a simple setting to continue using 500 as the first user
if you want, you are not forced to start at 1000.

Moving data to a new server is where it gets messy, to say nothing about NFS coordination.

In our case, being a small size installations we opted to simply build a "find and chown" script to be run once, rather than
continuing with the legacy numbering.

Re:Am I the only one

[icebike]

I've been thru this years ago with Suse. For a large shop it can be a bitch, best left to
when moving to a new server with the luxury of time. It was easily configurable
in SLES, and still is. In fact I still have some servers running the old uid ranges.
No actual use of uids above 500 by system accounts yet appears in most distros.

But for most systems, we just ran a script to chown the file system.

For a larger shop, I can see where this would be a problem.
The network file systems seem to be the biggest problem here, because the coordination
is a bitch. Then there all all the little uid/gid assignments that might be hard coded if your fstab
that lurk to haunt you.

Re:Am I the only one

[icebike]

Even THAT GUY trivializes the problem when you have a ton of users and or NFS shares that have to be
coordinated.

And god help you if things get out of hand and people start adding users to the new system before
you move all the old users over and you end up with a patchwork of numbers.

For Joe Random User's laptop, its just not a problem.

Re:Am I the only one

[swordgeek]

Now I'm not sure about the details of this. Will this actively prevent me from, as root, explicitly creating a user with whatever UID I want?

I assume (but am not sure) that I can force a uid when necessary, and this is only how users are added when the UID isn't explicitly given. Large shops almost always specify the UID, either through custom tools or by pushing a password file around. This won't affect them much.
(Assuming I'm correct in my understanding, of course)

Re:Am I the only one

[icebike]

Your assumption is correct as far as I know.
Other Distros that have converted to a 1000 base in the past, and it was not a problem to create a user using the old numbers, and usually just a minor setting somewhere to continue using the 500 base if you wanted to.

(I believe this is stored in /etc/login.defs in opensuse, might be somewhere else in Fedora.).

That being said, I'm guessing about just how Fedora may implement this. I assume they will follow the industry.

Re:Am I the only one

[Anonymous Coward]

Better?? That's actually the worse you can possibly do. It will execute "chmod" once for each entry reported by find. It will take *AGES* to complete. The alternative using xargs will accumulate arguments for chmod and reduce invocations dramatically.

Now, if in your commands above you replace \; by "+", that's a whole different story. In that case "find" alone behaves as "find | xargs" and whether or not that's "better" becomes an issue of personal preference.

Re:Am I the only one

[simcop2387]

However with xargs you can run into an issue with there being a limit on the number of arguments to a command. years gone by i think it was 32768 on linux it may be different or configurable now. I think xargs though has a way to tell it to limit the number of them and to run several in parallel also. I would also prefer the perl script method myself since you can handle all translations at once and not have to scan every file multiple times.

Re:Am I the only one

[Skapare]

Yes, the -h option on chown and chgrp is needed to do this right. Also, you'll need to use -print0 on find, and -0 or --null on xargs, to avoid being corrupted by odd file names, including file names with newline characters in them (technically valid).

Re:Am I the only one

[kasperd]

However with xargs you can run into an issue with there being a limit on the number of arguments to a command.

That is not an issue. xargs will run the command multiple times if necessary.

Re:Am I the only one

[SETIGuy]

Or even better.....

# sed 's/:1001:/:501:/' /etc/passwd >/etc/passwd.new
# cp /etc/passwd /etc/passwd.bak
# cp /etc/passwd.new /etc/passwd

One of benefits of linux is that you don't have live with the arbitrary stylistic decisions of the distro maintainers.

Re:This is progress in the Linux world?

[Z00L00K]

The UID:s are a minor issue for any well-seasoned *NIX admin.

But an evolution would be to convert to GUID:s, however that would make things really awkward in some cases and really break compatibility.

And RHEL

[Culture20]

I suppose RHEL will make the switch in RHEL9. At least I know to prepare...

Re:And RHEL

[Anonymous Coward]

At this rate, Fedoras 14 - 22 will be rolled into RHEL7.
RHEL6 is based on the word done in Fedoras 7 - 12/13.
RHEL5 was based on work up to FC6.

Re:This is progress in the Linux world?

[bsDaemon]

a "well-seasoned *NIX admin" isn't the target market for the "desktop" distributions, anyway.

Compatibility

[Per Wigren]

Why should this break backward compatibility? It surely won't modify existing users' IDs when upgrading, only when creating new users, most commonly (for home users) meaning on new installations only. I can't think of any real reasons this change should break anything.

Re:Compatibility

[Culture20]

They're probably planning on putting daemon users above 500. I feared such when they started encroaching into the 300s and 400s (forcing me to move my own custom daemon users).

Re:Compatibility

[bobaferret]

Not to mention the security implications of this. Tripwire, and I'm sure a number of other policy auditing systems, expect user accounts to start at 500, and do system wide permissions checking, and user_id -> service based auditing on this. Including running processes etc. This won't be too much of a pain to fix, but it will have to be fixed none the less. Oh well, C'est la vie.

Re:Compatibility

[Brian Feldman]

It is absolutely trivial to fix. You pick the first free UID over when grabbing a UID for a new service. There is no reason to hardcode a UID, ever.

Re:Compatibility

[Culture20]

It is absolutely trivial to fix. You pick the first free UID over when grabbing a UID for a new service. There is no reason to hardcode a UID, ever.

That's fine when you're using an existing system, but if you install a new OS, and suddenly discover that /etc/passwd already has entries in the 500's, you'll have some extra work chown'ing/chgrp'ing a bunch of user files on /home, /usr/people, etc. Not a huge issue, but it's something you have to keep in mind for Fedora16 now.

Re:Compatibility

[bobaferret]

NO, there's absolutely a way to deal with this, things are just going to have be changed is all. And that takes time and attention to detail. It's all part of the job, but it's one more thing none the less. SELinux is finally settled down, and now we've got systemd, and base UID changes, as we'll as virtualization and significantly heavier use of kernel cgroups. I'm just saying it's one more thing on the list to deal with in an already complicated and busy few years. The amount of effort required to go from RHEL4 to RHEL6 and still maintain PCI-DSS compliance and configuration standards is pretty rough at the moment. As Linux and the big distributions continue move away from traditional UNIX ways of doing things there are lot more potential ways to make mistakes, and far less people who understand the security implications, and where the pitfalls are.

Re:Compatibility

[bobaferret]

I agree, just takes time that's all. And I guess I've seen 500 as a fundamental constant in the universe, so when it get's changed I'm not really sure yet, what the ramifications could be.

Re:Compatibility

[jvillain]

How about all the UIDs and GIDs on back up tapes?

Any one who says this is all just trivial doesn't work with big enough systems. And when the auditors ask for the whole process to be documented?

This may need to be done. But if it does I am not sure we should stop at 1000. I wouldn't want to go through this again in 5 years.

Re:Compatibility

[SETIGuy]

I'm sitting at a networked Fedora 14 system. This NFS networking environment has been in continuous use since about 1987. The lowest active user number is in the 400s the highest is in the 9100s. We will not be changing user numbers. We will not use distributions that force us to change user numbers. We will not use utilities that force us to change user numbers. That will be all.

Re:Compatibility

[Per Wigren]

Just set the UID explicitly. If you are relying on which order your users are created in you have bigger problems. You aren't forced to anything.

Re:Compatibility

[Culture20]

Argh. I just updated a newly installed RHEL 6 box before updating /etc/password, shadow, group... A new daemon just started using GID 500. >:-(

Missed opportunity

[CharlyFoxtrot]

They should have started UID's at 9001 to make RedHat MEME compliant.

Re:Missed opportunity

[Rakshasa Taisab]

Yet how will this interoperate with the Japanese version of RedHat MEME when that starts at UID 8000?

Re:Missed opportunity

[VortexCortex]

Yet how will this interoperate with the Japanese version of RedHat MEME when that starts at UID 8000?

Well, actually, this will be fully compatible to the Japanese version; The docs state that compliant implementations start the UIDs at over 8000, which 9001 clearly is.

More trouble than that.

[pavon]

If you were to change a users UID, you would have to go through all the files in the system an update the UIDs as well. This is simple if all the drives are mounted at the time of the upgrade, and you want them all to be changed. However it becomes more of troublesome you have removable drives. Also, what if one of the mounted drives is a live backup; do you want to change the permissions on that or not. And you have to think about how you are going to handle restoring from a offsite backup with different UIDs. And if you have a networked file system, where all the computers on site share the same UIDs, it could become a real mess. Then there is the issue of config files that contain UIDs (like sudo users). It may be better to leave existing UIDs as they are, and just have new ones start at 1000.

Re:More trouble than that.

[Score Whore]

Don't forget the possibility that you may already have UID's of 1000 on your systems. So simply doing the find commands that several people have recommended is asking for some asshurt.

Re:More trouble than that.

[Brian Feldman]

Why the hell would you change a user's UID?

Re:More trouble than that.

[vlm]

Why the hell would you change a user's UID?

My suspicion is we're about to have a script unleashed upon us that whines when it sees files owned by UID inside a certain range anywhere but inside /home and /tmp, or a magic partition finder that finds /home by looking for uids in a certain range, or every file inside a certain UID range gets wiped out of /tmp with a different timeout than UIDs outside that range, or only files within a certain UID will be backed up (because its dumb to waste backup time and storage on /bin/ls, especially if it got haxored)

Re:More trouble than that.

[DaveV1.0]

Please tell me, when was the last time an upgrade changed the your normal user UIDs? Why would an upgrade do that?
 
Oh, and there are several ways to extract out the UID from the passwd file, reverse the list, then step through the list using each UID to do the "find exec" above.

Re:More trouble than that.

[Obfuscant]

Please tell me, when was the last time an upgrade changed the your normal user UIDs? Why would an upgrade do that?

He's talking about changing UIDs on existing users to move those below 500 up above 1000. An OS upgrade doesn't force that; changing the default UID numbering system does.

Oh, and there are several ways to extract out the UID from the passwd file, reverse the list, then step through the list using each UID to do the "find exec" above.

So you start by changing UID 500 to UID 1000, and then you get to your 500'th existing user who happens to have UID 1000. You happily find all the files belonging to UID 1000 and change them to 1500. Including the files that originally belonged to UID 500 that you changed to 1000 just a few minutes ago...

It doesn't even take having 500 users. If you've delegated user creation to different departments, say, and allocated them ranges of UID they are responsible for, then you might have one user at 500, one at 1000, one at 1500, etc...

The simple solution is, of course, to sort the changes you need to make and do the highest ones first. That way the UID 500 changes don't create files UID 1000 until after you've changed the 1000 to 1500.

This still leaves the issues brought up above. For the one about backups -- if you are doing something this drastic to the file system, you should back up before you do it, do it, and then do another backup.

Re:More trouble than that.

[SETIGuy]

That would be a good reason not to use those programs, or change distributions if you are forced to use them.

Re:More trouble than that.

[AvitarX]

I suspect you missed the purpose of reversing the list.

Re:More trouble than that.

[AvitarX]

use kdm and have that user not pictured.

Re:More trouble than that.

[DaveV1.0]

He's talking about changing UIDs on existing users to move those below 500 up above 1000. An OS upgrade doesn't force that; changing the default UID numbering system does.

First off, there will be no existing users if the system is a new install. Second, if the system is already installed, then it is an OS upgrade. Third, even if it is an upgrade with UIDs over 1000, there is no problem because the UID system takes the lowest AVAILABLE UID over the limit.
 
On a new system, the UIDs will start at 1000. On an upgraded system with the highest UID less than 1000, the next new user would be 1000. And, on a system with a UID over 1000, the next user would have a number equal to the highest current UID + 1. Really, I don't see any issue at all.

So you start by changing UID 500 to UID 1000, and then you get to your 500'th existing user who happens to have UID 1000. You happily find all the files belonging to UID 1000 and change them to 1500. Including the files that originally belonged to UID 500 that you changed to 1000 just a few minutes ago...

I am guessing you didn't really read my comment:

there are several ways to extract out the UID from the passwd file, reverse the list, then step through the list using each UID to do the "find exec"

I am not a UID!

[Anonymous Coward]

I am a free man!

Re:I am not a UID!

[Trashman]

You are unique and special, just like everyone else...

Re:This is progress in the Linux world?

[jedidiah]

What "problem" are you expecting the "n00b" to have with the status quo exactly?

Never mind where the "user" accounts start. There should be standardized values for application ids and those should be part of the LSB.

Re:Still no cure for time_t...

[armanox]

time_t is fixed for 64-bit systems. And for the 32-bit systems, well, we still have until 2038 to fix that problem.

Good for Samba/Windows interoperability

[mzilla]

Windows systems have all kinds of reserved rights for UIDs below 1000, so this is a good step as far as that's concerned. Is it a concession? I don't think so. It might be kind of a pain, but really how hard is the find command to search for and replace UIDs and GIDs on a system. Don't you do that sort of thing for fun anyway?

Re:Good for Samba/Windows interoperability

[tarius8105]

We use centrify express and the uid/gid conversion results in a number far higher than 1000. Its a good system if you start out that way but will be a pain when you change uid/gid schemes. I dont think its going to be a problem with a really good system administrator group because uid/gid combinations should have been standardized from the start for service accounts and users.

A script could do for mounted filesystems, but

[jabberw0k]

The only problem I see with writing a script that would simply recursively "chown" (change the ownership of) all files in descending uid-order, would be that unmounted filesystems, or remote filesystems, might complicate matters later.

Re:This is progress in the Linux world?

[bryan1945]

Just be happy they didn't decide to go on multiples of pi.

Re:Still no cure for time_t...

[kmdrtako]

2037? Why rush? It won't be a problem until 19 Jan 2038.

I'm sure we can wait at least until the 15th or the 16th to start working on a fix.

Re:Still no cure for time_t...

[idontgno]

time_t is fixed for 64-bit systems. And for the 32-bit systems, well, we still have until 2038 to migrate to 64-bit platforms. Or maybe 128-bit platforms.

FTFY.

LDAP and Kerberos

[vlm]

Since it only takes about 30 minutes to set up network wide single signon with LDAP and kerberos, even (especially?) at home, I'm not seeing this as having much impact. I use afs so I don't much care about the NFS/UID nightmare either.

I was recently thinking about this, and the last time I added a user to my LDAP and kerberos at home was when my daughter was born (figured she'd need it a couple years later, and in fact now she does). To add another user at home, not only would I have to look up again how the heck to do it, but I'd need to review all those "Now that you're expecting..." pregnancy books again.

This would have been a Big Deal in the mid 90s when I only had one box, but its not the mid 90s anymore...

Re:LDAP and Kerberos

[drinkypoo]

Since it only takes about 30 minutes to set up network wide single signon with LDAP and kerberos, even (especially?) at home, I'm not seeing this as having much impact. I use afs so I don't much care about the NFS/UID nightmare either.

The problem is, where do you put the database? I don't have any low-power machines reliable enough for the job. I suspect most people have even less :p

Re:LDAP and Kerberos

[discord5]

Since it only takes about 30 minutes to set up network wide single signon with LDAP and kerberos

Ah yes, I remember this particular book: "Setting up LDAP in 30 minutes". You'd expect it to be a technical manual, but it's actually a novella about a sysadmin who set up LDAP in 15 minutes. Driven by his passion for a single sign on solution and pressed for time he did a quick setup, and things were great. That is until he was supposed to link those userids back to e-mail accounts for the e-mail server, which coincidentally didn't support his particular LDAP layout.

"It's okay," he spoke, "I've still got 15 minutes to spare. In that time I'm sure I can read the manpages for sendmail, qmail and postfix and still have time to stroke my manly beard.".

And thus he read the manpages, setup his particular mailserver of choice properly, and stroked his manly beard. Now that every user could connect with SSH to the servers they needed to be on, mail was being delivered, and the manly beard was stroked his manager approached him.

"Hey, I was trying to access www.testyourmanagementskills.com, but I get this weird error saying Access Denied. I think the Internets are broken, I've never been denied access to the Internets before. Could you come have a look?"
"Sure thing, I'll be with you in a sec.", the sysadmin answered still enjoying the rough sensation of stroking his manly beard.

Sure enough, the squid proxy server was not configured yet to authenticate through the LDAP server and was now broken. "I'll be right back," the sysadmin told his manager, "I have to fix the internets". And sure enough, once the sysadmin had dug through the manpages of his clustered setup of squid proxy servers a few hours later everything was up and running smoothly except for those few glitches, but the url for testyourmanagementskills.com passed through the proxy logs so the most important part was taken care of.

"Time to stroke my manly beard again", the sysadmin thought, but before he had the chance to grab for his manly attribute he was quickly interrupted by the secretary who was trying to update the intranet. "I think the intranets are broken too," she complained in a nagging voice, "I was trying to upload pictures of kittens to improve the mood now that half of the IT stuff isn't working, but if the intranets are down I can't do that. FIX MY KITTENS!". Sure enough, the apache server running the intranet site hadn't loaded mod_ldap, hadn't set up in any other way than ye olde htpasswd password files, and sure enough some of the applications on the intranet site needed to be reprogrammed as well to handle the new and improved magnificent single sign on. Luckily for him the mod_ldap page explained pretty well what needed to be changed, so after a quick lunchbreak the apache server was up and running again (except for a few nasty PHP errors, but the kittens were back on the intranets, so who cares?)

"You know, " spoke the accountant, "I've got to hand it to you. You managed to fix a lot of stuff today that broke all of a sudden, but I still can't access the accounting excel sheets. I need to update the invoices and I just can't seem to do that.". Sure enough, the samba server hosting the accounting files wasn't configured for LDAP either. The sysadmin quickly went to work, and grabbed the samba documentation, and that is where the real problem began. You see, gentle reader, the documentation for samba isn't just a 3 page document saying "put this here, this here, and that there, and then /etc/init.d/smb restart" but a hefty document gently introducing you into the world of "domain controllers" and "shares" and the various quircks and oddities, such things as WINS servers and all that fun jazz. Oh, the original setup was never anything complicated, but a good LDAP setup for samba (or rather a good samba setup for LDAP) requires a bit of planning and care especially if you have a lot of users.

After reading through the various manuals and the small hand

Re:LDAP and Kerberos

[smash]

Although long-winded, the post has a point. Anyone who has ever tried to set up any sort of non-basic authentication on a unix box doing anything other than really basic desktop shit will have run into similar problems. Getting the OS to log you in using LDAP is the easy part. Getting all the related services to use LDAP (and doing a full audit before hand without missing anything to ensure that everything can be configured for LDAP) is not.

Maybe its simpler if you're starting out from scratch and have no network to manage a transition for, but if you have existing services to migrate - good luck!

Re:LDAP and Kerberos

[zpiro]

Don't ever switch filesystems, AFS locks you in for life!
AFS volume based backup *shudder*.

AFS is great as long as you don't need performance.
However, there is some interesting developments in AFS+OSD, but this is also mostly for those who painted themselves into a corner.
Personally I'd much rather "suffer" and use something like GlusterFS (which suffers in small file I/O), but not big files.
Only AFS and NFS does CacheFS.

Re:Still no cure for time_t...

[Kjella]

So it will be start being fixed around 2037...

Anything newer than an Atom N2xx or AMD since I dunno, Athlon 64? will run a 64 bit OS and so probably all future processors too. Even SoC systems probably have more than 4GB of RAM by then...

Re:ordering uids == fail

[Kjella]

if you're trying to order them and do something like if(uid>=magic) you need a trip to unix re-education camp.

Yep. It's trying to implement number magic instead of having user groups like local_users, remote_users, daemons etc. to determine what to show where. Welcome to poor design 101, I remember trying to add a ftp server to my box, reusing user and file system permissions is fine but every user I added also appeared on my login screen. They should be in an ftp_users group, nowhere else. But instead we'll use a UID that we can't easily change and can't belong to multiple groups, sigh...

Re:Still no cure for time_t...

[Z00L00K]

So either migrate to 64-bit (or a higher bit count) or perform a hack.

But I suspect that most systems will be 64-bit by then - if we still use computers.

!news

[Fujisawa Sensei]

How is this news at all?

Fedora and RedHat have had the ability to explicitly set UIDs and GIDs for years.

I've been explicitly starting UIDs at 1000 doing that since like 1998. Its not a big fucking deal, tripwire or otherwise.

And any distro that has a problem with non-system UIDs starting at 500 should be aborted as being hopelessly broken.

minor change really

[tarius8105]

This change doesnt really do anything important. It means that when you add a user without specifiying a uid it will default to the next available uid after 999. The only issue this will pose in a real environment is if there is no centralized account administration and sys admins are not paying attention. I honestly use centrify express, which uses arbitary high uid scheme, based off active directory (unfortunately a required to use it), which is something that can be configured for ldap/kerb setups too.

Re:A good step

[icebraining]

Actually a .deb is an 'ar' archive which contains a text file and two compressed 'tar' files.

Re:This is progress in the Linux world?

[Obfuscant]

a "well-seasoned *NIX admin" isn't the target market for the "desktop" distributions, anyway.

When one has to administer them, yes.

This solves nothing for the noob, since the system is assigning UIDs and unless you have just one user on each system, there is no guarantee that the UIDs for the same user will be the same between machines, unless you do them by hand. If you do them by hand, you can make them be whatever you want and this doesn't help.

This is still going to be a problem for me, since my UID for the last 20 years has been below 500 and I've always had to set mine on the desktops and servers I've installed, where the install script thinks it knows better than I do what my UID should be.

Re:A good step

[Mr. Jaggers]

Actually an .rpm is a binary with metadata headers and a 'cpio' archive which contains the files.

Re:This is progress in the Linux world?

[adolf]

Never mind where the "user" accounts start. There should be standardized values for application ids and those should be part of the LSB.

Why should I care what UIDs my applications run as?

8 bits are still around.

[tepples]

But I suspect that most systems will be 64-bit by then - if we still use computers.

Are most systems even PCs? Some embedded systems still use 8-bit microcontrollers for cost reasons over thirty years after the introduction of the MC68000 CPU, and I imagine that even thirty years into the future, there will still be countless embedded systems that use 32-bit ARM cores for cost reasons.

Re:8 bits are still around.

[batkiwi]

If you actually do some thinking you'll realize that's not completely true.

Most embedded systems are running 8 bit risc chips, but how many of them care about the current exact time, and how many of them run unix (which is the combo necessary for this to be unsurmountable).

32bit ARM chips are so low power and so cheap nowadays that I can easily imagine the crappiest embedded processor you can get in 10-15 years will be 4 core, have ~8mb of onboard program memory (as opposed to the 128kb I'm used to today), and be capable of handling 64 bit longs even if it's not 64bit native.

And draw next to no power.

Re:8 bits are still around.

[jandrese]

How many of those will care about the date though? My microwave doesn't give a crap what year it is.

Re:8 bits are still around.

[Man Eating Duck]

My microwave doesn't give a crap what year it is.

Reminds me of a particular scare story run by a Norwegian tabloid (Verdens Gang) some time during the y2k-bug craze with the following reasoning:

* Computers are vulnerable
* Even your waffle iron may contain a chip for temperature regulation, this is surely a kind of computer, right?
* YOUR WAFFLE IRON WILL STOP WORKING AT JANUARY 1ST 2000!!!111

Funny and sad at the same time. I actually sent an email to the journalist where I politely pointed out how ridiculous this was. His reply was basically that he didn't know the details, but had been assured of this by "a computer expert". I still wonder how that story came to be.

Re:Still no cure for time_t...

[Darinbob]

Depends if it's signed or unsigned 32-bit systems.

Re:Still no cure for time_t...

[Darinbob]

No, not all of them I think. We'll still have a need for smaller CPUs, and we'll still have a need for file systems with small overhead, and we'll still have archived files using older formats.

Re:Still no cure for time_t...

[armanox]

time_t is a signed int

Re:Still no cure for time_t...

[hey]

Do you really need a entire 64-bit OS to redefine time_t ?
I think its already defined as a long (on 32 bit systems).

Noobs and year of linux desktop

[morgauxo]

Why is this an issue? Unix admins ought to be able to handle this. Noobs shouldn't even care. Do they even know what a uid is? why?

Re:Still no cure for time_t...

[Darinbob]

True, but there are a LOT of systems out there that use "unsigned long" for "time_t", and some that use "unsigned long" without a typedef attached. They aren't Unix though.

Time is one of those complex issues that some people think is easy to solve. Ie, a solution that is great for file time stamps may be completely wrong for storing a patient's date of birth. Something that can handle patient ages may be inappropriate for archaeological or scientific use. You get something that's appropriate for archaeological use and it will be inappropriate for small file systems or task scheduling.

This is an almost-good idea, but could be better

[Lime Green Bowler]

The numbering should start with 1025.

You tore me away from Oprah's final show for this? Not for long...

Oh yeah?

[sootman]

MY distro goes to ELEVEN hundred. :-)

UIDs *used to be* 0-255, or even 0-127, PIDs 30K

[neurocutie]

such progress...

uid's used to be encoded in 8bits, 0-255 and some software would break with 128-255 being wrongly converted into a negative integer...

now we start at 1000... I guess it took a while to access the impact of PIDs going beyond 30000...

Re:ordering uids == fail

[greg1104]

uids on Debian derived systems start with 1000. If you build a system based on either RedHat or Debian standards right now, the uid numbers are going to be in a completely different range. This makes it even more annoying than usual to do things like create shared volumes where the file permissions are right, when mounted by two different servers running different distributions.

It's also a hassle on dual-boot systems, or ones where you converted from one distribution to the other, too. For example, last week I changed a RHEL server to run Debian. I had to go through 2TB of files and switch all of the UIDs over to the Debian standard for them, mapping user 500 -> 1000. Even though I could have just made the main account use the default RedHat range UID, that 500 number is technically reserved in Debian.

Small things, but definitely moving in the right direction as far as making Linux distributions less different from one another.

Re:Still no cure for time_t...

[rwa2]

Sorry, even 256-bit is passé

http://en.wikipedia.org/wiki/Transmeta_Crusoe

Compromise

[rwa2]

Hmm, now I'm left wondering what UID scheme Fuduntu uses.

Re:This is progress in the Linux world?

[jedidiah]

The same daemon might run on more than one machine and may need to be aware of more than just the local machine.

Generally, more determinism in a computer is a good thing.

Re:Still no cure for time_t...

[CarlosM7]

We'll be using primates!

Re:This is progress in the Linux world?

[adolf]

Doesn't /etc/passwd do an acceptable job of this?

Wonderful decision

[lsatenstein]

I dual boot systems, and I like my sudo user on Ubuntu to be the same number as my sudo user on Fedora. Before it was a manual procedure to create dummy user at 500, then a sudo user at 1000. Wonderful decision