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

help-circle







  • Something I’ve been wanting to work on is a TUI wizard for configuring software.

    The thought is most Linux server program use various config files, and in order to configure them correctly it generally takes a few minutes to a few hours to read through their documentation. But a lot of the configuration boils down to passwords/keys, file paths, network locations, a few different booleans, etc.

    So the general idea is, for a program, the developer or the community can provide a config file telling the TUI wizard what arguments the config file needs, and this one program can walk the end user through setup and generates the config files. This would reduce the amount of time hunting through documentation and reduce bugs due to typos or invalid choices.

    It could go a step further and auto generate keys or passwords if needed, validate entries (ie if the config needs an IP it could make sure it’s valid, etc)


  • What no one else has touched on is the protocol used for network drives interferes with databases. Protocols like SMB lock files during read/write so other clients on the network can’t corrupt the file by interacting with it at the same time.

    It is bad practice to put the docker files on a NAS because it’s slower, and the protocol used can and will lead to docker issues.

    That’s not to say that no files can be remote, jellyfin’s media library obviously supports connecting to network drives, but the docker volume and other config files need to be on the local machine.

    Data centers get around this by:

    • running actual separate databases with load balancing
    • using cluster storage like ceph and VMs that can be moved across hypervisors
    • a lot more stuff that’s very complicated

    My advice is to buy a new SSD and clone the existing one over. They’re dirt cheap and you’re going to save yourself a lot of headache.



  • Security through obfuscation is never a good idea. Best practices for exposing ssh (iirc):

    • disable root login (or at least over ssh)
    • disable password login over ssh, use key pairs instead
    • use fail2ban to prevent brute forcing
    • install security updates frequently

    All of those are pretty easy to do, and after that you’re in a really good place.

    I don’t see a problem with ssh tunneling to access services, as long as the ssh server is secured correctly


  • There have been many posts about people running truenas as a VM in proxmox. There are a few things to consider that I’m not well versed on, so I suggest doing some more in depth research, but it’s definitely possible (I did it myself up until the end of last year).

    One of the easiest ways to get the hard drives into truenas is to connect them to a raid card running in IT mode, which allows the OS to directly control the drives (do not raid them, truenas wants the raw disks), and then pass the raid card to the truenas VM