To clarify a bit, what will be needed is:

• creating a wdqs-admins group in the admin module
• grant access to tin (maybe this is optional)
• grant access to the "wdqs" cluster once it exists :)
• grant sudo rights to read logs and start/stop/restart wdqs

Change 223984 had a related patch set uploaded (by Dzahn):
add admin group 'wikidata query service deployers'

https://gerrit.wikimedia.org/r/223984

Here's a patch to add a new admin group to start with, add the 2 users and give them privileges: ['ALL = NOPASSWD: /usr/sbin/service wdqs *'] assuming the service will be called "wdq". Of course we can't apply it on anything yet until the cluster exists but it's what we could do today to move forward.

WDQS service will have two services, implementing Blazegraph database and the updater. I don't have yet debian service configs for them, but if you needs to choose names, we can use wdqs-blazegraph and wdqs-updater for that. These services should be running under dedicated user (blazegraph currently). I imagine there may also be a need for the members of the admin group to su to that user - e.g. since it allows to collect Java statistics about the service processes (such as jstat).

Thanks for the details. @Smalyshev. I amended and uploaded a new patchset to reflect that. How about

privileges: ['ALL = (blazegraph) NOPASSWD: /usr/sbin/service wdqs-blazegraph *, /usr/sbin/service wdqs-updater *']`

@Dzahn should I be using systemd or upstart or sysv configurations for the services? I'm not sure if /usr/sbin/service is the same system. Also, please see my comments on the patch - I'm not sure it would work as described.

so far i have simply copied that from other examples we have for existing services. that made me assume it's the right way for this service as well.

dzahn@sphinx:~/wmf/puppet$ grep -r NOPASSWD | grep service
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service parsoid *',
modules/admin/data/data.yaml:                 'ALL = NOPASSWD: /usr/sbin/service parsoid-rt-client restart',
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service ocg *',
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service mathoid *',
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service citoid *',
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service cxserver *',
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service chromium *',
modules/admin/data/data.yaml:                 'ALL = NOPASSWD: /usr/sbin/service xvfb *']
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service zotero *']
modules/admin/data/data.yaml:    privileges: ['ALL = NOPASSWD: /usr/sbin/service graphoid *',

on a Ubuntu trusty host (like for example current parsoid services on wtp1001)

dpkg -S /usr/sbin/service
sysvinit-utils: /usr/sbin/service

dpkg -S /sbin/init says
upstart: /sbin/init

but we would like to upgrade to Debian jessie and then it is

dpkg -S /usr/sbin/service
sysvinit-utils: /usr/sbin/service

dpkg -S /sbin/init
systemd-sysv: /sbin/init

fwiw

@Dzahn yes but your proposed config as far as I can see allows only to sudo to user blazegraph, not to root, for services. While services do run under blazegraph user, I think if I am going to start/stop them, I'll still need to sudo to root.

Also, I think some access to journalctl for log viewing may be needed, but this can be worked around by sending the logs to syslog and maybe configuring rsyslogd to put them in files which could be read by wdqs-admins group. I'll check on that.

@Smalyshev the first proposal had ALL users, i just amended to blazegraph after your comment. you are probably right and you need ALL.

regarding logs, i think we might want to send them to a central logserver anyways and then access would be solved over there in some way or another

@Dzahn I'm talking about service logs, like reporting that everything started/stopped/loaded/etc. properly and the progress metrics for updater - are those going to central server too? If so, where can I see the example of configs for those so I can update the puppet scripts accordingly?

I don't know the answer to the logging question yet. Looking at the parsoid role i see a comment "132 # until logging is handled differently, rt 6851"

OK, maybe then we can temporarily add journalctl to the sudo list until we figure out how centralized logging will work? Unless you see any security issues with that. We'll need some way to inspect the logs.

Yes, that sounds good for now until we figure out something else.

https://gerrit.wikimedia.org/r/#/c/223984/

Change 223984 merged by Giuseppe Lavagetto:
add admin group 'wikidata query service deployers'

https://gerrit.wikimedia.org/r/223984

Change 228129 had a related patch set uploaded (by Alex Monk):
Copy wdqs-admins group from tin to mira

https://gerrit.wikimedia.org/r/228129

Change 228129 merged by Ori.livneh:
Copy wdqs-admins group from tin to mira

https://gerrit.wikimedia.org/r/228129