Hi all,
Recently, we have been doing some experiments to run YaST as a privileged container and being able to change the host[1]. Of course, it does not work out of the box, but we found out that it might be possible to make it work. So you would not need Ruby (or its libraries) to be installed on the host.
Along with that experiment, I was thinking whether it was possible to do something similar with Cockpit. I saw that you had a discussion in 2014[2], but I do not know which was the final outcome.
On the other hand, I recently read the "minimal cockpit packages for target node" thread and I it sounds pretty cool. Do you have any concrete plans for that? Can we help in any way?
Just to summarize, we would like to monitor/configure the host system (with no Cockpit at all) from a container and I was unsure whether you already had solved that problem :-) Any comment is welcome.
Thanks!
[1] https://github.com/lslezak/yast-container [2] https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste... [3] https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste...
Hello Imobach,
Imobach Gonzalez Sosa [2022-05-18 12:40 +0000]:
Along with that experiment, I was thinking whether it was possible to do something similar with Cockpit. I saw that you had a discussion in 2014[2], but I do not know which was the final outcome.
The "cockpit/ws" container [1] has existed for a long time to do part of that. I.e. you don't need to run the web server on the host. But the container will connect to the host via SSH, so the host still needs to have cockpit-bridge and some pages (like cockpit-system) installed.
On the other hand, I recently read the "minimal cockpit packages for target node" thread and I it sounds pretty cool. Do you have any concrete plans for that? Can we help in any way?
Plans, yes. Unfortunately our Jira is not accessible from outside, but the summary is that:
- We plan to port cockpit-bridge to Python, and send it to the target system from cockpit's web server (container or Flatpak) if the target system does not have it.
- The flatpak, or possibly also cockpit/ws (perhaps in a "fat" variant/tag) can bundle at least some pages, and then use these instead of loading them from the host.
Just to summarize, we would like to monitor/configure the host system (with no Cockpit at all) from a container and I was unsure whether you already had solved that problem :-) Any comment is welcome.
We have the idea above, and a prototype for the Python bridge [2], but it's still going to be a lot of work. If we had little else to do, we could probably finish this in a few weeks even, but it's a low-priority project (i.e. we really like it, but it's less important than other more business critical projects).
So I'm afraid don't hold your breath for it right now, and I'd rather recommend to look for a shortcut. Possibly:
- Bundle up cockpit-bridge, cockpit-system, cockpit-yast, etc. into a cockpit/ws derived container - Start the container on the target system - podman cp out cockpit-bridge and /usr/share/cockpit/ and copy them to /usr/local/ or ~yastinstalleruser/{bin,.share/local}. Or play some dirty tricks with volumes, and have your container copy the files into a given volume on startup.
Copying the pages is reasonably uncritical. cockpit-bridge would need the correct runtime libraries/dependencies, but in your controlled environment this should be possible. Could that work for you?
Pitti
[1] https://quay.io/repository/cockpit/ws [2] https://github.com/allisonkarlitskaya/cockpit/tree/bridge.py
El jue, 19-05-2022 a las 16:03 +0200, Martin Pitt escribió:
Hello Imobach,
Hi Martin,
First of all, thanks for such a detailed answer!
[..]
The "cockpit/ws" container [1] has existed for a long time to do part of that. I.e. you don't need to run the web server on the host. But the container will connect to the host via SSH, so the host still needs to have cockpit- bridge and some pages (like cockpit-system) installed.
Yes, I knew that one; I have played a bit with that container and it looks fine, but it is a partial solution.
On the other hand, I recently read the "minimal cockpit packages for target node" thread and I it sounds pretty cool. Do you have any concrete plans for that? Can we help in any way?
Plans, yes. Unfortunately our Jira is not accessible from outside, but the summary is that:
- We plan to port cockpit-bridge to Python, and send it to the target system from cockpit's web server (container or Flatpak) if the target system does not have it.
- The flatpak, or possibly also cockpit/ws (perhaps in a "fat" variant/tag) can bundle at least some pages, and then use these instead of loading them from the host.
Thanks for sharing those plans: they sound great. I would say that salt-ssh[1] does something similar by copying some stuff to the target system, so Python is the only dependency. And I guess it is rather unrealistic to do not depend on Python.
We have the idea above, and a prototype for the Python bridge [2], but it's still going to be a lot of work. If we had little else to do, we could probably finish this in a few weeks even, but it's a low-priority project (i.e. we really like it, but it's less important than other more business critical projects).
It actually looks like a lot of work, but it is good that it is somehow on the radar.
So I'm afraid don't hold your breath for it right now, and I'd rather recommend to look for a shortcut. Possibly:
- Bundle up cockpit-bridge, cockpit-system, cockpit-yast, etc. into a cockpit/ws derived container - Start the container on the target system - podman cp out cockpit-bridge and /usr/share/cockpit/ and copy them to /usr/local/ or ~yastinstalleruser/{bin,.share/local}. Or play some dirty tricks with volumes, and have your container copy the files into a given volume on startup.
Copying the pages is reasonably uncritical. cockpit-bridge would need the correct runtime libraries/dependencies, but in your controlled environment this should be possible. Could that work for you?
Yes, it *might* work, although we might still need the dependencies on the host system. In that case, I would say that sticking to the cockpit/ws solution might be better. We will play around and see how far we can get.
Thanks *a lot* for your help!
Regards, Imo
[1] https://docs.saltproject.io/en/latest/topics/ssh/index.html
El vie, 20-05-2022 a las 08:20 +0000, Imobach Gonzalez Sosa escribió:
Thanks for sharing those plans: they sound great. I would say that salt-ssh[1] does something similar by copying some stuff to the target system, so Python is the only dependency. And I guess it is rather unrealistic to do not depend on Python.
Well, my comment is not actually true (and I noticed after I pushed the "send" button :-)). If you push a container/flatpak, there is no dependencies problem.
[..]
cockpit-devel@lists.fedorahosted.org
-
Imobach Gonzalez Sosa -
Martin Pitt