On 4/26/07, Brian Gupta <[EMAIL PROTECTED]> wrote:
That link sounds like what I want. But it is missing something.
When I said:
> The old methods with the old settings would still be supported, to maintain
binary
> compatibility. (using truncation in the event of a conflict. The first entry
in /etc/passwd
> that matched the truncated entry would match and return that UID).
I was referring to still supporting an 8byte L_Cuserid to maintain
backward compatibility. (This way applications would still be
backwards compatible by default) Only if it is recompiled to use the
"sysconf" setting would it allow the use of a longer user/groupid.)
-brian
From a practical standpoint, there are few problems that I have seen
in environments that have used 9-character usernames in production for
several years. To complicate matters, they were 9-digit numeric
usernames.
The problems in this environment boiled down to:
- Many commands that display tabular output (e.g. ps)
truncate the username field to 8 characters. This
makes using the default output of such commands
impractical. In the Solaris 2.6 days, columns of
ls(1) would run together.
- passwd(1) required the users to enter their username.
That is, "passwd" would not work but "passwd 123456789"
worked fine.
- Various sysadmin commands (e.g. useradd) enforce 8
character limits.
- Some commands mistakenly assumed that if the first
character of an id presented to it was a number,
that it should treat it as a uid, not a username.
This is really has nothing to do with long usernames
but was part of our problem set. It did have other
implications as shown below.
- "chown 123456789 file" sets the uid to 123456789. This
is a non-compliance with UNIX98 and later.[1][2]
- ClearCase initially worked, but an update applied in
2006 broke compatibility in one of the utilities.
IBM said they would not fix it.
- ar(1) can not store the username or uid (I forget which
it was)
- tar(1) may require special options. Again, I think
this is due to uid and not username
Aside from finding a single UNIX vendor that said that this was a good
idea, the thing that killed this user naming scheme was the breakage
of a key tool.
[1] See owner[:group] operand at
http://www.opengroup.org/onlinepubs/007908799/xcu/chown.html
If a numeric owner operand exists in the
user database as a user name, the user ID
number associated with that user name will
be used as the user ID.
[2] 6490974 fixed a bug that did away with getent(1)'s assuption that
if the first character was a number that a UID was presented. The
change appears to treat an all numeric operand as a UID and not a
username, which is just backwards from the behavior required of
chown(1).
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
