Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S
Posts
0
Comments
499
Joined
3 yr. ago

  • Then swap you nameservers to a DNS provider that allows that?

  • So I'd like to split my passwords file into multiple "files", where the unimportant logins are permanently unlocked for convenience, while the more sensitive login credentials remain encrypted until I actually need them.

    And how should that protect you against an attack that has compromised your system? If the system is compromised, then an additional lock does not hinder the attacker to wait until you open it.

  • The tweet he commented on was indeed a nice idea, but a CEO should have more foresight that the things Trump stated in it would not be true. When you look at it now, it looks like it was more or less a threat that led to a closer relationship between "tech bros" and the current administration instead of the "take down" of them.

  • Immich requires to be run on a server to function, but a lot of (or even all) of its functions are things that could reasonably done entirely on-device. Aves combined with some automatic backup solution such as Nextcloud gets (from what I can tell) most of the functionality Immich offers.

    How would you backup Immich on device?

    And if you backup to Nextcloud than you already have a served?

    So you are arguing that having a file server is enough? And processing is done on client side?

    That would be in this case very inefficient.

    1. You would need to have all the data on the Client or transfer all the data to the client once you load it.
    2. You device has to do all the processing which would lead to lower battery life.
    3. How do you handle multiple Users? Giving partially access to the Filesystem?

    I could come up with other points but this should give you an idea. Yes, for some use cases a server-client approach does not make sense but for a dedicated photo backup and indexer it absolutely does.

  • I am fully backing up my Mail Server with some exclusions like /tmp etc. with restic now for over a year, including updated binaries and docker images etc. and have about 16GB of data with hourly backups for over a year.

  • If you use any kind of deduplication and or compression, the system files do not amount to any meaningful size (assuming there is no additional encryption on the VM disks). Especially when you consider the size of OPs data, 1,5TB, then the couple of GB of system binaries etc. do not really matter.

  • Depends on the root setting. And depends on your goal. What is the purpose of the proxy? I doubt that it is easy to bypass, but you still could run a Proxy or VPN as user, this would not bypass the proxy but any filtering/blocking would not be possible. Etc

  • You can simply just download a binary and run it.

  • I'm also of the opinion that if a bad actor capable of navigating the linux file system and getting my information from it has physical access to my disk, it's game over anyway.

    I am sorry but that is BS. Encryption is not easy to break like in some Movies.

    If you are referring to that a bad actor breaks in and modifies your hardware with for example a keylogger/sniffer or something then that is something disk encryption does not really defend against.

  • With initramfs and dropbear you can make the password prompt accessible over ssh, so you can enter the password from anywhere.

    Edit: For debian it is something like

    • install dropbear
    • configure dropbear for initramfs
    • generate key pair
    • generate initramfs
    • You are done.
  • Full disk encryption on everything. My Servers, PCs etc. Gives me peace of mind that my data is safe even when the device is no longer in my control.

  • That's also my take on the topic and that is also what backblazes data is suggesting. Would they not believe it themself then they would stop buying unreliable drives. Every brand can have outlier models that have a bad failure rate.

  • I use dd.

  • Go with the drive with the best money/TB rate that meets your criterias. I would consider everything above ironwolf or red plus fitting for NAS use. Data center drives are in my experience often cheaper than NAS drives. (wd ultrastar or seagate exos or toshiba enterprise capacity)

    Look for the warranty. Some times another drive for just a couple of bucks gives you a way longer warranty.

  • And as backblaze says themselves every time, this data is not.the complete truth either, they have large sample size but this sample size is still too small to large claims about reliability. Especially about brand reliability.

  • https://en.m.wikipedia.org/wiki/Initial_ramdisk

    In Linux systems, initrd (initial ramdisk) is a scheme for loading a temporary root file system into memory, to be used as part of the Linux startup process. initrd and initramfs (from INITial RAM File System) refer to two different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.

    As i said 2 different things, initrd was used to create a ramdisk, a block device. Initramfs basically directly offers a filesystem instead of a block device.

    systemd has now a interface called systemd-initrd: https://github.com/systemd/systemd/blob/main/docs/INITRD_INTERFACE.md

    initrd was deprecated see here: https://lkml.org/lkml/2020/7/14/1508

  • Initramfs and initrd are 2 different things, the problem where the confusion happens is that initrd is deprecated since a few years.

    Now, systemd has implemented an interface called systemd-initrd which basically is initramfs.

    I guess here is were the confusion lies. Nowadays everything is initramfs even if it called initrd.

    The original initrd differs from initramfs, but it is no longer a thing.

    Sorry if i came across a little bit snappy have not had a great week so far.