Я нахожусь в процессе миграции дюжины учетных записей пользователей с одного старого сервера под управлением Mac OS X 10.10.5 Yosemite и Server 5.015 - машина называется server-2015.example.com
Новый сервер работает под управлением macOS 10.13.4 High Sierra и Serve 5.6 - машина называется server-2018.example.com
Вместо того, чтобы выполнять автоматическую миграцию, я перемещаю вещи вручную, чтобы гарантировать, что настройки-трюки не тянутся.
Передача календаря Server-2018 доставляет мне неприятности. Кажется, что делегирование ресурсов работает (например, user1 и users2 являются членами группы, которая является делегатом ресурса конференц-зала), но пользователи не могут надежно делегировать друг друга, как это возможно при использовании Server-2015. Попытки добавить делегата с помощью Calendar.app (Настройки ->. Учетные записи -> Delgation -> Edit) иногда бывают успешными, но иногда приводят к ошибке "нет такого человека" или даже к ошибке "этот сервер не поддерживает делегирование".
(Обновление - ошибка "нет такого человека", по-видимому, является результатом того, что некоторым учетным записям пользователей не присвоен адрес электронной почты - когда им присваивается адрес электронной почты, Calendar.app с радостью предоставит им статус делегата.)
Сначала я подумал, что это проблема OpenDirectory - старый сервер использовал OpenDirectory для учетных записей пользователей и групп, но я не включил новый сервер, полагая, что мне не нужно ничего из того, что он предоставил. Поскольку в некоторых случаях делегирование работает, это не проблема, верно?
Я видел некоторые комментарии, что система календаря чувствительна к конфликтам имен хостов и обратных DNS.
Единственное, что может быть проблемой, которую я не смог отследить, это то, что обратный DNS для сервера не соответствует ожиданиям. Возможно, совершенно не связанный, сервер, кажется, держит старое имя хоста.
Сервер-2018 предоставляет DNS для локальной сети, в том числе и для себя. IP-адрес сервера - 192.168.133.253, и в DNS есть запись A для server-2018.example.com, которая указывает на это. Server.app имеет имя хоста 2018.example.com, а обратная зона имеет запись PTR для 192.168.133.253, для которой установлено значение server-2018.example.com. Однако, когда я делаю «nslookup 192.168.133.253» или «dig -x 192.168.133.253», я получаю старое имя хоста для сервера, а именно server-2018-e.example.com (в какой-то момент у меня были имена хостов, чтобы различать ethernet и интерфейсы аэропорт /WiFi - таким образом, 2018-е и 2018-названия).
Я удалил имя хоста server-2018-e из любого места, где я могу его найти: DNS-записи сервера, нет записей PTR, A, MX или CNAME для server-2018-e.
"Имя хоста", указанное в Server.app -> Обзор - server-2018.example.com
"Имя компьютера", указанное в Server.app и в "Системных настройках" -> "Общий доступ", является server-2018-example-com
Я очистил кэш DNS в системах, которые я использую для поиска с помощью команды "sudo killall -HUP mDNSResponder"
Я не могу найти, откуда взялся этот долбанный сервер2018-e.example.com? Есть ли какое-то глубоко скрытое место, где программное обеспечение Server.app сохраняет старое имя хоста?
Я выключил и перезапустил DNS-сервер на сервере-2018, а также включил и отключил питание оборудования.
Все "scutil --get HostName" и "scutil --get LocalHostName" и "scutil --get ComputerName" дают ожидаемые результаты, без "2018-e" в них.