My Apple OSX server (Mountain Lion) at home is the centre of my network and entertainment system. It provides provides the following services:
Since several (soft-, and hardware) upgrades and redesigns of my internal network (from a single VLAN to a multi-VLAN with firewall services and traffic inspection) several services failed under certain circumstances. E.g. Air-Video would work internally where the client was in the same network as the OSX server network interface. But trying to connect through the SSL VPN stopped working for some reason. Also, the VNC Viewer did work in the old days, but stopped working over time. Same for several static NAT entries; worked before, and stopped working without 'no reason'. Other services like ssh did work in the old and new network design....
The last week, I've been experimenting with the Juniper Mobility System Software (MSS) in conjunction with two Juniper/Trapeze Access Points (type WLA522E). The MSS software is a Wireless LAN Controller (WLC) with manages the Access Points, and like so many Juniper Product; it can run in a virtual machine.
For the AP's to boot / connect to the network they need some basic information about where to find the WLC from which they receive their wireless settings. This can be done through DNS, or through DHCP. The first uses specific DNS records, and the latter uses DHCP Options (option 43 to be precise). I wanted to use the latter (which is a bit more challenging).
Ever since the upgrade to Apple
OS X Mountain Lion (10.8) on my MacBook (v5.1) I encountered wireless
problems every now and then. These 'experiences' are documented in two
different blog posts here and here.
At
the time I was also running an 'old' version of Little Snitch (v2.x).
After installing v3.0.1 my problems seemed to have solved... Seemed,
until I upgraded Little Snitch to v3.0.2.
After
the (mandatory) reboot my wireless connections were gone. The adapter
wouldn't go active. The symptoms being the exactly the same as before.
So I have no doubt, that Little Snitch had something to do with it.
The moment you download OS X Lion, you'd better have a copy of OS X Snow Leopard, because by default the new Apple OS can only be installed on a previous installed Operating System (upgrade). So if you need to reinstall your Mac in the future, you need to install OS X Snow Leopard first, and then upgrade to OS X Lion. Also, there's no way of ordering an OS X Lion copy on DVD..... Well, that sucks.
Fortunately, there's a way of creating the installation DVD by extracting the actual disk image from the downloaded OS X Lion installation package.
The earlier posts on my logging experiences didn't include the logrotation solution I used on my OS X Server.
When you create a new logfile (and have syslog fill that file up), you're gonna run into a lack of space sooner or later. This happens because the syslog server keeps writing data to that file, and the system doesn't 'recognize' (read: isn't configured) the file for logrotation. So, you need to tell the logrotation process to include the new logfile (and what to do with it).
Earlier this week I got the announcement (I opened an Adobe application) that there was an update for the Adobe Reader app. Security-conscious as I am, I fired up the update process.
Each time, this process stopped at the (near??) end of the installation with the following error:
The operation couldn’t be completed. (com.adobe.ARM error 1807.)
The error also suggested looking at the log file. Examination of this file showed nothing out of the ordinary. At least not that made sense to me.
There were some lines in the log that made me try to do a work-around (in bold);
PhotoLinkerI tend to geotag most of my photos. This way I have location information with the photo for future reference. It's also a neat feature that you might exploit when creating photo albums with e.g. iPhoto. The GPS coordinates in the images creates the option to create maps in iPhoto albums.
I use geotagging in two different ways. I use the jf Geocoding plugin in Lightroom and the PhotoLinker application. Both have their (dis)advantages. Something I won't go into in this post.
It has finally been done. I've switched off the old Windows 2003 server at home and officially replaced it with an Apple Mac mini server. For now... And with 'for now' I really mean for now. It turns out that Apple OS X Server doesn't resemble its client counterpart at all. Where the client is stable and intuitive, the server edition lacks both.
I'll try to explain why I think there's lots of room for improvement. Mainly stuff I ran into while configuring the server/services.
Since the Windows fulfilled several functions, I needed these functions to be available on the OS X server as well. These were;
- Networking services like DNS and DHCP
- Webserver
- Mailserver
- MySQL Database
- SSH Server
- File sharing on the internal network
- Public Key Infrastructure for issuing certificates
- Download station
Evaluating these functions, one would think that this shouldn't be a problem. Well it actually is.... At least some of those features.
After Apple updated the Mac mini to it's current form (mid 2010), I decided that it was time to start replacing my 'faithful' Windows 2003 server with something a bit less power consuming. The original Mac Mini was basically a consumer device, but a while back, Apple released a server version of the device. The main differences are:
- Only 1 CPU model available (2.66GHz at this moment)
- No DVD drive
- 2 * 500GB internal disks
- OSX 10.6.4 Server edition (unlimited clients)
Basically everything you could ever need for a server with a very small footprint.
The installation of Coldfusion is not straight forward. Not that I expected it to be [1], [2], [3], but one keeps hoping on an installer that actually installs the complete package, and where you don't have to edit files yourself to get it to work. It's not that it's the very first version of the scripting engine......
Anyway, the installer guides you through everything needed to INSTALL the software. Getting it to work comes next....
