Migration guide to convert Uyuni installation from RPM to container setup? #8816
Replies: 17 comments 52 replies
-
|
I'm aware of
|
Beta Was this translation helpful? Give feedback.
-
|
And some more confusion: https://youtu.be/0eiQIDTGY-U?t=88 uses Leap 15.5 and 15.6 while the docs in https://www.uyuni-project.org/uyuni-docs/en/uyuni/installation-and-upgrade/container-deployment/uyuni/opensuse-leap-micro-deployment.html use only Leap Micro 5.5 |
Beta Was this translation helpful? Give feedback.
-
|
For now we, are only supporting the migration or existing servers to a new machine. The reason is that we didn't had the time to test an in-place migration yet. The migration was tested for uyuni running on podman and kubernetes. Thank you for point out the documentation, I also think it's not clear enough, and we will work on improving it. |
Beta Was this translation helpful? Give feedback.
-
|
@rjmateus , got one more question on this for testing. |
Beta Was this translation helpful? Give feedback.
-
|
Migration is non-destructive. With migration from 4.3 to 5.0, the old machine will stay untouch. If something going wrong in the migration, you can just revert the DNS and have the old suma working. |
Beta Was this translation helpful? Give feedback.
-
|
So if I understand this correctly we can use the migration command to upgrade from a 2024.03 legacy to a 2024.05 container setup in one step. No need to upgrade the legacy setup first and migration in a second step. Although I think I would prefer doing the two-step approach so differ which issues come from the version upgrade and which come from the new container setup. When the migration is done - can we change the Uyuni master name on the clients to get rid of the old DNS name or will it have to stick around forever? I would like to transfer all clients to a generic alias which is easier to move around between servers. Keeping the old server name would complicate things for us. |
Beta Was this translation helpful? Give feedback.
-
|
You can migrate from uyuni version 2024.03 to a containerized one, with no need for an intermediate step. |
Beta Was this translation helpful? Give feedback.
-
|
Does the migration script handle migrating imported/custom signed cert/key pairs for the server if they're in use? If not, do you have some guidance on how to modify settings in the container and deploying the associated CA chain certs? Other customizations of concern would be the salt pillars for copying GPG keys according to https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/gpg-keys.html#_user_defined_gpg_keys (which currently doesn't seem to actually work for us even in an rpm installation), generating new management GPG keys for signing repo data in the containerized model https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/repo-metadata.html. How does that get done in the container environment? When can we expect updated documentation for doing that? For anything that isn't supported by the migration script, I'm going to guess that we would use mgrctl term, similar to what you've indicated for the PAM setup in #8675 (which we also use), but are there any gotchas? I'm also not clear on how updates are supposed to happen in the containerized environment. If we just update the container, but we've had to make these changes in the container overlay, won't they get lost with the container update? Having to redo all these changes manually with each new container release/update would be a big step backwards. |
Beta Was this translation helpful? Give feedback.
-
|
I confirm also the reports are automatically migrated by |
Beta Was this translation helpful? Give feedback.
-
I'm finally trying to do a migration test with 2024.08. I've already set up the authorized-keys ssh settings on the legacy Uyuni server, tested that it works to ssh directly to root from the container server but, when trying to do a trial run, I now get # mgradm migrate podman --prepare --logLevel debug <legacy_uyuni.fqdn> Why is it getting ssh connections denied when I've tested it successfully prior? So I'm guessing the mgradm command is failing because of the USER_AUTH (op=PAM:authentication and op=challenge-response ) failures are superceding the later ssh key successes, but I don't understand why mgradm is trying to do challenge-response when the ssh client doesn't. Or how to suppress it. I am using openSUSE Leap Micro 6.0, because by the time I tried to get started, Leap Micro 5.5 was no longer available for download, but I wouldn't think it would affect something like ssh connections. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Paul-Andre, |
Beta Was this translation helpful? Give feedback.
-
|
BTW you can still download Leap Micro 5.5 http://download.opensuse.org/distribution/leap-micro/5.5/product/iso/ |
Beta Was this translation helpful? Give feedback.
-
Thanks. Thanks to your reply in the other bug report, I did find the issue was not re-running ssh-add after starting the ssh agent. I had done that before a transactional update reboot, but not afterwards. As you can see in my other reply lower, I ran into some other issues, some of which were my fault, but which the Uyuni container tools don't provide an easy way to recover from. The #1 thing I'm currently finding a challenge that didn't get migrated is realm/sssd configuration for SSO authentication against AD or LDAP to allow use with Uyuni. It looks like the 2024.08 release supports two ways of doing AD auth, SSO with SAML2.0 and SSO with PAM I did get adcli to rejoin the container, but it's looks like it's not really all that useful since the kerberos config file isn't persistent, so it disappears with the next container restart. I guess we have to use LDAP? The other thing is I'm seeing a healthcheck failure for the Uyuni pod. The web site seems up, but not everything seems to be working. Any tips on how to get more details on the healthcheck failure than "healthcheck failed"? Maybe that could be added to the troubleshooting section. P.S. There's a mistake in https://www.uyuni-project.org/uyuni-docs/en/uyuni/installation-and-upgrade/container-deployment/uyuni/migrate-uyuni-to-a-container.html
should be using mgrctl, not mgradm |
Beta Was this translation helpful? Give feedback.
-
|
I think ppanon2022 makes some very valid points, all of which I share. The timescale seems very short for all of those reasons, plus the complexity of what may be quite evolved installations. Migration scripts in my experience rarely manage to resolve every single issue without fault, so it seems likely there will be a lot of testing and issues arising. That might mean several migration attempts for each user, then if they do hit problems, having to restore from backups, report the issue and wait for the dev team to fix. It feels unrealistic for that to happen within one month at any time of the year, but especially during the northern hemisphere's summer break. Admission: I hadn't actually realised until now that this container change would be mandatory and that Uyuni would only be available as a container option going forwards, so perhaps I hadn't given it my full attention. But this makes me uneasy and not every admin will have familiarity with the tools and methods going forwards. I would have expected some quite big notifications to make users aware of this, and at least a six month transition period. |
Beta Was this translation helpful? Give feedback.
-
I think if you create a file in
Consider that the backend is managed by |
Beta Was this translation helpful? Give feedback.
-
|
As far as I know, modularization and extension is done via pam, not sssd. I mean, there's some sssd variation available for joining via adcli vs. samba and using their respective callback handler libraries. But IIRC those options are hardcoded and sssd isn't anywhere near as standardized or designed for 3rd party integration the way PAM is, so I think the latter is what most 2FA solutions would use for maximum portability. If you take a look at the Cisco Duo installation process, it uses a separate pam module and the pam configuration files are modified to make it a second necessary component for ssh (or uyuni login). hhttps://duo.com/docs/duounix.
True, but it would be helpful to expand the current documentation that just says "use mgrctl term, change sssd.conf, then restart the container" and Bob's your uncle. If you also manually need to move directives like the default_realm directive into a separate file in /etc/krb5.conf. because adcli isn't being modified to support those persistent volume configurations, then departures from common administration workflows should be documented a little more clearly. Maybe some people will come looking and hit this discussion thread, but you might also lose a few users. I had this working for both ssh and the uyuni web app in the previous non-container installation. Now that I understand a little better how MicroOS transactional-update config works, I might be able to get it to work for ssh at the host level again (the older version of Duo depended on the 1.1 openssl library which doesn't have compat packages in MicroOS, but a newer version hopefully supports the openssl 3 libs included in MicroOS). Unfortunately, I don't see how I can get it to work for the Uyuni web app in the container currently. P.S. Since I didn't say it already, thank you very much for your responses and the pointer to PR 9188. I'm looking forward to a release that contains it. |
Beta Was this translation helpful? Give feedback.
-
|
I've managed to get Duo to work for the MicroOS host's ssh connection. Firstly, I got sssd ad authentication configured (which required using 'semanage boolean --modify --on kerberos_enabled'). Then I compiled from the source tarball on an openSUSE Leap 15.5 system, copied the tarball to the host, and manually installed the libraries (the make install command somehow requires gcc for the build dependencies, and it isn't available on MicroOS). I only actually need to install the pam components, since we don't use the duo_login (and the pam components are what we would want for web app auth in the container). The duo_unix_support directory/command isn't needed for normal operation, just for gathering info for a support case. Below are the commands I used to install it on the host, plus setting up the /etc/duo/pam_duo.conf (which I copied separately from the full Leap server because it isn't in the compiled tarball), to provide an example of the directories it uses. It's not a huge list, the really critical ones are the /etc/duo directory, the /lib64/security directory, maybe what goes in /usr/lib64/pkgconfig (not sure what it does), and whatever the container pam's equivalent of the /usr/lib/pam.d/postlogin-auth would be. However, I'm not sure what libtool does beyond copying the two pam_duo library files into /lib64/security and what other directories/files libtool might change. Those lib loader cache updates might be deal-breakers. I don't remember needing to do any SELinux chcon context changes as the context inherited from the parent directories seemed to generally be functional - although it might be better to change some user contexts from unconfined_u to system_u. transactional-update shell |
Beta Was this translation helpful? Give feedback.
-
|
One more question about the postgresql.conf configuration that is set up by the migration. I noticed that it sets wal logging level to archive (which is somewhat deprecated and synonymous with replication). Is there some type of automated backup set up in the container for the database? If it's not set to minimal and there is no backup, then I think it's going to grow those wal logs with every row data or schema change. If there is a pre-configured mechanism, what is it and what is the schedule? One more request, we used to run spacewalk-report and send the results out with output piped through the mailx command, but there doesn't seem to be a mailx (or even a mail) command in the container. Could that be added or is there a different mail mechanism you would recommend within the container context? |
Beta Was this translation helpful? Give feedback.
-
Ah, one more thing. Our AD domain controllers enforce SASL channel binding as described in As for the container host itself, there is no installable libldap-data package for that directory and config file. If I create the directory and file manually in a transactional-update shell, will the sssd ldap lookup functions use it, or does it try to find and parse that file from a different directory such as /etc/ldap, /usr/etc/openldap, /usr/etc/ldap, /lib/openldap, /lib/ldap, or something else? |
Beta Was this translation helpful? Give feedback.
-
|
OK, this is actually pretty important to avoid filling the database disk. How are we supposed to be doing database backups to clear the wal logs with the container? With the legacy install, we were setting wal logging to minimal, and doing VM level snapshot backups that got deduped. If I try to do this with the container, postgresql won't startup with the error I mean I guess I'm supposed to use |
Beta Was this translation helpful? Give feedback.
-
|
@mbussolotto I think this is something we should look at. Could you have a look and give your opinion? Thank you |
Beta Was this translation helpful? Give feedback.
-
|
Following the instructions above, it looks like the archive logs just build up in /var/spacewalk/db-backup. Currently up to 540+ files in the top level of that directory. Can I just have the cron job clear out everything in /var/spacewalk/db-backup before running the smdba backup-hot command? |
Beta Was this translation helpful? Give feedback.
-
|
I'm also a little confused about how cobblerd and autoinstallable distributions are supposed to work. It seems like at one point it was recommended to run dhcpd on the Uyuni server so that Uyuni could update the dhcpd configuration dynamically. However, dhcpd doesn't seem to be included in the container so that's clearly no longer the case. Is there some guidance I've missed on how to configure dhcpd for BOOTP redirection to the TFTPD service? Are we supposed to just use an Uyuni proxy for dhcp/tftp PXE bootstrapping? The DHCPd salt formula still seems to be in the 2024.08 Specialized Guides but I thought I had read somewhere that that salt formula was deprecated. Is there something I've missed in Community Hours on the future direction in the container-based deployment for this functionality? |
Beta Was this translation helpful? Give feedback.
-
|
@aaannz could you advise in this regard? Thank you |
Beta Was this translation helpful? Give feedback.
-
|
I do not remember when dhcpd was recommended to run on Uyuni. As far as I remember, cobbler managed dhcpd was not supported by Uyuni/SUSE Manager. DHCPd formula still can be used, however you need Leap or SLES minion for it. Lastly, you can use both Uyuni Server and Uyuni Proxy as PXE hosts. Uyuni Server has socket activated tftpd service, Uyuni Proxy has tftpd translation container running. |
Beta Was this translation helpful? Give feedback.
-
|
I've got one more question. On one of our Uyuni systems, we are using an NFS volume for the /var/spacewalk package repos (and a separate virtual disk for /var/lib/pgsql). But mgr-storage-server takes two disk devices as arguments. How do we deal with the migration and that command if we still want that mapped storage to be an NFS drive. Is there something fundamental about podman that requires that to be a disk interface? Or is it safe to run that command using a small dummy disk, then move its contents into an NFS volume and replace the small disk mount with the NFS mount? We would still use a virtual local disk for the Postgresql database. If it does require a local disk interface, why? |
Beta Was this translation helpful? Give feedback.
-
|
the tool is just preparing the disk, formating it and mount it in the right location. the trick in here is mount it in the expected location. You are not forced to use this script and can make it by hand, and mount whatever you want. The folder name inside the podman volumes should be the podman volume name. |
Beta Was this translation helpful? Give feedback.
-
|
That's what I was suspecting. I had tried manually changing the fstab but I ran into an issue. It looks as though the NFS volume has to support NFSv4.2 for security label extensions, because otherwise the SELinux context setting commands in the migration script fail and the migration script aborts. I tried setting the context on the nfs mount options in the hope that they would be consistent for the volume, but that didn't help. |
Beta Was this translation helpful? Give feedback.
-
|
Um, our two openSUSE Leap Micro container hosts for Uyuni (in different sites) both appear to have spontaneously rebooted at 4:30AM PST today. Is this typical? What would be the trigger? |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like rebootmgr is active. |
Beta Was this translation helpful? Give feedback.
-
|
That does seem to be the case. Micro's transactional update configuration has a bit of a learning curve. It also looks like the configuration file to change its schedule is /usr/etc/rebootmgr.conf (not /etc/rebootmgr.conf indicated by https://microos.opensuse.org/blog/2018-04-04-transactionalupdates/#:~:text=Rather%20than%20a%20dumb%20cron%20job,%20we%20recommend%20using%20rebootmgr.) |
Beta Was this translation helpful? Give feedback.
-
|
Hmm. I don't seem to be able to use spacecmd from within the container context with a config file. I do see some SELinux errors but they are for SEL context re-labeling, which seems to try to happen as a result of the spacecmd. It's possible it's misreporting the error. With no tcpdump packet capture available, it's not possible to be sure whether it's actually sending a packet or if it's very coarse-grained exception handling. It does take a long time to return the error. Suggestions? I could add a policy to allow the relabeling, but that seems like it would significantly reduce the security of the container. |
Beta Was this translation helpful? Give feedback.
-
|
From within the container, |
Beta Was this translation helpful? Give feedback.
-
|
To use spacecmd from inside the container please use localhost and call it with the insecure flag, to use HTTP instead of https |
Beta Was this translation helpful? Give feedback.
-
|
you may be hitting this error: uyuni-project/uyuni-tools#474 |
Beta Was this translation helpful? Give feedback.
-
|
I doubt it's the same issue, but I fail to understand the real problem. The generated inspect script looks like this (replace the |
Beta Was this translation helpful? Give feedback.
-
|
The solution to the "Error: cannot inspect podman values: cannot inspect data: cannot read config: While parsing config: line..." turned out to be deleting a duplicate java.hostname entry/line in /etc/rhn/rhn.conf, per Issue #9348, and deleting the duplicate line and re-running the mgradm upgrade podman (following digdilem-work's recommendation) allowed the rest of the container upgrade to proceed. Unfortunately, it did not fix my localhost/loopback issue. Spacecmd still fails as does calls to cobbler, preventing the registration/onboarding and deletion of systems from uyuni. So just running spacecmd on a different system doesn't solve those other serious issues. |
Beta Was this translation helpful? Give feedback.
-
|
That discussion starts to grow in all directions and I'm a bit lost in it... Couldn't we try to separate problems in different discussions? |
Beta Was this translation helpful? Give feedback.
-
|
I can see your point, but also there's a certain advantage to having a one stop shop survey article for issues that can arise from migration. Finding issues like #9348 and realizing it's applicable based on the issue's subject isn't straightforward. I think I should probably open an issue for my loopback/localhost problem at this point, but I don't know how to make it reproducible, so that's a challenge. |
Beta Was this translation helpful? Give feedback.
-
|
I also hit this.
Two options:
As Ricardo mentioned, using localhost and –nossl works.
From the host: mgrctl exec -- spacecmd -s localhost --nossl -u ValidUser -p UserPass
The second option is to download spacecmd onto a different machine on your network and run commands from there. (The binaries are in most EL distros – “yum install spacecmd.noarch” )
Then you can use spacecmd as you did on the RPM distro. Eg: spacecmd -u ValidUser -p UserPass -s fqdn-of-original-server
In both cases you can create the old ~/.spacecmd/config file with the server, user and password values to save entering them each time.
From: Paul-Andre Panon ***@***.***>
Sent: 09 October 2024 22:42
To: uyuni-project/uyuni ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [uyuni-project/uyuni] Migration guide to convert Uyuni installation from RPM to container setup? (Discussion #8816)
Hmm. I don't seem to be able to use spacecmd from within the container context with a config file.
uyuni-server:~ # spacecmd
Welcome to spacecmd, a command-line interface to Spacewalk.
Type: 'help' for a list of commands
'help <cmd>' for command-specific help
'quit' to quit
ERROR: Failed to connect to http://CARMD-NV-UYUNI1.sierrawireless.local/rpc/api
I do see some SELinux errors but they are for SEL context re-labeling, which seems to try to happen as a result of the spacecmd. It's possible it's misreporting the error. With no tcpdump packet capture available, it's not possible to be sure.
/var/log/audit # audit2allow -a
#============= container_init_t ==============
#!!!! This avc is a constraint violation. You would need to modify the attributes of either the source or target types to allow this access.
#Constraint rule:
# constrain dir { create relabelfrom relabelto } ((u1 == u2 -Fail-) or (t1 == can_change_object_identity -Fail-) ); Constraint DENIED
# Possible cause is the source user (system_u) and target user (unconfined_u) are different.
# Possible cause is the source level (s0:c303,c621) and target level (s0) are different.
allow container_init_t container_file_t:dir relabelfrom;
#!!!! This avc is a constraint violation. You would need to modify the attributes of either the source or target types to allow this access.
#Constraint rule:
# constrain file { create relabelfrom relabelto } ((u1 == u2 -Fail-) or (t1 == can_change_object_identity -Fail-) ); Constraint DENIED
# Possible cause is the source user (system_u) and target user (unconfined_u) are different.
# Possible cause is the source level (s0:c303,c621) and target level (s0) are different.
Suggestions?
—
Reply to this email directly, view it on GitHub<#8816 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7AIN5J7TUNM7D7QTMIDHLDZ2WPJFAVCNFSM6AAAAABIIWRW7SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBZG42DGNA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
That doesn't work for me I'm actually trying to run my own python command that does multiple LCM promotions, but it uses a lot of the same python libraries as spacecmd for parsing the config file and running API calls, so spacecmd is a good debugging tool because my issues with that should be reproducible and easier to support. If I can get spacecmd to work then I should be able to get my command to work But so far no joy. I really don't want to set up a completely different VM just to be able to run that one command. It shouldn't be necessary. |
Beta Was this translation helpful? Give feedback.
-
|
Can you reach that endpoint with curl?
mgrctl term
Then when inside the container; curl http://localhost/rpc/api
Should return with no error.
From: Paul-Andre Panon ***@***.***>
Sent: 10 October 2024 19:18
To: uyuni-project/uyuni ***@***.***>
Cc: Simon Avery ***@***.***>; Comment ***@***.***>
Subject: Re: [uyuni-project/uyuni] Migration guide to convert Uyuni installation from RPM to container setup? (Discussion #8816)
That doesn't work for me
myuyuniserver:/home/itadmin # mgrctl exec -- spacecmd -s localhost --nossl -d
DEBUG: stdout is not a TTY, setting TERM=dumb
DEBUG: command=, return_value=False
DEBUG: Read configuration from /root/.spacecmd/config
DEBUG: Loading configuration section [spacecmd]
DEBUG: Current Configuration: {'server': 'localhost', 'username': 'swi_admin', 'password': '************', 'nossl': True}
DEBUG: Configuration section [localhost] does not exist
DEBUG: Connecting to http://localhost/rpc/api
ERROR: <class 'xmlrpc.client.ProtocolError'>
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/spacecmd/misc.py", line 295, in do_login
self.api_version = self.client.api.getVersion()
File "/usr/lib64/python3.6/xmlrpc/client.py", line 1112, in call
return self.__send(self.__name, args)
File "/usr/lib64/python3.6/xmlrpc/client.py", line 1452, in __request
verbose=self.__verbose
File "/usr/lib64/python3.6/xmlrpc/client.py", line 1154, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib64/python3.6/xmlrpc/client.py", line 1187, in single_request
dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for localhost/rpc/api: 404 Not Found>
ERROR: Failed to connect to http://localhost/rpc/api
DEBUG: Error while connecting to the server http://localhost/rpc/api: <ProtocolError for localhost/rpc/api: 404 Not Found>
—
Reply to this email directly, view it on GitHub<#8816 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7AIN5JODWJJ4WFMQJ4GR7LZ23AFZAVCNFSM6AAAAABIIWRW7SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJQG4ZTSNY>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Not on this server having the problem, no. We do have a different server where this isn't an issue. The curl works, and the spacecmd works. However, I don't remember doing anything different between the two migrations. They were both created with the same The broken server does have some additional changes for sssd configuration attempts (currently failing due to lack of krb5.keytab that is awaiting a PR included in the next release). But that shouldn't be resulting in a 404 error AFAIK, since the rpc/api call should be using a local admin account. If that was causing problems, I would expect a 403 error or a 50X error. I tried stopping the sssd service and the error is unchanged (I tested and found that discrepancy thanks to your suggestion, so I do appreciate it.) I'll see if I can think of what else might be different between the two systems and causing the discrepancy, but I'd be grateful for further suggestions. |
Beta Was this translation helpful? Give feedback.
-
|
I'm wondering if setting up and running sssd on the container host could have interfered with the network configuration during pod deployment. See #8816 (reply in thread) above. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
OK , one more question. Post-migration, we're having some problems updating some Redhat 8 systems with perl packages in Appstream modules. The Appstreams are enabled on the Uyuni system entry and running dnf module list on the client shows the same modules enabled. 24 packages show as having newer versions needing to update from Uyuni, but none from the client when running a dnf update. Attempting to push the updates from Uyuni results in a code 02 result and The versions on the client seem older, i.e. el8.1.0 for DBD SQLlite, and el8.3.0 - although one outdated package is also el8.6.0 - whereas all the new packages it's trying to update to are el8.6.0. Dependencies seem OK otherwise. There are no filters on the LCM project used to create the channels assigned to this system. Looking at the Appstream tab on the assigned LCM channel shows the expected option for those modules and nothing else. But the same is true with the sync channel used as a source Thus, it seems like the available package list being transmitted to the client does not include the packages in the Appstream modules that are enabled for the system, despite showing up in the proposed updates list. The minion package version installed on the client is venv-salt-minion-3006.0-33.1.uyuni.x86_64, which seems to be the right one. I believe this used to work before the container migration but is broken now. |
Beta Was this translation helpful? Give feedback.
-
|
Your post was very useful, Cedric, in solving my own issue which I believe is related as it’s giving the same hostname error.
As a test of an affected system, I’ve run those commands you mention in the container and this one
cat /etc/rhn/rhn.conf 2>/dev/null | grep 'java.hostname' | cut -d' ' -f3 || true
Produces a double output
uyuni-server:/ # cat /etc/rhn/rhn.conf 2>/dev/null | grep 'java.hostname' | cut -d' ' -f3 || tru
ata-oxy-uyuni01.domain.com
ata-oxy-uyuni01.domain.com
On inspection, this file contains TWO java.hostname lines
uyuni-server:/ # grep java.hostname /etc/rhn/rhn.conf
java.hostname = ata-oxy-uyuni01.domain.com
java.hostname = ata-oxy-uyuni01.domain.com
Removing one of these lines (Commenting out doesn’t fix it, obviously since it’s grepping) allowed me to run the update “mgradm update podman”
So – it looks like the migration adds a valid java.hostname value to this file without checking whether one exists already.
I suspect this could be fixed within mgradm by restricting the output of the value by one, ie, changing that command to:
cat /etc/rhn/rhn.conf 2>/dev/null | grep 'java.hostname' | cut -d' ' -f3 | head -n 1 || true
Hope this helps.
—
Reply to this email directly, view it on GitHub<#8816 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7AIN5LXRKQYBMSZOEBELSLZ5JCDLAVCNFSM6AAAAABIIWRW7SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMBVGI4TCMA>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for the investigation! It seems that you nailed down the problem. Let me see if I can come with a quick PR fixing it. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a PR fixing the migration: uyuni-project/uyuni-tools#479. Maybe I should fix the inspect too to be more robust... who knows what could land in a config file 😉 |
Beta Was this translation helpful? Give feedback.
-
|
While at it I added a |
Beta Was this translation helpful? Give feedback.
-
|
Please keep discussions focused on the original topic and start a new discussion for each new topic. Mixing multiple topics can make it hard to follow and may lead to confusion. While related discussions are common, organizing them separately ensures clarity and helps everyone stay on track. So if the original issue has been resolved, please mark this discussion as "Close as resolved " |
Beta Was this translation helpful? Give feedback.
-
With the release of 2024.05 we got two announcements that will affect existing Uyuni installations:
So what are the supported migration or upgrade paths to switch an existing installation from RPM to the new container setup? Do we have a migration guide that we can follow?
Beta Was this translation helpful? Give feedback.
All reactions