In a nutshell I get the “User with login admin already exists, not seeding as admin.” error from trying a db:seed. I also ran the db:migrate, and it seemed to run without any issues (since the first attempt produced no output, I ran it again with --trace and checked the exit code, FWIW). See the detailed output below:
What other helpful diagnostic data can I provide? I’m stopping short of just uploading a tarball of my /var/log directory, seeing as this is a public forum.
Also, would there be any merit in trying to upgrade directly to Foreman v2.3 and Katello v3.18 (on the off chance that the bugs I’m tripping over have been fixed in that version of the installer)? The phrasing used in the upgrade documentation seems a bit ambiguous on that count:
Katello supports upgrades from the previous two versions only. Upgrades should be performed sequentially without skipping versions in between.
Thanks @cintrix84 , I’ll be sending it to you shortly (in the next five minutes). I’ve included the output of foreman-debug runs for both before and after the upgrade (in case a wonky condition existed prior to upgrading).
Super sorry about the delay, I never got anything. That is why I had the delay on my end. I did not get anything in the spam, so it’s possible our email filter just dropped the email. I can give you another spot to upload it or if you want to upload it somewhere like Dropbox or something and send me the link that would work too.
I think at this point I’m going to have to nuke the VM and reinstall from scratch, probably starting with Foreman 2.3 and Katello 3.18 (I’d go straight to 4.0, but I’m super wary of .0 releases).
The only thing stopping me from this drastic approach is that I’ve already gotten moderately invested in the current install. But there have been enough weird issues with my CentOS 8 repos that the pros might outweigh the cons at this point.
Also, I’m not sure I won’t run into these same issues the next time I attempt an upgrade. But I’m not sure what my alternatives are in any case (short of cherry-picking and rolling out the individual components myself, e.g., rolling my own Pulp3 server).
Are there any good ways to:
export (and later, re-import) repository configs, so I don’t need to manually cut-and-paste each one from the present configuration;
avoid needing to generate a new consumer certificate (and key), to avoid having to re-install it on all of the clients I’ve registered so-far?
(Is that latter item as simple as taking the cert and key files from their locations on the present server, and placing them into the same location on the new server?)
Sorry for the delay, I was not feeling well so took a few days off. I am back now and can look over the files you sent me if you want to keep the vm? If you want to start over you can just move your ssl certs over and create a new instance passing the certs as params during the installer run.
If you are still able to look into the logs and see if there’s any smoking gun, then I’m certainly interested in knowing what you find. I haven’t yet wiped the VM and started the reinstall, so anything you find would potentially save me some trouble.
And thanks again for looking into this. You’re clearly going out of your way to help me here.
Apologies, I got a tad discouraged earlier this week when I tried to add the CentOS 8 Stream repos, and ran into an additional roadblock. Pulp seems to have trouble recognizing .xz files from the repo metadata, and I thought they may have fixed it in Pulp 3 (hence the thought of cutting my losses and just jumping to a later version). When I get some time this week or next, I’ll file that into their trouble tracking system, if there isn’t already an issue for it.
In any case, thanks for the info about the key-pair. I still have that in my back pocket as a contingency plan.
Okay, I ran restorecon on that CSS file, but there’s no change. According to ls -Z, it had no context before and it still has none afterwards. Also, it’s owned by root:root. Should I change that to pulp:pulp?
Now, that leads to a larger can of worms, as it seems that everything in /var/lib/pulp/assets is owned by root:root. Should I chown -Rh pulp:pulp /var/lib/pulp/assets (rather than just that one CSS)?
As for Debian files: no, I’m not using any, and I can certainly afford to disable support for them (we’re pretty much a .rpm shop). Also, both of those counts return 0. So it’s looking like a safe bet to disable .deb content.
If not later this afternoon, then I’ll probably be attempting another upgrade early next week, using the arg you cited above, for foreman-installer (would there be any harm in also appending --katello-use-pulp-2-for-deb=false?).
I tried doing the upgrade again, with the permission changes to /var/lib/pulp/assets, and with Debian content support disabled, but it doesn’t look like it’s made much of a difference. I still end up with the same failure mode.
Here’s the script I use to automate as many steps as possible: go.sh.gz (613 Bytes)
Any pointers on where I should look next?
Could any specific repositories be throwing a spanner in the works? The fact that my CentOS 8 repos have never been stable seems like it could be a related issue. Periodically, I need to re-publish the content view containing my CentOS 8 repos, because the repomd.xml files from one of the repos (usually EPEL) will suddenly become inaccessible (from the point-of-view of a client, at any rate).
That’s just a hunch, though. I don’t have enough familiarity with the moving parts to know how to pinpoint the issue.