The following shell script is an All in one command that can be easily put in the crontab to mirror the repository on your Redmine server :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#!/bin/sh


if [ "run" != "$1" ]; then
  exec ssh -i "$GIT_KEY" -o "StrictHostKeyChecking no" "$@"
fi

remote=$2
local=$3

echo "Mirroring from $remote to $local"

name=$(basename "$local")

export GIT_KEY="`mktemp /tmp/git.XXXXXX`"
export GIT_SSH="$0"

cat >"$GIT_KEY" <<EOF
-----BEGIN DSA PRIVATE KEY-----
### Put here your private key ###
-----END DSA PRIVATE KEY-----
EOF

if [ -d "$local" ]; then
        git "--git-dir=$local" remote update
else
        git clone --mirror "$remote" "$local"
fi

rm -f "$GIT_KEY"

exit 0

You need to copy the private key in the script (line 20). You can then use the script with the following syntax

1

git-import.sh run <remote_repository>  <local_repository>

Notice the use of the run argument to distinguish between executions of the script as a user and as the ssh command to be used by Git.

Here is an example:

1
2
3
4
5
6
7
8
9

[antoine@dev ~]$ ./git-import.sh run git@github.com:antoinemartin/django-windows-tools.git django-windows-tools.git
Mirroring from git@github.com:antoinemartin/django-windows-tools.git to django-windows-tools.git
Cloning into bare repository 'django-windows-tools.git'...
remote: Counting objects: 112, done.
remote: Compressing objects: 100% (88/88), done.
remote: Total 112 (delta 46), reused 78 (delta 14)
Receiving objects: 100% (112/112), 41.04 KiB, done.
Resolving deltas: 100% (46/46), done.
[antoine@dev ~]$ 

The first time you run the script, it creates the Git mirror. The following runs only syncs the mirror:

1
2
3
4

[antoine@dev ~]$ ./git-import.sh run git@github.com:antoinemartin/django-windows-tools.git django-windows-tools.git
Mirroring from git@github.com:antoinemartin/django-windows-tools.git to django-windows-tools.git
Fetching origin
[antoine@dev ~]$ 

Google encourages you to verify that the signature is valid to authentify the purchase. You can do that inside the application, but if the delivery of the purchase involves a server, it is better to do it on the server to prevent client code manipulation. The following show how to do it on .Net server application.

The JSON payload looks like the following :

1
2
3
4
5
6
7
8
9
10
11

{ "nonce" : 1836535032137741465,
  "orders" :
    [{ "notificationId" : "android.test.purchased",
       "orderId" : "transactionId.android.test.purchased",
       "packageName" : "com.example.dungeons",
       "productId" : "android.test.purchased",
       "developerPayload" : "bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ",
       "purchaseTime" : 1290114783411,
       "purchaseState" : 0,
       "purchaseToken" : "rojeslcdyyiapnqcynkjyyjh" }]
}

You receive it with a broadcast com.android.vending.billing.PURCHASE_STATE_CHANGED in the inapp_signed_data extra intent field. The signature comes as a base 64 encoded string in the inapp_signature intent field and looks like this :

1
2
3
4
5

YlNBaqlKSS+zk/fteJuHbvI3/N+hbiLiolYsMl8gCD13+Ii+1m4GSd68rc2TwbSLYsYrHVL/9xg/0CBf
CN6NKLtqjFqRs034ExCW2qaMddwfRiqsGZ3z7ZvWuMyNntE3pTGTxG2X/71/cpGwQoSFQBceVR9t5Sge
Tw5HJimt5xlIhHqgRxS/W/kfrJIyKt03l2hUJDGOX9eig5S4ex6fgyFZxR73/HxOFGJ9ohApwaBNF7rD
LaMZFnYbLsYgBWMOHW1uE+F5b2JZWvyColpe5SKMWaNVWVWZGte1WBOYRFxbriZR1VwClkEg9Y4mVn5k
SZIje5pSueLKwiForU02jA==

It is the signature of the SHA1 digest of the JSON payload with the private key of your developer certificate. Don’t look for this private key, it is detained by Google. Google only provides you the corresponding public key in the profile page of your developer account :

This public key is the base 64 string of the Subject Public Key Info of your certificate encoded in the DER format. It corresponds to the following part of your certificate:

Certificate:
...
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
                   33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
                   66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
                   70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
                   16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
                   c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
                   8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
                   d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
                   e8:35:1c:9e:27:52:7e:41:8f
               Exponent: 65537 (0x10001)
...

The public key in this format cannot be read directly by the RSACryptoServiceProvider class of the .Net System.Security.Cryptography module. The preferred import format for this class is XML. The Bouncy Castle Library allows reading this kind of encoding, but you don’t really need to add a new dependency to your project. Instead, what you need is simply to convert your public key in XML. Once this is done, you can use the following simple .Net code to check the signature:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

    public static bool verify(String message, String base64Signature, String publicKey)
    {
        // By default the result is false
        bool result = false;
        try
        {
            // Create the provider and load the KEY
            RSACryptoServiceProvider provider = new RSACryptoServiceProvider();
            provider.FromXmlString(publicKey);

            // The signature is supposed to be encoded in base64 and the SHA1 checksum
            // Of the message is computed against the UTF-8 representation of the 
            // message
            byte[] signature = Convert.FromBase64String(base64Signature);
            SHA1Managed sha = new SHA1Managed();
            byte[] data = Encoding.UTF8.GetBytes(message);

            result = provider.VerifyData(data, sha, signature);
        }
        catch (Exception /* e */) { /* TODO: add some kind of logging here */}
        return result;
    }

For converting your key, you can download the PEMKeyLoader class and use it in a Console Project to convert your key to XML with the follwing code :

1
2
3
4
5

...

RSACryptoServiceProvider provider = PEMKeyLoader.CryptoServiceProviderFromPublicKeyInfo(MY_BASE64_PUBLIC_KEY);
Console.WriteLine(provider.ToXmlString(false));
...

You will obtain your XML formatted key :

1

<RSAKeyValue><Modulus>u5xfVod+5uEP7Zu/xN3v4yhAO3tSsezDJUBajr92u+wUXZNH2IKt/9/V/HjMyzW5AC0PZpi6ROTWvQoO5Xa2L8+lKLiVtVcaI60O+M6B1Rn1zCYD//TgYwfqofKPvbv/Vshl+LwdkqBcp1as4t6+2f0sGHwH/hT1D+E94m0zf4qOR5O5o3ILXaC1z8pAoV4cM6YttFRDh9lxPj/9hkQR4l809bbxOdJPo41F69rqdyU4xFjncxCOHcFdnkT7LQUVv1v2GYae3Rl4iZVncbEygg4K/+uG21QyC0xRda9L2KmQyV7Mtcb5YTJzyfaI/Z/EEZ0A2pkX+4Ki1MKCaUAPLw==</Modulus><Exponent>AQAC</Exponent></RSAKeyValue>

That you can use then in your project as a string constant.

This class is quite useful but you may find yourself scratching your head because your test does not work like it should. This happens in particular if you’re doing some background work in your service, relying for example on AsyncTask for it.

Read on if you want to understand why it doesn’t work and find a solution for it.

In an Android application, any service is instantiated and operates on the main thread. But this is not the case in the test framework provided by the ServiceTestCase class. Your Service is instantiated in the same thread the test runs.

While your tests are running, there is no Looper waiting for messages on the service thread. In consequence, anything that relies on it and on the Handler class to communicate back to the main thread will not work.

For instance, AsyncTask uses a handler to ensure that the onPostExecute method is called on the main thread. After doInBackground has been called, it posts a message on this handler, but as the Looper on the service is not running to handle the message, the onPostExecute method will never be called.

To circumvent this behaviour, the service must be run on a separate thread with a Looper running.

Simulating main thread behaviour

The ThreadServiceTestCase<T extends Service> (source here) class that we describe here provides such features. It declares a Looper and a Hanlder to be able to run code on it:

1
2

  protected Handler serviceHandler;
  protected Looper serviceLooper;

In the setup of the test, we instantiate the service thread, start it, and link our handler with its looper:

1
2
3
4
5
6
7
8
9

@Override
protected void setUp() throws Exception {
  super.setUp();
  // Setup service thread
  HandlerThread serviceThread = new HandlerThread("[" + serviceClass.getSimpleName() + "Thread]");
  serviceThread.start();
  serviceLooper = serviceThread.getLooper();
  serviceHandler = new Handler(serviceLooper);
}

The corresponding tearDown method shuts down the tread.

We provide a runOnServiceThread method to be able to run code on the service thread:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

 protected void runOnServiceThread(final Runnable r) {
      final CountDownLatch serviceSignal = new CountDownLatch(1);
      serviceHandler.post(new Runnable() {

          @Override
          public void run() {
              r.run();
              serviceSignal.countDown();
          }
      });

      try {
          serviceSignal.await();
      } catch (InterruptedException ie) {
          fail("The Service thread has been interrupted");
      }
  }

Then, the startService methods starts the service in its own thread:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

static class Holder<H> {
  H value;
}

protected T startService(final boolean bound, final ServiceRunnable r) {
  final Holder<T> serviceHolder = new Holder<T>();

  // I want to create my service in its own 'Main thread'
  // So it can use its handler
  runOnServiceThread(new Runnable() {

      @Override
      public void run() {
          T service = null;
          if (bound) {
              /* IBinder binder = */bindService(new Intent(getContext(), serviceClass));
          } else {
              startService(new Intent(getContext(), serviceClass));
          }
          service = getService();
          if (r != null)
              r.run(service);
          serviceHolder.value = service;
      }
  });

  return serviceHolder.value;
}

The bound parameters tells wether to start the service with a binding or with an Intent.. The optional ServiceRunnable parameter can be provided to add some initialization code.

A test class using this code looks like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class MyServiceTest extends ThreadServiceTestCase<MyService> {

  public MyServiceTest() {
      super(MyService.class);
  }


  public void testSomething() {

      // starts the service
      MyService service = startService(true, null);
      ...
      // Do something on the service
      runOnServiceThread( new ServiceRunnable() {
          public void run(Service service) {
              // do something
          }
      });

  }

With it, the service is started in its own thread and the Looper and Handler mechanism will work.

Waiting for listeners to be notified

A service that performs tasks asynchronously also notifies the outcome of the background tasks asynchronously. There are several techniques for doing that, but the most common are :

• Broadcast an intent, or
• Call a callback method on listeners.

This usually happens in the main thread. In our case, it would happen in the service thread. As the test is executing itself in its own thread, some synchronization mechanism is needed between the service thread and the test thread to be able to handle the outcome of the background task in the test.

The ThreadServiceTestCase class provides an helper class for that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public static class ServiceSyncHelper {
  // The semaphore will wakeup clients
  protected final Semaphore semaphore = new Semaphore(0);
  
  /**
  * Waits for some response coming from the service.
  * 
  * @param timeout
  *            The maximum time to wait.
  * @throws InterruptedException
  *             if the Thread is interrupted or reaches the timeout.
  */
  public synchronized void waitListener(long timeout) throws InterruptedException {
      if (!semaphore.tryAcquire(timeout, TimeUnit.MILLISECONDS))
          throw new InterruptedException();
  }
  
}

It contains a semaphore that can be used to synchronize the service thread with the test thread.

In the case of the callback listener, we can then define an utility class like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

static class SynchronizedListener extends ServiceSyncHelper {
  Object result;

  /**
  * Service listener that registers the value returned by the service in
  * the holder and release the semaphore.
  */
  final MyService.Listener listener = new MyService.Listener() {
      public void onTaskPerformed(MyService service, Object returnValue) {
          result = returnValue;
          semaphore.release();
      }
  };

}

When notified by the service in the service thread, the contained listener releases the semaphore and awakes the test that is waiting on the semaphore.

The listener contained in the helper class also needs to be added to the service being tested at service initialization. A test using this feature then becomes :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public void testSomething() {

    // Catch listener callback in the test
    final SynchronizedListener listener = new SynchronizedListener();

    // starts the service
    /* MyService service = */ startService(true, new ServiceRunnable() {
        @Override
        public void run(Service service) {
      // add our listener to the service
            service.addListener(listener);
        }
    });

    // wait for the service to notify us
    try {
        // Wait for the service to perform its background task
        listener.waitListener(WAIT_TIME);
    } catch (InterruptedException ie) {
        fail("The listener never got signaled");
    }

    assertEquals(expected_value, listener.result );
    ...
}

You can grab The ThreadServiceTestCase<T extends Service> source code here. Hope it will help.

• Easy backup and restore with Nandroid backup,
• Easy firmware replacement and updates installation,
• Advanced debugging capabilities.

The following instructions allow unlocking and rooting a Nexus device (Galaxy Nexus, Nexus 7) from the command line on a Linux machine. It involves:

• Backuping your device,
• Unlocking the bootloader,
• Restoring the backup,
• Rooting the device.

Prerequisites

Here is the list of prerequisites :

• Android SDK, to have access to adb and fastboot.
• Clockwork Mode (CWM) recovery image.
• SuperSU installable zip.

The platform-tools directory of the Android SDK must be on your PATH, and the device must have USB debugging enabled.

Udev rules

On Linux, you don’t have to install any driver. You need however to enable access for your users. Depending on your distribution, you may have a package handling that, but if not, here is a quick way to give access to your user to the device (here antoine). Type as root:

1
2
3
4
5

[root@dev ~] $ cd /etc/udev/rules.d
[root@dev rules.d] $ wget https://raw.github.com/M0Rf30/android-udev-rules/master/51-android.rules
[root@dev rules.d] $ groupadd adbusers
[root@dev rules.d] $ udevadm control --reload-rules
[root@dev rules.d] $ gpasswd -a antoine adbusers

Plug your device on the USB cable, and you should be able to see it with adb:

1
2
3

[antoine@dev nexus] $ adb devices
List of devices attached
015d2ebecd341e06        device

Backup

Unlocking the bootloader wipes all the data on the device. If you’re not doing this on a new device, you may want to backup and restore your data and applications. With the device connected in USB debug mode, type :

1

[antoine@dev nexus] $ adb backup -apk -shared -all -f backup.ab

Depending on the amount of data you have on your device, this process can be quite long.

OEM unlock

Unlocking the device is easy. With the device connected in USB debug mode, type:

1

[antoine@dev nexus] $ adb reboot bootloader

The device will reboot in fastboot mode. To check this, type:

1
2

[antoine@dev nexus] $ fastboot devices
015d2ebecd341e06        fastboot

You will see your device in the list. Then you can unlock it by typing:

1
2
3
4
5
6
7
8
9
10
11

[antoine@dev nexus] $ fastboot oem unlock
...
(bootloader) erasing userdata...
(bootloader) erasing userdata done
(bootloader) erasing cache...
(bootloader) erasing cache done
(bootloader) unlocking...
(bootloader) Bootloader is unlocked now.
OKAY [ 54.821s]
finished. total time: 54.821s
[antoine@dev nexus] $ fastboot reboot

At the end of the process, reboot your device:

1

[antoine@dev nexus] $ fastboot reboot

You will go through the initialization process in the device.

Restore

Once the device is up and running, you can restore your data with:

1

[antoine@dev nexus] $ adb restore backup.ab

Root

To root the device, we will apply the SuperSU installable zip as an update in CWM.

First we push the SuperSU installable zip in the device filesystem:

1
2

[antoine@dev nexus] $ adb push CWM-SuperSU-v0.96.zip /sdcard/update.zip
752 KB/s (674673 bytes in 0.875s)

Now that the device is unlocked, we can boot it into CWM. We first reboot it in fastboot mode:

1

[antoine@dev nexus] $ adb reboot bootloader

And then boot it with CWM:

1
2
3
4
5
6

[antoine@dev nexus] $ fastboot boot recovery-clockwork-6.0.1.0-grouper.img
downloading 'boot.img'...
OKAY [  0.800s]
booting...
OKAY [  0.020s]
finished. total time: 0.820s

After a few seconds, the device will show the CWM interface. With the volume buttons, move to the install zip from sdcard option and select it by pushing the power button.

On the new menu that appears, choose the apply /sdcard/update.zip option and scroll down to the Yes option. click on the power button and SuperSU will be installed.

Once done, you can go back to the main CWM menu and reboot the device.

Permanently install CWM

You can permanetly install CWM on the device recovery partition so that you can start your device in CWM without being connected via USB.

Your device automatically restores the recovery partition at each boot. To avoid that, you need to delete the /system/recovery-from-boot.p file on the device :

1
2
3
4
5

[antoine@dev nexus] $ adb shell
shell@android:/ $ su
shell@android:/ # rm /system/recovery-from-boot.p
shell@android:/ # exit
shell@android:/ $ exit

You can then reboot in fastboot mode and install CWM permanetly :

1
2
3

[antoine@dev nexus] $ adb reboot bootloader
[antoine@dev nexus] $ fastboot flash recovery recovery-clockwork-touch-6.0.0.6-grouper.img
[antoine@dev nexus] $ fastboot reboot

I personally don’t recommend to install CWM permanetly as it will prevent you from installing the OTA updates that are pushed to your device.

All your projects are located in your server git.mycompany.com under /srv/git. You’re using the user named git to connect to your server with the SSH private key located in ~/.ssh/git.

Here is the quickiest way to deploy your projet:

You first add your SSH key to the SSH agent :

1

[antoine@dev my_project] $ ssh-add ~/.ssh/git

If the agent is not started, you need to execute first :

1

[antoine@dev my_project] $ eval `ssh-agent`

Then you create an empty Git bare repository on your server with the name of your project :

1
2

[antoine@dev my_project] $ ssh git@git.mycompany.com "git --bare init /srv/git/$(basename $(pwd)).git"
Initialized empty Git repository in /srv/git/my_project.git/

Then you add your newly created remote Git repository as the origin of your local repo :

1

[antoine@dev my_project] $ git remote add origin "git@git.mycompany.com:/srv/git/$(basename $(pwd)).git"

You push your master branch to the remote repository :

1
2
3
4
5
6

[antoine@dev my_project] $ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 209 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@git.mycompany.com:/srv/git/my_project.git
 * [new branch]      master -> master

Lastly, you make your local branch track your remote branch :

1
2

[antoine@dev my_project] $ git branch --set-upstream master origin/master
Branch master set up to track remote branch master from origin.

The last two steps can be done for any local branch you have that you want to push on the server.

You can test pulling from the server :

1
2

[antoine@dev my_project] $ git pull
Already up-to-date.

That’s it !

Pre-requisites

Logged as root, install the following packages:

1

yum install make gcc gcc-c++ zlib-devel ruby-devel rubygems ruby-libs apr-devel apr-util-devel httpd-devel mysql-devel mysql-server automake autoconf ImageMagick ImageMagick-devel curl-devel

And then install the bundle ruby gem:

1

gem install bundle

Install Redmine

Redmine is installed with the following commmands:

1
2
3
4
5

cd /var/www
wget http://rubyforge.org/frs/download.php/76255/redmine-1.4.4.tar.gz
tar zxf redmine-1.4.4.tar.gz
ln -s redmine-1.4.4 redmine
rm -f redmine-1.4.4.tar.gz

Install Redmine ruby dependencies

Bundle helps us install the ruby Redmine dependencies:

1
2

cd /var/www/redmine
bundle install --without postgresql sqlite test development

Database creation

First we start MySQL:

1

service mysqld start

Then we secure it (Optional):

1

mysql_secure_installation

We then create the redmine database and user:

1
2
3
4
5

$ mysql
mysql> create database redmine character set utf8;
mysql> grant all privileges on redmine.* to 'redmine'@'localhost' identified by 'my_password';
mysql> flush privileges;
mysql> quit

Redmine database configuration

We copy the database configuration example and we modify it to point to our newly created database:

1
2

cd /var/www/redmine/config
copy database.yml.example database.yml

On the database.yml file, the production section should look like this:

1
2
3
4
5
6
7

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password
  encoding: utf8

And then we create and populate the database with the following rake commands:

1
2
3
4

cd /var/www/redmine
rake generate_session_store
rake db:migrate RAILS_ENV="production"
rake redmine:load_default_data RAILS_ENV="production"

Outgoing email configuration (Optional)

To configure an outgoing SMTP server for sending emails, we create the config/configuration.yml file from the sample:

1
2

cd /var/www/redmine/config
cp configuration.yml.example configuration.yml

And edit it to provide our configuration :

1
2
3
4
5
6
7

production:
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: "smtp.mydomain.com"
      port: 25
      domain: "mydomain.com"

Redmine standalone testing

At this point, Redmine can be tested in standalone mode by running the following command:

1
2

cd /var/www/redmine/
ruby script/server webrick -e production

and open the http://localhost:3000 addess in a browser. If you are testing from another computer, you will need to open the port in the /etc/sysconfig/iptables file by duplicating the ssh (port 22) line and adapting it:

1
2

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3000 -j ACCEPT

Then apply the new configuration with the following command:

1

service iptables restart

Passenger installation

To install Phusion passenger, we firts install its gem:

1

gem install passenger

And then install the Apache module with the command:

1

passenger-install-apache2-module

Apache configuration

We remove the default Apache configuration and replace it by a new one:

1
2
3

cd /etc/httpd
mv conf.d available
mkdir conf.d

In the empty new conf.d folder, we create a redmine.conf file with the following configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Loading Passenger
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.13/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.13
PassengerRuby /usr/bin/ruby

<VirtualHost *:80>
   ServerName redmine.mycompany.com
   DocumentRoot /var/www/redmine/public
   <Directory /var/www/redmine/public>
      # This relaxes Apache security settings.
      AllowOverride all
      # MultiViews must be turned off.
      Options -MultiViews
      allow from all
   </Directory>

   ErrorLog "|/usr/sbin/rotatelogs /etc/httpd/logs/redmine-error.%Y-%m-%d.log 86400"
   CustomLog "|/usr/sbin/rotatelogs /etc/httpd/logs/redmine-access.%Y-%m-%d.log 86400" "%h %l %u %t %D \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

</VirtualHost>

We then enable named based virtual hosting for our server by uncomenting the following line in the /etc/httpd/conf/httpd.conf file:

1
2
3
4
5
6

...
#
# Use name-based virtual hosting.
#
NameVirtualHost *:80
...

We give full access on the redmine folder to the apache user and test the configuration:

1
2

chown -R apache:root /var/www/redmine
service httpd configtest

At this point, the SELinux configuration needs to be modified to allow our apache instance to run the phusion passenger module. You can do this by putting SELinux in permissive mode:

1

setenfore Permissive

And letting the Permissive mode survive a reboot by modifyin the /etc/selinux/config file from:

1

SELINUX=enforcing

to

1

SELINUX=permissive

If you want to run redmine while enforcing, you may want to apply the method described here for which you will need to install the policycoreutils-python package.

In any case, you will start Apache with the command:

1

service httpd start

Now you can access your Redmine installation with your browser. To access it from all the computers in your network, you will need to open the port 80 in the /etc/sysconfig/iptables. You can replace the 3000 rule by :

1
2

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

And restart iptables.

1

service iptables restart

Start services at boot

To have MySQL and Apache started at boot, run the commands:

1
2

chkconfig --level 345 mysqld on
chkconfig --level 345 httpd on

Cleaning up

A quick command to clean up all the devel stuff needed for installation:

1

yum remove '*-devel' make automake autoconf

Tips

Don’t forget that if you change your Redmine configuration, you don’t have to restart Apache. Your can restart only Redmine with the command:

1

touch /var/www/redmine/tmp/restart.txt

If you restore data on your server from another redmine instance that runs on a previous version, dont forget to migrate your data:

1
2

cd /var/www/redmine
rake db:migrate RAILS_ENV="production"

On Windows, background processes are mostly run as Windows Services. Fortunately, Python for Windows Extensions (a.k.a pywin32) provides facilities to create a Windows Service.

I have packaged the related code for this post and the previous one in a project called django-windows-tools available on github and the cheese shop. To make it available for your application, simply install it with the command:

1

pip install django-windows-tools

Configuring your project

To run Celery for your project, you need to install Celery and choose a Broker for passing messages between the Django application and the Celery worker processes.

Installation of celery is easy:

1

pip install django-celery

Then you add it to your settings.py:

1
2
3
4
5
6

INSTALLED_APPS += (
    'djcelery',
)

import djcelery
djcelery.setup_loader()

You can choose among several message brokers. I personnaly use a Windows port of Redis installed as a Windows Service. The advantage of Redis is that it can also be used as an in-memory database. In case you’re interested, you can find here a binay copy of my installation.

The configuration of Redis as Celery’s broker also occurs in the settings.py:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Redis configuration
REDIS_PORT=6379
REDIS_HOST = "127.0.0.1"
REDIS_DB = 0
REDIS_CONNECT_RETRY = True

# Broker configuration
BROKER_HOST = "127.0.0.1"
BROKER_BACKEND="redis"
BROKER_USER = ""
BROKER_PASSWORD =""
BROKER_VHOST = "0"

# Celery Redis configuration
CELERY_SEND_EVENTS=True
CELERY_RESULT_BACKEND='redis'
CELERY_REDIS_HOST='127.0.0.1'
CELERY_REDIS_PORT=6379
CELERY_REDIS_DB = 0
CELERY_TASK_RESULT_EXPIRES = 10
CELERYBEAT_SCHEDULER="djcelery.schedulers.DatabaseScheduler"
CELERY_ALWAYS_EAGER=False

Finally, you add the django_windows_tools application to your project:

1
2
3

INSTALLED_APPS += (
    'django_windows_tools',
)

After the configuration, a python manage.py syncdb will ensure that the database of your project is up to date.

Enabling the service

The installed service is going to allow us to run in the backround arbitrary management commands related to our project.

With the application installed, on the root of your project, type the following command:

1

D:\sites\mydjangoapp> python winservice_install

It will create two files in the root directory of your project .service.py will help you install, run and remove the Windows Service. It’s much like manage.py for the service. service.ini contains the list of management commands that will be run by the Windows Service.

Configuring the service

A look at the service.ini file gives us the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

[services]
# Services to be run on all machines
run=celeryd
clean=d:\logs\celery.log

[BEATSERVER]
# There should be only one machine with the celerybeat service
run=celeryd celerybeat
clean=d:\logs\celerybeat.pid;d:\logs\beat.log;d:\logs\celery.log

[celeryd]
command=celeryd
parameters=-f d:\logs\celery.log -l info

[celerybeat]
command=celerybeat
parameters=-f d:\logs\beat.log -l info --pidfile=d:\logs\celerybeat.pid

[runserver]
# Runs the debug server and listen on port 8000
# This one is just an example to show that any manage command can be used
command=runserver
parameters=--noreload --insecure 0.0.0.0:8000

[log]
filename=d:\logs\service.log
level=INFO

The services section contains :

• The list of background commands to run in the run directive.
• The list of files to delete when refreshed or stopped in the clean directive.

Here the run directive contains only one command: celeryd. If we look at the corresponding section of the ini file, we find:

1
2
3

[celeryd]
command=celeryd
parameters=-f d:\logs\celery.log -l info

command specifies the manage.py command to run and parameters specifies the parameters to the command.

So here the configurations tells us that the service, when started, will run a python process equivalent to the command line:

1

  D:\sites\mydjangoapp> python manage.py celeryd -f d:\logs\celery.log -l info

And that the d:\logs\celery.log will be deleted between runs.

The log sections defines a log file and logging level for the service process itself:

1
2
3

[log]
filename=d:\logs\service.log
level=INFO

Installing and removing the service

You need to have administrator privileges to install the service in the Windows Registry so that it’s started each time the machine boots. You do that with the following command:

1

D:\sites\mydjangoapp> python service.py --startup=auto install

The --startup=auto parameter will allow the service to start automatically when the server boots. You can check it has been installed:

It can be removed with the following commands:

1

D:\sites\mydjangoapp> python service.py remove

Please ensure that the Server Manager is not running when you run this command, because in that case a complete removal of the service will need a server restart.

Starting and stopping the service

The service can be manually started and stopped with the following commands:

1
2

D:\sites\mydjangoapp> python service.py start
D:\sites\mydjangoapp> python service.py stop

If everything went fine, the python processes should be there:

Along with the log files :

Running the Beat service

If you deploy your Django project on several servers, you probably want to have Celery worker processes on each deployed machine but only one unique Beat process for executing scheduled tasks. You can customize the services section of the service.ini configuration file on that specific machine, but this is incovenient if you are sharing files between machines, for instance.

The service provides the ability to have several services sections in the same configuration file for different host servers. The Windows Service will try to find the section which name matches the name of the current server and will fallback to the services section if it does not find it. This allows you to have a different behaviour for the service on different machines. In the preceding configuration, you have one section, named BEATSERVER :

1
2
3
4

[BEATSERVER]
# There should be only one machine with the celerybeat service
run=celeryd celerybeat
clean=d:\logs\celerybeat.pid;d:\logs\beat.log;d:\logs\celery.log

which adds the celerybeat command to the celeryd command. With this configuration file, the service run on a machine named BEATSERVER will run the Celery beat service.

The winservice_install facility provides a convenient option for choosing the current machine as the Beat machine. Let’s try that :

The new service.py file will contain a section with the name of the current machine:

1
2
3
4

[WS2008R2X64]
# There should be only one machine with the celerybeat service
run=celeryd celerybeat
clean=d:\logs\celerybeat.pid;d:\logs\beat.log;d:\logs\celery.log

Now, when run, the service will start a new python process:

And new log files for the beat service will be present:

Changes to the configuration

The Windows Service monitor changes to the service.ini configuration file. In case it is modified, the service does the following:

• Stop the background processes.
• Reread the configuration file.
• Start the background processes.

You may have seen in the service.ini file the runserver section:

1
2
3
4
5

[runserver]
# Runs the debug server and listen on port 8000
# This one is just an example to show that any manage command can be used
command=runserver
parameters=--noreload --insecure 0.0.0.0:8000

It allows running the runserver command in a separate process. I you edit the service.ini file and add runserver to the run directive:

1
2
3
4

[WS2008R2X64]
# There should be only one machine with the celerybeat service
run=celeryd celerybeat runserver
...

As soon as you save the file, you can make your browser point to http://localhost:8000 and will obtain:

Running arbitrary commands

As shown in the preceding section, virtually any Django management command can be run by the service at startup or each time the service.ini file is modified. You could imagine having a section:

1
2
3

[collectstatic]
command=collectstatic
parameters=--noinput

Windows is probably not the best production environment for Django but sometimes one doesn’t have the choice. In that case, a few options aleardy exist, most notably the one developed by helicontech that relies on Microsoft’s Web Platform Installer. This solution, which is described here, relies on the installation of a specific native Handler developed by Helicontech.

This handler manages the communication between IIS and the Django application through the FastCGI protocol with the help of a little python script that bridges FastCGI to WSGI. This script is derived from the Allan Saddi flup package that is already used by Django in the manage.py runfcgi command. The flup package doesn’t work under Windows and Helicontech has made the necessary adaptations to make it work with its handler.

Since its version 7, IIS does however support FastCGI natively, so the use of a specific handler to support Django is not needed. This post describes how to configure and run a Django application with the native FastCGI IIS handler. For that, I have myself adapted the Helicontech FastCGI to WSGI script to make it a Django management command.

Python installation

But before that, to run Django you will need to have python on your server. If like me for some reason it is uneasy for you to run a software installer on your server, a good choice is to use Portable Python. With it, you can install and configure your python environment on your development or staging server and install it in your production server(s) by just copying over the python folder. You can even have different python environments with differents configurations on the same server. To use the portable python installation in copied in d:\python from a command line window, juste type:

1

set path=d:\python\app\scripts;d:\python\app;%path%

And then python and its commands are available from the command line:

Another advantage of Portable Python is that it comes already bundled with The Python for Windows extensions (a.k.a. pywin32) and Django.

Adding FastCGI to the project

In our example, the Django project will be named esplayer and will be installed in d:\sites\esplayer. Please note that this configuration has been tested on Windows 2008 Server R2.

Take the fcgi.py file and copy it in the management\commands directory of one of your project applications so that the manage.py help fcgi command returns you:

Configure the FastCGI application on IIS

The next step is to configure the FastCGI Application on IIS. FastCGI is available whenever you have installed the CGI feature on your IIS installation. Run the server manager and go to the IIS role and configuration. Select your website. You should see a FastCGI Settings icon:

Double click on it and select the Add application action. Enter the following parameters:

• In Full Path, enter the path to your python executable.
• In Arguments, enter the command line for running our fcgi command, i.e. d:\sites\esplayer\esplayer\manage.py fcgi --pythonpath=d:\sites\esplayer --settings=esplayer.settings. The pythonpath and settings arguments are needed to be path independent (more on this later).

The other arguments are optional but you should review them to enter sensible values. The Monitor changes to file setting is particularly interesting. It will allow you to specify the path of a file that will trigger a restart of the application whenever it is modified. You can enter the path to the settings.py of your project. I personally prefer to specify a file that I explicitely update via a touch command.

Create the website and configure it to use the FastCGI application

Once we have our FastCGI application configured, we need a web site to make use of it. For it, we create a website pointing to our Django project:

To make the website use our FastCGI application, we create the following web.config file in the root of our project (here d:\sites\esplayer\esplayer):

1
2
3
4
5
6
7
8
9

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <clear/>
      <add name="FastCGI" path="*" verb="*" modules="FastCgiModule" scriptProcessor="D:\python\App\python.exe|d:\sites\esplayer\esplayer\manage.py fcgi --pythonpath=d:\sites\esplayer --settings=esplayer.settings" resourceType="Unspecified" requireAccess="Script" />
    </handlers>
  </system.webServer>
</configuration>

We first clear all the request handlers and then specify that every request (path="*" and verb="*") should be managed by the FastCgiModule module. The scriptProcessor attribute reproduces the Full Path and the Arguments of our FastCGI application separated by |. It allows the module to identify the FastCGI application to which the requests will be routed.

Static files

With the preceding web.config configuration, all the requests are routed to the Django application. However, we want the static files of our application to be managed by IIS itself. To do that, we first configure Django to collect the static files in the static subdirectory of our project. For that, we have the following configuration in our settings.py file:

1
2
3
4
5
6
7
8
9
10
11
12
13

SITE_ROOT = os.path.abspath(os.path.dirname(__file__))
...
STATIC_URL = '/static/'
...
STATIC_ROOT = os.path.join( SITE_ROOT, 'static')
SITE_STATIC_ROOT = os.path.join( SITE_ROOT, 'local_static')

# Additional locations of static files
STATICFILES_DIRS = (
    # Don't forget to use absolute paths, not relative paths.
    ('', SITE_STATIC_ROOT),
)
..

The project wide defined static files are located in the local_static directory. All the static files are collected in the static directory by running the following command:

1

python manage.py collecstatic

In the local_static directory we put the following web.config file:

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <!-- this configuration overrides the FastCGI handler to let IIS serve the static files -->
    <handlers>
    <clear/>
      <add name="StaticFile" path="*" verb="*" modules="StaticFileModule" resourceType="File" requireAccess="Read" />
    </handlers>
  </system.webServer>
</configuration>

Which basically inverts the web.config file or the root of the project by clearing all the handlers and serving all requests only as static files. When collected, this file will go in the static directory and will instruct IIS that all requests below the path /static should be served as static files.

Website creation automation

The website creation that is described in the previous sections can be automated with the following script that must be run as an administrator:

1
2
3
4

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='d:\python\app\python.exe',arguments='d:\sites\esplayer\esplayer\manage.py fcgi --pythonpath=d:\sites\esplayer --settings=esplayer.settings',maxInstances='4',idleTimeout='1800',activityTimeout='30',requestTimeout='90',instanceMaxRequests='100000',protocol='NamedPipe',flushNamedPipe='False',monitorChangesTo='d:\sites\esplayer\esplayer\web.config']" /commit:apphost
%windir%\system32\inetsrv\appcmd.exe add apppool /name:esplayer
%windir%\system32\inetsrv\appcmd.exe add site /name:esplayer /bindings:http://*:80 /physicalPath:d:\sites\esplayer\esplayer
%windir%\system32\inetsrv\appcmd.exe set app "esplayer/" /applicationPool:esplayer

The four commands run in the script do the following actions:

• Create the FastCGI application.
• Create the site application pool.
• Create the website.
• Add the created website to the application pool.

Testing and troubleshooting

After the configuration, the website should be available through IIS. If this is not the case, you will probably get a 500 Error:

The first thing to do is to check that the website is available outside of IIS by running it with the command:

1

python manage.py runserver 0.0.0.0:8000

And accessing it on http://localhost:8000. If the application works as a standalone Django application, the most common cause of error is a misconfiguration of either the FastCGI application or the root web.config file. You need to be sure that the The scriptProcessor attribute of the web.config matches Full Path and the Arguments of the FastCGI application.

To troubleshoot further, the fcgi.py command provides several settings to be put in the settings.py file : FCGI_LOG (default False), when True, instructs the command to create a log file in the path pointed by FCGI_LOG_PATH. If FCGI_LOG_PATH is not defined, the log file will be created in the project root directory. The file name name pattern of the log file will be fcgi_AAMMDD_HHMMSS_XXXX.log, in which AAMMDD is the date, HHMMSS the time and XXXX the FastCGI application process number. If DEBUG is set to True in the settings, the log file will contain the Django debug logs. The FCGI_DEBUG setting (default False), when set to True, will output in the log file information about the FCGI protocol transfers between IIS and the Django application.

Easing the FastCGI configuration

It is somewhat painful to have to specify the pythonpath and settings parameters both in the FastCGI configuration and in the web.config file. To avoid entering them each time, I have created a manage.py script in the scripts subdirectory of the project root that auto configures itself. Here is the source of the file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/usr/bin/python
# -*- coding: utf-8 -*-

import os,sys
from os.path import abspath, dirname

# the base path is my parent directory
base_path = dirname(dirname(abspath(__file__)))


from django.core.handlers.modpython import handler

# Add the parent directory to the path to be able to import settings
sys.path.append(base_path)
sys.path.append(dirname(base_path))

# Now we can import our settings and setup the environment
try:
    import settings # Assumed to be in the same directory.
except ImportError:
    import sys
    sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
    sys.exit(1)
from django.core.management import setup_environ
setup_environ(settings)


from django.core.management import execute_manager

if __name__ == "__main__":
    execute_manager(settings)

With this script, the Arguments setting of the FastCGI application becomes d:\sites\esplayer\esplayer\scripts\manage.py fcgi and the scriptProcessor attribute in the web.config file becomes

1

scriptProcessor="D:\python\App\python.exe|d:\sites\esplayer\esplayer\script\manage.py fcgi"

What next

Once this configuration is done on a project and a server, replicating it across multiple servers is easy as the only configuration not part of the project is the one of the FastCGI application. Most configuration files are ported from server to server with the source code of the project.

However, the first creation and configuration could benefit from having some management commands dedicated to it. These would be part, along with the fcgi.py command, of a specific Django application that could be added to any project.

Furthermore, some of you may have noted that having the website point to the root of the Django project is not mandatory. Thus the Django project itself could be part of the python installation itself and deployed by running a Django management command.

If you are lazy like me, you may insert lazy logs like this one:

1

  Log.v("#LOOK#", "onStart()");

Instead of having less lazy code like:

1
2
3
4
5
6
7
8
9
10

public class SomeActivity extends Activity {
  private static final String LOG_TAG = SomeActivity.class
          .getSimpleName();
  private static final int LOG_LEVEL = Log.VERBOSE;
...

    @Override
    public void onStart() {
      if (LOG_LEVEL <= Log.VERBOSE)
          Log.v(LOG_TAG, "onStart()");

But Eclipse can easily help you to avoid this and then the need to clean up your code after debbuging.

Everybody uses content assist in Eclipse. The CTRL+Space shortcut alleviates us from the need to type all those long field and method names that come out of our imagination. With the Templates feature, it can even write code for us.

Templates are editable in the preferences. To see them, select Window > Preferences and then in the preferences dialog, Java > Editor > Templates. The window looks like this:

If you double click on a template you can edit it:

The template name is what you type in the Editor window before hitting CTRL+Space and that will make Eclipse propose you the template. I won’t go into a full explanation of the syntax of the templates, but basically the template name is replaced by the template pattern and the content between the ${} is replaced either by what you type or by values computed by existing macros. DZone gives you a good Visual Guide to Template listing most common macros.

Now we can create our templates for both adding the Log declarations at the beginning of our class as well as templates for inserting conditionally ran logs.

For the header, we create a template named alh in Java types member context with the following pattern:

1
2
3

${:import(android.util.Log)}private static final String LOG_TAG = ${enclosing_type}.class.getSimpleName();
private static final int LOG_LEVEL = Log.${level};
${cursor}

The different ${} mean:

• ${:import(android.util.Log)}: make sure android.util.Log is imported.
• ${enclosing_type}: insert the name of the type (class) we’re in.
• ${level}: when inserting, put the cursor here and wait for the user to enter the level variable.
• ${cursor}: leave the cursor here when the user hits the ENTER key.

With this template, inserting the log headers in a class is achievied with the following steps:

• type alh and hit STRL+Space.
• select the template (first choice) and hit ENTER
• enter the desired log level (DEBUG for instance) for the class and hit ENTER.
• continue coding.

This is much simpler than copy-pasting the code from another class and replacing the class name and log level.

The following template, named alv in the Java statement context is for inserting verbose logs:

1
2
3

if (LOG_LEVEL <= Log.VERBOSE)
  Log.v(LOG_TAG, "${enclosing_method}() ${}");
${cursor}

The nice thing is that it inserts the name of the current method and wait just after for your debug message. Just typing Enter will leave a log like:

1
2

 if (LOG_LEVEL <= Log.VERBOSE)
      Log.v(LOG_TAG, "onStart() ");

Wich may be just enough.

On this model, you can create ali, ald, ale templates for the different debug levels, or if you want to use String.format() templates like :

1
2
3

if (LOG_LEVEL <= Log.DEBUG)
  Log.d(LOG_TAG, String.format("${enclosing_method}() ${}", ${args}));
${cursor}

Just adapt them to your needs.

Once you have finished debugging, if you change the LOG_LEVEL of your class from let’s say VERBOSE to INFO, all the alv templates you’ve entered will become dead code as the if surrounding the log lines is always false. This is because it compares static variables, and this is just what we want. When we compile for delivery, we want the compiler to optimize out all this code from the binary.

However, the Java compiler will generate warnings for that. As it is not possible to surround the log with a @SuppressWarnings() attribute, you may want to change the error level of dead code from Warning to Ignore. This is done in Window > Preferences, Java > Compiler > Error/Warnings > Potential programming problems.

When it’s time for delivery, you may want to change the LOG_LEVEL of all classes to a particular value. To do that, I personally use a slightly modified version of the alh header template:

1
2
3
4

${:import(android.util.Log,com.eurosport.player.constants.DebugConstants)}private static final String LOG_TAG = ${enclosing_type}.class.getSimpleName();
private static final int LOG_LEVEL_LOCAL = Log.${level};
private static final int LOG_LEVEL = DebugConstants.LOG_FORCE_GLOBAL * DebugConstants.LOG_LEVEL + (1 - DebugConstants.LOG_FORCE_GLOBAL) * LOG_LEVEL_LOCAL;
${cursor}

That works with the DebugConstants interface :

1
2
3
4

public interface DebugConstants {
  public static final int LOG_LEVEL = Log.INFO;
  public static final int LOG_FORCE_GLOBAL = 0;
}

The way the modified alh template works is the following:

• if the value of DebugConstants.LOG_FORCE_GLOBAL is 0, the LOG_LEVEL variable contains the value of the LOG_LEVEL_LOCAL variable.
• if the value of DebugConstants.LOG_FORCE_GLOBAL is 1, the LOG_LEVEL variable contains the value of the DebugConstants.LOG_LEVEL variable.

By having inserted this template in my classes, even if at delivery time some of the LOG_LEVEL_LOCAL values are still set to Log.VERBOSE, by setting LOG_FORCE_GLOBAL to 1, all log levels will be forced to Log.INFO and all the log code for deeper debugging levels will be removed by DCE (Dead Code Elimination).

Now, there’s no more excuses to have sloppy logs in your Android code !

1

getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN)

It doesn’t work.

The height of the status bar is contained in a dimension resource called status_bar_height. It’s not part of the public resources, so you can’t access it directly from your code with android.R.dimen.status_bar_height. You can however compute it at runtime with the following code:

1
2
3
4
5
6
7
8

public int getStatusBarHeight() {
  int result = 0;
  int resourceId = getResources().getIdentifier("status_bar_height", "dimen", "android");
  if (resourceId > 0) {
      result = getResources().getDimensionPixelSize(resourceId);
  }
  return result;
}

You need to put this method in a ContextWrapper class.

Hope it helps.

This tip is divided in two parts :

1. First we create a shell startup script that activates the virtualenv, bash completion and cd in the project directory.
2. Then we create a Linux Desktop Entry file That spawns a console in our environment.

Here you have the startup script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#!/bin/bash
#
# The layout of the development environment is assumed to be:
#
# <pyton virtual env>/
#   src/
#     <project name>/
#       .consolerc (this file)
#       setup.py
#       ...
#       <project name>/
#         manage.py
#         settings.py
#         ...
#

# Run the standard bash rc file
source ~/.bashrc

# Get the current source file name
current="${BASH_SOURCE[0]}"

# Retrieve the source directory
DJANGO_SOURCE_DIR="$(dirname "$(readlink -f "$current")")"

# Get the Django related directories
DJANGO_PROJECT_NAME="$(basename "$DJANGO_SOURCE_DIR")"
DJANGO_ENV_DIR=$(readlink -f "${DJANGO_SOURCE_DIR}/../../")
DJANGO_PROJECT_DIR="${DJANGO_SOURCE_DIR}/${DJANGO_PROJECT_NAME}"

# Activate the environment
source "${DJANGO_ENV_DIR}/bin/activate"
cd "$DJANGO_PROJECT_DIR"
export PATH="$PATH:$(pwd)"

# Retrieve the Django bash completion file (only once) and execute it. 
# This is potentially insecure.
DJANGO_BASH_COMPLETION="${DJANGO_SOURCE_DIR}/.django_bash_completion"
if [ ! -f "$DJANGO_BASH_COMPLETION" ]; then
  curl http://code.djangoproject.com/svn/django/trunk/extras/django_bash_completion -o "$DJANGO_BASH_COMPLETION" 2>/dev/null
fi
source "$DJANGO_BASH_COMPLETION"

# Miscellaneous
alias runserver='cd $DJANGO_PROJECT_DIR;manage.py runserver 0.0.0.0:8000'

The comment at the beginning explains how the project directory layout is assumed to be. That is the only assumption that makes the script. In consequence, it is reusable as is in any other project.

Here is the .desktop file that runs a terminal console with our script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[Desktop Entry]
Exec=/bin/bash --rcfile .consolerc
GenericName[fr]=MyProject Django
GenericName=MyProject Django
Icon=/home/antoine/images/django-icon_0.png
MimeType=
Name[fr]=MyProject Django
Name=MyProject Django
Path=/home/antoine/src/django/my_project/src/my_project/
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
Categories=Development

The command runs in a terminal because of Terminal=true. You can see that apart from Name and GenericName, the only line specific to the project is

1

Path=/home/antoine/src/django/my_project/src/my_project/

It defines the project path, making it easy to reuse. The execution of our init script is done through:

1

Exec=/bin/bash --rcfile .consolerc

The Icon is the familiar Django icon :

I personally put the .desktop file in $HOME/Desktop, but it also can reside in $HOME/.local/share/applications. In that case, the entry will be available in the menu. I’ve tested this under KDE, but it should work also with Gnome.

If practical, you should perform signature verification on a remote server and not on a device. Implementing the verification process on a server makes it difficult for attackers to break the verification process by reverse engineering your .apk file. If you do offload security processing to a remote server, be sure that the device-server handshake is secure.

The signature verification here refers to the signature sent back by the Billing Service to the GET_PURCHASE_INFORMATIONrequest. The signature is against the JSON payload containing the purchase information. We’llget back later on the authentication of the dialog with the server.

The JSON payload looks like the following (It has been indented for readability):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "nonce":7822246098812800204,
  "orders":[
    {
      "notificationId":"-915368186294557970",
      "orderId":"971056902421676",
      "packageName":"com.xxx.yyy",
      "productId":"com.xxx.yyy.product",
      "purchaseTime":1331562686000,
      "purchaseState":1,
      "developerPayload":"WEHJSU"
    }
  ]
}

And we we receive a signature in Base64:

1

rKf9B38gLbJaLiyRbQVJNr0i0IvJxBgi3EmsLoZLkFedZvn642s4+fz3jYCk6IVWWFSqtBH2Z8ChONJkHWrkDUCK79uSBPLN5s4x4AsRHgQ8aw3sRQLAoEDMFA1ym1gkfYfDz+6sxP2Rgg1U/qpHIEHWPDbJAdP7zcM1iz2kEWbYvFwKP3NNWExNB4gWH3IFtPR0l/KLjKBoqpX5zVukmUeaZW0Skx10eFROa4VhqA5JrbZZQwK0jc6FCYi3u6c1ryIw6W5tcdIv1PFOKpE7VMq67yyD+IEXc+nl29FN5ByGhkj/khNY1KLXcszCCa7ygSYw7mQI+omLdyMz6aL3hg==

The payload is signed with the Private key associated with you Google Play account. You can grab your public key in your developer console page.

There are several crypto solutions available in python. In our example, we use pycrypto. It can easily be installed in your Django virtual environment with:

1

pip install pycrypto

Then, the following method allows checking of the payload singature:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

from Crypto.Signature import PKCS1_v1_5
from Crypto.Hash import SHA
from Crypto.PublicKey import RSA
import base64

PUBLIC_KEY='<Put here your public key>'
VERIFY_KEY= RSA.importKey(base64.decodestring(PUBLIC_KEY))

def verify_signature(message, signature):
    '''Verify that signature is the result of signing message'''
    # Get the hash of the message
    h = SHA.new(message)
    # Create a verifier
    verifier = PKCS1_v1_5.new(VERIFY_KEY)
    # decode the signature
    signature = base64.decodestring(signature)
    # verify
    return verifier.verify(h, signature)

In a next post, we’ll se how to make sure on the Android application side that the responses to our requests are really coming from our server.