You don’t need a dedicated git server if you just want a simple place to store git. Simply place a git repository on your server and use ssh://yourserver/path/to/repo as the remote URL and you can push/pull.
If you want more than that (i.e. a nice Web UI and user management, issue tracking, …) then Gitea is a common solution, but you can even run Gitlab itself locally.
“Use vim in SSH” is not a great answer to asking for a convenient way to edit a single file, because it requires understanding multiple somewhat-complex pieces of technology that OP might not be familiar with and have a reasonably steep learning curve.
But I’d still like to explain why it pops up so much. And the short version is very simple: versatility.
Once you’ve learned how to SSH into your server you can do a lot more than just edit a file. You can download files with curl directly to your server, you can move around files, copy them, install new software, set up an entire new docker container, update the system, reboot the system and many more things.
So while there’s definitely easier-to-use solutions to the one singular task of editing a specific file on the server, the “learn to SSH and use a shell” approach opens up a lot more options in the future.
So if in 5 weeks you need to reboot the machine, but your web-based-file-editing tool doesn’t support that option, you’ll have to search for a new solution. But if you had learned how to use the shell then a simple “how do I reboot linux from the shell” search will be all that you need.
Also: while many people like using vim, for a beginner in text based remote management I’d recommend something simpler like nano.
Billionaires don’t “work”. At least not in the sense that they get some amount of money that’s in any way in relation to the value they create. They shuffle around money to do things for them and sometimes that makes them more money. Calling that “work” lessens the meaning of that word and gives them too much credit.
I like to imagine that whenever there was a particularly slow day or someone was particularly stressed, they just opened the prepared article and tweaked and improved it a bit … it’s probably the collaborative work of many people over many years.
ZFS is nifty and I really like it on my Homelab Server/NAS. But it is definitely a “sysadmins filesystem”. I probably wouldn’t suggest it to anyone just for their workstation, as the learning curve is significant (and you can lock yourself into some bad decisions).
ZFS combines the features of something like LVM (i.e. spanning multiple devices, caching, redundancy, …) with the functions of a traditional filesystem (think ext4 or similar).
Due to that combination it can tightly integrate the two systems and not treat the “block level” as an opaque layer. For example each data block in ZFS is stored with a checksum, so data corruption can be detected. If a block is stored on multiple devices (due to a mirroring setup or raid-z) then the filesystem layer will read multiple blocks when it detects such a data corruption and re-store the “correct” version to repair the damage.
First off most filesystems (unfortunately and almost surprisingly) don’t do that kind of checksum for their data: when the HDD returns rubbish they tend to not detect the corruption (unless the corruption is in their metadata in which case they often fail badly via a crash).
Second: if the duplication was handled via something like LVM it couldn’t automatically repair errors in a mirror setup because LVM would have no idea which of the blocks is uncorrupted (if any).
ZFS has many other useful (and some arcane) features, but that’s the most important one related to its block-layer “LVM replacement”.
I was about to mention that ;-) Whenever I find myself looking for software in an area where I don’t know any of the “competitors”, I’ll look for the awesome-* lists. At the very least they are always a good starting point.
I’m torn a bit, because architecturally/conceptually the split that LVM does is the correct way: have a generic layer that can bundle multiple block devices to look like one and let any old filesystem work on top of that. It’s neat, it’s clean, it’s unix-y.
But then I see what ZFS (and btrfs, but I don’t use that personally) do while “breaking” that neat separation and it’s truly impressive. Sometimes tight integration between layers has serious advantages too and neat abstraction layers don’t work quite as well.
Once I’ve set up SSO I’d want to use it in as many places as possible. Not having to handle additional unnecessary passwords is a benefit.
Yes! As soon as your homelab grows above a couple of services and especially if it’s used by two or more people SSO becomes an absolute necessity! The tolerance of non-technical users for handling a bunch of passwords and having to enter them everywhere is understandably low.
The Home Assistant devs apparently also deal SSO as “a corporate feature that big-corp interests want to force onto us” whereas it’s the exact opposite in many cases: If we want self hosted services to be a realistic alternative to the “big corpo offerings” then we have to consider convenience and security an important feature and SSO is one of the few things that improves both at the same time.
If you want to go all philosophical about it, think about who decided what “insane” means. That was the same species. So we set arbitrary standards of sanity and then we repeatedly fail to meet them … something something philosophy …
But that’s exactly what every other Employee and country is doing.
And he’s not capable of handling the fact that someone might be standing up to him.
And I don’t even mean that in a “doesn’t have a business plan to handle that situation” sense either. I think that he’s personally not emotionally stable enough to fully grasp what’s happening.
This is also by the author of Uptime Kuma, which explains the similarity in UI.
Portainer has so many tiny broken places that I effectively treat it only as a read-only view. It lists my containers and shows my logs and nothing much else.
It could in theory do quite a bit more, but starting from the fact that it doesn’t quite do docker-compose, but its own thing that’s somehow similar but different there’s just too many tiny issues with it.
Also, it’s quite aggressively pushing the paid option without a way to turn that off (or at least turn it down to tolerable levels).
I’m using it too and even the current prices are reasonable (especially if you consider there’s no other fees, no transfer, no ingress, no egress, …). If you put it in S3 glacier and you ever have to restore a relevant chunk of your data (or god forbid, want to do periodic testing of the backed up data) then you’ll be paying quite a bit of fees.
And if that’s not enough, then at least there won’t be any humans around to suffer through it!
But you’re fighting against a fundamental urge of life here … kinda hard to achieve that at a large scale. At least that’s why I tell myself and my kid.
I just use Ansible to prepare the OS, set up a dedicated user, install/setup Rootless Docker and then Sync all the docker compose files from the same repo to the appropriate server and launch/update as necessary. I also use it to centrally administer any cron jobs like for backup.
Basically if I didn’t forget anything (which is always possible) I should be able to pick a brand new RPi with an SSD and replace one of mine with a single command.
It also allows me to keep my entire setup “documented” and configured in a single git repository.
I’m using encrypted ZFS as the root partition on my server and I’ve (mostly) followed the instructions in point #15 from here: https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html
This starts dropbear as an SSH server that only has a single task: when someone logs in to it they get asked for the decryption key of the root partition.
I suspect that this could be adopted to whatever encryption mechanism you use.
I didn’t follow it exactly, because I didn’t want the “real” SSH host keys of the host to be accessible unencrypted in the initrd, so the “locked host” has a different SSH host key than when it is fully booted, which is preferred for me.