Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 5999 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I am currently revisiting the problem of installing FMSA9 in a two machine configuration. These are both brand new XServes running Mac OS X Server 10.5.3, with FMSA 9.0.3.326. My last attempt at this (way back in January) was abandoned after it became clear that we were using under-spec machines and we rolled back to FMSA8.

Originally we attempted to install the webserver/wpe on the DMZ and FM Server on the LAN, with all ports on the firewall open between the two machines and no internal firewalls running. The only other service on the FM Server is Open Directory, while the webserver is also running Apache 2.2 and AFP.

The installation appeared to go smoothly enough on both machines. On first starting the Admin Console it displays the correct IP address or the database server but after deploying web publishing, the Admin Console only displays the IP address of the web server, showing only "localhost" for the database server.

Attempting to connect to Instant Web Publishing returns a "Forbidden" error message. Attempts to connect to php custom web publishing return "Maximum number of database sessions exceeded (956)" error. This is a test suite only - there are no other sessions in use.

At this point we called in Filemaker certified consultants who helped establish that it was not a firewall issue, and raised a case with Filemaker Tech Support (case number 909929 for those who are interested). From the log files I sent, Support suggested that the problem was due to bad DNS settings, although I am awaiting clarification as to what appears to be wrong with them (and it would be nice if error messages actually said what the error was, but hey, you can't have everything!). As our ISP provides the DNS its slightly out of my hands anyway, but I can't tell Cable & Wireless to sort out their DNS unless I have some idea of what's wrong with it.

As I had changed IP addresses on the webserver a number of times during our tests (which may have made the logs somewhat confusing) I re-installed the entire system - the end result was identical. The only DNS error that stands out now is that reverse dns does not resolve the ip address to a Fully Qualified Domain Name. Is this an undocumented requirement to run FMSA9? Perhaps I need a test.domain.com address just for testing Filemaker as I am obviously unwilling to try this out on a production server.

We have also attempted this installation (another completely fresh install) with both servers on the LAN and, of course, that particular dns error persists because there is no DNS server on the LAN. Once again the install appears to go smoothly although this time it appears the FM Web Publishing app refuses to start and after deployment the web server shows in the Admin Console but with a communication error reported in red.

Does anyone have an example of a configuration like this running? How did they test it without a FQDN?

Sorry if this has been a bit of a rant, but short of setting up my own DNS (which seems a bit much just to test the software) I am running out of ideas here.

Posted

The only other service on the FM Server is Open Directory, while the webserver is also running Apache 2.2 and AFP.

I doubt this is the cause of your problem, but why are you doing this? Running the OD master on the FileMaker Server is not a good idea.

You are sure that Apache is running on the Web Server and that the FMS daemon is running on the database server? You can make connections to both?

Steven

Posted

OD is not the problem - my current installation does not have an OD master running at all, although I would like to use one in future. On the LAN because it has all the IDs and passwords which we don't want exposed to the internet, and on one of the two Mac OS X 10.5 XServes because they cannot use an earlier version of the OS as an OD master.

Both FMS and Apache are running and can be connected to without issue. The only database running is FMServer_Sample. This is a very basic install, nothing fancy

Posted

1. Don't run the OD on the same machine as FIleMaker Server.

2. Check to be sure that the ports are opened between the two machines as required. See Tech Info 6427 for a list.

Steven

Posted

1. The OD master is not currently running on the Filemaker Server machine, but can you be more specific as to why they shouldn't both run on the same machine?

2. All ports are open, not just the ones on the Filemaker list.

The same machines both connected on the same network (as opposed to via the firewall) still cannot connect properly (see original post).

Posted

Well, I have finally got this sorted! I admit I was expecting the worst from Filemaker Tech Support having read some of the tales on this forum, but they were in fact pretty helpful, pointing out that there was a DNS problem (although they were unable to give any more detail than that). One guy at UK support has been particularly keen to help, chasing up my case with the developers in the US attempting to find a solution.

Anyway, Apache and system logs indicated that the server was unable to verify a fully qualified domain name. Although we do not control our DNS, I was able to free up a couple of IP addresses that have FQDN and to set up both XServes on these addresses.

If anyone is having similar problems, remember to use changeip and edit the hosts file to ensure that IP addresses and hostnames are all correct. I found it necessary for BOTH servers to have FQDN for the set-up to work (having previously attempted the connection with just the webserver with FQDN).

This topic is 5999 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.