BoxBackup installation and configuration on CentOS

2008-09-6 – 11:19 am

Boxbackup is a very interesting solution to automated backups.  For the most part it is all completely self contained relying only on OpenSSL.

Some things that set it apart:

  • Authentication via certificates
  • Userland RAID
  • Encrypted Data Store and Transfer
  • Automatic transfer
  • See here for more

There are quite a few steps to getting it set up, but nothing too complicated.

ON THE SERVER

Compile and install the program (You can try to find an rpm instead)

  1. wget http://boxbackup.org/svn/box/packages/boxbackup-0.11rc2.tgz
  2. tar xzvf boxbackup-0.11rc2.tgz
  3. cd boxbackup-0.11rc2
  4. ./configure –prefix=/usr
  5. make build-backup-server
  6. make install-backup-server
  7. cp contrib/redhat/bbstored /etc/rc.d/init.d/

Configuration (Replace /path/to/datastore and server.example.com with your own settings)

  1. useradd _bbstored -d /path/to/datastore -s /sbin/nologin
  2. mkdir /etc/box
  3. raidfile-config /etc/box 4096 /path/to/datastore
  4. bbstored-config /etc/box server.example.com _bbstored
  5. chown -R _bbstored /etc/box/bbstored
  6. chmod -R go-rwx /etc/box/bbstored

Generate and Sign Certificates (replace server.example.com)

  1. bbstored-certs /etc/box/certs init
  2. bbstored-certs /etc/box/certs sign-server /etc/box/bbstored/server.example.com

Create a user (I use the UID of the user for the boxbackup UID, in this case 501, but it can be an arbitrary number) (5G 6G is quota and max respectively)

  1. bbstoreaccounts create 501 0 5G 6G

Start service

  1. chkconfig –add bstored
  2. chkconfig bbstored on
  3. service bbstored restart

ON THE CLIENT

Installation is similar to above, all of my clients are Arch Linux though, so I’m not going to do a step by step for this.  However, I will show you the basics once it is installed, it’s really easy.  It will create a key (in my case 501-FileEncKeys.raw) it is important to backup this key.  Burn it to a CD, put it on Floppy (if you even have one), transfer it to another server, etc.  Just don’t put it on the boxbackup server or else if the box is comprimised you risk the chance of the attacker being able to decrypt your data store.

Configuration (replace 501 with the UID you used above)

  1. mkdir /etc/box
  2. bbackupd-config  /etc/box lazy 501 server.example.com /var/bbackupd /path/on/client/you/want/to/back/up
  3. scp /etc/box/bbackupd/501-csr.pem root@server.example.com:/etc/box/certs/clients/
    • This is copying the file to server.example.com, and may not work in your environment.  The key is to transfer /etc/box/bbackupd/501-csr.pem from the client to /etc/box/certs/clients/ on the server

BACK ON THE SERVER

Sign the client Certificate

  1. bbstored-certs /etc/box/certs sign /etc/box/certs/clients/501-csr.pem
  2. scp /etc/box/certs/clients/501-cert.pem root@client.example.com:/etc/box/bbackupd/
  3. scp /etc/box/certs/roots/serverCA.pem root@client.example.com:/etc/box/bbackupd/
    • as above the last two are copying the signed certs back to the client, use whatever transfer method works best for your environment

BACK ON THE CLIENT

Now you just need to start the bbclient service and your off and running.

That’s it!  Like I said really simple steps but quite a few of them.

Source Policy Routing on Linux

2008-07-2 – 3:32 am

Default, out of the box, behavior of a router is to look at the destination IP address and forward accordingly.

Policy routing gives you more control over your routers decision making process.  With Policy Routing you can define a specific attribute of a packet, and configure your router to forward the packet in a different way.

Source policy routing is routing based on source IP address.

Real World Example

The company I work for offers a VOIP service.  We use a sister company as our VOIP provider in another state.  Recently we have been experiencing packet loss where our two upstream providers peer.  Needless to say this is not good for VOIP and our customers have experienced issues.

Jokingly at a meeting today I suggested that we route all of the VOIP traffic through a VPN to another upstream of ours, thus bypassing the lossy peering point.

This sparked my interest for two reasons.  The first, proof of concept that it could be done (otherwise known as curiosity).  The second, if we couldn’t convince our upstream of the issue, it could be a last ditch solution.

A word of caution before continuing.  It’s not a good idea to policy route priority traffic through a midstream VPN.

More common situations for policy routing, would be to send priority traffic over a dedicated link.  On a Linux host if you have multiple IPs on different subnets, you could configure each IP to use it’s proper gateway.

Configuring Source Policy Routing on Linux

The bulk of this section was inspired/plagarized from TLDP.

Configuring Source Policy Routing in Linux is fairly simple.

  • Create a new routing table
  • Define a policy rule to lookup the new table
  • Populate new tables routing information

Create a new routing table

# echo “252 VOIP” >> /etc/iproute2/rt_tables

This creates a new routing table which can be referred to as 252 or VOIP.

You can substitute 252 with any number ranging from 1 - 252.
Table 255/local - a special table for local broadcasts.
Table 254/main - the standard table you should be familiary with.
Table 253/default - last resort table, not typically used.
Table 0/unspec - truthfully I’m unsure, but looks like it holds the routes of all tables?

You can view a particular routing table with:

# ip route show table <table_number or table_name>

Define a policy rule to lookup the new table

To create a rule based on source address we will use the policy “from”

# ip rule add from 192.168.254.20 table VOIP

Rules are looked up much in the same way as iptables.  First match wins.
We could define an entire subnet in the form of xxx.xxx.xxx.xxx/xx.

You can view your routing rules with:

# ip rule show
0:      from all lookup 255
32765:  from 192.168.254.20 lookup VOIP
32766:  from all lookup main
32767:  from all lookup default

Populate new tables routing information

Your traffic will currently be dropped as there is not any routing information in the table VOIP.

# ip route add default via 172.16.32.1 dev eth0 table VOIP

Last we need to clear the routing cache

# ip route flush cache

That’s it! We have succesfully altered the default routing decision to send any packet coming in with the source IP of 192.168.254.20 to the gateway 172.16.32.1.

Be sure to check the ip man page for more rule matches as well as rule destinations (it doesn’t have to be a routing table).

SilverMel for Mozilla

2008-06-29 – 6:10 pm

silvermel_screenshot_ff.png

silvermel_screenshot_tb.png

I’m a big kde fan, and I’ve always been frustated with the way Mozilla apps look on my desktop.  I’ve ran the gambit with trying to get gnome apps to look the same.  Some get really close, but still have a very Gnome feel about them, and I just really don’t like the themes that work with both KDE and Gnome theme engines, such as QtCurve.  Then while trying to find a theme addon for Firefox that would go well the KDE4 I stumbled across SilverMel.

SilverMel doesn’t really do much in the way of conforming to a particular Desktop Manager theme.  It is a theme all it’s own for Firefox and Thunderbird, and dang sharp one at that.

Check it out

Under Construction

2008-06-29 – 2:22 pm

Site Under Construction

under_construction_800x600.jpg