Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

crocidb.com

Post reply on HN
Print view View original

191–200 of 241 posts

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#191

Post by jeanlucas »

gerdesj wrote: post #81
arjie wrote: post #62

The biggest mistake I made was high uptime. arjie.com was up for 10 years plus on a Hetzner VPS so that by the time they wanted to sunset the machine underlying I had no idea what my teenage self had set up. I have the backups but the site hasn’t been up in a decade… Nowadays I build things so that they move and I have moved things about a bit so I know they work.

"The biggest mistake I made was high uptime" Quite. I'm old enough to remember machine uptime being a badge of honour. However, being older and not really wiser, I look for service uptime these days. Yes we did have similar back in the day, that's why MX and the like DNS records exist. Old school clusters were pretty esoteric but the lessons were learned (split brain n that) and that's why we still argue the toss wit…

> Yes we did have similar back in the day, that's why MX and the like DNS records exist.

Care to elaborate? I wanna know more.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#192

Post by brightball »

gerdesj wrote: post #81
arjie wrote: post #62

The biggest mistake I made was high uptime. arjie.com was up for 10 years plus on a Hetzner VPS so that by the time they wanted to sunset the machine underlying I had no idea what my teenage self had set up. I have the backups but the site hasn’t been up in a decade… Nowadays I build things so that they move and I have moved things about a bit so I know they work.

"The biggest mistake I made was high uptime" Quite. I'm old enough to remember machine uptime being a badge of honour. However, being older and not really wiser, I look for service uptime these days. Yes we did have similar back in the day, that's why MX and the like DNS records exist. Old school clusters were pretty esoteric but the lessons were learned (split brain n that) and that's why we still argue the toss wit…

In 2012 I took over a Perl project that was running on 25 BSD servers (OpenBSD I think?) that had not been updated / patched since 2000. It was an interesting time.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#193

Post by yard2010 »

tracker1 wrote: post #41

Personally, I've been running with Caddy in front of Docker (compose) for most of my personal/hobby usage. If it's a straight website, I'll let Caddy serve the contents directly... for "web apps" I'll pretty much containerize all the things and use caddy for TLS termination and reverse-proxy duties to the app running under Docker... Mostly ~/apps/appname, where each appname has a docker compose file, and the data dir…

I have started using Traefik on one of my projects and it's a nice upgrade from nginx proxy manager. NPM is great, its web gui is noce, but with Traefik all I need to do is write what I want to happen in the docker compose file and that's it.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#194

Post by X0Refraction »

mx7zysuj4xew wrote: post #176
da_chicken wrote: post #155

Earlier quoted context omitted.

The problem with live patching is twofold. First, you might not reload everything in memory, so it will be patched on disk but not in process. Second, you have not tested that the system can boot to a functional system. Say you have done live patching for 5 years and never rebooted, and then you have a power loss or hardware failure/upgrade that takes the system down. When you try to bring it back up, it doesn't work…

Which is moot, because of the system is important enough you'll have an automatic failover to another system running on standby All this "we must reboot to test" is bullshit excuses by unqualified workers

Not sure I'm following honestly. Your primary goes down and it fails over to the secondary (which becomes the primary), but if you can't boot how do you then get another secondary ready to fail over to again when the new primary inevitably fails?

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#195

Post by TingPing »

mx7zysuj4xew wrote: post #179
d3Xt3r wrote: post #118

Earlier quoted context omitted.

How about a lightweight immutable distro, like say Fedora CoreOS or openSUSE MicroOS? Fedora CoreOS in particular has had a good track record delivering patches quickly. Like for CopyFail was pushed to the stable channel in about a day, IIRC, but the patch was already available within a few hours of disclosure in the "next" / testing channel. Talos and Flatcar are also worth considering if you want an even smaller at…

Fedora is a staging environment for RHEL

This oversimplifies reality. Fedora has a community and actively makes decisions RHEL has no interest in. But yes they also help with testing many things.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#196

Post by kjs3 »

da_chicken wrote: post #155
pjmlp wrote: post #128

Earlier quoted context omitted.

There is something like live patching. One reason mainframes and micros are still around us, is that you can change almost everything between hardware and software without downtime. It is also available in commercial surviving UNIXes, and as paid for feature in some Linux distros, although not to the extent that those grandparent systems are capable of.

The problem with live patching is twofold. First, you might not reload everything in memory, so it will be patched on disk but not in process. Second, you have not tested that the system can boot to a functional system. Say you have done live patching for 5 years and never rebooted, and then you have a power loss or hardware failure/upgrade that takes the system down. When you try to bring it back up, it doesn't work…

And, yeah, everything is hot swappable on VAX.

Only the last generation or 2 of the highest end VAXen had any significant hot swap (VAX 9000/400 and later, which sold very poorly). The vast majority of VAX machines didn't. Even hot-swapping DSSI disks was at best iffy.

When someone whose been there talks about VAX 'high availability', they're usually talking about VAX/VMS clustering. Very cool and generally effective approach to the problem. That was one big issue with the end-game VAXen: clustering a couple of 6-figure mid-range machine was often considered a better solution than all-in on one 7- to 8-figure VAX 'mainframe'.

often require a service contract that includes a permanent on site tech.

I don't recall that being common with DEC service contracts. Most of the sites I know of that had dedicated DEC techs were either very large installs or had...other...drivers (e.g. tech had to have a TS clearance to work on the machines).

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#197

Post by kjs3 »

jeanlucas wrote: post #191
gerdesj wrote: post #81

Earlier quoted context omitted.

"The biggest mistake I made was high uptime" Quite. I'm old enough to remember machine uptime being a badge of honour. However, being older and not really wiser, I look for service uptime these days. Yes we did have similar back in the day, that's why MX and the like DNS records exist. Old school clusters were pretty esoteric but the lessons were learned (split brain n that) and that's why we still argue the toss wit…

> Yes we did have similar back in the day, that's why MX and the like DNS records exist. Care to elaborate? I wanna know more.

MX records publish an SMTP server for a domain and a 'priority'. You can have multiple MX records and (theoretically[1]) you try the one with the lowest priority, and if it doesn't respond, try the next lowest, etc. Or (theoretically[1]) if you have 2 MX records with the same priority, you can load balance between them.

https://www.cloudflare.com/learning/dns/dns-records/dns-mx-r...

[1] yes...I know there's a ton of caveats here...

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#198

Post by BadBadJellyBean »

andix wrote: post #19
BadBadJellyBean wrote: post #16

Earlier quoted context omitted.

You are betting that whatever you host doesn't live as long as the upgrade cycle because it'll probably be a pain when the upgrades finally arrive. I'd rather have smaller version jumps more often than a huge jump with everything changing after a long time.

It usually doesn't live until the end of the support cycle. And if it does I will probably migrate it to a fresh VM instead of upgrading the distribution.

I'm not worried about upgrading. I'm worried about the whole environment being potentially several versions newer than the old one. All shared libraries. All services. Everything new. And now you have to make a software that has had little upgrades run on that. Have fun.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#199

Post by peanut-walrus »

exyi wrote: post #157
peanut-walrus wrote: post #151

Earlier quoted context omitted.

I see no reason not to go with a rolling release distro for personal servers. Run all the services in containers and have the base OS auto-update itself as often as it needs. Went with openSUSE MicroOS myself, it updates and reboots almost daily so I can be pretty confident my server is healthy and it's atomic so if something does break and I don't feel like dealing with it, I can just click rollback button from cock…

Then you also have to auto-update the containers, if it's a public facing service. Either you'll have to build containers yourself or hope the developer pushes a new update whenever the base image has relevant security fixes.

Yup, podman quadlets autoupdate quite nicely. Setting up a local registry mirror with ~3d delay before applying updates is on my todo list.

My own service images already have a script that runs daily that pulls latest git updates and builds fresh images.

Re: Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

#200

Post by peanut-walrus »

mx7zysuj4xew wrote: post #178
peanut-walrus wrote: post #151

Earlier quoted context omitted.

I see no reason not to go with a rolling release distro for personal servers. Run all the services in containers and have the base OS auto-update itself as often as it needs. Went with openSUSE MicroOS myself, it updates and reboots almost daily so I can be pretty confident my server is healthy and it's atomic so if something does break and I don't feel like dealing with it, I can just click rollback button from cock…

Everything you listed is the antithesis to managing and maintaining high availability systems

It's your personal toy server, you are optimizing for something entirely different than high availability.
Post reply on HN