These devices have been recommended in the past, and it looks like they can run OpenWRT
https://www.amazon.com/GL-iNet-GL-SFT1200-Secure-Travel-Router/dp/B09N72FMH5
These devices have been recommended in the past, and it looks like they can run OpenWRT
https://www.amazon.com/GL-iNet-GL-SFT1200-Secure-Travel-Router/dp/B09N72FMH5
Bash and a dedicated user should work with very little effort. Basically, create a user on your VM (maybe called git
), set up passwordless (and keyless) ssh for this user but force the command to be the git-shell
. Next a simple bash script which iterates directories in this user’s home directory and runs git fetch —all
. Set cron to run this script periodically (every hour?). To add a new repository, just ssh as your regular user and su to the git user, then clone the new repository into the home directory. To change the upstream, do the same but simply update the remote.
This could probably be packaged as a dockerfile pretty easily, if you don’t mind either needing to specify the port, or losing the machine’s port 22.
EDIT: I found this after posting, might be the easiest way to serve the repositories, in combination with the update script. There’s a bunch more info in the Git Book too, the next section covers setting up HTTP…
I would probably use ntfy.sh for this purpose. It doesn’t quite meet all your requirements, but you could use a random channel name and get some amount of security…
You can self host it, or use the hosted version. (I know it’s technically not chat, but it works on a series of messages, it just happens to call them notifications.)
Yes, I have. I should probsbly test them again though, as it’s been a while, and Immich at least has had many potentially significant changes.
LVM snapshots are virtually instant, and there is no merge operation, so deleting the snapshot is also virtually instant. The way it works is by creating a new space where the difference from the main volume are written, so each time the application writes to the main volume the old block will be copied to the snapshot first. This does mean that disk performance will be somewhat lower than without snapshots, however I’ve not really noticed any practical implications. (I believe LVM typically creates my snapshots on a different physical disk from where the main volume lives though.)
You can my backup script here.
I don’t bother stopping services during backup, each service is contained to a single LVM volume, so snapshotting is exactly the same as yanking the plug. I haven’t had any issues yet, either with actual power failures or data restores.
My recommendation would be to utilize LVM. Set up a PV on the new drive and create an LV filling the drive (wit an FS), then move all the data off of one drive onto this new drive, reformat the first old drive as a second PV in the volume group, and expand the size of the LV. Repeat the process for the second old drive. Then, instead of extending the LV, set the parity option on the LV to 1. You can add further disks, increasing the LV size or adding parity or mirroring in the future, as needed. This also gives you the advantage that you can (once you have some free space) create another LV that has different mirroring or parity requirements.
It saves into the tiddlywiki HTML file. The default behaviour is to then trigger the browser to download the file. You can absolutely store it in a git repository.
TiddlyWiki might be a good option. Technically it’s a wiki, but it is a single HTML page with all functionality built in JavaScript, you could host it on GH pages, though you wouldn’t be able to use its save feature there (you would have to save to your local machine and the deploy a new version). It stores text in little (or large) cards which can be given a title, tags and other metadata, and it providesa full search system.
The peer range shouldn’t be your LAN, it should be a new network range, just for WireGaurd. Make sure that the server running Immich is part of the WireGaurd network.
My phone and laptop see three networks: the internet, the lan (192.168.1.0/24, typically) and WireGaurd (10.30.0.0/16). I can anonymize and share my WireGaurd config if that would help.
I use WireGaurd, it’s set to on demand for any network or cellular data (so effectively always on), no DNS records (I just use public DNS providing private range IP addresses). It doesn’t make any sort of dent in my battery life. Also, only the wiregaurd network traffic is routed through it, so if my server is down the phone/laptop’s internet continues to work. I borrowed my wife’s phone and laptop for 15 minutes to set it up, and now no one has to think about it.
I backup to a external hard disk that I keep in a fireproof and water resistant safe at home. Each service has its own LVM volume which I snapshot and then backup the snapshots with borg, all into one repository. The backup is triggered by a udev rule so it happens automatically when I plug the drive in; the backup script uses ntfy.sh (running locally) to let me know when it is finished so I can put the drive back in the safe. I can share the script later, if anyone is interested.
I did not know that, last I looked it was still in development, I believe.
Something that LVM supports but ZFS and BTRFS don’t, is the ability to reduce your storage. (That is, to empty and remove a drive from the array, without having to completely destroy the storage array.) As a home user without sufficient storage to have complete duplicates of everything, I find this an important feature.
What about simply shelling out to ripgrep?