If not you could also use Gate One[1].
Cockpit – Administer Linux servers via a web browser
41–50 of 152 posts
Re: Cockpit – Administer Linux servers via a web browser
#42Why 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 will wait until they get rid of this crazy requirement to consider using it.
Re: Cockpit – Administer Linux servers via a web browser
#43I tried it on my fedora 26 last year and my impression is that it has a far way to go and a lot of problems to resolve on the way. It's nowhere near a complete server administration product that will let you avoid the terminal. Perhaps for simple tasks but I fail to see the purpose.
So, yes, you're right - a lot of work still needs to be done, but Cockpit itself seems to be an adequate base, just need to add support for managing commonly needed services at least at a rudimentary level though (MySQL/PostgreSQL, Apache/Nginx/lighttpd, Postfix/Dovecot/exim/cyrus, etc).
Re: Cockpit – Administer Linux servers via a web browser
#44Does it have an SSH terminal built right in the browser? Not clear from the screenshots or documentation. If not you could also use Gate One[1]. [1] http://liftoffsoftware.com/Products/GateOne
Re: Cockpit – Administer Linux servers via a web browser
#45Personally 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.
Yeah I also wish there was some good Config Management IDEs. I think someone like InteliJ might be able to make a decent one.
Can't say anything about Chef or Salt, but with Ansible you get basically shit for help since the IDE just sees a YAML file and nothing more. This is partially the fault of Ansible though, to be honest, modules being standalone scripts that is cool - but they provide no standardized way to inspect their parameters and outputs beyond documentation.
Re: Cockpit – Administer Linux servers via a web browser
#46Personally 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.
I would definitely find that useful for Terraform and Cloudformation. Searching for it, I see that AWS has a tool targeted at that: Cloudformation Designer.
https://aws.amazon.com/blogs/aws/new-aws-cloudformation-desi...
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
Re: Cockpit – Administer Linux servers via a web browser
#47Personally 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.
Yeah I also wish there was some good Config Management IDEs. I think someone like InteliJ might be able to make a decent one.
Re: Cockpit – Administer Linux servers via a web browser
#48Why 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…
It then goes on to list how to use Kerberos or Public Key methods.
Re: Cockpit – Administer Linux servers via a web browser
#49Re: Cockpit – Administer Linux servers via a web browser
#50Why 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…
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.