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.dehaan(a)gmail.com (mailto:michael.dehaan@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.dehaan(a)gmail.com (mailto:michael.dehaan@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(a)lists.fedorahosted.org (mailto:cobbler-devel@lists.fedorahosted.org)
>
https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
>
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org (mailto:cobbler-devel@lists.fedorahosted.org)
>
https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org (mailto:cobbler-devel@lists.fedorahosted.org)
>
https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
>
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org (mailto:cobbler-devel@lists.fedorahosted.org)
>
https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org (mailto:cobbler-devel@lists.fedorahosted.org)
https://fedorahosted.org/mailman/listinfo/cobbler-devel