I can't zoom in on the image gallery without it going insane and flipping through all the images. You should not cycle through the image on pinch-zoom.
Cockpit: Web-based graphical interface for servers
151–160 of 199 posts
Re: Cockpit: Web-based graphical interface for servers
#152I've been using this from time to time on my laptops repurposed as home servers. Mainly for monitoring. Spinning up a VM or container here and there. Too bad they removed Docker support. To hell with Podman.
Why to hell with podman? I'd rather use something not encumbered by shady licenses.
Re: Cockpit: Web-based graphical interface for servers
#153For 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.
Piggybacking off your comment I wonder how many other people really care about the tech stack used to create any product they are running on a server. What dependencies does it have? Do I need to be conscious of vulnerabilities in some logging library or Curl? And I also find it really interesting to see whether a product is programmed using one clear stack or a mixture.
I usually care a great deal, because it gives some strong hints up-front about what to expect from the project while trying it out and subsequently deploying it for production use.
I know some languages and ecosystems much better than others, so I have an idea how well I could support it up-front if needed. Others have different deployment styles, ranging all the way from "just copy this one binary somewhere" to "first install this language interpreter with a fricken curlpipe, then this language-specific package manager, then these hundreds of dependencies, then our app if you're still awake. But don't forget you'll still need an application server..."
The widespread use of Docker has made the last even less common, but I still run into docker containers just don't work, and I don't know the tech stack, and learning a whole tech stack just to troubleshoot someone else's broken code in order to try it out is not my most favoritest use of time.
Re: Cockpit: Web-based graphical interface for servers
#154People who decry graphical admin interfaces in favor of command line are missing the wood for the trees. Sure, clickops is no way to run a server - but neither, if we’re honest, is ssh. For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone. If you’re going in with ssh or cockpit you’re just going to screw something up. So the only r…
> For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone. I'm curious if you have a specific tool or tools in mind. I've been using Ansible in my home lab, particularly for configuring Raspberry Pis. The OS install part (only?) works because it involves a bitwise copy of the image to the boot media (and some optional configuration.)
I'd like to see a tool, maybe a Cocpit-like or a wrapper around SSH, that would build Ansible playbooks for you as you clicked around or typed commands.
Re: Cockpit: Web-based graphical interface for servers
#155The 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.
Also, it's 99% "not different than doing it via command line", and also comes with a little js terminal gui, uses native users + passwords, has some lightweight monitoring history, lets you browse a bunch of configuration that you usually would have to remember byzantine systemd command lines for... it's awesome for what it is!
I'm happy to run it (aka: have it installed) on all my little raspberry pi's, because sometimes I'm not at a terminal when I want to scope them out, and/or if I'm at "just a web browser", being able to "natively ssh into them" via a web server (and then run `curl ...etc...` from a "real" command prompt) is super helpful!
Re: Cockpit: Web-based graphical interface for servers
#156Earlier quoted context omitted.
Are there any tools that allow you to manage a server like a pet, yet ensure it can be restored/rebuild? And, while with the analogy of pets, when you are on holiday, allow your neighbors to look after your pets?
In my homelab, I use Portainer to manage my hosts. All of my workloads are installed as collections of Docker containers, and I'm slowly but surely migrating even single container installs to Compose stacks. With some real bare bones GitOps, those stack files can be in Git, and deploy to the host in Portainer, thus at least giving me the recipes to rebuild my environment should it ever be lost.
I've also stumbled into the same paradigm - everything as compose files checked into git, deployed onto portainer. IMO pretty nice and low maintenance.
Re: Cockpit: Web-based graphical interface for servers
#157Re: Cockpit: Web-based graphical interface for servers
#158The 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.
I thought the cool thing was all the rookies who install this thing in a way that it's publicly accessible. How many stories have I heard about people who accidentally configure phpMyAdmin to be publicly accessible... Now you might not JUST leak your whole customer DB!
Re: Cockpit: Web-based graphical interface for servers
#159Earlier quoted context omitted.
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 ow…
> Another is zero cost for a rarely used tool.
Zero cost is only true for unused services. For rarely used services, it's a rarely occuring full cost that might come by surprise at a bad time.
> I think a nice benefit for an administrative tool is the ability to update it, and reload the updated version.
This is only a benefit if the systemd socket unit is co figured to operate in inetd-mode (Accept=yes), where systemd spawns a new process for every accepted connection, which is quite inefficient resource-wise.
"Normal" systemd socket activation just starts the service and hands over the socket. The service runs indefinitely afterwards as if it was a normal service, and needs to be manually restarted or hot-reloaded after upgrade or configuration change.
> 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.
Being separated has a lot of benefits - easy nesting, easy reuse in minimal containers, etc. The integrated model works best for monolithic servers.
Re: Cockpit: Web-based graphical interface for servers
#160Pssh, grafana, and docker compose. Oh, ansible too