Re: [Pulp-list] Syncing Red hat Repos entitlement issue

[Gravel Bone]

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  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  > > 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  bmbou...@redhat.com>>
> > *Date: *Thursday, May 28, 2020 at 8:52 AM
> > *To: *Gravel Bone mailto:gravelb...@gmail.com
> >>
> > *Cc: *Mike Myers mailto:mike.my...@nike.com>>,
> > "pulp-list@redhat.com " <
> pulp-list@redhat.com
> > >
> > *Subject: *Re: [Pulp-list]  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  > > 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 <
> bmbou...@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.my...@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: * > > on behalf of
> Gravel Bone
> > mailto:gravelb...@gmail.com>>
> > *Date: *Wednesday, May 27, 2020 at 5:48 AM
> > *To: *"pulp-list@redhat.com  >

[Pulp-list] pulp_rpm 3.4.0 is Generally Available

[Dennis Kliban]

pulp_rpm 3.4.0 is available on PyPI[0]. This release is compatible with
pulpcore 3.4.0. It is also accompanied by a Python client[1] and a Ruby
client[2].

Please note that upgrades from 3.2.z to 3.3.z were broken due to a
migration bug. This release addresses that problem.

This release contains a new feature, several bug fixes, and documentation
improvements. The changelog contains the full list of changes[3], but here
are some highlights:

## Features

* Distributions now serves a config.repo, and when signing is enabled
also a public.key, in the base_path. #5356

## Bugfixes

* Fixed the duplicated advisory case when only auxiliary fields were
updated but not any timestamp or version. #6604
* Fixed dependency solving issue where not all RPM dependencies were
coped. #6820
* Make ‘last_sync_revision_number’ nullable in all migrations. #6861
* Fixed a bug where the behavior of RPM advanced copy with dependency
solving differed depending on the order of the source-destination
repository pairs provided by the user. #6868

## Installation and upgrades

You can use the pulp_installer version 3.4.0 to perform an installation or
upgrade[4]. The installer has its own documentation[5].

[0] https://pypi.org/project/pulp-rpm/3.4.0/
[1] https://pypi.org/project/pulp-rpm-client/3.4.0/
[2] https://rubygems.org/gems/pulp_rpm_client/versions/3.4.0
[3] https://pulp-rpm.readthedocs.io/en/3.4/changes.html#id1
[4] https://github.com/pulp/pulp_installer/releases/tag/3.4.0
[5] https://pulp-installer.readthedocs.io/
___
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list