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

Итак задача:
Организовать удобное администрирование многодоменного web сервера.
Модель системы: linux -> nginx -> apache -> php -> mysql.

Раньше у меня для каждого домена были отдельные конфиги для nginx и apache,
и для добавления нового хоста требовалось добавить как минимум 2 конфига.

Работа была организована удобно. По сути, были 2 скрипта. 1 для добаления хоста к nginx, другой для apache. (ещё есть скрипт добавления хоста в bind но это другая история).

Но и это было не удобно в условия добавления удаления хостов… иногда забыл nginx прописать, иногда в апаче чтото не то…
Решено было следующим образом:

На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.

Что такое OAuth 2.0

OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.

В моем первом посте я описал применение Apache Traffic Server в качестве кеширующего reverse-proxy. В отзывах меня спрашивали почему не nginx? Поскольку в ATS все равно не нашлось удобного способа трансформировать контент сайта, то я решил изучить возможности Nginx. Для решения задачи пришлось углубится в дебри документации, и вот что получилось…

Хочу рассказать о простом скрипте, позволяющем защититься от двойного запуска заданий cron.

Допустим, раз в минуту вы обновляете некий кеш, чтобы стремительно отдать его миллионам посетителей сайта. Все идет прекрасно, но ровно до тех пор, пока глубокой ночью не запустится еженедельный бэкап и ваш кеш сформируется не за 10 секунд, а за 70, и на 60-й секунде его настигнет еще один процесс формирования кеша.

Что будет в таком сценарии дальше — вопрос весьма интересный. Велика вероятность, что два процесса будут активно мешать друг другу (они ведь работают с одними и теми же объектами), и их общее время выполнения будет отнюдь не в два раза больше, чем обычно, а если и третий настигнет…

Привет, Хабрачитатель!
Полнотекстовый поиск данных в InnoDB – это известная головная боль многих разработчиков под MySQL / InnoDB. Для тех, кто не в курсе дела я объясню. В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных, однако сама таблица исторически имеет ограничения, которые являются принципиальными в отдельных проектах. В более «продвинутом» типе таблиц InnoDB полнотекстового поиска нет. Вот и приходится мириться бедным разработчикам либо с ограничениями MyISAM, либо с отсутствием поиска в InnoDB. Я хочу рассказать о том, какие есть способы организовать полноценный поиск в InnoDB без магии и исключительно штатными средствами. Также будет интересно сравнить скоростные характеристики каждого способа.

В любом деле самое сложное — это начало. Часто бывает тяжело войти в контекст, с чем столкнулся и я, решив разработать свое первое Android-приложение. Настоящая статья для тех, кто хочет начать, но не знает с чего.

Статья затронет весь цикл разработки приложения. Вместе мы напишем простенькую игру “Крестики-Нолики” с одним экраном (в ОС Android это называется Activity).

Отсутствие опыта разработки на языке Java не должно стать препятствием в освоении Android. Так, в примерах не будут использоваться специфичные для Java конструкции (или они будет минимизированы на столько, на сколько это возможно). Если Вы пишете, например, на PHP и знакомы с основополагающими принципами в разработке ПО, эта статья будет вам наиболее полезна. В свою очередь так как, я не являюсь экспертом по разработке на Java, можно предположить, что исходный код не претендует на лейбл “лучшие практики разработки на Java”.

Серию официальных постов в блоге компании про то, как работать с облаком я ещё продолжу, но параллельно мне хочется рассказать про те проблемы, с которыми мы столкнулись во время адаптации Xen Cloud Platform под нашу модель работы облака. Эти посты будут чуток сложнее и предполагают, что читатель хотя бы в общих чертах знает, как работает Xen.

Когда концепция «оплата по потреблению» только-только оформлялась, а я судорожно искал «как считать», мне казалось, что процессор и память — это два самых простых ресурса.

Действительно, у нас есть xencontrol (библиотека управления гипервизором Xen), которая может точно сказать про каждый домен (запущенную виртуальную машину), сколько у неё есть памяти, сколько наносекунд времени было потрачено. Эта библиотека запрашивает информацию напрямую (через xenbus) у гипервизора и подвергает её минимальной обработке.

Выглядит эта информация примерно так (вывод биндинга xencontrol для питона):

{
    'paused': 0, 
    'cpu_time': 1038829778010L, 
    'ssidref': 0, 
    'hvm': 0, 
    'shutdown_reason': 0, 
    'dying': 0, 
    'mem_kb': 262144L, 
    'domid': 3, 
    'max_vcpu_id': 7, 
    'crashed': 0, 
    'running': 0, 
    'maxmem_kb': 943684L, 
    'shutdown': 0, 
    'online_vcpus': 8, 
    'handle': [148, 37, 12, 110, 141, 24, 149, 226, 8, 104, 198, 5, 239, 16, 20, 25], 
    'blocked': 1
}

Как мы видим, есть поле mem_kb, соответствующее выделенной памяти для виртуальной машины и есть поле cpu_time, содержащее какое-то умопомрачительное число (хотя на самом деле это всего лишь 17 минут). cpu_time считает с точностью до наносекунд (точнее, величина, которая тут хранится считается в наносекундах, реальная точность около микросекунды). Память, как понятно, в килобайтах (хотя внутренней единицей учёта, что гипервизора, что ядра линукс является страница — её размер по-умолчанию 4 килобайта).

Казалось бы «бери и считай», однако, дьявол кроется в деталях…

Извините за жёлтый заголовок ниже, но именно так звучал вопрос в полемике в ходе обсуждения одной из проблем:

Hyper-threading + Xen = воровство денег у клиентов

Сегодня, 26 января, в полночь по GMT, наступил 15000 день от начала летоисчисления Unix машин. Юниксоиды всех стран встречаются, празднуют, проводят массовые гуляния и гадают. Встречи локальных групп можно найти на специальном сайте, посвящённом этому знаменательному дню.
День можно посмотреть командой:

$ echo `date +%s`/86400|bc

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

Учёт интернет-трафика, наверное, самая простая тема из всех. Сколько байт на сетевой интерфейс пришло — такой и входящий трафик. Сколько байт ушло — такой и исходящий.

Необычным, наверное, является только то, что учитывается трафик не на третьем (сетевом) уровне, а на втором (канальном). Никакого сакрального смысла выбор уровня не несёт, просто в используемой технологии наиболее точный и простой учёт осуществляется именно по числу байт, переданных на канальном уровне. С технической точки зрения это учёт переданных байтов через VIF (виртуальный сетевой интерфейс машины). Единственным неприятным побочным эффектом является то, что всякий служебный трафик, такой как исходящие бродкасты, ARP и т.д. так же учитывается. Но, с учётом стоимости трафика (10^-6 рубля за килобайт) я с трудом себе представляю, как можно служебным трафиком намотать хотя бы на копейку.

А положительным аспектом (для нас, а в каком-то смысле и для клиента) является то, что если клиент поднимает тяжёлое приложение на втором уровне (l2tp, PPPoE, ATAoE), то оно посчитается так же, как и любой другой L3 протокол, без необходимости «довить» на клиента и принуждать его к прекращению использования неудобного для учёта протокола, не укладывающегося в модель «считать по IP».

Зачастую при развёртывании сети машин на Ubuntu возникает проблема с организацией доступа в интернет с целью установки новых программ из стандартных репозиториев. Например, когда доступен лишь очень узкий канал в интернет или траффик не является безлимитным. К счастью, принцип организации пакетной системы Ubuntu позволяет очень гибко управлять тем, что и откуда качать с использованием штатных средств управления пакетами. В частности, вы можете создать локальную копию нужных вам интернет-репозиториев Ubuntu и подключить её как основной источник приложений в вашу локальную сеть. Таким образом все компьютеры в вашей сети не будут требовать соединения с интернетом для установки новых программ и обновлений. И при этом, что самое важное, сохранится весь функционал пакетных менеджеров.

В этой статье я расскажу как создать локальную копию репозитория с помощью утилиты apt-mirror. Это простая и удобная утилита для создания локальных копий репозиториев Ubuntu, использующая такой же синтаксис, как и в файле /etc/apt/sources.list, в котором указываются все репозитории для Ubuntu.

Всё, что вам потребуется — это компьютер с установленной Ubuntu и безлимитным доступом к интернету.

Это шестая, заключительная часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»
• «Процесс слияния»

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

Часть 6. Архитектура репозиториев

Наш рецепт становится все лучше:

Есть программа iperf, которая позволяет проверять скорость интерфейсов (у меня на тестах из 10G интерфейса она выжимала 9.37 Гбит/с).

Пакет (в дебиане и убунте) так и называется — iperf.

Применение очень простое: на одном сервере запускаете iperf -s X.X.X.X (свой собственный адрес сервера, на котором слушать). Можно запустить просто iperf -s, тогда слушать будет на всех интерфейсах.

На клиентской части пишем iperf -c X.X.X.X (адрес сервера из предыдущего этапа). Клиент подключается, работает 10 с и показывает скорость работы канала.

Пример: сервер имеет адрес 192.0.2.1, клиент 192.0.2.200. На сервере запускаем iperf -s 192.0.2.1 на клиенте iperf -c 192.0.2.1.

Для того, чтобы сделать много байтов (привет хостерам с соотношениями) нужно просто указать опцию -t (время в секундах). Многие гигабайты трафика в нужном направлении вам обеспечены. С учётом текущих тарифов для дома — можно даже с домашней машины, за 3-4 часика можно выправить любое соотношение с минимальной нагрузкой как на сервер, так и на клиента.

Это пятая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»

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

Часть 5. Процесс слияния

Обеспечение слаженной работы нескольких людей над одним и тем же кодом — это важная функция системы контроля версий.

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

Я оказываю услуги по настройке web- и БД-серверов. На днях ко мне обратился Иван Усачёв — владелец портала ochevidets.ru с просьбой избавить сайт от торможения.

Страницы в пиковое время стали долго загружаться, вплоть до 5 минут на страницу.

UPDATE: Статья была написана в 2010 году. Кое-что изменилось: вышли новые версии программ, у nginx изменились некоторые директивы и появились новые. Учитывайте это.

В этой статье будут описаны различные настройки MySQL, преимущественно те, которые влияют на производительность. Для удобства все переменные разделены по разделам (базовые настройки, ограничения, настройки потоки, кэширование запросов, тайминги, буферы, InnoDB). Сначала уточним имена некоторых переменных, которые изменились в версии 4 MySQL, а в сети продолжают встречаться и старые и новые варианты имен, что вызывает вопросы.

Когда передо мной в очередной раз встала задача об одновременной загрузке нескольких файлов на сервер (без перезагрузки страницы, само собой), я стал блуждать по интернетам в поисках довольно корявого jQuery-плагина, который позволяет имитировать ajax-загрузку файла (того самого плагина, который со скрытым фрэймом: от java- и flash- плагинов сразу было решено отказаться). В процессе поиска я вспомнил, что в грядущем стандарте html 5 возможности по работе с файлами должны быть существенно расширены, и часть этих возможностей доступна уже сейчас. В итоге было решено опробовать их в действии.

Рассматривать возможности File API будем на примере одновременной загрузки нескольких картинок на сервер. В конце статьи приводится готовое решение, оформленное в виде jQuery-плагина.

Первый отрывок третьей части серии руководств для новичков. Практически всё, что нужно знать, чтобы найти справочную информацию по вашей системе. Короче, RTFM и не задавайте глупых вопросов.

Навигация по основам Linux от основателя Gentoo:

Часть I: 1, 2, 3, 4

Часть II: 1, 2, 3, 4, 5

Часть III

1. Документация (вступление)
2. Модель прав доступа
3. Управление аккаунтами
4. Настройка окружения (итоги и ссылки)

Высоконагруженный проект (web-сайт) — не обязательно популярная социальная сеть, видеохостинг или MMORPG. Простейший способ резко повысить требования сайта к железу — перенести хранение сессий в БД. В этой статье мы рассмотрим способ хранить данные в БД, и при этом не жертвовать производительностью. Пожертвовав небольшим объемом ОЗУ можно прилично сэкономить процессорное время. Мы говорим о стиуации, когда недоступны memcached и другие специальные средства кэширования.

В этой заметке я опишу методы увеличения производительности линуксового маршрутизатора. Для меня эта тема стала актуальна, когда проходящий сетевой трафик через один линуксовый маршрутизатор стал достаточно высоким (>150 Мбит/с, > 50 Kpps). Маршрутизатор помимо роутинга еще занимается шейпированием и выступает в качестве файрволла.

Предлагаю вашему вниманию простое и дешевое (по ресурсам) решение для перенаправления пользователей мобильных устройств на легкую версию сайта. Решение ориентировано на highload сайты, оптимизация которых основана на кешировании гостевых запросов.
Проверка, является ли клиент мобильным устройством, производится веб-сервером nginx и в случае успеха клиент перенаправляется на поддомен или локейшн. Это существенно экономит ресурсы и позволяет добиться большей масштабируемости по сравнение с PHP методами.