Для Mac OS X есть аналогичная утилита на базе DTrace – dtruss.

Сегодня при помощи двух команд “sudo dtruss -n xftpd -f” и “sudo tcpdump -i lo0 port 53″ я разобрался в мистической проблеме длительных задержек при заходе на Mac OS X Server по FTP.

Примеры использования dtruss

Показать системные вызовы всех xftpd (-n xftpd) с отслеживанием дочерних процессов (-f):

$ sudo dtruss -n xftpd -f
	PID/THRD  SYSCALL(args) 		 = return
24804/0x76294:  getpid(0x0, 0x0, 0x0)		 = 24804 0
24804/0x76294:  open_nocancel("/dev/urandom\0", 0x0, 0x0)		 = 3 0
24804/0x76294:  read_nocancel(0x3, "\2315\336\347\3546\355K\230\326r\2534qn\177\377\250;\0353\367\2769=a\363\350\255\032\361\017z\022\367\257;\315\363\vSg\021\"\252\211KSM\0", 0x74)		 = 116 0
24804/0x76294:  close_nocancel(0x3)		 = 0 0
24804/0x76294:  __sysctl(0xBFFFDC4C, 0x3, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  issetugid(0xBFFFDC4C, 0x3, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  geteuid(0xBFFFDC4C, 0x3, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  __sysctl(0xBFFFDC14, 0x2, 0xBFFFDBDC)		 = 0 0
24804/0x76294:  __sysctl(0xBFFFDBDC, 0x2, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  shared_region_check_np(0xBFFFDE30, 0x2, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  stat64("/usr/lib/libobjc.A.dylib\0", 0xBFFFCF6C, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  stat64("/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation\0", 0xBFFFCF6C, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  stat64("/System/Library/Frameworks/Security.framework/Versions/A/Security\0", 0xBFFFCF6C, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  stat64("/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices\0", 0xBFFFCF6C, 0xBFFFDC5C)		 = 0 0
24804/0x76294:  stat64("/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos\0", 0xBFFFCF6C, 0xBFFFDC5C)		 = 0 0
...

Проанализировать вызовы при запуске программы “df -k”:

$ sudo dtruss df -k

По процессу с нужным pid:

$ sudo dtruss -p 1637

Dtrace – мощная подсистема ядра, позволяющая исследовать работу операционной системы и приложений. Я давно к ней не возвращался в статьях, рекомендую почитать “Отладка файловой активности процессов с помощью DTrace, или как написать деинсталлятор” и “Поиск метода установки Mac OS X под VMWare Fusion“. В первой статье есть ссылки для дальнейшего чтения.

Сегодня приведу полезный скрипт, показывающий, к каким файлам шли частые обращения за 10-ти секундный интервал. Скрипт работает непрерывно до его прерывания. Применение – можно увидеть, почему вдруг увеличилась нагрузка на систему из-за дисковой активности.

Скрипт:

$ cat 02_openfiles.d
#!/usr/sbin/dtrace -s 

io:::start
{
        @[args[2]->fi_pathname] = count();
}

tick-10s
{
        trunc(@, 10);
        printa(@);
        trunc(@, 0);
}

Выставить права на запуск:

$ chmod +x 02_openfiles.d

Запуск:

$ sudo ./02_openfiles.d

Второй вариант запуска – в одну строку:

$ sudo dtrace -n 'io:::start {@[args[2]->fi_pathname] = count();} tick-10s {trunc(@, 10); printa(@); trunc(@, 0);}'

Пример работы:

0 129269                        :tick-10s
??/Logs/FileSyncAgent.log                                         1
??/Russian.lproj/Dictionary.dat                                   1
??/DiagnosticMessages/StoreData                                   3
??/DiagnosticMessages/2010.11.30.asl                              6
??/com.apple.Safari/Cache.db-journal                              8
??/com.apple.Safari/Cache.db                                     51

0 129269                        :tick-10s
??/bands/114                                                      1
??/bands/ef                                                       2
??/Cookies/Cookies.plist_tmp_67927_0.dat                          3
??/bands/115                                                      3
??/bands/a0                                                       3
??/bands/0                                                        4
??/bands/59                                                       5
??/com.apple.Safari/Cache.db-journal                              6
??/com.apple.Safari/Cache.db                                     12
??/unknown (NULL v_parent)/unknown (NULL v_name)                 16

По этим примерам можно сказать, что Safari активно пишет в кеш, и система синхронизирует iDisk.

Почему iDisk? /bands/114 указывает на Sparse Bundle Image, Time Machine вне подозрения (TimeCapsule далеко), а поиск find’ом показал каталог ctrld_iDisk.sparsebundle:

$ sudo find / -name 114
/Users/ctrld/Library/FileSync/0025bcdcddae/ctrld_iDisk.sparsebundle/bands/114

Указанный пример очень прост, есть гораздо более впечатляющие примеры. Хотите узнать больше? Смотрите OpenSolaris Community Group dtrace.

Если вы пытались установить под VMWare Fusion или Parallels Mac OS X, то сталкивались с отказом – есть возможность установить только Mac OS X Server. Это связано с лицензионным ограничением Apple, и, конечно же, ни VMWare, ни Parallels не хотят подвергать себя риску быть обвинёнными в нарушении Software License Agreement.

Интересно самому взглянуть на соглашение, а не просто принять это на веру – все Hardware и Software Product Agreements есть на сайте Apple. Смотрим раздел 2 “Permitted License Uses and Restrictions”, жирным текстом я выделил главное.

Mac OS X (Snow Leopard)

A. Single Use License. Subject to the terms and conditions of this License, unless you have purchased a Family Pack or Upgrade license for the Apple Software, you are granted a limited non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at a time.

Mac OS X Server (Snow Leopard)

A. Mac OS X Server Software. Subject to the terms and conditions of this License, you are granted a limited non-exclusive license to install and use one copy of the Mac OS X Server software (the “Mac OS X Server Software”) on a single Apple-branded computer. You may also install and use other copies of Mac OS X Server Software on the same Apple-branded computer, provided that you acquire an individual and valid license from Apple for each of these other copies of Mac OS X Server Software.

Различие налицо. Можно использовать только одну копию Mac OS X на одном компьютере одновременно, а Mac OS X Server – несколько копий. Именно это и даёт возможность легальной виртуализации Mac OS X Server.

А теперь уйдём на тёмную сторону силы – рассмотрим, что и почему нужно делать для запуска Mac OS X в виртуальной машине (давайте сделаем вид, что не поняли пункт SLA “You agree not to install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so” – ведь мы же работаем на родном Маке, а не Хакинтоше).

Сразу уточню – для установки под VMWare нужна Retail-версия Mac OS X. Версия, идущая с ноутбуком или же iMac, не подходит – Installer Mac OS X проверяет аппаратную часть, и не разрешает установку на другом оборудовании (а Model name “VMware Virtual Platform” – это совсем не “MacBook Pro”).

Предупреждение. Я показываю принцип поиска, а готовый рецепт есть в статье “Hack VMWare Fusion 2 – Virtualize Tiger/Leopard“. Я попытался пофантазировать, как происходило нахождение этого рецепта.

Итак, приступим. В наличии – VMWare Fusion 2.0 (заметьте – лицензионная, а не “лицензионная”) и DVD с Mac OS X 10.5 Retail вставлен в привод.

Создаём виртуальную машину “Mac OS X Server 10.5″ (все параметры стандартные). Запускаем в Terminal.app dtrace для проверки, к каким файлам обращается VMWare для проверки, сервер ли это. Нужен именно dtrace, fseventer не подходит – он не показывает открываемые файлы.

sudo dtrace -n 'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }' > vmware-10.5.txt

Стартуем виртуальную машину, и получаем назидательное сообщение о том, что DVD не совсем тот:

Останавливаем dtrace и смотрим, к каким файлам обратился VMWare на DVD:

$ cat vmware-10.5.txt | grep "Install DVD"
  0  18474                       open:entry mds /Volumes/Mac OS X Install DVD/
  0  18474                       open:entry mds Mac OS X Install DVD
  1  19260              open_nocancel:entry diskarbitration /Volumes/Mac OS X Install DVD/.autodiskmounted
  1  18474                       open:entry mds /Volumes/Mac OS X Install DVD
  1  18474                       open:entry Finder /Volumes/Mac OS X Install DVD/System/Library/CoreServices/SystemVersion.plist
  1  18474                       open:entry Finder /Volumes/Mac OS X Install DVD/System/Library/CoreServices/SystemVersion.plist

Содержимое файла SystemVersion.plist явно не указывает, что для проверки используется информация из него:

Думаем, как заставить думать VMWare, что у нас серверная версия. Для запуска системы с DVD у VMWare должен быть загрузчик. Анализируя захваченные данные dtrace (отфильтровываем по vmware), в итоге находим интересные строки:

  0  19260              open_nocancel:entry vmware-vmx /Library/Application Support/VMware Fusion/isoimages/tools-key.pub
  0  19260              open_nocancel:entry vmware-vmx /Library/Application Support/VMware Fusion/isoimages/darwin.iso.sig
  0  19260              open_nocancel:entry vmware-vmx /Library/Application Support/VMware Fusion/isoimages/darwin.iso

Загрузчик – в iso-образе darwin.iso. Второй вариант – можно было изучить каталоги VMWare и найти iso.

cd "/Library/Application Support/VMware Fusion/isoimages/"

Открываем darwin.iso в hex-viewer’е “Hex Fiend“. Как обычно пишется код? Просто: сделали проверку – выдали сообщение. Если есть сравнение строк, обращение к файлам, и они не прописаны в отдельном блоке как переменные, то есть вероятность, что в ресурсах программы будет идти проверяемая строка, а затем – сообщение об ошибке.
Пытаемся найти строку сообщения “The operating system is not Mac OS X Server”. И мы его находим, причём рядом видим имя файла ServerVersion.plist:

Делаем бекап всех файлов:

sudo bash
cd "/Library/Application Support/VMware Fusion/isoimages"
mkdir original
mv darwin.iso tools-key.pub *.sig original

На установочном диске в каталоге /System/Library/CoreServices файла ServerVersion.plist нет. Может стоит его подменить на SystemVersion.plist? Правим iso в Hex Fiend (бекапы!), благо количество букв совпадает. Другой вариант, без редактирования в hexeditor’е:

perl -n -p -e 's/ServerVersion.plist/SystemVersion.plist/g' < original/darwin.iso > darwin.iso

Загружаем, ошибка:

Вспоминаем о обращении к tools-key.pub и darwin.iso.sig перед открытием darwin.iso и понимаем, что файл изменился, и нужно перегенерировать цифровую подпись. Выходим из VMWare. В каталоге “/Library/Application Support/VMware Fusion/isoimages” видим не только публичный ключ tools-key.pub, но и приватный tools-priv.pem, которым производится подписывание (это не оплошность, так производится подписывание загружаемых образов). Смотрим документацию по OpenSSL и генерируем подпись (напоминаю, эти команды я взял из “Hack VMWare Fusion 2 – Virtualize Tiger/Leopard“):

sudo -s
cd "/Library/Application Support/VMware Fusion/isoimages"
openssl genrsa -out tools-priv.pem 2048
openssl rsa -in tools-priv.pem -pubout -out tools-key.pub
openssl dgst -sha1 -sign tools-priv.pem < darwin.iso > darwin.iso.sig
for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem < $A > $A.sig ; done

Запускаем виртуальную машину. Вуаля! Установщик загрузился:

Наслаждаемся.

fslogger

В книге “Mac OS X Internals. A System Approach” была описана командно-строковая утилита fslogger, написанная автором, позволяющая отслеживать различные изменения файловой системы, например:

• создание файлов и каталогов;
• удаление файлов и каталогов;
• изменения структуры stat (например, изменение разрешений);
• переименование файлов и каталогов;
• изменение содержимого;
• обмен содержимым между двумя файлами (это функция HFS+);
• изменение информации Finder;
• изменение владельца.

Пример работы утилиты:

ole-mac:~ ctrld$ sudo fslogger
Password:
fsevents device cloned (fd 4)
fslogger ready
=> received 654 bytes
# Event
  type           = FSE_CREATE_FILE
  pid            = 193 (iChatAgent)
  # Details
    # type           len  data
    FSE_ARG_STRING    66  string = /Users/ctrld/Library/Caches/com.apple.iChat/Pictures/.dat00c1.055
    FSE_ARG_DEV        4  dev    = 0xe000002 (major 14, minor 2)
    FSE_ARG_INO        4  ino    = 2766443
    FSE_ARG_MODE       4  mode   = -rw-r--r--  (0x0081a4, vnode type VREG)
    FSE_ARG_UID        4  uid    = 501 (ctrld)
    FSE_ARG_GID        4  gid    = 20 (staff)
    FSE_ARG_INT64      8  tstamp = 8200465994289
    FSE_ARG_DONE (0xb33f)
# Event
  type           = FSE_CONTENT_MODIFIED
  pid            = 193 (iChatAgent)
  # Details
    # type           len  data
    FSE_ARG_STRING    66  string = /Users/ctrld/Library/Caches/com.apple.iChat/Pictures/.dat00c1.055
    FSE_ARG_DEV        4  dev    = 0xe000002 (major 14, minor 2)
    FSE_ARG_INO        4  ino    = 2766443
    FSE_ARG_MODE       4  mode   = -rw-r--r--  (0x0081a4, vnode type VREG)
    FSE_ARG_UID        4  uid    = 501 (ctrld)
    FSE_ARG_GID        4  gid    = 20 (staff)
    FSE_ARG_INT64      8  tstamp = 8200466392596
    FSE_ARG_DONE (0xb33f)

fseventer

Компания fernLightning на основании идеи fslogger создала программу fseventer, которая в графическом виде показывает файловую активность. Программа бесплатная, но предлагает сделать добровольное пожертвование разработчикам. Функциональность видна по двум скриншотам:

Предупреждение: я не претендую на полноту изложения и с точки зрения опытного системного программиста под MacOS X часть статьи может выглядеть бредом :-) Но мой метод работает, и его можно рассматривать как взгляд системного администратора на MacOS X.

Недавно мне попалась на глаза новость об обновлении деинсталлятора “Yank – Your Mac’s Uninstaller”. Он отрабатывает самые сложные случаи – когда программа устанавливается не только перетаскиванием в Applications, но и с помощью инсталлятора, когда достаточно много файлов записывается в разные каталоги. Краткое описание программы есть на DeepApple. Yank следит за файловой активностью инсталлятора и записывает в отдельный файл перечень устанавливаемых файлов, а далее, используя этот файл, может всё чисто деинсталлировать. Также есть онлайн-сервис, который содержит файлы для удаления более 150 программ, т.е. можно удалять программы, которые были установлены до начала использования Yank.

Yank – это пример программы, которая выстроена вокруг нескольких команд в shell. Я хочу продемонстрировать принцип, по которому она работает, а заодно продемонстрировать очень мощную технику отладки – DTrace.

Вольно процитирую Wikipedia (прошу прощения за перевод, читать по английски намного проще, чем переводить на русский, особенно возникают проблемы с терминами):

DTrace – это мощный фреймворк, предназначенный для динамического трейсинга. Он был создан Sun Microsystems для поиска ошибок ядра и приложений на продуктивных системах в реальном времени. Разработанный для Solaris, он был выпущен под лицензией CDDL и был портирован на несколько других Unix-систем.

DTrace может использоваться для получения разнообразной глобальной информации по работающей системе, такой, как количество памяти, использование процессора, файловой системы и сетевых ресурсов, используемых активными процессами. Он также может предоставить гораздо детальную информацию, например, аргументы, с которыми вызываются конкретные функции, или перечень процессов, доступающихся к конкретному файлу.

С детальной информацией по DTrace можно ознакомиться на таких ресурсах (или поискать в Интернет):

• Sun Microsystems, “BigAdmin System Administration Portal”.
• Видео с “Google Tech Talks 2007″.
• Exploring Leopard with DTrace.
• MacOSXHints “10.5: Exploring OS X with dtrace”.
• DTrace tools.

Прототип программы

Наша задача – запустить сбор информации файловой активности всех процессов в системе, записать её в файл, а затем проанализировать, какие файлы создавались интересующим нас процессом.

Будем экспериментировать с ProteMac (системой сбора информации по сетевому трафику) – она использует инсталлятор, который ставит много чего, включая драйвер.

Примечание. Рекомендуется закрыть iTunes, QuickTime Player, DVD Player, так как по заявлению Apple они блокируют работу DTrace для защиты лицензионного контента. Возможно они блокируют отладку себя же, так как информация по интересующим меня процессам фиксируется.

Запускаем DTrace

$ sudo dtrace -n \
'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }' \
> protemac.log

В файле видим строки, вида:

Запускаем инсталлятор

Запускаем, убеждаемся, что данные по этому процессу фиксируются, и запускаем установку.

Прерываем dtrace после завершения установки, но не перезагружаемся, как нам рекомендуется – нас интересует не работа программы, а данные, захваченные DTrace.

Анализируем

После предварительного просмотра выясняем, что за распаковку отвечает pkgExtractor, который показывает, что распаковывается, но, к сожалению, не показывает, в какие файлы. Но мы домыслим это

$ cat protemac.log | grep pkgExtractor | cut -c 58- | sort

Получаем вывод (фрагмент):

///Applications/ProteMac Meter.app/Contents/.BC.50Myi7
///Applications/ProteMac Meter.app/Contents/.BC.XLbB01
///Applications/ProteMac Meter.app/Contents/Autolauncher/.BC.Spuh6S
///Applications/ProteMac Meter.app/Contents/Frameworks/CocoaEx.framework/Versions/A/.BC.JQH5kN
///Applications/ProteMac Meter.app/Contents/Frameworks/CocoaEx.framework/Versions/A/Resources/.BC.EcX4rG
///Applications/ProteMac Meter.app/Contents/Frameworks/CocoaEx.framework/Versions/A/Resources/.BC.M3gUoL
///Applications/ProteMac Meter.app/Contents/Frameworks/CocoaEx.framework/Versions/A/Resources/.BC.PGgSvo
///Applications/ProteMac Meter.app/Contents/Frameworks/CocoaProtector.framework/Versions/A/.BC.pbZPB2

После недолгих размышлений получаем перечень файлов и каталогов, которые нужно удалить при деинсталляции:

/Applications/ProteMac Meter.app/
/Library/LaunchAgents/com.protemac.MeterAutolauncher
/Library/ProteMac/
/System/Library/Extensions/AirGrabFirewallModule.kext/
/System/Library/LaunchDaemons/com.protemac.Daemon

Что нам и требовалось.

Проверка правильности

Для проверки посмотрим, что делает деинсталлятор, поставляющийся с программой. Делаем “Second Click” на деинсталляторе, смотрим скрипт uninstall.sh в каталоге “Contents/Resources”:

Обратите, кстати, внимание на комментарии разработчиков :-) Наш анализ был верен – мы вычислили все файлы.

#!/bin/sh

rm -Rf "/Applications/ProteMac Meter.app"
rm -Rf "/Library/LaunchAgents/com.protemac.MeterAutolauncher"

# Наследие от старых версий
rm -Rf "/System/Library/LaunchDaemons/com.protemac.MeterDaemon"

# А это уже новые прибабахи :)
rm -Rf "/Library/Receipts/install.pkg"

cd "/Library/ProteMac/ProteMac NetServices.bundle/Contents/tools"

./removeAppFromList.sh "ProteMac Meter"
./isCanBeRemoved.sh

if [ $? -ne 0 ]; then
	exit 0
fi

cd /

rm -Rf "/System/Library/LaunchDaemons/com.protemac.Daemon"
rm -Rf "/System/Library/Extensions/AirGrabFirewallModule.kext"
rm -Rf "/Library/ProteMac/ProteMac NetServices.bundle"

Замечание по усовершенствованию

Также необходимо удалить системные файлы, генерируемые системой, такие, как кеши и т.п.

А для быстрого просмотра содержимого инсталлятора рекомендую удобную программу Pacifist.

Более правильно было бы отслеживать не обращение к файлам, а именно запросы на создание файлов и каталогов. Причём записывать не весь лог, а только активность исталлятора и его дочерних процессов. Но цель статьи была демонстрация метода, и этот метод можно развивать до достижения совершенства. Немного исследования, работы, тестирования, и можно выпускать свою программу.

Disclaimer

Dear ProteMac! In my article I have analyzed only common questions about your installer program. It is not a reverse engineering of your software. I respect your work. Однако судя по комментариям в деинсталляторе, идущем в комплекте с ProteMac, можно было эту фразу написать по-русски ;-)