• 1 Post
  • 88 Comments
Joined 2 years ago
cake
Cake day: June 30th, 2023

help-circle
  • Yeah I tried just now and it diesn’t seem to be working (anymore?) could’ve sworn that worked.

    You can still kexec the installiers directly, I followed the netboot.xyz scripts and got the links they use. Here’s Debian as an example:

    From the scripts: https://deb.debian.org/debian/dists/stable/main/installer-amd64/current/images/netboot/ looking at the boot config debian-installer/amd64/grub/grub.cfg

    submenu '... KDE Plasma desktop boot menu ...' {
        set gfxpayload=keep
        menuentry '... Install' {
            set background_color=black
            linux    /debian-installer/amd64/linux desktop=kde vga=788 --- quiet
            initrd   /debian-installer/amd64/initrd.gz
    

    so we need to download those two files and take the netboot.xyz cmdline arguments then

    $ kexec --command-line="desktop=kde vga=788 mirror/suite=stable initrd=initrd.magic console=ttyS0,115200n8"  --initrd=initrd.gz -l linux´
    $ systemctl kexec
    

    and it boots.

    also here’s an example for the nixos netboot commands, more on that in the nixos manual:

    $ kexec --load bzImage \
      --initrd=initrd.gz \
      --command-line "init=/nix/store/n37nmcvbrblk9ahfzj9nxy01axs7zsf6-nixos-system-nixos-kexec-25.11pre-git/init nohibernate loglevel=4 lsm=landlock,yama,bpf"
    $ systemctl kexec
    

    Edit:

    No console access

    If that means that you can only connect to SSH and have no VGA/video then this will be limited, you could setup an automated install but that requires a lot more knowledge than what your guide requires.


  • Kexec can be used to load a new kernel and “reboot” quickly, it can also be used to load a new kernel, an initrd and never touch the disk. Such a system lives completely in ram and allows you to modify the disk in any way you want without breaking you running Linux (which is in ram)

    Any distro that has a network boot installer that can be passed to kexec can be installed this way, any that don’t can still kexec any Linux distro and then install any other distro by passing the disk to a VM and installing linux through that.

    You can also kexec the netboot.xyz image and get any distro supported there.




  • i will simply want to scan projects that i personally use to be aware of its current state and future changes, before i blindly update apps i host.

    If you’re just doing this for yourself then you still need to know the programming languages involved, what kind of vulnerabilities exist, how to validate them and quite a bit of how the projects operate.

    The AI will output a lot of false positives and you will need to actually know if any of the “vulnerabilities” are valid or just hallucinations. Do you really want that extra workload?









  • It is expected, the users inside the container are “real” users. They just get offset inside the container and some mapping is applied:

    Root inside the container is mapped outside to the user running the container, everything that has the owner “root” inside the container can be read from outside the container as your user.

    Everything that is saved as non-root inside the container gets mapped to the first subuid in /etc/subuids for your user + the uid inside the container.

    You can change this mapping such that, for example, user 1000 inside the container gets mapped to your user outside the container.

    An example:

    You have a postgres database inside a container with a volume for the database files. The postgres process inside the container doesn’t run as root but instead runs as uid 100 as such it also saves its files with that user.
    If you look at the volume outside the container you will get a permission denied error because it is owned by user 100100 (subuids starts at 100000 and usid inside container is 100).

    To fix: Either run your inner processes as root, this can often be done using environment variables and has almost no security impact or add --userns keep-id:uid=100,gid=100 to the cmdline to make uid 100 inside the container map to your user instead of root (this creates a new image automatically and takes a while on the first run)






  • There are multiple reasons but the most important one is: You didn’t enable it.

    Caddy fully supports https to the reverse proxy targets, though you’d have to get those targets trusted certificates otherwise caddy wouldn’t connect.

    The default protocol for backends is http, most of the time this isn’t a problem because:

    • The web server runs on the local machine
    • The web server runs in containers/vms on the local machine
      • or is running in a VM and has a direct virtual connection with the caddy vm
    • The connection to the Backend is encrypted with a VPN
    • Caddy and the web server are directly connected or connected through an otherwise isolated network

    Because https requires certificates that are somewhat difficult to set up for internal servers (and were even harder to get before) the default mostly is just to encrypt on another layer of the stack. Afaik at least.