CityCat4

Вариант сделать скрипт функцией и добавить в .bashrc не устраивает, т. к., во-первых, .bashrc выполняется перед запуском интерпретатора и таким образом при его удлинении увеличивается время ожидания при каждом запуске терминала

Смеетесь, да? Ну удлинится запуск шелла на пару микросекунд - неужто заметите?

Массовое обновление конфигов обычно делается средствами удаленного развертывания - Chef, Puppet. Делать это через ssh, да еще при логине рутом... Если прям нужно именно так, то я бы сделал немного по-другому - создал на каждом серваке юзера, обычного юзера, настроил аутентификацию по ключу, дал ему через sudo права на выполнение некоего скрипта... Механика выходит довольно сложная, Puppet наверное проще будет настроить :)

Можно client.sh доработать таким образом, чтобы он искал запущенную копию и, если нашел, тихо клеил боты с диагностикой, что тапки уже заняты :) Поскольку он видимо графический, можно диагностику даже через какое-нибудь окошко выдавать :)

UPD: Самый простой способ:

var1=`ps -ax | grep client-process-name | grep -v grep`
if [ $#var1 -ne 0 ]; then
   echo 'Тапки заняты!'
   exit 100
fi

Это как раз пример того, что будет, если начать в пакетном дистрибе работать, как в source-based. Поставил бубунту - забудь про сборку из исходников!

Придется решить задачу по ручному вынесению самбы (и скорее всего повторному вводу в домен) и установке ее из пакетов с подсовыванием соответствующим образом правленого конфига от старой.

Своих юзеров у самбы может и не быть - если система настроена на использованием доменных учеток через sssd или через winbindd. Свои учетки - это адЪ.

OMG, да она еще и domain master? Она единственный контроллер домена или же есть еще винда? Если она единственный DC, то нужно быть очень осторожным - база юзеров у самбы хранится в /var/lib/samba (или что-то такое, там много файлов с расширением .tdb). Если эту базу продудонить - все юзера потеряют свои RID-ы и им перестанут быть доступны профили...

1. Чем не нравится приглашение? Это стандартное приглашение /bin/sh - да-да, это оно и есть. А что Вы ожидали увидеть? Не нравится - его можно перенастроить, раскрасить и вообще перелопатить так, что никто не узнает.
2. Не надо так делать. Переходя в рута, Вы отключаете нафиг практически все (ну не все, но подавляющую часть) защитные механизмы и убить систему одной командой. На тестовом компе ничего в этом страшного конечно нет, но это формирует нехорошую привычку - и однажды Вы так сделаете на работающем сервере...

Сделать так можно через sudo, но я все же настоятельно рекомендую запрос пароля не отключать.

Нет.

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

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

Ну, у меня давно-давно, года наверное с 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

В любой команде UNIX могут быть совершенно произвольные ключи. Их смысл целиком и полностью задается разработчиком. Разработчик может дать им какое угодно название, части ключей дать короткие имена, а части длинные, использовать стандарт GNU (--keyname=keyvalue) или же getopt (-keyname=keyvalue), а то и вовсе стандарт DOS (/keyname:keyvalue) - и ничего тут не поделаешь :) Внутри неких крупных проектов (например GNU) есть некое внутреннее соглашение о формировании параметров, ключей и т.д., но общего соглашения среди всех разработчиков нет и быть не может :)

Банальный синтаксис. После case нет esac, после do нет done. Или это неполный скрипт? Для проверки файла вот есть такая фигня - проверяет наличие, то, что это файл (а не каталог, например) и то, что он не нулевого размера:

check_fileread()
{
  if [ ${#1} -ne 0 ]; then
    if [ ! -r $1 ]; then
      echo "File $1 cannot read (does not exist, access denied)"
      exit 55
     elif [ ! -s $1 ]; then
       echo "File $1 is empty (has zero size)"
       exit 56
    fi
  fi
}

Escape-последовательности, про которые Вы пишете, задаются в termcap или terminfo и очень даже запросто могут быть там переопределены. Есть некий стандарт (man termcap, man terminfo), но его как всегда придерживаться никто не обязал.

Есть только одна методика обучения всему и вся, в том числе и администрированию - делать. Ставить виртуалку, придумывать задачи - и делать. Ну или для хардкорщиков - ставить bare-metal. ЛЮбые курсы могут стоить денег - ведь их кто-то должен вести, да?