FileMaker 2024 (i.e. FileMaker 21.0), was released on June 4, 2024. Learn more about FileMaker 2024 on the Claris website. If you’re exploring a new solution on the Claris platform, we encourage you to sign up for a free trial here.
In this second section of our FileMaker 2024 Executive Summary, we will cover FileMaker Server, WebDirect, and the Data API.
FileMaker Server
OS and Client Compatibility
Claris FileMaker Server supports largely the same operating systems as its predecessor:
- Linux: Ubuntu 20 and Ubuntu 22 for x64 processors and Ubuntu 22 for ARM processors. We were a little surprised not to see support for Ubuntu 24 LTS, given its release in April 2024, but we are expecting that to be added soon enough.
- Windows Server 2019 and 2022
- macOS Ventura (13) and Sonoma (14). Note that support for Monterey (12) has now been removed.
If you are debating which operating system to choose, then keep in mind that Claris has indicated that they consider Linux to be the primary operating system. Most new features will be developed there, and some will only make it to Windows and macOS later (or possibly never). The https tunneling in FileMaker 20.3 is a good example. So is the Let’s Encrypt SSL feature in this version.
FileMaker Pro and Go clients need to be running version 19.4.2 and up. Realistically, though, you will want to be on version 19.6 or higher since the Claris Support Policy shows that 19.4 has been end-of-life since December 2023 and 19.5 ends in June 2024.
Security
The previous release before FileMaker Server 21.0 was 20.3.2. If you cannot upgrade to 21.0 soon, then we strongly urge you to at least upgrade to 19.6.4 or 20.3.2, both of which have the crucial security patches to be fully protected. The information from Claris on the patched vulnerability is scarce, but here is the knowledge base article. From what we know, it is very serious and reason enough to upgrade, even if it means working around a few functional issues.
Regarding security, the Linux version of FileMaker Server has always used firewalld as its firewall; that sometimes meant disabling the default ufw firewall that you maybe were already using on the server. The FileMaker Server installer will now not touch ufw if it detects it is running already and will add the required ports to it. If ufw is installed but disabled, then the installer will still install firewalld and use it.
Stability / Uptime
Claris has been working on the Persistent Cache feature for a few versions now. The feature is meant to protect the files in case FileMaker Server crashes or quits unexpectedly. In such an event, the best practice has always been to trash the files that were in use at that time and restore the most recent backup. Invariably, that leads to data loss, however small, even if you have a decent backup policy.
In this version, Claris adds a toggle to automatically restart the database engine process after a failure:
This setting is part of the Persistent Cache family, so it only becomes available when you use Persistent Cache, which is still off by default.
Along the same lines, recovering from persistent cache has been updated to preserve transaction consistency.
Our current opinion on the feature: we’re still a little wary about using the Persistent Cache. It’s a feature that is not very well understood. It’s a big ask to put a lot of trust in such a feature vs. sticking with tried-and-true best practices. The risk, as we see it, is that re-using a crashed file may carry with it damage that may only become apparent in the future, possibly at a point when no good backup of the pre-crash files exists anymore. Don’t rely on this feature alone if you are using it. Make sure you have a solid backup strategy that gives you enough restore points at a frequency that minimizes data loss.
If you have experienced crashes/hangs around operations that involve containers, then definitely test this release ASAP. Claris engineers have worked extensively on deadlocks in the DiskCache area.
When you use dedicated WebDirect worker machines, you can perform Java Garbage Collection on those workers from the admin console on the main machine (see below).
Logging
Top call stats and stats log are now on by default. I consider this to be a minor personal victory because I have been pushing for this for years now. Without logs we are flying blind, and many developers were afraid to turn on the logging because of the scary warning that was shown when you turned the logs on. You can read up on this in that linked blog post.
As a reminder, these logs collect metrics every 30 seconds, have a default max log file size of 40MB, and keep one old log when they reach their max size. You can adjust these settings from the Admin Command Line Interface but not from the Admin Console.
The client stats log is still off by default, and I highly recommend turning that one on as well.
If you have previously never enabled these logs on your FileMaker Server and you do an upgrade-in-place installation of FileMaker Server 21, then these logs will remain off. In this scenario, I do urge you to turn them on ASAP, which you can do from the command line or the API. The CLI command is:
fmsadmin set serverprefs UseStatsLog=true UseTopCallsLog=true UseClientStatsLog=trueThe all-important Event.log also received some much-needed attention and has been updated to include the following events:
- When performing recovery on startup using the persistent cache, uncommitted transactions are now reported in the event.log file.
- Enabling and disabling the HTTPS tunneling feature
- Events for preserving backups
- Events for the Let’s Encrypt SSL scripts (see more about that below).
If you are using any form of Event.log monitoring, then update your monitoring logic for these new entries. There is a new toggle to enable or disable the feature that separates the server-side script events from the other server events. The feature is not new. It was introduced earlier, but there was no Admin Console setting for it; now there is.
The default behavior is for a separate log for script events, but if you prefer the old behavior of having everything in the single Event.log, then you can enable the setting to force the old behavior.
We prefer the new behavior. We see many deployments where the Event.log is filled with meaningless server-side script errors to the point that they crowd out meaningful server events. Separating the two types of events into their own logs helps avoid this issue.
Last but not least, the log viewer that is built into the Admin Console now allows you to collapse the left sidebar to have more room to read the log entries.
Ubuntu Swap File
Think of a swap file as virtual memory that allows the operating system to swap out active memory to the disk when the memory use is under pressure. By default, many Ubuntu installations do not have a swap file enabled. We have seen some FileMaker Server failures on underpowered servers or servers under high load because of this.
To add a swap file to your existing server is easy. You can find the instructions here in our blog. FileMaker Server will now warn you during installation if there is no swap file and will give you the option to add one.
If the server already has a swap file, there will obviously be no prompt, and the installer will not try to adjust the size or swappiness of what is already configured on your server.
FileMaker Server defaults to a swap file size of 4GB and a swappiness setting of 10. These are not values you can set as part of the interactive installer.
If you want to have control over the swap file, then you can install one manually (see our blog post). Or, you can use the Assisted Install file mechanism, where you can specify values for both settings:
We prefer a setting of 5 for swappiness. On a scale of 0 to 100, the swappiness decides how aggressive Ubuntu can be with swapping out active processes to the swap file. 100 means very aggressive, and 0 means not at all. We prefer to be cautious and go for a low number.
Ideally, the size of the swap file should be determined based on the amount of RAM in the server, which is a topic we cover in our separate blog post.
Let’s Encrypt SSL Certificate
SSL certificates are cheap: a single domain certificate costs about $10 per year; a wildcard certificate will set you back $50 per year. Despite this low cost, there has always been a demand to support the free Let’s Encrypt (LE) SSL certificates.
Over the years, there have been several community-driven implementations of automating requesting and installing a LE certificate, and Claris now provides a set of scripts that does the same.
At the core of any process to obtain an SSL certificate is a verification phase where you must provide proof that you control the domain you are requesting the certificate for. Otherwise, I would be able to impersonate other entities and, for instance, ask for a certificate for fms.apple.com.
LE supports two mainstream verification processes: through http and through DNS.
The http challenge will ask you to place a file with a specific name and specific content in a specific folder on your server so that they can check that the file is there and that you thus control that server. The server is accessed through DNS using your domain name, so proving that you control the server also proves that you control the domain.
When using the dns challenge, you must create a TXT dns record with specific content on the DNS server for the requested domain. LE can then do a simple DNS check to see if that record exists.
Most examples that you will find use the http challenge. That is also what Claris decided to use since it is not dependent on the specifics of whatever DNS provider you may be using. But the DNS challenge is more secure, which we explain in this blog post. It’s all done with API calls and does not require any compromises on the network and server firewalls and port forwarding side of your network.
To use the LE http challenge, LE must be able to reach your FileMaker Server, and the server must have a publicly resolvable hostname. This means there must be:
- A dns A or CNAME record that points to your server.
- Your server needs to be reachable on port 80, albeit temporarily, at the moment of the request and each renewal.
- On your router, you also must set up port forwarding for port 80 to your FileMaker Server.
Those are three prerequisites that need to be in place. And from a security point of view, they are dangerous if you leave them in place beyond what is needed for issuing and renewing of the certificate.
The Claris scripts will temporarily disable the server’s firewall to allow incoming traffic on port 80, but you may also have other firewalls at the perimeter of your network that are almost certainly blocking port 80.
Do NOT leave port 80 open permanently just to make this work. Leaving it open will expose you to a ton of intrusion attempts.
You can install a choice of agents to generate the certificate request and interact with LE. Claris chose Certbot. However, FileMaker Server does not automatically install Certbot. You will need to install that client manually. The instructions are in the README file.
The scripts and the excellent README are in this folder:
FileMaker Server > Tools > Lets_Encrypt
The script will use the fmsadmin CLI to import the LE SSL certificate into FileMaker Server, so it must have access to your Admin Console credentials.
The username and password for your admin console are stored in the server’s environment (not in the script) if you want these scripts to run unattended. Or, you will be prompted when you run the script manually and there are no matching entries in the environment.
The README also explains the choices you need to make. In the request shell script, those options start on line 55. In the renewal script, the same settings must be configured, and they start on line 42.
PROMPT is the choice to make this script standalone or interactive. In interactive mode, you will be prompted to provide your FileMaker Server credentials. When you set this option to 0, those credentials must exist as a set of OS environment variables named FAC_USERNAME and FAC_PASSWORD.
Since your FileMaker Server needs to be restarted after importing an SSL certificate, the RESTART_SERVER gives you the choice to do this as part of this script or not. If set to 0 you will need to manually restart the server for the change in SSL certificate to take effect.
The DOMAIN and EMAIL options are self-explanatory. The TEST_CERTIFICATE lets you do dry runs to make sure you have the setup all correct. Only change this setting to 0 when these tests indicate that your environment is set up correctly.
Once you’ve set everything up and you are ready to request a certificate, execute the following script from inside that Let’s Encrypt folder (or specify the full path to the shell script in the command):
sudo -E ./fm_cert_request.shAnother factor to consider is that commercial SSL certificates are usually valid for 12 months. LE certificates are only valid for 3 months, so you will incur some downtime every three months as the renewed LE SSL certificate is imported; that process still requires a restart of FileMaker Server, so you will have to plan your downtime accordingly.
To renew an LE certificate, create a FileMaker Server System Script schedule to run the built-in system script Sys_Default_ReloadLetsEncryptCertificate.
This will obviously require that the FileMaker Server credentials are available as operating system environment variables so that the schedule can run unattended.
If you do not want to store your FileMaker Server credentials in the OS environment, then you will need to run the manual script at renewal time. To do that, execute the following script:
sudo -E ./fm_cert_renew.shTo reset the Let’s Encrypt process completely and start over from scratch, delete the Certbot subfolder in FileMaker Server > CStore and restart your FileMaker Server.
Block New Users
This is a tiny feature but comes in very handy during troubleshooting and go-lives. You now can prevent new client connections to your server:
Any existing connections will remain active and will not be disconnected until you disconnect them through the existing features.
Admin Console Changes
Probably the biggest change to the Admin Console is in the Schedules section. Backup schedules are now back in the same list as the other types of schedules.
That Schedules section was overhauled very extensively. You can now select which columns you want to see:
Other new features here may not be so immediately obvious, but they add a lot of good user experience. You can:
- Duplicate / Delete multiple schedules at once
- Filter each column
- Sort schedules on every column
- Run multiple schedules at once
- View better info on the last status of each scheduled execution
When you go to create or edit a schedule, that UI has also been thoroughly overhauled and now looks like this.
Elsewhere, there have been some impactful changes as well. The Custom OAuth section has been rearranged to provide a more intuitive experience based on whether you select OIDC or OAuth as the type of your custom identity provider. Not all input fields are relevant to both types, and the ones that are not required will now dynamically hide based on your choice.
In the same section, you can now upload a custom icon for your identity provider instead of having to provide a hard-coded path.
And because some Identity providers need it, you can also specify specific additional query parameters:
If you have been around the FileMaker platform long enough, you will recognize this next one as a comeback-feature: you can specify the owner for the server, and that owner will automatically be included in the emails for errors and warnings:
While you don’t have to use FileMaker Server to generate an SSL certificate signing request (CSR) at the start of the process to have an SSL certificate issued to you, the Admin Console can generate the CSR. In this version, you can also do that for the newer ECC certificates that FileMaker Server started supporting a while ago.
If you use Administrator Roles to delegate admin tasks to groups of sub-admins, you can now create different groups that act on the same folder. Before this change, the same folder could not be used by more than one admin role.
If you use any kind of OS-level scripting to detect and find backups and sync them to the cloud or otherwise move or copy them to other destinations, note that the folder naming for backups has changed. Backup folders now follow a naming scheme that includes the backup status. For example:
- While a backup is in progress, the backup folder will be named: XYZ_2024-03-02_1323_InProgress
- When a backup is canceled: XYZ_2024-03-02_1323_Canceled
- When a backup is completed, the folder name will not have a suffix: XYZ_2024-03-02_1323
Admn API
The Admin API sees some major updates as well. You can now upload and download a database through the API, which is a very welcome addition to the API toolset:
There are new operations to manage the external authentication through Custom OAuth identity providers and Sign-in-with-Apple:
And new endpoints to manage administrator roles:
And, of course, endpoints for the new server admin contact info and block new users features, and an updated GET/PATCH for persistent cache to include the new databaseServerAutoRestart option:
Data API
The Data API now supports the Set Error Logging script step. Note, however, that by default, FileMaker Server is set up to not allow this. Make sure to adjust these settings if you want to use this feature in your scripts. Do NOT toggle these on or off while you have connected clients, as these will restart their respective processes and disconnect active clients!
The log is in the Logs folder and named fmdapiScriptErrors.log. It lists the user account, file, and script name, plus the line number of the script that generated the error and the error number:
If you use monitoring tools and your server is on Windows, the number of connected Data API clients is now reported in the Windows Perfmon counters:
Weirdly enough, it is not in the Stats.log, which is still only listing Pro, Go, WebDirect and Custom Web clients.
When you create a record through the Data API, you have a new option named entrymode that allows you to override any field validations. This behavior is similar to what you can do in a script inside FileMaker Pro.
From the Data API help section on creating records:
There is a change in behavior when you use the Data API to perform a find, and there are no matching records. This change may break some of your existing code if not handled properly.
In FileMaker Server 20, when you call the _find endpoint and there are no records, the http response code is 500, with the FileMaker error code in the messages section of the return body and an empty response section.
With FileMaker Server 21, you will now get http response code 200 instead, the same messages section in the response body, but also a full response section:
If your code relies on the HTTP response, this change in behavior may break your code.
If you are using the Data API and you have noticed that the headers and data in the fmdapi.log are not properly aligned, then this issue is solved in FileMaker Server 21. Archive your current log so that Server can start a new one and the columns will be aligned properly.
FileMaker WebDirect
WebDirect sees some performance tweaks (more CSS caching), and support for the Set Error Logging script step. That log is in the Logs folder and named wpeScriptErrors.log:
See my notes above in the Data API section about the FileMaker Server setting that needs to be enabled to allow this script step to function.
Some work was done on the mobile experience:
- When you use WebDirect in a mobile browser, then these keyboards are supported:
- ASCII
- URL
- Number keypad
- You can now control the pull to refresh behavior: a new parameter has been added to the jwpc_prefs.xml file (in this folder: FileMaker Server > Web Publishing > conf).
Layouts will refresh when pulling down on mobile browsers when this setting is set to yes, which is the current and the default behavior. If you do not want layouts to refresh on the pull-down event, then change this setting to no.
Keep in mind that after changing the value, you need to restart the Web Publishing Engine.
On the stability side, you can now run Java Garbage Collection on each worker directly from the main admin console. Java is used heavily in WebDirect, so this is a good tool to have at your disposal.
Navigating These Updates with a Development Partner
Our team of FileMaker consultants are getting familiar with this new release and can help you explore new features and navigate what they mean for your application. If you’d like to talk with one of our team members, reach out to us.
