Sysinternals PsExec должен позволить Вам выполнить команду такой какpsexec @deploy.list msiexec /qn /i \\fileserver\installer\packagetoinstall.msi
.
Кто-либо еще хочет прокомментировать детали? Или Вы могли задать 2-й вопрос, более характерный для этого метода.
Мое предположение - то, что существует что-то в зональном файле в формате, немного отличающемся от того, что ожидает Администратор Сервера (хорошо, технически servermgrd) - я видел, что он запутывается чем-то столь же простым как "неправильное" количество пробелов между полями.
Для поиска и устранения неисправностей его я предложил бы удалить все из зонального файла (тот в/var/named/zones) ниже записи SOA, за исключением записей NS (Вы сказали, что у Вас есть резервное копирование, правильно?). Это должно выглядеть примерно так:
;GUID=34FEA604-B204-A7D7-95A5-B6D812B46454
$TTL 10800
example.com. IN SOA server.example.com. admin.example.com (
2010042600 ;Serial
86400 ;Refresh
3600 ;Retry
604800 ;Expire
345600 ;Negative caching TTL
)
example.com. IN NS server.example.com.
примечание: Я не уверен, но я думаю, что должна быть пустая строка в конце файла. Если необходимо сохранить нормальный сервис DNS при поиске и устранении неисправностей, можно переместить другие записи на другой зональный файл - тот в/var/named - где названо будет обычно читать их, но servermgrd не посмотрит.
Так или иначе, с зональным файлом, обрезанным к минимуму, выходу и Администратору Сервера перезапуска и, видят, ведет ли он обычно себя (т.е. можете Вы просматривать журнал, добавлять записи в зону, и т.д.). Если это обычно работает, попытайтесь добавить записи назад в/var/named/zones файл снова понемногу - я подозреваю, что один или несколько из них является немного странным и если Вы пропускаете его (т.е. воссоздайте его от Администратора Сервера вместо того, чтобы добавить к зональному файлу непосредственно), можно, вероятно, вернуть вещи к нормальному.
В пятницу я решил, что удалю DNS и восстановлю его. (Вздох).
Лучшие инструкции относительно запуска были, которые я нашел здесь, хотя я нашел, что должен был сделать немного больше, чем было указано там.
Во-первых, я создал резервную копию DNS (как упомянуто в вопросе в вершине).
Я выключил DNS. (Ну, я значил для. Я повернул его от шага или два позже, но это - когда я думаю, что это должно быть выключено.)
Я отредактировал /etc/dns/publicView.conf.apple
для удаления названий всех зон, мы создали при оставлении нетронутым те, что мы не создали. Вот файл с большим комментарием в середине, где все зоны были. (Я на самом деле не поместил комментарий в файл; я просто удалил записи).
acl "com.apple.ServerAdmin.DNS.public" {192.168.1.254;192.168.5.254;192.168.10.254;192.168.15.254;192.168.20.254;192.168.25.254;192.168.30.254;192.168.35.254;192.168.40.254;192.168.45.254;192.168.55.254;192.168.75.254;192.168.70.254;192.168.80.254;localnets;192.168.65.251;192.168.65.185;192.168.80.0;192.168.65.253;}; // // This is the view that is shown in Server Admin // This is an automatically generated file. // PLEASE DO NOT MANUALLY MODIFY THIS FILE! // Please make your changes in the named.conf file // view "com.apple.ServerAdmin.DNS.public" { //GUID=3EA358EF-5C55-4619-98D0-5004B310D1B0; allow-recursion {"com.apple.ServerAdmin.DNS.public";}; // ------------------------------------------------------------- // THERE WERE SEVERAL ZONES HERE IN THE FILE THAT WE HAD CREATED // I DELETED THEM ALL. // THE FOLLOWING ZONES DID NOT LOOK LIKE ONES WE CREATED, SO I LEFT // THEM IN TACT // ------------------------------------------------------------- zone "." { type hint; file "named.ca"; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; }; };
Сделав это и перезапущенный DNS, Администратор Сервера все еще не был счастлив. Выключая DNS снова, я вошел /var/named
и /var/named/zones
папки и удаленный все файлы создаются нами. Список прежде (и после) /var/named
похож на это:
db.100.168.192.in-addr.arpa. db.15.168.192.in-addr.arpa. db.20.168.192.in-addr.arpa. db.203.244.66.in-addr.arpa. db.34.168.192.in-addr.arpa. db.40.168.192.in-addr.arpa. db.5.168.192.in-addr.arpa. db.55.168.192.in-addr.arpa. db.65.168.192.in-addr.arpa. db.75.168.192.in-addr.arpa. db.somedomain.ab.ca. db.anotherdomain.net. localhost.zone named.ca named.local zones/
Я уехал localhost.zone
, named.ca
, named.local
и zones
папка, и удаленный все остальное. (sudo rm db*
).
/var/named/zones
папка выглядела очень похожей, но не делает (появитесь к), содержите любые файлы, которые не были созданы администратором сервера, таким образом, sudo rm db*
удаленный все.
На данном этапе я перезапустил DNS (и вероятно перезагрузил), и мог работать с Администратором Сервера снова.
Теперь я должен был повторно заполнить все наши записи DNS. К счастью, резервные копии /var/named/db.{$DOMAIN}.
(один файл для каждого домена), заставил его действительно очистить то, что должно было быть сделано для воссоздания доменов, будучи просто списком названия хоста, типа записи и IP-адреса, таких как это:
... silo IN A 192.168.100.254 old IN A 192.168.100.116 psmain IN A 192.168.100.121 mail IN CNAME ghs.google.com. ...
Я был двумя третями пути посредством воссоздания обоих из наших доменов, когда, внезапно, Администратор Сервера показал ту же проблему, я запустил с - а именно, больше нельзя было использовать его, чтобы отобразить или отредактировать зоны. О, человек!
Последняя запись хоста, которую я вставил, была ftp
. Я решил видеть, обнаружилось ли это в каком-либо из файлов:
$ cd /private/var/named/zones $ grep -R --include "*" ftp . ./db.somedomain.ab.ca.zone.apple:ftp IN A 192.168.100.254 ./db.somedomain.ab.ca.zone.apple:ftp IN TXT "Was pointing to webserver (192.168.100.116), now pointing to silo (192.168.100.254)."
Я удалил те две строки, и Администратор Сервера был счастлив снова. (Слава Богу).
Проблема, кажется, комментарий для FTP-сервера. (Мы используем очень немного комментариев; были только два, и я не видел оснований для не создания их. Я полагаю, что проявлю больше заботы в будущем.), Возможно, это - потому что комментарий содержал IP-адреса.
(Существует также ничтожный шанс, что FTP-сервер, будучи записью на машину, которая уже имела запись, вызвал проблему, но это кажется мне довольно вряд ли.)
Я воссоздал запись ftp как CNAME и не вставил комментарий.
Размышление на нем позже, изменение записи FTP-сервера были наиболее вероятными последнее изменение, которое мы внесли в DNS несколько недель назад.
Я закончил восстановление всех хостов и проверил мою работу:
mkdir DNSDiff && cd DNSDiff
# repeat for each domain
cat /path/to/backup/var/named/zones/db.somedomain.ab.ca.zone.apple | sort > old.somedomain.txt
cat /var/named/zones/db.somedomain.ab.ca.zone.apple | sort new.somedomain.txt
diff --side-by-side {old,new}.somedomain.txt
# or, with TextWrangler,
twdiff *.somedomain*
# (or, use the diff tool of your choice.)
DNS, кажется, хорошо работает теперь.
IN TXT
(в противоположность двум пробелам в IN A
). У меня нет 10,5 серверов для тестирования с, но я попробовал по существу это на 10,6, и они не испытывали затруднений (они только поместили одно пространство в файл, но не были перепутаны при чтении файла назад).
– Gordon Davisson
23 June 2010 в 21:24
Я обнаружил и исправил аналогичную проблему на нашем сервере MacOS X 10.5.
Оказалось, что это круглые скобки "(" и ")" в текстовом поле в одном из DNS файлы зоны. Я использовал текстовый редактор в командной строке, чтобы удалить круглые скобки, и теперь Server Admin снова работает нормально.
В версии 10.5 файлы зон расположены в / var / named / zone
.
Используйте команду grep для поиска в файлах зоны символа ")":
sudo grep -R --include "*" \) .
Прокрутите вывод и найдите что-нибудь необычное. (Все файлы зон будут иметь открывающую и закрывающую круглые скобки вверху; вы ищете запись в файле.) Если вы ничего не найдете, вы также можете найти открывающую скобку с помощью grep.
Когда вы нашли подозрительный файл, откройте его для редактирования:
sudo nano db.mydomain.zone.apple
Найдите строку, вызывающую нарушение, и удалите символы скобок. Сохранить и закрыть. Перезапустите Server Admin.
Могут быть и другие оскорбительные символы, но в моем случае это всегда были круглые скобки.