- ARCHIVED: Uyuni Users

AW: AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 19 Jul '21

19 Jul '21

Hi Viktor, your hint with the version of python3-salt made me think about downgrading it, which was successful. zypper in --oldpackage python3-salt-3000-30.1 and accepting the dependent downgrades of the packages of salt and salt-minion makes service salt-minion work again. It seems that Patch SUSE-15-SP2-2021-2106 is responsible for dysfunction of the service salt-minion. BTW: Is there a way to block a patch from being activated in general? Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 12. Juli 2021 17:55 An: Victor Zhestkov <Victor.Zhestkov(a)suse.com>; Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de>; users(a)lists.uyuni-project.org Betreff: Re: AW: SLES15SP2-Clients: salt-minion problem Check the output of: rpm -V python3-salt If it's ok then to check which python modules installed from Packagehub channel. Are there any tweaks in the minion configs? On Mon, 2021-07-12 at 15:49 +0000, Crefeld, Tobias LKV Bayern e.V. wrote: Hi Victor, thanks for your fast reply! I guess it's "3002.2-37.1" : zypper se -s salt |grep "^i" i | python3-salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i | salt | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 i+ | salt-minion | Paket | 3002.2-37.1 | x86_64 | SLE-Module-Basesystem15-SP2-Updates for x86_64 BTW: The SLES15SP1 systems where salt-minion is running fine, show version 3000-19.1. Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com <mailto:Victor.Zhestkov@suse.com> ] Gesendet: Montag, 12. Juli 2021 17:31 Hi Tobias. What is the salt version installed on the minion. It's better to check the output of: zypper se -s salt Regards, Victor

2 1

Ubuntu 20.04 salt client not "checking in" when going through a Squid proxy
by Paul-Andre Panon 17 Jul '21

17 Jul '21

Hi, We’ve got an Ubuntu 20.04 system which is set up to connect to the Uyuni server through a standard Squid proxy. It can do most typical client patching tasks against the Uyuni server fine: apt-get update, apt-get upgrade, etc. . I didn’t try pushing packages from the Uyuni side recently, though it used to work before inserting the web proxy. However the server is no longer checking in. It is in a DMZ so connections from the system to the Uyuni server are blocked except through the web proxy. This approach/mechanism worked with a traditional client config Ubuntu client and Spacewalk, where rhn_check was used to check in. Looking at the documentation, it looks like I should have set up and used a different activation key that used push via ssh. https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/cont… Is there any way to convert a standard salt client into the salt-ssh contact method? Is there a recommended way to get myself out of the hole I’ve dug myself into here? I’ve got to think I’m not the first person with a system that needs to move into a DMZ after setup and needs a contact method change. I seem to remember reading that you need to take care in unregistering and reregistering clients, so I’m not sure if trying to do that with a new activation code would work. Does the push via ssh use salt-ssh via public/private key pair? That would seem to be more secure than a user/password approach. Thanks, Paul-Andre Panon -- *For more information on how and why we collect your personal information, please visit our Privacy Policy <https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackI…>.*

2 1

AW: AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 16 Jul '21

16 Jul '21

Hi Viktor,, the output is „null“, probably meaning “ok”. How can I find out from which channel a package has been installed? What do you mean with “tweaks”? Regards, Tobias Crefeld. Von: Victor Zhestkov [mailto:Victor.Zhestkov@suse.com] Gesendet: Montag, 12. Juli 2021 17:55 Check the output of: rpm -V python3-salt If it's ok then to check which python modules installed from Packagehub channel. Are there any tweaks in the minion configs?

3 4

AW: SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 12 Jul '21

12 Jul '21

2 1

SLES15SP2-Clients: salt-minion problem
by Crefeld, Tobias LKV Bayern e.V. 12 Jul '21

12 Jul '21

Hi, after upgrading some SLES15 systems from SP1 to SP2 the service "salt-minion" of those systems don't work anymore although it still can get started. Uyuni release is 2020.11. The following channels are enabled - except the "perl channel" all channels are standard channels from SCC: 1 | SLES15-15-0 | No 2 | SLE-Module-Basesystem15-SP2-Pool for x86_64 | Yes 3 | SLE-Module-Basesystem15-SP2-Updates for x86_64 | Yes 4 | SLE-Module-Legacy15-SP2-Pool for x86_64 | Yes 5 | SLE-Module-Legacy15-SP2-Updates for x86_64 | Yes 6 | SLE-Module-Packagehub-Subpackages15-SP2-Pool for x86_64 | Yes 7 | SLE-Module-Packagehub-Subpackages15-SP2-Updates for x86_64 | Yes 8 | SLE-Module-Server-Applications15-SP2-Pool for x86_64 | Yes 9 | SLE-Module-Server-Applications15-SP2-Updates for x86_64 | Yes 10 | SLE-Module-Web-Scripting15-SP2-Pool for x86_64 | Yes 11 | SLE-Module-Web-Scripting15-SP2-Updates for x86_64 | Yes 12 | SLE-Product-SLES15-SP2-Pool for x86_64 | Yes 13 | SLE-Product-SLES15-SP2-Updates for x86_64 | Yes 14 | perl modules (SLE_15_SP2) | Yes 15 | SUSE-PackageHub-15-SP2-Backports-Pool for x86_64 | Yes 16 | SUSE-PackageHub-15-SP2-Pool for x86_64 | Yes /var/log/salt/minion shows multiple log entries like this one: ---------------------------------------------------------------------------- 2021-07-12 16:26:20,138 [salt.utils.decorators:714 ][WARNING ][7870] The function "module.run" is using its deprecated version and will expire in version "Phosphorus". 2021-07-12 16:26:20,139 [salt.state :322 ][ERROR ][7870] An exception occurred in this state: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 352, in _call_function return self._function(*args, **kwargs) TypeError: _run() missing 1 required positional argument: 'name' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/salt/state.py", line 2176, in call *cdata["args"], **cdata["kwargs"] File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2113, in wrapper return f(*args, **kwargs) File "/var/cache/salt/minion/extmods/states/mgrcompat.py", line 85, in module_run ret = module.run(**new_kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 738, in _decorate return self._call_function(kwargs) File "/usr/lib/python3.6/site-packages/salt/utils/decorators/__init__.py", line 355, in _call_function self._function, self._orig_f_name TypeError: replace() argument 1 must be str, not function ---------------------------------------------------------------------------- I played around with disabling several channels without any effect. Actually I have no clue which packets might be responsible for these exceptions. Maybe some Python experts have an idea about the reason of these exceptions. During update (by using Uyuni's "SP Migrate") there were some warnings: problem with installed package libyaml-0-2-0.2.5-27.1.x86_64 problem with installed package perl-gettext-1.07-322.1.x86_64 problem with installed package libyaml-0-2-0.2.5-27.1.x86_64 "Dry Run" runs successfully only if I mark "Allow Vendor Change". The real upgrade worked only with "zypper dup" at the client's CLI. Using "SP Migrate" for this task doesn't work - not even with "Allow Vendor Change". The upgrade is actually successful but without salt-minion Uyuni's WebGUI still show the old patch level. Any idea? Regards, Tobias Crefeld.

2 1

how to import GPG Keys in Uyuni (RepoMDError: Cannot access repository. Maybe repository GPG keys are not imported)
by Heiner Wulfhorst 12 Jul '21

12 Jul '21

Hi List, i added " https://downloads.linux.hpe.com/SDR/repo/spp-gen10/SUSE/15/x86_64/current/" as a custom channel in Uyuni. If i want to sync its repo with checked "Has Signed Metadata?" Box i always get this error in my reposync log: RepoMDError: Cannot access repository. Maybe repository GPG keys are not imported If that box is unchecked it syncs fine. - I filled out the "Security: GPG" Fields with data from " https://downloads.linux.hpe.com/SDR/keys.html" - added the Key to "Systems > Autoinstallation > GPG and SSL Keys", and - did rpm --import on my uyuni server Is there a way to add more verbosity to that log so i can ensure i really added the right key (should be gpg-pubkey-26c2b797-5669d0b9)? Thanks, Heiner

2 2

Difference between SLES Channels "Product-SLES15-SP2-Pool" and "Product-SLES15-Pool": When to use which?
by Heiner Wulfhorst 12 Jul '21

12 Jul '21

Hi List, i need HPE ssacli on my uyuni managed Systems, so i added this Repository as a Custom Channel: https://downloads.linux.hpe.com/SDR/repo/spp-gen10/SUSE/15/x86_64/current/ As it seems to be for all SLES Service Packs i created it as a child to the parent channel "SLE-Product-SLES15-Pool for x86_64". My managed Systems have been installed with SLES SP2, so i added them to a staged ("lifecycle management") version of Base Channel "SLE-Product-SLES15- *SP2*-Pool for x86_64". 1. Within my Lifecycle Project I can add the "foreign" Child Channel to my Systems. But how would I accomplish this if my systems would be using the latest / upstream version? 2. Is there a "better" way to add Service Pack independent Software to my systems? 3. Should i even use "Product-SLES15-*SP2*-Pool" as a base channel for my Systems, or would it be better to use the general " Product-SLES15-Pool"? 4. What is the difference between "Product-SLES15-*SP2*-Pool" and "Product-SLES15-Pool", how/when should they be used? Hope to get a better understanding of how it is meant to be used so i can avoid possible future problems! Thanks! Heiner

2 3

Where to find bootstrap logs
by Stefan Bluhm 12 Jul '21

12 Jul '21

Hello, I seem to be blind or have lost my patience. When entering "host" (tried IP/hostname), "user"/"password", "activation key" and "Disable SSH.." under "Systems --> Bootstrapping" a blue info message appears "Your system is bootstrapping: waiting for a response..". After some long time, the bar changes to the red error bar saying: "Server error, please check log files.". Where are the logs for the bootstrap attempts? I claim, I searched "everywhere". Thank you and best wishes, Stefan

3 10

How to install old Uyuni release 2021.02
by Heiner Wulfhorst 01 Jul '21

01 Jul '21

Hi List, i need to do a fresh install of Uyuni release 2021.02 on my test system as that is the version our prod is currently running. How/where do i get that version? All docs i found refer to https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… BR Heiner

2 1

Unable to restart Uyuni following Uyuni upgrade 2021-06
by Simon Avery 30 Jun '21

30 Jun '21

Hi Folk, Thanks for the new release - but I'm having significant issues (around four hours so far) in updating this and currently have a broken system. Please advise! 'spacewalk-server status' reports all is fine, however the webui times out (At other stages, it was returning a 404 for all urls) Steps I have done: * Changed repos and upgraded base OS to Leap 15.3 * Upgraded database as per https://www.uyuni-project.org/uyuni-docs/en/uyuni/upgrade/db-migration-13.h… * Changed the Uyuni repo. * Normal Uyuni upgrade. All package issues seemingly resolved, apart from this: Problem: the to be installed patch:SUSE-2020-3767-1.noarch conflicts with 'apache-commons-el < 1.0-3.3.1' provided by the installed apache-commons-el-1.0-bp153.2.24.noarch Solution 1: Following actions will be done: deinstallation of apache-commons-el-1.0-bp153.2.24.noarch deinstallation of spacewalk-java-4.2.23-1.7.uyuni1.noarch deinstallation of spacewalk-common-4.2.3-1.6.uyuni1.noarch deinstallation of spacewalk-postgresql-4.2.3-1.6.uyuni1.noarch deinstallation of patterns-uyuni_server-2021.06-2.3.uyuni1.x86_64 deinstallation of susemanager-4.2.19-1.2.uyuni1.x86_64 deinstallation of supportutils-plugin-susemanager-4.2.2-2.4.uyuni1.noarch deinstallation of uyuni-cluster-provider-caasp-4.2.3-1.4.uyuni1.noarch Solution 2: do not install patch:SUSE-2020-3767-1.noarch (Did try #1, then reinstalling uyuni-server patterns, but it just reappears. ISTR there was a breaking issue with apache-commons-el in a previous update) The main issue appears to be related to this, in catalina's logs: (The dir is present and has an index.jsp file and dirs.) 24-Jun-2021 11:24:31.328 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.36] 24-Jun-2021 11:24:31.357 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/srv/tomcat/webapps/rhn] 24-Jun-2021 11:24:33.950 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/srv/tomcat/webapps/rhn] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1132) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1865) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1044) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) ... 37 more Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:382) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:195) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1971) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1129) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:775) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5044) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 more 24-Jun-2021 11:24:33.958 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [2,601] ms 24-Jun-2021 11:24:33.990 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 24-Jun-2021 11:24:34.297 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 24-Jun-2021 11:24:34.509 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 24-Jun-2021 11:24:34.564 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [3,354] milliseconds Simon Avery Linux Systems Administrator

2 13