![](https://seccdn.libravatar.org/avatar/f8681a5ce9ab75bcfc59a901a86f6884.jpg?s=120&d=mm&r=g)
On lunes, 12 de julio de 2021 13:42:49 (CEST) Stefan Bluhm wrote:
Hello Julio,
Server and client are both AlmaLinux 8.
Ah, ok. So this is part of your effort
The py26 packages were not installed so I guess this is a missing dependency that needs fixing. I installed them, now the salt api log is empty and I am back to square 1: No log entries at all.
About no errors: Did you stop the services before installing the packages, and stopped them? If not, use `spacewalk-service restart` now. Not saying it will fix the problem, but it could be related. About the missing packages: Did you change the pattern? https://build.opensuse.org/package/view_file/systemsmanagement:Uyuni:Master/ patterns-uyuni/patterns-uyuni.spec?expand=1 has Requires: py26-compat-salt Requires: py27-compat-salt Both are required to be able to onboard any OS that only has python 2.6 or 2.7. The py26-compat-salt package requires those that you were missing.
a) What OS is installed at the client? Since py26 is mentioned, I guess CentOS6? AlmaLinux 8 b) How are you bootstrapping? WebUI? Script? WebUI (Systems --> Bootstrapping) c) What kind of client do you intend to bootstrap? SSH or regular salt minion? I actually don't know. I guess SSH as it mentions SSH on the page? Maybe here is the user error. I don't know anything about boot strapping.
There are two checkboxes mentioning SSH at that page. If you checked "Manage system completely via SSH (will not install an agent)", then that will be a salt-ssh minion.
This is what I did: 1. Installed Uyuni. 2. Loaded the channels and created an activation key 3. Kickstarted an Alma Client.
Now I am trying add the Alma Server to the Uyuni system management. I did nothing further on the client assuming the WebUI boot strapping is doing everything.
Yes, it should. And if something is failing and you get that bar, it must be something at the logs, somewhere about it. In fact that usually means a Java exception on the logs. But since this a server based on AlmaLinux, I have no idea of why you can't see anything, if it's not because of the services not being restarted. Did you check the tomcat logs as well, just in case?
Best wishes,
Stefan
----- Ursprüngliche Mail ----- Von: "Julio Gonzalez"
An: "Victor Zhestkov" , "Stefan Bluhm" CC: "users" , "uyuni-users" Gesendet: Montag, 12. Juli 2021 13:05:09 Betreff: Re: Where to find bootstrap logs On lunes, 12 de julio de 2021 10:07:13 (CEST) Stefan Bluhm wrote:
Thank you both!
Julio, I added you to my linux god of the month list. I didn't realise "tail -f *" was possible. It would have saved me so much time in the past.
there were no entries for "tail -f /var/log/rhn/*"
But "tail -f /var/log/salt/*" gave in api ==> api <== 2021-07-12 10:02:17,312 [salt.utils.thin :289 ][WARNING ][1899] Module tornado is not a Python importable module with
2021-07-12 10:02:17,313
[salt.utils.thin :289 ][WARNING ][1899] Module msgpack is not a Python importable module with /usr/lib64/susemanager/py26-compat/msgpack 2021-07-12 10:02:17,364 [salt.utils.thin :282 ][WARNING ][1899] Module backports_abc configured with not a file or does not exist: /usr/lib/python2.7/site-packages/salt/ext/backports_abc.py 2021-07-12 10:02:17,365 [salt.utils.thin :303 ][ERROR ][1899] Missing dependencies for the alternative version in the external configuration: tornado, msgpack
Our salt experts should have a look, but I wonder:
a) What OS is installed at the client? Since py26 is mentioned, I guess CentOS6? b) How are you bootstrapping? WebUI? Script? c) What kind of client do you intend to bootstrap? SSH or regular salt minion?
In any case, both directories are provided by the compat packages:
m233:~ # rpm -qf /usr/lib64/susemanager/py26-compat/tornado py26-compat-tornado-4.2.1-53.2.uyuni1.x86_64
m233:~ # rpm -qf /usr/lib64/susemanager/py26-compat/msgpack py26-compat-msgpack-python-0.4.6-53.2.uyuni1.x86_64
Both should be installed, as dependencies for py26-compat-salt, which is part of the uyuni serve pattern. Do you have them installed?
So will chase up on those modules above.
Best wishes,
Stefan
Von: "Victor Zhestkov"
An: "opensuse org" , "Julio Gonzalez" CC: "users" , "uyuni-users" Gesendet: Montag, 12. Juli 2021 09:58:14 Betreff: Re: Where to find bootstrap logs Hi Stefan.
Please also check /var/log/salt/api.
Regards, Victor
On Mon, 2021-07-12 at 09:21 +0200, Stefan Bluhm wrote:
Thank you Julio,
I also expected a server error. But I do not see any relevant errors in the logs (or so I assume).
find . -type f -newer /tmp/$$ # all files changed today ./tasko/sat/notifications-cleanup-bunch/notifications-cleanup_15359_out ./tasko/sat/mgr-sync-refresh-bunch/mgr-sync-refresh_16848_err ./tasko/sat/mgr-sync-refresh-bunch/mgr-sync-refresh_16848_out ./tasko/sat/channel-repodata-bunch/channel-repodata_17057_out ./search/rhn_search.log ./search/rhn_search_daemon.log ./rhn_taskomatic_daemon.log
tomcat/local_access_log.2021-07-12.txt shows these consecutive lines: 192.168.0.152 - - [12/Jul/2021:07:33:06 +0200] "POST /rhn/manager/frontend-log HTTP/1.1" 200 16 192.168.0.152 - - [12/Jul/2021:07:44:53 +0200] "GET /rhn/errors/500.jsp HTTP/1.1" 500 -
/var/lib/pgsql/data/log/postgresql-Mon.log is empty.
So I guess, I have to up the log level, right?
Best wishes,
Stefan
----- Ursprüngliche Mail ----- Von: "Julio Gonzalez" < [ mailto:jgonzalez@suse.com | jgonzalez@suse.com ]
An: "uyuni-users" < [ mailto:uyuni-users@opensuse.org | uyuni-users@opensuse.org ] >, "users" < [ mailto:users@lists.uyuni-project.org | users@lists.uyuni-project.org ] > CC: "Stefan Bluhm" < [ mailto:opensuse.org@bluhm-de.com | opensuse.org@bluhm-de.com ] > Gesendet: Montag, 12. Juli 2021 08:50:08 Betreff: Re: Where to find bootstrap logs
On lunes, 12 de julio de 2021 7:48:43 (CEST) Stefan Bluhm wrote:
BQ_BEGIN
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".
In this case, this seems to be problem at the server, not at the client.
/var/log/rhn at the server is the place where you need to start looking. Most likely there will be an ISE (Internal Server error) there.
In some cases it could be interesting having a look at the tomcat log and PostgreSQL logs.
BQ_BEGIN
Thank you and best wishes,
Stefan
BQ_END
BQ_END
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com