add debian support #184
add debian support #184
Conversation
| @@ -31,6 +31,17 @@ then | |||
|
|
|||
| # configure rhsm | |||
| # the config command was introduced in rhsm 0.96.6 | |||
| subscription-manager config \ | |||
There was a problem hiding this comment.
can we DRY this? Maybe wrap just BASEURL= foo around an if else?
| --server.port="$PORT" \ | ||
| --rhsm.repo_ca_cert="%(ca_cert_dir)s$KATELLO_SERVER_CA_CERT" \ | ||
| --rhsm.baseurl="$BASEURL" | ||
| elif uname -v | grep -qi debian |
There was a problem hiding this comment.
Can we use /etc/os-release or a fact for this? Though I don't want to add another dependency.
There was a problem hiding this comment.
ATM we transform the built RPM into a DEB. That way we can install and run the script.
|
On a second thought, i'm not so sure, the DRY-ing was worth it, because there are some specialities going on around older rhel versions. I kept it on a separate commit to ease the comparison. |
Are you suggesting that is the official documented way for users to register Debian clients? |
|
No, i'd prefer a proper debian package of course. Or considering, that this packet really only contains one script that is run on install, we could just run |
|
Sorry I never got round to looking at this again earlier. Yes I agree, lets remove that second commit. I think there is a discussion to have around how to we register clients, I'm thinking we should change to running I'm not suggesting this PR deprecates RPM, just that I think the method on both systems should be the same, if not very similar. @ehelms @jlsherrill @ekohl others; agree? disagree? any other views? |
mdellweg
force-pushed
the
debian_support
branch
from
7d07617 to
6053fca
Compare
|
I'm not that familiar with the subscription manager workflow. |
|
@sean797 I think what you said makes sense, I'm just not sure how users would react? I think that if i were an admin i would prefer an rpm, but mainly because i tend to not want to run random scripts from a webserver. With the rpm I can sign it with a gpg key from my company, i can't as easily do that with a random script. In reality I'm not sure if users actually care. The script was added to support atomic hosts (who can't install an rpm), but it does make sense to try to reduce the bootstrap steps to a single set of instructions. |
There was a problem hiding this comment.
@jlsherrill the rpm method and the script method both provide the same security, though I feel users might perceive the RPM method to be more secure than curl https:foo/pub/bar | bash
The RPM method, like you say, can be made more secure be signing the RPM, though I've never seen anyone actually do that.
ACK, for now lets discuss removing the RPM method more at a later date. Thanks @mdellweg 👍
Isn't that the goal of #188? |
|
No, the goal of #188 is to facilitate signing/verifying the repo metadata that is generated by Pulp, not the RPMs themselves. It is assumed that the RPMs served by Pulp will already be signed when Pulp retrieves them from the upstream repo ... So Pulp doesn't need to re-sign the RPMs, it only needs to sign the new metadata that Pulp itself generates. In addition, #188 updates this bootstrap RPM so that it will install the GPG key generated by #188, so clients are unlikely to trust that GPG key until after this bootstrap RPM is installed, so it won't help to sign this bootstrap RPM with that key... |
|
@PaulSD thanks for explaining that distinction. I'll get back to reviewing it tomorrow. |
|
Thanks! |
No description provided.