Hi,
after my initial problems with compiling lsh-1.5.3 are solved now, I thought I'll give tcpwrappers a try. Actually, I want to run lsh thru Dan Bernsteins tcpserver [1], and my assumption is that enabling tcpwrappers support for lsh will allow me to do this. If I'm completely wrong here - how can I do it anyway? :)
After a configure --with-tcpwrappers, make stops here:
make[4]: Entering directory `/usr/local/src/lsh-1.5.3/src' gcc -O2 -march=i386 -mcpu=i686 -fPIC -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -Wl,-rpath,/usr/local/lib -L/usr/X11R6/lib -o lsh lsh.o liblsh.a spki/libspki.a nettle/libnettle.a -lpam -lutil -lcrypt -lXau -lwrap -lz -loop -lgmp /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libwrap.a(hosts_access.o): In function `host_match': hosts_access.o(.text+0x616): undefined reference to `yp_get_default_domain' collect2: ld returned 1 exit status make[4]: *** [lsh] Error 1 make[4]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/lsh-1.5.3' make: *** [all] Error 2
What's the problem here?
System is RedHat 7.1, /usr/lib/libwrap.a belongs to tcp_wrappers-7.6-18. If you need more details, please let me know.
Regards Jochen
Hi,
after my initial problems with compiling lsh-1.5.3 are solved now, I thought I'll give tcpwrappers a try. Actually, I want to run lsh thru Dan Bernsteins tcpserver [1], and my assumption is that enabling tcpwrappers support for lsh will allow me to do this. If I'm completely wrong here - how can I do it anyway? :)
No, it won't, (at least for you to be able to use tcpserver, lshd would have to accept to handle one session from stdin/stdout and then exit, which it doesn't).
If you just want to use the wrapper functionality of tcpserver (and don't want to use tcpwrappers instead), you could let your lshd listen on a local interface and have tcpserver run a program that just sets up a tcp connection to lshd and copy data from/to stdin/out to/from the network (tcpcat seems to be suitable, netcat and tcpconnect are other alternatives).
make[4]: Entering directory `/usr/local/src/lsh-1.5.3/src' gcc -O2 -march=i386 -mcpu=i686 -fPIC -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -Wl,-rpath,/usr/local/lib -L/usr/X11R6/lib -o lsh lsh.o liblsh.a spki/libspki.a nettle/libnettle.a -lpam -lutil -lcrypt -lXau -lwrap -lz -loop -lgmp /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libwrap.a(hosts_access.o): In function `host_match': hosts_access.o(.text+0x616): undefined reference to `yp_get_default_domain' collect2: ld returned 1 exit status make[4]: *** [lsh] Error 1 make[4]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/lsh-1.5.3' make: *** [all] Error 2
What's the problem here?
This seems rather strange, considering that it's lsh (not lshd) you're building, and it shouldn't really have need anything from libwrap, but most likely linking with libnsl (i.e. adding -lnsl to LDFLAGS) will help (possibly throwing in -lsocket if -lnsl alone doesn't help).
/Pontus
Pontus Skoeld wrote:
after my initial problems with compiling lsh-1.5.3 are solved now, I thought I'll give tcpwrappers a try. Actually, I want to run lsh thru Dan Bernsteins tcpserver [1], and my assumption is that enabling tcpwrappers support for lsh will allow me to do this. If I'm completely wrong here - how can I do it anyway? :)
No, it won't, (at least for you to be able to use tcpserver, lshd would have to accept to handle one session from stdin/stdout and then exit, which it doesn't).
Ok, I wasn't sure about what the tcpwrappers support exactly means. I thought it would be similar to compiling in an inetd compatibility mode, but thats obviously wrong.
If you just want to use the wrapper functionality of tcpserver (and don't want to use tcpwrappers instead), you could let your lshd listen on a local interface and have tcpserver run a program that just sets up a tcp connection to lshd and copy data from/to stdin/out to/from the network (tcpcat seems to be suitable, netcat and tcpconnect are other alternatives).
Hmm ok, maybe I'll give this one a try.
make[4]: Entering directory `/usr/local/src/lsh-1.5.3/src' gcc -O2 -march=i386 -mcpu=i686 -fPIC -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -Wl,-rpath,/usr/local/lib -L/usr/X11R6/lib -o lsh lsh.o liblsh.a spki/libspki.a nettle/libnettle.a -lpam -lutil -lcrypt -lXau -lwrap -lz -loop -lgmp /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libwrap.a(hosts_access.o): In function `host_match': hosts_access.o(.text+0x616): undefined reference to `yp_get_default_domain' collect2: ld returned 1 exit status make[4]: *** [lsh] Error 1 make[4]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/lsh-1.5.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/lsh-1.5.3' make: *** [all] Error 2
What's the problem here?
This seems rather strange, considering that it's lsh (not lshd) you're building, and it shouldn't really have need anything from libwrap, but most likely linking with libnsl (i.e. adding -lnsl to LDFLAGS) will help (possibly throwing in -lsocket if -lnsl alone doesn't help).
Setting LDFLAGS="-lnsl" before configuring lsh with tcpwrappers support works. So thats a problem with the configure script? Shouldn't it work out all the libraries needed?
Thanks a lot for the help and suggestions, Pontus!
Best regards Jochen
lsh-list@brennmeister.com writes:
Ok, I wasn't sure about what the tcpwrappers support exactly means. I thought it would be similar to compiling in an inetd compatibility mode, but thats obviously wrong.
Yes, it just brings in code to use tcpwrappers (which is basically the same thing as tcpserver, in library form (well, it comes as a separate program for usage with inetd too, see tcpd).
The primary reason for using tcpserver instead of tcpwrappers would be to have access control lists one place less.
Setting LDFLAGS="-lnsl" before configuring lsh with tcpwrappers support works. So thats a problem with the configure script? Shouldn't it work out all the libraries needed?
Yeah, it should (and AFAIK, it does so on all the boxes I have access to). In fact, it should have complained about it at the ./configure stage (sending me your config.log might help).
/Pontus
Pontus Skoeld wrote:
lsh-list@brennmeister.com writes:
Ok, I wasn't sure about what the tcpwrappers support exactly means. I thought it would be similar to compiling in an inetd compatibility mode, but thats obviously wrong.
Yes, it just brings in code to use tcpwrappers (which is basically the same thing as tcpserver, in library form (well, it comes as a separate program for usage with inetd too, see tcpd).
The primary reason for using tcpserver instead of tcpwrappers would be to have access control lists one place less.
Tried this now... tcpcat didn't do the trick (seems to be redirecting only the output from the ip/port it connects to), but tcpconnect works fine.
Setting LDFLAGS="-lnsl" before configuring lsh with tcpwrappers support works. So thats a problem with the configure script? Shouldn't it work out all the libraries needed?
Yeah, it should (and AFAIK, it does so on all the boxes I have access to). In fact, it should have complained about it at the ./configure stage (sending me your config.log might help).
I've put the log here: http://www.brennmeister.com/lsh-config.log
Regards Jochen
Pontus Skoeld pont_lsh@soua.net writes:
No, it won't, (at least for you to be able to use tcpserver, lshd would have to accept to handle one session from stdin/stdout and then exit, which it doesn't).
Actually, it shouldn't be too hard to fix this. Look at src/daemon.c:daemon_init. That function should return DAEMON_INETD if lshd has a connected socket on stdin/stdout (is inetd startup compatible to tcpserver?). Currently, lshd just exits with an error message in this case, but it should be fairly straight-forward to wrap the socket fd in an lsh_fd object and start the initial handshake.
Regards, /Niels
Niels Möller wrote:
Pontus Skoeld pont_lsh@soua.net writes:
No, it won't, (at least for you to be able to use tcpserver, lshd would have to accept to handle one session from stdin/stdout and then exit, which it doesn't).
Actually, it shouldn't be too hard to fix this. Look at src/daemon.c:daemon_init. That function should return DAEMON_INETD if lshd has a connected socket on stdin/stdout (is inetd startup compatible to tcpserver?). Currently, lshd just exits with an error message in this case, but it should be fairly straight-forward to wrap the socket fd in an lsh_fd object and start the initial handshake.
Maybe a feature for 1.5.4? ;-) I'm not able to apply the changes you mention myself, but if you provide a patch and want me to test it, that's no problem.
Regarding your question re tcpserver (from http://cr.yp.to/ucspi-tcp/tcpserver.html): "tcpserver waits for connections from TCP clients. For each connection, it runs prog, with descriptor 0 reading from the network and descriptor 1 writing to the network. It also sets up several environment variables." I don't know if this helps.
Btw, I experience the same connectivity lag as another person mentioned some time ago on the list (only read about it in the web archive of the list, don't have the actual mail at hand). I'm connecting to a host in the U.S. over DSL from Germany (using Putty under Win32), and OpenSSH is much more responsive (no matter if I enable TCP_NO_DELAY in Putty or not).
Regards Jochen
lsh-list@brennmeister.com writes:
Maybe a feature for 1.5.4? ;-) I'm not able to apply the changes you mention myself, but if you provide a patch and want me to test it, that's no problem.
If you want to, you can add it to the bugzilla at http://bugzilla.lysator.liu.se/index.cgi, then at least it shouldn't be forgotten.
Regarding your question re tcpserver (from http://cr.yp.to/ucspi-tcp/tcpserver.html): "tcpserver waits for connections from TCP clients. For each connection, it runs prog, with descriptor 0 reading from the network and descriptor 1 writing to the network.
It would help lsh if it could use a single fd for both reading and writing. Perhaps that works too (it should, if tcpd passes the raw socket on to the program it starts).
Regards, /Niels
Niels Möller wrote:
lsh-list@brennmeister.com writes:
Maybe a feature for 1.5.4? ;-) I'm not able to apply the changes you mention myself, but if you provide a patch and want me to test it, that's no problem.
If you want to, you can add it to the bugzilla at http://bugzilla.lysator.liu.se/index.cgi, then at least it shouldn't be forgotten.
Done :)
Regarding your question re tcpserver (from http://cr.yp.to/ucspi-tcp/tcpserver.html): "tcpserver waits for connections from TCP clients. For each connection, it runs prog, with descriptor 0 reading from the network and descriptor 1 writing to the network.
It would help lsh if it could use a single fd for both reading and writing. Perhaps that works too (it should, if tcpd passes the raw socket on to the program it starts).
Well, I can't help you with these details, that's beyond my understanding of how tcpserver works. Sorry.
Regards Jochen
nisse@lysator.liu.se (Niels Möller) writes:
Actually, it shouldn't be too hard to fix this. Look at src/daemon.c:daemon_init. That function should return DAEMON_INETD if lshd has a connected socket on stdin/stdout (is inetd startup compatible to tcpserver?). Currently, lshd just exits with an error message in this case, but it should be fairly straight-forward to wrap the socket fd in an lsh_fd object and start the initial handshake.
Regards, /Niels _______________________________________________ lsh-bugs mailing list lsh-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
-
lsh-list＠brennmeister.com -
nisse＠lysator.liu.se -
Pontus Skoeld -
Pontus Skoeld