вторник, 31 января 2012 г.

Уходим с SSL на TLS

Уходим с SSL на TLS

OpenSSL
Дока про работу с SSL - можно проверять в том числе возможности сервера.
В частности

# openssl ciphers -v |grep -i TLS
#

И это дебиан 6.0.3! Впрочем, он отличается тормознутостью, сравнимой с даунизмом. Зато (типа) безопасный!
Вообще, в openssl с поддержкой TLS всё печально. Так что можно сразу переходить на gnutls.

Для этого придется править конфиги всех доменов с SSL. Универсальный метод - описать оба варианта сразу, например
<ifmodule mod_ssl.c>
        SSLEngine on
        SSLCertificateFile      /var/www/site.ru/ssl/certs/site.ru.pem
        SSLCertificateKeyFile   /var/www/site.ru/ssl/ppk/site.ru.key
        SSLCertificateChainFile /var/www/site.ru/ssl/ca/comodo-ca.crt
    </IfModule>

    <ifmodule mod_gnutls.c>
        GnuTLSEnable on
        GnuTLSCertificateFile   /var/www/site.ru/ssl/certs/site.ru.pem
        GnuTLSKeyFile           /var/www/site.ru/ssl/ppk/site.ru.key
        GnuTLSClientCAFile      /var/www/site.ru/ssl/ca/comodo-ca.crt
        GnuTLSPriorities        NORMAL

    </IfModule>

Замечания: без GnuTLSPriorities не запустится.
SSLCertificateChainFile будет называться GnuTLSClientCAFile, также можно попробовать добавить chain certificate в конец основного, или обновить системный ca-bundle.crt (отсюда). Надо проверять!
Тут есть нюанс с nginx:
"if you have a chain of certificates — by having intermediate certificates between the server certificate and the CA root certificate — they're not specified separately like you would do for Apache. Instead you'll need to concatenate all the certificates, starting with the server certificate, and going deeper in the chain running through all the intermediate certificates. This can be done with "cat chain.crt >> mysite.com.crt" on the command line."
http://wiki.nginx.org/HttpSslModule

То есть (наш домен) (корневой сертификат) >> итоговый файл

немного линков
SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
Apache HTTP Server: Обслуживание нескольких HTTPS-хостов на одном IP-адресе
Apache2/SSL and Name Based Virtual Hosts

суббота, 28 января 2012 г.

exim: отправка почты для отдельных доменов с другого айпи

exim и отправка некоторых доменов через отдельные айпи

Находим секцию
begin transports
        remote_smtp:
                driver = smtp

дописываем до вида
begin transports
        remote_smtp:
                driver = smtp
                interface = ${if exists {/etc/exim4/mail_ips}{${lookup{$sender_address_domain}lsearch{/etc/exim4/mail_ips}{$value}{}}}{}}
                helo_data = ${lookup dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
При этом формат файла /etc/exim4/mail_ips:
domain.ru: 1.1.1.1
domain2.ru: 2.2.2.2

Остальные отправляться будут со стандартного айпи.

пятница, 27 января 2012 г.

По железке под задачу или виртуализировать?

Периодически встаёт выбор: купить под каждую задачу по железке или виртуализироваться и собрать все задачи на меньшем количестве машин. Ведь, как это отмечается во многих брошюрах и статьях, среднестатистический сервер загружен лишь на 10%. Но там же обычно забывают сказать, что виртуализация по хорошему будет требовать хорошего железа, SAN, внешний SAS/FC, хотя иногда пойдёт и iSCSI. Плюс свичи несколько другой стоимости, особенно FC, плюс карты, оптика.. А также всё это будет тоже требовать обслуживания, и уровень знаний нужен более серьёзный, чем для пачки серверов всё-на-себе. И отказ инфраструктуры будет иметь более печальные последствия, поэтому нужно будет всё дублировать, это в лучшем случае стоимость х2, а зачастую и больше.
Поэтому для крупных компаний - да, железа будет меньше, его загруженность больше, админам работы станет чуть побольше в плане обслуживания софта - надо хост-системы обслуживать + виртуальных серверов обычно становится даже больше, поскольку создание новой виртуалки - процесс довольно простой, а выделение по машине под каждый сервис повышает надёжность и управляемость системы. Хотя если меньше железа - меньше нужно обслуживания аппаратной части, но уровень "дежурный инженер" обычно ниже и порой весьма дешевле комплекта профессионалов сеть-виртуализаторы-админы_виртуалок.

Для мелких компаний, у которых "сервера" это старые снятые с эксплуатации персоналки - абсолютно невыгодно, потому что надёжность старого железа, особенно уровня персоналок, очень низкая, а покупать новое железо выходит крайне дорого. Собирать же подобные системы из старья - никто никаких гарантий дать не может, железо будет не валидировано, нет SAS, ECC и прочих необходимых в контексте повышенной нагрузки возможностей. И если раньше отказ 1 железки грозил отказом 1 сервиса (телефонии например), то с виртуализацией, когда всё на 1 железке - ляжет ВСЁ. А если откажет физически - на восстановление может уйти и неделя, и хорошо если были бэкапы.
Ну и уровень админа должен быть более высоким, то есть приходящего админа скорее всего уже будет недостаточно, если простой должен быть менее суток.

Самая интересная категория тут - средние компании, у которых уже есть админы, есть много разнотипного железа, которое постоянно требует обслуживания, выходом их строя старого железа, которому уже по 10 лет и его авральной заменой, полный хаос в фирмах, софте, технологиях... Хотя парк железа скорее всего будет подлежать модернизации и приведению к неким стандартам, в частности вендорам: такие интересные вещи как live migration требуют не просто однотипного железа, а желательно полностью совпадающего: на разном железе может и получится смигрировать, но ВДРУГ всё может упасть из-за мелких нюансов. С большой вероятностью сеть потребует перевода на новые свичи, внедрение 10гбит итд.
Ну и надо учитывать, что "средняя IT-компания" это совсем не тоже самое, что какая-нибудь лесопилка, пусть и с парой сотен/тысяч рабочих. Также надо смотреть на длительность возможного простоя и завязанность техпроцессов на работу информационных систем.

факсы и цифра

небольшая заметка по факсам

Старые факсы работают по протоколу Т.30, и в основе мультиплексный канал с разделением по времени (TDM)
Напрямую через интернет факс передать невозможно - там в основе канал на базе пакетов плюс применяются кодеки, оптимизированные под минимальное использование канала при сохранении качества речи (за исключением G.711, через который факс может пройти при достаточном качестве канала, но без гарантий). Чтобы передавать факсы через интернет, надо упаковать Т.30 в Т.38 (image/t38), который уже может быть передан через IP, причём есть варианты TCP и UDP. TCP распространения особо не получил, так как там много требований к качеству канала, и обычно применяется UDP.

http://ru.wikipedia.org/wiki/T.38

среда, 25 января 2012 г.

apache+nginx и 4 числа в выводе

Небольшая заметка на тему косяка в апаче (это всё-таки он игнорирует то, что ему передали HTTP/1.0, и отдаёт с HTTP/1.1)
http://habrahabr.ru/blogs/nginx/135662/

В качестве обхода проблемы (особенно если используется не Apache) по идее также должна помочь установка nginx >= 1.1.4 или chunked_transfer_encoding off.

среда, 18 января 2012 г.

bacula+amazon

Основной документ
http://lucasmanual.com/mywiki/Bacula

Варианты исполнения
Через fuse-s3fs
Бэкапы через bacula на Amazon S3

Можно через s3cmd делать синхронизацию локального хранилища с удаленным.

"особо хитроумные пользователи AWS используют EC2 для бекапов и используют там rsync, а на s3 держат только снимки состояния EC2"
Но это + к стоимости за сервер. Хотя можно из скриптов запускать инстанс, ждать окончания и гасить, но если "вдруг" что-то изменится/сломается (ключ отозвали например), и мы не заметили и что-то сломалось, прощайте данные.

понедельник, 16 января 2012 г.

Релиз FreeBSD 9.0

http://www.opennet.ru/opennews/art.shtml?num=32749

thunderbird autoconfig

В линейке Thunderbird 3 появилась полезная возможность «подхватывать» настройки доступа к почтовому серверу. Но для этого необходимо немного «почесаться».
Есть несколько вариантов как это сделать:
0) Ленивый. Добавить для домена записи pop3.mymaildomain.com, imap.mymaildomain.com, smtp.mymaildomain.com и использовать стандартные порты для доступа.
1) Добавить в installdir/isp/ на конкретном компьютере файлик emailaddressdomain.xml с описанием настроек доступа (формат смотрите в ссылках)
2) Наилучший вариант. Добавить запись autoconfig.mymaildomain.com
Автоматизация создания аккаунтов в Thunderbird v3

"Цель - сделать msi пакет, готовый для установки в домене. Ставишь пакет - имеешь почтовый клиент, который настраивается под каждого конкретного пользователя сам. Чудеса! Как это работает - thunderbird ломится по ntlm на указанный url, на серваке скрипт выцепляет имя пользователя, лезет в active directory, смотрит мыло и другие полезные сведения, (как например, если пользователь залочен - не давать ему конфиг), формирует конфиг и отдает thunderbird. Плюсы очевидны."
Thunderbird autoconfig

суббота, 14 января 2012 г.

membase и дальше

Не так давно был мной найден membase

Краткий обзор membase — нового NoSQL решения от авторов memcached

Построен на базе memcached, который до последнего времени при нехватке памяти вытеснял наиболее старые ключи из памяти "в никуда", несмотря на
MemcacheDB: API: Memcache protocol (get, set, add, replace, etc.), Written in: C, Data Model: Blob, Misc: Is Memcached writing to BerkleyDB.

membase был создан, чтобы стать полноценным nosql хранилищем, используя в основе очень быстрый и удобный memcached (подробнее в статье выше)

Но теперь membase.org перекидывает на http://www.couchbase.org/

CouchDB & Membase merge to CouchBase ! »

Но дальше - хуже.
Couchbase Single Server
As of January 2012, Couchbase Single Server will be discontinued.

И это уже документ-ориентированная база, а не hash-table. Вдобавок осталась только облачная версия.

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

UP
Похоже, membase не полный труп:
http://www.couchbase.com/docs/membase-manual-1.7/membase-getting-started.html

воскресенье, 8 января 2012 г.

Latest snapshot on server is older than what we already have!

Одновременно на 3 серверах вылезло сообщение:
> sudo portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found.
Fetching snapshot tag from portsnap6.FreeBSD.org... done.
Latest snapshot on server is older than what we already have!
Cowardly refusing to downgrade from Sat Jan  7 23:51:48 MSK 2012
to Thu Jan  5 19:31:17 MSK 2012.

That spells bad news. You should never see this message. Make sure the time/date on your machine are set (and updated) correctly, and run rm /var/db/portsnap/tag && portsnap fetch extract before you continue.
отсюда

Так что алгоритм:
1) проверить время на сервере, возможно синхронизироваться через ntp
2) rm /var/db/portsnap/tag && portsnap fetch extract

В данном случае все сервера лезли к portsnap6. Есть идея попробовать в /etc/portsnap.conf принудительно прописать другой сервер, могло помочь. Но сервера уже обновлены по методу выше.