OpenBSD Passes 300,000 Commits(undeadly.org)
undeadly.org
OpenBSD Passes 300,000 Commits
http://www.undeadly.org/cgi?action=article&sid=20141019130102&mode=expanded
4 comments
For those who have heard of OpenBSD but have not used it, I strongly recommend trying it on your next server appliance. I have been using it on my servers for some time now and I have been very happy. The entire OS seems to be of substantially higher quality than Linux.
Also things are deceptively simple. There's of course the initial hiccup for new users since the setup is a tad esoteric, but once past that, using it is very straightforward.
It's not quite "set it and forget it" for servers, but pretty close IMHO.
There's an attitude among the developers of making it extremely difficult to run sub-par code on the OS, which makes the overall quality of most ported apps high, quite stable and (unpleasant)surprise-free.
It's not quite "set it and forget it" for servers, but pretty close IMHO.
There's an attitude among the developers of making it extremely difficult to run sub-par code on the OS, which makes the overall quality of most ported apps high, quite stable and (unpleasant)surprise-free.
It's very close to set-it-and-forget-it.
A buddy of mine is an overworked (and underpaid) sysadmin for a small ISP, and commented the other day that the OpenBSD firewall that I built for them 7 years ago (!) is still humming along nicely, they're still using and tuning its rulesets, and it wasn't vulnerable to shellshock.
(This isn't to say that not updating a firewall for 7 years is good practice, obviously. I shouldn't have to say that, but HN.)
A buddy of mine is an overworked (and underpaid) sysadmin for a small ISP, and commented the other day that the OpenBSD firewall that I built for them 7 years ago (!) is still humming along nicely, they're still using and tuning its rulesets, and it wasn't vulnerable to shellshock.
(This isn't to say that not updating a firewall for 7 years is good practice, obviously. I shouldn't have to say that, but HN.)
I'm looking to set up an OpenBSD server myself. Things are going quite well, but I'm not looking forward to the upgrade process (as an example, here's 5.4 -> 5.5 http://www.openbsd.org/faq/upgrade55.html). How easy has it been for you to upgrade?
Its actually very easy to upgrade OpenBSD. There is lots of information on that page and you should read it all, but the actual process of the upgrade is quick.
Following -current and updating within a release
Would you recommend the patch by patch process or the full check out code and compile?
Would you recommend the patch by patch process or the full check out code and compile?
Success recipe I use:
1. Install a release.
2. Subscribe to the security list.
3. Patch any issues that turn up and may affect you using the instructions in the patch. Rarely this requires a reboot. Don't patch anything you don't need to.
4. Upgrade release a couple of weeks after it is released (everyone else has found the bugs then ;-)
5. To manage ports, subscribe to the ports mailing list, create packages yourself from ports on another machine and install them and upgrade them yourself if there is an upgrade or security hole posted.
Before you do anything though, test it on another host properly. YMMV with all updates on all platforms.
1. Install a release.
2. Subscribe to the security list.
3. Patch any issues that turn up and may affect you using the instructions in the patch. Rarely this requires a reboot. Don't patch anything you don't need to.
4. Upgrade release a couple of weeks after it is released (everyone else has found the bugs then ;-)
5. To manage ports, subscribe to the ports mailing list, create packages yourself from ports on another machine and install them and upgrade them yourself if there is an upgrade or security hole posted.
Before you do anything though, test it on another host properly. YMMV with all updates on all platforms.
I appreciate the OS, but I wish it had a longer lifetime, as it is I can't really set it up on servers in a serious manner.
It might be good on firewalls though where they don't expose a lot of services to the internet.
It might be good on firewalls though where they don't expose a lot of services to the internet.
That's not really a major concern if you've used it at all.
Their lifecycle is security oriented and you only get reliable security coverage if you keep something up to date. There's no point in sitting around living off backports and patches forever as all that does is create work.
It's pretty easy to upgrade as well.
With respect to application services, they can evolve independently to the base OS as well.
Their lifecycle is security oriented and you only get reliable security coverage if you keep something up to date. There's no point in sitting around living off backports and patches forever as all that does is create work.
It's pretty easy to upgrade as well.
With respect to application services, they can evolve independently to the base OS as well.
I've toyed with it, not sure if that qualifies as "used". As a DC sysadmin I live off backports and patches (CentOS). 99% of our deployed OSes are all supported a long (to very long) time.
I used to do that but having had certain duff kernels and SMB packages out of RH, they can go to hell.
This one took out our SMB/CIFS implementation in CentOS 6.2 forcing us to grab some windows licenses in the end (which I will add has been damn reliable):
https://bugzilla.redhat.com/show_bug.cgi?id=476442
Still broken in CentOS 6.5 and Centos 7.0. Many people have raised this issue (google it) and it's always "fixed next release".
Patched and built my own kernel in the end but by then it was too late.
No thanks. Had enough of crap like that.
This one took out our SMB/CIFS implementation in CentOS 6.2 forcing us to grab some windows licenses in the end (which I will add has been damn reliable):
https://bugzilla.redhat.com/show_bug.cgi?id=476442
Still broken in CentOS 6.5 and Centos 7.0. Many people have raised this issue (google it) and it's always "fixed next release".
Patched and built my own kernel in the end but by then it was too late.
No thanks. Had enough of crap like that.
Well, I won't turn this into a thread to fix that problem, but have you tried these packages?
http://enterprisesamba.com/
Having said that, switching to OpenBSD is not as simple. It's not just some random web server with 2 sites on it; we're talking many, many servers with a great range of software running on them and so on. Some of this software will not even run on OpenBSD at all and so on. The problems are many. :)
The big linux distros - buggy as they are - are here to stay.
Also, some interesting "statistics" from $dayjob. Our DC workload (dedicated servers) is mostly web stuff; when I joined the company in 2009 there were a reasonable amount of FreeBSD servers around; that number is now 0 (or very close); my opinion is that it went "extinct" because of poor binary updates and package management as well as lack of long term support. CPanel stopping to support it was probably the last nail in the coffin. I'm seeing a similar thing with Debian, Ubuntu LTS took over that customer base.
OpenBSD - from our pov - is facing the same issues. I'd love to see more BSDs deployed, but this will not happen unless the above points are addressed. Add to that the lack of "kickstart"-like functionality, as well.
Having said that, switching to OpenBSD is not as simple. It's not just some random web server with 2 sites on it; we're talking many, many servers with a great range of software running on them and so on. Some of this software will not even run on OpenBSD at all and so on. The problems are many. :)
The big linux distros - buggy as they are - are here to stay.
Also, some interesting "statistics" from $dayjob. Our DC workload (dedicated servers) is mostly web stuff; when I joined the company in 2009 there were a reasonable amount of FreeBSD servers around; that number is now 0 (or very close); my opinion is that it went "extinct" because of poor binary updates and package management as well as lack of long term support. CPanel stopping to support it was probably the last nail in the coffin. I'm seeing a similar thing with Debian, Ubuntu LTS took over that customer base.
OpenBSD - from our pov - is facing the same issues. I'd love to see more BSDs deployed, but this will not happen unless the above points are addressed. Add to that the lack of "kickstart"-like functionality, as well.
Okay, what I'm about to say might not be too popular with some people, but I'll say it anyway:
How much did you pay for CentOS? Perhaps if more people were willing to pay for RedHat and/or Samba, some of the more obscure bugs would more readily get fixed.
In the general case, developers need to put food on their dinner table and put a roof over their heads. Good quality "free" software only goes so far, OpenBSD pulls it off because they limit the scope of their efforts.
So, instead of complaining about CentOS, buy some RedHat licenses. The end result might not be any different but you'll at least have paid for the right to complain.
How much did you pay for CentOS? Perhaps if more people were willing to pay for RedHat and/or Samba, some of the more obscure bugs would more readily get fixed.
In the general case, developers need to put food on their dinner table and put a roof over their heads. Good quality "free" software only goes so far, OpenBSD pulls it off because they limit the scope of their efforts.
So, instead of complaining about CentOS, buy some RedHat licenses. The end result might not be any different but you'll at least have paid for the right to complain.
> The entire OS seems to be of substantially higher quality than Linux.
That's a pretty bold statement. Care to elaborate?
That's a pretty bold statement. Care to elaborate?
This was posted on HN a little while ago. It gives some great insight into their process : http://www.openbsd.org/papers/dev-sw-hostile-env.html
Summary: Basically, the development process for OpenBSD is the same as stomach acid. To survive this environment is an exercise in code correctness. I.E. It's designed to break things that aren't up to par. The end result is a platform that doesn't sacrifice stability and security (the two often are two sides of the same coin) for the sake of compatibility.
Summary: Basically, the development process for OpenBSD is the same as stomach acid. To survive this environment is an exercise in code correctness. I.E. It's designed to break things that aren't up to par. The end result is a platform that doesn't sacrifice stability and security (the two often are two sides of the same coin) for the sake of compatibility.
As a long time lurker, I'm going to jump on this one.
Yes it is bold by the user but I agree entirely.
I spent the best part of a decade running Solaris and Linux machines from 1998-2008. The Solaris kit was easy to keep running once you'd got over the initial configuration hell and was very stable. The Linux stuff however was nasty at best. From CIFS/SMB crashes taking out the VFS layer to drivers packing in to incorrect documentation to random hangups. That is across CentOS and Debian. They are not even remotely stable IMHO. Debian is far better than CentOS was but that still pales in comparison to even, dare I say it, Windows Server 2008.
As a sideline, I'd been using OpenBSD on a couple of test machines because it was interesting and I encountered entirely the opposite of the above. I threw it into production instead of a CentOS 5 box that we were retiring as a postfix/dovecot SMTP/IMAP box. The throughput is about 10-15%[1] less but my word the thing is a million times easier to administer and is absolutely bomb proof. Every configuration option, tool etc is entirely and perfectly documented. It is nothing but bliss. It just keeps ticking. We now have 3 hosts on it. The only missing bit is a decent OpenJDK port but the software guys are starting to use Python for a lot of stuff so that may be moot shortly anyway.
My metric for an operating system's reliability is if it goes wrong, how much crap do I have to deal with? Well I'm confident that if an OpenBSD host went down that I could have it back up, even if the internet connection was out and all I had was an OpenBSD CD. I can't say the same about anything else these days. Last time I lose an md raid on Linux, it took me a day to get it back due to nothing but crappy documentation and bugs even those it was a tested recovery strategy.
[1] The thing is a hefty HP Xeon box so this is background noise compared to the actual load.
Yes it is bold by the user but I agree entirely.
I spent the best part of a decade running Solaris and Linux machines from 1998-2008. The Solaris kit was easy to keep running once you'd got over the initial configuration hell and was very stable. The Linux stuff however was nasty at best. From CIFS/SMB crashes taking out the VFS layer to drivers packing in to incorrect documentation to random hangups. That is across CentOS and Debian. They are not even remotely stable IMHO. Debian is far better than CentOS was but that still pales in comparison to even, dare I say it, Windows Server 2008.
As a sideline, I'd been using OpenBSD on a couple of test machines because it was interesting and I encountered entirely the opposite of the above. I threw it into production instead of a CentOS 5 box that we were retiring as a postfix/dovecot SMTP/IMAP box. The throughput is about 10-15%[1] less but my word the thing is a million times easier to administer and is absolutely bomb proof. Every configuration option, tool etc is entirely and perfectly documented. It is nothing but bliss. It just keeps ticking. We now have 3 hosts on it. The only missing bit is a decent OpenJDK port but the software guys are starting to use Python for a lot of stuff so that may be moot shortly anyway.
My metric for an operating system's reliability is if it goes wrong, how much crap do I have to deal with? Well I'm confident that if an OpenBSD host went down that I could have it back up, even if the internet connection was out and all I had was an OpenBSD CD. I can't say the same about anything else these days. Last time I lose an md raid on Linux, it took me a day to get it back due to nothing but crappy documentation and bugs even those it was a tested recovery strategy.
[1] The thing is a hefty HP Xeon box so this is background noise compared to the actual load.
Thank you for the detailed response. I've always discounted the BSDs because of the popularity of Linux, but perhaps now I'll give them a second look.
Sure.
Everything is more reliable. Not one crash yet. When I use Linux, I would have expected several by now.
Everything works perfectly out of the box and has sane and safe defaults.
Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
The code is substantially better. Less macrotanium, better naming, more understandable.
There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
Everything is more reliable. Not one crash yet. When I use Linux, I would have expected several by now.
Everything works perfectly out of the box and has sane and safe defaults.
Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
The code is substantially better. Less macrotanium, better naming, more understandable.
There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
> Everything is more reliable. Not one crash yet.
Also true with Linux, of course.
> Everything works perfectly out of the box and has sane and safe defaults.
Same with Linux, at least in the distros I use.
> Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
"My way or the highway", in other words. Use the Only OpenBSD Toolkit or get out?
> The code is substantially better. Less macrotanium, better naming, more understandable.
Readability is subjective. Macros aren't inherently bad.
> There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
At the expense of everything else, it seems, including hardware support.
Also true with Linux, of course.
> Everything works perfectly out of the box and has sane and safe defaults.
Same with Linux, at least in the distros I use.
> Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
"My way or the highway", in other words. Use the Only OpenBSD Toolkit or get out?
> The code is substantially better. Less macrotanium, better naming, more understandable.
Readability is subjective. Macros aren't inherently bad.
> There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
At the expense of everything else, it seems, including hardware support.
I would expect to run Linux for many, many months doing pretty hard work before expecting a crash. I genuinely can't recall the last crash I had that wasn't hardware-related - probably an early ext3 issue?
Does OpenBSD have an analog of Docker?
Docker originated from BSD Jails which basically give you Chroot on steroids.
The synchronization likely won't 100% work, with cron script you maybe able to just do that with git.
The synchronization likely won't 100% work, with cron script you maybe able to just do that with git.
Jails are a FreeBSD thing. OpenBSD doesn't have them so far as I know.
sysjail is available for OpenBSD.
>It provides a similar function as FreeBSD's jail(8) utility while being significantly more flexible. The package provides jail(1), a drop-in replacement of FreeBSD's jail(8)
http://sysjail.bsd.lv/
>It provides a similar function as FreeBSD's jail(8) utility while being significantly more flexible. The package provides jail(1), a drop-in replacement of FreeBSD's jail(8)
http://sysjail.bsd.lv/
sysjail is not safe for jail-like use. Sysjail'ed processes can do Bad Things by exploiting concurrency races in the syscall interception layer.
Relevant paper: http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi...
Relevant paper: http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi...
This paper is from 2007, is it still not fixed?
It's my understanding that it's not fixable without some help from the kernel. The fundamental problem is that a program can race ahead of a userspace syscall policy enforcement framework (i.e. sysjail) by trapping to the kernel directly. The authors identify several ways this can be exploited to gain privileged information or invoke syscalls the OS allows but the framework tries to prevent.
Did some quick googling. Yes apperently as of 2009 it was unfixed. Seems the problem is with systrace over arching architecure OR how the kernel works with systrace.
Learned something new today thanks :)
Learned something new today thanks :)
It's amusing that commit 300,000 fixes a buffer overflow. It's a demonstration that large C programs do not converge to the state of having no buffer overflows.
You may be right or you may be wrong, but that's not how you demonstrate convergence :)
If anything, this should demonstrate the exact opposite. The code that just got fixed predates OpenBSD. If you could measure the amount of buffer overflows in the tree on the day OpenBSD was forked from NetBSD, and year after year up to now, you'd see a very clear trend. The situation is only getting better, and the fact that the OpenBSD team tries to clean up and polish old code instead of just rewriting and churning out "cool new" replacements for everything really helps. Year after year, the same old code is subjected to mass audits (such as the recent reallocarray() job, wight might've very well triggered the discovery of some bugs in col, including the one referred to in this commit). Other bugs are found in actual use. And, of course, new tools find new problems. New "hostile" changes in the system reveal new bugs. The mature code in the system really does get better.
OpenBSD is not one program though. It's a collection of many programs, large and small, some independent, mostly not.
Might be slightly off-topic, but how would you compare it to DragonflyBSD? I've been thinking on trying out the main BSD.
Their focus is different from what I can see. OpenBSD is about rock solid security. DFBSD original aim was to implement single system image (maybe it still is). In past few years, I see most visible work on HAMMER filesystem which you shThey released some benchmarks outperforms FreeBSD and NetBSD considerably on multi-core systems.[1]
If you write kernel code, you may like, vkernel, which is full blown kernel that runs on userspace. Speeds up kernel development process.
[1] http://www.dragonflybsd.org/performance/
If you write kernel code, you may like, vkernel, which is full blown kernel that runs on userspace. Speeds up kernel development process.
[1] http://www.dragonflybsd.org/performance/
Thank you for your answer. Yes, OpenBSD is definitely about security. I'm also aware of the performance benchmarks. Pretty interesting. The thing is I'm still not completely sure which niche it fills (and I'm pretty sure it fills one). I guess I will have to give them a long try myself and see if I can come with a conclusion.
Am I the only one who suspects a high number of commits is a sign of good programming, and by induction good programmers?
I would tend to think a high number of commits is a sign of activity and judging by the small number of developers, it shows they are dedicated to OpenBSD.
high number of commits can be one indicator of "goodness"
but consider an unsolvable problem that tempts developers, yet stumps them at the same time. they could all commit a solution thinking it's the right one, yet nobody actually solves a problem.
not saying this about BSD ... obviously, but: high number of commits is not a very good metric besides indicating that people are committing.
but consider an unsolvable problem that tempts developers, yet stumps them at the same time. they could all commit a solution thinking it's the right one, yet nobody actually solves a problem.
not saying this about BSD ... obviously, but: high number of commits is not a very good metric besides indicating that people are committing.
That, or a sign of bloat.
But, to be fair, everything is a sign of bloat.
But, to be fair, everything is a sign of bloat.