If you purchased your FileMaker Cloud server with user connection licenses, you may well wonder “Where do I get the client software to connect to my server?”.
We’ll discuss how you can use a one or three year reserved instance for your FileMaker Cloud instance. This can shave 30% or more off your AWS instance charges.
If you had started a FileMaker Cloud deployment, but lost access, accidentally closed the page, or had some other issue that caused the process to stop, you may be able to restart your deployment easily by going to the AWS Marketplace and checking your history.
Although setting up your AWS account and creating a new FileMaker Cloud instance is a fairly easy process, it does have dozens of steps, and a few places where you could easily take a wrong turn. On this post we’ll go through each step in the configuration of your Amazon AWS account and requesting your first server.
Continue reading Step-by-step for FileMaker Cloud
Intro: SSL Basics
SSL certificates are a very common way to secure client/server network connections, and the FileMaker platform has made use of them for many years. With version 15 however, FileMaker has made a number of security changes, in handling SSL and certificates, on both the server and the clients. But where do they come into play, and how might this affect your deployments?
Recently we’ve been thinking about how we can better monitor the collection of systems that we manage. These can be client servers with very diverse configurations, access, or functions. Additionally, we have our own array of systems, almost as diverse as our clients’.
Trying keep track of all this can easily become a source of headaches, but we have been gradually integrating tools into our toolkit to allow better monitoring. One which we’ve used for a while now is Facter, a Ruby based library of routines for collecting “facts” about your servers. Normally this is used as part of the Puppet deployment system, which we also use, but it can be used independently too.
As an aid to improving the security of your server, Fail2ban is an open source component that checks for signs of abusive activity in your logs, and when these are detected, blocks an address (or possibly a subnet) for a given period of time. In May of ’13 I blogged about how to set up Fail2ban rules to check the FileMaker Server event logs (http://buzz.beezwax.net/mVfrR7).
Various times I’ve needed to do some quick summaries of how a given server and its databases were being used. When using Mac OS X, I may use shell commands to get a quick summary of what’s happening on a particular server.
Here’s one that came up just recently. Client wanted to know what accounts had been used to access databases, but they were largely using generic account names.
As part of a shell script I’m cooking up, one of the required tasks is to list all currently hosted database files on a Mac OS based FileMaker server. This may get deployed over multiple servers, and I want to keep it as simple and trouble free as possible.
I was looking for a way to monitor client usage of FileMaker Servers over an extended period of time.
We can get a little bit visibility into this by enabling the Access logs, but these only show when users log or out and open or close databases. There is an option however in the Admin Console that can show you real-time usage:
It turns out that when the Log client statistics…. check box is checked, this data is logged to (on Mac OS) /Library/FileMaker Server/Logs/ClientStats.log. But only when this check box is ticked and the Clients tab is selected. (This behavior has changed in FMS 15 — it will now stick between reboots).