The installation program has a nice feature. When you arrive at the screen where you enter a user into the to be installed system and when the installer detected an other system (I am not sure if only openSUSE or more), then below the fields where you can enter the credentials of the new user, you can choose for importing user definitions from that old system. When you do so, you are offered a list of the non system users on the old system and can choose from them which ones of them (or all) you want to copy.
This is a very nice feature when you do a new installation over, or beside an old one, where you want to keep the /home partition. In the new system all users will be present, with the correct UID (thus they will be the onwers of the corect home directories, etc.) and their old passwords. Very helpful to the system manager.
I use this feature for years, but this time (and I can not remember the same behaviour in earlier installations of new over old) all users got the primary GID 100 (which is ‘users’ on a default installation) in /etc/passwd. In my case there was one user that should have 100, but two other users belonging to a different group. Also that GID was not copied to /etc/group.
The tricky thing is that when you do not detect this, your might run into problems with those users, because there is no warning given.
Are you importing the users from 13.1 ? If so, compare the old /etc/group to the new one. My bet is there will be differences. I’ve never seen this fail, but whenever I did this, users were imported from max 1 version before.
Could be, but the logic of /etc/passwd, /etc/shadow and /etc/group did not change for years IMHO. Thus what once worked should do it still.
But you are right, the fact that it is a big version jump would make it easy for a bug report to become rejected.
When you say it worked for you while having different primary groups for your users, I will consider my case as exceptional an just keep it in my mind for the next time (may be long in the future as I nowadays do online updates to new versions).
Well, it does not import everything, i.e. non-default groups. F.e. firebird group is created by the install of the firebird server packages. And the firebird group had a different GID in the past.
I understand that. I understand also that it is not obvious how to handle all those groups. But as I said, as far as I can remember the group used by those users was taken over. But I have of course no evidence.
I like the feature, but accept that to make it perfect is a asked too much and maybe impossible and/or outide the scope of an installation program that should fit beginners, but it could give a message that it did change the copied /etc/passwd entries because “to difficult”.
zypper se system-user* system-group*
S | Name | Summary | Type
--+------------------------+-------------------------------------+-----------
i | system-group-hardware | Hardware related system groups | package
| system-group-obsolete | Obsolete system groups | package
i | system-group-wheel | System group 'wheel' | package
i | system-user-bin | System user and group 'bin' | package
i | system-user-daemon | System user and group 'daemon' | package
| system-user-ftp | System user and group ftp | package
| system-user-games | System user and group games | package
i | system-user-lp | System user lp | package
i | system-user-mail | System user and group mail | package
i | system-user-man | System user and group 'man' | package
| system-user-news | System user and group 'news' | package
i | system-user-nobody | System user and group nobody | package
i | system-user-root | System user and group root | package
i | system-user-srvGeoClue | System user for the geoclue service | package
| system-user-upsd | System user upsd | package
| system-user-uucp | System user and group uucp | package
| system-user-uuidd | System user and group uuidd | package
| system-user-wwwrun | System user wwwrun and group www | package
As said, I can understand why it is done, but I would like a message that will trigger the installer to look into it and repair things to her/his satisfaction.
However, my users (that I import) all use group 100. One of the users is also in group 1001. But I handle that entirely in “/etc/groups”, and I have to make that change manually after the install (I use “vipw -g” for that).
I’m guessing that what you are seeing is a feature, not a bug. It is probably scrubbing the imported entries to make sure that they only use groups that already exist.
As said, I understand that, but the administrator will have no knowledge about the restrictions and limitations. And no message. In the end security could be compromised when this is not seen by the administrator.
Looking at the Perl file ‘/usr/share/YaST2/modules/Users.pm’ there’s sections beginning at “set the list of users to be imported during installation”.
Looking at that code, it seems that, only users are being considered – despite “groups” being a part of “installation_import” – need the complete installation code to decipher what’s going on here.
I think that confirms what we think. It is a nice feature, but not implemented in all it’s consequences.
Let us be thankful to the one that made it available. It spares a lot of work and the bits that are left to do can be done easy. The only thing being that you have to know about it.