Первая статья для нытиков (это те, которые постоянно ноют на хабре: «Ну по-че-мууу, по-че-мууу техника Apple в России в два раза дороже чем в Европе, а-а-а?») и просто здравомыслящих людей, который предпочтут купить качественные джинсы Levi's производства Мексики, сделанные для внутреннего рынка САСШ, за 40$ с доставкой, а не платить русским барыгам 4000р. за польское говно с лэйблом Levi's.

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

Начнём?

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

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

Вступление

Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:

По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.

Я начал изучать проблему. Первичный диагноз был простой — аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.

После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют 'mdadm' по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS'ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).

Ситуация для меня была необычной — я никогда не гонялся за чистым bandwidth рейдов. IOPS'ы — наше всё. А тут — надо многомногомного в секунду и побольше.

Адские графики

Я начал с определения baseline, то есть производительности единичного диска. Делал я это, скорее, для очистки совести.

Вот график линейного чтения с одной SSD.



Увидев результат я реально взвился. Потому что это очень сильно напоминало ухищрения, на которые идут производители дешёвых USB-флешек. Они помещают быструю память в районы размещения FAT (таблицы) в FAT32 (файловой системе) и более медленную — в район хранения данных. Это позволяет чуть-чуть выиграть по производительности при работе с мелкими операциями с метаданными, при этом предполагая, что пользователи, копирующие большие файлы во-первых готовы подождать, а во вторых сами операции будут происходить крупными блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584

Содержимое: что такое CDN? История возникновения. Зачем она нужна? Кому она нужна, а кому нет? Порог вхождения, стоимость, издержки. Основные технологии.

CDN — сокращение от content delivery network, то есть “сеть доставки контента”. Чаще всего это множество серверов с специализированным ПО, которые ускоряют доставку (“отдачу”) контента конечному пользователю. Сервера расположены по всему миру таким образом, чтобы время ответа посетителям сайта было минимальным. Под “контентом” чаще всего подразумевают видео и статические элементы веб-сайтов (не требующие выполнения кода на сервере или запросов в базу данных, такие как css/js), но к “контенту” относятся и совсем неожиданные вещи — например, игры в Стиме (использует CDN для отдачи игр), обновления для операционных систем и т.д.

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

Резкий рост Интернета в середине 90-х привёл к ситуации, что сервера тех лет не могли в одиночку выдержать нагрузку (много ли может отдать могучий двухпроцессорный сервер на базе Pentium Pro на частоте в 266 МГц с 128 мегабайтами памяти?). Лимит производительности серверов и потребность во всё большей и большей производительности породила ныне забытые слова: “ферма серверов”, “иерархическое кеширование”… Айтишный новояз удивительно чувствителен к возрасту — и слова вроде “servers farm” или “information superhighway” сейчас ассоциируются с тёплыми ламповыми CRT-мониторами, а не с прогрессом. В ходе разработки и внедрения разных решений была замечена одна важная особенность: есть два типа контента — статический и динамический.

При работе над облачными сервисами Webzilla мы уделяем очень большое внимание системе мониторинга. Мы уверены, что только имея корректно работающий и надежный мониторинг, мы можем оказывать сервис на требуемом клиентами уровне качества. Во время работы над первым из облачных продуктов компании – облачным хранилищем Webzilla Instant Files – мы приступили к построению системы мониторинга еще до того, как начали строить сам продукт, продумали мониторинг для каждой функции еще на этапе её планирования.



Наша система мониторинга преследует несколько целей:

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

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

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

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

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

Когда люди запускают своей первый Docker-контейнер, они часто спрашивают: «А как мне попасть внуть контейнера?» и ответ «в лоб» на этот вопрос, конечно: «Так запустите в нём SSH-сервер и приконнектитесь!». Цель этого топика — показать, что на самом деле вам не нужен sshd внутри вашего контейнера (ну, конечно, кроме случая, когда ваш контейнер собственно и предназначен для инкапсуляции SSH-сервера).

Запустить SSH-сервер — заманчивая идея, поскольку это даёт быстрый и простой доступ «внутрь» контейнера. Все умеют пользоваться SSH-клиентами, мы делаем это каждый день, мы знакомы с доступами по паролям и по ключам, перенаправлением портов, ну и вообще доступ по SSH — хорошо знакомая вещь, точно будет работать.

Но давайте подумаем ещё.

Вот шикарная новость от пользователя ValdikSS — Новый Userland-RootKit Azazel. Позволю себе процитировать первый абзац:

Возможно вы слышали про руткиты Jynx и Jynx2. Это так называемые userland-руткиты, они используют возможность переменной LD_PRELOAD, которая позволяет подгружать любые библиотеки до того, как будет запущена программа. Они уже относительно старые, но все еще хорошо работают.
2 дня назад, Github-пользователь Chokepoint выложил rootkit Azazel. Он основан на исходном коде Jynx и имеет много новых фич:

Антиотладочные механизмы
Скрытие от unhide, lsof, ps, ldd
Скрытие файлов и директорий
Скрытие удаленных подключений
Скрытие процессов
Скрытие логинов
Скрытие от локального сниффинга трафика через PCAP
2 бекдора с полноценными шеллами (с PTY):
— Crypthook accept()-бекдор
— Обычный accept()-бекдор
PAM-бекдор для аутентификации под любым пользователем
Очистка логов utmp/wtmp для PTY
Обфускация строк скомпилированной библиотеки через xor.

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

Возможно вы слышали про руткиты Jynx и Jynx2. Это так называемые userland-руткиты, они используют возможность переменной LD_PRELOAD, которая позволяет подгружать любые библиотеки до того, как будет запущена программа. Они уже относительно старые, но все еще хорошо работают.
2 дня назад, Github-пользователь Chokepoint выложил rootkit Azazel. Он основан на исходном коде Jynx и имеет много новых фич:

• Антиотладочные механизмы
• Скрытие от unhide, lsof, ps, ldd
• Скрытие файлов и директорий
• Скрытие удаленных подключений
• Скрытие процессов
• Скрытие логинов
• Скрытие от локального сниффинга трафика через PCAP
• 2 бекдора с полноценными шеллами (с PTY):
• — Crypthook accept()-бекдор
• — Обычный accept()-бекдор
• PAM-бекдор для аутентификации под любым пользователем
• Очистка логов utmp/wtmp для PTY
• Обфускация строк скомпилированной библиотеки через xor.

Давайте рассмотрим их подробно.

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

Я работаю предпринимателем — фрилансером с 2007 года и успел накопить значительный опыт получения денег из-за рубежа как через онлайн-биржи вроде oDesk и Elance, так и работая с заказчиками напрямую. В свое время я был инициатором некоторых изменений на oDesk, помогающих упростить легальное получение денег на свой предпринимательский счет. Сегодня я руковожу разработкой в нашем украинском стартапе Taxer.ua, от чего опыта во взаимодействии с государством накопилось еще больше.

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

1. Государственная регистрация предпринимателя: выбор системы налогообложения, подача заявления.
2. Составление ВЭД договора, получение денег от клиентов: биржи oDesk, Elance и напрямую.
3. Ведение ВЭД бухгалтерии: акты, счета, книга доходов и курсовая разница.
4. Уплата налогов и отправка отчетности в контролирующие органы: сдавать ли валютную декларацию.

Abstract: Рассказ про некоторые возможности IPv6 на примере конфигурации сложной домашней IPv6-сети. Включает в себя описания мультикаста, подробности настройки и отладки router advertisement, stateless DHCP и т.д. Описано для linux-системы. Помимо самой конфигурации мы внимательно обсудим некоторые понятия IPv6 в теоретическом плане, а так же некоторые приёмы при работе с IPv6.

Зачем IPv6?

Вполне понятный вопрос: почему я ношусь с IPv6 сейчас, когда от него сейчас нет практически никакой пользы?

Сейчас с IPv6 можно возиться совершенно безопасно, без каких-либо негативных последствий. Можно мирно разбираться в граблях и особенностях, иметь его неработающим месяцами и nobody cares. Я не планирую в свои старшие годы становиться зашоренным коболистом-консерватором, который всю жизнь писал кобол и больше ничего, и все новинки для него «чушь и ерунда». А вот мой досточтимый воображаемый конкурент, когда IPv6 станет продакт-реальностью, будет либо мне не конкурентом, либо мучительно и в состоянии дистресса разбираться с DAD, RA, temporary dynamic addresses и прочими странными вещами, которым посвящено 30+ RFC. А что IPv6 станет основным протоколом ещё при моей жизни — это очевидно, так как альтернатив нет (даже если бы они были, их внедрение — это количество усилий бОльшее, чем завершение внедрения IPv6, то есть любая альтернатива всегда будет отставать). И что адреса таки заканчиваются видно, по тому, как процесс управления ими перешёл во вторую стадию — стадию вторичного рынка. Когда свободные резервы спекуляций и хомячаяния адресов закончится, начнётся этап суровой консолидации — то есть выкидывание всего неважного с адресов, перенос всех «на один адрес» и т.д. Примерно в это время IPv6 начнёт использоваться для реальной работы.

Впрочем, рассказ не про будущее IPv6, а про практику работы с ним. В Санкт-Петербурге есть такой провайдер — Tierа. И я их домашний пользователь. Это один из немногих провайдеров, или, может быть, единственный в городе, кто предоставляет IPv6 домашним пользователям. Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального (то есть в четыре миллиарда раз больше адресов, чем всего IPv4 адресов быть может — и всё это в одни руки). Я попробую не просто описать «как настроить IPv6», но разобрать базовые понятия протокола на практических примерах с теоретическими вставками.

Структура сети:

(Оригиналы картинок: github.com/amarao/dia_schemes)

• 1, 2, 3 — устройства в локальной сети, работают по WiFi
• 4 — WiFi-роутер, принужденный к работе в роле access point (bridge), то есть коммутатора между WiFi и LAN
• 5 — eth3 сетевой интерфейс, который раздаёт интернет в локальной сети
• 6 — мой домашний компьютер (основной) — desunote.ru, который раздачей интернета и занимается, то есть работает маршрутизатором
• 7 — eth2, интерфейс подключения к сети Tiera

Перед тем, как настраивать роутер (не важно — офисный аппаратный роутер за 50 долларов или программный роутер на базе сервера с двумя 4-х ядерными процессорами) — важно понимать, как пакеты двигаются по цепочкам (изучить в онлайн документации Диаграммы движения пакетов — Packet Flow Diagrams).
Невозможно должным образом управлять и поддерживать сложные конфигурации без понимания того — что, где, когда и почему происходит.

В случае бриджинга трафика (Layer 2 (MAC)) — роутинг представлен ввиде черного серого «ящика» Layer3,


…

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

В качестве shell-оболочки рассмотрим bash, как самую используемую. А в качестве операции над файлами рассмотрим удаление, как самую деструктивную.

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

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

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

Среди сетевых специалистов не утихают споры: возможно (и стоит ли) готовиться к экзамену CCNA самостоятельно или нужно идти на платные курсы? В этой статье мы бы хотели дать несколько полезных советов тем, кто выбрал путь самостоятельной подготовки к экзамену компании Cisco CCNA.

Итак, возможно или нет?

Всем привет!

В одном из моих проектов используется нечто, немного похожее на частное облако. Это несколько серверов для хранения данных и несколько — бездисковых, отвечающих за виртуализацию. На днях я похоже что наконец поставил точку в вопросе выжимания максимальной производительности дисковой подсистемы данного решения. Это было довольно интересно и даже в некоторые моменты — довольно неожиданно. Поэтому и хочу поделиться своей историей с хабрасообществом, которая началась в далёком 2008м году, ещё до появления «Первого облачного провайдера России» и акции по рассылке бесплатных счётчиков воды.

Архитектура

Экспорт виртуальных жёстких дисков осуществляется через отдельную гигабитную сеть по протоколу AoE. Если коротко — это детище компании Coraid, которая предложила реализовать передачу ATA-команд по сети, напрямую. Спецификация протокола занимает всего десяток страниц! Главная особенность — это отсутствие TCP/IP. При передаче данных получается минимальный оверхед, но как плата за простоту — невозможность роутинга.

Почему именно такой выбор? Если опустить перепечатывание официальных источников — в т.ч. и банальный lowcost.

Соответственно, в хранилищах мы использовали обычные SATA-диски с 7200 rpm. Их недостаток известен всем — низкий IOPS.

Доброго времени суток, уважаемые!

В последнее время, читая различные статьи в хабре, всё больше стал замечать, что многие авторы до сих пор ничего не знают о ISO/IEC стандартах бинарных префиксов (KiB=кибибайт, MiB=мебибайт и т.д.) и постоянно путают их с SI префиксами (kB=килобайт, MB=мегабайт). Поэтому я решил ещё раз заговорить об этом в надежде, что, прочитав статью, ещё пара человек начнёт пользоваться стандартами!

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

1. Серые списки (Greylisting)
2. DNSBL
3. Чёрные списки
4. Spamassassin
5. DKIM

Как использовать все эти средства для наиболее эффективного решения проблемы нежелательной корреспонденции?

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

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

Лирика

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

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

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