Re: Advice on adding com2 to (amd64) GENERIC; enabling easier IPMI SOL with SuperMicro boards
On Sat, Mar 30, 2013 at 02:06, Rogier Krieger wrote: The GENERIC kernel config has commented out com2 (at isa0, addr 0x3e8, irq 5) and I assume this is not without reason. I've been unable to find that reason in source changes, but perhaps someone here knows. On i386, it is present. I am guessing this is an oversight. i386 runs on the same machines, so if com2 were causing trouble it would be disabled there too.
OpenBSD as NAS
I will defintly try the vnode and buffercache parameters for these are totally new to me
Variation on PHP in chroot problem: SQLite3::loadExtension()
I think I've done my homework, but apparently the answer eludes me
despite my best intentions to find an answer on my own. So, I throw
myself on the mercy of misc and pray I am not mauled too badly. :-)
I am running 5.3-current (3/22/2013 snapshot), Nginx as http server, and
PHP and PHP-FPM 5.3.22 from packages. I am trying to connect to a
Sqlite3 database with an extension (libspatialite-4.0.0, built from
ports). Connecting to a Sqlite3 database from PHP *without* an extension
works just fine. The trouble arises when I attempt to throw
libspatialite into the mix.
Here is the error:
2013/03/30 11:43:39 [error] 19127#0: *1110 FastCGI sent in stderr:
PHP message: PHP Warning: SQLite3::loadExtension(): Cannot load
specified object in /htdocs/foo/test.php on line 10
Here is the relevant PHP code:
?php
class MyDB extends SQLite3
{
function __construct()
{
$this-open('test.sqlite');
}
}
$db = new MyDB();
$db-loadExtension('libspatialite.so.0.0');
I am assuming that PHP is finding the libspatialite library, since when
I change the file name in the loadExtension() function call to an
intentionally bogus name, I get a different error, like this:
2013/03/30 11:23:16 [error] 19127#0: *1104 FastCGI sent in stderr:
PHP message: PHP Warning: SQLite3::loadExtension(): Unable to load
extension at 'lib/foo.so.0.0' in /htdocs/foo/test.php on line 10
So, my next thought is it must be a library dependency. So, I run ldd:
lib $ldd /var/www/lib/libspatialite.so.0.0
/var/www/lib/libspatialite.so.0.0:
StartEnd Type Open Ref GrpRef Name
0f20 2f369000 dlib 10 0 /var/www/lib/libspatialite.so.0.0
059fb000 25a0 rlib 03 0 /usr/lib/libpthread.so.17.0
09306000 2930a000 rlib 01 0 /usr/local/lib/libfreexl.so.0.0
04971000 24a51000 rlib 02 0 /usr/local/lib/libiconv.so.6.0
0a9a1000 2a9ab000 rlib 01 0 /usr/local/lib/libproj.so.6.0
03eea000 23ef8000 rlib 01 0 /usr/lib/libsqlite3.so.22.0
0d078000 2d082000 rlib 01 0 /usr/local/lib/libgeos_c.so.4.0
062ba000 262fc000 rlib 02 0 /usr/local/lib/libgeos.so.7.1
00889000 208b7000 rlib 03 0 /usr/lib/libstdc++.so.55.0
0a42e000 2a437000 rlib 05 0 /usr/lib/libm.so.7.1
So I copy all of these libraries into the paths specified by ldd, taking
the chroot into account. Here is where the libraries ended up:
lib $ls -al /var/www/lib/
total 8524
rwxr-xr-x 2 root users 512 Mar 30 10:23 .
drwxr-xr-x 16 root daemon 512 Mar 22 11:28 ..
-rw-r--r-- 1 root bin 923 Mar 22 18:10 libspatialite.la
-rw-r--r-- 1 root bin 4339888 Mar 22 18:10 libspatialite.so.0.0
lib $ls -al /var/www/usr/lib/
total 11148
drwxr-xr-x 2 root users 512 Mar 30 10:23 .
drwxr-xr-x 5 root users 512 Mar 30 10:21 ..
-r--r--r-- 1 root bin 457102 Mar 22 11:29 libm.so.7.1
-r--r--r-- 1 root bin 163854 Mar 22 11:29 libpthread.so.17.0
-r--r--r-- 1 root bin2504122 Feb 7 18:30 libsqlite3.so.21.0
-r--r--r-- 1 root bin2518224 Mar 22 11:29 libsqlite3.so.22.0
lib $ls -al /var/www/usr/local/lib/
total 7088
drwxr-xr-x 2 root users 512 Mar 30 10:22 .
drwxr-xr-x 3 root users 512 Mar 30 10:21 ..
-rw-r--r-- 1 root bin 37910 Mar 27 23:37 libfreexl.so.0.0
-rw-r--r-- 1 root bin2011553 Mar 22 18:08 libgeos.so.7.1
-rw-r--r-- 1 root bin 177649 Mar 22 18:08 libgeos_c.so.4.0
-rwxr-xr-x 1 root wheel 1056690 Feb 7 06:38 libiconv.so.6.0
-rw-r--r-- 1 root bin 270455 Mar 22 13:51 libproj.so.6.0
However, still no joy. I've also tried placing all of the libraries in
/var/www/lib alongside the libspatialite library, but that did not work
either.
I am at a loss trying to figure out what other specified object that
PHP is unable to load. If anyone can provide any clues as to how I can
track this down, I would be most grateful.
Many thanks in advance.
Re: Variation on PHP in chroot problem: SQLite3::loadExtension()
On 3/30/2013 1:12 PM, Scott Vanderbilt wrote:
I think I've done my homework, but apparently the answer eludes me
despite my best intentions to find an answer on my own. So, I throw
myself on the mercy of misc and pray I am not mauled too badly. :-)
I am running 5.3-current (3/22/2013 snapshot), Nginx as http server,
and PHP and PHP-FPM 5.3.22 from packages. I am trying to connect to a
Sqlite3 database with an extension (libspatialite-4.0.0, built from
ports). Connecting to a Sqlite3 database from PHP *without* an
extension works just fine. The trouble arises when I attempt to throw
libspatialite into the mix.
Here is the error:
2013/03/30 11:43:39 [error] 19127#0: *1110 FastCGI sent in stderr:
PHP message: PHP Warning: SQLite3::loadExtension(): Cannot load
specified object in /htdocs/foo/test.php on line 10
Here is the relevant PHP code:
?php
class MyDB extends SQLite3
{
function __construct()
{
$this-open('test.sqlite');
}
}
$db = new MyDB();
$db-loadExtension('libspatialite.so.0.0');
I am assuming that PHP is finding the libspatialite library, since
when I change the file name in the loadExtension() function call to an
intentionally bogus name, I get a different error, like this:
2013/03/30 11:23:16 [error] 19127#0: *1104 FastCGI sent in stderr:
PHP message: PHP Warning: SQLite3::loadExtension(): Unable to load
extension at 'lib/foo.so.0.0' in /htdocs/foo/test.php on line 10
So, my next thought is it must be a library dependency. So, I run ldd:
lib $ldd /var/www/lib/libspatialite.so.0.0
/var/www/lib/libspatialite.so.0.0:
StartEnd Type Open Ref GrpRef Name
0f20 2f369000 dlib 10 0 /var/www/lib/libspatialite.so.0.0
059fb000 25a0 rlib 03 0 /usr/lib/libpthread.so.17.0
09306000 2930a000 rlib 01 0 /usr/local/lib/libfreexl.so.0.0
04971000 24a51000 rlib 02 0 /usr/local/lib/libiconv.so.6.0
0a9a1000 2a9ab000 rlib 01 0 /usr/local/lib/libproj.so.6.0
03eea000 23ef8000 rlib 01 0 /usr/lib/libsqlite3.so.22.0
0d078000 2d082000 rlib 01 0 /usr/local/lib/libgeos_c.so.4.0
062ba000 262fc000 rlib 02 0 /usr/local/lib/libgeos.so.7.1
00889000 208b7000 rlib 03 0 /usr/lib/libstdc++.so.55.0
0a42e000 2a437000 rlib 05 0 /usr/lib/libm.so.7.1
So I copy all of these libraries into the paths specified by ldd,
taking the chroot into account. Here is where the libraries ended up:
lib $ls -al /var/www/lib/
total 8524
rwxr-xr-x 2 root users 512 Mar 30 10:23 .
drwxr-xr-x 16 root daemon 512 Mar 22 11:28 ..
-rw-r--r-- 1 root bin 923 Mar 22 18:10 libspatialite.la
-rw-r--r-- 1 root bin 4339888 Mar 22 18:10 libspatialite.so.0.0
lib $ls -al /var/www/usr/lib/
total 11148
drwxr-xr-x 2 root users 512 Mar 30 10:23 .
drwxr-xr-x 5 root users 512 Mar 30 10:21 ..
-r--r--r-- 1 root bin 457102 Mar 22 11:29 libm.so.7.1
-r--r--r-- 1 root bin 163854 Mar 22 11:29 libpthread.so.17.0
-r--r--r-- 1 root bin2504122 Feb 7 18:30 libsqlite3.so.21.0
-r--r--r-- 1 root bin2518224 Mar 22 11:29 libsqlite3.so.22.0
lib $ls -al /var/www/usr/local/lib/
total 7088
drwxr-xr-x 2 root users 512 Mar 30 10:22 .
drwxr-xr-x 3 root users 512 Mar 30 10:21 ..
-rw-r--r-- 1 root bin 37910 Mar 27 23:37 libfreexl.so.0.0
-rw-r--r-- 1 root bin2011553 Mar 22 18:08 libgeos.so.7.1
-rw-r--r-- 1 root bin 177649 Mar 22 18:08 libgeos_c.so.4.0
-rwxr-xr-x 1 root wheel 1056690 Feb 7 06:38 libiconv.so.6.0
-rw-r--r-- 1 root bin 270455 Mar 22 13:51 libproj.so.6.0
However, still no joy. I've also tried placing all of the libraries in
/var/www/lib alongside the libspatialite library, but that did not
work either.
I am at a loss trying to figure out what other specified object that
PHP is unable to load. If anyone can provide any clues as to how I can
track this down, I would be most grateful.
Many thanks in advance.
Hi,
I've never run into this specific problem, but perhaps ldconfig is
required in the chroot?
man ldconfig
Or perhaps copy in /var/run/ld.so.hints?
Cheers,
Steve
