So I've talked to upstream about this already. The idea is not to drop geekotest exactly, but split it up: they want to have different user accounts for the test runners and for the web UI, as they felt it was a bad idea to have the same account used for those two pretty different purposes.

On the topic of the dispatcher script, they actually recommend running it as root: that's why the package permissions are set up the way they are. The problem they see with running it as 'geekotest' (or, in the new design, the web UI user) is that that's the user account most vulnerable to compromise (as it's the user account running the public-facing service) and therefore it should not have access to anything more than is necessary for the purpose of running the web service. It's not a good idea for it to have write access to other stuff, they think.

The new design does have an issue with client.conf, though, as both the workers and whatever wants to schedule jobs needs access to that file. There was a bit of discussion of it in https://github.com/os-autoinst/openQA/pull/236 and more of it in IRC, I'll attach the log.

This in the install guide:

# change "User=_openqa-worker" to "User=geekotest" in /usr/lib/systemd/system/openqa-worker@.service

is just wrong, the workers should run as _openqa-worker. What should be changed are the bits of the install guide that do bad chowns on things the workers need access to - so dump chown -R geekotest backlog cache factory perl pool share testresults script and chown -R geekotest pool).

There really shouldn't be any chown's necessary in the install guide at present, AFAICS. On happyassassin I run with the package's standard permissions, and run openqa_fedora_tools commands as root. If you want to schedule tasks as some other user you probably only need to give that user write access to an ISOs directory one way or another and either give them read access to client.conf or create a ~/.config/openqa/client.conf.

I did suggest the concept of a openqa_admin group or something along those lines; users in that group would have write access to the necessary locations to download ISOs and so on.

Here's the IRC chat we had:

09-03-2015 11:59:50 -!- adamw!~adamw@redhat/adamw has joined #opensuse-factory
09-03-2015 11:59:50 -!- Topic for #opensuse-factory: http://en.opensuse.org/Portal:Factory | http://lists.opensuse.org/opensuse-factory/ | Untested Live-CDs: http://download.opensuse.org/factory/iso/ | https://build.opensuse.org/project/status?project=openSUSE:Factory
09-03-2015 11:59:50 -!- Topic set by darix!darix@irssi/staff/darix [Saturday 06 November 2010, 06:45:37]
09-03-2015 11:59:59 > adamw: coolo: ahoy! I tried #opensuse-openqa but it seems dead :)
09-03-2015 12:00:08 < coolo!coolo@kde/opensuse.member.Coolo: it exists? :)
09-03-2015 12:00:45 > adamw: found it with some google result but no-one's there :)
09-03-2015 12:00:57 < coolo!coolo@kde/opensuse.member.Coolo: tacit: have fun - https://github.com/openSUSE/open-build-service/blob/master/src/backend/bs_dispatch
09-03-2015 12:01:12 > adamw: looks like the testresults thing is a wild goose chase, didn't notice the log messages / file timestamps are from a week ago.
09-03-2015 12:02:08 > adamw: so it looks like things are failing earlier, webUI shows a bunch of test runs in 'pre-processing' but nothing's really running and my journal is stuffed with worker errors
09-03-2015 12:02:22 > adamw: guess i should just sit tight and let you screw down a few more fixes huh :)
09-03-2015 12:03:27 < tacit!~andi@opensuse/member/AndreasStieger: coolo: :-P
09-03-2015 12:04:58 < coolo!coolo@kde/opensuse.member.Coolo: adamw: yeah, today is an exceptionally bad day to deploy master :)
09-03-2015 12:05:20 > adamw: coolo: i'm just using the packages! i just followed the instructions...single tear
09-03-2015 12:05:26 > adamw: :P
09-03-2015 12:06:59 < coolo!coolo@kde/opensuse.member.Coolo: adamw: we expected to fix the fallout quicker :)
09-03-2015 12:07:15 > adamw: 'what could possibly go wrong'...
09-03-2015 12:08:50 < coolo!coolo@kde/opensuse.member.Coolo: adamw: but the client.conf is tricky ;(
09-03-2015 12:09:13 > adamw: coolo: yeah, that's what I thought :/
09-03-2015 12:09:28 < coolo!coolo@kde/opensuse.member.Coolo: https://progress.opensuse.org/issues/6096 might need to get a prio++ :(
09-03-2015 12:10:01 > adamw: maybe it would be an opportunity to allow restricted access to the API with different keys and stuff? so the workers could have their own keys which only allow them to do the stuff they need to do? just a very blue-sky thought, though.
09-03-2015 12:10:16 > adamw: oh, wow, jinx. :)
09-03-2015 12:12:25 > adamw: btw, on the subject of RPM package permissions: the way we schedule jobs in the fedora system, we have a single script which downloads some ISOs then runs the client command to kick off the jobs. so, we run that as geekotest. but that means we have to do 'chown geekotest /var/lib/openqa/factory/iso' as in the package it's owned by root
09-03-2015 12:12:37 > adamw: what would be your thoughts about that? how do ISOs get to openqa in the suse setup?
09-03-2015 12:13:25 < coolo!coolo@kde/opensuse.member.Coolo: our syncing runs as root
09-03-2015 12:14:43 > adamw: i see...
09-03-2015 12:15:07 > adamw: i suppose we could revise our bits to work that way. do you see any particular problem with having the isos/ dir owned by geekotest, though, if say we wanted to do that in our own package or something?
09-03-2015 12:15:24 < coolo!coolo@kde/opensuse.member.Coolo: not ideal either, but lnussel is obsessed with user seperation :)
09-03-2015 12:16:35 < coolo!coolo@kde/opensuse.member.Coolo: adamw: the webui user is the easiest to hack, so we try to give geekotest as least permissions as possible
09-03-2015 12:17:36 > adamw: hum, true
09-03-2015 12:18:20 < coolo!coolo@kde/opensuse.member.Coolo: but the rest will have to wait for tomorrow - cu
09-03-2015 12:18:28 > adamw: cya
09-03-2015 12:18:37 > adamw: thanks for the help, i'll take another look at things tomorrow
09-03-2015 12:18:43 > adamw: plenty of other stuff to work on :P
09-03-2015 12:22:59 > adamw: coolo: as a thought, perhaps we want three levels of user separation? the account under which the daemon itself runs and the privs required to communicate with it should probably be separate?
09-03-2015 12:23:28 > adamw: i.e. /etc/openqa/client.conf could be owned by group 'openqa-admins' or something...

Thank you for clarification. I have added all that chown geekotest stuff only because I wanted to document how I have hacked it on our Boston machine (because I didn't know what user should have access to what file and this was the easiest way). Current state in Boston is not clean and ideal - I want to reinstall OpenQA and update Guide accordingly as soon as I will have time.

I hope that this got solved by recent updates in README.md and InstallGuide.md.