Для начала, что это:
jenkins, он же hudson (что случилось) - инструмент непрерывной интеграции, написанный на Java.
Непрерывная интеграция - это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.
wiki
Итак.
Centos:
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins
Debian:
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
echo "deb http://pkg.jenkins-ci.org/debian binary/" >> /etc/apt/sources.list
sudo apt-get update
sudo apt-get install jenkins
По умолчанию сервис садится на порт 8080
линки
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+RedHat+distributions
http://pkg.jenkins-ci.org/debian/
http://habrahabr.ru/search/?q=[jenkins]&target_type=posts
среда, 29 февраля 2012 г.
понедельник, 27 февраля 2012 г.
MariaDB на centos
Для начала, идём на mariadb.org и выбираем нужную нам версию
Например, для стабильной версии 5.2:
downloads.askmonty.org/mariadb/5.2/
Там же есть инструкции. Но для 5.2 есть только всякие виндовые версии, а под центось только под 5 центось и рхел.
В итоге мы должны получить 3 .rpm файла: -shared, -server, -client
!!предварительно сносим mysql-*, иначе будут конфликты.
!!Сначала ставится -shared. Потом оставшиеся пакеты.
После завершения используем mysql_secure_installation
Например, для стабильной версии 5.2:
downloads.askmonty.org/mariadb/5.2/
Там же есть инструкции. Но для 5.2 есть только всякие виндовые версии, а под центось только под 5 центось и рхел.
В итоге мы должны получить 3 .rpm файла: -shared, -server, -client
!!предварительно сносим mysql-*, иначе будут конфликты.
!!Сначала ставится -shared. Потом оставшиеся пакеты.
После завершения используем mysql_secure_installation
воскресенье, 26 февраля 2012 г.
Обновление облачного сервера на centos
Захотели обновить софт на серверах, стоящих в селектеле. Был centos 5.5
Простое обновление через yum update не удастся: нельзя обновить ядро
Поэтому надо обновить через
yum -x kernel-xen update
Замечание:
Не забываем, что для корректного автообновления надо иметь установленный yum-priorities
проверить:
# rpm -qa|grep -i prior
установить:
# yum install yum-priorities
Простое обновление через yum update не удастся: нельзя обновить ядро
Error Summary ------------- Disk Requirements: At least 101MB needed on the /lib/modules filesystem.
Поэтому надо обновить через
yum -x kernel-xen update
Замечание:
Не забываем, что для корректного автообновления надо иметь установленный yum-priorities
проверить:
# rpm -qa|grep -i prior
установить:
# yum install yum-priorities
вторник, 14 февраля 2012 г.
ssl: некоторые особенности заполнения
Прежде всего, а на что опираться при переводе названий городов и компании?
http://ru.wikipedia.org/wiki/Транслитерация_русского_алфавита_латиницей предлагает несколько вариантов, в частности для буквы Ц это C, TS, TC, Z. Какой вариант выбрать?
http://ru.wikipedia.org/wiki/ISO_9
http://ru.wikipedia.org/wiki/Транслитерация
Особенности транслитерации есть и для городов:
moscow, moskow, moskva...
sankt-peterburg, saint-petersburg, saint petersburg...
итд. И иногда вроде более верный вариант регистратор заворачивает. На что опираться? Опять же, или на ISO, или на спец порталы. Например
http://geonames.nga.mil/ggmagaz/
"Согласно информации из официальной базы данных иностранных географических названий http://geonames.nga.mil/ggmagaz/, поддерживаемой National Geospatial-Intelligence Agency (NGA), название Sankt-Peterburg считается одобренным (Approved). Название Saint Petersburg считается общепринятым (Conventional). Считаю использование названия Sankt-Peterburg в качестве значения атрибута Locality Name допустимым."
Некоторые регистраторы вроде того же Comodo требуют, чтобы фирма была в duns
http://en.wikipedia.org/wiki/Data_Universal_Numbering_System
http://www.dnb.ru/rbr.asp?rbr=25
Зачастую хотят, чтобы информация из whois на домен совпадала с той, что прописана в запросе. Поэтому уже на стадии заполнения информации для домена надо заполнять максимально правильно.
http://ru.wikipedia.org/wiki/Транслитерация_русского_алфавита_латиницей предлагает несколько вариантов, в частности для буквы Ц это C, TS, TC, Z. Какой вариант выбрать?
http://ru.wikipedia.org/wiki/ISO_9
http://ru.wikipedia.org/wiki/Транслитерация
Особенности транслитерации есть и для городов:
moscow, moskow, moskva...
sankt-peterburg, saint-petersburg, saint petersburg...
итд. И иногда вроде более верный вариант регистратор заворачивает. На что опираться? Опять же, или на ISO, или на спец порталы. Например
http://geonames.nga.mil/ggmagaz/
"Согласно информации из официальной базы данных иностранных географических названий http://geonames.nga.mil/ggmagaz/, поддерживаемой National Geospatial-Intelligence Agency (NGA), название Sankt-Peterburg считается одобренным (Approved). Название Saint Petersburg считается общепринятым (Conventional). Считаю использование названия Sankt-Peterburg в качестве значения атрибута Locality Name допустимым."
Некоторые регистраторы вроде того же Comodo требуют, чтобы фирма была в duns
http://en.wikipedia.org/wiki/Data_Universal_Numbering_System
http://www.dnb.ru/rbr.asp?rbr=25
Зачастую хотят, чтобы информация из whois на домен совпадала с той, что прописана в запросе. Поэтому уже на стадии заполнения информации для домена надо заполнять максимально правильно.
openvpn: виды соединений
[черновик]
Варианты, которые могут быть:
1) комп-комп
2) комп-сеть
3) сеть-комп
4) сеть-сеть
TAP симулирует Ethernet устройство и работает на канальном уровне модели OSI, оперируя кадрами Ethernet. TUN (сетевой туннель) работает на сетевом уровне модели OSI, оперируя IP пакетами.
TAP используется для создания сетевого моста, тогда как TUN для маршрутизации.
wiki
Возможно создать Layer 3-based IP туннель, называемый TUN, и Layer 2-based Ethernet — TAP, способный передавать Ethernet трафик.
В принципе, все варианты можно реализовать на обоих видах, но с некоторыми оговорками. Например, мультикасты и броадкасты по L3 сами по себе не побегут.
Также есть отличия в настройке для linux, *bsd, windows.
[дальше варианты настроек]
1.1 Комп-комп, TUN
1.2 Комп-комп, TAP
2.1 Комп-сеть, TUN
2.2 Комп-сеть, TAP
3.1 Сеть-комп, TUN
3.2 Сеть-комп, TAP
4.1 Сеть-сеть, TUN
4.2 Сеть-сеть, TAP
Ссылки
http://openvpn.net/index.php/open-source/documentation/howto.html
http://ru.wikipedia.org/wiki/OpenVPN
http://ru.wikipedia.org/wiki/TUN/TAP
http://www.lissyara.su/doc/man/safety/openvpn/
http://www.anfes.ru/e107_plugins/content/content.php?content.6
http://tuxnotes.ru/articles.php?a_id=26
openvpn в centos
http://wolandblog.com/1103-ustanovka-i-nastrojka-openvpn-na-centos-5-3/
Варианты, которые могут быть:
1) комп-комп
2) комп-сеть
3) сеть-комп
4) сеть-сеть
TAP симулирует Ethernet устройство и работает на канальном уровне модели OSI, оперируя кадрами Ethernet. TUN (сетевой туннель) работает на сетевом уровне модели OSI, оперируя IP пакетами.
TAP используется для создания сетевого моста, тогда как TUN для маршрутизации.
wiki
Возможно создать Layer 3-based IP туннель, называемый TUN, и Layer 2-based Ethernet — TAP, способный передавать Ethernet трафик.
В принципе, все варианты можно реализовать на обоих видах, но с некоторыми оговорками. Например, мультикасты и броадкасты по L3 сами по себе не побегут.
Также есть отличия в настройке для linux, *bsd, windows.
[дальше варианты настроек]
1.1 Комп-комп, TUN
1.2 Комп-комп, TAP
2.1 Комп-сеть, TUN
2.2 Комп-сеть, TAP
3.1 Сеть-комп, TUN
3.2 Сеть-комп, TAP
4.1 Сеть-сеть, TUN
4.2 Сеть-сеть, TAP
Ссылки
http://openvpn.net/index.php/open-source/documentation/howto.html
http://ru.wikipedia.org/wiki/OpenVPN
http://ru.wikipedia.org/wiki/TUN/TAP
http://www.lissyara.su/doc/man/safety/openvpn/
http://www.anfes.ru/e107_plugins/content/content.php?content.6
http://tuxnotes.ru/articles.php?a_id=26
openvpn в centos
http://wolandblog.com/1103-ustanovka-i-nastrojka-openvpn-na-centos-5-3/
понедельник, 13 февраля 2012 г.
httpd dead but subsys locked
httpd dead but subsys locked
Решение:
rm /var/lock/subsys/httpd
Впрочем, помогает не всегда. Причин может быть много - нет места, кто-то мешает запустить (типа селинукса). Или свои же модули, например 2 раза грузится ssl. Это определить легко - при запуске ругается, что 443 порт занят, но при остановленном апаче его никто не занимает. Иногда бывает при обновлении и очень часто - при переписанных под себя конфигурациях.
Проверить:
netstat -tulpn
tail -f /var/log/messages
tail -f /var/log/httpd/error_log
Есть вариант через ipcs -s
Решение:
rm /var/lock/subsys/httpd
Впрочем, помогает не всегда. Причин может быть много - нет места, кто-то мешает запустить (типа селинукса). Или свои же модули, например 2 раза грузится ssl. Это определить легко - при запуске ругается, что 443 порт занят, но при остановленном апаче его никто не занимает. Иногда бывает при обновлении и очень часто - при переписанных под себя конфигурациях.
Проверить:
netstat -tulpn
tail -f /var/log/messages
tail -f /var/log/httpd/error_log
Есть вариант через ipcs -s
среда, 8 февраля 2012 г.
Оборудование huawei
Компания выросла из телефонной сферы.
Сегмент сетевого железа начал с клонирования чужого железа. Изначально это была циска, во всех планах - на их железо вставали циско-прошивки без каких-либо модификаций. Также их наименования были схожи и по возможностям можно было найти аналог циски, но дешевле (цена покупки), но цена сопровождения выше, как говорят.
Баш в тему
Из преимуществ - с поставками гораздо меньше проблем по сравнению с цисками. Железо дешевле цисок, особенно в нижнем сегменте.
Об оборудовании
http://forum.nag.ru/forum/index.php?showtopic=54893
БРАСы у них говно, мплс коробки - почти говно, Л2 свищи не говно, но сверху им обмазано.
Учитывая TCO по ценам сравнимо с цыской. Так что смысла брать не вижу, разве что те самые Л2 свищи, там на хорошей партии можно взять хороший дисконт. А в целом если вас откат не интересует, то это не ваш вендор.
BRAS MA5200g-2 нормально работет VRP на Version 5.30. ( но нада уметь его готовить)
NE40 - отстой
NE40E - норм
S8500 - норм
S2000 (S2403) - норм
Попробуйте в NE40E загрузить фуллвью от 6 пиров в vpn-instance и посмотрите как он будет тормозить. Даже с двумя пирами оно 15 минут туда грузится и жрет 100% CPU. Роутпроцессор на NE40E откровенно слабоват.
Если вы сравниваете с ценой ASR1002 ESP10 + 10G, то посмотрите на Juniper MX80. Шасси с 4х10G портами стоит $60К по GPL, производительность 80G, можно еще два модуля вставить.
По Huawei свитчи S3300/S5300 вполне ничего себе железки, на L2 работают стабильно, особых багов не замечено, что не понравилось по сравнению с Cisco, это гораздо более бедный набор команд. С маршрутизаторами Huawei не связывайтесь, по перфомансу в даташите написано одно, в жизни раза в 2 в 3 все более печально, особенно это ярко выражено на слабых железках AR/NE20/NE20E, старшие железки NE40/NE80E/NE80E по деньгам будут не дешевле Cisco или Juniper, по функционалу примерно то же, хотя по производительности на слот все так проигрывают заморским зверюшкам, и опять же очень скупой output у команд, ну и поддержка Huawei не самое дешевое удовольствие.
=====
Про S2300
Есть способ делать это без промежуточного софта и патча.
1. Зайти в hidden view
<Sхххх-SI>sys
Enter system view, return user view with Ctrl+Z.
[Sхххх-SI]_hide
Password:
Пароль - Vrp&8031
[Sхххх-SI-hidecmd]undo startup system-software
2. После этого можно удалить файл с флешки
<Sхххх-SI>delete /u xx.cc
3. После этого заливаем новый софт и радуемся жизни.
http://forum.nag.ru/forum/index.php?showtopic=49765&view=findpost&p=605802
Сегмент сетевого железа начал с клонирования чужого железа. Изначально это была циска, во всех планах - на их железо вставали циско-прошивки без каких-либо модификаций. Также их наименования были схожи и по возможностям можно было найти аналог циски, но дешевле (цена покупки), но цена сопровождения выше, как говорят.
Баш в тему
Из преимуществ - с поставками гораздо меньше проблем по сравнению с цисками. Железо дешевле цисок, особенно в нижнем сегменте.
Об оборудовании
http://forum.nag.ru/forum/index.php?showtopic=54893
БРАСы у них говно, мплс коробки - почти говно, Л2 свищи не говно, но сверху им обмазано.
Учитывая TCO по ценам сравнимо с цыской. Так что смысла брать не вижу, разве что те самые Л2 свищи, там на хорошей партии можно взять хороший дисконт. А в целом если вас откат не интересует, то это не ваш вендор.
BRAS MA5200g-2 нормально работет VRP на Version 5.30. ( но нада уметь его готовить)
NE40 - отстой
NE40E - норм
S8500 - норм
S2000 (S2403) - норм
Попробуйте в NE40E загрузить фуллвью от 6 пиров в vpn-instance и посмотрите как он будет тормозить. Даже с двумя пирами оно 15 минут туда грузится и жрет 100% CPU. Роутпроцессор на NE40E откровенно слабоват.
Если вы сравниваете с ценой ASR1002 ESP10 + 10G, то посмотрите на Juniper MX80. Шасси с 4х10G портами стоит $60К по GPL, производительность 80G, можно еще два модуля вставить.
По Huawei свитчи S3300/S5300 вполне ничего себе железки, на L2 работают стабильно, особых багов не замечено, что не понравилось по сравнению с Cisco, это гораздо более бедный набор команд. С маршрутизаторами Huawei не связывайтесь, по перфомансу в даташите написано одно, в жизни раза в 2 в 3 все более печально, особенно это ярко выражено на слабых железках AR/NE20/NE20E, старшие железки NE40/NE80E/NE80E по деньгам будут не дешевле Cisco или Juniper, по функционалу примерно то же, хотя по производительности на слот все так проигрывают заморским зверюшкам, и опять же очень скупой output у команд, ну и поддержка Huawei не самое дешевое удовольствие.
=====
Про S2300
Есть способ делать это без промежуточного софта и патча.
1. Зайти в hidden view
Enter system view, return user view with Ctrl+Z.
[Sхххх-SI]_hide
Password:
Пароль - Vrp&8031
[Sхххх-SI-hidecmd]undo startup system-software
2. После этого можно удалить файл с флешки
3. После этого заливаем новый софт и радуемся жизни.
http://forum.nag.ru/forum/index.php?showtopic=49765&view=findpost&p=605802
пятница, 3 февраля 2012 г.
Критическая уязвимость в PHP 5.3.9, позволяющая выполнить код на сервере
Критическая уязвимость в PHP 5.3.9, позволяющая выполнить код на сервере
В PHP обнаружена одна из самых серьёзных уязвимостей за время существования данного языка. Уязвимость проявляется только в PHP 5.3.9 и позволяет удалённому злоумышленнику выполнить свой код на сервере, независимо от того какие PHP-скрипты используются.
...
Всем пользователям PHP 5.3.9 рекомендуется в экстренном порядке наложить патч или вернуться на более ранний выпуск PHP. Официального уведомления и исправления пока не выпущено. Проблему усугубляет то, что поддержка директивы max_input_vars была портирована из PHP 5.3.9 многими дистрибутивами и включена в пакеты с более старыми версиями PHP. Например, в обновлении пакета php5-5.3.3-7+squeeze6 для debian Squeeze имеется поддержка директивы max_input_vars. Та же самая ситуация наблюдается в Red Hat Enterprise Linux 5 и 6, а также в Fedora Linux.
Уязвимость выявлена Стефаном Эссером (Stefan Esser), создателем проектов Hardened-PHP и Suhosin. Комментируя решение проекта Debian отказаться от использования Suhosin, Стефан указал на то, что уязвимость в PHP пришлась весьма кстати, так как она хорошо демонстрирует необходимость в использовании Suhosin, который значительно снижает возможность эксплуатации, даже в стандартной конфигурации.
====
"Комментируя решение проекта Debian отказаться от использования Suhosin,"
Правильно, зачем нам системы защиты для самого бажного языка в истории... Да, это не панацея. Но если этот патч закрывает хотя бы 5% проблем - он однозначно обязан включаться в штатные поставки.
И если они там не совсем идиоты, сухосин будет подключаться как доп модуль в случае убирания из штатного пакета. Документы дополнятся строчкой доустановки сухосина...
Как же надоел их маразм. Чуть не каждые пол года - серьёзные проколы, после чего хочется показать на их пользователей пальцем и сказать "ха-ха, создатели дебиана вам снова показали, что вы все - тупое стадо баранов, а они хозяева мира". Прочем, они свою позицию "вы все тупые, и мы лучше знаем, что вам делать" показывают давно. Хороший пример - jdk6 больше нельзя обновлять, так они новым обновлением просто сносят его.
Поэтому я до сих пор уважаю freebsd - они хотя бы не тыкают постоянно своих пользователей носом в говно.
А другие дистры для веб-сервера... Центось подходит плохо и требует напильника, остальные линукс-дистры ещё хуже, некоторые вроде мандривы вообще всё никак помереть не могут. Увы.
Впрочем, дебиан тоже использую, приходится. Но если каноникал, строясь на том же дебиане, сможет обеспечить в том числе платную поддержку + будет от таких вот маразмов вычищать и собирать нормальные пакеты - все сервера будут (принудительно) переводиться на убунту сервер.
В PHP обнаружена одна из самых серьёзных уязвимостей за время существования данного языка. Уязвимость проявляется только в PHP 5.3.9 и позволяет удалённому злоумышленнику выполнить свой код на сервере, независимо от того какие PHP-скрипты используются.
...
Всем пользователям PHP 5.3.9 рекомендуется в экстренном порядке наложить патч или вернуться на более ранний выпуск PHP. Официального уведомления и исправления пока не выпущено. Проблему усугубляет то, что поддержка директивы max_input_vars была портирована из PHP 5.3.9 многими дистрибутивами и включена в пакеты с более старыми версиями PHP. Например, в обновлении пакета php5-5.3.3-7+squeeze6 для debian Squeeze имеется поддержка директивы max_input_vars. Та же самая ситуация наблюдается в Red Hat Enterprise Linux 5 и 6, а также в Fedora Linux.
Уязвимость выявлена Стефаном Эссером (Stefan Esser), создателем проектов Hardened-PHP и Suhosin. Комментируя решение проекта Debian отказаться от использования Suhosin, Стефан указал на то, что уязвимость в PHP пришлась весьма кстати, так как она хорошо демонстрирует необходимость в использовании Suhosin, который значительно снижает возможность эксплуатации, даже в стандартной конфигурации.
====
"Комментируя решение проекта Debian отказаться от использования Suhosin,"
Правильно, зачем нам системы защиты для самого бажного языка в истории... Да, это не панацея. Но если этот патч закрывает хотя бы 5% проблем - он однозначно обязан включаться в штатные поставки.
И если они там не совсем идиоты, сухосин будет подключаться как доп модуль в случае убирания из штатного пакета. Документы дополнятся строчкой доустановки сухосина...
Как же надоел их маразм. Чуть не каждые пол года - серьёзные проколы, после чего хочется показать на их пользователей пальцем и сказать "ха-ха, создатели дебиана вам снова показали, что вы все - тупое стадо баранов, а они хозяева мира". Прочем, они свою позицию "вы все тупые, и мы лучше знаем, что вам делать" показывают давно. Хороший пример - jdk6 больше нельзя обновлять, так они новым обновлением просто сносят его.
Поэтому я до сих пор уважаю freebsd - они хотя бы не тыкают постоянно своих пользователей носом в говно.
А другие дистры для веб-сервера... Центось подходит плохо и требует напильника, остальные линукс-дистры ещё хуже, некоторые вроде мандривы вообще всё никак помереть не могут. Увы.
Впрочем, дебиан тоже использую, приходится. Но если каноникал, строясь на том же дебиане, сможет обеспечить в том числе платную поддержку + будет от таких вот маразмов вычищать и собирать нормальные пакеты - все сервера будут (принудительно) переводиться на убунту сервер.
вторник, 31 января 2012 г.
Уходим с SSL на TLS
Уходим с SSL на TLS
OpenSSL
Дока про работу с SSL - можно проверять в том числе возможности сервера.
В частности
И это дебиан 6.0.3! Впрочем, он отличается тормознутостью, сравнимой с даунизмом. Зато (типа) безопасный!
Вообще, в openssl с поддержкой TLS всё печально. Так что можно сразу переходить на gnutls.
Для этого придется править конфиги всех доменов с SSL. Универсальный метод - описать оба варианта сразу, например
Замечания: без 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
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 и отправка некоторых доменов через отдельные айпи
Находим секцию
дописываем до вида
domain.ru: 1.1.1.1
domain2.ru: 2.2.2.2
Остальные отправляться будут со стандартного айпи.
Находим секцию
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-компания" это совсем не тоже самое, что какая-нибудь лесопилка, пусть и с парой сотен/тысяч рабочих. Также надо смотреть на длительность возможного простоя и завязанность техпроцессов на работу информационных систем.
Поэтому для крупных компаний - да, железа будет меньше, его загруженность больше, админам работы станет чуть побольше в плане обслуживания софта - надо хост-системы обслуживать + виртуальных серверов обычно становится даже больше, поскольку создание новой виртуалки - процесс довольно простой, а выделение по машине под каждый сервис повышает надёжность и управляемость системы. Хотя если меньше железа - меньше нужно обслуживания аппаратной части, но уровень "дежурный инженер" обычно ниже и порой весьма дешевле комплекта профессионалов сеть-виртуализаторы-админы_виртуалок.
Для мелких компаний, у которых "сервера" это старые снятые с эксплуатации персоналки - абсолютно невыгодно, потому что надёжность старого железа, особенно уровня персоналок, очень низкая, а покупать новое железо выходит крайне дорого. Собирать же подобные системы из старья - никто никаких гарантий дать не может, железо будет не валидировано, нет 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
Старые факсы работают по протоколу Т.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.
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"
Но это + к стоимости за сервер. Хотя можно из скриптов запускать инстанс, ждать окончания и гасить, но если "вдруг" что-то изменится/сломается (ключ отозвали например), и мы не заметили и что-то сломалось, прощайте данные.
http://lucasmanual.com/mywiki/Bacula
Варианты исполнения
Через fuse-s3fs
Бэкапы через bacula на Amazon S3
Можно через s3cmd делать синхронизацию локального хранилища с удаленным.
"особо хитроумные пользователи AWS используют EC2 для бекапов и используют там rsync, а на s3 держат только снимки состояния EC2"
Но это + к стоимости за сервер. Хотя можно из скриптов запускать инстанс, ждать окончания и гасить, но если "вдруг" что-то изменится/сломается (ключ отозвали например), и мы не заметили и что-то сломалось, прощайте данные.
Подписаться на:
Сообщения (Atom)