Oldest version of FreeBSD still in current use

P

Paul Floyd

A quick straw poll

Currently [April 2020], what is the oldest version of FreeBSD that you are using?

In particular, is anyone still using FreeBSD 10 and older?
 
I've just retired our old pentium running 5.4 - it was our old home firewall, proxy and general blocker of all things "social" media. It's now in the storage area waiting for a trip to the e-recycler.

I loved the simplicity of 5.4, it was far less complicated, less commands and so, obviously, closer to the original 4.4BSD than FreeBSD 12 + is. Oh, and it only had a few hundred ports. (You couldn't build from ports now as most of the source links are broken but the packages are still all available).
 
I wonder what's the point? There are people running 7.x, for "some" reason ... and I've even seen a posting in some other forum recently where someone was looking for help with a 4.x (!) release.

But anyone running an EOL system (of any brand, not just FreeBSD) acts grossly negligent, at least if this system has *any* connection to the internet or access to any pluggable media.
 
Zirias said:
I wonder what's the point? There are people running 7.x, for "some" reason ... and I've even seen a posting in some other forum recently where someone was looking for help with a 4.x (!) release.

But anyone running an EOL system (of any brand, not just FreeBSD) acts grossly negligent, at least if this system has *any* connection to the internet or access to any pluggable media.
Click to expand...
If that's a veiled attempt to critique me, then you're so far from wrong that it's funny.

If you don't have any skill then it's quite easy to assume a new OS will protect you, when in fact any OS connected to the outside world is vulnerable if you don't know what you're doing. Case in point, Windows (any version).

This machine was running FreeBSD since 3.x and never has it been hacked. It's been attacked and survived, plenty of times. It didn't have needless ports or services open. It was a great multi-homing, squid proxy, mail and firewall device. The kernel was MUCH more simpler with less chance of bugs. Its uptime was measured in years!
Drivers were limited and again, less chance of bugs. Anyone knows, the increase in complexity adds a propensity for bugs to increase. It ran a simple old Pentium with 1GB RAM.

Compare that to modern CPUs which require mitigation to stem the tide of ever growing breaches. Makes you think just how secure your modern OS is, surely?
 
I didn't reply to your posting in particular, and if you think bad of my "skill", that's your personal point of view I'm not interested in and won't discuss.
 
I know it is generally frowned upon in these forums to run an old version of FreeBSD. Most questions regarding it are swiftly pointed to a post about EOL versions. In some ways though I suspect this is so that us members can give better advice rather than deciphering subtle version differences so I am fine with this.

... However if you block all ports apart from incoming SSH, unless there is a crucial issue in SSH daemon in the older version, you will be just as protected on the old version as one that is fully up to date.

Certainly Linux has this issue much more than FreeBSD but the dropping of hardware support because it is no longer "popular" is also a good reason to run an old version.

For me personally, the oldest BSD I still currently run in production/development is OpenBSD 5.9 for the Linux emulation (was dropped in 6.0) so that it can run the Linux-only Perforce client (it acts as a gateway between version control systems). That said, now it could be updated because the Perforce client was finally released open-source a year back.

I did also run FreeBSD 8 for a long time because I was fairly fond of Gnome 2 and wasn't quite ready to move to a different desktop environment once it was killed.

The oldest alternative operating system I run as a build machine is Windows 8. Released in 2012 (FreeBSD 9 era).
 
kpedersen said:
... However if you block all ports apart from incoming SSH, unless there is a crucial issue in SSH daemon in the older version, you will be just as protected on the old version as one that is fully up to date.
Click to expand...
Keep in mind SSH uses (Open)SSL, so this statement might have to be reconsidered -- at least, you'll have to do some extra work, so your sshd won't expose any well-known flaws.

That said, sure there are ways to run EOL systems in a secure way. It's just that's not what you find most of the time with people running them.

kpedersen said:
The oldest alternative operating system I run as a build machine is Windows 8. Released in 2012.
Click to expand...
Which is still supported.
 
What do we have there? "Real men patch remote exploits in old software by their pure awesomeness." Ah, ok then.

I'll show myself out now.
 
I didn't want to start a security flame war 😇

I've been setting up a few VirtualBox VMs, going back as far as FreeBSD 9.3 (which was fairly difficult). It doesn't look like its worth going back any further, even though it sounds like there are still users ov very old versions.
 
I remember coming across a firewall appliance running 4.3 when 8.0 was bleeding edge. The supplier was still selling them.
 
Paul Floyd said:
I didn't want to start a security flame war 😇

I've been setting up a few VirtualBox VMs, going back as far as FreeBSD 9.3 (which was fairly difficult). It doesn't look like its worth going back any further, even though it sounds like there are still users ov very old versions.
Click to expand...

I actually installed FreeBSD 6.2 on a old early-Pentium 4 PC for kicks late last year, and yesterday 7.2 in VirtualBox. And I only started using FreeBSD daily with 9.0.

I have never been able to try 5.x or below successfully.

Although for day-to-day use I use 13-CURRENT on desktops and 12.1 on servers/routers.
 
We were using Windows XP at Subway till just about five years ago. While everyone else had already moved to Windows 8, we were able to finally go to Windows7 with appropriate all new, needed hardware upgrades. Bumping up to Windows 8, shortly after, wasn't too awful but, again, going to Windows 10 required all new hardware and several weeks before anything worked properly.
 
kpedersen said:
I know it is generally frowned upon in these forums to run an old version of FreeBSD. Most questions regarding it are swiftly pointed to a post about EOL versions. In some ways though I suspect this is so that us members can give better advice rather than deciphering subtle version differences so I am fine with this.

... However if you block all ports apart from incoming SSH, unless there is a crucial issue in SSH daemon in the older version, you will be just as protected on the old version as one that is fully up to date.

Certainly Linux has this issue much more than FreeBSD but the dropping of hardware support because it is no longer "popular" is also a good reason to run an old version.

For me personally, the oldest BSD I still currently run in production/development is OpenBSD 5.9 for the Linux emulation (was dropped in 6.0) so that it can run the Linux-only Perforce client (it acts as a gateway between version control systems). That said, now it could be updated because the Perforce client was finally released open-source a year back.

I did also run FreeBSD 8 for a long time because I was fairly fond of Gnome 2 and wasn't quite ready to move to a different desktop environment once it was killed.

The oldest alternative operating system I run as a build machine is Windows 8. Released in 2012 (FreeBSD 9 era).
Click to expand...
I think if people come here looking for help on, say FreeBSD 8, then they shouldn't be running it. If you don't understand how to lock down a system, then you shouldn't be exposing any of it to the outside world. Perhaps too many here think running FreeBSD 12.1 will protect them from the meanies on the internet?

However, as you rightly point out, sometimes old systems run something you like and have no alternative.

In my case, we've been using (up until last year) this old FreeBSD box as our gateway. It's been super reliable (a testament to the pre-6 series OSs) and crash free. It runs only what is required, opens only what ports are needed and is more secure than most people's PCs they connect to the internet on.
 
Paul Floyd said:
I didn't want to start a security flame war 😇

I've been setting up a few VirtualBox VMs, going back as far as FreeBSD 9.3 (which was fairly difficult). It doesn't look like its worth going back any further, even though it sounds like there are still users ov very old versions.
Click to expand...
No, it's just people speaking from a level of ignorance. They assume an old system equals a leaky system. Nonsense.

There's probably no point or benefit intentionally going backwards, if other than for some educational merit. There's plenty of benefit in keeping an older system running. Mind you, with the old 5.4 box, it was intended I replace it about 4 years ago, but I just never got around to it. Why? Well it just worked. Shame on it and me!
 
Code: 
> uname -a
FreeBSD example.com 4.10-RELEASE-p22 FreeBSD 4.10-RELEASE-p22 #5: Thu Feb 28 02:46:42 PST 2008 someone@example.com:/build/obj/build/src/sys/BIGSYS  i386
> uptime
10:00PM  up 156 days, 20:51, 1 user, load averages: 0.05, 0.10, 0.08
There must have been a big power outage 156 days ago; usually this machine gets rebooted every few years.

This is a commercial multi-user machine, operated by an ISP, in current production; I removed the name. It is dead nuts reliable, and still performs billing and administration for the ISP. Coincidentally, the ISP is located in Berkeley, and the person who configured this machine worked at UCB on the BSD project.
 
FreeBSD 10.3 on my old ThinkPad 600 notebook. I was recently thinking about updating it to 12.1, but then again -- what for?
 
Oh, I do see quite some ignorance about the topic, for sure.

Nobody ever claimed that running a supported system on the latest patch level automatically protects you against any threat. But it's an important prerequisite, at least as soon as this system gets any "untrusted" data to operate on.

E.g. at some point, your system will have to expose some service (and if it's "only" ssh) to be useful. If it is exposed only in some "trusted" LAN, that's still a risk, but depending on the circumstances, it might be acceptable. If it is exposed to the internet, you're doomed. The same holds for any other data/input from untrusted sources, but the network is the most obvious one.

So, of course there are scenarios where running EOL systems doesn't hurt. Those are rare, and I bet most people operating such an EOL system actually overlook something. Very often, when talking about stability and uptime, these are just lame excuses for avoiding the work to upgrade the system. And once you're more than one major release behind, this work piles up to something that isn't manageable easily any more.

Yes, for (larger) organizations, the upgrade "blocker" are often applications that don't work with the new release -- this especially happens in Windows environments, but not only.
 
It seems it's too easy to conflate old systems with security risk. Potentially, every new system becomes a security risk as soon as you plug it in. Intel mitigations have seen to that.

Exposing a service to the internet does not spell the end of the world; that's why we have firewalls. Hell, even someone sitting on a Windows 95 computer has zero risk if they don't use a browser (and probably can't now anyway). Why? They're likely behind a NAT and firewall.

If one's not knowledgeable enough to lock down a system and just open up ports and services like a drunken carefree sailor, then it truly is curtains; eventually and deservedly.

I personally work with systems 15+ years old, running old versions of their applicable OS, that function fine and even are connected to the internet. It's a fact of life in business.

Anyway, this is diverting a long way away from the topic.
 
You must log in or register to reply here.
Back
Top