Следующая проблема может рассматриваться как проблема, связанная с CIFS / AD (конкретное представление) или как вопрос о перезапусках службы, обработке ошибок и синтаксическом анализе журнала (общий вид). Я представлю здесь обе области, но был бы рад получить ответы по любому из них (просто пропустите части, которые вас не интересуют).
. В Active Directory, совместимой с Windows Server 2008, обычно имеется несколько контроллеров домена для обеспечения высокой доступности. Если все эти серверы одновременно недоступны и загружается файловый сервер OmniOS (r151018) с активным SMB / CIFS-сервером ядра (который успешно присоединен к домену и работает должным образом), происходит следующее:
Служба idmap
пытается связаться с контроллером домена в течение 60 секунд, а затем отказывается ...
root@omnios:/root# tail -n 20 /var/svc/log/system-idmap:default.log
@ Tue Sep 6 10:19:42 2016
Global Catalog servers not configured/discoverable
Domain controller servers not configured/discoverable
created thread ID 3 - 1 threads currently active
[ Sep 6 10:19:42 Method "start" exited with status 0. ]
@ Tue Sep 6 10:19:53 2016
created thread ID 4 - 2 threads currently active
getdcname wait begin
@ Tue Sep 6 10:19:57 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
@ Tue Sep 6 10:20:08 2016
getdcname timeout
@ Tue Sep 6 10:20:12 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
@ Tue Sep 6 10:20:27 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
@ Tue Sep 6 10:20:42 2016
DNS: _ldap._tcp.dc._msdcs.testdomain.intranet: Host name lookup failure
Domain discovery took 60 sec.
Check the DNS configuration.
... но не завершается критически:
root@omnios:/root# svcs -xv idmap
svc:/system/idmap:default (Native Identity Mapping Service)
State: online since Tue Sep 6 10:19:42 2016
See: man -M /usr/share/man -s 1M idmapd
See: man -M /usr/share/man -s 1M idmap
See: /var/svc/log/system-idmap:default.log
Impact: None.
После этого smbd
жалуется ( правильно) в системном журнале каждую минуту, когда он не может найти DC:
smbd[525]: [ID 510351 daemon.notice] smb_locate_dc status 0xc0000233
smbd[525]: [ID 199031 daemon.notice] smbd_dc_update: testdomain.intranet: locate failed
Это сохраняется даже после того, как DC снова в сети и становится доступным. Это устраняется мгновенно путем перезапуска idmap
с помощью svcadm restart idmap
. Конечно, поскольку эти сбои могут произойти без планирования, это не должно происходить вручную.
idmap
для автоматического выполнения при этих событиях? Я пробовал использовать SMF, но кажется, что это работает только для аварийных служб, в то время как idmap
не сообщает о проблемах (а smbd
сообщает только уведомления). Еще одна возможность - постоянно отслеживать файлы журналов и искать события с помощью grep, но мне это кажется неэффективным. Я также попытался уменьшить значение config / rediscovery_interval
до 60 секунд, но кажется, что оно игнорируется (или не применяется здесь). idmap
также перезапускается там). Изменить: Вывод svccfg -s idmap listprop
- единственное, что я изменил, это config / rediscovery_interval
(по умолчанию 3600), идентификаторы были впоследствии удалены вручную.
config application
config/id_cache_timeout count 86400
config/list_size_limit count 0
config/name_cache_timeout count 604800
config/preferred_dc astring
config/stability astring Unstable
config/use_ads boolean true
config/use_lsa boolean true
config/value_authorization astring solaris.smf.value.idmap
config/machine_uuid astring [...]
config/machine_sid astring [...]
config/rediscovery_interval count 60
config/domain_name astring testdomain.intranet
debug application
debug/all integer 0
debug/config integer 0
debug/discovery integer 0
debug/dns integer 0
debug/ldap integer 0
debug/mapping integer 0
debug/stability astring Unstable
debug/value_authorization astring solaris.smf.value.idmap
rpcbind dependency
rpcbind/entities fmri svc:/network/rpc/bind
rpcbind/grouping astring require_all
rpcbind/restart_on astring restart
rpcbind/type astring service
filesystem-minimal dependency
filesystem-minimal/entities fmri svc:/system/filesystem/minimal
filesystem-minimal/grouping astring require_all
filesystem-minimal/restart_on astring error
filesystem-minimal/type astring service
manifestfiles framework
manifestfiles/lib_svc_manifest_system_idmap_xml astring /lib/svc/manifest/system/idmap.xml
general framework
general/action_authorization astring solaris.smf.manage.idmap
general/entity_stability astring Unstable
general/single_instance boolean true
general/value_authorization astring solaris.smf.manage.idmap
start method
start/exec astring /usr/lib/idmapd
start/timeout_seconds count 60
start/type astring method
stop method
stop/exec astring :kill
stop/timeout_seconds count 60
stop/type astring method
refresh method
refresh/exec astring ":kill -HUP"
refresh/timeout_seconds count 60
refresh/type astring method
tm_common_name template
tm_common_name/C ustring "Native Identity Mapping Service"
tm_man_idmapd1M template
tm_man_idmapd1M/manpath astring /usr/share/man
tm_man_idmapd1M/section astring 1M
tm_man_idmapd1M/title astring idmapd
tm_man_idmap1M template
tm_man_idmap1M/manpath astring /usr/share/man
tm_man_idmap1M/section astring 1M
tm_man_idmap1M/title astring idmap
Эту проблему можно обобщить на вопрос , как наиболее эффективно просматривать файлы журнала в Solaris . Я искал и нашел несколько инструментов, таких как swatch
, logsurfer
, logwatcher
, или простое старое задание cron, выполняемое каждую минуту и подключенное к простому сценарию, который считывает вывод dmesg
.
Спасибо за подробное описание этой проблемы в вопрос. Я недавно тоже столкнулся с этим, с оговоркой, что контроллер MS AD - это виртуальная машина, работающая на (пост) хосте OpenSolaris, и поскольку поддержка Win / AD уменьшается на этом сайте, это единственная сохранившаяся реплика. Поэтому, когда он находится на ранней стадии загрузки (а idmap является частью дерева зависимостей, ведущего к многопользовательскому серверу), виртуальная машина еще не работает, и idmap не может связаться с ней, как вы написали, и smbd жалуется. Думаю, это лучше, чем невозможность полностью загрузить сервер из-за сбоя при контакте с AD.
Я думаю, что в качестве прямого ответа на ваш вопрос есть и другие демоны регистрации :) Например, rsyslog может запускать команды, если зарегистрированный сообщение соответствует некоторому шаблону, который вы установили.
Поскольку журналы SMF svc не цитируют системные журналы, я думаю, что для этой ситуации нужно было бы создать специальный сценарий, чтобы проверить конкретный журнал и перезапустить службу.
Также может выполнять отложенное действие (например, сценарий инициализации, который выводит эхо «svcadm restart idmap» | сейчас + 10мин
), чтобы всегда запускать это после загрузки, что, я думаю, именно то, что я сделаю здесь.
Наконец, можно добавить некоторую активность в сценарий запуска виртуальной машины, чтобы активировать idmap после загрузки виртуальной машины (и поэтому не полагаться на чисто жестко запрограммированное время) - но не как часть дерева зависимостей SMF, поскольку idmap является необходимо так рано при загрузке ... или, по крайней мере, не как строгая зависимость, а что-то вроде restart_on ...