I agree with him, simpler is better and I still have not jumped on the container bandwagon. I did use Jails on FreeBSD and from my limited experience, I still think Jails is much better than anything Linux offers.
Old school Linux administration – my next homelab generation
61–70 of 115 posts
Re: Old school Linux administration – my next homelab generation
#62Earlier quoted context omitted.
When you only need docker to isolate your dependencies, its unnecessary overhead.
You made a point about complexity, I'm talking about that, why are you talking about overhead? As for overhead, what is the quantified measure of it? Like sure there's overhead, but exactly how much?
You don't need to run a network bridge because you want to run two daemons of the same kind.
Re: Old school Linux administration – my next homelab generation
#63HA is overrated, i'd much rather go for a low mean time to repair.
Backups, reinstall, ansible playbook is my way to go if hardware fails, which is quite rare to be honest. HA goes beyond hardware in terms of "electricity, internet connection, storage, location etc.., IMO people quite often underestimate what it means to have real HA --> second location with identical setup to shift workload or even have active-active instead of active-passive.
i have an intel nuc as plain debian server with containers on it.
2 raspberry pi's(act as loadbalancers with traefik and authelia on top) and a hetzner vm all connected through wireguard.
All is configured via ansible and i rely on LE certificates to connect via https or directly via wireguard vpn to http if i want it only exposed via vpn.
encrypted backups are copied via wireguard to an offsite storage box.
full down to back online if hardware is not damaged is less than 15 min.
it is very easy to do and rock solid, unattend-upgrades does the trick. i tried almost every combination and even though i am a k8s user from version 1.2 onwoards the complexity for k8s at home or even vsphere is too much for me vs. this super simple and stable configuration i now have.
Re: Old school Linux administration – my next homelab generation
#64Earlier quoted context omitted.
You made a point about complexity, I'm talking about that, why are you talking about overhead? As for overhead, what is the quantified measure of it? Like sure there's overhead, but exactly how much?
You don't need to run a network bridge because you want to run two daemons of the same kind.
I never said you did. I'm asking you to quantify the costs because all engineering and ops decisions involve tradeoffs. Just because something incurs overhead, or is on of several solutions, it doesn't mean that it's bad. It's just an additional factor for consideration. So what are the actual overhead costs?
Re: Old school Linux administration – my next homelab generation
#65Earlier quoted context omitted.
Depends on what system you want to administrate. The topic is very broad. But it never hurts to understand the fundamentals: - networking (IPv4/IPv6/TCP/UDP/ICMP/various link layer technologies (ethernet, wifi, ppp, USB, ...)... and concepts like VPNs/VLAN/bridging/switching/routing/...) - protocols (DHCP, DNS, NTP, SMTP, HTTP, TLS, ...) - chosen OS fundamentals (so on Linux things like processes, memory, storage, pr…
This is a helpful review of the fundamentals to cover. I will definitely be doing my own searches for content on the topics. Do you have any good references for resources in the vein of teaching the fundamentals. Not like "DNS: here is how to configure a BIND server" but like "DNS: Here are the core concepts, what you will typically need to set up, common issues / confusions, and further reading." I have tried going…
I'm reading this book and it contains explanations about "why" too, in addition to some light historical context in places:
Douglas Comer: "Internetworking with TCP/IP Volume One 6th Edition"
Re: Old school Linux administration – my next homelab generation
#66I love LXC/LXD for my home server. Far easier to use and maintain than VMs, fast, and use far less resources than VMs. And understanding containers is great foundational knowledge for working with Docker and K8s. They also work great with NextCloud, Plex, PostgreSQL, and Zabbix, and SAMBA. But each are separate, no risk of a library or an OS upgrade taking out an app (and my weekend along with it). Snapshots are the…
Would you use LXD in production?
Re: Old school Linux administration – my next homelab generation
#67Earlier quoted context omitted.
I think nowadays requiring that all application developers should also do ops (DevOps?) is a bad idea. Sure they should have basic shell skills, but when you’re on Kubernetes or similar, understanding what’s underneath is not vital. Instead, rely on specialized teams that actually want to know this stuff, and become the experts you escalate to only when things really go sideways and the abstractions fail (which is ra…
But then there's the problem that now you have two teams - ops team doesn't understand the app and app team doesn't understand the ops/infra side. I of course agree with your point that there should be two teams but you need a few guys who understand both app dev and ops/infra/OSes/k8s internals etc. And finding these people has been nearly impossible.
You can just add an ops guy with minimal coding to a dev team and it works wonders. Ops guy does the ops stuff, writes the shell scrips and consults with the devs on how to build what they need to build.
The ops guy has an opportunity to level up his coding since the devs are doing code reviews for him and devs have an opportunity level up their ops knowledge because they are working with someone who understands what hand how platform should be built.
Re: Old school Linux administration – my next homelab generation
#68Once you work in enterprise IDC, setting up home labs is nothing but a liability. Unwanted stuff like UPS, cooling and more bills. I have one Intel NUC running FreeBSD 13 (dual SSD with 32 GB ram and Intel i7 CPU 8th GEN) with one jail and VM. It acts as a backup server for my Ubuntu laptop and MacBook pro. Nightly I dump data to cloud providers for offsite reasons. Finally, I set LXD, Docker and KVM on my Ubuntu dev…
Agreed, I used to run enterprise hardware at home, and it was certainly fun to tinker with (Not to mention all of the blinking lights!). Last year I ran some numbers and realized that it just wasn't worth it, as electricity costs alone make it fairly close to what Hetzner/OVH would charge for similar hardware. I also had power go down in my area, for probably first time in 5 years or so that I lived there, which I to…
[deleted]
Re: Old school Linux administration – my next homelab generation
#69I love LXC/LXD for my home server. Far easier to use and maintain than VMs, fast, and use far less resources than VMs. And understanding containers is great foundational knowledge for working with Docker and K8s. They also work great with NextCloud, Plex, PostgreSQL, and Zabbix, and SAMBA. But each are separate, no risk of a library or an OS upgrade taking out an app (and my weekend along with it). Snapshots are the…
Would you use LXD in production?
If you build it yourself from source or use distro packages. Running it under cannonical's snap packages is a bit of a nightmare because of issues around the forced auto updates.
Re: Old school Linux administration – my next homelab generation
#70HA is overrated, i'd much rather go for a low mean time to repair. Backups, reinstall, ansible playbook is my way to go if hardware fails, which is quite rare to be honest. HA goes beyond hardware in terms of "electricity, internet connection, storage, location etc.., IMO people quite often underestimate what it means to have real HA --> second location with identical setup to shift workload or even have active-activ…
Quick to repair is also a lot more versatile. Unfortunately, I had to work in a lot of environments with proprietary, vendor-locked software and hardware. Usually all you can do is make sure you design the system so that you can chuck entire parts of it (possibly for rework, but sometimes not) if it breaks or gets compromised.
Definitely relevant for, say, SCADA controls with terrible security.