Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.

Bastille automates deployment and management of containers using a container technology *old enough to buy you a drink! We’ve taken automation concepts learned from leading config management contenders and combined them with the ORIGINAL container technology. FreeBSD introduced containers in April 1999, pre-dating every other container technology available. Imagine, a reliable container technology that has had two decades to work out bugs. Talk about production ready! This talk will outline design features and demonstrate secure container automation in the cloud and on the Raspberry Pi.

* Bastille uses FreeBSD Jails as the container platform.

To learn more about getting started with containers on FreeBSD see the Bastille Getting Started Guide.

Step 1: Download the DSET utility using wget.

wget ftp://ftp.us.dell.com/FOLDER00481758M/1/dell-dset-3.2.0.141_x64_A01.bin

Step 2: Create a working directory and extract the archive
mkdir ~/dell
tail -n+20 dell-dset-3.2.0.141_x64_A01.bin | tar -xzv -C ~/dell

Note: If you get an error saying that the file is not in a valid archive format, you may need to alter the tail command slightly. Use the following command to determine the line at which the archive begins:
awk '/^__ARCHIVE_BELOW__/ {print NR + 1; exit 0; }' dell-dset-3.2.0.141_x64_A01.bin

Step 3: Trick the installer into thinking you’re running a supported OS
The installer uses the /etc/issue and /etc/redhat-release files to determine the operating system. The trick here is to update those files on your system to match one of the supported operating systems listed in the included archive. Look at the support_os_list file found in your working directory (~/dell), and update your files to match one of the listed systems. For CentOS 6.2 I used the Red Hat Enterprise Linux Server release 6 x86_64 entry.

cp /etc/issue{,.bak} && echo 'Red Hat Enterprise Linux Server release 6 x86_64' > /etc/issue
cp /etc/redhat-release{,.bak} && echo 'Red Hat Enterprise Linux Server release 6 x86_64' > /etc/redhat-release

Once this is done you can try to run the installer found in your working directory (~/dell/install.sh).

If you haven’t heard of Salt yet, I’d highly recommend checking out the 30 second summary and consider using Salt to manage your systems.

states/vim/init.sls:
/root/.vimrc:
file.symlink:
- target: /usr/local/share/vim/vim73/vimrc_example.vim


This state breaks down as follows:

/root/.vimrc – File to create
file.symlink – Use the symlink function (others include file.managed, and file.directory)
-target: /usr/local/share/vim/vim73/vimrc_example.vim – Path to original file

Finally I applied the state using the state.sls module, applying only the vim state:

[root@starbuck ~]# salt-call state.sls vim
local:
----------
State: - file
Name: /root/.vimrc
Function: symlink
Result: True
Comment: Created new symlink /root/.vimrc
Changes: new: /root/.vimrc


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.

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!

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.