[Freeipa-devel] command-line arguments

[Karl MacMillan]

On Fri, 2007-09-07 at 11:27 -0400, Simo Sorce wrote:
> On Fri, 2007-09-07 at 11:11 -0400, Andrew C. Dingman wrote:
> > On Fri, 2007-09-07 at 10:49 -0400, Simo Sorce wrote:
> > > Usually uidNumbers may have to be set for system accounts, but for user
> > > accounts??
> > 
> > In an ideal world, no. In the real world, it can smooth things out just
> > often enough that I wouldn't want the ability to go away. I wouldn't
> > mind if it were a bit of a pain, though, 'cause even in a large
> > environment it's a rare occurrence. Personally, as long as I can safely
> > make the change with ldapmodify on the new user and group, I don't feel
> > a need for a specific UI. If it's more complicated than that to pull
> > off, I do.
> 
> ldapmodify will do it, so I vote for not letting the admin specify the
> uidNumber in the current tools.
> 

But it would be nice to be able to specify it via xml-rpc for conversion
tools.

> > > And this opens another debate, should we have system services accounts
> > > in IPA?
> > > IMO no, for v1 at least they should stay local in /etc/passwd as
> > > unfortunately they are not at all standardized on all platforms and
> > > linux flavors.
> > 
> > Sounds reasonable to start with. System accounts aren't even the same
> > across an all-RHEL site, since some packages add their own.
> > 
> > There's an argument to be made that putting 'root' in the directory is a
> > good thing, since it lets you leave the account passwordless on the
> > local systems. That's nice if you have an admin leave and need to change
> > the password everywhere.
> 
> It makes it also impossible to take the system out or to log in when the
> network is down for system maintenance. Until we have offline support I
> would not do this.

Agreed.

> Also having a single per-site password, would make it for a very bad
> situation when the password is compromised (you have access as root on
> _all_ the machines at that point).
> Also it make it impossible for users to join the machine and keep
> themselves control on it. In some enterprises that is not wanted but in
> many R&D departments that's a necessity.
> 

Having the ability to grant administrative rights to normal users will
help this situation (and also argues for pushing this to v2).

Karl