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

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


Конкретно в моем случае, нужно было настроить роутер так, чтобы web-сервер в локальной сети за ним был доступен по IP любого из 3-х провайдеров.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Статья написана в 2009 году, и с тех пор многое изменилось, в том числе появились некоторые альтернативные шрифты для программирования, например, Anonymous Pro.

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

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

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

Существующая маска для IP адреса выросла из классового деления адресов, на заре эпохи IP:

Класс A: 8 бит для номера сети 24 бита для номера хоста
Класс B: 16 бит на сеть и 16 бит на хост
Класс C: 24 бита на сеть 8 бит на хост

Когда стало слишком расточительным делить адреса подобным образом появилась маска, представляющая собой 32-х битное (из стольких же бит состоит и IP адрес) поле из подряд идущих единиц с начала поля, и после подряд идущих нулей. Единицы определяют те биты в IP адресе которые формируют номер сети, нули те биты в адресе которые формируют номер хоста.

IP адрес, десятичное:     10.      10.       0.       1
IP адрес, двоичное: 00001010.00001010.00000000.00000001
Маска, двоичное:    11111111.11111111.11111100.00000000
Маска, десятичное:       255.     255.     252.       0

Представление маски подобным образом, вполне, соотносится с термином битовой маски, т.е. единицы и нули определяют действия над конкретными битами в исходном числе, но плохо соотносится с форматом IP адреса – номер сети всегда определяется битами вначале, номер хоста битами в конце. Поэтому представление маски в виде 32-х битного поля является избыточным. Для однозначного определения маски можно определить только количество подряд идущих единиц с начала IP адреса от 0 до 32 – префиксное обозначение, обычно записывается через дробь после IP адреса: для примера выше 10.10.0.1/22 – 22 бита номер сети и 32-22=10 бит номер хоста. Если говорит про IPv6 адрес, то там определяется только префиксная запись маски/адреса – 2001:d8:a15e::1/48

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

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

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

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

В последнее время громадную популярность завоевали т.н. твердотельные накопители (Solid State Drives, SSD). Для простого пользователя они представляют особый интерес тем, что позволяют значительно расширить «бутылочное горлышко» производительности системы, которая упирается в быстродействие жёстких дисков. SSD потребительского класса по скорости чтения/записи превосходят жёсткие диски в несколько раз, а в некоторых задачах — даже на порядок.

Да, нынешние SSD уже готовы заменить жёсткие диски на десктопах и в ноутбуках в полной мере, но не для всех пользователей это приемлемо, и причин этому несколько. Во-первых, вызывает вопросы та самая надёжность. Тут обычно спасают бекапы, главное — вовремя их делать. Вторая причина связана с конфиденциальностью. Если на HDD использование LUKS не вызывает вопросов, то на SSD включение TRIM понижает защищённость информации. Без TRIM же есть шансы просадить производительность дисковых операций.

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

Для операционной системы Linux представлено несколько технологий кеширования данных на SSD — bcache, EnhanceIO, dm-cache и т.п. Использование их позволяет ощутить прирост быстродействия дисковых операций, при этом надёжность функционирования системы хранения данных останется на прежнем уровне.

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

В службу технической поддержки RUVDS регулярно обращаются по поводу GUI и удаленного доступа к нему на виртуальных серверах с Linux, несмотря на то что в интернете достаточно много материалов освещающих эту проблему. Поэтому, для наших пользователей мы решили собрать всё по этой теме в одну статью.

В этой небольшой статье я хотел бы рассказать о средствах мониторинга, использующихся для анализа работы DWH нашего банка. Статья будет интересна всем, кого не устраивают существующие готовые системы мониторинга и кого посещали мысли собрать таковую «под себя» из отдельных кусочков. Большое внимание в статье уделяется дашборду Grafana, который, по моему мнению, незаслуженно обделён вниманием на Хабре. По большинству компонентов системы мониторинга будет вкратце рассмотрен процесс инсталяции (под RedHat).


Тёплый ламповый дашборд

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

Предыстория

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

Доброго времени суток всем тем, кто собирается делать Backup'ы постоянно.

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

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

Однако, ownCloud, устанавливающийся в виде плагина в системе FreeNAS, да и просто из коробки, имеет ряд недостатков, от которых хотелось бы избавится даже при использовании дома:

• Во-первых, устанавливается в связке с SQLite, что подходит только если у вас небольшое кол-во файлов и пользователей, и абсолютно не подходит, если вы планируете синхронизацию с помощью клиента. У меня же хранилище уже расползлось почти на 5Tb и установленный таким образом ownCloud просто отказывался видеть часть файлов. Да и без синхронизации отдача от облака не велика. Заменим базу данных на MariaDB.
• Во-вторых, отсутствует работа по https, а мне совсем не нравится мысль о том, что кто-то может перехватить мои файлы. Включим https.
• В-третьих, начисто отсутствует защита от банального подбора пароля методом брутфорса. Защитимся от брутфорса с помощью fail2ban.
• В-четвёртых, мне лень часто просматривать логи на предмет взлома, но очень хочется оперативно узнавать о таких попытках. Настроим push-оповещения о попытках подбора пароля с помощью сервиса pushover.net.

… или что такое на самом деле 'raid edition' для жёстких дисков

Немного теории

Существуют две стратегии поведения НЖМД при обнаружении ошибки:

• standalone/desktop — пытаться прочитать до последнего. Это ощущается как «тормозящий винт», который всё-таки работает, если это единичный сбой, то «затупило, но прошло», плюс характерный перестук перекалибрующихся головок.
• raid — отваливаться тут же. Это ощущается как «внезапно была ошибка диска но потом mhdd и т.д. НИЧЕГО НЕ НАШЁЛ ЧТО МНЕ ДЕЛАТЬ».

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

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

Расшифровка названия

Возможность управления поведением диска при ошибках называется очень и очень путанно: SCT ERC. Это расшифровывается как SCT Error Recovery Control. SCT в свою очередь название общего протокола SMART Command Transport. SMART в свою очередь расшифровывается как Self-Monitoring, Analysis and Reporting Technology, таким образом, полная расшифровка SCT ERC звучит так: Self-Monitoring, Analysis and Reporting Technology Command Transport Error Recovery Control (выдохнули).

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.



Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

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

Сегодня слово «виртуализация» у всех на слуху, а технологии виртуализации становятся одним из основных компонентов ИТ-инфраструктуры организаций. Кстати, сегодня вышел наш пост, в котором мы поделились своим опытом создания провайдера виртуальной инфраструктуры на примере 1cloud.

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

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

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

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

Ниже будет приведен список инструментов мониторинга. Есть как минимум 80 способов, с помощью которых ваша машинка будет под контролем.



1. первый инструмент — top

Консольная команда top- удобный системный монитор, простой в использовании, с помощью которой выводится список работающих в системе процессов, информации о этих процессах. Данная команда в реальном времени сортирует их по нагрузке на процессор, инструмент предустановлен во многих системах UNIX.