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