So this is a howto about installing pervasive sql 8.7 to a fedora core 5 server.  I've been testing this but have yet to use it in production.  Just thought I'd share my installation steps with other people and maybe start getting some feedback...
 
I started with basic fedora core 5 installation.  Psql needs Samba server, but as far as I could tell fedora core 5 installs that by default.  I also installed KDE, but thats probably not necessary.  I mainly installed it so that after the first reboot I could easily turn off SELinux and the firewall.  If you want to use those than there are other issues to be dealt with that I won't touch on here.
 
Without further ado, download the Pervasive Psql8 update from pervasive, fire up a shell, and extract it:
 
$ tar zxf Pervasive.SQL_8.70_Server_Linux.tar.gz
$ cd Pervasive.SQL_8.70_Server_Linux  
$ tar zxf Pervasive.SQL-8.70-014.000.i486.tar.gz
 
login as root
$ su
 
copy the extracted psql dir to usr/local
# cd /usr/local
# cp -r /home/user/Pervasive.SQL_8.70_Server_Linux/psql ./ (note: no trailing slash on psql)
# cd psql/etc/
 
postinstall.sh uses useradd, but fedora uses the function adduser, so edit postinstall.sh and change useradd to adduser.
# vi ./postinstall.sh
 
Here is the section of postinstall.sh to edit ->
 
postinstall.sh :

       # we need to verify if the adduser call succeeded because on certain flavors of linux the system
       # takes a while to realize that a newely added group is really a group. To allow for this we keep
       # retrying the adduser call with 2 second sleeps in between for no longer then 20 seconds.
 
       echo Creating user $USERNAME, this may take a while...
       for var in var0 var1 var2 var3 var4 var5 var6 var7 var8 var9
       do
               USERADDCHECK=`/usr/sbin/useradd -c "Pervasive daemon" -d $PVSW_ROOT/bin -g $GROUPNAME -s $USERSHL $USERNAME 2>&1`
               if [ "X$USERADDCHECK" = "X" ] ; then
                       break
               fi
               if [ "$USERADDCHECK" = "/etc/login.defs not accessible, using defaults." ] ; then
                       break
               fi
               # warn that a failure occured
               if [ "X$var" = "Xvar9" ] ; then
 
change that useradd to adduser
 
         USERADDCHECK=`/usr/sbin/adduser -c "Pervasive daemon" -d $PVSW_ROOT/bin -g
 
then run postinstall.sh
# ./postinstall.sh
 
It should start the psql services so check them:
 
[root@localhost etc]# ps -A | grep mkded
 3311 ?        00:00:00 mkded
[root@localhost etc]# ps -A | grep sqlmgr
 3345 ?        00:00:00 sqlmgr
 3376 ?        00:00:00 sqlmgr
 
[root@localhost etc]# /sbin/service psql status
Status Pervasive services:
mkded (pid 3311) is running...
sqlmgr (pid 3376 3345) is running...
 
the pervasive installation will update smb.conf.  If samba is not already started, then make sure it starts at boot:
[root@localhost etc]# /sbin/chkconfig smb on
 
and also start it now:
[root@localhost etc]# /sbin/service smb start
Starting SMB services:                                     [  OK  ]
Starting NMB services:                                     [  OK  ]
 
then, to access the pervasive share you'll need a samba user with appropriate rights.  I just use the psql user(which may be a bad idea, but it can't be much worse than giving full rights to the share on a windows server).
 
First I set the unix password for the psql user:
 
# passwd psql
 
add the user to samba and set the password
 
# smbpasswd -a psql
 
add the user to pervasive (change password)
 
# /usr/local/psql/bin/btadmin -p password a+ psql
 
make a directory to contain the dba files within the psql data samba share
 
# cd /usr/local/psql/data
# mkdir DBAMFG
 
i needed to mount the windows share containing my current dbamfg folder so that i could copy the files  
 
# mkdir /mnt/dba
# mount -t cifs //server_ip_address/dbamfg /mnt/dba -o user=windows_user_with_rights
 
Copy the files to the newly created psql/data/DBAMFG dir
 
# cp -r /mnt/dba/* ./DBAMFG/
 
Change the owner of the DBAMFG folder
 
chown -R psql:pvsw DBAMFG/
 
Thats it for server installation.  To test the new installation, map the psqldata samba share on a workstation and run workstation setup in the DBAMFG folder (and install pervasive if you need).
 
Now for ODBC.
 
Note: I was never able to create a ODBC connection to the root DBA directory, so my solution was to create a separate ODBC connection for each company (luckily we are only using one company... ).  Also note that this changes the table names in SQL queries e.g. BKARINV and not BKARINV_B.
 
Log in as the psql user:
 
# su psql
 
run dbmaint to add the named database to pervasive:
 
 $ /usr/local/psql/bin/dbmaint a -nDBA -l /usr/local/psql/data/DBAMFG/Default/ -d /usr/local/psql/data/DBAMFG/Default/ -sClassic -e
 
add an entry to the odbc.ini file:
$ /usr/local/psql/bin/dsnadd -dsn=DBA -db=DBA
 
return to the root user
 
$ exit
 
add a symlink to odbc.ini in /etc (but first remove the empty odbc.ini)
 
# cd /etc
# rm odbc.ini
# ln -s /usr/local/psql/etc/odbc.ini
 
On the client I created a system dsn using the Pervasive client driver.  I'm not entirely positive this was necessary, however.  I was then able to go in to pervasive control center and add the server by ip address and start browsing DBA tables, confirming ODBC connectivity.

Do you mean, why run it on FC5 rather than NT4?   ???
 
Personal preference I guess.  I really want to run DBA on another server rather than on my master domain controller (windows 2003).  I don't want to buy more windows server licenses, and I feel comfortable (prefer) administering linux.  Right now I'm comparing the performance of the two however and that will play into my decision as well.
 
If you don't have your own reasons to try it then definitly I would suggest not trying it.  However if you do, maybe you could share your experiences with us .
 

 
Julian

just a side note on ODBC connections.  
 
the DDF's in the Root Directory of DBAMFG are NOT ODBC compliant. which is why the utility was created to generate a set of DDF's for each seperate company, such that the DDF's ARE in the company Data directory.
 
the DDF's in the Root are for use by the DBA Maintain Database program.

This is very interesting, for a linux fanatic as I am anyways.
 
The next step will be try to run DBA on linux using someting like wine HQ.
 
Regards,
 
Kelloggs

Hi,
Has anyone had any luck getting the dba workstation client software to run on a linux box (Ubuntu 7.04). I have tried wineHQ and both the pervasive client and dba workstation install fine, but when I run dba it says that there was an error trying to load Btrieve.  Error 3012
 
It seems like it would work if I could get past this.
 
Thanks for any / all replies.
 
-Matt

Well, I just tried loading up the EvoERP demo on my laptop to see what WINE would do. It doesn't work. More specifically, nearly all programs BUT Evo work. The btrieve DB manager comes up, I can run the setup programs, I can run the report editor but it tells me to try running it from Evo instead of directly. But Evo and T7Runtime.exe both crash WINE with a segfault in KERNEL32. It seems they'd like to access memory at address 0. That doesn't work so well. I'm not really sure why they are crashing but other programs work fine...