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.

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.

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.

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.

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.

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.

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.

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.

Configure /etc/login.conf

The password format is stored within the /etc/login.conf file. The default value being “md5″. To update your configuration to use blowfish instead make the following change to your file:

-       :passwd_format=md5:\

+       :passwd_format=blf:\

After you’ve made this change you’ll need to rehash the login database, which is done using the cap_mkdb command:

cap_mkdb /etc/login.conf

At this point any newly assigned passwords will be created using blowfish instead of MD5. Any existing accounts will retain their MD5 password hash until the password is reset.