Re: [HTCondor-users] docker universe and centos 6

["Bockelman, Brian" <BBockelman@xxxxxxxxxxxxx>]

> On Sep 3, 2019, at 1:03 PM, Dimitri Maziuk <dmaziuk@xxxxxxxxxxxxx> wrote:
> 
> On 9/2/19 2:49 PM, Bockelman, Brian wrote:
> 
>> Do you have a write-up of the setup?  Or, failing that, an updated Dockerfile?
> 
> I actually have a couple of questions.
> 
> Dockerfile is attached, not much to it, but I'd prefer to get rid of
> /entrypoint.sh. It is
> '''
> $(condor_config_val MASTER) -f -t >> /var/log/condor/MasterLog 2>&1
> '''
> and as far as I can tell the only reason for it is the log file
> redirect. Manual page for condor_master is rather sketchy and has
> neither "-f" nor "-t" there, so
> a) what are they and more importantly
> b) is there a flag to tell it to log to MasterLog so I can put the whole
> thing in ENTRYPOINT?
> 

I knew "-f" ("run in foreground" -- otherwise the process will try to background, which causes Docker issues).

Had to look up "-t".  It is "log to terminal" -- that is, utilize stdout as a log destination instead of the normal logging system.

Does it "do the right thing" if you do simply use "condor_master -f"?  Seems correct in my test.

> I left it running with
> 
>    --net host \
>    -v /etc/condor:/etc/condor \
>    -v /var/lib/condor:/var/lib/condor \
>    -v /var/log/condor:/var/log/condor \
>    -v /var/run/docker.sock:/var/run/docker.sock \
> 
> over the weekend and it is running vanilla universe jobs now. But they
> are logging "user not found" errors.

Which use is it complaining about?  'condor' user or a target user?

> 
> Are those harmless for jobs that do file transfer and not need the
> actual filesystem access?

Yes, these are likely harmless.  My preference / suggestion would be to use the dedicated slot users, however:

https://htcondor.readthedocs.io/en/latest/admin-manual/security.html#who-jobs-run-as

E.g., something like:

STARTER_ALLOW_RUNAS_OWNER = False
DEDICATED_EXECUTE_ACCOUNT_REGEXP = cndrusr[0-9]+

> 
> So it seems you'll need to also bind-mount at least /etc/passwd, or
> install ldap client, in order to get the permissions working.
> 

With the above setup, you could use an auto-generated /etc/passwd *if* jobs are running in the same container as HTCondor.  If they are all running in Docker universe (I think that was the original setup, no?), then you'd indeed need a bind-mounted /etc/passwd.

Philosophical aside that keeps me up at night: HTCondor goes out of its way to prevent people from running jobs as root.  In 2019, when "root inside the container" might be equivalent to "user nobody outside the container" (especially when the container is single-user), does this serve the same purpose as in 2009?

Brian