Wednesday, 30 May 2012

Merging Branch with Trunk

SVN: Merge a branch with your trunk

When created a branch a few days back to try some fancy new technology in application. Now I want to merge the code in the branch with my trunk.

I have a checked-out working copy of the branch available.

First, make sure you have a working copy of your trunk. I choose to switch my working copy back: (oh, make sure you have all your changes checked in in your branch before you switch!)

$ svn switch
This removes, adds and updates all files you have worked on in your branch and creates a working copy of the code in the trunk.

Now, with my trunk in place, I can call 'merge' and apply the changes.

$ svn merge
Since the files from the trunk and the beginning of the TRY-branch are still exact copies, I won't get in any trouble. If you do (and you did change your code in your trunk), make sure to resolve merging problems before checking in. When ready, check in your new code!

$ svn ci -m "Merge TRY-AJAX branch with trunk"
That's it. You have now merged the branch with your trunk. Enjoy!

Friday, 25 May 2012

LDAP: Creating your first Organizational Units

On the offchance that you haven't installed LAM, and thus haven't created the organizational units people, groups, hosts and domains, here's how to create them manually. Create a file containing the following information:
dn: ou=people,dc=saruman,dc=biz
ou: people
objectClass: top
objectClass: organizationalUnit

dn: ou=groups,dc=saruman,dc=biz
ou: groups
objectClass: top
objectClass: organizationalUnit

dn: ou=hosts,dc=saruman,dc=biz
ou: hosts
objectClass: top
objectClass: organizationalUnit

dn: ou=domains,dc=saruman,dc=biz
ou: domains
objectClass: top
objectClass: organizationalUnit
Let's suppose this file is named orgunits.ldif. Now from the directory that contains this file, feed the information into your OpenLDAP using the following commands:
sudo invoke-rc.d slapd stop
sudo slapadd -c -v -l orgunits.ldif
sudo invoke-rc.d slapd start
This effectively stops the server, writes the information directly into the database, and then starts the server again.
Another way to do (almost) the same thing, would be to add the information with the ldapadd command:
ldapadd -c -x -D cn=admin,dc=saruman,dc=biz -W -f orgunits.ldif
This binds to the OpenLDAP server (which must be running) using the admin account. This in turn causes the command to request the admin password, and then feed the contents from the orgunits.ldif file into the database. However, adding data to a live database precludes you from adding system controlled attributes, as structuralObjectClass is. So for live addition, remove those four particular lines from the orgunits.ldif file.
Explanation of this difference: slapadd is meant as a restore tool, so it must (and can) create system controlled attributes. ldapadd is a modification tool, so it shouldn't need to (and can't) create these attributes.

Migrating User, Password and Group entries to an LDAP server

It's nice to have an LDAP, but it's much nicer if it is filled with information. We'll try to enter all existing users and groups from the host server into LDAP, using the available migration tools.

Creating new users

If we need new users (e.g. when the server you're setting up is spankin' new) then we can create them in several ways. Let's discuss two of them:

Adding a user with an LDIF file

To add a user with the LDAP command line utilities, we first need to create an LDIF file. This file is a simple text file, created with a text editor like vi. The file could look something like the text below. In that file, we create a posix group "networkusers", and a user "sixpacjo" that's a member of this posix group. However, first we need to generate a password for our user, e.g. "raQaMad3", then hash it:
slappasswd -u -h {SSHA} -s raQaMad3
Now with this hashed password, and all other information on user sixpacjo and group networkusers, we can create the actual LDIF file
# Create the user group
dn: cn=networkusers,ou=groups,dc=saruman,dc=biz
objectClass: posixGroup
gidNumber: 10001
cn: networkusers
description: Internal network users 

# Create a new user:
dn: uid=sixpacjo,ou=people,dc=saruman,dc=biz
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Joe Sixpack
description: Your Average Network User
givenName: Joe
sn: Sixpack
# The Unix login-name for the user:
uid: sixpacjo
# The group and user IDs:
gidNumber: 10001
uidNumber: 10001
# The Unix account data:
homeDirectory: /home/sixpacjo
loginShell: /bin/bash
# The encrypted password for the user:
userPassword: {SSHA}OcAQWgcTCzpu6v8n4yUUthiKPM6rlODq
For a line-by-line explanation of this LDIF file, go here; we also explain the password hashing there. If you need to create more users, you can put them all in the same LDIF file, as long as you leave empty lines between each user.
To put the information from this file into our LDAP server, we have two options:
  1. Shut down the OpenLDAP server, put the information straight into the database using slapadd, and then starting the server again. This would be the recommended way to enter information if we hadn't just typed it in ourselves, but previously made a backup of some sorts from the LDAP server using slapcat.
  2. Keep the OpenLDAP running, and use the ldapadd utility to read the data into the live LDAP database. This makes use of the credentials of some user that has the right to write in the database, at least at the places where your LDIF file wants to store information (in the above example: in the groups and people OU's).
The ldapadd method works like this: after creating the file, e.g. sixpack.ldif in a certain place, e.g. our home directory, we run the following command:
ldapadd -v -x -D cn=admin.dc=saruman.dc=biz -W -f ~/sixpack.ldif
The meaning of the options is as follows:
  • -v the everamusing "verbose" for extra diagnostic messages.
  • -x use "simple bind" and not a TLS-encrypted connection.
  • -D cn=admin.dc=saruman.dc=biz is the Distinguished Name with which to bind to the LDAP server.
  • -W prompt for the password of the -D credential. Alternatively, use -w , but ofcourse then the password winds up in your Bash history file et cetera.
  • -f ~/sixpack.ldif read the LDIF information from this particular file, instead of the StdIn
The output of such an action could look like this:
ldapadd -v -x -D cn=admin,dc=saruman,dc=biz -W -f sixpack.ldif
ldap_initialize(  )
Enter LDAP Password:
add objectClass:
add gidNumber:
add cn:
add description:
        Internal network users
adding new entry "cn=networkusers,ou=groups,dc=saruman,dc=biz"
modify complete

add objectClass:
add cn:
        Joe Sixpack
add description:
        Your Average Network User
(et cetera et cetera)
adding new entry "uid=sixpacjo,ou=people,dc=saruman,dc=biz"
modify complete
There, wasn't that fun? We now have Joe Sixpack in our LDAP server with all data necessary for a valid account - even though he as yet can't do anything yet on our server! To change that, we'll have to instruct our server to give user sixpacjo shell access.

Adding a user with LAM

To add a user with LAM is not exactly challenging. Log into LAM with an admin account; in the top menu, click Users; at the left bottom, you'll find a button "New user". Click it.
You'll find yourself in a browser screen with four "tabs": Personal, Unix, Shadow, and Samba3. Incidentally, if the system complains about "No Samba3 domains found in LDAP": ignore that for now.
In the first tab Personal, we find a (large) number of attributes that we can fill; the mandatory attributes are marked with an asterisk. At a minimum, fill in those required attributes. Then switch to the next tab, Unix. Here we fill in the required attributes, taking care to select a unique UID number, selecting the right primary group (that you've made beforehand, naturally, e.g. with the LDIF file mentioned previously), and setting a password. We don't need to add anything to the 3rd and 4th tab, so we can finish by clicking save at the left top hand. LAM should respond with "LDAP operation succesfull".

Wednesday, 2 May 2012

Oracle Client installation on Ubuntu

Oracle Instant Client is a free Oracle database client. The current version is, and several versions back to are available.

Install RPMs

  • Download the Oracle Instantclient RPM files from Everyone needs either "Basic" or "Basic lite", and most users will want "SQL*Plus" and the "SDK".
  • Convert these .rpm files into .deb packages and install using "alien" ("sudo apt-get install alien" if you don't have it):
    alien -i oracle-instantclient-basic*.rpm
    alien -i oracle-instantclient-sqlplus*.rpm
    alien -i oracle-instantclient-devel*.rpm
  • Test your Instantclient install by using "sqlplus" to connect to your database:
sqlplus  username/password@//dbhost:1521/SID
If sqlplus complains of a missing file, run 
sudo apt-get install libaio1
If sqlplus complains of a missing file, follow the steps in the section "Integrate Oracle Libraries" below.
If you execute sqlplus and get "sqlplus: command not found", see the section below about adding the ORACLE_HOME variable. 

Integrate Oracle Libraries

If oracle applications, such as sqlplus, are complaining about missing libraries, you can add the Oracle libraries to the LD_LIBRARY_PATH each time it is used, or to add it to the system library list create a new file as follows:
sudo vi /etc/
  • and add the oracle library path as the first line. For example,
  • or
  • Then run ldconfig:
    sudo ldconfig


Many Oracle database applications look for Oracle software in the location specified in the environment variable 'ORACLE_HOME'.
Typical workstations will only have one Oracle install, and will want to define this variable in a system-wide location.
sudo vi /etc/profile.d/
Add the following:
export ORACLE_HOME=/usr/lib/oracle/
export ORACLE_HOME=/usr/lib/oracle/11.2/client
Alternatively, each user can define this in their ~/.bash_profile
Note: For 11.04 sqlplus was not recognized as a command unless the following line was also included in the file:

SDK fix

Some packages may look for 'oci.h' in $ORACLE_HOME/include, or in $ORACLE_HOME/rdbms/public
The instant client sometimes places the include files, such as oci.h, in /usr/include/oracle//client.
Inspect your system by running the following commands
ls -d /usr/include/oracle/*/client
If there is no 'include' directory under ORACLE_HOME, and it is located over in /usr/include/oracle/ , create a symbolic link to assist packages looking for these header files. For example,
sudo ln -s /usr/include/oracle/11.2/client $ORACLE_HOME/include
And then check it is correct