[Shield] Free Daemon Consulting, LLC [Todd]
/home     /rates     /goals     /tech     /news     /contact     /hosting     /links     
/de
/el
/en
/es
/fr
/it
/ja
/ko
/nl
/pl
/pt
/ru
/zh

Free Daemon Consulting Newsletter Page


2005: /09 /10

9/14/2005 - September Newsletter

In this edition...


Welcome to the first edition!

Welcome. The goal of this and future newsletters is to get the word out to anyone about, well, news and events happening in the particular corner of the computing world Free Daemon Consulting stays abreast of. Some of you may not otherwise get exposed to what is contained here. It is my hope that these newsletters will, through time, provide useful memos, notes, and tips that will be both useful and timely.

To that end, the first article is about the upcoming release of OpenBSD 3.8. Several of my clients have asked me to inform them of future releases. Having install media when your Internet connection is down is a good business decision, right??? ;-)

If you have any topics you feel appropriate for future newsletters, please feel free to mention them. You never know, others might be wanting to know the same thing!

Back to the top.

OpenBSD 3.8 Pre-Orders now available!

Today, September 14th, 2005, pre orders are available for OpenBSD 3.8, which is due to be released on November 1st, 2005. As is typical for releases, which occur once every 6 months, if you pre-order your CD's you should receive them very close to the official release date.

For those interested in more details, there is a What's New list of new features and systems.

One major effort that is reflected in the poster and cd artwork, as explained by Theo de Raadt, project leader, in his pre-order announcement, was the addition of bioctl(8), a RAID management interface. Theo gives a brief demo/tutorial on how this new interface works in his mail to the misc@openbsd.org mailing list. A full rundown is described here by Jolan Huff. Suffice it to say, RAID management has taken a very important step forward this release for ami(4) SCSI raid controllers, with the framework for other controllers in place, some pending time from developers, most waiting on documentation from vendors. It is particularly sad for me to see Linux, FreeBSD, and NetBSD accepting binary only drivers instead of demanding documentation for hardware which permits things like this to happen. The alternative is to rely on vendors to release binary only software for each release of otherwise free operating systems which are specific to each vendor, no commonality in sight. This also limits what platforms can utilize specific functionality. This would be the equivalent of supporting one out of the 17 platforms OpenBSD supports today which seems .. rather limiting.

For the redundancy advocates out there, note the addition of trunk(4). With a `super redundant setup' of failover trunking, one can setup a system with 6 nics in each of two machines and several switches that result in a super resilient setup in which no one piece of equipment (including a switch) failing will permit loss of traffic.

The fact that malloc(3), the userland's method for allocating memory, has been rewritten to use the mmap(2) system call is more than a small step. Traditionally, memory allocated to a system would be all together in one contiguous region. If an algorithm in a program behaved reliably but stepping slightly outside the area of memory it allocated, this was a bug gone undetected. With the release of 3.8, because of the way mmap randomizes the location in memory, this is no longer true. Since the location is random, `empty space' is between almost every allocation and the next. Stepping in this `empty space' causes a program to segfault, thus making bugs more easy to find. Some people are not happy to find that previously reliable programs suddenly start crashing. However, as one person put it, they would rather have an application crash than introduce a subtle but undetected corruption in some mission critical database that does not get detected until three months down the road. One such application is X(7), the graphics interface for nearly any UNIX based platforms, including Linux, Solaris, and the other BSD distributions. It was discovered that the X server would crash in several different ways. Ultimately, there have been more patches applied for several uniquely different problems than I can count on one hand. This is but one application, and many undetected bugs were fixed because of this one ``not so small change'' to memory allocation in OpenBSD. Fixing bugs is a very good thing, at the heart of OpenBSD's security track record, because all security issues are bugs, or poorly written code. Once again, another tool in the chest of bug hunting for OpenBSD!

The perl package tools, written from scratch by Mark Espie, as a replacement from the rotting c package tools, are steadily making improvements. With OpenBSD 3.7, we gained the functionality to update packages via 'pkg_add -r'. Previously, a painful process of 'pkg_delete /var/db/pkg/*' followed by a 'pkg_add ' of each package on the system was required. With OpenBSD 3.8, many tweaks and improvements have gone into the package tools, including fat binary support (multiple binaries inside of one package to save space where packages otherwise contain many non binary files in common). To me, though, the most exciting change is the addition of the '-u' flag. For reliability reasons, for 3.8, a small step was taken. The '-u' flag at this point only suggests the cmdline argument to 'pkg_add -r' to update all packages, given PKG_PATH is set in the environment to one or more locations that contains packages. However, being able to say:

     export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/i386/
     pkg_add -u

.. and then cut-and-paste the 'pkg_add -r' command line is trivial when compared to manually selecting which packages to update in 3.7. No promises on when, hopefully for 3.9, but it will be a real treat when Marc Espie finds the time to complete this transition to a full 'update everything with a single command'...

Back to the top.

OpenSSH 4.2 released

A sub-project of OpenBSD, OpenSSH has released a new version recently. Hardly anyone using UNIX these days does not use OpenSSH. As with past releases, this one includes several bugfixes, proactive security fixes, and improved features.

One of the new features I would like to highlight here is the 'ControlMaster=auto/autoask' options to support opportunistic multiplexing. Aside from being a mouthful, you might wonder what this means. By adding this to my $HOME/.ssh/config file:

     Host *
             ControlPath ~/.ssh/ctl-%r-%h-%p
             ControlMaster auto

.. I ssh to a machine named 'eclipse' in one xterm on my laptop:

     todd@blue/p7 4126$ ssh eclipse
     todd@eclipse's password: 
     Last login: Wed Sep 14 11:46:00 2005 from blue.isp.fries.net
     OpenBSD 3.8 (GENERIC) #130: Mon Aug 29 11:40:56 MDT 2005

     todd@eclipse/p0 1$

So far, nothing is different. Or is it? Back on my laptop, I see this new file created:

     todd@blue/p8 3966$ ls -l $HOME/.ssh/ctl-todd-eclipse-22 
     srw-------  1 todd  todd  0 Sep 14 23:18 /u/todd/.ssh/ctl-todd-eclipse-22=
     todd@blue/p8 3967$ 

This is a 'socket' denoted by the 's' on the far left of the filename. With this, subsequent ssh connections to eclipse from my laptop will use the socket and utilize the existing connection instead of establishing a new one:

     todd@blue/p8 3967$ ssh -v eclipse
     OpenSSH_4.1, OpenSSL 0.9.7g 11 Apr 2005
     debug1: Reading configuration data /u/todd/.ssh/config
     debug1: Applying options for *
     debug1: Reading configuration data /etc/ssh/ssh_config
     debug1: auto-mux: Trying existing master
     Last login: Wed Sep 14 23:17:03 2005 from blue.wfi.fries.net
     OpenBSD 3.8 (GENERIC) #130: Mon Aug 29 11:40:56 MDT 2005

     todd@eclipse/p1 1$ 

This has really saved me a lot of time since I started using this new functionality. If you are a regular user of ssh on a unix system, I suspect it will save you time as well!

Back to the top.

ICMP Vulnerability .. Why wait to fix?

One of the fun things I find being associated with the OpenBSD project as a developer is that there are so many people out there who just don't get it in so many ways. Many people wait for bugs to hit them on the head before fixing a program, and even then, only if the buggy behavior bothers them enough to do something about it. This may seem counter-intuitive, but there really are many well meaning people out there that know about issues, know they should do something about it, but do not, for many reasons, dedicate the time and energy it would take to actually fix the source of the problem.

I would like to introduce you to the name of Mr. Fernando Gont. Throughout the last year he has been lobbying the IETF to accept his draft specification to fix ICMP vulnerabilities in every RFC compliant TCP/IP implementation out there. Surely I jest, you say. There cannot be a common bug in every TCP/IP implementation, can there? Don't just take my word for it. Please visit this translated website. You can see for yourself that both CISCO and Microsoft are singled out for having issues. Also, in this article, it is clear in the final paragraphs that this is an accident waiting to happen:

Unless a major event shakes up the security community, most researchers continue to believe that the threat is not a critical one.

That's a serious mistake, said Gont.

"For some reason, it seems the security community does not understand what matters is which threats are current, rather than which threats are new," he said. "If someone can take your entire network off the Internet, does it make a difference whether he did it with a zero-day exploit or with a 20-year-old bug?"

While it can be noted that the CERT bulletin here lists OpenBSD as 'Vulnerable' as of April of 2005, rest assured that the 3.8 release has this issue fixed, as can be seen by this commit nearly three months ago.

Back to the top.

Friendly Bandwidth Tips

Every once in a while on the net, something amazing happens. Sponsors line up to back a service that benefits everyone, for free. In the two examples below, individuals and companies hosting large data files can shave many bytes off their servers by employing either or both of these organization's freely available services.

The first organization I would like to introduce you to is called ``Our Media''. Borrowing from the storage space and bandwidth available to the Internet Archive, and sponsored by a number of other online companies, this free service promises to host your content (video, photos, audio, text, software, etc) forever for free. The only catch? You must accept that anyone is permitted to view your content. For home videos, or sharing pictures online, this site promises to be very popular in years to come. You no longer have to have a huge bill per month to host large multimedia files, throw it onto the http://ourmedia.org site and link to it!

The second organization I would like to introduce you to is called The Coral Content Distribution Network. In short, it is a global cache that permits appending '.nyud.net:8090' to any URL. Once its cache network has retrieved the content once from a given URL, it will not do so again. It is cached! For those large files you truly wish to host yourself or on your own web site, but would like to reduce the overhead of bandwidth, Coral is the ticket for you. The upper limits for this system include that currently no file greater than 50mb are cached, but rather transparently redirected to the original webserver, and that approximately 250GB per day per site may be cached and redistributed via coral. An example usage would be to view this web page via coral by clicking here. Their FAQ contains many more interesting facts about Coral.

The above two pioneers are freely donating their bandwidth and resources to benefit the Internet. Now that you know about them, it is up to you to take advantage of them!

Back to the top.

Philosophy: Mistakes vs Learning Experiences

Over and over I have the same conversation with many different people. It goes something like this:

"Oh no! I have made an awful mistake. This is terrible! This is a disaster!" says the person.
"Did you try doing x, y, or z .. realize that this knob is tweaked like you might not expect." I say.
"How could I have been so dumb! I am totally embarrassed!" says the person.
"Please," I say with as much comfort as I can generate. "do not be so hard on yourself! Let me introduce you to my philosophy about mistakes. There is no such thing as a mistake, there are only Learning Experiences".

Unfortunately, the above, as logical as it sounds, does not come naturally, in my experience. Mistakes happen, we learn, yes. Have you ever realized that you learn when you make mistakes, and best when you make mistakes? Installing that software, without a problem, was easy. How did you do it? Simple, you say. So, when you go to another computer, and encounter a problem, you suddenly realize you didn't know everything about installing that software. But by the time you have figured out what the problem is, you have learned something. Such is, as I have discovered, most of life.

So, the next time you are worried that you are making a huge mistake, computer related or not, perhaps it will help to know that you are engaged not in a monster mishap but in a learning experience!

Back to the top.

Valid HTML 4.01! vipower Valid CSS!