Haven't used the web gui, so can't comment on it. The core open source ansible product is text-based. A few months ago, I migrated a provision and deploy system from a bundle of fabric and shell scripts to ansible. I'm happy with the results.
Some things are easier to do: builtin templating for things like config files is nice and all the modules I've used work as advertised. Some things are harder: reusing groups of similar tasks is kind of awkward but doable. The main advantage is that the ansible imposes a structure that is necessarily self-descriptive and that makes everything very readable. The docs are great and the learning curve is pretty linear so you can defer messing with advanced features until you need them (at that point you'll probably be happy they exist).
I don't want to hijack this thread, but I've found parameterized roles fit my use case perfectly. However, a couple related things caught me out earlier tonight: both the apt_key 'file' parameter, and 'with_file' seem to ignore the roles search paths. I have an apt role which handles installing the package keys, adding and updating repositories, and installing a list of packages. Passing e.g. 'nginx.key' from the nginx role wouldn't work, as they looked only in roles/apt/tasks rather than roles/*/files as I expected. Passing a full path worked. (If I remember correctly! I'm a little hazy on the exact details now, although if this isn't as expected I can do some legwork tomorrow and raise a bug.)
yeah shoot the list an email on this. All the lookup plugins should use the roles search path already, but it could be that one got missed. I'd probably want to see a snippet of the playbook to understand a little better too. Thanks!
Hi mpdehaan. I hadn't seen parametered roles - maybe I just overlooked them. I did use a lot of parameterized includes but roles would be more flexible. Thanks for the heads up.
That's not so far off. It has all of the really beautiful system stuff of FreeBSD (rc.conf, predictable file hierarchy, documentation) and matches them or does better. It forces you to learn how things work and does a good job of teaching you good practices. Even if you don't use Arch, the Arch wiki is a gold mine on configuring pretty much anything.
The main thing Arch has over FreeBSD is you get easy access to lots of shiny toys. Pacman repos update much more frequently and the process of updating packages is much faster. If your favorite text editor drops a new version, it will be available in Arch repos in minutes/hours; it may be months before it makes it to FreeBSD ports. And things like audio, video drivers, wireless are pretty painless in Arch compared to FreeBSD.
The biggest downside of Arch is that it sits on the complete opposite side of the security spectrum. FreeBSD makes sure you start with a secure machine and anything you do to cheapen the security is your bag; most of the time it'll try to let you know you when you're doing it wrong. The BSDs in general have a really healthy culture of security paranoia. You don't get that with Arch. Signed packages have only recently made their way into pacman and I'm not sure if they're even required yet. So a lot of the time, it feels like you just have to cross your fingers and trust that the repos you're hitting haven't been compromised. And you're constantly installing software from them.
Also, occasionally you'll need to spend 5 or 10 minutes recovering from a wonky upgrade (upgrading often is better than not).
Arch is an excellent, if not secure, desktop/laptop environment and you'd be crazy to run a production server on it.
I think it's actually where the second derivative (concavity) of a function changes sign; but you're right in that it can be a positive as much as a negative indication.
The idea is very similar: you create a set of jails that behave as independent systems. Then every process started from a jail is tagged with a jail ID corresponding to the jail that the process was started from. All processes run in the same kernel and the jail ID gives the kernel just enough information to tell whether or not a process should have access to a given resource when sys calls are made.
I've never used OpenVZ so I don't know how they compare in practice but I can say that FreeBSD jails worked beautifully when I was using them heavily (about 2 years ago). They are super easy to manage and were as stable as you'd expect in FreeBSD (you'd have to be trying really hard to knock them down).
Some things are easier to do: builtin templating for things like config files is nice and all the modules I've used work as advertised. Some things are harder: reusing groups of similar tasks is kind of awkward but doable. The main advantage is that the ansible imposes a structure that is necessarily self-descriptive and that makes everything very readable. The docs are great and the learning curve is pretty linear so you can defer messing with advanced features until you need them (at that point you'll probably be happy they exist).