Zelut’s Blog

I’ve had a 13″ Macbook for about your years now. When I learned about MacPorts I was really happy to know I could run newer software, and compile things to my liking. These days I run a development environment on my Macbook, all built using MacPorts.

This post covers how to leverage ccache in compiling your MacPorts. ccache is a compiler cache utility that increases the efficiency of your compiles by reusing cached build data, often improving build times by 5-10 times!

Step 1: Install ccache

sudo port install ccache

Step2: Edit macports.conf”

Open /opt/local/etc/macports/macports.conf in your favorite editor. Find the line ‘configureccache’ (near line 65)

configureccache no

and change it to

configureccache yes

You’re done! New compiles will now use ccache.

note: ccache stores it’s cached date in your home directory, ie; /Users/$username/.ccache. It defaults to a maximum cache storage size of 1G. You can find out more about the ccache settings via the ‘ccache -s’ command.

Dell Latitude E5500 Wireless – Fedora 14

I recently needed to send my main work machine in for repairs so I temporarily used a Dell Latitude E5500 while my normal D630 was away. Boy did I have trouble with the hardware on this machine! This blog post is a meagre attempt at outlining what was required of me to get some hardware supported. Hopefully this helps some other poor soul along the way.

Wireless Driver

In order to enable Wireless on the Dell Latitude E5500 (bcm4322), you’ll need to follow the steps below. This requires a “nonfree” driver from the rpmfusion repository, as well as an addition to the kernel parameter in GRUB. It’s not so bad once you know the requirements, the trouble is finding the requirements (again, the reason for this post!)

Install the rpmfusion nonfree repository using the command:

rpm -Uvh http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

With this repository now added, you’ll be able to install the broadcom-wl package.

yum install broadcom-wl

Kernel Parameters

The last addition you’ll need to make is to append a parameter to your kernel configuration in GRUB.  Append the following to GRUB on the kernel entries:

intel_iommu=off

Reboot your machine, and when you come back up you should be online!

I hope these little tips help someone else get wireless running in Fedora. Lack of wireless sure can be a deal-breaker. Here’s to winning that battle!

I’ve been reconfiguring my Irssi installation this morning and wanted to document the steps I took. I use irssi on FreeBSD 8.0-RELEASE.

Required Certificates

In order to connect securely over SSL to freenode you need to ensure you have the certificate installed. On FreeBSD, this port is ca_root_nss.

portmaster security/ca_root_nss

Configure the Network and Server

/network add -nick 'nick' -realname 'real name' freenode
/server add -auto -ssl_verify -ssl_cafile /usr/local/share/certs/ca-root-nss.crt -network freenode chat.freenode.net 7000
/save

Note: If the blog wraps the content, there are three commands above, prefixed with /. /network, /server and /save.

Now, when you open irssi, you’ll automagically connect to Freenode over SSL.

I spent some time this afternoon setting up a public git repository for my project, Origami. I had a little bit of trouble getting the repository set up initially, particularly the cgi aspect of it all. Below outlines the steps I took to configure Lighttpd for gitweb, hosted on FreeBSD.

Installation

First, of course, I installed the git port:

portmaster devel/git

I made sure to select the gitweb option, which is de-activated by default. The other options are up to you.

Configuration

Second, I configured Lighttpd in the simplest manner I could find. This solution uses the existing gitweb files in-place. This is contrary to what the pkg-message prescribes, but I like this idea because it’ll ensure that upgrades are handled automatically. I don’t plan to run any additional repositories either, so using the one central set of files is preferable in my situation. This is my configuration:

$HTTP["host"] =~ "^origami.zelut.org" {
$HTTP["url"] =~ "/gitweb/" {
server.indexfiles = ( "gitweb.cgi" )
}
alias.url += ( "/gitweb/" => "/usr/local/share/examples/git/gitweb/" ),
cgi.assign = ( ".cgi" => "/usr/bin/perl" )
}


Repository Configuration

Lastly, I update the repository configuration in /usr/local/share/examples/git/gitweb/gitweb.cgi to my repository location:

our $projectroot = "/path/to/git/repository/"

Conclusion

I find that Lighttpd configuration, once you get used to it, is much simpler than Apache configuration. It’s all a matter of taking the time to learn the options (and finding examples, like this one) and it gets simpler.

I think this configuration for gitweb is very clean, requires minimal configuration additions, and is hopefully pretty self explanatory. I hope it works for you as well.

I reinstalled my Dell Latitude D630 this afternoon using the new Arch Linux installer (2010.05) netinstall. I had an issue however where the live image would start to boot and then I’d get a blank screen. I quickly realized what the problem was, and found a fix.

Note: it looks like it is a similar issue to the one found here.

Basically, the fix that I found, was to append the following to the kernel line at the initial boot prompt:

nomodeset

This is done by hitting the [TAB] key at the boot prompt of the installer and appending that text to the end.

I wanted to get this out in hopes that it’d help others with the same problem.

Good luck, and happy Arch’ing.

Today I built some virtual machines on a KVM platform (Ubuntu 10.04 Server as the host). The three virtual machines are CentOS 5, i386 and will be used primarily for internal application testing. One of the requirements for using these machines in a virtual environment was configuring back-end console access from the host. The virtual machine management tools (virsh) provide custom commands to console into your guest machines, but the guest machines need to be configured to output to the proper console. This article outlines what customizations I made to the CentOS 5 virtual machines in order to console into them from the host using ‘virsh console <guest>’

GRUB

The first modifications that I needed to make were in GRUB. On CentOS the GRUB config file can be found at: /boot/grub/menu.lst. Below you’ll find the changes I made:

default=0
timeout=5
#splashimage=(hd0,0)/grub/splash.xpm.gz
serial --unit=0 --speed=115200
terminal --timeout=10 console serial
hiddenmenu

I’m sure if you compare that snippet with your current configuration you’ll see the changes that I’ve implemented. Primarily the commenting of the splashimage, and the addition of the serial and terminal lines.

In addition to these changes you’ll also need to append some console configurations to each ‘kernel’ line. Here is an example:

title CentOS (2.6.18-164.15.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.15.1.el5 ro root=/dev/SLIM/root console=tty0 console=ttyS0,115200n8


Again, compare this to your current configuration. You’ll notice I’ve added console=tty0 console=ttyS0,115200n8

/etc/inittab

Finally you’ll need to make a change to the /etc/inittab file, which will allow login via the serial console connection:

S0:2345:respawn:/sbin/agetty ttyS0 115200 linux


Once these changes have been applied you should be able to reboot and connect to the console:

virsh console <guest> should then display the GRUB menu, boot output and finally a login.

I’ve recently migrated my server(s) to a new VPS, one which offers BSD as a hosting option. I have long been a fan of FreeBSD on my servers, so this was a deal I couldn’t pass up. I did, however, run into one fairly difficult problem based on my combination of FreeBSD and lighttpd web server. I felt it was important to blog about it so that “teh internets” could share the wisdom and, hopefully, others could solve this same issue quickly.

Problem

The web server seemed to work great. It was handling traffic efficiently. Logs were going where they were expected. Rewrites were working. All the main things that I would expect to test were working just fine. And then I uploaded a file.

Hard lock. Panic. Do not pass go. Do not collect $200. This was bad.

I was even able to reproduce it. Anytime I would upload a file to the server (in my case via WordPress upload form), the server would hard-lock and I’d have to manually bring it back up.

Solution

The solution was to manually define the server.network-backend value, instead of using the auto-detected value. Apparently, at the time of this writing, the auto-detection on FreeBSD is.. less than perfect. The solution that I found was to add the following line to my lighttpd.conf:

server.network-backend = "writev"

After restarting the lighttpd service things seemed to perform as expected.

Conclusion

FreeBSD is a great, stable hosting platform. Lighttpd is a lightweight, efficient web server. Together they provide me with a very efficient, stable web hosting environment. The simple detail is to define the right parameters for the platform in the configuration.

I needed to mount an .iso file this morning, which I’ve done dozens of times in Linux, and I realized the command I’d normally use in Linux does not work. For example:

Linux

mount -o loop image.iso /mnt

This works fine in Linux and lets you “mount” the .iso file as if it were burned and in the drive. This does not work on FreeBSD. You get an error like:

mount: image.iso mount option is unknown: Invalid argument

FreeBSD

The solution (the only one I’ve found so far) is to use a much more in-depth command like:

mount_cd9660 -o ro /dev/$(mdconfig -a -t vnode -f /path/to/file.iso) /mount-point

Hopefully this little note helps someone else have less trouble than I did in mounting .iso images in FreeBSD.

I read an article today regarding an alleged Facebook based virus from the “Fan Check” application. I will admit I’ve been sucked into the Facebook, but to my defense I primarily stick to just a few applications. Reading about this makes me glad that I’m running Chromium browser on Linux. I think, between the two of those, my chances of becoming infected are pretty slim. The chances of becoming infected with any kind of virus are pretty limited by using Linux in the first place, but that is pretty obvious.

What I found interesting about this article and the related “infection” is that, so far, there haven’t been any proven cases of the Facebook application actually directly infecting anyone. The infection is caused by third-party websites provided through search engine results, and then by way of social engineering. Whether from the Facebook application or the third-party websites, this infection does not rely on browser vulnerabilities or outdated software. It is all done with the permission of the user.

Think about it. Your friend invites you to “join the fun” and use a Facebook application. Each application has to be given permission by the end user in order to access required data. If the application itself were the cause of the infection, the user would have to give permission for it to happen.

In the more roundabout situation the user is afraid they were infected directly by the application (may or may not be the case), so they use a search engine to find a tool that will verify this for them. The search results are then populated by pages telling them they are infected and to download security software immediately. Again, if the user decides to download and install the “security software” they have allowed the infection into their machine.

I decided to try some of these search results to see what it is they tried to do. I was honestly pretty impressed with one of them. If I didn’t know any better, and if I were running Windows it would surely look legitimate to me. Have a look.

I find that I run into this problem everytime I reinstall Arch, so I figured it was time to document those pesky missing peices. Considering Arch Linux is more of a “do-it-yourself” distribution there are more peices to the puzzle than you might find in Ubuntu or similar. In this short article I’ll outline everything required to playback DVDs on Arch Linux.

Required Packages

As is the problem with any major Linux distribution, DVD playback can’t be enabled by default for “potential patent issues“. The required packages have to be installed manually. This is done using the command:

sudo pacman -S libdvdcss libdvdread

Required Groups

In order to have required access to the audio, video and optical devices the user needs to be in the required groups. You can ensure your user is in the required groups for DVD playback with the command:

sudo gpasswd -a username audio,video,optical

You’ll have to logout and back in again for the group changes to take effect. After that you should be able to play DVDs as expected.

Media Application

My preferred application for playing back media, including DVD, .avi and general audio, is VLC. VLC works on each major platform and generally does not required extra codecs. You can install VLC using the command:

sudo pacman -S vlc

Conclusion

Arch Linux requires a little more work to get things going, but the reward for the granular control is nice. Your machine is never exactly like any other machine–each Arch Linux users installation is different. Enabling DVD playback takes this same amount of granular configuration, but following the required steps makes the process simple.