Slashdot Mirror
SunOS to Linux Migration?
phuzzie asks:
"I'm in the process of switching our server from a
single SunOS [intel] box to several Slackware Linux boxes.
However, I'm running into a couple snags. Namely the fact
that SunOS allowed us to have greater than 8 character
usernames, whereas Slackware doesn't. Does anyone know if
there is a way to make Linux use >8 char usernames? Also,
I need to know if the shadow crypt and the /etc/passwd are
the same between Linux and SunOS [ie do I have to re-enter
all of our 3000 users or can I just copy the files over?].
Any help anyone has to offer about any other issues dealing
with this sort of migration would also be greatly
appreciated." Are there any other Sun-to-Linux snags to
be wary of?
I've done this before when i changed a radius server on a solaris 2.5.1 machine to a redhat 5.x machine. This is really easy to do. Just write a script to copy /etc/passwd line by line and in the $2 field of the line(where the password is) do a sweep of /etc/shadow and get the encrypted password there. The passwords are the same, they all use the same password scheme, by getting the first 2 characters of the username and then going through something like this: .. 'z', 'A' .. 'Z', '0' .. '9', '.', '/');
@salt = ('a'
srand(time);
$enc = crypt($arg, $salt[int(rand(63))] . $salt[int(rand(63))]);
print $enc
As far as the usernames go, redhat will allow > 8 characters, its just the adduser program doesnt.
You shouldnt have a problem whatsoever.
I set up, and it is still in production use, a RedHat 5.0 box that has many users with 8-16 character usernames. I don't recall coming across any non-cosmetic (e.g. ls, ps) problems.
I would like to see official support for longer usernames. 8 character usernames are sometimes as painful as 8 character passwords.
It's perfectly possible, just not suggested. In particular, the username restriction is at the level of the scripts used to create users; there are many ways to get around this.
Take a look at the program you're running: is it a script, and in what language? If you know how to change it to either issue a warning rather than exit, or simply accept it, do so. If it's a compiled program, all I can say is "weird" -- what program are you using?
You can also copy stuff pell-mell -- I'm not sure about the compatibility of passwd and shadow, but you can at worst try. Try it out, and if it works, you've solved all your problems.
--Matthew
It seems like the password files are not identical, but that does not not mean that you have to re-enter all users. For most fields a small Perl or AWK script should be fine, but the passwords will be a problem: they are encrypted, and as SunOS and Linux use different encryption schemes. Your only chance is to crack them, otherwise all users must get new passwords.
Cracking them with a root account shouldnt be too difficult from a technical point of view, but I dont know where to find a program that cracks SunOS password files.
Anyway, Solaris does not support usernames of greater than 8 characters, although it may happen to work at times. In particular, try using useradd to add a user of more than 8 characters - it won't work. I also recall that even if you add users of more than 8 characters by editing the password/shadow file directly, problems can arise: I remember passwd crashing on me in this situation once.
In short, don't do it, on Solaris or Linux :-)
As far shadow file compatibility, yes, they should be fully compatible. I haven't verified this empirically, but according to the manual pages on Solaris 2.6 and Red Hat 6.0, the order and meaning of the shadow fields is identical.
I can't speak for Slackware, I don't use it, but I would imagine it uses the same shadow format as Red Hat.
There are solutions. Are the users aware of the migration, or is this going to be a stealth migration?
We did something similar (smaller scale) recently. We used a simple sed script that reset everyone's password to something simple and generic (used passwd to change one password to, say, "Okj*ij83rR", on the new machine and then copied the resulting gibbering into each password field). We then alerted each user individually (sealed envelope marked "confidential") informing them of their new "randomly generated password", and set the passwords to expire using the shadow passwd file. Next time each user logged in, they had to change their password to something of their own devising. Insecure, since everyone had the same interim password, but everyone thought the password had been randomly generated for them, so it wasn't that bad.
As an aside, someone mentioned that Linux and Solaris used difference versions of the crypt system call. Is this true? I was under the impression that they used the same algorithm. If they do use the same algorithm, you should be able to copy the passwd and shadow files directly (or at least use a simpler sed script if you have to reorder the entries). If they are different, and you can find out the algorithm Solaris uses, you can modify the Linux version to be identical to the Solaris version.
Also, we used the migration as an excuse to get people to change their passwords (we didn't have a password policy expiration then).
(darren)