Andrew Fore

Due to a problem with the grid-cluster at MediaTemple, the site was down for well over a day.  They still don’t have everything up and running 100% yet, so their are at least two posts that are missing images.

Hopefully they will get everything finished today.  According to the latest update on the status entry for Incident 754, they have approximately 155 sites to restore out of the almost 2500 that were hosted on gs cluster 2.  Fortunately this didn not affect the database cluster, so none of my actually posts, pages or comments were lost.

The affected content at the moment is:

I just got finished reading Stealing MySpace by Julia Angwin.  In it there was this great conversation about the firing of Ross Levinshohn by Peter Chernin, the soon-to-be former COO of News Corps.  Here it is:

“You’re not happy, are you?” Chernin said. “No, I’m not,” Levinsohn agreed. “This isn’t working out, is it?” Chernin said. “No, it’s not,” Levinsohn replied. “We should probably part ways,” Chernin said.

“Yes,” Levinsohn replied.

Today I picked up one of the new dual-band AirPort Extreme base stations at Best Buy. The reason behind the purchase was so that I could use 802.11n for my iMac and Apple TV while using 802.11g for my iPhone, since this should give me the best wireless throughput for my shared files to the Apple TV.

After getting the DHCP, PPPoE, WiFi and network security configured to mimic the settings of the Linksys router that I replaced, I thought I was through, but then I realized that I still needed to configure an ACL to implement MAC filtering. For those who don’t know, a MAC filter on a typical router lets the admin control which devices will be allowed to talk to the router.

While there are some people who say that having both WPA2 encyrption as well as MAC filtering is unnecessary, I decided that I wanted to do both, since I am allowing the SSID to be broadcast for the convenience of visitors.

On my last two Linksys routers (a WRT54G and a WRT160N) this was simply a matter of checking a box and entering the allowed MAC addresses into a table. On the AEBS it require a little more work.

Necessary items

• an Apple AirPort Extreme base station that is properly configured for your network
• AirPort Utility
• a list of the MAC addresses for the allowed devices

Step 1

Open AirPort Utility. On the main screen, double-click on the connected AEBS listed in the column on the left side of the window.

Main screen for AirPort Utility

Step 2

In the configuration screen that comes up, click on the Access options.

Airport utility access configuration screen defaults

Step 3

Change the default setting for MAC Address Access Control from the default to say Timed Access.

Airport utility access configuration set to Timed Access

Step 4

In the configuration pane click on the default entry, then click the Edit button. This will bring up the Timed Access Control Setup Assistant window.

In the Timed Access Control Setup Assistant window click in the drop down menu that currently reads Everday and select No Access from the list. This will make sure that any computer or device with a MAC address that is not in the list will be denied access to your network. Then click the Done button to save your changes.

Timed Access Control Setup Assistant for default rule

Step 5

Back in the access configuration screen, click on the plus sign in the left below the list of devices. This will bring up the Timed Access Control Setup Assistant window that allows you to add new devices.

In the MAC Address field you will need to enter the MAC address (aka ethernet address, hardware address, ethernet id, etc.) for your device. (Hint: If you are doing this for the computer you are currently using just click the This Computer button.) If you want, you can add a description for each device as well. I use the devices hostname when appropriate.

Then change the time frame that the device is allowed to connect if you need to restrict it to something other than the default of Everday/all day.

When you are finished just click the Done button to save your changes. Repeat this step for each device.

Timed Access Control Setup Assistant add device dialog

Step 6

After adding all your devices you should have a screen that looks similar to the below. (Note: I have obscured my MAC addresses to protect the innocent.)

Airport access configuration screen completed

Step 7

If you have added all your devices and you are sure you are finished, just click the Update button. This will save your configuration changes and restart the AEBS.

Final Notes

Understand that like the Linksys MAC filter, this only affects devices that are connecting over the wireless network. This is useful since it gives you an avenue for fixing any problems that you have run into. Also, if you run into a problem so extreme (pardon the pun) that you need to perform a hardware reset of the AEBS, follow the instructions in the Apple knowledgebase article Resetting the AirPort Extreme Base Station (Article No. HT1406).

During the migration of a production system from Solaris 10 to RedHat Enterprise Linux 5, I discovered that I had a problem with a couple of my LDAP scripts.  The commands being run were standard ldapsearch and ldapmodify commands in a format similar to the following:

ldapsearch -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password cn=foobar

ldapmodify -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password -f updates.ldif

Each time I ran the commands I got the following error:

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available:

It turns out that the versions of the ldapsearch and ldapmodify commands that comes with RHEL5 are based on the standard OpenLDAP code.  The OpenLDAP code defaults to expecting an SASL authentication mechansim on the server-side.  Given that the LDAP server I am connecting to is a iPlanet 5.1 LDAP server, it is not configured to understand the SASL authentication types.

The solution is to add the -x option to the commands:

ldapsearch -x -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password cn=foobar

ldapmodiy -x -h hostname.domain.com -p 389 -b o=organisation -D cn=admin -w password -f updates.ldif

This command option specifies that the command should be executed using simple authentication instead of SASL.

Image Credit: Ohio State University

Yesterday in my post on Solaris 10 Password Policy Enforcement, I outlined the steps necessary to implement the password requirements that have been decided upon in my system environment.  This post will outline the same process on the RHEL5 systems that I admin.  While the policy requirements are the same, the implementation is vastly different.

Desired Policy

To re-cap, here is the policy that is to be applied to normal users:

• at least 8 characters in length
• no more than 20 characters in length
• contain at least on letter
• contain at least one number
• forced to change at least every 180 days
• 15 minute lockout after 5 unsuccessful attempts

Implementation Differences with Solaris 10

While there were a couple of pieces of the desired password policy that I was unable to implement on Solaris 10, the ease of which the others were configured wins the game hands down.  The PAM module setup on Solaris makes it dead simple to update the policy.  All you have to do is to change the various tunable settings.  And they are all listed in fairly understandable verbiage, no complex or arcane settings.

On the RHEL5 systems I had to delve into the vagaries of PAM module attributes and ordering.  As always, it is important to make backups of any files to protect yourself and allow for disaster recovery. To implement the requirements, I had to edit two files on the system:

1. /etc/login.defs
2. /etc/pam.d/system-auth

Implementation Process

It is important during this process to recognize that if you set the PAM requirements incorrectly you can get burned to the point that the root user will be unable to login, forcing you to boot into single-user mode to recover or to boot the system from a live cd and revert the authentication files.

Setting the password expiration requirement and length setting

Before we get into this please note the warning notice from the login.defs file manpage on a RHEL5 system

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Pleaserefer to the corresponding PAM configuration files instead.

It is still important to configure the password length in the login.defs file so that we can account for legacy codebases.

1. Open /etc/login.defs in your favorite editor
2. Set the attribute of PASS_MAX_DAYS to be 180
3. Set the attribute of PAS_MIN_LEN to be 9

Setting the password complexity requirements

Now here is where the going gets real interesting.  Before we look at /etc/pam.d/system-auth a strong caution

Backup up the file before you alter it and open a backup terminal session as the root user before continuing.  If you put the wrong attributes in place or put the PAM directives in the wrong order you will lock yourself, root user and all, out of the system.  At that point you have two options: single user mode recovery from the console or use a live cd to boot the machine and revert to the backup after mounting the filesystem.  Oh, and it is wise to give yourself a delay with either GRUB or LILO because without the delay you won’t be able to change the boot option to allow the single user mode recovery option.

So, the file involved in this process is /etc/pam.d/system-auth and before I go into some of the nitty gritty, here’s the configuration I ended up using:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_tally2.so deny=6 unlock_time=900
auth sufficient pam_unix.so nullok try_first_pass nodelay
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
 
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
account required pam_tally2.so per_user
 
password required pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
 
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The retries requirement is implemented using the following line

auth        required      pam_tally2.so deny=6 unlock_time=900

The complexity and length requirements are implements using the following line

password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3

The following line is set to ensure that the retries count is maintained even if the counter for the pam_tally2 module is corrupted

account     required      pam_tally2.so per_user

References

Rather than go into the details of each individual attribute and how they interact, here are the resources used to develop this ruleset.  They contain an large amount of valuable information.

When trying to sort my cthub XML file recently I found out that my code from the post on sorting the role listing had stopped working.

Turns out that there was an error introduced into the format of this file when upgrading from Contribute 3.11.

As you are no doubt aware, when at least one admin upgrades to Contribute 4 or Contribute CS3 (aka 4.1) all the admins have to since there are upgrades made to the XML files that control the site. Well it appears that this upgrade makes the cthub file non-valid XML.

Take a look at this file and look for the tag font_use_css inside the group_list_item child node of the group_list node. In a copy of the cthub file that was upgraded you will find that this standalone tag is missing the appropriate closing slash. If you compare this against a copy of the cthub file from before the upgrade, assuming you made a backup, you will find that the tag is properly closed.

Since this file is the master file with all of the role information for the site, I wonder if this XML error is causing unknown instability in the system somewhere.

While this is an easy fix, I will be posting some code that you can run to fix this, since editing a file like this by hand can be a real pain.

One of the annoyances I have found with the Contribute Client is that in the Administration interface section, when adding a user, the menu of roles is not sorted for you. The list that appears when you reassign a user or when you create a new role, is sorted for you.

Each time that a new role is added, the client updates the hub file, adding the new role to the end of the list.

In investigating this I found that the hub file is just an XML file. This file is stored in the root _mm folder of the website that you are managing. Note that this file is connection specific, so if you are managing multiple websites, the location of this control file will vary. And if you are managing a large deployment by having multiple sites with a single directory structure, you will have a different _mm folder and hub file for each site, even though they are physically on the same server they are treated differently by the logic of the software.

In the process of troubleshooting the LDAP user problems I was experiencing I found that by default the logging of info and debug messages is turned off by default for the OEM jrun install that is part of Contribute Publishing Server 3.11.

In order to enable these logging levels you have to edit the sevrer configuration xml file. This file should be located in the configuration directory of your jrun4 server’s WEB-INF folder.

The name of the file is: ckm.xml

Open this file in your favorite editor and look for the following section:

/usr/Macromedia_CPS/logs/out.log /usr/Macromedia_CPS/logs/err.log true true true

By default the logger is only set to show error messages. This section also shows the location of the error logs and the output logs.

Note, that enabling this you will get larger log files, since this will log all connections to the LDAP server by the Contribute client(s) that you have installed. You may find it necessary to open the admin console and set a max log file size to control this.

In WordPress the editing section of both Posts and Pages uses TinyMCE.  TinyMCE is a Javascript-based WYSIWYG editor that is used in a myriad of web applications and platforms.  It works by converting HTML Textareas or other elements into an editor for the user.  TinyMCE is very extensible by using plugins to extend the functionality from the default setup.  There are quite a few commercial and free plugins available.

At my current job I am working on a project with a fellow WordPress fan, Joe Searcy, to convert from Adobe Contribute as our web-publishing platform to WordPress MU.  There are a number of education folks out there using both single-player WordPress and WordPress MU to manage the website for their institutions.

One of the challenges as an institutional webmaster is having to reign in the users so that they will not create content that is tremendously ugly and makes your eyes bleed, yet you also have to give them a certain amount of editorial and visual control so that they don’t feel like their freedoms are being stepped on.

The Adobe Contribute engine with the use of the Contribute Publishing Server made this fairly easy with the role-based administration.  As the webmaster, I could limit what things the users could do in regards to the styles that they can apply to the webpage content as they create and edit it.

While WordPress MU roles don’t give you the ability to turn off certain functions, such as changing the forecolor of text in a post or page, this is easily controlled by editing the configuration files that implement the TinyMCE editor.

The file is the same in a standard install of both single-player WordPress and WordPress MU.  Here’s the directory tree showing the location of the file we need to edit:

In this file you need to look for a function entitled

function wp_tiny_mce

The section of code that handles the arrangement and appearance of the buttons will be around line 1221.  Here’s the code from a unmodified WordPress MU that handles the TinyMCE buttons when “Showing the Kitchen Sink”.  This code allows a user to change the forecolor (aka textcolor):

$mce_buttons_2 = apply_filters(‘mce_buttons_2′, array(‘formatselect’, ‘underline’, ‘justifyfull’, ‘forecolor’, ‘|’, ‘pastetext’, ‘pasteword’, ‘removeformat’, ‘|’, ‘media’, ‘charmap’, ‘|’, ‘outdent’, ‘indent’, ‘|’, ‘undo’, ‘redo’, ‘wp_help’ ));

This is the code for the second row of buttons.  There are also variable for a third or fourth row of buttons, but they are not currently used.

If you wish to remove the ability to change the forecolor (aka textcolor) when creating or editing a post or page then make the code look like this by removing the text shown above in red:

$mce_buttons_2 = apply_filters(‘mce_buttons_2′, array(‘formatselect’, ‘underline’, ‘justifyfull’, ‘|’, ‘pastetext’, ‘pasteword’, ‘removeformat’, ‘|’, ‘media’, ‘charmap’, ‘|’, ‘outdent’, ‘indent’, ‘|’, ‘undo’, ‘redo’, ‘wp_help’ ));

If you notice, all the was removed was the array entry for forecolor.  The same methodology can be applied the the other buttons that are shown in the TinyMCE bars.

Be careful what you remove in this file, since it controls the posting mechanism for both pages and posts.  Also, the changes are not role-based, so the apply evenly to everyone, including administrators.

For those of you who are into browser plugins, you may have run across a plugin called Inquisitor.  According to the website, Inquisitor:

speeds up your searches like no other

While this may be true after several searches I determined that I wanted to go back to using the default Safari search plugin features instead.  Unlike the XMarks plugin, the Inquisitor plugin doesn’t come with an uninstallation script.  The Inquisitor FAQ lists the following instructions on removing the plugin for Safari on Mac OS X:

• Navigate to your hard drive device
• Select the “Library” folder
• Select “InputManager” folder
• Delete the “Inquisitor” folder
• Restart Safari

My experience with this was not quite as nice as the FAQ would lead you to believe.  The main issue was that I had to actually logout of my user session before the bundle was released and could be emptied from the trash.

The second issue I had with the instructions was that they are incomplete.

Like many software developers on the Mac, David Watanabe, did not provide a complete uninstaller for the plugin, he just told you to go delete a few files.  I find this a very poor practice when writing software.  If you installer writes files and preferences to particular locations, then you should provide an uninstallation routine that removes those files.

After some searching, here is a list of the files that you need to remove in order to completely expunge Inquisitor from your system:

• /Library/InputManagers/Inquisitor/
• /Users/username/Library/Application Support/Inquisitor/
• /Library/Recipts/inquisitor.pkg
• /Library/Recipts/inquisitorPreflight.pkg

However, since this is a plugin for Safari that gives you options to configure, you should also take the time to remove the entries added to the Safari plist file.  The plist is named com.apple.Safari.plist and is stored in the /Users/username/Library/Preferences/ directory.

Here are the entries to remove from the plist file:

• kInquisitorAutocomplete
• kInquisitorBeaconEnabled
• kInquisitorNumberOfResults
• kInquisitorNumberOfSuggestions
• kInquisitorOrdering
• kInquisitorRepairDefaultShortcuts
• kInquisitorSearchHistory
• kInquisitorSearchSitesA
• kInquisitorSearchSource
• kInquisitorShowSearchViewA
• kInquisitorVersionCheck