on 2020 Apr 14 1:34 PM
I'm running PHP 7.2 on Linux (Ubuntu 18.04) with SA 17.0.9.4935 and things are working fine.
If I upgrade SA17 to version SA 17.0.10.5923, the PHP 7.2 extension module fails with a Bad Gateway 402 error.
I've tried it with SA17 versions as far back as SA 17.0.10.5745 and they all fail with the 402 error.
The Linux PHP extension module is SQLAnywhere-php-7.2_Linux.tar.gz with SHA-1: e1a6a9e133075bd9bea2d411a327cf5c2e6d61fb
Is anyone running SA 17.0.10.xxxx successfully with PHP 7.2 on Linux?
############# UPDATE ############
I've now run this using the CLI, which should make it easier to reproduce. Here is an example:
<?php
$cstring = "UID=DBA;PWD=*****;Server=newsatlasCN;DBN=newsatlassup;CS=UTF8";
$conn = sasql_connect( $cstring );
$payload = new stdClass();
if( $conn ) {
$payload->meta = new stdClass();
$payload->rows = array();
$rs = sasql_query( $conn, "SELECT * FROM SYS.SYSCATALOG WHERE creator='SYS' AND tname='ISYSUSER'" );
if( $rs ) {
while( $row = sasql_fetch_assoc( $rs ) ) {
$payload->rows[] = $row;
}
sasql_free_result( $rs );
}
header( "HTTP/1.1 200 OK" );
header( "Content-Type: application/json; charset=utf-8;" );
print json_encode( $payload ) . "\\n";
sasql_disconnect( $conn );
}
?>
On SA 17.0.9.4935 and PHP 7.2.24-0ubuntu0.18.04.4 (cli), it runs properly with the expected output:
{"meta":{},"rows":[{"creator":"SYS","tname":"ISYSUSER","dbspacename":"system","tabletype":"TABLE","ncols":13,"primary_key":"Y","check":null,"remarks":null}]}
But on SA 17.0.10.5923, it crashes with the message:
PHP Warning: request_startup() for sqlanywhere module failed in Unknown on line 0
It seems to be failing in the call to the PHP extension module which, as noted above, is is SQLAnywhere-php-7.2_Linux.tar.gz with SHA-1: e1a6a9e133075bd9bea2d411a327cf5c2e6d61fb
Any ideas?
Request clarification before answering.
As Volker noted, the file search algorithm was tamed in 17.0.10 to address security issues (spoofed DLLs/shared objects). It is key that the customary SQLA install structure be maintained (bin64, lib64, res, etc hanging off the install root), that SQLANY17 point to the install root, and for OS static loading that LD_LIBRARY_PATH include the path to lib64, and that PATH include any directories where dynamically loaded executable programs are to be found. A message like this one, Missing or invalid encryption DLL "libsapcrypto.so", suggests something is off in the SQLANY17 setting.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I was beginning to suspect it was related to SQLANY17. I have LD_LIBRARY_PATH set correctly, but not SQLANY17.
I've now added a definition for SQLANY17 to the php-cgi configuration and it seems to be working. i.e., the config file /etc/php/7.2/fpm/pool.d/www.conf
now has both lines
env[SQLANY17]=/opt/sqlanywhere17
env[LD_LIBRARY_PATH]=/opt/sqlanywhere17/lib64
Thanks. If you want to create an 'Answer', I can mark it correct.
All the files in bin32/64 and lib32/64 have new dates that match the installation date, my application (PHP) is working fine, and I haven't had to make copies anywhere else, so I think all is well.
User | Count |
---|---|
47 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.