spacecmd doesn't work after migration to Uyuni container migration

ppanon2022 commented 2 days ago

Problem description

I don't seem to be able to use spacecmd from within the container context with a config file. After running mgrctl term,

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://<server.fqdn>/rpc/api

I also tried to use localhost and uyuni-server.mgr.internal as the server value, but neither worked. 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.

/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.

While I could add a policy to allow the relabeling, that seems like it would significantly reduce the security of the container with no assurance it's actually the root cause.

Steps to reproduce

Migrate Uyuni installation to container
Recreate spacecmd config file in /root/.spacecmd/config, including server, username, password, and nossl key-value pairs
Run spacecmd

This fails to connect with nossl set to either true or false ...

Uyuni version

Running 2024.08 container

Uyuni proxy version (if used)

No response

Useful logs

See description

Additional information

Also see my more detailed testing in these replies to the migration Github discussion

ppanon2022 commented 2 days ago

Attempting to telnet to port 80 on the host FQDN from within the container just hangs. Perhaps some sort of firewall rule, though there seems to be none on the host.

Attempting to use localhost to bypass any firewalling shows a redirect to uyuni-server.mgr.internal, but then trying to connect to uyuni-server.mgr.internal and do a get /pub shows the exact same 301 reply message.

uyuni-server:~ # telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET /pub
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://uyuni-server.mgr.internal/pub/">here</a>.</p>
</body></html>
Connection closed by foreign host.

agraul commented 2 days ago

It's not a firewall, it's the so-called "hairpin problem". By using the FQDN of the server from within the container, the network packets go container -> host -> container. This back-and-forth is the problem.

Inside the container localhost should be used instead of the FQDN.

ppanon2022 commented 1 day ago

localhost doesn't work for me either. You can see the results with that server name (as well as trying uyuni-server.mgr.internal which probably shouldn't do a container/host hairpin) and using telnet to test the HTTP response for more detail in these replies to the migration Github discussion

uyuni-project / uyuni