[Dxspider-support] dxspider in docker and some questions on why some things are the way they are

[Dirk Koopman]

On 25/03/15 00:08, Brendan Minish wrote:
> I have been working on setting up spider so it can be run in a docker
> container, mainly as an exercise in learning how to use docker well
> enough to win arguments with bright eyed and bushy tailed 'Devops' types
> who think ageing linux sysadmins are holding back progress..
>
> Running spider in docker is dead easy if you treat the docker instance
> as a traditional virtual machine and go through the manual install
> steps, however this is not the docker way and one misses out on a lot of
> the shiny bits.
> Instead you build your image when you need it as a recipe from a Docker
> file.
>
> Creating this recipe got me to thinking about some of the things around
> how we install spider, hence the questions..
>
> I'd also like to properly write up the installing on centos7
> instructions on the Wiki
>
> 1/ at install time we add a group 'sysop' for spider, this seems
> redundant since a group called spider will be created and associated
> with the spider user when we create the spider user with 'adduser'.
> Is this now a Historical legacy ?
> If there's a 3rd party application that really needs to access the files
> owned by the sysop then it can be given group access to the sysop group

Not "legacy", just an attempt to make it easier at the time. In fact, 
the permissions have simply got to be correct for the installation, 
given the user/group that the tree was created under.

>
> 2/ we 'fix up' the permissions by doing
>       # chown -R sysop.spider spider
>       # find . -type d -exec chmod 2775 {} \;
>       # find . -type f -exec chmod 775 {} \;
>
> In all my recent installs 'git clone' has done the right thing with
> similarly permissive permissions, this this seems unnecessary now that
> we source dxpsider from a version control system rather than a tarball.

You have your answer: "using git clone". The instructions are belt and 
braces and really only required if installing from a tarball (and then 
only with the "correct" owner/group as above).

>
> 3/ in parts of the code spider references it's working directory
> as /spider thus mandating the symbolic link be created.
> ln -s  ~/sysop/spider /spider
> is there a good reason that the code does this instead of just
> referencing via the current home directory of the user running spider
> (Line 20 of spider/perl/cluster.pl , could it be altered to root =
> "~/spider" ?)
>

There has to be an override to cope with people that don't do default 
things (i.e. you or me), which might include running two instances in 
the same machine.

That is what DXSPIDER_ROOT is all about. So starting the cluster.pl thusly:

DXSPIDER_ROOT=~ cluster.pl

or some similar incantation may do what you want.

>
>
> 4/ is there a way to execute 'set/spider <nodecall> ' without having to
> invoke the console (or log in as sysop) to do so?
> The reason I ask this is that setting a peer as a node has to be done
> before you connect to it as a cron job.
> Having to connect to the console and issue 'set/spider <nodecall>' is
> the only step that prevents me creating a docker recipe that completely
> automates firing up a cluster instance
>
>

You can drop a (any) command into the /spider/cmd_import directory by 
creating a file with a suitably privileged callsign as the filename, 
which then contains as many commands as you want.

giving a $myalias = 'G9TST'

echo 'set/spider gb7djk' > /spider/cmd_import/G9TST

should do what you require.

Dirk