LINUX.ORG.RU
ФорумAdmin

настраиваем удалённый запуск утилит


0

0

В случаях, когда пользователи не имеют возможности залогинится на 
batch nodes в кластере под управлением одной из batch submission 
systems провести полноценную отладку и мониторинг становится 
невозможным, тк встроенные "куцие" возможности батчёвых систем по 
мониторингу заданий (обычно утилитой qstat) не дают полной информации 
о системе и процессах на нодах. Администратор системы для удобства 
может настроить ssh-аутентификацию по ключу без пароля, чем и можно 
воспользоваться для удалённого запуска утилит. Ниже описывается вся 
процедура:

* генерим RSA ключ для ssh-аутентификацию по ключу:

bash> ssh-keygen -t rsa # generate RSA keys for SSH protocol version 2
<Enter># enter empty passphrase (no passphrase)
bash> ssh-keygen -t rsa # generate RSA keys for SSH protocol version 2
... # enter empty passphrase (no passphrase)
bash> PUB_KEY=`cat $HOME/.ssh/id_rsa.pub`
bash> ssh sgeadmin@bn001 echo $PUB_KEY '>> $HOME/.ssh/authorized_keys2'
sgeadmin@bn001's password: # enter remote host password
bash> ssh sgeadmin@bn001
remotehost:bash> # voila! login without password

если в настройках удалённого ssh-сервера была разрешена аутентификация
 по ключу, мы сможем залогиниться без ввода пароля, если нет, 
попробуйте запустить клиента в verbose mode и заодно посмотреть лог на
 удалённом хосте, ssh-сервер пишет в логах какие методы аутентификации
 были опробованы. Аналогично копируем public-key на остальные ноды.


* создаём скрипт "туннелирующий" нужную утилиту и её вывод и запускаемый через sudo:

bash> cat > /home/sgeadmin/bin/cluster_utility_starter.sh
#!/bin/bash

function usage() {
    echo "Usage: PROGRAM [OPTION]... [HOST]
Run a program from list:
  ${util_nm[*]}
on HOST from list:
  $batch_host_list
Exit program by SIGINT/^C if a programm is looped.

 -h       print help and exit
 -l       List available hosts and exit"
}

# cluster work nodes
readonly batch_host_list="@bn001 @bn002 @bn003" # batch nodes

# util list for remote execution
util_nm[0]="Qtop"
util_cm[0]="/usr/bin/top b"

util_nm[1]="Qps"
util_cm[1]="/bin/ps"

util_nm[2]="Qfree"
util_cm[2]="/usr/bin/free"

util_nm[3]="Qvmstat"
util_cm[3]="/usr/bin/vmstat"

util_nm[4]="Qstat"
util_cm[4]="/usr/bin/stat"

util_nm[5]="Qls"
util_cm[5]="/bin/ls"

util_nm[6]="Qcat"
util_cm[6]="/bin/cat"

util_nm[7]="Qpstree"
util_cm[7]="/usr/bin/pstree"


if test $# -le 1
then usage $0
     exit 1
fi

i=0
cmd_name="$1"
shift
util_name=""

while :; do
    if test $i -ge ${#util_nm[*]}; then
	echo >&2 "$cmd_name: no such command"
	usage
	exit 1
    fi
    if test "${util_nm[$i]}" == "$cmd_name"; then
	util_name="${util_cm[$i]}"
	break
    fi
    let $((++i))
done

host_name=""
options=""

while test $# -gt 0
  do case "$1" in
        -h) echo -e "Copyright (C) 2005 Alexey Filin\n"
            usage
            exit ;;
        -l) echo -n "Available batch hosts: "
            echo $batch_host_list
            exit ;;
        @*) if test -n "$host_name"; then
		usage
		exit
           fi
	   for i in $batch_host_list; do
		if test "$i" == "$1"; then
		    host_name="$1"
		    break
		fi
	   done
           if test -z "$host_name"; then
		echo "$1: no such host name"
		exit
	   fi
           shift ;;
        *) options="$options $1"
	   shift ;;
        esac
     done
if test -n $host_name; then
    #echo ssh -x "sgeadmin$host_name" "sudo -u $SUDO_USER $util_name $options"
    ssh -x "sgeadmin$host_name" "sudo -u $SUDO_USER $util_name $options"
else
    usage
    exit
fi
exit
^D
bash> chmod +x /home/sgeadmin/bin/cluster_utility_starter.sh

заметьте, что утилита на удалённом хосте запускается под пользователем
 запустившим скрипт-обёртку описываемый ниже.
★★

настраиваем удалённый запуск утилит (продолжение)

* создаём скрипт-обёртку для sudo:

bash> cat > /home/sgeadmin/bin/sudo_starter.sh
#!/bin/bash
sudo -u sgeadmin /home/sgeadmin/bin/cluster_utility_starter.sh `basename $0` $*
^D
bash> chmod +x /home/sgeadmin/bin/sudo_starter.sh


* создаём запись в sudoers на user front-end машине (uihost) для 
запуска обёртки:

bash# visudo
...
# SGE users are allowed to run some utilities on batch nodes
%sgeusers       uihost = (sgeadmin) NOPASSWD: /home/sgeadmin/bin/cluster_utility_starter.sh

где sgeusers - специальная группа в которую входят все пользователи 
кластера которым разрешён удалённый запуск утилит


* заходим на рабочую ноду и добавляем запись в sudoers:

bash# visudo
...
# Cmnd alias specification
Cmnd_Alias      CLUSTERCOMMANDS = /usr/bin/top b, /bin/ps, /usr/bin/free,\
                                  /usr/bin/vmstat, /usr/bin/stat, /bin/ls,\
                                  /bin/cat, /usr/bin/pstree
...
# sgeadmin can run any cluster command as user
sgeadmin    ALL = (%sgeusers) NOPASSWD: CLUSTERCOMMANDS

разрешим запуск только указанных утилит для пущей безопасности (top 
запускается в batch mode, поэтому игнорирует потенциально опасный 
ввод)

копируем /etc/sudoers на остальные рабочие ноды.


* создаём линки с нужными именами в директории где лежат остальные 
утилиты системы запуска заданий:

bash> cd $SGE_ROOT/bin/lx24-x86/
bash> ln -s /home/sgeadmin/bin/sudo_starter.sh Qtop
bash> ln -s /home/sgeadmin/bin/sudo_starter.sh Qps
...


* "время отправиться в сказку пришло", если всё настроено и создано 
верно, запускаем для проверки Q-аналоги так нужных пользователям 
утилит под одним из пользователей фермы и любуемся результатом рук 
наших.

filin ★★
() автор топика

добавление

несколько советов пользователям ssh:

* пропишите в ~/.ssh/config пару опций

ForwardX11 yes
Protocol 2,1

первая чтобы чтобы шифровать трафик X-клиентов (если вы не уверены насчёт отсутствия прослушки), вторая чтобы при коннекте изначально использовалась вторая версия протокола, иногда после попытки приконнектиться по первой версии клиент отваливается с ошибкой и вторую версию клиенту приходится указывать явно через command line arguments (опция -2), уже не помню что было в sshd_config такого криминального.

* "дремучий" совет: когда-то мне пришлось выставить права на чтение _только_ для owner для всех файлов в директории $HOME/.ssh/, для group и other их пришлось закрыть, несмотря на то, что сама директория $HOME/.ssh/ закрыта по умолчанию для всех кроме owner, а пользователь имел уникальную группу. ssh как и полагается всем логин-утилитам параноик по определению, а то ли разработчики дистрибутива, то ли разработчики ssh "перекрутили" какие-то гайки, в результате ssh совсем отбилась от рук.

anonymous
()
Ответ на: добавление от anonymous

ForwardX11 yes - это, мягко говоря, совсем не "шифровать трафик X-клиентов". Читай документацию :)

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.