So, I recently updated to Server 3.0 and my PHP installation was obliterated. Since PHP in Mavericks server is something like 5.4, I decided to take this opportunity to upgrade to 5.5.5 through the liil project. To upgrade, fire up Terminal.app and run this script:

curl -s http://php-osx.liip.ch/install.sh | bash -s 5.5

Still in Terminal.app, use pico and modify the Apache .conf file:

sudo pico /Library/Server/Web/Config/apache2/httpd_server_app.conf

While you’re in pico, press “control” and “w” and search for “php5”. Add a hashtag to the line your search results hit and add the line below, as shown here:

#LoadModule php5_module libexec/apache2/libphp5.so

LoadModule php5_module /usr/local/php5/libphp5.so

Finally, press “control” and “x” and save your changes. To reload with your upgraded PHP, run the following:

sudo apachectl restart

To be sure the syntax in your modified .conf is working properly, you can test it this way:

sudo apachectl -t

The key to my 2001 New Beetle broke off the remote housing a couple days ago. The RFID chip and radio inside the remote were fine, so I ordered up a replacement housing on Amazon. After following instructions on YouTube to carefully swap the internals, I found that the buttons on the new remote didn’t appear to lock/unlock the vehicle, nor was the RFID being acknowledged by the vehicle. Ironically, my backup master key/remote would also no longer lock/unlock the vehicle, so I figured something else was going on.

As recommended by VW, I reset the non-working remote by following page 31 of the manual. For those that don’t have it handy:

1. Press either the lock or unlock button on the non-working remote one time for one second.
2. Lock or unlock the vehicle with the master key (non-working remote).

The non-working remote should now be able to lock/unlock doors! Repeat as necessary for additional non-working remotes. I also started the vehicle and the RFID appeared to be acknowledged, as it was no longer tripping the vehicle’s security system as indicated by the dashboard.

Digi is working on version 6 of XCTU that runs on Mac OS X. Get it here:

http://ftp1.digi.com/support/utilities/40003027_1P.dmg

I’ve been using it on Mountain Lion and it works fine for me, but I’ve only begun to test it out.

I’ve had the need to append pages to PDFs encoded with DRM. A great tool for removing DRM one file at a time is a service called pdfclean for OS X, an installer of the command line utility included with mupdf’s MuTool clean. I successfully installed and used the service under Mountain Lion and found it effective. Thanks, be3n!

For macOS Sonoma and later, be3n’s tool works as an Automator app, just drop an encrypted .pdf on it. I’m having some trouble with it removed the encryption under Sonoma and am checking with be3n on a potential solution. Right now, when pdfclean attempts to remove encryption on a .pdf, it makes a new file that takes the form “old_file_name.pdf.broken” – removing “.broken” allows the file to open, but the encryption is still there.

My beloved Ibex Commuter Knickers are wearing through. Say it ain’t so!

This is the right butt cheek in a close up.

This is the right side from further away.

This is the left side further away.

This is the left side close up.

I normally don’t have a use for a password cracking application like John the Ripper, but a family member was having problems logging in to their Mac and they couldn’t remember what password they were using for the keychain. I decided to give John the Ripper a try and I’m glad I did. It picked the password for the keychain in about a minute using its built-in dictionary. If you get in a similar bind, the following worked for me running Mountain Lion Server.

The family member was remote, so they zipped up the login.keychain file and sent it to me. I moved the file to my local machine running Mountain Lion Server, but this should work on Mountain Lion, Lion, Snow Leopard, and maybe further back… I downloaded a jumbo build of John the Ripper, moved the login.keychain file into the same directory as the “run” directory of the downloaded JtR, and ran the following commands from JtR’s run directory with Terminal.app:

./keychain2john login.keychain

(running keychain2john spews out a few lines of characters, copy all of the lines to a .txt file and save it to the JtR directory – I copied keychain2john’s output to “clwlogin.txt”) and then I ran the following command from Terminal:

./john -i=all clwlogin.txt

While the command above is running, you can press “enter” and see JtR’s status. When JtR picks the password, it will automatically throw it up on the screen followed by a question mark in parentheses. At this point, JtR will keep running to look for more passwords, so I press Control-C to force it to quit. Success!

I recently upgraded to iLife ’11 from iLife ’09. When I attempted to fire up iPhoto, I was prompted to upgrade my library. I accepted, but not more than a few seconds into the upgrade, I was greeted with: “Unable to open this Library”.

To get around this, fire up Terminal and do the following:

Type “sudo chown -R yourusername” (replace yourusername with the username on your Mac), press the space bar, drag your iPhoto library file from the Finder to the Terminal window, and press return.

Repeat the following process with these commands (enter the command, press space, drag iPhoto library to Terminal and press return):

sudo chmod -R -N

sudo chmod -R u+rwX

I recently migrated data from an Active Directory user account to a new user account, due to a bungled unbind from the Active Directory. Inside the new user account, I was able to import the login.Keychain, but the System.keychain was read only. I’m not sure if this is the correct permissions for the System.keychain, but I fired up Terminal and ran the following:

bash-3.2# sudo chmod 644 System.keychain

The following error message was repeated several times in Console on my aging G4 iMac running Leopard 10.5.8:

7/8/11 9:31:22 PM com.apple.AppleFileServer[8123] MDSChannelPeerCreate: (os/kern) invalid argument

This error appears to be related to permissions of “.feseventsd” located on the root directory of your boot drive. To fix it, quit file sharing by unselecting it in the “Sharing” preference pane, fire up “Terminal.app”, and enter the following at the prompt:

www-schwie-com:/ brad$ sudo chown -R root:staff .fseventsd
Password:
www-schwie-com:/ brad$ sudo chmod -R 770 .fseventsd

After these changes are made to the .fseventsd file, go back to System Preferences and turn file sharing back on under “Sharing”.

My Mac runs 10.6.6 and has a machine account on the Active Directory at work. Today at work, I was in System Preferences->Accounts->Login Options and, by complete accident, I unchecked “Allow network users to log in at login window”. What ensued was a waste of time, so I hope this saves you time, should the same happen to you (I posted a bug report with Apple today and I hope it is resolved in 10.6.7 or Lion).

After unchecking the box, the spinning beachball of death immediately came up and I was forced to restart my unresponsive MacBook Pro. When it came back up, I couldn’t log in to any of the accounts on the MBP, admin or not, network or local, even the root account. I freaked out and tried to reset my passwords by booting the Snow Leopard DVD and then I reinstalled Snow Leopard, but none of this helped!

Eventually, I happened across Brian Keefer’s solution.

To summarize his post, fix things by booting your Mac to the Login Window and in the username field, enter “>Console” without the quotes and press enter. Your screen will go dark for a few moments and then you’ll be prompted for your username and password. Enter credentials that use to work and you should be able to successfully authenticate. Now fix the problem, by using the line below with your own username and password substituted:

dseditgroup -o edit -a localaccounts -u yourusername -P yourpassword -T group com.apple.access_loginwindow

Repeat the command above for any other user accounts that you are not able to log in with. Now type in “reboot” and you should be able to log in as you use to.