Go для программистов на С++

https://github.com/golang/go/wiki/GoForCPPProgrammers

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

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

Хочется начать сильно издали, от баз данных. Казалось бы, при чем здесь базы данных, когда мы говорим про Сети? Я попробую объяснить. Последние  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.

Три строчки, которые сэкономят тонну нервов с Go :)

Забивать это дело в /etc/profile сразу для всех юзеров :)

export PATH=$PATH:/usr/local/go/bin

export GOPATH="$HOME/gofolder"

export PATH=$PATH:$GOPATH/bin

Подразумевается, что Go установлен из tar.gz в папку /usr/local/go.

Мой конфиг в VIM

Выглядит вот так: https://gist.github.com/pavel-odintsov/9b3375b4de6ff7098030

Приятных фишек не так много, но отполирован за годы работы :)

ИТ прогноз на 2016й год от Одинцова Павла

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

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

---

Прогноз - начало массового внедрения технологии 100GE на всех уровнях инфраструктуры.

Подоплека: Intel выпускает 100GE сетевую карту: http://ark.intel.com/products/92674/Intel-Ethernet-Multi-host-Controller-FM10420

---

Прогноз - программируемая FPGA логика в серверных процессорах общего назначения.

Подоплека: Intel покупает компанию Altera, ведущего производителя FPGA чипов: http://www.bloomberg.com/news/articles/2015-06-01/intel-buys-altera-for-16-7-billion-as-chip-deals-accelerate Intel также не скрывает своих планов предоставить чипы программируемой логики

---

Прогноз - взрывной рост популярности сетевых switch'ей с прошивками на базе Linux (как проприетарными - Cumulus, так и полностью открытыми - https://opennetlinux.org/hcl)

Подоплека: партнерство Dell и Cumulus, https://cumulusnetworks.com/dell/, партнерство HP и Cumulus: http://www.networkworld.com/article/2884208/sdn/hp-latest-to-unbundle-switch-hardware-software.html, а также инициатива openswitch.net в целом.

В тоже время стоит отметить рост популярности white label производителей switch'ей, таких как: http://www.edge-core.com/

---

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

Подоплека: 2015й год был знаменит массовыми атаками на GutHub (http://arstechnica.com/security/2015/04/ddos-attacks-that-crippled-github-linked-to-great-firewall-of-china/), корневую инфраструктуру DNS (http://www.theregister.co.uk/2015/12/08/internet_root_servers_ddos/) и крупного оператора Linode (http://www.theregister.co.uk/2016/01/04/linode_back_at_last_after_ten_days_of_hell/). С учетом отсутствия серьезной динамики по борьбе с амплификацией и спуфингом не стоит ожидать решения этого вопроса, а наоборот - стоит ожидать появления более изощренных методик атак.

---

Прогноз - крайне активное внедрение HTTP/2 и HTTPS.

Подоплека: добавление поддержки HTTP/2 крупнейшими Интернет компаниями (Google.com, https://blog.cloudflare.com/introducing-http2/). Появление новых инструментов работающих только на базе HTTP/2 (gRPC, https://nghttp2.org). Также поддержка HTTP2 внедряется в веб-серверы, негативно радует в этом вопросе популярный сервер Nginx, отключая возможность работы одновременно с очень широко распространенным SPDY/3, а также отсутствием поддержки HTTP/2 для бэкэнда, что открывает большие перспективы конкурирующим веб-серверам.

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

Практическая сторона вопроса блестяще решена силами инициативы Let's Encrypt: https://letsencrypt.org/

---

Прогноз - повсеместное внедрение программно управляемых сетей (речь не только про SDN, а опять же решения на базе Cumulus/OpenSwitch) и превращение Network Engineer'ов в Network Developer Engineer'ов.

Подоплека: Расписана в пункте про switch'и на Linux. Всем сетевым инженерам, кто не знает хотя бы одного языка программирования придется крайне туго.

---

Прогноз - продолжение тотальной миграции проектов в облака.

Подоплека - тотальный рост облаков от Amazon, Google и Microsoft. Ни один "классический" провайдер не показывает таких темпов роста и подобного уровня технологичности решений.

---

Прогноз - software defined автомобили.

Подоплека: огромный рост популярности и ошеломляющий успех проекта Tesla. За почти половину века застоя автомобили наконец-то получили полноценную высокотехнологичную начинку и интеграцию с Интернетом. Если Вы считаете, что другие машины имеют что-то подобное, то попробуйте найти три полноценных компьютера и внутреннюю локальную сеть внутри них, а в Тесле - это норма! :)

---

Прогноз - развитие ИИ огромными темпами!

Подоплека - создание открытого проекта https://openai.com/blog/introducing-openai/ и выделение ему инвестиций в размере $1 млрд. Все результаты работы ученых будут опубликованы в свободном доступе. Что же это? Констатация невозможности и высочайшей сложности решения данной задачи? Пожалуй, так и есть. Но все вместе мы определенно справимся.

Также, безусловно, стоит отметить открытие проекта https://tensorflow.org с машинным обучением от Google.

---

Прогноз - дальнейшая глубокая социализация программирования и open source.

Подоплека - если раньше open source был уделом гиков, то теперь у нас есть своя "социальная сеть" - GitHub.com и ошеломляющего размера армия программистов :) Почти все крупные проекты в том или ином виде переходят под крыло GitHub, предоставляющего потрясающую по удобству и возможностям систему коммуникации между программистами. Пожалуй, сложно придумать проект, который так сильно бы продвинул удобство и организацию разработки.

---

Прогноз - начало снижения популярности классических Linux дистрибутивов (Ubuntu, Debian, RHEL, CentOS) при установке непосредственно на сервер. Расцвет гибридных ОС основанных на технологии Docker и Linux контейнерах (CoreOS, http://www.projectatomic.io/).

Подоплека: высокое удобство, легкость масштабирования, готовность проекта Docker для промышленного использования.
---

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

Подоплека - огромная работа со стороны компании Virtuozzo (Odin, Parallels) и RedHat для повышения безопасности контейнеров. В тоже время крайне не радует, что данные проекты сконцентрированы вовсе не на ванильном  Linux ядре, а на сильно старых и уже заведомо устаревших форках ядра (Linux 3.10).

Также стоит отметить появление сервиса https://aws.amazon.com/blogs/aws/cloud-container-management/ в публичной доступности!

---

Прогноз - продолжение стремительного роста и повышение популярности NoSQL баз данных (MongoDB, Couchbase, RethinkDB, RocksDB, Redis, Cassandra)

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

Стоит отдельно отметить, что даже классические БД, такие как MySQL и PostgreSQL пошли по пути копирования функционала из NoSQL, например, в недавнее время в них была добавлена поддержка JSON.


Заключение.

Все выше сказанное является лишь субъективным мнением автора (Pavel Odintsov, pavel.odintsov at gmail.com) и не обязательно к исполнению :)

How to scale graphite up to X times and reduce cpu consumption twice?

So much customers who are working with Graphite could highlight two significant issues with Graphite:
1) It's coded with Python which pretty slow
2) It's bundled to single CPU core and need clustering for using all cores

I have hit first issue. I'm using Graphite with FastNetMon for awesome visual reports and I'm storing about 40 000 records per second.

So carbon daemon eat so much cpu:

top - 13:58:37 up 128 days, 19:32,  1 user,  load average: 3.88, 3.80, 3.76
Tasks: 150 total,   1 running, 149 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  8.8 sy,  0.0 ni, 66.2 id, 11.6 wa,  0.1 hi,  0.8 si,  0.0 st
KiB Mem:  32933416 total, 31923200 used,  1010216 free,   697700 buffers
KiB Swap:  3905532 total,   564568 used,  3340964 free. 26169476 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAN  
20598 root      20   0 5343724 619232 543572 S 179.0  1.9  80770:18 fastnetmon            
22981 _graphi+  20   0  250300 128484   4756 S  21.3  0.4   0:06.81 carbon-cache          

So We could hit limit with about 200 000 records per second and it's not so fine.

I have found awesome product Go-Carbon. It's drop-in replacement for carbon daemon and it's implemented in Golang (very fast and reliable!).

So I have replaced my existing carbon with go-carbon this way. I'm using Debian 8 and all guide will be about it.

Install it:

wget https://github.com/lomik/go-carbon/releases/download/v0.6/go-carbon_0.6_amd64.deb
dpkg -i go-carbon_0.6_amd64.deb

Then we need to change path to original graphite data files (it's completely back compatible but please keep backup):

Then open file /etc/go-carbon/go-carbon.conf

And change following options:

schemas-file = "/etc/carbon/storage-schemas.conf"
data-dir = "/var/lib/graphite/whisper/"
user = "_graphite"
max-updates-per-second = 500 (because it's standard configuration for graphite: MAX_UPDATES_PER_SECOND = 500)

Then switch off python carbon and start go-carbon:

 /etc/init.d/carbon-cache stop
/etc/init.d/go-carbon start

So you still can use graphite web for reading data! And feed data with pickle of text protocol.  It's completely back compatible.

And it's lightning fast:

top - 13:57:44 up 128 days, 19:32,  1 user,  load average: 3.85, 3.78, 3.75
Tasks: 149 total,   1 running, 148 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13.6 us, 12.5 sy,  0.0 ni, 62.0 id, 10.7 wa,  0.1 hi,  1.0 si,  0.0 st
KiB Mem:  32933416 total, 31888556 used,  1044860 free,   697680 buffers
KiB Swap:  3905532 total,   564568 used,  3340964 free. 26161116 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
20598 root      20   0 5343724 619232 543572 S 208.1  1.9  80768:40 fastnetmon  
21882 _graphi+  20   0  446480 102512   8028 S  10.7  0.3   6:59.83 go-carbon   

As you can see we got two times CPU usage reduction!  But you could use workers = X and max-cpu = X option for scaling go-carbon over all available cores!

We have awesome picture from author:

Эффективность работы антивирусов на платформе Linux

В течение последних 2-3 недель (с конца апреля до 8го мая 2014) с помощью Antidoto и в процессе его отладки мною было обнаружено большое число зловредного ПО на различных Linux машинах. Оно по-разному пробиралось на серверы, но было обнаружено и удалено с машин с исправлением исходных причин заражения. В процессе этого было изъято большое число исполняемых файлов, которые были тщательным образом проанализированы в запущенном виде и после этого нейтрализованы. Наиболее интересные экземпляры исследованы здесь.После изъятия все файлы были проверены ведущими антивирусами и результаты проверок приведены ниже.

• apache2_rootkit_from_srv_277274 ced2ebfccfe2d52f362908020acd5831 0/51
• apache_rootkit_from_srv_277274 614ad37e6755ef7443addd2df27256c2 0/51
• atd_virus_ovz17 36f6c1169433cc8a78498d54393132ed 1/51 только Kaspersky, после репорта
• fake_sshd_mc e3305c8ae035d81d75cf0d4ea2ba1131 0/52
• irc_bouncer_hidden_as_ssh_from_5560 d7cb8d530dd813f34bdcf1b6c485589b 1/52только Avast, ELF:PsyBNC-A [PUP]
• jawa 36c97cdd3caccbacb37708e84b22a627 0/52
• libworker.so a6765b7ab914e042a6f8e1adb59c08b9 2/52 Kaspersky Avast
• pine_virus_from_2441 88cc70e9f07654d5afc392bf4e135d87 0/52
• ps_virus_ct_6205 21f9a5ee8af73d2156333a654130f3f8 1/49 Kaspersky, после нашего репорта.
• sfewfesfs f9ad37bc11a4f5249b660cacadd14ad3 3/52 Avast, Gdata, Qihoo-360
• sfewfesfsh 9b6283e656f276c15f14b5f2532d24d2 5/52 DrWeb, Kaspersky, Qihoo-360, TrendMicro-HouseCall, ViRobot
• sshd_32_bit_fake_from_2453 0c0dc04b427e8e2bf90fcc4e6dc6cbc9 0/52
• virus_from_43165 a6752df85f35e6adcfa724eb5e15f6d0 1/52 Только Kaspersky, после нашего репорта
• named_bitcoin_virus 99ca61919f5afbdb3c0e07c30fad5bb1 9/52 Avast, Bkav, DrWeb, ESET-NOD32, Fortinet, Kaspersky, TrendMicro, TrendMicro-HouseCall, VBA32

Все вирусы были отправлены на Virustotal и могут быть найдены по хэшам (в том числе сотрудниками AV компаний), все вирусы были перданы в компанию ClamAv, часть вирусов была передана в компанию Kaspersky.

Итого, 14 типов подтвержденно зловредного ПО:

• 6 из них не определяются никаким антивирусным ПО
• 3 определяются антивирусом Касперского только после получения багрепорта от нас
• 1 определяется только антивирусом Avast
• 4 типа зловредного ПО определяются более чем одним антивирусом.

Победителей я бы распределил так:

• Avast (безоговорочная победа)
• Kaspersky (более-менее, наши посылки не учиытвались в анализе)
• DrWeb (2 вируса, мало, но лучше, чем что-то)

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

Update: в данный момент все вирусы были полностью отправлены в DrWeb и Kaspersky, ClamAV. Остальным отправлять очень лениво.

Выводы

А они печальные - даже от базовых очень стандартных вирусов (многие из приведенных мною загружались на VirusTotal еще несколько лет назад и до сих пор никем не определяются) антивирусы не предоставляют НИКАКОЙ ЗАЩИТЫ вообще.

Что же делать? Иметь очень хорошего системного администратора и использовать проверенные диагностические утилиты - netstat, ss, lsof и другие в дополнение к тулкиту Antidoto :)

Источник, моя же публикация. 

Отличный доклад про фрагментацию ploop

Рекомендую всем, что работает с OpenVZ! 

Бесплатный журнал Интернет изнутри от MSK-IX

Прошу любить и жаловать всех, кто так или иначе связан с сетью Интернет.

Сетевикам прочтение крайне обязательно: http://www.ccni.ru/download/InternetInside/InternetInside_N1.pdf

Реалии использования динамических библиотек скомпилированных силами Go из С/С++

Всем известно, что начиная с версии 1.5 Golang научился делать бинарные динамические .so библиотеки (go build -buildmode=c-shared -o libgobgp.so *.go), которые можно прилинковать к православному C коду.

Но если копнуть дальше, на деле это не совсем .so библиотека и привычного нам машинного кода там нету.

А есть обертки, которые вызывают код из Golang и подставляют себя С функциями.

Дада, Вы верно догадываетесь, Go's runtime запускается рядом. Не заметить это сложно - появляется 5ка тридов рядом с вашей программой Смайлик «smile»

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

И если оно форкается или форкается и потом использует popen - горевать Вам очень долго, потому что многопоточное приложение, которым с момента запуска int main стал Ваш любимый софт из-за Go рантайма нельзя форкать, будет все крайне плохо Смайлик «smile»

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

Как чинить? Линковаться динамически в рантайме, силами dlopen/dlsym, как сделал я - тут.

Вот так вот друзья - не все так просто, за все нужно платить Смайлик «smile»После этого фикса все стало работать решительно приличнее, но совершенно никаких гарантий, что так будет и впредь.

Недостатки используемых в данный момент способов доставки приложений и библиотек

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

Кто эти люди, кто считает, что старый, неактуальный код полутора летней давности НАДЕЖНЕЕ того же самого кода, который был выправлен от пары-тройки критичных багов, скажем, неделю назад?

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

Единственные, кто хотя бы отчасти радует в этом мире идиотизма - это Ubuntu LTS, которые нарушили все кармические запреты и обновляют ядро до разумных версий!

Red Hat со своим чудо-ядром класса 2.6.32 на стероидах с тыщей бэкапорт патчей сверху (да пропади оно пропадом сто раз - баголовище и багокостылище) не просто задрал, а задрал - нисказанно Смайлик «smile»

Алсо, друзья, какие выходы из этой патовой ситуации Вы видите?

Мы уже местами упоролись в конец и собираем то-что-нам-нужно (на богобоязныенных Го и Си Плас Плас) вручную и нужных-нам-версий, используя от дистрибутива лишь базовые вещи (хотя под час там даже базовый компилятор - старье и им просто-напросто не собрать актуальный проект, скажем, на С++ 11).

Докеры и прочее прошу не рекомендовать - я хочу решение, а не костыль и желательно без 7ми слоев виртуализаци и изоляции даже если она делается во благо мне Смайлик «smile»

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

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

Но при этом хочется возможности фиксировать библиотеки. Скажем - я опираюсь на xxx, yyy, zzz и просто не хочу получать обновления на их следующие версии, а только обновления, скажем, безопасности.

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

Также вместо докера с его огромным ворохом проблем рекомендую посмотреть на CoreOS + Rocket (годная и адекватная замена Doker спроектированная инженерами, а не хипстерами).

А что думаете Вы?

Остерегайтесь! Криптеры файлов дошли до мира Linux серверов

Кажется эре наплевательского отношения к безопасности в сфере хостинга наступает конец.

Буквально несколько дней назад столкнулись с о взломами клиентских выделенных серверов и VPS, когда вместо очередного ботнет-контроллера, спам-скрипта или же флудера гостевых книг (c) (tm) появилось нечто новое.

Это "нечто" заимев root полномочия на машине (отдельный вопрос - как, но в целом данный вектор атаки работает даже без рутания) зашифровало к чертям все от начала до конца файлы (а это - десятки гигабайт) на сервере относящиеся к сайтам (текст скриптов) и базам данных (все внутренности mysql) и услужливо разложило везде файлик info с указанием Bitconin кошелька куда класть выкуп если вдруг образовалось желание вернуть свои файлы обратно.

Друзья, искренне рекомендую всем иметь надежный бэкап!

Effectiveness of ZFS usage for OpenVZ

This article is a detailed answer to conversation about simfs vs ploop vs ZFS from OpenVZ maillist.

Because I have finished very detailed tests of ZFS for VPS storage I would like to share they with my Dear Community. 

Source data (real clients, real data, different OS templates, different OS templates versions, server running for ~1year, production server full copy):

Size: 5,4T
Used: 3,5T
Avail: 1,7T
Usage:69%

This data from HWN with OpenVZ with ploop.

Our internal toolkit fastvps_ploop_compacter show following details about this server:

Total wasted space due to ploop bugs: 205.1 Gb

Wasted space means difference between real data size and ploop disks size, i.e. ploop overhead.

gzip compression on ZFS

We have enabled ZFS gzip compression and move all data to new created ZFS volume.

And we got following result:

NAME          SIZE   ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT data  8,16T  3,34T  4,82T    40%  1.00x  ONLINE  -

As you can see  we save about 160 GB of data. New ZFS size of this data is: 3340 GB, old size: 3500 GB.

lz4 compression on ZFS

So, ZFS developers do not recommend gzip and we will try lzr4 compression as best option.

We copy same data to new ZFS storage with lz4 compression enabled and got following results:

ALLOC: 2,72Tb

Wow! Amazing! We save about 600 Gb of data!  Really!

ZFS deduplication

As you know, ZFS has another killer feature - deduplication! And it's best option when we store so much containers with fixed number of distributions (debian, ubuntu, centos).

But please keep in mind, we have disabled compression on this step!

We have enabled deduplication for new storage and copy all production data to new storage with deduplication.

When data copy was finished we got this breath taking results:

zpool list

NAME         SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOTdata  8,16T  2,53T  5,62T    31%  1.33x  ONLINE  -

We have saved 840 GB of data with deduplication! We are really close to save 1Tb!

For very curious readers I could offer some internal data regarding ZFS dedup:

zdb -D data
DDT-sha256-zap-duplicate: 5100040 entries, size 581 on disk, 187 in core
DDT-sha256-zap-unique: 27983716 entries, size 518 on disk, 167 in core
dedup = 1.34, compress = 1.00, copies = 1.02, dedup * compress / copies = 1.31

ZFS compression and deduplication simultaneously

So, ZFS is amazingly flexible and we could use compression and dedulication in same time and got even more storage save. And this tests is your own home task :) Please share your results here!

Conclusion

That's why we have only single file system which ready for 21 century. And ext4 with derivative file systems should be avoided everywhere if possible.  

So, will be fine if you help ZFS on Linux community with bug reporting and development! 

How to enable Autonomus System Lookup for tshark/wireshark?

In article http://www.stableit.ru/2015/04/how-to-enable-geoip-support-in-tshark.html we discuss GeoIP feature. If you interested in AS numbers of client hosts, please execute this reference.

Install GeoIP:

apt-get install -y geoip-database

Then download ASN database:

wget http://geolite.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz
gunzip GeoIPASNum.dat.gz
mv GeoIPASNum.dat  /usr/share/GeoIP/

Then you should specify folder with GeoIP databases to Wireshark:

mkdir -p ~/.wireshark
echo '"/usr/share/GeoIP"' > ~/.wireshark/geoip_db_paths

Let's start:

tshark -i eth0 -n -T fields -e ip.geoip.src_asnum -o "ip.use_geoip: TRUE"

And you will get following output:

AS60781 LeaseWeb B.V.
AS34757 Sibirskie Seti Ltd.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS200000 Hosting Ukraine LTD
AS60781 LeaseWeb B.V.
AS23947 PT.Mora Telematika Indonesia
AS60781 LeaseWeb B.V.
AS2914 NTT America, Inc.
AS60781 LeaseWeb B.V.
AS18881 Global Village Telecom

Селективный блэкхол

Видимо, пошло оно от selective blackhole. На удивление недавно (на ENOG9) обнаружил, что термин частенько не понимается многими и вовсе не является обще принятым :)

Что же он означает? Речь идет о RTBH (remote triggered black hole), который обычно висит на BGP комьюнити 666. При его активации он блокирует весь трафик с/на узел.

Селективный же блокирует либо заданный протокол (часто - UDP) либо же набор протоколов по определенным параметрам (например, популярные UDP амплификаторы).

Операторы, кто поддерживает это дело - редки, делимся в комментах :)