понедельник, 5 сентября 2016 г.

Install Scapy on Mac OS El Capitan

Is following:
brew tap Homebrew/python
brew install scapy

воскресенье, 28 августа 2016 г.

Как приручить трафик или traffic engineering в деталях

Как приручить трафик?

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

Как известно, Internet traffic engineering включает в себя множество задач управления трафиком главной целью которых является обеспечение надежной и эффективной работы каналов сети Интернет.

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

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

Существует по меньшей мере три типа автономных систем интернета - генераторы трафика (отношение исходящего трафика к входящему превышает 2), потребители трафика (отношение входящего трафика ко входящему превышает 2) и магистральные провайдеры ( отношение входящего ко входящему равно).

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

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

При использовании full bgp view, со стороны всех провайдеров мы получаем маршруты до всего интернета и мы должны выбрать лучший. Выбор лучшего осуществляется на основании ASPATH - числа автономных систем между нами и получателем трафика. Этот метод довольно эффективен и требует минимальный уровень контроля со стороны администратора.

Если же по тем или иным причинам у нас трафик распределился по провайдерам неравномерно, то мы должны прибегнуть к local preference , выбрать наиболее нагруженные направления, куда отправляется трафик и сделать путь до перегруженного провайдера хуже. Данный подход довольно эффективен. Как его альтернатива, может быть использовать policy based роутинг, чтобы в зависимости адреса от сети клиента в нашей сети направить его в тот или иной канал.

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

В случае потребителей трафика ситуация становится намного сложнее, так как арсенал средств балансировки входящего трафика все также основывается на методах выбора лучшего пути в bgp. А именно длине выше упомянутого ASPATH, а также на основании предпочтения к префиксам наименьшей длины. Поэтому все, что мы здесь можем - это использовать ASPATH prepend, чтобы сделать путь заведомо хуже через определенного провайдера. Либо же мы можем раздробить сети на более мелкие (тем самым увеличив full view, что тоже очень плохо) и увеличить поток трафика на выделенную сеть через определенного провайдера. Кроме этого, может быть использован параметр MED, чтобы выдать больший приоритет тому или иному каналу, но в этом случае нужно убедиться, принимает ли вышестоящий оператор этот параметр от вас, так как многие его обнуляют и не пропускают дальше.

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

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

Безусловно, как генераторам, так и потребителям трафика (и даже магистральным операторам) стоит использовать системы управления трафиком , потому что они решительно улучшают качество интернет соединения, снижают необходимость постоянного контроля за bgp роутингом почти до нуля и что самое важное - позволяют решительно снизить затраты на каналы интернет путем их максимально эффективного и полного использования.

Дата написания: 26 ноября 2015 г., 12:06

О роли баз данных в надежности Интернета

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

Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние  5 лет наблюдается процесс экстенсивного укрупнения Интернет компаний.

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

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

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

К примерам таких сетей можно отнести - Facebook, Google, Youtube, Twitter (список совершенно не претендует на полноту). Это довольно разные по своей сути компании - социальные сети, хранилища контента, поисковые системы. Но их объединяет глобальный характер и популярность планетарного масштаба. Я специально не указал здесь сети, которые распространены в масштабах определенных стран, чтобы подчеркнуть именно глобальный масштаб оценки.

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

И тут мы подходим к самому Интересному, базам данных. Любой кто работал с базами данных MySQL, PostgreSQL, MSSQL и Oracle сталкивался с запросами, а как же обеспечить полное резервирование этих баз данных на случае сбоя. Кроме этого, почти всегда накладывается требование - сделать это на уровне базы данных, без внесения изменений на уровне бизнес-логики приложения. К сожалению, обобщенный ответ на этот вопрос почти всегда - "никак". Каждый из вариантов резервирования - master/master, master/single slave, master/multiple slaves является компромиссом и требует очень высокого уровня как квалификации архитектора подобного решения, так и предъявляет высокие требования к квалификации персонала и резко увеличивает необходимый для поддержки решения штат.

Безусловно, решения задачи резервирования баз данных существуют и для реляционных баз данных (SQL), так и для нереляционных, так называемых key-value или document-oriented баз данных, но каждый из них требует серьезных инвестиций и серьезных изменений в архитектуре приложения.

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

И здесь мы подходим к самому интересному моменту, что даже  крупные компании из перечисленных выше эту задачу не решают в полной мере. На 2014й год вся запись информации (например, публикация нового сообщения) на сайте Facebook безусловно уходила в США. В то время как графика и статический контент могли загружаться из Дата Центра в Швеции (Лулль). Казалось бы, ничего страшного, но в масштабе сети это очень неприятное явление. Так как нарушение связанности с сетями США в виду каких-либо проблем приведет к полной потере работоспособности сервиса и последующей потери его ценности для конечного пользователя.

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

Их нужно знать в лицо - наиболее устойчивые к сбоям протоколы.

Есть ли примеры реализации полностью устойчивых к нарушениям связанности протоколов и сервисов? Безусловно! Это наш любимый сервис - root DNS, который тоже в своем роде является очень большой географически распределенной сетью насчитывающей около тысячи узлов. Но в случае протокола DNS у нас нет необходимости менять значения для корневых зон, чаще всего меняются данные в листьях (записи в конкретной доменной зоне и записи для конкретного домена). И протокол DNS отлично справляется с обеспечением надежного хранения изменений. Несмотря на это, единая точка отказа все равно присутствует, как раз на ней хранятся данные о всех корневых серверах. Но, к счастью, в связи с довольно медленным процессом изменения данных в DNS (сравните с базой транзакций банка!) такой сбой пройдет скорее всего незамеченным даже если продлится несколько десятков часов.

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

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

Что в будущем?

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

Также технологической проблемой на пути к построению реально надежных сервисом является отсутствие встроенной поддержки обеспечения высокой доступности как в протоколе HTTP, так и в протоколе HTTP2.

Выводы

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

Дата написания: 10 декабря 2015 г., 22:09.

четверг, 25 августа 2016 г.

вторник, 23 августа 2016 г.

Крайне неприятная фича Google Groups

Вот столкнулся с такой фишкой Google Groups, что все, кто подписывается на твою группу на самом деле не получают из нее писем, если не сделают это явно в настройках!

Несколько ласковых слов в эту сторону: https://productforums.google.com/forum/#!topic/apps/3OUlPmzKCi8

суббота, 9 июля 2016 г.

Как заставить Nginx использовать и SPDY и HTTP/2 одновременно?

Вот этим чудесным патчем от CloudFlare: https://blog.cloudflare.com/open-sourcing-our-nginx-http-2-spdy-code/

В чем суть? Суть в том, что в актуальном Nginx есть только HTTP/2, а у кучи пользователей старые браузеры и  имеется поддержка только SPDY. Патч от CF добавляет возможность выбора либо HTTP/2 либо SPDY и за счет этого серьезно увеличивает число пользователей, которые могут использовать все преимущества HTTP/2.

воскресенье, 26 июня 2016 г.

Оптимизация работы блога силами CloudFlare :)

Всем привет!

Провел большую работу по оптимизации работы блога путем подключения облачной защиты от DDoS, CDN и DNS от CloudFlare.

Что было сделано:

  • Перенос DNS на CloudFlare, он базируется на Anycast и работает очень быстро из любой точки планеты
  • Подключен протокол SSL и TLS для защиты трафика от прослушивания и подмены
  • Активирована поддержка HTTP/2 и SPDY.
  • Добавлена поддержка IPv6, теперь блог полностью доступен по данному протоколу!
  • Добавлены DNS серверы поддерживающие IPv6, теперь блог будет работать даже с IPv6-only машин.
  • Добавлены CloudFlare Page Rules для перенаправления с http на https версию, так как сам движок Google Blogger такое не умеет.

В FireFox могут наблюдаться небольшие уведомления по поводу небезопасности отдачи контента, но надеюсь, Google скоро это исправит. Также возникла проблема с Navbar (полоска в самом верху, где был поиск), ее также отрепортил в Google.

Не удалось добиться работы DNSSEC, так как регистратор моего домена REG.RU не поддерживает этот протокол несмотря на свои обещания еще из 2012го года его добавить.

Подумываю о переносе домена, к регистратору с данной функцией, чтобы обеспечить полную безопасность сайту :)

Работать сайт стал ощутимо быстрее, рекомендую всем :)

понедельник, 20 июня 2016 г.

Руководство по уходу за дисковой подсистемой выделенного сервера

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

Профилактических мероприятий тут два: RAID массивы (с резервированием - raid - 1, 5, 6 10, raid-0 и его производные защиты от потери данные не дает) и самостоятельное слежение за здоровьем дисков посредством различных средств.

Защита данных посредством RAID

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

Но опять же, за массивом требуется следить. Так как он совершенно спокойно может перейти в состояние DEGRADED (то есть, один из его дисков отказал и массив работает в аварийном режиме), в котором сбой единственного оставшегося диска с данными чреват потерей всей информации. То есть, за массивом также нужно следить, а не просто "поставил и забыл".

Контроль состояния soft raid

Состояние soft-raid можно посмотреть командой:
cat /proc/mdstat
если все хорошо, то выдано там будет примерно следующее:
cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md2 : active raid1 sda3[0] sdb3[1]
20972736 blocks [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
2104448 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
4200896 blocks [2/2] [UU]

Если же один из дисков откажет, то вместо [UU] будет [U_] либо [_U], это означает, что нужно написать в поддержку и указать на отказ одного из дисков и проблемы с RAID массивом. Вам должны будут заменить диск и, возможно, еще собрать массив.

Как же это автоматизировать? Не каждый же день дергать эту команду! Вообще, лучше каждый день. Потеря 1 секунды в сутки намного менее фатальна, чем отказ диска с информацией за годы. Конечно, есть способы автоматизации в виде mdadm monitor, но они упираются в электронную почту, которая никогда ни гарантией получения уведомления не отличалась. Так что если у Вас есть соответствующие знания, то пожалуйста, иначе - лучше руками.

Дает ли RAID гарантию от потери данных по механическим причинам?

Если же за RAID массивом следят и он всегда в состоянии ACTIVE, то я могу быть совершенно спокоен за данные? Да вот совершенно нет, кстати. Почему же? Во-первых, отказать могут сразу два диска (случай почти нереальный, но тем не менее согласно теории надежности имеющий место быть), может отказать электроника на одном из дисков, которая перестанет диагностировать ошибки чтения / записи (ввода-вывода) и на рабочий диск будет сдублирован мусор в итоге в лучшем случае немного повредится файловая система (обычно, лечится fsck), а в худшем будут потеряны данные. В своей практике я сталкивался с таким случаем и что-либо сделать в этом случае было нельзя.

Как защититься от форс-мажорных проблем c RAID

Для защиты от такого рода ошибок существует механизм само-тестирования массива. Когда система (по крону) раз в неделю запускает посекторное сравнение дисков массива и если находит отличия, сразу сообщает о них. Более подробно, об этом можно прочесть здесь: http://phpsuxx.blogspot.com/2010/04/warning-mismatchcnt-is-not-0-on-devmd2.html


Теперь немного о самих жестких дисках.

Мониторинг физического состояния жестких дисков
Проблемы с жестким диском можно определить двумя способами - напрямую (через систему самодиагностику жесткого диска именуемую SMART) и косвенно (ага, по потере данных, отказу сервера или же по ошибкам в dmesg).

S.M.A.R.T мониторинг жестких дисков

С мониторингом SMART посложнее, для его контроля используется пакет smartmontools (в CentOS его ставить: yum install -y smartmontools, в Debian: apt-get install -y smartmontools), в составе которого идет утилита smartctl, которая позволяет получить информацию от SMART подсистемы жестких дисков следующим образом:
smartctl --all /dev/sdX
Где sdX имя интересующего Вас жесткого диска (список имеющихся жестких дисков при использовании soft-raid можно посмотреть в команде cat /proc/mdstat). Тут в первую очередь стоит обращать внимание на параметр reallocated sectors, если он больше 20-30, то значит диск, скорее всего, скоро выйдет из строя и таже нужно написать в поддержку с просьбой его заменить.

Также в самом низу выдачи есть блоки "SMART Error Log Version: 1" - там могут быть большие записи (с кучей 16-ричных адресов), повествующие об отказе какой-либо из частей диска; если же диск в норме - там все должно быть пусто - "No Errors Logged". Кроме него, есть еще блок "SMART Self-test log structure revision number 1", в который пишутся результаты диагностических само-тестов диска. В нормальных условиях он выглядит так:
# 1  Short offline       Completed without error       00%     26274         -# 2  Short offline       Completed without error       00%     26248         -# 3  Short offline       Completed without error       00%     26226         -# 4  Short offline       Completed without error       00%     26200         -# 5  Short offline       Completed without error       00%     26178         -# 6  Short offline       Completed without error       00%     26151         -# 7  Short offline       Completed without error       00%     26127         -# 8  Extended offline    Completed without error       00%     26062         -

Но эти самые тесты нужно запускать либо вручную либо силами того же smartmontools'а (путем правки  /etc/smartd.conf).

Вручную запуск ускоренного теста осуществляется вот так:
smartctl -t short /dev/sdX
Запуск расширенного теста:
smartctl -t long /dev/sdX
Через некоторое время после запуска (несколько минут для короткого и до получаса-часа для длинного) поле "SMART Self-test log structure revision number 1" будет заполнено и будет добавлена информация о завершении теста.

Если какой-либо из тестов FAILED, то это повод идти к оператору Дата Центра и запрашивать замену сбойного диска.

Косвенный мониторинг состояния жесткого диска

Самый очевидный вариант - когда жесткий диск был выброшен из RAID массива по причине FAULTY (то есть возникла ошика ввода вывода и диск был отключен). Также косвенным показателем отказа дисков являются разнообразные ошибки (например I/O error) в выдаче команды dmesg.

Это также говорит о подтвержденном сбое с заданным жестким диском и должна быть осуществлена его замена.

Если с RAID и SMART все в порядке, могу ли я быть спокоен за данные?

И снова нет. Для полной защиты необходим последний штрих - бэкапы на внешнем носителе.

Бэкапы

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

Руководство новобранца по OpenVZ

Если Вам в руки неожиданно попадается OpenVZ ранее установленный кем-либо то этот гайд как раз для вас! Подразумевается, что OpenVZ у Вас стоит на базе CentOS 6. Про чудо-юду на базе CentOS 7 я писать отказываюсь наотрез :)

Итак, начнем. Что такое OpenVZ - это технология позволяющая запустить несколько копий операционной системы Linux в пределах одного физического сервера.

Итак, получить список всех имеющихся на сервере виртуальных окружений (также будет использоваться термин "контейнеры") можно командой: vzlist

Выдача которой имеет примерно такой вид:
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
      1001        182 running   xx.xx.xx.xx  domain.ru
      1002          - stopped   xx.xx.xx.xx  second.domain.ru
Для идентификации контейнеров используется так называемый идентификатор контейнера - CTID. Его требуется использовать, если нужно что-либо сделать с контейнером.

Что с ним можно сделать?

Выключить (но если настроена его автозагрузка после нее он запуститься вновь):
vzctl stop 1001
Запустить:
vzctl start 1001
Отключить загрузку при запуске сервера (параметр --save необходим):
vzctl set 1001 --onboot no --save
Как искушенный системный администратор, явно вы будете использовать программы ps, lsof, top, netstat, ss и прочие на физическом сервере, где работает OpenVZ. Спешу Вас расстроить - эти утилиты не изолированы и будут показывать все процессы и все соединения принадлежащие всем виртуальным контейнерам на заданном сервере поэтому толку от этих программ не будет вовсе.

Итак, мы поняли как производить базовые операции с контейнерами.

Пройдемся по конфигам, стандартно конфигурации контейнеров хранятся по адресу /etc/vz/conf/CTID.conf, где CTID - идентификатор заданного контейнера. Конфиги довольно легки к пониманию и поддаются правке. После правки обычно требуется перезапуск: vzctl restart CTID.

Итак, но где же данные? Внимание! Сейчас они появятся. У OpenVZ используется две схемы размещения данных виртуального контейнера - ploop и simfs. Если у Вас ploop - это все усложняет и выходит за рамки статьи. В ploop данные хранятся в отдельном диске-образе и чтобы до них добраться нужно немного магии (магия простая - vzctl mount).

В случае же simfs данные доступны по адресу: /vz/private/CTID. Причем, вне зависимости от того, запущен контейнер или нет, все содержимое его жестких дисков находится там.

Теперь о том, как войти на контейнер OpenVZ. Тут два пути: обычный, силами ssh запущенного в виртуальном окружении и необычный - силами специальной команды.

Итак, необычный способ входа в OpenVZ контейнере следующий:
vzctl enter CTID
После этого Вам будет предоставлен доступ с root полномочиями в заднное виртуальное окружение так, как будто вы сидите напротив сервера и сидите с локальной консоли, разве что у Вас не будет запрошен никакой пароль. Выйти из этой консоли можно командой exit либо сочетание CTRL+D.

Теперь пару слов о багхантинге. Если Вы нашли эту статью, то явно с Вашим OpenVZ что-то не так!

Основные пути проверки проблем - это dmesg, в случае чего-то фатального о проблемах сообщит ядро. Второй частый историк проблем - исчерпание ресурсов внутри контейнера. Это можно зафиксировать стандартными утилитами free/top, но даже если они говорят, что все в порядке, Вам на помощь приходит файлик:  /proc/bc/CTID/resources, в котором можно найти вот такое содержимое:
            kmemsize                414620051            591908864  9223372036854775807  9223372036854775807                    0
            lockedpages                  4033                 7339              8388608              8388608                    0
            privvmpages               1809462              3191128  9223372036854775807  9223372036854775807                    0
            shmpages                    13839                15135  9223372036854775807  9223372036854775807                    0
            numproc                       179                  453  9223372036854775807  9223372036854775807                    0
            physpages                 6182653              6479824                    0              8388608                    0
            vmguarpages                     0                    0              8650752  9223372036854775807                    0
            oomguarpages              1344550              1532976              8388608  9223372036854775807                    0
            numtcpsock                    852                13014  9223372036854775807  9223372036854775807                    0
            numflock                        7                   43  9223372036854775807  9223372036854775807                    0
            numpty                          2                   31  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                  639  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                35976592            382477672  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                29720624            287987552  9223372036854775807  9223372036854775807                    0
            othersockbuf               210392              6495528  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0               661240  9223372036854775807  9223372036854775807                    0
            numothersock                  144                  957  9223372036854775807  9223372036854775807                    0
            dcachesize              309714841            310094288  9223372036854775807  9223372036854775807                    0
            numfile                      5474                11610  9223372036854775807  9223372036854775807                    0
            numiptent                      30                   30  9223372036854775807  9223372036854775807                    0
            swappages                    2372                 2967                    0               262144                    0
Обращайте внимание на последний столбец, если в нем не нули, значит контейнер упирается в заданный ресурс. И нужно разобраться - почему и решить проблему либо же увеличить лимит заданного ресурса путем правки конфигурации контейнера.

Ну вот, пожалуй, и все, что нужно знать про OpenVZ :)

воскресенье, 19 июня 2016 г.

Отключить IPv6 в Mac OS El Capitan

Из стандартного интерфейса не получится.

Используем магию:

networksetup -setv6off Wi-Fi
networksetup -setv6off Ethernet

Чтобы включить заново:
-setv6automatic
Причем, в интерфейсе будет корректно отображено "выкл" напротив IPv6.

Источник: https://louisville.edu/it/departments/communications/wireless/wireless-connection-problems-how-to-disable-ipv6 


суббота, 18 июня 2016 г.

Отсортировать размеры файлов в человеко-понятной форме

Очень часто встречаются данные вот в таком формате:
2,6G3,8G789M3,1G3,3G699M43M103M1,9G3,9G115M2,9G326M25M
И не менее часто нужно иметь возможность их отсортировать.

Как же это сделать?

На самом деле просто - использовать sort с ключем -h и на выходе получаем сортированные данные:
cat example.dat | sort -h

Выдача:
cat /tmp/example.dat |sort -h 25M43M103M115M326M699M789M1,9G2,6G2,9G3,1G3,3G3,8G3,9G
Но стоит отметить, что требуется довольно новый sort, в старых версиях этой фишки не было.  Например, в Убунту 16/04 такой вариант точно работать будет!

пятница, 17 июня 2016 г.

Конфигурирование сетевых интерфейсов в Ubuntu 16.04 удобно как никогда!

Удобное создание конфигов в отдельных файлах:
vim /etc/network/interfaces.d/eno1
Вот пример статической конфигурации:
auto eno1
iface eno1 inet static
address xxx
netmask 24
gateway yyyy
dns-nameservers  zz.zz.zz.zz aa.bb.bb.cc
Как же давно я этого ждал :)

Передернуть конфиг можно так:
sudo systemctl restart networking  

четверг, 16 июня 2016 г.

Продаются книги по ИТ не не только - только Питер

Всем привет!

Продаются следующие книжки, только Питер, географически - север синей ветки, метро пионерская:

  1. 100 Легендарных самолетов 250
  2. Cockpit confidential Patrick Smith 350
  3. Left behind Лахей и Дженкинс Жатва человеков: 150
  4. Sudents International гид по зарубежному образованию 200
  5. О Мексика - Люси Невилл: 250
  6. Веб аналитика Яковлев Довжиков: 150 р
  7. Ядро Линукс - Бювет Чезатти 850
  8. Ставь Цели - Ицхак Пинтосевич: 150 р
  9. Артур Хейли Отель 100р
  10. Книга начинающего инвестора Антон Монин 200
  11. Волчьи стаи - подводные асы гитлера - 200
  12. Научные теории за 30 секунд 150
  13. Мексика Потенциал Экономического развития Школяр: 300
  14. Оптимизация и продваижение Ашманов и Иванов: 350
  15. Контекстная реклама Seopult: 350 рублей
  16. Контекстная реклама Яковлев Довижиков: 200 рублей
  17. Конституция Эстонии: 100 рублей
  18. ПДД РФ + Экзамен ГИББ АБСД + Безопасность дорожного движения + Экзаменационные билеты АБ с комментариями: 500 рублей
ИТ:
  1. Junos for Dummies - Goralskiy 1000 р
  2. Linux азбука ядра Родригез и Фишер - 500
  3. Linux руководство программиста Фуско 350
  4. Linux программирование в примерах Роббинс 200
  5. STL спарвочное руководство Мюссер 1000
  6. Сеть Эндрю Блам 150
  7. Основы работы с Линукс Войтов - 200
  8. Тайм менеджмент для системных администраторов Томас Лимончелли 350

Если есть интерес, пишите конаткты в комментариях либо звоните: +79516808811.

воскресенье, 12 июня 2016 г.