Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

Привет, Хабр! В ходе обсуждения одной статьи про «идеальную» домашнюю сеть, возник спор, что лучше, аппаратный NAS или мини-компьютер с Linux дистрибутивом. Автор предлагал использовать аппаратный NAS, т. к. якобы он проще в администрировании, не требует знаний Linux, да и вообще NAS тихий. Но при этом, для просмотра на DLNA-телевизоре видео, который он не поддерживает, предлагал включать ноутбук с транскодирующим DLNA. Меня это, мягко говоря, удивило, т. к. в идеальной сети такого быть не должно. Поэтому хочу представить своё видение одного из ключевых компонентов домашней сети — централизованного хранилища данных, и основано оно будет на мини-ПК с ОС Ubuntu Server.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Всем привет!

Сегодня поговорим о том, для каких задач на самом деле полезна MySQL Master-Master репликация, для каких — полностью бесполезна и вредна, какие мифы и заблуждения с ней связаны и какую практическую пользу можно быстро получить от данной технологии. Приведу конкретные примеры настройки и схемы архитектур.

Говорить о MySQL Master-Master репликации — в контекстах высокой доступности и производительности — модно, но, к сожалению, многие не понимают ее сути и связанных с технологией серьезных ограничений.
Начнем с того, что в классическом MySQL «настоящей» Master-Master репликации — пока нет :-) Но если постараться, можно все таки просто и быстро настроить эффективную схему выживания при отказе одного датацентра и получить свою долю счастья.

Краткое введение

В наши дни все понимают насколько простой задачей является угон незащищенной http сессии.
И останавливать от повсеместного внедрения может только цена на покупку сертификата, www.startssl.com решает эту проблему, раздавая бесплатные сертификаты (Class 1). Verified (Class 2) стоят копейки.

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

Что такое NAXSI ?

NAXSI = NGINX ANTI XSS & SQL INJECTION
Проще говоря, это файрвол веб-приложений (WAF) для NGINX, помогающий в защите от XSS, SQL-инъекций, CSRF, Local & Remote file inclusions.
Отличительными особенностями его являются быстрота работы и простота настройки. Это делает его хорошей альтернативой например mod_security и апачу.

Зачем нужен NAXSI ?

Очевидно, лучше всего защищаться от вышеперечисленных атак правильно написанным кодом. Но есть ситуации, когда WAF (и в частности naxsi), поможет:

• Низкое качество кода сайта, при отсутствии возможности/ресурсов все выкинуть и переписать нормально.
• “Закрытый” код, в котором невозможно исправить ошибки.
• Неизвестное качество кода в важном для бизнеса участке.

Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего — либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

Итак, вы изучили mod_rewrite, составили несколько RewriteRule и успели столкнуться с бесконечными перенаправлениями, со случаем, когда правило почему-то не ловит ваш запрос, а также с непредсказуемой работой группы правил, когда последующее правило неожиданно изменяет запрос, кропотливо подготовленный правилами предыдущими.

Почему так происходит?

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Тематику cisco на хабре нельзя назвать популярной, зачастую интересные статьи остаются почти незамеченными. Но нас приятно удивил ажиотаж вокруг нашей предыдущей публикации. Больше тысячи человек добавили её в избранное, и это определённо говорит о том, что продолжение необходимо.
Кроме того, много людей, имеющих опыт реального планирования и строительства сетей, делали очень правильные замечания по резервированию. Дело в том, что предложенная в прошлый раз схема сети — это макет, лаборатория, на который мы будем отрабатывать и понимать технологии, поэтому такими вещами мы не озадачивались. В реальной же жизни, особенно, если вы оператор связи/провайдер, необходимы различные схемы резервирования: VRRP, STP, Link Aggregation, протоколы динамической маршрутизации.
Все замечания мы постараемся учесть и в конце цикла, вероятно, рассмотрим то, как сеть должна строиться, чтобы через полгода после запуска инженеру не было мучительно больно.

Сегодня же мы обратимся к части немного скучной, но важной для начинающих: как подключиться, поставить или сбросить пароль, войти по telnet. Также рассмотрим существующие программы — эмуляторы ciscо и интерфейс оборудования.
Как и обещали, в этот раз всё по-взрослому: с видео.

Под катом то же в текстовой и чуть более подробной форме.
Итак, вот они приехали — заветные коробки с надписью Cisco на борту.

Интеграция CISCO AAA и Microsoft Active Directory

Наверняка многие системные администраторы рано или поздно сталкиваются с проблемой аутентификации на сетевых устройствах. Если руководствоваться best-practices, то учетные записи должны быть персонифицированными, пароли должны отвечать критериям устойчивости, время жизни паролей должно быть ограничено. Также не будем забывать о разграничении уровней доступа в соответствии с выполняемыми задачами и поддержке актуальности базы пользователей, связанной с изменениями в штате сотрудников. При соблюдении этих требований ведении базы пользователей на каждом устройстве становится трудоемкой и нетривиальной задачей, а на практике часто просто игнорируется, администраторы ограничиваются заданием паролей на физическую и виртуальную консоль и заданием пароля суперпользователя (enable). Логичным решением этой проблемы является ведение единой базы пользователей с контролем выдвигаемых к учетным записям требований. Если у нас есть Active Directory, почему бы не использовать его?


Рис.1 Топология системы

Здравствуй, Хабр!

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

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

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Введение

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

Эта статья — не набор “волшебных команд” и рецептов (cookbook, как называют такие наборы по-английски), хотя они тут тоже присутствуют, а, скорее, попытка описать, как общие принципы построения эргономичных интерфейсов можно применить в практике использования Vim, чтобы сделать из него удобную и эффективную среду работы с текстами.

Эта статья также не является tutorial’ом для начинающих пользователей Vim, хотя и им (а также пользователям Emacs) может быть интересна, поскольку некоторые упоминаемые принципы являются достаточно общими и действуют не только в системах редактирования текстов, а вообще везде, где идет речь об использовании компьютера для редактирования чего-либо. Тем не менее, я предполагаю, что читатель знаком с основными концепциями, применяемыми в Vim (режимы, регистры, буфера, команды) и не останавливаюсь на их подробном описании.

По умолчанию Vim настроен очень старомодно, и эта настройка подразумевает, что пользователь при работе с текстом будет мыслить метафорами пятидесятилетней давности, как будто бы сейчас заря эпохи UNIX. Однако дизайн Vim позволяет сделать несколько настроек, после которых система станет выглядеть вполне прилично и станет работать весьма эффективно, сочетая в себе полезные черты и древних юниксовых инструментов работы с текстом, и современных WYSIWIG-процессоров, при этом обходя, насколько это возможно, присущие им недостатки. Вот об этих настройках и приемах их использования и пойдет речь.