Slashdot Mirror
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."
time_t is fixed for 64-bit systems. And for the 32-bit systems, well, we still have until 2038 to fix that problem.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Just be happy they didn't decide to go on multiples of pi.
Vote monkeys into Congress. They are cheaper and more trustworthy.
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)
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
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?
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
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.
Sig Battery depleted. Reverting to safe mode.
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!
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.