Re: [Pulp-list] sqlite3.DatabaseError: file is encrypted or is not a database
Thanks, Unfortunately, that didn't work either. I ended up just deleting the repo, deleting the orphans, recreating the repo and it seemed to work after that. Earlier I didn't do the orphan purge between the deletion and creation. Now to figure out why the URLs created are incorrect. On Tue, Jun 9, 2020 at 8:36 AM Ina Panova wrote: > I am not familiar with this traceback. One of the solutions could be to > disable repoview and see if publish succeeds. > > > https://docs.pulpproject.org/en/2.21/plugins/pulp_rpm/tech-reference/yum-plugins.html?highlight=repoview > > > > Regards, > > Ina Panova > Senior Software Engineer| Pulp| Red Hat Inc. > > "Do not go where the path may lead, > go instead where there is no path and leave a trail." > > > On Sat, Jun 6, 2020 at 2:16 AM Gravel Bone wrote: > >> One of my repos is throwing this error: >> >> Generating HTML files >> [/] >> >> Task Failed >> >> Error occurred during 'repoview' execution: Examining repository...done >> Opening >> primary database...done >> Opening changelogs database...done >> Parsing >> comps.xml...done >> Examining state db...done >> Collecting >> letters...done >> >> :: >> Traceback (most recent call last): >> File >> "/usr/bin/repoview", line 940, in >> main() >> File >> "/usr/bin/repoview", line 937, in main >> Repoview(opts) >> File >> "/usr/bin/repoview", line 191, in __init__ >> packages = >> self.do_packages(repo_data, group_data, pkgnames) >> File "/usr/bin/repoview", >> line 544, in do_packages >> pkg_data = self.get_package_data(pkgname) >> File >> "/usr/bin/repoview", line 500, in get_package_data >> >> ocursor.execute(query) >> sqlite3.DatabaseError: file is encrypted or is not a >> database >> >> I tried deleting the repo and recreating it, I've checked the disk space, >> checked SELinux, stop and started the services, updated pulp to latest 2 >> stable release and associated other packages...searching on Google I can >> see things regarding the error, but it's not related to pulp, and I'm >> hesitant to just go find the file and try things...not that it matters... >> ___ >> Pulp-list mailing list >> Pulp-list@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list > > ___ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
Re: [Pulp-list] Syncing Red hat Repos entitlement issue
That didn't work either: * rhsmcertd is not running, disabled * rhnsd is running * rhsmd is running * Server is configured with auto-attach off in Red Hat Portal The key worked for a couple of days, and then getting the "Error retrieving metadata: Forbidden" error again. Unless there is another issue and updating the entitlement just happens to clear that issue, I've been presuming it was an entitlement issue. On Tue, Jun 2, 2020 at 2:44 PM Gravel Bone wrote: > 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 > > <mailto:mike.my...@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 > bmbou...@redhat.com>> >> > *Date: *Thursday, May 28, 2020 at 8:52 AM >> > *To: *Gravel Bone > gravelb...@gmail.com>> >> > *Cc: *Mike Myers mailto:mike.my...@nike.com >> >>, >> > "pulp-list@redhat.com <mailto:pulp-list@redhat.com>" < >> pulp-list@redhat.com >> > <mailto: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 > > <mailto:gravelb...@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 < >> bmbou...@redhat.com >> > <mailto: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
[Pulp-list] sqlite3.DatabaseError: file is encrypted or is not a database
One of my repos is throwing this error: Generating HTML files [/] Task Failed Error occurred during 'repoview' execution: Examining repository...done Opening primary database...done Opening changelogs database...done Parsing comps.xml...done Examining state db...done Collecting letters...done :: Traceback (most recent call last): File "/usr/bin/repoview", line 940, in main() File "/usr/bin/repoview", line 937, in main Repoview(opts) File "/usr/bin/repoview", line 191, in __init__ packages = self.do_packages(repo_data, group_data, pkgnames) File "/usr/bin/repoview", line 544, in do_packages pkg_data = self.get_package_data(pkgname) File "/usr/bin/repoview", line 500, in get_package_data ocursor.execute(query) sqlite3.DatabaseError: file is encrypted or is not a database I tried deleting the repo and recreating it, I've checked the disk space, checked SELinux, stop and started the services, updated pulp to latest 2 stable release and associated other packages...searching on Google I can see things regarding the error, but it's not related to pulp, and I'm hesitant to just go find the file and try things...not that it matters... ___ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
Re: [Pulp-list] Syncing Red hat Repos entitlement issue
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 > <mailto:mike.my...@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 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 <mailto:pulp-list@redhat.com>" < > pulp-list@redhat.com > > <mailto: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 > <mailto:gravelb...@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 < > bmbou...@redhat.com > > <mailto: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 > > <mailto: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 > >
Re: [Pulp-list] Syncing Red hat Repos entitlement issue
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 > *Date: *Thursday, May 28, 2020 at 8:52 AM > *To: *Gravel Bone > *Cc: *Mike Myers , "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 > 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 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 < > gravelb...@gmail.com> > *Date: *Wednesday, May 27, 2020 at 5:48 AM > *To: *"pulp-list@redhat.com" > *Subject: *[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@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@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
Re: [Pulp-list] Syncing Red hat Repos entitlement issue
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 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 > > On Wed, May 27, 2020 at 11:20 AM Myers, Mike 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 < >> gravelb...@gmail.com> >> *Date: *Wednesday, May 27, 2020 at 5:48 AM >> *To: *"pulp-list@redhat.com" >> *Subject: *[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@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list > > ___ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
[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@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
Re: [Pulp-list] Red Hat Repo Sync , pulp 2.21
Ugh, I didn't realize that rhsmcertd was turned back on for my pulp server so the certs were rotating. I figured it was going to end up being something I forgot to check. On Tue, Mar 31, 2020 at 10:32 AM Dennis Kliban wrote: > Please open a support case with Red Hat. It seem like a problem with the > CDN. > > On Tue, Mar 31, 2020 at 10:17 AM Gravel Bone wrote: > >> I've been syncing Red Hat repos, however, almost weekly they start >> failing with the dreaded "Error retrieving metadata: Not found" or "Error >> retrieving metadata: Forbidden" >> >> If I delete the repo and re-create with same entitlements, it starts >> working again. If I update the entitlement with the same entitlement, it >> sometimes starts working again, if I just go get a new entitlement key it >> will generally work. >> >> I've been trying various things like --force option, republishing. Don't >> know if it's the server configuration or a pulp thing at this point. >> >> I've searched, but almost all the help is referring to Foreman now and >> refreshing a manifest or disabling proxy, neither of which I think I'm >> using. >> ___ >> Pulp-list mailing list >> Pulp-list@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list > > ___ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
[Pulp-list] Red Hat Repo Sync , pulp 2.21
I've been syncing Red Hat repos, however, almost weekly they start failing with the dreaded "Error retrieving metadata: Not found" or "Error retrieving metadata: Forbidden" If I delete the repo and re-create with same entitlements, it starts working again. If I update the entitlement with the same entitlement, it sometimes starts working again, if I just go get a new entitlement key it will generally work. I've been trying various things like --force option, republishing. Don't know if it's the server configuration or a pulp thing at this point. I've searched, but almost all the help is referring to Foreman now and refreshing a manifest or disabling proxy, neither of which I think I'm using. ___ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
[Pulp-list] relative-url issue
I created a repo: sudo pulp-admin rpm repo create \ --repo-id=live-rhel6-opt \ --display-name="BLAH" \ --description="BLAH BLAH" \ --repoview=true \ --serve-http=true \ --feed= https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86_64/optional/os \ --validate=true \ --relative-url=rhel6/opt \ --checksum-type=sha1 \ --remove-missing=true \ --gpg-key=/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \ --feed-ca-cert=/etc/rhsm/ca/redhat-uep.pem \ --feed-key=REDACTED \ --feed-cert=REDACTED In a browser I can go to http://server/pulp/repos/rhel6/ks, however all presented links (Packages, repoview, etc.) omit the ks and render as http://server/pulp/repos/rhel6/Packages/ which of course don't work. I've searched around and seen similar issues but no solutions or not quite the same issue. I'm sure I'm missing something either in my http configuration or somewhere else. Any pointers would be appreciated. Gravelbone ___ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
