Transip uses a Java Applet for accessing your newly created VM. At first I could not get the Java applet to work with the packages available on Ubuntu. This is not Transip’s fault, but rather due to the issues surrounding Java on Linux. Oracle decided to change Java ‘s license and thus forcing Ubuntu to change the way they are handling Java. Basically making installing Java unnecessary difficult. Anyways, if you follow these steps you at least should get a working Transip Console, albeit a very buggy and highly annoying to use console.

Since I use a 64-bit version of Ubuntu the following steps might be different for the 32-bit version. Oh, this worked for me, it might not work for you and eat your cat or something evil like that. Use the following information at your own risk! For now I’m ONLY interested in getting Java applets to work with Chrome & Chromium. If you need a different browser or want to use this Java version on the desktop, you’ll have to find out yourself on how to achieve what you need. Leave a comment if you have done so

Anyways, let’s start!

1) Download Oracle Java JRE 7 (Use the link otherwise you might get lost in a forest of corporate speak…). In my case I’ve downloaded only the Java Runtime Environment (JRE 64-bit tar.gz) version and not the Java Development Kit (JDK) since I only wanted to use an Java applet.

2) Unpack the tar.gz. In my case I used the following path: /opt/jre1.7.0_02
I’ve symlinked this from /opt/jre-oracle to make it more accessible and easy to change.

3) In order to make Chromium use the newly installed Java plugin you need to tell it where it can find the plugin. You need to do this by making a symlink:

sudo ln -s /opt/jre-oracle/lib/amd64/libnpjp2.so /usr/lib/chromium-browser/plugins

4) Restart Chromium and check if the plugin is found. Do this by entering chrome://plugins in the url bar. If you see multiple Java plugins, for instance something with IcedTea, disable all except the one you just installed (probably called similar to this: ‘Java(TM) Plug-in 1.7.0_02′

5) Check if you can use or view a Java Applet. I’ve used this example from the excellent Learning Processing site by Daniel Shiffman

Note: In theory nothing should happen to any other installed Java version you might have, since we only changed the Java plugin for Chromium, but keep in mind that Java Applets will now run using the Oracle JRE and not any previous installed Java versions.

After following the above steps I finally managed to ‘use’ the Transip Console.

PS: Transip, if you’re reading this please fix this abomination you call a console. You can do so much better as you have already shown with your awesome employees responding diligently and the spot on price quality ratio in your products. Except for this horrible VPS console! Please check out Linode and learn from them.

Oh, feel free to contact me if you need a beta tester for a new console


alias sudo='sudo env PATH=$PATH $@'


This allows me to add my ~/Scripts/bin path for personal scripts that make my life easier while allowing those scripts to be run with sudo.

At first I was not so impressed. The first chapters mostly felt like filler content. Actually I can’t even remember the main arguments brought forward in those chapters. However the last chapter really made up for this lack of content in the first chapters. I think the quote below sums this up nicely:

“For the person who understands code, the whole world reveals itself as a series of decisions made by planners and designers for how the rest of us should live. Not just computers, but everything from the way streets are organized in a town to the way election rules (are tilted for a purpose vote for any three candidates) begin to look like what they are: sets of rules developed to promote certain outcomes. Once the biases become apparent, anything becomes possible. The world and its many arbitrary systems can be hacked.”

Source: Program or be programmed

Filtering on the server allows me to easily switch between mail clients like Mutt, Thunderbird and webmail without having to wonder about each client’s specific filtering options. The server deals with the filtering and serves my mail via IMAPS to whatever client I might use to read my mail. Procmail served me well, but it’s arcane ‘language’ to construct rules by which emails are sorted into different folders is a pain to use.

It became harder and harder for me to create correct rules to filter my mail. This resulted into less important mail cluttering up my inbox hiding the important mail and even important mail being sorted into the wrong folder. So I set out to find an alternative for Procmail.

Surprisingly it took way longer than I anticipated to find an alternative to Procmail. Apparently most people just deal with Procmail’s arcane mumbo jumbo language. After some failed attempts I stumbled upon maildirproc by Joel Rosdahl. As Joel puts it:

maildirproc is a program that processes one or several existing mail boxes in the maildir format. It is primarily focused on mail sorting — i.e., moving, copying, forwarding and deleting mail according to a set of rules. It can be seen as an alternative to procmail, but instead of being a delivery agent (which wants to be part of the delivery chain), maildirproc only processes already delivered mail. And that’s a feature, not a bug.

The greatest feature of maildirproc is not even mentioned in this quote: it uses the regular Python programming language to construct rules by which your mail will be sorted. Python is widely regarded as a great readable programming language which suits both aspiring as well as advanced developers. By using Python it is quite easy to construct rules to filter emails. The documentation and examples of maildirproc should have you up and running within minutes.

Personally I still use Procmail as MDA, but it only makes sure my emails will be put into the inbox. Maildirproc will take care of the sorting. I run maildirproc using cron, so that I can see every mail coming in, but all the less important stuff will get automatically sorted every minute or so.

I highly recommend using maildirproc to sort your email instead of Procmail!

I’ve elaborated a bit more on Sean’s piece mainly on the installation, so even if you’re not that experienced you should be able to follow along. Also read Sean’s article as it contains a more sophisticated solution as well!

Preamble
I use Linux on my development machines, but I suppose it should work with any Unixish type of OS, such as OS X or *BSD. Probably doesn’t work on Windows (leave a comment for a Windows based solution).

1. Ok, first put the following line in a file called ‘logmail’ (without the quotes!):
   cat >> /tmp/test-emails-sent.log
2. Save the file somewhere you can find it back In my case, like Sean, I’ve used /usr/local/bin as the directory for this file.
3. Then make sure it has execute rights. You may set it by typing in: chmod +x /usr/local/bin/logmail
4. Finally if you use PHP you need to change the sendmail_path variable in your php.ini. In my case (I’m using Ubuntu 11.04 and 11.10) I’ve added a file called mail.ini to the /etc/php5/conf.d directory with the following line:
   sendmail_path=/usr/local/bin/logmail
5. Restart Apache by typing sudo service apache2 restart
6. Test your application’s mail sending capabilities by looking at the test-emails-sent.log in your /tmp directory

Onder de naam HackersNL is er elke laatste donderdag van de maand (check de agenda!) een informele bijeenkomst voor techneuten, nerds en aanverwanten in hartje Utrecht. Doel van de avond is om kennis, ideëen en ervaringen uit te wisselen rondom technologie.

Aankomende donderdag 28 juli is de eerste keer dat we HackersNL organiseren. Dankzij de hulp van SETUP zijn er geen entreekosten en kunnen we dit doen in het gebouw van de Dutch Game Garden in hartje Utrecht!Daar staat tegenover dat we wel iedereen vragen zich aan te melden zodat we weten op hoeveel mensen we kunnen rekenen. Zonder de hulp van SETUP was dit absoluut niet mogelijk geweest!

Op het programma staan twee interessante sprekers: Peter Maas over de programmeertaal Scala & een kijkje in de keuken van ontwikkelaar Bèr Kessels. Tevens hebben we de ’1 Minuut’ – een concept ontwikkeld met Patrick Beeker – om snel een beeld te krijgen van de aanwezigen en het ijs alvast een beetje te breken

Voor meer informatie en aanmelden, zie http://hackersnl.nl

1. Create a local domain by adding a fake domain name to your hosts file. In this case I use ‘testproject.mine’ as the domain name. In my hosts file I point this domain name to my own local machine. Here’s an example of my hosts file:

testproject.mine 127.0.0.1
anotherproject.mine 127.0.0.1
secret-project.mine 127.0.0.1

2. Setup a Virtualhost in Apache. I use Apache (2.2.14-5ubuntu8.4) on Ubuntu Linux. Check the manual for info on the configuration files. In the main Apache configuration (usually httpd.conf, in my case apache2.conf) I have the following lines:


NameVirtualHost 127.0.0.1
Include /etc/apache2/sites-enabled


The first line with the NameVirtualHost tag binds the local IPv4 ip-address to the Virtualhosts. In the Virtualhost config I also need to use this ip-address as you will see. The second line will include my site aka Virtualhost specific configurations located in /etc/apache2/sites-enabled. In this directory I have a file testproject.mine which contains the VirtualHosts configuration file for ‘testproject.mine’:


<VirtualHost 127.0.0.1>
DocumentRoot /home/bjorn/Sites/testproject.mine
ServerName testproject.mine

<Directory /home/bjorn/Sites/testproject.mine>
Options All
AllowOverride All
</Directory>
</VirtualHost>

As you can see I have a VirtualHost tag which uses the same ip-address as the previous NameVirtualHost on the first line. Within this tag I have several others. Most importantly I have set the DocumentRoot, which points to a directory with all the files I would like serve with Apache (make sure the Apache user has access to this!) and a tag ServerName which is used to uniquely identify a virtual host, when using name-based virtual hosts.
In other words it makes sure that this particular VirtualHosts’ config is loaded when browsing to http://testproject.mine Between the Directory tags are some directives in dealing with this directory. In this case I’m leaving it very open (not recommend for production!) by setting AllowOverride to All and Options to All. This makes it very easy to alter options with an .htaccess.

Deploying WordPress from a local machine to another location such as a testserver is annoying, because there is no easy way to export and import settings (although menu’s and other content can be exported and imported!). WordPress saves configuration options in the database and often these settings are part of serialized arrays (see Serialization) . Making it hard to change these by hand or using a deployment script. Imagine working with multiple developers, several plugins and it becomes a real pain in the ass to keep track of configuration changes.

Some problems are more or less solved for the single WordPress install: moving a single WordPress installation is a lot easier than a WordPress Multisite installation. Using certain constants in the wp-config.php file, such as WP_SITEURL or RELOCATE, you may alter the domain name used to access the WordPress installation. Et voila the installation has been moved!

Keep in mind though, all other settings have not been automagically altered. So you still need to change these, but at least for a single WordPress install there are some constants to help you out. Such constants are, as far as I know, not available in a WordPress Multisite installation and we still have the issues with all the other settings which need to be changed. Basically WordPress at the moment lacks a good approach for dealing with multiple installations and sharing settings.

Therefor my current approach towards development with multiple developers on WordPress Multisite uses database dumps and a simple search-replace. This is a bit ‘hackish’ and certainly not a magic silver bullet, but it at least makes developing with multiple developers a bit easier.

Assumptions

• The WordPress Multisite installation uses subdirectories for the seperate sites.
• There are at least two WordPress Multisite installations. One locally on the developer’s machine and one on a common test server. Both use a domain name and extension, which has the exact amount of characters regardless of it being locally installed or on a test server.

For instance I’ve started to use the following scheme:

• http://domain.mine for my local test installation on my laptop
• http://domain.test for a test server which we use with multiple developers

It doesn’t matter what the domain names and extensions are as long as you are using the exact same amount of characters for both. This ‘fixes’ the issue with settings being tied to a domain name in a serialized array. Due to the nature of serialized arrays, changes in the length or type of the new value will affect the serialized array. By keeping the amount of characters used in the domain name and extension exactly the same we prevent any issues with the length or type. Now I can dump the test server’s database, search ‘domain.test’, replace it with ‘domain.mine’ and use this on my local machine.

For the search and replace I use sed, a nice little Unix commandline tool which makes it very easy to do search-and-replaces. Check out this great tutorial on sed by Bruce Barnett, even if you have used sed before. This is the one-liner I use:

sed 's/bnn.test/bnn.mine/g' < database-dump-original.sql > database-dump-renamed.sql

Note: this implies the test server is the leading example for all installations, so be careful with the test server and make regular dumps (I try to do this with every configuration change).

Although this approach does not solve deployment on a production or live server, keeping track of configuration changes during development is made a bit easier.

• The directory I want to server with Apache is: /var/www/html
• I have three developers: Joe, Jack and Amy
• Apache (by default on Ubuntu) runs as user www-data with group www-data
• The server is a Linode VPS (link uses my referral code)

Instructions

1. Create a new group called web-dev: groupadd web-devThis will be the group to which uses will be added in order to read and write files and directories within /var/www/html

   Note:
   I could also have added the users to the existing www-data group used by Apache, but then the Apache user would have gotten read and write privileges together with the rest of the group. I’m not comfortable doing this, because if an attacker would gain access through Apache, it would give the attacker the same privileges as the Apache user. Therefor I don’t want to give the Apache user anymore privileges than absolutely necessary. In my case nothing more than the ability to serve the files and directories.

2. Add the users to the web-dev group: useradd -G web-dev joeRepeat this for all users you want to be able to read and write the files within /var/www/html.

   Note:
   This is the common group for which we will set the correct permissions.

3. Change the ownership of /var/www/html to one of the developers and the common group they belong to: chown -R joe:web-dev /var/www/html/
   Make sure the directory is still accessible (read for files and execute for directories) by Apache.

   Note:
   By changing the ownership to one of the users in the common group, in our case joe with group ownership changed to the common group web-dev we have established a common directory for all users part of the group web-dev. Update: It may also be a good idea to change the ownership to root. This prevents accidental removal of the directory by the group members. Thanks Jaap for mentioning this!

4. Make sure the /var/www/html is group writeable: chmod -R 775 /var/www/htmlIf the directory is already group writeable you may skip this step
5. Make sure any new files or directories within /var/www/htmlwill inherit the parent directory’s group owner: find /var/www/html -type d -print0 | xargs -0 chmod g+sThis uses the setgid permission bit to make sure any new file or subdirectory will belong to the same group as it’s parent directory. In our case web-dev

   Note:
   Many thanks to rthomson’s answer on ServerFault for the command and concise explanation of setgid

6. Make sure new files and directories created by users are group writable:
   1. Install libpam-umask (mine was installed using libpam-modules by default): sudo apt-get install libpam-modules
   2. Add the line: session optional pam_umask.so umask=002 to the file /etc/pam.d/common-session
   3. Make sure there is no umask line in /etc/profile/ or ~/.bashrc otherwise this will be combined with the umask set in PAM causing the umask to be changed from 002 to something else. If you do find a umask defined in the previous mentioned files, just comment them with a pound sign #.

   Note:

   By default Ubuntu uses an umask 022, which ensures new files are only writable for the owner (i.e. the user who created them). In our case we want files and subdirectories created in /var/www/html to be group writeable and therefor the umask for the users should be changed to umask 002. As far as I know this cannot be done on a per-directory base (although some mentioned that you could do this using POSIX ACL) so we need to set this either per user using ~/.bashrc or systemwide for all users using /etc/profile or by setting up PAM.
   In our case I decided to use PAM so that regardless how a user logs into the server his/her umask will be set correctly. I’m not sure if this is the right way of doing this, since this means that every user would have his/her files group writeable by default which may pose a significant security issue. Our case is (for now) limited to a single purpose server with a very small group of users, so I’m willing to take the risk, however I do think a better solution must be at hand (perhaps POSIX ACL’s?).

7. Type: umaskThis shows the current umask. It should be 022. Now logout and login again to make sure the changed PAM settings take effect when logging in. Again type umask. It should be 0002, if the PAM settings have taken effect.
8. Finally create a new file called test.txt into /var/www/html: touch test.txtUse this file to see if other users can edit it, remove it and create it again. If this little test succeeds everything should have been setup correctly.