Можно привязать. Правда, всё зависит от того, в каком порядке запускаются сервисы — сервис драйвера WiFi должен стартовать и быть функциональным раньше Winlogon и его службы входа.
В логах KDC обнаружил, что клиент пытается получить тикет для HTTP/srv.mydomain.smth.ru, т.е. CNAME хоста, а имя сервиса — HTTP. Информацию о том, какого сервиса ловить, сервер клиенту не предоставляет, используется well known, в данном случае HTTP.
Сделал такого принципла, выгрузил его в keytab, убрал KrbServiceName http — всё заработало.
Не помогает. Такое впечатление, что он даже и не пытается. Подскажите, заголовки первого ответа (что нужна аутентификация) мне правильные сервер выдаёт?
Нет, даунтайма не будет. Можно делать проверку на лету с помощью RAID Web Console 2 (есть на диске к материнке и можно скачать с сайта).
Вообще покопайтесь в этой консоли — настройте уведомления на почту и т. п…
Ещё есть одна неприятная тонкость: RFC822 и всех его наследников, в том числе 5322 не читали разработчики из Rit Labs. Как следствие, The Bat не знает про то, что восьмибитные символы там не допускаются, и пихает их туда. В этом случае кодировку заголовка остаётся только угадывать. Некоторые особо продвинутые почтовые серверы исправляют это, есть два способа: забить XXXXX (cyrus) и попытаться угадать кодировку и перекодировать; оба способа ломают подпись письма. Короче, не используйте Bat и всех уговаривайте не использовать, он базовых стандартов 20-летней давности, до сих пор актуальных, не знает.
хм. Подумал сам и понял. Maximum Concurrent Jobs для клиента установить 2, для стораджа — 1. Тогда собственно копирование в сторадж сериализуется, а если в задании есть что-то помимо этого копирования — например, RunBeforeJob и т. д. — они не задействуют сторадж и смогут выполняться, пока другое задание задействует его.
Ну, grub, положим, ничего не монтирует — он загружает ядро и initramfs в память и передаёт управление вместе с командной строкой.
В общем, второй раз-то монтировали тот же самый block device? Если да, то очень зря — на такое использование рассчитаны только кластерные ФС (типа ocfs), а e* — не рассчитаны и с большой вероятностью серьёзно портятся.
Если надо получить «то же самое содержимое», но без навешанных сверху точек монтирования, делайте bind:
mkdir /mnt/root
mount -o bind / /mnt/root
В этом случае, в /mnt/root у вас будет содержимое корневой ФС, а вот /mnt/root/mnt/root, а также /mnt/root/dev, /mnt/root/proc, /mnt/root/sys и прочее будут пустыми директориями, т.к. bind привязывается к конкретной ФС а не к элементу VFS.
Не знаю про openssh, а в openssl действительно есть места с warning. Намеренно оставленные, чтобы добавить случайности. т.е. это warning с точки зрения компилятора, а программисты знали, что делали, и намеренно использовали неинициализированные переменные.
Смысл в секретной фразе — чтобы если сопрут ваш приватный ключ, не смогли подключиться к вашим хостам. Ведь он зашифрован, кажется, AES, а ключ — та самая секретная фраза.
И приходится каждый раз её вводить — для подключения к удалённому хосту ключ надо расшифровать.
Это всё равно надёжнее, чем пароль — ведь пароль-то вы высылаете хосту на проверку, хотя бы и по зашифрованному каналу; а вот с ключами вы никаких своих секретов не выдаёте.
А чтобы каждый раз не вводить эту самую секретную фразу, придумали ssh-agent. Схема такая: вошёл в систему — автоматом запустился ssh-agent, в окружении появились переменные, как его найти. Теперь вы делаете ssh-add, один раз пишете секретную фразу — ключ расшифровывается и попадает в кэш агента. Теперь любые команды ssh будут (по окружению) автоматически находить агент и подхватывать ключ, ничего у вас не спрашивая.
Это касается вообще любых ssh-подключений, а не только собственно оболчки: scp, vncviewer в тоннеле (с ключом -via), virt-manager и т. д.
Eddy_Em, это полная чушь. Они никак вообще не зависят друг от друга.
ssh-agent хранит расшифрованный приватный ключ в памяти, чтобы вам каждый раз не расшифровывать его (не вводить секретную фразу)
ssh-copy-id дописывает приватный ключ r ~/.ssh/authorized_keys удалённого хоста. При этом он как-то аутентифицируется на том хосте, т.е. спросит у вас либо пароль от того хоста, либо потребуется какой-нибудь ключ, который есть на удалённом хосте — неважно, в ssh-agentе он или в файле лежит, тогда ещё потребуется расшифровать.
ПФР и налоговая делают совершенно правильно. Законодательство постоянно меняется, по факту отчёт, выполненный прошлогодней программой, будет неправильным и наверняка, используя её, вы нарвётесь на штраф.
Если сервер настроен правильно, вы никак не получите все записи из зоны. Тем более, все записи на сервере. Разве что перебрать все возможные (как вы догадываетесь, это нереализуемо).
