Help Forwarding Incoming Requests to Other Internal Machines (not the web server)

First off, I want to say that I am fairly well versed in computer hardware, networking, etc. but relatively new to Linux and very new to Web hosting. I just built a Web server, installed Fedora Core 5 and followed the excellent "How-To" on the "perfect setup." I now have ISPConfig installed and working great. Thanks to these excellent forums and some other great resources, I have my Web domain working just like I want it to.

The only thing left for me to do is to migrate one more thing from my Windows machine to my new Linux server so that the Windows machine can be shut down when not in use, and that is my setup for remote access to my TiVoWebPlus.

The way it is set up now, a incoming request to a certain domain (tivo1.xxxx.dyndns.com) is directed to my Windows machine. I have a program called OrenOSP (which as I understand it is based on Apache) set up to re-route these requests to my various TiVos (for instance, tivo1 would get rerouted to internal IP 192.168.1.121, and tivo 2 to .122, etc.). I know there has got to be a way to set up my Linux box to do this.

My first attempt was to simply set up co-domains where tivo1, tivo2, etc. were the hosts and were forwarded to 192.168.1.121, etc. While this works inside my network, it doesn't work remotely because, obviously, 192.168.1.121 is not an accessible IP from the outside world.

Any ideas as to how I would set this up? I only have one domain name, and would very much like to let my server handle these requests.

The way it is set up now, a incoming request to a certain domain (tivo1.xxxx.dyndns.com) is directed to my Windows machine. I have a program called OrenOSP (which as I understand it is based on Apache) set up to re-route these requests to my various TiVos (for instance, tivo1 would get rerouted to internal IP 192.168.1.121, and tivo 2 to .122, etc.). I know there has got to be a way to set up my Linux box to do this.

Click to expand...

If this OrenOSP is really running on Apache, it should not be difficult to move it to your new Linux system because you also have an Apache there.

Sorry -- I think I was unclear -- what I meant to say was that I was told when I installed Orenosp is that it is similar to Apache.

I know I have Apache on my server, just not sure yet how to tell it to do this. Unless someone here has seen a "How-To" on this, I'll have to keep looking at the multiple resources I have come across thus far.

OK, I just worked on this, following the documentation you linked to above. I am able to get to the main index of my other servers (TivoWebPlus on my various TiVos), but any redirects screw me up.

The way TWP works, if you click on a link that operates a separate module, it redirects you to the relevant address (i.e., clicking on "User Interface" takes you to 192.168.1.121/ui).

The problem with the way Apache seems to do reverse proxies is that this causes a problem (i.e., clicking on "User Interface" takes you to www.mydomain.com/ui, which does not exist). Is there a way to tell Apache to stay on the servers behind the firewall? What use is this if it keeps pushing you back out to the public server?

OK, so I am working through this reverse proxy documentation. There's lots of conflicting info out there. I think I know how to configure httpd.conf (using the details found at http://www.apacheweek.com/features/reverseproxies). However, I am having trouble with getting libxml2.so.2 and/or mod_proxy_html.so to load at startup.

The error I get during startup says: wrong elf class ELFCLASS32

At first, I thought this was something to do with me miscompiling mod_proxy_html using apxs. The command I used was:

# apxs -c -I/usr/include/libxml2 -i mod_proxy_html.c

Now, I think, however, that I have installed the wrong version of libxml2. Is it possible I installed the 32-bit library and not the 64-bit?

The problem I had with the original setup is that httpd.conf sets the default directory to etc/httpd/. libxml2.so.2 is located in usr/lib/. So I had trouble with typing in that path because it wasn't recognizing the file. Should I have used ./usr/lib/libxml2.so.2 or something like that? Apologies -- I am new to this stuff so I don't know the proper conventions. I thought using a link would be just as effective. I would like to use the full path instead of a link, so if that's possible please do let me know.

falko said:

How did you install libxml2? What's the output of

Code:

uname -m

?

Click to expand...

I cannot run this command at the moment because I am at work. I will run it tonight and post the output here. However, I believe installed libxml2 with the following command:

Code:

yum install libxml2 libxml2-devel

I assume yum figures out that I need 64-bit vs 32-bit, because I did not specifically tell it to install one vs the other.

The problem I had with the original setup is that httpd.conf sets the default directory to etc/httpd/. libxml2.so.2 is located in usr/lib/. So I had trouble with typing in that path because it wasn't recognizing the file. Should I have used ./usr/lib/libxml2.so.2 or something like that? Apologies -- I am new to this stuff so I don't know the proper conventions. I thought using a link would be just as effective. I would like to use the full path instead of a link, so if that's possible please do let me know.

The yum command shows that both libxml2.i386 and libxml2.x86_64 are installed. I used the following in httpd.conf:

Code:

LoadFile /usr/lib64/libxml2.so

There are two files in /usr/lib64 -- libxml2.so and libxml2.so.2. Using the first file, this produces no errors and Apache loads fine. So we figured out the Elf Class problem (thank you for troubleshooting this with me).

Now, however, my reverse proxy is still not routing redirections correctly. It is sneding, for example, a request for "/ui" to www.domain.com/ui, instead of www.domain.com/zone/ui, where zone is one of the zones I set up in httpd.conf. Looking at the excerpts from httpd.conf I posted above, can you see anything I might have done incorrectly?

Now, however, my reverse proxy is still not routing redirections correctly. It is sneding, for example, a request for "/ui" to www.domain.com/ui, instead of www.domain.com/zone/ui, where zone is one of the zones I set up in httpd.conf. Looking at the excerpts from httpd.conf I posted above, can you see anything I might have done incorrectly?