mardi 3 février 2015

DB2 Express on Linux

I have been trying for about 30 hours to get DB2 Express running on an AWS Linux Ubuntu instance. I have it running on my Macbook well, and am able to do work there, but would like to use this in a true server.


I have uninstalled and reinstalled several times and keep running into the same problem:


Here is a general history of what I have done:



source /home/db2instl/sqllib/db2profile

./db2icrt db2instl

sudo -i -u db2instl /home/db2instl/sqllib/adm/db2start

~/sqllib/adm$ ./db2start

SQL1063N DB2START processing was successful.


When running python connectivity code using SQL Alchemy I get this:



sqlalchemy.exc.OperationalError: (OperationalError) ibm_db_dbi::OperationalError: [IBM][CLI Driver] SQL1639N
The database server was unable to perform authentication because security
related database manager files on the server do not have the required
operating system permissions.
SQLSTATE=08001 SQLCODE=-1639 None None


According to the IBM knowledgecenter:


http://ift.tt/1DCCzit


One must execute db2rfe in order get past this.


Reading the instructions there, db2rfe should be executed as root after manipulating the configuration file in a certain way.


I change ENABLE_OS_AUTHENTICATION to YES:


ENABLE_OS_AUTHENTICATION=YES


After successfully executing:



sudo ./db2rfe -f db2rfe.cfg


I attempt to run looking at this:


http://ift.tt/1DCCBqA


I execute:



sudo -i -u db2instl /home/db2instl/sqllib/adm/db2start

Which gives me this error:

SQL1641N The db2start command failed because one or more DB2 database
manager program files was prevented from executing with root privileges
by file system mount settings.


This is an AWS Ubuntu instance:



~/sqllib$ mount

/dev/xvda1 on / type ext4 (rw,discard)

proc on /proc type proc (rw,noexec,nosuid,nodev)

sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)

none on /sys/fs/cgroup type tmpfs (rw)

none on /sys/fs/fuse/connections type fusectl (rw)

none on /sys/kernel/debug type debugfs (rw)

none on /sys/kernel/security type securityfs (rw)

udev on /dev type devtmpfs (rw,mode=0755)

devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)

tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)

none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)

none on /run/shm type tmpfs (rw,nosuid,nodev)

none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)

none on /sys/fs/pstore type pstore (rw)

/dev/xvdb on /mnt type ext3 (rw)

systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)


So, as the other questioner posted, / is not mounted in "nosuid" mode. However, I am NOT doing a Root install, as the answerer to one of the questions said above.


This computer is an AWS Ubuntu 12.04 install:



lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 14.04.1 LTS

Release: 14.04

Codename: trusty


Additional Notes:


I had to change the hashing algorithm on this machine to use 256 bytes because of the weird DB2 length limitation. I've gotten past a lot of hurdles and this appears to be the last step.


I CAN change the permission on db2start to seeming get past this problem and make it owned by root, but then it says I am not allowed to run as root.


Here is an attempt to rephrase my catch-22 informally:


I cannot enable OS Authentication without running db2rfe. When I run db2rfe, to enable OS Authentication,


I can't restart the server because of a permissions problem, but the error message does not seem to match the condition.


Note that I would be happy to use client-side authentication or any other kind of authentication in this case -- this is not production code, is something being set up purely as a demonstration.


Any help you can provide would be greatly appreciated.





Aucun commentaire:

Enregistrer un commentaire