Add users keys as authorized keys for yumrepostage

[ehelms]

No description provided.

[ehelms]

Based upon the design for pushing locally generated stage repository from Copr to the staging repository -- theforeman/theforeman-rel-eng#280

[ekohl]

Argh, I forgot to submit the review yesterday.

[ehelms]

Switched to using keys as the naming instead of users

[ekohl]

I still question about the bigger picture. This allows a user to call a script, but they're still not allowed to upload their own content. How do you plan to address this?

[ehelms]

I still question about the bigger picture. This allows a user to call a script, but they're still not allowed to upload their own content. How do you plan to address this?

Explain? The goal is to allow users to rsync RPMs as the yumrepostage user to the staging repository location.

[ekohl]

You can see it forces a command to run, which is $HOME/bin/secure_$USER. That has

foreman-infra/puppet/modules/web/templates/deploy-stagingyum.sh.erb

Line 2 in da534ce

YUM_PATH=`echo "${SSH_ORIGINAL_COMMAND}" | awk '{ print $NF }'`

as the source.

My reading is that it only allows the command to start with rsync --server, which means you can't upload files from your local disk.

Am I missing anything?

[ehelms]

I do not follow where you are getting that from, but this is what Jenkins does which has no --server, what I believe it relies on is the presence of rsync_cache:

if [[ `echo "${SSH_ORIGINAL_COMMAND}" | awk '{ print $NF }'` =~ ^rsync_cache/.* ]] ; then

You can see what Jenkins does here, which is what a user would be doing:

https://github.com/theforeman/jenkins-jobs/blob/master/theforeman.org/pipelines/lib/packaging.groovy#L474-L485

Which is my goal here: https://github.com/theforeman/theforeman-rel-eng/pull/280/files#diff-75ffb578a1aa224516bbb4130ba24c902b62748edddd6c77fc637648471bb3e6

[ekohl]

Perhaps internally rsync rewrites the SSH command to include --server. From man rsync:

INTERNAL OPTIONS
The options --server and --sender are used internally by rsync, and should never be typed by a user under normal circumstances. Some awareness of these options may be needed in certain scenarios, such as when setting up a login that can only run an rsync command. For instance, the support directory of the rsync distribution has an example script named rrsync (for restricted rsync) that can be used with a restricted ssh login.

Which makes me think it would be good to use rrsync instead of plain rsync. It has --no-del --no-overwrite as options. Those sound like they can be used to easily enforce we don't overwrite already signed RPMs. I wonder about metadata or other things, but if we'll regenerate the metadata on the server (which AFAIK we should do anyway) then it sounds like something we can deal with. We can also use temporary files which the script always removes after regenerating the metadata if needed.

[ehelms]

Which makes me think it would be good to use rrsync instead of plain rsync. It has --no-del --no-overwrite as options. Those sound like they can be used to easily enforce we don't overwrite already signed RPMs. I wonder about metadata or other things, but if we'll regenerate the metadata on the server (which AFAIK we should do anyway) then it sounds like something we can deal with. We can also use temporary files which the script always removes after regenerating the metadata if needed.

For the stage repository, we are not generating the repository and metadata on the webserver. Production and staging are handled differently and this is only targeting staging.

The workflow for staging:

• generate repository locally (or on Jenkins)
• rsync packages and metadata over to the staging vhost location

And a reminder stage to production is handled:

• rsync from staging on web01 to production
• runs createrepo to regenerate the metadata since only the diff is copied

[ehelms]

@evgeni @ekohl I'm blocked on any further Copr work until this and theforeman/theforeman-rel-eng#280 are merged

[evgeni]

For the sake of my own sanity, here is how I read this:

Today, there is a set of systems (identified by the foreman_search in stagingyum.pp who are allowed to push to this repo. These pushes happen to a "special" rsync_cache folder from where then the receiver script is moving them to the "correct place" after the push happened. There is no post-processing of the repo happening (contrary to, e.g. when we push to yum.tfm.o).

This change adds a set of additional keys that are allowed to perform the same action as above (push to cache, get the cached content copied over to the real destination), without the IP address restriction. Those additional keys are taken from the users module that is already handling our normal SSH logins.

While I think the way we configure the set of users whose keys are added could be better configurable, I wouldn't block on this to get the copr integration further.

[evgeni]

Something tells me this list should be configured somewhere else, but I guess it's good enough here for starting and testing?