Monthly Archives: September 2011

Auto-deploy your Virtualmin website with git

Virtualmin’s non-standard implementation of git can be a little awkward to work with, primarily because git itself assumes too many things about the environment by default. However, there is a very easy way to auto-deploy your website from a virtualmin git repo to your virtualmin website root (public_html) using git hooks.

This assumes you have installed git onto your virtualmin server, and will be accessing the remote (virtualmin) repository over ssh (you can also use any protocol that works with git hooks; http doesn’t!)

  1. Create a new virtual server in virtualmin, and set up a repository for it
  2. On the virtualmin server (ssh into it, or whatever method you prefer), navigate to the git directory (/home/sitename/public_html/git/git.git/), and execute the following commands:
    git config core.bare false
    git config receive.denycurrentbranch ignore
  3. Then go to add the hook; go into the hooks directory, create a file called post-receive, and add the following:
    #!/bin/sh
    cd /home/sitename/public_html/
    git –git-dir=/home/sitename/public_html/git/reponame.git –work-tree=/home/sitename/public_html/ checkout -f
  4. Add execute permissions on the hook, and ensure the ownership is correct (www-data:sitename)
  5. And that’s it…get the url for your repo (something like sitename@siteurl:public_html/git/git.git), and set it up on your local copy of git, then create some files and push from local to remote and it should automatically deploy – by the way, you will need to use “git push origin master” the first time you push to the empty repo

I think this will just deploy the master branch, and I don’t think it will delete files that are deleted locally (not sure exactly how the checkout command works).

I’ll be adding another tutorial that incorporates branches and proper sync between the two.

Notes on XenServer and NTP

  • XenServer syncs with the NTP server anytime between once every one minute and once every 15-20 minutes, depending on the amount of “drift” your hardware clock exhibits (ref)
  • XenServer syncs the hardware clock with the system clock automatically – I think when ntp starts (ref: /etc/rc.d/init.d/ntpd – on XenServer 5.6 SP 2)
  • VMs (both with and without XenServer Tools) have their hardware clocks synced with XenServers system clock when they start up – if you try and use a command like “hwclock -r” and get the message that the hardware clock cannot be accessed; do not worry, it still works

 

 

Configuring list-based querying permissions in bind9

In named.conf.options:

At the top (needs to be at the top, not the bottom), create your access lists:

acl “allowquery” {
    10.9.0.0/16;
    localhost;
};
acl “allowrecursion” {
    10.9.100.1/31;
    10.9.100.2/31;
    localhost;
};

 

Then your options section will look like this:

options {

    forwarders {
        10.0.0.1;
        10.0.0.2;
    };

    allow-query {
        allowquery;
    };

    allow-query-cache {
        allowquery;
    };

    allow-recursion {
        allowrecursion;
    };

    auth-nxdomain no;    #conform to RFC1035
    listen-on-v6 { any; };

};

Setting up a cifs share in Ubuntu 11.04

I’m connecting to Windows SBS 2011, but it should work in other versions of Windows to.  First, you’ll need the server IP, share name, and credentials to access the share if required.

Then:

  1. apt-get install smbfs
  2. Create the directory on your machine you’ll like the share to be linked to
  3. vi /etc/fstab, and add the following to the end:
    //[SERVER_IP]/[SHARE_NAME]     /[LOCAL_SHARE_FOLDER]    cifs    uid=[YOUR_LOCAL_USERNAME],credentials=/etc/cifspw,_netdev     0       0
  4. vi /etc/cifspw, and add the credentials to access the share (windows user account)
    username=Name
    password=Password
  5. chmod 600 /etc/cifspw
  6. mount -a

If successful, there will be no errors/messages when you use the mount -a command, and the share will be visible from Nautilus / wherever you mounted it.

Juniper SSG5 trouble switching the zone on an interface

I’m sure this will apply to other models as well.  Trying to make configuration changes to the interface gives an error similar to: “cannot edit interface, interface currently in use”.  Sadly, simply unplugging the interface is not the solution.  In my case, I had to remove the interface (or rather, an address that routes through that interface) as a DNS Proxy to allow it to be editable (other things I also tried that may or may not be required: deleting all policies associated with the zone the interface is in – I’ve tested this and it looks like it’s not required; deleting policy elements -> addresses for that interface; deleting an address using the interface from DNS -> Host).

I basically went through my config file looking for things referencing the zone that the interface was in / interface / IP addresses that route through that interface.  Unfortunately it’s quite irritating.

Switching from policy-based to route-based VPN with Juniper SSG5 and Shrew Soft

I used this guide to set up the VPN between my Juniper SSG5 and Shrew Soft client, however, it has a disadvantage; the VPN can only be tunnelled into one zone.  To fix this, you can change the VPN from policy-based to route-based.

  1. Backup your config…
  2. Delete the VPN policies
  3. Create a new zone for your VPN – I called mine “VPN”
  4. Create a new tunnel interface in the new zone, make it unnumbered, and set the interface to whatever interface the incoming VPN will be going through (probably WAN)
  5. Go into VPNs > AutoKey IKE > edit > advanced, and select to bind to your tunnel interface
  6. Network > Routing > Destination, create a new route from the IP pool to the tunnel interface
  7. Create policies allowing communication between your VPN zone and whatever zones it should communicate with
  8. Test! (No changes needed on Shrew Soft)

I did read a forum post about adding multiple policies, but my SSG5 gave errors that the IKE was already part of another policy when I tried to set up the additional policies.  This method seems to work though.

Getting git working in aptana on Ubuntu

  1. Make sure you have sun java installed (see here)
  2. Obviously install git and any languages you want to use
  3. If you do not have firefox installed you’ll need to download webkit/mozilla packages (I’m not exactly sure which)
  4. Install the following:
    • xulrunner-1.9.2-dev (NOT 2.0 – 2.0 seems to rename some things from mozilla to webkit, and aptana wants mozilla)
    • tk8.5 (might work with tk, I haven’t tried
    • python-tk
    • libswt-gtk-*-java (I have 3.6 version)

If you’re getting an error similar to the following:

 Unhandled event loop exception
 No more handles [MOZILLA_FIVE_HOME='/usr/lib/xulrunner-devel-2.0'] (java.lang.UnsatisfiedLinkError: Could not load SWT library ......

Make sure to install the 1.9.2 version of xulrunner instead of 2.0 (installing it should uninstall 2.0).
And if you’re getting an error similar to this:

exec 3 wish not found

Check your tk and python-tk are installed.

 

Once you’ve got rid of the error messages, you’re ready to start playing with git.  Connecting an existing repo to a remote one ([commands icon] -> more -> add remote) was causing my aptana to crash without logging anything, however, creating a new project by importing a remote git repo worked, so let’s do that:
File > Import > Git > Git Repository

If you import an empty remote repo, the first time you try and push your files to the repo you’ll get the following error:

No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.

To fix this, go to the terminal within aptana (or a normal terminal), make sure you’re in your project folder, and type:
git push origin master

This will sync the files, and from then you should be able to push properly.

Changing XenServer bonding mode back to default (or reducing bond switchover up-delay)

You need to get the pifs again (or ideally, find the lines you used to change the mode in your bash history) – see here for getting pifs.

Then use the following:
xe pif-param-set uuid=bd26334f-f7ff-3206-e5b2-4c017c51907c other-config:bond-mode=balance-slb other-config:bond-updelay=200

This will set your bond back to balance-slb, and reduce the up-delay time (see here for the issue – although I can’t actually confirm right now that the issue still exists in XenServer 5.6, will try and find out and post here if I do*).

*ps, just doing cat /proc/net/bonding/bond0 will tell you.