The new G4 MacMini with the SSD is running beautifully. However, there is one little detail I’d like to take care of to help prolong the life of the SSD: disable the atime updating in the file system.

When we build out Linux servers, one of the configuration changes we always make is to add a noatime flag to the mount options for the file systems. atime is the Last Access Timestamp and really is useless in a server environment.

After some empirical testing…..

Under Tiger:

# mount -uvw -o noatime /
/dev/disk0s3 on / (local, journaled)

no effect. Even produced this entry in the system.log:

Jan 8 14:19:27 vpn KernelEventAgent[34]: tid 00000000 received
unknown event (256)

Leopard:

# mount -vuw -o noatime /
/dev/disk4 on / (hfs, local, journaled, noatime)

where it looks to be supported…

The test is to check the last access time with a ls -lu , then simply cat the file, then ls -lu again.

—

I guess I’ll need to upgrade the Mini to Leopard Server!

Posted by Brian Blood as Hardware, OS X Server at 3:27 PM UTC

No Comments »

In our continuing adventures of putting the highly versatile Apple MacMini to work in all sorts of applications:

A customer of ours has a specialized application that is extremely low bandwidth, but needs to be able to be accessed through a VPN connection to a protected network resource. All the usual suspects for providing this kind of service (Netscreen/SSG, Netopia) all have artificial limits on the number of concurrent VPN connections. In order to service the number of concurrent users (anywhere from 1 to 200), the customer would be looking at least $5,000 for a capable device. Again, this system is very low bandwidth, so these kinds of devices would be serious overkill.

In comes the MacMini running Tiger Server with the built-in VPN service.

However… the MacMini has always had a single weak spot: the hard drive. Even with a very low disk based usage that a dedicated VPN Server would entail that vulnerability to a disk failure has always bothered me and I wanted this VPN server to be on par in terms of reliability as much as possible compared to a hardware device. Even the MacMinis that we build out for customers in a load balanced environment, we always replace with a extended use rated drive, as the extra $100 is a nominal expenditure compared to the time that would be involved in dealing with a failed system.

In comes the Solid State Disk. A 32GB SSD with a IDE interface runs just under $100. For a system running primarily as a VPN Server, this is PLENTY of space as the only real ongoing writes will be log files. I chose a MLC (Multi-Level Cell) device over a SLC (Single Level Cell) based device as the differences in speed and longevity between the two variations of SSD just were not a factor in this application. A MLC SSD already has a useful lifetime/MTBF an order of magnitude greater than a standard Winchester based disk with it’s moving parts.

In the end I used a 1.33Ghz G4 (PowerPC, not Intel) MacMini with 1GB of RAM, as that CPU should be able to easily handle the tasks of handling a couple hundred concurrent VPN connections using 1-2Kbits/sec each. Again, VERY low bandwidth application.

I took the MacMini with it’s original 40GB Seagate drive and installed Tiger Server so I could get it updated and setup while I waited for the SSD to arrive from the online vendor. When I was ready to install the SSD, I used Disk Utility to save the installed system to a disk image. Installing the SSD was straightforward and not any different that replacing the internal drive on a MacMini. I then booted from CD, formatted the new SSD device and then performed a Restore operation of the installed Tiger Server onto the new SSD.

One thing that was very interesting to watch… SSDs perform their best with you throw a large amount of sequential reads/writes at them. When doing a Restore with Disk Utility it’s best to use the “Erase Destination” option as that will enable the imaging system the best opportunity to use a Block level Restore, instead of a File based Restore. A Block level Restore streams data at the disk and the SSD just ate this up. I Restored the 3.2GB installed System image in about 3 minutes. This is about 3 times faster than restoring back to the 40GB Seagate (I went back and tried it for comparison)

As always, when deploying a new type of setup we test the power utilization and found that 1) the G4 MacMini uses a ridiculously low amount of Amps; 2) the SSD didn’t really save much power usage.

Some anecdotes from my ammeter (we use 120V here in the States):

Adding a USB Ethernet Adapter increased all values by about 0.06A
This is necessary for the backside network resource routing.

Some pictures

Transcend 32GB SSD

Transcend 32GB SSD upright

Transcend 32GB SSD in Apple System Profiler

And of course the obligatory speed of boot/login videos:

G4MiniSSD-Boot

G4MiniSSD-Login

We have several more G4 MacMinis and are looking for appropriate applications to utilize them especially with a ultra-reliable drive installed.

Posted by Brian Blood as Colocation, Hardware, OS X Server, Routers and Firewalls, Servers at 1:41 PM UTC

No Comments »

This is from an exchange on the OS X Server mailing list.

The OP was trying to get mcrypt compiled into his PHP5 install on a 64-bit machine running 10.5.4

On Jul 24, 2008, at 4:53 PM, Someone wrote:
> I’m trying to compile my own PHP (which I’ve done plenty of times
> in the past on other systems), but
> I need libmcrypt support. Because 10.5 OS X Server is all 64 bit, I
> need a 64bit php binary, which
> means all my linked libraries need to be 64 bit as well.
>
> I tried to compile libmcrypt by hand and with the SVN version of
> macports, but both versions give me
> the following error when I do `make test` after compiling php with
> them:
>
> dyld: Symbol not found: _arcfour_LTX__is_block_algorithm
> Referenced from: /usr/local/lib/libmcrypt.4.dylib
> Expected in: flat namespace
>
> Googling for this error just brings up a forum post on entropy.org,
> which isn’t much help. How can I get my 64bit php to play nice?
>
> I’m using CFLAGS=’-arch x86_64′ before all my ./configure
> statements to get a x86_64 build.
>

Jul 25 14:20:59 gerry org.apache.httpd[625]: httpd: Syntax error on line 1462 of /private/etc/apache2/httpd.conf: Syntax error on line 8 of /etc/apache2/sites/entropy-php.conf: Cannot load /usr/local/php5/libphp5.so into server: dlopen(/usr/local/php5/libphp5.so, 10): no suitable image found.
Did find:
/usr/local/php5/libphp5.so: no matching architecture in universal wrapper

—–

My response for solving the problem in a different way that I found on the Entropy.ch forums

—–

How about going the other way…..

I ran into a similar situation setting up an Intel Xserve with a new install of Leopard Server.
I was trying to get the entropy.ch PHP module (which contains mcrypt FYI) running and it would not load due to “no appropriate image found” errors.

Apache on Leopard is a fat binary and was trying to load as a 64-bit app, which of course means that all plug-ins, loadable libraries need to be 64-bit as well and the Entropy PHP doesn’t currently have a 64-bit x86 image.

Since this is for an Apache 2 web server and I would be using the pre-forked model and any single one of my requests that would be running PHP code would be very unlikely to need anywhere near more than even 1GB of RAM, I forced Apache to run as a 32-bit process so that the PHP module would load.

I did this by using the lipo command to thin out Apple’s apache2 binary (after making a backup of course) to just contain a 32-bit x86 image.

Here is a small shell script that will make a backup and run the lipo command:

#!/bin/sh -
#
#

cd /usr/sbin;
mv httpd httpd.ub;
lipo -info httpd.ub;
lipo -thin i386 httpd.ub -output httpd.i386;
lipo -info httpd.i386;
ln -s httpd.i386 httpd;

Posted by Brian Blood as OS X Server, Servers, Web App Development at 9:02 PM UTC

No Comments »

We had the occasion to setup shared calendaring for our office. Here is a quick to-do list:

Prerequisites:

1. Server must be a full Open Directory system (not standalone)

Basic Steps:

1. Setup DNS name for calendar: ical.networkjack.info
2. Setup iCal Server on OS X Server, including setting up vhost for calendar
3. Turn on Calendaring (in Advanced tab in Workgroup Manager) for all users who will be calendar

Client Setup (Mac OS X 10.5)

1. Add server as a Directory using Directory Utility, so that you can search
2. Add account for iCal Server within iCal (Prefs -> Accounts)
   1. username : password
   2. ical.networkjack.info:8008
3. Setup delegation to other users (this is where the Directory comes in)

That should be it for the most part.

Posted by Brian Blood as OS X Server at 12:03 PM UTC

No Comments »

With all the recent attention on the DNS exploit and the delay in response by Apple for providing a response, I thought I would undertake a deeper review some of our dns systems. We were already protected from the exploit as we do not provide recursive service with any of our unpatched dns servers.

Turns out that not only has Apple not patched the BIND install as of July 29, they haven’t really kept up with the installed config files, specifically the root servers hints file (/var/named/named.ca)

DNS is a distributed system, but a DNS resolver has to be given a place to start in it’s search for your name resolution request. That’s what the 13* root servers are about. They are the top of the tree so to speak. They are strategically placed around the world and load balanced and are THE critical part of the Internet infrastructure.

The hints file is populated with names/IP addresses of the 13 root servers preset like so:

A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

this goes on down from A to M

Occasionally, an IP address of one of the root server will change. There have been two updates in the past 4 years: B and L

Old
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12

New:
; updated Jan 29, 2004
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
; updated Nov, 1, 2007
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.4

In Tiger Server, both B and L are out of date even with all updates and security patches applied

Leopard Server (up to 10.5.4) still shows the L root server out of date.

Update your /var/named/named.ca with the new entries preferably with this file:

ftp://rs.internic.net/domain/named.root

then stop/start the named process

The hints file from internic will also include IPv6 information.

The guys at Renesys wrote a good article about the potential dangers of not querying the correct root servers.

Links:

http://www.root-servers.org/

* – The count is 13 and 13 being the count because that’s the maximum amount of dns records that can be crammed into a single IP packet response.

Posted by Brian Blood as OS X Server, Servers at 12:47 PM UTC

No Comments »

We have a few servers that are still running from being upgraded from the 10.2 and 10.3 days. Most all are running Tiger server, with one or two running Leopard.

Since all our XServe G4s run with dual mirrored pairs, we have quite a few of these software RAID sets.

The trick is that if a mirror pair becomes degraded, your server is now vulnerable because 10.4 disk utilities will not allow you to rebuild a v.1 raid set. You MUST convert the RAID set to v2 before it can be restored.

Unfortunately, the convertRAID verb for the command line diskutil, had some issues. Specifically if your drives had the OS 9 Drivers installed on them, or there wasn’t enough room to shrink the current partition, then the convertRAID operation would destroy the partition map of your disk.

As a result, the only way to get these volumes converted to v2 was to take the volume offline and run a Dusk Utility Restore operation from the v1 pair/disk to a new v2 pair/disk.

Since we have a handful of v1 RAID pairs that are the boot volume, being able to take a server down long enough to perform this operation is sometimes difficult.

The fine folks at SoftRAID have added a new feature to their latest version that allows you to convert RAID sets from the Apple RAID to a SoftRAID version and back. We’ve tested converting from v1 to SoftRAID format then to v2 and it works well. We had some strange behavior from the partition maps, but Mark James and the engineering staff gave us some tips on what to look for and this cleared those issues up. If you can’t run hardware RAID, get yourself a copy of SoftRAID.

As a lark, we also booted the server we used to test all of this on with Leopard Server and tried the diskutil convertRAID command to see if Apple had fixed that operation and it hallelujah it worked!

It even turned a single disk degraded v1 raid into a single member v2 raid set that could easily have another drive added to it for bringing it back to full redundancy. Good news this is as we won’t have to have a server with a boot volume that needs converting down for longer than it takes to boot from Leopard (a external FireWire drive of course), run the conversion, then reboot.

If you are running a server and do not have fully redundant (RAID is NOT backup) boot and data partitions, get thee to a store and buy another drive and add it in. The diskutil enableRAID command also works very well on a single disk.

Posted by Brian Blood as OS X Server, Servers at 10:40 AM UTC

No Comments »

Server Monitor is an application that allows you to monitor the health of several Xserves over the network:

Sometimes the application gets a bit cranky about the connections it makes to the servers and reports that it can’t communicate or as you see here in the picture “reply not understood”. So we don’t really use it for serious monitoring other than as a cursory glance usually to check some items.

However, Apple really takes the cake with this knowledge-base article:

Xserve: Server Monitor does not authenticate with server over subnet

in which they claim that the way to fix the problems with their SOFTWARE, is to:

1. Make the necessary changes to the username or password using Server Monitor.
2. Quit Server Monitor.
3. Shut down the Xserve that is the target of these changes.
4. Remove the power cord from the back of the Xserve.
5. Wait 30 seconds and plug the power cord back in.
6. Power the server back on.

This sounds suspiciously similar to something an old tech friend of mine once told me:

There are sound scientifically proven reasons why one must sometimes sacrifice a chicken in order to get a SCSI chain to work.

Ugh.

Posted by Brian Blood as Colocation, Hardware, OS X Server, Servers, Soap Box at 11:33 PM UTC

No Comments »

One of our customers runs a system that has a shopping cart system and they like it when a customer upgrades their site to include full store functionality. This of course means an SSL certificate. And traditionally, this would mean an additional IP address that would need to added to the server to support the new certificate.

Entering wider spread usage is what is becoming known as the UCC (Unified Communications Certificate), which is just a fancy name for a regular X509 v3 certificate that utilizes the Subject Alternate Name extension. This extension allows the certificate creator to embed multiple alternate names that are cryptographically tied to the primary key that defines the certificate.

What this means in practical terms is that you could purchase a certificate whose primary name is www.mydomain.com and with the same certificate and IP address, support multiple variations of that domain name, such as secure.mydomain.com or www.mydomain.net, www.mydomain.org, etc… This is different than a wildcard certificate that is tied to a specific domain name and can be used on any third level host name as desired: *.mydomain.com.

Since many entities that have a web presence tend to pick up the .net/.biz/.org variations on their .com domain name, this type of certificate means that those additional names can be secured with the same certificate/IP address. This means simpler configuration and not having to burn an IP address for every single name variation.

I’ve tested GoDaddy’s version of this certificate that gives you a 5 name cert for $60/year on plain jane Apache under 10.4 client and it works without issue. I have two different vhosts with different ServerName directives and the SSL config under both simply use the same SSL

Example. Assume I have a cert that I have based on mydomain.com as the primary name and has the following names embedded in as Subject Alternate Name extensions:

1. www.mydomain.com
2. store.mydomain.com
3. www.mydomain.net
4. mydomain.net
5. admin.mydomain.net

Also assume that I have two different facets of my web application. The public facing side that is served by the .com and the admin/extranet that is served under the .net variation. My Apache config would look like so:


Listen 443
NameVirtualHost *:443

<VirtualHost *:443>
ServerName www.mydomain.com
ServerAdmin support@mydomain.com
DocumentRoot “/www/mydomain-com/”
<IfModule mod_ssl.c>
SSLEngine On
SSLCertificateFile “/etc/httpd/ssl/mydomain-com.crt”
SSLCertificateKeyFile “/etc/httpd/ssl/mydomain-com.key”
SSLCertificateChainFile “/etc/httpd/ssl/gd_intermediate_bundle.crt”
</IfModule>
ServerAlias mydomain.com store.mydomain.com
</VirtualHost>

<VirtualHost *:443>
ServerName www.mydomain.net
ServerAdmin support@mydomain.net
DocumentRoot “/www/mydomain-net/”
<IfModule mod_ssl.c>
SSLEngine On
SSLCertificateFile “/etc/httpd/ssl/mydomain-com.crt”
SSLCertificateKeyFile “/etc/httpd/ssl/mydomain-com.key”
SSLCertificateChainFile “/etc/httpd/ssl/gd_intermediate_bundle.crt”
</IfModule>
ServerAlias mydomain.net admin.mydomain.net
</VirtualHost>
notice the certificate files are the same for both vhosts and there is no distinguishing between IP addresses on the VirtualHost directive. Nice, clean, simple and it Just Works.

I’ve tested the certificate in the following browsers and none of them complain at all:

IE 6, FF2, Camino 1.5, Safari 2/3, Opera 8.5

X.509 v3 has been around at least since 2002 so it should be well supported.

Now, OS X Server should work exactly the same way as the underlying Apache system pieces are the same. The only issue comes into play with the way that ServerMgr handles storing certificates, their keys and passphrases and how Apache integrates all of these items.

Using the Server Admin app, you will not be able to use one of these certificates to secure two different Hosts that you enter as the host name in Apache is used by the “getsslpassphrase” binary to locate the certificate, private key, and password for the host in question to start SSL.

Since the primary name of the certificate is NOT the name of this secondary vhost, the loading process will fail. Any usage of this type of certificate will require you to manually create whatever non-primary VirtualHosts that would be setup to take advantage of these additional names secure by the “UCC” cert.

In order to get these certificates to load you will need to remove the passphrase from the key file so that Apache doesn’t call the getpassphrase and then fail.

the basic command for doing this is:
openssl rsa -in mydomain.key -out mydomain.key.open

For those who are use to working with OS X Server and doing something a bit out of the ordinary, this should not be surprising.

More SSL Certificate vendors are starting to offer this type of certificate, but I like the extra feature that the folks at DigiCert include with ALL their certificates: unlimited usage on any number of servers.

The DigiCert products are more expensive than the ones at GoDaddy, but theirs are single root certificates and they also go through additional layers of validation more than the simple “can you get an email at the domain” verification that GoDaddy utilizes.

Posted by Brian Blood as OS X Server, Servers, Web App Development at 5:56 PM UTC

No Comments »

Question to my Apple Authorized dealer that I just ordered Leopard
Server from to install on an Xserve G4:

> can you find out for me how I can get CD versions of the Leopard
> Server installer?
> we have some xserves that do not have DVD capable optical drives.

His Reply:
> From what I understand it doesn’t exist, one of the requirement of
> Leopard is a DVD drive. I’m guessing you’ll have to
> boot from another computer that has a DVD drive in Firewire Target
> mode.

My retort:
> From:
> http://www.apple.com/server/macosx/specs.html
> System Requirements
>
> Mac server or desktop computer with an Intel, PowerPC G5, or
> PowerPC G4 (867MHz or faster) processor; 1GB of physical RAM; 20GB
> of available disk space.

His Reply (looks like text pulled from somewhere)
> This is the first release of Mac OS X that’s not available in any
> form on CD, as all consumer-class computers that are capable of
> running Leopard also have at least a Combo Drive (DVD reading plus
> CD writing). Some Xserve models can run Mac OS X Server 10.5 but
> have only a CD-ROM drive; for such machines, you can perform a
> network installation using another computer running Leopard Server,
> or put the computer into Target Disk Mode and install Leopard
> Server from another computer that has a DVD reader.

Asking the Google, I find that text here:

http://db.tidbits.com/article/9243

So, installing Leopard Server on an Xserve G4 requires some sort of external piece of hardware. (Which of course, won’t be supplied by Apple (-; )

Target Disk Mode is not really an option as TGM on an Xserve G4 only exposes the device in Bay 1. Since we always build our Xserve G4s out with Mirrored arrays, we couldn’t start with a fresh pair of disks to install onto as a RAID pair. Perhaps a single drive RAID mirror might work and then add in second disk once booted up.

Ugh. I hate having to perform convoluted workarounds just to install an OS.

I guess all machines are equally supported for Leopard, just some are more equal than others.

UPDATE:  A really good suggestion was made to me on the OS X Server mailing list of making an image of the Leopard disc, then restoring onto a partition of a external firewire drive. This will boot the machine and run the installer just as if from an disc.This can even be used to put multiple install partitions of any number of install discs.

Posted by Brian Blood as OS X Server, Servers, Soap Box at 7:23 PM UTC

No Comments »

We setup our hosting environment in such a way that a site is tied to a Group and anyone in that group (usually just the one user) can do anything in that Sites folder. We provide both AFP and FTP access to our clients Site folders and although the controls for making AFP propagate the proper permissions (group read/write) are readily available, FTP is a different story. Users uploading files by FTP tend to have their documents set with rw-r-r. Under Panther Server, I had edited the ftpd.conf file, but had to LOCK that file as the servermgr software would overwrite the file and wipe out my umask directive even if I merely OPENED Server Admin utility. Of course, then every time I did, Server Admin would complain that the FTP service was broken. Very annoying.

With Tiger, however, I have a little more flexibility as I can now edit the LaunchDaemon plist file and give xtfp an additional command line argument whenever it is launched by launchd.

Here is the procedure:

launchctl unload /System/Library/LaunchDaemons/ftp.plist

edit /System/Library/LaunchDaemons/ftp.plist  and add a new ProgramArgument:

This:

<key>ProgramArguments</key>
<array>
<string>xftpd</string>
<string>-a</string>
</array>

becomes:

<key>ProgramArguments</key>
<array>
<string>xftpd</string>
<string>-a</string>
<string>-u0002</string>
</array>

and then to complete the change:

 launchctl load /System/Library/LaunchDaemons/ftp.plist

and that’s it.

That is now in my little toolkit of tweaks to make to OS X Server when installing. You do have to make sure that change isn’t wiped out by some OS update.

Posted by Brian Blood as OS X Server at 11:53 AM UTC

No Comments »