Error trying to bootstrap / register / onboard sles15sp3 salt client/minion
Hi List, i am trying to register a system to uyuni ( release 2022.05 https://dehwlluyunip01.claas.local/docs/en/release-notes/release-notes-serve... ). Installation of salt agent seems to work (both venv and classic), i can also accept salt key in uyuni, but after accepting there seems to be a communication problem when uyuni tries to onboard the client (create client profile: Here's some log regarding the issue: 2022-07-13 15:06:53,396 [salt-event-thread-3] WARN com.suse.manager.webui.services.impl.SaltService - Got no result for grains.items on minion dehwllhdb21.claas.local (minion did not respond in time) 2022-07-13 15:06:54,971 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-26] WARN com.suse.manager.webui.services.impl.SaltService - Got no result for grains.item on minion dehwllhdb21.claas.local (minion did not respond in time) 2022-07-13 15:06:54,971 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-26] ERROR com.suse.manager.reactor.messaging.RegisterMinionEventMessageAction - Aborting: needed grains are not found for minion: dehwllhdb21.claas.local 2022-07-13 15:06:57,369 [salt-event-thread-3] ERROR com.suse.manager.reactor.messaging.RegisterMinionEventMessageAction - Unable to find the server architecture for osfamily: '' and osarch: '' 2022-07-13 15:06:57,369 [salt-event-thread-3] ERROR com.suse.manager.reactor.messaging.RegisterMinionEventMessageAction - Error registering minion id: dehwllhdb21.claas.local java.lang.IllegalArgumentException: Unable to get the server architecture uyuni can ssh to the client and vice versa. can someone help me troubleshoot this issue? I have no more idea where to look and what to check/try :'( BR Heiner
Hi List, here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21") What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt* Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup ... and rebooted the client os. I tried bootstrapping with new venv salt and also the old salt-minion packages. I even tried using another network interface on my client, with another ip, net, route to uyuni. Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try? Thanks, Heiner
Hi Heiner. The original message from you contains the note that it was not able to detect the architecture of this server. It's better to check full grains.items output and check for the arch there (most probably `osarch`). I don't think the issue is related to the machine ID. Victor On Thu, 2022-07-14 at 08:22 +0000, Heiner W. wrote:
Hi List,
here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21")
What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e
What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt*
Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup
... and rebooted the client os.
I tried bootstrapping with new venv salt and also the old salt-minion packages.
I even tried using another network interface on my client, with another ip, net, route to uyuni.
Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try?
Thanks, Heiner
Hi Victor, thanks for your feedback. I also checked for arch. Only "osarch" seems to be relevant. It can also be queried from console as root without any problem and also doesn't look suspicious to me: # salt dehwllhdb21 grains.items|grep -A1 osarch osarch: x86_64 In the meantime i also rebooted my uyuni server, but still no progress - errors keep the same: Any more ideas, hints, suggestions? Thanks, Heiner Am Do., 14. Juli 2022 um 11:32 Uhr schrieb Victor Zhestkov via Uyuni Users < users@lists.uyuni-project.org>:
Hi Heiner.
The original message from you contains the note that it was not able to detect the architecture of this server. It's better to check full grains.items output and check for the arch there (most probably `osarch`). I don't think the issue is related to the machine ID.
Victor
On Thu, 2022-07-14 at 08:22 +0000, Heiner W. wrote:
Hi List,
here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21")
What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e
What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt*
Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup
... and rebooted the client os.
I tried bootstrapping with new venv salt and also the old salt-minion packages.
I even tried using another network interface on my client, with another ip, net, route to uyuni.
Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try?
Thanks, Heiner
In this case I would suggest cleanup the minion and trying to bootstrap again, but before the bootstrapping run the following command: salt-run state.event pretty=true | tee /var/salt-events.txt to capture the salt responses. Check rhn_web_ui.log for the errors and the events from the minion in the captured file maybe you will find the reason, or create an issue in https://github.com/uyuni-project/uyuni/issues with capture and logs attached. Victor On Thu, 2022-07-14 at 12:13 +0200, Heiner Wulfhorst wrote:
Hi Victor,
thanks for your feedback. I also checked for arch. Only "osarch" seems to be relevant. It can also be queried from console as root without any problem and also doesn't look suspicious to me: # salt dehwllhdb21 grains.items|grep -A1 osarch osarch: x86_64
In the meantime i also rebooted my uyuni server, but still no progress - errors keep the same:
Any more ideas, hints, suggestions?
Thanks, Heiner
Am Do., 14. Juli 2022 um 11:32 Uhr schrieb Victor Zhestkov via Uyuni Users
: Hi Heiner.
The original message from you contains the note that it was not able to detect the architecture of this server. It's better to check full grains.items output and check for the arch there (most probably `osarch`). I don't think the issue is related to the machine ID.
Victor
On Thu, 2022-07-14 at 08:22 +0000, Heiner W. wrote:
Hi List,
here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21")
What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e
What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt*
Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup
... and rebooted the client os.
I tried bootstrapping with new venv salt and also the old salt- minion packages.
I even tried using another network interface on my client, with another ip, net, route to uyuni.
Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try?
Thanks, Heiner
Hi Victor, thanks again, great hint with state.event! I'm new to salt, seems like a tool that will generally be handy in future! In this case unfortunately it didn't show anything interesting, besides the fact that uyuni is using user "admin" and if using salt on bash it shows my personal uyuni os system account. So i created this bug report, hope it helps :-/ https://github.com/uyuni-project/uyuni/issues/5669 BR Heiner Am Do., 14. Juli 2022 um 13:40 Uhr schrieb Victor Zhestkov < vzhestkov@suse.com>:
In this case I would suggest cleanup the minion and trying to bootstrap again, but before the bootstrapping run the following command: salt-run state.event pretty=true | tee /var/salt-events.txt
to capture the salt responses. Check rhn_web_ui.log for the errors and the events from the minion in the captured file maybe you will find the reason, or create an issue in https://github.com/uyuni-project/uyuni/issues with capture and logs attached.
Victor
On Thu, 2022-07-14 at 12:13 +0200, Heiner Wulfhorst wrote:
Hi Victor,
thanks for your feedback. I also checked for arch. Only "osarch" seems to be relevant. It can also be queried from console as root without any problem and also doesn't look suspicious to me: # salt dehwllhdb21 grains.items|grep -A1 osarch osarch: x86_64
In the meantime i also rebooted my uyuni server, but still no progress - errors keep the same:
Any more ideas, hints, suggestions?
Thanks, Heiner
Am Do., 14. Juli 2022 um 11:32 Uhr schrieb Victor Zhestkov via Uyuni Users
: Hi Heiner.
The original message from you contains the note that it was not able to detect the architecture of this server. It's better to check full grains.items output and check for the arch there (most probably `osarch`). I don't think the issue is related to the machine ID.
Victor
On Thu, 2022-07-14 at 08:22 +0000, Heiner W. wrote:
Hi List,
here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21")
What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e
What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt*
Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup
... and rebooted the client os.
I tried bootstrapping with new venv salt and also the old salt- minion packages.
I even tried using another network interface on my client, with another ip, net, route to uyuni.
Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try?
Thanks, Heiner
Hi List, hi Victor,
mbussolotto found the solution in
https://github.com/uyuni-project/uyuni/issues/5669 :
After increasing java.salt_presence_ping_timeout from default (4) to
10 and spacewalk-service
reload, uyuni was able to register that client.
It would really make sense if notification in uyuni or error in log would
say something about that parameter, because the documentation
https://www.uyuni-project.org/uyuni-docs/en/uyuni/specialized-guides/large-d...he
linked clearly says: "Tuning is not required on installations of fewer than
1000 clients. Do not perform these instructions on small or medium scale
installations." and we only have 62 clients right now.
Thanks,
BR,
Heiner
Am Do., 14. Juli 2022 um 16:09 Uhr schrieb Heiner Wulfhorst : Hi Victor, thanks again, great hint with state.event! I'm new to salt, seems like a
tool that will generally be handy in future!
In this case unfortunately it didn't show anything interesting, besides
the fact that uyuni is using user "admin" and if using salt on bash it
shows my personal uyuni os system account. So i created this bug report, hope it helps :-/
https://github.com/uyuni-project/uyuni/issues/5669 BR
Heiner Am Do., 14. Juli 2022 um 13:40 Uhr schrieb Victor Zhestkov <
vzhestkov@suse.com>: In this case I would suggest cleanup the minion and trying to bootstrap
again, but before the bootstrapping run the following command:
salt-run state.event pretty=true | tee /var/salt-events.txt to capture the salt responses. Check rhn_web_ui.log for the errors and
the events from the minion in the captured file maybe you will find the
reason, or create an issue in
https://github.com/uyuni-project/uyuni/issues with capture and logs
attached. Victor On Thu, 2022-07-14 at 12:13 +0200, Heiner Wulfhorst wrote: Hi Victor, thanks for your feedback. I also checked for arch. Only "osarch"
seems to be relevant. It can also be queried from console as root
without any problem and also doesn't look suspicious to me:
# salt dehwllhdb21 grains.items|grep -A1 osarch
osarch:
x86_64 In the meantime i also rebooted my uyuni server, but still no
progress - errors keep the same: Any more ideas, hints, suggestions? Thanks,
Heiner Am Do., 14. Juli 2022 um 11:32 Uhr schrieb Victor Zhestkov via Uyuni
Users Hi Heiner. The original message from you contains the note that it was not
able to
detect the architecture of this server. It's better to check full
grains.items output and check for the arch there (most probably
`osarch`). I don't think the issue is related to the machine ID. Victor On Thu, 2022-07-14 at 08:22 +0000, Heiner W. wrote: Hi List, here's some additional Information regarding my problem ("Error
registering minion id: dehwllhdb21") What confuses me the most: Uyuni integrated salt master is able
to
work with said client/minion:
# salt dehwllhdb21 cmd.run date
dehwllhdb21:
Thu Jul 14 09:37:22 CEST 2022
# salt dehwllhdb21 grains.items|wc -l
10118
# salt dehwllhdb21 grains.items|grep -A1 'id:'
gid:
0
id:
dehwllhdb21
lsb_distrib_id:
SLES
machine_id:
a0a85c7a8e4c611fa66868da62cfc837
pid:
5881
server_id:
444072978
uid:
0
uuid:
0a024321-7508-5d5c-8f34-dc250ec0c11e What i already tried:
I removed any salt rpm and config from client several times
before
each bootstrap retry:
# zypper remove -y venv-salt-minion salt*
# rm -rf /etc/venv-salt-minion* /etc/salt* Also regenerated system uid:
# rm /etc/machine-id /var/lib/dbus/machine-id
# dbus-uuidgen --ensure
# systemd-machine-id-setup ... and rebooted the client os. I tried bootstrapping with new venv salt and also the old salt-
minion
packages. I even tried using another network interface on my client, with
another ip, net, route to uyuni. Why can't uyuni register the client (get its data/grains) but
directly using salt as root in bash from uyuni seems to work
great?
What else could i try? Thanks,
Heiner
participants (3)
-
Heiner W.
-
Heiner Wulfhorst
-
Victor Zhestkov