Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Talking about system accounts...

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Talking about system accounts...
  • Date: Wed, 28 Jun 2006 21:28:42 +0200

Hi there...

I just had a test cast of mysql (verifying that it casts with
STAGED_INSTALL=off as opposed to without, apparently) fail because of
one isse that I'd like to see solved in a more consistent manner:

This line in BUILD:

create_account mysql

results in

useradd: UID 121 is not unique
The user id 121 already exists, so continuing...

and consequently:

chown: `mysql.mysql': invalid user
! Problem Detected !
! Problem Detected !
chown: `mysql.mysql': invalid user
INSTALL failed!

I remember having raised that topic before but know I wanna really nail
it down:
The system user account handling has to be improved - IMHO, of course.

I previously had issues with more basic accounts than mysql simply
because I didn't install from ISO. ISO cheats (or did so in the past)
by providing a /etc/passwd that fits the basic requirements like having
group tty 'n stuff.
That file doesn't (didn't) even need to agree with the accounts list
in grimoire...
Also, not every spell which needs special accounts does create them
(I'm sure there is at least one left;-), since the situation where this
account doesn't yet exist is too exotic.

Ideally, every spell needing it would call create_account and/or
create_group and all ist fine... but that doesn't work in my opening
example.
I remember that that case where I create some other user with an id
that is destined for mysql in grimoire is considered as "user messed up,
his fault" by some of you, but I disagree to this.

1. When smgl predefines account names and ids, but only creates them when
needed, it calls for the trouble, not the admin creating some account
with a free id that _may_ be occupied later by some spell.

2. There are situations where the user/admin not even has control over
all accounts / ids. This is the case with the box I casted mysql on,
It is my workstation in the network at ... work.
I am root there, but the box is embedded in the standard NIS + NFS
environment there, with some user ids being there since deep in last
century.
there are many NIS accounts with id<1000, some with id<500 - and _of
course_ there is someone with the id 121.
I think smgl should be flexible enough to handle that.

At least the part with the conflicting numerical ids should be easily
solvable.
Having the current experience in mind, I opt not for a fully predefined
/etc/passwd what would be logical when we predefine all ids anyway
(IMHO), but for simply _not_ defining the ids.
The create_account and create_group functions should be smart enough to
search a valid free id for themselves.

But before I start hacking anything in that direction, I want some
agreement on how we really want it to be.

Some ideas that come to my mind:

1. It should be configurable what range of ids is to be included as
candidates for system accounts.
2. The functions should _fail_ if they cannot find one (current behaviour
with unavailable id assumes that user id 121 existing means mysql user
existing, which is _wrong_).
3. The functions should rather check if the _name_ is already there,
but possibly still fail (or at least warn) if corresponding id is out
of specified system id range.
4. It should still be possible to predefine the ids, p.ex. if one wants
the same setup of user ids on a range of machines - simplest realization
could be just copying a passwd/group with all needed accounts defined...

I'd even volunteer to code that stuff myself (as I seem to be the one
having the hardest headache with current solution;-), but as I said,
some discussion on what is needed and sensible ... is needed and a
sensible thing to do first.

So, please:

Input, anyone?


Thomas.

Attachment: pgptVdSf5b5RJ.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page