Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

SunOS to Linux Migration? 12

Posted by Cliff from the porting-your-system dept.
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?
This discussion has been archived. No new comments can be posted.

SunOS to Linux Migration? More

SunOS to Linux Migration?

Comments Filter:
  • 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.
  • 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.
  • /etc/passwd's are the same. Linux seems to use a few more fields in /etc/shadow (on Debian 2.1 compared to Solaris 7), but that should not be a problem.
  • I'm guessing you're referring to SunOS 5.x (Solaris 2.x/Solaris 7) here, rather than SunOS 4. To be pendantic, SunOS actually refers to the kernel, Solaris is the distribution, as it were.

    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.

  • Are the fields different? They appear to be identical between Solaris 2.6 and Redhat 6.0...

    But you're right about the encryption differences - I'd forgotten about that when I posted before.

    Does Slackware use PAM these days? I guess the differences you mentioned are down to the MD5 encryption scheme, which *could* be disabled (via /etc/pam.d/login) for compatibility.

    Security-wise, though, it would be better to keep it active and perhaps generate new passwords for each user. Cracking's an option, but then those users who've actually chosen secure passwords suffer, which is a bit unfair :-)

  • You realize; however, that by doing this, you defeat shadowed passwords. Shadowed passwords are a Good Thing TM. In answer to the poster's original question (as I've done this repeatedly with a userbase with over 1600 entries):

    (1) The file formats between Slackware and Solaris are identical, as is the encryption method used by crypt(3c).

    (2) By default, Slackware keeps its home directories in /home, whereas Solaris keeps them in /export/home. Solaris also keeps its mailspool in /var/mail, while Slackware keeps it in /var/spool/mail.

    (3) Slackware uses a BSD-like init-script system (rc.inet1, rc.serial, etc.) whereas Solaris uses a System V-style init-script system (/etc/rc2.d/S10foobar, /etc/rc3.d/S30httpd, etc.)

    (4) If you've got any custom C code (that runs setuid) that you're planning on using after the transition beware that, while SunOS 5 does not inherit effective UIDs after a fork(2), Linux does, so you have room for potential exploits and "can't happen"-style of mistakes.

    (5)As someone posted previously, SunOS and Linux both allow usernames with more than eight characters, but neither distribution (IE: Solaris or Slackware) makes very effective use of them. The user-management scripts with Slackware do tend to snag on larger usernames, but you can either modify the scripts or get new ones (look at http://www.unifiedportal.com/pub/ [unifiedportal.com] for the tools I wrote for my company. It's the first public beta and enuser is broken, so don't use enuser until beta 2 (due out sometime before Tuesday)). Other utils such as ps(1) and ls(1) show only the first eight characters. However, I do think that usernames under Linux are significant to their length (not just eight characters). Someone please correct me, if I'm wrong here.

    (6) By default Slackware ships a rather lax system, in terms of security (it's still my favourite Linux distribution, BTW). Be prepared to tighten things up a bit, kill off unnecessary daemons, and make sure that TCP wrappers (which are installed per default... Cool!) and /etc/securetty is set to your liking before putting the box online. But, really, you have to do this with any normal Unix setup, so it's not really anything unusual.

    (7) Slackware uses /etc/printcap instead of /etc/printers.conf, so your you'll have to redo any printing tweaks you did under Solaris in the older (but more standardized) printcap format (the man page is a great help).

    That's all I can think of for the moment. I hope this helped.


    The following sentence is true.
    The previous sentence is false.
  • >As long as the usernames are the same (for the salt) you should be fine.

    Ummm. No. I copy passwords to and from users all the time, and the username doesn't matter either... the first 2 bytes of the 13 character password are the salt....
    I'm going out on a limb here but, the salt is NOT derived from the username, that would be inherantly insecure. It must (should, at least) be randomly selected.

    /olle
  • Solaris _DOES_ support >8 character usernames. Only the first 8 characters are significant, however. There is space in the kernel to support up to 32 character unames, IIRC.

    Some utilities, however, do _not_ support it well. The finger command, for example. Also, a ps
    listing will only show the first 8 characters of
    the username.

    Essentially, it's OK To use longer names -- however, only the first 8 mean anything.
  • but the passwords will be a problem: they are encrypted, and as SunOS and Linux use different encryption schemes.
    Umm. No. I copy the encrypted fields back and forth verbatim all the time between Solaris box at work and my Debian distribution at home. As long as the usernames are the same (for the salt) you should be fine.

  • 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).

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Close