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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
