Gather around kids, I’ll tell you a story of the olden days. Back when it first came out I installed gentoo, and at the time the recommended process was to start from stage1. And of course I was a true believer and spent a lot of time optimizing cflags. I could get the base system running in maybe half a day, on the third try on average (I was distro hopping a lot). I used gnome at the time, and it wasn’t that bad to bring it up. Less than 24 hours. But if you wanted openoffice (there was no libreoffice at the time), oh boy, you could say goodbye to your system for a good day and then some. Assuming that it didn’t fail and then you had to change cflags, recompile half the system and try again. But man, when it finished the system would fly sooo smooth.
“Oh man, I’d love to use Linux because then I wouldn’t have to have Edge installed!” - Nobody. Ever.
People use Windows because it comes with the PC and it runs all their shit (maybe except some yellowing-beige and blue scanner from 1997) with no fucking about needed. They were never incentivised to use Linux. They don’t know what an OS is, and more importantly, they don’t care.
I don’t know why, but the thought of some 38 year old American farmer who doesn’t know computers going “you linux people” is very sweet sounding to me.
I love it, because you can also get best out of both worlds in relation to the comic discusses. You can personalize OS to your liking, and the entire configuration is in a file, so you can redeploy the same setup again.
I feel like I keep posting this everywhere but there’s a project called AstOS that attempts this. Also someone clued me in on this distro neutral solution. AshOS. Full disclosure I haven’t used either.
It looks like solutions like these miss the whole point of what Nix is trying to do. Nix comes with the belief: “Unix has some fundamental issues, because it was designed in specific way. If we store things differently it works really well, and we even get those cool properties for free”.
The authors of those projects instead of thinking “this looks interesting, and it is a paradigm shift but it might be worth to to try feel like Linux noob for some time and start thinking a bit differently how the file system is structured to see if this change is really worth it”
Instead it is: “I don’t need to be PhD in Computer Science (whatever that means), here is how I can force this Nix feature or two on traditional Linux, with ansible, bubble gum and some duct tape and make it immutable-ish, which fails sometimes but, hey, it has the same feature on paper.”
Well to be fair I think it’s because they aren’t trying to be NixOS. You could leverage those arguments against any distro that’s trying out an immutable flavor. Which is mostly accomplished through btrfs features.
I agree that Nix/NixOS does a lot more and it’s a genuinely impressive and paradigm shifting project but it does break with traditional Linux layouts and thinking in a way that immutability doesn’t necessarily have to do.
You could also make the same argument with the systemd and non-systemd crowd.
Either way I look forward to the future of both immutability projects and NixOS. I feel like both areas still need a bit of work but they’re both really exciting fields.
Just add rescue to kernel options (if you use GRUB, press e to edit it for the current boot) and it will boot into console from which you can do downgrade.
When I started using Arch I just set it up on a btrfs filesystem and wrote a simple btrbk hook to take a snapshot before any package updates. That made it trivial to unfuck anything that broke after an update. I can’t remember the last time I had to roll the system back but it’s nice for peace of mind.
Start by playing with subvolumes and snapshots so you can get a feel for how they work. Once you’ve got that down you can break down your root filesystem into sensible subvolume chunks (/, /home, /var/log, /var/cache etc) so that you only snapshot relevant content during each update. I wrote a btrbk config at that point, tested it a few times and then wrote a pacman hook to fire it on install, update or package remove events and went from there.
Here’s what I use to take snapshots - you’ll need to write an appropriate btrbk config file for your subvolume layout but it’s otherwise feature complete. gitlab.com/arglebargle-arch/btrbk-autosnap
Like I mentioned above, I haven’t actually needed to roll the system back in ages but I get a lot of mileage out of being able to reach back in time and grab old versions of files for comparison.
Time shift is a lot easier if you’re just starting out but it also requires a specific subvolume structure and isn’t very flexible.
Edit: pro tip: don’t make /var a separate subvolume from /, it’s way, way, way too easy to roll one or the other (/ or /var) back without the other. If you do that by accident pacman’s state becomes out of sync with the running system and everything breaks. Stick to splitting frequently rewritten data like /var/cache and /var/log off, leave /var itself in the root subvolume.
Well yeah obviously like NixOS. My reason for not using it is that they use a non standard Linux filesystem and it renders a # of packages I want to install incompatible.
Speaks to the fact that we apparently need better and new alternatives or make current tools easier to use.
Certain aspects of discord seem to resonate with people (unfortunately…).
Man pages are great as mentioned, but maybe not as accessible to some people. Are there tools to generate more convenient resources (e.g. wikis) from that? Similar to how generating technical documentations from (structured) code comments.
I love Ansible while hating when people touch it. Yes, it’s very flexible but at what cost? If you actually learn it and follow some basic guidelines, you can make beautiful playbooks and inventories having wonderful automation for even complex setups while keeping it clean. But if one doesn’t care and just try to make servers go brrr, it becomes horrific glorified shell script with everything hardcoded, most tasks unaware of changes they make, cesspool of shitty templates, breaking itself in minutes, being pain to work with and making me want to delete all the shit and start all over.
I decided I wanted nothing to do with Ansible when I was half an hour into reading the website and I still didn’t have a fucking clue what it is or exactly what it does.
To this day, I couldn’t really tell you. It seems to be basically a framework for automatically SSH’ing into machines and running shell scripts on them which doesn’t sound robust in the slightest. It’s like they took thirty years of sysadmins’ discarded spit-and-duck-tape solutions and bundled them into a “framework”.
I dunno how the fuck you’re supposed to manage cloud infrastructure at scale with that.
It’s far more than just SSHing and running shell scripts. Besides, I wouldn’t ever call it a „framework”.
It’s a tool for Linux, BSDs and even Windows machine setup automation in a declarative fashion. Tasks are usually built out of wide range of provided modules for both universal actions (like file edits, templating, shell commands) and very specific ones (like Podman containers, Postgres users, indexes in Mongo, whatever you imagine, you can even implement your own in Python). Those tasks have logic that can detect the status for each of the tasks in each specified nodes, so they can not only be applied, but also dry run with precise diff tracking (diff of config files to be applied, packages to be installed, etc).
It has inventory that can be both static (config file), and dynamic (e.g query an AWS account for Ec2-s or get nodes from Proxmox) that lets you group your however many hosts (by purpose, etc), attach variables to specific hosts or entire groups, or even store encrypted credentials to use them in roles. When dealing with hundreds of hosts, at some point this is something you need to do anyway, but here it really shines even with much smaller amount of machines.
Ansible can be very reliable and provide awesome environments, but it requires some learning and due to its flexibility, it can also be used badly. I have some success stories with it in last 7 years of utilizing it for both small and big business.
That being said, if you want some magic hammer that just does stuff without requiring any understanding, Ansible might not be the thing.
And no, Terraform is not an replacement for Ansible and vice versa. Those two are designed for different purposes. I actually used them together in some projects.
And no, Terraform is not an replacement for Ansible and vice versa. Those two are designed for different purposes. I actually used them together in some projects.
Yeah, that’s the problem. Every time infrastructure management came up, a certain coworker would always bring up Ansible. It eventually got kind of annoying.
Yup. I used ansible for a good year, maybe two, and found myself asking, “Why the fuck am I maintaining some abstract thing when I can just write a shell script and deploy that?”
Cloud orchestration is better done with other tooling. Honestly don’t see a use case for ansible beyond physical data center deployments.
They installed it for us at work as part of a project, and we went to ask the ansible guy wtf we could use it for in a windows world, and he couldn’t articulate how it would be an improvement in any way over a scheduled task.
It appeals to me for management of a windows machine for a few things:
Lots of machines at once, over winrm. Although ssh is the default, as ansible is linux first.
I don’t have to learn powershell - the shared language means the windows teams and the linux team don’t have to learn eachother’s language. In ansible, it’s very easy to avoid the footguns that come with something like bash, especially after you install the red hat linter, ansible-lint, which warns of ansible’s own footguns.
easy to version control it
premade stuff: the official “modules” are massive and do a lot. There are also community packages: galaxy.ansible.com - of course, you should probably check any stuff you run first. But ansible is very easy to read.
built in secret management. Encrypt secrets, but still be able to use them smoothly with the automation framework.
For just one machine? Task scheduler is probably good enough. 2-3 machines, managed remotely? Ansible is at least worth looking at.
The examples are very helpful, with things like getting a list of ad users. I used that to create a ansible script to shuffle all ad user passwords - while being a a linux lover who hates windows and has literally never touched ad before this.
There is a reason ansible exists and is widely used. Shell scripts are brittle and don’t account for a ton of use cases.
For instance- are you going to write a shell script to determine the OS family of a server? Are you then going to do a bunch of if statements for things you want run on Debian hosts vs RedHat ones vs. Alpine? Are you going to manually make templates yourself or just use jinja templates and the template module in ansible (and use variables easily gathered by the setup module)? Are you going to manually select which hosts you’re going to target or are you just going to use your ansible inventory that categorizes your machines based on location or purpose or whatever other arbitrary thing and use tags? Are you going to manually dig in and find out how many NICs are in a box, what IPs they have, what CPU, how many cores so you can set some service to use “X” amount of threads, define service templates using those machine variables, etc. etc. etc.? Are you going to make such well defined shell scripts that they can be reused over and over again against a variety of machines without breaking things and make it easy to include them in parent shell scripts?
This is all stuff ansible does quite easily.
It’s not the end all be all of course. Some would argue (maybe rightfully) that Puppet or Salt can maintain config drift a bit better. I would argue it’s not the tool to use for containerization really either. But it definitely has a real purpose in initial and maintained configuration management and in both cloud and on-prem deployments.
Terraform for day 0 operations is a better experience but it had its quirks. Ansible is nice when it’s done well, but when you don’t have an Ansible module for something, you’re essentially writing a shell script
Yeah, in contrast the value proposition for Terraform was immediately obvious. “Oh, you mean I don’t have to manually set up Kubernetes clusters and shit every time we want to deploy to a new region? Fucking sign me up!”
LUKS doesn’t protect you from an evil maid attack. It hides your data when your stuff gets stolen in a powered off state, but it provides neither verification of data, nor does it provide verified/secure/safe boot.
In simple terms: the very first thing which gets loaded needs to be unencrypted (barring some exceptions I will omit here), which can get replaced with an evil version by the evil maid.
Is it even possible to mitigate such an issue? Will resetting the bios by removing the cmos battery not also disable password protection in the bios thus making it possible to disable secure boot?
And at that point could they not just use a hardware keylogger or something?
Yes, with a TPM. A TPM (2.0) can seal secrets and only release it when a machine fulfills certain configuration and state requirements (saved into registers called PCRs).
For example: make the decryption key one part dependant on a passphrase you memorized (to not only rely on a TPM), and one part on something saved in a TPM. If you select the correct PCRs when saving the latter, and your TPM works as advertised (and doesn’t offer an easy way to eavesdrop/fool it), removing the battery would make the TPM not release the secret (if removing the battery even still works on modern machines).
However, this depends on having a unified kernel image, having configured dm-verity and maybe more stuff I don’t recall right now. Probably should also make sure you don’t allow Microsoft’s Secure Boot keys and instead only your own. I hope this will get easier in the future, but I know SystemD is actively developing useful tools for that (e.g. ukify).
That all doesn’t mean the critique of TPMs (intransparent, proprietary) is invalid. Maybe we’ll have OpenTitan based TPMs at some point?
linuxmemes
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.