• 7 Posts
  • 159 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle

  • z3bra@lemmy.sdf.orgtoProgrammer Humor@lemmy.ml:3{:3|:3&};:3
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    5 months ago

    I didn’t come up with this idea myself, this is straight from OpenBSD disk setup guide (which I personally trust as a good source of info) :

    Encrypting External Disks

    This section explains how to set up a cryptographic softraid volume for an external USB drive. An outline of the steps is as follows:

    • Overwrite the drive’s contents with random data

    […]

    # dd if=/dev/urandom of=/dev/rsd3c bs=1m
    


  • Well as I see it, it will just do a lot of write operations to your disk, which might eventually damage it if you do it a lot (just like any write operation done on a disk). However, this specific command isn’t bad per se, and is even technically a good thing to do for preparing to full disk encryption.









  • Keeping the source IP intact means you’ll have troubles routing back the traffic through host B.

    Basically host A won’t be able to access the internet without going through B, which could not be what you want.

    Here’s how it works:

    On host A:

    • add a /32 route to host B public IP through your local ISP gateway (eg. 192.168.1.1)
    • setup a wireguard tunnel between A and B
    • host A: 172.17.0.1/30
    • host B: 172.17.0.2/30
    • add a default route to host B wireguard IP

    On host B:

    • setup wireguard (same config)
    • add PAT rules to the firewall so to DNAT incoming requests on the ports you need to 172.17.0.1
    • add an SNAT masquerade rule so all outbound request from 172.17.0.1 are NATed with host B public address.

    This should do what you need. However, if I may comment it out, I’d say you should give up on carrying the source IP address down to host A. This setup I described is clunky and can fail in many ways. Also I can see no benefits of doing that besides having “pretty logs” on host A. If you really need good logs, I’d suggest setting up a good reverse proxy on host B and forwarding it’s logs to a collector on host A.


  • OpenBSD is the most pleasing expérience I’ve had with an OS. It’s fully contained and has all the tools you need without needing to install anything (eg a DNS, HTTP, SMTP servers, a proxy, a good firewall). All config files look alike and use the same keywords for the same things, making it straightforward to configure everything.

    And regarding RAID 1, I’ve never done it myself, but it totally works out of the box (as well as full disk encryption).






  • % pm -i | wc -l
    55
    

    That’s how many software I packaged myself. They are installed to /usr/local using an alternative package manager because I couldn’t be bothered with making an appropriate .deb.

    And as to explain how this alternate workflow is less complex, here’s how I go about installing a program:

    % git clone git://git.z3bra.org/human ~/code/human
    Cloning into '/home/z3bra/code/human'...
    remote: Enumerating objects: 53, done.
    remote: Counting objects: 100% (53/53), done.
    remote: Compressing objects: 100% (53/53), done.
    remote: Total 53 (delta 28), reused 0 (delta 0), pack-reused 0
    Receiving objects: 100% (53/53), 9.35 KiB | 195.00 KiB/s, done.
    Resolving deltas: 100% (28/28), done.
    % cd $_
    % pack
    CC human.c
    LD human
    install -D -m 0755 human /tmp/tmp.rfnbLyIQOz/usr/local/bin/human
    install -D -m 0644 human.1 /tmp/tmp.rfnbLyIQOz/usr/local/man/man1/human.1
    
            > /tmp/[email protected]
    
    installed human (0.3)
    % pm -i human
    usr/
    usr/local/
    usr/local/bin/
    usr/local/bin/human
    usr/local/man/
    usr/local/man/man1/
    usr/local/man/man1/human.1
    

  • Talking for myself and not OP: What’s complex about apt and yum is the package format per se. The cli is very straightforward and “just works”, but whenever you want something that’s not packaged and need to package it yourself, you gotta fasten your seatbelt and prepare for the complex task of creating an RPM or a DEB package.

    I know there are tools to help with that, but I’ve created packages for many distros (Debian, CentOS, Alpine, Arch, Void and Crux), and rpm/deb are just way more complex to create than the alternatives.