IT Enquirer has a short preview of Mac OS X 10.4 Server, including screenshots of the new Firewall rules and Stealth Mode and advanced rules.
IT Enquirer has a short preview of Mac OS X 10.4 Server, including screenshots of the new Firewall rules and Stealth Mode and advanced rules.
‘Bout time!
I see the mac server comes with a FireWall,
Does Windows 2003 server does too?
“Does Windows 2003 server does too?”
I think everything does at this point.
Mac OS X, even the client version, has a firewall. In fact, all Mac OS X versions since beta (2001) have IPFW installed. You could either use the GUI or hack up the IPFW settings by hand if you’re a BSD guru.
Was I the only one that thought that this article was poorly written and absent of any real information. I’m surprised that OSNews would even link to it.
And in other news:
10.3.7 was released tonight. Installed without problems on my two Macs.
I wonder if there are any plans to eventually switch to PF, as most of the other BSDs are doing? Of course, I understand the difficulty, stemming from the kernel differences (contrary to popular belief, the OSX kernel and the FreeBSD kernel are not exactly the same….in fact, they’re quite different).
The iChat server is jabberd, too, no?
Where’s some info on Netinfo? Is it still the same old stuff, or have they integrated something new (e.g. ldap)?
It’s certainly possible to port PF to Mac OS X, the main issue is that, afaik, the Mac OS X kernel and TCP/IP stack are not open source. This poses two problems.
The first one is technical. It’s hard to impossible to add the proper hooks that call PF if you can’t modify the source and rebuild the kernel from source. If there are binary APIs, they might not be perfectly suitable for PF. Also, testing and debugging on a developer level becomes very tiresome if you don’t have all (even just slightly) related modules as source, to study effects and add debug output.
The second one is motivation. The reason, for me, to spend time on a PF port is to get something back in return. More user base means more testing, more useful feedback and bug reports, leading to fixed bugs and improved quality in the base code. Without an open source license on Mac OS X, this feedback mechanism won’t work. If some developer, under NDA and paid by Apple, produces a binary-only module of PF, user feedback will be mostly unusable to anyone but that developer.
You have to talk to Apple. It’s unlikely that they’ll open source their kernel. As a consequence, they don’t get free man-hours from this open source project and have to invest their own development time in a port.
The BSD license on PF allows them to do that. None of the open source developers will have bad feelings if they produce a closed source port and maintain it themselves, not feeding back changes and improvements. But if they’d like participation from the open source developers, they have to understand that we’re not driven by market share but the goal to improve our code. If we don’t see improvements (or can’t use them freely) as a result, it would be a waste of our time, even if it makes thousands of Apple users happy.
The XNU-Kernel of MacOS X IS open source, look at
http://www.opendarwin.org/en/articles/building_xnu
I’ll have to read what sources those are, precisely. Thank you for the link.
From a support perspective, it’s important that you have the very same sources that the binaries your users are running were built from. Not some (even binary API compatible) abstraction, but the real thing.
For example, most bug reports I get come from users who use not the latest code, but one of several older releases (or snapshots of a given date in the past). Often, I need to check out precisely the code revision they are using to reproduce and analyze the problem. On different code revisions, the same problem can show different symptoms. Often, a change in the current kernel code outside PF affects PF in some unexpected way. Hence, to ensure release quality, developers need to run precise current versions for testing before a release.
Some non-current stripped source snapshot is not sufficient, you really want real-time read access to the real source repository (including the change logs) to do the work efficiently, or you’ll quickly get frustrated hunting down ghosts.
I’m not saying XNU is not the real thing, I have to check it out first
Mac OS X kernel is indeed open source, and been so since the beginning. wtf are you talking about !?
What he is talking about is that he doesn’t know much about OS X.
Ok, so my understanding of Mac OS X’ open sourceness might be flawed. Humour me, show me where on http://www.opensource.apple.com/darwinsource/10.3.7/ I can find the implementation of, for instance, ip_input(). This is traditionally found in sys/netinet/ip_input.c on a BSD system. Like, I’d like to see the full implementation of ip_reass(). It might look like http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_input.c?re…, at least it should share some common struct or function names.
I might just be blind or too unfamiliar with the file hierarchy. Point me to the file, and I might even try to hook PF into it