Bjoern is working on tb3, a replacement of the server side tinderbox In order to use the tb script to communicate with tb3 and to avoid implementing and managing yet another authentification scheme, it is preferable to re-use gerrit existing infrastructure hence the need for a plugin that would + accept incoming call from tb + check that the user belong to a given (configuration) ACL group + prepend to the command line argument --user='<user name>' and --groups='list of groups the user belong too' the list of the group can be filtered by configuration to only include the listed one in the configuration + run a local command using a configured program name and the argument given by the user prepended as above (do not use a shell wrapper, invoke the program directly to avoid variable expansion redirection and other nasty trick... even better sanitize the input command line. redirect the incoming read-side socket to stdin and stdout to the outgoing socket (stderr is redirected to a log file (configured) or /dev/null if no such logfile is configured if a logfile is configured log before and after call even with the then timestamp and the command line received + ideally the plugin should be 'nameable' in other word one would be able to rename the jar and get a new plugin command forwarder based on the jar name. if that is not technically possible. The reason for that is that gerrit allow to enable/disable individual plugin, which in turn would allow a gerrit admin to quickly and without disturbing the rest of gerrit to turn on/off a given forwarder... while allowing multiple such forwarded to exist to deal with multiple external services as tb3 is likely not going to be the only one to use that scheme if that prove successful
Bjoern, can you provide more infos how to call tb3 + give an test case how to test that?
(In reply to comment #1) > Bjoern, can you provide more infos how to call tb3 + give an test case how > to test that? the fact that we eventually call tb3 is irrelevant to the plugin. from the plugin point of view it must know (config) the name of an executable to call and call it with the parameters as decribed above... iow the fact that we intend to use this as a way to drive tb3 is immaterial to the work needed on the plugion side to test it you can just use a small echo-like program that send back to stdout the command line arguments it received and test with ssh gerrit <plugin> args [arg....] and it should output --user <your username in gerrit> --groups='the group you belong too' args [args...]
Another IRC session: There is currently not possible to define default SSH command, so the command can not be omitted, instead "call" command should be used instead: ssh gerrit <plugin> call [args] It is not obviously to me how to handle generic arguments. Will have a look here. The actually command has to be configured in <plugin-name>.config file located in $gerrit_site/etc directory. The format of this file is: [shell] target = /home/gerrit/bin/foo ACL = BUILDBOT_USERS forward_user = true forward_user_groups = true where * target is the path to the executable * ACL optionally the group the caller must be in to be able to call that shell utility. If the call is not in this group, then the call is rejected with not authorized error. * forward_user if true, then --user=<user> option should be passed to the target shell utility. What exactly should be passed exactly? Username, i. e. "doe", user id, i. e. "1000031" or prefered Email, i. e. john.doe@example.com as defined in Gerrit? * forward_user_groups if true then the --groups="<group1 group2>, ..." passed to the target shell utility. Blanks are replaced with '_' character.
in second thought, may be divide the sections in config file? [shell] target = /home/gerrit/bin/foo [acl] group = BUILDBOT_USERS [forward] user = true groups = true
(In reply to comment #3) > > * forward_user if true, then --user=<user> option should be passed to the > target shell utility. What exactly should be passed exactly? Username, i. e. > "doe", user id, i. e. "1000031" or prefered Email, i. e. > john.doe@example.com as defined in Gerrit? Username, as this is easely available and does not change (whereas there can be more than one email addres associated with an account) and yes having section in the cfg file is fine... up to you.
First version is ready and deployed on gerrit-test2. Here is a short description of config file: Name: $gerrit_site/etc/plugin-name.config Format: Section: shell * target: aboslute path to the target command to call. Required: yes. * directory: directory where the command should be executed. Required: np. Default $gerrit_site/plugins Section: acl * group: name of the group the calles must be a member of. Required: no. Default: no acl check Section: forward * user: true if user name should be forward to the target command. Required: no. Default false * groups: true if groups should be forwarded to the target command, the curent user is a member of. Required: no. Default fasel. Note: because the names of the groups can contain blanks, the blanks are replaced with "_" chracter. Example: If plugin is loaded as shell.jar, then the plugin name is tb3 and the config file is $gerrit_site/etc/shell.config. $> cat $gerrit_sie/etc/shell.config [shell] target = /home/gerrit2_lo/bin/say-hello directory = / [acl] group = Administrators [forward] user = true groups = true
(In reply to comment #6) > If plugin is loaded as shell.jar, then the plugin name is tb3 and the config > file is $gerrit_site/etc/shell.config. Upps: the plugin name is of course shell: If plugin is loaded as shell.jar, then the plugin name is shell and the config file is $gerrit_site/etc/shell.config.
Ci-infra bugs are now tracked in redmine. Redmine bug #1116 https://wiki.documentfoundation.org/Category:Infrastructure https://redmine.documentfoundation.org/projects/infrastructure https://redmine.documentfoundation.org/issues/1106 https://redmine.documentfoundation.org/issues/1116 Closing this bug as MOVED.