Mac OSX Hosting!

Network Monitoring – Automated Reboot System

netman714 — Thu, 06 May 2010 19:50:30 +0000

Bring State of the Art Network Monitoring in house – save money, offer more network monitoring options and stay ahead of your servers.

Monitor the services you need to monitor – use login’s to verify connectivity to your network services. Any network service can be checked at any interval – from every 10 seconds to every 15 minutes – whatever frequency makes you feel the most comfortable. Other network monitoring systems are based on a per unit pricing scheme – using our solution, you can monitor as many devices as you need to monitor – and you can monitor any service that is available over the network.

From SNMP to SMTP, MySQL monitoring and web site up-time, you can bring your network monitoring solution in-house – at an affordable price and with a number of options available.

Automated Reboot Systems

It’s not enough to simply monitor your servers and services – what do you do in case of a server outage, a remote site’s connection down or any of the other services you have to monitor?

Being able to control the power outlets of your servers and and network devices allows the network admin to toggle a machine off and on – resolving over 98% of server service outages.

The PowerKey Pro 600 has 6 software controlled outlets – allowing you to reboot up to 6 devices at any time. Imagine having your webserver stuck at 3 am – rather than driving to the office or data center, login to the network monitoring system from your home or office and toggle the outlet remotely.

With our network monitoring tools and automatic reboot system, you can notify the on-call technician, reboot your server and be notified the services are back on-line faster than you get your pants on and into your car.

For more info, http://edition.net/Network-Monitoring-Automated-Reboot-System

Protection for sensitive files when using Apache on an HFS+ volume

montanaflynn — Thu, 06 Mar 2008 00:28:23 +0000

Security Update 2004-12-02 makes changes to the httpd.conf file. After a successful update, the Apache configuration file will deny access to the following files:

*/..namedfork/data
*/..namedfork/rsrc
*/rsrc
rsrc
.ht* (case insensitive)
.ds_s* (case insensitive)

Warnings:

The configuration changes that block named-fork exposure apply only to the default webserver, apache1. If you’ve chosen to use Apache2, it’s recommended that you serve content from a UFS volume.
For important related information, see “mod_hfs_apple” protects web content against case insensitivity in the HFS file system.

Blocking these files improves security, but it may impact applications that either provide resource fork content via a web server (no Apple applications do) or store files called “rsrc”.

If clients attempt to access blocked files, the Apache error log will create a record. By default, Apache writes log files into /private/var/log/httpd. Here’s what this example would look like:

[Tue Nov 16 13:15:26 2004] [error] [client 1.2.3.4] client denied by server configuration: /Library/WebServer/Documents/rsrc

In some circumstances, the Security Update may not install successfully if the Web Server configuration file has been manually edited or has been updated by installing certain third-party software.

If the Security Update can’t successfully modify the Web Server configuration file, this entry will appear in system install log (/var/log/install.log):

## WARNING ###########################################################
The Security Update was unable to safely apply a patch to your Apache
config file, /etc/httpd/httpd.conf. It has been left undisturbed.

Please look at /etc/httpd/httpd.conf.default and consider merging the
new Files 'rsrc' and DirectoryMatch '..namedfork' directives from that
file into /etc/httpd/httpd.conf.

######################################################################

If this occurs, we highly recommend that you edit your /etc/httpd/httpd.conf file manually, as follows.

An unpatched configuration file will contain one of the following three alternative sections:


    Order allow,deny
    Deny from all
    Satisfy All


    Order allow,deny
    Deny from all
    Satisfy All


    Order allow,deny
    Deny from all
    Satisfy All

Whichever section appears, replace it with all of the following:


    Order allow,deny
    Deny from all
    Satisfy All



    Order allow,deny
    Deny from all
    Satisfy All



    Order allow,deny
    Deny from all
    Satisfy All

Additional information

Security Update 2004-12-02 may update Mac OS X client with a copy of the Apache default configuration file (httpd.conf.default) that is intended for Mac OS X Server. The default file is provided in Mac OS X client only as a reference in the event that user-made changes to the active configuration file result in a need to revert back to a known-good default copy. You can restore a Mac OS X client httpd.conf.default file to the correct state by opening it in a text editor and replacing its contents with the copy found below. The copy below is only for Mac OS X 10.2.8 or 10.3.6 with Security Update 2004-12-02 installed.

Begin copying below this line.

##
## httpd.conf -- Apache HTTP server configuration file
##

#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file. It contains the
# configuration directives that give the server its instructions.
# See for detailed information about
# the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# After this file is processed, the server will look for and process
# /private/etc/httpd/srm.conf and then /private/etc/httpd/access.conf
# unless you have overridden these with ResourceConfig and/or
# AccessConfig directives here.
#
# The configuration directives are grouped into three basic sections:
# 1. Directives that control the operation of the Apache server process as a
# whole (the 'global environment').
# 2. Directives that define the parameters of the 'main' or 'default' server,
# which responds to requests that aren't handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
# 3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path. If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/foo.log"
# with ServerRoot set to "/usr/local/apache" will be interpreted by the
# server as "/usr/local/apache/logs/foo.log".
#

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#

#
# ServerType is either inetd, or standalone. Inetd mode is only supported on
# Unix platforms.
#
ServerType standalone

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE! If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation
# (available at );
# you will save yourself a lot of trouble.
#
ServerRoot "/usr"

#
# The LockFile directive sets the path to the lockfile used when Apache
# is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or
# USE_FLOCK_SERIALIZED_ACCEPT. This directive should normally be left at
# its default value. The main reason for changing it is if the logs
# directory is NFS mounted, since the lockfile MUST BE STORED ON A LOCAL
# DISK. The PID of the main server process is automatically appended to
# the filename.
#
#LockFile "/private/var/run/httpd.lock"

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
#
PidFile "/private/var/run/httpd.pid"

#
# ScoreBoardFile: File used to store internal server process information.
# Not all architectures require this. But if yours does (you'll know because
# this file will be created when you run Apache) then you *must* ensure that
# no two invocations of Apache share the same scoreboard file.
#
ScoreBoardFile "/private/var/run/httpd.scoreboard"

#
# In the standard configuration, the server will process httpd.conf (this
# file, specified by the -f command line option), srm.conf, and access.conf
# in that order. The latter two files are now distributed empty, as it is
# recommended that all directives be kept in a single file for simplicity.
# The commented-out values below are the built-in defaults. You can have the
# server ignore these files altogether by using "/dev/null" (for Unix) or
# "nul" (for Win32) for the arguments to the directives.
#
#ResourceConfig /private/etc/httpd/srm.conf
#AccessConfig /private/etc/httpd/access.conf

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 15

#
# Server-pool size regulation. Rather than making you guess how many
# server processes you need, Apache dynamically adapts to the load it
# sees --- that is, it tries to maintain enough server processes to
# handle the current load, plus a few spare servers to handle transient
# load spikes (e.g., multiple simultaneous requests from a single
# Netscape browser).
#
# It does this by periodically checking how many servers are waiting
# for a request. If there are fewer than MinSpareServers, it creates
# a new spare. If there are more than MaxSpareServers, some of the
# spares die off. The default values are probably OK for most sites.
#
MinSpareServers 1
MaxSpareServers 5

#
# Number of servers to start initially --- should be a reasonable ballpark
# figure.
#
StartServers 1

#
# Limit on total number of servers running, i.e., limit on the number
# of clients who can simultaneously connect --- if this limit is ever
# reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW.
# It is intended mainly as a brake to keep a runaway server from taking
# the system with it as it spirals down...
#
MaxClients 150

#
# MaxRequestsPerChild: the number of requests each child process is
# allowed to process before the child dies. The child will exit so
# as to avoid problems after prolonged use when Apache (and maybe the
# libraries it uses) leak memory or other resources. On most systems, this
# isn't really needed, but a few (such as Solaris) do have notable leaks
# in the libraries. For these platforms, set to something like 10000
# or so; a setting of 0 means unlimited.
#
# NOTE: This value does not include keepalive requests after the initial
# request per connection. For example, if a child process handles
# an initial request and 10 subsequent "keptalive" requests, it
# would only count as 1 request towards this limit.
#
MaxRequestsPerChild 100000

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the
# directive.
#
#Listen 3000
#Listen 12.34.56.78:80

#
# BindAddress: You can support virtual hosts with this option. This directive
# is used to tell the server which IP address to listen to. It can either
# contain "*", an IP address, or a fully qualified Internet domain name.
# See also the and Listen directives.
#
#BindAddress *

#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Please read the file http://httpd.apache.org/docs/dso.html for more
# details about the DSO mechanism and run `httpd -l' for the list of already
# built-in (statically linked and thus always available) modules in your httpd
# binary.
#
# Note: The order in which modules are loaded is important. Don't change
# the order below without expert advice.
#
# Example:
# LoadModule foo_module libexec/mod_foo.so
#LoadModule vhost_alias_module libexec/httpd/mod_vhost_alias.so
#LoadModule env_module libexec/httpd/mod_env.so
LoadModule config_log_module libexec/httpd/mod_log_config.so
#LoadModule mime_magic_module libexec/httpd/mod_mime_magic.so
LoadModule mime_module libexec/httpd/mod_mime.so
LoadModule negotiation_module libexec/httpd/mod_negotiation.so
#LoadModule status_module libexec/httpd/mod_status.so
#LoadModule info_module libexec/httpd/mod_info.so
LoadModule includes_module libexec/httpd/mod_include.so
LoadModule autoindex_module libexec/httpd/mod_autoindex.so
LoadModule dir_module libexec/httpd/mod_dir.so
LoadModule cgi_module libexec/httpd/mod_cgi.so
LoadModule asis_module libexec/httpd/mod_asis.so
LoadModule imap_module libexec/httpd/mod_imap.so
LoadModule action_module libexec/httpd/mod_actions.so
#LoadModule speling_module libexec/httpd/mod_speling.so
LoadModule userdir_module libexec/httpd/mod_userdir.so
LoadModule alias_module libexec/httpd/mod_alias.so
LoadModule rewrite_module libexec/httpd/mod_rewrite.so
LoadModule access_module libexec/httpd/mod_access.so
LoadModule auth_module libexec/httpd/mod_auth.so
#LoadModule anon_auth_module libexec/httpd/mod_auth_anon.so
#LoadModule dbm_auth_module libexec/httpd/mod_auth_dbm.so
#LoadModule digest_module libexec/httpd/mod_digest.so
#LoadModule proxy_module libexec/httpd/libproxy.so
#LoadModule cern_meta_module libexec/httpd/mod_cern_meta.so
#LoadModule expires_module libexec/httpd/mod_expires.so
#LoadModule headers_module libexec/httpd/mod_headers.so
#LoadModule usertrack_module libexec/httpd/mod_usertrack.so
LoadModule log_forensic_module libexec/httpd/mod_log_forensic.so
#LoadModule unique_id_module libexec/httpd/mod_unique_id.so
LoadModule setenvif_module libexec/httpd/mod_setenvif.so
#LoadModule dav_module libexec/httpd/libdav.so
#LoadModule ssl_module libexec/httpd/libssl.so
#LoadModule perl_module libexec/httpd/libperl.so
#LoadModule php4_module libexec/httpd/libphp4.so
LoadModule hfs_apple_module libexec/httpd/mod_hfs_apple.so
LoadModule rendezvous_apple_module libexec/httpd/mod_rendezvous_apple.so

# Reconstruction of the complete module list from all available modules
# (static and shared ones) to achieve correct module execution order.
# [WHENEVER YOU CHANGE THE LOADMODULE SECTION ABOVE UPDATE THIS, TOO]
ClearModuleList
#AddModule mod_vhost_alias.c
#AddModule mod_env.c
AddModule mod_log_config.c
#AddModule mod_mime_magic.c
AddModule mod_mime.c
AddModule mod_negotiation.c
#AddModule mod_status.c
#AddModule mod_info.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
#AddModule mod_speling.c
AddModule mod_userdir.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
#AddModule mod_auth_anon.c
#AddModule mod_auth_dbm.c
#AddModule mod_digest.c
#AddModule mod_proxy.c
#AddModule mod_cern_meta.c
#AddModule mod_expires.c
#AddModule mod_headers.c
#AddModule mod_usertrack.c
AddModule mod_log_forensic.c
#AddModule mod_unique_id.c
AddModule mod_so.c
AddModule mod_setenvif.c
#AddModule mod_dav.c
#AddModule mod_ssl.c
#AddModule mod_perl.c
#AddModule mod_php4.c
AddModule mod_hfs_apple.c
AddModule mod_rendezvous_apple.c

#
# ExtendedStatus controls whether Apache will generate "full" status
# information (ExtendedStatus On) or just basic information (ExtendedStatus
# Off) when the "server-status" handler is called. The default is Off.
#
#ExtendedStatus On

### Section 2: 'Main' server configuration
#
# The directives in this section set up the values used by the 'main'
# server, which responds to any requests that aren't handled by a
# definition. These values also provide defaults for
# any containers you may define later in the file.
#
# All of these directives may appear inside containers,
# in which case these default settings will be overridden for the
# virtual host being defined.
#

#
# If your ServerType directive (set earlier in the 'Global Environment'
# section) is set to "inetd", the next few directives don't have any
# effect since their settings are defined by the inetd configuration.
# Skip ahead to the ServerAdmin directive.
#

#
# Port: The port to which the standalone server listens. For
# ports < 1023, you will need httpd to be run as root initially.
#
Port 80

#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don't use Group "#-1" on these systems!
#
User www
Group www

#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed. This address appears on some server-generated pages, such
# as error documents.
#
#ServerAdmin webmaster@example.com

#
# ServerName allows you to set a host name which is sent back to clients for
# your server if it's different than the one the program would get (i.e., use
# "www" instead of the host's real name).
#
# Note: You cannot just invent host names and hope they work. The name you
# define here must be a valid DNS name for your host. If you don't understand
# this, ask your network administrator.
# If your host doesn't have a registered DNS name, enter its IP address here.
# You will have to access it by its address (e.g., http://123.45.67.89/)
# anyway, and this will make redirections work in a sensible way.
#
# 127.0.0.1 is the TCP/IP local loop-back address, often named localhost. Your
# machine always knows itself by this address. If you use Apache strictly for
# local testing and development, you may use 127.0.0.1 as the server name.
#
#ServerName homeslice.apple.com

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/Library/WebServer/Documents"

#
# Each directory to which Apache has access, can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# permissions.
#

Options FollowSymLinks
AllowOverride None

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

#
# This should be changed to whatever you set DocumentRoot to.
#

#
# This may also be "None", "All", or any combination of "Indexes",
# "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
Options Indexes FollowSymLinks MultiViews

#
# This controls which options the .htaccess files in directories can
# override. Can also be "All", or any combination of "Options", "FileInfo",
# "AuthConfig", and "Limit"
#
AllowOverride None

#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all

#
# UserDir: The name of the directory which is appended onto a user's home
# directory if a ~user request is received.
#

UserDir Sites

#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
#
# AllowOverride FileInfo AuthConfig Limit
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
#
# Order allow,deny
# Allow from all
#
#
# Order deny,allow
# Deny from all
#
#

#
# DirectoryIndex: Name of the file or files to use as a pre-written HTML
# directory index. Separate multiple entries with spaces.
#

DirectoryIndex index.html

#
# AccessFileName: The name of the file to look for in each directory
# for access control information.
#
AccessFileName .htaccess

#
# The following lines prevent .htaccess files from being viewed by
# Web clients. Since .htaccess files often contain authorization
# information, access is disallowed for security reasons. Comment
# these lines out if you want Web visitors to see the contents of
# .htaccess files. If you change the AccessFileName directive above,
# be sure to make the corresponding changes here.
#
# Also, folks tend to use names such as .htpasswd for password
# files, so this will protect those as well.
#

Order allow,deny
Deny from all
Satisfy All

#
# Apple specific filesystem protection.
#

Order allow,deny
Deny from all
Satisfy All

#
# CacheNegotiatedDocs: By default, Apache sends "Pragma: no-cache" with each
# document that was negotiated on the basis of content. This asks proxy
# servers not to cache the document. Uncommenting the following line disables
# this behavior, and proxies will be allowed to cache the documents.
#
#CacheNegotiatedDocs

#
# UseCanonicalName: (new for 1.3) With this setting turned on, whenever
# Apache needs to construct a self-referencing URL (a URL that refers back
# to the server the response is coming from) it will use ServerName and
# Port to form a "canonical" name. With this setting off, Apache will
# use the hostname:port that the client supplied, when possible. This
# also affects SERVER_NAME and SERVER_PORT in CGI scripts.
#
UseCanonicalName On

#
# TypesConfig describes where the mime.types file (or equivalent) is
# to be found.
#

TypesConfig /private/etc/httpd/mime.types

#
# DefaultType is the default MIME type the server will use for a document
# if it cannot otherwise determine one, such as from filename extensions.
# If your server contains mostly text or HTML documents, "text/plain" is
# a good value. If most of your content is binary, such as applications
# or images, you may want to use "application/octet-stream" instead to
# keep browsers from trying to display binary files as though they are
# text.
#
DefaultType text/plain

#
# The mod_mime_magic module allows the server to use various hints from the
# contents of the file itself to determine its type. The MIMEMagicFile
# directive tells the module where the hint definitions are located.
# mod_mime_magic is not part of the default server (you have to add
# it yourself with a LoadModule [see the DSO paragraph in the 'Global
# Environment' section], or recompile the server and include mod_mime_magic
# as part of the configuration), so it's enclosed in an container.
# This means that the MIMEMagicFile directive will only be processed if the
# module is part of the server.
#

MIMEMagicFile /private/etc/httpd/magic

#
# HostnameLookups: Log the names of clients or just their IP addresses
# e.g., www.apache.org (on) or 204.62.129.132 (off).
# The default is off because it'd be overall better for the net if people
# had to knowingly turn this feature on, since enabling it means that
# each client request will result in AT LEAST one lookup request to the
# nameserver.
#
HostnameLookups Off

#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a
# container, error messages relating to that virtual host will be
# logged here. If you *do* define an error logfile for a
# container, that host's errors will be logged there and not here.
#
ErrorLog "/private/var/log/httpd/error_log"

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t <"%r<" %>s %b <"%{Referer}i<" <"%{User-Agent}i<"" combined
LogFormat "%h %l %u %t <"%r<" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a
# container, they will be logged here. Contrariwise, if you *do*
# define per- access logfiles, transactions will be
# logged therein and *not* in this file.
#
CustomLog "/private/var/log/httpd/access_log" common

#
# If you would like to have agent and referer logfiles, uncomment the
# following directives.
#
#CustomLog "/private/var/log/httpd/referer_log" referer
#CustomLog "/private/var/log/httpd/agent_log" agent

#
# If you prefer a single logfile with access, agent, and referer information
# (Combined Logfile Format) you can use the following directive.
#
#CustomLog "/private/var/log/httpd/access_log" combined

#
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (error documents, FTP directory listings,
# mod_status and mod_info output etc., but not CGI generated documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
#
ServerSignature On

# EBCDIC configuration:
# (only for mainframes using the EBCDIC codeset, currently one of:
# Fujitsu-Siemens' BS2000/OSD, IBM's OS/390 and IBM's TPF)!!
# The following default configuration assumes that "text files"
# are stored in EBCDIC (so that you can operate on them using the
# normal POSIX tools like grep and sort) while "binary files" are
# stored with identical octets as on an ASCII machine.
#
# The directives are evaluated in configuration file order, with
# the EBCDICConvert directives applied before EBCDICConvertByType.
#
# If you want to have ASCII HTML documents and EBCDIC HTML documents
# at the same time, you can use the file extension to force
# conversion off for the ASCII documents:
# > AddType text/html .ahtml
# > EBCDICConvert Off=InOut .ahtml
#
# EBCDICConvertByType On=InOut text/* message/* multipart/*
# EBCDICConvertByType On=In application/x-www-form-urlencoded
# EBCDICConvertByType On=InOut application/postscript model/vrml
# EBCDICConvertByType Off=InOut */*

#
# Aliases: Add here as many aliases as you need (with no limit). The format is
# Alias fakename realname
#

#
# Note that if you include a trailing / on fakename then the server will
# require it to be present in the URL. So "/icons" isn't aliased in this
# example, only "/icons/". If the fakename is slash-terminated, then the
# realname must also be slash terminated, and if the fakename omits the
# trailing slash, the realname must also omit it.
#
Alias /icons/ "/usr/share/httpd/icons/"

Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all

# This Alias will project the on-line documentation tree under /manual/
# even if you change the DocumentRoot. Comment it if you don't want to
# provide access to the on-line documentation.
#
Alias /manual/ "/Library/WebServer/Documents/manual/"

Options Indexes FollowSymlinks MultiViews
AllowOverride None
Order allow,deny
Allow from all

#
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
ScriptAlias /cgi-bin/ "/Library/WebServer/CGI-Executables/"

#
# "/Library/WebServer/CGI-Executables" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#

AllowOverride None
Options None
Order allow,deny
Allow from all

# End of aliases.

#
# Redirect allows you to tell clients about documents which used to exist in
# your server's namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
# Format: Redirect old-URI new-URL
#

#
# Directives controlling the display of server-generated directory listings.
#

#
# FancyIndexing is whether you want fancy directory indexing or standard
#
IndexOptions FancyIndexing

#
# AddIcon* directives tell the server which icon to show for different
# files or filename extensions. These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

#
# DefaultIcon is which icon to show for files which do not have an icon
# explicitly set.
#
DefaultIcon /icons/unknown.gif

#
# AddDescription allows you to place a short description after a file in
# server-generated indexes. These are only displayed for FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz

#
# ReadmeName is the name of the README file the server will look for by
# default, and append to directory listings.
#
# HeaderName is the name of a file which should be prepended to
# directory indexes.
#
ReadmeName README.html
HeaderName HEADER.html

#
# IndexIgnore is a set of filenames which directory indexing should ignore
# and not include in the listing. Shell-style wildcarding is permitted.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

# End of indexing directives.

#
# Document types.
#

#
# AddLanguage allows you to specify the language of a document. You can
# then use content negotiation to give a browser a file in a language
# it can understand.
#
# Note 1: The suffix does not have to be the same as the language
# keyword --- those with documents in Polish (whose net-standard
# language code is pl) may wish to use "AddLanguage pl .po" to
# avoid the ambiguity with the common suffix for perl scripts.
#
# Note 2: The example entries below illustrate that in quite
# some cases the two character 'Language' abbreviation is not
# identical to the two character 'Country' code for its country,
# E.g. 'Danmark/dk' versus 'Danish/da'.
#
# Note 3: In the case of 'ltz' we violate the RFC by using a three char
# specifier. But there is 'work in progress' to fix this and get
# the reference data for rfc1766 cleaned up.
#
# Danish (da) - Dutch (nl) - English (en) - Estonian (ee)
# French (fr) - German (de) - Greek-Modern (el)
# Italian (it) - Korean (kr) - Norwegian (no) - Norwegian Nynorsk (nn)
# Portugese (pt) - Luxembourgeois* (ltz)
# Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cs)
# Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)
# Russian (ru)
#
AddLanguage da .dk
AddLanguage nl .nl
AddLanguage en .en
AddLanguage et .ee
AddLanguage fr .fr
AddLanguage de .de
AddLanguage el .el
AddLanguage he .he
AddCharset ISO-8859-8 .iso8859-8
AddLanguage it .it
AddLanguage ja .ja
AddCharset ISO-2022-JP .jis
AddLanguage kr .kr
AddCharset ISO-2022-KR .iso-kr
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pl .po
AddCharset ISO-8859-2 .iso-pl
AddLanguage pt .pt
AddLanguage pt-br .pt-br
AddLanguage ltz .lu
AddLanguage ca .ca
AddLanguage es .es
AddLanguage sv .sv
AddLanguage cs .cz .cs
AddLanguage ru .ru
AddLanguage zh-TW .zh-tw
AddCharset Big5 .Big5 .big5
AddCharset WINDOWS-1251 .cp-1251
AddCharset CP866 .cp866
AddCharset ISO-8859-5 .iso-ru
AddCharset KOI8-R .koi8-r
AddCharset UCS-2 .ucs2
AddCharset UCS-4 .ucs4
AddCharset UTF-8 .utf8

# LanguagePriority allows you to give precedence to some languages
# in case of a tie during content negotiation.
#
# Just list the languages in decreasing order of preference. We have
# more or less alphabetized them here. You probably want to change this.
#

LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br ru ltz ca es sv tw

#
# AddType allows you to tweak mime.types without actually editing it, or to
# make certain files to be certain types.
#
AddType application/x-tar .tgz

#
# AddEncoding allows you to have certain browsers uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
AddEncoding x-compress .Z
AddEncoding x-gzip .gz .tgz
#
# If the AddEncoding directives above are commented-out, then you
# probably should define those extensions to indicate media types:
#
#AddType application/x-compress .Z
#AddType application/x-gzip .gz .tgz

#
# AddHandler allows you to map certain file extensions to "handlers",
# actions unrelated to filetype. These can be either built into the server
# or added with the Action command (see below)
#
# If you want to use server side includes, or CGI outside
# ScriptAliased directories, uncomment the following lines.
#
# To use CGI scripts:
#
#AddHandler cgi-script .cgi

#
# To use server-parsed HTML files
#
#AddType text/html .shtml
#AddHandler server-parsed .shtml

#
# Uncomment the following line to enable Apache's send-asis HTTP file
# feature
#
#AddHandler send-as-is asis

#
# If you wish to use server-parsed imagemap files, use
#
#AddHandler imap-file map

#
# To enable type maps, you might want to use
#
#AddHandler type-map var

# End of document types.

#
# Action lets you define media types that will execute a script whenever
# a matching file is called. This eliminates the need for repeated URL
# pathnames for oft-used CGI file processors.
# Format: Action media/type /cgi-script/location
# Format: Action handler-name /cgi-script/location
#

#
# MetaDir: specifies the name of the directory in which Apache can find
# meta information files. These files contain additional HTTP headers
# to include when sending the document
#
#MetaDir .web

#
# MetaSuffix: specifies the file name suffix for the file containing the
# meta information.
#
#MetaSuffix .meta

#
# Customizable error response (Apache style)
# these come in three flavors
#
# 1) plain text
#ErrorDocument 500 "The server made a boo boo.
# n.b. the single leading (") marks it as text, it does not get output
#
# 2) local redirects
#ErrorDocument 404 /missing.html
# to redirect to local URL /missing.html
#ErrorDocument 404 /cgi-bin/missing_handler.pl
# N.B.: You can redirect to a script or a document using server-side-includes.
#
# 3) external redirects
#ErrorDocument 402 http://some.other-server.com/subscription_info.html
# N.B.: Many of the environment variables associated with the original
# request will *not* be available to such a script.

#
# Customize behavior based on the browser
#

#
# The following directives modify normal HTTP response behavior.
# The first directive disables keepalive for Netscape 2.x and browsers that
# spoof it. There are known problems with these browser implementations.
# The second directive is for Microsoft Internet Explorer 4.0b2
# which has a broken HTTP/1.1 implementation and does not properly
# support keepalive when it is used on 301 or 302 (redirect) responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4<.0b2;" nokeepalive downgrade-1.0 force-response-1.0

#
# The following directive disables HTTP/1.1 responses to browsers which
# are in violation of the HTTP/1.0 spec by not being able to grok a
# basic 1.1 response.
#
BrowserMatch "RealPlayer 4<.0" force-response-1.0
BrowserMatch "Java/1<.0" force-response-1.0
BrowserMatch "JDK/1<.0" force-response-1.0

# End of browser customization directives

#
# Allow server status reports, with the URL of http://servername/server-status
# Change the ".your-domain.com" to match your domain to enable.
#
#
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#

#
# Allow remote server configuration reports, with the URL of
# http://servername/server-info (requires that mod_info.c be loaded).
# Change the ".your-domain.com" to match your domain to enable.
#
#
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#

#
# There have been reports of people trying to abuse an old bug from pre-1.1
# days. This bug involved a CGI script distributed as a part of Apache.
# By uncommenting these lines you can redirect these attacks to a logging
# script on phf.apache.org. Or, you can record them yourself, using the script
# support/phf_abuse_log.cgi.
#
#
# Deny from all
# ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
#

#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
#
# ProxyRequests On

#
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#

#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
# ProxyVia On

#
# To enable the cache as well, edit and uncomment the following lines:
# (no caching without CacheRoot)
#
# CacheRoot "/private/var/run/proxy"
# CacheSize 5
# CacheGcInterval 4
# CacheMaxExpire 24
# CacheLastModifiedFactor 0.1
# CacheDefaultExpire 1
# NoCache a-domain.com another-domain.edu joes.garage-sale.com

#
# End of proxy directives.

### Section 3: Virtual Hosts
#
# VirtualHost: If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# Use name-based virtual hosting.
#
#NameVirtualHost *:80

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#
#
# ServerAdmin webmaster@dummy-host.example.com
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#

# If php is turned on, we respect .php and .phps files.
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

# Since most users will want index.php to work we
# also automatically enable index.php

DirectoryIndex index.html index.php

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

# Only the pages of users who have edited their
# default home pages will be advertised on Rendezvous.
RegisterUserSite customized-users
#RegisterUserSite all-users

# Rendezvous advertising for the primary site is off by default.
#RegisterDefaultSite

Include /private/etc/httpd/users/*.conf

End copying above this line.

Apple’s XSAN 2 with OSX Leopard

montanaflynn — Fri, 22 Feb 2008 18:04:24 +0000

In the first major upgrade to its Storage Area Network (SAN) file system, Apple on Tuesday introduced Xsan 2, adding a new feature called MultiSAN and making it easier for first time users to get up and running. “The feedback we’ve heard from customers is that a SAN is too difficult to setup, so one of the goals in this release was to make SAN simpler,” Eric Zelenka, senior product line manager server & storage software, told Macworld.

One of the ways Apple has accomplished this is with the SAN Setup Assistant, which is integrated into Mac OS X Leopard Server or as an application that can be run on its own. When first setting up Mac OS X Server, a fourth option automatically appears if you have a Fibre Channel card installed. The setup assistant will do all the heavy lifting for you, setting up everything including Open Directory permissions.

Xsan 2 also includes a new feature called MultiSAN for users who need to access multiple Xsan volumes from the same workstation or server. Zelenka pointed to examples like a newsroom with separate SAN volumes for production and broadcast.

“Tens of thousands of businesses, from small video post-production houses to large data centers and TV stations, use Xsan as their clustered SAN file system,” said Zelenka. “Now with Xsan 2, businesses can efficiently share and access their data faster and easier than ever before.”

In addition, Apple said that Leopard Server features such as iCal Server, Mail Server and Podcast Producer, can now integrate with Xsan 2 to support clustered file systems, improving performance and scalability and reducing the impact of a service outage from the loss of any one server.

Xsan 2 has also been qualified with third-party RAID storage hardware from Promise Technology in configurations tuned and optimized for Xsan.

Apple has qualified Xsan 2 with Xserve, Mac Pro and Apple Fibre Channel PCI-X cards. Xsan 2 requires that Mac OS X version 10.5 or Mac OS X Server version 10.5 software be installed and will support qualified Fibre Channel switches from vendors such as Brocade, QLogic and Cisco, and RAID storage hardware including Xserve RAID and Promise VTrak E-Class RAID subsystems.

Xsan 2 is available immediately for $999.

Basic Command Line Utilities, Tips, & Commands

montanaflynn — Wed, 20 Feb 2008 17:04:32 +0000

Many Mac users avoid the command line altogether, a reasonable amount probably don’t even know it exists. For the curious out there, here are some basic and essential commands and functionalities to know if you want to get started using the Mac OS X Terminal. We’ll cover simple file manipulation, maneuvering in the file system, displaying and killing processes, and more. Remember to remove the brackets or the commands won’t work.

The Basics

ls -la list all contents of a directory including hidden files
cd [directory] move to the specified directory, cd /Applications will move to your applications folder
mv [file1] [file2] mv is able to rename files or move them, depending on usage
cp [file] [destination] copies a file to either a new filename or destination
cat [file] | more display contents of a file screen by screen by ‘piping’ the contents through more
touch [file] creates a file with the given name, eg: touch test.txt will create a blank text file
top display a continuously updated list of all running processes, including memory and cpu usage, PID is the process ID which you would use to kill a process
ps -aux list all processes running from all users, -ux will list only processes of current user
kill -9 [pid] kill the specified process id (basically force quit for the command line)
rm [file] rm removes the specified file or directory, there is no warning so use with caution
ping [ip] determine network latency by pinging another host

General Usability Tips

Use the tab key, the tab key will autocomplete directories and filenames for you
Enable colored terminal, this makes it easier to browse through large amounts of files
If a command confuses you, try running it with the –help flag, which will often display basic instructions on the given command
Remember manual pages exist on many commands as well, access them by typing man [command], eg: man ping
If the output of a command flies by you and is too much to fit on one screen, try piping it through more, like so: ls -la |more this will enable you to see the output a screen at a time
You can export the contents of a file, output of a command, and results of a script to a text file using the alligators (improper terminology, excuse my forgetfulness), eg: ls -la /Applications > applist.txt
If you’ve ever noticed your CPU load skyrocket inappropriately, a good place to find the errant process is with the top command, use top in conjection with kill to find the process ID and kill the CPU hog
Don’t be afraid to get your hands dirty!

Integrating OSX Clients with an OpenLDAP Directory

montanaflynn — Tue, 19 Feb 2008 21:50:52 +0000

This is an article by Adam Shand you can view the original article at http://www.spack.org/wiki/AppleOsxIntegrationWithOpenLdap.

Where I work is primarily a RedhatLinux shop, with a smattering of MicrosoftWindows, SgiIrix and Apple Osx. While we will remain primarily a Linux house for cost reasons, Apple Osx is becoming an increasingly important part of our corporate workflow due to our dependence on quicktime, the increasing number of applications available and the increasing preference of both our artists and IT staff.

Because we already had a huge Linux infrastructure built I didn’t want to mess about with Netinfo or using an OSX Server as a bridge between our Macs and our LdapAuthentication infrastructure. I wanted our Mac’s to play nicely in our existing world, this meant that authentication, naming (users, groups etc) and automount all had to work with as little fuss or differences as possible.

Assumptions

To keep this howto as simple as possible I had to make some assumptions:

That you are moderately familiar with LDAP or willing to struggle through the relatively steep learning curve before tackling this.
That you have admin/root privileges on at least one Mac and one Linux server.
You are capable of installing and configuring complex packages.
That you are using AppleOsx 10.3/Panther as your client (I’m using 10.3.4).
That you are using running OpenLdap 2.0 on a Linux server (I’m using OpenLdap 2.0.21 on a RedhatLinux 7.3 box).

You may or may not have good luck following these directions with older or newer versions.

Setting Up the OpenLDAP Server

There are plenty of articles out there on setting up an OpenLdap server, so I won’t go into that here. If you haven’t done this before the best article I’ve found is the Mandrake Secure article (a slightly more evolved version is available on the authors wiki). If you are unfamiliar with LDAP and still want to tackle this probably the single most useful thing you can do is install a good LdapClient and start browsing around to get a feel of how it works. I recommend PHP LDAP Admin as by far the best client I’ve used.

OSX can access normal user and group data so long as you configure it correctly. The hard part, and the almost completely undocumented part, is getting OSX automount to work. OSX comes with two options for automounting directories, AMD and the Apple proprietary automount. I only discuss the automount option because all our attempts at configuring AMD resulted in a horrible unstable mess. ¹

Setup and configure an OpenLdap server.
If possible make sure that you can authenticate to it from a Linux box and that everything works as expected before you continue any further.
Add the apple.schema² to you LDAP directory:
1. Download the apple.schema file.
2. Copy it into your schema directory (normally /etc/openldap/schema).
3. Because of the way that Apple wrote their automount schema definition, adding it requires that you disable schema checking in your OpenLdap configuration. To turn off schema checking you must add this line to your slapd.conf:
```
schemacheck off
```
Restart OpenLdap for the configuration changes to take effect, watch the logs carefully to make sure that the new schema file was not rejected.
If you have already populated your LDAP directory make sure you have top level containers called “ou=people”, “ou=group” and “ou=mounts”. If you haven’t populated it I’ve included a sample LDIF file which you can use to get started.
Using the sample LDIF as an example, add enough valid user, group and mount entries for you test your configuration.

Note: I have not yet followed the above steps to make sure they are correct and that I haven’t left anything out. If you encounter problems please let me know.

Configuring the Apple OSX Client

These instructions were written for OSX 10.3 (Panther) however they are still approximately correct for anything from 10.2 to 10.4. Once you understand how it works just follow your nose and it should be fairly straight forward.

Open Directory Access (/Applications/Utilities)
Enable the LDAPv3 Plugin
Select the LDAPv3 Plugin and click “Configure”
Click “New”
1. Enable: tick
2. Server: ldap01.spack.org
3. LDAP Mappings: RFC 2307 (Unix)
4. Search Base Suffix: dc=spack,dc=org
5. SSL: unticked
Click “Edit”
1. [optional] Open/Close times out in: 10
2. [optional] Connection times out in: 10
3. Use authentication while connecting: unticked
4. Encrypt using SSL: unticked
5. Use custom port: unticked
Now Click on “Search & Mappings” ³
1. [optional] Click on “Users”
  1. In the “Search base” box enter ou=people,dc=spack,dc=org
  2. Tick “first level only”
2. [optional] Click on “Groups”
  1. In the “Search base” box enter ou=group,dc=spack,dc=org
  2. Tick “first level only”
3. [optional] Click on “Mounts”
  1. In the “Search base” box enter ou=mounts,dc=spack,dc=org
  2. Tick “first level only”
Save back out to the main “Directory Access” screen.
If you’ve made any mistakes now is the time to catch them, use the techniques in the below testing section to verify that you can see users, groups and mounts. If you find any problems you should fix them before you continue or risk an unusable system.
Click on the “Authentication” tab.
1. Select “Custom” from the “Search:” drop down menu.
2. Click “Add” at the bottom of the screen.
3. Select the “LDAPv3 …” option from the “Available Directories” screen.
Exit “Directory Access” and save all changes.

Depending on the exact order you exit “Directory Access”, you may need to reboot for the changes to become live. It can be a bit quirky and I haven’t figured out exactly which things make a difference yet.

Testing

The best program to test your new directory service with is an AppleOsx tool called dscl for “Domain Service command line utility”.⁴

You can use dscl to either search all of the available sources for information (via the /Search/Users path) or you can manually specify which particular directory you wish to query (eg./LDAPv3/ldap.spack.org/Users. The difference between Users and People seems to be based on whether the data is keyed on username (uid) or full name (cn/gecos).

Hopefully some examples will make it clear:

## to list only LDAP users
# dscl localhost list /LDAPv3/ldap.spack.org/Users
adam
ben
bill
paul
......

## to list all available users (local, LDAP, NIS, whatever)
# dscl localhost list /Search/Users
adam
ben
bill
paul
......

# dscl localhost list /LDAPv3/ldap.spack.org/People
Adam Shand
Ben Foo
Bill Bar
Paul Gaz
......

# dscl localhost read /LDAPv3/ldap.spack.org/Groups/staff
cn: staff
gidNumber: 10
memberUid: adam ben bill paul
objectClass: posixGroup top
AppleMetaNodeLocation: /LDAPv3/ldap.spack.org
GroupMembership: adam ben bill paul
Member: adam ben bill paul
PasswordPlus: ********
PrimaryGroupID: 10
RecordName: staff

# dscl localhost read /Search/Users/adam
cn: Adam Shand
gecos: Adam Shand
gidNumber: 105
givenName: Adam
homeDirectory: /home/adam
loginShell: /bin/bash
objectClass: top person organizationalPerson inetOrgPerson account posixAccount shadowAccount inetLocalMailRecipient kerberosSecurityObject
sn: Shand
uid: adam
uidNumber: 364
AppleMetaNodeLocation: /LDAPv3/ldap.spack.org
NFSHomeDirectory: /home/adam
PasswordPlus: ********
PrimaryGroupID: 101
RealName: Adam Shand
RecordName: adam
UniqueID: 364
UserShell: /bin/bash

# dscl localhost read /LDAPv3/ldap.spack.org/Mounts/netapp\\:\\/vol\\/vol0\\/home
cn: rhun:/vol/vol0/home
mountDirectory: /home
mountOption: nodev intr hard nfsv3 resvport wsize=8192 rsize=8192
mountType: nfs
objectClass: mount
AppleMetaNodeLocation: /LDAPv3/ldap.spack.org
PasswordPlus: ********
RecordName: rhun:/vol/vol0/home
VFSLinkDir: /home
VFSOpts: nodev intr hard nfsv3 resvport wsize=8192 rsize=8192
VFSType: nfs

If the above works as expected then you should be able to:

Log into your OSX box with a username and password that only exists in LDAP.
Finger users that only exist in LDAP (e.g. finger -m ).
Change directories into a network mount location and have it automatically mounted (e.g.. cd /home/adam). This works for home directories as well.
Do an ls -l on a file owned by an LDAP user and group and have the uid/gid resolve into proper names.

Trouble Shooting

Debugging OSX

I heartily recommend that you turn the debugging up as high as possible. The best way to do this on the client side is to add a line like this to your /etc/syslog.conf and then restart syslog ⁵:

*.*                                /var/log/debug.log

Debugging LDAP

If you are having trouble understanding why OpenLdap is behaving the way it is, or why client queries don’t seem to be work as you expect, it’s very useful to fire it up in debug mode where it prints everything it’s doing to the screen. To do this stop your LDAP service and run slapd -d 255.

LDAP ACLs

Access control lists in LDAP are powerful, complicated and confusing. I recommend you don’t configure any ACL’s until after you have everything tested and working. After that enabled them one at a time and test copiously to make sure you haven’t introduced unexpected problems.

NFS Locks

If you NFS mount your users home directories you may find that your users experience random application hangs, especially applications which use the Addressbook.app. The way to resolve this is disable NFS locking. You can do this either by downloading Marcel Bresink’s [NFS Manager] or by editing /etc/hostconfig and changing the NFS locking line to look like NFSLOCKS=-NO- (you have to reboot for the change to take effect).

Further Thoughts

Automount Quirks

The Apple automount doesn’t support a few standard automount features, we’ve worked around them in various ways:

The special directory /net (or /hosts in SgiIrix land) allows you to mount any available share by simply changing into a /net// style directory. While not ideal the best solution I’ve found is to reshare /net from an Linux server via Samba. OSX clients can then get similar functionality by manually mounting the Samba share (eg. Command-K and mount smb://samba.spack.org/net).
Actually, you can mkdir /net and add “-m /net -host” to the second automount line in /System/Library/StartupItems/NFS to get the /net behavior, or better yet, copy that item to /Library/StartupItems before modifying it so your changes don’t get overwritten. — Anonymous Comment — I will test this and update — AdamShand
- * The above doesn’t seem to work on Intel Macs, anyone got any ideas?
  - Colin Aspin (caspin at mac.com)
Wildcard mapping using the * and & characters is typically used by autofs for home directories. The work around is to simply mount all of your home directories rather then rely on the wildcard mapping to mount just the required user home directories. This works fine, but it means that an accidental ls /home can be quite slow.
When getting automount maps from LDAP, automount doesn’t seem to be able to create required parent directories (so if you are automounting /foo/bar, you must make sure that the/foo directory exists when automount starts).
Automount keys mounts off of the source name instead of the destination name. This is silly since you sometimes have legitimate reasons for having the same share mounted at different points in your filesystem (but by definition can’t mount two shares at the same point in your filesystem).

Optimizing Searches

You can make the searches for user, group and mount data a bit more efficient by telling “Directory Access” exactly where it can find the information it’s looking for (as opposed to the default of it searching from the top of the tree down for matching entries):

Updating Automount

Sadly automount isn’t capable of automatically rescanning the LDAP server for changes, if you make changes to the automount data in LDAP you must either reboot (ick!) or kill -HUP the automount process (there are two automount processes, you want the one with all the “-m” options and the one without the “-nsl”⁶).

NFS Mount Options

OSX supports the usual NFS mount options but has two unusual ones. The first is “resvport”, this option is required for OSX to be able to mount shares from many NFS servers, as a general rule I recommend you always use it. The second is the “net” option, for the purposes of making an OSX box behave like a normal Unix box I recommend that you stay far away from it. If you want to learn more then Marcel Bresink’s excellent article is the best place to learn more.

Configure Slaves

Before you bring your new system into production I strongly recommend that you configure at least one LDAP slave. Because your new LDAP infrastructure will be responsible for all your authentication, naming and automounting needs, you really want the redundancy provided by a slave server.

Providing Redundancy with DNS

I name my master server ldap0.spack.org and my slaves ldap1.spack.org and ldap2.spack.org. I then create a DNS round robin called ldap.spack.org which points at all three addresses. Once you have this setup you should point your clients at the round robin alias ldap.spack.org. Now if one of your LDAP servers fails you can stop clients from talking to it by simply removing the failed server from the DNS round robin.

Better Redundancy

Better then a DNS round robin would be to provide redundancy with some sort of layer 7 aware proxy. I don’t know if any of the commercial switch providers offer LDAP aware load balancing switches. There may also be OpenSource alternatives that I’m not aware of.

Linux AutoFS

The Linux AutoMount daemon can also store it’s entries in the “ou=mounts” container of your LDAP directory. There does not seem to be any problem with the Linux mount entries coexisting with the OSX mount entries in the same ou.

Automation

I have some PerlLanguage scripts which will mirror the contents of the Linux “auto.master” and ‘”"auto_*” files into OSX automount format on an LDAP directory. If get permission, I will post them here.

SSL

Before deploying this you should make sure that all of your clients and servers are configured to talk to LDAP over SSL encrypted links. Eamon Caddigan has kindly written in with what he did to make it work:

Once unencrypted authentication was working, I followed these instructions for configuring the server to use SSL (part of the expanded Mandrake Secure guide already linked to your site). After restarting slapd, simply tick the “Encrypt using SSL” checkbox (“Use custom port” is left unticked because TLS uses the standard port) in the Directory Access app on the OS X client. Unless I’m missing something (very possible), that’s all there is to it.

Missing Pieces

Remove Mapping for Password

In the attribute mapping part, if you remove the password map then OSX will authenticate the user by binding to the LDAP server rather then doing a password comparision. This means your encryption method becomes transparent to your clients and you can get away from crypt. Untested.

Use DHCP Supplied LDAP Server

OSX supports getting it’s LDAP information from DNS, I have not successfully made this work yet and am a little confused about how you are supposed to configure it this way since “Directory Access” does it’s pathing seems to require that you know the name of the LDAP server the client will use. Here’s a snippet from a /etc/dhcpd.conf, though I still wonder how to specify two LDAP servers:

option ldap-server code 95 = text;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.200 192.168.1.250;
  option routers 192.168.1.1;
  option domain-name "spack.org";
  option domain-name-servers 192.168.1.2,192.168.1.3;
  option ldap-server "ldap://192.168.1.2/dc=spack,dc=org";
}

Write Mappings to Server

You can write your custom mappings to the server so that you don’t have to manually configure each client. I have managed to write the mappings to my server but have been unable to make the client pay any attention to them. There is some more information in this security advisory.

Review of FreeNAS

montanaflynn — Mon, 18 Feb 2008 22:14:32 +0000

FreeNAS, an open source NAS server, can convert a PC into a network-attached storage server. The software, which is based on FreeBSD, Samba, and PHP, includes an operating system that supports various software RAID models and a Web user interface. The server supports access from Windows machines, Apple Macs, FTP, SSH, and Network File System (NFS), and it takes up less than 16MB of disk space on a hard drive or removable media.

FreeNAS is free to use and deploy without cost. It’s an open source project published under the BSD license. The software is popular enough to have gotten more than 20,000 downloads last month.I downloaded the FreeNAS 0.66 ISO image and burned it onto a CD. To get started with FreeNAS, you need a PC or server with at least 96MB of memory, a network adapter, and at least one hard disk. I used an older PC with four IDE drives attached. I wanted to install FreeNAS on one of the disks and use the other three as a RAID 5 set. My test machine supports only four IDE drives, so I temporarily changed one of the drives for a CD-ROM drive, installed FreeNAS, and swapped back the hard disk before configuring the disks.

Booting the PC from the CD gets FreeNAS up and running, but you still need to configure it. Follow the instructions in the FreeNAS setup and user guide.

One thing to watch while doing the initial configuration is that the FreeNAS server doesn’t do any auto assignment of the network card. I assumed that since I only had one network card, it would automatically be assigned as the network card for the system. I was wrong. I only realised the problem after an hour of checking connections and cables. You must assign the network card as laid out in the “LAN interface and IP configuration” section of the user guide.

Once you have the box working, enter the IP address you assigned the FreeNAS server into the address bar of a Web browser. You’ll be prompted for a username and password. The defaults are “admin” and “freenas”. The start page shows some system information such as the version number and memory usage, with a menu on the left side.

The first thing I wanted to do was get the RAID disks working. Once again, the user guide is your friend, with clear, step-by-step instructions for the process.

Only whole hard disks can be used for RAID sets, so if you install the FreeNAS server onto one of your disks (rather than onto a USB pen drive) then that disk can’t be used as part of a RAID set. Also, to get the maximum space from your RAID sets, use disks of the same or similar size. Some versions of FreeNAS insist on the drives being exactly the same size due to some bugs in the software.

One other thing to watch while creating a mount point for a RAID set is that you must change the the partition type to Software RAID. I didn’t do this on my first attempt to set up RAID and had to scratch my head for a while when the RAID set didn’t work.

The final step to making the volume available on the network is to configure the network services such as CIFS and FTP. Windows machines use the CIFS protocol to access files over the network. CIFS is configured on the CIFS page in the Services section. To enable it, tick the Enable box at the top right and then set the workgroup name. Anonymous authentication is the easiest to get up and running, and you’ll find options for authenticating locally defined users and using domain-based authentication. After clicking Save, I was able to access the FreeNAS server from a Windows machine. I watched the hard disks while I copied over some files, and the little LEDs all blinked rapidly as the disks worked in unison. My FreeNAS server was fully functional!

FreeNAS’s web management interface is comprehensive enough that to administer the server you don’t need to use the command line. There is provision for full shell access via SSH but I didn’t find the need to try it. Reading the forums on freenas.org, which are the primary venue for support, shows that some people do use the command line for some more exotic configurations, but for the basic user the Web management interface will be sufficient.

In my testing, the core FreeNAS system was stable, but it is possible to get the system configuration into a confused state. For example, when creating my first local user I ignored the message that a group must be created first and blindly went ahead and tried to create the user. This resulted in some internal errors, and from that point on all local user authentication failed. The only way to fix the situation was to restore the FreeNAS server to the factory defaults and reconfigure the system from the beginning. If you respect the warnings and messages, you shouldn’t have any problems.

To secure your server you need to change the default password for the Web management interface. It also might be worth disabling the console menu if physical access to the server isn’t limited.

One limitation of the software is the lack of granularity in setting access rights to shares. The local user authentication model is an all-or-nothing affair. You can’t set some users to be read-only or others to only have access to certain shares. Once a user is authenticated, he has full access to all the shared storage.

The FreeNAS server has lots of potential and is under active development; there were 11 point releases in the first four months of 2006 alone. It’s a good alternative for building a simple network server without having to install a full-blown version of Linux or FreeBSD. It is also a good way to make use of aging hardware, as its system requirements are quite modest by today’s standard.

Gary Sims has a degree in Business Information Systems from a British university. He worked for 10 years as a software engineer and is now a freelance Linux consultant and writer.

Need for a personal server? iServe?

montanaflynn — Mon, 18 Feb 2008 22:12:44 +0000

Consumers are increasingly investing in three forms of digital content (content that lives primarily on hard drives):1) commercial content, such as music, TV shows, and now movies; 2) personal content, such as photos and home video; and 3) hybrid content, commercial or public content that consumers have recorded or downloaded, such as TV shows saved on personal video recording (PVR) devices like Tivo and content downloaded from Internet sites like Google Video.

For consumers embracing commercial, personal, and hybrid content, two challenges are rapidly emerging:

Massive storage needs. For some content, such as music, each song file is relatively small (perhaps 3 or 4 megabtes (MBs)), but a collection can take up many gigabytes (GBs) of storage. For other content, such as movies, files can each be multiple gigabytes (e.g., the file for the movie Pirates of the Caribbean from Apple Computer’s iTunes Store (iTS) is 1.6 GB; a recent episode of the TV show Battlestar Galactica from iTS is over 480 MBs; the movie Superman Returns from Amazon.com’s Unbox download store in “DVD quality” is 2.9 GBs). And as high-definition content becomes the norm, the file sizes will only increase.
The use, management, and distribution of content. Many households have multiples PCs (we use the term PC to mean a computer running Windows, Mac OS, Linux, or any other user operating system), and many consumers also bring home notebooks and other portable computers supplied by their employer. Each of these devices may be purchasing and storing digital content, and many of the downloaded files are locked down by various digital rights management (DRM) technologies, such as Apple’s FairPlay, that set the rules for how the content can be used and distributed. Added to the mix is the the growing personal content, such as multi-gigabyte photo databases and video repositories. In households with adults and kids, these issues will become critical very quickly.

Media center PCs and external hard drives won’t cut it; a home server is needed

The storage issue is the first challenge most consumers face as they embrace digital content. Even those with modest music and photo collections can quickly find their primary PC unable to cope with the gigabytes of content. Unfortunately, many consumers may also experience the downside of unprotected digital content if that central PC has a hard drive failure or files are corrupted. And as consumers experience the ease of buying and using digital downloads (e.g., quick delivery and instant access without fumbling with physical media), they will also face the issues around DRM and device authorization limitations.

These experiences have or will lead consumers to look at two potential solutions:

Media management and distribution on media-centric PCs. Both Microsoft and Apple market products aimed at the consumer interested in a media-centric PC. Microsoft currently sells Widows XP Media Center Edition 2005 software (soon to be upstaged by various flavors of its next-generation operating systems, Vista) that includes technology for recording TV shows, displaying photos and videos on TVs, and linking with other devices, such as the company’s Xbox 360 game console, using Media Center Extender technology. All of Apple’s consumer-oriented products, such as the iMac, Mac mini, and MacBook offer somewhat similar technology for remote display of content (notably, Apple does not offer its own PVR software). In addition, Apple recently announced plans to deliver “ITV” (a code name), a set-top box that connects to TVs and plays digital content wirelessly streamed from Apple software. ITV is expected sometime in Q1 of 2007 (see this Engadget article).
More storage by buying high-capacity hard drives as part of new PCs or in external packages. Hard drives are relatively cheap these days. It is not uncommon to see home PCs with 250 GB drives, and external hard drives that rely on USB or FireWire connections are also relatively inexpensive (a 500 GB external hard drive may cost anywhere from $200-300). They are also simple to use — just plug them into most PCs and the storage is available.

The problem is that neither one of these solutions address the storage and media management challenges effectively. Media-centric PCs are about making one PC the center of the household media experience. They don’t provide a way to easily distribute and manage content, playlists, and related databases among consumer devices. And larger, single hard drives most likely won’t provide enough storage for the household, they are tied to a PC, and they don’t have any “brains” — i.e., they lack software and tools for managing content. They are just big, dumb filing cabinets. And as many home PC users know, relying on a single drive with no backup plan — which is the case for most consumers — is a disaster waiting to happen.
Some technophiles have invested in network attached storage (NAS) devices, essentially high-capacity, multiple drive appliances that adds storage to any network. Others have bought multi-hard drive disk arrays that plug into a single PC. Again, while these solutions offer plenty of storage, they aren’t designed to overcome the challenges of consumer content management.
Instead of media center PCs or larger hard drives, we think the most sensible solution is a dedicated home media server that combines lots of storage with the required software brains to intelligently and seamlessly manage consumer content of all types.

What a home media server needs to do

A home media server is a lightweight server designed to store, stream, sync, and manage a household’s complex portfolio of digital assets. It is not meant to be used as a computer. It will be tucked away in a utility closet or hidden behind closed cabinet doors in the living room media center. Ripping CDs, buying TV shows online, and editing photos will be handled by other household devices. The home server will:

Store content by auto-syncing with and backing up other devices. On the surface, the primary job of the home media server is to simply store files. But manual storage or rudimentary backup plans are not enough. The server’s software needs to be tied into the media applications on other household devices. When a PC in a kid’s room buys a show, a copy of the file will be copied to the server’s hard drives. Periodically, the server will run a backup program that culls connected devices to discover new files, such as family photos, that need to be archived. In other cases, a consumer may choose to ensure that all files of a certain type are only on the server. Either way, the media server becomes the central repository of the household’s digital horde.
Distribute content using streams or file transfers. Some content needs to be on a device, such as a notebook computer (a consumer may want to watch a TV show or listen to certain music while traveling), while other devices only need to access a content stream from the server. A home server would enable consumers to choose whether to move large media files and collections to devices, leave most files on the server, or make those decisions based on the capacity of each device.
Manage content –including DRM files — on devices and by accounts. In the two previous bullets, we talked about examples where consumers would determine how content was stored and accessed. This management function of the server will also be critical in terms of DRM content. If the music industry, for example, insists on keeping the 5-device limit on audio file use, the server software could be used to easily authorize or deauthroize devices. Also, the server could be configured so that some content, while household owned (by the “super” or Admin account), is restricted to certain users. In addition, it could manage multiple user accounts, each with their own authorization, so that siblings’ content was managed, but kept separate.

How Apple could do it: The “iServ” concept

Two companies are likely to lead the home server charge: Apple and Microsoft. However, since Apple dominates the digital download market for audio today, and since they have direct control over their PC and server hardware products, we will focus on what it could deliver. Also, Apple is continually looking to innovate with its consumers offerings, and the idea of an “iServ” media server seems very reasonable given the company’s history.

Inside the iServ

The server would be built around these concepts:

User upgradeable storage. The iServ would offer bays of hot swappable hard drives, perhaps up to 1.5 terabytes in a three-drive configuration. The large storage would provide a central repository for content as well as enable household backup of data on various other Mac, PCs, and digital devices. The iServ could ship with a single 250 GB drive; consumers would got to the Apple Store or order additional drives online.
Automatic syncing of household digital content. Any device on the network that buys a song, TV show, or movie from the iTS will inform the server of its purchase; a specialized iTunes iServ app will make a copy of all content purchased on authorized household systems. This copy will serve as both an archive, as well as a source for streaming or copying the file to other authorized devices.
Streaming access to content. Besides enabling simple backup and transfers, iServ would be hard wired or use wireless connections to directly stream content to other computers or the forthcoming ITV set-top box. For example, when a mom purchases a copy of the Office on her laptop, the device will notify and transfer a copy of the file to the iTunes server app on the iServ. Without any extra effort, the family can then access the show from the FrontRow interface on the ITV box.
Remote management of the iServ. The home server could be used in a headless fashion — controlled by a remote Mac — or with a local monitor. The iServ Remote software would enable the household administrator to set policies on content access, such as restricting streams or transfers of explicit content. From this remote console, a consumer could authorize and deauthorize household devices and otherwise manage FairPlay digital rights management issues.
Additional household software. Just as Apple offers complementary — but secondary — applications for its iPods, such as games, the iServ could offer its own complementary software, such as a server-based family calendaring solution. In addition, an iPhoto server app could archive, backup, and enable local distribution of family photos.

Could Apple really do it? Is it a realistic product? Yes, because:

Consumers might want it today, but they will need it tomorrow … Consumers will bump into a wall as they buy more and more digital content. Managing DRM files and swapping them to various devices will become increasingly frustrating, as will authorizing and deauthorizing systems. Losing content to a hard drive failure will make any consumer interested in a seamless backup solution. Overall, the iServ would make digital content ownership much easier.
… and Apple already has most of the pieces. The box itself could be basically a Mac mini with drive bays. The hot-swappable bays are technology Apple is familiar with in its Xserve and Xserve RAID offerings (the vendor calls them Apple Drive Modules). The iCal Server is already being developed for Mac OS X 10.5 Leopard Server. The core technology for remote manage already exists in Remote Desktop, and Backup and iSync technology have already been built.Apple could leverage its Core Animation development technology to create easy-to-use but powerful iServ management tools and apps. Other OS X Server features that could be utilized include Software Update Server, allowing a household to stay on top of Security Updates and other patches. Non-needed server features could be hidden, such as Open Directory and Xgrid. The most work would come from creating an iTunes and iPhoto server app.

Finally, what about price? An interesting Apple product that costs too much can fail (e.g., the Cube). While this note is not the result of detailed research on component pricing or likely acceptable consumer price points, we can make some assumptions based on current Apple, competitive, and peripheral products:

iServ with one 250 GB drive, Mac OS X Server (iServ Edition) and iServ apps – $999
Additional drives – 250 GB for $150; $500 GB for $300

With budding demand and the technical capability, we just have to wait and see how long it takes Apple to build and sell an iServ.

By: Tom Rhinelander, NRG Analyst

Installing WordPress on Mac OS X Tiger

montanaflynn — Mon, 18 Feb 2008 17:06:33 +0000

Of the many options out there, many people choose to run their own blogging software as opposed to a managed service like Blogger or TypePad. On the software side, there are many decent tools available, such as Six Apart’s Movable Type (we have a tutorial for installing MT as well). WordPress is another mature, capable and free blogging engine that is very popular with many bloggers (like its founding developer, Matt Mullenweg) and rapidly gaining in popularity across the Web. WordPress is an excellent choice for a personal or professional blog, and the price is right, too. This tutorial will show you how to install WordPress 1.5.1.3 on OS X 10.4 Tiger.

Note: The most recent version of WordPress is 1.5.1.3, which contains a security patch among other improvements. This tutorial is fully compatible with the most recent version of WordPress. Version 1.5.1.3 is recommended for all WordPress users (upgrade instructions).

If you have installed another blog engine such as WordPress or Movable Type already, you may already have MySQL and/or PHP configured. If this is the case, you can skip right down to step 4.

Before we get started, let’s summarize what we’ll be going over in the installation:

Downloading and Installing WordPress 1.5.1.3

If we’re going to blog our way to stardom, we’ll need some blogging software, right? The first step we’ll take will be to download the latest stable version of WordPress, version 1.5.1.3. The compressed file should be about 250KB, and OS X will decompress it for you.

Once it’s decompressed, we’ll move the wordpress directory to OS X’s Web hosting directory in /Library/WebServer/Documents. By default, all requests for the domain’s root directory (like http://maczealots.com/) will go to this directory. This can be changed in Apache’s httpd.conf file, which we’ll cover later. If you like, you can also change the name of the wordpress directory to something else, like blog. This way the URL of the blog would change to http://www.yoursite.com/blog/ Additionally, if you want the blog itself to be at the root directory, delete all the items from the /Library/WebServer/Documents directory and move the contents of the wordpress directory to the now-empty Documents folder.

Enabling Personal Web Sharing

“Personal Web Sharing” (PWS) is Apple’s marketing name for Apache, the industrial-strength, tried-and-true Web server du jour. When you enable PWS, OS X starts up Apache, registers the modules, opens ports, etc. Since we’ll be serving the blog, we’ll need to have Apache running.

To enable Personal Web Sharing, open the Sharing preference pane in System Preferences. Check the box labeled “Personal Web Sharing”, and that’s it. (You may have to authenticate as an administrator before it will let you enable anything.) Go ahead and close System Preferences; you’re ready to install MySQL now.

Note: We are working on a version of this tutorial that includes the ability to host the database with SQLite, which is prepackaged in OS X 10.4. However, support for SQLite in WordPress is still being fully developed, so for now MySQL is still the way to go. If you’d like to see such an article, let us know.

Downloading and Installing MySQL

MySQL is the database backend that WordPress (and other blogging packages like Movable Type) can use to store blog entries, users, comments, etc. MySQL is free for personal use. First, download MySQL (4.0.24 at the time of publication). It will come as disk image with two packages and a readme. We will be installing both packages. First, open the main MySQL installer. It will install all the necessary components to run MySQL onto your OS X volume. After that installer has completed, run the startup item installer, which will automatically start up MySQL after any computer restarts.

Note: One of the most common problems reported is that people install MySQL 4.1 instead of 4.0. I can understand the desire to be on the bleeding edge of software, but WordPress (and most other blog/CMS engines) use an older authentication scheme that is incompatible with MySQL 4.1 and greater. There are hacks and workarounds out there, but for the easiest installation, stick to MySQL 4.0.

Configuring MySQL

Now that you have installed MySQL, let’s configure it so WordPress can access it. Open a new terminal session (found in /Applications/Utilities/Terminal.app) and type the following commands to navigate, make some changes, and start the MySQL daemon:

cd /usr/local/mysql
sudo chown -R mysql data/
sudo echo
sudo ./bin/mysqld_safe &

Next, let’s launch MySQL and use the test database (called test, even) to make sure everything’s running correctly:

/usr/local/mysql/bin/mysql test

If everything’s running correctly, you should see output similar to this:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version 4.0.24-standard

Type 'help;' or '\h' for help.  Type '\c' to clear the buffer.

mysql>

Once you’ve verified that MySQL is running correctly, use the command quit to return to the console prompt.

Now that MySQL is running, we’ll change the root password of MySQL so that WordPress (and you) can access it later. Use this command (where yourpasswordhere is replaced by your chosen password):

/usr/local/mysql/bin/mysqladmin -u root password yourpasswordhere

The last thing we’ll have to do in MySQL is to create a table for WordPress to store its data. We’ll call it wordpress to keep things simple. To accomplish this, we’ll enter MySQL, create the table, and allow WordPress to edit it.

/usr/local/mysql/bin/mysql -u root -p
CREATE DATABASE wordpress;
quit

Enabling and Testing PHP

Now that MySQL is ready to go, let’s fire up PHP. OS X ships with PHP installed, but not activated. Fortunately, this is really easy to do. The only file we’ll need to edit is httpd.conf, which Apache uses for its configuration.

Open the config file in your favorite editor (I’ll be using pico):

sudo pico /etc/httpd/httpd.conf

Mosey on down to the Dynamic Shared Object (DSO) Support section. It’s the one with all the LoadModule listings. The one for PHP 4 is towards the bottom of that list. Look for the line and uncomment it to activate it. You can uncomment a line by removing the pound symbol (“#”) from the beginning of the line. The new line should look as such:

LoadModule php4_module

We’ll also need to uncomment the PHP 4 entry in the AddModule listings, so that it looks as such:

AddModule mod_php4.c

Once those two lines are edited you can save the httpd.conf file and quit the editor. Since we’ve edited Apache’s load setup, we need to restart Apache so it will recognize the changes:

sudo apachectl graceful

With that out of the way, let’s make sure that PHP is indeed running. Create a new text file in your favorite editor (stay away from RTF-happy TextEdit, though – SubEthaEdit gets my vote) and fill it with the following text:

Save the file as test.php in the root directory (/Library/WebServer/Documents/) and load the address of the page (usually http://localhost/test.php) into a Web browser. If PHP was correctly enabled, the phpinfo(); command should output page after page about the PHP installation. If not, retrace your steps – it can be easy to make a mistake.

Configuring WordPress

Now for the last step: configuring WordPress. First, you’ll need to edit WordPress’ default configuration file wp-config-sample.php. You’ll find it in the root folder of the WordPress installation. This is where you’ll set up the database information. Edit the following settings:

define('DB_NAME', 'wordpress'); – Change ‘wordpress‘ to the name of the database you created in MySQL (in the example we named it wordpress).
define('DB_USER', 'username'); – change ‘username‘ to root.
define('DB_PASSWORD', 'password'); – change ‘password‘ to the MySQL password you chose.

Once you’ve made the changes, save the file as wp-config.php in the same directory and delete wp-config-sample.php.

Now, open a Web browser window and start the WordPress installer, found at http://localhost/blog/wp-admin/install.php. (Remember that if you chose to install WordPress in a different directory, such as the root directory, the address will be different for you.) WordPress will take you through the install process and set up the database with all the tables it needs to run.

After it completes, it will give you the login (admin) and password to log in to WordPress. The password is randomly generated and not recoverable so please write it down!

After you log in, there are two things you need to immediately do. First, change your password to something you can remember. You can find it in the Users tab of WordPress’ controls. Also, to avoid posting entries as “Administrator”, you can either create another account with a posting name, or simply enter a nicknaame in the admin account. But whatever you do, change the password and remember it — once you lose it, your data is hard to get back.

Now comes the moment you’ve been waiting for. Click View site » in WordPress’ controls or open a Web browser and go to http://localhost/blog and watch your blog appear! Roll up your sleeves, perfect the CSS, and wax poetic, serving it to the free world without spending a dime on extra software. Happy blogging!

Installing Movable Type on Tiger

montanaflynn — Wed, 13 Feb 2008 18:09:19 +0000

One of the biggest phenomenons to hit the Internet in the past few years has been the personal weblog: blog for short. A blog is basically a Web site that allows its owner to post his thoughts, ideas and daily happenings. Some use it as a personal diary, some as a soapbox for their beliefs.

Note: This article is written for installing Movable Type on “Tiger” (Mac OS X 10.4.x). The Panther and older OS X versions of this article, have been relocated to their own seperate, permanent pages.

Many people host a weblog on a third-party web server hosted by someone else, but with MacOS X, we have the tools we need to set up a fully functional weblog on our system. This blog could be served to the entire world via the Internet, or just used as a personal diary on your own system. It doesn’t matter. Weblogs are what you make of them. There are several systems we could use to set up a weblog on our Mac, but for this article I have chosen Movable Type from Six Apart. I chose this solely because I have the most experience with it, as I have used it for almost four years on my personal Web site. Movable Type is designed using a Perl backend. Perl is an interpreted programming language that is capable of doing almost anything you wish. Tiger ships with Perl 5.8.6, which is more than enough for this process. The backend of our weblog will use SQLite. SQLite is the database system that is bundled with Mac OS X Tiger and powers the Core Data framework. Several major Mac applications use SQLite as well. A few examples are Freshly Squeezed Software’s PulpFiction and Michael Tsai’s SpamSieve. This article will assume that you are running a fresh install of MacOS X 10.4 or later and have the MacOS X Developer Tools installed. You should also be comfortable working in the command line and editing system configuration files. If this scares you, you may want to sign up for a service such as Six Apart’s TypePad. Let’s get started… ### Downloads First let’s download all of the files you are going to need to complete this exercise. We are only going to need DBI, DBD::SQLite and Movable Type 3.16. DBD::SQLite is a Perl module that will interface between SQLite and Movable Type. DBI stands for Database Interface and was written by Tim Bunce. The DBI module then speaks to the DBD module. The DBD module we will be using is DBD::SQLite. The biggest advantage of DBI is that you can talk to the database without having to talk on the network to the actual database server or dealing with the server’s libraries. Movable Type is simply a collection of Perl scripts that run the entire weblog system. * Movable Type * DBI * DBD::SQLite ### Apache In terminal, we need to edit our Apache config file. We are basically going to allow for cgi scripts to be executed on the Mac. By default CGI Scripts are located in /Library/WebServer/CGI-Executables/. We need to uncomment the line in the httpd.conf file that reads # AddHandler cgi-script .cgi I am going to explain how to do it using the vi text editor, but you are more than welcome to use your favorite editor of choice.

sudo vi /etc/httpd/httpd.conf Go down to the line we want to edit and remove the # in front of _AddHandler_ by pressing the x key. Next type in _:wq_ to write and quit vi. Next, type the following into the Terminal window: sudo apachectl graceful The last command simply restarts the apache server without having to restart your system. Oh, the power of Unix. ### Connecting to SQLite Before we can establish a connection between Movable Type and SQLite, we need to install the Perl modules we downloaded earlier. Double-click on each file to extract the folders that live inside. We need to compile these modules so that our database will show up when we test Movable Type. It’s a relatively simple process. Type the following commands in the Terminal: cd ~/Desktop/DBI-1.48 perl Makefile.PL make sudo make install Now we need to install the SQLite module. cd ~/Desktop/DBD-SQLite-1.08 perl Makefile.PL make sudo make install Now that we have our perl modules set up, we can celebrate. We are finally ready to set up Movable Type! ### Movable Type cd ~/Desktop/MT-3.16-full-en_US/ vi mt.cfg Place a # before DataSource ./db Set your CGIPath to equal _http://localhost/cgi-bin/_ Add the following lines to your file. ObjectDriver DBI::sqlite Database /Library/WebServer/CGI-Executables/db/mtdbmovabletype.sql Set StaticWebPath to _/mt-static/_ Remove the # before _NoTempFiles 1_ :wq Ok, that is a lot of steps, so let’s go through what each one of them is. mt.cfg is the configuration file that gives basic information for the perl backend about your weblog. We set the CGIPath to equal where we are putting the cgi files. On your local system, it is /Library/WebServer/CGI-Executables/. StaticWebPath is where Movable Type’s images, docs, and other similar files will be stored. We set that to http://localhost/mt-static/ so that the directories are housed in /Library/WebServer/Documents/mt-static/. It should be noted that if you are going to set up your blog to be available for people on the Internet, you should replace all instances of localhost with your external IP address or domain name. The next set of commands is basically telling Movable Type to use the SQLite database. Now you see why we had to set up the DBI and DBD stuff earlier. We turned off NoTempFiles because Tiger was having issues when trying to build the index files. If anyone can find a solution to the problem, please post it in the comments. Let’s jump to the Finder. Yes, I am serious. After all of the love we have been giving the command line we are going back to the good old graphical filesystem. We need to install the Movable Type application onto our Webserver. First, lets copy the static files to the /Library/WebServer/Documents/mt-static/ folder. Make sure to copy the following files to that directory.

styles.css
mt.js
images
docs
index.html

Also, go ahead and create a new folder and call it _archives_. This is where we will hold all of our blog entries.

Now, let’s move back a level and enter the CGI-Executables folder. Copy the following files into it.

examples
extlib
lib
mt-add-notify.cgi
mt-atom.cgi
mt-check.cgi
mt-comments.cgi
mt-db-pass.cgi
mt-load.cgi
mt-search.cgi
mt-send-entry.cgi
mt-set-reg.cgi
mt-tb.cgi
mt-view.cgi
mt-testbg.cgi
mt-xmlrpc.cgi
mt.cfg
mt.cgi
php
plugins
schemas
search_templates
tmpl
tools

We are almost done. Now we need to jump back into Terminal and set some permissions for our scripts and create a folder for our database. cd /Library/WebServer/CGI-Executables/ chmod 755 mt*.cgi mkdir db chmod 777 db cd .. sudo chmod 777 Documents cd Documents chmod 777 archives What we just did is set the cgi scripts to be read and executed by group and others, while you can read, write and execute. If you don’t understand what that means, it is simply a Unix permissions thing. We then created a db folder that will house our SQLite databse. The last two commands set read, write, and execute commands for the archives and Documents folder. I ran into a lot of permissions issues by trying to lock the Documents folder with 755. The archives folder must be 777 though. If you want a more secure set up, I would recommend you recompile Apache with suexec installed. Sadly, Tiger’s version of Apache doesn’t have it compiled in. Everything is set up, let’s test. Pop open Safari and go to the following url. http://localhost/cgi-bin/mt-check.cgimt-check checks for installed perl modules on your system. You should have everything you need installed. If you find you are missing some of the modules, or want to install extra ones, Six Apart does a great job of giving you a walkthrough. This is important…. http://localhost/cgi-bin/mt-load.cgi This step sets up the tables, an initial author and some starter templates in your database. Assuming you have followed my instructions to their exact specifications, the script should report SUCCESS! You have a working Movable Type installation. With Movable Type 3.16, the application has the ability to run several tasks in the background. We need to test to make sure this will work on your system so click on the link below to do that: http://localhost/cgi-bin/mt-testbg.cgi As long as you see two unique numbers listed on the page, you will be fine. Delete mt-load.cgi from /Library/WebServer/CGI-Executables. Leaving it on your system is a big security vulnerability, because each time you run it, it is going to reset your database to the initial values. Congratulations, Movable Type is ready to go. ### Basic Configuration http://localhost/cgi-bin/mt.cgi

Now that we have the weblog configured, let’s go through some basic configuration. The link above is where you will do all of your blogging. It houses the configuration, templates and a basic editor. You will be greeted with a login prompt. The mt-load.cgi script created a default user name Melody and a password of Nelson. The first thing you are going to want to do is change that username and password. To accomplish this, just head to the Edit Your Profile link. Change the username and password to something you can easily remember. Next, let’s edit the default weblog to fit your specifications. The default is creatively named Weblog, but you may want to change that to something to describe you. I have my personal one as just my name, but others have been far more creative.
Next, go to the Weblog Config button and let’s double check some values.

Local Site Path: /Library/WebServer/Documents
Site URL: http://localhost/
Local Archive Path: /Library/WebServer/Documents/archives
Archive URL: http://localhost/archives/

Save those changes, and start blogging, because you are ready. Simply go to the New Entry button and make your first entry. To view your content simply pop open Safari and visit http://localhost/### Conclusion We accomplished a lot. We set up a full-fledged content management system on our Mac using nothing but free or donationware software. This article merely gets you set up with a basic Movable Type installation. There is a vast world of plugins, configuration changes, and tips and tricks out there. Here are a few resources to check out.

Leopard Server: Using ACLs with Open Directory

montanaflynn — Thu, 07 Feb 2008 17:21:27 +0000

In Leopard, Workgroup Manager supports rudimentary ACLs for the LDAP database. We’re all familiar with Access Control Lists by now. Especially in the Mac OS X Server community. However, we might not all be familiar with ACLs as they’re implemented in LDAP. But we should be, because LDAP is being used more and more as an address book, and with the new Directory application being shipped in Leopard it is conceivable that environments aren’t just going to use ACLs to secure LDAP but they’re also going to use them to allow users to self update their information in the directory. So in the interest of security and making the most out of the technologies build into LDAP, let’s cover LDAP ACLs for a bit. So to push beyond what you can do in Workgroup Manager, let’s take a look at building out more finely grained ACLs manually.

First, like with most things in LDAP ACLs are configured using the /etc/openldap/slapd.conf file. Below is the pertinent portion of this file that we will be looking at:

# Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING!
Now, if we remove the commented out portions of the file or add more lines we can start to limit who has access to read and/or change what information in the LDAP database. Keep in mind that you always want to back up your slapd.conf file prior to doing so.

You can control access to each element in the database. Each ACL has an “access to” which is the elements in the LDAP database that you are granting or denying access for and then a “by” portion that lists who can do what to that portion of the database. An entire ACL can be listed on one line, as is done with policies that have only one user or group associated to them. For example, the following line gives anyone and everyone read access to the database:
access to dn.base=”” by * read

For ease of use and reviewing, we typically put the “access to” on one line and the subsequent users or groups with access in their own “by” lines for more complicated ACL rule sets. Slapd parses the file in such a way that it realizes that “access to” means the beginning of a new ACL. The following is an example of some more complicated ACLs:
access to attrs=userPassword by dn="cn=users,dc=318,dc=com" write by self write by * compare

access to *
by dn=”cn=computers,dc=318,dc=com” write
by users read
by * auth

Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. In the above example, a user is able to write to their own userPassword record. This means that the user is also able to auth, compare, search and read that record.

ACLs are prosessed from top to bottom. This makes it important to put specific ACLs and by statements above more general ones. ACLs that restrict access to the userPassword attribute, followed by one applicable to *, that is, the entire LDAP database. In the above example, placing the userPassword ACL first causes the rule that allows users to change their own passwords to process before the wildcard that specifies everyone. When a * is used as a wildcard in the access to line of slapd.conf it means the entire database or tree of the LDAP database. When the * is used in the by line it typically denotes all users.

Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. These two points, the first match wins rule and the inclusive nature of access levels, are crucial to understanding how ACLs are parsed. They also are important for making sure your ACLs don’t lead to either greater or lesser levels of access than you intend in a given situation.

It can be time consuming to go through every possible attribute by group and determine who has access to what. However, if you want to have users updating their own addresses, phone numbers, and other information, as can be done with the Directory application, this is often one way to accomplish this goal. You could also provide help desk users the ability to update the database using the Directory application but not allow them to access other records in the LDAP database, such as group memberships. Having a very granular ACL environment for records can also allow you to obtain a maximum level of security.

This can also be put into the schema in order to force replication between hosts. Keep an eye out for that article at a later date.

For what it’s worth, at 318 we’ve found that commenting out each ACL helps us to keep track of who did what, why and what they were thinking when they did it. Happy OD everyone!!!