Существуют различные бесплатные системы мониторинга состояния систем и сети такие как: Munin, Zabbix и т.д. Я же хочу поделиться с IT сообществом примером настройки системы мониторинга Nagios на операционную систему Arch Linux.

Приведенный ниже пример установки Nagios производился на дистрибутив Arch linux x64, но так же данный материал можно использовать для Arch i686.

Тех, кто использует или собирается использовать Zabbix в промышленных масштабах, всегда волновал вопрос: сколько реально данных сможет Заббикс «переварить» перед тем как окончательно поперхнется и подавится? Часть моей недавней работы как раз касалось этого вопроса. Дело в том, что у меня есть огромная сеть, насчитывающая более 32000 узлов, и которая потенциально может полностью мониториться Заббиксом в будущем. На форуме давно идут обсуждения о том, как оптимизировать Zabbix для работы в больших масштабах, но, к сожалению, мне так и не удалось найти законченное решение.

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

Обычно VRF (Virtual Routing and Forwarding, VPN Routing and Forwarding) используется совместно с MPLS, но без оной в терминологии Cisco называется VRF-Lite. Суть этой технологии в том, что маршрутная информация, принадлежащая различным классам (например, маршруты одного клиента) изолируется друг от друга. Считается, что такие возможности есть только у «взрослых» железных решений, но это не совсем так. Благодаря наличию множественных таблиц маршрутизации, гибких политик маршрутизации всё это можно сделать и в Linux. Кому интересно, добро пожаловать под кат.

Когда работал системным администратором, возникла у меня необходимость реализовать VPN на несколько десятков филиалов компании, интранет и почту на серверах в Москве с суровой защитой и доступом через VPN вообще отовсюду. При этом придумать всю систему и организовать её развёртывание предстояло в одно лицо. Бюджет был в тысячи полторы долларов, было это 4 года назад, некоторое время честно пытался найти более-менее приемлемое по цене ПО, потом нечестно пытался найти что-то на торрентах – пусто. В итоге – OpenSSL и OpenVPN. В этом вводном тексте хотелось бы поговорить об OpenSSL.

В конечном итоге были развёрнуты:

• центр выдачи сертификатов (CA – Certificate Authority, он-же УЦ – Удостоверяющий Центр, в отечественной терминологии организация, уполномоченная выпускать сертификаты),
• интранет-сайт с авторизацией доступа по клиентским сертификатам,
• VPN с взаимной аутентификацией серверов, клиентов и динамической маршрутизацией,
• Авторизация клиентов на корпоративном IM сервере с помощью тех-же сертификатов.

802.1x — это стандарт, который используется для аутентификации и авторизации пользователей и рабочих станций в сети передачи данных. Благодаря стандарту 802.1x можно предоставить пользователям права доступа к корпоративной сети и ее сервисам в зависимости от группы или занимаемой должности, которой принадлежит тот или иной пользователь. Так, подключившись к беспроводной сети или к сетевой розетке в любом месте корпоративной сети, пользователь будет автоматически помещен в тот VLAN, который предопределен политиками группы, к которой привязана учетная запись пользователя или его рабочей станции в AD. К данному VLAN будет привязан соответствующий список доступа ACL (статический, либо динамический, в зависимости от прав пользователя) для контроля доступа к корпоративным сервисам. Кроме списков доступа, к VLAN можно привязать политики QoS для контроля полосы пропускания.

Этой статьей я планирую открыть серию мануалов по Juniper серии SRX. Если это кому-то будет полезно – буду очень рад. И не стесняйтесь задавать вопросы.

Отмечу, что все ниженаписанное, скорее всего, будет подходить и к любой другой модели маршрутизаторов от Juniper (вследствие их слогана «One Junos», то есть одна операционка на все железяки). Данная статья основана на официальном англоязычном мануале по настройке NAT, взятом отсюда: www.juniper.net/us/en/local/pdf/app-notes/3500151-en.pdf.

Итак, проброс портов. Или по-научному, destination NAT. Тут надо сделать одно небольшое замечание. Некоторые админы привыкли под словом NAT понимать source NAT, со всеми вытекающими. И даже не source NAT, а одну из его разновидностей — PAT. Но надо понимать отличия между разными видами ната. Здесь я не буду вдаваться в теорию, на википедии все достаточно понятно написано. Я хочу сделать лишь одно пояснение: NAT – это всего лишь подмена адресов, ничего больше. Если вы понимаете суть этой технологии по-другому, вы неправы. Ничего больше, чем замена одного адреса в заголовке IP-пакета другим, эта технология не делает. И ничего изначально страшного и ужасного в ней нет. Соответственно, если мы говорим о destination NAT, то речь идет о подмене адреса назначения. Рассмотрим пример:

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

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

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

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



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

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

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

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

Введение

Многие при подготовке к сдаче экзаменов Cisco или просто изучения сетей для практических занятий предпочитают собрать и использовать лабораторию из реального железа. В таком случае одним из выходов является покупка подержанного цисковского железа на Ebay, но это вам обойдется не в одну сотню долларов.
Другие довольствуются использованием симулятора сети — Cisco Packet Tracer. Для подготовки к CCNA я использовал именно его. Он прост в использовании, удобен, не требует сильного железа и идеально подходит для начинающих. Но из-за ограниченности в функциях для более серьезного изучения он непригоден.
Если же вы не хотите тратить свои кровные $$ и получить устройства с реальными IOS-ами, то нужно смотреть в сторону использования эмулятора сети GNS3 на базе Dynamips. Введение в его использование уже есть на Хабре.

Я же расскажу как его можно соединить с хостовой ОС Linux (на котором он запущен) и серверами в VirtualBox-е. Это значительно расширяет наши возможности по созданию сложных топологий с использованием роутеров Cisco, серверов с различными сервисами в VirtualBox и выходом в Интернет через хостовую ОС Linux.

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

Нет? Тогда пришло время вступить в ряды бойцов Cisco

Свою первую статью я решил написать о том, о чем невольно задумывается каждый начинающий инженер Cisco: о Зарплате. Шучу, конечно о самообучении и Сертификации.

Рано или поздно все мы сталкиваемся с тем, что нам нужно обновить IOS. Если Вы никогда этого не делали, но сделать надо, то этот пост для вас!

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

Сравнение с точки зрения разработчика

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

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)