macports notification of outdated

A quick and dirty bash/shell script to get automatic notification of outdated macports:

#!/bin/bash

# 20090902 mvgfr: tweaks
# 20071110 mvgfr: check for outdated macports & notify if any - via growl & stdout (emailed when cron'd)
# 20080209 mvgfr: must run sync before, so it can learn about updates!
#                 also added "-H localhost" workaround for growl Leopard bug (ignores some)

debugMe="" # presume we'll only use alphanum; like "YES" or empty string for NO

# may take awhile; is this an issue?
if [ ! $debugMe ] ; then /opt/local/bin/port sync; fi

if [ $debugMe ] ; then
    potentialOutput="`echo 'debugging:';ls -1|head -1`"
else
    potentialOutput=`/opt/local/bin/port outdated`
fi

if [ "$potentialOutput" != "No installed ports are outdated." ] ; then
    echo "$potentialOutput" # for cron to email to root
    if [ -f /usr/local/bin/growlnotify ]; then
 NumLinesToDisplay=$((`echo "$potentialOutput" | wc -l` -1))
 if [ $NumLinesToDisplay -lt 1 ]; then
     echo "underflow error; see log" | /usr/local/bin/growlnotify -H localhost -s -t 'macports outdated:'
 elif [ $NumLinesToDisplay -gt 20 ]; then
     echo "overflow error; see log" | /usr/local/bin/growlnotify -H localhost -s -t 'macports outdated:'
 else
  echo "$potentialOutput" | tail -`echo $NumLinesToDisplay` | \
      /usr/local/bin/growlnotify -H localhost -s -t 'macports outdated:'
 fi
    fi
fi

if [ $debugMe ] ; then echo "`date "+%Y%m%d-%H%M%S"`: $potentialOutput" >> /var/log/port-outdated.log; fi

#end

(Old 2007/12/01 script here.)

Snow Leopard upgrade notes

Words of warning for anyone who's customized "under the hood" a little:

1. The Snow Leopard installer (doing an upgrade) wipes out /var/log/.
   

   Not only would I have preferred to keep the old logs (historical reference; maybe to compare pre- and post- Snow Leopard), but I also had some custom stuff logging into there (ex: freshclam) that was just gone. And my code was quick-and-dirty so it didn't recover gracefully (ex: to the logs not existing) so I had to do a bit of cleanup.
   

   No huge deal (this is not-unexpected behavior for /var/) though it is new behavior for the Installer, so I'm adding this to the great Internet KnowledgeBase, so maybe it saves someone else a bit of effort. :)
   

2. It seems to have wiped out the /opt/local/mysql symlink to /opt/local/mysql-version_spec; also easily fixed.
   
   
3. MacPorts wouldn't selfupdate for me, so I just reinstalled from the latest disk image (1.8.0 for 10.6). I also installed the new Snow Leopard Xcode Tools (3.2; newer even than the version I downloaded last week!) on the Snow Leopard DVD.

BTW: If you have done some customizing, look for files with these strings added to the name (not just appended): "~previous", "~orig", or (maybe) "disabled". Such as:

• /etc/syslog.conf~previous
• /etc/postfix/main.cf~orig

As you may need to bring some customizations back. (Though in both the above cases, I was happy with the way the Installer had done it.)

(Thanks to Apple for putting some nice info in various logs.)

Otherwise, smooth sailing! Definitely a must-have upgrade, especially considering the price and what it sets up for the near future.

Macs are more secure

Check out the Macalope's column "Lies, damned lies, and statistics" in which he discusses yet another (strange) survey trumpeting trouble for Apple.

He also discusses Apple trumpeting about Macs being more secure, and makes a good analogy to be somewhat more realistic: "no matter how nice the neighborhood, you can only leave your houses unlocked for so long before something bad happens".

Clearly, no matter how secure Macs are to start, if you make insecure choices (ex: easy password, auto-login, etc.) you may find yourself in trouble.

The comments below the article are worth reading too; and indeed security does include many things.

One factor is the default config. In MS Windows, virtually everything defaults to "on" whereas the Mac defaults to "off"; you can't be attacked via a door that isn't there.

Another factor is monoculture vs. diversity; much malware depends on the targets running IE or Outlook or whatever - whereas the Mac market benefits from a different and more varied environment and so is more difficult to target.

Macs are certainly not immune (nothing is) - however they do suffer from far less malware and one reason is that they start out more secure than MS Windows. The rest is up to you.

Pruning Time Machine Backups

Here's an interesting twist; Apple seems to be protecting me from myself again:

I noticed that Time Machine (TM) is backing up the Thumb64Segment.data (etc) files in my iPhoto bundle/folder and since those files are large and easily replaced, I want to skip them; easily added to the exception list ("Do not back up", via the "Options" button in the Time Machine preference pane) for future backups - HOWEVER I can't figure out how to prune them from previous TM backups.

(Tip: If you don't already use Eriban's Grand Perspective, check it out - it's terrific for exploring just where your disk space is spent, and it properly counts the hard links that TM makes such heavy use of. BTW: I also recommended Robert Pointon's tms, a command line utility to get lots of great info on your TM backups, including what exactly was backed up each time.)

Now, back to the problem that software exposed:

Of course I can open the iPhoto bundle in a Finder window, but as soon as I "Enter Time Machine", the window changes and moves to its parent. If I first open a Finder window to a subfolder within the bundle, that does stay viewed in Time Machine, but as soon as I click on the Thumb64Segment.data file to "Delete all Backups..." of it, the window immediately moves up another level.

Apparently Apple wants to prevent me from messing with bundles. I do understand the reasoning, however I'd argue the protections in the Finder are enough; if I've explicitly chosen to navigate into a bundle (hard to do by mistake) then let me work there! :)

So, there appears to be no GUI way to prune TM backups of bundles in this way; does anyone know how to prune by command line, within Time Machine? Of course it's easy enough to simply find and delete files via command line, however I don't know if that's safe within a Time Machine backup - anyone?

It's such a drag when you can't drag!

Strange problem that's been bugging me for awhile now:

For no apparent reason, the (Mac OS X) Finder suddenly chooses not to respond to an attempt to drag a file - say, to move it into another folder.

No error message; just that dislocated feeling when you realize that you didn't really pick it up - and can't.

Nothing interesting in syslog (asl) / system.log (even temporarily logging *.debug messages). Nothing in Console. Nothing in any other log that had recently been modified.

Tools like fs_usage and sc_usage didn't yield any promising clues.

Quitting and restarting the Finder didn't help.

HUP'ing SystemUIServer didn't help.

Checking the SystemUIServer plist ("defaults read /Users/username/Library/Preferences/com.apple.systemuiserver.plist") showed nothing unusual - and I don't just delete prefs to see what happens; that's sledgehammer voodoo.

Google searches turned up lots of discussion - but really nothing more interesting than the standard "Repair Permissions" voodoo or "Have you tried turning it off and on again?"

Quitting all open apps (and menu extras, etc.) had no effect.

Restarting will clear the problem (as will, if I recall, logging out and back in) - for awhile - however of course it's then necessary to reconstruct the 17 things you were trying to do at the moment; not good.

I noticed that other apps were affected - for instance, TextWrangler reports an error -4960 when attempting a drag.

The very cool "Technical Note TN2124 - Mac OS X Debugging Magic" (on the Apple Developer site) had a promising idea (launch an app with "-NSDragManagerLogLevel 6"), though that didn't yield anything for either Finder (probably because it's not a Cocoa app :) or TextWrangler (is it a Cocoa app?).

Looking into the Drag Manager some more didn't yield anything promising.

Well, then I started searching more deeply, including into some of the coding discussions. That's when I found mentions of the pasteboard (AKA clipboard). It didn't seem related, however that was the trick:

sudo killall -s pboard

(HUP'ing it apparently is not sufficient, but the default signal (-TERM) will do it. The "-s" flag means it'll show you what it'll do; if you approve, re-issue the command without the "-s" to really do it.)

It seems that - even for dragging a file in the Finder - the pasteboard is engaged and if it's wedged the operation fails silently.

If I can discover a little more background, I'll submit to RADAR.)

UPDATE: Apparently a little more background is required: While killing pboard re-allows dragging, it apparently is a BAD thing, causing apps to hang, probably expecting to hear back from the old process. Back to the drawing board...

Update 2009/03/20: It happened again and while I confirmed that logging out will clear it, that's not good enough. I did however find that there was a "Recovered Items" folder in my Trash; it contained a folder called "msoclip1" with four files (clip_image001.gif, clip_image002.wmf, clip_image003.png, clip_oledata.mso) so maybe the problem is related to some MS Office app's use of the clipboard?

Debugging 101 - Drat! Now What?!

What to do when something goes wrong.

(A presentation and interactive debugging session for the February 18, 2009 MacChamp (Apple User Group) meeting - though virtually all of it is applicable to any debugging scenario.)

Intro: The steps below may seem daunting, however this is the typical process - even if you call someone else for help, it can be handy to know. For instance, it removes some of the mystery and can help you gather critical info you might otherwise have missed. And every advantage to get you closer to a solution and more quickly on your way, is a good thing.

Step 1: STOP!

• Don't make things worse.
  
• Take a moment to assess; is it a genuine emergency?
  
• If immediate action is required, do what's absolutely necessary and then re-assess. (Ex: Dropped mobile phone in puddle: IMMEDIATELY remove battery!)

Step 2: What happened?

• Before you can fix it, you must understand just what occurred.
  
• Understanding requires hard (precise) information.
  
• Write down the time it is NOW.
  
• Write down when it happened:
  
  • If known: The exact time, using the clock on the problem device if possible.
    
  • If not known: When was the last time things were OK? How certain are you of that?
  
  
• Take snapshots:
  
  • Of the screen:
    
    • Shift-Control-3.
      
    • Use a camera if need be!
    
    
  • Of specific files:
    
    • Copy to ANOTHER disk.
      
    • If there are possible problems with a disk, avoid making any changes and especially adding any files to it. Just about anything can cause changes...
    
    
  • Of a whole disk:
    
    • CCC, SuperDuper, Disk Utility...
  
  
• In as much detail as possible, write down:
  
  • What you were expecting.
    
  • What actually happened.
    (Nothing is too small to mention; it's like "brainstorming".)

Step 3: Backups?

• What's the state of your backups?

Step 4: Background.

• List ANYTHING that happened recently that was out of the ordinary.
  
• List EVERYTHING you changed recently, REGARDLESS if it seems unrelated.

Step 5: Why?

• Why did it happen; what's the cause? Using the info you've gathered, generate some theories.
  (ex: Juxtapose what happened with what you were expecting.)

Step 6: Form a plan.

• For each theory, develop a test plan.
  
• Flesh each plan out in as much detail as possible, into a step-by-step checklist.
  (This is important; it may indicate the solution or help avoid a problem.)
  
• TIP: Test one thing - the smallest thing possible - at a time.

Step 7: Backups?

• Should you make additional backups, if possible, before doing anything?

Step 8: Test theories methodically.

• Use checklists & write down results at each step; it may be necessary to backtrack.
  
• Don't make things worse; change as little as possible.
  
• If a theory looks promising, retest to confirm *before* making changes.
  
• If no theories remain, review the info you now have; this may lead to new theories.

Step 9: Fix?

• If you think you have a fix, try it (one at a time!) and take notes about what happens.
  
• Retest to confirm.
  (Better to find out now, that it's not really a fix.)
  
• If a promising fix doesn't pan out, review the info you now have; this may lead to new theories.
  
• If a fix works, does it indicate anything that can be done to avoid problems in the future?

Step 10: Clean up.

• File your notes away; you may need them later; ex: long-term effects, multiple variables.

Mac AirPort (WiFi) and "promiscuous mode"

Interesting; I'm not sure when it happened or whether it's due to hardware or software (my money's on the latter), however:

I can now use Wireshark to capture packets over the built-in AirPort in a MacBook!

The Model Identifier is "MacBook4,1"; it's 2.10GHz 13.3" White, Model Number MB402LL/A.

And I'm using Mac os X 10.5.6 now.

Last time I tried, was with a 15" MacBook Pro (I think it was a 2006 model) and an earlier version of 10.5.

Whatever the reason, it's nice that simply attempting to use Wireshark (or, likely, attempting "promiscuous mode" in general) no longer renders the AirPort connection totally deaf, requiring something like switching Locations to recover.

Gmail: Bad Request; Error 400

First time I've seen this: Tried to log in to gmail (via browser) and all I got was:

Bad Request
Error 400

I figured it was momentary, so went off to do other things. (So many other things to do...)

A few hours later, same thing. Next day, same thing.

This is unlike gmail. So tried a simple Google search... slow, but it did return.

Maybe Google is under a DoS attack? No news, and now Google is returning just fine, but still no gmail.

So I started searching around for anyone with a similar problem. Saw a few, though they were old.

Tried the gmail Google Group and went through what seemed to be the procedure to enter a new issue (after reviewing current open issues), but that did not give an opportunity, at the end, to open a new issue.

So, some more generic searching, using both Google and Yahoo, turned up the typical low-level support "decision tree" request to empty cache and delete cookies. Well, I'm certainly not going to delete all my cookies right away, however...

I tried a different browser and got right in - OK; we're on the right track.

I then saved my cookies (always have a backup) and looked for which cookies might be the culprit.

Got it in one: There were probably well over a hundred (!) separate cookies for the mail.google.com domain (both with and without a leading dot), that also used a path of "/mail". I deleted them, and gmail loaded right up on the next try!

Update 2009/03/20: Apparently there's a similar problem with Firefox.

Browser password managers leak like sieves

We're browsing away, maybe checking our bank account balance and up pops the requirement to type in the password to unlock the password manager. Ah, we think, another indication that we're safe - it required me to type the password AND I was so careful to make sure it was the right site, etc.

Unfortunately, that's a false sense of security - which is worse than no security at all.

Click through the link above to read the gory detail if you like; even if you don't understand it all, at least some will make sense.

Even better, try the test yourself - watching it pull passwords out of YOUR very own password manager will really drive the point home.

I know of no actual exploits yet, and they do seem to require a compromise of the site from which the attacker wants to steal your password - however, as we've seen, such compromises are not at all uncommon.

One other item of note: For Safari in particular, I note that the default, when creating a new entry, is to give Safari blanket permission (via Access Control). While convenient, it is far less safe - and it seems that the problems detailed in the CIS article, might well be avoided if Safari did not do this; at least the user would be required to type in the keychain password each time and thus get some warning.

"What To Look For in a CIO"

Economic constraints mean there's business out there that others are pulling back from, for the rest of us to pick up - opportunity!

What's an org to do? Get crazy - like a fox.

http://www.cio-today.com/story.xhtml?story_id=12200AVJWGKE

We have lots of tech already, and there are people who can do amazing things with it, even before investing in anything new.