• 0 Posts
  • 6 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle
  • The problem is always having the bad option being enabled by default. Not even the ads are the biggest problem. I didn’t even mention their current ads in the terminal. The problem is the same Microsoft is having now, that your keyboard input gets sent to an untrustworthy third party.

    Your comment got cut off. If you wanted to dispute the paid paid claim. It is about Ubuntu Pro, that’s literally all what the basic tier is. We recently even had the case where a patch with a highish CVE rating was only available to subscribers of the service. We also verified that the same patch was already available on Debian. Even without my anecdote it should be obvious why it is bad.



  • sudo is not simply a tool to give admin privileges, but a tool to manage elevated permissions or run commands in a different users context.

    These things become a lot more relevant once you use the tools professionally. In a well configured system you are only allowed to run the things you are explicitly allowed.

    To be completely honest sudo is basically pointless in a single user context. There is almost no reason to even have it installed. It makes dealing with different environments easier though.

    Anyway as I said it does not matter in many cases if you are the systems administrator. On the other hand there is also no benefit in getting used to bad practices in case you have to unlearn them later.

    One more thing: what you suggest with chroot is one of the very reasons why you should not do that. You might have handed over the keys to break out of chroot. It is a well known vector which boils down to never run anything as root in a chroot environment.


  • sudoedit opens the editor as your user and just writes the file as root. For a single user who is also admin on the system this does not matter in many cases.

    In a multi user context you can easily escape your editor and run a shell which allows a non admin user to escalate their privileges. So from a security implementation standpoint this must exist and it does for this reason.

    Of course this also prevents some mistakes from happening and a bad plugin cannot destroy your whole system easily and so on. It boils down to good practice.


  • If you are new and need help you can ask in the newbie corner. Most people are really helpful there even with the most trivial problem. Well you can also use it if you are more experienced, it is a nice place to get help and participate.

    In other forums you are expected to have done some research first though, e.g. checked the wiki and maybe the bug tracker first and provide your relevant logs. That’s what might get you in this comics situation though.


  • If you can use containers always use containers as a rule of thumb. VMs are less efficient in almost every way and they add some unnecessary complexity.

    For docker you basically only have to backup the persistent data. So in case of the docker setup you just have to backup the mounts and probably your compose file you are using. This probably also answers your third question already. Container files can be left alone and don’t need to be considered for backups as they should be stateless and can reside in their default location (/var/lib/docker/overlay2 or so by default).

    Overall it is quite simple as you only really have to consider the mounts and the docker setup. The mounts you define and should be really obvious and the docker setup is just a few config files at most or just the compose file.