diy

    My version of a DIY GR1 hip belt

    I wanted a hip belt for my GoRuck GR1 backpack. I tried GoRuck’s own padded hip belt. It’s great for stabilizing the bottom of the bag so that it doesn’t swing from side to side. However, I wanted a weight-bearing belt like the one on my camping backpack. This wasn’t it.

    The gang over at Yomp Notes wrote a guide to make a DIY hip belt. I couldn’t make heads nor tails of their system for attaching the belt to the bag, so I tried something vastly simpler.

    My shopping list:

    1. Fairwin tactical belt. This is the tough, non-stretching nylon belt that cinches the setup snugly around your hips. It’s basically the tough version of a normal belt you’d wear to hold your pants up.
    2. Condor Elite battle belt. This is a padded wrapper that goes around the nylon belt for comfort. It doesn’t have a buckle of its own. Feel free to roll your eyes at the tacticoolness of the description, but here we’re using it purely for its width and the padding. You wouldn’t want to wear the nylon belt directly against your hips without it, unless you’re a fan of being sawed in half. We’re going to use those PALS straps on out its outside to connect it to the bag. Sizing tip: I’m 6 feet tall and, ahem, robust. I bought a medium and it wraps all the way around me. If you’re not sure which size to get, get the smaller option.
    3. Two C.A.M.P. Compact Oval Screwgate Locking carabiners to connect the battle belt to your GR1.

    First, open the velcro flaps on the battle belt to expose its inner channel, lay the nylon belt inside it, and close the velcro again. Ta-da! The belt is assembled.

    Next, thread the carabiners through the bottom 2 PALS straps on the sides your GR1, closest to the part of the pack that rests against your back.

    Finally, lay your battle belt against the padded back of your GR1. Find the 2 columns of PALS straps that are about the same width apart as the carabiners are on your pack. Err on the side of them being a little wider apart on your belt than they are on the GR1. Now work the carabiners through those straps on your belt.

    You’re done. There’s no step 4. Now your belt is attached securely to your GR1, and you can still remove it easily for all the times when you don’t want to wear a padded belt.

    This is how the attachment of the belt to the bag looks. It’s straightforward: the carabiners temporarily lock the belt snugly to the GR1.

    Close-up view of the carabiner passed through 2 loops on the belt and 2 loops of the bag so that they're locked together.

    This is how it looks from the front. See how the carabiner splays out to the side a little? When the belt is snug on you, that’ll put a small outward tension on the bag to hold it centered against your back.

    Front view of the extending out from the side of the bag, with the carabiner visibly holding them together.

    Eagle eyes might notice that the belt is technically upside down. Try it both directions and see what’s most comfortable for you. It’s your belt. You can wear it any way you want to.

    I like the end result much more than GoRuck’s own hip belt. Their belt attaches to the sides, too, but it doesn’t go all the way around your hips. It just stretches from one side of the bag, around your belly, and to the other side. That is, your bag becomes an integral part of the belt. The tighter you snug the belt, the harder it pulls the sides of your bag outward like wings. With the DIY belt, the only force between the belt and the bag is the weight of the bag pushing downward. Tension on the GR1’s PALS straps is purely upward against its weight, not upward and outward against the snugness of the belt.

    This setup costs more than the GoRuck version. I didn’t do this to save money. I did it to have a sturdy belt that works about as well as such a thing possibly can. I expect this setup to last almost as long as the GR1 itself.

    Forgejo Runner in rootless Podman on Debian

    I wanted to experiment with Forgejo’s Actions as a DIY alternative to GitHub Actions, using a nearby Raspberry Pi as a build server. I also wanted to deviate slightly from their Runner installation process by executing the Runner and rootless Podman as a regular, non-privileged user and without using the system-level systemctl. It was pretty easy once I wrapped my head around it.

    1. Set up the runner user. Since I was using Podman, not Docker, I didn’t have to add it to the docker group. As root:
    root# useradd --create-home forgejo-runner
    

    This created user number 1001 on my system. Remember that number later when it’s time to configure systemd.

    1. Allow that user to run commands via systemctl without logging in and launching them manually:
    root# loginctl enable-linger forgejo-runner
    
    1. Use machinectl instead of su to become the forgejo-runner user. Without this, most systemd commands will fail with the Failed to connect to bus: No medium found message. I’m certain there’s a way to get su or sudo to play nicely with dbus but I had more interesting problems to solve today than this.
    root# apt install systemd-container
    root# machinectl shell forgejo-runner@
    
    1. Run podman-system-service as the forgejo-runner user:
    $ systemctl --user enable podman.socket
    $ systemctl --user start podman.socket
    
    1. Run the forgejo-runner program as the forgejo-runner user. I lightly modified the standard forgejo-runner.service file:
    $ cat > .config/systemd/user/forgejo-runner.service <<EOHD
    [Unit]
    Description=Forgejo Runner
    Documentation=https://forgejo.org/docs/latest/admin/actions/
    After=podman.socket
    
    [Service]
    ExecStart=/usr/local/bin/forgejo-runner daemon
    ExecReload=/bin/kill -s HUP $MAINPID
    # 1001 is the forgejo-runner user's UID
    Environment="DOCKER_HOST=unix:///run/user/1001/podman/podman.sock"
    
    # This user and working directory must already exist
    WorkingDirectory=/home/forgejo-runner
    Restart=on-failure
    TimeoutSec=0
    RestartSec=10
    
    [Install]
    WantedBy=default.target
    EOHD
    $ systemctl --user daemon-reload
    $ systemctl --user enable forgejo-runner.service
    $ systemctl --user start forgejo-runner.service
    

    I rebooted my RPi to make sure it would start on its own and it did. Yay! Now I can run Forgejo Actions on my little server and everything works as documented.

    Fixing the Casper Glow Light charger

    Our Casper Glow Lights are nice. However, their charging bases are poorly made, and as seen in user reviews, they often break in a specific way. Inevitably, one or both of the little spring-loaded charging pins will permanently stick in the lowered position so that they don’t contact the charging elements on the light.

    The pin on the right is permanently recessed

    In this photo, the outer pin on the left sticks up a little above the charger’s base. When the light sits on this charger, that pin touches one of the light’s charging rings. The inner pin on the right is flush with the surface and doesn’t touch its corresponding charging ring.

    That’s easy to fix. Rather than disassemble the base and try to mechanically repair the pin, I added a tiny glob of solder to the top of the pin. Then I used an emery board and trial and error to smooth it to a good height.

    The pin on the right is a little taller now

    Ta-da! Now the Glow Light is charging away on the resuscitated charger.

    The Glow Light is happily charging again

    After cleaning, the charger looks and acts like new, and I bet that cheap little solder glob will outlast the original spring mechanism.

    Use local Git repos for personal work

    I’ve heard a lot of online arguments about whether you should host your Git-based projects in GitHub or GitLab, but a lot of them miss an obvious option. Is this repo for your own personal work that you don’t intend to share with others? Great! You can host unlimited, free, completely private repositories on your own system. Here’s the complete process:

    $ mkdir -p ~/src/myproject
    $ cd ~/src/myproject
    $ git init --bare
    $ cd ~
    $ git clone ~/src/myproject
    $ cd myproject
    

    There, you’re done. Now you have a 100% fully functional Git repo that doesn’t require a network connection and supports every single Git feature. Pull it, push it, branch it, revert it, whatever: it’s your own repo and you can do whatever you want with it. And you don’t have to sign up for anything, or agree to a Terms of Service, or share your work, or trust a company you don’t know very well.

    If you want to move your repo to another server later, you can copy ~/src/myproject to its new home via whatever means you find most convenient, use git remote set-url origin [...] to point your existing work toward the new location, and then go on about your business as usual without changing any of your workflow.

    GitHub and GitLab have a lot of nice features that may be totally irrelevant if you’re not collaborating with a team. Never forget that you can host Git projects yourself, easily and for free.

    Oh, and if you do find yourself needing to work with a handful of people and don’t need all of the integration features of the commercial options, I highly recommend Gitea. It’s a tiny little service you can host yourself and it takes very few resources. I use it whenever I need my Git repo to be accessible across the Internet.