This is cool, but there's no information on how to set it up. Am I missing something?
Cockpit – Administer Linux servers via a web browser
81–90 of 152 posts
Re: Cockpit – Administer Linux servers via a web browser
#821. Anyone remember Webmin?
2. Seems to rely heavily on Systemd being present...
Re: Cockpit – Administer Linux servers via a web browser
#83What's different between this and Webmin?
This one seems to be tied to systemd...
Re: Cockpit – Administer Linux servers via a web browser
#84This is cool, but there's no information on how to set it up. Am I missing something?
I recently spun up a Debian 18.04 server to play with the beta. Installing it on that system was as easy as:
sudo apt install cockpit
Re: Cockpit – Administer Linux servers via a web browser
#85Earlier quoted context omitted.
>what exactly do you mean by "just shifts the weak point ... to another"? I'm not the person who made that argument, but I can give you my reasoning to support it. Your key is on your laptop and unlocks your server, now your server is safe. But your laptop is just secured with a password. I brute-force the password on your laptop, and now I have no barriers preventing me from accessing your server. Your server is sec…
> But you also have to protect your keys and any machine those keys are installed on, otherwise you're just shifting the weak point to another machine. I’m okay with this, personally. What’s riskier: a public server listening on port 22 for any SSH traffic or my personal laptop which doesn’t accept random requests from the entire internet and is almost never out of my sight? And even if someone compromised my machine…
Your laptop, maybe. It sounds like you understand security, which is good. Not everyone does. I'll give you an example:
I have a picture I like to use in my presentations where I was at a mostly-empty family restaurant and the person sitting next to me (alone) had their laptop sitting out and went to the bathroom without even locking the screen. In 15 seconds I could have popped in a USB drive and copied all of his SSH keys (and more) without anyone ever noticing. It could have been done before he even reached the bathroom door, let alone came back. I don't think you would do this, of course, but some people do. And your coworkers might.
On top of that, about 25%-30% of security incidents are caused by insider threats. Considering how easy attacks over the Internet are, that's an absolutely massive number. Even if your laptop never leaves your desk, it's entirely possible someone within your company might want to do some harm to you or the company and it might be the desktop support technician hooking up your new monitor while you grab another cup of coffee.
Your point about what's riskier is completely true: if you have Internet-facing servers using passwords, stop that and use keys. But when you do that, you need to study up on the new risks you may not be aware of. Security shouldn't just be a curtain you close. Companies/people who don't understand this love paying me shitloads of money to explain it to them :)
Re: Cockpit – Administer Linux servers via a web browser
#86This looks really awesome but the thing that i feel is missing from the website is simply what is it capable of doing? Like I want a list of features that it is capable of so I can evaluate whether or not I may have use for it.
Re: Cockpit – Administer Linux servers via a web browser
#87Earlier quoted context omitted.
A better idea would be to spit out a spec that tools could use to perform the thing, and get tools to follow the spec. Unfortunately, even though most tools do virtually the exact same thing, they all use their own incompatible ways to describe it in a config. I'm not sure why devs enjoy reinventing the wheel in incompatible ways all the time. For example: you have Puppet, Chef, Ansible, Salt, etc. They can all make…
because most of these systems also support non-Unixy target systems
All the non-Unixy targets are POSIX compliant so the majority of the basic functionality is the same. All the other stuff like package management will vary among distros anyway, so they can just add extra portability glue for more complicated functions.
Re: Cockpit – Administer Linux servers via a web browser
#88Earlier quoted context omitted.
Cockpit itself is trying to be a "platform of sorts for modules to hook into. oVirt, for example, will install a cockpit plugin during installation of a hypervisor node allowing you to manage the local host or global cluster maintenance state and see how many VM's are running on the system (I would argue this is of limited benefit since you could just login to the oVirt Admin portal to do the same thing, but hey). So…
I'm the maintainer of the oVirt plugin. The real advantage of it is that it allows installation of hosted engine easily, and a 'single pane' overview of a host (oVirt Node status without using nodectl, etc) Since Cockpit wants to deal with dbus, the push is for other utilities (postfix, snmpd, etc) to publish relevant information over dbus, rather than teaching Cockpit the format of each and every configuration file…
Never realized it was even possible to do a hosted engine deployment via Cockpit, that's certainly useful (I've always just used hosted-engine --deploy from the command line because that's how I've done it since the 3.x days).
Do you have a link to a video of the presentation?
Re: Cockpit – Administer Linux servers via a web browser
#89Cockpit looks cool, but I'm using the new Jupyter Lab as a pretty awesome Python remote web shell. Access to a terminal, file explorer, and editor covers most everything I need and being able to run Python/Shell code in cells has covered most everything else.
Re: Cockpit – Administer Linux servers via a web browser
#90How much of an added security risk does adding a web-based admin interface (to the usual ssh tunnel) represent?
You could bind the web service to the loopback interface of the server. This way it cannot be accessed directly from the internet. Then you can use SSH port forwarding to access it from the web browser on your local machine.
How much overlap is there between the users who know how to do that and the users who need a Web-based control panel, though?