OS X 10.5 Server comes with a Radius server, but at the surface, it seems that Apple only ships with support for wireless access stations. However, the foundation is a fully working FreeRadius server.
When trying to get the Radius server to work together with our Checkpoint firewall for VPN authentication, I found that the Radius server tries to authenticate the users against the /etc/passwd file. However, for authorization, it correctly queries the OpenDirectory. I opened a support call with Apple, and I eventually received the following instructions to change the behavior.
Read on to see the response I received from Apple...
This one is simple, but can save some incredible headaches.
When installing OS X Server 10.5, you are presented with a few different install options. If you plan to use Apple Remote Desktop with your machine, you should choose Advanced. The standard install will only allow Screen Sharing to be used.
[robg adds: A friend who administers Server tells me "one can activate ARD via the kickstart command, logged in via ssh, but Advanced indeed activates ARD right after configuring."]
I was finally able to figure out how to disable SSH access to a user account, but still allow SFTP to occur. Edit /etc/sshd_config, and add this section:
Match User sftponly
AllowTcpForwarding no
X11Forwarding no
ForceCommand /usr/libexec/sftp-server -l INFO
Replace sftponly with your short user name, then save the file and quit the editor.
[robg adds: You'll probably have to restart Remote Login in the Sharing panel to make these changes take effect, but I'm not sure of that, as I haven't tested this hint. It's categorized as an OS X Server hint, but I have no reason to think it wouldn't work in Client as well.]
I have succesfully made Apache 2.2 use the accounts in our Mac OS X Open Directory, instead of a flat text file. I found that the DN (distinguished name) needed an extra element on the front, uid=. But all the examples I had been finding on the web used a DN of this form:
cn=user1,dn=example,dn=com
Once I added uid=USERNAME on the front, and omitted the cn= part, it worked fine:
uid=user1,dn=example,dn=com
I found this out by using the command-line tool ldapsearch:
This is a way to transparently set up a server to cache software updates on your local network. This doesn't require any modifications (defaults write...) on clients -- it just works. And I didn't find any other similar solution on the internet; not even here! It does require Mac OS X Server, however. Here's how we did it:
Build a Mac OS X Server and call it yoursus. We used a headless Mac mini to do the job.
You must use external DNS servers on this server (so it won't check itself for updates).
Add a record for your server on your internal DNS, so yoursus.yourdomain.com resolves to your SUS's IP.
Start Software Update Server (SUS). It may take some time to cache all updates -- our /usr/share/swupd/html/ folder now has almost 9GB of files in it!
Start Web Service, and add following redirect (Server Admin » Web » Sites » default » Edit » Aliases » URL Aliases and Redirects » Add » Redirect):
Add a zone in your internal DNS, called swscan.apple.com, and point the whole subdomain to the IP of your SUS.
Flush your DNS cache on the clients: lookupd -flushcache
Now test your setup. Using Safari, following this link to Apple's catalog on your SUS should show Apple's real catalog (ApplePostURL should start with swquery.apple.com), while the same on other computers in your network should resolve and be forwarded to your SUS, http://yoursus.yourdomain.com:8088/index.sucatalog (ApplePostURL will start with yoursus.yourdomain.com:8088 this time).
I was trying to figure out why Static Maps would not work on my 10.4 Server. The setup is straightforward: add MAC Address and assign IP; pretty simple. However, my server would not hand out the assign IPs.
Well I found out that when you create static maps on OS X Server, your clients should not have anything in the DHCP Client ID box (i.e. they should leave it blank). Hopes that helps someone!
Recently we installed an Intel XServe at a company where all Mac stations were running Mac OS 9.2.2. I may seem odd, but here in Greece, most of the publishing companies still rely on native boot Mac OS 9 stations. The problem that occurred was that none of the Mac OS 9 stations could not search the 1.5TB shared AFP volume of the XServe with Sherlock, an abilty that the older Panther Server use to provide.
After extensive search, I end up to the conclusion -- I may be wrong -- that the missing Install Mac OS 9 drivers option of the Disk Utility was to blame. This conclusion came up since Mac OS 9 clients can successfully search any PowerPC-based Tiger Server. I've come up with this solution: install Searchlight, a $29.90 utility, on the XServe, and Netscape 7.02 on the Mac OS 9 clients. It's not perfect, but it's a solution.
[robg adds: Lacking an Xserve here at macosxhints HQ, I can't confirm either the problem or a solution...]
We spent a long time trying to get our XServe Macs to talk serial to serial. Putting together many of the hints and pieces, we finally came up with a relatively simple Terminal solution. Just connect the serial cables together of two machines and run this on one of them:
This may help you out if you are running any server version of OSX on a desktop machine and are experiencing extreme slowness while starting new programs. I installed Tiger server on my desktop machine and was running into unexplained creeping slowness with applications. It turned out to be related to a memory hogging program that Server runs by default, called Web Performance Cache, or webperfcache (name of the program).
webperfcache performs a very useful function if you are serving web pages on the internet and want really high performance. It caches static web pages in memory to accomplish this, which is great if you're a web company, but is generally unnecessary for home use. The problem is it forces these pages to stay resident in memory, and has a negative impact on OS X's memory paging and swapping routines. Long story short, turning it off drastically improved the performance of my G4, and it might help you out, too, if you're the kind of person who runs Server at home as a graphical desktop.
To disable it, go into the Server Admin program (under Applications/Server) and click on the local node (your computer's name) under Computers and Services. Then select the Web service, and under this the Settings tab. There is an Options tab under settings that controls optional web server components. You should uncheck Web Performance Cache here and save your settings.
It can be re-enabled by checking this box again, but I can't see why anyone would need to.
I had big trouble with the Advanced Firewall settings in Server Admin. I had a lot of double entries in the rules list, but could not delete them. If I moved them up or down, they were copied instead of being moved. If I enabled a disabled rule and saved it, it was automatically disabled again. Many rule numbers were duplicated with different contents.
So here's the fix: Disconnect your server from the internet, then in Server Admin, stop the firewall. Quit Server Admin and open Terminal. Type in the following:
$ cd /etc/ipfilter
$ cp ip_address_groups.plist ip_address_groups.plist.orig
$ sudo open ip_address_groups.plist
Check, edit, and correct all the rules. To see a list of ports, use cat /etc/services. To learn how to set up rules correctly use man ipfw. When all rules are correct, then:
Start Server Admin, start the firewall, and check the Active Rules tab. If it is empty, make a dummy change in a rule and save. If everything looks good, bring your server online again.
[robg adds: I can't test this one easily, nor do I know anyone who runs Server regularly. If this hint isn't helpful, please let me know!]