Перекодировка времени в логах SQUID

Если посмотреть в логи сквида access.log, то можно заметить что SQUID время доступа к определенным страницам пишет в каком-то своем (непонятном) формате. Данной командой можно перевести этот формат в нормальный вид

tail -f access.log | perl -p -e 's{^([\d]+\.[\d]+)(.*$)}{localtime($1).$2}e'

Смена языка ввода по умолчанию в Windows7

С помощью реестра
Для этого нужно перейти в реестр Windows (запускаем через сочетание клавиш Windows + R, там прописываем regedit и жмём Enter).
Когда мы попали в реестр заходим в раздел HKEY_USERS\.Default\Keyboard Layout\Preload
Там два ключа, 1 и 2. В ключе 1 надо задать значение 409 (англ) в ключе 2 значение 419 (рус). Т.е. просто поменять местами, т.к. для русской локализации они заданы наоборот

SSH авторизация для нескольких серверов

Итак имеется (к примеру) три сервера: lin_1 (10.10.10.1), lin_2 (10.10.10.2), lin_3(10.10.10.3), необходимо чтоб сервер lin_1 имел право запускать команды (скрипты) на lin_2 и lin_3 без запрашивания пароля.

Все нижеперечисленные действия выполняем под root (делал на SLES 9)

1. Генерируем ключи на lin_1

ssh-keygen -t rsa -b4096

Если нас все устраивает, просто жмем ENTER

По умолчанию он создаст два ключа (приватный id_rsa и публичный id_rsa.pub) в каталоге /root/.ssh/

2. Копируем ключ id_rsa.pub на lin_1 и lin_2 изменяя при этом имя ключа

scp id_rsa.pub root@10.10.10.2:/root/.ssh/id_rsa_1

scp id_rsa.pub root@10.10.10.3:/root/.ssh/id_rsa_1

3. Генерируем ключи на lin_2

ssh-keygen -t rsa -b4096

Также получаем два ключа (приватный id_rsa и публичный id_rsa.pub) в каталоге /root/.ssh/

4. Копируем ключ id_rsa.pub с lin_2 на lin_3 изменяя при этом имя ключа

scp id_rsa.pub root@10.10.10.3:/root/.ssh/id_rsa_2

5. Настраиваем lin_3 (доступ с lin_1 и lin_2)

В директории /root/.ssh/ имеем два ключа id_rsa_1 и id_rsa_2

Создаем пустой файл с названием keys_all (сам придумал) добавляем в него содержимое обоих ключей

cat ./id_rsa_1 >> keys_all

cat ./id_rsa_2 >> keys_all

6. Настраиваем sshd_config (/etc/ssh/sshd_config) на lin_3 на прием входящих соединений.

А именно необходимы следующие строки из дефолтного конфига (просто найти их в конфиге и разремить)

Port 22

Protocol 2

PermitRootLogin yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/keys_all

RhostsRSAuthentication no

HostbasedAuthentication no

UseLogin no

7. Перегружаем демона sshd

/etc/init.d/sshd restart

Проверяем с lin_1 и lin_2 выполняем к примеру следующие команды

shh 10.10.10.3 df –hl

После ввода команды не должно спрашивать пароль, а сразу выдать результат (может попросить добавить в know_hosts, это единоразовое добавление)

8. Далее настраиваем lin_2 на прием входящих соединений от lin_1

Делается по аналогии, в каталоге /root/.ssh/ имеем два ключа id_rsa_1 и id_rsa , добавляем содержимое этих ключей в keys_all и рихтуем sshd_config и перегружаем демона (см.выше….)

Задача выполнена, так можно делать и для большего количества серверов (если есть необходимость) (Вроде ничего не забыл... )

Восстановление UCHTEH с BACKUP

1. Для начала необходимо иметь под рукой системный backup , а также имя сервера должно совпадать с оригинальным именем восстанавливаемого сервера.

2. Далее убедится в наличии установленных пакетов (если их нет, установить через YAST, они есть в дистрибутиве)

jakarta-tomcat

jakarta-tomcat-doc

apache2-jakarta-tomcat-connectors

jakarta-tomcat-examples

gcc-java

java2-jre

java2

apache2-prefork

3. Далее копируем папки из архива, предварительно переименовываем оригинальные

/etc/tomcat

/srv/www/tomcat

/usr/share/tomcat

/var/cache/tomcat -- этого не было в системном backup

В файле /etc/tomcat/base/server.xml указаны настройки подключения к базе

4. Далее необходимо убедится в «правильных» разрешениях для папки /etc/tomcat/base

5. После всех вышеперечисленных действий запускаем tomcat и apache

6. Проверяем (если все делал по инструкции должно заработать, если нет - надо сходить к доктору и проверить откуда растут руки)

Настройка mdadm

Совсем недавно появилась необходимость слежения за состоянием программного RAID-массива.

Итак в системах Unix, в частности будем рассматривать на примере системы SLES 9 (Suse Linux Enterprise Server), есть такая замечательная приблуда как mdadm. И чтоб быть постоянно в курсе состояния RAID-массива достаточно ее просто правильно настроить, об этом и пойдет речь ниже.

Для начала необходимо удостовериться, что стоит нужный rpm-пакет

mdadm -1.5.0-40.12 -- версия пакета может отличаться, это не столь важно

Предварительно запускаем команду, чтоб узнать название RAID-массива, его UUID и т.д.

# df -hl

# mdadm –D /dev/md0

Далее правим файл /etc/sysconfig/mdadm

MDADM_DELAY=60 -- время проверки в секундах, можно изменить на больше при необходимости

MDADM_MAIL=”адрес электронной почты, куда будут отсылаться отчеты”

Также необходимо настроить POSTFIX, для отправки отчетов. Это расписывать не буду, тут и так все просто

MDADM_RAIDDEVICES=”/dev/md0, /dev/md1” -- /dev/md* - RAID-массивы

Далее создаем сам конфиг (/etc/mdadm.conf) для проверки RAID-массива (для каждого массива он будет уникальный. Почему? Дальше все сами поймете.)

А вот и сам конфиг:

DEVICE /dev/sda5

DEVICE /dev/sda6

ARRAY /dev/md0 UUID=4710e761:f6ec22b3:06a21234:7e65eb08

ARRAY /dev/md0 superminor=1

ARRAY /dev/md0 devices=/dev/sda5, /dev/sda6

MAILADDR admesto@gmail.com (адрес электронной почты, куда будут отсылаться отчеты)

PROGRAM /usr/sbin/handle-mdadm-events

На этом все. Можно проверить работоспособность. Для этого переведем в состояние FAULT один из винтов RAID

mdadm /dev/md0 –f /dev/sda5

И через установленное время должен прийти очтет…

Также можно удалить(добавить) винт из RAID-массива

mdadm /dev/md0 -r /dev/sda5 --r (remove)

mdadm /dev/md0 -a /dev/sda5 --a (add)