Нарешті переїхав на OS X Server v3

Опублікував Сергій Макаренко 3-07-2014 об 12:12

Ви будете сміятися, але задача по переїзду на OS X Mavericks та OS X Server третьої версії для мого Mac mini Server мала закінчитися ще 17 жовтня 2013 року. Але я все відкладав міграцію. В першу чергу через те, що сервер мігрувати це не те, що клієнтську версію OS X оновити. Хоча б через те, що перед міграцію потрібно зробити купу перевірок і, бажано, перевірити як всі сервіси працюватимуть на новій системі. Можливо, хтось і з вас подумає, що такі міри по підготовці надмірні, але мій особистий досвід говорить про протилежне. Якщо не перевірити все перед міграцією то після неї можна ще дуже довго розгрібати проблеми, на усунення причин виникнення яких ви витратите дуже багато часу.

Напевне, дехто з вас зауважить, що Apple зробила прекрасний механізм оновлення системи і нічого не потрібно робити: скачав OS X Mavericks з Mac App Store, запустив оновлення і вуаля. І частково будуть праві. Але це все має рацію стосовно клієнтської версії OS X і до сервера майже ніяк не відноситься. Я свого часу стільки навоювався з глюками після таких оновлень і зараз твердо притримуюсь того правила, що потрібно мігрувати на нову систему без усіляких «хвостів» зі старої і переносити лише користувацькі дані. На користь мого підходу свідчать майже три роки стабільної і беззбійної роботи спочатку севера на базі Snow Leopard, а потім на Mountain Lion.

Не можу сказати, що я зараз в захопленні від того, що зробила с сервером Apple. Зараз це не ентерпрайз рішення, а, скоріше, дуже прокачана версія OS X для домашнього використання або для малого (дуже маленького) бізнесу. Хоча б через те, що раніше Mac OS X Server можна було б віддалено встановити от так. А зараз я встановлюю нову версію OS X так, як це зображено на фотографії нижче. Apple виключила можливість зробити Clean Install дистанційно. І для того, щоб поставити систему з нуля треба до сервера мати фізичний доступ. Стидоба.

Встановлення OS X Mavericks начисто

Але це все полеміка і туга за тим, що вже ніколи не повренеться. Тому я повернувся до вирішення суто практичних питань. У мене була задача перенести свою інформацію зі старої версії OS X на нову. Перелік сервісів у мене був таким:

  • Контакти з власного Jabber;
  • Налаштування DNS;
  • Образи NetInstall;
  • Налаштування web-сервера на якому хоститься мій блог, файлова помийка для роздачі своїх картинок в інтернет і ще кілька сайтиків;
  • Потрох власного RSS-агрегатора Feedafever;
  • База OmniFocus, яка синхронізується через WebDAV;
  • Сертифікати сервера. Я викорстовую сертифікати StartSSL для того, щоб захищати деякі з'єдання з сервером (наприклад, jabber або https доступ до деяких сайтів).

Перед переїздом потрібно було виконати деякі підготовчі роботи. І це все настільки було не зручно тримати в голові, що я вирішив написати документ по міграції. Він вийшов в мене не дуже великим, всього сім сторінок. До речі, у Apple є хороший зразок такого документа, але для моїх цілей цілком вистачало функціональності Time Machine і у мене не було зайвого зовнішнього HDD потрібного об’єма для того, щоб зберігати на ньому образ старого диска сервера.

Після того, як резервні копії було зроблено я перевірив кожну з них на цілісність і провів кілька розгортань на віртуальній машини для того, щоб впевнитись в тому, що вони робочі (як відомо, системні адміністратори поділяються на три категорії: ті, хто не роблять резервних копій; ті хто вже робить резервні копії і ті, хто резервні копії перевіряє на цілістність даних). Після цього я дослідив структуру Messages server на новій системі для того, щоб зрозуміти чи змінилася структура SQLite БД і якщо змінилася, то що потрібно зробити для того, щоб перенести її вміст в нову базу. В результаті своїх досліджень я дійшов того, що не змінилося нічого і взагалі Messages server в OS X Server v3 простий як двері і цого можна ґвалтувати вздовж і поперек без ризику втрати даних (зокрема, під час свої експериментів знайшов кілька корсних статей на сайті підтримки Apple: раз, два та три). В принципі, це був єдиний стримуючий фактор і після цього я почав процесс перенесення даних.

Під час налаштування сервера я, знову таки, згадав про важливі речі, про які адміністратору OS X Server забувати не варто. Найголовніша служба в OS X Server — це DNS. Друга за важливістю — це Open Directory. І якщо з вашими сервісами щось не так, то слід причину шукати спочатку в налаштуваннях цих служб, а вже потім в самому сервісі. Мене спідкала невдача саме на роботі Open Directory. Під час створення Open Directory Master OS X Server сказав мені, що процес створення пройшов вдало і все ок, але виникла якась невідома помилка. Про це я згадав тоді, коли налаштовував Messages server. Стара база піднялася і нормально почала «жити». Про це красномовно свідчили логи Messages server:

Jul  3 11:13:23 my.server.name jabberd/s2s[440]: [20] [::ffff:184.73.173.246, port=11275] incoming route 'jabber.makarenko.me/smileart.in.ua' is now valid, TLS negotiated
Jul  3 11:13:23 my.server.name jabberd/s2s[440]: [17] [184.73.173.246, port=5269] outgoing route 'jabber.makarenko.me/smileart.in.ua' is now valid, TLS negotiated
Jul  3 11:23:21 my.server.name jabberd/s2s[440]: [20] [::ffff:184.73.173.246, port=11275] disconnect, packets: 2
Jul  3 11:23:25 my.server.name jabberd/s2s[440]: [17] [184.73.173.246, port=5269] disconnect, packets: 4
Jul  3 11:31:17 my.server.name jabberd/s2s[440]: dns lookup for smileart.in.ua returned 1 result (ttl 60)
Jul  3 11:31:17 my.server.name jabberd/s2s[440]: [17] [184.73.173.246, port=5269] outgoing connection for 'smileart.in.ua'
Jul  3 11:31:18 my.server.name jabberd/s2s[440]: [17] [184.73.173.246, port=5269] sending dialback auth request for route 'jabber.makarenko.me/smileart.in.ua'
Jul  3 11:31:19 my.server.name jabberd/s2s[440]: [20] [::ffff:184.73.173.246, port=12993] incoming connection

Але при спробі залогінитись в Messages за допомогою того користувача, якого я використовував на стрій системі отримав таку помилку:

Jul  2 02:48:08 my.server.name jabberd/c2s[6424]: int ODKVerifyClientRequestFixed(ODKSession *, CFStringRef): Unable to authenticate: Could not verify credentials because directory server does not support the requested authentication method.
Jul  2 02:48:08 my.server.name jabberd/c2s[6424]: Authentication failed, mech: DIGEST-MD5 client IP: ::ffff:10.0.1.2 client port: 52121 username: ?
Jul  2 02:48:09 my.server.name jabberd/c2s[6424]: [9] [::ffff:10.0.1.2, port=52121] disconnect jid=unbound, packets: 0
Jul  2 02:48:21 my.server.name jabberd/c2s[6424]: [9] [::ffff:10.0.1.2, port=52131] connect
Jul  2 02:48:21 my.server.name jabberd/c2s[6424]: int ODKVerifyClientRequestFixed(ODKSession *, CFStringRef): Unable to authenticate: Could not verify credentials because directory server does not support the requested authentication method.

Тут у мене засіпалося око, бо Open Directory мала підтримувати цей тип автентифікації. Шукаючи інформацію про діагностування помилок в роботі Open Directory я натрапив на ось цей сивий документ, в якому, не дивлячись на час, є купа корисної інформації. Команда ldapsearch -LLL -x -h my.server.name -b "" -s base + видала такий результат:

dn:
operatingSystemVersion: 10.9
vendorVersion: 491.1
vendorName: Apple
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=my,dc=server,dc=name
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.1.8
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
supportedLDAPVersion: 3
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: WEBDAV-DIGEST
entryDN:
subschemaSubentry: cn=Subschema

Поборсавшися ще в логах Open Directory я зрозумів, що проблема таки з цією службою і та помилка, про яку мене сповісти в OS X Server ніфіга не невідома. Під час творення Open Directory Master було зламано SASL-фреймворк і автентифікація не працювала належним чином. Після цього відкриття дії були рішучі. Я просто зупинив всі сервіси, які були зав'язані на користувачах з Open Directory (в моєму випадку це Messages server, Profile Manager, Mail, File Sharing та VPN), знищив цю копію і створив новий Open Directory Master. Після цього Messages server завівся з півоберта.

Мораль тут проста. Потрібно завжди пам'ятати про DNS та Open Directory і приділити час для вивчення їх функціональності та методів налаштування. Якщо цими навичками оволодіти і пам'ятати про те, що всі служби в OS X Server зв'язані на цих двох сервісах можна уникнути більшості проблем. Мені тут здається, що, на перший погляд, більш надійна робота Linux викликана там, що переважна більшість служб (VPN, jabber тощо) там обособлені і не зав'язані зі старта на Open Directory або DNS. Якщо це зробити, то можна отримати проблеми, схожі на ті, що з'являються час від часу під час експлуатації OS X Server. Ну і, звісно, переважна більшість проблем виникає через незнання того, як влаштований той чи інший сервіс.

В цій всій ситуації засмучує лише одне. Від покоління до покоління Apple все більше і більше звужує перелік корисної документації і в певний момент деякі проблеми з серверним ПЗ вирішити буде просто неможливо через брак знань. Тут доведеться або відмовитись від його використання, або самостійно займатися вивченням і дослідженням. Скажу відверто, що другий спосіб мені пробувати не хотілося б. Хоча, звичайно, можливо і таке, що коли брак документації стане критичним Apple випустіть версію OS X Server, яка буде супер-надійною і ніколи не ломатиметься.