Здравствуйте. Недавно я задавал вопрос по поводу создания цикла статей. Вот первая статья.

В этом цикле статей вы узнаете как грамотно настроить LAMP сервер, аля «хостинг только мощней».
Мы будем использовать следующий стек: nginx — apache-mpm-itk — mod_php — mysql — linux/debian.

Буду освещать следующие темы:

• Настройка frontend — backend
• Расчет возможностей сервера, настройка mysql и backend
• Рассказ об опыте на базе intel s3420gp

Совершенно уверенно могу сказать, что настройка LAMP сервера не ограничивается 6-10 командами установки и раскомментирования определенных строчек в файлах настройки.
Пример: по умолчанию nginx не дает возможности закачать на сервер тело запроса больше чем 1M. Если не настроить данный параметр, будет возникать ошибка 414 (Request-URI Too Large), при попытке добавления небольшой серии фотографий.
У apache совершенно противоположное: у него тело запроса по умолчанию не ограничено. Это делает возможным совершать пакости.

В этой статье мы познакомимся со всей настройкой досконально. В статье вы сможете найти конфигурационные файлы, подготовленные мной. Будучи педантом, мои конфигурационные файлы всегда сгруппированы по типу, например: «производительность», «генерация контента», «страницы ошибок», «сжатие», «другие настройки», «общие настройки». Мне кажется, что читаемость данных файлов становится намного лучше, если они сгруппированы.

Мы узнаем о том какие бывают простые атаки и как от них защищаться. Сразу скажу, что при базовой конфигурации frontend в лице nginx — backend apache все равно остается уязвим.

Я практически уверен, что я не смогу уместить все в одну статью. Добро пожаловать под кат.

Возникла задача сделать геотаргетинг для регионов России на новостном сайте, т.е. при заходе на главную страницу, должно происходить перенаправление на региональную страницу сайта с адресами вида: region/[номер региона], причем перенаправление клиента должно осуществляться на nginx-е без передачи данных на апач, в противном случае это лишняя ненужная нагрузка на сервер.

Для чего это надо

Гибернация (спящий режим) — это режим выключения системы при котором её текущее состояние, включая состояние ОЗУ, сохраняется на энергонезависимое хранилище.

Этот режим при использовании совместно с Proxmox позволяет значительно ускорить процесс завершения работы основной — хост-системы без необходимости завершать работу гостевых виртуальных систем. Особенно удобно, когда в качестве гостевой системы развернуты терминальные сервера на Windows. Ведь при штатном завершении работы такой системы, в окнах пользователей появляется запрос на сохранение редактируемого документа и если у пользователя тоже отключился свет вместе с его компьютером и монитором пользователь отсутствует на месте, принудительное завершение системы вызовет предынфарктное состояние потерю редактируемых сотрудником/ми данных. Вот тут и спасет гибернация хостовых нод и после восстановления электроснабжения пользователи смогут продолжить работать с того-же места!
Конечно, что-бы такое произошло нужно еще настроить ИБП сервера. Переход в режим гибернации удобно назначить в качестве события при разряде батареи ИБП, а благодаря скорости перехода в этот режим можно серьезно снизить требования к ёмкости его батарей.

Администраторам Linux писать скрипты на Bash приходится регулярно. Ниже я привожу советы, как можно ускорить эту работу, а также повысить надежность скриптов.

Совет 1

Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».

Совет 2

Отталкиваясь от предыдущего, в начало каждого скрипта неплохо помещать что-то вроде:

read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE 
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2

Команда echo, кстати, здесь нужна потому, что после нажатия кнопки <y> у вас не будет перевода строки, следовательно, следующий любой вывод пойдет в эту же строку.

Совет 3

Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:

Это вторая часть перевода статьи What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text, первая часть — тут.

Мой документ – полная чушь в любой кодировке!

Если последовательность бит не выглядит разумной(с точки зрения человека), то это случай, когда документ скорее всего был неверно сконвертирован в определенный момент. К примеру мы берем текст ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢ, и, не придумав ничего лучше, сохраняем его в UTF-8. Текстовый редактор предположил, что он правильно прочитал текст с кодировкой Mac Roman и теперь его надо сохранить в другой кодировке. В конце концов, все эти символы валидны в Unicode. В смысле, в Unicode есть пункт для É, для G, и так далее. Так что мы просто сохраняем его в UTF-8:

11000011 10001001 01000111 11000011 10001001 11000011 10101100 11000011 10001001 01010010 11000011 10000101 01011011 11000011 10001001 01100110 11000011 10001001 01000010 11000011 10001001 11000011 10101100 11000011 10001001 01001111 11000011 10000111 11000011 10010101 11000011 10101100 11000011 10010100 11000011 10000111 11000010 10110101 11000011 10000111 11100010 10001001 10100000 11000011 10000111 11000010 10111011 11000011 10000111 11000010 10100010

Спустя почти 70 лет после окончания Второй мировой войны в дымоходе одного из особняков деревни Блетчингли, Великобритания были обнаружены останки голубя с привязанным к лапе почтовым контейнером красного цвета.

В многих местах вижу вопросы о том, как настроить ipv6 для контейнеров в proxmox, а так-же, почему не работает онлайн бекап.

Сам уже довольно давно пользуюсь proxmox для виртуализации openvz (разделение сервисов, тесты, дев. окружения) ну и все это крутится на hetzner.

О том, как установить и настроить proxmox — писать не буду, на Хабре в частности, да и в интернете в целом — этой информации полно. Не смотря на то, что лучший источник такой информации — официальный вики.

Но что в вики нет, так это того, как же правильно ставить proxmox на дебиан.

По долгу службы мне время от времени приходится копировать, архивировать, разархивировать и проводить другие стандартные действия с большими файлами. Консольные утилиты, типа cp, tar или cat — отлично справляются с поставленной перед ними задачей, но возникает одна маленькая проблема: предположим, что надо заархивировать SQL-дамп на 500 Мб, на среднем железе данная операция может выполняться 5 — 10 минут и при этом, стандартный tar не выводит никакой строки прогресса, т.е. консоль как бы подвисает и только открыв top в соседнем окне можно понять что что-то происходит. Я думаю, что будет намного удобнее, если в консоли появится полоска прогресса как в том же scp и тогда пользователь будет лучше осведомлен о том, как долго ему осталось ждать до завершения операции.

Один мой друг сказал по поводу pv следующее «Я админю семь лет, мне нужна была эта тулза десятки раз, а я даже не знал что она существует». В размышлениях над тем как заполучить инвайт на Харбе, я набрал в поиске pv. И ничего не нашел.

Ratchet — новый фреймворк, который позволяет быстро создавать прототипы приложений для iOS. По сути является аналогом Twitter Bootstrap для мобильных устройств.

Сайт проекта | Ratchet на GitHub | Обсуждения в Google Groups | Twitter

Феерическая расстановка точек над i в вопросе удаления файлов из переполненной директории.

Прочитал статью Необычное переполнение жесткого диска или как удалить миллионы файлов из одной папки и очень удивился. Неужели в стандартном инструментарии Linux нет простых средств для работы с переполненными директориями и необходимо прибегать к столь низкоуровневым способам, как вызов getdents() напрямую.

Для тех, кто не в курсе проблемы, краткое описание: если вы случайно создали в одной директории огромное количество файлов без иерархии — т.е. от 5 млн файлов, лежащих в одной единственной плоской директории, то быстро удалить их не получится. Кроме того, не все утилиты в linux могут это сделать в принципе — либо будут сильно нагружать процессор/HDD, либо займут очень много памяти.

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

В связи с вступлением в силу нашумевшего закона 149-ФЗ у многих хабравчан возник вопрос: а что будет дальше? Неужели в России появится аналог Великого Китайского Фаервола, который будет блокировать всё и вся? В данном туториале я хотел бы рассмотреть один из самых эффективных и безопасных способов обеспечения себе свободы информации — собственный VPS сервер, находящийся далеко за границей и связанного с вами с помощью зашифрованного VPN туннеля. В отличие от tor или i2p конфиденциальность передаваемой информации гарантированна, вряд ли кто-то будет пытаться расшифровать ваши данные или устраивать рейд на заграничный сервер (если конечно вы не хакер мирового масштаба).

Не так давно я рассказывал, как у нас в Topface устроено хранение и раздача пользовательских картинок на Topface Developer Day (презентация на speakerdeck). Картинки мы нарезаем на лету в nginx с помощью image_filter.

Люди в основном продолговатые в вертикальном направлении и фотографии себя для сервиса знакомств делают соответствующие, дизайнеры хотят квадратики, а nginx вырезает людям не совсем то, что интересует людей (лицо я имею в виду). На примере longcat получается примерно следующее:

Предистория

Рано или поздно системный администратор сталкивается с необходимостью распределить трафик по нескольким каналам, при этом естественно желание чтобы каждый канал использовался по максимуму. Столкнувшись с подобной необходимостью, и решив не изобретать велосипед, обратился к помощи поисковиков. Так как сервер у меня на Ubuntu, то обратил свое внимание на статью http://help.ubuntu.ru/wiki/ip_balancing. Реализовал «Способ 1», но при тесте были замечены следующие критичные проблемы: при использовании ссылок на некоторых сайтах они не открывались (например при попытке включить музыку на ресурсе «ВКонтакте»). Причина очевидна — запрос шел через другой канал. Обдумав ситуацию, решил скомбинировать подход к балансировке. Логика проста — больше всего съедает трафика торренты и им подобные программы, поэтому разделяем трафик. В итоге трафик с портами до 11000 распределяем приблизительно равномерно по количеству абонентов — подсетями, трафиком с портами 11000-60000 выравниваем загрузку каналов.

Наверняка почти все читатели Хабра знают оболочки sh и bash. Так же большинство из нас что-то слышали про zsh и tcsh. Однако на этом список существующих оболочек не заканчивается. Условно можно разделить их на три группы:

• Клоны Bourne shell (bash, zsh)
• C shell (csh, tcsh)
• Базирующиеся на популярных языках программирования(psh, ipython, scsh)
• Экзотические, специфические и все остальные

О наиболее интересных из них и пойдет речь.

Check Point Software Technologies является одним из мировых лидеров в области обеспечения интернет-безопасности. Сетевые экраны Check Point используются во многих банковских учреждениях. К сожалению, в Сети практически отсутствует информация о конфигурировании этих устройств. Попробуем восполнить этот пробел.

Есть два основных документа, которые чаще всего упоминаются при обсуждении стандартов центров обработки данных: это стандарт TIA 942 и классификация по уровням от Uptime Institute. Оба этих документа регламентируют уровни (Tier), что часто приводит к путанице: например, Tier III по TIA 942 и Tier III по Uptime Institute — это две большие разницы.

TIA vs Uptime

TIA 942 — Telecommunications Industry Association — Telecommunications Infrastructure Standard for Data Centers:

• Этот стандарт разработан ассоциацией телекоммуникационной промышленности США и, в первую очередь, касается вопросов организации структурированных кабельных систем в ЦОД, и в меньшей степени вопросов отказоустойчивости и других инженерных подсистем.
• Носит рекомендательный характер.
• Есть пошаговые инструкции и рекомендуемые схемы (помощь инженеру). «Делай как тут написано и получишь хороший результат».
• Соответствие стандарту заявляется владельцем объекта или исполнителем проекта (на уровне «Я делал как вы сказали, честное слово»).
• Обычно, на соответствие стандарту проверяется только проектная документация.
• Однажды реализованный объект не теряет уровень.

В первой части я рассказал об основных особенностях системы управления конфигурациями Puppet. Во второй части мы настроим две машины для того, чтобы попробовать базовые вещи.

Для имён хостов я решил использовать имена роботов из эпопеи Джорджа Лукаса «Звёздные войны»: R2D2 и C-3PO. Так как R2 умнее, то он будет управлять C-3PO.

Puppet — это инструмент, который позволяет автоматизировать настройку и управление большим парком машин. Используя Puppet вы сможете централизованно управлять конфигурациями одной, десятков, сотен и тысяч машин.

В этой статье я расскажу об основных особенностях системы.

Puppet — довольно удобный инструмент для управления конфигурациями. По сути, это система, которая позволяет автоматизировать настройку и управление большим парком машин и сервисов.

Базовой информации о самой системе много, в том числе и на Хабре: здесь, здесь и здесь. Мы же постарались собрать в одной статье несколько «рецептов» использования Puppet под действительно большими нагрузками — в «боевых условиях» Badoo.

О чём пойдет речь:

• Puppet: ликбез;
• кластеризация, масштабирование;
• асинхронный Storeconfigs;
• сбор отчётов;
• анализ полученных данных.