Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
regards Tom
If you want to resolv hostnames using resolv.conf file, you need the appropriate library libresolv which is part of libc. So you'll need to copy the libc librairies in your chroot environment.
Regards, Flo
On Wed, Feb 13, 2019 at 1:00 PM tom [email protected] wrote:
Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
regards Tom _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
On Wed, Feb 13, 2019 at 01:12:54PM +0100, Flo Rance wrote:
Regards, Flo
On Wed, Feb 13, 2019 at 1:00 PM tom [email protected] wrote:
Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
If you want to resolv hostnames using resolv.conf file, you need the appropriate library libresolv which is part of libc. So you'll need to copy the libc librairies in your chroot environment.
Mmm, I don't think that the resolver libraries are loaded dynamically; they are usually loaded in the stunnel binary at startup.
However, tom, can you also try copying the /etc/nsswitch.conf file to the chroot?
G'luck, Peter
Am Mi., 13. Feb. 2019 um 13:23 Uhr schrieb Peter Pentchev [email protected]:
However, tom, can you also try copying the /etc/nsswitch.conf file to the chroot?
yes, of course but no luck - still the same error.
Reagrds Tom
Hello, When you "pinged", were you in your chrooted environment ? Pierre
Le 13/02/2019 à 12:59, tom a écrit :
Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
regards Tom _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Ok, but in that case you should remove "delay = yes" and the hostname will be resolved at startup, before chroot
On Wed, Feb 13, 2019 at 1:23 PM Peter Pentchev [email protected] wrote:
On Wed, Feb 13, 2019 at 01:12:54PM +0100, Flo Rance wrote:
Regards, Flo
On Wed, Feb 13, 2019 at 1:00 PM tom [email protected] wrote:
Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
If you want to resolv hostnames using resolv.conf file, you need the appropriate library libresolv which is part of libc. So you'll need to copy the libc librairies in your chroot environment.
Mmm, I don't think that the resolver libraries are loaded dynamically; they are usually loaded in the stunnel binary at startup.
However, tom, can you also try copying the /etc/nsswitch.conf file to the chroot?
G'luck, Peter
-- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Ok, but in that case you should remove "delay = yes" and the hostname will be resolved at startup, before chroot
yes this works, the problem - foobar.remote.site is dynamic DNS host. In this scenario I'll never update the host until stunnel restart.
On Wed, Feb 13, 2019 at 02:31:00PM +0100, Flo Rance wrote:
On Wed, Feb 13, 2019 at 1:23 PM Peter Pentchev [email protected] wrote:
On Wed, Feb 13, 2019 at 01:12:54PM +0100, Flo Rance wrote:
Regards, Flo
On Wed, Feb 13, 2019 at 1:00 PM tom [email protected] wrote:
Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
If you want to resolv hostnames using resolv.conf file, you need the appropriate library libresolv which is part of libc. So you'll need to copy the libc librairies in your chroot environment.
Mmm, I don't think that the resolver libraries are loaded dynamically; they are usually loaded in the stunnel binary at startup.
Ok, but in that case you should remove "delay = yes" and the hostname will be resolved at startup, before chroot
This would be true if the resolver libraries are loaded dynamically... which seems to be true. I just found a CentOS 7 system to test on, and it seems that libnss loads its modules dynamically, grrrrr.
OK, so, tom, you should also find your libnss_* libraries - the easiest way is through `ldconfig -p | fgrep -e libnss_files` - and copy all of the libnss_*.so* (both the *.so ones and the *.so.something ones) into the corresponding directories in your chroot. I believe that the ones in the /lib64 directory should be enough - e.g. I think that it might be enough to do this:
mkdir /var/run/stunnel/lib64 cp -p /lib64/libnss_*.so* /var/run/stunnel/lib64/
...but if this doesn't work, you should also copy all others from all the directories mentioned in the `ldconfig -p | fgrep -e libnss_files` output.
Sorry for doubting the "dynamically loaded resolver modules" idea at first :(
G'luck, Peter
No problem, anyway this was an assumption but I hadn't any CentOS to confirm or disprove that theory.
On Wed, Feb 13, 2019 at 2:55 PM Peter Pentchev [email protected] wrote:
On Wed, Feb 13, 2019 at 02:31:00PM +0100, Flo Rance wrote:
On Wed, Feb 13, 2019 at 1:23 PM Peter Pentchev [email protected] wrote:
On Wed, Feb 13, 2019 at 01:12:54PM +0100, Flo Rance wrote:
Regards, Flo
On Wed, Feb 13, 2019 at 1:00 PM tom [email protected] wrote:
Hello,
Are you sure 'foobar.remote.site' should resolve? Does "ping foobar.remote.site" work?
yes, the host is resolved on commandline and other services on this system can reach this host.
Do you have a /var/run/stunnel/etc/resolv.conf file?
No at this time I dont have this file, but it doesnt change
anything
if I copy the original from /etc to this lokation. But this brings
me
to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in
the
chroot jail.
I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well?
If you want to resolv hostnames using resolv.conf file, you need the appropriate library libresolv which is part of libc. So you'll need to copy the libc librairies in your chroot
environment.
Mmm, I don't think that the resolver libraries are loaded dynamically; they are usually loaded in the stunnel binary at startup.
Ok, but in that case you should remove "delay = yes" and the hostname
will
be resolved at startup, before chroot
This would be true if the resolver libraries are loaded dynamically... which seems to be true. I just found a CentOS 7 system to test on, and it seems that libnss loads its modules dynamically, grrrrr.
OK, so, tom, you should also find your libnss_* libraries - the easiest way is through `ldconfig -p | fgrep -e libnss_files` - and copy all of the libnss_*.so* (both the *.so ones and the *.so.something ones) into the corresponding directories in your chroot. I believe that the ones in the /lib64 directory should be enough - e.g. I think that it might be enough to do this:
mkdir /var/run/stunnel/lib64 cp -p /lib64/libnss_*.so* /var/run/stunnel/lib64/
...but if this doesn't work, you should also copy all others from all the directories mentioned in the `ldconfig -p | fgrep -e libnss_files` output.
Sorry for doubting the "dynamically loaded resolver modules" idea at first :(
G'luck, Peter
-- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
mkdir /var/run/stunnel/lib64 cp -p /lib64/libnss_*.so* /var/run/stunnel/lib64/ ...but if this doesn't work, you should also copy all others from all the directories mentioned in the `ldconfig -p | fgrep -e libnss_files` output.
I try it, but same problem - to make it short, I copy the whole /lib and /lib64 directories to /var/run/stunnel - same issue. So it couldn't be only caused by missing libs. :(
I would suggest to use strace to identify exactly what is called when you run stunnel.
Regards, Flo
On Wed, Feb 13, 2019 at 3:27 PM tom [email protected] wrote:
mkdir /var/run/stunnel/lib64 cp -p /lib64/libnss_*.so* /var/run/stunnel/lib64/ ...but if this doesn't work, you should also copy all others from all the directories mentioned in the `ldconfig -p | fgrep -e libnss_files` output.
I try it, but same problem - to make it short, I copy the whole /lib and /lib64 directories to /var/run/stunnel - same issue. So it couldn't be only caused by missing libs. :( _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
Flo Rance -
Peter Pentchev -
Pierre Delaage -
tom