Recently in server Category

Chassis lock on Xserve prevents bootup

| No Comments | No TrackBacks

I'm sure there are parameters here that I'm not acknowledging, but this is something that justifies jotting down for posterity. One of the Xserves I manage (Early 2009) has a quad fibre card with connections to two fibre different switches (an Emulex and Qlogic SanBox). If the server's chassis is locked (as if to prevent accidental ejection of the internal hard drives), bootup is prevented; all I get is a blinking folder on the screen. Unlock the chassis and the machine boots normally. In my experience, it doesn't seem to matter how the server was shutdown or started up, via LOM or at the console.

Though this behavior seems reasonable, it's still undesirable. After all, what's the point of remote lights-out reboots if you can't reboot, even when your machine is configured properly. Oftentimes, chassis are locked to prevent accidents, which increase in likelihood when a server is in a high traffic area. I suggest the desired behavior should be is for the system to note its state prior to the shutdown, and permit booting only when that state is maintained.

Snow Leopard's Samba adds unwanted directives to shares

| 11 Comments | No TrackBacks
Update: Be sure to add the path of the share in your 10.6 edits suggested below.

There's an important behavioral difference between the version of Samba in Mac OS X Server 10.5 (Version 3.0.25b-apple) Snow Leopard's (Version 3.0.28a-apple) in the way it handles processing the /etc/smb.conf file and manages shares.

With 10.5 you could edit your /etc/smb.conf file include at least two directives in your custom [global] parameter set "acl check permissions = no" and "nt acl support = no" to address issues with locking and access. In some environments, these are very important to have, especially some Office documents and Windows XP clients.

With 10.6 however it appears you can't entirely rely on including these in your custom [global] section any longer, as recommended by Apple. You may need to append a share-specific parameter set with these two directives instead.

For example, at the end of /etc/smb.conf file:

; Site-specific parameters can be added below this comment.
; END required configuration.
[global]
    veto files = /Thumbs.db/.DS_Store/.TemporaryItems/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/Network Trash Folder/    

[Test Share]
    path = /Shares/Test Share
    acl check permissions = no
    nt acl support = no

I have a few ideas about what the problem might be.

Extended attributes, Office 2007 clients via SMB from Xsan

| 2 Comments | No TrackBacks

We recently deployed Mac OS X 10.6.2 Server, sharing files on an Xsan volume via Samba to Windows users with Office 2007. When these PC users try to download or open the file, however, they got this warning, "Error Copying File or Folder. Cannot copy FILENAME: Cannot find the specified file. Make sure you specify the correct path and file name."

Some forums suggested adding two parameters at the very end of your /etc/smb.conf file:

[global]
    ea support = yes
    stream support = no

I've edited this entry to reflect some changes in late 10.6 Samba releases. Further, with the right smb.conf configuration, the changes below to various EAs  don't need to be made.


We I noticed that I could download the .doc files to my Mac via AFP, make a neglible modification and save the file, then upload it back to the SAN, my Windows colleagues could then view the file. When I did an ls -l@ on the file, I could see that this process added the com.apple.ResourceFork extended attribute. At this point, the modified Office files could be opened by my PC friends.

So, ironically, rather than deleting the EAs, I needed to apply this EA to the right files. It's probably OK to write this EA on each file and directory, but that's a little heavy handed. So instead, I executed this command:

find /Shares/Docs -name "*.doc" -print0 | xargs -0 sudo xattr -w com.apple.ResourceFork  

This will find the files with the .doc extension in my /Shares/Docs, add the extended attribute, and make everyone happy.

If you want to make it more thorough, you could try:

find . \( -name "*.doc" -or -name "*.docx" -or -name "*.xls" -or -name "*.xlsx" -or -name "*.ppt" -or -name "*.pptx" \) -print0 | xargs -0 xattr -w com.apple.ResourceFork   

One possible issue, though, is that if you apply this command too high up the hierarchy, it seems to make a problem. You might get this error: unable to execute /usr/bin/xattr: Argument list too long

You may wish to recursively apply this further down the directory tree.

Build WebAuth with Mac OS X Server 10.6 (Snow Leopard)

| No Comments | No TrackBacks

WebAuth (cf developer link) can be built cleanly on Mac OS X Server 10.6 with no additional flags or configuration edits. Just ./configure, make and sudo make install. Because of the changes in Snow Leopard server, you can now use WebAuth while continuing to use Apple's Server Admin.app tool to manage your web server.

This is different than with Mac OS X 10.5, which has an httpd built with 64- and 32-bit PowerPC and x86 architectures. WebAuth, like many other Apache modules, did not build properly, since each module needed to be of four architectures, too. (Instructions for Leopard Server are here. For instructions on installing WebAuth on other Unix-like operating systems, see here.)

Here's a list of things that are, I think, unique to the process of installing and using WebAuth on Mac OS X Server 10.6, after the jump.

Directory Services, OpenLDAP and DNS pools

| No Comments | No TrackBacks

Like many universities, we use OpenLDAP for our central directory system. As you might guess, the hostname for this system is ldap.stanford.edu. This is actually a DNS pool, though. There are multiple machines offering the same service. There's ldap1.stanford.edu, ldap2.stanford.edu, ldap3 and so on.

When I configure a Mac to use an external directory system, it's usually our OpenLDAP directory. Using Directory Access.app in the Utilities folder (or the command line equivalent, dsconfigldap), I usually enter that hostname, ldap.stanford.edu. However, there are limitations to this.

At some point during configuration, the Mac connects to the DNS pool, gets sorted to one of the physical machines, does a forward name resolution, then uses that numerical IP address for subsequent connections.

Here's the rub: if the IP address of that specific host changes, things break.

Server Monitor.app stupidity

| No Comments | No TrackBacks

This confounded me until it I sorted it out. Once done so, it made sense, but it doesn't help that, in this case, the user interface is unhelpful and unintuitive, and the behavior is different than other configurations for similar machines. (Note: I haven't regressively seen is this is the case pre-Mac OS X Server 10.5.7 Update or pre-Server Admin Tools 10.5.7.)

On this Xserve (Late 2006), Server Monitor.app on the local machine has the LOM feature configured for Network 1 (which corresponds to en0 aka the port labeled Ethernet 1 on the machine and by default the Network preference pane). This LOM interface has its own MAC address distinct from the physical port. I've registered this address for convenience's sake.

To configure this server for monitoring, launch Server Monitor --> Server --> Configure Local Machine. Give it an IP (again, distinct from the physical Ethernet ports), give it a username and password. This is the only step that's the same on this and the Xserve (Early 2008) model.

FTP anonymous only, no account holders please

| No Comments | No TrackBacks

I had a client request an anonymous FTP service be configured on their Leopard server. I did this, but had a concern that users with accounts on the server might try to connect. This would be highly undesirable; FTP as we all know, is an insecure protocol. So how to allow anonymous access only, but deny account holders with valid credentials?

Building WebAuth on Leopard Server

| No Comments | No TrackBacks

I needed to get WebAuth working on my Leopard server, but out of the box, there are some issues with building the modules. I want it to work with the included Apache 2.2, so that I and other admins can use Apple's Server Admin tool to configure sites and directories. (Admittedly, I get that tingly, satisfying feeling when third-party tools fit like a puzzle piece in your operating system of choice. Can't discount that motivating incentive.)

But time pressures prevailed, so I had to prioritize a workaround to meet a looming deadline. Personally, "workarounds" almost always gives leave me dissatisfied, but in this case, it's a necessity. Here's how I implemented WebAuth, opting to give up the web server administration utility of Server Admin (which, at the end of the day, isn't too great a loss).

In short, you'll 1) build Apache 2.2 from source, 2) build WebAuth, 3) add the WebAuth Kerberos keytab, 4) add an SSL certificate, 5) hand-configure your conf files to protect your sites and 6) add a launchd file to start it all automatically.

A simple bash script to email some log reports

| No Comments | No TrackBacks

I wrote a simple bash script to help monitor some aspects of Mac OS X Server. You might find it helpful. You'll need to edit it accordingly for your purposes, and of course, there are no guarantees. Feel free to modify it to your purposes and environment.

I tried to make somewhat agnostic regarding hardware (specifically, which NIC reflects the primary IP). And since I use Tivoli Storage Manager to back up some of our hosts, it includes a grep statement to send notices about TSM.

I'm quite certain it can be made more sophisticated, as I'm a scripting newbie, I'll admit. Nevertheless, you can find it at http://stanford.edu/~nbfa/files/daily-report.sh.

On my 10.4 and 10.5 servers, I made a launchd process that runs this script daily. On my 10.3 server, I made a cron job.

If it helps you learn, then all the better. If you repurpose and use it, then rock on. If you have suggestions to make it better, please comment.

Add a free, signed SSL certificate to Leopard Server

| No Comments | No TrackBacks

SSL certificates are a necessary component for using WebAuth and for serving any web pages using https. ITS provides some guidelines for getting SSL certs, with information on how to procure certs from Stanford's "certificate authority of choice" --essentially the third-party vendor with whom ITS works most often. There's even a nice web form to streamline the process. InstantSSL is fine, but they cost $83 per two-year certificate. This is the best choice if you have sensitive data and need that level of confidence.

But for other occasions, there are alternatives worth considering. You can use a self-signed certificate, but that might just annoy or confuse your users with browser warnings about untrusted certificates (and they don't enjoy a high degree of trust). Or, you can use ipsCA, which is a Spanish certificate authority that offers free two-year SSL certificates to educational institutions. Their root certificate (IPS SERVIDORES) is on just about every computer out there, too, so it works almost every browser. In other words, it's legit.

Here are some simplified instructions on how to implement SSL on your Leopard web server on a SUnet host. We'll start with generating the certificate signing request (CSR).

About this Archive

This page is an archive of recent entries in the server category.

learning opportunities is the previous category.

zimbra is the next category.

Find recent content on the main index or look in the archives to find all content.