Slashdot Mirror

Um.. if they weren't overselling, they wouldn't need QoS or 'best effort'..

Ummm, no. QoS has nothing to do with overselling.

I have a 8mbps download/1 mbps upload DSL at home. Assume that there is zero overselling.

Whenever the amount of traffic exceeds the connection limts, QoS is still useful, because some of the traffic is more important to me, and some is more time sensitive.

For example, I might prioritize tcp acks on the upload side - this makes sure that I get my max download speed.

Nice example here:

http://www.openbsd.org/faq/pf/queueing.html#assign

That's true on some projects. There are a few megalomaniac assholes out there. Some are quite successful. Some are not.

Sometimes the users are unreasonable. On smaller projects, you can't expect a two person dev team to drop everything they're working on to add whatever minor feature every user wants. In these cases, it's actually sound advice; if you want it, send us a patch, and we'll give it a try. They're not being assholes in these cases; they just don't have the time. In other cases, you have people who disagree with fundamental parts of a project. They demand sweeping changes that would affect the entire codebase. It's just not possible to make everyone happy.

If you think about it, it's not really that much different than the closed source world; software companies don't bow to the whim of every user that submits an idea. Maybe, if enough people want a feature, they'll add it - but there's no guarantee. With open source, if enough people want a feature, one of those people will probably have the ability and time to code it and submit a patch.

None of those are the reason there are 300+ Linux distros out there. There are a few distros that were forked due to poor management, but most of the time it's down to philosophical differences. Debian exists to fulfill the idea of a completely free platform. Redhat exists to make money. Slackware exists because it's been there since the dawn of time and some people like they way it does things. Ubuntu exists to provide a polished, user-friendly version of Debian. DSL exists for small installs. Many distros exist because some people decided they wanted to try making their own distro. When you get down to it, there's only really a handful of relevant distros out there - the other ones are really only for hobbyists, people with special needs, or people who want to try something different. If one of the small ones comes up with a good idea, it might get adopted by one of the big distros. It's useful, and I don't understand why people think multiple distros is a bad thing.

I Run OpenBSD on a lot of our critical infrastructure systems. I do this for a lot of reasons, but foremost because their uncompromising attitude toward code and documentation. Just one easy attainable proof of the quality of this project is to look at the simplistic beaty of the html from this page: http://www.openbsd.org/faq/faq1.html#WhatIs (CTRL - U).

Considering that the BSD network stack is pretty much THE reference, whatever you code has to stay compatible with it.

"Compatible" at the API level or "compatible" at the network level? ("Compatible" at the API level is irrelevant, as it's not going to happen; PE is not a.out or ELF.)

So you're going to need to copy ALL the BSD constants,

No, you're not. Nobody's going to give a damn about AF_DATAKIT/PF_DATAKIT, for example. You're only going to have to copy the names of the ones that matter, namely AF_INET and AF_INET6.

and ALL the BSD typedefs,

Again, you'll only have to copy the ones used in socket calls.

So, tell us, how are you going to write something that complies with the standard without those constants, typedefs, and api? Magic? Time machine? Million Monkeys?

So, tell us, how are you going to write something that complies with various UN*X standards without using the code of an existing implementation?

As indicated, you don't have to copy the exact definitions of the constants; even the existing *BSDs don't all have the same numerical value for AF_INET6 (28 in FreeBSD and DragonFly BSD and 24 in NetBSD and OpenBSD; it's 30 in Mac OS X and presumably iOS).

In any case, even if they copied and pasted some typedef calls, that, in and of itself, doesn't mean that it's derived from the BSD code in any interesting way.

As for the "api", an API isn't code, it's documentation. There are a number of cases where multiple implementations of an API exist without sharing code. (You may have heard of some software called "the Linux kernel" and "the GNU C library" - and those APIs include more than the socket calls, so arguing that the Linux networking code may have been in part based on the BSD socket code is insufficient to dismiss those examples.)

OpenBSD has had the Epitome deduplication framework for some time. I believe version 2 is considered production-ready.

Two.

Something's wrong or lost in communication here. The entropy pool in a /dev/random implementation is designed so that even if an attacker can add a known source of numbers to it, it still doesn't decrease the real entropy in the pool. As long as my entropy estimates are correct, I could let you pick half the bits (or 99% of the bits) going into /dev/random's entropy pool and that still wouldn't help you guess the output.

Yes, but in a server most often there is no keyboard or mouse involved. So, the machines get the vast majority of their entropy from the network.

And we're talking about Theo de Radt here... it doesn't have to be a RATIONAL threat, it just has to be a theoretical one.

Going to the source:

The OpenBSD kernel uses the mouse interrupt timing, network data interrupt latency, inter-keypress timing and disk IO information to fill an entropy pool.

So, they do use "network data interrupt latency", but not the time between sequential packets, or packet data, or anything that a remote attacker could control.

Did you actually read the superb installation manual? It's all in there, dude.

This is how you install Openbsd. You can download a small iso for your usb/cd, and that will download anything needed thru the net.

Back in the version 3 days, you needed only a floppy or two to start such an install, nowdays is the same, but ppl mostly use usb sticks now (the floppy image still exists).

Going for randomly made iso images on bittorrent was a very stupid idea. The only reason i could see someone needing a whole iso is if they lack connectivity.

You can compare this install method to Debian netinstall, or Ubuntu minimal iso images.

TIP: The installation and configuration guide is called "FAQ" for some reason.

This is how you install Openbsd. You can download a small iso for your usb/cd, and that will download anything needed thru the net.

Back in the version 3 days, you needed only a floppy or two to start such an install, nowdays is the same, but ppl mostly use usb sticks now (the floppy image still exists).

Going for randomly made iso images on bittorrent was a very stupid idea. The only reason i could see someone needing a whole iso is if they lack connectivity.

You can compare this install method to Debian netinstall, or Ubuntu minimal iso images.

TIP: The installation and configuration guide is called "FAQ" for some reason.

Not been the case for years, you can download the "install50.iso" image from the mirrors right now.

http://www.openbsd.org/ftp.html

Example:

http://mirror.bytemark.co.uk/pub/OpenBSD/5.0/i386/install50.iso

link to the 5.0 song, art and lyrics.
http://www.openbsd.org/lyrics.html#50
it is recommended best practice to play the correct release song while upgrading your openbsd.

Of course, just correctly guess sooner, and then you can fix the system beforehand

One method to make such a guess is called a "code audit", and code auditing practices applied since mid-1996 are part of why OpenBSD has had only two remote vulnerabilities for over a decade.

I hope they got rid of Robert Barr, the man from the redundancy detector van.

Could'nt agree more. Take a look at the HTML for http://openbsd.org/ Thats just beautiful! Another reason why i trust their software above anybody elses

VRRP, philosophically,
must ipso facto standard be
But standard it
needs to be free
vis a vis
the IETF
you see?

But can VRRP
be said to be
or not to be
a standard, see,
when VRRP can not be free,
due to some Cisco patentry.. s/VRRP/O

It's even more amazing if you've ever interacted with the OpenBSD community, who are basically dickheads. Admittedly, it's been a while since I gave up on the -misc, but the last time I was there there was some poor guy trying to discuss virtualisation and the lead developers (including Theo) were simply hurling childish abuse at him rather than, say, actually trying to communicate. And of course all their groupies were joining in. It was incredibly unpleasant.

I suppose it's possible that they've grown up since then.

Actually, they have. Drivers for VMware virtual hardware are enabled in the default 4.9 reactiveOpenBSD kernel:

http://www.openbsd.org/49.html#new

I just wish it had apt, that's all.

You can set a shell variable and use the pkg_add command to install packages over the internet.

for the last couple years, http://www.openbsd.org/i386.html#hardware very good, works with all the wireless and USB devices I've plugged into it including cameras, several types of wireless ethernet, usb to serial. Yes, it works on my Toshiba and Thinkpad laptops with all video and sound ok, admittedly as one of two alternate partitions for grand occassions with windows xp, and not my main Linux one.; A lot of the recent device additions of that is due to NetBSD and FreeBSD, the BSD license is great for spreading the device love around.

People who really care about freedom and know what they're doing run real UNIX operating systems and wouldn't touch Linux, Gnome, GTK, Qt, PulseAudio, Avahi, etc with a 10 foot pole. As for everyone else: 99% of them run Windows or Mac.

(Signed: Alex Libman's sockpuppet.)

table <route_cable> persist file "/etc/route_cable"
table <route_dsl> persist file "/etc/route_dsl"

then would force the network ranges/IPs contained through the appropriate interface.

I dumped the DSL about a year ago but this worked very well for me. YMMV. Mail me if you'd like more info/tips.

It's interesting to contrast Ubuntu with OpenBSD. Both have six-month release schedules, but OpenBSD is known for not introducing new bugs -- if something is problematic, they back it out.

Theo gave a talk on it once:
https://www.youtube.com/watch?v=i7pkyDUX5uM
http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/

A more informative link should be included, like:
http://www.openbsd.org/papers/bcrypt-paper.ps
so nerds not in the know can understand how silly the article is. NT hashes are a joke and other than pointing out how bad all the non-bcrypt ones are. It is not all that useful to work on GPU brute forcing for poorly designed systems... (other than to make a point or to aid in exploitation of them.)

You can use shorter passwords if the hash algorithm is sound. dictionary attacks will work regardless but once you are into using brute force your password could be short if it takes a long enough amount of time to cover the domain. bcrypt "scales" to as slow as needed ( I feel odd using "scales" in this way... ) one could make it so expensive that searching the space for short passwords would be too costly.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

In UNIX-land, no it isn't.

Sorry, but shipping code beats standards based theory, and pretty much every *nix vendor ships dc with the OS.

Oracle (nee Sun) Solaris, IBM AIX, HP HP/UX, SGI IRIX, Apple MacOS X, SCO Openserver, SuSE Enterprise Linux (dc listed on bc page), FreeBSD, OpenBSD ...

You also appear to missed a few things about the Open Group Base Specifications Issue 7 / IEEE Std 1003.1-2008 standard - it is in essence a floor, not a ceiling - vendors can ship more tools if they care to. Also, the discussion on bc notes that some implementations of bc are built on top of dc, and that is OK, as long as the behavior of bc is correct.

It is worth noting that dc was one of the earliest programs to run in Unix, making it in while Unix was still written in assembly language. If for some reason it was to be not only omitted, but actually excluded by the standard, it would still be found in the vast majority of shipping systems for years to come until said vendor decided to migrate their Unix system to the current standard, a process that often takes years.

So yes, for the vast majority of people using Unix, an RPN calculator is often only as far away as a shell prompt.

as for #2, you build the patched release files on another server and deploy on production, procedure 5.4 Building a Release is in the (very nicely done) docs http://www.openbsd.org/faq/faq5.html#Release

wake me when they have:

1) start/stop scripts, so I don't have to ps|grep|kill|...crap, what were those flags for the daemon again... to manage running processes or daemons

Well, for this one:

New rc.d(8) for starting, stopping and reconfiguring package daemons:
The rc.subr(8) framework allows for easy creation of rc scripts. This framework is still evolving.
Only a handful of packages have migrated for now.
rc.local can still be used instead of or in addition to rc.d(8).

Check out SSH Agent Forwarding some time.

From the OpenBSD ssh_config(5) man page:

Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. The argument must be ``yes'' or ``no''. The default is ``no''.

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Everyone seems to presume that I don't know how to use SSH, or that I think FTP is spiffy. Both of those are nonsense. I've been using SSH for about 15 years now (I worked for an ISP which was an early adapter), and I described FTP as "sucky" in the very first sentence of my post. My entire point was that FTP has one feature that can be handy in certain specific situations, no more, no less. As my company's network admin, I hate having to run a proxy server on my firewall just to support the one legacy protocol we still have to handle. My boss gave me permission to deprecate it from new customer setups in favor of SFTP and to migrate our old setups as the opportunity arises. But none of that changes the fact that FTP still has a (very) short list of handy features.

Check out SSH Agent Forwarding some time.

From the OpenBSD ssh_config(5) man page:

Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. The argument must be ``yes'' or ``no''. The default is ``no''.

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Everyone seems to presume that I don't know how to use SSH, or that I think FTP is spiffy. Both of those are nonsense. I've been using SSH for about 15 years now (I worked for an ISP which was an early adapter), and I described FTP as "sucky" in the very first sentence of my post. My entire point was that FTP has one feature that can be handy in certain specific situations, no more, no less. As my company's network admin, I hate having to run a proxy server on my firewall just to support the one legacy protocol we still have to handle. My boss gave me permission to deprecate it from new customer setups in favor of SFTP and to migrate our old setups as the opportunity arises. But none of that changes the fact that FTP still has a (very) short list of handy features.

But, according to the summary up there, this one survives password changes. That's really the gotcha. It sounds like they are using something similar to the SSH authentication keys. http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1

But, they really need to implement a way to reset the key files and force you to restart the authentication cycle.

Damn. Beat me to it. OpenVOX.

In this case, it's kind of hard to see Symbian's brief flirtation with openness as a major loss; but it has always interested me that the OpenBSD guys, whose work lacks the legal terms in favor of remaining open that the GPLed Linux team has, are nevertheless some of the most consistent supporters of fully-open systems outside of the core FSF people.

It's Nokia's code, and they can do what they want; but it is rather hard to see this as anything other than the spasmodic flailing of a dying platform, rather reminiscent of the bipolar behavior Sun was exhibiting shortly before their demise(only more serious, since the odds of Symbian related techologies being installed by the end user on a phone sold as non-Symbian are basically zero, while absolute fuckloads of non-Sun servers and desktops end up running JVMs...)

Maybe it is time to cure your Microsoft addiction? Break your Windows!

1) Before doing anything else, back up your data, all of it, off of the computer. Seriously. Do it.

2) Check out:

http://www.ubuntulinux.org/
http://www.debian.org/
http://www.openbsd.org/

(Be sure to completely format the computer's hard drive before or during the installation process).

WARNING: if you do not know what you are doing, ask for help from someone who does.

(P.S. - forget Apple, which is just the new Microsoft.)

Some commentary on the topic from OpenBSD:
OpenBSD 3.5: "CARP License" and "Redundancy must be free"

Where does Linux fail where BSD succeeds?

For some people it's the licensing (BSD vs GPL). For others it is the coherence of the system (how many places hide an IP address in Red Hat?). For others, it is a question of style (BSD vs AT&T type Unix). For some, its functionality (I always liked the way the BSD _______ command worked). From some, it's the simple Joy of BSD, or the McKusick - take your pick. For some, it could be the approach taken to a particular problem taken by one of the BSDs, such as the continuous OpenBSD code audits. For some it might be a particular platform maintained as part of the main distribution. For some, it may be the continuing BSD innovations. For some it might be the counter-culture aspect BSD in the Linux world. Plenty more reasons that people could have, including: Linux - 5 letters, BSD - 3 letters. Do the math.

You could say that the only truly popular Unix desktop is Apple's Macintosh running OS X.
Mac OS X: What is BSD?

What's The Greatest Software Ever Written?

OpenBSD FreeBSD NetBSD PC BSD

FreeBSD Mall BSD Magazine

To each his own.

Where does Linux fail where BSD succeeds?

For some people it's the licensing (BSD vs GPL). For others it is the coherence of the system (how many places hide an IP address in Red Hat?). For others, it is a question of style (BSD vs AT&T type Unix). For some, its functionality (I always liked the way the BSD _______ command worked). From some, it's the simple Joy of BSD, or the McKusick - take your pick. For some, it could be the approach taken to a particular problem taken by one of the BSDs, such as the continuous OpenBSD code audits. For some it might be a particular platform maintained as part of the main distribution. For some, it may be the continuing BSD innovations. For some it might be the counter-culture aspect BSD in the Linux world. Plenty more reasons that people could have, including: Linux - 5 letters, BSD - 3 letters. Do the math.

You could say that the only truly popular Unix desktop is Apple's Macintosh running OS X.
Mac OS X: What is BSD?

What's The Greatest Software Ever Written?

OpenBSD FreeBSD NetBSD PC BSD

FreeBSD Mall BSD Magazine

To each his own.

You might have better success with even a semi-valid HTTP/1.1 request such as

GET / HTTP/1.1
Host: www.google.com

Also, using telnet here is redundant. You should consider using one of the several netcats available. Some even support nice features like SSL encryption, so you can make encrypted requests to to the https port (443).

BSD (it's not dead, after all!)

This shows a huge amount of ignorance. BSD is alive and fine, in several forms:
- FreeBSD
- NetBSD
- OpenBSD
- DragonFly BSD
These are probably the most important. Take a look at Freebsd Derivates. You'll see there are many commercial products derived from Freebsd too.

Also, there are initiatives of porting different Linux distros on top of the BSD kernel:
- Gentoo/*BSD
- Debian GNU/kFreeBSD
- Debian GNU/NetBSD (abandoned in 2002 it seems)

BSD was, is and will be alive for a long time.

Or you fight back with a little more creativity using spamd Nothing stops spam like sending the spam spew to a grinding halt (or even crashing it) by setting your TCP receive window to a value of 1 based on known spammer IP addresses. It is a highly elegant solution. I've deployed it within the family business and we went from thousands of spam messages per day to maybe 2 per week without the headaches of heuristic filtering.

Flamebait indeed. It doesn't take much baiting for OpenBSD fans to fire up the torches.

But here: http://www.openbsd.org/security.html#process

A description of the auditing process. It's not as awesome as your average "they're among the best" proclaimers would think, but it's healthy. This is no way substantiates the claim, though.

You're right to question. And it makes the OpenBSD fans look bad that you got modded flamebait.

Citation needed.

Ok then, the first hit from "openbsd auditing" leads to an OpenBSD Security page which has a section claiming that OpenBSD has a continual audit process and that it is successful..

I'm not necessarily thinking the opposite, but is OpenBSD really that much audited? Are we talking about the kernel? The network stack? Or the encryption protocols?

As I understand it, OpenBSD refers to the whole release, everything they ship.

Now, I'm not sure if claims from the OpenBSD marketing department actually translates to a citation.. I am of the feeling that an "audit" would imply that there were specific procedures followed (searching for particular algorithms known to be problematic for instance) and specific records kept of the results but I have never been able to find public records of those.. Yes, there is the OpenBSD CVS repository but that includes things which are not part of any audit. I found a quote from Theo de Raadt "Most bugs in software are the same ten to fifteen mistakes made over and over" but I don't know what he thinks those mistakes actually might be.

So in conclusion I [as a NetBSD devloper] would be interested to see such records.. I know that many open source projects are subject to Coverity scans which are more public, though it seems that OpenBSD is not listed at this time..

This is why we have theo.c
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/mg/theo.c?rev=1.120;content-type=text%2Fplain

Well, if you have a few minutes I think that Theo deRaadt has a few lines of code that could use your expert review.

According to this, yes.

OpenBSD does have an ongoing code audit

Perhaps not as thorough as you were suggesting. However, I think for others who are not familiar with OpenBSD's ongoing code audit, the above link will be essential for fully understanding these stories.

. And IINM, Linux apps will run under BSD, won't they?

Sort of. For example, the Linux emulation support in OpenBSD is based on Fedora 4, which was originally released June 13, 2005. I've never bothered with it—and wouldn't even if Netflix released a Linux client (that's what I have a Roku box for)—since it really seems like a headache I just don't need.