Subject RE: [firebird-support] UDF Meltdown
Author Edwin A Epstein, III
Thanks for the reply!

I am trying to get this to work on both Linux and Win32 environments. I am being very careful about the case, especially on Linux.

I know the "full" setting in firebird.conf is a bad idea. Setting it was a move of desperation more than anything. Previously I had been working with default of "Restrict UDF".

I keep ALL my UDF libraries in the UDF folder under the Firebird installation. On my win32 machine that is \FireBird_1_5\UDF and on Linux is /opt/firebird/UDF.

After every change in the firebird.conf I have shutdown the databases and restarted the firebird service. I have even gone so far as to restart the whole server.

On the Linux Server right now I am:

1) Running 2.1.0.17798-0.i686.
2) I have firebird installed at /opt/firebird. The UDF that I am using is FreeAdHocUDF_fb2x.so which is supposed to be compatible and tested.
3) The permissions on the UDF directory is firebird:firebird and the permissions on the file are firebird:firebird as well.
4) The firebird.conf file is set to default with Restrict UDF.
5) I have restarted the firebird service as well.

This is my declaration for the UDF function:

DECLARE EXTERNAL FUNCTION MD5SUM
CSTRING(16383)
RETURNS CSTRING(32) FREE_IT
ENTRY_POINT 'fn_md5sum' MODULE_NAME '/opt/firebird/UDF/FreeAdhocUDF_fb2x';

My declaration for the procedure is:

SET TERM ^^ ;
CREATE PROCEDURE P_TESTMD5 (
STR_INPUT VarChar(16383))
returns (
MD5HASH VarChar(32))
AS
begin
MD5HASH = MD5SUM(STR_INPUT);
SUSPEND;
end
^^
SET TERM ; ^^

When attempting to commit the transaction creating the procedure I get: ".. BLR Offset 49 function MD5SUM is not defined module name or entrypoint could not be found"

I have tried the MODULE_NAME with the full path, with and without the .so extension on the UDF.




-----Original Message-----
From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie
Sent: Monday, July 14, 2008 5:17 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] UDF Meltdown

At 08:17 AM 15/07/2008, you wrote:
>Hi All,
>
>A few years ago I developed a database in Firebird 1.5.5 and was using the rFunc UDF Library. No problems at all. It started out on a Windows 2000 Advanced Server and later migrated to a Red Hat Linux server. No problems with the migration, and rFunc has a linux compiled UDF.
>
>I am now developing a new database, and I am extremely behind. I first used the latest FirebirdSS 2.1.0.17798 32-bit on a recent CentOS installation. Installed the rFunc library as well as the FreeAdhocUDF libraries for Linux on it. It worked at first, but then shortly started giving me errors when I attempted to compile and commit the transaction to create my procedures. The standard BLR error which indicates it cannot find the module or entry point for my UDF.
>
>I never get errors when declaring the UDF functions. I only get the error when creating the procedures or running the old procedures.

That figures. At declaration time the module_name and entry_point arguments are stored but not checked - deliberately, since this would prevent the database from being portable.

On Linux, take care that the entry_point and module_name arguments AND any calls are case-correct. At both compile and execution time your PSQL modules must be able to find both the module and the entry point *as declared* - this is hard-wired into the BLR of the PSQL module. (which is a good reason NOT to configure UdfAccess as Full!)

>
>I have used three different version of FirebirdSS 2.x now on both Win32 and 32-bit and 64-bit Linux operating systems (CentOS, Red Hat Linux enterprise) and continually get the same errors when attempting to use the UDF functions. I have created all new databases from scratch with a single declared UDF function and a single stored procedure attempting to use that function.
>
>I have edited the Firebird.conf file to give everything “full” access

This is not a good idea as it requires you to provide the full local path to the UDF library in all declarations. Not only does this make your database totally specific to a single platform and host machine, it will also break existing compiled SPs that call the UDFs.

The "right" thing is to use the Restrict option and provide the paths to the UDF libraries. The default setting is 'Restrict UDF', which assumes that you used the Firebird convention for locating the libraries, i.e., in directory UDF beneath the Firebird root directory. Here 'UDF' is a relative path location.

If you have used a Linux distro that locates things differently from the Firebird convention then you will need to add these locations to the Restrict list the UDF path location. If the location is not within the firebird root then a full path is required, NOT a relative path.

Also check that the executables can be found. Some distros move shared objects out of the firebird root directory into "some other place", according to their own conventions, e.g. /usr/lib

> and have tried various different configurations for it as well.

Don't overlook the fact that configuration changes won't be seen by Superserver until after a server restart.

Ensure that (1) SS is running as user 'firebird' ; (2) you have a system user 'firebird' and a 'firebird' group and (3) that firebird:firebird has sufficient read and execute permissions on both the UdfAccess Restrict directories and the executable files within them.

In the declarations, make sure that the format of the library name is correct for the configured UdfAccess mode, e.g.
MODULE_NAME '/usr/local/lib/myfuncs' is wrong for Full (needs to be '/usr/local/lib/myfuncs.so'); while 'myfuncs.so' is wrong if the setting is Restrict (should be 'myfuncs'). There are quite a few permutations of "invalid"....

>
>I am at my wits end here and frankly have no idea why the UDF libraries refuse to work at all now. I just don’t get it.

Personally, I don't like to have to mess around with the default for UdfAccess. If you have to call UDFs then just put the SO's straight into $firebirdroot/UDF. If your Linux version insists on putting SO's somewhere else, then search them out and make symlinks in ../UDF for them.

As always, GET THE PERMISSIONS RIGHT.

./heLen

------------------------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !

Also search the knowledgebases at http://www.ibphoenix.com

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yahoo! Groups Links