[Pulp-list] <External> Syncing Red hat Repos entitlement issue
Gravel Bone
gravelbone at gmail.com
Tue Jun 2 18:44:02 UTC 2020
Right, but rhsmcertd wasn't running...I'm now trying to turn off
Auto-Attach and see if that might help.
Bob
On Mon, Jun 1, 2020 at 10:59 AM Bryan Kearney <bkearney at redhat.com> wrote:
> rhsmcertd is not doing the invalidation, it is pulling down the most
> up2date
> certificate. Any process you have would need to simulate that.
>
> -- bk
>
> On 5/28/20 4:18 PM, Gravel Bone wrote:
> > Also, I shut the service down and ensured it wasn't running and
> while the entitlement
> > file in /etc/pki/entitltements didn't change the syncs still failed with
> the
> > issue...so while yes, it rhsmcertd can be the culprit, there's
> something else on Red
> > Hat side maybe?
> >
> > On Thu, May 28, 2020 at 12:24 PM Myers, Mike <Mike.Myers at nike.com
> > <mailto:Mike.Myers at nike.com>> wrote:
> >
> > It’s 100% the rhsmcertd process that’s doing it. From the man
> page:____
> >
> > __ __
> >
> > rhsmcertd - Periodically scans and updates the entitlement
> certificates on
> > a registered system.____
> >
> > __ __
> >
> > What I’m unclear on is why the certs get changed by Red Hat so often
> when our
> > entitlements certainly haven’t. And more importantly, what, if
> anything, we can
> > do to integrate that process more closely with Pulp.____
> >
> > __ __
> >
> > And to be clear, I’m not trying to call this out as a Pulp project
> problem or
> > issue, just wondering if others who use the project have insights or
> solutions
> > they’re willing to share.____
> >
> > __ __
> >
> > Cheers,____
> >
> > *Mike Myers*____
> >
> > __ __
> >
> > __ __
> >
> > *From: *Brian Bouterse <bmbouter at redhat.com <mailto:
> bmbouter at redhat.com>>
> > *Date: *Thursday, May 28, 2020 at 8:52 AM
> > *To: *Gravel Bone <gravelbone at gmail.com <mailto:gravelbone at gmail.com
> >>
> > *Cc: *Mike Myers <Mike.Myers at nike.com <mailto:Mike.Myers at nike.com>>,
> > "pulp-list at redhat.com <mailto:pulp-list at redhat.com>" <
> pulp-list at redhat.com
> > <mailto:pulp-list at redhat.com>>
> > *Subject: *Re: [Pulp-list] <External> Syncing Red hat Repos
> entitlement issue____
> >
> > __ __
> >
> > One idea to track down which process is editing those certs/files
> would be to use
> > auditd or systemtap https://unix.stackexchange.com/a/99091
> > <
> https://urldefense.com/v3/__https:/unix.stackexchange.com/a/99091__;!!KLCbKzk!3-4lUfRz-2wFNgovtknDNZUEiyn20AZ72aaznXiV_QGBFFfkIRrb454_Sjx08Ns$
> >
> > Just a thought I wanted to share.____
> >
> > __ __
> >
> > On Thu, May 28, 2020 at 9:18 AM Gravel Bone <gravelbone at gmail.com
> > <mailto:gravelbone at gmail.com>> wrote:____
> >
> > In this case the entitlement certs themselves aren't expired
> from a date
> > perspective, they just no longer work connecting to Red Hat.
> It's more
> > like they've been revoked because the server they are on got new
> entitlement
> > certs which is happening automatically, I just have not figured
> out how to
> > prevent that. I've tried turning of rhsmcertd, disabled
> subscription
> > management, and combinations in between.____
> >
> > __ __
> >
> > On Wed, May 27, 2020 at 2:23 PM Brian Bouterse <
> bmbouter at redhat.com
> > <mailto:bmbouter at redhat.com>> wrote:____
> >
> > If the certs are short-lived, then there isn't much to do
> except ask the
> > issuer to give you longer ones. You could inspect the certs
> more closely
> > I believe using the `rct cat-crt` command. Pulp-certguard
> has some docs
> > showing an example with that tool
> >
> https://pulp-certguard.readthedocs.io/en/latest/debugging.html#checking-authorized-urls-in-rhsm-certificates
> > <
> https://urldefense.com/v3/__https:/pulp-certguard.readthedocs.io/en/latest/debugging.html*checking-authorized-urls-in-rhsm-certificates__;Iw!!KLCbKzk!3-4lUfRz-2wFNgovtknDNZUEiyn20AZ72aaznXiV_QGBFFfkIRrb454_MFyqH7A$
> >____
> >
> > __ __
> >
> > On Wed, May 27, 2020 at 11:20 AM Myers, Mike <
> Mike.Myers at nike.com
> > <mailto:Mike.Myers at nike.com>> wrote:____
> >
> > We’ve faced that too. I’ve love some deeper insight,
> but what I’ve
> > found so far is that “rhsmcertd” process does some sort
> of
> > check/update on those certs. We’ve just set a process
> to pull those
> > from /etc/pki/entitlement into Pulp when such a failure
> occurs. It
> > would be nice if there were a Pulp native way to address
> this (short
> > of running the whole Satellite suite)____
> >
> > ____
> >
> > Cheers,____
> >
> > *Mike Myers*____
> >
> > ____
> >
> > *From: *<pulp-list-bounces at redhat.com
> > <mailto:pulp-list-bounces at redhat.com>> on behalf of
> Gravel Bone
> > <gravelbone at gmail.com <mailto:gravelbone at gmail.com>>
> > *Date: *Wednesday, May 27, 2020 at 5:48 AM
> > *To: *"pulp-list at redhat.com <mailto:pulp-list at redhat.com
> >"
> > <pulp-list at redhat.com <mailto:pulp-list at redhat.com>>
> > *Subject: *<External>[Pulp-list] Syncing Red hat Repos
> entitlement
> > issue____
> >
> > ____
> >
> > This is probably something straight forward, but my
> searches have
> > found nothing...____
> >
> > ____
> >
> > I pull an entitlement files from our server (well three
> for three
> > different subscriptions) and create repos using them to
> sync the
> > corresponding Red Hat repository. The problem is, the
> entitlements
> > seem to expire about every month. I'm sure it's
> something I'm
> > missing that stupid obvious, but google has not been my
> friend nor
> > has the documentation...help would be appreciated...____
> >
> > _______________________________________________
> > Pulp-list mailing list
> > Pulp-list at redhat.com <mailto:Pulp-list at redhat.com>
> > https://www.redhat.com/mailman/listinfo/pulp-list
> > <
> https://urldefense.com/v3/__https:/www.redhat.com/mailman/listinfo/pulp-list__;!!KLCbKzk!3-4lUfRz-2wFNgovtknDNZUEiyn20AZ72aaznXiV_QGBFFfkIRrb454_ppGV4nQ$
> >____
> >
> >
> > _______________________________________________
> > Pulp-list mailing list
> > Pulp-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-list
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20200602/c293bac8/attachment.htm>
More information about the Pulp-list
mailing list