Basically, it should/could still source the same variables as before, right?
On Monday, February 13, 2012 at 3:25 PM, Jim Nachlin wrote: > Pull request submitted. > > Maybe someone else will chime in as to the logic of trying different > reg systems. I am a bit of a novice at certificate-based RHN, so > please bear with me. It's my impression that not many people are > using it yet, anyway. > > Regards, > Jim > > On Mon, Feb 13, 2012 at 3:15 PM, Michael DeHaan > <michael.deh...@gmail.com (mailto:michael.deh...@gmail.com)> wrote: > > > > On Monday, February 13, 2012 at 3:11 PM, Jim Nachlin wrote: > > > > On Mon, Feb 13, 2012 at 2:37 PM, Michael DeHaan > > <michael.deh...@gmail.com (mailto:michael.deh...@gmail.com)> wrote: > > > > Thanks… > > > > Probably some existence check to see if subscription-manager is present and > > then falling back to the old way rhn_register way if that's installed > > instead sounds reasonable. > > > > > > Hi Michael, > > > > It makes a lot of sense to ensure that subscription-manager is > > present. I'm not sure about falling back to the other way, though. > > My thinking is that a shop will probably either want to use the new > > cert-based registration or the old one, and not have the old one > > available as a fallback. That is, if you are going with cert-based > > registration and the registration fails, you probably just want to > > fail and not register (but not fail completely!). > > > > > > Yeah, so the script would just figure out which one to use, is what I was > > suggesting. > > > > What you said was cert based seemed to still take a username/password from > > what you pasted. > > I suppose if it took a cert the field could hold the cert value and it could > > try the cert value first. > > > > I'm not opposed to the system trying all three methods as long as it does > > decent error handling > > and doesn't crash the installer. > > > > > > > > > > > > > > Cobbler should already be laying out the yum.repos.d files ok and shouldn't > > need to do the channel enablement -- many users are going to be mirroring > > channels onto their cobbler server anyway, and using stock yum, so I don't > > *think* this needs a new parameter to work with the channel enablement. > > Maybe it should though. > > > > > > OK. I did not know that. In my case, it seemed to be necessary to > > enable the repos explicitly, because there's no longer an > > rhn.redhat,com where I can go and add the channels. > > > > > > Patches are pretty easy -- Basically it's just forking the project on github > > and then sending github.com/cobbler/cobbler > > (http://github.com/cobbler/cobbler) a pull request. > > > > Anyway, one thing at a time -- send me a patch or the subscription-register > > part and we can perhaps figure out if channel enablement should be there or > > not separately? > > > > > > I don't have a patch. The way I did it was to create a complete file. > > If there's a way to create a patch for a new file, I can't figure it > > out! > > > > I will send you a pull request, though. > > > > > > git-format-patch has some special magic in it. > > > > Anyway, the github pull request is easier as it allows web based merge and > > such, plus maintains the queue of patches > > we need to review. > > > > > > Thanks, > > Jim > > > > > > > > > > On Monday, February 13, 2012 at 2:32 PM, Jim Nachlin wrote: > > > > Hi List, > > > > Red Hat is moving to a new, "certificate-based" registration system. > > They are doing away with rhn_register and moving to > > subscription-manager. > > > > Here is a trivial but possibly useful snippet which we have saved as > > /var/lib/cobbler/snippets/install-puppet: > > > > > > # Subscribe (register) the system > > subscription-manager register --autosubscribe --username=XXXXXXX > > --password=XXXXXXXXXX > > > > # Add what used to be called channels > > yum -y install yum-utils > > yum-config-manager --enable rhel-6-server-optional-rpms > > yum-config-manager --enable rhel-6-server-supplementary > > > > > > I don't know the process for adding it to the cobbler github project, > > and I'd want to make the username and password into settings rather > > than having them hard coded, but I am open to doing that work and > > adding it if it is wanted. > > > > Regards, > > Jim > > _______________________________________________ > > cobbler-devel mailing list > > cobbler-devel@lists.fedorahosted.org > > (mailto:cobbler-devel@lists.fedorahosted.org) > > https://fedorahosted.org/mailman/listinfo/cobbler-devel > > > > > > > > _______________________________________________ > > cobbler-devel mailing list > > cobbler-devel@lists.fedorahosted.org > > (mailto:cobbler-devel@lists.fedorahosted.org) > > https://fedorahosted.org/mailman/listinfo/cobbler-devel > > > > _______________________________________________ > > cobbler-devel mailing list > > cobbler-devel@lists.fedorahosted.org > > (mailto:cobbler-devel@lists.fedorahosted.org) > > https://fedorahosted.org/mailman/listinfo/cobbler-devel > > > > > > > > _______________________________________________ > > cobbler-devel mailing list > > cobbler-devel@lists.fedorahosted.org > > (mailto:cobbler-devel@lists.fedorahosted.org) > > https://fedorahosted.org/mailman/listinfo/cobbler-devel > > > > _______________________________________________ > cobbler-devel mailing list > cobbler-devel@lists.fedorahosted.org > (mailto:cobbler-devel@lists.fedorahosted.org) > https://fedorahosted.org/mailman/listinfo/cobbler-devel > >
_______________________________________________ cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
