Happy New Year 2012!

Here we go, another year passed. So a Happy New Year to you all, I thought It was time for some stats so here goes:

- 41 entries posted
- most popular articles were about my Samsung Galaxy SII and secret codes and cyanogen
- visits steadily increased from 2000 to 10000 every month throughout the year
- The top 3 visitors respectively are US, UK then France

So thanks for your support and I’ll try to post more and intersting stuff this year :)

Graphite and Nginx

I have been working on Graphite for a while and the one thing I didn’t like much was having to use Apache. It took some time to get it right, but I have eventually set it up to use supervisor, uwsgi and nginx. I have installed graphite 0.9.9 from sources. This setup is on a Debian stable system. First things first, a few packages to install: apt-get install python-dev libxml2-dev build-essential python-django-tagging. Then unpack carbon, whisper and graphite-web in that order and install them (default directory is /opt/graphite).

Then you need to grab uwsgi and unpack it and cd into the directory, you are now required to run this:

wget http://projects.unbit.it/downloads/uwsgi-0.9.9.2.tar.gz
tar xf uwsgi-0.9.9.2.tar.gz
cd uwsgi-0.9.9.2
make -f Makefile.Py26
cp uwsgi /usr/local/bin/
cp nginx/uwsgi_params /etc/nginx/

All is well in the universe, it is time to configure supervisor (apt-get install supervisor). Then create a file called /etc/supervisor/conf.d/uwsgi.conf and put that in. To restart supervisor, make sure you do a stop/start. Restart is flaky for me.

[program:uwsgi]
command=/usr/local/bin/uwsgi
  --module 'django.core.handlers.wsgi:WSGIHandler()'
  --socket 127.0.0.1:3031
  --chdir /opt/graphite/webapp
  --processes 1
  --master
  --harakiri 120
  --max-requests 5000
  --pythonpath "['/opt/graphite/webapp'] + sys.path"
directory=/opt/graphite/webapp
environment=DJANGO_SETTINGS_MODULE='graphite.settings'
user=www-data
autostart=true
autorestart=true
stdout_logfile=/var/log/nginx/uwsgi.log
redirect_stderr=true
stopsignal=QUIT

Next is to get your nginx config right, keep in mind that i use a directory within a vhost for graphite, so your config will differ if you use graphite as /, here is my full config:

server {
        listen 80;
        listen [::]:80; # use this only if using IPv6
        client_max_body_size    4M;
        server_name  graphite.frlinux.net;
        root   /var/www/stats;
        access_log  /var/log/nginx/stats.access.log;
        error_log  /var/log/nginx/stats.error.log;

        location / {
        }
       location /graphite/ {
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
       location /content {
                alias /opt/graphite/webapp/graphite/content;
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
       location /metrics {
                alias /opt/graphite/webapp/graphite/metrics;
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
       location /dashboard {
                alias /opt/graphite/webapp/graphite/dashboard;
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
       location /render {
                alias /opt/graphite/webapp/graphite/render;
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
       location /browser {
                alias /opt/graphite/webapp/graphite/browser;
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
       location /composer {
                alias /opt/graphite/webapp/graphite/composer;
                gzip off;
                include uwsgi_params;
                uwsgi_pass      127.0.0.1:3031;
        }
}

That’s it, point your browsers to your site like: http://site.example.com/graphite and it should be ready to show you data. Keep in mind that you have to take care of security which I am not covering in this article.

cgit on nginx

A friend of mine made me aware of a nicer web interface for git than gitweb called cgit. You will need to grab the source and compile it. I am assuming that you use /var/www/ as the root of your web server and fcgiwrap which should be configured right already. This is the missing bits for my config:

       location /cgit/ {
		index cgit.cgi;
		include fastcgi_params;
                gzip off;

               if ($uri ~ "/cgit/cgit.cgi") {
                        fastcgi_pass unix:/var/run/fcgiwrap.socket;
                }

        }

You then need to create a folder called /var/www/cgit in which you copy the cgit binary but also cgit.css and cgit.png. You then need to create a /etc/cgitrc configuration file which you will edit for your local configuration and projects. Mine looks like this:

root=/var/cache/git
repo.url=tripwire
repo.desc=Tripwire
repo.path=/var/cache/git/tripwire/.git

Restart/reload your nginx and you are ready to roll.

Quagga and BGP

I recently got reminded of Quagga which is an OpenSource router solution supporting RIP/OSPF/BGP/ISIS and can connect quite nicely with Cisco/Juniper routers. Having done a bit of work with BGP on bare metal Cisco/Juniper, I thought it could be fun to try out Quagga.

BIG FAT WARNING: This proof of concept does not include any proper router security, I suggest you read more about this before deploying this on a live setup.

The setup described here is done by using 2 Debian Squeeze VMs with all latest patches and quagga installed from apt. The topology is fairly simple, I am using 2 network interfaces, eth0 on both boxes is in bridged mode and the second is attached to the host only. My topology is:

  • VM #1: isis – eth0 – 192.168.0.50/255.255.255.0 – eth1 – 10.10.0.1/255.255.0.0
  • VM #2: osiris – eth0 – 192.168.0.52/255.255.255.0 – eth1 – 10.20.0.1/255.255.0.0

The first thing you got to do is enable IP forwarding: sysctl -w net.ipv4.ip_forward=1. Save this into /etc/sysctl.conf. Next, you need to create configuration files for quagga. Edit the first VM and add the following into /etc/quagga/Quagga.conf:

log stdout
!
password awesome_pass
enable password awesome_pass
!
router bgp 7675
 bgp router-id 192.168.0.50
 network 10.10.0.0/16 route-map v4-bgp
 neighbor 192.168.0.52 remote-as 7676
!
route-map v4-bgp permit 10
 set originator-id 192.168.0.50
 set community 7675:1 additive
 set extcommunity rt 7675:1
 set aggregator as 7676 192.168.0.52
 set as-path prepend 192.168.0.52
 set atomic-aggregate
 set metric 20
!
line vty
!

Edit /etc/quagga/zebra.conf and add the following:

hostname isis
password awesome_password
enable password awesome_password
interface eth1

Then edit /etc/quagga/daemons.conf and enable zebra and bgpd to YES. And restart the service: service quagga restart.

You can now edit your second router and add this in /etc/quagga/Quagga.conf:

log stdout
!
password awesome_pass
enable password awesome_pass
!
router bgp 7676
 bgp router-id 192.168.0.52
 network 10.20.0.0/16 route-map v4-bgp
 neighbor 192.168.0.50 remote-as 7675
!
route-map v4-bgp permit 10
 set aggregator as 7675 192.168.0.50
 set atomic-aggregate
 set community 7676:1 additive
 set extcommunity rt 7676:1
 set metric 20
 set originator-id 192.168.0.52
!
line vty

Also edit /etc/quagga/zebra.conf and add the following:

hostname osiris
password awesome_password
enable password awesome_password
interface eth1

Then restart the router. You are now ready to test this and see what happens, from isis, I am going to take a look at osiris, for this, type vtysh to go to the router CLI.

First we check how BGP is looking, notice the second line with a next-hop of 192.168.0.52? This means we are getting routes information from the other router.

isis# sh ip bgp
BGP table version is 0, local router ID is 192.168.0.50
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.0.0/16     0.0.0.0                 20         32768 i
*> 10.20.0.0/16     192.168.0.52            20             0 7676 i
Total number of prefixes 2

Second, we check the neighbours, you see a foreign host, this means they talk to each other.

isis# sh ip bgp neigh
BGP neighbor is 192.168.0.52, remote AS 7676, local AS 7675, external link
  BGP version 4, remote router ID 192.168.0.52
  BGP state = Established, up for 01:35:05
  Last read 09:31:26, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  2          0
    Notifications:          0          0
    Updates:                1          1
    Keepalives:            97         96
    Route Refresh:          0          0
    Capability:             0          0
    Total:                100         97
  Minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  Community attribute sent to this neighbor(both)
  1 accepted prefixes
  Connections established 1; dropped 0
  Last reset never
Local host: 192.168.0.50, Local port: 179
Foreign host: 192.168.0.52, Foreign port: 36249
Nexthop: 192.168.0.50
BGP connection: non shared network
Read thread: on  Write thread: off

Last you can check the connection, this tells you how long they have been connected to each other. If you see Active instead of Established, this is not working properly.

# check the connection
isis# sh ip bgp sum
BGP router identifier 192.168.0.50, local AS number 7675
RIB entries 3, using 288 bytes of memory
Peers 1, using 4560 bytes of memory
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.0.52    4  7676      98     101        0    0    0 01:36:52        1
Total number of neighbors 1

And a ping from the first router to confirm we are getting the routes.

isis# ping 10.20.0.1
PING 10.20.0.1 (10.20.0.1) 56(84) bytes of data.
64 bytes from 10.20.0.1: icmp_req=1 ttl=64 time=0.255 ms
64 bytes from 10.20.0.1: icmp_req=2 ttl=64 time=0.241 ms
64 bytes from 10.20.0.1: icmp_req=3 ttl=64 time=0.217 ms
64 bytes from 10.20.0.1: icmp_req=4 ttl=64 time=0.301 ms
^C
--- 10.20.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.217/0.253/0.301/0.034 ms

This is all for now, I will add some IPv6 configuration soon.

OpenVPN on SGS2 using Cyanogen 7.1

I have toyed with this yesterday and thought I would share the experiment. I wanted to try out the OpenVPN software built-in Cyanogen for my Samsung Galaxy S2, for this I used a Debian on the other side (which uses a public IP). The first step is obviously installing OpenVPN on the server, then configuring it. Once this is installed, you can do the following steps, this will take care of symlinking the easy-rsa directory, create the server CA and create its certificates.

ln -s /usr/share/doc/openvpn/examples/easy-rsa/1.0 easy-rsa
cd easy-rsa
source ./vars
./clean-all
./build-ca
./build-dh
./build-key-server yourserver

Once this is done and you have checked there was no error in all the commands you typed, you can create your first client, still within the same directory do: ./build-key-pkcs12 cm7. In this example, cm7 is your client name.

This is the working config for my OpenVPN server, edit /etc/openvpn/server.conf. I chose TCP as a more reliable way to have my client keep the vpn connection over crappy GPRS.

proto tcp
port 8443
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/yourserver.crt
key /etc/openvpn/easy-rsa/keys/yourserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server 192.168.6.0 255.255.255.0
keepalive 10 120
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
mssfix 1200
tun-mtu 1200

Now comes the interesting bit, Cyanogen has a page on OpenVPN but they don’t really explain how to install the p12 cert you generated. You will need to copy that to the root of your sdcard, then go to Settings/Location and Security/Storage Credentials/Install from SD Card. Once you have selected the file, it will ask for the same password as used during the client cert generation, then you can select a storage password to keep it safe.

You can now set up your OpenVPN, go to Settings/Wireless & Networks/VPN Settings/Add VPN, then define the IP, name and certs, select the same cert for CA and user. Then go to advanced and make sure you change the IP Port and switch to TCP. Now the interesting part, it failed to connect until i rebooted the device. Has to be the shittiest fix ever but here goes…

Make sure you have started your OpenVPN server and check the logs for errors.

CyanogenMod 7.1.0 is out!

The new Cyanogen release is now out and officially supports the Samsung Galaxy S2! Read all the details of the announce but also don’t forget to take a look at the changelog.

I was on the nightly builds since mid-july but it is nice to see a stable release out there. You can download it there. Last but not least, the install guide. Enjoy!

Highly redundant FS server with DRBD

I got to work on a pretty cool piece of hardware lately in order to setup a highly redundant FS server. This is on Centos 5.x, you will need to grab the following packages from CentOS+: drbd83, kmod-drbd83, make sure you exactly match your kernel revision, you can grab the RPMS from the official mirror And also the OCFS2 from Oracle, this is available here for the kernel modules and here for the tools. Again, make sure this matches your kernel. You can now load this up: modprobe -v drbd.

Before preparing your config, please make sure you have two disk slices matching in blocks/cylinders, otherwise this will not work. In this example we use two local machines 192.168.6.66 and 6.67. You must now prepare the configuration file, edit /etc/drbd.conf (which should be empty):

#
# please have a a look at the example configuration file in
# /usr/share/doc/drbd83/drbd.conf
#

global { usage-count yes; }

# you may want to lower the rate, if you're not using a dedicated GBit link
# between both peers; 20M worked well on EC2
common { syncer { rate 100M; } }

resource res0 {
  protocol C;
  startup {
    wfc-timeout 20;
    degr-wfc-timeout 10;
    # we will keep this commented until tested successfully:
    # become-primary-on both;
  }
  net {
    # the encryption part can be omitted when using a dedicated link for DRBD only:
    cram-hmac-alg sha1;
    shared-secret ubersecret;

    allow-two-primaries;
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
  }
  on tic.example.com {
    device /dev/drbd1;
    disk /dev/sdb1;
    address 192.168.6.66:7789;
    meta-disk internal;
  }
  on tac.example.com {
    device /dev/drbd1;
    disk /dev/sdb1;
    address 192.168.6.67:7789;
    meta-disk internal;
  }
  disk {
    fencing dont-care;
  }
}

Copy that config over to the second machine then create it, you will need to type that command on BOTH boxes: drbdadm create-md res0. It will not work if your hostname does not match your configuration. All going well, it should initialize on both, once done, you can start the service on the two boxes together (do not wait too long): service drbd start. If they both started without a hitch, you are ready to sync up the data. An important consideration is a local network for this setup, all the syncing will go over the network so a dedicated link is a good idea (a simple cable from one box to another on private address is more than adequate unless you plan more boxes which is beyond the topic of this article).

You are now ready to make it sync, choose your master and type the following command: drbdadm — –overwrite-data-of-peer primary res0, all going well, you can watch its progress with: drbd-overview.

Once this is done, you can set the two boxes as masters, which is something I want since I will be using a virtual IP, you can promote the second box as master with: drbdadm primary res0 then you can uncomment on both servers the following line: become-primary-on both;.

That’s all folks! :)

A big thanks to this article. And of course, take a look at the official site for more information.

CyanogenMod 7and SGS1/2, the good, the bad and the ugly

I have had a lot of friends and other people asking about Cyanogen and why would I replace the stock rom on all the Android Phones I got (2 at this time) with Cyanogen. I believe this deserves a bit of writing. I have started in the world of Android back on Samsung Galaxy S in July 2010. At the time, my Nokia N97 had just died and a friend of mine (you know who you are :) convinced me enough to go to Android. At the time, my device was served with 2.1 which honestly was kludgy, slow and buggy. It took a month before I rooted the phone and applied another ROM, Samsung leaked 2.2 beta at the time and I liked how fast it was, then followed custom ROMs especially Darky’s Rom which is an excellent choice if you want to stick on Samsung stock but with optimizations.

I have to say that despite all the ROMs I tried, it felt something was missing, I wanted fast and optimized, running on ext4 and not Samsung’s RFS. In march 2011, I eventually installed CyanogenMod, still considered beta at the time, after a not so straight forward install, I was on it. My only regret, the battery life. I haven’t been the only one to complain about it, it was definitely faster to eat up the battery than stock. But the trade was still unbelievable, fast and snappy, like a dream, almost like I had bought a new phone… Then Samsung released the SGS2 and I sold my precious, not without a tear, especially not knowing what it would hold.

May 2011 came and so did my SGS2, delivered with Gingerbread 2.3.3, very fast phone, Samsung made the sane choice to get rid of MFS and stick to EXT4. Major improvement if you ask me. A bounty went out for Cyanogen on the SGS2. Samsung then later gave a free phone to Cyanogen developers. In July 2011, the first public build was out, I installed it straight away. It was not exempt of bugs, namely the light sensor and some bluetooth issues, but again, it beat stock straight away.

We are now at the end of September, and CM7 still isn’t considered as stable but man, the amount of bugs and additions the devs make is simply tremendous. The latest nightly is now on 2.3.5 (something Samsung hasn’t released yet) and bug fixed a plenty. In conclusion, the release pace of Cyanogen is every phone maker’s dream, a team of devs going faster and working hard at releasing the latest and greatest from Android’s official sources, there are issues but in fairness so with the official stock ROM and as for the ugly, apart from one or two stone cold freeze, it was more of a catchy title :)

Last but not least, it is only fair to finish the article with a link to the official site. If you feel like they helped freeing your phone (well just take a look at the impressive list of supported devices), you might want to donate (link on the frontpage of the site). That is all for now, good fight and good night!

OpenDnsSec on Debian with Bind

I had posted about dnssec a few months ago but that was using some quite cumbersome method to deploy DNS Security to your DNS. I have since looked at OpenDNSSEC which is a more suitable and easier solution. Here are my steps to make it work on Debian.

Big Fat Warning: Test this at your own risk, do not deploy in live setups unless you know what you are doing, this will eat kittens and increase your carbon tax. Still reading? Carry on then.

I am using Debian Wheezy (testing) for this DNS setup because the OpenDNSSEC packages are more up to date. Start off by installing the required packages: apt-get install opendnssec libhsm-bin softhsm libsofthsm libhsm-bin. Then you can start on configuring it. All files are under /etc/opendnssec.

Edit the following file: conf.xml (change your PIN with your own):

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: conf.xml.in 3192 2010-04-14 20:51:42Z rb $ -->
<Configuration>
        <RepositoryList>

                <Repository name="SoftHSM">
                        <Module>/usr/lib/libsofthsm.so</Module>
                        <TokenLabel>OpenDNSSEC</TokenLabel>
                        <PIN>6666</PIN>
                </Repository>
        </RepositoryList>
        <Common>
                <Logging>
                        <Syslog><Facility>local0</Facility></Syslog>
                </Logging>

                <PolicyFile>/etc/opendnssec/kasp.xml</PolicyFile>
                <ZoneListFile>/etc/opendnssec/zonelist.xml</ZoneListFile>
        </Common>
        <Enforcer>
                <Privileges>
                        <User>opendnssec</User>
                        <Group>opendnssec</Group>
                </Privileges>
                <Datastore><SQLite>/var/lib/opendnssec/db/kasp.db</SQLite></Datastore>
                <Interval>PT3600S</Interval>
        </Enforcer>
        <Signer>
                <Privileges>
                        <User>opendnssec</User>
                        <Group>opendnssec</Group>
                </Privileges>
                <WorkingDirectory>/var/lib/opendnssec/tmp</WorkingDirectory>
                <WorkerThreads>2</WorkerThreads>
                <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>
        </Signer>
        <Auditor>
                <Privileges>
                        <User>opendnssec</User>
                        <Group>opendnssec</Group>
                </Privileges>

                <WorkingDirectory>/var/lib/opendnssec/tmp</WorkingDirectory>
        </Auditor>
</Configuration>

Then edit kasp.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: kasp.xml.in 3564 2010-07-06 13:39:29Z rb $ -->
<KASP>
        <Policy name="default">
                <Description>A default policy that will amaze you and your friends</Description>
                <Signatures>
                        <Resign>PT2H</Resign>
                        <Refresh>P3D</Refresh>
                        <Validity>
                                <Default>P7D</Default>
                                <Denial>P7D</Denial>
                        </Validity>
                        <Jitter>PT12H</Jitter>
                        <InceptionOffset>PT3600S</InceptionOffset>
                </Signatures>
                <Denial>
                        <NSEC3>
                                <!-- <OptOut/> -->
                                <Resalt>P100D</Resalt>
                                <Hash>
                                        <Algorithm>1</Algorithm>
                                        <Iterations>5</Iterations>
                                        <Salt length="8"/>
                                </Hash>
                        </NSEC3>
                </Denial>
                <Keys>
                        <!-- Parameters for both KSK and ZSK -->
                        <TTL>PT3600S</TTL>
                        <RetireSafety>PT3600S</RetireSafety>
                        <PublishSafety>PT3600S</PublishSafety>
                        <!-- <ShareKeys/> -->
                        <Purge>P14D</Purge>

                        <!-- Parameters for KSK only -->
                        <KSK>
                                <Algorithm length="2048">7</Algorithm>
                                <Lifetime>P1Y</Lifetime>
                                <Repository>SoftHSM</Repository>
                                <Standby>0</Standby>
                        </KSK>

                        <!-- Parameters for ZSK only -->
                        <ZSK>
                                <Algorithm length="1024">7</Algorithm>
                                <Lifetime>P150D</Lifetime>
                                <Repository>SoftHSM</Repository>
                                <Standby>0</Standby>
                                <!-- <ManualRollover/> -->
                        </ZSK>
                </Keys>
                <Zone>
                        <PropagationDelay>PT43200S</PropagationDelay>
                        <SOA>
                                <TTL>PT86400S</TTL>
                                <Minimum>PT1H</Minimum>
                                <Serial>unixtime</Serial>
                        </SOA>
                </Zone>
                <Parent>
                        <PropagationDelay>PT9999S</PropagationDelay>
                        <DS>
                                <TTL>PT3600S</TTL>
                        </DS>
                        <SOA>
                                <TTL>PT172800S</TTL>
                                <Minimum>PT10800S</Minimum>
                        </SOA>
                </Parent>
                <Audit>
                        <!-- <Partial /> -->
                </Audit>
        </Policy>
</KASP>

Edit the following file /etc/softhsm/softhsm.conf then add:

1:/var/lib/opendnssec/db/kasp.db

We can now create the database, it will ask for you PIN, this is the one declared in your first configuration file. Execute the following: softhsm –init-token –slot 1 –label “OpenDNSSEC”

Edit your groups file to match the following:

bind:x:107:opendnssec
opendnssec:x:114:bind
softhsm:x:999:opendnssec

You can now setup the database by doing the following: ods-ksmutil setup

I recommend doing the following to set permissions right and linking the new signed/unsigned directories for OpenDNSSEC.

chown -R opendnssec:opendnssec /var/lib/opendnssec/
chgrp opendnssec /etc/opendnssec/*
ln -s /var/lib/opendnssec/signed /etc/bind/master/
ln -s /var/lib/opendnssec/unsigned /etc/bind/master/

This is now the exciting bit, we are adding our first zone, copy it under /var/lib/opendnssec/unsigned then do:

ods-ksmutil zone add -z myzone.net
service opendnssec-enforcer restart
service opendnssec-signer restart

If you have done it right, it will tell you that it found your zone. If this is the case, it is now time to declare it in order to generate keys: ods-ksmutil key generate –policy default –interval 30. At this stage, you have to wait for the zone to become valid, this takes around 12h depending on what you setup. Time to make yourself a few coffees and listen to a few metal albums.

You now need to ready your zones. Rather than doing it manually, here is a script you can use (make sure you put it in the right folder):

ods-ksmutil  key list |grep ready|awk '{ print $1 }'  > list
for i in `cat list`;
do
SERIAL=`ods-ksmutil key export --zone $i --keystate ready |awk '{ print $11 }'`
ods-ksmutil key ds-seen -z $i -x $SERIAL
done

Now that the zone is ready, you need to get ods to sign it, this is just done by service opendnssec-signer restart. If it worked, you should see your new signed zone in /etc/bind/master/signed. All you got to do now is to change your bind config to point to the newly signed file.

We are now at the end of this article, it should be pointed out that keys expire, your Zone Signing Key (ZSK) expires after 6 months and the KSK after a year, you should plan for regenerating keys before the expiry if possible, since you are supposed to propagate these to the internet to establish the chain of trust from the root servers.

When you are modifying a zone, just trigger ods-signer sign myzone.net to re-sign it. If you need to delete a zone within ods, you can use the following: ods-ksmutil zone delete –zone myzone.net

At this time of writing please note that only a FEW root zones are signed, so this is more research than production (although all my zones are currently signed).

gitweb and nginx on Debian

I have been using NGINX for a while and really like it. You run into special cases depending on when you are trying to run any CGI stuff. I wanted to quickly document how to get it running on a Debian system. I will assume you are using /var/www as your web root and you have Debian. It all starts with apt-get install gitweb fcgiwrap then you need to symlink your new install like this: ln -s /usr/share/gitweb /var/www/.

You now need to tell nginx what to do and how, edit your default file (or wherever you set your vhosts) then add this:

       location /gitweb/ {
		index index.cgi;
		include fastcgi_params;
                gzip off;

               if ($uri ~ "/gitweb/index.cgi") {
                        fastcgi_pass unix:/var/run/fcgiwrap.socket;
                }

        }

My fastcgi_params file is a bit different from the defaults, so I am adding this here, edit /etc/nginx/fastcgi_params

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Just do a service nginx restart and point your browser to /gitweb, all set!

This blog is protected by Dave\\\'s Spam Karma 2: 179 Spams eaten and counting...