Author: 891rpm

Leave a comment Posted on by 891rpm Tech articles

named.conf.options

Содержимое named.conf.options:

options {
 directory "/var/cache/bind";        //Понятно, что это кэш для запросов
 forwarders {                       //Секция для форвардинга неразрешённых
     10.0.0.1;                      //запросов. Т.е. резольвинг адресов будет
 10.0.15.1;                     //выполняться указанными здесь серверами.
 };                             //Чаще всего указываем DNS-сервера провайдера.

auth-nxdomain no; # conform to RFC1035        //Что-то отключённое. Потом посмотрим.

listen-on {
     127.0.0.1;                     //Наш DNS-сервер будет принимать запросы
     192.168.0.1;                    //только на внутренних адресах.
    };
 };
Leave a comment Posted on by 891rpm Tech articles

lm-sensors

Установка

# apt-get install lm-sensors

На сайте http://www.lm-sensors.org советуют использовать последний lm-sensors 3.1.1.

  • Удалил текущий lm-sensors.
  • Скачал из нестабильной ветки Debian пакет с lm-sensors 3.1.1.
  • Попробовал установить скаченный пакет dpkg -i lm-sensors*.deb
  • Обнаружилась неудовлетворённая зависимость -> libsensors4.
  • Скачал оттуда-же пакет libsensors4 и установил. В результате пакет lm-sensors заработал.
  • Запустил sensors-detect и обнаружил:
  • w83627ehf и coretemp
  • Разрешил добавить эти строки в /etc/modules.
  • Перезагрузил компутер.
  • sensors заработал.
Настройка

В большинстве случаев настройка отслеживания за температурами, скоростью вращения вентиляторов и т.д. проста.

$ sensors-detect

На все вопросы отвечаем энтером.

В конце скрипт предложит внести в /etc/modules модули для найденных системных датчиков. Согласимся. Потом можно загрузить модули без перезагрузки компутер modprobe <название модуля>. И опросим датчики командой sensors.

Если датчики показывают неправильные значения, то редактируем /etc/sensors.conf.


Leave a comment Posted on by 891rpm Tech articles

Переподключение к сеансу SSH

В настройках SSH поставил «не завершать сеанс при разрыве». После переподключения не знаю как присовокупиться к висящему сеансу.

В инете рекомендуют использовать screen, который позволяет использовать несколько псевдотерминалов и подключаться к ним по мере необходимости.
http://libc6.blogspot.com/2008/09/screen-terminal.html

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

Как настроить автоматический запуск screen при входе по ssh

Достало постоянно вводить screen -dR при входе на удалённую машину. Погуглив нашёл простое решение. В конце ~/.bashrc дописать:

 if [ -z "$STY" ]; then
 exec screen -dR
 fi

У меня чуть более продвинутый вариант 🙂

В конец .bashrc надо добавить

if [ "$SSH_TTY" ]; then
 if [ ! "$STY" ]; then
  CHOICE=`SCREEN/choose`
  if [ -z "$CHOICE" ];
  then
   exec screen
  else
   exec screen -dr $CHOICE
  fi
 fi
fi

и создать файл ~/SCREEN/choose:

#!/bin/bash
USERNAME=`whoami`
i=0
declare -ax SCREENS
SOCKETS=`find /var/run/screen/S-$USERNAME -type p`
if [ -z "$SOCKETS" ];
then
exit 0
fi
for S in $SOCKETS
do
((i=$i+1))
S=`basename $S`
SCREENS[$i]=`screen -ls | grep $S | perl -e '$s=<>; $s =~ s/^\\t(.*)\s/$1/; $s =~ s/\s/_/g; print $s'`
done
MENU=""
for ((j=1; j do
MENU="$MENU $j ${SCREENS[$j]}"
done
WHICH=`dialog --stdout --menu Select: 0 0 0 $MENU`
echo ${SCREENS[$WHICH]} | sed -e 's/_(.*)$//'

При логине будет предлагаться меню со списком имеющихся сессий screen, можно выбрать нужную либо создать новую. Если запущенных screen’ов нет, автоматически запустится новая сессия.

Единственная (вроде бы) зависимость — нужно поставить dialog.

Ссылки:
http://www.truediamon.ru/content/kak-nastroit-avtomaticheskij-zapusk-screen-pri-vhode-po-ssh

Leave a comment Posted on by 891rpm Tech articles

Tar

Архивирование всей папки folder без сжатия:

$ tar -cf archive.tar folder/

Архивирование всей папки folder со сжатием gzip:

$ tar -zcvf archive.tar.gz folder/

Архивирование всей папки folder со сжатием bzip2:

$ tar -jcvf archive.tar.bz2 folder/

 

Leave a comment Posted on by 891rpm Tech articles

Автоматическая перезагрузка Linux при kernel panic, перегрузке CPU или системном сбое

If you are a system administrator, you have probably wondered at least once ohw to configure your Linux server to automatically reboot itself if it crashes, is going through a mass CPU overload, e.g. the server load average “hits the sky”.

I just learned from a nice article found here that there is a kernel variable which when enabled takes care to automatically restart a crashed server with the terrible Kernel Panic message we all know.

The variable I’m taking about is kernel.panic for instance kernel.panic = 20 would instruct your GNU Linux kernel to automatically reboot if it experiences a kernel panic system crash within a time limit of 20 seconds.

To start using the auto-reboot linux capabilities on a kernel panic occurance just set the variable to /etc/sysctl.conf

debian-server:~# echo 'kernel.panic = 20' >> /etc/sysctl.conf

Now we will also have to enable the variable to start being use on the system, so execute:

debian-server:~# sysctl -p

There you go automatic system reboots on kernel panics is now on.
Now to further assure yourself the linux server you’re responsible of will automatically restart itself on a emergency situation like a system overload I suggest you check Watchdog

You might consider checking out this auto reboot tutorial which explains in simple words how watchdog is installed and configured.

On Debian installing and maintaining watchdog is really simple and comes to installing and enabling the watchdog system service, right afteryou made two changes in it’s configuration file/etc/watchdog.conf

To do so execute:

debian-server:~# apt-get install watchdog
debian-server:~# echo "file = /var/log/messages" >> /etc/watchdog.conf
debian-server:~# echo "watchdog-device = /dev/watchdog" >> /etc/watchdog.conf

Well that should be it, you might also need to load some kernel module to monitor your watchdog.

On my system the kernel modules related to watchdog are located in:

/lib/modules/2.6.26-2-amd64/kernel/drivers/watchdog/
If not then you should certainly try the software watchdog linux kernel module called softdog , to do so issue:

debian-server:~# /sbin/modprobe softdog

It’s best if you load the module while the softdog daemon is disabled.
If you consider auto loadig the softdog software watchdog kernel driver you should exec:

debian-server:~# echo 'softdog' >> /etc/modules

That should be all your automatic system reboots should be now on! 🙂

Leave a comment Posted on by 891rpm Tech articles

Экспорт или импорт сертификата PKCS#12

Файлы PKCS#12 используются в разных приложениях типа MS IIS. Они часто имеют расширение .pfx.

# создать файл, содержащий ключ и самоподписной сертификат
openssl req \
  -x509 -nodes -days 365 \
  -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

# экспортировать mycert.pem как файл PKCS#12, mycert.pfx
openssl pkcs12 -export \
  -out mycert.pfx -in mycert.pem \
  -name "My Certificate"

Превратить pfx в pem:

# export certificate and passphrase-less key
openssl pkcs12 -in mycert.pfx -out mycert.pem -nodes

# same as above, but you’ll be prompted for a passphrase for
# the private key
openssl pkcs12 -in mycert.pfx -out mycert.pem
Leave a comment Posted on by 891rpm Tech articles

Создание самоподписанного сертификата?

Создать файл mycert.pem, в котором будет и секретный ключ и открытый сертификат, основанный на нём. Сертификат будет действителен в течение 365 дней; ключ (благодаря опции -nodes) будет нешифрованным.

openssl req \
    -x509 -nodes -days 365 \
    -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

После вызова команды надо будет ответить на несколько вопросов: Country Name, State, City и так далее. На вопрос “Common Name” нужно отвечать именем сервера, по которому будут обращаться люди.

Можно автоматизировать ввод ответов с помощью опции -subj.

openssl req \
  -x509 -nodes -days 365 \
  -subj '/C=US/ST=Oregon/L=Portland/CN=www.madboa.com' \
  -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

Leave a comment Posted on by 891rpm Tech articles

Подключение разделов TrueCrypt с помощью сервера Asterisk

Предисловие

Частью моей работы является ежедневное монтирование контейнеров TrueCrypt на удаленном сервере (1С с «серыми» базами… ну, вы понимаете).

Утренний порядок действий меня напрягал: включить ноутбук, подключиться к серверу, ввести 70-тизначный пароль в TrueCrypt, отключиться от сервера, выключить ноутбук, собраться и ехать на работу.

Мысль об использовании Asterisk пришла сразу. Необходимо было это реализовать.

Решение

Конфигурация оборудования такая:

  1. сервер Asterisk — Ubuntu Server 10.04, Asterisk v1.6.
  2. терминальный сервер — Windows Server 2003 R2, TrueCrypt v6.1a, два жестких диска с разделами TrueCrypt.

Логическая цепочка размышлений была такая:

  1. TrueCrypt позволяет управлять собой из командной строки.
  2. Asterisk позволяет запускать любые скрипты, достаточно прописать их в extensions.conf.
  3. Есть виндовая утилита psexec.exe, позволяющую запускать процессы на удаленном виндовом компьютере из командной строки.
  4. Asterisk стоит на Ubunte, значит необходим аналог psexec для линукса — найден winexe.

Дальше привожу сами скрипты.

extentions.conf:

... exten => 777777,1,Playback(beep) exten => 777777,n,Read(auth,,3,5) exten => 777777,n,GotoIf($["${auth}" = "123"]?m:u) exten => 777777,n(m),System(/etc/asterisk/scripts/mount.sh) exten => 777777,n,Goto(end) exten => 777777,n(u),GotoIf($["${auth}" = "321"]?ok:end) exten => 777777,n(ok),System(/etc/asterisk/scripts/umount.sh) exten => 777777,n(end),Playback(vm-goodbye) exten => 777777,n,Hangup ...

Пояснение:

звоним на внутренний номер 777777, вводим пароль 123, выполняется скрипт mount.sh (монтирование разделов) либо вводим пароль 321 и выполняется скрипт umount.sh (размонтирование разделов, так называемая «КРАСНАЯ КНОПКА»)

mount.sh:

#!/bin/sh /etc/asterisk/scripts/winexe -U DOMAIN\LOCALROOT%PASS //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /v \Device\Harddisk1\Partition1 /lE /a /p "CJIo}i{HbIU'napoJIb" /q /s' /etc/asterisk/scripts/winexe -U DOMAIN\LOCALROOT%PASS //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /v \Device\Harddisk2\Partition1 /lF /a /p "CJIo}i{HbIU'napoJIb" /q /s'

/etc/asterisk/scripts/winexe — путь к утилите winexe, которая находится в папке со скриптами.
DOMAIN — имя вашего домена,
LOCALROOT — локальный админ на терминальном сервере,
PASS — пароль локального админа,
IPADDRESS — IP-адрес терминального сервера,
дальше путь к TrueCrypt.exe на терминально сервере с параметрами
\Device\Harddisk1\Partition1 — жесткий диск 1 (для того, чтобы определить путь к разделу, запустите TrueCrypt и щелкните Выбрать устройство / Select Device),
/lE — закрепляемая за диском буква (E:\)
/p «CJIo}i{HbIU’napoJIb» — пароль к разделу TrueCrypt,
\Device\Harddisk2\Partition1 — жесткий диск 2 и дальше по аналогии с первым диском.

umount.sh

#!/bin/sh /etc/asterisk/scripts/winexe -U "DOMAIN\LOCALROOT%PASS" //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /d E /q /s /w /f' /etc/asterisk/scripts/winexe -U "DOMAIN\LOCALROOT%PASS" //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /d F /q /s /w /f' # Варианты удаления либо перезаписи содержимого файлов со скриптами: # 1. Использование urandom # dd if=/dev/urandom of=/etc/asterisk/scripts/mount.sh bs=512 count=1 # dd if=/dev/urandom of=/etc/asterisk/scripts/umount.sh bs=512 count=1 # 2. Использование shred, который забивает файл случайными числами из /dev/urandom (рекомендуется) shred -f /etc/asterisk/scripts/{mount,umount}.sh # или полное удаление скриптов (не рекомендуется) # rm -f /etc/asterisk/scripts/*mount.sh

Здесь происходит форсированное тихое размонтирование разделов E:\ и F:\ и рандомная запись в содержимое скриптов для скрытия информации.

Все скрипты и winexe находятся в папке scripts (/etc/asterisk/scripts/)

Итог

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

Применение связки Asterisk+скрипты может существенно упростить жизнь и расширить возможности системного администратора, например, создание бэкапа или перезапуск служб по звонку.
Лень толкает на подвиги!

UPD. Критика, разгоревшаяся в комментариях, приводит к выводу, что в реальных условиях безопасность данной схемы довольно низкая, остается только удобство )).

http://habrahabr.ru/blogs/sysadm/127997/

Leave a comment Posted on by 891rpm Tech articles

Кое-что о соглашениях об именах почтовых ящиков

Заведя для себя «почту для домена» на Яндексе, я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции catch-all, которая направляет всю входящую почту несуществующих ящиков моего домена на мой основной ящик, предо мной встала необходимость зарезервировать за собой все «стандартные» названия ящиков, чтобы не было недоразумений, когда какое-то имя уже забил посторонний, и вся «служебная» почта уходит совсем не вам. В П.Д.Д. можно, конечно, в любой момент экспроприировать любой ящик подконтрольного домена, но ведь осадочек-то остается. Я озадачился: какие же имена почтовых ящиков являются стандартными и системными? Техподдержка Яндекса ответила, что они резервируют для себя только имя postmaster@ на каждом домене, чтобы отслеживать жалобы и проблемы с почтой, и что на данный момент вопрос о наборе резервированных имен у них остается открытым. Далее, результат поиска в интернете оказался немного предсказуем.

(на картинке: знаменитый black mailbox, место паломничества уфологов-любителей)

RFC

Первое и главное, что я стремился найти — это RFC, коим оказался RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS (имена почтовых ящиков для общих сервисов, ролей и функций), в последней редакции 1997 года. Приведу только интересующую нас информацию. Исходя из документа, следующие почтовые ящики должны существовать и иметь следующее назначение:

Деловые почтовые ящики:

info@ — Отдел маркетинга, тут можно узнать краткую информацию об организации, продукции, сервисах.
marketing@ — Отдел маркетинга и взаимодействия продаж.
sales@ — Отдел продаж, заказ продукции и информация о заказах
support@ Отдел клиентской поддержки, проблемы с продуктом или услугами.
abuse@ — Взаимоотношения с клиентами, ящик должен быть всегда рабочим и валидным, сюда направляются жалобы клиентов, в том числе сообщения об «Inappropriate public behaviour».

Работа с сетью:

noc@ — Сетевые операции, сетевые инфраструктуры.
security@ — Сетевая безопасность, уведомления, оповещения или запросы.

Техническая поддержка отдельных интернетных служб

postmaster@ — SMTP, [RFC821], [RFC822]
hostmaster@ — DNS, [RFC1033-RFC1035]
usenet@ — NNTP, [RFC977]
news@ — NNTP, Synonym for USENET
webmaster@ — HTTP, [RFC 2068]
www@ — HTTP Synonym for WEBMASTER
uucp@ — UUCP, [RFC976]
ftp@ — FTP [RFC959]

Maillist сервис

(рассматривать не будем, просто перечислим основные, там целая плеяда служебным имен и куча RFC, например RFC2369)
list@
list-request@

Сдается мне, что этот RFC 2142 одобрялся во времена расцвета доткомов, а значит потребность в подобных соглашениях была очень актуальна. Предполагалось, видимо, что сотрудники на автомате должны уметь отправлять почту на соответствующие всем известные адреса и ожидать соответствующих компетентных ответов.

Таким образом, следует сделать алиасы этих имен на свой «основной» email, чтобы никто не смог, например, на вашем домене открыть usenet конференцию, не стал из «отдела продаж» банчить валенками и не подписывался системным администратором всея сети с ящика noc@.

/etc/aliases

Стандартом де-факто для *nix систем является соглашение о почтовых именах, содержащееся в файле/etc/aliases. Который де-юре основывается на RFC и прочих документах, по каждому отдельному сервису.

Парадигма назначения почтовых ящиков для людей в *nix звучит примерно так: каждый юзернейм получает почтовый ящик на рабочей станции с таким же именем, как его логин. После создания юзернейма в системе вы уже можете отправлять и получать почту в свой аккаунт.(тут будет своё «но»: если разрешит root и верно прописаны MX). Если хотите получить модный алиас — обратитесь к администратору, он его пропишет в /etc/aliases или еще где в почтовой системе.
То же самое касается и системных служб. Существует масса резервных имен типа @nobody, clamav@, www-data@, которые соответствуют системным учёткам служб, в реальной жизни не используются никем, кроме этих соответствующих служб и являются почтовыми алиасами системного пользователя root, поэтому мы их в расчет не возьмем, потому что все значимые имена ящиков сетевых служб мы уже узнали из предыдущего пункта. Добавим только

root@

Современный интернет и прочие негласные соглашения об именах ящиков

Попробуем вместе с вами найти самые частые имена, которые хозяева доменов оставляют для себя и используют в качестве административных, деловых и личных контактах.

admin@
administrator@ (мьсе, знающие в этом толк, могут добавить локализованные имена админа в Windows, вроде administrador, administrateur)
user@
mail@
blog@
office@
job@ (и иногда resume@ и hr@)-для отправки и приема заявлений на работу и резюме.
spam@ — иногда его ставят как алиас к abuse@ или postmaster@, для жалоб на спам, очевидно.
billing@ — для биллинга. К.О.
account@ — для бухгалтерии и поддержки аккаунтов.
domain@domain.tld — имя ящика повторяет домен, очевидно, для эстетики.
alex@, boss@ — не стесняйтесь забить свои имена, фамилии и ники, чтобы исключить фактор социального инжиниринга, когда, вас, например, зовут Алексей, и ваша жена, прекрасно зная что вы купили vashdomen.ru, получает с ящика alex@vashdomen.ru письмо сомнительного содержания — не ровен час поверит злоумышленнику.

Вы можете что-то добавить в этот лист.

Кроме этого мне почти ничего не известно о соглашениях почтовых имен в системах Windows, существуют ли они в действительности?

Таким образом, зарезервировав все эти имена, как алиасы для своего основного ящика на домене, вы обезопасите себя, в том, числе от мейлбокс-сквоттерства и злонамеренного использования ящиков с «системными» именами. Так же вся «служебная» переписка по вашему домену, которая может придти на системные имена не останется без внимания. Если вы организовываете почту для офиса, то подобные соглашения могут быть так же полезны вам.

http://habrahabr.ru/blogs/sysadm/126822/