aporem.net

There is an excellent article by Dru Lavigne on ONLamp.com about the more sublte parts of X11 configuration.

Starting with a short sketch on how to choose the right accelerated drivers for the video card, including the installation of the kernel modules, the author proceedes to explain the more advanced features of X11: nested X servers and distributed multihead configurations.
While nesting (as the name implies) allows you to run several X servers on one screen, distributed multihead goes the other way by sharing one desktop across multiple machines on the network.

Although I won’t use any of the features presented in the article, I nevertheless enjoyed reading and was really surprised how much potential there is in my X11.

A little while back, I’ve discovered the usefullness of cheat-sheets. The idea to summarize some commands or keyboard shortcuts is not new to me, though. I just missed the fact that I’m not alone with this habit and that usually someone already has put together a nice quick reference.

Therefore, here some starting points:

• Cheat Sheets from Smashingmagazine
• Cheat Sheets from Contentschmiede.de

Until now, I didn’t find a really big/exhaustive compilation of cheat sheets, but this is what search engines are for. (Although a website dedicated to cheat-sheets with a coherent layout/design would please the nerd in me.)

Are you searching for an alternative way to get your files from a remote server without the hassle of rsync’ing or copying? Do you have problems with UID mapping between your hosts?
Then take a look at fuse-sshfs (available for Linux and FreeBSD 6.x but not for MacOS X).

The syntax is comparably easy to grasp:
sudo sshfs {{user id}}@{{server hostname}}:{{desired remote share}} {{desired local mount point}} -o idmap=user -o allow_other -o uid={{local user id}} -o gid={{local group id}}

Although there is a (heavy) performance penalty, the enhanced security compared to a NFS mount and the lighter configuration footprint (there isn’t any on the server side) compared to AFS make it an ideal choice for any quick file operation you want to make remotely.
For example, think of sharing code trees between your build box and several production systems. With sshfs you can add without hassle remote sites connected without any VPN (although, I wouldn’t recommend this as a permanent solution).

“SSH is the HTTP of system administrators!”

Today’s blog is going to state something obvious, but I would like to emphasize the fascination the power a simple command can give you. I’m talking about ls, the most widely used command on any CLI.

Of course, every senior Unix user should be aware of the huge amount of command line options ls sports, but integrating this power into your day to day usage is somewhat harder.
Here, from the man page, the complete list of possible options:
ls [-ABCFGHLPRTWZabcdefghiklmnopqrstuwx1] [file ...]

The key to mastering all the possible and practical combinations is to arrange them into something easy to memorize. For example, you want to have a detailed listing of all files sorted by time-stamp. The following two lines achieve the same thing, one being somehow easy to memorize (spoken, it sounds like “later”):
ls -latr
ls -trla
And this is already the whole secret: the easier to speak/spell the options, the easier you remember them! Additionally, if it sounds like a word which gives you a hint of the function, you will learn it in no time.

Ken Smith, the release engineer in charge, has today announced the availability of the first release candidate (RC) for FreeBSD 6.2. I’ve already posted about the delays and problems this release faces, but now the worst issues has been fixed and the normal process can go on.

Since this is RC1, there are open issues, though:

• sysinstall doesn’t get the Linux package right
• gnome2 fails to package if installed off the distribution media
• no documentation is included in the distribution media

But this does not affect people upgrading (test)-systems with cvsup.

The announcement can be found on the mailing list archives.

Robert Watson, founder of the TrustedBDS project was interviewed by Federico Biancuzzi on SecurityFocus about FreeBSD Security Event Auditing.

The auditing mechanism will be part of the upcoming release 6.2 of FreeBSD, although being marked as experimental and hence not included into the GENERIC kernel.
It uses SUN’s BSM API and log file format (the industry standard) and is based on Apple’s BSD licensed implementation. Since significant improvements were made during porting, the OpenBSM project was created to host the code. The project builds on Mac OS X, FreeBSD and Linux.

The key advantage the new auditing has above syslog is the finer granularity, configurability and reliability. This is achieved by putting auditing functionality into the kernel and hence being at the level where system calls are transformed into direct instructions.
And the team made a good decision in keeping the configuration syntax as close to SUN’s as possible, giving the new project direct access to an already mature basis of examples and best practices.

Finally, I want to emphasize the impact this has for the FreeBSD project, since having a full blown auditing system is the requirement for any operating system to be used in security aware environments such as defense departments or financial institutions.

In my post official start of the FreeBSD 6.2 release cycle, I’ve reproduced a timetable alongside with the promise to post more informations on the availability of Beta1.

Both failed. Today, Ken Smith announced FreeBSD 6.2-Beta3, whereas RC2 should have been on October 29. And I never posted the changelog.

So here a short summary:

• Beta1 was announced on September 20, the main feature being the last minute include of FreeBSD update, the binary update mechanism.
• Beta2 was announced on October 5. Since not all problems could be solved, a Beta3 was planned.
• Beta3 was necessary because a break in the em(4) driver. Ken Smith looks forward for a RC.

The announcement can be found in the mailing list archive.

From the status report June-October 2006:

• XEN
  Through a Summer of Code project (f(o)unded by Google) Xen has been ported to FreeBSD. This means that the domU support is finished.

  Unfortunately, there was not enough time for a dom0 support which is much more anticipated by myself.

  By the way, Xen announced its update to 3.0.3.

• ZFS
  Outside of Solaris, I dare to say that FreeBSD has the most mature support for ZFS, the zeta file system from SUN.

  Nevertheless there is very much left to do. ZVOL is done (sort of) and ZPL is being worked on. For those like me, who don’t know the innards, there is a source tour available on the Solaris homepage.

• Linux compatibility
  As every FreeBSD fan knows, there is a syscall compatibility to the Linux kernel. Default compatibility is with version 2.4.2.
  In another Summer of Code project, compatibility with version 2.6.16 has been achieved.

The full report can be found here.

California based iXsystems has announced on October 10 that it has aquired PC-BSD, the producer of the FreeBSD based OS with the same name.

The main selling points of PC-BSD are the graphical installer and a point-and-click packet manager (called PBI), apart of the rock-solid FreeBSD foundations. And all this comes for free!

So why did an enterprise-class hardware provider buy a graphically inclined BSD?
For one, iXsystems also has high-end workstations in its portfolio and probably want to run a (ABI-)stable but up to date OS on them.
On the other hand, there is a will to push the development of PC-BSD towards a more sophisticated Server and Laptop support in the announcement. Although I wonder how Servers and Laptops fall into the same category for hardware support.

I’m very curious to see how the journey for PC-BSD continues. Hopefully, the focus on not BSD-savvy users (administrators?) doesn’t get lost.

The original announcement from iXsystems.

Yesterday the security officer of FreeBSD reminded of the impeding end of lifecycle of several FreeBSD releases. You can read the full text here.

In the next few months, first the 5.4 and 5.5 branches go out of support then 6.0 (depending on the release of 6.2) and in january next year the whole 4 branch reaches it’s end of life.

So, why is this so important? The reminder goes out to all administrators that have production boxes and hence require planning for any downtime. Additionally, the test teams (usually the same administrators) have to work out upgrading plans and test for all eventualities.
And developers supporting applications that require specific versions of the operating system have to adapt their support lists too. For example if a company decides to support their application on every FreeBSD branch with extended lifecycle support can stop supporting the 5.3 branch and eventually inform their customers about available upgrade procedures.

And why do I mention this? Because features like this make the difference between a geek OS and a enterprise grade OS. Usually one has to pay to get this kind of support from a Linux distributor or the Redmond based software company.