4 ms·

Does it work on non fedora/redhat? Does it need an agent on managed systems? I'm developing a somewhat similar system[1], based purely on very easy to develop

Does it work on non fedora/redhat? Does it need an agent on managed systems? I'm developing a somewhat similar system[1], based purely on very easy to develop plugins, agentless, and integration with third parties where needed (Prometheus, for example).But without big corporate backup it is being difficult to keep the development pace. [1] https://github.com/serverboards/serverboards/ https://github.com/serverboards/serverboards/

sifex 9y ago
Seems to work just fine on Debian as well. http://cockpit-project.org/running.html http://cockpit-project.org/running.html
jbreiding 9y ago
If this is the same as this site talks about, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_cockpit/index https://access.redhat.com/documentation/en-us/red_hat_enterp..., then it would seem to be a first class citizen.
guhcampos 9y ago
I've used it before on Ubuntu and it worked just fine. As far as I understand, Cockpit deals directly with Systemd and Docker, so any system based on Systemd should just work.
- evol262 9y ago
  Again, Cockpit does not explicitly deal with systemd. Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd. Docker is not required at all either, though it's an option.
  - JdeBP 9y ago
    That is directly contradicted by Cockpit's own doco, which explicitly states that Cockpit uses the systemd APIs and that "use of alternate system APIs are not currently implemented". * http://cockpit-project.org/guide/latest/feature-systemd.html http://cockpit-project.org/guide/latest/feature-systemd.html It should of course be obvious that Cockpit does explicitly deal with systemd. Desktop Bus is a transport layer, and the important thing about it is what DBus servers are on the other side of the broker are being talked to. In the case of Cockpit they are things like systemd's own idiosyncratic API for process #1 ... * https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/service.js#L97 https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14... ... systemd's hostnamed server ... * https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/machines.js#L275 https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14... * https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ ... and systemd's timedated server. * https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a229ff8ba0ff9189c2feab6285d1c/pkg/systemd/host.js#L68 https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a... * https://www.freedesktop.org/wiki/Software/systemd/timedated/ https://www.freedesktop.org/wiki/Software/systemd/timedated/ Cockpit also hardwires use of systemd's journalctl program. * http://cockpit-project.org/guide/latest/feature-journal.html http://cockpit-project.org/guide/latest/feature-journal.html * https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/journal.js#L101 https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
    - evol262 9y ago
      Yes, cockpit uses hostnamed and timedated. Plus journalctl, which I noted. I'm perfectly aware of how dbus works, and if you think that hostnamed or timedated have 'idiosyncractic' APIs, I'd challenge you to look at the API for glib. But it uses these because they are readily available over dbus. Not because cockpit has a hard dependency on systemd. While that functionality wouldn't work, it would be really trivial to write your own using cockpit.spawn() to call `date`... or `hostname ...` instead of hostnamed or timedated. The truth is that hostnamed and timedated are simply better than the CLI tools. However, I'm sure the Cockpit team would welcome a patch. More to the point, there is absolutely nothing in Cockpit which is explicitly using systemd APIs outside of dbus, and this would not be hard to work around. I know it's cool on HN to hate on systemd, but this is dumb. Cockpit already uses bare `hostname`: https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a229ff8ba0ff9189c2feab6285d1c/pkg/systemd/host.js#L555 https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a... It would be a 20 line patch to break the systemd "dependency" on hostnamed. This is not a project intrinsically linked to systemd. Even your hardwired "example" of journalctl is literally calling a process, which could just as easily be "cat /var/log/messages". It's 'hardwired' because systemd is the standard these days, whether you like it or not. However, extending the promise to simply do that if journalctl fails is trivial. Maybe your idea of 'hard' dependencies and mine are very different. To me, a 'dependency' on, say, Python, means that there are Python calls all over the place which a reliance on specific semantics. That means that stubbing it out for Ruby or Lua or whatever would be hard. It is not "we wrote our application with this in mind, but we could patch it into stubbable modules in 3 minutes".

sifex 9y ago

Seems to work just fine on Debian as well. http://cockpit-project.org/running.html http://cockpit-project.org/running.html

jbreiding 9y ago

If this is the same as this site talks about, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_cockpit/index https://access.redhat.com/documentation/en-us/red_hat_enterp..., then it would seem to be a first class citizen.

guhcampos 9y ago

I've used it before on Ubuntu and it worked just fine. As far as I understand, Cockpit deals directly with Systemd and Docker, so any system based on Systemd should just work.

evol262 9y ago
Again, Cockpit does not explicitly deal with systemd. Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd. Docker is not required at all either, though it's an option.
- JdeBP 9y ago
  That is directly contradicted by Cockpit's own doco, which explicitly states that Cockpit uses the systemd APIs and that "use of alternate system APIs are not currently implemented". * http://cockpit-project.org/guide/latest/feature-systemd.html http://cockpit-project.org/guide/latest/feature-systemd.html It should of course be obvious that Cockpit does explicitly deal with systemd. Desktop Bus is a transport layer, and the important thing about it is what DBus servers are on the other side of the broker are being talked to. In the case of Cockpit they are things like systemd's own idiosyncratic API for process #1 ... * https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/service.js#L97 https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14... ... systemd's hostnamed server ... * https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/machines.js#L275 https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14... * https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ ... and systemd's timedated server. * https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a229ff8ba0ff9189c2feab6285d1c/pkg/systemd/host.js#L68 https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a... * https://www.freedesktop.org/wiki/Software/systemd/timedated/ https://www.freedesktop.org/wiki/Software/systemd/timedated/ Cockpit also hardwires use of systemd's journalctl program. * http://cockpit-project.org/guide/latest/feature-journal.html http://cockpit-project.org/guide/latest/feature-journal.html * https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/journal.js#L101 https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
  - evol262 9y ago
    Yes, cockpit uses hostnamed and timedated. Plus journalctl, which I noted. I'm perfectly aware of how dbus works, and if you think that hostnamed or timedated have 'idiosyncractic' APIs, I'd challenge you to look at the API for glib. But it uses these because they are readily available over dbus. Not because cockpit has a hard dependency on systemd. While that functionality wouldn't work, it would be really trivial to write your own using cockpit.spawn() to call `date`... or `hostname ...` instead of hostnamed or timedated. The truth is that hostnamed and timedated are simply better than the CLI tools. However, I'm sure the Cockpit team would welcome a patch. More to the point, there is absolutely nothing in Cockpit which is explicitly using systemd APIs outside of dbus, and this would not be hard to work around. I know it's cool on HN to hate on systemd, but this is dumb. Cockpit already uses bare `hostname`: https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a229ff8ba0ff9189c2feab6285d1c/pkg/systemd/host.js#L555 https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a... It would be a 20 line patch to break the systemd "dependency" on hostnamed. This is not a project intrinsically linked to systemd. Even your hardwired "example" of journalctl is literally calling a process, which could just as easily be "cat /var/log/messages". It's 'hardwired' because systemd is the standard these days, whether you like it or not. However, extending the promise to simply do that if journalctl fails is trivial. Maybe your idea of 'hard' dependencies and mine are very different. To me, a 'dependency' on, say, Python, means that there are Python calls all over the place which a reliance on specific semantics. That means that stubbing it out for Ruby or Lua or whatever would be hard. It is not "we wrote our application with this in mind, but we could patch it into stubbable modules in 3 minutes".