cbum

Members
  • Content count

    138
  • Joined

  • Last visited

Everything posted by cbum

  1. Hi Wim, thanks for your response - you were correct. I only got back now, and the folder containing the DB files indeed lacked fmserver as user. I was able to simply use the GUI in the cmd-i box to add fmserver with r&w privileges, applying it to all contained files, and all went back to normal. I had done this using chown & chmod a few years ago, so I was pleasantly surprised the GUI worked as well. It remains unclear why this corruption occurred, as mentioned, I had done both FMS and MacOS updates at the same time in a rush to get out the door...
  2. I updated my FMS15 from 15.0.2 to 15.0.3 yesterday (on MacOS Sierra & latest updates) running on a MacPro. I shut off the DB before updating. Today, my host files are unmodifiable. Anyone see this? Did the files get corrupted? They behave normally otherwise... I am traveling, so I can't troubleshoot directly, but I can use the server admin console remotely.
  3. Thanks, they are not paused. Host is not asleep. ne other item: I had just updated the OS with its latest security upgrade before updating FMS to 15.0.3. Could there be some complications with the new security patch?
  4. Our university hospital IT is mandating that all Mac servers that contain PHI be encrypted using FileVault. There is a longstanding and strong recommendation by FMI and posts on this board advising against this for FM server, although there are also some dissenting voices. The relevant passage on the FM Knowledge base pages (http://help.filemaker.com/app/answers/detail/a_id/9650) reads: "FileVault: FileVault is a feature that performs on the fly encryption and decryption of data on your hard drive.. However, this added level of security requires additional processing power. Because of this, it is recommended that FileVault not be used in conjunction with FileMaker Server and your FileMaker databases." (Last Updated: Jan 13, 2016 01:47 PM PST) 2 points to mention: First, no discussion of actual incompatibility or corruption risk, just a requirement for extra processing power, suggesting this is simply a possible performance issue. Some of the comments I heard at Devcon and read here suggest much more serious issues - I would appreciate any information or discussion on the specifics here. Second, the way FileVault is described, i.e., "on the fly encryption ... decryption" suggests this entry and general discussions recommending against FV use are based on the old FileVault v1, which was replaced with FileVault2 in Lion (!) quite a few years ago. According to a discussion yesterday with Apple tech support (with escalation) the current FV2 uses encryption at rest, not on the fly, making it similar/equal to FM's own encryption offering, and this has been the case since 2011. (http://www.cnet.com/news/about-filevault-2-in-os-x-10-7-lion/) Nevertheless, a discussion with FM tech support yesterday revealed that FM's position on FV is unchanged, and they did not answer my question if this was based on testing with FV2 (with encryption at rest, which should have no performance or other impact on FMserver after the initial boot up) or simply reflects that FM has not revisited this problem since FV2 came out in 2011. I would appreciate some clarity on this issue. My IT security people are not satisfied with the explanations I tried to give them describing FM's position and are not willing to substitute their current requirement with a third party solution they know nothing about, unless I can give them a coherent and documented explanation.
  5. Apple tech support called back with feedback from their engineers, who echoed what they had said: FV2's EAR means that except for boot up and shut down, there is nothing interfering with running apps. FV2 encrypts the drives at the logical volume level using core data at shut down. And indeed files can be copied unencrypted from a logged in account, so be aware of that. The engineer asked for details about the FMS issues that had been reported, so I told the support guy to copy and paste the most informative passages from this thread to the engineer. I will update if I hear anything back.
  6. Josh & Mike, Thanks for your comments. The issue that files on a logged in mac are unencrypted and subject to getting copied to a thumb drive etc is definitely real, and may be a strong argument against FV in certain situations, but is not relevant here, as we are not concerned about Mr. Robot-style cyberwarfare. My data does not leave the server, users work on it remotely (using SSL). IP sec is just concerned about someone breaking into (locked) offices and grabbing computer hardware to sell. They don't want unencrypted PMI on stuff that can be carried away, so boot or other drives need to be encrypted by an approved method . PMI does not have commercial value of the kind usual thieves would care about, so I don't see anyone breaking in and sticking in a thumb drive to covertly steal PMI from a running server. Josh, your experience with FV on 10.10 and 10.11 does not jive with what Apple is saying. I called them again this morning and gave them the link to this thread. They maintain that FV2's EAR only affects boot up and shut down, there should be no processes interfering with the FMS engine once it's running (I'm a bit confused about your point about opening and closing files showing strange effects - I don't usually open or close files, they keep running once FMS is running...?) They read your posts, and do not see how FV could be involved, but they agreed to get in touch with the engineering guys to discuss possible low level processes etc that are not usually discussed. I will let you know if they get back to me.
  7. According to Apple, is decrypts at boot up, and encrypts at shut down. While the server is running, it's transparent and nothing is happening. Do you know anything different? As such, it's simply designed as safety against physical theft, nothing else - IT sec is fine with that, as all network traffic is secured by SSL by FMS. I'm assuming that's how the FM version of encryption at rest does it as well, but I don't know?
  8. Wim, I know about "FMS requires exclusive control over the files" - that's why I don't use Time Machine as backup etc. But you guys did read my post, right? Where I mention that FV2 does encryption at rest, not on the fly, exactly what is said about the FM solution. Where do you see "Apple FV's routines ... being ... smart enough to interpret what FMS is doing" creating a problem if that is true? According to Apple, 2 days ago, nothing is happening regarding FV routines while FMS is running. That is what encryption at rest means, after all. What is vague or unclear about that? Or are you just telling me Apple tech support is lying to me? Josh, re: "drive is unlocked and data unencrypted when booted": How is that different from the FM version of encryption at rest? Isn't that exactly what it does as well? re: "It is my understanding that some of the processes involved in FV 2 CAUSE problems with FMS. Not sure exactly what it effects..." Right, that is what FM people tell me (except they haven't specified FV2 vs FV1, to me at least), so why won't they confirm that that is happening with FV2 as well? Tech support refused to be specific on that point. And if that IS the case, why not update the knowledge base section to state that, so I can show that to my IT sec people? I do not find it intuitive that there are FV2 processes interfering with FMS if it only does anything on boot up and shutdown (that is exactly how the apple tech guy represented it). If there is an interaction at those 2 times, then first of all, JUST SAY SO, and second, there is already a setting in FMS that prevents the server to start at boot - I use it because some of my disks are external and take time to spin up, so that should be easy to mitigate. There was an entire session at DevCon about how to help make FMS more easily accepted in institutional environments - "Just use the FM option" without rational explanation is not helping to be responsive to IT sec requiring FV on macs.
  9. Josh, a simple statement that their recommendation is based on FV2 rather than FV1 would be a good start. As described above, the current info in the knowledge base article strongly suggests it is not relevant to the current version of FV ("FileVault is a feature that performs on the fly encryption", which is clearly wrong), which has been out for over 5 years, and FM tech support is unwilling to explain the current entry or indicate that it relates to FV2. As it is, I'm getting NO information. We can't go off what info we have, since there is none.
  10. Wim, Apple, as the OS provider, is 1st party for them, and they have vetted and accepted FV as offered by the OS a option for their security requirements. (It's already a win that they even consider Mac as a useful platform, believe me). For them, FM is simply a SW vendor for that platform, and they don't want to check every other option out there, I assume. Regardless, I think it's reasonable to want to know what the strong antipathy to using FV with FMS is based on, and particularly if this even applies to the current version available since 2011, and I can't get any useful response from FM. I'm hoping someone can fill in the blanks. There is no "FM position" as you suggest that I can find beyond the quote I included above, which I hope you agree, does not amount to much and sounds like it is out of date and not applicable to the current FV2.
  11. Wim, quick update: portscans showed 16000 was not active (16001 was on the server itself). Several calls to Apple and FM were useless, no info about how to turn on the port. Finally, a FM tech told me there was a FMS update that was not usually reported with the usual check for updates routine (14.0.4b). He walked me through not just stopping the DB engine, but using terminal to stop all FM processes, applying the updater. That fixed the issue, and port 16000 suddenly showed up as visible on portscan.
  12. Any experiences on the latest El Capitan upgrade (10.11.5)?
  13. I'm having the same issue mentioned in the first post (not having access to the Admin Console from a remote machine, while able to access it locally, FMS14 on Os X.9). Do I need the web server to be installed to use admin console remotely? Since when? If not, what is the issue preventing me from using remote admin console? As far as I know, no firewall changes were made to the environment (University LAN), but I am trying to check that; anything besides port 16000 that needs to be open? thanks
  14. Our University IT is now requiring MacOS users to encrypt all storage devices. What I found on the FM board (http://help.filemaker.com/app/answers/detail/a_id/9650) is the recommendation NOT to enable Filevault due to the performance hit, but no indication of the severity of the effect. The recommendation is indistinguishable from being part of a laundry list of generic recommendations to improve performance (get a fast drive, enough RAM etc). Any experiences to help guide me here? thanks.
  15. Thanks Steven, that would be my preference as well. Unfortunately, I do not know if that will satisfy the IT demands, given that they may want to check off their checkboxes. That's why it would be useful to have some examples, even anecdotes, as long as they provide some metrics and details on the setup, that could serve as signposts for what to expect, even if it is quite clear that there is no generally valid answer given all the variables involved.
  16. Wim, I have the same problem, with the twist that I know that one of the fields contains unique values. So I don't understand what you mean with "FM will attempt to produce a unique key "...? It should be able to based on what I know. I was assuming it was not working because there was no "designated" unique key on the SQL side, is that not the case?
  17. Variation on the theme: I can connect to my FMSA14 (on MacPro running 10.9) Admin console with Safari on a Mac running 10.9 at the office (within the same LAN), but when I try from home, Safari on a Mac running 10.7, I get this when I click on start admin console after connection to the server with https<IP> : Request-URI Too LargeThe requested URL's length exceeds the capacity limit for this server. I am trying to connect using <IP>:16000/admin-console. The server is using SSL, with the self-signed default CA. Anyone see this message before?
  18. Just updated my FMServer advanced 13 (FMServer13.0.10.1004, latest available patch), and while I can connect with FMA 13 clients, my =FM12 clients no longer connect - whats up?
  19. Simply missed a FM12 security patch.
  20. I'm using replace field contents to update an "ID" field by getting it from a related table (related by other identifiers) that has the new ID. That works fine, except that it replaces the field with a blank in cases where the new table has no matching record. Is there a way to avoid that? thanks
  21. As stated above, no idea where this came from. Last successful edits performed a few days ago, today, no modifications allowed. Logged in as admin remotely as well as on the server itself, same behavior. Can't change anything in the file, or in the security settings etc. This is on the MacPro running 10.6.8, latest available OS patches, server version 11.0.5.510, running with IWP, all other web options off. Security: FM accounts only; List only authorized DBs; SSL enabled. I did install the SSL patch for 11 several weeks ago, but no adverse effects were noted at the time... Any ideas welcome...
  22. Hi Wim, you are correct, I eventually figured that out after posting here, but it has gotten pretty strange since. Just got off a long discussion with FM tech support, and I'm back up and running, but we both agreed I should not be able to... Briefly, my setup is I'm running FMS on the boot drive, using alternate folder for the db files, which are on a second HD. FMS backs up the files to the boot drive, where they are copied by Retrospect to tape. A few days ago, I had modified privileges to another subdirectory of the 2nd HD to allow lab members to upload important files for backup, and inadvertently got too high in the hierarchy and included the FM data folder -> no more write access. It was not apparent for a few days, possibly because the drive with the FMS was untouched and it could continue operations etc. Only when someone wanted to actually make a change to one of the db did the issue manifest itself. My problem now is that I don't understand enough about the OS (plain, not Macserver) to allow my to restore the fmserver user and fmsadmin group to the folders in the secondary drive hosting the dbs, i.e., these items do not show up in the get info popup when I click the +button. (they are present on the main drive in the FM-specific folders). Since the console was also blocked from doing anything to the files, but was allowed to close them, I manually copied the closed files to the main drive. After deleting all files on the second HD, I was finally able to get to the DB server config window in the admin console (I was getting an error that someone was already using it before), I inactivated and reactivated the alternate path for the db folder. Initially the path would not validate, until I manually added the "Admin" group to all folders in the path (that is the OS admin, not fmsadmin, which is still unavailable on the second drive, for reason), then it validated correctly, and I was able to use the upload db command from the admin console to reload all dbs, which are now functioning normally again, as far as I can tell. The weird part is, when I check the sharing/permissions of the db folders or the dbs themselves, neither fmserver or fmsadmin are listed! !! I'm assuming somehow putting in the OS admin group allows FMS to work with the path and the files, but this does not make any sense...
  23. Just talked to FM tech support, they currently have no guidance on this. Anyone have any comment on if/how this affects the server? I just read this post on the FM company forum: Eliminating the POODLE Vulnerability in FMS 13 on OS X Forum post posted October 21, 2014 by JohnDCCIU, last edited October 21, 2014 47 Views Title: Eliminating the POODLE Vulnerability in FMS 13 on OS X Your post: I did a little playing around to see if I could eliminate the POODLE vulnerability in FMS 13 running on OS X. FMS 13 installs its own version of Apache, it doesn't use the version from Apple as it did in previous versions. Out of the box, FMS 13 is vulnerable to POODLE. I turns out that the FMS web SSL functionality is controlled in an Apache config include file at /Library/FileMaker Server/HTTPServer/conf/extra/httpd-ssl.conf I edited that file with TextWrangler and applied the POODLE mitigation (adding "-SSLv3" on the end of the existing "SSLProtocol" line), restarted the server, and poof: no more POODLE vulnerability. My server seems to be fine afterwards, but YMMV, so use at your own risk, and only if you know how to edit config files without mucking things up (and always make a backup of the file before editing regardless). It's uncertain if FMS will eventually overwrite that config (since it manages it itself), either during normal operations or during a future upgrade (unless FMI incorporates that into the next upgrade, which they should), but so far the mitigation has survived a few reboots, so it seems stable. You can test your server's POODLE vulnerability at http://whodig.com/poodle/ or for a more comprehensive SSL test (including POODLE), use https://www.ssllabs.com/ssltest/ John
  24. To answer my own question ;-) Software Update: FileMaker Server 13.0v5 (OS X) Disabled SSL 3.0 in the Apache web server used by FileMaker Server. SSL 3.0 has a known man-in-the-middle attack vulnerability referred to as “Padding Oracle on Downgraded Legacy Encryption” (POODLE).