Well, we are finally at the point of testing our first Servoy application somewhat out in the real world with a group of initial testers. While we are configuring a web-based version on a cloud server (where we have another adventure going on ), for this test, we have built a runtime version of our application using File|Export|Servoy|Runtime Builder. Most of our testers have been able to download the runtime version to their PCs and run it, but one user is getting an error that they “can’t connect with the database server”.
I’ve looked at the postgres_log file. While it does contain a bunch of errors that I know about, and the system seems to be work ok with for now, there a couple of new ones that caught my attention. They are…
LOG: could not receive data from client: No connection could be made because the target machine actively refused it.
followed later by…
LOG: invalid IP address “::1”: Unknown host
CONTEXT: line 82 of configuration file “C:/WA4Beta/database/pg_hba.conf”
FATAL: could not load pg_hba.conf
Now, the thing is, everybody got the same files, so either her installation got screwed up, or there’s something unique going on with her PC. Now, that message about the “target machine” actively refused it" got me to thinking that it might be a security problem of some sort. I checked on the postges community site, and yeah, you need to be able to connect to port 5432 like we’d expect, but with everything being local, I’m not sure if there’d be a problem if she had a firewall on her PC.
I’ve attached the postgres_lof file as well, if that might be of any help.
As always, thanks for any guidance that you might be able to provide.
What is line 82 from pg_hba.conf ? It looks like that particular person’s machine is trying to use IPv6 to connect, but doesn’t have the IPv6 stack installed…
EDIT: I should rephrase that: it looks like Postgres during startup analyzes the pga_hba.conf file and is unable to resolve line 82 with the IPv6 address because most likely that particular machine doesn’t have the IPv6 stack installed. So it throws an error and won’t start. You can try to comment that line out and restart. My 2 cents.
The folks using this software probably aren’t the types that would know if they are loading the v4 or v6 IP stacks, so if that does turn out to be the problem, it was most likely inadvertent. But, there should be a way to isolate exactly what is causing the problem, and that’s what I’m trying to figure out.
The pg_hba file says that it is the “VMWare DHCP Configuration Information”. These are the last lines from the file…
TYPE DATABASE USER CIDR-ADDRESS METHOD
IPv4 local connections:
host all all 127.0.0.1/32 trust
IPv6 local connections:
host all all ::1/128 trust
From my count, the last line is line 82.
I’ve sent the user a set of instructions on getting into the Windows command prompt, and running a netstat and a tasklist, which should give us some idea if another application is trying to use the same port that postgres uses. Also asked her if she has any firewall software running that might be blocking the port, or if she’s aware of another application that might be using it. I’ve also asked her to reboot and then immediately try to start the runtime, thinking that if another of her applications is causing the problem, we might be able to get an indication of that by trying the runtime before anything else (unless the offending application autostarts).
I made an edit to my post that you may have missed. Try commenting out line 82 and restart.
The IP stacks are not something a user chooses to start or not start - it is built in to the OS. Whether it has it or not is mainly a function of how old the pc is. IPv6 has not yet garnered a large adoption so some pc’s may not have it activated. Newer pc’s use both IPv4 as well as IPv6 in preparation for the “big move”.
I had the user run a netstat and a tasklist from the Windows command prompt. There doesn’t appear to be any other applications using port 5432. She says that she’s not running any firewall software.
It seems like the next thing to try would be Matthew’s suggestion, and I think that that’s what we’ll do.
I had the user run a test, commenting out the line for IPv6, and this did resolve the problem. Great!
Now, the question is “why is it happening”, and “what do we do about it?”, since this is a file that comes from the Servoy Runtime Builder. I am in the process of confirming this, but I believe that this tester is using Windows XP. As Matthew noted, perhaps the older O/S not having whatever is needed for this to work correctly?
I wonder if any other runtime developers have seen this, and what they do about it?
The “why is it happening” is as I already stated: The customer does not have ipv6 installed on their pc. Postgres scanned the pg_hba.conf file and said “Huh?, what is that? This machine doesn’t have ipv6 installed, so that is an invalid address.” about the ipv6 ::1 address. So Postgres decided to be on the safe side, threw an error and shutdown.
As I see it, you have 4 options for the “What do we do about it”.
modify the pg_hba.conf file on the client when you run into this issue again (as you did this time)
modify the pg_hba.conf file BEFORE you send to any users. For the foreseeable future(next few years minimum) not having postgres use ipv6 won’t be an issue.
See if there is a configuration flag you can set during the build process for postgres to ignore ipv6
(my least favorite idea). have the end user install ipv6. It is a quite easy and painless process and relatively risk free, but I dislike it because i don’t like to mess with someone else’s pc more than i have to. I don’t want someone pointing the figure at me for some “new” issue that coincided with my changing some system settings on their pc. Next thing you know you are on the hook to solve a bunch of their it problems.
I’d lean towards #2 for now, and then #3 once we get closer to production and wrap the runtime in an actual installer.
I’d also like to hear what Servoy has to say. This file is coming out of the Runtime Builder, and so, at this point, it appears that the runtime builder is limited to particular versions of Windows. I’d like to see if that’s their perspective as well, or if they have a different take on it. I’ve posted down in the “Issues” section to see what I might hear from them.
But for now, at least we have a usable workaround.
Ok - but at the risk of boring you with my replies, I will try for this to be my last one on this topic.
As long as you understand that there is no real problem as per se (i.e. it is not a bug) - it is just postgres being cautious. It is Postgres’s host based security file even though it is “coming out of” the runtime builder. You have the same file on you pc with your version of developer - and would have the file if you downloaded and installed Postgres separately.
So this issue has nothing to do with Servoy and their runtime builder - there is nothing wrong with it and it not limited to certain versions of windows. I may not have been clear before, but XP comes shipped with ipv6 but just not activated, so to speak. I suspect some OEM’s had activated on shipped products, some did not. If this person did an upgrade, they may not have added it at that time as well. In any event, ever since Vista Windows activates ipv6 by default. So it is only XP and older versions of Windows that would possibly have this issue that you need to watch out for.
Also, there is no performance difference from using ipv4 vs ipv6 - especially when traffic is limited to the local machine. It is not limiting communications in anyway. Postgres will happily use either stack. If there is an issue, then I would rather suspect low memory, older hardware, disk fragmentation, loaded with cpu sucking crapware, etc.
Not boring at all. Nice to have someone to bounce ideas off of.
I should be clear that I’m not trying to imply that it’s a Servoy “problem”, per se, just that it’s coming out of their runtime, and so I thought it’d be good to get their input on this. One. It could well be one of those “we just pass on what Postgres gives us” kind of things, and there’s really not anything there that they control. Two, it might be helpful for them to know if it comes up again, and for that reason, they might just want to take a look at it.
I appreciate your taking the time to respond. Have a good day.