I usually connect with my server via ssh in a terminal and run basic commands. What’s a better, more efficient and modern way of doing that? Especially considering ai and documentation along the way? I wonder if there’s a better approach than “connect from remote and act local”. Is there a method to “code local and push to remote”?
I use a fedora server with podman, caddyfile and vi.
You must log in or # to comment.
I wait for something to break. Then I yell “God fucking dammit, I don’t have time for this right now!” and spend an hour triaging things before I just try docker down, pull, up and everything works.
Poorly.
Hear hear
I just use ssh and manually type commands. Keep doing it and you will get good and it will become second nature.
No need to burn tokens on basic tasks.
Master your tools. Learn awk, sed, just, etc.
Some shell customisation can help. For example I’m fond of zsh-auto-suggestions and skim. Makes me quicker.
Ansible is one way to “code local, push to remote(s)”. Can define so-called playbooks, which is basically just a script, to do reoccuring tasks like e.g. updates.
I use ssh with tmux
This is the way
<insert Mandalorian gif here>
I write my NixOS configs in my PC, commit to the repo, then push it to the server. Then SSH in, and apply it. Or more likely, MOSH in.
It’s good to get comfortable in the command line, including over ssh.
Especially considering ai and documentation along the way?
If I am going to ask AI or Google about something, I just do that to help me find the answer and then apply the answer myself. That way I learn, and can double check the AI isn’t hallucinating, at least on in obvious ways.
As for documentation, I keep a notes folder with detailed notes on manual configuration I’ve done, how and why, and the things I’ve learned along the way. I’ve found it’s both useful to help remember the things I’ve learned, and it is useful to go back to refer to.
I ssh into it twice a year to perform updates but otherwise i leave it alone. Server’s been chugging along for like a decade now.
Similar, but you might want to update more frequently with the huge number of critical security bugs being discovered by AI recently
I have unattended upgrades configured
Twice a year is crazy. I suppose most of my maintainence is adding drives (I’m a creator and I definitely totally need to archive all of my footage), but I also run a fair few apps that have needed manual update steps, so I do all my updates manually so I can fix stuff if it breaks.
I’ve been using a program someone on Lemmy has been writing: SSHPilot. It helps keep my server list organized and can easily ssh to the machines or open up a file browser for easy drag and drop of files if I have some quick files to move around. It copies ssh keys easily as well.
nixos, mostly. It has a very steep learning curve but if it breaks I’m just “whatever, rollback now, fix properly later”.
Ansible.
That, and there is no change that isn’t done on ansible, or, when it required trying and research gets backported into a bit of ansible.
Nothing wrong with good old ssh. My VMs are different enough that building and maintaining ansible playbooks or something similar would be a bigger task than actually doing it in the traditional way. Maybe I could benefit by building simple playbooks to populate user accounts, ssh keys, smtp relay settings and other common things, but I don’t really set up new servers that often that it would justify spending time to set up tools for that.
Maybe a bit more on the overkill side, but I use Talos Linux (declarative K8s distribution), then Terraform for initial setup and FluxCD for everything else (including VMs via Kubevirt). It’s a hell of an initial learning curve, but afterwards I just do my talosctl upgrade and upgrade-k8s from time to time, and don’t have to worry about anything else. Upside is, Kubernetes provides a unified, extensible API for everything, for example:
- reverse proxy via Ingress or Gateway-API
- firewall via NetworkPolicy
- even databases like Postgres through an Kubernetes Operator like CNPG, with a similar simplicity as with the big cloud providers (just a single yaml file with the specs like storage capacity, CPU and memory limits, backup target and schedule etc.)
- it is very scriptable (everything is managed via the API)
- automated image updates via either FluxCD itself or just dependabot/RenovateBot creating PRs to your GitOps repo
Downsides:
- you have to figure out persistent storage (CSI), which is slightly more complicated than just a single filesystem and manually specifying volume mounts like with docker, but if done right, you have a simple interface with powerful capabilities via the Kubernetes API
- there are simple CSI implementations that just expose node local disks via LVM or ZFS, so if you just have a single node, or don’t care about replication, it’s fairly easy to get started
- initial learning curve is quite high, especially if you have no prior experience with container orchestration in general
- definitely overkill if you just want something simple that “just works”
I assume this is on your own physical hardware? What parts do you set up with terraform?
Yes, my own hardware. But before I decided to build my own server last September, I was on a similar setup on a dedicated server at Hetzner, just less powerful (I’m so goddamn glad I bought the memory and storage back then, I probably wouldn’t even get the 192GB DDR5 right now for the price I paid for all memory and storage combined).
Terraform starts at the Talos initial machine config and cluster bootstrap including CNI setup and routing configuration (I have an opnsense in front that handles ingress routing) until FluxCD is fully set up and takes over.
Ingress traffic works via a small Hetzner VPS, and BGP through Wireguard, so there is no DNAT or SNAT between the open Internet and my Kubernetes load balancers and all services see the actual client IP. This took a shit load of time to get right, because wireguard only has an mtu of 1420, but the regular uplink is usually 1500, so pmtu discovery in my load balancers implementation (Cilium) and mss clamping in opnsense had to all be configured
I spent a while getting Ansible to be able to setup and maintain my server(s). And ended up not using it as much as I should, mostly because the computer I used to run Ansible from became a “Steam Machine” so I’m rarely sitting on it with a keyboard now and I don’t want to have personal info and keys on my work computer.
But it was a good learning, and useful while I used it. Now I just use ssh and compose files directly.
My target is terraform to provide VMs on my miniPC and ansible to configure them. For my nas, probably a basic distro then some ansible stuff to setup stomate.
