Архивирование всей папки folder без сжатия:
$ tar -cf archive.tar folder/
Архивирование всей папки folder со сжатием gzip:
$ tar -zcvf archive.tar.gz folder/
Архивирование всей папки folder со сжатием bzip2:
$ tar -jcvf archive.tar.bz2 folder/
Автоматическая перезагрузка 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 -pThere 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.confWell 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! 🙂
Экспорт или импорт сертификата 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
Создание самоподписанного сертификата?
Создать файл 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
Подключение разделов TrueCrypt с помощью сервера Asterisk
Предисловие
Частью моей работы является ежедневное монтирование контейнеров TrueCrypt на удаленном сервере (1С с «серыми» базами… ну, вы понимаете).
Утренний порядок действий меня напрягал: включить ноутбук, подключиться к серверу, ввести 70-тизначный пароль в TrueCrypt, отключиться от сервера, выключить ноутбук, собраться и ехать на работу.
Мысль об использовании Asterisk пришла сразу. Необходимо было это реализовать.
Решение
Конфигурация оборудования такая:
- сервер Asterisk — Ubuntu Server 10.04, Asterisk v1.6.
- терминальный сервер — Windows Server 2003 R2, TrueCrypt v6.1a, два жестких диска с разделами TrueCrypt.
Логическая цепочка размышлений была такая:
- TrueCrypt позволяет управлять собой из командной строки.
- Asterisk позволяет запускать любые скрипты, достаточно прописать их в extensions.conf.
- Есть виндовая утилита psexec.exe, позволяющую запускать процессы на удаленном виндовом компьютере из командной строки.
- 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. Критика, разгоревшаяся в комментариях, приводит к выводу, что в реальных условиях безопасность данной схемы довольно низкая, остается только удобство )).
Кое-что о соглашениях об именах почтовых ящиков
Заведя для себя «почту для домена» на Яндексе, я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции 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, существуют ли они в действительности?
Таким образом, зарезервировав все эти имена, как алиасы для своего основного ящика на домене, вы обезопасите себя, в том, числе от мейлбокс-сквоттерства и злонамеренного использования ящиков с «системными» именами. Так же вся «служебная» переписка по вашему домену, которая может придти на системные имена не останется без внимания. Если вы организовываете почту для офиса, то подобные соглашения могут быть так же полезны вам.
Групповое переименовывание фотографий в Linux
С помощью утилиты exiv2, которая позволяет читать данные EXIF из файлов фотографий, я переименовываю фотографии, которые сделал фотоаппаратами Canon EOS 7D, из вида IMG02731.CR2 в вид, более удобный для сортировки и отображения, 20110719_114534_IMG02731.CR2. Теперь в имени файла присутствует год, месяц, число, время и первоначальное имя файла фотографии.
$ exiv2 -r'%Y%m%d_%H%M%S:basename:' rename *
При использовании выводится много ошибок. Типичные:
Error: Directory (Last IFD item), entry 0x145f has invalid size 3062158522*1; skipping entry. Warning: Directory (Last IFD item), entry 0x19b7 has unknown Exif (TIFF) type 48470; setting type size 1. Error: Offset of directory (Last IFD item), entry 0x19b7 is out of bounds: Offset = 0xf35a8f80; truncating the entry Error: Directory (Last IFD item) with 8532 entries considered invalid; not read.
Не обращаю внимания. Пока не заметил проблем.
PlayOnLinux
Для обновления необходимо подключить репозиторий PlayOnLinux’а и обновить программу:
wget -q "http://deb.playonlinux.com/public.gpg" -O - | sudo apt-key add - sudo wget http://deb.playonlinux.com/playonlinux_natty.list -O /etc/apt/sources.list.d/playonlinux.list sudo apt-get update sudo apt-get install playonlinux
Удаление ключа ssh-узла из списка .ssh/known_hosts
$ ssh-keygen -f "/home/user/.ssh/known_hosts" -R 192.168.116.11
Авторизация SSH по RSA ключу
Для начала создадим алиасы устройств — вместо длинной записи ssh -l user 192.168.0.1 будем использовать, например, ssh router. Красиво и эстетично! Для организации такой красоты достаточно создать конфигурационный файл SSH (если у вас его еще нет).
user$ mkdir ~/.ssh user$ cd ~/.ssh user$ nano config
Примерно такого содержания
Host router HostName 192.168.0.1 User user Port 22
Немного поясню:
- Host — наш алиас к устройству, по которому будем вызывать
- HostName — имя или IP адрес устройства
- User — имя пользователя для подключения к устройству
- Port — номер порта SSH, если переопределено
Каждый алиас необходимо прописать соответствующим блоком, например, можно создать алиасы к одному устройству с разными именами пользователей. Теперь можно вызывать ssh router. Параметры для подключения к устройству router считаются из конфигурационного файла, который мы только что создали. Замечательно! Далее настроим, чтоб при подключении удаленное устройство не спрашивало пароль. Для таких целей достаточно создать пару RSA ключей и один из них поместить на удаленное устройство. Перед генерацией ключа проверим необходимые параметры в настройках системы на стороне клиента/etc/ssh/ssh_config.
user$ sudo nano /etc/ssh/ssh_config
Ищем нужный нам параметр, должно быть так
.. IdentityFile ~/.ssh/id_rsa ..
Подготовку сделали, можно генерировать пару RSA ключей
user$ ssh-keygen -t rsa
Отвечаем на несколько вопросов — нажимаем Enter 😉
Generating public/private rsa key pair. Enter file in which to save the key (/home/user.ssh/id_rsa): <span style="color: red; font-weight: bold;"><-Enter</span> Enter passphrase (empty for no passphrase): <span style="color: red; font-weight: bold;"><-Enter</span> Enter same passphrase again: <span style="color: red; font-weight: bold;"><-Enter</span> Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: b6:a0:23:59:54:79:67:44:0f:e8:24:6b:5b:01:be:9b user@desktop The key's randomart image is: +--[ RSA 2048]----+ | o++=*o | | . .oo.oo | | + o o. | | . = | | o + S | | = + o | | E o . | | . . | | | +-----------------+
Пара RSA ключей готова, теперь публичный ключ необходимо передать на удаленное устройство. Но перед этой операцией проверим настройки на удаленном устройстве /etc/ssh/ssh_config.
Ищем нужный нам параметр, должно быть так
.. RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys ..
Параметр AuthorizedKeysFile предписывает, что принятые ключи будут храниться для каждого пользователя отдельно. Можно еще добавить следующие опции, хуже от этого не будет:
- PermitRootLogin no — разрешается ли пользователю root логиниться по SSH. Лучше запретить, при необходимости права себе можно повысить, например, sudo.
- PermitEmptyPasswords no — разрешить использовать пустые пароли. Даже не знаю для чего такую опцию оставили, если только для лабораторных отладок.
- AllowUsers — указывает список пользователей, под которыми можно входить по SSH. Очень полезная опция! Если таковой нет в вашем конфиге — создайте ее. Формат AllowUsers user1 user2. В качестве логинов можно указывать user1@example.com (или user1@192.168.0.22), позволит логиниться пользователю user1 только с адреса example.com и 192.168.0.22
- Port — указывает прослушиваемый демоном SSHD порт. По-умолчанию — 22, для повышения безопасности лучше сменить его на что-то выходящее за пределы 1024 или еще лучше, за пределы 10000. К примеру поставить 55555, легко запоминается, а вот nmap’ом не просканишь.
Все готово. Передаем ключ на удаленное устройство.
user$ ssh-copy-id router
После успешного прохождения аутентификации ключ будет передан на удаленное устройство
Now try logging into the machine, with "ssh 'router'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
Пробуем подключится
user$ ssh router
Подключение успешно. Теперь подключаться к настроенным удаленным устройствам одно удовольствие. Вводим одну короткую команду и вуаля — вы уже управляете удаленным устройством. Надо заметить, что при подключении с другого устройства вам необходимо ввести все параметры подключения и пароль, но никто не запрещает вам повторить выше описанную процедуру и с этим устройством. Если, конечно, это необходимо. Приятной работы.