Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cockpit: Web-based graphical interface for servers

cockpit-project.org

Post reply on HN
Print view View original

91–100 of 199 posts

Re: Cockpit: Web-based graphical interface for servers

#91

Post by jeroenhd »

lopkeny12ko wrote: post #54
Karrot_Kream wrote: post #52

Earlier quoted context omitted.

> Where would you not be able to open a terminal emulator? I am so confused. A mobile device. I don't use terminal emulators without access to some non-touch keyboard so I want a simple interface on my mobile device. > That cockpit is very limited and seemingly has no future does not mean you can't like what it does now. Just might be worth considering if there are better-supported alternatives. Sure then compare coc…

Terminal emulators, which can run SSH clients, are absolutely possible on a mobile device. https://termux.dev/en/

I use Termux to do SSH once in a a while. It makes me want to install a web UI to be honest. Most of the time I'm fumbling my long sudo password to restart some systemd service that crashed or manually running a maintenance script, that stuff is a massive pain on touch screens.

Re: Cockpit: Web-based graphical interface for servers

#93

Post by jelly1 »

fulafel wrote: post #23

For others curious, https://github.com/cockpit-project/cockpit shows that it's written in several languages, with C at the #1 place, with JS and Python following. "src/cockpit" (main backend logic?) is Python.

Cockpit Developer here, the webserver is written in C and the old bridge (the one "API" which communicates with JavaScript through the webserver with system API's such as systemd, podman, dbus, etc.).

The new bridge is written in Python and when time comes we want to rewrite our webserver into some modern.

Re: Cockpit: Web-based graphical interface for servers

#95

Post by dale_glass »

arghwhat wrote: post #48
barosl wrote: post #36

The cool thing about this project is that as it uses systemd's socket activation, it requires no server processes at all. There is no waste of resources when Cockpit is not being used. Accessing a page is literally the same as invoking a command-line tool (and quitting it). No more, no less. What a beautiful design.

To be fair, we've had this since BSD4.3 (1986) through inetd - which worked slightly differently, but same overall idea. Once popular, it fell out of fashion because... Well, there isn't really any reason for it. A good server process is idle when nothing is happening, and should be using miniscule real memory that should be easy to swap out. If the server in question uses significant memory for your use-case, you al…

There's good reasons for it though!

One is boot performance. Another is zero cost for a rarely used tool, which may be particularly important on a VPS or a small computer like a Raspberry Pi where you don't want to add costs for something that may only rarely be needed.

I think a nice benefit for an administrative tool is the ability to update it, and reload the updated version. You don't need the tool to have its own "re-exec myself" code that's rarely used, and that could fail at an inconvenient time.

The reason why inetd didn't stick is because it's a pain to use -- it's separated from SysV init, so it needs to be very intentionally set up. Plus there was the inetd/xinetd disagreement.

Tying in init, inetd and monit into a single system that can do all those things IMO made things much nicer.

Re: Cockpit: Web-based graphical interface for servers

#96

Post by jelly1 »

Cthulhu_ wrote: post #69
fs0c13ty00 wrote: post #61

I can't imagine myself using this. One more port open, one more attack vector for those restless bots to scan for vulnerabilities, one more service I need to keep up-to-date. But I understand it would help Linux servers become more approachable, especially people that are switching away from PHP-based shared hosting to a full-featured VPS, don't have much knowledge about servers, and want something similar to cPanel…

You don't have to open up a port, you can use a VPN or SSH tunnel (I don't know what the difference is) instead.

With Cockpit Client this is not even required it will do the SSH magic for you.

https://flathub.org/apps/org.cockpit_project.CockpitClient

Re: Cockpit: Web-based graphical interface for servers

#97

Post by BodyCulture »

jarym wrote: post #87
shortrounddev2 wrote: post #80

Earlier quoted context omitted.

I think there's an elitism within the Linux world to being a totally CLI user

There does seem to be a bit of it yes, but I thought it had become less common. Reminds me of a colleague I met once who was happily boasting he's a 'real' HTML developer because he writes everything in Microsoft notepad. I took a look at his work and cried inside - broken tags, bad formatting and of course he didn't escape all his characters correctly. Being able to type some characters on a keyboard does not make a…

Diff is to type you need to have better understanding, what is good for IT work.

Re: Cockpit: Web-based graphical interface for servers

#98

Post by dale_glass »

smetj wrote: post #46
tanelpoder wrote: post #41

Earlier quoted context omitted.

I ended up reading more about this and looks like SSHD in Ubuntu 22.10 and later also uses systemd socket activation. So there should be no sshd process(es) started until someone SSHs in! https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...

Certainly for SSH I find this a bad idea. If you need to ssh into a troubled machine then it might very well be it cannot be started.

If it's so troubled that a process won't start, it's probably time to reach for the IPMI console. Even if ssh is still running, if the system is that broken, is bash going to start, or what tools you might need?

Re: Cockpit: Web-based graphical interface for servers

#99

Post by leetrout »

There is value in "porcelain"[0]

I have watched startups fold for not pushing product development further into UI/UX with off the shelf backends. At one company I worked at I showed how our backend (completely custom container orchestrator) could be replaced in a weekend with AWS Lambda and ECS. But our UI/UX and workflow tools would take much, much longer. Yet we continued to waste money and time on "building a new raft based cluster". In the mean time I was handed "add batch processing" and we already used Go so I just used Nomad under the hood and moved on.

I like working on teams that ship features not JUST tech for tech's sake.

https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

Re: Cockpit: Web-based graphical interface for servers

#100

Post by darkwater »

notpushkin wrote: post #42
barosl wrote: post #36

The cool thing about this project is that as it uses systemd's socket activation, it requires no server processes at all. There is no waste of resources when Cockpit is not being used. Accessing a page is literally the same as invoking a command-line tool (and quitting it). No more, no less. What a beautiful design.

systemd-cgi :^)

It was/is inetd[1] actually

[1] https://en.wikipedia.org/wiki/Inetd

Post reply on HN