131–140 of 152 posts
@authors The "Try it out" page shows nothing about where to get Cockpit or how to configure and run it. #plsfix
@authors The "Try it out" page shows nothing about where to get Cockpit or how to configure and run it. #plsfix
sudo apt-get install cockpitEarlier quoted context omitted.
Probably because these "security guides" just repeat what others said without any real consideration? In fact, using key-based authentication just shifts the weak point from one server to another, and, if implemented incorrectly (let's login without passwords to several servers - how convenient!), it's a security disaster. People need to think rather than follow recommendations blindly.
"Common knowledge" is a big problem in the security industry, like you mentioned. It's common knowledge that you need a 32 character randomly generated password with special characters and numbers and mixed case, right? But actually that's less secure, and now security folks have to work overtime to convince people otherwise. And it's common knowledge that passwords are super insecure and should be replaced, but ofte…
The real reason is passwords are weaker is first and fore most people. People reuse passwords or choose ones that are too short or simple that brute force becomes possible. If passwords where chosen at random and of proper of length they can be equally as strong as a key. Further, passwords basically functions the same as a key symmetric cryptography. People just don't like to memorize long random strings. (Although many apply key stretching since passwords may be of lower entropy).
Second when it comes HTTP it really only supports basic and digest authentication which is based on MD5, and further is susceptible to offline brute force attacks, and a down grade attacks to basic without TLS.
Thusly, most websites just send your password over TLS. However, because each site basically can handle passwords however they want they can store them in plain text. Secondly, if your TLS sessions is compromised you sent the password over over that connection it can be compromised. Sadly, the browsers don't support J-PAKE which by the way has an RFC.
https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exc...
I guess my point is password authentication can be just as secure, and really they are just shared secret crypto-systems. Problem is people choose low entropy passwords first and foremost. So just generating a key and saving locally avoids that issue.
Websites (HTTP) can use client X509 side certs as authentication and this gets rid users choosing bad passwords. However, if browsers implemented J-PAKE you don't have to worry about accidentally visiting the site via plain text will comprise your password or a comprised certificate authority. You could always validate the certificate yourself since we don't have something like J-PAKE in place.
For SSH long passwords can be just as strong, but you must verify the fingerprint matches your servers else you may get MITMed. Although if people see a server with SSH using password logins. They may try to brute force the password which may be annoying for the system admin. So the system admin enables key based authentication stop people from trying. Even though you have a high entropy password and your not worried about a brute force attack. The attacker does not know that so they will try anyways.
Personally I'd much rather see a GUI that can help string together snippets of Terraform/CFN and Ansible/Chef/Puppet/Salt/whathaveyou. A visual IDE for infrastructure automation, if you will.
And it worked both from the command line and the GUI. I can see no issues with it having a web interface as well.
Earlier quoted context omitted.
Cockpit uses hostnamed, networkmanager, and other services for configuration, not 'ip' or 'hostname'. Everything you can see is persistent.
Thank you very much for clearing this up. Since I'm not familiar with networkmanager in combination with other config: what happens if I configure some network interface using Cockpit that is already defined in /etc/network/interfaces.d/*? Will it just throw an error or could it bring my system into a broken/undefined state so that it wouldn't be reachable after the next reboot? If the latter is the case it would pro…
Debian appears to require a flag to enable this on its own: https://wiki.debian.org/NetworkManager#Enabling_Interface_Ma...
If it's enabled, networkmanager will parse out the files and present them over dbus, nmcli, etc. Changes with nmcli, gnome-network (which also uses NM), or other tooling will update the config files. The same ones in /etc/network/interfaces.d/
So, hypothetically:
auto eth0
iface eth0 inet static
address 192.168.40.112
netmask 255.255.255.0
gateway 192.168.40.1
dns-nameservers 8.8.8.8
If it's not enabled, Cockpit will not see the interfaces at all.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
This one seems to be tied to systemd...
Only for the journal and hostname functionalities, it should work fine for everything else without systemd.
Earlier quoted context omitted.
dubs means it will be linux only, maybe should write an agent that deals with dbus, meanwhile the agent can work with other OSes to provide info cockpit needs.
dbus-daemon works on BSDs too. There as a Linux-specific implementation of D-Bus called "dbus-broker", but that's an implementation of D-Bus, and Cockpit doesn't care about that at all.
It too, like Cockpit here (as shown at https://news.ycombinator.com/item?id=16448768), talks directly to the idiosyncratic systemd process #1 API (rather than, say, using the "service" command to start services on demand).
* https://github.com/bus1/dbus-broker/blob/07e43501e418c8066c7...
Earlier quoted context omitted.
cockpit is not dependent on systemd. They don't ship sysvinit scripts, but there's no hard dependencies on systemd anywhere. I'd expect that the system logging may not be very nice without journald, but the vast majority of the interface runs over dbus or spawns processes on the server. It _is_ dependent on dbus.
From their documentation, it certainly sounds like it is: > Cockpit uses systemd and the DBus APIs it provides to configure and monitor core aspects of the system. Use of alternate system APIs are not currently implemented. and > Cockpit configures the system time and time zone via the timedated daemon. To perform similar tasks from the command line use the timedatectl command That's a systemd specific daemon. http:/…
Its pretty, usable, friendly, however No one is going to use this to manage more then a few systems.
If you need to manage a large and diverse infrastructure you should also consider Mist.io: https://github.com/mistio/mist.io Disclaimer: I'm one of the founders