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

Здесь не будет сравнения с LVM, ибо сравнивать muscle-car с jet-truck'ом хоть и можно, но бессмысленно.
Графиков и комиксов так же не завезли.
Это, скажем так, незавершенная история успеха, потому что апгрейд, которым она была вызвана, можно лишь прекратить, но не завершить.

«Для чего в команде ping используются опции Loose, Strict, Record, Timestamp и Verbose?» — такой вопрос мне недавно встретился в вендорном экзамене. Они позволяют влиять на маршрутизацию ICMP пакетов и собирать информацию о транзитных L3-устройствах. Но занимаясь сетевыми технологиями уже достаточно давно, я почти никогда их не использовал.

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

Эта статья описывает конфигурацию шлюза под управлением Linux для балансировки трафика между каналами разных провайдеров.


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

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

Как устроена загрузка современных ОС? Как при установке системы настроить загрузку посредством UEFI, не утонув в руководствах и ничего не сломав?

Я обещал "самое краткое руководство". Вот оно:

1. Создаём на диске таблицу разделов GPT
2. Создаём FAT32-раздел на пару сотен мегабайт
3. Скачиваем из интернета любой UEFI-загрузчик
   (нам нужен сам загрузчик, это один бинарный файл!)
4. Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi
5. Создаём текстовый конфиг, кладем его там, где загрузчик ожидает его увидеть
   (настройка и местоположение конфига зависят от конкретной реализации загрузчика, эта информация доступна в интернете)
6. После перезагрузки видим меню загрузчика
   (Если на диске установлена Windows 8 или 10 — с большой вероятностью это руководство сокращается до пунктов 3 — 5.)

TL;DR не надо прописывать путь к загрузчику в новых загрузочных записях UEFI — надо файл загрузчика расположить по стандартному "пути по-умолчанию", где UEFI его найдет, и вместо загрузочного меню UEFI пользоваться меню загрузчика, которое гораздо проще и безопаснее настраивается

Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.

Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.

Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!

Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.

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

Недавно мне понадобилось организовать почтовый сервис для небольшой фирмы. И я вспомнил про завалявшийся у меня бесплатный аккаунт в Google Apps. К сожалению, основной домен, к которому аккаунт был привязан давно почил в бозе и оказался занят на текущий момент. Благо, к аккаунту были привязаны несколько дополнительных бесплатных доменов, один из которых оказался свободным и я его снова зарегистрировал. И тут передо мной возник вопрос, который вынесен в заголовок. Знакомая ситуация? Если обратиться к справке уважаемого Google, то узнаем, что это сделать невозможно.

Как частый посетитель тэга PHP на StackOverflow, я очень часто встречаю вопросы о том, как распарсить какие-то конкретные аспекты HTML, используя регулярные выражения. Самый распространённый ответ на это:

«Ты не можешь парсить HTML с помощью регулярных выражений, потому что HTML не является регулярным. Используй XML парсер, и будет тебе счастье»

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

Продолжаем начатое. В этот раз я расскажу о том, что содержится в полезной нагрузке кадра I/K-bus, кратенько об устройстве информационно-развлекательной системы BMW e38, e39, e46, e53, и рассмотрим подробнее работу протокола на примере чейнджера компакт-дисков.

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

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

В прошлый раз мы рассказали об Intel Management Engine (ME) — подсистеме, которая встроена во все современные компьютерные платформы (десктопы, лэптопы, серверы, планшеты) с чипсетами компании Intel. Эта технология многими воспринимается как аппаратная «закладка», и на то есть причины. Достаточно сказать, что Intel ME является единственной средой исполнения, которая:

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

Ошарашенный присутствием такого компонента в компьютере, пользователь (получается, что именно «пользователь», а не «владелец») наверняка задавался вопросом: можно ли выключить Intel ME?

Эта статья целиком посвящена этому вопросу.

VPN (англ. Virtual Private Network — виртуальная частная сеть) — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет).
© Wikipedia

VPN используется для удаленного подключения к рабочему месту, для защиты данных, для обхода фильтров и блокировок, для выдачи себя за гражданина другой страны и вообще — штука незаменимая. Практически повсеместно в качестве простого средства для организации пользовательского VPN используется всем известный OpenVPN, который использовал и я. Ровно до тех пор, пока у меня не появился Macbook и OS X в придачу. Из-за того, что подход Apple к конфигурации DNS сильно отличается от подхода других *nix-систем, проброс DNS через VPN нормально не работал.

После некоторых исследований у меня получилось два варианта:
— Использование DNS «мимо» VPN, что сильно небезопасно, но решает проблему.
— Использование нативных для OS X VPN-протоколов: PPTP и семейства IPSec.
Разумеется, я выбрал второе и разумеется — IPSec, а не устаревший PPTP.

Сейчас я расскажу вам о том, как можно сэкономить немалое количество времени и денег на вашей IT-инфраструктуре.
Как централизованно админить большое количество linux рабочих станций не разводя при этом хаос в вашей экосистеме.
И так, что же такое LTSP?

LTSP — Это терминальное решение на Linux.
Говоря "терминальное", я в первую очередь имею в виду не подключение к удаленному рабочему столу как в Windows. Я подразумеваю гораздо более гибкую и продвинутую систему доставки ПО, конфигов, домашенего каталога, да и самой операционной системы на клиентские рабочие станции с вашего терминального сервера.

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

У LTSP есть несколько режимов работы:

• тонкий клиент
• толстый клиент

Меня зовут %username%, мне n лет и я параноик. И каждый день информационный мир усложняет мне жизнь. Технологий становится больше, порог вхождения в IT снижается, и мы получаем действительность, где грубые ошибки в безопасности это нормально. А еще и мощность вычислительной техники растет с каждым годом. В итоге наши пароли, хранимые как получится, становятся достоянием общественности.

Безопасность не мертва, но инкапсулирована и агонизирует. И с каждым годом стук по крышке черного ящика все тише, а сдавленные вопли и вовсе больше не слышны. Уж больно много абстракций поверх.

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

Поэтому мы придумали свой хакерский подход к хранению и вводу паролей.



Кратко: телефон связан через Bluetooth со специальным девайсом, который эмулирует клавиатуру. Утеря девайса и телефона не позволяют получить паролей. Утеря девайса и мастер-пароля тоже не страшны. Как так? Добро пожаловать под кат (там 7 картинок, но они красивенькие).

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

Ключевые слова: policy routing, source based routing

Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

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

Решение

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Сегодня обнаружил на просторах интернета Windows 8.1 RTM (финальная версия), и решил обновится, но не тут-то было.

У меня была установлена Windows 8.1 x64 Enterprise Preview, а как заявлял microsoft: с preview нельзя обновится до RTM,
соответственно терять все установленные программы и пр. мне не захотелось, пошёл в гугл, нашёл что можно менять версию в файле cversion.ini, но спустя 5 попыток замены — ничего не получилось.
Оказалось что версия RTM с языком en-US, а у меня ru-RU, а это уже причина удалять всё, по мнению microsoft.

Поразмыслив 10 минут, нашёл еще один, более интересный способ установки windows 8.1, о котором и пишу здесь.

Цель: получить минимально работающий почтовый сервер, используя только Postfix и Dovecot, с минимальным изменением настроек по умолчанию. Получить каркас системы, на основе которого можно, в дальнейшем, настраивать спам фильтры, работу с базами данных, LDAP…
Почтовая система должна:

1. Поддерживать любое количество доменов и пользователей.
2. Обслуживать пользователей, не привязанных к локальным учетным записям.
3. Обеспечивать доступ к почтовым ящикам по протоколам POP3, IMAP с поддержкой TLS.
4. Обеспечивать отправку и прием писем по протоколу SMTP с поддержкой TLS.

Настройка проводилась в CentOS 6. Postfix 2.6.6, Dovecot 2.0.9. Никакие особенности ОС не применялись.