Tuesday, March 31, 2009

Saturday, March 28, 2009

How to fit a bicycle

fit

Colorado Cyclist

Time Machine preparing

James Meister on 18. helmikuuta 2009 at 13.41 +0200 wrote:
I did an erase and re-install of Leopard Server software about 10 days
ago complete with all the updates.
Ever since, when I try to get Time Machine to back up to any of the 3
external hard drives attached to the server, it continually "prepares"
the disk.
This latest attempt at backing up to a hard drive that has been
previously used as the Time Machine back up hard drive has been
"preparing" for 3 full days.

The drives have been inspected and found to be OK via disk utility,
and in the case of one disk, re-formatted twice.

Any ideas except another erase and install?


I have one server that has been doing this sometimes, I don't know what causes it but I managed to get it working by unloading and loading Time Machine launch daemons like this:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.backupd-attach.plist
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.backupd-auto.plist
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.backupd-wake.plist
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.backupd.plist

sudo launchctl load /System/Library/LaunchDaemons/com.apple.backupd-attach.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.backupd-auto.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.backupd-wake.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.backupd.plist

Then try to start backup manually.

I haven't tested if it's necessary to unload all of them or just com.apple.backupd.plist but that's the one that finally stops the 'preparing' state. The server has been backing up for weeks since the last time I had to do this.


-Perttu
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (Macos-x-server@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/porsche%40realmac.biz

This email sent to porsche@realmac.biz

Spotlight: How to re-index folders or volumes

Spotlight

Spotlight Tips

thexlab.com

Information and Recommendations on Cloning

http://www.macfixit.com/article.php?story=20090327150228817

MacFixit

Friday, March 27, 2009

Stanford University Mac SIG

Stanford Special Interest Group Archives Feb 09

Solutions for Microsoft Word 2004 and AFS Homes

20 May 2006 12:37:35 PM

I doubt too many other shops have a configuration like ours, but I thought I'd share our collection of Word (& Office) hacks just in case. Perhaps it will give others some ideas. (Apologies for the length and multiple postings.)

Our lab Macs authenticate against an OpenLDAP server. Users have network home directories, accessed via AFS (as in Andrew File System), so their home attributes are of the form /afs/ir/users/*. (AFS root is mounted at /afs on all the machines.) Up through Panther we used a loginhook to redirect a lot of directories within these AFS homes to local disks, using symbolic links. For example, ~/Library/Caches, ~/Library/Preferences/Adobe/GoLive/Cache, &c. are all replaced with symlinks to new directories created in a secure user-owned location on the local drive.

Problem the first: After moving to Tiger, Word will not save a pre-exisiting document that has been opened and edited. Error messages abound. Investigation with `ktrace` shows a lot of thrashing about in ~/Library/Caches/TemporaryItems, so we change our cache redirection scheme. Now ~/Library/Caches remains in AFS, and we redirect around 20 subdirectories (~/L/C/Acrobat, ~/L/C/Adobe, &c.) to the local drive, *but* leave ~/Library/Caches/TemporaryItems in AFS. It's a pain to track down all the cache locations used by our other apps, but now Word saves fine, both to AFS and to local drives.

Second problem: AFS homes exhibit the same "Insert Object" problem as AFP/SMB homes. The first time Word is opened and "components are registered", all the functionality is there. The second time Word is opened, the "Insert Object" dialog has no entries in it. No equations, no graphs, no nothing.

Now since accounts with local homes do not have this problem, we open Word as our local admin user, then copy the resulting ~/Library/Preferences/Microsoft/OLE Registration Database 11 and ~/Library/Preferences/Microsoft/Office Registration Cache 11 to a world-readable location. A loginhook copies these files into place in LDAP users' AFS homes (symlinking to them is insufficient). This restores functionality for the LDAP user, but results in delays of 20-25 seconds every time the user logs in and opens Word. It turns out that Word determines whether the Registration Cache is invalid and needs rebuilding by storing in that cache the creation date of the Registration Database. When the database file is copied into AFS, the creation date does not go with it, since AFS does not store that particular metadatum. Word sees the wrong date in the cache and reregisters everything.

However, a creation date of 0 (the epoch) is reliably returned for files in AFS (at least using OpenAFS 1.4.1, as we do). So we alter the creation process for our pregenerated database and cache files. Log in as the local admin user, open Word, close Word, then use SetFile (from the Developer Tools) to change the creation date of the Registration Database to the epoch. (`date -r 0` is useful in determining the right value for your time zone. You'll know you have it right when `GetFileInfo -d` prints no output for the file.) Then open Word again, let it recreate the cache, close Word, and give the resulting files to LDAP users with a loginhook.

Third problem: There's still a significant delay in opening Word for the first time as it "optimizes the font menu". (I trust everyone is already removing the Do Fonts file to prevent Word from actually copying fonts into users' homes at launch; this is a different issue.) It turns out that the file involved, ~/Library/Preferences/Microsoft/Office Font Cache (11), is susceptible to symlink redirection, so we use the admin account to create a font cache for our full deployed image, put it in a world-readable location on the image, and have our loginhook symlink the user's cache to it. (Though first we check whether ~/Library/Fonts has any contents—if the user has installed his/her own fonts we let them create their own font cache.)

One caveat to all this is that we don't deploy Entourage. I imagine these tactics would work for those that do, but we haven't tested that combination ourselves.

That's all. I hope this info can be of use to someone—at least it should be Google-able now.

—IWC

_____________________________________________________
Subscription Options and Archives
http://listserv.cuny.edu/archives/macenterprise.html

Office 2004 save problem

macosxhints article

Exploring OS X with dtrace

macosxhints article

Hitachi Defective Hard Disk sounds

http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/4b1a62a50f405d0d86256756006e340c?OpenDocument

link

OS X Terminal Diagnostic commands dtrace

dtruss terminal command +

bitesize.d(1m) - analyse disk I/O size by process. Uses DTrace
cpuwalk.d(1m) - Measure which CPUs a process runs on. Uses DTrace
creatbyproc.d(1m) - snoop creat()s by process name. Uses DTrace
dappprof(1m) - profile user and lib function usage. Uses DTrace
dapptrace(1m) - trace user and library function usage. Uses DTrace
diskhits(1m) - disk access by file offset. Uses DTrace
dispqlen.d(1m) - dispatcher queue length by CPU. Uses DTrace
dtrace(1) - generic front-end to the DTrace facility
dtruss(1m) - process syscall details. Uses DTrace
errinfo(1m) - print errno for syscall fails. Uses DTrace
execsnoop(1m) - snoop new process execution. Uses DTrace
fddist(1m) - file descriptor usage distributions. Uses DTrace
filebyproc.d(1m) - snoop opens by process name. Uses DTrace
hotspot.d(1m) - print disk event by location. Uses DTrace
httpdstat.d(1m) - realtime httpd statistics. Uses DTrace
iofile.d(1m) - I/O wait time by file and process. Uses DTrace
iofileb.d(1m) - I/O bytes by file and process. Uses DTrace
iopattern(1m) - print disk I/O pattern. Uses DTrace
iopending(1m) - plot number of pending disk events. Uses DTrace
iosnoop(1m) - snoop I/O events as they occur. Uses DTrace
iotop(1m) - display top disk I/O events by process. Uses DTrace
kill.d(1m) - snoop process signals as they occur. Uses DTrace
lastwords(1m) - print syscalls before exit. Uses DTrace
loads.d(1m) - print load averages. Uses DTrace
newproc.d(1m) - snoop new processes. Uses DTrace
opensnoop(1m) - snoop file opens as they occur. Uses DTrace
pathopens.d(1m) - full pathnames opened ok count. Uses DTrace
pidpersec.d(1m) - print new PIDs per sec. Uses DTrace
plockstat(1) - front-end to DTrace to print statistics about POSIX mutexes and read/write locks
priclass.d(1m) - priority distribution by scheduling class. Uses DTrace
pridist.d(1m) - process priority distribution. Uses DTrace
procsystime(1m) - analyse system call times. Uses DTrace
runocc.d(1m) - run queue occupancy by CPU. Uses DTrace
rwbypid.d(1m) - read/write calls by PID. Uses DTrace
rwbytype.d(1m) - read/write bytes by vnode type. Uses DTrace
rwsnoop(1m) - snoop read/write events. Uses DTrace
sampleproc(1m) - sample processes on the CPUs. Uses DTrace
seeksize.d(1m) - print disk event seek report. Uses DTrace
setuids.d(1m) - snoop setuid calls as they occur. Uses DTrace
sigdist.d(1m) - signal distribution by process. Uses DTrace
syscallbypid.d(1m) - syscalls by process ID. Uses DTrace
syscallbyproc.d(1m) - syscalls by process name. Uses DTrace
syscallbysysc.d(1m) - syscalls by syscall. Uses DTrace
topsyscall(1m) - top syscalls by syscall name. Uses DTrace
topsysproc(1m) - top syscalls by process name. Uses DTrace
weblatency.d(1m) - website latency statistics. Uses DTrace

Disk Utility Command

Update on this... thanks to Andrew Laurence for pointing me toward
looking up the model numbers of the drives via "diskutil info disk0".
Once I'd done that, we were able to determine that they were indeed 80
GB Seagate Barracuda 7200.10 drives, and not SAS drives.

In short, Apple System Profiler on the Intel-based Xserve is lying
through its teeth when it claims these are SAS drives. So that's good
- it means I got what I ordered and what I paid for, and the fact that
Apple seems to be using stock Seagate drives makes me more confident
about replacing the questionable drive with a large SATA drive.

Maybe not one of the Seagate drives with the firmware bug though. :-)

cheers... -Adam