Hi everyone,

I have some servers with RHEL4 installed on them, and I’ve noticed a problem every time I start processes that saturate the I/O channels, such as VMware’s vmware-vdiskmanager. This tool performs various operations on VMware virtual disk files, and when creating a new one, the load average on the server tends to spike into the double digits. As you can imagine, this negatively affects virtual machines running at the same time!

After some searching, I found the ionice tool that looked like a perfect solution to the problem. Unfortunately, it doesn’t run on the 2.6.9 vintage kernel supplied with RHEL4. Back to the drawing board!

After more searching, I came across a forum thread and a link to an ionice replacement for RHEL4, written in Perl. I downloaded it and tried it out, and it appears to work as advertised. My heavy I/O operations take longer now (fine), and the load average stays within acceptable limits (great!).

The script has some hard-coded values, and it can be easily tweaked as needed. Thanks to Greg Bell at ServEdge for writing it!

Hi everyone,

As I’ve been writing over the past couple of weeks, there are a large number of FreeBSD ports that are unmaintained and would benefit greatly from a new maintainer. Today, we’ll visit with a particularly tragic strain of port:

Unmaintained and BROKEN!

Bill Fenner sends out a periodic automated email to the freebsd-ports mailing list with links to ports that do not build: http://people.freebsd.org/~fenner/errorlogs/.

This is a useful page for any port maintainer to visit periodically to make sure all of his/her ports are humming along. If a port remainis unbuildable for too long, portmgr will likely mark it BROKEN after a while, and if it stays BROKEN too long, it will be removed from the tree.

The problem is that when a port is unmaintained, it’s likely that no one will notice that it doesn’t build, and it won’t be fixed in time to save it from removal. One place to start if you’re interested in adopting a port is the page detailing unmaintained ports that are broken on one or more platforms:

http://people.freebsd.org/~fenner/errorlogs/ports@freebsd.org-date.html

There are many different reasons that ports refuse to build, including (sample log follows each):

• Unfetchable upstream distribution files (log)
• GNU configure errors (log)
• Compiler/linker errors (log)
• Package building problems (log)

Fixing a broken port may be as easy as correcting a download URL or as complex as patching source code so it builds correctly on the AMD64 platform. There are many different ways to get your feet wet, so I encourage you to check some of the broken build log files and see if you can fix, and possibly adopt, one of these ports!

Greetings all,

I’m here with some more statistics about the FreeBSD ports tree and the unmaintained ports in it. Today, I calculated the top five categories with the largest number of unmaintained ports in each:

Category	Unmaintained Ports	Sample Ports
devel	461	ace allegro-devel p5-Yada-Yada-Yada
games	381	gnomesudoku gnuchess xasteroids
textproc	352	diffutils flex xerces-c
graphics	298	Coin bmeps xfpovray
audio	245	icecast rioutil zinf

There is a huge variety of software to explore in the ports tree, and if you’re interested in maintaining one or more ports, I suggest looking for something you’ve already used in the past or a piece of software in your area of interest.  For instance, there are a number of astronomy and biology-related ports that could use some help!

Another great place to find ports that need some help, be it maintainership or submitting PRs to fix them, is the pointyhat build cluster status page: http://pointyhat.freebsd.org/errorlogs/.

If you’re just getting your feet wet and don’t know where to start, subscribe to the freebsd-ports mailing list or browse its archives. You’ll find a lot of questions and solutions to common problems as you learn more about the ports infrastructure.

Hi everyone,

To prepare for the upcoming inaugural International FreeBSD Adopt-A-Port Day on June 15th, 2009, I am publishing some interesting (???) statistics about the FreeBSD ports tree.

First up (cue the violins): The most unloved FreeBSD port!

This port has been a workhorse since the year 1996, back in the days before the Internet you now know, when a fast connection was 56k and we often disabled image loading in our browsers to speed up the browser! Those days, there were fewer than 500 ports in the tree, a far cry from the 20,000+ we now enjoy.

And now, I give you (drumroll, please)….

print/ghostview

The CVS log shows that this port has been unmaintained since 17-Nov-96, so it’s been nearly 13 years that ghostview has been wandering aimlessly through the tree, waiting for someone to adopt her/him/it. The ghostview port won’t require a lot of care and feeding, but if a new upstream version is released, the port would like a FreeBSD maintainer that will submit a PR to keep it in sync.

So, wouldn’t you like to help a port regain its standing in the tree and become all that it can be and more? Contact me at glarkin@FreeBSD.org to get involved and help out!

Hi everyone,

Just for fun, let’s designate June 15th as the inaugural International FreeBSD Adopt-A-Port Day for 2009!

My colleague and co-mentor to Alexander Logvinov, Thomas Abthorpe, posted to the freebsd-ports mailing list in March looking for folks to adopt unmaintained FreeBSD ports and keep them up to date.

I’d like to continue Thomas’ effort and find out who in the FreeBSD community is interested in taking on one or more unmaintained ports. Some current stats:

FreeBSD ports info page (20325 total ports as of June 4th, 2009)

FreeBSD unmaintained port list (4719 as of June 4th, 2009, 77 with build errors)

FreeBSD unmaintained ports that need upgrading (253 as of June 4th, 2009)

If you are interested in maintaining a port, contributing PRs for port upgrades, and perhaps eventually becoming a ports committer, read the following documents to get a good overview of the process:

• http://www.freebsd.org/doc/en/articles/contributing-ports/index.html
• http://wiki.freebsd.org/PortsTasks
• http://www.onlamp.com/pub/a/bsd/2002/01/31/Big_Scary_Daemons.html

I started my own path to becoming a FreeBSD ports tree committer by discovering that a web application (WebCalendar) that we use at SourceHosting.net was not part of the tree.  I read up on how to create a new port, submitted a PR for it, and after review by an existing FreeBSD committer, it was added to the tree.  Now other WebCalendar users can install it on FreeBSD as easily as typing:

cd /usr/ports/www/webcalendar && make install clean

After a port is added to the tree, a maintainer keeps track of upstream package releases, updates the port to track the new version, adds any needed configuration options and makes sure that it builds and installs on the FreeBSD supported platforms. As payback, you’ll often hear from folks using your port, whether sending thanks, enhancement requests or the occasional bug report!

Since submitting that first PR, I have created a number of new ports for tools used at SourceHosting.net or just in my areas of interest.  I have adopted many as well. Most unmaintained ports are very undemanding and just need some minor TLC! It’s a great way to support a project that has contributed directly to the success of my Real Job.

Have any questions or guidance? Email me at glarkin@FreeBSD.org, follow me on Twitter or comment here. We’d love to work with you!

Hi everyone,

To go along with the FreeBSD 8.0-CURRENT amd64 virtual appliance I released a few days ago, I’ve also prepared one for the i386 architecture.

Get the virtual appliance here: FreeBSD 8.0-CURRENT i386 virtual appliance

As always, comments and feedback to virtualization@sourcehosting.net is welcome. Enjoy!

Hi everyone,

Do you want to experience FreeBSD on the cutting edge without devoting a brand-new piece of hardware to it? You can test out the latest and greatest FreeBSD bits by downloading the FreeBSD 8.0 amd64 virtual appliance.

You’ll need a BitTorrent client, and once the download has completed, you’ll have a .ova file. This is a self-contained virtual appliance running FreeBSD 8.0-CURRENT amd64, and you can either import it directly into certain VMware products (e.g. VMware Workstation, VMware Player 2.x) or use VMware Converter to convert it into virtual machine format for use within VMware Server 1.x and other products that don’t read .ova files directly.

FreeBSD amd64 doesn’t actually require an AMD CPU to run as long as the specific Intel CPU is the correct architecture. Check for supported CPUs on the FreeBSD amd64 project page.

The virtual appliance’s root password is “password” and a minimal number of services and packages are installed. The virtual appliance is perfect for experimentation and testing, and please send any feedback or questions about it to virtualization@sourcehosting.net.

Enjoy!

Hi everyone,

I caught a posting on Colin Percival’s (FreeBSD Security Officer) blog the other day:

http://www.daemonology.net/blog/2008-10-26-freebsd-EC2.html 

Like me, he wants to get FreeBSD running on Amazon EC2 and needs your help with funding and to register support for the project with Amazon.  Who knows, if enough people want to use FreeBSD on EC2, Amazon may decide it’s worth funding the development themselves!

If you want to help out with the project, contact Colin directly.

Hi everyone,

I was excited to see VMware release the free ESX 3i software over the summer and had grand plans to install it on a spare SFF PC with a mini-ITX motherboard that I have laying around. I downloaded the installation bits and burned an ISO, salivating over the thought of a free ESX development box about the size of a large dictionary.

Whoa, nelly – not so fast! The ESX installer started up, chugged for a bit, and then told me that my CPU is not compatible. I guess I shouldn’t have been surprised, since it’s an EPIA Nehemiah M10000. I had to find another solution that didn’t include plunking down $$$ for a dedicated ESX host.

VMware Workstation to the rescue! If your PC has enough horsepower, you can install Workstation on it, create a VM for ESX3i inside of it, and then create your target VMs inside of ESX3i. It sounds crazy, but it works.

I started with Workstation 6.0.5 at the end of the summer and got everything working. After the evaluation ran out on the software, I decided to purchase it and eventually installed Workstation 6.5. As soon as I tried to start up my previously-working ESX3i VM, it kept hanging during boot-up, as seen here:

Originally, the following directives had to be added to the ESX3i .vmx file to get it to boot inside of Workstation 6.0.5:

monitor_control.restrict_backdoor = "true"
monitor_control.vt32 = "TRUE"

After some sleuthing around on the Internets, one more directive added to the .vmx file gets ESX3i booting under Workstation 6.5:

monitor.virtual_exec = "hardware"

Now you can even provision some interesting configurations using FreeNAS or OpenFiler to manage the disk space available to the VMs inside ESX3i. This makes it so much easier to develop a whole architecture on your desktop and deploy it right to a production ESX host.

Hi everyone,

Every now and again, a strange problem crops up with VMware Server. In this case, the VMs on one host began running with a very fast clock, even though the .vmx files contained the following line:

tools.syncTime = "TRUE"

Apparently, this setting helps keep the VM clock from slowing down too much, but it doesn’t do much when it’s going 1.5x faster than it should – whoa, Nelly! Running ntpdate every few seconds showed the clock resetting backwards 5-10 seconds each time. That’s going to play havoc with everything – log file messages, email timestamps, Makefiles and many other things.

I searched around Google for solutions, and 99% of the posts say “set kern.hz=100 in your /boot/loader.conf for a FreeBSD guest OS“. That’s great if your clock is slow, but it doesn’t fix this problem. A quick check showed that I had already added that setting a long time ago.

After more and more in-depth searching, a solution emerged. The host OS is RHEL4, and it enables CPU frequency scaling by default with the cpuspeed service. The idea behind this service is great, as it saves power, but it just wrecks the VMware timekeeping accuracy. Disabling the service fixes the problem for good:

# /etc/rc.d/init.d/cpuspeed stop
# cd /etc/rc.d/init.d/
# /sbin/chkconfig --del cpuspeed

Easy!

One final problem – the VM clock still runs fast until you reboot the host and the VMs on it. To get around the problem temporarily if you are running a high-availability service, add the following lines to your VM /etc/crontab file:

*/5 * * * * root /usr/sbin/ntpdate -s us.pool.ntp.org

I hope this posting makes the solution easier for someone else to find in the future!