We could host SMB shares directly on our OD server, but ideally we keep our OD server just as a directory and authentication server, and let other servers do the file sharing heavy lifting.

We’ll be using a Mac OS X Server 10.5 OD master to authenticate a Red Hat Enterprise Linux 5 system with the distro Samba package, but this should work on any of the Samba distributions out there.  We’ll make a simple share point for some OD users to access their files in a collaborative way.

First, we’ll configure the Open Directory server.  In Server Admin, make sure you have activated SMB as a service under “Services” in the general section of your OD server’s entry.

Assuming this is an OD master, click on the new SMB entry on the left panel, and change the server’s role from Standalone Server to Primary Domain Controller (PDC).

Enter a description, computer name, and domain for your new PDC.

Unless you need Windows95 support (shudder), it is a good idea to un-check “LAN Manager” authentication under “Access” as this is generally considered insecure these days.

Samba requires a few ports open on your host firewall to be browseable and accessible.  Under Firewall on the left panel of Server Admin, you’ll need to make sure the following are open for “full-service” Samba:

• Microsoft Domain Server (445 TCP)
• WINS – Windows Internet Naming Service (137 UDP)
• NETBIOS datagram – Windows browsing (138 UDP)
• SMB/CIFS – Windows file service (139 TCP)

Be sure any firewalls upstream are also allowing this traffic to this specific host.  Be conservative on what networks get access, as there have been numerous security issues initiated with breaches on these services.  Some services, such as WINS, may not be necessary for your specific installation.

Now to the Linux server…

On Red Hat systems and many others, the core configuration for Samba is in /etc/samba/smb.conf.  Open this file in your favorite editor.

Under “Network Related Options” enter:

workgroup = MYCOMPANYGROUP

Under “Domain Members Options” enter:

security = domain
encrypt passwords = yes
password server = ODSERVER1

Under “Share Definitions” enter:

[mynewshare]
comment = My test share
path = /myshare
writable = yes
browseable = yes
valid_users = @od_group1

Next, we need to join the Samba server to the PDC.  You’ll need your directory administrator password for this:

net join –S odserver1 -U diradmin

Restart your Samba service to bring in the new config.  On Red Hat:

service smb restart

To make permissions function cleanly, we’ll want to make our linux server aware of our OD server users.  To do this in Red Hat, you can edit the PAM entries directly, or use one of the available utilities.  We’ll use authconfig-tui here.  Be very careful to restrict access when doing this if you allow authentication from your OD server (via sshd_config, pam, etc) as this will potentially allow anyone in your OD domain to log in to the linux server.  This is most likely not your intended configuration.

Under “User Information”, select “Use LDAP”.  If you want users to log in via other means, under “Authentication”, select “Use Kerberos”.

Choose “Next”.

Select “Use TLS” (highly recommended, but you need to install the CA cert for your OD server locally on the linux server).

For “Server” enter the url to your ldap server:  ldap://odserver1.mycompany.com/

“Base DN” should be the DN assigned by your Mac OS X Server at install:  dc=odserver1,dc=mycompany,dc=com

For “Kerberos Settings”:

Realm: ODSERVER1.MYCOMPANY.COM

KDC: odserver1.mycompany.com:88

Admin Server: odserver1.mycompany.com:749

Finally, we need to make sure the share point /myshare exists and has the right permissions.  If you want everyone in the OD group to be able to be able to edit and share files in the directory, set the sgid bit on the /myshare directory and change ownership to the group od_group1:

chown nobody:od_group1 /myshare
chmod 2770 /myshare

If you don’t want users deleting each others’ files, you can also set the suid or “sticky” bit:

chmod o+t /myshare

If you are running SELinux in Enforcing mode, you will need to change security contexts on the /myshare directory:

chcon –t samba_share_t /myshare

The last step is to ensure the linux server host firewall is allowing smb access, as we did with the OD server above.

—

About Iris Professional Services
Iris Professional Services is a computer consulting company operating offices in both Seattle and Portland. Businesses throughout the Pacific Northwest rely on our expert IT consultants for all their network IT support services.

The executable for this function is /usr/sbin/jabber_autobuddy. The documentation says it’s not intended to be invoked by users directly, but we’ll do it with a scheduled script here. jabber_autobuddy is a simple binary that modifies entries in the SQLite database (/var/jabberd/sqlite/jabberd2.db) containing your jabberd users.

First, let’s create a new script as an administrator called auto_buddy.sh. To that file, add:

#!/bin/sh
/usr/sbin/jabber_autobuddy -D -m

The -D provides some verbose output to keep track of issues, while the -m does the actual “buddifying” of the users in your chat user database.

We’ll need to make this script executable:

chmod u+x auto_buddy.sh

Put it in a location where you keep other scripts you like to run, such as /usr/local/bin, or ~/bin.

It might seem a bit over the top to make a new script for a single command, but makes things a little more flexible using launchd, as we’ll see in a moment.

Running this script will make any initialized user in iChat server (any user that has logged in before) a buddy of everyone else. But what if I want to add a new user? They won’t be included until the next run of jabber_autobuddy. We need to schedule a job for this, and we’ll do it with Apple’s preferred scheduler and master process, launchd.

Launchd uses xml plist files to decide what to do. We’re going to add a new file to /Library/LaunchDaemons called com.mycompany.autobuddy.plist.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
   "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

<dict>
	<key>Disabled</key>
	<false/>

	<key>Label</key>
	<string>com.mycompany.autobuddy</string>

	<key>ProgramArguments</key>
	<array>
		<string>/private/var/root/bin/auto_buddy.sh</string>
	</array>

	<key>KeepAlive</key>
	<false/>

	<key>StartInterval</key>
	<integer>1800</integer>
</dict>

</plist>

Here, I’m assuming the script auto_buddy.sh will sit in ~root/bin, and I want it to execute every 30 minutes (1800 seconds).

The final step is to load the plist file into launchd:

launchctl load com.mycompany.autobuddy.plist

You should see your process loaded in launchd with:

launchctl list | grep autobuddy

Whenever anyone joins the iChat server for the first time, they are registered in the SQLite database. Once autobuddy runs in its scheduled window, at the next login, the new user will be buddied up with everyone else in the list.

If you ever want to unload the process from launchd, use:

launchctl unload com.mycompany.autobuddy

You will need to do this if you change the StartInterval value. You might see the value of putting more complex commands in a container script, so you can edit the script without having to unload/load the launchctl plist file each time you change the switches on the ProgramArguments line. Note that it would seem simpler to just add a cron entry for this process, and you would probably be right. However, cron is technically deprecated in the latest versions of Mac OS X Server. My guess is cron isn’t going anywhere anytime soon, but who knows?

—

About Iris Professional Services
Iris Professional Services is a computer consulting company operating offices in both Seattle and Portland. Businesses throughout the Pacific Northwest rely on our expert IT consultants for all their network IT support services.

As is typical of Mac OS X Server, Server Admin makes it easy to add Apple base stations to authenticate against Open Directory using RADIUS.  But what if you want to use the RADIUS server for other devices?  Most decent managed switches and routers can authenticate to RADIUS.  Wouldn’t it be great to have them authenticate against Open Directory?  Read on.

First, what is RADIUS and why do I need it?

RADIUS stands for Remote Authentication Dial-In User Service.  It is a well-known and heavily-used protocol, most often associated with managed switches, routers, modem pools, and other network devices.  On embedded systems like these, RADIUS is almost always available as a centralized authentication option.  RADIUS provides three important components to your network:  Authentication, Authorization, and Accounting.

WPA/WPA2 pre-shared keys (PSK) are often used for AirPort base stations and other wireless devices.  Everyone uses the same PSK, usually saved in Network Preferences for convenience.  PSKs are considered secure transport, but do not scale well in a large organization.  If an employee is fired or a laptop is stolen, the PSK has to be changed and everyone in the organization has to be made aware of it.  This quickly becomes a problem with more than a few people.  With RADIUS, the employee’s access is instantly disabled when the account is deactivated in Open Directory, or the employee can change her password if her laptop is stolen.  Much easier!

Centralized authentication and authorization also allows for accounting.  You can see where your employees are accessing your network and when they did it.  Industry compliance requirements often dictate you need to be in control of this information.

So how do I get my devices talking to my RADIUS server?

Mac OS X Server comes with a full install of the FreeRADIUS server, a highly configurable and complex server involving a number of config files in /etc/raddb.  When you add a new base station in Server Admin, the data is stored in an SQLite database at /etc/raddb/sqlite_radius_client_database.  However, you don’t have to insert devices into this database to have RADIUS acknowledge them.  By modifying the file /etc/raddb/clients.conf, you can add additional devices to authenticate.

Here I have added some security appliances sitting at 10.10.3.1 and 10.11.80.1 to clients.conf:

client 10.10.3.1 {
   secret        = k34nu3jsogls
   shortname       = parisgw
}

client 10.11.80.1 {
   secret          = 928jv2lkss0df
   shortname       = tokyogw
}

On the security devices I simply add the IP address of the RADIUS server as an auth mechanism, include the shared secret I’ve designated in my clients.conf file, make sure it is connecting to port 1812, and ensure I have a clear path through firewalls to the RADIUS server on this port.  After restarting the RADIUS service on Mac OS X Server, the client will be authenticating to Open Directory.  Great!

But what if I want to limit certain groups to certain devices?  Server Admin only lets you limit a certain group to all basestations in the list.  This is a major limitation.  Perhaps we don’t want our Paris users to be able to use the Tokyo service.  Or perhaps only IT administrators should be able to access the admin areas on switches.  By adding some entries to the huntgroups file, you can solve this problem:

paris   NAS-IP-Address == 10.10.3.1
           Group = france_users,

tokyo   NAS-IP-Address == 10.11.80.1
            Group = japan_users,

switch01928    NAS-IP-Address == 10.11.20.3
              Group = net_admin,

Where france_users, japan_users, and net_admin are OD groups with the members you wish to access the access point.

This is only the tip of the iceberg with FreeRADIUS configuration.  Apple has made a big step towards making it accessible to non-propeller-heads.  But with a little extra legwork, you can make the service much more valuable and flexible to your organization.  Happy authenticating!

One feature missing from the initial Server release is the ability to perform VM snapshots of both disk and memory within the admin application. There’s no easy way to schedule jobs out for automation in a backup strategy.  Parallels Desktop 4 has this functionality, but it has yet to show up in the Server product. One solution is to roll your own snapshot system using the command line tool /usr/bin/prlctl and a bit of scripting.  A few people out there have started making their own backup systems using prlctl, and here is only one example of what you can do with this tool.

I’ve attached a basic perl script that calls the prlctl tool to get a list of all active VMs, suspend each VM (which dumps a copy of memory to the disk to resume), copy the full VM to a new location of your choosing and optionally compress, date-stamp, and archive, and finally resume the VM after copy.

I’ve added a flag in the script to compress the image into a date-stamped archive if I choose to, though this adds some time to the copy and subsequent restoration of the archive.  I have found it saves a considerable amount of disk space, which could make a difference for your backup times to a network volume or tape.  The entire process leaves the VM suspended for under 10 minutes on my storage systems.  You will need to decide for yourself what is considered acceptable downtime to get the snapshot. The archives are obviously quite large, so it may be best to do the wholesale VM copy in your weeklies, while getting client VM system-level copies daily. These are big files! However, if you forgo compression, you can be up and running on new hardware literally within seconds, with an identical point-in-time of your virtual host.

This particular script uses ditto to archive as a .cpz and make the transfer, but rsync or a gzipped tar setup would work just as well.

I’m sure there are some tricks to be made with your company’s backup solution to get incrementals of the full copy over time, but that can be left as an (easy) exercise for the reader, as every environment has its own circumstances. Time Machine increments come to mind as a cool option.

Once you have your script dialed in, throw it into your crontab, or better yet, build a launch daemon plist file for it and load it in with launchctl (interestingly, cron is considered depreciated in Mac OS X these days). All backups should be automated, even if they only run once a week or month.

Here’s an example of com.yourcompany.vmsnapshot.plist, which should execute your backup at 9pm nightly (the script will need to be executable):

bash-3.2# cat com.yourcompany.vmbackup.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Disabled</key>
        <false/>
        <key>Label</key>
        <string>com.yourcompany.vmbackup</string>
        <key>ProgramArguments</key>
        <array>
                <string>/private/var/root/bin/vm_backup.pl</string>
        </array>
        <key>KeepAlive</key>
        <false/>
        <key>StartCalendarInterval</key>
        <dict>
                <key>Hour</key>
                <integer>21</integer>
                <key>Minute</key>
                <integer>0</integer>
        </dict>
</dict>
</plist>

Copy this file to your /Library/LaunchDaemons directory, and launchctl load com.yourcompany.vmbackup.plist.  Do a quick confirmation with launchctl list | grep vmbackup, and you should be good to go.

Feel free to adapt and expand as you need, but please remember this is just a suggestion, not a released backup product!  The utility prlctl provides error codes, so some basic error checking would be a good addition here.  We would love to see this expanded and improved, so post back with any additions or changes!  Happy virtualizing.

vm_backup.pl

Start up in Single User mode by holding down the Command and S keys at boot, then run these commands:

/sbin/mount -uw /
rm /var/db/.SoftwareUpdate*
reboot

You can also delete the problem files by logging into the server via SSH and executing the rm command, provided that you still have SSH turned on of course.

Under some circumstances when a software update fails for any reason under Leopard and Leopard Server it appears to not properly remove the /var/db/.SoftwareUpdateAtLogout and /var/db/.SoftwareUpdateOptions files. If those files are present they can cause Leopard Server to invoke the Server Assistant mode at startup. Force quitting the Server Assistant just causes the Server Assistant to relaunch. Instead boot into single user mode and delete the offending files.

/var/db/.SoftwareUpdateOptions appears to be an XML-formatted .plist with settings for Software Update while /var/db/.SoftwareUpdateAtLogout is just an empty file which if present causes the system to run Software Update and install any pending updates at next logout or restart. Why these files are causing Leopard Server to start up in Server Assistant is beyond me but is almost certainly a bug. There is another file in /var/db called .AppleSetupDone which if missing will cause Mac OS X to run the Setup Assistant/Server Assistant once upon startup, this bug is reminiscent of that ‘feature.’

This fix was inspired by Mark Douma’s post and fix for the same issue happening to Leopard client in the Apple Discussion Forums.

First a little background: for a while now I have been teaching about “URL Fun” in my server classes. Its a pretty universal concept that you find server admins implementing on Mac OS X clients: the idea of an alias, link, script or application that connects to a server on login. The windows folks normally refer to this conceptually as a “Mapped Network Drive” which is why I choose it for the name of this article. I actually find it humorous how often I get asked to make a link to the “x” or “q” drive when doing consulting, its actually a testment to how simple this works on windows, people have no idea of the shares name, just the drive letter ( for better or worse sometimes ). Now there are multiple ways of accomplishing this on OS X ,some are better or fancier then others. All of them try at best to get around requiring users to use “Go” > “Connect To Server”

Part 1: “Aliases” and “Location” Files

Part 2: AppleScript and Login items

Part 3: Shell Scripts and Login Hooks

Part 4: Automounts with Directory Services

Lets take a look at some of the more basic “Alias” implementations

The most common and recommend method I see in the field is by dragging a drive’s icon ,mounted on the Desktop ( or /Volumes ) to the “System Preferences” > “Accounts” > “Login Items” for the respective user account. Whats going on behind the scenes is that the alias “data” that would normally exist in the resource fork of the filesystem has been inserted in to the “AliasData” key nested within the “AutoLaunchedApplicationDictionary” array of your users ~/Library/Preferences/loginwindow.plist file. There is actually one of these stored in the local /Library as well but we will cover that in part 2. You can view this “data” by runnning the following command ( type it in as you see it i.e. line break aka the “return” key is escaped by the “\” or get rid of the “\” and type it on one line.) Also some of the code in this article can be dowloaded by clicking on it.defaults read ~/Library/Preferences/loginwindow \AutoLaunchedApplicationDictionaryIn the output you will see the encoded alias data which is, if you make aliases this way in the finder you can view similar data or the resource fork in the file system using the “special” path “foobar/..namedfork/rsrc” ( “foobar/rsrc” works as well but its deprecated) I find this data easiest to look at with “less” or “strings” but its mostly meaningless to us humans.less -f /path/to/myalias/..namedfork/rsrc ; resetor to just see the ASCII stringsstrings /path/to/myalias/..namedfork/rsrcor if you have the developer tools installed you can use DeRez/Developer/Tools/DeRez /path/to/myalias This is normally the point where I ask people how many times they have seen a broken alias. Before you answer, I don’t want to chase any red hearings, aliases are not broken when you see the following behavior ( pictured below ) in your login items preferences pane.

This happens because the system can’t load the icon ( and kind ) when the volume is unmounted. So when the server volume is unmounted you will see the bottom example always. Because of this login aliases are very hard to troubleshoot as their content is encoded and they look the same when they are broken as they do when the are working (and unmounted). Feature or bug i’ll let you be the judge.

There are alot of reasons a “break” can happen but often the most common is in fact the simplest. When you created this alias data, quite a bit of infomation relating to how you orginally connected to the server is stored. Especially if you used the Network Browser then it was based around whatever broadcast protocol was being used to propagate the list at that moment, or if you used the “Go” > “Connect to Server” ( Command + K ) in the Finder there where multiple ways it could be resolving the address of our server in the alias.such as the following( For fun I have added code snippets if you dont know your server’s value )

The Bonjour (Rendevous) Name:
o

sudo /usr/sbin/systemsetup -getlocalsubnetname add .local to the end and this is your mDNS aka your Bonjour name Graphically “System Preferences” > “Sharing” > “Edit” Button (shown below )The Fully Qualified Domain Name of your server:
o

/bin/hostname # shows the primary hostname only /usr/bin/host 10.1.0.1 /usr/bin/host 206.163.40.59 You could have many other hostnames and in fact we are looking up the “reverse”(PTR) record, but hopefully that will map back to a “forward”(A) record. The IP address (internal, external, multi-homed, etc.):
o

/sbin/ifconfig | /usr/bin/grep inet

systemsetup and networksetup do exist on client, they are just in a different place : /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/This basically means how you orginally connected to the server is how the alias will attempt to connect for then on in. If your servers values never changes this is still a good practice right? Well unfortunately not always no, on top of your servers connection address you might also be injecting a default user name (i.e. the username of the authenticated user who orginally connected to the share that the alias was created from). I for instance saw this at a school district , every local “student” account would open the server connection using the orginal admin’s username (who had created the NetRestore image) already filled in. Bit of hinderance having to blank it out and fill your username wouldnt you say? You actually can control this behavior using a preference key outline in this . Its also worthy of note that a proper kerberos setup should prevent this behavior, as you will only be allowed to auth as the Kerberos user in the case of at least AFPBefore we go through how not to do that lets quickly look at a scenario where you might in fact want to embed say “guest access” credentials in the alias. If when originally connecting we use Go Connect To Server, most of this information will be based on the URL we use to connect to the server.for SMS/CIFS URI’s this is normally just “guest@”: smb://guest@server.example.com For AFP Guest access its a little bit different idea as you can (in 10-10.4 at least) have a user actually named “guest”, so guest@ wont work,so there is a special string for this commonly found in the mount records (mentioned in later sections of this article) you can use. afp://;AUTH=NO%20USER%20AUTHENT@server.example.com you can in fact embed a password in using this method for many protocols such as AFP, SMB, and FTP (even SFTP by way of Transmit.app and other 3 party apps ), Perhaps you have a generic login for “guest” type access (not the you would ever do that right ) . afp://genericlogin:password@server.example.com/Share smb://DOMAIN;user:pass@server.example.com/SHARE Obviously this is not a secure practice unless you know exactly what your doing but as you can see you can make your aliases with more specific information using this method.Now while this would solve some issues in a small environment but it doesn’t scale well, imagine having to do this for all users in a large network.

Internet Location Files: A good first step and a “Classic” trick

Even if you connect omitting the user@ field the alias will still embed it in its connection data,so as an alternative method we can use Internet Location Files. these come in many variations.Creating them is also pretty easy once you learn how. And they have been around along time too and thus are very compatible.

Type in the URL in to a new TextEdit.app Document

If you use spaces in your servers share names (shame on you ) remember to substitute those with “%20″ i.e. afp://server/My%20Spaced%20Share%20Name

Highlight the text

(if your like me and double click it to highlight, make sure to click once more at the next step. )

Click and hold on top on the highlighted text until your cursor changes to an “Arrow”

Now drag it out on to your Desktop.

I have found people sometimes have problems with this so read below for a non drag ‘n drop way using “Go” -> “Connect to Server”

Depending on the type of URL you typed in you will have created one of the following Location files and corresponding URLs.

foobar.fileloc a file system URL file://

foobar.afploc an AFP server URL file afp://

foobar.inetloc a Server Message Block (CIFS) URL

foobar.webloc a HTTP URL, (not WEBDAV)

foobar.ftploc a FTP URL (Finder is read only from the UI) There are others as well, but for our purposes this is what we probably want to mount

You can also even make them directly from a website’s links depending on your browser, here is one for –> Applications <– that uses the file:// URL type If you drag it (the word “Applications”) out onto your Desktop you will see a file created called “Application.fileloc”, and yes I know you cant click on it from within the browser ( as you might have noticed from my others above and through the rest of this article ) , but you can also drag it to the location bar making it almost as easy to launch.if you dont see the file extention (which is the default) you can enable file extentions from the Finder.app’s “Finder” menu (next to the Apple) under “Preferences” > “Advanced” > “Show all file extentions”. or use, defaults write -g AppleShowAllExtensions -bool YES Then if your finder is free to be killed ( i.e. not coping important CEO files ) you can use the following to apply the change killall -HUP Finder You should be able to double click on it and viola there is your Application folder. As a cool note many email clients like Mail.app and Entourage with parse these such links natively ( unlike your browser in the case of file://) making it a cinch to tell your users about a hard to find path like file:///System/Library/CoreServices/Kerberos.app You can also customise what application handles these URLs with RCDefaultApp a graphical LaunchServices Preference Pane.

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>

<plist version=”1.0″>

<dict>

<key>URL</key>

<string>afp://afp.example.com</string>

</dict>

</plist>

These files are infact the same type that are created by adding a favorite in the “Go” -> “Connect to Server” dialog box (the little plus sign), they are then stored in ~/Library/Favorites folder. The only exception is the “Server Address: ” box itself which can be configured with the following command.defaults write ~/Library/Preferences/com.apple.finder \FXConnectToLastURL 'afp://files.example.com/data'

You can in fact add your own items to this menu by way of making these location files and adding them to the folder ( They are greyed out but they work ). If you don’t specify a user@ then they will default to using the console users “RealName” sometime’s referred to as the “Long Name”. If that doesn’t suite your environment you can put bogus info in here like afp://FILLINYOURUSERNAME@server.example.com/Public To see or script the RealName value for a local user you can use dscl like this: dscl . -read /users/$USER RealName For a network LDAP user you can use:dscl /LDAPv3/iduro.wallcity.lan -read /Users/$USER RealName Or for an Active Directory user: dscl /Active\ Directory/All\ Domains/ -read /Users/$USER RealName

Now that we have files that we can embed specific connection data into, but how do we deploy them? Well as you might guess these can the be added as login items, the only problem is that they will not be embeded in the preference file like they alias data was, they instead will path names to the “flat” file locations. I like to add them to the login items and keep the orginating items in ~/Library/Favorites .The only real problem I have with this is that fact if the user deletes the orginal file , the login item reference is broken. One easy way to stop that from happening is to “lock” the favorites so that they cant easily be deleted through “Go”->”Connect to Server”, You can do the from the command line for all favorites:

chflags uchg ~/Library/Favorites/* or to reverse (unlock) the flag you can use “no”, also you can replace the star with a file name if you want to only effect a particular file in the folder. chflags nouchg ~/Library/Favorites/* This will affect only the current set , so users can add remove additional items. You can turn this flag on and off from the finder as well from the File>Get Info ( Command + I ) window.

If you dont want to deal with “locking” then another trick is to hide these files from your users by placing them in a “dot” folder

mkdir ~/Documents/.LoginItems mv ~/Desktop/my.afploc ~/Documents/.LoginItems/ open ~/Documents/.LoginItems only use “mv” in 10.4 or later as older styles of these files had important resource fork’s and older versions of mv did not move them. You can just drag and drop in the finder if you like.That last “open” bit is to open the “hidden” folder in the finder . This will prevent all but the savy from easily deleting these items most days. You could just as easily use “Go” -> “To Folder” or from the keyboard: “Command + Shift + G” and drag and drop.You could also put them into a folder in the “local domain” such as the local /Library/Application Support/.

If you use ARD you can automate this process with an Apple Script. Here is a pretty basic Apple Script that has been wrapped in whats known as a “here” document then executed by osascript

osascript << EOF tell application "System Events" make new login item at end of login items with properties {path:"/Library/Application Support/Irisink/Foobar.afploc"} end tell EOF Note: the user has to be logged in for this to work

The only real downside of the files that we have not covered is that they won’t always allow work due to the Network not being active at time of login ( Think Wireless, Spanning Tree etc ),So in our next section of this article we will turn our 6 line Apple Script into a 60 line version with pretty dialog boxes, fault tolerance and an artificial delay.So stay tuned for Part 2 of this series:AppleScript and Login items

Here is a quick taste of how to make an Applescript Login Item to mount multiple drives at the same time, and put in an artificial delay so we don’t timeout.First open up the /Applications/Applescript/Script Editor.app Add the following two lines: Click the code to open it up in Script Editor delay 5 -- I like to put a 5-10 second delay in mount volume "smb://user@allthestuffabove.com/Share"

You can continure to add mount volume lines,for any shares using the conventions above. mount volume "afp://user@allthestuffabove.com/Public" Those of you using ADmitMac may want to instead use the open location syntax: open location "cifs://DOMAIN;user@allthestuffabove.com/Public" When you are done, run your script to make sure it delays and then connects to all the share points listed. Once you have verfied it will workChoose File -> Save Asand choose “Application Bundle” from the “File Format:” Pop-Up

If would you like to contact me with comments or inaccuracies about this article, feel free but support requests will be ignored unless you would like to sign up for Iris Professional Services service. Thanks

Read on to find out how to setup awstats on Mac OS X Server.

This article discusses Mac OS X Server version 10.4.

Modify your logs
oYou should change your log format to one that contains more information than the default common format, and if you host more than one site you should tell the web server (Apache) to split out the logging so each site gets its own log.

-In Server Admin, go to the Web section then the Settings section. Click on the Sites tab and open the details for the site you are setting up awstats for. Once there click on the Logging tab. Make sure that ‘Enable Access log’ is checked. In the Location field for the Access log edit the log name so it contains the name of your site. For example, if it said ‘/var/log/httpd/access_log’ before, change it to ‘/var/log/httpd/[your site name]_access_log’

-while you are there, change the log format to ‘combined’

Setting up awstats on Mac OS X Server
o

Download the latest version of awstats (grab either the .zip or .tar.gz files)

Create a folder called awstats in your web documents folder, which is by default in /Library/WebServer. If you are keeping your web documents elsewhere, create your awstats directory there instead. The important thing is that the awstats folder be a subfolder of a web share.

Unpack the download, then place the contents in your awstats folder.

In Terminal, navigate to the tools subfolder of the awstats directory that you created. Next, run the awstats configure script by running ./awstats_configure.pl and answer the questions.
o-look for the section that asks you to define the config file name. Put your web site URL there (i.e. www.example.com) and take note of what you entered. A config file that you will need to edit later will be created with the name awstats.[your config name].conf in your awstats/wwwroot/cgi-bin/ directory.

You will likely need to edit your configuration file, awstats.[your config name].conf. The configuration files are well documented.

Edit the configuration file in your favorite text editor (vi, emacs)
look for the following lines and put in the appropriate values:

o
• -LogFile=”[path to the access log that you specified above]“

-default log format is Apache combined so as long as you chose that above you should be okay

o

• -SiteDomain=”[your site name]“

o

• -DirData=”.”

-this is where awstats will put the database of site visitation data. Putting a “.” here will tell awstats to store its data in the same directory as the awstats.pl file.

o
Schedule awstats to update your statistics

There are several ways you can do this. Mac OS X Server already runs maintenance scripts each night. You can insert the awstats update script into the maintenance script by editing /etc/periodic/daily/600.daily.server

Insert these commands below the line containing “log_message(“Starting.”);”

log_message("update awstats web monitoring statistics");
\`/Library/WebServer/awstats/wwwroot/cgi-bin/awstats.pl -update -config=[config file name]\`;

Test out your awstats page by going to http://[your domain name]/awstats/awstats.pl?config=[config file name] in your web browser. The statistics will be updated every morning at 3:15am when your server maintenance periodic scripts normally run.

awstats sample

Bonus: setup geoip country location.

Awstats can display what country your visitors are hailing from if you enable the geoip plugin.

First you must install the Geo::IP::PurePerl module. You can do this using CPAN, the Perl module download and installation utility. Before you can use CPAN you must have XCode installed on your system and you will need to configure CPAN first which it will prompt you to do when you run it for the first time. After you have those dependancies out of the way, issue this command:

perl -MCPAN -e 'install Geo::IP:PurePerl'

Next you should download the free IP to country database from Maxmind and place it somewhere on your system. The awstats directory is one logical place for it.

Now edit the awstats config file for your site. Locate this line and uncomment it by removing the # and put in the correct path to the GeoIP.dat file you just downloaded.

#LoadPlugin="geoip GEOIP_STANDARD /pathto/GeoIP.dat"

Refresh your awstats page to see your handywork!