Tiny Deathstars of Foulness

Merry Christmas ya’ll!

On the first day of Christmas my true love gave to me one 32 gig iPad

On the second day of Christmas my true love gave to me two bash one-liners

On the third day of Christmas my true love gave to me three Red Hat servers

On the fourth day of Christmas my true love gave to me four email blasts

On the fifth day of Christmas my true love gave to me five retweets

On the sixth day of Christmas my true love gave to me six regular expressions

On the seventh day of Christmas my true love gave to me seven lines of perl

On the eighth day of Christmas my true love gave to me eight app store apps

On the ninth day of Christmas my true love gave to me nine AWS instances

On the tenth day of Christmas my true love gave to me ten Active Directory forests

On the eleventh day of Christmas my true love gave to me 11 crappy python scripts

On the twelfth day of Christmas my true love gave to me 12 craft brews


December 25th, 2014

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , , , ,

Configuring web services is as easy in OS X Mountain Lion Server (10.8) as it has ever been. To set up the default web portal, simply open the Server app, click on the Websites service and click on the ON button.

After a time, the service will start. Once running, click on the View Server Website link at the bottom of the pane.

Provided the stock OS X Server page loads, you are ready to use OS X Server as a web server.

Before we setup custom sites, there are a few things you should know. The first is, the server is no longer really designed to remove the default website. So if you remove the site, your server will exhibit inconsistent behavior. Also, don’t remove the files that comprise the default site. Instead just add sites, which is covered next. Webmail is gone. You don’t have to spend a ton of time looking for it as it isn’t there. Also, Mountain Lion Server adds web apps, which we’ll briefly review later in this article as well.  Finally, enabling PHP and Python on sites is done globally, so this setting applies to all sites hosted on the server.

Now that we’ve got that out of the way, let’s add our first custom site. Do so by clicking on the plus sign. At the New Web Site pane, you’ll be prompted for a number of options. The most important is the name of the site, with other options including the following:

  • Domain Name: The name the site is accessible from. The default sites do not have this option as they are accessible from all names that resolve to the server.
  • IP Address: The IP address the site listens on. Any means the site is available from every IP address the server is configured to use. The default websites do not have this option as they are accessible from all addresses automatically
  • Port: By default, sites without SSL run on port 80 on all network interfaces, and sites with SSL run on port 443 on all network interfaces. Use the Port field to use custom ports (e.g., 8080). The default sites do not have this option as they are configured to use 80 and 443 for default and SSL-based communications respectively.
  • SSL Certificate: Loads a list of SSL certificates installed using Keychain or the SSL Certificate option in the Settings pane of the Server application
  • Store Site Files In: The directory that the files that comprise the website are stored in. These can be placed into the correct directory using file shares or copying using the Finder. Click on the drop-down menu and then select Other to browse to the directory files are stored in.
  • Who Can Access: By default Anyone (all users, including unauthenticated guests) can access the contents of sites. Clicking on Anyone and then Customize… brings up the “Restrict access to the following folders to a chosen group” screen, where you can choose web directories and then define groups of users who can access the contents.
  • Additional Domains: Click on the Edit… button to bring up a simple list of domain names the the site also responds for (e.g. in addition to, add
  • Redirects: Click on the Edit… button to bring up a list of redirects within the site. This allows configuring redirects to other sites. For example, use /en to load or /cn to load
  • Aliases: Click on the Edit… button to load a list of aliases. This allows configuring redirects to folders within the same server. For example, /en loads /Library/Server/Web/Data/Sites/Default
  • Index Files: Click on the Edit… button to bring up a list of pages that are loaded when a page isn’t directly indicated. For example, when visiting, load the wp.php page by default.
  • Advanced Options: The remaining options are available by clicking on the “Edit Advanced Settings…” button.
  • Enable Server Side Includes: Allows administrators to configure leveraging includes in web files, so that pieces of code can be used across multiple pages in sites.
  • Allow overrides using .htaccess files: Using a .htaccess file allows administrators to define who is able to access a given directory, defining custom user names and passwords in the hidden .htaccess file. These aren’t usually required in an OS X Server web environment as local and directory-based accounts can be used for such operations. This setting enables using custom .htaccess files instead of relying on Apple’s stock web permissions.
  • Allow folder listing: Enables folder listings on directories of a site that don’t have an Index File (described in the non-Advanced settings earlier).
  • Allow CGI execution: Enables CGI scripts for the domain being configured.
  • Use custom error page: Allows administrators to define custom error pages, such as those annoying 404 error pages that load when a page can’t be found
  • Make these web apps available on this website: A somewhat advanced setting, loads items into the webapps array, which can be viewed using the following command:  sudo serveradmin settings web:definedWebApps

Once you’ve configured all the appropriate options, click on Done to save your changes. The site should then load. Sites are then listed in the list of Websites.

The Apache service is most easily managed from the Server app, but there are too many options in Apache to really be able to put into a holistic graphical interface. The easiest way to manage the Websites service in OS X Mountain Lion server is using the serveradmin command. Apache administrators from other platforms will be tempted to use the apachectl command to restart the Websites service. Instead, use the serveradmin command to do so. To start the service:

sudo serveradmin start web

To stop the service(s):

sudo serveradmin stop web

And to see the status:

sudo serveradmin fullstatus web

Fullstatus returns the following information:

web:health = _empty_dictionary
web:readWriteSettingsVersion = 1
web:apacheVersion = "2.2"
web:servicePortsRestrictionInfo = _empty_array
web:startedTime = "2012-08-13 23:01:42 +0000"
web:apacheState = "RUNNING"
web:statusMessage = ""
web:ApacheMode = 2
web:servicePortsAreRestricted = "NO"
web:state = "RUNNING"
web:setStateVersion = 1

While the health option typically resembles kiosk computers in the Computer Science departments of most major universities, much of the rest of the output can be pretty helpful including the Apache version, whether the service is running, any restrictions on ports and the date/time stamp that the service was started.

To see all of the settings available to the serveradmin command, run it, followed by settings and then web, to indicate the Websites service:

sudo serveradmin settings web

The output is pretty verbose and can be considered in two sections, the first includes global settings across sites as well as the information for the default sites that should not be deleted:

web:defaultSite:documentRoot = "/Library/Server/Web/Data/Sites/Default"
web:defaultSite:serverName = ""
web:defaultSite:realms = _empty_dictionary
web:defaultSite:redirects = _empty_array
web:defaultSite:enableServerSideIncludes = no
web:defaultSite:customLogPath = ""/var/log/apache2/access_log""
web:defaultSite:webApps = _empty_array
web:defaultSite:sslCertificateIdentifier = ""
web:defaultSite:fullSiteRedirectToOtherSite = ""
web:defaultSite:allowFolderListing = no
web:defaultSite:serverAliases = _empty_array
web:defaultSite:errorLogPath = ""/var/log/apache2/error_log""
web:defaultSite:fileName = "/Library/Server/Web/Config/apache2/sites/0000_any_80_.conf"
web:defaultSite:aliases = _empty_array
web:defaultSite:directoryIndexes:_array_index:0 = "index.html"
web:defaultSite:directoryIndexes:_array_index:1 = "index.php"
web:defaultSite:directoryIndexes:_array_index:2 = "/wiki/"
web:defaultSite:directoryIndexes:_array_index:3 = "default.html"
web:defaultSite:allowAllOverrides = no
web:defaultSite:identifier = "37502141"
web:defaultSite:port = 80
web:defaultSite:allowCGIExecution = no
web:defaultSite:serverAddress = "*"
web:defaultSite:requiresSSL = no
web:defaultSite:proxies = _empty_dictionary
web:defaultSite:errorDocuments = _empty_dictionary
web:defaultSecureSite:documentRoot = "/Library/Server/Web/Data/Sites/Default"
web:defaultSecureSite:serverName = ""
web:defaultSecureSite:realms = _empty_dictionary
web:defaultSecureSite:redirects = _empty_array
web:defaultSecureSite:enableServerSideIncludes = no
web:defaultSecureSite:customLogPath = ""/var/log/apache2/access_log""
web:defaultSecureSite:webApps = _empty_array
web:defaultSecureSite:sslCertificateIdentifier = ""
web:defaultSecureSite:fullSiteRedirectToOtherSite = ""
web:defaultSecureSite:allowFolderListing = no
web:defaultSecureSite:serverAliases = _empty_array
web:defaultSecureSite:errorLogPath = ""/var/log/apache2/error_log""
web:defaultSecureSite:fileName = "/Library/Server/Web/Config/apache2/sites/0000_any_443_.conf"
web:defaultSecureSite:aliases = _empty_array
web:defaultSecureSite:directoryIndexes:_array_index:0 = "index.html"
web:defaultSecureSite:directoryIndexes:_array_index:1 = "index.php"
web:defaultSecureSite:directoryIndexes:_array_index:2 = "/wiki/"
web:defaultSecureSite:directoryIndexes:_array_index:3 = "default.html"
web:defaultSecureSite:allowAllOverrides = no
web:defaultSecureSite:identifier = "37502140"
web:defaultSecureSite:port = 443
web:defaultSecureSite:allowCGIExecution = no
web:defaultSecureSite:serverAddress = "*"
web:defaultSecureSite:requiresSSL = yes
web:defaultSecureSite:proxies = _empty_dictionary
web:defaultSecureSite:errorDocuments = _empty_dictionary
web:dataLocation = "/Library/Server/Web/Data"
web:mainHost:keepAliveTimeout = 15.000000
web:mainHost:maxClients = "50%"

The second section is per-site settings, with an array entry for each site:

web:customSites:_array_index:0:documentRoot = "/Library/Server/Web/Data/Sites/"
web:customSites:_array_index:0:serverName = ""
web:customSites:_array_index:0:realms = _empty_dictionary
web:customSites:_array_index:0:redirects = _empty_array
web:customSites:_array_index:0:enableServerSideIncludes = no
web:customSites:_array_index:0:customLogPath = "/var/log/apache2/access_log"
web:customSites:_array_index:0:webApps = _empty_array
web:customSites:_array_index:0:sslCertificateIdentifier = ""
web:customSites:_array_index:0:fullSiteRedirectToOtherSite = ""
web:customSites:_array_index:0:allowFolderListing = no
web:customSites:_array_index:0:serverAliases = _empty_array
web:customSites:_array_index:0:errorLogPath = "/var/log/apache2/error_log"
web:customSites:_array_index:0:fileName = "/Library/Server/Web/Config/apache2/sites/"
web:customSites:_array_index:0:aliases = _empty_array
web:customSites:_array_index:0:directoryIndexes:_array_index:0 = "index.html"
web:customSites:_array_index:0:directoryIndexes:_array_index:1 = "index.php"
web:customSites:_array_index:0:directoryIndexes:_array_index:2 = "/wiki/"
web:customSites:_array_index:0:directoryIndexes:_array_index:3 = "default.html"
web:customSites:_array_index:0:allowAllOverrides = no
web:customSites:_array_index:0:identifier = "41179886"
web:customSites:_array_index:0:port = 80
web:customSites:_array_index:0:allowCGIExecution = no
web:customSites:_array_index:0:serverAddress = "*"
web:customSites:_array_index:0:requiresSSL = no
web:customSites:_array_index:0:proxies = _empty_dictionary
web:customSites:_array_index:0:errorDocuments = _empty_dictionary

The final section (the largest by far) includes array entries for each defined web app. The following shows the entry for a Hello World Python app:

web:definedWebApps:_array_index:15:requiredWebAppNames = _empty_array
web:definedWebApps:_array_index:15:includeFiles:_array_index:0 = "/Library/Server/Web/Config/apache2/httpd_wsgi.conf"
web:definedWebApps:_array_index:15:requiredModuleNames:_array_index:0 = "wsgi_module"
web:definedWebApps:_array_index:15:startCommand = ""
web:definedWebApps:_array_index:15:sslPolicy = 0
web:definedWebApps:_array_index:15:requiresSSL = no
web:definedWebApps:_array_index:15:requiredByWebAppNames = _empty_array
web:definedWebApps:_array_index:15:launchKeys = _empty_array
web:definedWebApps:_array_index:15:proxies = _empty_dictionary
web:definedWebApps:_array_index:15:preflightCommand = ""
web:definedWebApps:_array_index:15:stopCommand = ""
web:definedWebApps:_array_index:15:name = ""
web:definedWebApps:_array_index:15:displayName = "Python "Hello World" app at /wsgi"

Each site has its own configuration file defined in the array for each section. By default these are stored in the /Library/Server/Web/Config/apache2/sites directory, with /Library/Server/Web/Config/apache2/sites/ being the file for the custom site we created previously. As you can see, many of the options available in the Server app are also available in these files:

<VirtualHost *:80>
DocumentRoot "/Library/Server/Web/Data/Sites/"
DirectoryIndex index.html index.php /wiki/ default.html
CustomLog /var/log/apache2/access_log combinedvhost
ErrorLog /var/log/apache2/error_log

<IfModule mod_ssl.c>
SSLEngine Off
SSLProtocol -ALL +SSLv3 +TLSv1
SSLProxyEngine On
SSLProxyProtocol -ALL +SSLv3 +TLSv1

<Directory "/Library/Server/Web/Data/Sites/">
Options All -Indexes -ExecCGI -Includes +MultiViews
AllowOverride None
<IfModule mod_dav.c>
Deny from all
ErrorDocument 403 /customerror/websitesoff403.html


The serveradmin command can also be used to run commands. For example, to reset the service to factory defaults, delete the configuration files for each site and then run the following command:

sudo serveradmin command web:command=restoreFactorySettings

The final tip I’m going to give in this article is when to make changes with each app. I strongly recommend making all of your changes in the Server app when possible. When it isn’t, use serveradmin and when you can’t make changes in serveradmin, only then alter the configuration files that come with the operating system by default. I also recommend keeping backups of all configuration files that are altered and a log of what was altered in each, in order to help piece the server back together should it become unconfigured miraculously when a softwareupdate -all is run next.

August 15th, 2012

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

I’ve had a pretty easy time using Nikto over the years. Nikto is a security scanner specific to web servers. I did a post on Nessus recently, but Nessus is a tool for looking at any service running on a system and trying to find available vulnerabilities. Nikto is can do many of the same things, but is specific and therefore more in depth for web servers. This involves looking at things like CGI directories and robots.txt files as well.

Nikto is written in Perl. In order to do everything Nikto can do there are a few perl mules that need to be installed. But let’s look at one of the easiest implementations available for Nikto, which is Yang (short for Yet Another Nikto GUI), available on the OS X App Store. Yang is so easy, you can literally install the app, type a domain name and hit Start to get started. Yang also runs the latest release of Nikto. Let’s look at what a basic scanning process looks like. To get started, open the App Store and search for Nikto. Yang appears, so click on Install by the name of the app.

Once installed, click on Yang in LaunchPad to fire up the scanner (or open from /Applications). When Yang opens, click on the Preferences in the toolbar. Go through each of the options and choose the ones that make the most sense for each scan you run. Keep in mind that each box can increase or decrease the amount of time scans require or the output of the scan drastically. The author of the app was kind enough to include tool tips for the options, very helpful.

Click back on the Scan icon in the toolbar and enter the name of the site to scan in the “Website to analyze” field. Then click on Launch.

The scan then begins. This might take some time. And not “go get some coffee time” but more like, “go take a nap time.” While the scan is running, click on Logs in the toolbar. Here, you can see the exact command run against Nikto.

If you download Nikto from you can use these exact commands, although there will be a little work getting the app up and running, defining config files, etc. If you want to do anything (such as writing output to metasploit) then you might end up needing to go ahead and install manually. But if you’re just interested in running some quick scans as sanity checks for deployed configurations, etc then this is a nice little tool that is a bit too nice to be free. Especially given that the author went ahead and built out Nikto with LibWhiskers, SSL support and a few other goodies that aren’t required for a basic deployment. It’s also (IMHO) a really good example of putting a GUI wrapper around command line tools. I’ve played with a few other GUI overlays for Nikto and this one is by far the best one I’ve seen for OS X. Well worth the time to check it out!

July 5th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, sites, WordPress

Tags: , , , , , , , , , ,


Open and paste the following in there:

print "Hello Cruel Perln";

Make sure you have executable permissions for Then run:


February 29th, 2012

Posted In: Mac OS X, Unix

Tags: , , , , , ,

There are a lot of versions of the popular perl scripting language out there, and depending on what version you may have written a script with you might find that using a different version than the one that comes with an OS by default can have a drastic impact on a script. In Mac OS X you can change the default version of perl that the perl and a2p command will use. Before doing so you should check the version of perl being used by default, which can be done using the perl command, followed by the -v option:

perl -v

By default, the OS currently uses version 5.10.0. To change the version, you would use the defaults command to change the defaults domain. You will add a key called Version with a string of the version you would like to use. For example, to switch to 5.8.8:

defaults write Version -string 5.8.8

To change it back to 5.10.0:

defaults write Version -string 5.10.0

You can also set perl to run in 32 bit mode:

defaults write Prefer-32-Bit -boolean TRUE

To put it back:

defaults write Prefer-32-Bit -boolean FALSE

Python provides the same functionality:

defaults write Version -string 2.6

Or to run Python in 32-bit mode:

defaults write Prefer-32-Bit -boolean TRUE

June 8th, 2010

Posted In: Mac OS X

Tags: , , , , , ,

Sometimes ya’ just need to run Perl in 32-bit. Regrettably. To do so:

defaults write Prefer-32-Bit -bool yes

December 10th, 2009

Posted In: Mac OS X

Tags: , ,

Getting through all of the dependencies for certain Perl modules can be hairy. To give you a sense of how complex perl can be, here’s a small fact: CPAN has over nine thousand perl modules listed. Keeping track of module dependencies can be a real pain. Fortunately, there’s a simple solution… is a PERL module that automates the whole process of downloading, unpacking, compiling and packaging modules. For example, if I wanted to install a module called Colors::Yellow, I would type:

perl -MCPAN -e ‘install Colors::Yellow’

That’s it. The would automatically figure dependancies, download the appropriate modules, and install them. If you want more information on using the (pm is short for perl module) then the URL is, under “How do I install Perl modules?”

April 20th, 2009

Posted In: Mac OS X, Mac OS X Server, Unix

Tags: , , ,

Little dittie on installing GD in Mac OS X Server:

August 10th, 2008

Posted In: Mac OS X Server

Tags: , ,

This Perl Module will allow you to call Objective-C code from within Perl.  Use this command to read the docs on it:

perldoc PerlObjCBridge

August 8th, 2008

Posted In: Mac OS X

Tags: ,

I originally posted this at

1. Enable MySQL.
2. Create a database in MySQL called joomladb.
3. Create a new user called jadmin that has full priviledges to this database (the user does not need to be called jadmin, but that is the username we will be using for this walkthrough).
4. Download the latest stable release of Joomla.
5. Extract the tar files into a new folder (for this example we are going to call it joomla to keep things easy).
6. Make the following folders writeable for Joomla
7. Move the joomla folder onto a web server.
8. From your web server, visit the site or the subfolder that you placed the joomla files into.
9. Make sure PHP is enabled for the domain and globally.
10. At the Joomla Pre-Installation check page, you will either see a notice that you can install Joomla or a notice that your system does not meet the minimum requirements for installion. If your system does not meet the requirements, install the modules that are listed in Red, or make Joomla work and click on the Check Again button. Once the dependencies are all installed click Next.
11. Read the license agreement and click on Next.
12. Fill in the appropriate fields for your MySQL environment and click Next >>. The fields that are used:
a. Host Name: If the server you are currently using is a MySQL server then enter localhost. Otherwise enter the name or IP of your MySQL server.
b. MySQL User Name: Either enter the root User Name for your MySQL server or another username if desired.
c. MySQL User Name: Either enter the root password for your MySQL server or the password for another user if desired.
d. MySQL Database Name: The name of the database on the MySQL server you would like the Joomla files saved to. In our example, we will use joomladb.
13. Enter the name you would like to use for your Joomla site. This will be the name users will see when logging into your Joomla site and click on the Next button.
14. At the next screen you will be asked to enter some site specific information and then click Next.
a. URL: Enter the URL that users will use to access your site.
b. Path: Enter the full path to the Joomla directory on your server.
c. Email: This will be used for administrative logins.
d. Admin password: This will be the administrative password used to access your Joomla site.
15. cd into the Joomla directory and remove the directory called installation.
16. Click on the View Site button. If you see the Default Joomla site then you are almost done.
17. Go back to the previous screen and click on the Administration button.
18. Enter admin as your username and the administrative password you gave Joomla in field 14.d.
19. You now have Joomla configured and are now ready to customize it.

July 14th, 2006

Posted In: Mac OS X Server, sites, Social Networking

Tags: , , , , ,

Next Page »