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.
Have you tried this https://puphpet.com/
Cockpit – Administer Linux servers via a web browser
91–100 of 152 posts
Re: Cockpit – Administer Linux servers via a web browser
#92Earlier quoted context omitted.
So the idea is that you would choose your changes in the GUI, but instead of actually changing the target, it spits out the required code to do it for you in a repeatable way? 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…
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…
Sure, you picked the simplest possible case for a configuration management system. Now, in this very simple case:
- What happens when "/the/path" changes depending on the distribution? How do you specify that?
- What should happen if the "/the/path/name" already exists? Should the system touch it or something?
- What if it exists but is not a directory? Should it delete whatever exists and create a directory instead?
There is no way to define that stuff using POSIX semantics, because POSIX is inherently imperative. "mkdir" means "make a directory", not "on this path there must be a directory".
That mismatch in semantics is real, and each configuration management system tries to close that gap in the simplest, most user-friendly way they can figure out. Most have flocked towards defining their own, as declarative as possible, API. For instance, ansible defines this as:
- name: Ensure name's base folder exists
file:
path: /the/path/name
state: directory
recurse: no
owner: pid/name
group: gid/name
Re: Cockpit – Administer Linux servers via a web browser
#93Earlier quoted context omitted.
Yeah I also wish there was some good Config Management IDEs. I think someone like InteliJ might be able to make a decent one.
If you're doing Puppet then the plugin for IntelliJ works pretty well with Puppet code, including reference checks and all the good stuff you'd expect from a half-decent IDE. 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 c…
Ansible's modules documentation is auto-generated from the code. Hence, there is a standardized (across all ansible's modules) way to extract their parameters/outputs.
See https://github.com/ansible/ansible/blob/devel/lib/ansible/mo... for example:
DOCUMENTATION is a yaml snippet that follows their documentation schema to tell you about all the module's input parameters.
EXAMPLES gives you some usage examples.
RETURN documents the outputs.
A proper IDE plugin could parse those snippets for each module and do some pretty nice autocompletion/inline documentation for you...
Re: Cockpit – Administer Linux servers via a web browser
#94Earlier quoted context omitted.
I've used it before on Ubuntu and it worked just fine. As far as I understand, Cockpit deals directly with Systemd and Docker, so any system based on Systemd should just work.
Again, Cockpit does not explicitly deal with systemd. Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd. Docker is not required at all either, though it's an option.
That is directly contradicted by Cockpit's own doco, which explicitly states that Cockpit uses the systemd APIs and that "use of alternate system APIs are not currently implemented".
* http://cockpit-project.org/guide/latest/feature-systemd.html
It should of course be obvious that Cockpit does explicitly deal with systemd. Desktop Bus is a transport layer, and the important thing about it is what DBus servers are on the other side of the broker are being talked to. In the case of Cockpit they are things like systemd's own idiosyncratic API for process #1 ...
* https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
... systemd's hostnamed server ...
* https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
* https://www.freedesktop.org/wiki/Software/systemd/hostnamed/
... and systemd's timedated server.
* https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a...
* https://www.freedesktop.org/wiki/Software/systemd/timedated/
Cockpit also hardwires use of systemd's journalctl program.
* http://cockpit-project.org/guide/latest/feature-journal.html
* https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
Re: Cockpit – Administer Linux servers via a web browser
#95Earlier 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…
Sure, you picked the simplest possible case for a configuration management system. Now, in this very simple case: - What happens when "/the/path" changes depending on the distribution? How do you specify that? - What should happen if the "/the/path/name" already exists? Should the system touch it or something? - What if it exists but is not a directory? Should it delete whatever exists and create a directory instead?…
Well let's be clear: a lot of tasks people try to accomplish are just bad ideas. Config management is not about having a magical tool that does everything you want exactly how you want on 50 platforms using one config file. Config management is just managing complexity. It works better the less complex it is.
The example above is two basic operations: mkdir and chown. On top of those operations are policies, rules which need to be applied. And then there are transforms, where the arguments or policies may change depending on some variables.
These are all different things that the above rule is mixing together, and we're supposed to think this is a good thing. We pretend it's less complex, but it's not, it's just obscured. And the end result is a lot of wasted effort to redo the same thing.
The GUI is useful because it can craft the operations, policies, and transforms for you, and output instructions to be interpreted and executed by an agent. You could keep all the complexity, but make it standard among a set of common tools. They really all do the same things - they just don't speak the same language.
Another way to think about this is from an app's perspective. It just wants to write to a log file in a directory, it does not care where. That's somebody else's job to figure out - just tell me where the file is! Wouldn't it be handy if the app had a language to tell a CM tool what it needed? It wouldn't have to say "make me file X in Y dir", it would say "give me a writeable file that I will call 'log_fd'".
Then we wouldn't need to craft an environment for it like parents assembling a nursery. The apps could be more self-sufficient, and the CM tools would just do their bidding. Using a standard language.
Re: Cockpit – Administer Linux servers via a web browser
#96Earlier 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.
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.
Re: Cockpit – Administer Linux servers via a web browser
#97Its 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
How's the open source version of mist.io these days? I remember evaluating it (and cockpit, among others) for managing a small isolated network of about two dozen machines in early 2017 and it seemed that the open source release had been somewhat ignored and wasn't really working at that point.
Note that all of my work is on networks that are disconnected from the internet, so I ignore SaaS offerings or versions completely.
Re: Cockpit – Administer Linux servers via a web browser
#98Earlier 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…
If you compromise my dev machine, you'll install a keylogger and sniff all my passwords. The only way I see that even passphrase-less keys are worse than passwords is if I physically lose the machine (and don't use full disk encryption).
Re: Cockpit – Administer Linux servers via a web browser
#99Earlier quoted context omitted.
I'm neither a sysadmin nor a securyt expert, so I might be terribly wrong, but, as I understood it, password-based authentication was undesirable because the attacker could try to brute-force it. Key-based auth doesn't have this flaw so it's arguably safer in that it has one less entry point. On the other hand, not sure I fully understand your argument. You are saying that not being vulnerable to password brute-forci…
> Key-based auth doesn't have this flaw so it's arguably safer in that it has one less entry point. This is exactly what people think when reading the guides. In fact, it's not that there is one less entry point, but this entry point was moved and now exists on another machine together with the key. And since many people use one workstation to log in to several servers, you now have one single point of failure (an eq…
That SPOF exists with passwords too; a keylogger in the workstation will capture them all.
Re: Cockpit – Administer Linux servers via a web browser
#100Earlier quoted context omitted.
I'm neither a sysadmin nor a securyt expert, so I might be terribly wrong, but, as I understood it, password-based authentication was undesirable because the attacker could try to brute-force it. Key-based auth doesn't have this flaw so it's arguably safer in that it has one less entry point. On the other hand, not sure I fully understand your argument. You are saying that not being vulnerable to password brute-forci…
> Key-based auth doesn't have this flaw so it's arguably safer in that it has one less entry point. This is exactly what people think when reading the guides. In fact, it's not that there is one less entry point, but this entry point was moved and now exists on another machine together with the key. And since many people use one workstation to log in to several servers, you now have one single point of failure (an eq…
Yeah, I see your point.