masthead
 
 

Paint by Numbers set up of a Mac Mini Workgroup Server

How To Setup a SAMBA/openVPN Workgroup Server
for the not-so-super-Unix-y

Last Updated: 10/3/07

TABLE OF CONTENTS:

1. Introduction
2. Why
3. Purpose
4. Versions
5. Prerequisites
6. A Few Tricks & Shortcuts
7. OS X Security and Early Setup
8. Install Key Applications
9. Enable PostFix (OS X 10.4.+)
10. LogSentry Installation
11. SSH / SFTP / SSHD
.....11b. Setting Up SSH Keys
12. Changing the SSHD Port, "Security Through Obscurity"
13. SAMBA and User setup
14. Using Sharepoints
15. CUPS Printing and Printer Sharing
16. Virtual PDF Printer setup (sharing OS X's PDF Printer)
17. openVPN Setup on OS X
18. Remote Desktop Setup
19. Backups: Local
20. Backups: Off Site

1. Introduction

(10/25/2006)
I have now set up 3 distinctly different workgroup servers under OS X. As I get better at the setup, so do my notes. I've stumbled down many dead ends and taken several tines along numerous forked roads. I figure it's time to share these notes with a broader audience. Kind of like payback in kind for all the great websites I leaned on as I figured things out.

NOTE: One of the things that I found while scouring the web is out-of-date postings without any date reference whatsoever. I promise to keep the "Last Updated" (see the top of each sub-section) accurate and include version numbers of all software used at the time.

Back to Table Of Contents

2. Why

(10/25/2006)
Why have this document? Well, in addition to paying back the community, I have found that keeping detailed notes as-you-go helps me on future debugging and setup of additional servers. I also find that these notes keep me in-line as the night gets late and I'm two steps into deep water. In order to make this document remotely useful to anybody other than me, I have had to clean it up significantly. However, I have left scraps and snippets of notes when there are side roads or decisions I have made that need some explaining......or even if I feel like the notes are just worth leaving in. Consider it simply one path to take with many forks pointed out along the way.

Back to Table Of Contents

3. Purpose

(10/25/2006)
I hope this document serves at least one of several purposes. First, to show that OS X is not only a beautiful GUI but also a kick ass UNIX core capable of being a full fledged server -- even if it is set up and administered by a total hack (that's me). Second, to support the community that has helped and support me. Third, to provide either a full how-to or bits and pieces a la carte.

On the flip side, this is not a document claiming primacy in any way, shape or form. I'm not going to get into flame wars over security or any of that. This is stuff that has worked for me and may work for you. The servers I have set up have been secure enough and have run intrusion free for several years on end while fully exposed to the outside world. Sure, a dedicated cracker probably could get inside, but the prize is simply not worth their effort (as in, this is not a bank or DOD computer.....'Would you like to play a game?') Secure Enough is a valid test: if you can sleep at night, then your server is secure enough.

4.  Versions

(11/1/2006)

Here's the most up-to-date listing of what this document involves.  To stick with the OAOO (once-and-only-once) rule-of-thumb, this is the only place you'll find version information.

HARDWARE

  • Mac Mini
    • Intel Core Solo, 1GB RAM, 60GB internal HD
  • External Firewire Drive
    • 120GB, external from OWC

NOTE: This setup also works with 800MHz iMac G3 running 10.4+. I like buying old iMacs off of eBay for $300 and turning them into full house servers and drop-in internet surf locations. And old iMac (3+ years) can make a fine drop-in house server and the price is unbeatable.

SOFTWARE

  • Operating System
    • OS X, 10.4.x (latest)
      • (10.4 uses PostFix instead of SendMail)
      • (10.4 uses launchd instead of cron/periodic/xinetd)
    • 3.0.1
    • 2.x
    • 1.1.1

NOTE: This setup also works under 10.3 (for the most part) although there are some major differences. OS 10.3 does not have launchd (use periodic or cron or xinetd) and still uses sendmail (as opposed to 10.4's use of postfix). Regardless, you should be able to get most of the stuff to work, or find tutorials elsewhere to help ya' out.

Back to Table Of Contents

5. Prerequisites

(11/1/2006)

Straight up, you're going to need to know some basic UNIX commands and you'll need to know your way around your Mac GUI (i.e. where Applications, Utilities and your Documents folder exist). I recommend putting Terminal in your dock (~/Utilities/Terminal.app) for quick access.

NOTE ABOUT FILE SYSTEM LINKS: From here on out, file-system links work for Mac users using Safari. Also NOTE: links to your HOME directory (signified with a ~) are not active at this time. Anybody know how to web link inside ~/ ??. Contact Me.

A really really great FAQ for OS X users can be found here .
Switchers may want to consider doing a onceover of MacTacToe.

You'll also want to know the difference between ~/Library (your home directory's Library folder) versus /Library (top level Library) and /System/Libary (top level, System, Library)

Back to Table Of Contents

6. A Few Tricks and Shortcuts

(11/1/2006)

IMHO, OS X is the world's best GUI on top of a variant of the world's best and most powerful OS (UNIX). Even for UNIX ultra-geeks, GUI's can be useful! There are things you can do much faster in a GUI without having to memorize all sorts of archaic commands. At the same time, there are things that you can do using the UNIX CLI (Command Line Interface) that are simply impossible (or ultra slow) in the GUI. Learn your own strengths and efficiencies and apply the tool best suited for the particular task.

Here are a couple of tricks and suggestions that I use all the time.

Drag & Drop Into Terminal.app
Simply drag a folder or document into an open Terminal window and bingo, you have the path to said folder or doc. Fully escaped and everything! I use this feature all the time, even when I'm not doing UNIXy stuff, because you can drag-select the text and copy-paste it into some other app.

Keep a mirror folder of changed files
In my ~/Documents directory I create a folder called !Server_Setup (the "!" keeps it at the top of the column view list for quick access). Inside !Server_Setup I keep this document (or some other text document called !serversetup.txt) where I keep notes as I go. I also create a set of directories that mirror the UNIX side of any changed files called "Changed_Files" I do this for 2 reasons: (1) just in case an OS X update writes over a file that I've changed or altered and (2) to make it easier to setup another server in the future.

  • For instance, the Samba configuration file (smb.conf) is located at:
    • /etc/smb.conf
  • Before working on the file, I create a backup using the command:
    • sudo cp /path_to/original.file /path_to/original.file.backup
  • I also save an exact copy of the altered file in:
    • ~/Documents/!Server_Setup/Changed_Files/etc/smb.conf
  • Likewise, after adding an "openvpn" directory to /etc, I'll create a mirror:
    • ~/Documents/!Server_Setup/Changed_Files/etc/openvpn/

Sure seems like a lot of work, huh? But it has always been worth the extra 10 seconds. TextWrangler (more on that later) makes this easy with it's "Save A Copy.." command. It is incredibly valuable to be able to revert to a previous version, or simply have the peace of mind that your smb.conf file won't get obliterated by a security update. Some could argue this is a security hole, but I figure if somebody's got access to my admin's Document's folder they've got the machine by the short-n-curlies anyway.

Keep a TO DO list
In the ~/Documents/!Server_Setup/serversetup.txt file, at the very top, I usually keep a "TO DO STILL" list. Since I can't setup a server in a single session (takes a few nights) this is handy to keep me on task and for jotting down other items so I can focus on the task at hand. Likewise, at the bottom of serversetup.txt I retain the notes of even failed paths in a section called: THINGS I TRIED THAT DIDN'T WORK (like the time I attempted to get WebDAV working on Apache 1.5). Quite often, those notes come in handy, either for reminding me of what I've tried, why I've failed or for a second go-around on making it work.
.

Back to Table Of Contents

7. OS X Security and Early Setup

(11/8/2006)

This assumes that the machine (or OS install) is brand-spanking new. Obviously, you may not need all the steps. In a rough order of events:

  • Create an administrative user account. DO NOT call this user "admin", "administrator" or "root" or any other common name. That just makes it even easier for SKIDS (script-kids).
  • Give your admin account a secure password. (basic info here at about.com)
  • Enable root and set a secure password. Then disable root.
    • To enable root, go to: /Applications/Utilities/NetInfo Manager.app Under "Security" menu, select "Authenticate". This will then enable you to select Security->Enable Root User. When the root is enabled, the menu item will read Security->Disable Root user, (There is lot's of cool stuff in NetInfo Manager, we'll be using it later).
    • It is more secure to have root disabled, since "root" is the most frequent target account for cracks. Don't worry, you can still sudo from the command line.
  • Open System Preferences\
    • In the Security Panel:
      • Select: Use Secure Virtual memory
      • Select: Require Password to Unlock Each Secure System Preference
      • Optional: Require password to wake this computer from sleep
        • I don't enable this on my home server, for it operates as a "drop-in" for family and friends. However, for a work server this is definitely enabled.
      • Optional: Disable automatic login
        • I wish there was an easy option to automatically start up into an account and immediately lock itself down. For now, I enable automatic log in so that the server comes back up after a power outage. I figure if somebody has physical access to the server, it's compromised anyway. As a partial defense, I set the screen saver to turn on in a short time so that after auto-login the server locks itself down. This is secure enough for my purposes. Another possibility is to have the server auto-login to a non-admin account to start up essential services. More in depth options can be found here at macosxhints. Do what you like.
    • Enable the Firewall:
      • In the Sharing Panel: Click on Firewall and select the Start button.
      • Click the "Advanced" button and select both "Enable Firewall Logging" and "Enable Stealth Mode"
    • In the Networking panel:
      • I prefer hard-coded IP addresses for my servers.
      • Write down IP address in you serversetup.txt file along with subnet mask, gateway and DNS settings. You'll find yourself referring to this quite often.
      • NOTE: on my MacMini Intel Core Solo under 10.4, I was seeing really slow ethernet performance until I manually set the ethernet to 100baseTX, Full-Duplex, Flow control (standard). Don't know if this is fixed now---posting this for reference.
    • Desktop & Screen Saver:
      • NOTE: I like to set my admin account desktop and screen saver to something distinct that I do not like too much. Why? Keeps me from being too comfortable logged in as admin user and encourages me to log in (typically) as a normal user.
    • Energy Saver Panel:
      • It's a server, right? You probably don't want it going to sleep. And you probably want it restarting automatically after a power failure.
      • Slide the sleep slider over to "Never"
      • Check the button to automatically restart after power failure
  • Set the servers Workgroup
    • Under /Applications/Utilities launch Directory Access.app and Configure SMB/CIFS.
    • Name your Workgroup wherever you want those windoze blokes to see your server under.
    • NOTE: In Windows-land it is a lot easier to find shared directories in the same workgroup. Macs have no problem finding other workgroups on their network, so setting your workgroup will save you the frustration of dealing with windoze users later on.
  • Setup Terminal Prefs
    • Change your color, transparency prefs. I like green on partially transparent black for that cool old-school matrixy look.
    • Copy over (if you have them) your familiar .profile and .tcshrc to your ~/ directory
      • I usually keep a backup of these files in my !Server_Setup directory.
  • Setup a Mail Account for your server and then set Mail.app to check that mail.
    • e.g. myserversname@hotmail.com
      • This can be really useful for sending file snippets and whatnot to your server from your laptop or elsewhere. It also gives your server an outlet. This may be where you want to send a copy of root emails as well.
  • Redirect root emails to yourself:
    • In terminal, at the prompt type: sudo pico /var/root/.forward
    • Change the /dev/null line to a real email address you want root emails to go to.
    • Write the file out and close it.
  • Optional: Create daily and weekly updater scripts.
    • Note: This is optional, it's not always best to auto-update your server, and I don't feel like getting into a long discussion here. That said, Apple is really good about issuing stable updates and I have been auto-updating my "production" servers for some time now.
    • Here's an example daily updater script (constructed from various online sources) and weekly updater script. Download them somewhere & hack away in TextEdit or TextWrangler.
    • In terminal: cd /etc/periodic
    • Remember that drag-n-drop trick from above, it's a quick way to get the path of a file onto the command line in Terminal (replacing the "path_to" placeholder below)
    • In terminal: sudo cp /path_to/700.dailyupdater.sh ./daily/
    • and: sudo cp /path_to/weeklyupdater.sh ./weekly/
    • Verify they are executable: ls -al ./daily and ls -al ./weekly
      • Don't see -rwxr-xr-x in front of your updaters? Then make the file executable with: sudo chmod +x ./daily/700.dailyupdater.sh (or /weekly/weeklyupdater.sh)
    • Keep backups in your local "Changed_Files" directory that you created earlier.

Back to Table Of Contents

8. Install Key Applications

(11/8/2006)

There are a bunch of applications that I install at the very beginning. Most of these apps are freeware or shareware (please be a good citizen and contribute!). There are numerous other apps that have similar (or the same) functionality, but these are my favorites that I keep in my toolkit.

In a rough order of events:

Install Apple's Developer Tools (aka Xcode). Apple GIVES YOU some very powerful developer tools for the price of a little disk space. These come on the OS installation CD/DVD or you can download them from developer.apple.com Plus, you'll need these installed for some of the source compiling that will occur later.

Download and Install the following apps:

  • TextWrangler www.barebones.com
    • Essential. Install the command line tool. Then from a command line you can type "edit filename" and TextWrangler hops open to give you a GUI. TW also does colorized syntax and opening of hidden files directly. For the rest of this HowTo, I use "edit" to tweak on files in lieu of pico or emacs.
  • CarbonCopyCloner www.bombich.com
    • Essential. Great tool for making bootable backups. Shareware. SuperDuper is supposedly equal or better. CCC can be scripted for automated clones.
    • Another alternative is SuperDuper, but I have not had the opportunity to use it as of yet.
  • DarwinPorts www.macports.org
    • Essential. We'll be using DarwinPorts because it meshes better with OS X than Fink does. Unfortunately, at the time of this writing, DarwinPorts is in transition and it's not nearly as easy as the old site. There is a GettingStarted page that may help you along for now.
    • ipcalc is a nice download from Darwin ports.
  • TinkerTool www.bresink.com/osx/TinkerTool.html
    • Good To Have. Great for setting and tweaking on various system settings. My favorite is the double-double arrow scroll bar settings.
  • Onyx www.titanium.free.fr
    • Good To Have. Along the lines of TinkerTool with some additional features.
  • Cyberduck cyberduck.ch
    • Good To Have. If you need to do SFTP to your server or to another one, cyberduck is a great OS X app for the job.
  • LaunchdEditor www.codepoetry.net
    • Good To Have. Provides a reasonable GUI for OS 10.4's new launchd service (no more cron or xinetd). You can also edit launchd plists inside Property List Editor or even TextWrangler.
  • Firefox www.mozilla.com/firefox
    • Optional. Safari (with tabbed browsing) will do the job, but if you may want a more powerful browser on your server that is also broadly accepted by sites.
  • VLC Media Player www.videolan.org/vlc/
    • Optional. If you need to play WMV files, this is your ticket. I've used Flip4Mac but had problems with how it integrated into my browsers and clobbered various other settings.
  • SharePoints www.hornware.com/sharepoints
    • Essential. Chances you'll be running SAMBA on this server. While I don't use Sharepoints for editing or setting up my smb.conf file (it does strange things to your comments), I do use it as a front end for setting up groups and user accounts for the share. This is far easier than doing some of the same tasks in NetInfo Manager.
  • ManOpen www.clindberg.org
    • Essential. If you are not a UNIX guru (just an amateur hack like me) you'll want manopen. It hyperlinks man pages and opens them in a viewer so that you don't clutter your terminal window with man pages as you try to figure out the flags for "ls". Better yet, have multiple man pages open in an easy-to-move-out-of-the-way GUI. Be sure to put an alias to openman in your profile.
    • Be sure to read and follow the install instructions (e.g. install openman in /opt/local/bin)
  • Fink fink.sourceforge.net
    • Good To Have. Lots of great UNIX stuff out there on fink. FinkCommander is a Mac GUI that helps download all the great open source goodies out there.
    • nmap is one of the fink sources I would recommend. Helps you portscan yourself looking for open holes. NOTE that OS X comes with /Applications/Utilities/Network Utility.app that also has lots of goodies wrapped in a tasty GUI.
  • StuffitExpander www.stuffit.com
    • Optional. Occasionally you come across an old .sit file. You need Stuffit. NOTE: Use a junker email address, as allume systems is notorious for spamming you with "offers".
  • Tunnelblick www.tunnelblick.net
    • Optional but Recommended. You are setting up an openVPN server on your Mac, right? If so, you may eventually need Tunnelblick, the openVPN GUI for the Mac.

Back to Table Of Contents

9. Enable PostFix (OS X 10.4.+)

(11/22/2006)

Prior to 10.4, OS X used sendmail. Sendmail supposedly has some issues, so in 10.4 you'll need to enable PostFix instead. PostFix appears to be incredibly scalable, awesome and powerful. But don't be afraid, it is also well documented!

If you plan on using LogSentry (next section) you'll want to run through this section first so that LogSentry can send you emails (which is kind of the point).

I got a lot of help from http://www.david-reitter.com/software/osxpostfix.html and am essentially distilling his page down.

  1. Download the postfix-tiger.tar to your desktop and double-click to extract.
  2. In terminal: sudo postfix start
  3. To make sure postfix launces on startup (this is weird! Surely there must be a better way to do this!)
    1. cd /System/Library/StartupItems
    2. sudo mv ~/Desktop/Postfix .
    3. sudo chown -R 0:0 Postfix
    4. sudo chmod +rx Postfix/Postfix
  4. Edit your /etc/hostconfig file (and be sure to save a backup into Changed_Files)
    1. sudo edit /etc/hostconfig
    2. Find the MAILSERVER= line and change it to: MAILSERVER=-YES-
    3. If there is no such line, add it at the end.
  5. Optional: You can set Mail.app or Entourage to use 127.0.0.1 in order to send email using Postfix.
  6. That's pretty much it, but you really should edit some options in main.cf (and save a backup of main.cf)
    1. sudo edit /etc/postfix/main.cf to edit your config file
    2. Changed myhostname to myservername.mydomain.com
    3. Advanced (optional): i setup some canonical mapping to make mails sent from various accounts on the server appear as if sent by the server itself. To do this:
      1. Read up the SAMPLES from /etc/postfix/samples .
      2. Edited main.cf around lines 375-400
      3. Uncommented: alias_maps = hash:/etc/aliases
      4. Uncommented: alias_database = hash:/etc/aliases
      5. Then added "CANONICAL MAPPING" section to main.cf (see snippet examples of my main.cf file here)
      6. added: canonical_maps = hash:/etc/canonical
      7. added: sender_canonical_maps = hash:/etc/canonical.from
      8. added: recipient_canonical_maps = hash:/etc/canonical.out
      9. sudo edit /etc/canonical (here's my canonical file...names altered of course. Also, here are my canonical.from example and canonical.out example).
      10. Save the file and a backup in Changed_Files course!
      11. sudo postmap -p /etc/canonical to generate the db file
      12. sudo postfix reload (force the refresh)
  7. Test it out: mail -s "this is a subject" test@address.com
  8. Verify: sudo tail -25 /var/log/mail.log
  9. Other PostFix Notes:
    1. If nightly OS X permissions fixing is screwing up your postfix install, you might want to downoad David Reitter's repair_postfix.sh script and drop it into /etc/periodic/daily
    2. Another option may be Postfix Enabler: http://cutedgesystems.com/software/PostfixEnabler/
  10. Some PostFix Commands of note:
    1. To reload the config file: sudo postfix reload
    2. To test the config file: sudo postfix check
    3. To stop postfix: sudo postfix stop
    4. To look at the mail queue if something is stuck: postqueue -p
    5. To delete stuck messages: sudo postsuper -d #### (where ### is the msg # of the stuck msg)
    6. The get a verbose status: sudo postfix -v -v check

Back to Table Of Contents

10. LogSentry Installation

(11/23/2006)

LogSentry (LogCheck) is a great tool for monitoring keywords in your system logs and then emailing them to you at a regular interval. Talk about peace of mind. Note: This set of instructions assumes DarwinPorts. Unfortunately, I do not have instructions for MacPorts quite yet, but these may be close enough to help you get the job done and may still work nonetheless. Note: you'll need to set up a system mail handler (PostFix under 10.4) to send mail.

We're basically going to follow the instructions from logsentry's INSTALL instructions. They are superb!! If something here doesn't work

  1. Install logsentry (http://logsentry.darwinports.com/) using darwin ports command (in Terminal):
    1. sudo port install logsentry
  2. 2 Figure out where your various pieces went with the command: port contents logsentry
    1. Note: I had to create a temp directory /opt/local/etc/tmp (may not be necessary in your case)
    2. Make sure it's not there first, then you can do this with the command:
      1. sudo mkdir /opt/local/etc/tmp
    3. For now, we want the location of the following:
      1. logcheck.sh....mine is in: /opt/local/bin/logcheck.sh
      2. INSTALL.........mine is in: /opt/local/share/doc/logsentry/INSTALL
  3. Read the INSTALL file. As I've said, it is well written and we're basically just following its instructions.
  4. Edit logcheck.sh (Here's what I had to do...)
    1. sudo edit /opt/local/bin/logchheck.sh To open the file for editing in TextWrangler.
      1. Note: it helps to have line numbering turned on for this part.
    2. Line 55: TMPDIR=/opt/local/etc/tmp
    3. Line 47: LOGTAIL=/opt/local/bin/logtail (remember that port contents logsentry command?)
    4. Line 92: HACKING_FILE=/opt/local/etc/logsentry/logcheck.hacking
    5. Line 101: VIOLATIONS_FILE=/opt/local/etc/logsentry/logcheck.violations
    6. Line 118: VIOLATIONS_IGNORE_FILE=/opt/local/etc/logsentry/logcheck.violations.ignore\
    7. Line 128: IGNORE_FILE=/opt/local/etc/logsentry/logcheck.ignore
    8. Save a backup copy of logcheck.sh into your Changed_Files directory.
  5. Follow INSTALL's instructions for creating /var/log/messages file.
    1. Note: on OS X, logs are kept under /var/log
    2. Here's what I did:
      1. sudo pico /var/log/messages (to create the file)
      2. save and write the file out (yup, it's blank)
      3. sudo ls -al /var/log to see what permissions are like for other logfiles. Typically -rw-r-----
      4. To get its permissions correct: sudo chmod 640 /var/log/messages
  6. Per INSTALL's instructions, add a line to /etc/syslog.conf
    1. sudo edit /etc/syslog.conf
    2. The line looks like:
      1. *.info /var/log/messages
      2. NOTE: some syslog.conf files care whether you use tabs or spaces. Check some of the other lines to make sure you choose the right option here.
    3. Save a backup copy of syslog.conf into your Changed_Files directory
  7. Create a periodic log rotation for rotating messages:
    1. You can use this example 600.messagelog for rotating the message log (Be sure to save a backup to Changed_Files)
    2. sudo cp /path/to/600.messagelog /etc/periodic/daily/ to move the file into the periodic's daily directory.
  8. Double check that /var/root/forward is set to forward to an email address (see Initial Setup section.
  9. Create a LaunchDaemon (launchd) plist file to launch logcheck.sh
    1. You can use LaunchdEditor.app to help, or download a copy my logcheck.plist file.
      1. Note: I've set this particular launchd job to run every 2 hours, which is often enough to give me a sense of security without completely overloading my inbox. After a few emails you get pretty good at scanning and looking for irregularities.
    2. sudo cp /path/to/logcheck.plist /Library/LaunchDaemons/ to move your logcheck plist to the right place.
    3. verify permissions or set: sudo chmod 644 /Library/LauncDaemons/logcheck.plist
    4. verify ownership or set with: sudo chown root /Library/LauncDaemons/logcheck.plist
    5. verify group or set with: sudo chgrp wheel /Library/LauncDaemons/logcheck.plist
    6. Save a backup copy of logcheck.plist to Changed_Files directory.
    7. Note: I had problems with the launchd job re-spawning constantly until I put OnDemand = True, something that supposedly isn't necessary. I still see spawning issues from time to time, but at least it's working.
  10. Use the launchctl command to load into launchd.
    1. sudo launchctl load -w /Library/LaunchDaemons/logcheck.plist
    2. You can verify the plist is loaded with: sudo launchctl list
    3. You can force the job to run with: sudo launchctl start logcheck
  11. You can poke into your messages file to verify things are collecting in there (and logcheck is at least working).
    1. sudo tail -25 /var/log/messages
  12. Now, if PostFix is working, steps 10 & 11 should have resulted in an email being sent out (you can actually see the postfix actions recorded in the messages log).

Back to Table Of Contents

11. SSH / SFTP / SSHD

(12/3/2006)

If you're running a server that has internet access, you may want to be able to remotely administer it. OS X makes it easy to turn the SSH service on and off (for an "as needed" basis should you not want to leave it on all the time). Don't knock remote access, properly locked down with strong passwords it can be "secure enough" for my tastes. Remote access lets you do such cool things as setting up PostFix and LogSentry remotely from home in your slippers!

This is where Cyberduck (or another SFTP application) comes in handy.

  1. Open System Preferences and select the Sharing panel. Turn on "Remote Login". That's it! Your SSH (and SFTP) service is now up and running. But that's really not good enough or secure enough for that matter, so turn off "Remote Login" until we finish with the next few steps.
  2. In terminal, first make backup of the original: sudo cp /etc/sshd_conf /etc/sshd.conf.bak
  3. In terminal: sudo edit /etc/sshd_config Seriously, why can't all the config files share the same naming convention!!
    1. Uncomment the line that reads "Protocol 2, 1" and make it read "Protocol 2" only.
      1. Protocol 2 is evidently more secure than 1
    2. Change the port to one of your chosing, but leave the line commented out for now.
      1. We'll uncomment and talk about that in the next section.
      2. NOTE: Pick a 4-digit port number somewhere above 1000 that you can remember. It can be just about anything...we'll check for conflicts (or what we're clobbering) in the next section. The example file above uses port 1111.
    3. Add a line: "AllowUsers username1 username2"
      1. This is a key security measure. On a server with many user accounts, you really only want to allow remote access for one or two of those accounts. Make sure these account names aren't readily guessed (like "root" or "admin") or you'll just make the job for the script kiddies easier.
    4. Optional: On a computer with multiple ethernet adapters (like wired + wireless) set the "ListenAddress" to the one that matters for you. i.e. "ListenAddress 192.168.1.1" to listen to the ethernet port but not the airport adapter.
      1. Listening to only the wired connection can be a security improvement, and limits the number of possible access points to the system.
    5. Optional: Uncomment "MaxStartups" line. Mine is set for "MaxStartups 2".
      1. This limits the maximum sshd processes on the system at a time. This should help keep parallel attacks to a minimum and slow those types of attacks down a little.
    6. Save the file, and don't forget to save a backup copy in Changed_Files
  4. Go ahead and use the GUI to reload the sshd_config file by going back into System Preferences and turning "Remote Login" off and then back on.
    1. Yes, there is a command line way of doing this too, try: sudo killall -SIGHUP sshd
  5. To grep for attackstry the following command:
    sudo grep 'failed to authenticate' /var/log/secure.log
  6. Also note, there are tutorials out there for setting up private keys (for better, some say simpler, security than just a password), but I find a strong password secure enough for me to sleep at night and slighly easier to manage than the key files.
  7. Verify that the firewall allows traffic on the port (if you used the GUI in step 4, this was automatic, otherwise you'll have to go to the Sharing control panel and adjust the firewall for remote login).
  8. Test your setup:
    1. From terminal: ssh username@127.0.0.1
    2. From another computer: ssh username@public.ip.address
    3. You should have command line capability to troll around. Proceed to section 12 to learn about adding a little obfuscation.
    4. Optional: setup Cyberduck to access the server via sftp (either locally or externally).
    5. Optional: Windoze users can access the server using and sftp app like WinSCP.
    6. Optional: You can set the home directory for users in NetInfo Manager.app by setting the path for home to something like /Users/UserHome
  9. Here's my sshd_config_examp and banner_examp , but these are a little different from what you might have at this point (the port has been set to 1111 and the ListenAddress has been set, the MaxStartups has been set)

Back to Table Of Contents

11b. Setting up SSH Keys

(8/9/2007)

While this step is optional, it really does help out later (with offsite backups, a much later section) and improve upon simple password based security. We're going to be setting up a basic public key infrastructure for ssh login so that our server can log into another server (elsewhere on the network) and then send files over an ssh tunnel for remote backup.

This is a 2-part setup, as we have to configure both the client machine and the host (server) machine.

Client Machine Setup

  1. In preparation, create the directory where you plan on saving your keys
    1. mkdir /Users/username/.ssh (this is kind of the default)
  2. 2 At the prompt, type ssh-keygen This is the application used to generate a public/private rsa key pair. We're going to accept the defaults, as this works with both protocols #1 & #2
    1. Enter the directory/file where to save the keys...the default should be something like (/Users/username/.ssh/id_rsa)
    2. NOTE: If the directory does not already exist, then you will eventually get a failed message, hence Step 1 above
    3. Optional: enter a password to protect the private key usage
  3. This creates 2 files in that .ssh directory, "id_rsa" and "id_rsa.pub".
  4. 4 Now, create a file in .ssh directory named "config" (edit config if you want to use TextWrangler, or nano config)
  5. 5 Save the following into your .ssh/config file
    PubkeyAuthentication yes (this is the default behavior for protocol 2, and both machines will need to use this, so I like to spell it out).

Host (Server) Machine Setup

NOTE: Your client will be using ssh to log into your host machine utilizing a specific account. This is an important distinction, as you need to follow the next set of instructions for that specific account. Since we are essentially enabling one machine to have full access to another, it may be a good idea to setup a somewhat restricted (non-admin) dummy account on your host machine so that if your client machine gets compromised, the access on the host machine is somewhat (initially) restricted and/or easier to shut down.

  1. If it doesn't exist, mkdir ~/.ssh to create the directory
  2. edit authorized_keys (or nano authorized_keys) to create a file "authorized_keys"
  3. Here's the trick that took some guess work. Copy the contents of your client machine's ~/.ssh/id_rsa.pub into the host's authorized_keys file. NOTE that each key ends up getting it's own line -- similar to the known_hosts file.

Checking the Setup

  1. On the client machine, you should now be able to type: ssh -p xxxx user@IPAddress and not have to enter a password.
  2. Should #1 fail and require a password, try ssh -v -p xxxx user@IPAddress
    1. The "-v" puts ssh into verbose mode.
    2. Read the output line by line to see what ssh is trying, where it is looking for files and then check your setup appropriately.
    3. One of the things to double check is which files the host is using (remember that specific account thing I mentioned earlier? The ssh key works from a specific account to a specific account.
    4. Having the hosts known to each other is another potential stumbling block. The first time you establish an ssh connection, you'll get a warning about a host fingerprint and something that looks like: a6:8f:32:16:11:6b:16:c0:59:b1:af:e1:cc:8e:c3:1b . That fingerprint gets saved into your ~/.ssh/known_hosts file. If the host is not recognized, the automatic ssh-ing might fail. Sometimes it is necessary to delete the fingerprint line for a given known_host so that you can re-set the value.
    5. Depending on your systems, various authentication methods may not match up. You may have to specify an authentication method in ~/.ssh/config on both machines.
    6. Don't give up. For the life of me, I couldn't get it to work at first until I double checked my setup, and sure enough, I had made 1 or 2 boneheaded slip-ups in copying files over.

Back to Table Of Contents

12. Changing the SSHD Port, "Security Through Obscurity"

(12/3/2006)

Don't even bother flame warring over this one, I know that purists hate "Security Through Obscurity". As a first line of defense, steganography has been around for 1000's of years and is a useful (albeit basic, simplistic) layer of protection against scripted attacks. If skiddies don't know something there, they'll have a lot harder time cracking it.

Truth be told, I have found firsthand that changing the listening port of your ssh daemon will reduce the number of scripted attacks by greater than 99%. Yup, my server's ssh port was constantly getting knocked on by skiddies and my logs were filling up with all their futile fatal attempts (username 'root', 'admin', etc). Simply put, those bastards were wasting my CPU cycles.

Moving ssh to another port reduces the quantity of attacks (less load on your server) and makes it easier to scan your logs for actual threats. Sure, there are other ways to do this (like editing obscure firewall tables or simply creating a redirected port pinhole through your hardware firewall--I found this link helpful.).

I had to change both the ssh (outgoing) and sshd (incoming) ports to get this to work. Here's what I did:

  1. First, pick a port number you can remember and hope it isn't some other essential service. For this writeup, we'll clobber port 1111
  2. Backup of the original /etc/services with: sudo cp /etc/services /etc/services.bak
  3. Edit /etc/services with: sudo edit /etc/services
    1. Add a "#" to comment out the 2 lines that read "ssh 22/udp..." and "ssh 22/tcp...", the outgoing handler
    2. Directly below, you may want to add something like: "# CHANGED BY ME ON 1/1/1901"
    3. Add two more lines formatted the same, but with your new port number:
      1. ssh 1111/udp
      2. ssh 1111/tcp
    4. Scroll down to the port of your choice and comment out what's there (in this example, "#lmsocialserver 1111/udp" and "#lmsocialserver 1111/tcp"
    5. Add two more lines, formatted the same, but THIS TIME for "sshd", the listener
      1. sshd 1111/udp
      2. sshd 1111/tcp
    6. Note: Setting both the ssh (outbound) and sshd (inbound listening) port appears necessary to get this port redirection to work.
    7. Save /etc/services and save a backup copy in your Changed_Files directory.
    8. Note: Under OS 10.3, I actually had to go in and edit xinetd...but as of OS 10.4 and with the introduction of launchd this appears unnecessary, so I have not included those notes.
  4. Once again: sudo edit /etc/sshd_config
    1. Make sure your port is set: "Port 1111" in our example and make sure the line is uncommented.
    2. Save the file and save a backup copy in Changed_Files.
  5. Restart remote login (either through the Sharing Control Panel) or sudo killall -SIGHUP sshd
  6. Make sure your firewall allows your particular port through (you will have to add a new line to the Firewall settings in the Sharing Control Panel).
  7. Test your setup:
    1. From terminal: ssh -p 1111 username@127.0.0.1
    2. From another computer: ssh -p 1111 username@public.ip.address
    3. Optional: setup Cyberduck to access the server via sftp (either locally or externally) and enter your new port number.
    4. Optional: Windoze users can access the server using and sftp app like WinSCP.
    5. Optional: You can set the home directory for users in NetInfo Manager.app by setting the path for home to something like /Users/UserHome Once again, here are my sshd_config_examp and banner_examp for reference.

Back to Table Of Contents

13. SAMBA Setup

(01/25/2007: updated 5/5/2007)

Simply put: SAMBA is industrial strength network file sharing. SAMBA does Windows Files Sharing (better than Windows itself). Samba also does sharing across platforms and is open source. There are so many great guides, howtos, examples and whatnot, that this tutorial is really just some more noise. I'm simply showing one way to set up a basic office server (we have 10+ users) on a Mac Mini under OS 10.4+. Alternatively, you can use Sharepoints [See Section Below] for handling all the nitty gritty setup.

First off, SAMBA ships with OS X and is integrated into the GUI. Turning on SAMBA is as simple as going to the Sharing Control Panel in System Preferences and enabling Windows File Sharing. Note that this also automatically punches the appropriate hole through the Firewall.

Second, Apple kicks ass and ships the complete O'Reilly Using Samba book in /usr/share/swat You have two ways to get to it: (1) in Terminal: open /usr/share/swat/using_samba/toc.html (2) or while on your Mac click this link. This is a worthwhile read and reference to keep at hand.

  1. Backup /etc/smb.conf with: sudo cp /etc/smb.conf /etc/smb.conf.bak
  2. Then: sudo edit /etc/smb.conf Here is an example smb.conf file that I've used.
  3. Be sure to save a backup in your Changed_Files directory
  4. Test your config file by typing: testparm at the command line
  5. Restart SAMBA
  6. From the command line: sudo killall -HUP smbd
  7. -or- from the GUI go to System Preferences' Sharing Control Panel and toggle Windows File Sharing.
  8. Wait a bit, since there's all sorts of "elections" and arbitration that the networked computers have to do. Sometimes this can take like 5 minutes or more.
  9. In the Finder: Check your network locale and your server should be there.

NOTE: Windows users may have a tougher time, simply because Microsoft likes to limit network neighborhood to one's specific workgroup.

13-b SAMBA User Setup

(5/5/2007)

There are a couple of tricks to getting users and such to work out correctly. Sure, you could utilize Netinfo Manager.app, or you could take the convenient shortcut and use Sharepoints instead. Using Sharepoints:

  1. Create your users in the Users & Public Shares tab. Give them a name and a short name, and assign them to a group (I prefer "staff" for general purpose users. Get the next UID and then click "Add New User" to make a share only user. Share only users don't have nearly the extra baggage that a typical OS X user comes with. Unless the user is logging into the machine directly, share only users are just fine.
  2. Be sure to have your user enter their password.
  3. In the "Groups" tab, add this new user to whatever groups they should belong to. If you need to create a new group for better Samba control, go to town.
  4. However, before your user can log on, their account must be enabled for Windows Share access.
    1. Go to your System Preferenes and select the "Sharing" control panel.
    2. Click on "Windows Sharing" (Services tab) then click on the Accounts... button.
    3. Select the account you wish to allow access via Samba and have your user re-enter their password.

13-c SAMBA Shared Folder

(5/5/2007)

If you read the example smb.conf file, you'll notice a line under the share definitions that reads: inherit permissions = Yes . Basically, if you point a share to a folder on your drive, that folder's permissions will be inherited as users create files and folders below. In general cases, you might browse (in finder, whatever) to your main share folder and Get Info (command-i). Check out the user and group. If you set up your "typical" user as a member of the staff group, you will want to set the group permissions to staff for your root shared folder. Alternatively, you could use chmod, chown, or chgrp from the command line.

In the same example, you can see how members of the consultants group were barred from a certain folder, while members of staff have access. Access can also be done on a user level. For instance, if you set the "User" to a particular user and grant them full access, but set the group to "admin" or something, you will effectively limit all other users from seeing this folder. This is particularly useful with the hide unreadable = yes setting. Users won't be annoyed that they do not have access to something if they are unable to see that something in the first place!

Another alternative is to use the create mode = 755 option for making sure your users create files that other share users can access. One of the common problems I found when first setting all of this up is that users would get locked out of files that other users set up. This was typically my error for not setting up the root folder's access permissions correctly. Additionally, users that "ssh"d into the server could create files without going through SAMBA -- files that were then set up without inheriting permissions from above.

Back to Table Of Contents

14. Using Sharepoints

(5/30/2007)

As mentioned earlier, Sharepoints is a kick-booty shareware application that helps you deal with Samba and NetInfo to create user accounts and network shares. You can find Sharepoints here.

In more detail, Sharepoints is a cool little tie-it-all-together-app that makes is easier to set up SMB shares and group shares under OS X. It basically edits the /etc/smb.conf file for you and works to create some NetInfo Manager stuff (like user accounts assigned to certain groups). If you have ever worked in NetInfo Manager, you'll realize that there are a lot of potential pitfalls and errors that can be made. NetInfo can also feel more like a tangled web of settings than a clean workflow.

Using Sharepoints (in lieu of NetInfo Manager) you can create new groups, users, and even assign passwords from within Sharepoints. I find it a lot quicker to setup Share-Only users and groups inside of Sharepoints than to go mucking with NetInfo Manager. Sharepoints also makes it easy to assign users to one or more groups. Remember, if you like Sharepoints and use it regularly, be sure to donate some $$$ to support its continued development.

IMPORTANT NOTE: If you do hand-edit your smb.conf file and include comments lines and such, DO NOT change share definitions while inside Sharepoints, as Sharepoints will trounce all over the smb.conf file and mess up the editing and comment locations. I prefer to manually edit my smb.conf file so that I can add comments and more advanced settings. I use Sharepoints for the user and group administration tasks

The set up a share using only Sharepoints:

  1. Create your directory to share (somewhere on your harddrive, I typically go with /Users/MySharedDirectory)
  2. "Get Info" and set the group to your shared group (i.e. staff) with RWX priveledges
  3. Open Sharepoints and click on the "Normal" Shares tab
  4. Enter a name for your share under "Share Name:" Grant the owner (most likely yourself) and group (most likely staff) permissions (most likelly owner = r/w, group = r/w, everyone = up-to-you).
  5. Be sure to select "Inherit permissions from parent" to keep the share behaving more openly for multiple users.
  6. Decide whether you want guests accessing your shares.
  7. Specify that directory you created in step #1.
  8. Enable the Windows(SMB) Sharing for this directory and then click "Create New Share"
  9. Now, go to the "Groups" tab and make sure you have the people you want in the "staff" group.
  10. Then, under "SMB Properties", set important things.
    1. General Properties: NetBios Name: The name seen in the network directory
    2. Max Connections (Keep this number fairly low....prevent bogging the server down)
    3. WorkGroup: IMPORTANT. Windoze machines have a bitch of a time finding network shares outside their workgroup. Most Windoze boxes come with their workgroup set as "Workgroup". I prefer to set my workgroup to something unique and deal with the Windoze issues as needed.
    4. WINS Server (you can leave blank for small in-house shares)
    5. Server Info String: Something descriptive, like "My home mini server on OS X"
    6. Security Method: USER for user-level access security. Allows more granular control
    7. Code Page: Latin (437) does fine for cross-platform work
    8. Services: Workgroup Master Browser can be left unchecked in small environments, but sometimes helps speed up discovery in larger offices.
    1. Under FILE VISIBLITY TAB, under Veto Files type /.DS_Store/ if it is not already there.
    2. Under FILE VISIBILITY, be sure to check "Hide Files Starting with a Period".
    3. Under HOME DIRECTORIES, I leave it all unchecked....we're just doing a simple share.
  12. Finally, click on the "Update Samba Server Properties" button (be sure to read the IMPORTANT NOTE above). This will write out the settings to your /etc/smb.conf file.
  13. Turn on your share
    1. From the GUI, go to System Preferences and select the Sharing control panel.
    2. Make sure Windows File Sharing is selected (this turns Samba on)
    3. Check your network locale (in a finder window). You should be able to browse to your share.
  14. Enable Users
    1. Under System Preferences, select the Sharing control panel.
    2. Select Windows File Sharing (don't toggle the box, just select it) and click the "Accounts" button
    3. Select the account(s) you'd like to enable and re-enter your password. I agree, this is annoying.

To set up another user account, assign them to a group, set their password and then authorize their access, proceed to 13-b Samba User Setup above.

Back to Table Of Contents

15. CUPS Printing and Printer Sharing

(5/30/2007)

Now, I'm no CUPS printing expert, but I know that it stands for Common UNIX Printing System. CUPS can be used for managing and setting up shared printers, as well as setting up virtual shared printers. While CUPS is possible but may not be worth the hassle to setup. Consider using Bonjour for Windows (Bonjour is standard on the mac), as this makes finding a workgroup printer even easier!!!

Now, to share your printers with Windoze folks. You can always go to the System Preferences and select the Print & Fax control panel. Go to the Sharing sub-panel and select which printers to share. Done.

Alternatively, you can mess around with CUPS to achieve a similar end:

  1. Open your web browser and go to 127.0.0.1:631 (This is your machine, port 631...the CUPS port).
  2. You can click on Do Administration Tasks. Use your machine's admin username and password to get access.
  3. Under the Printers tab, at the bottom, you can Add Printer.
  4. Give it a name, location, description, hit Continue
  5. Select a printer protocol (for instance "Windows Printer via SAMBA")
  6. Enter the URL for the printer, then the make, then the model. You can copy this info from one of your existing printers
    1. NOTE: If you select RAW for the driver, it allows the Windoze blokes to selec their driver of choice.
  7. Back in the Printers, you'll see your new printer among the list. You'll also see the printer in the GUI in the Print & Fax control panel.

To connect from Windoze, you can use the URL http://your.mac.IP:631/printers/nameofprinter (for example: http://192.168.1.1:631/printers/MySharedPrinter). Alternatively, if you have CUPS enabled in SAMBA, users can browse to your network share and click on the shared printer to connect to it.

Nothing too special yet...until we get to the next section...

Back to Table Of Contents

16. Virtual PDF Printer setup (sharing OS X's PDF Printer)

Perhaps one of the coolest things your MacMini server can do for your workgroup is to provide PDF printing capabilities to your poor buddies stuck in the wide wide world of Windoze. Oh, and it can do this for free, which is a whole mess cheaper than buying Acrobat. Given the cost of Acrobat, if 2 Windows users make use of this feature, the MacMini Server will have paid for itself! This turns out to work very well for 95% of files, In fact, the only problems I have had have been printing from Powerpoint on XP with lots of metadata -- the PDFWriter tends to turn some of the images black. Of course, this solution takes a little work, so I would not recommend this for the faint-of-heart.

Before going further, I have to credit this Max OS X Hint. Another alternative that may work for you is to use CodePoetry's solution.

Here's the paint-by-numbers approach for OS 10.4:

  1. Download this slightly modified pdfscript file. Modifications from the original include editing line #82 to fix the permissions of the output file.
  2. Copy the file to /usr/libexec/cups/backend/pdf
  3. Make it executable by everone: sudo chmod a+x /usr/libexec/cups/backend/pdf
  4. Restart the CUPS daemon so that it finds the new backend model: sudo killall -HUP cupsd
  5. Now, configure the virtual printer using the Printer Setup Utility in your /Applications/Utilities/ directory.
    1. Click the 'Add' button
    2. In the 'Printer Browser' window that opens, hold down the <option> key while clicking 'More Printers'
    3. This brings up the 'Advanced' option in the drop down menu at the top.
    4. After you select 'Advanced', you can select 'PDF Writing' from the 'Device:' drop-down menu. (This option comes from the pdf script that you added to /usr/libexec/cups/backend/ in step 2.
    5. For 'Device Name', give it something descriptive but short & sweet. e.g. PDFWriter or VPrinter
    6. For the device URI, use "pdf://tmp". It is a good choice, as it gets cleaned out automatically every time you restart. If you wish to put the output files someplace else, specify it.
    7. Leave the printer model as "Generic". You'll see why later.
    8. Click on "Add" and youa re ready to go.
  6. The script creates a log file (/tmp/pdf.log) each time it prints, which might be helpful for debugging if something goes wrong.
  7. The script checks to see if the output exists, and if it does it creates a new name. This is important, because printing multiple worksheets out of excel caused each worksheet to be seen as a unique print job, and they were overwriting themselves.
  8. Remember, your files will be printed to /tmp and will therefore be lost if you don't copy them to somewhere safe before you restart the system. (/tmp gets cleaned out at system restart).
  9. HINT: In OS X 10.4 (Tiger): Create a SmartFolder (File-> New Smartfolder) on the Desktop (or elsewhere) that searches /tmp for PDFs. Call this folder "PDFWriter_Spool" or something. This makes PDFPrinted files easy to reach. If you locate this folder within your Samba network share, your users can get to it easily, too! Alternatively, see "Changing the PDFWriter Directory" below.

Share your PDF Writer using CUPS:

  1. Go to System Preferences, and under Print & Fax go to the Sharing sub-panel. Select your PDFWriter and enable sharing.
  2. ---OR---
    1. Open the CUPS control panel (127.0.0.1:631) and follow the instructions in the previous section for using the CUPS interface to setup and share a printer.

Add the shared PDF Writer from Windoze:

Mac users skip this step....you already have PDF printing on board natively.

  1. Click on Add Network Printer in your Printing control panel (or simpoly use Bonjour for Windows) (or browse for it on the Samba Share if you have that setup already)
  2. Type the printer address, in this case it will be something like: http://macmini.ip.address:631/printers/PDFWriter
  3. Select the driver maker as GENERIC. Use the MS Publisher Color Printer.
  4. Test print.... go check your output -- wherever you put it.

One small problem and its workaround:

For some reason, i couldn't print PDFs locally from the server once I had completed the above steps. If you see this problem, I found this worked as possible work around:

  1. Add a second printer, call it "localPDF" or something.
  2. The key is to leave the second printer with the "GENERIC" driver and do NOT touch it with the CUPS web interface, since CUPS does not have the "Generic" option. I set the printer to print to pdf://~/Desktop.

Changing the PDF Writer's directory:

  1. Open the CUPS control panel in your web browser (127.0.0.1:631)
  2. Select "Do Administration Tasks" and enter your admin username and password for your machine.
  3. Select on the Printers tab and scroll down to your PDF Writer
  4. Choose "Modify Printer" and click on Continue until you get to the "Device URI" box.
  5. Enter a location that 'makes sense': e.g. PDF://Users/SambaSharedFolder/PDFWriterOutputFolder
  6. Once again, use RAW for the Model/Driver

Go Hog Wild:

One of the other small issues with using the virtual PDF Writer approach is that the users don't have the fine control over things like image compression and whatnot. One thing that I did was add 2 folders within my PDFWriterOutputDirectory. One folder is called "DropHereToCompress" while another is "PickupCompressedPDFs". I then created an Automator folder action that simply runs the "Compress PDF" quartz filter and then moves the compressed file to the pickup folder. As Automator PDF handling capabilities improve (hopefully), you'll be able to provide your users with more and more cool drop-folder actions.

Back to Table Of Contents

17. openVPN Setup on OS X

(7/11/2007)

Also: see openVPN's web page.

Why pay $300-$800 for a VPN endpoint with proprietary restrictions? Why not use an open source based VPN that is fairly easy to configure and runs right on top of your Mac? Even better is that this open sourced software is cross platform and free! In this section, we'll setup the openVPN server with a Public Key Infrastructure (PKI). Most of the instructions are available in the various sources, but here I'll try to provide a paint-by-numbers approach to it all. Using openVPN (as opposed to SSH-ing) to access the samba share (setup earlier) is a great way to enable out-of-office users to access and share files on your central server without mucking permissions up [something that SSH-ing into the share will do].

Don't be dismayed by the length of this section.... I've taken great pains to break it down step-by-step for you to make it a straightforward path (hopefully to success).

17.1 Installing openVPN & some Basics with MacPorts

  1. First, update Darwin Ports (now MacPorts) with sudo port -d selfupdate or grab the latest installable version from MacPorts. Note that since MacPorts is still in transition (early 2007), I am unable to write exact paint-by-numbers instructions here. I did find that once I installedt the latest version from MacPorts, the above command did, in fact, work.
  2. Install openvpn with: sudo port install openvpn2
    1. Alternatively, you can search openvpn versions by using port search openvpn
    2. You can get info with: port info openvpn
    3. You can check what ports you have installed with: port installed
    4. You can check an install directory with a command like: port location openvpn2
    5. You can check if any ports are outdated: port outdated
    6. You can upgrade a port: sudo port upgrade openvpn2
    7. You can upgrade all the installed ports: sudo port upgrade installed
  3. Clean up the install: port clean openvpn2 . Alternatively, to clean it all port clean --all openvpn2
    1. Side note: Sometimes port install download sites don't work. In my case, I had to find the "lzo-2.02.tar.gz" file somewhere else, then cp it into /opt/local/var/db/dports/distfiles/lzo2/. Then I could run sudo port -v -d install lzo2 and ports found the downloaded port and installed it. Then I could finish out the openvpn2 install. This is a useful trick to know sometimes.

17.2 Setting up Public Key Infrastructure (PKI)

Now that you've got OpenVPN installed, it's time to set up the Public Key Infrastructure. This is more secure than passwords, but does involve pushing and pulling files to various places (including your client users).

This assumes the port location is /opt/local/var/dports/software/openvpn2/... but yours may vary slightly (try port location openvpn2).

I basically am following the instructions located at the OpenVPN Quickstart page.

  1. sudo mkdir /etc/openvpn <<easier to access here, also the typical place for mac os X helper app support
  2. sudo cp -r /opt/local/share/doc/openvpn2/easy-rsa /etc/openvpn/ <<move the easy-rsa files
  3. cd /etc/openvpn/easy-rsa <<head to that directory to make command typing shorter in following steps
  4. . ./vars edit the vars (see the opneVPN quickstart for more details).
    1. (set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, KEY_EMAIL)
      (edit KEY_DIR=/etc/openvpn/easy-rsa/keys)
  5. sudo mkdir /etc/openvpn/easy-rsa/keys <<to create your key directory (where you just specified it)
  6. . ./vars <<note the space between the 2 periods, this threw me for a loop>>
  7. sudo ./clean-all
  8. sudo ./build-ca << build the cert authority
    1. COMMON NAME: YourServerName-CA <<set your cert authority's common name, hence the "CA"
  9. ./build-key-server server <<cert/key for your server
    1. COMMON NAME = server
    2. challenge password <blank>
    3. sign the cert? <y>
    4. commit? <y>

17.3 Setting up Client Server Keys

Now that you've got OpenVPN installed, it is time to create the client keys. In this case, we will user the same username strategy that we used for setting SAMBA accounts / email accounts etc. This makes it easier to manage. I also highly recommend keeping a small file listing your actiive account names. For simplicity (and ease of password management), I have chosen not to password protect the user keys. The users will be able to gain access to the VPN without a password, but will still need their password to get on the SAMBA share.

  1. cd /etc/openvpn/easy-rsa
  2. sudo ./build-key username <to password protect, use: ./build-key-pass username
    1. COMMON NAME = same as username (e.g. "flast", "first.last")
    2. no password at this time

17.4 Generate Diffie Hellman Parameters

I have no idea what the DHP's are, but I know you need to do this step.

  1. cd /etc/openvpn/easy-rsa
  2. sudo ./build-dh

17.5 Key Distribution

Your client users will need their client.crt and client.key files as well as the ca.crt file copied onto their user machine. It is important to keep the .key file "secret". I conduct this transfer in person using a USB thumb drive and delete the files on the thumb drive afterwards. More on where to put the keys later.

17.6 Server Configuration Files

Sample config files can be found in: /opt/local/share/doc/openvpn2/sample-config-files . The server.conf file is a good starting point.

  1. sudo cp /etc/openvpn/sample-config-files/server.conf /etc/openvpn/server.conf
  2. sudo edit /etc/openvpn/server.conf
    1. edit the ca, cert, key and dh parameters to point to files from PART 2 -- wherever you chose to locate.
  3. Be sure to save a local copy in your Changed_Files repository.

17.7 Client Configuration Files

This assumes we are using openVPN GUI on any windoze clients and TunnelBlick on any client macs. These 2 apps are both open source and easy to install -- a wonderful thing when you are configuring weird TUN/TAP device extensions.

NOTE: I find it easiest to create a "COMMON" directory for story the ca.crt, all of the .conf or .ovpn files as well as other common install stuff (and reminder setup instructions). I also create a directory for each user that includes their .crt and .key files. I find it happy to have the various versions of the config files ready to go so that I only need to occupy a minimal amount of client computer time during the setup.

  1. copy example client.conf to /etc/openvpn and edit
    1. sudo cp /etc/openvpn/sample-config-files/client.conf /etc/openvpn/client.conf
  2. sudo edit /etc/openvpn/client.conf
    1. be sure: dev tun, proto udp comp-lzo are all set << don't ask me why, this setup just worked
    2. remote (set the IP address of your server). See note below.
      1. openVPN uses port 1194, but you can use some security-thru-obscurity to utilize a different port if you'd like, especially in the case where your firewall can do a pinhole port translation. (e.g. from port 222 to 1194)
    3. for Mac/PC uncomment & edit the appropriate ca, cert, key lines to show the correct location.
      1. On a client mac, you will create a directory and place Mac config files in: ~/Library/openvpn/
        1. Therefore, location examples for a mac would be:
          ca /Users/red/Library/openvpn/ca.crt
          cert /Users/red/Library/openvpn/red.crt
          key /Users/red/Library/openvpn/red.key
      2. You will place PC config files in: C:\Program files\OpenVPN\config\
        1. Because PC's are AFU'd and don't use the right directory slashes, you have to quote the location lines. Therefore, example locations for a PC would look like this:
          ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
          cert "C:\\Program Files\\OpenVPN\\config\\red.crt"
          key "C:\\Program Files\\OpenVPN\\config\\red.key"

NOTE: For testing and training of users, I highly recommend creating an openVPN config that can access the VPN internally. You would be amazed at how this will help you debug random PC firewall issues -- especially since you can do this debugging on site! Setting up an internal client config is the same, except that the Server's IP address will be the local address (typically 192.168.1.xxx).

17.8 Server & Client Firewall Setup

Server:

  1. On your sever, you will need to allow port 1194 through (the openVPN port). You will find firewall settings under System Preferences -> Sharing -> Firewall.

Clients:

  1. The #1 problem that occurs with openVPN is a firewall getting in the way. Typical users have a hard time diagnosing this problem, so I highly recommend testing your setup with an local VPN connection first. Here are some hints for various firewalls.
    1. On macs....this shit just works. Seriously. I have never had a problem with the mac firewall trying to "help" me out.
    2. On PC's it is another story, since the available firewalls typically have terrible controls for fine-tuning program/port access.
      1. ZONEALARM (my favorite firewall), Mcaffee and Norton are fairly easy. You need to set the server's IP address (both the internal/exteral) as a TRUSTED machine. However, I have noticed a tendancy for both McAffee and Norton to "forget" your trusted IPs now and then.
      2. Windoze Firewall simply sucks ass. Turn that crap off and download the free version of ZoneAlarm. The Windoze firewall IMHO is almost completely unconfigurable in any meaningful way. It serves only to get in the way of everything but spyware, viruses, trojan horses and Explorer exploits.

17.9 We're almost there..... Initial Launch of OpenVPN on the Server

  1. sudo /opt/local/sbin/openvpn2 /etc/openvpn/server.conf

Note: At this point I was running into a problem with it being unable to allocate the TUN/TAP interface. Turns out that there was no TUN/TAP device on OS 10.4 Also turns out that *installing* TunnelBlick on the mac server installed the TUN/TAP interface. After launching, then quitting TunnelBlick, I was able to finally startup openvpn2 using the above command. Use Part9B to get past this, otherwise you have to launch TunnelBlick every time you want to run openvpn2 (not such a bad option.)

17.9b, installing TUN/TAP drivers for the server (if your openVPN setup isn't finding them)

  1. downloaded latest Intel binary TUN/TAP driver 20060513 from : http://www-user.rhrk.uni-kl.de/~nissler/tuntap/
  2. saved a copy of tuntap driver in the !ServerSetup folder
  3. INSTALLED TUN/TAP driver and restarted
  4. NOW.......the launchctl (from Part 13 below) works on startup

17.10 Setting up SAMBA for use with openVPN using dev tun (routing)

So, now that you have the server running openVPN on startup and you have a client configured, how would you access our SAMBA share?

  1. sudo edit /etc/smb.conf so to ADD 10.8.0.0/24 to hosts allow (or whatever the VPN subnet is, 10.8.0.0 is standard). I have found that this step may or may not be necessary.....
  2. On PC's connect to the openVPN client and browse the network neighborhood, or use direct address: \\10.8.0.1\\sharename
  3. On Macs in the finder select GO->Connect To Server and cifs://10.8.0.1/

17.11 Revoking a Client Key

Got a problem with a user, or need to shut their access down, here's how.

  1. cd /etc/openvpn/easy-rsa
  2. . ./vars (note periods have space between them)
  3. sudo ./revoke-full clientname <<you'll see "error 23" and that's what you want>>
  4. This creates a "crl.pem" file.
  5. sudo edit /etc/openvpn/server.conf
    1. enable the use of the .pem file ..... add/uncomment: crl-verify /etc/openvpn/crl.pem

17.12 Setup openVPN maagment interface

You can also manage openVPN with a managment interface. I rarely use this, but I could imagine it being helpful in a dynamic environment.

  1. Add to the /etc/openvpn/server.conf file management localhost xxxx (where xxxx is a port number of your choosing)
  2. TO USE: ssh adminusername@64.174.37.102
  3. once logged in> telnet localhost xxxx
  4. log 20 (shows last 20 items in log)....etc

17.13 Setting openVPN to Launch on Server Startup

You want yoru server to come up ready to go....including your VPN connection.

  1. Create a LaunchDaemon plist using LaunchdEditor to launch openvpn at startup. I called mine openvpn2.plist
  2. saved plist in /library/launchdaemons/ <<backup in Changed_Files folder>>
  3. Verify that the .plist is chown'd and chgrp'd to root/wheel This makes sure the launched process runs at right permissions.
  4. Use "launchctl" (see launchctl or launchd man page) to load into launchd and then start my daemon
    1. sudo launchctl load -w /Library/LaunchDaemons/openvpn2.plist
    2. sudo launchctl list
  5. restart to verify that the launch daemon is loading the "openvpn2" process on startup

openVPN SETUP SUMMARY

OpenVPN is definitely worth the time to setup. Once you have openVPN ready to go, you'll be able to do all sorts of remote managment and access from home and still be able to sleep at night. While there are a lot of steps, I have found openVPN to be incredibly stable once running. In fact, I have not had to touch my server setup or configuration in any way, and that was a year (and numerous OS updates) ago! This is definitely an industrial strength solution.

Back to Table Of Contents

18. Remote Desktop Setup

(8/8/2007)

Chicken of the VNC and Apple Remote Desktop combine to give you headlless server control. What's more, when done over openVPN you get that added level of security of not exposing the Remote Desktop port to the world. Sure, it's a little on the slow side, but once you have your server setup, you'll find that you access the GUI less often than you'd imagine!

NOTE: The following instructions assume that you have openVPN setup and working through your obscurified port of choice.

  1. Open the server's firewall on the (obscurified) SSH port as well as the Remote Desktop Ports (3283, 5900) . In my case, I opened these ports only to the internal network, not to the internet. We'll use the VPN to get to the internal network so that we can see those ports.
  2. Download Chicken of the VNC onto your client.
  3. On the server:
    1. Under Syste Preferences -> Sharing enable "Apple Remote Desktop". This will bring up Access Priveledges
    2. Under Access Priveledges, select "VNC Viewers May ControL Screen" and enter a nice good password.
    3. NOTE: I found that in order for this to work over the obscurified SSH port, I had to select one of the users and then select all of the checkboxes to give them control. Once I did this, everything seemed to work in the next step.
  4. While on your local network, open COTVNC and enter the server's address (192.168.1.xxx) and password.
    1. Over a VPN connection, remember the server's VPN IP address will be something like (10.8.0.1).
    2. IF THIS WORKS, skip step #5. You are rocking!!!
  5. OPTIONAL POSSIBILITY: If for some reason you are stuck, there may be a fingerprinting/trust issue. NOTE: This order of events DID NOT work for me.
    1. Open Terminal and SSH into your server using your username where "XXXX" is our obscurifed SSH port number. Use the following command:
      sudo ssh -p XXXX -L 22:127.0.0.1:XXXX -L 5900:127.0.0.1:5900 username@192.168.1.xxx
    2. This command attempts to bind our SSH port "XXXX" to port 5900 (the Remote Desktop port) for "username" on our local intranet with server IP 192.168.1.xxx
    3. The first time you do this, you should get a fingerprint to approve
    4. Enter a password to complete the ssh
    5. Fire up your COTVNC and create a new connection, but enter "localhost" as the host.

Back to Table Of Contents

19. Backups: Local

(9/17/2007)

After all this work, it would be a terrible thing if something happened and you lost your server setup (and data). One of the greatest things about the Mac OS is its ability to boot off of an external firewire or USB drive (take that Windoze). There are several great apps out there with the capability of making a bootable clone of your server. While everybody has their own strategy, the backup strategy below will do the following:

  1. Nighly snapshots of your shared SAMBA directory. These are rolling weekly, so that last Wednesday's snapshot gets overwritten by this Wednesday's snapshot.
  2. Weekly snapshots of the shared SAMBA directory. These do not roll, as they are dated. Obviously, you could fill up your hard drive if you kept all of them. I choose to manually filter through and keep weekly snapshots around for about one month.
  3. I save one weekly snapshot every month and put it into a special "monthly" folder. This could be automated, but it's trivial to manage this manually every now and then.
  4. Monthly clones of the entire drive. Since I don't make that many alterations to the server setup, this is adequate for disaster recovery. Should I have a week with numerous changes, I can always force the clone. Remember: It is a good idea to verify your clone by booting off of it now and hten. Don't wait for disaster to strike to discover that you don't have a bootable backup.
  5. NEXT SECTION: Weekly offsite backups. What if disaster struck your location? Would you lose all your data and onsite backups? Well, I'm too lazy to swap out drives, etc.... so I use rsync over SSH to perform weekly snapshots of the drive to a trusted offsite server.

19.1 Nightly snapshots

You can start with this 450.dailyDOCSexample file as a template. Open the downloaded file in TextEdit or TextWrangler (I prefer the latter, with line numbering ON). Nominally, you would place your customized copy of this file under /etc/periodic/daily/ and then sudo chmod +x yourfilename to make the file executable -- this will enable the script to run with your daily cron jobs. Here is some basic explanation:

  • You may or may not need line 8, depending on how your local paths are setup.
  • Lines 10, 11, 12 are for reporting to your log scanners or to your screen. Edit these as you see fit. The date +%a command is a simple command for outputting short day of the week. Want more options (and there are a lot), try "man date".
  • Line 14 contains any modifiers you may wish to add to or not. These become part of the rsync command later.
  • Lines 17-20 simply did NOT work for me. The idea is to speed up the process by turning Spotlight off so that it does NOT index as you run the rsync. This messed all sorts of stuff up, so I commented it out along with lines #25 and #28
  • Line 26: Since I am going to use an external drive for my snapshots, I figured I should test for the existance of the drive first. This line checks to see that the drive/directory is in fact available and if it is not it spits out a message and halts the scrript.
  • Line 27 is where the heart of the matter is. We are using rsync (man rsync for more) to do the heavy lifting. I have chosen several flags, based on the examples in the rsync man pages, that seem to do the trick for a nightly snapshot. We're working in archive mode with extended attributes and we're deleting files not present on the source. The source is /Users/DOCS/ an the destination is /Users/Backups/`date +%u`_`date +%a`_DOCSbackup Basically, we're taking the contents of the DOCS folder and copying it into a folder titled something like 3_Wed_DOCSbackup. This helps us visually sort out our snapshots...
  • Lines 36 - 38 are for humans to feel warm and fuzzy.

19.2 Weekly snapshots

Take a look at 450.weeklyDOCSexample.txt by opening it in your favorite text editor. Nominally, you would place your customized copy of this file under /etc/periodic/weekly/ and then sudo chmod +x yourfilename to make the file executable -- this will enable the script to run with your weekly cron jobs. Here is some basic explanation:

  • Line 8 might need editing depending on how your local paths are setup.
  • Lines 10-12 are for human warm and fuzzies.
  • Line 14 contains modifiers for the later rsync command.
  • Once again, Lines 16... simply did not work for me. The idea being to turn off Spotlight before using rsysc.... too bad.
  • Line 26 tests for the existence of our external hard drive where we are storing the snapshots. You could also store your snapshots on your internal drive (until you run out of room, that is).
  • Line 27 is the meat & potatoes. We're taking our /Users/DOCS/ files and putting them inside .../WEEKLY_BACKUPS/DOCSweekly_`date +%Y%m%d
    • Don't be afraid of that last bit. Open up your terminal and type man date Or better yet, open up Terminal and type date +%Y%m%d
  • To finish out, lines 36, 37 , 38 give us the warm and fuzzies.

19.3 Monthly Bootable Clones

There are several ways to achieve the our goal with this one. On this particular server, I am utilizing Carbon Copy Cloner to do the work. The great thing about CCC is that once you have setup your preferences for your cloning operation, you can simply hit the "Scheduler" button and determine when you want this automated backup to run. Every month, CCC creates a fully bootable clone of my system drive. Just to be sure, I regularly shutdown and boot off of the clone to verify that all is well. NOTE: If you run into problems with CCC, be sure to check out their FAQ pages. More often than not, starting out wtih a freshly partitioned clone drive seems to do the trick.

Back to Table Of Contents

20. Weekly Offsite Backups

(10/3/2007)

Our goal here is to backup our server to a remote location using ssh and rsync. This will go a long way towards saving our data should there be a catastrophe at the server's location. For this example, our MacMini Server is the local machine and our offsite backup server is our remote machine. Furthermore, for this example let us assume that our offsite remote server is a similarily setup MacMini (althout it really could be just about anything). There are lots of resources out there to help you navigate through this part. For instance, M. Bombich (creator of Carbon Copy Cloner) has a page here. His page is top notch and I pilfer from it, yet for the sake of completeness I'm going to distill it down for you here as I do a few things slightly different.

Part 1: Setting up our Public/Private key ssh log in capability

Phase 1: Create your public/private key pair on your client/local machine

  1. On your local (client) machine generate your public and private keys. We're going to use RSA version 2 keys with defaults all around.
    sudo ssh-keygen -t rsa -C "optional comment"
  2. If prompted for a password to protect the key, just hit return, since we don't want our script having to enter a password.
  3. This will create a private key ( ~/.ssh/id_rsa) and public key (~/.ssh/id_rsa.pub )

Phase 2: Setup authorized keys on your remote machine

  1. On your remote machine, we'll need to tell it which clients are in fact authorized. To do this, you need to make a copy of the public key and append it to ~/.ssh/authorized_keys
  2. While I find it easier to sneaker-net the public key over to the remote machine and copy/paste the line in using a GUI tool like TextWrangler, you could also try Bombich's approach. Either way, make sure each key occupies only 1 single line in the file. If you are situated at the remote machine, try:
    sudo cat /PATH/TO/id_rsa.pub >> ~/.ssh/authorized_keys

Phase 3: Modify ssh settings on the local machine

To make things work more smoothly, we have to make some configuration mods to both the local/client and remote/host machines. While you can store some local user settings under ~/.ssh/config I prefer to keep it all in one place under /etc/ssh_config.

  1. On your local MacMini Server: sudo edit /etc/ssh_config
  2. Add a line PubkeyAuthentication yes to enable our public/private RSA version 2 authentication scheme.
  3. Uncomment/edit to set GSSAPIKeyExchange no and GSSAPIAuthentication no and GSSAPIDelegateCredentials no . I was finding that these were causing hangups and errors in 10.4.10.
  4. Be sure to save a copy of this file in your Changed_Files directory.

Phase 4: Modify sshd settings on the remote machine

To make things work more smoothly, we will need to make some modifications to our sshd and ssh configurations. We've already done some basic modification in the SSH section above (if you have not, you should go through that section before continuing). Regardless, we have a few more to do with sudo edit /etc/sshd_config

  2. Be sure you are happy with your Port number (we set it to 1111 in the SSH example) and the AllowUsers call.
  3. Uncomment PubkeyAuthentication yes
  4. Set: GSSAPIKeyExchange no and GSSAPIAuthentication no and GSSAPICleanupCredentials no . I was finding that these were causing hangups and errors in 10.4.10.
  5. Be sure to save a copy of this file in your Changed_Files directory.

Phase 5: Verify and Test

  1. Time to Verify and Test. On your local machine (fixing the obvious values): ssh -v -p 1234 username@111.111.111.111
    1. The -v puts ssh into "verbose" mode so we can diagnose what is going wrong -- and a LOT can go wrong. The good news is you can follow the logic as ssh tries to connect. If you read the output closely, you can usually figure out whether or not something is in the correct place, or a setting is incorrect. This is how I discovered teh "GSSAPI" issues that ssh was having under 10.4.10
    2. The -p (like we learned earlier) sets the port to our obscurified ssh port.
  2. Did it work? You'll know your public/private key worked because you won't have to enter a password!!! If it failed, double check that you have the public key in the authorized_keys file (correctly) and that your local key is in ~/.ssh/ . It is easy to mess up the order of events, and having done so myself -- the best thing is to go through them from scratch again.

Part 2: Setting up our Remote Backup Script
Now, assuming you got your ssh call to work out for you, you now have a secure way to log into a remote machine without requiring a user to sit at the keyboard and enter a password. This next part is easy.

  1. Take a look at 455.weeklyOffsiteDOCSexamp.txt
    1. Like the other backup scripts, this one utilizes rsync and is actually very very basic.
    2. Lines 10, 11, 12 and 25, 26, 27 are for the warm and fuzzies and the log files.
    3. Line 14 sets what to exclude in the transfer.
    4. Line 23 does the heavy lifting
      rsync -e "ssh -v -p 1234" -avEz --delete $EXCLUDES /Users/DOCS/ username@www.myservernameorIP.org:/Volumes/SKRATCH/DIR/DOCS_bak
      1. The -e flag tells rsync to issue a shell command. In our case, that shell command sets up our ssh tunnel (you'll recognize it from earlier. We're leaving it verbose for now, but it need not be).
      2. -avEz sets up archive , verbose , extended-attributes , compression. The extended-attributes is useful for us Mac folks and the rest should be pretty obvious.
      3. --delete tells the receiver to delete any files not on the sending side.
      4. $EXCLUDES is a variable of files not to transfer.
      5. /Users/DOCS/ is our source location
      6. username@www.myservernameorIP.org: is that remote ssh server we just setup.
      7. /Volumes/SKRATCH/DIR/DOCS_bak is the location on the remote server we'd like to put everything into.
  2. Edit the script to your needs and locate in /etc/periodic/weekly . Be sure to chmod the thing to make it executable.
  3. Test the script
    1. Make one minor edit first, add -n to the rsync call to make it a dry-run. Otherwise, you could be sitting there for a long time as rsync does its job.
    2. sudo /etc/periodic/weekly/455.weeklyOffsiteDOCS (or whatever you called it) to execute the script. Debug at your leisure.
  4. Finalize: When you're ready, remove that -n (dry-run) call and be sure to save your file in your Changed_Files directory. Oh, and if you want to force it, you could sudo periodic weekly

Congratulations!!! Offsite backups rock. Pay attention to them and verify that they are doing their thing. If you have fast bandwidth and whatnot, you could even extend the above script to make nightly rolling offsite backups, or backup to multiple servers. Knock yourself out.

Back to Table Of Contents

 
 
 

© March 3, 2008
www.redstoyland.com