I’m also in the distressed to see EL7 support being removed camp.
CentOS 8 not being a thing has left loads of people stuck on CentOS 7 until either the Rocky/AlmaLinux situation settles or their companies stump up the money for RHEL licensing.
Red Hat Satellite 7.0 will be the last version to support RHEL7. EL7 is currently in maintenance support 2, which means no new features.
From a developer perspective it’s more and more common to run into limitations. I run into systemd limitations most often and those won’t get fixed, but also more fundamental issues where rpm is too old or various packaging macros. The Apache is too old to support the event MPM, which is supposed to be more efficient. Packaging go on EL7 is also painful and software is starting to show up which uses this.
So the cost of supporting EL7 is going up and at least from the Red Hat perspective there’s no need for it anymore. That means a serious community of people needs to stand up to make sure it continues to work. Time that IMHO is better spent on making sure future versions work well.
I don’t know if this has been mentioned, but apparently more recent versions of ansible do not work on RHEL7. No plan to fix that either, AFAIK.
Various dependencies just don’t build.
So, I think RHEL7 is pretty much as dead as it can be, even from the RedHat perspective.
And the only reason people are sour about this is the CentOS 8 “situation”. Else everybody would have moved on.
1 Like
O.K. That’s probably what I have to do then. I really do hope it works. It just took me 2 months, various upgrade attempts, countless debugging hours, to upgrade from 4.2 to 4.3, just discovering at least two more issues/bugs.
So considering that, I am worried that the backup/restore project takes me a year until it actually works. Even the docs are extremely limited on how to restore on a different system:
Restoring Foreman server or Smart Proxy server from a Backup
If the original system is unavailable, provision a system with the same configuration settings and host name.
So what are those “same configuration settings”? And using the same hostname is kind of difficult as I cannot really shutdown everything for a longer time…
Just thinking about how I can set up the new system in parallel to the old one in production causes me headache, e.g. hostnames and names in certificates etc. I also have 1 TB for /var/lib/pulp. As far as I understand the backup process, it will backup the content of that and then restore it. So I have 1 TB on the old server, 1 TB in the backup, and 1 TB on the destination. And everything is going to be copied twice. For content which is 99,9% available online anyway. --skip-pulp-content is only for debugging purposes, so it seems copying the pulp content manually before or even simply using cloning the vdi and attaching it to the new server isn’t an option.
So I am really worried that this is going to be a major operation and in the end I will only wonder if it hadn’t be better simply to start all over again. I have 31 products, ~120 repositories, 4 content views, 275 hosts with parameters set, individual subscriptions and enabled repositories sets. Manually setting this up on a new server takes a lot of time, but if backup/restore would take longer in the end, causing much more problems it might be worth it… Of course, it’s futile to assume how long something will really take…
I don’t really like that. Over the time foreman collected so much garbage on the system that I really don’t want to convert the system in-place to CentOS 8. If I run yum autoremote it wants to remove more than 200 packages. I don’t want to keep all that garbage and I don’t feel comfortable what is going to happen with this after the conversion…
Well, extracting all the data manually is more complicated… Using hammer to extract the information about my 120 repositories, converting it into a form that ansible get take. I mean it’s only a limited amount of information that there is.
And if I simply set up a new system I have to get this information out of the old system anyway, even if it would be a simple click/copy/paste…
So either way, this is already causing me headache and sleepless nights, and I really don’t know what’s the best way to go without wasting too much time…
Another note on migration options: using ansible isn’t really fully working at the moment either, at least if you want to setup a katello server: it seems even the latest version of the ansible collection is still wants to configure the mirror_on_sync option and also has problems with empty http_proxy_id and ssl_*_id options. During each run it wants to remove the latter even though they are set to null anyway.
So my original plan with running the same playbook against my old and new foreman server, verifying it doesn’t make any changes on the old server and then deploying everything on the new server, doesn’t run so smoothly. Each run I have to manually check what it says needs to be changed and check that it’s only the repositories which are incorrectly flagged…
So now I need to patch the theforeman.foreman collection to make it properly work to be used in a migration…
For developers, users of our nightly packages and our Puppet modules, on June 6th we will begin the process of removing EL7 support across the ecosystem for nightly and thus developer setups.
1 Like
Is there a documented in-place upgrade path for RHEL7? The leapp method here mentions it won’t work on RHEL7.
If not, is there a tested and working way to export the data (without pulp/packages) from Foreman/Katello installed on RHEL7 to a fresh install on RHEL8 or even RHEL9? I have the same concerns as post #18 above.
There is a recent community demo that shows how to use Leapp to perform this upgrade:
Official documentation is in process along with a blog post.
1 Like
I’ve updated Created module for RHEL 7 to RHEL 8 upgrade by bangelic · Pull Request #1248 · theforeman/foreman-documentation · GitHub to have RHEL steps too now.
And no, you can’t export data w/o packages.
1 Like
Thanks for this, I’ll watch it and plan to test the upgrade once there is more complete documentation around it.
Would this be worth supporting in the future? From the sysadmin side having brought a production system from Foreman 2.1 to 3.1 with the usual issues during almost every y-stream upgrade, it would be a boon to be able to quickly throw a streamlined backup onto a fresh install and let it sync the packages after.
Given most repos don’t serve historical packages, you wouldn’t be able to sync and get a broken setup.
(Or one that absolutely doesn’t match the one you “backed up”)
Yes, that would definitely be an issue for installs with the need to keep older versions. However, more options and robustness in general for backup surrounding these kind of cases, such as whether to export only packages that are marked such or no longer exist in the source repo, would really help. I can’t speak to the feasibility of these options, but if they existed now it would make upgrade testing and planning much quicker and easier for organizations with larger setups.
Why is it a broken setup then? Technically, it should simply clean it up and fine.
And if I don’t use backup but set up a complete new server with the foreman ansible module it won’t serve historical packages either.
And either way: why must the backup include the complete pulp directory? For me, it would be much more efficient, if the backup only included everything else needed and I take care of getting a complete copy of the pulp directory to the target server (which would be pretty easy as it’s on a separate virtual disk in our virtual environment…) That would safe me a lot of time and terabytes of data copied around by the backup/restore process…
1 Like
But it won’t. Pulp has its state in the DB and there it says “the file is on disk” whereas there is no file on disk.
Is that ideal behavior? Probably not. But it’s what we have today.
Sure, but then pulp won’t think it has all the data.
You don’t have to include pulp data in the backup, you can skip it and create the copy by some other means (rsync, whatever) and the restore will restore fine (minus the fact that you now have to provide the pulp data yourself). Just make sure whatever is on disk and in the DB matches.
Does this mean the following procedure (high-level) is possible?
- We take a backup of a Foreman 3.1 + Katello 4.3 install on EL7 by running “foreman-maintain backup offline --skip-pulp-content”.
- We set up a fresh install of Foreman 3.1 + Katello 4.3 on EL8/9, keeping the same hostname/IP.
- We copy the /var/lib/pulp directory from the EL7 system to the EL8/9 system.
- We restore the foreman-maintain backup from the EL7 system to the EL8/9 system. After the restore completes, we should have the same functionality and host/repo/subscription/CV/etc data that we did on the previous install, and nothing needs to be changed on the clients provided we keep the same certificates. This includes RHEL clients and repos.
- We can continue to upgrade Foreman+Katello on the EL8/9 system as normal.
Interested in hearing your perspective on if this approach will work.
Yes, this should work.
This is also roughly how we document to clone a Satellite server (see Chapter 2. Cloning Satellite Server Red Hat Satellite 6.10 | Red Hat Customer Portal), which reminds me that I still wanted to finish up the work of making satellite clone also support plain Foreman and Katello setups.
2 Likes
At this time we have dropped EL7 from our nightly testing pipelines. We are no longer generating EL7 nightly repositories nor testing installations or upgrade against EL7. We are continuing to work in this area to remove the nightly release repositories on EL7, as well as cleanup packaging to stop building all but client packages on EL7. Forklift has also been updated to drop EL7 as a nightly and development environment option.
Developers – this means that if you are using an EL7 based development environment, it is now out of date and will not be update-able - Please find time and move to an EL8 based setup. There is no in-place upgrade for development environments.
Is there any ETA or more information around when a clone tool will be available for Foreman?
I don’t see any notes on deprecations in the Foreman 3.3 and Katello 4.5 Release Notes
But that is now the last version with EL7 support? 3.4 won’t?
It looks like the entire Foreman release notes weren’t added. Normally speaking they should have been copied. Foreman 3.3.0(GA) release process shows an unchecked checkbox but worse, some steps are missing. Looks like Add steps to update the index, versions of docs.theforeman.org on GA · theforeman/tool_belt@9b9e704 · GitHub was not present in the checkout when the process was applied.