• 0 Posts
  • 22 Comments
Joined 2 years ago
cake
Cake day: June 26th, 2023

help-circle



  • You will need many iterations of trial and error. No way.

    You can speed up testing your playbook by using Molecule or something similar. Don’t touch your working VMs until you get a service (role) set up correctly in your test environment. If you need to set up multiple services in a single VM, you can automate their deployment sequentially, of course.

    P. S. I don’t like Ansible and won’t recommend it because it is full of bugs and non-obvious behavior. However I didn’t investigate alternatives and can’t suggest a better one.







  • Just checked one more time that emails from my server are accepted by Gmail. What am I doing wrong?

    the list of the daemons running in docker-mailserver

    Awful. Who heeds both rspamd and spamassassin simultaneously? fetchmail and getmail6? More than a half of these components are not required to get a working mail server. But I agree that setting up the another half is rather complicated. So I’m planning to give a try to mox when I’ll need to set up a new mail server.







  • disclaimer

    I’m a Debian user and not a Mullvad user. When installing software, I carefully read instructions and almost never follow them because in most cases I know how to deal with my distro better than developers.

    There is a repo for noble, I’ve checked this before writing my answer. It is always possible to edit apt sources config manually and specify any repo you want regardless your distro codename. IDK what is Mint Store, isn’t it about flatpacks that TS doesn’t want to use?



  • Well, first I need to note that blkdiscard is not more secure. But it is much more faster. It does not actually wipe flash memory, it just tells the controller to mark it as unused. So it will drop stored data at the moment it decides the best. Maybe immediately, maybe just before writing new data. But anyway it wont provide ability to read it. It would be still possible if you can get direct access to the flash memory bypassing the controller.

    Second, you forgot that SSDs are not HDDs and data are not stored exactly at offset you write them. The controller remaps memory blocks as needed. And it has more blocks than actually available to user. So when you use dd (or cp, or any other program writing directly to block device) you only override blocks that are actually mapped, but some blocks can still keep old data. So using dd is also not secure in case someone can get direct access to the flash memory. But it takes much longer time and reduces the flash lifetime.

    Several people here mentioned a secure erase feature of SSDs. I didn’t know about it. It should be more secure than both methods if implemented correctly by the manufacturer (i. e. clears all memory cells immediately). In the worst case it could be the same as blkdiscard, I guess.


  • /dev/random, seriously? This will take ages and have no advantages over /dev/zero. Even when you really need to fill your drive with random data, use /dev/urandom, there’s a chance that this will finish in couple days at least. And no, there’s no guarantee that it will wipe all blocks because there are reserved blocks that only device firmware can access and rotate. Some data on rotated blocks still can be accessible for forensic analysis if you care about this.