Debian Bug report logs - #684463
condor fails to install if condor user already exists

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: condor fails to install if condor user already exists

Date: Fri, 10 Aug 2012 10:30:36 +0200

Package: condor
Version: 7.8.1~dfsg.1-1~nd12.04+1
Severity: grave
Justification: renders package unusable

Hi!

when I try to install condor on a machine where the condor user already exists (either
because the machine uses LDAP authentication and condor user is in
LDAP or because I am just re-installing or upgrading condor), the
configuration step fails with:

Setting up condor (7.8.1~dfsg.1-1~nd60+1) ...
adduser: The user `condor' already exists. Exiting.
dpkg: error processing condor (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
Errors were encountered while processing:
 condor
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up condor (7.8.1~dfsg.1-1~nd60+1) ...
adduser: The user `condor' already exists. Exiting.
dpkg: error processing condor (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 condor

I am somehow unsure what is happening, because I have this also on a
machine where condor is already installed and working, but:

hamxxx ~ # dpkg-reconfigure condor
/usr/sbin/dpkg-reconfigure: condor is broken or not fully installed
hamxxx ~ # condor_q
-- Submitter: hamxxx : <172.29.xxx.xxx:40590> : hamxxx
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
2586.0   xxxxxxx         8/9  15:50   0+05:36:39 R  0   43.9 bash_lc_var_5 2586
2586.1   xxxxxxx         8/9  15:50   0+05:36:39 R  0   43.9 bash_lc_var_5 2586
[...]

this happens on squeeze, wheezy and ubuntu precise...

am I doing something wrong?

thank you,
tiziano

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-27-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages condor depends on:
ii  adduser                         3.113ubuntu2
ii  debconf [debconf-2.0]           1.5.42ubuntu1
ii  libc6                           2.15-0ubuntu10
ii  libclassad3                     7.8.1~dfsg.1-1~nd12.04+1
ii  libcomerr2                      1.42-1ubuntu2
ii  libcurl3                        7.22.0-3ubuntu4
ii  libdate-manip-perl              6.25-1
ii  libexpat1                       2.0.1-7.2ubuntu1
ii  libgcc1                         1:4.6.3-1ubuntu5
ii  libglobus-common0               14.5-1
ii  libglobus-ftp-control1          4.2-1
ii  libglobus-gass-transfer2        7.1-1
ii  libglobus-gram-client3          12.3-2
ii  libglobus-gsi-credential1       5.1-1
ii  libglobus-gsi-proxy-core0       6.1-1
ii  libglobus-gsi-sysconfig1        5.1-1
ii  libglobus-gss-assist3           8.1-1
ii  libglobus-gssapi-gsi4           10.2-1
ii  libglobus-io3                   9.2-1
ii  libglobus-rsl2                  9.1-2
ii  libglobus-xio0                  3.2-1
ii  libgsoap1                       2.8.4-2
ii  libk5crypto3                    1.10+dfsg~beta1-2ubuntu0.3
ii  libkrb5-3                       1.10+dfsg~beta1-2ubuntu0.3
ii  libldap-2.4-2                   2.4.28-1.1ubuntu4.1
ii  libpcre3                        8.12-4
ii  libssl1.0.0                     1.0.1-4ubuntu5.3
ii  libstdc++6                      4.6.3-1ubuntu5
ii  libuuid1                        2.20.1-1ubuntu3
ii  libvirt0                        0.9.8-2ubuntu17.3
ii  neurodebian-popularity-contest  0.28~nd12.04+1
ii  perl                            5.14.2-6ubuntu2
ii  python                          2.7.3-0ubuntu2

Versions of packages condor recommends:
ii  dmtcp  1.2.5-1~nd12.04+1

Versions of packages condor suggests:
pn  coop-computing-tools  <none>

-- debconf information excluded

Message #10 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>, 684463@bugs.debian.org

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Fri, 10 Aug 2012 17:41:21 +0200

Hi,

On Fri, Aug 10, 2012 at 10:30:36AM +0200, Tiziano Zito wrote:
> Package: condor
> Version: 7.8.1~dfsg.1-1~nd12.04+1

Where does this version come from?
Debian has 7.8.1~dfsg.1-2 in Wheezy and Sid.

> when I try to install condor on a machine where the condor user already exists (either
> because the machine uses LDAP authentication and condor user is in
> LDAP or because I am just re-installing or upgrading condor), the
> configuration step fails with:
> 
> Setting up condor (7.8.1~dfsg.1-1~nd60+1) ...
> adduser: The user `condor' already exists. Exiting.
> dpkg: error processing condor (--configure):
>  subprocess installed post-installation script returned error exit status 1

This does not happen with 7.8.1~dfsg.1-2 on my machine.
The user is created once and then adduser silently ignores the calls 
because of the --system switch.

> this happens on squeeze, wheezy and ubuntu precise...

Squeeze and Precise do not even have a condor package...

I would close the bug as non-existing, but awaiting your reply first.

Regards
Evgeni

Message #15 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>, 684463@bugs.debian.org

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Fri, 10 Aug 2012 17:51:29 +0200

On Fri, Aug 10, 2012 at 05:41:21PM +0200, Evgeni Golov wrote:
> Hi,
> 
> On Fri, Aug 10, 2012 at 10:30:36AM +0200, Tiziano Zito wrote:
> > Package: condor
> > Version: 7.8.1~dfsg.1-1~nd12.04+1
> 
> Where does this version come from?
> Debian has 7.8.1~dfsg.1-2 in Wheezy and Sid.

It seems to come from http://neuro.debian.net and to be a backport of 
7.8.1~dfsg.1-1.
It has the very same postinst script as the Debian version and it should 
really not fail. Unless the user is not a system user.

Is your condor user a regular LDAP user?

-- 
Bruce Schneier can read and understand Perl programs.

Message #20 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: Evgeni Golov <evgeni@debian.org>

Cc: 684463@bugs.debian.org

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Fri, 10 Aug 2012 20:07:28 +0200

> > > Package: condor
> > > Version: 7.8.1~dfsg.1-1~nd12.04+1
> > 
> > Where does this version come from?
> > Debian has 7.8.1~dfsg.1-2 in Wheezy and Sid.
> 
> It seems to come from http://neuro.debian.net and to be a backport of 
> 7.8.1~dfsg.1-1.

Sorry for not mentioning it, I quickly checked on two different
machines, but both were using the neuro.debian repos... 

> It has the very same postinst script as the Debian version and it should 
> really not fail. Unless the user is not a system user.
> 
> Is your condor user a regular LDAP user?

Yes, it has  UID > 1000 as suggested by pam_ldap. Why should the
condor user be a "system" user? for one, it requires a valid email
address if you want email sent by condor not being tagged as SPAM by
overzealous SPAM filters. And if you use LDAP for authentication you
typically use it for email too, so the condor user naturally fits as
a non-system LDAP user. Couldn't this check be lifted altogether, or
at least give the possibility to set UID and GID of the condor user
on installation? 

Thank you for your quick reply!

Tiziano

Message #25 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>

Cc: 684463@bugs.debian.org

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Fri, 10 Aug 2012 20:36:09 +0200

Hi,

On Fri, Aug 10, 2012 at 08:07:28PM +0200, Tiziano Zito wrote:
> > > > Package: condor
> > > > Version: 7.8.1~dfsg.1-1~nd12.04+1
> > > 
> > > Where does this version come from?
> > > Debian has 7.8.1~dfsg.1-2 in Wheezy and Sid.
> > 
> > It seems to come from http://neuro.debian.net and to be a backport of 
> > 7.8.1~dfsg.1-1.
> 
> Sorry for not mentioning it, I quickly checked on two different
> machines, but both were using the neuro.debian repos... 

About which you theoreticaly should not fill bugs into the Debian BTS, 
as these aren't Debian packages. But given these are rebuilds only, lets 
see what we can do for you :)
[ condor maintainer might disagree here ]

> > It has the very same postinst script as the Debian version and it should 
> > really not fail. Unless the user is not a system user.
> > 
> > Is your condor user a regular LDAP user?
> 
> Yes, it has  UID > 1000 as suggested by pam_ldap. Why should the
> condor user be a "system" user? for one, it requires a valid email
> address if you want email sent by condor not being tagged as SPAM by
> overzealous SPAM filters. And if you use LDAP for authentication you
> typically use it for email too, so the condor user naturally fits as
> a non-system LDAP user. Couldn't this check be lifted altogether, or
> at least give the possibility to set UID and GID of the condor user
> on installation? 

Well, users created for packages should be created as system users.
No idea how the fact of being a system user might play into your spam 
issue.
I have little clue about LDAP and no clue about condor (just stumbled 
over the bug while RC-bughunting), but I would say you should not have a 
condor user in your LDAP and let it be a lonely local user created by 
adduser.
If you want condor@host to work, add an alias or something.

However, these are my two cheap cents, maintainers might disagree here.

-- 
Bruce Schneier can read and understand Perl programs.

Message #30 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>

Cc: neurodebian-devel@lists.alioth.debian.org, 684463@bugs.debian.org

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

Date: Sat, 11 Aug 2012 20:59:48 +0200

severity 684463 wishlist
tag 684463 wontfix
thanks


Hi Tiziano,

[Debian bug is in CC]

On Fri, Aug 10, 2012 at 08:42:17PM +0200, Tiziano Zito wrote:
> I mistakenly posted a bug report about condor on debian BTS
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684463> which
> should have been posted here. Should I ask to close the bug and keep
> on discussing here?

First of all: I consider it appropriate to file bugs like this in the
Debian BTS. NeuroDebian binary packages are unmodified rebuilds and I
upload binaries built from the same source packages to Debian proper
also.

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.

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.

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

Best,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Message #39 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: neurodebian-devel@lists.alioth.debian.org, 684463@bugs.debian.org

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

Date: Mon, 13 Aug 2012 12:28:17 +0200

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

Message #44 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>

Cc: neurodebian-devel@lists.alioth.debian.org, 684463@bugs.debian.org

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

Date: Mon, 13 Aug 2012 14:02:54 +0200

severity 684463 normal
tag 684463 - wontfix
thanks

On Mon, Aug 13, 2012 at 12:28:17PM +0200, Tiziano Zito wrote:
> > 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

This seems good at first glance. However, it is a bit tricky to
implement, because of the way the debconf interface works. Essentially
the postinst script (with the failing adduser call) runs last and it seems
quite cumbersome to implement what you suggesti, as it would need to be
done in the config script.

Maybe it could be:

1. Add a low-priority debconf question whether to use a non-system account
   named 'condor' if one is available.

   [I18N won't be happy about adding a template so late in the release
    cycle and I'm not sure whether we can get such change into the
    frozen wheezy]

2. Check the choice from (1) if adduser --system fails in the postinst
   and act accordingly.


However, it would be much nicer if we could find a way to deal with this
scenario without having to use debconf. Maybe we could try to check the
validity of the requirements: there is a 'condor' user and it can't be
used to log in. If there is a reliable way to verify this in the case
that adduser --system fails (and the user comes from LDAP, or whatever
other possible auth method), we could maybe issue a warning message and
proceed without manual approval. Opinions?


> > 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.

;-) you're arguments are valid, so let it be a 'normal' bug that needs
fixing...

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Message #53 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: neurodebian-devel@lists.alioth.debian.org, 684463@bugs.debian.org

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

Date: Mon, 13 Aug 2012 14:18:11 +0200

> severity 684463 normal

thank you!

> However, it would be much nicer if we could find a way to deal with this
> scenario without having to use debconf. Maybe we could try to check the
> validity of the requirements: there is a 'condor' user and it can't be
> used to log in. If there is a reliable way to verify this in the case
> that adduser --system fails (and the user comes from LDAP, or whatever
> other possible auth method), we could maybe issue a warning message and
> proceed without manual approval. Opinions?

What about this in condor.postinst::

SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
   # condor user exists and it is a locked user 
else
   adduser --system ...
fi

getent gets is info from the nss libraries, so it is independent of
auth method.

So no need to use new dpkg questions. Could this warrant a freeze
exception?

Ciao,
Tiziano

Message #58 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Jaime Frey <jfrey@cs.wisc.edu>

To: Michael Hanke <mih@debian.org>, 684463@bugs.debian.org

Cc: Tiziano Zito <opossumnano@gmail.com>, neurodebian-devel@lists.alioth.debian.org

Subject: Re: [condor-debian] Bug#684463: [Neurodebian-devel] condor fails to install if condor user already exists

Date: Mon, 13 Aug 2012 11:20:27 -0500

On Aug 13, 2012, at 7:02 AM, Michael Hanke wrote:

> On Mon, Aug 13, 2012 at 12:28:17PM +0200, Tiziano Zito wrote:
>>> 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
> 
> This seems good at first glance. However, it is a bit tricky to
> implement, because of the way the debconf interface works. Essentially
> the postinst script (with the failing adduser call) runs last and it seems
> quite cumbersome to implement what you suggesti, as it would need to be
> done in the config script.
> 
> Maybe it could be:
> 
> 1. Add a low-priority debconf question whether to use a non-system account
>   named 'condor' if one is available.
> 
>   [I18N won't be happy about adding a template so late in the release
>    cycle and I'm not sure whether we can get such change into the
>    frozen wheezy]
> 
> 2. Check the choice from (1) if adduser --system fails in the postinst
>   and act accordingly.
> 
> 
> However, it would be much nicer if we could find a way to deal with this
> scenario without having to use debconf. Maybe we could try to check the
> validity of the requirements: there is a 'condor' user and it can't be
> used to log in. If there is a reliable way to verify this in the case
> that adduser --system fails (and the user comes from LDAP, or whatever
> other possible auth method), we could maybe issue a warning message and
> proceed without manual approval. Opinions?


I like the idea of allowing the use of an existing 'condor' account that we can reasonably verify can't be logged into. I presume the packaging would have to remember that it didn't create the account, so that it leaves the account in place on uninstall.

Thanks and regards,
Jaime Frey
UW-Madison Condor Team

Message #63 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Jaime Frey <jfrey@cs.wisc.edu>

Cc: 684463@bugs.debian.org, Tiziano Zito <opossumnano@gmail.com>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Tue, 14 Aug 2012 09:18:27 +0200

[dropping the mailing list]

On Mon, Aug 13, 2012 at 11:20:27AM -0500, Jaime Frey wrote:
> I like the idea of allowing the use of an existing 'condor' account
> that we can reasonably verify can't be logged into. I presume the
> packaging would have to remember that it didn't create the account, so
> that it leaves the account in place on uninstall.

Debian packages typically do not remove user they created. It is not
very robust (files might be left behind with invalid UIDs ...). What is
typically done, is to lock down a system user when the package is
removed. In Condor's case this is not necessary, as the user is already
locked down from the very beginning.

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Message #68 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>, 684463@bugs.debian.org

Subject: Re: Bug#684463: [Neurodebian-devel] condor fails to install if condor user already exists

Date: Tue, 14 Aug 2012 09:18:36 +0200

On Mon, Aug 13, 2012 at 02:18:11PM +0200, Tiziano Zito wrote:
> What about this in condor.postinst::
> 
> SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
> if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
>    # condor user exists and it is a locked user 
> else
>    adduser --system ...
> fi

I'd like to turn this around: First run adduser and only if it fails
check for an existing condor user and issue a warning if it exists _and_
is locked down _and_ the package will use it as a daemon user. Otherwise fail.

The code above would result in a warning message on every upgrade,
even when the package did successfully create a system user itself.

Objections?

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de

Message #73 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>, 684463@bugs.debian.org

Cc: Jaime Frey <jfrey@cs.wisc.edu>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Tue, 14 Aug 2012 09:23:21 +0200

On Tue, Aug 14, 2012 at 09:18:36AM +0200, Michael Hanke wrote:
> On Mon, Aug 13, 2012 at 02:18:11PM +0200, Tiziano Zito wrote:
> > What about this in condor.postinst::
> > 
> > SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
> > if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
> >    # condor user exists and it is a locked user 
> > else
> >    adduser --system ...
> > fi
> 
> I'd like to turn this around: First run adduser and only if it fails
> check for an existing condor user and issue a warning if it exists _and_
> is locked down _and_ the package will use it as a daemon user. Otherwise fail.
> 
> The code above would result in a warning message on every upgrade,
> even when the package did successfully create a system user itself.

So here is a proposal how to deal with this. Please let me know, if
you anticipate problems with this approach:

diff --git a/debian/condor.postinst b/debian/condor.postinst
index 91ac8a5..0156b7c 100755
--- a/debian/condor.postinst
+++ b/debian/condor.postinst
@@ -164,8 +164,24 @@ case "$1" in
     configure)
         # according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833#119
         # this should always work
-        adduser --system --group --gecos "$condor_gecos" --home $condor_home \
-                --disabled-password --disabled-login $condor_user --quiet
+        if ! adduser --system --group --gecos "$condor_gecos" --home $condor_home \
+                --disabled-password --disabled-login $condor_user --quiet ; then
+            # the only time where it would fail, is when there is an existing
+            # non-system 'condor' user. This could happen e.g. in a heterogenous
+            # Condor pool (various OSes) where the adminstrative Condor user
+            # comes from LDAP and the home dir is shared across machines. This
+            # is a supported deployment scenario for Condor (see installation
+            # manual section 3.2)
+            # the only problem is the possibility to conflict with an actual
+            # "human" user with the same name, so only proceed when the
+            # respective user is locked down
+            SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
+            if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
+                echo "WARNING: Condor will be running under an existing non-system user account 'condor'."
+            else
+                exit 1
+            fi
+        fi
         # make sure the config and home dir are complete
         condor_local_cfg_template
         condor_put_debconf_cfg



Thanks

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Message #80 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: Michael Hanke <mih@debian.org>

Cc: 684463@bugs.debian.org, Jaime Frey <jfrey@cs.wisc.edu>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Tue, 14 Aug 2012 10:30:00 +0200

> diff --git a/debian/condor.postinst b/debian/condor.postinst
> index 91ac8a5..0156b7c 100755
> --- a/debian/condor.postinst
> +++ b/debian/condor.postinst
> @@ -164,8 +164,24 @@ case "$1" in
>      configure)
>          # according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833#119
>          # this should always work
> -        adduser --system --group --gecos "$condor_gecos" --home $condor_home \
> -                --disabled-password --disabled-login $condor_user --quiet
> +        if ! adduser --system --group --gecos "$condor_gecos" --home $condor_home \
> +                --disabled-password --disabled-login $condor_user --quiet ; then
> +            # the only time where it would fail, is when there is an existing
> +            # non-system 'condor' user. This could happen e.g. in a heterogenous
> +            # Condor pool (various OSes) where the adminstrative Condor user
> +            # comes from LDAP and the home dir is shared across machines. This
> +            # is a supported deployment scenario for Condor (see installation
> +            # manual section 3.2)
> +            # the only problem is the possibility to conflict with an actual
> +            # "human" user with the same name, so only proceed when the
> +            # respective user is locked down
> +            SH=$(getent passwd | egrep '^condor:'| cut -d : -f 7)
> +            if [ "$SH" = "/bin/false" -o "$SH" = "/usr/sbin/nologin" ]; then
> +                echo "WARNING: Condor will be running under an existing non-system user account 'condor'."
> +            else
> +                exit 1
> +            fi
> +        fi

This seems OK to me. One last thing may be that instead of 'exit 1'
you could have:

echo "ERROR: Condor can not run under unlocked non-system account 'condor'" 1>&2
exit 1

so that people know why it is failing. It would be better also to
devnull the output of adduser, otherwise you'll get spurious error
messages:

if ! adduser --system --group --gecos "$condor_gecos" --home $condor_home \
       --disabled-password --disabled-login $condor_user --quiet 2>/dev/null; then

Thanks, it's great it got solved so fast :)

Tiziano

Message #85 received at 684463-close@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: 684463-close@bugs.debian.org

Subject: Bug#684463: fixed in condor 7.8.2~dfsg.1-2

Date: Tue, 21 Aug 2012 19:02:38 +0000

Source: condor
Source-Version: 7.8.2~dfsg.1-2

We believe that the bug you reported is fixed in the latest version of
condor, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 684463@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Hanke <mih@debian.org> (supplier of updated condor package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 12 Aug 2012 19:20:35 +0200
Source: condor
Binary: condor condor-dev condor-doc condor-dbg libclassad-dev libclassad3
Architecture: source amd64 all
Version: 7.8.2~dfsg.1-2
Distribution: experimental
Urgency: low
Maintainer: Condor Developers <condor-debian@cs.wisc.edu>
Changed-By: Michael Hanke <mih@debian.org>
Description: 
 condor     - distributed workload management system
 condor-dbg - distributed workload management system - debugging symbols
 condor-dev - distributed workload management system - development files
 condor-doc - distributed workload management system - documentation
 libclassad-dev - Condor classads expression language - development library
 libclassad3 - Condor classads expression language - runtime library
Closes: 678425 684463 684667 684879
Changes: 
 condor (7.8.2~dfsg.1-2) experimental; urgency=low
 .
   * Make postinst script more robust against missing config variables (Closes:
     #684667). Patch is courtesy of Tim Cartwright.
   * Disable Condor's file transfer mechanism for jobs submitted via
     condor_qsub, because a shared filesystem is assumed for these jobs
     (Closes: #684879).
   * This time really remove dangling symlink /usr/sbin/condor -> ../bin/condor.
     This file no longer exists (Closes: #678425).
   * Support deployment scenario where the administrative 'condor' user is not
     a local system user, but is shared (e.g. through LDAP) by all machines in a
     Condor pool (see installation manual section 3.2). The condor package will
     accept to run under an existing non-system user account named 'condor',
     but only when that account is locked, i.e. not login is possible
     (Closes: #684463).
Checksums-Sha1: 
 f987bf67d4f9737f8397338878d3bcb28c2a8317 2632 condor_7.8.2~dfsg.1-2.dsc
 bc56540faed90859f18f9d847f2e5c5574935ff2 84583 condor_7.8.2~dfsg.1-2.debian.tar.gz
 2e30cd942b8af8ba24472cbf11e6aa05a00e4155 4734238 condor_7.8.2~dfsg.1-2_amd64.deb
 a3b046bd286bbfd7d82c894f0652cdcd0de13bab 453308 condor-dev_7.8.2~dfsg.1-2_amd64.deb
 d8f0a76db23370b7e4ef23487bb58069443ff394 1332840 condor-doc_7.8.2~dfsg.1-2_all.deb
 93f24abfdaa6579f3498d2c77d80661b1b27d707 11650946 condor-dbg_7.8.2~dfsg.1-2_amd64.deb
 bb6821a97f0a9a534c7ac00f90a8b09b6ed4e313 521388 libclassad-dev_7.8.2~dfsg.1-2_amd64.deb
 b59a0a11a8f1f14c36262110a32f94f88def08a1 282352 libclassad3_7.8.2~dfsg.1-2_amd64.deb
Checksums-Sha256: 
 e70b1222e1c1d94e70b53f273507528dd0557ba6759431f4ac0a91be39b55acd 2632 condor_7.8.2~dfsg.1-2.dsc
 bcbf0ef175afc969bfaa1f6965536be691967d7168b49aaa9e9b6bd2d5b6d454 84583 condor_7.8.2~dfsg.1-2.debian.tar.gz
 f16e3e65c247f62939eb11a077751c4d42257c6d4347fd958547f25e0d72f50b 4734238 condor_7.8.2~dfsg.1-2_amd64.deb
 01166f3a8cee8636f1b5ee04f17e1fd030d0c8e383e490ad90a1a33beab57662 453308 condor-dev_7.8.2~dfsg.1-2_amd64.deb
 ccee3c3966b32b8ffbc403bf3bce2e373461769c91a421c8339903ca9e9edf57 1332840 condor-doc_7.8.2~dfsg.1-2_all.deb
 5e28eb8ac3cbf891a702e10c58827f4c55a200cd9afd957eb5b6ac63674a7af3 11650946 condor-dbg_7.8.2~dfsg.1-2_amd64.deb
 031882da0b8bb4b7727aa94678d1a9cee6e12614ee7b1bfeae1fa5418e5c0c3f 521388 libclassad-dev_7.8.2~dfsg.1-2_amd64.deb
 b1eddcd76c7b52c171cc30ededfa3eec6ddd6a6329c60a6df06d2fcb05a9e3ed 282352 libclassad3_7.8.2~dfsg.1-2_amd64.deb
Files: 
 d6d494f3e343231ddb515adcc628ee9e 2632 science extra condor_7.8.2~dfsg.1-2.dsc
 beb1f24a5debe9a6ad011b21968541f5 84583 science extra condor_7.8.2~dfsg.1-2.debian.tar.gz
 cf6084c7404df867a27c58d76d867e82 4734238 science extra condor_7.8.2~dfsg.1-2_amd64.deb
 9fdbfbd22c303262464900c2ed38b390 453308 devel extra condor-dev_7.8.2~dfsg.1-2_amd64.deb
 8b24055f2513c6373b3603b5299aff7d 1332840 doc extra condor-doc_7.8.2~dfsg.1-2_all.deb
 3c21137e7aef58420a401c6149a105f2 11650946 debug extra condor-dbg_7.8.2~dfsg.1-2_amd64.deb
 ec2847db5cb51cb6766bce71f49976ac 521388 libdevel extra libclassad-dev_7.8.2~dfsg.1-2_amd64.deb
 b1e104de4319731af84dd63b8ea57944 282352 science extra libclassad3_7.8.2~dfsg.1-2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQM9ANAAoJEMBz0ih/+56b9xgP/3jqjRtizVLJKGjqhIf/wDkC
+AmElLH5BlFfkCpmciUaTA3n9t+GZ6OG+3Uiu0aIIW8ziZj2c9j5BwM5oFIc2cJE
h3swwHoY8W80jQVqHx0mPPk/FukoGNXbutU/F3c4+DVWOrVL0EW2juaGTvu+qMWG
6VPUvGkwMMogSMBNdYjcdZj4P/+Cy7NuNSe4wTLDzMcijrxAjSLL0ZdOLTJS6kwF
Hv+pt8dNLer1s7w1vyZczcZk/SBSBY3JFACwCX65d3Ky7a/2UJSzwIs09Lg8KiOt
umcMVdfSJu9ElpbXd9TkDT5mKDstsUE9d4+uclQZ65TerRqNGtt4dDehZmCRO3gT
NT9WOZosEbTBVwexuk0xkUVlX7CbsqNZpnoe6iSKKl+Jdo3jBHNP2PX7g/nj9cqe
qFO/D17QUM0wdBgDohBYmWPxQpbmmVr+gGh2Nmr/AvBVzfLEdKBFRD4758LAjcde
XAQEw7pZKB0ZVU0yY4gEzNYXN6zfPLZAnqOaexY6Kar5xlNTl0U9AHwhJogUkyE4
ZLOpVMaq87kHMLB3g95OA7nLHDif3yPesYXvJw1ntQF22IL/7oNtsDDlA4Hsqnyi
2BjMozU8+bPbiU/au8RUbYydJLKaS7YG5fHPbjoy5wLGHwrO0p+l5Ffx2FzhWK2D
CAmGdsE9yTynyVr7jWfK
=Mu5M
-----END PGP SIGNATURE-----

Message #90 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>

Cc: 684463@bugs.debian.org, Jaime Frey <jfrey@cs.wisc.edu>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Tue, 21 Aug 2012 21:04:48 +0200

On Tue, Aug 14, 2012 at 10:30:00AM +0200, Tiziano Zito wrote:
> Thanks, it's great it got solved so fast :)

I have just uploaded 7.8.2~dfsg.1-2 to experimental. It has all the
bugfix that have accumulated so far. Tiziano, could you please check
whether the package works with you setup now. Once I have your
(positive) feedback, I'll try to request a freeze exception...

Thanks,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Message #95 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: Michael Hanke <mih@debian.org>

Cc: 684463@bugs.debian.org, Jaime Frey <jfrey@cs.wisc.edu>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Wed, 22 Aug 2012 08:38:15 +0200

Hi Michael,

any chance that you can upload somewhere (maybe on nd archives) a
backport for squeeze? All production systems I have right now run
squeeze. 

Thanks,
Tiziano

On Tue 21 Aug, 21:04, Michael Hanke wrote:
> On Tue, Aug 14, 2012 at 10:30:00AM +0200, Tiziano Zito wrote:
> > Thanks, it's great it got solved so fast :)
> 
> I have just uploaded 7.8.2~dfsg.1-2 to experimental. It has all the
> bugfix that have accumulated so far. Tiziano, could you please check
> whether the package works with you setup now. Once I have your
> (positive) feedback, I'll try to request a freeze exception...
> 
> Thanks,
> 
> Michael
> 
> -- 
> Michael Hanke
> http://mih.voxindeserto.de

Message #100 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Michael Hanke <mih@debian.org>

To: Tiziano Zito <opossumnano@gmail.com>

Cc: 684463@bugs.debian.org, Jaime Frey <jfrey@cs.wisc.edu>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Wed, 22 Aug 2012 13:47:06 +0200

On Wed, Aug 22, 2012 at 08:38:15AM +0200, Tiziano Zito wrote:
> Hi Michael,
> 
> any chance that you can upload somewhere (maybe on nd archives) a
> backport for squeeze? All production systems I have right now run
> squeeze. 

Binary packages for squeeze have been uploaded to NeuroDebian.

HTH,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de

Message #105 received at 684463@bugs.debian.org (full text, mbox, reply):

From: Tiziano Zito <opossumnano@gmail.com>

To: Michael Hanke <mih@debian.org>

Cc: 684463@bugs.debian.org, Jaime Frey <jfrey@cs.wisc.edu>

Subject: Re: Bug#684463: condor fails to install if condor user already exists

Date: Wed, 22 Aug 2012 15:45:04 +0200

Perfect!

If the LDAP account is a normal account, installation fails as
expected with:

ERROR: Condor cannot run under unlocked non-system account 'condor'
dpkg: error processing condor (--configure):
[...]

If the LDAP account is a locked account, installation is successful
and a warning is issued:

WARNING: Condor will be running under an existing non-system user account 'condor'.

I tested it on a production machine and everything is fine.
Deployment on the whole cluster is happening tomorrow, as soon as
the German neurodebian mirror as catches up with the US one.

Thanks a bunch!
Tiziano

On Wed 22 Aug, 13:47, Michael Hanke wrote:
> On Wed, Aug 22, 2012 at 08:38:15AM +0200, Tiziano Zito wrote:
> > Hi Michael,
> > 
> > any chance that you can upload somewhere (maybe on nd archives) a
> > backport for squeeze? All production systems I have right now run
> > squeeze. 
> 
> Binary packages for squeeze have been uploaded to NeuroDebian.
> 
> HTH,
> 
> Michael
> 
> -- 
> Michael Hanke
> http://mih.voxindeserto.de

Send a report that this bug log contains spam.