Server is only serving default page, for all sites

I originally deployed my InterWorx system with an internal IP, behind a NAT. Unfortunately, it doesn’t appear to come with the RPAF apache module (to translate client IP headers from the load balancer in to logged IPs), so I moved it out to it’s own public IP.

I added the public IP to the system, moved all domains to the public IP and verified the private IP has no domains associated. I also checked the vhost files to ensure each domain is referencing the correct IP.
Now, when I access any domain (secondary, or subdomain) I’m getting the root default page associated with the IP. If I turn default pages off, it falls over to the first site in the alpha list, and never reaches the actual target domain site.

Pointer sites are redirecting as desired, but, if they reference another domain on the system, back to the default page you go.

Short of manually updating Apache config files, which could potentially be overwritten by InterWorx, I’m not sure what else to review on the system to return my sites back to service.

Any ideas/comments are greatly appreciated.

Thank you.

Hi jzmatrix

I hope you don’t mind, but you should be able to run IW behind nat on a private ip or on an public ip, or even both, or mixtures thereof.

I suspect it’s connected with DNS, so have you checked your seeing the correct ip used for the domain, if not, flush your cache for browser and dns on your computer and retest.

Also, have you deleted the IW holding page index.html I think from memory, as if you have index.htm or php, I believe if the top file listed first, if existent would be used, so it’s important to delete the IW holding index page.

I would strongly advise against altering apache files, unless you know exactly what your doing as you can break it.

I hope that helps a little

Many thanks

John

When default sites is on, does it list the correct domains with the correct IP’s? Also, in the System IP’s page, does it report the correct SiteWorx accounts and domains as associated with the correct IP’s?

For the NAT setup, in the past we’ve seen situations where the NAT device itself actually stripped the domain out of the packet headers in http requests. Since it happened at the NAT device it’s out of our control, so that might be something else to check.

The system was originally running behind a NAT and was working correctly, with the exception of the NAT IP being logged instead of the actual client IP. Mainly due to the RPAF module not being installed on the system. I’m fairly certain I installed that module, but a day or so later it was gone (don’t know if InterWorx self-heals).

That was the driving factor behind moving it from behind the NAT as logging/tracking actual clients is fairly important for my sites and overall user accountability.

While it was behind the NAT all of the target domains were resolved and presented correctly. When I moved the server out to it’s own public IP, I moved all of the associated domains to the public IP, and cleaned up DNS accordingly to ensure everything resolved to the correct public IP.

The issues stems from the /etc/httpd/conf.d/namevirtualhost.conf file, which maintained the private IP and didn’t add the public IP, so it was never honoring the vhost configurations.
I switched out the private IP for the public IP in this file, restarted http, and everything is now functioning correctly.

My main concern at this point, will updates to the server (InterWorx in particular) possibly revert this file back to it’s original state?

I’m quite versed with httpd and overall system management, but tend to step back when I’m relying on a 3rd party system to handle/manage the overall configuration.

Should this file remain intact over the life of the system (InterWorx updates, etc), or is there something else that I may need to do in order to prompt an automatic update of the namevirtualhost.conf file?

Hi Jzmatrix

I’m pleased you resolved it, and have posted the reason for failure, which I have tested on our test system, and can concur, the same result is seen for failure to remove the IP address, however, in my tests it did correctly write the new IP address which was added.

I also checked and noted that the IP address which was added, then deleted, whilst still remaining in the namevirtualhost.conf, also remained shown in DNS server, and had to be manually removed.

I will forward this post as a bug so you have the credit if alright, but I know another user had a similar issue conected with namevirtualhost.conf, as of yesterday, but I did not have the time to run a check until now, so I’ll include them as well for credit.

I hope you don’t mind, but IW would not remove any additional conf you may have installed, and unless you make changes, IW does do an excellent job at updates to IW, to keep all settings as was, and I think any changes made, a backup of the original is seen, such as namedvirtualhost.conf.orig, but this also does not appear to change as above, however I could be wrong so apologise in advance.

I can certainly confirm we have been using IW for many years, and all version upgardes to IW have not stopped service (IW all version 4 upto current), however, IW do not accept any liability if your OS or Distro upgrade breaks anything, but again we have not had any service issues with this either (there has been very small issues seen though, which were very quickly correctly by IW, such as graphs not displaying, but a quick look through the forum here and you will see how many issues re updates there were/are).

Lastly, re RPAF module, have you checked to see if your downloaded file(s) are still shown, and if they are listed in conf.d folder. Reason I ask, is because you seem sure you did install this module, but are uncertain if IW would have removed RPAF, which I can only think it might only remove it from httpd.conf (if installed as module in httpd.conf), if not, then I cannot honestly see how it could remove the file from conf.d, when httpd is set to load any conf found in conf.d folder, as far as I know anyway sorry, and IW is not self healing.

I apologise if I wrong though, and hope someone would correct me.

Many thanks

John

Thank you for replying and confirming the same behavior in your tests.
I’m not sure why my system decided to act a bit ‘wonky’ with the updating of the files though, once traced, the fix is fairly straight forward.

I can rest much easier now know that these files shouldn’t be overwritten providing me with an ‘early morning surprise’.
In regards to RPAF, I’m honestly not sure what happened. I know I installed/configured it during my initial ‘behind NAT’ tests, and everything was working as expected. Now when I check the system, RPAF and all traces (including the RPM) are gone, which was the primary trigger in my worrying about ‘self healing’. I’ll review the system for other traces of what happened to that, and now that all is good in public-IP world, I’m loving IW.

I’ve used numerous CP platforms, including rolling my own, and IW has been the best one I’ve worked with along the way. Great job on the product, and thank you for the very fast and concise replies on the forum!