[MAGNOLIA-1959] Leopard (osx 10.5) issues Created: 11/Dec/07  Updated: 15/Dec/09  Resolved: 15/Dec/09

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicate
is duplicated by MGNLEE-153 Installation on MacosX and Linux fail... Closed
relation
is related to MAGNOLIA-2958 (Local?) Magnolia 4.1/4.2 AdminCentra... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Leopard's application level firewall :

Leopard's (OSX 10.5) firewall behaves significantly differently than the firewall shipped with OSX 10.4. The symptoms are that Tomcat seems unreachable ("kCFErrorDomainCFNetwork:302"), but unfortunately no log message clearly identifies the issue.
In some cases, Tomcat is only "partly" reachable; pages will appear, but some of the resources can't be loaded (broken images, missing stylesheets, ...) Another symptom is that you have to kill Tomcat to stop it (-HUP works), because the shutdown script can't reach the running process either.

We've tried a bunch of variations on the firewall settings, but nothing really help.

Solution

Well, it's pretty simple! Update to OSX 10.5.8 !

If you're using Snow Leopard, the issue was also present until 10.6.1, but is fixed as from 10.6.2 !

Some interesting links:

"Max.files opened"

There might be some "max.files opened" issues, with settings which are different from Tiger(10.4), although this hasn't been reported in a while.



 Comments   
Comment by Magnolia International [ 30/Jul/08 ]

– edited issue description and cleaned up comments for clarity and usefulness.

Comment by Philipp Bracher [ 05/Feb/09 ]

Thought I share that with you. Quoted from: http://db.tidbits.com/article/9294

There's one behavior that caught me completely by surprise and calls for an immediate fix. If you have the firewall set to control applications, those applications that don't already have their code signed are signed by Leopard when they access the network. (Code signing is the process of affixing a digital signature to an application, such that the operating system can tell if the application has been modified by malware, because the application's checksum would no longer match the checksum in the signature.) If the application changes itself while running, as Skype does (and as some other applications do too), it won't

An other article saying the same: http://www.heise-online.co.uk/security/Apple-documents-Leopard-firewall-functionality-and-holes--/news/98695

The new firewall recognises applications by means of digital signatures. If a rule is required for an unsigned program, the operating system generates one on the fly. This ad-hoc code signing modifies the program file on the hard drive. This means that programs like Skype or WoW which test their own integrity may subsequently have problems due to a modified checksum. A problem which Apple fails to mention are programs in interpreted languages such as Java or Perl. Here, the user can only define rules which relate to the runtime environment itself, and therefore to all Java or Perl programs.

So the application might indeed be blocked by the fact that we write into the repository or change files in the webapp. None of the articles tells clearly how one can get rid of that behavior.

Comment by Philipp Bracher [ 05/Feb/09 ]

Consequently I tried to move the website outside of tomcat which didn't help at all.

Comment by Philipp Bracher [ 05/Feb/09 ]

It seems to work nicely if one has only one instance (a author or public instance) in the webapp.

This might also point to something else than the firewall (to many open files, sockets, to many threads, ..). It is also suspicious that not all requests are blocked.

Comment by Boris Kraft [ 05/Feb/09 ]

I have installed two tomcat instances, one with public and one as author and this works without the above issues.

  • apache-tomcat-5.5.27
  • osx 10.5
Comment by Tom Wespi [ 05/Feb/09 ]

See http://discussions.apple.com/thread.jspa?threadID=1449787&tstart=195
So I increased the maxfiles to 4096 (launchctl limit maxfiles 4096 unlimited) and the maxproc to 2048 (launchctl limit maxproc 2048 unlimited).

After this two instances are starting fine.

osx 10.5.6
EE rc3
tomcat 5.5.27

Comment by Boris Kraft [ 05/Feb/09 ]

we might want to add this to the magnolia-control script for osx (if it works)

Comment by Christian Ringele [ 05/Feb/09 ]

The "limit maxfiles 4096 unlimited" value didn't help on my machine at all.

Comment by Philipp Bärfuss [ 15/Oct/09 ]

Seems as if the so called 'firewall' issue has disappeared with Magnolia 4.1.1 and OSX 10.5.8. In case you still encounter such problems please let us know.

Comment by Philipp Bärfuss [ 15/Dec/09 ]

The issue is not occurring anymore on the latest OSX versions: 10.5.8 and 10.6.2

Generated at Mon Feb 12 03:32:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.