When I took over doing support while we look for someone to replace our network admin, I was excited, for a moment, about playing with Mac OS X Server. For a quick moment. The first thing I know, I get a phone call from a remote user who cannot reach the server with ftp. I fire up Workgroup Manager and Server Admin to make sure the user’s account is active, and that ftp is in fact running, and that the firewall is not blocking any of the ftp ports. Everything is a go. I reset the password, and think that was the problem. I ask the user (on the phone) to try and log in, but no luck. I then bust out Cyberduck (my new favorite FTP client..thanks Ken!) and try to connect. No go. “Server shut down” Wild. I stop and start the service a few times, look at the logs…everything looks fine. I start to remember how much I love Mac OS X Server. Don’t worry, I am sure “it will be fixed in 10.4”. Right.
At this point I decided to look at other ftp servers out there, but then I realize how much of a pain it will be to add 50+ users, and I am not one to let Mac OS X Server to win so I forge on. I do a search at Apple’s support web site in seach for an answer to why the ftp process is not running, but Server Admin says it is. Not too much in the mailing lists (for once) nor google, so I head off to my last resort, the Apple Discussions before I write into the macosx-server list. Thankfully I found someone with the exact problem, and a solution which also fixes my problem. I still cannot figure out the miscommunication between Server Admin and the actual process, but at least it is working.
Again with my refrain…how do you screw something up like that when ftp (like httpd) is so straightforward in Mac OS X Client?
I have been looking for good Mac (not MAC) OS and UNIX training opportunities and think I finally came up with the missing piece, Big Nerd Ranch. Over the years, I have looked for good training for Mac OS X/Mac OS X Server, Apache, PHP, and other web technologies, but have often come up empty handed or less than satisfied. So if you are looking for some decent training, here is what I would recommend:
I have finally reached the point in my career where I need certification. Back in the Mac OS 7-9 days there was no certification programs for us Mac geeks, but now we face job competition with all the UNIX geeks too. Apple now offers certification, but after taking a class on Mac OS X Server for 5 days, I left feeling pretty let down. I know how to add users, and I am pretty comfortable to all the services. What I needed was something more in-depth. That was 3 years ago. Now I am working to get my “Linux/Unix System Administration Certificate” from O’Reilly/the University of Illinois. As technical as I am, I was not sure how much I would like taking classes via the web, but the more time I put in, the more I enjoy it.
O’Reilly and the U of I offer a few certifications that I would recommend anyone who like me, has the skills, but no certification to “prove” it.
[tags]UNIX, Linux, certification, O’Reilly[/tags]
Thanks to a friend that is always pointing out cool apps…I recently started using GeekTool. There are 3 modes to GeekTool…file mode, shell mode, and image mode. I use GeekTool for a few things…file mode to tail my web acces log on my web server, and image mode to load the gauge graphic for [email protected]. You can also use shell mode to run scripts or UNIX commands to monitor processes or get information on your computers/servers. It is definately a cool tool and I recommend it!
I like to keep my finger on the pulse with Apple products as well as with their documentation. Apple makes this easy with offering mailing lists that are dedicated to all their products. If you want to keep up specifically with all new and changed documentation, Apple has a great list for you: Daily Knowledge Base changes.
Apple’s description of the list:
“The Daily Knowledge Base changes mailing list announces new and modified documents in the AppleCare Knowledge Base. Each e-mail contains the titles of new and modified documents with links to them. E-mail from this list may also contain hints and tips to get the most out of your Apple products with links to Apple Discussions, Customer Installable Parts, custom support pages, and more.”
So if you want to make sure you keep up to date, subscribe to the list, it is low volume and very helpful!
So you need to install a search engine on your site. Keeping with my open source solutions, I have decided to go with ht://Dig. As soon as Apple decided to go with UNIX as a back end to their OS, I was excited because I could finally use ht://Dig (and another classic program called Mailman) I will always be grateful to both communities (ht://Dig and Mailman) because I learned so much about compiling and not to be afraid of source files. I have used ht://Dig for a few years with minimal complaints. You will need to compile ht://Dig, so make sure you have Apple’s Development Package (Xcode).
No need to re-create the wheel, so to compile/install ht://Dig, follow these directions. Before you actually compile everything, you will need to apply a patch that came out since the instructions were made. download the patch: ftp://ftp.ccsf.org/htdig-patches/3.1.6/htnotifyNull.0 and change the actual ntnotify source file with the corrected variables. After you have applied the patch, you can then complile the source while following the directions from the link above.
To customize the result pages, you can edit the html files in the /common folder so the search pages look seemless with your web site.
If you are going to use ht://Dig on multiple sites (your Virtual Hosts), simply create multiple conf files and multiple db directories, one for each site so that all of your site indexing is separate.
You are also able to add multiple attributes into each conf file to further customize your install. A comprehensive list of all the attrributes for the conf file can be found on ht://Dig’s web site.
So if you want to use a tried and true search engine, give ht://Dig a shot. A new version should be coming soon!
What a morning. Surprise surprise…I decided to install Mac OS X Server on my PowerBook to play around with the Apache conf (since I legally own two copies that just sit in my drawer). Ever since Mac OS X Server 1.0 came out I was excited to use Mac OS X Server. I loved AppleShare IP, and was ready to learn something new. Yeah, you are right, how many times can I tell this story?
To the point: you have web sites that need to be hosted in a Mac environment…what do you do? Two options (not including Darwin): Mac OS X Client, Mac OS X Client. I took my standard Mac OS X Client conf file and went line by line to see how the conf file was modified for Mac OS X Server. I will give credit to Apple for cleaning up the conf from 10.2 to 10.3, but man, it still leaves a lot of room for improvement. First of all….let me break down the conf files that Mac OS X Server uses.
- httpd.conf – The main configuration file that should contain all the basics. I have not figured out exactly why Apple has arranged the configuration file so…wierdly (not putting some basic directives like port number, listen, etc) but I am trying. At the end of standard Apache conf files, there is a Virtual Host template where ordinarily you would put all of your Virtual Host directives.
- virtual_host_global.conf – Apple decided to create a folder “sites” for all their vhost (Virtual Host) files, which is acceptable. There is also a conf file in the “sites” directory which does not make sense to me. The file is called “virtual_host_global.conf” and has one or two lines, depending if you want to use the performance cache. If you use the standard configuration from Apple, the “virtual_host_global.conf” contains one line:
If you chose to not use the performance cache, the file then looks like:
- 0000_any_80_default.conf – Apple’s conf files for all virtual hosts (even if you only host one site, it is treated as a vhost). All site specific information (from the Server Admin) is located in this/these files. Good: Apple separated them out for easy editting. Bad: don’t expect your changes to stick if you edit them by hand and then do something in the Server Admin. Also, WARNING if you use SSL, make sure you use Apple’s SSL files, or you will face the wrath when ediing your SSL and non SSL files (see old post)
What I would recommend if you have to use Mac OS X Server for your web needs, but feel it does not quite cut it…?
- Ask me for my httpd.conf file that I finally got to work that uses 95% standard Apache directives straight from the default Apache conf (5% of OS X Server stuff). I went line by line to see what it takes to break Mac OS X Server’s Apache conf. I rearranged the conf file to look more like the default conf as well as commented all my changes. My conf file does not use any of Apple’s vhost files, and you have a very simple, easy to follow example of vhosts.
- If you do not need a completely new httpd.conf file but would like to actually have the directives in the indivual site conf files to stick, create a conf file with your custom directives and then add an “Include “/etc/httpd/mychanges.conf” line at the end of the httpd.conf. Next time you restart your custom directives will be added and Apple will not be able to touch them.
- If you need complete control of your Apache install but still need to use Mac OS X Server for other server processes (AFP/FTP/Samba/Mail/DNS, etc) I would recommend downloading and compiling Apache into a different directory (ex. /usr/local) so you can control all your modules, conf files, etc.
- If you really are unhappy with Mac OS X Server’s web serving set up and do not need any other Mac OS X Server services, and do not want to worry about compiling, recompiling, and making sure Apple does not touch your custom configuration, I would at this point recommend running Apache on Mac OS X Client. Apple maintains updating Apache and does not touch the conf files with any GUI application. You can fully customize the conf file and not worry about too much because everything is standard Apache.
Something to think about…
If you did not notice, I have a thing for wierd and often funny Mac OS X and Mac OS X Server error messages. I periodically update the image on the right hand side that is a screen shot of an error I have received. Keep looking for new and exciting errors.
PS. The “You cannot continue to log in at this time” error was produced upon startup, as the log in dialog box popped up in the background. Fun!
If you have mission critical servers, you know that a backup is essential. I do not want my mission critical web server to go down. Along comes rsync.
How to set up rsync to synch my boot drive (and make it bootable) as well as synch my data files (html/php files):
First, you will to set up passwordless ssh between your servers. This is a good tutorial, except make sure step #5 is actually:
/var/root/.ssh/cat id_rsa.pub >> authorized_keys2 . Now you are ready to send data from your main server to the backup(s).
I have a daily cron job to run my data rsync script.
The script is:
time sudo rsync -a -vv -z -e ssh "/Volumes/www" "[email protected]:/Volumes".
(where /Volumes/www is the location of all my data files and 10.0.0.1 is the IP of my backup web server)
Boot drive (that is bootable)
I have a weekly (I chose weekly because if I apply an update to something that proves not to work, I know I have some flexibility) (and yes I always apply updates to a test server first) cron job to run my boot script.
The script is:
time sudo rsync -a --exclude /dev/* --exclude /afs/* --exclude /private/tmp/* --exclude /Network/* --exclude /Volumes/* --exclude /automount/* --exclude /private/var/run/* -vv -e ssh "/." [email protected]:/Volumes/BackUp --delete ; sudo rsync -qe ssh 10.0.0.1:'`sudo bless -folder /Volumes/BackUp/System/Library/CoreServices`' .
(where /Volumes/BackUp is the location of all my boot(System) files and 10.0.0.1 is the IP of my backup web server)
Next up: IP Failover! (another day)
Using rsync really cuts down on my worry..well a little, and also helps me keep all my servers synched to the primary server. Enjoy, it is time we started making these servers work for us, not the other way around!