With LDAP, I can keep all of my user authentication and group membership information in an LDAP directory. If you already have a directory set up, such as Microsoft Active Directory, Novell eDirectory, or an OpenLDAP directory that is in use for authentication, then you can just point at that.

In this case, though, I’m going to create a directory specifically for my DB2 instance. I’ll use OpenDS, an open source Java LDAP server.

After downloading OpenDS, I’ll put unzip it in /opt, resulting in my installation being in /opt/OpenDS-1.0.0:

root@lab01v04# cd /opt
root@lab01v04# unzip /root/OpenDS-1.0.0.zip
Archive:  /root/OpenDS-1.0.0.zip
   creating: OpenDS-1.0.0/
   creating: OpenDS-1.0.0/QuickSetup.app/
   creating: OpenDS-1.0.0/QuickSetup.app/Contents/
   creating: OpenDS-1.0.0/QuickSetup.app/Contents/MacOS/
   creating: OpenDS-1.0.0/QuickSetup.app/Contents/Resources/
   creating: OpenDS-1.0.0/QuickSetup.app/Contents/Resources/Java/
   creating: OpenDS-1.0.0/Uninstall.app/
 [...]
  inflating: OpenDS-1.0.0/setup
  inflating: OpenDS-1.0.0/uninstall
  inflating: OpenDS-1.0.0/upgrade
root@lab01v04#

I’m going to create a new user, opends, under which to run the directory server, then change ownership of the installation directory to the new user:

root@lab01v04# cd /opt/OpenDS-1.0.0/
root@lab01v04# groupadd opends
root@lab01v04# useradd -g opends -d /export/home/opends -m \ 
> -s /usr/bin/ksh93 opends
64 blocks
root@lab01v04# passwd opends
New Password: ...password...
Re-enter new Password: ...password...
passwd: password successfully changed for opends
root@lab01v04# chown -R opends:opends /opt/OpenDS-1.0.0/

Now I can perform the rest of the steps as the new users. After logging in as the opends user, I change to the OpenDS directory and start the setup program. This will allow me to set up the basics of the directory service.

I’ll give you the full conversation below. In essence, I’m accepting most of the defaults. I’ll be running on port 1389, so I can start the server as a non-root user. The base DN for my directory will be dc=lab,dc=mattwilson,dc=org (”dc” is short for “domain component,” so this is equivalent to a DNS name of lab.mattwilson.org).

opends@lab01v04$ cd /opt/OpenDS-1.0.0/
opends@lab01v04$ ./setup --cli

OpenDS Directory Server 1.0.0
Please wait while the setup program initializes...

What would you like to use as the initial root user DN for the Directory
Server? [cn=Directory Manager]:
Please provide the password to use for the initial root user:
Please re-enter the password for confirmation:

On which port would you like the Directory Server to accept connections from
LDAP clients? [1389]:

What do you wish to use as the base DN for the directory data?
[dc=example,dc=com]: dc=lab,dc=mattwilson,dc=org
Options for populating the database:

    1)  Only create the base entry
    2)  Leave the database empty
    3)  Import data from an LDIF file
    4)  Load automatically-generated sample data

Enter choice [1]: 1

Do you want to enable SSL? (yes / no) [no]: no

Do you want to enable Start TLS? (yes / no) [no]: no

Do you want to start the server when the configuration is completed? (yes /
no) [yes]: yes

Setup Summary
=============
LDAP Listener Port: 1389
LDAP Secure Access: disabled
Root User DN:       cn=Directory Manager
Directory Data:     Create New Base DN dc=lab,dc=mattwilson,dc=org.
Base DN Data: Only Create Base Entry (dc=lab,dc=mattwilson,dc=org)

Start Server when the configuration is completed

What would you like to do?

    1)  Setup the server with the parameters above
    2)  Provide the setup parameters again
    3)  Cancel the setup

Enter choice [1]: 1

Configuring Directory Server ..... Done.
Creating Base Entry dc=lab,dc=mattwilson,dc=org ..... Done.
Starting Directory Server ........ Done.

See /var/tmp/opends-setup-23950.log for a detailed log of this operation.

To see basic server configuration status and configuration you can launch
/opt/OpenDS-1.0.0/bin/status
opends@lab01v04$

And with that, we have a directory server running! I’m going to update my path to make it easier to use the various LDAP utilities:

opends@lab01v04$ PATH=/opt/OpenDS-1.0.0/bin:$PATH

Now that the directory server is running, we need to create entries in it to support authentication. At the highest level, we’re going to create to “organizational units,” one for users and one for groups. To create LDAP entries, we use LDIF files. The LDIF file with the “ou” definitions, which we’ll call container-setup.ldif, contains the following:

# users
dn: ou=users,dc=lab,dc=mattwilson,dc=org
objectClass: organizationalUnit
ou: users

# groups
dn: ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: organizationalUnit
ou: groups

To actually import these records into the directory, we’ll use the ldapmodify command. I’m connecting as the directory manager to the LDAP server running on port 1389, and creating records in the container-setup.ldif file:

opends@lab01v04$ ldapmodify -a -D "cn=Directory Manager" -p 1389 \
> -c -f container-setup.ldif
Password for user 'cn=Directory Manager':
Processing ADD request for ou=users,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN ou=users,dc=lab,dc=mattwilson,dc=org
Processing ADD request for ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN ou=groups,dc=lab,dc=mattwilson,dc=org

Next we need to create the users. I need to create users to represent the two operating system users that DB2 is already dependent on: db2inst1 and db2fenc1. Additionally, I will create the bsmith user. When we are all done, we should be able to connect as bsmith even though there is no equivalent Solaris user. DB2 should allow the login based on the LDAP entry.

The following user definitions are in user-setup.ldif:

# db2inst1 user -- required to match instance owner
dn: uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org
objectClass: inetOrgPerson
uid: db2inst1
cn: DB2 Instance 1 Owner
sn: DB2 Instance 1 Owner

# db2fenc1 user -- required to match instance fenced user
dn: uid=db2fenc1,ou=users,dc=lab,dc=mattwilson,dc=org
objectClass: top
objectClass: inetOrgPerson
uid: db2fenc1
cn: DB2 Fenced User 1
sn: DB2 Fenced User 1

# "Bob Smith" user
dn: uid=bsmith,ou=users,dc=lab,dc=mattwilson,dc=org
objectClass: inetOrgPerson
uid: bsmith
cn: Bob Smith
sn: Smith
givenName: Bob

Now we’ll use the ldapmodify tool again to create these entries:

opends@lab01v04$ ldapmodify -a -D "cn=Directory Manager" -p 1389 \
> -c -f user-setup.ldif
Password for user 'cn=Directory Manager':
Processing ADD request for uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=or
g
Processing ADD request for uid=db2fenc1,ou=users,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN uid=db2fenc1,ou=users,dc=lab,dc=mattwilson,dc=or
g
Processing ADD request for uid=bsmith,ou=users,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN uid=bsmith,ou=users,dc=lab,dc=mattwilson,dc=org

And now we’ll define the groups. Again, we need to create the current operating system groups that DB2 is using, db2iadm1 and db2fadm1. We also need to create the other security groups that DB2 uses by default, SYSADM, SYSMAINT, SYSCTRL, and SYSMON. Note also how we’re adding members to these groups.

The contents of the group-setup.ldif file are:

# db2iadm1 group
dn: cn=db2iadm1,ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: top
objectClass: groupOfEntries
cn: db2iadm1
member: uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org

# db2fadm1 group
dn: cn=db2fadm1,ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: top
objectClass: groupOfEntries
cn: db2fadm1
member: uid=db2fenc1,ou=users,dc=lab,dc=mattwilson,dc=org

# SYSADM group
dn: cn=SYSADM,ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: groupOfEntries
cn: SYSADM
ou: Groups
member: uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org

# SYSMAINT group
dn: cn=SYSMAINT,ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: groupOfEntries
cn: SYSMAINT
ou: Groups
member: uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org

# SYSCTRL group
dn: cn=SYSCTRL,ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: groupOfEntries
cn: SYSCTRL
ou: Groups
member: uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org

# SYSMON group
dn: cn=SYSMON,ou=groups,dc=lab,dc=mattwilson,dc=org
objectClass: groupOfEntries
cn: SYSMON
ou: Groups
member: uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org

And finally, create these records with ldapmodify:

opends@lab01v04$ ldapmodify -a -D "cn=Directory Manager" -p 1389 \
> -c -f group-setup.ldif
tPassword for user 'cn=Directory Manager':
Processing ADD request for cn=db2iadm1,ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN cn=db2iadm1,ou=groups,dc=lab,dc=mattwilson,dc=or
g
Processing ADD request for cn=db2fadm1,ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN cn=db2fadm1,ou=groups,dc=lab,dc=mattwilson,dc=or
g
Processing ADD request for cn=SYSADM,ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN cn=SYSADM,ou=groups,dc=lab,dc=mattwilson,dc=org
Processing ADD request for cn=SYSMAINT,ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN cn=SYSMAINT,ou=groups,dc=lab,dc=mattwilson,dc=or
g
Processing ADD request for cn=SYSCTRL,ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN cn=SYSCTRL,ou=groups,dc=lab,dc=mattwilson,dc=org
Processing ADD request for cn=SYSMON,ou=groups,dc=lab,dc=mattwilson,dc=org
ADD operation successful for DN cn=SYSMON,ou=groups,dc=lab,dc=mattwilson,dc=org

The last thing we need to do is assign passwords to the users. OpenDS includes a utility, ldappasswordmodify, to do just that (”adminPassword” is the password I set during setup of OpenDS, and “userPassword” is what I want to set the user’s password to):

opends@lab01v04$ ldappasswordmodify -p 1389 -D "cn=Directory Manager" \
> --authzID "dn:uid=db2inst1,ou=users,dc=lab,dc=mattwilson,dc=org" \
> -w adminPassword -n userPassword
The LDAP password modify operation was successful

opends@lab01v04$ ldappasswordmodify -p 1389 -D "cn=Directory Manager" \
> --authzID "dn:uid=db2fenc1,ou=users,dc=lab,dc=mattwilson,dc=org" \
> -w adminPassword -n userPassword
The LDAP password modify operation was successful

opends@lab01v04$ ldappasswordmodify -p 1389 -D "cn=Directory Manager" \
> --authzID "dn:uid=bsmith,ou=users,dc=lab,dc=mattwilson,dc=org" \
> -w adminPassword -n userPassword
The LDAP password modify operation was successful

And with that, our LDAP directory is created and populated with users and groups, and the users have passwords so they should be able to log in.

After setting up the directory, we need to configure DB2 to use the LDAP plugins. These require some configuration to tell them how to connect to the LDAP user, and how to find users and groups. The configuration is stored in the file sqllib/cfg/IBMLDAPSecurity.ini, relative to the instance root. In my case, that’s /export/home/db2inst1/sqllib/cfg/IBMLDAPSecurity.ini.

For the setup we created above, I’ve entered the following configuration in the file:

LDAP_HOST = localhost:1389
USER_OBJECTCLASS = inetOrgPerson
USERID_ATTRIBUTE = uid
AUTHID_ATTRIBUTE = uid
USER_BASEDN = ou=users,dc=lab,dc=mattwilson,dc=org
GROUP_OBJECTCLASS = groupOfEntries
GROUP_BASEDN = ou=groups,dc=lab,dc=mattwilson,dc=org
GROUPNAME_ATTRIBUTE = cn
GROUP_LOOKUP_METHOD = SEARCH_BY_DN
GROUP_LOOKUP_ATTRIBUTE = member

With the configuration in place, we’ll change the DB2 instance configuration to use the LDAP plugins:

db2inst1@lab01v04$ db2 update dbm cfg using srvcon_pw_plugin \
> IBMLDAPauthserver
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.

db2inst1@lab01v04$ db2 update dbm cfg using clnt_pw_plugin \
> IBMLDAPauthclient
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.

db2inst1@lab01v04$ db2 update dbm cfg using group_plugin IBMLDAPgroups
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.

For the changes to take effect, we need to restart the instance:

db2inst1@lab01v04$ db2 terminate
DB20000I  The TERMINATE command completed successfully.
db2inst1@lab01v04$ db2stop
SQL1064N  DB2STOP processing was successful.
db2inst1@lab01v04$ db2start
SQL1063N  DB2START processing was successful.

Now to test it: we’ll try to connect to the database we created in the last article, mydb, as the user bsmith. Since there’s no user on my Solaris system named bsmith, this wouldn’t have worked before the LDAP configuration. If we’re able to connect, it means DB2 is now using our LDAP directory for authentication:

db2inst1@lab01v04$ db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 9.5.1

You can issue database manager commands and SQL statements from the command
prompt. For example:
    db2 => connect to sample
    db2 => bind sample.bnd

For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
 ? CATALOG DATABASE for help on the CATALOG DATABASE command
 ? CATALOG          for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.

db2 => connect to mydb user bsmith
Enter current password for bsmith:

   Database Connection Information

 Database server        = DB2/SUNX8664 9.5.1
 SQL authorization ID   = BSMITH
 Local database alias   = MYDB

db2 =>

Success! You can see that we are logged in as bsmith. You can try other experiments to make sure this is really working—enter an incorrect password or an invalid username that isn’t defined in LDAP, for example, and the server will correctly reject the connection.

The other day, Ben Rockwell mentioned on his blog that the free edition of DB2 was available for 64-bit Solaris on x86 systems. I like learning about new server software, and databases in particular, so I figured I’d take a look at it.

The majority of my relational database administration experience has been with Oracle, Microsoft SQL Server, MySQL, and PostgreSQL. Of that mix, I was expecting DB2 to be much more like Oracle than the others—specifically, complex installation (if you don’t want to use GUI tools that produce bloated default databases with every option under the sun enabled) and annoying command line tools (it’s 2009 and sqlplus doesn’t have any sort of command completion or press-the-up-arrow-to-get-to-previous-command support). I was pleasantly surprised in how easy it was for a mere mortal to install and create a database entirely from the command line. The interactive tools, though, seem about as brain-dead as sqlplus, though, so my guess was partially right (although perhaps slight favor to DB2 for its help system within its interactive command processor, but ding it back down for requiring an explicit line continuation character…but I’m getting way ahead of myself, we haven’t even installed it yet!).

So enough philosophy, let’s get down to business. Please remember that there’s a “GUI setup wizard” that can do all of this in just a few clicks (for Solaris as well as the other supported platforms, Linux and Windows). But where’s the fun in that? I like to know exactly what’s going on in my systems, and I’ve found that doing things the manual way is a much better way to learn how to support a system in the long run. Also, I like to be able to script most server setup tasks for reliable repeatability. If you’re with me, here we go!

Installing DB2

I have downloaded DB2 9.5 Express-C for Solaris x64, and have the distribution extracted in /root/db2_9.5_expc, ready for installation.

First, I’ll install the software to the default location, /opt/IBM/db2/V9.5. The -p EXP option is to tell the installer what product to install — EXP for Express Edition in this case. Before running the installer, I create the /usr/local/bin directory because DB2 puts a command (db2ls) in there. It doesn’t hurt if that command doesn’t get installed, but the installer will tell you that there were minor errors. So, the installation of the software:

root@lab01v04# mkdir -p /usr/local/bin
root@lab01v04# cd /root/db2_9.5_expc
root@lab01v04# ./db2_install -b /opt/IBM/db2/V9.5 -p EXP -n
The execution completed successfully.

For more information see the DB2 installation log at
"/tmp/db2_install.log.18091".
root@lab01v04#

Creating an Instance

Easy enough. Now we need to create an instance. A DB2 instance is what holds databases and everything in them. One instance can hold several database (like Microsoft SQL Server or MySQL, but unlike Oracle). DB2 instances are owned by and tied to a local user account. In addition to the instance owner user, there is a “fenced user” that is used to provide a security context in which to run certain code. So we’ll be creating two users, db2inst1, the instance owner, and db2fenc1, the fenced user. Note that the actual instance data will live inside of the home directory of the instance owner. We’ll also create two groups, the instance admin group (db2iadm1) and the fenced admin group (db2fadm1). One physical server can run several instances of DB2, so the 1 on the end of the user and group names is just an easy way of identifying this particular instance we’re creating.

Create the groups, then the users, then set the users’ passwords using the regular Solaris tools:

root@lab01v04# groupadd db2iadm1
root@lab01v04# groupadd db2fadm1
root@lab01v04# useradd -g db2iadm1 -d /export/home/db2inst1 \
               -s /usr/bin/ksh93 -m db2inst1
64 blocks
root@lab01v04# useradd -g db2fadm1 -d /export/home/db2fenc1 \
               -s /usr/bin/ksh93 -m db2fenc1
64 blocks
root@lab01v04# passwd db2inst1
New Password: ...password...
Re-enter new Password: ...password...
passwd: password successfully changed for db2inst1
root@lab01v04# passwd db2fenc1
New Password: ...password...
Re-enter new Password: ...password...
passwd: password successfully changed for db2fenc1

We now have the users ready to go. Finally, our last task as root is to create the actual instance. We’ll do that with the db2icrt command, which takes an argument for the fenced user and the instance name/user:

root@lab01v04# /opt/IBM/db2/V9.5/instance/db2icrt -u db2fenc1 db2inst1
Sun Microsystems Inc.   SunOS 5.11      snv_104 November 2008
Sun Microsystems Inc.   SunOS 5.11      snv_104 November 2008
DBI1070I  Program db2icrt completed successfully.

Simple as that. The Sun banner that appears a couple of times is from the instance creation scripts logging in as the users to perform some setup.

Now that the instance is created, we can do the rest of the work as the db2inst1 user, so we’ll change logins. The instance creation tool added an entry to db2inst1’s .profile file to pull in the environment for all of the DB2 commands.

Our first task is to start the instance:

db2inst1@lab01v04$ db2start
SQL1063N  DB2START processing was successful.

Creating the First Database

Since this is a new instance, there isn’t actually anything in it yet (specifically, databases). Now we can create our first database, which we’ll call mydb.

db2inst1@lab01v04$ db2 create database mydb
DB20000I  The CREATE DATABASE command completed successfully.

The db2 command is the DB2 Command Line Processor (CLP). The CLP is the primary interface to issue commands to the server. You can either run db2 command from the shell, which executes the command and exits, or you can use the CLP interactively by running db2 with no arguments. To do a couple quick tests on our database, we’ll use the CLP interactively:

db2inst1@lab01v04$ db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 9.5.1

You can issue database manager commands and SQL statements from the command
prompt. For example:
    db2 => connect to sample
    db2 => bind sample.bnd

For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
 ? CATALOG DATABASE for help on the CATALOG DATABASE command
 ? CATALOG          for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.

db2 =>

When we launch the CLP, we get some basic usage information and then the prompt. We first need to connect to a database, so we’ll connect to the one we just created, mydb:

db2 => connect to mydb

   Database Connection Information

 Database server        = DB2/SUNX8664 9.5.1
 SQL authorization ID   = DB2INST1
 Local database alias   = MYDB

Looks good. We’re connected as the db2inst1 user to the mydb database. Now we can just issue regular SQL statements, so we’ll create a table and insert a couple rows. Note that in the DB2 CLP (like the Unix shell), you need to put a backslash on the end of a line if you want to continue the command. Also, do not put semicolons at the end of SQL commands; in interactive mode they are not allowed.

db2 => create table testtab ( \
db2 (cont.) => id integer not null primary key, \
db2 (cont.) => name varchar(50) not null )
DB20000I  The SQL command completed successfully.
db2 => insert into testtab values (1, 'First entry')
DB20000I  The SQL command completed successfully.
db2 => insert into testtab values (2, 'Second entry')
DB20000I  The SQL command completed successfully.

Not surprisingly, it’s working like a SQL database should. We have a table, testtab, which we’ve inserted two rows into.

Finally, we’ll disconnect from the database and quit the CLP:

db2 => connect reset
DB20000I  The SQL command completed successfully.
db2 => quit
DB20000I  The QUIT command completed successfully.

Enabling Network Connectivity

That works great, but so far we’ve only accessed the instance locally. To allow connections from clients on other systems, we need to configure the instance to accept TCP/IP connections. This is an instance-level setting, so all of the databases you create in this instance will be available to remote clients.

The first step is to tell the instance what port to listen on. We’ll use 50,000. Note that svcename in the following command could also be the name of an entry in the /etc/inet/services file, which explains why the parameter is named svcename instead of something with the word “port.”

db2inst1@lab01v04$ db2 update dbm configuration using svcename 50000
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.
SQL1362W  One or more of the parameters submitted for immediate modification
were not changed dynamically. Client changes will not be effective until the
next time the application is started or the TERMINATE command has been issued.
Server changes will not be effective until the next DB2START command.

Next we need to enable TCP/IP as a communication protocol. This uses a new command, db2set:

db2inst1@lab01v04$ db2set DB2COMM=tcpip

Finally, restart the instance:

db2inst1@lab01v04$ db2stop
SQL1064N  DB2STOP processing was successful.
db2inst1@lab01v04$ db2start
SQL1063N  DB2START processing was successful.

How do we know if it worked? First, we’ll check to see if there’s something listening on port 50,000 on our system:

db2inst1@lab01v04$ netstat -an | grep 50000
      *.50000              *.*                0      0 49152      0 LISTEN

Looks good! netstat reports that a process is accepting connections on port 50000 on all interfaces. To really prove that we’re ready to start serving clients, though, we’ll test connectivity from another system.

Connecting From a Remote Client

We installed DB2 on lab01v04. Over on another machine, lab01v03, the DB2 client is installed. I’m logged in as mwilson, a user that the DB2 server knows nothing about, but I should be able to connect to DB2 as the db2inst1 user, which is the “superuser” or “root user” for the database.

The DB2 client software contains the same db2 command to launch the Command Line Processor. To connect to a remote server from a client, you first need to define the “node,” which represents the instance. Then you define the specific database within the instance. Once I have the database defined (cataloged in DB2 parlance), I can connect to it by name just like I did on the server, only I’ll add a username since I don’t have the benefit of being logged on locally to the server as an authorized user.

I’ll give you this one in one piece: starting the CLP, cataloging the node and database, then connecting and reading the data we inserted into the table earlier. All of this is happening from lab01v03, talking to the DB2 instance we created on lab01v04.

mwilson@lab01v03$ db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 9.5.1

You can issue database manager commands and SQL statements from the command
prompt. For example:
    db2 => connect to sample
    db2 => bind sample.bnd

For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
 ? CATALOG DATABASE for help on the CATALOG DATABASE command
 ? CATALOG          for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.

db2 => catalog tcpip node lab01v04 remote lab01v04 server 50000
DB20000I  The CATALOG TCPIP NODE command completed successfully.
DB21056W  Directory changes may not be effective until the directory cache is
refreshed.
db2 => catalog database mydb at node lab01v04
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the directory cache is
refreshed.
db2 => connect to mydb user db2inst1
Enter current password for db2inst1: ...password...

   Database Connection Information

 Database server        = DB2/SUNX8664 9.5.1
 SQL authorization ID   = DB2INST1
 Local database alias   = MYDB

db2 => select * from testtab

ID          NAME
----------- --------------------------------------------------
          1 First entry
          2 Second entry                                      

  2 record(s) selected.

db2 => connect reset
DB20000I  The SQL command completed successfully.
db2 => quit
DB20000I  The QUIT command completed successfully.

Wrapping Up

It worked! With really just a handful of commands, entirely from the command line, we’ve a) installed DB2, b) created an instance, c) created a database, d) enabled network client connectivity, and e) connected to our database from a remote client. If you’re familiar with doing the exact same thing using Oracle (please, no GUI installer or automatic bloated database creation with the Database Creation Assistant), you’ll appreciate just how much of a breeze this was with DB2, despite it being an equally “enterprise” database as Oracle. Maybe I’ll put together an article going through all of my Oracle installation and instance creation scripts for comparison.

In any case, the only thing we didn’t do is create the DB2 Administration Server (DAS), which allows remote management with the DB2 GUI utilities, but I don’t plan on needing that for now. If I did, it’s literally just a matter of creating a user to own the DAS and running the command dascrt -u DASuser.

There is one thing that I’m not satisfied with at this point, though: the instance uses the local system user accounts for authentication. That means, for example, that if I want a user, mwilson, in my database, I need to create a Unix account for mwilson. Luckily, DB2 ships with an LDAP authentication plugin. This will allow me to store user information in an LDAP directory and create as many users as I want without making any changes to the operating system hosting DB2. We’ll get that up and running, using OpenDS, in the next installment.