wolf

@wolf@lemmy.zip

This profile is from a federated server and may be incomplete. Browse more on the original instance.

wolf,

Debian, settled down few years ago and my fallback would be Fedora.

Nice thing about Debian is, I can use it for servers, desktop and raspberry pi on am64, arm7 and aarch64. This is a real killer feature for me, because I’d rather do interesting things with my devices instead of learning n different ways to accomplish the same tasks. (e.g. using different distributions for server/desktop/pi and having to figure out 3 times the names of the same packages or where the configuration file in which version is expected.)

wolf,

Sorry, wasn’t aware of the other posts but will do my due diligence in the future!

Thank you for the heads up!

wolf,

Seriously, I don’t understand the point of the article, if there is one.

It seemed more like a confused enumeration of systems which are POSIX conform and in the end it talks about Wayland.

Is the point that Wayland breaks compatibility with X11/X.org and is mostly a Linux thingy? (AFAIK FreeBSD is working on a Wayland port, but no one else.)

Anyway, I am a happy Wayland user for several years now, although I am of course unhappy about the split with the *BSDs, OTOH most 'NIX software nowadays uses so many Linux APIs, that Wayland is IMHO no big game changer when talking about portability anyway.

wolf,

Good to know that FreeBSD pulls Wayland off! :-)

It is a pity, that FreeBSD is not more utilized for desktops.

wolf,

In my impression OpenBSD is used at least as much as FreeBSD on the desktop, if not even more.

Nowadays I agree with your point, that for the ‘typical desktop usage’ the BSDs are not very viable (I try from time to time and always have to give up, because of missing hardware support or missing software.).

Still, IMHO it is a great loss that the BSDs are not really an alternative on the desktop for most users. BSDs are extremely good engineered, when hardware is supported, it just works™, the base system is clean and has great documentation.

wolf,

Using both, too.

Supposedly NGINX gives you better peak performance and the configuration file format is more popular.

I would guess that peak performance is only a concern when being google/netflix/amazon, otherwise I would bet the bottleneck is somewhere else.

Further, NGINX seems to have become the default reverse proxy for all start ups, companies etc. around 10 years ago and thanks to group thinking by now one has to explain when using something else than NGINX.

What I really miss from Apache is Apaches awesome letsencrypt module w/o the need for certbot. (If somebody knows about a module for NGINX which takes care of letsencrypt w/o certbot, please enlighten me.)

In summary: Technical Apache and NGINX are IMHO mostly interchangeable (outside of peek performance demands), but the market/herd/group think prefers NGINX.

wolf,

Nice, thank you very much for this great summary!

In my own words, you describe the difference between declarative vs. imperative configuration and the joy of atomic updates. :-)

I just want to add one point: Theoretically I totally agree, that one might have a bad state in Ansible and the updated state is spoiled, and of course configuration drift is a theoretical problem via Ansible. In practice I never run into this problems in 10+ years of using Ansible. (Of course I treat servers/desktop as cattle, so every major revision of Debian means a complete/clean new installation.)

wolf,

Thanks, that clarified things for me. Only thing I really would love to have are atomic updates, but for this I probably could just use BTRFS snapshots.

wolf,

Sorry, hard disagree from me.

Immutable distros solve a lot of problems and are IMHO a great idea. I love my SteamDeck with SteamOS, I really like Silverblue and OpenSUSEs MicroOS (Avalon or however it is called right now). For my desktops/servers Debian is the best choice right now, but my Thinkpad from 2012 which runs now happily as an entertainment machine is a perfect example where an immutable distro would be much better and practical.

Immutable distros are a solution to a real problem, and this problem is not solved by Ansible/BTRFS etc. Hell, I’ll happily jump ship sooner than later. Of course, YMMV and I don’t say immutable distros solve all problems for everyone, but having this option is great IMHO.

wolf,

Yes, I really love the Silverblue download in the background, reboot and you are up to date updates. So much better than watching the package manager do its thing. :-)

I don’t know about your knowledge about Ansible, and when you are already running Silverblue and are happy with it, it might be more worthwhile for you to explore how to automate Silverblue and the containers you are using… and write a blog post for people like me, how you did it, so I can learn. :-P

Ansible… basically it allows you to install software with the package managers (apt, dnf, …), configure/restart etc. services, clone git repositories, run arbitrary commands, configure stuff with dconf.

Example for my workflow:

When Debian 12 got into the alpha stage, I simply set up a virtual machine, install git, ansible and vim, and then I start from a known starting place (like Gnome Desktop for desktops, minimal for servers). First, I clone my git repository with my dotfiles, and link all the relevant dotfiles. After that I simply use Ansible to install all packages I will use from that distribution, run dconf to configure Gnome for my needs, configure/download software from 3rd party package repositories or just download tarballs and install them to /opt or ~/opt. Of course also flatpaks can be configured/downloaded via Ansible.

Once, everything works great in the virtual machine I will work in the VM for a few days or even weeks. If everything works stable I’ll just make a clean install of the operating system, add some hardware specific tweaks (change grub config, tweak WIFI drivers power mode) and then I am up and running. Thanks to Debian, my Ansible configs are mostly stable with minor tweaks for around 2 years, and when time is due for Debian 13, I’ll repeat the cycle.

The way I do things with Ansible have grown for a long time and are tailored to my private/professional use cases. I simply like having the same setup on every desktop/server I deploy, because I never have to wonder, if my software is configured in the way I like it, if a hotkey works or if something I use is installed or not. (And if my hardware dies or I do an SSD upgrade, I am up and running within minutes, same is true if I get new hardware.)

Still, it is a tradeoff. I really like Fedora, but one year of updates is too short for me and my initial investment to setup a new version of Debian. Further, I only use dconf based desktops like Mate or Gnome, because I can simply configure them painless 100% via Ansible. OTOH I have MY Debian desktop setup running on multiple AMD64 and AARCH64 physical and virtual machines. If I want to experiment with software, I just create a VM, start Ansible, get a cup of tea and I have a disposable machine to play around. Further I have my setup 100% documented, if I wonder, what strange power settings tweak I needed in which file to make Debian 11 work on my netbook, I know were to find the 100% correct answer…

Excuse the wall of text, hope that gave you an idea, don’t hesitate to reach out if any questions are left. Obviously, you have to decide for yourself if such a setup is worthwhile for you. In case you use only one Desktop, this would be total overkill. :-P

wolf,

Some examples pointed out above, the big thing is the ‘immutable’ and bit for bit replication to the best of my knowledge.

Ansible is imperativ and applies changes to a starting state. Immutable distros replicate a known state 100%, which is in every respect superior and prevents nasty surprises Immutable distros are 100% reproducible from a config file, which is a big thing for cyber security, building software etc. Debian has too many packages given the amount of contributors they have. The immutable distros are mostly moving to flatpak, which hopefully means that the Distros can focus their energy on a great core experience, and communities like LibreOffice can focus on creating a great flatpak experience.

Nobody says that containers / and/or immutable distros are a good solution for your specific needs and use cases, that’s fine. For me, and after using Silverblue for some time (and btw. containers on multiple occasions), I am looking forward to jumping ship, because I like the user experience, declarative configurations are the logical next step when using Ansible and atomic updates in the backgrounds w/o the problems of package managers are great IMHO.

wolf,

Sorry, I have only Ansible files at work which I cannot share and my private Ansible setup is in a private git repository. I elaborated further down in another comment my workflow.

My suggestion is to forget about best practices (like roles) for private desktop setup, simply start with a task file and a fresh installation of your favorite distro inside a virtual machine. From that starting point, everything you do to configure the VM you do via Ansible. Want to set the hostname? Learn about ansible.builtin.hostname, want do install a package? Use ansible.builtin.apt, ansible.builtin.dnf or similar, want to harden your sshd config? Look at ansible.builtin.lineinfile, ansible.builtin.copy or ansible.builtin.template … Screwed up your VM? Replace it with a new one, run your Ansible tasks and continue were you left off…

Hope that helps!

wolf,

Sorry, perhaps I do not understand what you are asking for?

On a *NIX box you install ansible, start sshd and then run something like:


<span style="color:#323232;">ansible-playbook -i inventory -u username -e 'ansible_user=username' all.yml  -K --limit hostname.domain.net
</span>
wolf,

“The next Arch install, I’ll document the setup” - Famous last words! :-)

Seriously, I wonder how good my approach would work with a rolling distribution like Arch. I would be afraid, that pacman updates would drift/change the system and over time the delta to my assumed setup grows… OTOH if you keep your scripts in sync with Archs updates, you might simply distribute the maintenance of your Ansible script. If you go full Ansible with Arch, please give an experience report in 6 months!

wolf, (edited )

Great write up, thank you very much!

I expect Google to keep Mozilla/Firefox on the lifeline indefinitely to avoid antitrust issues in the states and EU, so Mozilla/Firefox won’t go anywhere.

Still, this doesn’t mean anything, because I often need Chrome or Safari to access some websites.

In the end it is quite funny: Moving a lot of stuff to the web made Linux a more realistic desktop option, at the same time to access a lot of stuff on the web one needs to run a Blink browser.

IMHO the most annoying thing is, that we could have at least some laws, which mandate that every government service must be available to Open Source users and every government paid software must run on at least Linux. Thanks to lobbying and power this will never happen.

Edit: To state it more clearly: Firefox is IMHO in bad shape and in a bad situation. Firefox won’t die, but at the same time right now I already need Chrome/Safari browsers, because Firefox support is broken on many sites. I see no way Firefox can gain significant market share, especially seeing what regular consumers tolerate from Microsoft/Edge and Google/Chrome.

wolf,

I ended up using spreadsheets for keeping track of todos and habits. LibreOffice Calc is the obvious solution for FOSS, though I am using Googles Spreadsheet for cloud syncing and the Android/iPhone apps. If I get trouble with Google I will just copy and paste to LibreOffice and I am good.

For notes, IMHO nothing beats a good directory structure/layout and markdown. (Sorry, org-mode guys. :-P )

wolf,

Seriously, unless you are extremely specialized and know exactly what you are doing, IMHO the answer is: Always (and even being extremely specialized, I would still enable a firewall. :-P)

Operating systems nowadays are extremely complex with a lot of moving parts. There are security relevant bugs in your network stack and in all applications that you are running. There might be open ports on your computer you did not even think about, and unless you are monitoring 24/7 your local open ports, you don’t know what is open.

First of all, you can never trust other devices on a network. There is no way to know, if they are compromised. You can also never trust the software running on your own computer - just look at CVEs, even without malicious intentions your software is not secure and never will be.

As soon as you are part of a network, your computer is exposed, doesn’t matter if desktop/laptop, and especially for attacking Linux there is a lot of drive by attacks happening 24/7.

Your needs for firewalls mostly depend on your threat model, but just disabling accepting incoming requests is trivial and increases your security by a great margin. Further, setting a rate limit for failed connection attempts for open ports like SSH if you use this services, is another big improvement for security. (… and of course disabling password authentication, YADA YADA)

That said, obviously security has to be seen in context, the only snake oil that I know of are virus scanners, but that’s another story.

People, which claim you don’t need a firewall make at least one of the following wrong assumptions:

  • Your software is secure - demonstrably wrong, as proven by CVEs
  • You know exactly what is running/reachable on your computer - this might be correct for very small specialized embedded systems, even for them one still must always assume security relevant bugs in software/hardware/drivers

Security is a game, and no usable system can be absolutely secure. With firewalls, you can (hopefully) increase the price for successful attacks, and that is important.

wolf,

You’re right. If you don’t open up ports on the machines, you don’t need a firewall to drop the packages to ports that are closed and will drop the packets anyways.

Sorry, hard disagree.

I assume you are assuming: 1.) You know about all open ports at all times, which is usually not the case 2.) There are no bugs/errors in the network stacks or services with open ports (e.g. you assume a port is only available to localhost) 3.) That there are no timing attacks which can easily be mitigated by a firewall 4.) That software one uses does not trigger/start other services transitively which then open ports you are not even aware of w/o constant port scanning

I agree with your point, that a server is a more controlled environment. Even then, as you pointed out, you want to rate limit bad login attempts via firewall/fail2ban etc. for the simple reason, that even a fully updated ssh server might use a weak key (because of errors/bugs in software/hardware during key generation) and to prevent timing attacks etc.

In summary: IMHO it is bad advice to tell people they don’t need a firewall, because it is demonstrably wrong and just confuses people like OP.

wolf,

I think I get you and the ‘theory vs. practice’ point you make is very valid. ;-) I mean, in theory my OS has software w/o bugs, is always up-to-date and 0-days do not exist. (Might even be true in practice for a default OpenBSD installation regarding remote vulnerabilities. :-P)

Who migitates for timing attacks? I don’t think this is included in the default setup of any of the commonly used firewalls.

fail2ban absolutely mitigates a subset of timing attacks in its default setup. ;-)

LIMIT is a high level concept which can easily applied for ufw, don’t know about default setups of commonly used firewalls.

If someone exposes something like SSH or anything else w/o fail2ban/LIMIT IMHO that is grossly incompetent.

You are totally right, of course firewalls have bugs/errors/miss configurations… BUT … if you are using a Linux firewall, good chances are, that the firewall has been reviewed/attacked/pen tested more often and thoroughly than almost all other services reachable from the internet. So, if I have to choose between a potential attacker first hitting a well tested and maintained firewall software or a MySQL server, which got no love from Orcacle and lives in my distribution as an outdated package, I’ll put my money on the firewall every single time. ;-)

wolf,

Perhaps I don’t understand your point. If I understand your point in the sense that there are also issues with firewalls and that one always has attack vectors against usable systems, I fully agree with your remark. My point is simply, as a rule of thump a firewall usually mitigates a lot of attack vectors (see my remark about LIMIT for ssh ports elsewhere). Especially for client systems having a firewall which blocks all incoming traffic by default is IMHO high payoff for almost no effort.

wolf,

It will be a pleasure, like every other year of the Linux Desktop™ for more than 20 years now! :-)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • khanakhh
  • kavyap
  • thenastyranch
  • everett
  • tacticalgear
  • rosin
  • Durango
  • DreamBathrooms
  • mdbf
  • magazineikmin
  • InstantRegret
  • Youngstown
  • slotface
  • megavids
  • ethstaker
  • ngwrru68w68
  • cisconetworking
  • modclub
  • tester
  • osvaldo12
  • cubers
  • GTA5RPClips
  • normalnudes
  • Leos
  • provamag3
  • anitta
  • lostlight
  • All magazines