Вездесущий… это определённо то слово, которым можно описать язык PHP по отношению к вебу. Он действительно вездесущ. В настоящее время, среди всех серверных языков программирования, PHP используется наиболее широко. На нём написаны более 80% сайтов, при этом следующий по популярности ASP.NET со своими 17% остаётся далеко позади.



Почему? Что позволило PHP стать настолько популярным и широко используемым? На этот вопрос нет однозначного ответа, но простота использования языка, безусловно, существенный фактор, поспособствовавший его успеху. Новички в PHP могут быстро выйти на достаточный уровень и разместить динамический контент на своих веб-сайтах с минимум познаний в программировании.

Именно в этом и заключается основная проблема поиска высококвалифицированных PHP-разработчиков. Относительно низкий порог вхождения и 20 лет развития языка привели к тому, что PHP-программисты стали такими же вездесущими, как и сам PHP. Многие из них могут на законных основания утверждать, что «знают» язык. Однако разработчики, которые действительно являются экспертами по PHP, способны создавать куда более функциональное, надёжное, масштабируемое и простое в сопровождении программное обеспечение.

Как же отличить тех, кто обладает реальной компетентностью в PHP (не говоря уже о тех, кто входит в 1% наиболее опытных кандидатов) от тех, у кого только поверхностные знания?

Конечно, статья не совсем верно названа. В чистом Redmine особо больших проблем с производительностью нет. Но мы, в процессе разработки большого количества плагинов, эти проблемы с легкостью вносили.

Поэтому, статья расскажет о том, как разобраться в чем причина медленной работы той или иной функции плагина Redmine и какие инструменты могут помочь в этом. Многие советы, естественно, могут касаться не только самого Redmine, но и Rails-приложений в целом.

Симптом у проблем с производительностью всегда один – это разгневанный пользователь, кричащий, клянущий твое ПО и возможно тебя лично.

Баста карапузики, кончилися танцы.

В предыдущей части мы детально рассмотрели «читерские» приёмы обхода «защит» (скрытие SSID, MAC-фильтрация) и защит (WPS) беспроводных сетей. И хотя работает это в половине случаев, а иногда и чаще — когда-то игры заканчиваются и приходится браться за тяжёлую артиллерию. Вот тут-то между вашей личной жизнью и взломщиком и оказывается самое слабое звено: пароль от WPA-сети.

В статье будет показан перехват рукопожатия клиент-точка доступа, перебор паролей как с помощью ЦП, так и ГП, а кроме этого — сводная статистика по скоростям на обычных одиночных системах, кластерах EC2 и данные по разным типам современных GPU. Почти все они подкреплены моими собственным опытом.

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

В этой статье не будет описываться, как можно быстро настроить icecast в различных Linux системах для разных задач. Нет. В этой статье хотелось бы осветить маленькую историю одного небольшого проекта по выводу эфирной радиостанции в глобальную сеть. С какими проблемами пришлось столкнуться и как мы их решали.

Итак. Маленькая предистория — есть радио-холдинг из нескольких эфирных музыкальных радиостанций с головным офисом в столице нашей родины Москве. Сами радиостанции вещают себе в FM диапазоне столицы, имеют свою аудиторию и вполне себе счастливы своим слушателем. Но вот незадача — на дворе 2012 год, а направление интернет вещания развивается не шатко не валко. Дальше будет много слов и маленьких историй в рамках одной основной, если заинтересовало, добро пожаловать под кат.

Средства для резервного копирования информации можно разделить на несколько категорий:
— Для домашнего/офисного применения (резервирование важных документов, фотографий и пр. на NAS либо в облако);
— Для средних и крупных (offline) предприятий (резервирование важных документов, отчетности, баз данных и пр. как на серверах так и на рабочих станциях сотрудников);
— Для малых веб-проектов (резервирование файлов и баз данных с хостинговой площадки либо VPS/VDS на удаленный хост (или наоборот));
— Для крупных веб-проектов с распределенной архитектурой (почти то же самое, что и на offline-предприятиях только с учетом работы в глобальной сети, а не локальной, и как правило с использование open source средств).

С программными продуктами для дома и офиса все достаточно просто есть масса решений как открытых так и проприетарных, от cmd/bash скриптов до решений известных производителей ПО.
В enterprise секторе все достаточно скучно есть масса программных продуктов которые давно и успешно работают на многих предприятиях, в крупных банках и пр, рекламировать никого не будем. Многие из этих продуктов хорошо упростили жизнь системных администраторов, за достаточно «скромные деньги» по меркам некоторых предприятий.
В данной статье более подробно рассмотрим open source решения для резервного копирования веб-проектов разного масштаба, а также проведем тест на скорость резервирования файлов.
Статья будет полезна веб-мастерам, небольшим веб-студиям, ну и возможно даже бывалый админ найдет здесь что-то полезное.

Предыстория

Существует красивое решение для создания надёжного недорогого кластера основанное на DRBD + Proxmox VE. Страница в Wiki проекта Proxmox появилась 11 сентября 2009-го года и создана она была CEO компании Martin-ом Maurer-ом.



С тех самых пор это решение стало очень популярным, и никто не подозревал, что у этого решения есть скрытый подводный камень. В документации про это не пишут, а те, кто сталкивался с последствиями этой проблемы (например, зависание машины при онлайн миграции с одного хоста на другой), списывали всё на «случай». Кто-то грешил на железо, кто-то на Proxmox, а кто-то на драйверы внутри виртуальной машины. Конечно, хотелось бы, чтобы DRBD сам сообщал о своих проблемах, и, как-то подсознательно веришь в то, что он так и делает. Проверяешь /proc/drbd, видишь строку «cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate» и продолжаешь верить что DRBD не причём.

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

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

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Сегодня существует довольно много профессиональных инструментов для мониторинга состояния серверов с обилием настроек, плагинов, поддержкой сразу множества машин и т.д., это известные Nagios, Zabbix, Munin, Cacti и многие другие.


Но в этом посте речь пойдет об очень маленьком и простом, но от этого не менее полезном инструменте: инструменте для мониторинга Scout Realtime. Этот написанный на Ruby open source проект позиционируется разработчиками как современная замена консольной утилите top с выводом статистики использования диска, памяти, сети, CPU и запущенных процессов. Все это отображается в реальном времени с плавными графиками. Во время диагностики работы сервера, иногда полезно пару минут понаблюдать за показателями, и проследить их изменение во времени (в отличие от гирлянды мерцающих чисел в терминале, отображающих данные исключительно на текущий момент).

В последнее время набирает популярность идея SDN (Software-defined Networking). На фоне данной концепции, а может и под её влиянием, развивается идея и SDS – Software Defined Storage. Данное направление выглядит перспективным и начинает активно развиваться, к примеру, выход в бета версии VSAN.

Часть вторая

Прелюдия

Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.

Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам.

Вводные

Требования у меня были простые: создать кластер для работы виртуальных машин, не имеющий единой точки отказа. А в качестве бонуса — хранилище должно было уметь шифровать данные, чтобы враги, утащив сервер, до них не добрались.

В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.

Осталось хранилище. Разные брендовые решения от ведущих вендоров были отброшены по причине большой стоимости как их самих по себе, так и лицензий на синхронную репликацию. Значит будем делать сами, заодно и поучимся.

В качестве софта было выбрано:

• Debian Wheezy + LTS ядро 3.10
• iSCSI-таргет SCST
• DRBD для репликации
• Pacemaker для управления ресурсами кластера и мониторинга
• Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)

В итоге, в недолгих муках была рождена такая несложная схема:

Вступление (лирическое)

Привет, Хабр!

Для меня, автоматизатора-линуксоида, использвание Windows на основной рабочей станции первое время было просто болью и страданием. Но с этим я ничего поделать не мог: корпоративные стандарты и софт, кторый работает только на Windows. В попытке найти золотую середину, я прошёл три стадии. Сначала я только изредка переключался на винду по необходимости. Затем виртуалка на virtualbox-е с X-server-ом. После этого захотелось хоть чуть-чуть того консольного комфорта, который был на линуксе (я использовал Terminator в качестве основного терминала).

После яростного гугления и установки всех эмуляторов терминала под Windows, которые только удалось найти, оказалось, что нет ни одного хоть немного подходящего мне. А хотелось, чтобы вёл себя терминал максимально приближенно к линуксовым вариантам. Например, естественно нужны табы, сплит, выделение текста с прокруткой (когда нужно выделить больше чем один экран), копирование текста в буфер сразу при выделении и т.д.

В итоге я получил «комбайн» как на скриншоте ниже. О том, как это настроить, можно узнать, заглянув под кат.

В этой статье я расскажу как удобно осуществлять отладку кода в PhpStorm на примере работы с веб-сайтом, работающем в системе 1C-Битрикс. Работать будем с IDE PhpStorm и отладчиком XDebug. Я предполагаю, что на вашем сервере уже установлен XDebug и у вас уже создан проект в PhpStorm.

В данной статье примеры приводятся с таким набором инструментов:

• Веб-сервер — MAMP PRO
• XDebug v2.2.3.
• IDE PhpStorm 7.1
• На моем локальном серевере установлен 1С-Битрикс 14 версии с решением интернет-магазина.

Итак, начнем.

Доброго времени суток, уважаемые пользователи Хабра.

После очередной вспышки вирусной активности в сетевой папке нашей организации я задумался об ее антивирусной защите. Речь идет о сетевой папке, за которую отвечает Samba, работающая на Debian Wheezy.

Обратившись в гугл за информацией, я нашел 2 актуальных на текущий момент способа:

Жил да был у меня роутер одной хорошей фирмы на букву «Dead». Ну, это с ним, собственно, и случилось.
Посмотрел я на цены новых, на кучу компьютерного хлама в углу, на список подключений на домашнем компе… И понял, что не нужен мне роутер. Соберу свой, с нормальной маршрутизацией, DNS, WINS, i2p, блекджеком и так далее.

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

Представьте, что у Вас есть веб-приложение и одной из его функций является массовая рассылка новостей Вашим пользователям.
По некоторым причинам часть email адресов пользователей нерабочие или неверно заполненные. Хорошо бы таких пользователей автоматически отписать от рассылки?

Моя машина меня устраивает почти всем. Есть практически все, что нужно. В комплектации блютусный телефон, кнопочный климат-контроль, электростеклоподъемники на всех дверях, подогрев сидений, подогрев, регулировка и складывание зеркал, чип-ключ, CD-чейнджер на 6 дисков, но без MP3 и линейного входа. Вот этот прискорбный факт и привел меня к мысли начать собрать свой CarPC на базе андроида. Начал рассматривать варианты и покатился… появилось много идей.

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

Спасибо каждому, кто читал и комментировал первую часть. Благодаря вам, продолжение будет еще интереснее. Если еще не читали — рекомендую это сделать. Там мало текста, и есть классные видео.

Изначально планировалось, что эта часть будет завершающей. Но, для удобства попадания в скролл, сейчас остановимся лишь на этих вопросах:

• Тренировки. Вырабатывание летных навыков.
• Выбор модели: самолет, вертолет или мультикоптер?
• Выбор конкретной конструкции и размера
• Моторы и ESC
• Полетный контроллер

Как обычно, сразу к делу.

Привет всем!

Не так давно я задался целью обеспечить интернетом жену, отдыхающую все лето с ребенком в деревне. Даже ответственно озаботился покупкой сим-карты для ее любимого айпадика (раньше как-то обходились wi-fi). Каково же было мое разочарование, когда по приезду в деревню я обнаружил почти полное отсутствие сигнала сотовой сети что на планшете, что на мобильных телефонах… Понятно — зря выкинул деньги на симку. Неделя моего пребывания в деревне ознаменовалась лазаньем по чердакам, крышам, просто по участку, уткнувшись в смартфон в надежде увидеть хотя бы GPRS. Все тщетно… Отбыл в Москву, мои остались в этой глухомани отдыхать от радиоволн.

По дороге домой обдумывал план решения проблемы. Необходимость в интернете у жены диктовалась даже не сколько развлекательными целями, сколько возможностью бесплатно переписываться по Viber и регулярно снабжать меня фотками дочурки (надо сказать, писать sms и mms из Тверской области в Москву недешево). Так же давало надежду знание того, что в другой деревне, в паре километров, интернет работал, причем довольно устойчиво и с почти полным индикатором сигнала. Значит где-то рядом с этой деревней есть базовая станция, снабжающая деревню устойчивым 3G сигналом. Судя по всему, складки местности или иные преграды мешают сигналу достигать нашего участка.

Решение придумалось конечно не новое и не оригинальное — и ежу понятно, что нужно вооружаться направленной 3G антенной. Тем более, у меня уже имелся некоторый опыт эксплуатации направленных антенн для ловли 4G в Москве. В голове, где-то на пыльных задворках, лежали воспоминания о курсе антенно-фидерных устройств, который нам целый семестр читали в институте. И благодаря этим знаниям я прекрасно понимал, что собирать такую антенну самостоятельно будет довольно трудозатратно и долго, решил покупать готовую.