Под стеком web-приложений мы будем подразумевать множество программных продуктов с открытым исходным кодом: операционная система, web -сервер, сервер БД и среду исполняемого кода. Наиболее известным и обыденным стеком является LAMP. Это акроним для стека web-приложений на базе бесплатных решений с открытым исходным кодом. Название составлено из первых букв входящего в его состав продуктов: Linux (операционная система), web -сервер Apache, база данных MySQL, и PHP (иногда Perl или Python). Опубликованные нами ранее материалы, посвященные вопросам безопасности, рекомендуют держать различные сетевые службы на выделенных под эти цели серверах или виртуальных машинах. Это позволит изолировать скомпрометированные и взломанные злоумышленником элементы системы, в случае если последний получит возможность эксплуатации ошибок в одном из звеньев сети обслуживания. Статья также является ответом на наиболее часто задаваемые нашими читателями вопросы, присланными нам по электронной почте. В руководстве я объясню, как построить решение на базе физических или виртуальных серверов, одинаково подходящих для раздачи статического и динамического контента, для приложений, требующих наличие БД и кэширования.

Доброго времени суток, коллеги.

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

О пользе избавления от рекламы и самое ужасное — счетчиков (по несколько штук на страницу), думаю, рассказывать не нужно… Чтобы польза была практической и эстетической, забаненные картинки надо заменять на прозрачный однопиксельный GIF. В конфиге squid-a это делается так:

Я долгое время имел на руках только ноутбук и вот недавно разжился системным блоком. Без монитора и клавиатуры, иначе говоря, headless-системой. Таким образом возникла задача:

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

Продолжаем развитие нашей маленькой уютной сети Лифт ми Ап. Мы уже обсудили вопросы маршрутизации и стабильности, и теперь, наконец, выросли для подключения к Интернету. Довольно заточения в рамках нашей корпоративной среды!
Но с развитием появляются и новые проблемы.
Сначала вирус парализовал веб-сервер, потом кто-то притаранил червя, который распространился в сети, заняв часть полосы пропускания. А ещё какой-то злодей повадился подбирать пароли на ssh к серверу.
А представляете, что начнётся, когда мы подключимся к Интернету?!
Итак, сегодня:
1) учимся настраивать различные списки контроля доступа (Access Control List)
2) пытаемся понять разницу между ограничением входящего и исходящего трафика
3) разбираемся с тем, как работает NAT, его плюсы, минусы и возможности
4) на практике организуем подключение к Интернету через NAT и увеличим безопасность сети, используя списки доступа.

Вступление

Сегодня я расскажу о том, как установить и настроить гипервизор hyper-v server от компании Microsoft, а так же о некоторых подводных камнях и способах их избежать.
Поводом для написания этот статьи стал материал данного поста. Этот пост подходит больше как шпаргалка, если вы уже работали с данным гипервизором. Новичку же придется столкнуться с кучей нюансов и перекопать немало форумов, в поисках ответов на нестандартные вопросы.

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

Под катом много текста и скриншотов

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

Apache 2 под наблюдением

Вступление

Уже написано немало постов на просторах интернета, о мониторинге веб-сервера Apache. При вводе такой фразы, как «мониторинг нагрузки apache» в строке поиска Google, результаты поиска указывают на полезнейший модуль mod_status. А также о еще большей полезности этого модуля в сочетании с perl-расширениями. А если еще и немного пропатчить эти perl-расширения — то вообще супер система получается. Но настроив такую систему — системный администратор на этом, как правило, не останавливается, ему уже необходимо история нагрузки по серверу в целом, потом по каждому хосту, а далее и с точностью до скрипта. И чтоб потом сравнить можно было, а как раньше было, а как теперь нагрузка распределяется.
И вот здесь на помощь может прийти модуль для веб-сервера Apache — mod_performance.

Итак, свершилось. Тебе на стол принесли свежекупленный контроллер wi-fi производства Cisco, и ещё десяток новых точек доступа. Что это, зачем мне, как оно работает? Как мне установить этот контроллер в сеть, и наконец-то «раздать фай-фай правильно»? Об этом и пойдет речь сегодня.

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

• Время (затраты на обслуживание системы)
• Железо (различные сбои, потеря производительности, устаревание)
• ПО (лицензионная составляющая, защита от вирусов, централизация управления приложениями)

В своей статье я рассматриваю реализацию (не)тонкого клиента на базе ОС Linux, как прослойке между аппаратной составляющей и привычным интерфейсом ОС Windows.
(Не)тонкий клиент, в моем понимании, это дистрибутив ОС Linux обладающий следующими свойствами:

• достаточно большой набор компонентов для загрузки; не подходит для загрузки по сети
• достаточно маленький набор компонентов; не рационально устанавливать жесткий диск

Я программист. По крайней мере так написано в трудовой книжке. Почти всё своё рабочее время я провожу в консоли и текстовом редакторе. Мне очень нравится bash. Почти год я жил в zsh, прислушавшись к советам своих многочисленных коллег и знакомых, но в итоге я вернулся в bash и ни капельки об этом не жалею.



Zsh красив, приятен, чертовски функционален, но, признаюсь честно, я не смог совладать со всеми его многочисленными настройками. Я хочу работать, а не бороться со своим рабочим окружением. Простой пример: пару раз из-за автодополнения zsh я удалял все директории и файлы в текущей директории — zsh просто ставил пробел между автодополненной директорией и введённой мною звёзочкой (я хотел удалить всё в выбранной папке). Помните тот эпичный баг с пробелом и удалении директории /usr? У меня было то же самое. Спасибо гиту, выручил в который раз.

Впрочем, дело не в zsh — будь я чуточку умнее, я бы с ним обязательно справился бы, и всё было бы хорошо, но мы, суровые программисты, будем использовать bash и vim, а гламурные zsh и textmate оставим хипстерам и прочим модникам ;)

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

Сеть работает, 1С открывается, пользователи довольны. Картина встречающаяся сплошь и рядом. Кажется, что жизнь администратора удалась. Именно так думает половина, если не две трети начинающих и достаточно продвинутых системных администраторов. Многие из нас даже не задумываются о том, что стоит в сетевых шкафах в офисе, в лучшем случае контролируя то, что стоит в серверной. Данный подход особо опасен для вашей работы (уволят) и для работы вашей организации (встанет). Если всё работает – пора обновлять оборудование.

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

Как же понять, что сетевое оборудование в сети требует обновления и когда к нему приступать? Как подходить к вопросу?

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

П.С. Тру фанатов оракла прошу строго не судить, мне известно что установка этой БД на неподдерживаемы ОС чревата и т.д… Но поскольку имею практический опыт в эксплуатации данной СУБД в нескольких «несертифицированных» ОС и опыт разрешения весьма небольшого числа коллизий по ходу эксплуатации — до сих пор считаю требование к «сертифицированности» ОС сильно преувеличенным.

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

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

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

Несложная задача. Только есть одно «но». Количество исходников, которые планируется использовать как эталонные — около 15 тысяч файлов, суммарным объемом чуть меньше гига (для удобства они завернуты в один TAR). Подобный «прогон» может быть весьма долгим. И есть естественное желание сделать тест максимально быстрым, используя многопроцессорную машину, ибо задача прекрасно распараллеливается.

Как вариант — можно сделать Makefile и запускать его с ключом "-j" в GNU Make. Но если написать специализированную многопоточную программу, то можно достичь лучшей производительности.

В языке Go используются обычные способы управления потоком выполнения: if, for, switch, goto. Есть ещё оператор go, чтобы запустить код в отдельной го-процедуре. А сейчас я бы хотел обсудить менее обычные способы: defer, panic и recover.

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

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

Статья основана на codelab с сайта Go, но не ограничивается им. По ходу прочтения статьи можно будет узнать о структурах данных Go, динамических массивах, использовании библиотек http, template, regexp для создания веб-приложения, шаблонизации и фильтрации ввода, соответственно.

Для понимания статьи необходимо немножко уметь программировать, не пугаться слов unix и веб. Основы языка будут изложены в статье.

Я снова вернулся к любимой задаче для освоения новых языков. После написания движка для блога на Go, захотелось снова поразмять пальцы, болезный TCP/IP proxy/debugger теперь написан на Go.

Вкратце, TCP/IP proxy — это программа, которая умеет принимать соединения и «пробрасывать» их на указанный адрес. Попутно ведутся логи переданных данных. Это очень удобно при отладке различных самодельных сетевых протоколов.

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

Конечно, все многопоточно. И так как в Go параллельное программирование настолько просто (и безопасно), количество параллельных активностей для каждого соединения даже больше, чем в версии на Эрланге.

Я люблю писать тексты, люблю отлаживать примеры, пробовать, анализировать. Чего я не люблю, так это возиться с форматированием, закачиванием картинок, проверкой верстки и т.д.

По причине лени я начал использовать Блогспот. Тут тебе и море шаблонов, виджеты всякие, мгновенная индексация Гуглом, статистика разная, с какого-то времени даже комментарии стали древовидные, и прочие свистелки. Ну все бы хорошо, но, увы, не предназначен редактор Блогспота для создания программистских постов. Когда надо вставлять код или таблицы разные, начинаются мучения. Например, для своего другого блога, не про программирование, Яйца всмятку, сэр!, «возможностей» Блогспота вполне хватает.

Еще мне хочется хранить оригиналы постов в нормальном, не в обгаженном HTML'ем виде. Получалось, что материалы по блогу раскиданы по компьютеру там и сям в нескольких копиях. Сначала ты просто пишешь текст в редакторе, только разбивая на абзацы, без ссылок и картинок, и в конце сохраняешь почти готовый документ. Потом начинается верстка в HTML, в процессе которой, помимо, собственно, HTML'я, делаются поправки в оригинальном тексте. При этом обновлять оригинальный файл уже лень, и по сути, он остается в «сыром» виде. А в «сухом» виде остается только HTML'ная помойка. Но это еще не конец истории. Часто уже после публикации замечаешь опечатку, лезешь в Блогспот и правишь прямо на странице. Опять, самый первый оригинал и его локальная об'HTML'ная версия остаются неисправленными. В итоге: актуальные версии постов находятся только на самом Блогспоте. Конечно, можно делать автоматизированный бэкап всего блога, но опять таки — все будет уже только в HTML'е.

Некоторое время назад я начал использовать ReST. Тут жизнь хоть как-то полегчала. ReST позволяет писать текст в уже более менее предсказуемой разметке (абзацы, ссылки, код), и затем из него генерируется HTML, который вставляется (опять таки вручную) в Блогспот. Попытки автоматизировать предварительный просмотр поста через googlecl фактически провалились. Опять оставалась проблема, когда после исправления опечатки на странице оригинальный документ в ReST устаревал. Кроме того, ReST не решал проблему картинок. Их надо было куда-то заранее выкладывать, чтобы можно было полностью сделать preview.

Не могу объяснить почему, но идея динамических движков типа Wordpress'а меня как-то пугала. Сама идея держать посты в базе данных мне кажется перебором.

Иногда мне приходится сталкиваться с заменой корневой файловой системы. Имея загрузочный диск и доступ к серверу, это не сложно. Однако, я хочу поделиться опытом замены корневой ФС удаленно, через ssh, без перезагрузки.

Причины для замены коневой ФС бывают разные:

• перевод / в LVM
• перевод / в mdraid
• замена типа файловой системы (ext3 => btrfs)
• уменьшение размера ФС (resize2fs)

Возможности скрипта:
— бэкапить директории и базы данных
— загрузка архивов в локальную папку или на фтп
— информирование по email о удачном/не удачном завершении