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

Cockpit – Administer Linux servers via a web browser

cockpit-project.org

Post reply on HN
Print view View original

121–130 of 152 posts

Re: Cockpit – Administer Linux servers via a web browser

#121

Post by kruffin »

thechriswalker wrote: post #48
kruffin wrote: post #40

Why does it require that the server has password logins enabled? This seems contrary to every "secure your server" guide I've seen and opens your server up to the password guessing game. It seems like a cool product, but that's a huge non-starter. The target server will need to have password based authentication enabled in sshd. When this is setup for the first time, Cockpit will ensure that the user connected to pri…

I don't think it does. That quote is from the section explaining how to configure "Password" authentication. i.e. to use Password authentication, you must enable it on the target server. It then goes on to list how to use Kerberos or Public Key methods.

Reading again, it does look like the installation is limited in some way if you choose to use public keys and your user doesn't have the privileges (without sudo) necessary for some of Cockpit's commands it tries to run.

Note that when a user is authenticated in this way [public key] the authentication happens without a password, as such the standard cockpit reauthorization mechanisms do not work. The user will only be able to obtain additional privileges if they do not require a password.

Re: Cockpit – Administer Linux servers via a web browser

#122

Post by wingworks »

excalibur wrote: post #22
fazza99 wrote: post #7

what was wrong with webmin? (ducks)

How to get recommendations for a software solution on HN: 1. Submit an Ask HN thread, and ask for advice. 2. Watch your thread get no response or interest from anybody. 3. Give up on HN and go build your own solution. 4. When it's ready, submit it to HN to help others in your situation. 5. The recommendations you were looking for will appear in the comments.

Haha, it's scary how close to reality this is. At least for me.

Re: Cockpit – Administer Linux servers via a web browser

#123

Post by kilburn »

peterwwillis wrote: post #117
icebraining wrote: post #105

Earlier quoted context omitted.

Can you explain a bit further how do you see that working? I use CM because I want to control the app; I want to tell it where it should store its logs (so I can process them), where it should store its data (so I can back it up), which ports it should use (so I can point my reverse proxy at it), etc. If the app just asks for stuff, where would the management part come it? And why have a CM at all? Granting resources…

A traditional CM tool in this new paradigm (which i'm coining App Management before somebody steals the idea) would probably become more of a configuration fulfiller (CF) in this context. It fulfills the configuration requirements that the app dictates. The CF could modify its behavior to fit a given platform. If you're on Windows, it will do operation X in one way, and on Linux a different way. You could describe to…

Your ideas resonate a lot with dependency injection [1] to me. However, I don't see how such an "App manager" would be able to setup, for instance, an nginx server with multiple virtual hosts.

Some applications need entire configuration languages because they are so flexible that writing some ini/json/xml quickly becomes too cumbersome. How would your system deal with those problems?

Finally, your proposed solution seems to suffer from having to adapt all applications to be able to manage them. This is impractical to say the least, and if you had the resources to take that adventure... I think you'd be better off turning to something like Nix

https://en.wikipedia.org/wiki/Dependency_injection

Re: Cockpit – Administer Linux servers via a web browser

#124

Post by jniles »

burdzwastaken wrote: post #107
happyhotpocket wrote: post #104

Maybe I'm just missing something but where is the name of the package? How do I install this? Is it an `apt-get install cockpit`? I don't see that written anywhere obvious.

click your distribution (I assume Ubuntu?) here to reveal the way to install it http://cockpit-project.org/running.html . if you are running Ubuntu seems to require backports for anything below 17.04 though.

I also had this question and it took me about 5 minutes to figure out that you needed to click to reveal. It's fancy, but not at all practical. Hopefully someone updates it to just a flat list.

Re: Cockpit – Administer Linux servers via a web browser

#125

Post by icebraining »

peterwwillis wrote: post #117
icebraining wrote: post #105

Earlier quoted context omitted.

Can you explain a bit further how do you see that working? I use CM because I want to control the app; I want to tell it where it should store its logs (so I can process them), where it should store its data (so I can back it up), which ports it should use (so I can point my reverse proxy at it), etc. If the app just asks for stuff, where would the management part come it? And why have a CM at all? Granting resources…

A traditional CM tool in this new paradigm (which i'm coining App Management before somebody steals the idea) would probably become more of a configuration fulfiller (CF) in this context. It fulfills the configuration requirements that the app dictates. The CF could modify its behavior to fit a given platform. If you're on Windows, it will do operation X in one way, and on Linux a different way. You could describe to…

OK, I get what you're saying. I'd say we already have an API for that: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

When I apt-get install most applications, I don't need to tell them where they should put their logs, they just the mkdir('/var/log/...') API. I don't see us gaining much by adding another man-in-the-middle to translate a logfiles(X) call to mkdir('/var/log/app')/open('/var/log/app/'+'/var/log/'+X).

The reason I use a CM is mostly to configure the system itself (such as - which apps I want installed in the first place) and to define application-specific configurations, which a configuration fulfiller would have no way of knowing how to do.

The app knows what ports it wants to offer.

No, the app knows what services it wants to offer; ports are shared resources, so they can't be defined by each app.

We've had /etc/services for like 30 years and yet nobody seems to realize you can use a name instead of a port number and stop worrying about manually mapping numbers around.

On the contrary; /etc/services is part of the old paradigm, in which each application got a static port that you had to manually configure, even if you used a text file to give it a label. In my systems, the CM takes care of that, by allocating any free port and taking of the bookkeeping to prevent double use.

Re: Cockpit – Administer Linux servers via a web browser

#126

Post by SSLy »

peterwwillis wrote: post #87
SSLy wrote: post #78

Earlier quoted context omitted.

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.

Windows without WSL or WSU is not Posix-compliant.

Re: Cockpit – Administer Linux servers via a web browser

#128

Post by dmoreno »

maxaf wrote: post #15

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.

With a system based on plugins and components like Serverboards[1] its quite easy to create new functional areas (screens[2] in Serverboards parlance) as the ones you describe. Some times its more difficult to really round up the ideas to make something useful, than implementing it [2].

If you have specific ideas on how would you like a functionality like that to be, I'm all ears to make it real!

[1] https://github.com/serverboards/serverboards/ [2] https://serverboards.io/developers/18.01/plugins/screen-defi...

Re: Cockpit – Administer Linux servers via a web browser

#129

Post by morganvachon »

evol262 wrote: post #29
morganvachon wrote: post #9

For those who may wonder, it looks like this is GNU/Linux only, no support for BSD or any Linux distro that doesn't use systemd . That means no Alpine Linux and no OpenBSD/FreeBSD.

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://cockpit-project.org/guide/latest/feature-systemd.html

Edit: Also please note that I'm not disparaging Cockpit nor systemd, just pointing out that (according to their documentation linked above) it is tied to systemd which may be an issue for some.

Re: Cockpit – Administer Linux servers via a web browser

#130

Post by derefr »

peterwwillis wrote: post #118
derefr wrote: post #111

Earlier quoted context omitted.

> a lot of tasks people try to accomplish are just bad ideas. For most people, the point of config management tooling is to turn all their manual, bus-factor-of-one crufty legacy processes into automated, documented, centralized crufty legacy processes. Ops people don't want a system that is opinionated or that pushes back to force them to change their process. They want a Turing-complete system, and maybe macros as…

In theory, with unlimited resources and fully automated systems, there should be no infrastructure problems to firefight. But probably even with limited resources we shouldn't need to firefight so much if it was engineered correctly. I think about cars and planes, and wonder what life would be like if we needed a team of engineers sitting on the wing of a plane to keep it in the sky when the pilot moves the flaps.

> what life would be like if we needed a team of engineers sitting on the wing of a plane to keep it in the sky

It's the world we'd be in if new planes were in such high demand that the number of startups building them totally outstripped the supply of aeronautical engineers, to the point that most new designs only had ~5 man-years of effort invested in them on release, rather than the thousands they get today.

Software is really a different world, economically.

Post reply on HN