June 2011 Archives

My mid-2009 MacBook Pro was starting to feel a bit old around the edges but we're on a multi-year replacement cycle at Yale and I wasn't going to get a new one soon. So I instead opted for an SSD drive upgrade/replacement.

I got a new 750 gigabyte (rotating) hard drive and used the MCE Tech OptiBay to mount an Intel 160 gigabyte SSD. So I have around 900 gigabytes of online data and my system and application boots are around 4x faster.

I used "Trim Enabler" to enable TRIM support for my Intel SSD on Mac OSX 10.6.8 (updated 2011.08: and MacOSX 10.7 Lion).

INTEL SSDSA2CW160G3:

  Capacity:	160.04 GB (160,041,885,696 bytes)
  Model:	INTEL SSDSA2CW160G3                     
  Revision:	4PC10302
  Serial Number:	CVPR11xxxxHF160xxx  
  Native Command Queuing:	Yes
  Queue Depth:	32
  Removable Media:	No
  Detachable Drive:	No
  BSD Name:	disk0
  Medium Type:	Solid State
  TRIM Support:	Yes
  Partition Map Type:	GPT (GUID Partition Table)
  S.M.A.R.T. status:	Verified

Highly recommended for all MBP owners -- if you're willing to give up your optical drive bay!

I had some trouble configuring denyhost on my Mac OS X 10.6 (user) machine as the instructions on the website @ http://www.denyhosts.net/faq.html#macos were wrong. Here is the correct configuration for denyhosts.cfg:

denyhosts.cfg

# Mac OS X (v10.4 or greater - 
#   also refer to:   http://www.denyhosts.net/faq.html#macos
# SECURE_LOG = /private/var/log/asl.log
# SSHD_FORMAT_REGEX=.* \[Sender sshd\] \[PID \d*\] \[Message .* PAM: (?P.*?)\].*?

# Mac OS X (v10.6 or greater - 
#   - reversion to standard log format. No need to do log regex parsing.
SECURE_LOG = /var/log/secure.log


# zip down a bit to the bottom:

#this work_dir worked for me, it's where the python install script added it:

WORK_DIR = /usr/share/denyhosts/data

#this lock_file worked for me although I had to create the directory:

LOCK_FILE = /var/lock/subsys/denyhosts

and then for the file [daemon-control]:

###############################################
#### Edit these to suit your configuration ####
###############################################

DENYHOSTS_BIN   = "/usr/local/bin/denyhosts.py"
DENYHOSTS_LOCK  = "/var/lock/subsys/denyhosts"
DENYHOSTS_CFG   = "/usr/share/denyhosts/denyhosts.cfg"

PYTHON_BIN      = "/usr/bin/env python"

Hope this helps! This is only really necessary if your Mac is on the internet with a static IP and not behind a firewall or NAT router. 99.9% of home machines are ok because they are hidden behind NAT routers, it's mostly academic machines that are in danger.

If spam wasn't enough, my machines are also getting hit by hackers trying to get through the sshd port:

Jun  5 00:35:31 kyoto sshd[59150]: Invalid user prueba from 62.27.42.80
Jun  5 00:35:32 kyoto sshd[59152]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:32 kyoto sshd[59154]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:33 kyoto sshd[59156]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:34 kyoto sshd[59158]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:34 kyoto sshd[59160]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:35 kyoto sshd[59162]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:36 kyoto sshd[59164]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:37 kyoto sshd[59170]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:37 kyoto sshd[59172]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:38 kyoto sshd[59174]: Invalid user postgres from 62.27.42.80
Jun  5 00:35:39 kyoto sshd[59176]: Invalid user hadoop from 62.27.42.80
Jun  5 00:35:39 kyoto sshd[59178]: Invalid user hadoop from 62.27.42.80
Jun  5 00:35:40 kyoto sshd[59180]: Invalid user hadoop from 62.27.42.80
Jun  5 00:35:41 kyoto sshd[59182]: Invalid user hadoop from 62.27.42.80

I've installed denyhost, let's hope that it can work to cut back on some of this nonsense.

This is just for people running Mac OSX server. If your secure.log is full of spam like this:

Jun  8 23:02:40 media-lab com.apple.SecurityServer[55]: Succeeded authorizing ri
ght com.apple.server.admin.streaming by client /usr/sbin/QuickTimeStreamingServe
r for authorization created by /System/Library/CoreServices/ServerManagerDaemon.
bundle.
Jun  8 23:03:40 media-lab com.apple.SecurityServer[55]: Succeeded authorizing ri
ght com.apple.server.admin.streaming by client /System/Library/CoreServices/Serv
erManagerDaemon.bundle for authorization created by /System/Library/CoreServices
/ServerManagerDaemon.bundle.
Jun  8 23:03:40 media-lab com.apple.SecurityServer[55]: Succeeded authorizing ri
ght com.apple.server.admin.streaming by client /usr/sbin/QuickTimeStreamingServe
r for authorization created by /System/Library/CoreServices/ServerManagerDaemon.
bundle.
Jun  8 23:04:40 media-lab com.apple.SecurityServer[55]: Succeeded authorizing ri
ght com.apple.server.admin.streaming by client /System/Library/CoreServices/Serv
erManagerDaemon.bundle for authorization created by /System/Library/CoreServices
/ServerManagerDaemon.bundle.

Then the problem is an overzealous servermgrd (server manager daemon). You can throttle it back by editing its preferences at:

/Library/Preferences/com.apple.servermgrd.plist

Change the idlePeriod from 60 to 300 (the max). This will at least put 5 minutes between the spam messages.

Thanks to: macenterprise

Sorry for the long hiatus from this blog. After the tsunami hit in Northern Japan, I was in a tizzy of activity and then several other things happened after that. I should be posting more regularly from now on.