Jump to content

Peter Wagemans

  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Peter Wagemans

  • Rank
    just passing through

Profile Information

  • Title
  • Gender
  • Location

Contact Methods

  • Website URL

FileMaker Experience

  • Skill Level
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
  • OS Version
    High Windows

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Peter Wagemans

    reverse proxy and SSL certificate check

    Aucun problème Tom. I saw from your screen shot you are French speaking. I also speak French but most of the time I do not know what I am saying. 🙂 I found the solution to the problem. Using https://www.markbrilman.nl/2012/07/creating-a-pfx-file-with-chain/ as documentation I created a pfx file that contains the main AND the intermediate certificate. I first removed the old wildcard crt file from the firewall, then imported the pfx file, and assigned it to the virtual servers that run over https. They now return a green A sign on sslabs and... the FileMaker client problem disappeared!! Thanks everyone for helping me understand and solve this.
  2. Peter Wagemans

    reverse proxy and SSL certificate check

    Indeed. I reinstalled the server to find the reason for the problem, and did not configure it yet. So the other test files are hidden now because they require a password. Thanks for mentioning it. There's no Pentagon secrets on this server, luckily. 🙂 You should now only see the HTML Snippet Library, which is a public freeware project I did years ago with Andries Heylen, and a PluginManager test file, that should be rather well protected. As for the problem itself, I discovered using the SSL Labs site https://www.ssllabs.com/ssltest/ that there is a problem with the intermediate certificate. And that explains the trouble I am having. The Sophos UTM firewall is only proxying the clarify.net certificate. But not the intermediate one, because there is not even a way to configure that. I'll take this up with Sophos, at least I know now where the problem orginates.
  3. Peter Wagemans

    reverse proxy and SSL certificate check

    Hi Tom, All DNS setup has been correctly done. Or I wouldn’t even be able to reach the server using fms.clarify.net, and make the screen shots. But... I have currently disabled the server, so if you try that address you will nog get a response anymore. Maybe that explains your reaction.
  4. Peter Wagemans

    Things to do

    Hi Tobias, Thanks for this feedback. Yeah, even on my test server, I was amazed by all the data it is generating. I think that FileMaker Server schedules are the best way to schedule regular deletion. @Claus Lavendt is this something we should create in the FileMaker front end? Maybe we could just make a deletion script with some parameters like a datestamp cutoff offset and a log file name, the script could default to all logs if that parameter would not be provided. The front end FileMaker solution is using an ODBC datasource as a FileMaker external reference for occurrences, so scripting this from FileMaker would be the best solution I think. Definitely something for me. I know. I've been spending considerable time installing Xojo on CentOS 7 ( Xojo installation on Linux really sucks ), and it already compiles - without functioning of course. But I should put that on hold and go for the encrypted connection first, I think it will be way more easy to implement. I think these are all features to put in the FileMaker front end file. That rough demo would be nice to look at. Are you doing it with or without plug-ins? Please post it here. I don't know exactly how the Prowl feature works, @Claus Lavendt also added this feature to the front end file. Maybe he can answer this one. The daemon/service only sends log data, interpretation of that data is done on the FileMaker side.
  5. Peter Wagemans

    reverse proxy and SSL certificate check

    Thanks Mike, So are you saying that the SSL certificate verification is happening over port 5003, while the "view certificate" button uses port 443? Yes for the intercept part, yes for the configuring part, but no for the "instead". It is also configured on the FMS web server.I am using the exact same certificate on both the FileMaker Server and the reverse proxy. For the 5003 part I use simple NAT port forwarding, it has always worked fine and will probably continue to do so. I have a little trouble believing that the SSL verification is happening over port 5003. Port 5003 is not proxied, there is no interception anywhere. Important to know here is that from the private network, everything works correctly. This is a firewall issue I am trying to solve. I know how to configure FileMaker Server. I just have trouble configuring this freaking firewall, maybe I have to try another distribution like pfsense.
  6. Peter Wagemans

    reverse proxy and SSL certificate check

    Hi Steven, As you can see in the screen shots, I used the FQDN. Can you elaborate on the "ConnectionStatus 3"? Sounds interesting.
  7. Because I have only 1 external IP address in the office here, I have set up a reverse proxy on my Sophos UTM 9 firewall, they call it WAF or Web Application Firewall. In this setup, you define a number of "real" web servers with their internal IP addresses, you also define a number of "virtual" web servers by DNS name m type ( http or https ) and port ( 80, 443, or whatever you would like). This works great if you want to host different web servers on different internal machines. BTW they are all VMs. I also configured this for FileMaker Server, so everything https related is nicely routed to the fms machine. That also works great, apart from 1 small thing. The client complains about the certificate. There is nothing wrong with the certificate, as this works fine when I connect to the server internally ( using the same DNS name of course ). Everything nicely green. It only goes wrong when contacting it externally. FileMaker shows an error dialog that it cannot verify the identity of the server. See screen 1. When I click on "View Certificate" it shows perfectly fine certificates, as shown in screen 2, 3 and 4. There must be something wrong with the way the firewall is implementing the reverse proxy. I think I configured it correctly: I am passing the host headers, and the virtual filemaker site is correctly associated with the wildcard certifcate, just like the regular virtual apache web site that I am running as well and which gives not problems whatsoever. Someone at the Sophos forum indicated that perhaps the firewall is inserting some certificate information that is not making FileMaker itself happy. It appears to me that FileMaker is using 2 technologies here, one that is a custom FileMaker certificate client, which is detecting something it doesn't like, and the "View Certificate" dialog is almost certainly using standard system software ( webkit? ) and decides everything is fine. They are not agreeing with each other, that is for sure. Are there any IT people on this forum who have set up something like this? Any help is very much appreciated.
  8. Peter Wagemans

    Things to do

    It was great to see all those positive reactions when we presented WhistleBlower's functionality and installation during Berlin's dotFMP. There was also some good feedback, on what can be done next. Let me first explain about how Claus and I divided our efforts on this monitoring solution. While Claus has been working hard on the front end FileMaker solution, my job was to take care of the part that's installed on the FileMaker servers. We choose for a Windows service and a macOS daemon. We also choose to handle all monitoring communication by reading from, and writing to a MySQL database. The daemon uses the macOS FSEvents framework to monitor the FileMaker logs, and the service uses the FindFirstChangeNotification function. For process reporting, the service uses the Windows Management Instrumentation and a terminal feed from the top command on macOS. The rest of the code for the daemon and service is pretty much the same, and everything is written in Xojo. So Claus has been building the FileMaker solution, and while doing so, asked me to add and/or improve something in the WhistleBlower daemon/service, each time something was needed on the FileMaker side. The FileMaker solution we provide is an example of what you could do, but in fact you can brew your own FileMaker solution, and we even encourage that. We feel everyone has slightly different needs, For the daemon/service I have 2 things on my wish list: write the platform specific code for CentOS so WhistleBlower can run on a FileMaker Cloud Server. I already did some research on iNotify, and it seems to be the way to monitor the FileMaker Server logs. I have to set up a Xojo IDE and I' still not sure if I would be developing on Ubuntu or on CentOS, still a lot of things to prepare there, so don't hold your breath. improve the MySQL connection to use encryption. We already considered doing that, but decided not to include this in the first release. You can always setup a VPN client service on the FileMaker server machine to make things more secure, at least for the moment. Please feel free to share improvement ideas in this thread.
  9. Peter Wagemans

    oauth suddenly broken this morning

    I used Onyx to rebuild launchservices and caches. It was probably launchservices that was broken, since Onyx asked me where FileMaker was using the typical AppleScript dialog, it was in the list, and it was running, so the db was probably corrupted somehow. Problem solved.
  10. I try to login this morning with google authentication, and the login dialog does not go away. All the rest is standard: Safari comes to the foreground, asks if it can authenticate, I click the OK button. But nothing happens. I tried restarting FileMaker restarting Safari relogin to Google account another browser ( Vivaldi ) restarting the Mac throwing away com.filemaker.client.advanced12.plist I tried on my old MacBook ( I switched to a new one recently ) and there everything works correctly. Next thing I will try is to start throwing away caches, but I wonder: did anyone experience this already? How did you solve it? Please do not tell me I have to reinstall my Mac...:-)
  11. Peter Wagemans

    user connection licenses and reconnect

    Thanks Claus, that sounds like great advice. See you soon.
  12. Hi people, A customer is complaining about his FileMaker Pro 16 application acting up: when brought back from the background, the application requires the address of the server, even when the customer is actually logged in to the server. The customer took a screen shot of this, and the application window is clearly visible behind the nagging dialog. Clearly again a FileMaker problem, but I'm not going that way anymore, since I have to make a living as well. I was just wondering what could be done to avoid the disconnect, and on reconnect, how to help FileMaker a bit reconnecting. The first thing I was wondering about, was App Nap. There's a FileMaker help article here: using-filemaker-networking-on-mac-os-x-with-app-nap-enabled but the last edit is in 2015 and it covers only until 2013. The second google link FMP v14 and App Napp on the FileMaker Community web site seems to confirm that it is still an issue in v14. Why did FileMaker stop editing the article then? Apple has removed the check box option from the "Get Info" window of the application, one way of enabling/disabling it today is to use the excellent Onyx freeware application. But that switches App Nap system wide, not on application level. I'm wondering if it should be off or on, the customer uses the latest MacBook with Sierra. The second thing is the password linking mechanism that seems broken as well on reconnect. You open File A, file A needs file B and FileMaker internally passes the credentials used to open File A, to open File B. Unfortunately this doesn't seem to happen on reconnect, and FileMaker asks for the password of File B, with no option to save the password, although this option is set in the file preferences. I made the customer open File B directly, and save the password to the keychain. At least this *should* lessen the annoyances he is facing today. Does anybody have any insights to add here?
  13. Yesterday, I tried to move a script that creates a PDF ( and mails it ) to a server side script, as the "save records as PDF" script step is now supported in server side scripts. It did not work correctly, and generated an error 800 (file could not be created on disk) in the server log. Rather generic error. I changed the script to point to a blank layout instead. No more error. A nice blank PDF was created. I put a text box with "test" in it on the layout, Arial 12 point. -> error 800 I removed the text box and put a png graphic on the layout -> OK I put a text box in a font that I was sure of the server did not have -> OK! I tried this several times, 2 several fonts, and the results and errors were consistent. So if during the PDF creation, the server replaces the font reference by its own replacement font reference, it is able to save as PDF. If a reference lik "Arial" is used, it fails and the server reports the generic error that it can not create the file on disk (800). I'm using MacOS 10.12.4 as client and Window Server 2012R2 as the server. Maybe there is a cross platform issue here? As always, more testing is required. Can anyone confirm similar issues? Any workarounds that are known? Any thoughts and insights?
  14. Peter Wagemans

    Zulu configuration questions

    Bonjour Pierre, Interesting link! I'm going to take my time examining this some more, it seems like a good solution in a lot of situations, and not only for Zulu. Zulu 2 is definitely an improvement over v1, but I can't help it, it gives me the shivers. Zulu always gives me the feeling it can break any moment, and leave me stranded with problems I'm not qualified to handle.
  15. Hi forum, I am upgrading a customer with a FMS 13 setup with Zulu 1 on port 8080 to a FMS 15 with Zulu 2. It was already a problematic setup, as the FileMaker Server runs concurrently with an OSX Server. Hence the 8080 port to keep away from OSX Server hijacking port 80 all the time. The new FMS 15 is installed on port 85/2443 to keep away from the OSX Server web ports. Great. We wanted to keep Zulu on 8080 though, because then we wouldn't have to change the deployment on every machine. Installing Zulu 2, there is no option to choose the ports. It just configures to port 80. I would really like to have Zulu listen on port 8080 and talk to FMS over port 85. I tried modifying the context.xml, but that didn't do anything. For the moment, I have done a custom install using the old TomCat 7 instance listening on 8080, and a ProxyPass instruction on the OSX server, which is very ugly. But it works. What is the best way to do this?

Important Information

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