Re: no SASL backend available out of: gsasl

2013-10-25 Thread Tomasz Sterna
Dnia 2013-10-25, pią o godzinie 12:24 +0100, Niamh Holding pisze:
 ./conftest: error while loading shared libraries: libgsasl.so.7: cannot open 
 shared object file: No such file or directory
 But
  ll /usr/local/lib/libgsasl.so.7


/usr/local/lib is not standard library directory.

$ ./configure --help
[...]
  --with-extra-library-path
  use additional library paths (remember to update
  /etc/ld.so.conf too)
[...]


Try:
./configure --with-extra-library-path=/usr/local/lib



-- 
Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/





Re: no SASL backend available out of: gsasl

2013-10-25 Thread Marcin Mirosław
W dniu 25.10.2013 14:08, Tomasz Sterna pisze:
 Dnia 2013-10-25, pią o godzinie 12:24 +0100, Niamh Holding pisze:
 ./conftest: error while loading shared libraries: libgsasl.so.7: cannot open 
 shared object file: No such file or directory
 But
  ll /usr/local/lib/libgsasl.so.7
 
 
 /usr/local/lib is not standard library directory.
Hi!
On *BSD it is standard library directory. Man hier also says:
   /usr/local/lib
  Files associated with locally installed programs

Regards,
Marcin




Re: no SASL backend available out of: gsasl

2013-10-25 Thread Eric Koldeweij

Niamh

Having no further information, it looks to me that you might have a too 
old version of gsasl...


 checking for gsasl_check_version in -lgsasl... yes

This line says it can find gsasl and its library.

 checking for GnuSASL version= 0.2.27... no

This line says it fails the version check. Do you have GSASL 0.2.27 or 
later installed? What does config.log say about it?


Regards,
Eric.


On 10/25/13 15:10, Niamh Holding wrote:


Hello Tomasz,

Friday, October 25, 2013, 1:08:38 PM, you wrote:

TS  Try:
TS  ./configure --with-extra-library-path=/usr/local/lib


Makes no difference

checking for gsasl.h... yes
checking for gsasl_check_version in -lgsasl... yes
checking for GnuSASL version= 0.2.27... no
configure: error: no SASL backend available out of: gsasl

../conftest: error while loading shared libraries: libgsasl.so.7: cannot open 
shared object file: No such file or directory









Re: no SASL backend available out of: gsasl

2013-10-25 Thread D'Arcy J.M. Cain
On Fri, 25 Oct 2013 14:17:03 +0200
Marcin Mirosław mar...@mejor.pl wrote:
 W dniu 25.10.2013 14:08, Tomasz Sterna pisze:
  Dnia 2013-10-25, pią o godzinie 12:24 +0100, Niamh Holding pisze:
  ./conftest: error while loading shared libraries: libgsasl.so.7:
  cannot open shared object file: No such file or directory But
   ll /usr/local/lib/libgsasl.so.7
  
  
  /usr/local/lib is not standard library directory.
 Hi!
 On *BSD it is standard library directory. Man hier also says:

Which BSD?  It is standard on FreeBSD but not NetBSD for example.

Why not use the packaging facility on your system?

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net




Re: no SASL backend available out of: gsasl

2013-10-25 Thread Tomasz Sterna
Dnia 2013-10-25, pią o godzinie 15:12 +0100, Niamh Holding pisze:
 EK What does config.log say about it?
 
 As the rooot message said-
 
 ./conftest: error while loading shared libraries: libgsasl.so.7:
 cannot open shared object file: No such file or directory

How did the test compilation line looked like?

i.e.
$ grep 'checking for GnuSASL version' -A1 config.log 
configure:15860: checking for GnuSASL version = 0.2.27
configure:15879: gcc -o conftest -Wall -Wno-pointer-sign -g -g -O2 
-funsigned-char   conftest.c -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt  
-ldl 5






Re: no SASL backend available out of: gsasl

2013-10-25 Thread Eric Koldeweij

Niamh,

Is it possible that the library in /usr/local/lib incompatible is with 
your build?

For instance a 32-bit library on a 64-bit system?

Regards,
Eric.

On 10/25/13 16:12, Niamh Holding wrote:


Hello Eric,

Friday, October 25, 2013, 2:32:53 PM, you wrote:

EK  Having no further information, it looks to me that you might have a too
EK  old version of gsasl...

  gsasl --version
gsasl (GNU SASL) 1.8.0
Copyright (C) 2012 Simon Josefsson.
License GPLv3+: GNU GPL version 3 or laterhttp://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Simon Josefsson.

EK  What does config.log say about it?

As the rooot message said-

../conftest: error while loading shared libraries: libgsasl.so.7: cannot open 
shared object file: No such file or directory







Re: no SASL backend available out of: gsasl

2013-10-25 Thread Niamh Holding
 
Hello Tomasz,

Friday, October 25, 2013, 3:48:23 PM, you wrote:

TS How did the test compilation line looked like?

configure:15716: checking gsasl.h usability
configure:15716: checking gsasl.h presence
configure:15716: checking for gsasl.h
configure:15727: checking for gsasl_check_version in -lgsasl
configure:15752: gcc -o conftest -g -O2 -funsigned-char  -L/usr/local/lib 
-L/usr/lib  conftest.c -lgsasl  -ludns -lidn -lexpat -lresolv -lcrypt  -ldl 5
configure:15793: gcc -o conftest -g -O2 -funsigned-char  -L/usr/local/lib 
-L/usr/lib  conftest.c -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt  -ldl 5
./conftest: error while loading shared libraries: libgsasl.so.7: cannot open 
shared object file: No such file or directory

-- 
Best regards,
 Niamhmailto:ni...@fullbore.co.uk





Re: no SASL backend available out of: gsasl

2013-10-25 Thread Niamh Holding
 
Hello Eric,

Friday, October 25, 2013, 3:56:25 PM, you wrote:

EK Is it possible that the library in /usr/local/lib incompatible is with
EK your build?
EK For instance a 32-bit library on a 64-bit system?

It's possible, I installed
ftp://ftp.gnu.org/gnu/gsasl/gsasl-1.8.0.tar.gz
ftp://ftp.gnu.org/gnu/gsasl/libgsasl-1.8.0.tar.gz

On to CentOS 6.4 64 bit.



-- 
Best regards,
 Niamhmailto:ni...@fullbore.co.uk





Re: no SASL backend available out of: gsasl

2013-10-25 Thread Tomasz Sterna
Dnia 2013-10-25, pią o godzinie 16:39 +0100, Niamh Holding pisze:
 configure:15793: gcc -o conftest -g -O2 -funsigned-char
 -L/usr/local/lib -L/usr/lib  conftest.c -lgsasl -ludns -lidn -lexpat
 -lresolv -lcrypt  -ldl 5
 ./conftest: error while loading shared libraries: libgsasl.so.7:
 cannot open shared object file: No such file or directory

Is your dynamic linker configured to look for dynamic libraries
in /usr/local/lib ?   ( /etc/ld.so.conf )



-- 
Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/





Re: no SASL backend available out of: gsasl

2013-10-25 Thread Tomasz Sterna
Dnia 2013-10-25, pią o godzinie 18:55 +0100, Niamh Holding pisze:
  cat /etc/ld.so.conf
 include ld.so.conf.d/*.con
 /usr/local/libf
 
 But correcting it made no difference

After editing /etc/ld.so.conf you need to run ldconfig (as root) to
generate /etc/ld.so.cache



-- 
Tomasz Sterna:(){ :|:};:
Instant Messaging ConsultantOpen Source Developer 
http://abadcafe.pl/   http://www.xiaoka.com/portfolio





sm/router: XML parser error

2013-10-25 Thread Justin T Pryzby
We have a jabberd2 installation with LDAP client authentication, and
roster published from active directory ldap.  Our jabber service has
stopped working a few times in the last few weeks in the middle of the
day; clients (pidgin) are disconnected, and can't reconnect (or only
partially reconnect, not sure). 

Up until today, I was able to resolve the problem by restarting the
nonfunctional (but running) sm component.  This morning, however, I
started getting these:

router:
Thu Oct 24 10:04:41 2013 [notice] [127.0.0.1, port=48998] error: XML
parse error (not well-formed (invalid token))
sm:
Fri Oct 25 11:45:48 2013 [notice] error from router: XML parse error
(junk after document element)

That could be related to bad data in AD, but I don't believe any users
were changed by anyone but myself, and don't see anything wrong.

In the process of trying to figure out if it was a jabber bug or a
data error, I ran under valgrind, which detected (I believe) a buffer
over/under run in sx_can_read.  That was a stripped binary, so no
other details.

I'm trying to reproduce the problem now on a 2nd server (which also
experienced the problem during the failure period), so far without
success.

Intimate details follow:

Until last week, that was running a debian package I created of
2.2.17; that used ubuntu's package as a template, plus a couple
changes I made.  Since those changes are now either included upstream,
or otherwise unnecessary, I installed ubuntu's vanila 2.2.17 from
their saucy suite.  I believe the sm hangs (or whatever) happened
before and after the upgrade.  Checking ubuntu's patch, they only
patch one C file, which fixes a typo in an error message.

I found XML parse errors in earlier log files, but this time in c2s
(only).  It's possible that's from a misconfigured client.

Also, we recently installed two new AD servers, and retired the old
one.  It's possible that's not all working as intended.  

Justin