[Neurodebian-devel] condor fails to install if condor user already exists

[Tiziano Zito]

Hi!

On Sat 11 Aug, 20:59, Michael Hanke wrote:
> Regarding the actual bug. This issue came up in the early days of this
> packaging. It essentially happens mostly for people upgrading from
> existing Condor deployments. While I can't say much about the necessity
> to have a Condor user in LDAP. I'm pretty sure that the Debian packages
> cannot work with a non-system user. There are all kinds of problems, but
> one of them is that the package can't assume that any user named
> 'condor' is also one that is available for Condor's operations. If a
> normal user 'condor' exists, IMHO failing is the only option. Otherwise
> that user would have access to Condor's runtime data (job payload, ...),
> but we would not know whether there is an actual (human) 'condor' user.
> 
> The system user that the condor package creates is a dedicated one -- no
> login, no shell access.
> 

I think the current behaviour deviates from upstream in a significant and
gratuitous way, making it much harder to deploy on top of an
existing condor installation. And, it makes harder or impossible to
use a perfectly valid configuration.

The condor installation manual in chapter 3.2.2
<http://research.cs.wisc.edu/condor/manual/v7.8/3_2Installation.html#SECTION00422000000000000000>
states that:

"""
5. Will you have a Unix user named condor, and will its home directory be shared?

    To simplify installation of Condor, create a Unix user named condor on all
machines in the pool. The Condor daemons will create files (such as the log
files) owned by this user, and the home directory can be used to specify the
location of files and directories needed by Condor. The home directory of this
user can either be shared among all machines in your pool, or could be a
separate home directory on the local partition of each machine. Both approaches
have advantages and disadvantages. Having the directories centralized can make
administration easier, but also concentrates the resource usage such that you
potentially need a lot of space for a single shared home directory. See the
section below on machine-specific directories for more details.

    Note that the user condor must not be an account into which a person can
log in. If a person can log in as user condor, it permits a major security
breach, in that the user condor could submit jobs that run as any other user,
providing complete access to the user's data by the jobs. A standard way of not
allowing log in to an account on Unix platforms is to enter an invalid shell in
the password file.

    If you choose not to create a user named condor, then you must specify
either via the CONDOR_IDS environment variable or the CONDOR_IDS config file
setting which uid.gid pair should be used for the ownership of various Condor
files. See section 3.6.13 on UIDs in Condor on page [*] in the Administrator's
Manual for details. 
"""

The only requirement is that there is a user condor on all machines.
If the condor user's home directory is to be shared, which is a
perfectly valid configuration, the user account creation procedure
in the debian package is not going to work, because the probability
of getting the same uid and gid on all nodes are pretty low. NFS
sharing of the home directory becomes impossible.  For security
reasons it is important that the condor user does not correspond to
someone who can log in, which has nothing to do with the user uid
being < 1000 (which is the default in adduser.conf for "system"
accounts). 

> If you see a way that is both secure and satisfies your needs, please
> let me know. Otherwise, I think Evgeni is right: move 'condor' out of
> LDAP and solve email issues with alternative means.

I think that in condor.postinst the call to adduser should be
followed by a check: 

1. if adduser failed, i.e. there is already a
   condor user and it is not a "system" account, then prompt the user
   to ask if they really want to use the existing account.
1a. if they want to use it, everything is fine
1b. if not, fail

> For now I am downgrading this bug to 'wishlist' and tag it with
> 'wontfix' until a more viable solution is found.

Well, I think that "wishlist" is a bit unfair, given that it breaks on
upgrade and makes it impossible to use the debian package on a
cluster where other condor clients are not debian systems and use
the valid configuration of sharing home with NFS and non-system
condor account.

Ciao,
Tiziano