Hi all.

 

 I have been trying to get Pervasive 9 or 10 to install on Fedora 9. I know, I know, some one is going to say that neither version has not been tested with Fedora 9. But the shares never really worked on Fedora 8, so I shelved the project until Fedora 9 came out. I am happy to announce that you can get the shares to work just like Windows in Fedora 9 if you follow some simple instructions. If anyone wants them, just ask. I don't want to annoy anyone by talking about Samba or posting other stuff, but it is really easy to do and seems to work flawlessly with Windows and Linux clients.

I tried installing Pervasive 10 beta, but there was a problem with the script and it returned errors. So I rebuilt the server and tried Pervasive 9.5, which did install under Fedora 8. There were so many script errors that I couldn't possibly list them all, even though rpm -qa|grep 'Pervasive' returns that Pervasive is installed. But since all the directories that the script should create do not get created, clearly this is not true. The user psql is created though, so some of it worked.

So I have two questions:

1. When will Pervasive 10 for Linux be released and will the scripts be written for Fedora 9?

2. Could some one point me at a how to that will instruct me on how to disassemble the rpm file so that maybe I could modify it or atleast understand what it is doing so that maybe  could kludge it to work?

As always, thank you in advance for anyone who will take the time to respond to my questions. And please, I am only a level noob +2, so assume I need clear instructions.

Thank you again.

Das Goat

I haven't checked the v10 beta on Linux yet, so I'll have to base my answer on v9 

Essentially the RPM version is exactly the same as the tarball version. All the RPM does is unpack and autorun the install script from /usr/local/psql/etc (is that /etc/psql now?). If anything fails you can always rerun the install script after making necesary changes.

Possible reason for folder operations to fail is that the target contains a symlink. For one this would prevent the script to set the correct owner on any such, possibly crucial, folder.

 Thanks Gordon.

 

So what you are saying is that I should be able to examine the TAR file and manually run each part of the script so that I can see what is failing? If this what you mean then I will research how to break out the TAR (unless you want to point me in the right directions).

Question: Since this is a community supported forum and I am working with the Linux version, am I correct in thinking that I can modify the TAR files any way I have to to make them work? And is there a review body that I should send my findings to? And, is there a Linux centric forum I should be checking out, or am I already in the right place?

 

Thank You again for your kind help.

 

Das Goat 

 

I just downloaded the new 10.10 RC2 and it appears to be all the same. There are just some minor changes in the install script that should probably cope better with variations in Init-V locations and it appears that the homedirectory for user psql is no longer set to $PVSW_ROOT/bin but uses the system default for home directories (I fail to see why that is).

Get the tarball and unpack in /usr/local. Move into /usr/local/psql/etc which should now exist. There are two shell scripts of interest for installation:
 - preinstall.sh performs some system checks to verify compatibility (should return "passed")
 - postinstall.sh performs the actual install

Most of the stuff you'd want to change is parameterized and declared at the top of the script. This includes the installation folder /usr/local/psql that you might want to change to /opt/psql on certain systems. Group name can be changed to an existing group that you've got mapped in Samba as the Windows Domain Users group.

Just stay away from symlinks in your installation path. Either change PVSW_ROOT to the physical path or use binds.

 Gordon, can you explain to me what the error at the end of the postinstall.sh output is?

 

[root@hercules etc]# sh postinstall.sh
+++++ Setting up pvsw group and admgroup...
Creating group pvsw...
An existing group pvsw-adm was found.

+++++ Setting up user psql...
Creating user psql
Creating mailbox file: File exists
Configuring user psql environment...
non-network local connections being added to access control list

+++++ Setting up symbolic links for libraries...
Making user psql owner of all files in /usr/local/psql...

+++++ Setting up entries in /etc/services...
The following line found in /etc/services:
btrieve 3351/tcp # Btrieve port btrieve 3351/udp # Btrieve port

+++++ Registering the PCOM libraries...
/usr/local/psql/bin/psregsvr: error while loading shared libraries: libuuid.so.1: cannot open shared object file: No such file or directory
ERROR: PCOM registration failed for libpseucjp.so.3.
[root@hercules etc]#

 

As always, thank you for your kind help.

Das Goat

 Ah, if I am understaning the script right, then there is a whole directory, $PVSW_ROOT/lib64/, that doesn't exist and therefore all those lib files it wants to register don't exist either.

(Hang on, my brain is actually expanding, I can feel it!)

So I searched the whole file system for a folder called lib64. I found several folders called that, one had a file that was a symbolic link to a file called  libpseucjp.so.3, I don't know if this is actually the file that the script is looking for or not (dso_register libpseucjp.so $PS_VER). Searching libpseucjp.so returned two instances of the same symbolic link, and two instances of a file called libpseucjp.so.3.10.014.000

(one fault with the search program in Fedora is that it doesn't tell me the path to the file it found, so I have no idea where these files are.)

So, if I had to hazzard a guess, there is something wrong with the pointer or the path.Remembering something Ann told me, I checked the script in the section covering the export options. Although I didn't get any errors from the script, the output from export does not seem to set the variables, which maybe why the scrip can not find the /lib64 folder. I am going to reboot, just to see if it makes a difference, and rerun postinstall.sh

 

 Nope, I got the same error. Please point me in the right direction.

 

Thanks

 

Das Goat

Hi there,

Sorry about the delay, I've been out catching up on my sunbathing and listening experience  

It appears that the PCOM message can only occur if the target file actually exists. The script module that performs this registration tries to locate the specified file in either lib or lib64 and there's no fall-through routine. Point of interest seems to be the message about the shared library file libuuid.so.1 which is called from the 32 bit psregsvr routine. According to my resources this file belongs to e2fsprogs which I'm guessing you've only got the 64 bit version installed.

Should be sufficient to install the e2fsprogs-libs-1.40.8-2.fc9 RPM

 I understand about getting away from it all, maybe one day I can too.

Gordon, you lost me. I don't understand what "Should be sufficient to install the e2fsprogs-libs-1.40.8-2.fc9 RPM" means. What do I need to do to get the script beyond this point? There seems to be many more steps the script wants to perform, but the script just stops.

I sure wish my vendor would help me, but I suspect that until I can prove to them that I can make the APP work, they are not going to do anything about supporting me. I have to atleast get back to the point where my Linux server would run Pervasive correctly and Windows clients could connect to it before they will get involved.

As always, thanks in advance Gordon.

What you need is the 32 bit version of libuuid.so.1 and this provided by the (Fedora 9) package I specified. 

 Thanks for clairifying that for me, Gordon.

It seems the package has dependancies of its own:

    ld64.so.1()(64bit) is needed by e2fsprogs-libs-1.40.8-2.fc9.ppc64
    ld64.so.1(GLIBC_2.3)(64bit) is needed by e2fsprogs-libs-1.40.8-2.fc9.ppc64
    libdl.so.2(GLIBC_2.3)(64bit) is needed by e2fsprogs-libs-1.40.8-2.fc9.ppc64

So I will do some research and get back with you. Installing packages in Fedora has never been as easy as Ubuntu, but I'm sure some one out there has posted a link for these issues.

Isn't there some kind of rundeps option? On SuSe I can use 'yast' to install a package and solve all its dependencies at the same time.

I'm actually wondering whether you're trying to install the correct version, since the message from the Pervasive installer is about libuuid.so.1, not libuuid.so.1()(64 bit). I'd suspect to solve this installer error you'd need to install the e2fsprogs-libs-1.40.8-2.fc9.i386 package but looking back I'm also wondering whether you actually need to have the 32 bit libraries registered if all you want is a 64 bit Pervasive engine.

Without anything like yast it's probably going to be a hell of a job to get all the required 32 bit libraries installed. I think you'd be fine if you try to skip that section in the installer and only leave the code for registering the 64 bit modules. This will most likely still require e2fsprogs-libs-1.40.8-2.fc9.ppc64 which I would have expected to be installed already as part of the full e2fsprogs.

 I'm searching for some kind of dependancy checker for Fedora 9. I'm not very encuraged because it has never been as easy to install add ons with Fedora as it is with something like Ubuntu.

I download and tried to install both e2fsprogs-libs-1.40.8-2.fc9.ppc64 and e2fsprogs-libs-1.40.8-3.fc9.ppc64, but both failed the same way. I'm not the best at this, but if I am understanding all this correctly, what I'm reading is that these packages are Java language extentions of some sort. Mostly I get directed to the Iced Tea project which works to implement these extentions on Fedora. However, Fedora 9 ditched Iced Tea in favor of OpenJDK.My guess is that something got missed, and the way Fedora adds / removes programs is just not very robust.

Which brings up another approach to solving my problems that you might give some input. I'm not tied to Fedora, I just started using it because the Pervasive package was available as RPMs. Path of least resistance, as it were.  I see you use SuSe. Have you been able to get Pervasive 10 up and running on SuSe? Is Pervasive 10 intended for a particular flavor of linux? Is it even created to run on 64 bit systems? Myabe I am barking up the wrong tree here. I don't care what the server runs as long as it is Linux. I hope that SuSe server has the ability to load a GUI interface like Fedora because I tend to get lost and bogged down doing simple tasks without the GUI, but if that is the price I have to pay to get this working, I can learn.

 

As always, thank you in advance for your kind help Gordon.

Pervasive PSQL was originally targeted towards RedHat Linux but should not have any trouble running on other distributions as long as the minimum specifications are met, specifically kernel and glibc versions. I believe the current releases of Pervasive PSQL server (9.5 and 10.10) will install on SuSE without the need for file system tweaks but if you're on any other distribution like Debian or Gentoo you're definitely going to need to make some changes to the install script.

Except for version 10.x all Pervasive PSQL engines are 32 bit and will require compatibility libraries if you're on a 64 bit operating system. On desktop and developer systems this will probably not be much of a problem but servers are a complete different ball game.

So you might try installing the 10.10 "Core" version which should only include 64 bit components (it appears the utilities are still 32 bit). If it still fails with a missing library message you could try reinstalling the server but then change the disk partitioning to include an ext2 or ext3 volume. In theory this should force the installer to include the e2fs tools for maintaining these kind of filesystems and thus give you the required libraries for installing Pervasive PSQL.

Another option is to install everything in 32 bit versions, i.e. the Linux OS also. Obviously this limits the systems address space to 4Gb which is really not much of an issue for typical environments.

I'm sorry. I currently do not have a 64 bit machine available for testing any of these options. I know the last option works because we have this in our production environment (apparently a smart decision). All the other stuff is just calculated guesses.

 Well Fudge! Maybe that has been my problem all along, because I don't see anyone else having the same kind of trouble. Seems like a waste of a 64x2 RAID system, but I will try 32bit. Actually, I don't think the 32bit version will load on this server or the one at work I want to use for the same reason. Sigh.

Well, let me try putting all of this on an old 32 PC and see what happens. Do you think I should back up to Pervasive 9.5 as it is more stable?