Jump to content

JohnDCCIU

Members
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About JohnDCCIU

  • Rank
    novice

Profile Information

  • Gender
    Male

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    High Sierra
  1. JohnDCCIU

    Memory Leak with FM 15.0.2 and Email Plugin?

    FYI, this turned out to be an issue with FileMaker Pro v15.0.2: apparently it leaks memory doing stuff related to plugin APIs. As soon as I updated to v15.0.3, the memory stayed at a minimal level, less than 300MB.
  2. I have a listserver-type system that polls IMAP accounts for new messages and then relays those messages to subscribers. It uses the Email plugin and runs 24/7. It worked fine with FileMaker 14 under Mac OS X 10.11. I recently updated to FileMaker 15.0.2 and macOS 10.12.2 and while the system still works fine, it seems to be leaking memory like crazy. The "Memory" (as shown in Activity Monitor) used by FileMaker starts around 600MB but quickly climbs over the next few hours to over 10GB, then keeps going to over 32GB. The machine only has 4GB of memory in it, so now sure what that number represents (the "Real Memory" remains under 1GB), but it just keeps going. Eventually, macOS puts up the "Out of Application Memory" dialog and halts everything. The only "fix" at that point is to kill FileMaker and start the process again. The Email plugin remained at v2.17, so I'm not sure if FileMaker 15 or macOS 10.12 triggered the issue. Has anyone else seen this issue? I haven't seen it with of my other FileMaker 15/macOS 10.12 upgrades except for this one, which happens to run the Email plugin around the clock. That could be coincidental, but it's awfully suspicious. Thanks, John
  3. Unfortunately, I updated and now FM clients can no longer see hosted databases with the SSL connections enabled. Here's what I posted in the FileMaker Support forums; maybe someone here has seen this or has an idea on how to resolve it? I've been running FMS 13v1 successfully for awhile on OS X 10.9 (now at 10.9.2, fully patched), with "Require Secure Connections" checkmarked in the Database Server section and a commercial SSL cert from GoDaddy installed with fmsadmin. I applied the first "emergency fix" that FMI put out, which involved copying files to certain places on the server. That also worked fine. I saw that they released a real updater and applied that tonight....and that seems to have broken something. Now if "Require Secure Connections" is checkmarked, hosted databases do not appear in the FM client (even a client running on the same machine as the server). The server shows up under "Local Hosts", but no databases appear. All databases show as opened and Normal on the server, and if I uncheck "Require Secure Connections" and restart the server, all the databases appear just fine. Note that I'm not talking about Web Services: this is the core fmnet protocol functionality. However, it also is broken (The server test page for both WebDirect and PHP fail) when "Require Secure Connections" is enabled in the core server, and it starts working again when "Require Secure Connections" is unchecked. At the suggestion of one of the moderators on the FileMaker Discussion Forums, I generated a new key with the CERTIFICATE command, revoked and re-keyed the cert, then imported it again, rebooted the box, but that didn't fix the issue either. Is anyone else seeing this? Any ideas on a fix? I wouldn't want to run my server without SSL security for very long.
  4. First, just wanted to say that we've been using SuperContainer successfully for over a year and have been extremely happy with it; it's a great solution and has singlehandedly enabled us to do systems in FileMaker that we otherwise would not have been able to do. I just updated our server to v2.831, which apparently changes things to HTML5 because of bugs in OS X. The effect that we've seen, however, is that when a user clicks on a PDF image in the SuperContainer webviewer field, it now opens the file in the user's browser rather than in the local copy of Adobe Reader. This change is a little disconcerting for the users, but they could always open it in Adobe Reader via a secondary step. The big problem is that Safari generates this giant red phishing warning dialog (see attached screenshot) when it tries to open the SuperContainer link, because of the password embedded in the link (which has always freaked me out, but it was never "in your face" with Adobe Reader, plus we use UUIDs as ersatz passwords). This is freaking users out and obviously isn't acceptable behavior from the system. In addition, it's exposing that "password-in-the-link" underbelly of SuperContainer that I'd rather not have visible out there: I worry that some auditor is going to tell us to shut it down, regardless of my protestations about UUIDs and how that protects the data, etc. Firefox users don't see the phishing warning; instead they see a dialog warning them that they're logging into a server as "SuperContainer" (my SC server's username), and it's confusing them as well, plus once again bringing attention to the URL sitting there in a browser with the password in it. I understand the need to work around the OS X bugs, but how can we get back to having SuperContainer links open in Adobe Reader rather than Safari? Thanks, John
  5. From the point of view of these remote users, OD accounts really aren't any different from local server accounts: they will login using their credentials, but won't have any idea that their password has expired. I see some logic in FMI's current assumption that all users authenticate first to the OD before trying to authenticate to FMS, but in at least some cases, that assumption is flawed. I'd like to see them make FMS into a fully functional client to the OD/AD server (which is of course what it is) that reports credentials issues to users and allows them to change their OD/AD passwords. WGM and the DC don't handle user notifications and password changes: the clients handle that. The client can be the OS, of course, but FileMaker is also acting as a client, and it should have that same functionality IMO. Anyway, I appreciate your help in nailing this down; this really helps in determining what my current options are.
  6. I could do that if it made a difference...would FileMaker properly notify users of expired passwords that they need to be changed, and allow the users to change them, if it's all local accounts and groups on the machine? I didn't think it would make any difference if the accounts were external to FileMaker itself, regardless of whether they were OD accounts or local OS X accounts....
  7. We have staff users all over the place: at home, at our sites both tiny and large, placed in our 12 far-flung school districts, all over the state, etc. Most don't "sign in" to our network or a central OD/AD controller: they just login to their computers with local accounts and use FileMaker, FirstClass, and MS Office. We do have such a centralized system for our student laptop initiative (all OD with Mobile Accounts) for the purpose of central control, but none of them need/use FileMaker. I guess FMI is assuming that kind of centralized system is taking care of things up front, and that probably is a majority of cases so it's probably a reasonable one. I suppose that I could make a major change in the way that we do things and centralize all of our staff authentication for OS logins, but that's a huge job when we just want to be able to do FileMaker authentication via an external server and have it handle the password stuff. In any case, thanks for all of your insight and advice on this; it's much appreciated and has given me quite a bit to think about.
  8. I discussed this via email with the author of the very cool FileMaker utility called "Account Manager". It seems that there's no hook into the FileMaker login interface for developers, so there's no simple way that a FileMaker-based system can determine when an unsuccessful login has occurred. Thus it would seem currently impossible to have FileMaker disable an account or take any other action based on unsuccessful logins. So it seems that I'm stuck with External Authentication, as clunky and support-intensive as it will be. I may have to hack something together to continually parse the OD PasswordService log, associate usernames with email addresses, and email the user when various messages come up. Ick. It really seems like FMI hasn't thought this External Authentication thing through very well, at least not in the context of providing necessary notifications and the ability to change passwords to FileMaker users.
  9. Thanks, I ran across that utility and that may be what I can use to allow users to change their passwords...but how will they know that they need to change them? All other OD clients tell the user that a password needs to be changed....except for FileMaker. It seems to me that it should parse the return from the OD/AD server and at least tell the user what's going on, if not provide the function to change the password via the FileMaker login dialog (same as a local password). I can educate the users and do it this way, but it will be very support-heavy and generate a lot of calls, no doubt. This seems like a lack of functionality/laziness on the part of FMI. I guess they count on most users in this kind of situation also having access to AFP/SMB shares and the OS takes care of notifying the user and making them change their OD/AD password, but that seems like a flawed assumption. Even if the users had access to both shares and FM databases, confusion would reign if they accessed the FM databases before hitting the shares.
  10. There are no auto-entered credentials in this file, and if I login with any other invalid username/password, it denies access. This situation only occurs when the OD server replies "password change required", as shown in the OD server's PasswordService log: FileMaker immediately allows the login (presumably based on the "RSAVALIDATE: success"), but it takes no action on the requirement to change the password, which it should if it was being a proper OD client that integrates with External Authentication (as it claims to be). By contrast, a call to the simple chkpasswd utility generates the same log entries in the PasswordService log, but the client properly denies the login (although it also doesn't notify that a password change is required, but what do you want from chkpasswd ;-).
  11. One of the critical things is avoiding dictionary attacks by disabling the account after X unsuccessful logins. Could that be part of the system? I was actually trying to avoid creating a development project; all the advice that I've seen says that if you're looking for comprehensive authentication, then go External Authentication and let OD take care of it....except it seems for when the passwords need to be changed, which FileMaker doesn't seem to support. The other problem is that FileMaker seems to ignore OD's admonition that the password needs to be changed; it still lets the user login. Tools like /usr/libexec/chkpasswd say "Sorry" in this state, but FileMaker ignores it and allows entry. This seems very bad to me....looks like FileMaker is NOT a good OD client, unless I'm missing something.
  12. IT Auditors from the State have descended upon us and are insisting that our FileMaker databases be setup to: 1) enforce a minimum password length, complexity, and age. 2) lock usernames after 5 incorrect login attempts I don't see a way to do that using internal FM authentication, so I've experimented with External Authentication in OS X Server OD. Everything seems to work, except that the FileMaker login doesn't enforce the OD password changes/expirations/etc. It seems to happily authenticate the first time, even though OD says that the password must be changed the first time. Many of my FileMaker users have no access to anything but the FileMaker databases, so I need FileMaker to notify the users that their password has expired, enforce the OD length/complexity requirements, let them change the password, etc. Is any/all of this possible? If there are holes in what FM with External Authentication can do, can anyone suggest a solution that would let me do what I need to do? Thanks for any advice.
  13. JohnDCCIU

    FM 8 Server Scripting

    I think that the command you're looking for is "fmsadmin", not "fmserverd". The former is a command to control the latter. Typing fmsadmin by itself at the Terminal prompt will give you further information on how to get syntax, etc. You can use systemstarter to stop and start fmserverd directly, but I don't think you'll need to do that if you use fmsadmin.
×

Important Information

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