CityCat4

Я Вас разачарую до невозможости...

Админство - это набор практик. И как всякая прикладная дисциплина, вне конкретных задач она не существует. И все руководства на эту тему - это просто более-менее связное изложение этих практик - как поставить ось, как настроить то, как настроить се, как сделать то, как сделать это, "и почему енот и крот танцуют танго и фокстрот"... Да, есть некий образовательный минимум - но для него Вам надо не Немет сотоварищи читать, а Олиферов. Если же Вы знаете кто такие Олиферы и о чем они пишут - значит ничего читать не надо, нужно ставить задачу и начинать ее решать. И вопросы, возникающие по ходу решения, изучать.
Собственно, это и есть системное администрирование :)

agentless мониторинг невозможен. Чтобы знать, что делается в виртуалке, нужно там иметь "своего человека", иначе Вы похожи на человека, который стоит перед закрытой дверью и пытается на основе шума за ней, а также подсчета входящих-выходящих людей понять, чем заняты в помещении...
Посмотрите советский фильм "Бармен из Золотого Якоря". Сам фильм посредственный. Но в нем есть идея - целая шпионская операция проворачивается ради установки агента (датчика)!

Нет.

Единого стандарта на конфигурационные файлы нет.

Да, в большинстве случаев, это просто var = value со знаком # в качестве комментария. Но в качестве комментария может быть и ; и // и даже /* */, а в качестве переменных куски кода на С, PHP, Perl или даже виндовые ini-файлы (с секциями в квадратных скобках). Кроме того, это вовсе даже не обязательно могут быть текстовые файлы, а вполне могут оказаться db- или sqlite- базы данных (как например в sendmail)

FEATURE(allmasquerade)
FEATURE(masquerade_envelope)
FEATURE(local_no_masquerade)

MASQUERADE_AS(`deltahw.ru')

Вот этого обычно достаточно. local_no_masquerade можно не указывать, если нет в DMZ другого локального сервера.
Я надеюсь, выше приведен кусок sendmail.mc, а не он весь -потому что если это он весь, то работать он не будет :)

Если на удаленном сервере отключена возможность логина рутом, то хоть на голове стой - рутом не подключиться. Нужно подключаться обычным юзером, а потом su или sudo.

Для паролей браузера - встроенное хранилище FF + blur. Для паролей, связанных с TDE - Kwallet, для прочих - моск :)

А с чего Вы решили, что кто-то будет Вам инструкции писать? Это Ваш сервер, что нам нем лежит, то и отображается, никто никаких инструкций Вам писать не будет.
Одну директорию перевести не получится - https это отдельный сервер с отдельным дополнительным набором настроек, касающихся шифрования, сертификатов etc. Его можно распространить только на одну директорию, но все равно это будет отдельный сервер.

"Доменный" компьютер - это тот, который имеет учетку в домене. Учетка в домене нужна чтобы как минимум проходила аутентификация через керберос, без ввода пароля. Именно этот факт - без ввода пароля и есть признак - "доменный" или "чужой".
"Чужой" тоже может получить список пользователей и даже аутентифицировать юзеров, но для этого ему самому сначала надо в домене аутентифицироваться. Обычно это делается созданием фейкового юзера, не имеющего никаких прав и имеющего простой текстовый пароль. Пароль этого юзера указывается в конфиге в открытом виде. Так работает аутентификация через апач (AuthBasicProvider ldap), так работает PAM-модуль pam_ldap.so и NSS-модуль nss_ldap.so, так может работать аутентификатор squid. Так работает любой скрипт на Perl/PHP, которому нужно аутентифицировать юзеров в AD - redmine, horde, любой велосипед, использующий Net::LDAP.
Конечно, это неудобно и небезопасно. Поэтому и создают учетки компам в AD, настраивают керберос через ktpass и полученный keytab сбрасывают на линух - так например делают для squid.
Аутентифицироваться в домене можно и не заводя учетку. Но логин и пароль хоть какого-нибудь юзера из домена комп, который аутентифицируется, должен знать.

Я обычно использую такую схему - (обьект)_(роль)_(выдавший CA). Обьект - это либо логин для юзера, либо hostname без доменной части для сервера. Роль - либо client, либо server. Выдавший CA - короткое наименование СA, выдавшего сертификат. Раньше для серверов использовал только (hostname), но в этом случае реально возникает путаница.

Один.
Настроить нельзя. В sftp нет понятия параллельного потока.

Можно :)
- Установить (а если есть, просто запустить) систему виртуализации - говорят есть и не одна.
- Скачать дистриб линуха (предвидя вопрос - какой, сразу отвечаю - новичкам рекомендуют бубунту или минт)
- Создать виртуальную машину, подключить дистриб, установить линух
- ПРОФИТ!

В wine работает далеко не все. Простая программа скорее всего заработает. Сложная - скорее всего нет, если только wine специально не оптимизировать. Запускал winbox - среду настройки устройств Mikrotik - все работает замечательно. Пробовал vSphere client - не работает. Ставится, но не работает. Игры не работают практически никакие, за исключением единиц, даже старые, образца 2000 - 2002 года. Запустил Горький-18 (и снова его прошел:) ), запустил Fallout Tactics. Silent Storm, Sentinels, Серп и Молот, Власть закона - не заработали. Последняя установилась, запускается общее меню, но не грузится боевая арена.

Сталкивался я с такой проблемой, когда пытался архивировать на FreeBSD файлы, лежащие на примонтированной виндовой шаре. Решения я не нашел, пришлось велосипедить - сделал несколько патчей на tar :) и он при архивировании имена файлов перекодировал из koi8-r в что скажешь.
Давным-давно я в том месте не работаю, но патчи где-то сохранились, если надо - мыло в профиле.

Ну, у меня давно-давно, года наверное с 2000 работает велосипед. Писался он для FreeBSD, но после небольшой доработки взлетел на линухе. Правда он решает задачку посложнее - копировать весь указанный каталог (или БД, правда понимает только мускл) в точку А, причем в точке А предыдущая информация может как затираться так и не затираться.
Собственно bash по крону запускать бессмысленно - простую команду можно непосредственно записать в кронтаб, сложную - в файл скрипта и имя этого файла - в кронтаб. Где кронтаб? В /etc как правило есть файл crontab, но это "корневой" кронтаб, который я обычно избегаю править. В /etc/cron.d можно создавать файлы типа

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
*/30 8-17 * * 1-5 root /usr/sbin/my.super.script

Пример немного нетривиальный и означает он, что по рабочим дням (1-5) с 8 до 17 часов раз в полчаса (*/30) будет запускаться my.super.script

Первая запись означает "Запускать команду /command каждую минуту каждого часа 1,10,20,30 числа каждого месяца каждого дня недели".
Вторая запись означает "Запускать (неуказанную команду) в 0 минут 0 часов с 27-го по 31 число каждого месяца каждого дня недели"
Поля в кронтабе идут в следующем порядке:
- Минута (0-59, ведущий ноль можно не указывать)
- Час (0-23, про ноль тоже самое)
- Число месяца (1-31)
- Месяц (1-12)
- День недели (0-6, 0 - воскресенье)
Если в поле указана * - это означает "любой". Если в поле указано */(число) - это означает "раз в (число) единиц", например */15 в первом поле - раз в пятнадцать минут.

И обо всем это можно прочитать в man crontab :D

Насчет опытного товарища совершенно согласен с Victor Alenkov . Если опыта работы с линухом нет - что-нибудь "дружественное" (и тут же в голову приходит "бубунта" :D Ее вроде как самой дружественной считают :) )