Unauthorized when trying to to connect to NS8 for migration

NethServer Version: 7.9.2009
Module: NS8 Migration

I’m trying to migrate to a machine that is installed on Proxmox with Debian 12.

When running the command echo ‘{“action”:“login”,“Host”:“FQDN”,“User”:“Administrator”,“Password”:“*********”,“TLSVerify”:“disabled”}’ | /usr/bin/setsid /usr/bin/sudo /usr/libexec/nethserver/api/nethserver-ns8-migration/connection/update | jq

The node log says
ns8-join: HTTP Error 401: Unauthorized.
The logs say [AUTH] redis authentication failed for user Administrator: WRONGPASS invalid username-password pair or user is disabled

And the log for traefik
2024-11-06T11:04:31+01:00 [1:traefik1:traefik] 192.168.0.1 - - [06/Nov/2024:10:04:31 +0000] “POST /cluster-admin/api/login HTTP/1.1” 401 67 “-” “-” 835 “ApiServer-https@file” “http://127.0.0.1:9311” 51ms

I’ve checked everything and credentials are correct and the account is active. I created a different user and it gives the same error message.

Isn’t the default user on NS8 “admin”. There is an “Administrator” account, but it’s disabled.

Cheers.

I found the password I had used for the admin account and I came one tiny step forward.
It now got a timeout when running this command

echo ‘{“action”:“login”,“Host”:“fqdn”,“User”:“admin”,“Password”:“Password in clear text”,“TLSVerify”:“disabled”}’ | /usr/bin/setsid /usr/bin/sudo /usr/libexec/nethserver/api/nethserver-ns8-migration/connection/update | jq

When I came back to it today I get this error message on NS7
bild
as if the migration had completed but nothing has actually been done yet.

@EddieA Do you have any idea what is causing this problem?

Can you ping the wireguard IP of NS8 from the NS7?

To check the wireguard connection on NS8 or NS7 you could use the wg command.

On the NS8, do you get more entries than one?

redis-cli keys node/*/vpn

There was a bug but it should already be fixed. Maybe you need to adapt the WG IPs manually.

To begin with I just want to inform you that I gave up and uninstalled the installation and then ran the installation again including to download the latest files. My NS7 is also completely updated.
No down to business.
I can ping between the servers using their hostnames but not on the ns8/wg0 IP.

When I ran the initial setup it ran fine until i got a timeout and after that can’t I connect to it again.

On NS7 it looks as I would except

ns8: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.5.4.2/32 scope global ns8
valid_lft forever preferred_lft forever
inet6 fe80::83e9:955f:cdfb:afd1/64 scope link flags 800
valid_lft forever preferred_lft forever

On NS8 I get this output.

wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.5.4.1/32 scope global wg0
valid_lft forever preferred_lft forever

So far so good as far as I can see.
When I run redis-cli keys node/*/vpn I get this response.

  1. “node/2/vpn”
  2. “node/1/vpn”

Please check the wireguard connection on NS7 and Ns8 using the following command:

wg

The wireguard IPs have to match the allowed IPs on the other side.

You could check and edit the config files and restart the services as explained here.

I checked the configuration and it has the same IP on both sides, redis has two records but from what I understand that shouldn’t cause any problems.
It worked when I tried again to ping ns8 → wg0 , maybe I tried in the wrong direction earlier.

When I reload the migration page it throws this in the NS7 logs. I’ve reversed the order so read it from top to bottom.

10:38 root : TTY=unknown ; PWD=/run/user/0 ; USER=root ; COMMAND=/usr/libexec/nethserver/api/nethserver-ns8-migration/migration/read sudo
10:38 pam_unix(sudo:session): session opened for user root by root(uid=0) sudo
10:38 Traceback (most recent call last): cockpit-bridge
10:38 File “/usr/lib64/python3.6/urllib/request.py”, line 1349, in do_open cockpit-bridge
10:38 encode_chunked=req.has_header(‘Transfer-encoding’)) cockpit-bridge
10:38 File “/usr/lib64/python3.6/http/client.py”, line 1254, in request cockpit-bridge
10:38self._send_request(method, url, body, headers, encode_chunked) cockpit-bridge
10:38 File “/usr/lib64/python3.6/http/client.py”, line 1300, in _send_request cockpit-bridge
10:38 self.endheaders(body, encode_chunked=encode_chunked) cockpit-bridge
10:38 File “/usr/lib64/python3.6/http/client.py”, line 1249, in endheaders cockpit-bridge
10:38 self._send_output(message_body, encode_chunked=encode_chunked) cockpit-bridge
10:38 File “/usr/lib64/python3.6/http/client.py”, line 1036, in _send_output cockpit-bridge
10:38 self.send(msg) cockpit-bridge
10:38 File “/usr/lib64/python3.6/http/client.py”, line 974, in send cockpit-bridge
10:38 self.connect() cockpit-bridge
10:38 File “/usr/lib64/python3.6/http/client.py”, line 946, in connect cockpit-bridge
10:38 (self.host,self.port), self.timeout, self.source_address) cockpit-bridge
10:38 File “/usr/lib64/python3.6/socket.py”, line 724, in create_connection cockpit-bridge
10:38 raise err cockpit-bridge
10:38 File “/usr/lib64/python3.6/socket.py”, line 713, in create_connection cockpit-bridge
10:38 sock.connect(sa) cockpit-bridge
10:38 socket.timeout: timed out cockpit-bridge
10:38 During handling of the above exception, another exception occurred: cockpit-bridge
10:38 Traceback (most recent call last): cockpit-bridge
10:38 File “/usr/sbin/ns8-action”, line 104, in cockpit-bridge
10:38 resp = request.urlopen(req, timeout = 20) cockpit-bridge
10:38 File “/usr/lib64/python3.6/urllib/request.py”, line 223, in urlopen cockpit-bridge
10:38 return opener.open(url, data, timeout) cockpit-bridge

Ping should work in both directions.

Do you still get the “Error retrieving apps to migrate” error in NS7 UI?

Maybe it helps to abort the migration and start over with a new one.

It looks like NS7 can’t establish the connection to NS8.

I got and idea from your response, the problem was with the firewall on Debian. I’ve shut it down temporarily now and can see the migration options.
Now I need to check everything at least three times to avoid running into problems after the migration.

2 Likes