aboutsummaryrefslogtreecommitdiffstats
path: root/extraconfig/pre_deploy/rhel-registration/scripts
AgeCommit message (Collapse)AuthorFilesLines
2016-10-03Disable all repos during rhel registrationBen Nemec1-0/+1
Some accounts get repos automatically enabled when the system is registered, which is a problem because some of these repos pull in things we don't want like early beta versions of software. Since a full list of desired repos is supposed to be included as part of the registration config, let's just disable all repos to start with to ensure we have a clean repo configuration. I'm not sure whether satellite has the same problem (I would think not, since satellite should only be providing the desired repos), so I'm only making this change for portal registration. Change-Id: I052080352e8b1c9b985e42d91a6c42b3258b0b11 Closes-Bug: 1629922
2016-03-29change the default satellite tools rpm repo.Mike Burns1-1/+1
Change-Id: I60ab36b04b8932e4dbee58e21998dc984178b41c Bugzilla: https://bugzilla.redhat.com/1275281
2016-03-23Fix satellite registration for http or httpsJames Slagle1-4/+5
If the satellite registration url was specified with https, the curl command to detect the satellite version would not work as expected since -L was not passed and you get redirected to https when testing the ping api. To additionally handle the case where https is specified, also use curl directly with -k to download the configuration rpm instead of using rpm with a url. Fixes another bug with a missing $ in the reference to the $satellite_version variable. Change-Id: I984fdfc415eeeed4ef29cc8d0812e1b67545d6b1
2016-02-29Add Satellite 5 supportJames Slagle2-7/+36
Add Satellite 5 support to the RHEL registration environment and resources. The registration script is updated to support both satellite versions in place given the similarity of the options for both scenarios. The satellite version is detected based on $REG_SAT_URL, and that determines whether subscription-manager or rhnreg_ks is used. Change-Id: Ic261c8a16a7d6d3978f8bfc6e53f75dbe1b716db
2015-10-01Move RHEL (un)registration to NodeExtraConfigSteven Hardy2-0/+139
Currently, we have a problem because the unregistration happens in the "post deploy" phase, which works fine when the top-level stack is being deleted, but not when the ResourceGroup of servers is being scaled down, because then the normal "post deploy" update ordering is respected and we try to unregister after the corresponding server has been deleted. So, instead, register/unregister each node inside the unit of scale, e.g the role template being scaled down, which is possible via the new NodesExtraConfig interface, which means unregistration will take place at the right time both on stack delete and on scale-down. Change-Id: I8f117a49fd128f268659525dd03ad46ba3daa1bc