Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 12222 сообщений
Cообщения с меткой

linux - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Анонс конференции Linux Piter 2016 — второй международной Linux-конференции в России

Четверг, 25 Августа 2016 г. 17:20 (ссылка)

Сейчас мы активно готовим вторую конференцию Linux Piter и, пока формируется список докладчиков, давайте вспомним как прошла её первая часть.



image







В прошлом году мы вместе с коллегами из Айти-События провели первую большую международную Linux-конференцию в Санкт-Петербурге. Это была однодневная конфа с докладами в 3 параллельных потока. Событие такого уровня и масштаба в России нам захотелось сделать после поездки на множество прекрасных Linux-конференции в Штатах, Канаде и Европе.



Для первого раза мы собрали 150 человек, если быть совсем точным то 148, тогда это был в основном Питер и Москва, хотя и гостей из России и зарубежья было более чем достаточно.



Состав участников был достаточно предсказуем: почти половина программисты, треть — системные администраторы, остальные представители ВУЗов и технические менеджеры.

image

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



Ключевыми спикерами конференции стали: Павел Емельянов (Архитектор / OpenVZ, Москва), Daniel Nagy (Managing director / ePoint Systems / Венгрия), John Ronciak (SW Architect / Intel / США), Allen Hubbe (Software engineer / EMC / США) и Илья Космодемьянский (CEO и консультант / PostgreSQL-Consulting / Германия).



image



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



image



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



О подготовке Linux Piter 2016





В этом году конференция Linux Piter станет двухдневной, она будет проходить в 2 параллельных потока докладов и состоится 11-12 ноября 2016 в Санкт-Петербурге.



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



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



Итак, ТОП 10 докладов конференции Linux Piter 2015





1) Павел Курочкин и Денис Габидуллин: “Самый SoC, linux, u-boot, грабли”







2) Константин Ушаков: “Сетевой стек OpenOnload. В чем и почему он обыгрывает ядро Linux”







3) Александр Чистяков: “Оптимизация производительности в Linux: время удивительных историй”







4) Павел Емельянов: “Живая миграция контейнеров: плюсы, минусы, подводные камни”







5) Тимофей Туренко: “MaxScale: интеллектуальный шлюз данных”







6) Александра Федорова: “OpenStack CI: flows, tooling, and more”







7) Илья Космодемьянский (Linux tuning to improve PostgreSQL performance),







8) Евгений Поляков: “История, опыт, ошибки и успехи в процессе создания по-настоящему масштабируемых систем хранения данных”







9) John Ronciak: “DPDK — The many ways to configure the kernel interfaces”







10) Дмитрий Самсонов: “Тюним память и сетевой стек в Linux: история перевода высоконагруженных серверов на свежий дистрибутив”







Все доступные записи вы можете найти на нашем канале.



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



Linux Piter – взрослая конференция о системах, платформах и инструментах.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308536/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Rost

Про рутовый пароль (дыбр)

Четверг, 25 Августа 2016 г. 10:34 (ссылка)

Вчера делать было нечего, устроил себе геморрой на ровном месте: вместо "su" набрал "sudo". И офигел, что рутовый пароль не подходит.

Загрузил Kali с LiveCD, с горем пополам ничего сделать не смог. Разве что хеш старого пароля стёр. При этом новый задать не смог. Получил ошибку проверки подлинности. Но я - упорный. Скачал LiveCD с Calculate, загрузился, задал пароль.

Подумал, что если уже 2 LiveCD загрузил, можно попробовать и другие дистрибутивы. Ещё попробовал CentOS и последнюю Ubuntu (16.04.1). Ubuntu даже удалось повесить. Для этого достаточно запустить Unity под root. Ubuntu - прикольная. Единственная OS, которая не хотела меня пускать в мой раздел на жёстком диске (с Windows, кстати, она это себе не позволяла).

Сегодня попробую Mint. Спасибо Яндексу за ftp-зеркало и доступ к iso-образам большинства известных дистрибутивов.
Метки:   Комментарии (24)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Linux исполнилось 25 лет

Среда, 25 Августа 2016 г. 03:32 (ссылка)



Линус Торвальдс собственной персоной



Время бежит очень быстро, и операционной системе Linux уже исполнилось четверть века. Правильнее было бы говорить, что 25 лет исполнилось ядру этой операционной системы. С общей историей появления Linux знакомы, вероятно, все читатели Habrahabr. 25 августа 1991 года, спустя пять месяцев после начала работы над своим проектом, 21-летний Линус Торвальдс (тогда еще студент) рассказал о создании прототипа совершенно новой ОС с названием Linux.



17 сентября 1991 года состоялся первый публичный выпуск ядра Linux. Версия ядра на тот момент — 0.0.1. Уже тогда количество строк кода ядра составляло 10 тысяч. Размер его был всего 62 Кб в сжатом виде. Сейчас же ядро насчитывает во много раз больше строк кода — целых 19 млн. Если бы разработка ОС проводилась силами коммерческой организации, то стоимость такого проекта составила бы около миллиарда долларов США, а то и более.



Линус Торвальдс решил создать ядро после работы с операционной системой MINIX. Она не устроила студента ограниченной лицензией. Как водится, Торвальдса пытались обвинить в плагиате. А именно в том, что он просто скопировал код ряд подсистем MINIX. Но специалистам удалось доказать, что это не так. Сам автор MINIX Эндрю Таненбаум сравнил код своей ОС и Linux, и пришел к выводу, что в коде есть лишь несколько несущественных совпадений, на которые можно не обращать внимание. Эти совпадения обусловлены рядом требований POSIX и ANSI C.



Интересно, что Linux мог бы изначально называться Freax («free», «freak» и X (Unix)). Такое название своему проекту дал сам Линус. Но Ари Лемке (Ari Lemmke), который по просьбе Линуса выложил ядро на своем FTP-сервере, назвал директорию с ядром «linux». С момента своего первого релиза ядро претерпело множество преобразований. Вот наглядная статистика:




  • 0.0.1 — сентябрь 1991, 10 тыс. строк кода;

  • 1.0.0 — март 1994, 176 тыс. строк кода;

  • 1.2.0 — март 1995, 311 тыс. строк кода;

  • 2.0.0 — июнь 1996, 778 тыс. строк кода;

  • 2.2.0 — январь 1999, 1.8 млн. строк кода;

  • 2.4.0 — январь 2001, 3.4 млн. строк кода;

  • 2.6.0 — декабрь 2003, 5.9 млн. строк кода;

  • 2.6.28 — декабрь 2008, 10.2 млн. строк кода;

  • 2.6.35 — август 2010, 13.4 млн. строк кода;

  • 3.0 — август 2011, 14.6 млн. строк кода.

  • 3.5 — июль 2012, 15.5 млн. строк кода.

  • 3.10 — июль 2013, 15.8 млн. строк кода;

  • 3.16 — август 2014, 17.5 млн. строк кода.

  • 4.1 — июнь 2015, 19.5 млн. строк кода.

  • 4.7 — июль 2016, 21.7 млн. строк кода.





Ядро развивается силами сторонних разработчиков. По данным Linux Foundation, с 2005 года в разработке системы приняли участие 13500 специалистов. Средняя скорость работы над системой — 7,8 патчей в час. В разработке системы принимают участие не только независимые разработчики, но и многие представители крупных технологических корпораций. Среди прочих можно упомянуть Intel, Red Hat, Linaro, Samsung, SUSE, IBM, Renesas, Google, AMD, Taxas Instuments и ARM.



«Я очень доволен настольной версией Linux. Конечно же, я хотел, чтобы Linux захватил и мир настольных PC, но, как оказалось, эту область захватить очень сложно. Я по-прежнему работаю над этим. Прошло уже 25 лет. Я могу потратить на это ещё 25 лет. Я добьюсь своего долгой осадой», — сказал Линус Торвальдс в ходе своего апрельского выступления на конференции Embedded Linux.



По словам Джима Землина, исполнительного директора организации Linux Foundation, «в свои 25 лет Linux выглядит солидно… ОС пошла дальше, чем мы могли ожидать». По его мнению, операционная система продолжает развиваться по плану, и будет существовать в отдаленном будущем.



Картинки по запросу linux



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



«Совместная работа, в ходе которой совершенствуется каждый ее участник, — это высокая цель, и она имеет огромное значение, — сказал Джим Землин. — Это и есть проявление волшебства Linux и всего Open Source, и именно к таким результатам движение Linux пришло через 25 лет».



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



С днем рождения, Linux! С юбилеем!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308470/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Docker: гибкая сеть без NAT на все случаи жизни

Среда, 24 Августа 2016 г. 16:00 (ссылка)

image



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



Так дело обстояло и в моем случае. Хочу заметить, что многие задачи, которые приходится делать, я делаю по принципу keep it simple. То есть почти всегда, если для решения задачи можно использовать простые инструменты и шаги, я выберу этот путь. Я понимаю, что простой или сложный шаг или инструмент — оценка субъективная, но т.к. работаем мы в команде, то вот такие критерии могут подходить при выборе инструментов:




  • используется ли инструмент в инфраструктуре?

  • если требуется что-то новое, то нельзя ли использовать то, что уже есть?

  • насколько сильно обслуживание (обновление, перезапуск) сервиса будет отличаться от остальных сервисов?

  • <...>



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



О том, как Docker работает с сетью, можно ознакомиться по ссылке. Выделим основные моменты:




  • default bridge network;

  • host network;

  • user defined network.



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



Долгое время (да чего уж скрывать — и по сей день) для запуска контейнеров мы используем параметр --net=host, получая тем самым «нативный» eth внутри контейнера. Да, в этом случае одного бенефита — изоляции — мы, конечно, лишаемся… Но посмотрев на плюсы и минусы в нашем конкретном случае, мы намеренно пришли к такому решению, т.к. задачи изолировать сеть между запущенными приложениями в рамках одного хоста не стояло. Хочу напомнить, что пишу я о конкретном месте применения Docker — в Badoo.



Что мы знаем про наши сервисы:




  • у нас есть карта размещения сервисов на серверах;

  • у нас есть карта портов для каждого сервиса и его типа (или типов, если их много);

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



Исходя из вышесказанного, мы гарантируем следующее:




  • если мы запускаем несколько сервисов на одной машине с --net=host, то пересечения портов мы не получим: все запустится и будет работать;

  • если нам станет мало одного eth-интерфейса, то мы физически подключим еще один и посредством, например, DNS, раскидаем нагрузку между ними.



Все хорошо, тогда зачем мне пришлось что-то менять?



Дело было вечером, делать было нечего… Ранее говорилось о том, что мы продолжаем переносить наши сервисы в контейнеры. При следовании такому сценарию, как это обычно бывает, самые сложные остаются на потом. Причин для этого может быть масса:




  • сервис критичен;

  • отсутствие достаточного опыта, чтобы предложить максимально прозрачный и быстрый переезд сервиса в контейнер;

  • можно «добавить что-то еще по вкусу».



Ну так вот. Был (и есть) у нас один такой сервис, который давно написан. Он и по сей день отлично работает, но есть у него несколько минусов:




  • работает он на одном ядре (да, такое бывает);

  • восполняя первый пробел, стоит отметить, что можно запустить несколько инстансов сервиса и использовать taskset/--cpuset-cpus;

  • сервис «сильно» использует сеть, а также ему требуется большое количество портов для исходящих соединений.



Вот так сервис запускался ДО:




  • на машине, где планировалось поднятие сервиса, нужно было добавить дополнительный IP-адрес (или даже несколько) — ip a add (тут можно сразу указать на много минусов данного подхода, о которых мы знаем);

  • про вышесказанное стоит помнить, чтобы не получить, к примеру, 2 одинаковых адреса на разных машинах;

  • в конфигурации демона стоило указать, на каком адресе он работает, как раз чтобы не «съесть» все порты соседа или хост-системы.



Как можно было решить задачу, если бы было лень изобретать новые методы:




  • оставить все как есть, но обернуть в контейнер;

  • поднимать на dockerhost все те же дополнительные IP-адреса;

  • «биндить» приложение на конкретный адрес.



Как к задаче решил подойти я? Изначально, конечно, это все выглядело как эксперимент, да чего скрывать — это и было экспериментом. Мне показалось, что для этого сервиса как нельзя кстати подойдет MACVLAN-технология, которая на тот момент была отмечена в Docker как Experimental (версия 1.11.2), а вот в версии 1.12 всё уже доступно в основном функционале.



MACVLAN — это, по сути, Linux switch, который основан на статичном соответствии MAC и VLAN. Здесь используется unicast-фильтрация, не promiscuous-режим. MACVLAN может работать в режиме private, VEPA, bridge, passthru. MACVLAN — это reverse VLAN в Linux. Данная технология позволяет взять один реальный интерфейс и сделать на его основе несколько виртуальных с разными MAC-адресами.



Также сравнительно недавно появилась технология IPVLAN(https://www.kernel.org/doc/Documentation/networking/ipvlan.txt). Основное отличие от MACVLAN заключается в том, что IPVLAN может работать в L3 mode. В данной статье я буду рассматривать вариант использования MACVLAN (в режиме bridge), потому что:




  • не стоит ограничение в 1 MAC-адрес с одного линка на активном сетевом оборудовании;

  • количество контейнеров на хосте не будет таким большим, что может привести к превышению mac capacity. С течением времени этот момент у нас может, конечно, измениться;

  • на данном этапе L3 не нужен.



Чуть подробнее про MACVLAN vs IPVLAN можно ознакомиться по ссылке http://hicu.be/macvlan-vs-ipvlan.

Вот здесь можно почитать теорию и как это работает в Docker: https://github.com/docker/docker/blob/master/experimental/vlan-networks.md.



Теория — это отлично, но даже там мы видим, что overhead имеет место быть. Можно и нужно посмотреть на сравнительные тесты пропускной способности MACVLAN в интернете (например, http://comp.photo777.org/docker-network-performance/ и http://delaat.net/rp/2014-2015/p92/report.pdf), но также неотъемлемой частью эксперимента является проведение теста в своих лабораторных условиях. Поверить на слово — хорошо, но «потрогать руками» и сделать выводы самому — интересно и необходимо.



Итак, поехали!


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

Если данный функционал при сборке не включен, то в логах можно будет видеть вот такие сообщения об ошибках:



# docker network create -d macvlan --subnet=1.1.1.0/24 --gateway=1.1.1.1 -o parent=eth0 cppbig_vlan
Error response from daemon: plugin not found


А в логах процесса будет следующее:



docker[2012]: time="2016-08-04T11:44:44.095241242Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 1s"
docker[2012]: time="2016-08-04T11:44:45.095489283Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 2s"
docker[2012]: time="2016-08-04T11:44:47.095750785Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 4s"
docker[2012]: time="2016-08-04T11:44:51.095970433Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 8s"
docker[2012]: time="2016-08-04T11:44:59.096197565Z" level=error msg="Handler for POST /v1.23/networks/create returned error: plugin not found"


Если вы видите такие сообщения — значит, поддержка MACVLAN в Docker не включена.



Тест был символическим, с использованием iperf. Для каждого варианта я запускал сначала 1 клиента, потом 8 в параллель. Вариантов было 2:




  • --net=host;

  • --net=macvlan.



Посмотреть на тест подробнее
Запускаем сервер:


# docker run -it --net=host --name=iperf_w_host_net --entrypoint=/bin/bash dockerio.badoo.com/itops/sle_12_base:latest
# iperf3 -s -p 12345
-----------------------------------------------------------
Server listening on 12345
-----------------------------------------------------------


Запускаем клиента:


# iperf3 -c 1.1.1.2 -p 12345 -t 30


На сервере получаем результат:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth

[ 5] 0.00-30.04 sec 0.00 Bytes 0.00 bits/sec sender

[ 5] 0.00-30.04 sec 2.45 GBytes 702 Mbits/sec receiver



На клиенте:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-30.00 sec 2.46 GBytes 703 Mbits/sec 0 sender

[ 4] 0.00-30.00 sec 2.45 GBytes 703 Mbits/sec receiver





Запускаем в параллель 8 клиентов:


# iperf3 -c 1.1.1.2 -p 12345 -t 30 -P 8


На сервере получаем результат:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth

[ 5] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 5] 0.00-30.03 sec 314 MBytes 87.7 Mbits/sec receiver

[ 7] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 7] 0.00-30.03 sec 328 MBytes 91.5 Mbits/sec receiver

[ 9] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 9] 0.00-30.03 sec 305 MBytes 85.2 Mbits/sec receiver

[ 11] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 11] 0.00-30.03 sec 312 MBytes 87.3 Mbits/sec receiver

[ 13] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 13] 0.00-30.03 sec 316 MBytes 88.3 Mbits/sec receiver

[ 15] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 15] 0.00-30.03 sec 310 MBytes 86.7 Mbits/sec receiver

[ 17] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 17] 0.00-30.03 sec 313 MBytes 87.5 Mbits/sec receiver

[ 19] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 19] 0.00-30.03 sec 321 MBytes 89.7 Mbits/sec receiver

[SUM] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[SUM] 0.00-30.03 sec 2.46 GBytes 704 Mbits/sec receiver



На клиенте:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-30.00 sec 315 MBytes 88.1 Mbits/sec 0 sender

[ 4] 0.00-30.00 sec 314 MBytes 87.8 Mbits/sec receiver

[ 6] 0.00-30.00 sec 330 MBytes 92.3 Mbits/sec 0 sender

[ 6] 0.00-30.00 sec 328 MBytes 91.6 Mbits/sec receiver

[ 8] 0.00-30.00 sec 306 MBytes 85.6 Mbits/sec 0 sender

[ 8] 0.00-30.00 sec 305 MBytes 85.3 Mbits/sec receiver

[ 10] 0.00-30.00 sec 313 MBytes 87.5 Mbits/sec 0 sender

[ 10] 0.00-30.00 sec 312 MBytes 87.4 Mbits/sec receiver

[ 12] 0.00-30.00 sec 317 MBytes 88.8 Mbits/sec 0 sender

[ 12] 0.00-30.00 sec 316 MBytes 88.4 Mbits/sec receiver

[ 14] 0.00-30.00 sec 312 MBytes 87.1 Mbits/sec 0 sender

[ 14] 0.00-30.00 sec 310 MBytes 86.8 Mbits/sec receiver

[ 16] 0.00-30.00 sec 314 MBytes 87.9 Mbits/sec 0 sender

[ 16] 0.00-30.00 sec 313 MBytes 87.6 Mbits/sec receiver

[ 18] 0.00-30.00 sec 322 MBytes 90.2 Mbits/sec 0 sender

[ 18] 0.00-30.00 sec 321 MBytes 89.8 Mbits/sec receiver

[SUM] 0.00-30.00 sec 2.47 GBytes 707 Mbits/sec 0 sender

[SUM] 0.00-30.00 sec 2.46 GBytes 705 Mbits/sec receiver





2. Запускам сервер, используя MACVLAN:


# docker run -it --net=cppbig_vlan --name=iperf_w_macvlan_net --ip=1.1.1.202 --entrypoint=/bin/bash dockerio.badoo.com/itops/sle_12_base:latest
# iperf3 -s -p 12345
-----------------------------------------------------------
Server listening on 12345
-----------------------------------------------------------


Запускаем клиента:


# iperf3 -c 1.1.1.202 -p 12345 -t 30


На сервере получаем результат:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth

[ 5] 0.00-30.04 sec 0.00 Bytes 0.00 bits/sec sender

[ 5] 0.00-30.04 sec 2.45 GBytes 701 Mbits/sec receiver



На клиенте:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-30.00 sec 2.46 GBytes 703 Mbits/sec 0 sender

[ 4] 0.00-30.00 sec 2.45 GBytes 702 Mbits/sec receiver





Запускаем в параллель 8 клиентов:


# iperf3 -c 1.1.1.202 -p 12345 -t 30 -P 8


На сервере получаем результат:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth

[ 5] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 5] 0.00-30.03 sec 306 MBytes 85.4 Mbits/sec receiver

[ 7] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 7] 0.00-30.03 sec 319 MBytes 89.1 Mbits/sec receiver

[ 9] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 9] 0.00-30.03 sec 307 MBytes 85.8 Mbits/sec receiver

[ 11] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 11] 0.00-30.03 sec 311 MBytes 87.0 Mbits/sec receiver

[ 13] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 13] 0.00-30.03 sec 317 MBytes 88.6 Mbits/sec receiver

[ 15] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 15] 0.00-30.03 sec 322 MBytes 90.1 Mbits/sec receiver

[ 17] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 17] 0.00-30.03 sec 313 MBytes 87.5 Mbits/sec receiver

[ 19] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[ 19] 0.00-30.03 sec 310 MBytes 86.7 Mbits/sec receiver

[SUM] 0.00-30.03 sec 0.00 Bytes 0.00 bits/sec sender

[SUM] 0.00-30.03 sec 2.45 GBytes 700 Mbits/sec receiver



На клиенте:

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-30.00 sec 307 MBytes 85.8 Mbits/sec 0 sender

[ 4] 0.00-30.00 sec 306 MBytes 85.5 Mbits/sec receiver

[ 6] 0.00-30.00 sec 320 MBytes 89.6 Mbits/sec 0 sender

[ 6] 0.00-30.00 sec 319 MBytes 89.2 Mbits/sec receiver

[ 8] 0.00-30.00 sec 308 MBytes 86.2 Mbits/sec 0 sender

[ 8] 0.00-30.00 sec 307 MBytes 85.9 Mbits/sec receiver

[ 10] 0.00-30.00 sec 313 MBytes 87.5 Mbits/sec 0 sender

[ 10] 0.00-30.00 sec 311 MBytes 87.1 Mbits/sec receiver

[ 12] 0.00-30.00 sec 318 MBytes 89.0 Mbits/sec 0 sender

[ 12] 0.00-30.00 sec 317 MBytes 88.6 Mbits/sec receiver

[ 14] 0.00-30.00 sec 324 MBytes 90.5 Mbits/sec 0 sender

[ 14] 0.00-30.00 sec 322 MBytes 90.2 Mbits/sec receiver

[ 16] 0.00-30.00 sec 314 MBytes 87.9 Mbits/sec 0 sender

[ 16] 0.00-30.00 sec 313 MBytes 87.6 Mbits/sec receiver

[ 18] 0.00-30.00 sec 311 MBytes 87.1 Mbits/sec 0 sender

[ 18] 0.00-30.00 sec 310 MBytes 86.8 Mbits/sec receiver

[SUM] 0.00-30.00 sec 2.46 GBytes 704 Mbits/sec 0 sender

[SUM] 0.00-30.00 sec 2.45 GBytes 701 Mbits/sec receiver





Как видно из результатов, overhead есть, но в данном случае можно считать его не критичным.



Ограничения технологии by design: доступность контейнера с хоста и доступность хоста из контейнера отсутствует. Нам такой функционал необходим, потому что:




  • часть проверок доступности сервиса проверяется «хелперами» Zabbix, которые выполняются на том хосте, где работает сервис;

  • есть необходимость использовать кеширующий DNS, который расположен на хост-системе. В нашем случае это Unbound;

  • бывает необходимость использовать доступ к еще каким-то сервисам, запущенным на хост-системе.

  • Это лишь часть причин, по которым доступ «хост <==> контейнер» нам необходим. Взять и переделать архитектуру подобных узлов в одночасье невозможно.



Варианты преодоления данного ограничения:




  1. Использовать два и более физических линка на машине. Это дает возможность взаимодействия через соседний интерфейс. Например, взять eth1 и отдать его специально для MACVLAN, а на хост-системе продолжать использовать eth0. Вариант, безусловно, неплохой, но это влечет за собой необходимость держать одинаковое количество линков на всех машинах, где мы планируем запускать подобные сервисы. Реализовать это дорого, не быстро и не всегда возможно.




  2. Использовать еще один дополнительный IP-адрес на хост-системе, повесить его на виртуальный MACVLAN-интерфейс, который нужно поднять на хост-системе. Это приблизительно так же сложно с точки зрения поддержки («не забыть/не забывать»), как предыдущее предложение — это раз. А, так как ранее я говорил о том, что наш сервис сам по себе требует дополнительного адреса, то в итоге для запуска такого сервиса нам потребуется:




    • адрес для основного интерфейса хост-системы (1);

    • адрес для сервиса (2);

    • адрес для виртуального интерфейса, через который мы будем взаимодействовать с сервисом (3).



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



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



    В предыдущих двух вариантах предполагалось, что адреса всех интерфейсов принадлежат одной сети. Как несложно представить, даже при 100 серверах в такой подсети, если завести по три адреса, то в /24 мы уже не попадаем.




  3. Сервисный IP. Суть идеи заключается в том, что мы делаем отдельную подсеть для сервисов. Как это выглядит:




    • на сервер начинаем подавать «тегированный» траффик;

    • native VLAN оставляем в виде основной сети для dockerhost (eth0);

    • поднимаем виртуальный интерфейс с 802q, без IP-адреса на хост системе;

    • используем для сервиса IP-адрес из сервисной сети.




Рассматривать, как уже стало понятно, будем пункт три. Чтобы все у нас заработало, нужно проделать несколько действий:




  • для того чтобы подать «тегированный» трафик на интерфейс, кто нам нужен? Правильно, сетевики! Просим их выполнить переключение access-порта в порт, на который подаем 2 VLAN;




  • поднять дополнительный интерфейс на хосте:



    # cat /etc/sysconfig/network/ifcfg-vlan8
    BOOTPROTO='static'
    STARTMODE='auto'
    VLAN='yes'
    ETHERDEVICE='eth0'

    # ip -d link show vlan8
    31: vlan8@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether e4:11:5b:ea:b6:30 brd ff:ff:ff:ff:ff:ff promiscuity 1
    vlan protocol 802.1Q id 8



  • завести MACVLAN-сеть в Docker




    # docker network create -d macvlan --subnet=1.1.2.0/24 --gateway=1.1.2.1 -o parent=vlan8 c_services



  • убедиться, что сеть в Docker появилась:




    # docker network ls | grep c_services
    a791089219e0 c_services macvlan



Все сделал, все хорошо. Тут я решил посмотреть на общие графики по хосту (а если быть точнее, то на это обратил мое внимание коллега). Вот такую картину мы там увидели:



image



Да, здесь видно использование conntrack на хосте.



Как так? Ну не нужен же conntrack для МACVLAN?! Так как дело было уже вечером, я решил проверить даже самые невероятные теории. В подтверждение моих теоретических знаний, connection tracking был на самом деле не нужен. Без него все продолжало работать. Выгрузка модулей, так или иначе завязанных на conntrack, была невозможной только в момент запуска моего контейнера. Идеи меня покинули, и пошел я домой, решив, что утро вечера мудренее.



На следующий день я в очередной раз убедился в точности данного высказывания. Итак, я решил «топорным» методом сделать так, чтобы Docker не мог подгружать nf_conntrack. Сначала я его просто переименовал (т.к. blacklist игнорируется при загрузке модуля через modprobe), после чего запустил свой контейнер снова. Контейнер, как и ожидалось, поднимался и отлично себя чувствовал, но в логе я увидел сообщения о том, что четыре правила не могут быть добавлены в iptables. Получается, что conntrack нужен? Вот правила, которые не хотели добавляться:




-t nat -A OUTPUT -d 127.0.0.11 -p udp --dport 53 -j DNAT --to-destination 127.0.0.11:35373
-t nat -A POSTROUTING -s 127.0.0.11 -p udp --sport 35373 -j SNAT --to-source :53
-t nat -A OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.11:41214
-t nat -A POSTROUTING -s 127.0.0.11 -p tcp --sport 41214 -j SNAT --to-source :53


53 порт? Налицо работа, связанная с «резолвером». И тут я, к своему удивлению, узнаю про embedded DNS server. Ну хорошо, пусть и встроенный, но можно же как-то опциями выключить его? Нет, нельзя :)



Далее я попробовал вернуть модуль, запустить сервис, поправить правила из iptables и выгрузить модули… Но не тут то было. Путем ковыряния modinfo я выяснил, какой там модуль от какого зависит, и какой из них кого тянет за собой. При создании сети Docker принудительно делает modprobe xt_nat, который, в свою очередь, зависит от nf_conntrack, вот тому подтверждение:




# modinfo xt_nat
filename: /lib/modules/4.4.0-3.1-default/kernel/net/netfilter/xt_nat.ko
alias: ip6t_DNAT
alias: ip6t_SNAT
alias: ipt_DNAT
alias: ipt_SNAT
author: Patrick McHardy <kaber@trash.net>
license: GPL
srcversion: 9982FF46CE7467C8F2361B5
depends: x_tables,nf_nat
intree: Y
vermagic: 4.4.0-3.1-default SMP preempt mod_unload modversions


Как я уже говорил, все работает и без этих модулей. Соответственно, мы можем сделать вывод, что в нашем случае они не нужны. Остается вопрос: зачем, все же, они нужны? Я не поленился и заглянул в 2 места:




  • на Docker issues;

  • в исходный код.



И что я там нашел? Верно: для любого user defined network Docker делает modprobe. Смотрим код и видим 2 интересных для нас пункта:



       if out, err := exec.Command("modprobe", "-va", "nf_nat").CombinedOutput(); err != nil {
logrus.Warnf("Running modprobe nf_nat failed with message: `%s`, error: %v", strings.TrimSpace(string(out)), err)
}
if out, err := exec.Command("modprobe", "-va", "xt_conntrack").CombinedOutput(); err != nil {
logrus.Warnf("Running modprobe xt_conntrack failed with message: `%s`, error: %v", strings.TrimSpace(string(out)), err)
}


И вот такое еще:



       if err := r.setupIPTable(); err != nil {
return fmt.Errorf("setting up IP table rules failed: %v", err)
}


Делаем патч, а точнее — выкидываем все ненужное :) Делаем новую сборку Docker.



Смотрим. Все ок, все работает.



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



image

Пояснения о том, как оно работает:




  • (1 и 6) мобильный клиент устанавливает соединение с неким урлом, за которым стоит балансировщик;

  • (2) балансировщик выбирает нужный инстанс нашего сервиса и позволяет установить соединение клиент-сервис;

  • (3 и 4) далее наш сервис проксирует запросы от клиента на кластер с кодом, но тоже через балансировщик в виде nginx. Вот тут мы и вернулись к нашему требованию о том, что nginx должен быть на той же машине, что и сервис. На данный момент также есть ограничение в том, что он должен быть именно на хосте, а не в контейнере (это, кстати, решило бы проблему сразу). Мы не будем в данной статье рассуждать о причинах этого требования, а примем это как условие.

  • (5) у каждого инстанса нашего сервиса есть определенный id, который нужен коду, чтобы понимать, через какой именно инстанс отвечать клиенту.



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



# ip r
default via 1.1.2.254 dev eth0
10.0.0.0/8 via 1.1.2.1 dev eth0
1.1.2.0/24 dev eth0 proto kernel scope link src 1.1.2.14
192.168.0.0/16 via 1.1.2.1 dev eth0


Т.е. все, что должно идти в или из наших внутренних сетей, идет через .1, а остальное — через .254.

Почему это проблема в нашем случае? Потому что при запуске контейнера в его маршрутах мы видим следующее:




# ip r
default via 1.1.2.1 dev eth0
1.1.2.0/24 dev eth0 proto kernel scope link src 1.1.2.14


Попытка поменять маршруты внутри контейнера ни к чему не приведет, т.к. он у нас не привилегированный (--priveleged). Остается менять маршруты руками после старта контейнера с хоста (тут кроется большое заблуждение, но про это — дальше). Здесь варианта два:




  • делать это руками, используя namespace контейнера;

  • взять pipework https://github.com/jpetazzo/pipework и сделать все то же самое, но с его помощью.



Скажу сразу, что с этим можно жить, но существуют опасности, как у студента: «можно забыть, забить или запить» :)



Стремясь к идеалу, мы сделали для этой сервисной сети все маршруты через default gw, а всю сложность маршрутизации переложили на сетевой отдел. Всё. Точнее, я думал, что всё…



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




  1. Сеть, у которой есть только 1 default gw и нет внешнего балансировщика.



    image



  2. Сеть, у которой более одного GW: например, балансировщик внешних запросов. Сложность в том, что внутренний трафик мы через него не гоняем.

    image



Поговорив с сетевиками, мы сделали следующие выводы:




  • они не готовы брать на себя ответственность и следить за всеми сетями, в которых роутинг будет именно таким;

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



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



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



Итак, вот те условия, которые гарантируют нам работу нашего сервиса в контейнере:




  • сам сервис;

  • выделенный IP для сервиса;

  • доступность сервиса и адреса со всех наших подсетей;

  • возможность использовать и менять маршруты при запуске контейнера (самое важное, потому что именно это можно забыть).



Запускать контейнеры в привилегированном режиме (--privileged) не хотелось и не хочется. Я изначально не подумал про Linux capabilities, которые можно добавлять и убирать при запуске контейнера. Подробнее про них можно почитать вот тут. Для нашей задачи было достаточно добавить NET_ADMIN.



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

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



Dockerfile:




FROM dockerio.badoo.com/itops/sle_12_base:latest
MAINTAINER #MAINTEINER#

RUN /usr/bin/zypper -q -n in iproute2
RUN groupadd -g 1001 wwwaccess

RUN mkdir -p /local/SERVICE/{var,conf}
COPY get_configs.sh /local/SERVICE/
COPY config.cfg /local/SERVICE/
ADD SERVICE-CERTS/ /local/SERVICE-CERTS/

ADD SERVICE/bin/SERVICE-BINARY-${DVERSION} /local/SERVICE/bin/
ADD SERVICE/conf/ /local/SERVICE/conf/

COPY routes.sh /etc/cont-init.d/00-routes.sh
COPY env.sh /etc/cont-init.d/01-env.sh
COPY finish.sh /etc/cont-finish.d/00-finish.sh
COPY run /etc/services.d/SERVICE/
COPY finish /etc/services.d/SERVICE/
RUN touch /tmp/fresh_container
ENTRYPOINT ["/init"]


На что тут стоит обратить внимание:




  • мы используем s6 overlay как supervisor внутри контейнера;

  • мы добавляем пакет iproute, чтобы можно было править маршруты;

  • мы добавляем запуск нескольких скриптов, которые выполняются ДО старта нашего сервиса (директория /etc/cont-init.d/), а также добавляем скрипты, которые будут выполнены ПОСЛЕ завершения работы сервиса, но ДО того, как опустится контейнер (/etc/cont-finish.d/);

  • мы добавляем файл /tmp/fresh_container для того, чтобы понимать, первый ли раз стартует наш контейнер или нет. Чуть яснее про это будет, когда я покажу содержимое остальных скриптов;



Используемые скрипты:




  1. get_configs.sh — это скрипт, который смотрит, есть ли конфиг для сервиса в нашей системе хранения и генерации конфигов, доставляет их в контейнер, проверяет на валидность, и если все в порядке, то с ним и запускает. Подробнее про это мы рассказывали на Docker Meetup;




  2. routes.sh — скрипт, который подготавливает маршруты внутри контейнера:




    #!/usr/bin/with-contenv sh
    if [ ! -x /usr/sbin/ip ];then
    echo -e "\e[31mCan't execute /usr/sbin/ip\e[0m";
    [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services
    exit 1;
    else
    LTMGW=$(/usr/sbin/ip r show | /usr/bin/grep default | /usr/bin/awk {'print $3'} | /usr/bin/awk -F \. {'print $1"."$2"."$3".254"'})
    DEFGW=$(/usr/sbin/ip r show | /usr/bin/grep default | /usr/bin/awk {'print $3'} | /usr/bin/awk -F \. {'print $1"."$2"."$3".1"'})
    /usr/sbin/ip r replace default via ${LTMGW}
    /usr/sbin/ip r add 192.168.0.0/16 via 10.10.8.1 dev eth0
    /usr/sbin/ip r add 10.0.0.0/8 via 10.10.8.1 dev eth0
    echo -e "\e[32mAll job with routes done:\e[0m\n$(/usr/sbin/ip r show)"
    fi



  3. env.sh — скрипт, который готовит окружение для нашего сервиса; зачастую именно он выполняется только 1 раз при первом старте контейнера:




    #!/usr/bin/with-contenv sh
    if [ ! -z "${ISTEST}" ];then exit 0;fi
    if [ ! -n "${SERVICETYPE}" ];then
    echo -e "\e[31mPlease set SERVICE type\e[0m";
    [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services
    exit 1;
    fi
    bash /local/SERVICE/get_configs.sh || exit 1
    echo -e "\e[32mSERVICE ${SERVICETYPE} is running\e[0m"



  4. finish.sh — скрипт, который просто чистит pid-файлы от нашего сервиса. Конкретный сервис настолько крут (как Чак Норрис), что сам этого не делает, но он не запустится, если обнаружит старые pid-файлы :)




  5. run — это скрипт, который запускает наше приложение:




    #!/usr/bin/with-contenv bash
    exec /local/SERVICE/bin/SERVICE-${DVERSION} -l /local/SERVICE/var/mobile-${SERVICETYPE}.log -P /local/SERVICE/var/mobile-${SERVICETYPE}.pid -c /local/SERVICE/conf/SERVICE.conf -v ${VERBOSITY}



  6. finish — скрипт, который тушит контейнер в случае, если сервис завершил свою работу:




    #!/bin/sh
    [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services





Строка для запуска нашего сервиса будет выглядеть так:




docker run -d --net=c_services --ip=1.1.2.17 --name=SERVICE-INSTANCE16 -h SERVICE-INSTANCE16.local --cap-add=NET_ADMIN --add-host='nginx.localhost:1.1.1.17' -e SERVICETYPE=INSTANCE16_eu1 -e HOST_IP=1.1.1.17 --volumes-from=badoo_loop dockerio.badoo.com/cteam/SERVICE:2.30.0_994


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



Антон banuchka Турецкий

Site Reliability Engineer, Badoo
Original source: habrahabr.ru.

https://habrahabr.ru/post/308402/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Аудит уязвимостей Linux c Vulners.com

Понедельник, 22 Августа 2016 г. 14:39 (ссылка)

Vulners задумывался как поисковик для Security Content-а: уязвимостей, бюллетеней безопасности, эксплоитов, плагинов детекта и прочей полезной информации. Но мы подумали: если у нас уже есть разобранные бюллетени безопасности для основных Linux-дистрибутивов, почему бы нам не сделать сервис, который будет брать данные о системе, а на выходе отдавать список уязвимостей. Также, как это делают привычные сканеры уязвимостей, только быстрее и бесплатно.







Откуда мы получаем информацию об уязвимостях Linux? Для этого мы парсим бюллетени вендоров. Покажем процедуру разбора на примере бюллетеня безопасности Debian DSA-3638.



Изначальная информация на странице вендора:



https://security-tracker.debian.org/tracker/DSA-3638-1







Мы видим, что уязвим source пакет curl на операционной системе версии jessie и уязвимость исправлена в пакете версии 7.38.0-4+deb8u4. Но этой информации не достаточно, чтобы правильно определить уязвимость. curl в данном случае является source-пакетом, то есть на его основе собираются бинарные пакеты. Поэтому нужно найти все бинарные пакеты, собранные из пакета curl:



packages.debian.org/source/jessie/curl





В итоге мы считаем, что уязвимость есть для всех перечисленных пакетов версии меньше 7.38.0-4+deb8u4



https://vulners.com/api/v3/search/id?id=DSA-3638


{
"result": "OK",
"data": {
"documents": {
"DSA-3638": {
"objectVersion": "1.0",
"modified": "2016-08-03T00:00:00",
"affectedPackage": [
{
"packageName": "libcurl3-nss",
"packageVersion": "7.38.0-4+deb8u4",
"packageFilename": "libcurl3-nss_7.38.0-4+deb8u4_all.deb",
"arch": "all",
"operator": "lt",
"OSVersion": "8",
"OS": "Debian GNU/Linux"
},
{
"packageName": "curl",
"packageVersion": "7.38.0-4+deb8u4",
"packageFilename": "curl_7.38.0-4+deb8u4_all.deb",
"arch": "all",
"operator": "lt",
"OSVersion": "8",
"OS": "Debian GNU/Linux"
...




Как работает Аудит? Сначала нам нужно собрать и отправить на сервер информацию о пакетах и ОС. Версия ос содержится в файлах /etc/os-release, /etc/centos-release и других файлах, специфичных для тех или иных операционных систем. В качестве источника информации об установленных пакетах для rpm-based систем достаточно стандартной команды rpm -qa. В случае deb-based системы нужен вывод команды посложнее — dpkg-query -W -f='${Package} ${Version} ${Architecture}\n'



В ответ сервер вернет нам информацию о найденных уязвимостях. Рассчет происходит очень быстро. Мы обрабатываем 750 пакетов за 160ms! Можно подумать, что на сервере происходит какая-то магия. Но это не так, все на самом деле очень просто и так работаю практически все сканеры уязвимостей.



Рассмотрим пакет — curl 7.38.0-4+deb8u3 amd64 для Debian Linux. Имя пакета curl. Мы ищем в системы все бюллетени, которые содержат это пакет среди списка уязвимых пакетов. После того, как все такие бюллетени найдены, нужно пройтись по каждому из них и проверить, выполняется ли хотя бы одно из условие из перечисленных в поле affectedPackage. Возьмем для примера пакет DSA-3638:




{
"OS": "Debian GNU/Linux",
"operator": "lt",
"packageFilename": "libcurl3-nss_7.38.0-4+deb8u4_all.deb",
"OSVersion": "8",
"packageVersion": "7.38.0-4+deb8u4",
"packageName": "libcurl3-nss",
"arch": "all"
}




Здесь указано, что уязвимость имеет место быть в случае, если:

— Операционная система — Debian GNU/Linux («OS»: «Debian GNU/Linux»)

— Версия этой операционной системы — 8 («OSVersion»: «8»)

— Установлен пакет с именем libcurl3-nss («packageName»: «libcurl3-nss»)

— Архитектура уязвимого пакета — любая

— И версия этого пакета меньше, чем 7.38.0-4+deb8u4 («operator»: «lt» и «packageVersion»: «7.38.0-4+deb8u4»)



Если все условия выполнились — пакет подвержен данной уязвимости DSA-3638. Для каждого пакета в системе мы проверяем все условия из бюллетеней и получаем список уязвимостей для системы. Как видите, какой-то сложности или магии в этом нет.



Важно отметить, ни в коем случае нельзя сравнивать версии как числа или строки. Для каждой из систем (debian, redhat, solaris) структура версий отличается. И соответственно отличается механика их сравнения. Для того, чтобы обеспечить достоверность сканирования, необходимо реализовывать сравнение версий ровно по тому же алгоритму, как он сделан в самой операционной системе. К счастью, какой-то тайны в этом нет, есть готовые примеры функций сравнения для того же debian.



На сегодняшний день мы готовы вам предложить веб-интерфейс, с помощью которого можно проверить свой сервер на уязвимости, полноценное API для автоматизации и PoС агента для нашего будущего облачного решения по управлению уязвимостями. Поддерживаются следующие дистрибутивы Linux: RedHat, CentOS, Fedora, Oracle Linux, Ubuntu, Debian.



Графический интерфейс доступен на вкладке Audit.







Найденные уязвимости:







Аналогично можно работать через Audit API. Задайте список установленных пакетов и версию ОС, а в ответ получите список уязвимостей и описание того почему мы считаем, что уязвимость действительно есть. Вы можете сравнить результаты с результатами своего сканера и попросите своего вендора объяснить расхождения. Ну или пните нас, что мы где-то накосячили ;-)




curl -H "Accept: application/json" -H "Content-Type: application/json" -X POST -d '{"os":"centos","package":["pcre-8.32-15.el7.x86_64", "samba-common-4.2.3-11.el7_2.noarch", "gnu-free-fonts-common-20120503-8.el7.noarch", "libreport-centos-2.1.11-32.el7.centos.x86_64", "libacl-2.2.51-12.el7.x86_64", "sos-3.2-35.el7.centos.noarch" ],"version":"7"}' https://vulners.com/api/v3/audit/audit/
{
"result": "OK",
"data": {
"reasons": [
{
"providedPackage": "sos-3.2-35.el7.centos.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0188",
"providedVersion": "0:3.2-35.el7.centos",
"bulletinPackage": "sos-3.2-35.el7.centos.3.noarch.rpm",
"bulletinVersion": "3.2-35.el7.centos.3",
"package": "sos-3.2-35.el7.centos.noarch"
},
{
"providedPackage": "pcre-8.32-15.el7.x86_64",
"operator": "lt",
"bulletinID": "CESA-2016:1025",
"providedVersion": "0:8.32-15.el7",
"bulletinPackage": "pcre-8.32-15.el7_2.1.x86_64.rpm",
"bulletinVersion": "8.32-15.el7_2.1",
"package": "pcre-8.32-15.el7.x86_64"
},
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:1486",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-7.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-7.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
},
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0612",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-6.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-6.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
},
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0448",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.3-12.el7_2.noarch.rpm",
"bulletinVersion": "4.2.3-12.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
],
"vulnerabilities": [
"CESA-2016:1486",
"CESA-2016:1025",
"CESA-2016:0448",
"CESA-2016:0612",
"CESA-2016:0188"
],
"cvelist": [
"CVE-2015-5370",
"CVE-2015-7560",
"CVE-2016-2119",
"CVE-2016-2118",
"CVE-2015-7529",
"CVE-2016-2112",
"CVE-2016-2113",
"CVE-2016-3191",
"CVE-2015-8386",
"CVE-2015-8388",
"CVE-2015-8385",
"CVE-2016-2110",
"CVE-2015-5073",
"CVE-2015-8391",
"CVE-2015-2328",
"CVE-2016-2115",
"CVE-2015-3217",
"CVE-2016-2114",
"CVE-2016-2111"
],
"cvss": {
"vector": "AV:NETWORK/AC:LOW/Au:NONE/C:PARTIAL/I:PARTIAL/A:COMPLETE/",
"score": 9.0
},
"packages": {
"pcre-8.32-15.el7.x86_64": {
"CESA-2016:1025": [
{
"providedPackage": "pcre-8.32-15.el7.x86_64",
"operator": "lt",
"bulletinID": "CESA-2016:1025",
"providedVersion": "0:8.32-15.el7",
"bulletinPackage": "pcre-8.32-15.el7_2.1.x86_64.rpm",
"bulletinVersion": "8.32-15.el7_2.1",
"package": "pcre-8.32-15.el7.x86_64"
}
]
},
"sos-3.2-35.el7.centos.noarch": {
"CESA-2016:0188": [
{
"providedPackage": "sos-3.2-35.el7.centos.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0188",
"providedVersion": "0:3.2-35.el7.centos",
"bulletinPackage": "sos-3.2-35.el7.centos.3.noarch.rpm",
"bulletinVersion": "3.2-35.el7.centos.3",
"package": "sos-3.2-35.el7.centos.noarch"
}
]
},
"samba-common-4.2.3-11.el7_2.noarch": {
"CESA-2016:1486": [
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:1486",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-7.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-7.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
],
"CESA-2016:0448": [
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0448",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.3-12.el7_2.noarch.rpm",
"bulletinVersion": "4.2.3-12.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
],
"CESA-2016:0612": [
{
"providedPackage": "samba-common-4.2.3-11.el7_2.noarch",
"operator": "lt",
"bulletinID": "CESA-2016:0612",
"providedVersion": "0:4.2.3-11.el7_2",
"bulletinPackage": "samba-common-4.2.10-6.el7_2.noarch.rpm",
"bulletinVersion": "4.2.10-6.el7_2",
"package": "samba-common-4.2.3-11.el7_2.noarch"
}
]
}
}
}




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




$ git clone https://github.com/videns/vulners-scanner
$ cd vulners-scanner
$ ./linuxScanner.py

_
__ ___ _| |_ __ ___ _ __ ___
\ \ / / | | | | '_ \ / _ \ '__/ __|
\ V /| |_| | | | | | __/ | \__ \
\_/ \__,_|_|_| |_|\___|_| |___/

==========================================
Host info - Host machine
OS Name - centos, OS Version - 7
Total found packages: 1026
Vulnerable packages:
krb5-libs-1.13.2-10.el7.x86_64
CESA-2016:0532 - 'Moderate krb5 Security Update', cvss.score - 6.8
openssh-server-6.6.1p1-23.el7_2.x86_64
CESA-2016:0465 - 'Moderate openssh Security Update', cvss.score - 7.7
libtdb-1.3.6-2.el7.x86_64
CESA-2016:0612 - 'Critical ipa Security Update', cvss.score - 0.0
kernel-tools-3.10.0-327.4.5.el7.x86_64
CESA-2016:1033 - 'Important kernel Security Update', cvss.score - 0.0
CESA-2016:1633 - 'Important kernel Security Update', cvss.score - 4.3
CESA-2016:0185 - 'Important kernel Security Update', cvss.score - 7.2
CESA-2016:1539 - 'Important kernel Security Update', cvss.score - 7.2
CESA-2016:1277 - 'Important kernel Security Update', cvss.score - 7.2
openssl-libs-1.0.1e-51.el7_2.2.x86_64
CESA-2016:0301 - 'Important openssl Security Update', cvss.score - 0.0
CESA-2016:0722 - 'Important openssl Security Update', cvss.score - 10.0
nss-softokn-3.16.2.3-13.el7_1.x86_64
CESA-2016:0685 - 'Moderate nss-softokn Security Update', cvss.score - 6.8
...




Как видите анализа защищенности Linux, можно делать эффективнее и быстрее и без дорогостоящих сканеров уязвимостей. Мы, конечно, рекомендуем Vulners. Но если вы не хотите отправлять ничего на наш сервер, например волнуетесь за приватность, ты вы можете реализовать данный функционал самостоятельно. Это сделать не сложно. Вам потрубется реализовать функцию сравнения, скачать у нас полный набор данных по операционной системы, например набор для CentOS, и обработать свои данные так, как мы показыли выше. Как делать сбор данных вы можете посмотреть в исходном коде нашего агента. Агент у нас открытый и мы были бы рады разивать его вместе с вами! Pull requests welcome! Ждем предложений и пожеланий!
Original source: habrahabr.ru.

https://habrahabr.ru/post/308236/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Жонглируем версиями PHP в системе

Понедельник, 22 Августа 2016 г. 10:41 (ссылка)

Проблема “ хочу новую версию %software% на моем стареньк… стабильном Debian/CentOS…” так же стара, как *nix-мир. Способов добиться желаемого хватает. Есть масса решений как притащить в систему несколько версий одного и того же софта. Но дальше хочется не просто иметь ещё одну версию, но и управлять тем, какая из версий доступна в системе по умолчанию, для конкретных приложений или пользователей.



Что делать, если хочется сменить системную версию PHP на одну из кастомных сборок? Давайте отталкиваться от того, что у вас на сервере уже установлено несколько версий PHP и вы хотите, чтобы в консоли команда php была конкретной версии, отличающаяся от той, что шла с системой. В этой статье я расскажу, как правильно это настроить, чтобы не было проблем с будущими пакетными обновлениями.





В качестве примера возьмём сервер на CentOS 7, где установлен родной PHP:



# php -v
PHP 5.4.16 (cli) (built: May 12 2016 13:45:17)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.0.12, Copyright (c) 2002-2015, by ionCube Ltd.


Также на сервере установлен наш Plesk с парой своих сборок PHP:



# rpm -qa | grep plesk-php.*-release
plesk-php56-release-5.6.22-centos7.16052711.x86_64
plesk-php70-release-7.0.7-centos7.16052710.x86_64


Допустим, мы хотим переключить систему на использование PHP 5.6 по умолчанию (переключать глобально PHP с версии 5.4 на 7 как-то сс… страшно — чему-то в системе может поплохеть от такого). Бинарь PHP 5.6 лежит у нас тут:



# /opt/plesk/php/5.6/bin/php -v
PHP 5.6.22 (cli) (built: May 27 2016 11:45:28)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.0.18, Copyright (c) 2002-2015, by ionCube Ltd.
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies


Как же сделать так, чтобы система использовала эту, нужную нам, версию PHP?



Сначала посмотрим на системную переменную PATH



# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin


В ней перечислен список директорий, в которых ищутся программы по имени. Главный нюанс — поиск в директориях происходит последовательно и используется первый найденный результат. Текущий путь до текущего бинарника PHP мы можем увидеть с помощью команды:



# which php
/usr/bin/php


Как видно из PATH, /usr/local/bin находится в списке раньше, чем /usr/bin. Значит, если мы поместим ссылку на альтернативную версию PHP “пораньше”, в /usr/local/bin, то именно она и будет использоваться при вызове команды php вместо /usr/bin/php. Мы можем создать эту ссылку руками (и всё даже будет работать), но правильнее использовать специально созданную для этих целей утилиту update-alternatives (в CentOS это просто alternatives, но есть симлинка update-alternatives, поэтому дальше будем оперировать именно этой командой, как универсальной для Debian/Ubuntu/CentOS/и т.д.).



Теперь, давайте зарегистрируем все доступные версии PHP с помощью этой команды:



# update-alternatives --install /usr/local/bin/php php /opt/plesk/php/5.6/bin/php 10
# update-alternatives --install /usr/local/bin/php php /opt/plesk/php/7.0/bin/php 20
# update-alternatives --install /usr/local/bin/php php /usr/bin/php 30


Цифры 10, 20 и 30 — это приоритет. Он работает для автоматического выбора, если администратор сам не выбрал конкретную версию. Самое большое число определяет выбор "по умолчанию".



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



# update-alternatives --list | grep php
php auto /usr/bin/php

# update-alternatives --display php
php - status is auto.
link currently points to /usr/bin/php
/opt/plesk/php/5.6/bin/php - priority 10
/opt/plesk/php/7.0/bin/php - priority 20
/usr/bin/php - priority 30
Current `best' version is /usr/bin/php.


Давайте разберемся, что же update-alternatives сделала для нас:



# which php
/usr/local/bin/php
# ls -l /usr/local/bin/php
lrwxrwxrwx. 1 root root 21 Jul 2 10:03 /usr/local/bin/php -> /etc/alternatives/php
# ls -l /etc/alternatives/php
lrwxrwxrwx. 1 root root 26 Jul 2 10:03 /etc/alternatives/php -> /usr/bin/php


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



# php -v
PHP 5.4.16 (cli) (built: May 12 2016 13:45:17)
...


То есть, мы успешно настроили группу PHP в update-alternatives, где по умолчанию в автоматическом режиме выбран системный PHP. Сейчас у нас есть возможность переключить команду PHP на любую другую версию..



Давайте переключимся на PHP версии 5.6, которая идет в поставке с Plesk'ом:



# update-alternatives --config php

There are 3 programs which provide 'php'.

Selection Command
-----------------------------------------------
1 /opt/plesk/php/5.6/bin/php
2 /opt/plesk/php/7.0/bin/php
*+ 3 /usr/bin/php

Enter to keep the current selection[+], or type selection number: 1


Проверяем, что переключение произошло:



# php -v
PHP 5.6.22 (cli) (built: May 27 2016 11:45:28)

# update-alternatives --display php
php - status is manual.
link currently points to /opt/plesk/php/5.6/bin/php


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



С помощью update-alternatives можно выбирать не только версию PHP, но и многие другие вещи, например разные версии phpunit или редактор по умолчанию в системе. Подход этот универсален для различных систем. Не изобретая своего велосипеда, используя существующие инструменты, вы можете быть уверенным, что не устроили для ваших коллег квеста “Ну почему оно так работает?!”. Настраивайте свою систему правильно.



P.S. Приглашаю пофлеймить про phpenv в комментарии :)


Original source: habrahabr.ru.

https://habrahabr.ru/post/306682/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Используем Secure Boot в Linux на всю катушку

Четверг, 18 Августа 2016 г. 13:00 (ссылка)





Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы, то есть защиту от буткитов и атак типа Evil Maid. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются.



Более подробно о Secure Boot можно узнать из цикла статей от CodeRush.





Чтобы Secure Boot обеспечивал безопасность, подписываемые приложения должны соблюдать некоторый «кодекс чести»: не иметь в себе лазеек для неограниченного доступа к системе и параметрам Secure Boot, а также требовать того же от загружаемых ими приложений. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению. Такую угрозу представляют загрузчик shim, подписываемый Microsoft, и загружаемый им GRUB.



Чтобы от этого защититься, мы установим Ubuntu с шифрованием всего диска на базе LUKS и LVM, защитим initramfs от изменений, объединив его с ядром в одно UEFI-приложение, и подпишем его собственными ключами.



Ограничения решений «из коробки»



Ubuntu, как и другие распространённые дистрибутивы, предлагает опцию шифрования всего диска с LVM во время установки. Дистрибутив в такой конфигурации без ошибок устанавливается на UEFI с активным Secure Boot.



Но Canonical в первую очередь заинтересована в работоспособности ОС на устройствах с включённым Secure Boot, а не в обеспечении безопасности за счёт него. Если вы хотите использовать Secure Boot как средство безопасности, то вы сами по себе.



Как Ubuntu реализует загрузку в Secure Boot с шифрованием всего диска и что с этим не так?



Red Hat разработали загрузчик shim, чтобы он работал на всех устройствах и служил на благо человечеству, соблюдая строгие предписания стандарта Secure Boot и загружая только доверенные UEFI-приложения. Canonical использует shim как прокси, встраивая в него свой публичный ключ и подписывая у Microsoft. Shim загружает GRUB, подписанный ключём Canonical, который затем загружает ядро, подписанное Canonical.




  • Начнём с того, что шифруется не весь диск — /boot остаётся незашифрованным, а значит и initramfs в нём. Доступ к initramfs означает root-доступ. Fail.




  • /boot остаётся незашифрованным, потому что устанавливаемый по умолчанию GRUB не может расшифровать диск без криптографических модулей. Которые почему-то не встроили в подписанный GRUB. GRUB'у запрещено загружать дополнительные модули в Secure Boot. Double Fail1.




  • GRUB должен верифицировать загружаемые ядра и отвергать неверно подписанные. Он этого не делает. Triple Fail.




  • GRUB загружает свои настройки из файла и по умолчанию предоставляет доступ к консоли. Подлинность конфигурационного файла не проверяется, с помощью его модификации или через консоль можно сделать что угодно: загрузить UEFI Shell, другое ядро, initramfs или передать аргументы ядру и получить root-доступ. Fatal Error2.



Что это всё означает?



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







Согласно политике Microsoft о подписывании UEFI-приложений, все подписанные загрузчики GRUB и shim, используемые для загрузки GRUB, уже должны быть занесены в чёрный список.



Говорите, нужно просто отключить загрузку с внешних устройств? Это борьба с симптомами. Если у вас установлен незащищённый GRUB, то вас это не спасёт. Если на вашем устройстве стоит Windows, то вы можете выбрать из неё устройство для загрузки, и есть вероятность, что ваша прошивка это позволит4. Ещё остаётся PXE Network Boot. Поможет только пароль на включение устройства.



Вывод


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



Установка Ubuntu с шифрованием всего диска с помощью LUKS и LVM



LUKS — Linux Unified Key Setup — обёртка для криптографической системы dm-crypt, позволяющая создавать виртуальные зашифрованные устройства в файлах и на физических дисках. С помощью LUKS можно зашифровать данные на всём диске для того, чтобы перед загрузкой ОС требовалось ввести пароль.



LVM — Logical Volume Manager — менеджер логических томов, с помощью которого мы разделим криптоконтейнер на тома. Тома LVM автоматически монтируются после ввода пароля к криптоконтейнеру, отдельный ввод пароля для каждого тома не требуется.



Следующие инструкции должны быть применимы к любому дистрибутиву на базе Ubuntu, для других потребуются коррективы. Сперва загрузитесь с Live CD или установочного образа в режиме Try before installing.



Разметка и шифрование



Чтобы загружаться с диска в режиме UEFI, он должен быть размечен в формате GPT. Разметку диска рассмотрим с помощью KDE Partition Manager и GParted. Если у вас их нет, установите один, соответствующий вашей среде.



sudo apt-get install partitionmanager   # KDE
sudo apt-get install gparted # GNOME и другие


Запустите редактор разделов и выберите интересующий вас диск, обычно это первый в системе — /dev/sda. Посмотрите свойства диска.



KDE Partition Manager: Два раза кликните по диску,
GParted: View -> Device Information.


В строке Partition table указана используемая таблица разделов. Если диск размечен в формате dos/msdos (MBR), то его необходимо преобразовать в GPT. Это возможно сделать без потери данных, но здесь я этого описывать не буду, поищите инструкции в интернете. Если на диске нет важных данных и вы хотите форматировать его в GPT, создайте новую таблицу.



KDE Partition Manager: New Partition Table — GPT
GParted: Device -> Create Partition Table — gpt


На диске должен быть как минимум один раздел ESP (EFI System Partition), в котором будут храниться загрузчики. Если на этом диске установлена ОС в режиме UEFI, то один такой раздел уже есть. В любом случае я рекомендую создать новый размером не меньше 100 МБ. ESP должен быть отформатирован в один из FAT-форматов, предпочтительно в FAT32, а также помечен как загрузочный.



KDE Partition Manager: Кликнуть по неразмеченной области -> New
File system: fat32
Size: 128.00 MiB
Free space before: 0.00 — место после таблицы GPT
OK, Apply
Выбрать созданный раздел и открыть свойства (Properties), выставить флаг boot
OK, Apply

GParted: Кликнуть по неразмеченной области -> New
File system: fat32
New size: 128 MiB
Free space preceding: 1 MiB или больше — место под таблицу GPT
Add, Apply
Выбрать созданный раздел и открыть управление флагами (Manage Flags), выставить флаг boot
Close


Дальше нужно создать раздел для шифрования. Тем же образом, что и ESP, только без форматирования (unformatted), выставления флагов и размером побольше — так, чтобы вместил систему и раздел подкачки. Создадим в этом разделе криптоконтейнер LUKS через терминал, предварительно перейдя в режим суперпользователя.



sudo -i


Отформатируем раздел с указанием современных алгоритмов шифрования и хеширования. В режиме XTS длину ключа необходимо указывать в два раза больше, поэтому для AES-256 нужно указать ключ длиной 512 бит. Параметр --iter-time задаёт время в миллисекундах, затрачиваемое на генерацию ключа из вводимого пароля функцией PBKDF2. Большее количество итераций усложняет перебор пароля, но и увеличивает время ожидания после ввода верного пароля.



cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 2000 /dev/sda2


Подтвердите форматирование, написав YES, введите пароль. Теперь откройте криптоконтейнер (sda2_crypt — имя для маппинга) и введите тот же пароль.



cryptsetup luksOpen /dev/sda2 sda2_crypt


Контейнер должен стать доступным как блочное устройство /dev/mapper/sda2_crypt. Перейдём к разметке логических томов внутри криптоконтейнера. Инициализируем физический раздел LVM поверх /dev/mapper/sda2_crypt.



pvcreate /dev/mapper/sda2_crypt


Внутри этого физического раздела создадим группу томов с именем ubuntu.



vgcreate ubuntu /dev/mapper/sda2_crypt


Теперь мы можем создавать логические тома внутри этой группы. Первым делом создадим том для раздела подкачки и инициализируем его. Рекомендуемый размер — от sqrt(RAM) до 2xRAM в гигабайтах.



lvcreate -n swap -L 4G ubuntu # создать логический том с меткой swap размером 4 ГБ в группе ubuntu
mkswap /dev/ubuntu/swap


Добавим том для корня и создадим в нём файловую систему ext4. Хорошей практикой считается оставлять свободное место и расширять тома по мере необходимости, поэтому выделим для корня 20 ГБ. По желанию в свободном месте можно будет разметить дополнительные тома для home, usr, var и так далее. Выделить всё свободное место для тома можно с помощью параметра -l 100%FREE.



lvcreate -n root -L 20G ubuntu
mkfs.ext4 /dev/ubuntu/root


С разметкой закончено, можно перейти к установке.



Установка



Так как мы планируем создать загрузчик самостоятельно, да и установщик Ubuntu не поддерживает шифрование /boot, запустим установку без создания загрузчика.



ubiquity -b


На этапе разметки диска выберите Вручную.



Здесь нам необходимо указать точки монтирования. Выберите /dev/mapper/ubuntu-root, укажите использование в качестве журналируемой файловой системы Ext4, точку монтирования (Mount Point) в /, без форматирования. Ubiquity сама подхватит /dev/mapper/ubuntu-swap как раздел подкачки и запомнит один из системных разделов EFI. Экран разметки должен выглядеть так:







Закончите установку и не перезагружайтесь.



Настройка crypttab, fstab и resume



Смонтируйте корень установленной системы в /mnt, свяжите /dev, /sys и /proc с /mnt/dev, /mnt/sys и /mnt/proc соответственно, а также /etc/resolv.conf с /mnt/etc/resolv.conf, чтобы у вас был доступ к сети. Теперь смените корневой каталог с помощью chroot.



mount /dev/ubuntu/root /mnt
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /etc/resolv.conf /mnt/etc/resolv.conf
chroot /mnt


Вам необходимо вручную заполнить /etc/crypttab — файл, описывающий монтируемые при загрузке криптоконтейнеры.



nano /etc/crypttab


В него нужно добавить запись о /dev/sda2, монтируемом в /dev/mapper/sda2_crypt. Настроим монтирование по UUID, а не по имени устройства. Чтобы узнать UUID /dev/sda2, откройте другой терминал и воспользуйтесь командой:



sudo blkid


В строке, начинающейся с /dev/sda2, будет записан его UUID. Скопируйте его (Ctrl+Shift+C). В /etc/crypttab добавьте запись вида имя_маппинга UUID= none luks, вставив UUID (Ctrl+Shift+V). Закройте nano, нажав Ctrl+X и Y, подтвердив сохранение.







Проверьте, чтобы в /etc/fstab были правильно описаны монтируемые разделы, а в /etc/initrmfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.







После всех изменений обновите образ initramfs.



update-initramfs -u


Не выходите из системы и chroot,



Создание загрузчика



Ядро Linux поддерживает загрузку напрямую из UEFI, если оно было скомпилировано с параметром CONFIG_EFI_STUB. В таком случае initramfs обычно хранится рядом в ESP, и путь к нему передаётся в аргументах к ядру.



Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.



Процесс компиляции ядра достаточно длительный, её придётся производить после каждого изменения initramfs. К счастью, есть другой способ. В пакете systemd (ранее в gummiboot) находится linuxx64.efi.stub — заготовка UEFI-приложения, в которую можно встроить ядро, initramfs и аргументы, передаваемые ядру. Подписав это UEFI-приложение, мы защитим ядро и initramfs от изменений.



Для данной операции потребуется пакет binutils.



sudo apt-get install binutils


Запишем в /tmp/cmdline аргументы, которые будут передаваться ядру.



echo -n "quite splash" > /tmp/cmdline


В /boot хранятся образы ядра (vmlinuz-*-generic) и initramfs (initrd.img-*-generic). Определите последнюю версию и встройте их в заготовку.



objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub ubuntu.efi


Полученное UEFI-приложение ubuntu.efi необходимо расположить в ESP в каталоге *FI/BOOT/. Установщик Ubuntu должен был определить ESP и настроить монтирование в /boot/efi. Если в этом ESP нет других загрузчиков, то ubuntu.efi можно скопировать в /boot/efi/EFI/BOOT/BOOTX64.EFI, тогда он будет загружаться при выборе этого раздела в меню загрузки UEFI.



mkdir -p /boot/efi/EFI/BOOT
cp ubuntu.efi /boot/efi/EFI/BOOT/BOOTX64.EFI


Если в ESP уже записан загрузчик BOOTX64.EFI, то можно создать ещё один ESP, либо записать ubuntu.efi под другим именем и добавить соответствующую загрузочную запись через встроенную в вашу прошивку консоль UEFI (UEFI Shell). Использование efibootmgr не рекомендовано5.



Если у вас включён Secure Boot, то загрузиться с ubuntu.efi не получится, так как он не подписан. Временно отключите Secure Boot и загрузитесь, либо продолжите из chroot.



Настройка Secure Boot



Генерацию ключей, их установку в прошивку и подписывание UEFI-приложений описал CodeRush здесь, поэтому я буду считать, что вы всё понимаете и умеете.



Остаётся только подписать созданный нами загрузчик.



sbsign --key ISK.key --cert ISK.pem --output BOOTX64.EFI ubuntu.efi


Поместите BOOTX64.EFI в каталог EFI/BOOT/ раздела EFI, с которого вы планируете загружаться.



Автоматизация



Чтобы загрузчик автоматически обновлялся и подписывался при обновлении initramfs, создайте скрипт update-efi-loader в /etc/initramfs/post-update.d/, изменив пути где требуется.



echo -n "quiet splash" > /tmp/cmdline

objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-$(uname -r) --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-$(uname -r) --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/ubuntu.efi

sbsign --key /root/keys/ISK.key --cert /root/keys/ISK.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/ubuntu.efi


Дайте скрипту право на исполнение.



chmod a+x /etc/initramfs/post-update.d/update-efi-loader


При обновлении ядра придётся произвести эту операцию вручную.



Подписывание драйверов и модулей ядра



Если вам нужно установить сторонние или собственные драйвера и модули ядра, их необходимо подписать. Для подписи модулей ядра требуются сертификат в формате DER и ключ без пароля, то есть сгенерированный с параметром -nodes.



openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
-subj "/CN=Kernel Key" -outform DER -out kernel.der \
-keyout kernel.key


Для подписывания используется скрипт sign-file.



/usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 kernel.key kernel.der module.ko


Чтобы добавить этот сертификат в прошивку, его необходимо преобразовать в формат PEM, затем в ESL и подписать ключом KEK.



openssl x509 -inform der -in kernel.der -outform pem -out kernel.pem
cert-to-efi-sig-list -g "$(uuidgen)" kernel.pem kernel.esl
sign-efi-sig-list -k KEK.key -c KEK.pem kernel kernel.esl kernel.auth


Очевидные советы



Если вашей задачей стоит защита данных на устройстве, то Secure Boot выполнит свою работу и не больше. Остальное возлагается на вас.




  • Не добавляйте чужих ключей в прошивку. Даже от Microsoft. В первую очередь от Microsoft.




  • Не подписывайте UEFI Shell, KeyTool или другие приложения, имеющие доступ к записи в NVRAM. Используйте их в Setup Mode.




  • Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров.




  • Установите пароль на UEFI Setup не проще, чем от вашего криптоконтейнера.




  • При физическом доступе к внутренностям устройства можно отключить Secure Boot, сбросив память NVRAM или повредив её, а также оставить хардварную закладку. Такая атака успешна только тогда, когда она незаметна. Сделайте так, чтобы вы о ней могли узнать: заклейте винты на корпусе трудновоспроизводимыми стикерами, обмажьте их лаком с блёстками. Опечатайте своё устройство.




  • Поставьте первым в списке загрузки неподписанное приложение. Если вы однажды не увидите сообщение от Secure Boot, то ваше устройство однозначно скомпрометировано.




  • Надёжнее отключённого от интернета устройства, хранимого в сейфе, всё равно ничего не придумаешь. Уязвимости в реализации Secure Boot в конкретных прошивках не исключены.



Бонус: возвращение гибернации



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



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







Это верно в том случае, если initramfs не верифицируется и/или раздел подкачки не зашифрован. Однако независимо от использования гибернации при таких условиях initramfs может быть подменён, а чувствительные данные восстановлены из раздела подкачки. В нашей конфигурации initramfs верифицируется, будучи включённым в подписанный загрузочный файл, а раздел подкачки зашифрован. Значит, данное ограничение для нас бессмысленно.



Chung-Yi Lee ещё в 2013 предложил верифицировать образ восстановления, а в 2015 представил реализующий его идею патч. Но воз и ныне там. Поэтому предположим, что мы достаточно защищены с нашим шифрованием, и вернём нам гибернацию без верификации.



Способ 1. Отключить верификацию модулей ядра



Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.



Большого ущерба безопасности это нанести не должно. Модули ядра устанавливаются из доверенного источника вместе с обновлением ядра и хранятся на зашифрованном диске и в верифицируемом initramfs. Сторонние драйвера устанавливаются вручную, и будут они подписаны нами или нет, значения не имеет, ведь мы им уже доверяем. SecureApt для ядра и TLS/HTTPS для сторонних драйверов должны защитить от MiTM, и тогда остаётся только root-доступ к расшифрованному диску. Но в таком случае у злоумышленника уже есть наши данные.



«Оставить заявку» на отключение верификации модулей можно с помощью mokutil, а подтвердит её загрузчик shim.



sudo apt-get install mokutil shim
sudo mokutil --disable-validation


Введите пароль, который затем потребуется посимвольно подтвердить. Теперь нужно загрузиться через shim и выбрать в нём Change Secure Boot state (sic!). Поместите /usr/lib/shim.efi в EFI/BOOT/BOOTX64.EFI на одном из ESP или добавьте загрузочную запись через UEFI Shell. Предварительно отключите Secure Boot, после верните обратно.





Сейчас Secure Boot и гибернация работают, UEFI-приложения верифицируются, но модули ядра нет.



В принципе, shim и mokutil больше не требуются, их можно удалить.





Способ 2. Использовать старую версию ядра



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



Способ 3. Скомпилировать своё ядро



Если ваше время ничего не стоит, то вы можете скомпилировать своё ядро без этого ограничения. Гарантий, что после долгих мучений вы будете довольны результатом, нет. Но если вы этого очень хотите, хвала Линусу Торвальдсу и GPLv2, у вас есть на это право. Вы можете предварительно протестировать скомпилированное мною ядро, чтобы не тратить зря время.



Инструкции

Получение исходного кода



apt-get


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



В /etc/apt/sources.list должны присутствовать указатели на репозитории исходных кодов. Обычно там уже есть закомменти­рованные записи с deb-src. Раскомментируйте их для репозиториев xenial main и xenial-security main, либо добавьте сами, а затем обновите индекс apt.



$ sudo nano /etc/apt/sources.list
...
deb-src http://ru.archive.ubuntu.com/ubuntu/ xenial main restricted
deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
...
$ apt-get update


Загрузите исходный код и перейдите в создавшуюся директорию.



apt-get source linux-image-$(uname -r)
cd linux-4.4.0


Обратите внимание на то, чтобы apt скачивал актуальную версию исходного кода. Проверьте номер версии у файла .dsc.



linux_4.4.0-34.53.dsc


git


Если вы хотите поддерживать ядро в актуальном состоянии и перекомпилировать его по мере выхода обновлений с сохранением своих изменений, выберите git. Первоначальная загрузка займёт продолжительное время.



Установите git.



sudo apt-get install git


Создайте локальную копию git-репозитория ядра текущего релиза Ubuntu и перейдите в создавшуюся директорию.



git clone git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
cd ubuntu-xenial


По умолчанию git указывает на ветку master, соответствующую версии последнего релиза. Переключиться на другую версию можно по тегу релиза этой версии. Чтобы перечислить все теги по заданной маске, используйте git tag -l <маска>.



$ git tag -l Ubuntu-*
...
Ubuntu-4.4.0-33.52
Ubuntu-4.4.0-34.53
Ubuntu-4.4.0-35.54
...


Создайте ветку temp для тега, соответствующего вашей версии, и переключитесь на неё.



git checkout -b temp Ubuntu-4.4.0-34.53


Настройка



Загрузите пакеты, требуемые для компиляции (build dependencies).



sudo apt-get build-dep
sudo apt-get ccache fakeroot kernel-package libncurses5-dev


Убедитесь, что скриптам выставлено право на исполнение, запустите чистку.



chmod a+x debian/rules
chmod a+x debian/scripts/*
chmod a+x debian/scripts/misc/*
fakeroot debian/rules clean


Скопируйте старый файл конфигурации в текущую директорию, запустите конфигурацию, выберите Load и загрузите config. Больше изменять ничего не требуется, выйдите и сохраните конфигурацию — Exit -> Yes.



cp /boot/config-4.4.0-34-generic config
fakeroot debian/rules editconfigs


Измените файл kernel/power/hibernate.c, убрав проверку secure_modules().



--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -67,7 +67,7 @@ static const struct platform_hibernation_ops *hibernation_ops;

bool hibernation_available(void)
{
- return ((nohibernate == 0) && !secure_modules());
+ return (nohibernate == 0);
}

/**
--


Если вы используете git

Подготовьте файл к коммиту.



git add kernel/power/hibernate.c


Если вы ещё не совершали коммитов и не вводили свои данные, сделайте это сейчас.



git config --global user.email "you@example.com"
git config --global user.name "Your Name"


Сделайте коммит, введите комментарий.



$ git commit
...
Allow hibernation on Secure Boot


Теперь ваши изменения сохранены в новом снимке состояния (snapshot). Если вы захотите обновиться до следующей версии и применить к ней те же самые изменения, используйте git rebase <ветка или тег>



$ git rebase Ubuntu-4.4.0-35.54
Сначала перематываем указатель текущего коммита, чтобы применить ваши изменения поверх него…
Применение: Allow hibernation on Secure Boot


Скрипты компиляции определяют версию ядра по последней записи в истории изменений (changelog) в директории debian.master. Добавьте новую запись, чтобы изменить версию.



EDITOR=nano debchange -c debian.master/changelog -l "custom"


К версии будет добавлен суффикс custom1, что отразится при сборке пакетов .deb и позволит установить их при уже установленных пакетах той же версии без суффикса. Однако этот суффикс распространяется только на имя пакета, но не на его содержимое: ядро и директория с его модулями будут иметь ту же версию 4.4.0-34-generic, и при установке старые файлы перезапишутся новыми. Чтобы этого избежать, измените версию ABI c 34 на, например, 3400.



linux (4.4.0-3400.53custom1) UNRELEASED; urgency=medium

* Allow hibernation on Secure Boot
...


Компиляция



Запустите чистку ещё раз и скомпилируйте ядро. Если вы не опытный разработчик ядра и не понимаете, как работают проверки ABI и модулей (я вот не понимаю), отключите их (skipabi=true, skipmodule=true), иначе ваша компиляция сломается на одном из последних этапов. Здесь используется многопоточная сборка пакетов с количеством потоков, равным количеству ядер процессора. Цель binary-generic означает компиляцию обычной разновидности ядра, архитектура определяется автоматически.



fakeroot debian/rules clean
skipabi=true skipmodule=true DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN) do_tools=false no_dumpfile=1 \
fakeroot debian\rules binary-generic


Если компиляция прошла успешно, то в вашей домашней директории появятся три пакета .deb. Необходимо установить linux-image-.deb, а также желательно linux-image-extra-.deb. Это можно сделать с помощью dpkg -i <путь к пакету> или через QApt, открыв пакет в файловом менеджере, если он это поддерживает. Будьте осторожны: если вы не изменяли версию ABI, то старое ядро и модули перезапишутся.



Снова соберите загрузочный файл.



echo -n "quiet splash" > /tmp/cmdline

objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/test.efi

sbsign --key /root/keys/my.key --cert /root/keys/my.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/test.efi




Гибернация работает, но нестабильно. Как, впрочем, и без Secure Boot.





Способ 4. Отказ от гибернации и использование виртуализации



Если гибернация и работает, то это не делает её надёжным средством сохранения состояния. Это может быть проблемой моего железа, дистрибутива или, что более вероятно, KDE Plasma, но у меня Kubuntu просыпается через раз.



По уже описанной технологии в качестве хостовой ОС можно установить подходящий дистрибутив Linux, а гостевой — предпочитаемую для работы. При завершении работы автоматически останавливать виртуальную машину с сохранением состояния, а затем отключать устройство. При включении же восстанавливать состояние. Если ваше устройство поддерживает аппаратную виртуализацию, то для этого подойдёт Qemu KVM. Но это уже тема для отдельной статьи.



С большей надёжностью придёт и большая защищённость: чувствительные данные можно изолировать от опасной среды. Браузер и песочница для установки стороннних пакетов в одной виртуальной машине, важные персональные данные — в другой. Украсть мастер-ключ от зашифрованного диска в памяти хостовой ОС из гостевой гораздо сложнее. Кажется, для подобного существует Qubes OS. Но она данный момент не поддерживает Secure Boot. Fail.



На этом всё, приветствуются любые дополнения и замечания.



Примечания




  1. ^Решаемо путём сборки образа GRUB с нужными модулями с помощью grub-mkstandalone, но его придётся подписывать самому.




  2. ^Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.




  3. ^А он есть у всех кроме параноиковоправданно озабоченных своей безопасностью пользователей.




  4. ^У меня загрузиться с USB не даёт. Windows 8 и 10 также без пароля не пускают в безопасный режим или консоль.




  5. ^Говорят, некоторые прошивки он окирпичивает. Безопаснее создать по ESP на каждый загрузчик.


Original source: habrahabr.ru.

https://habrahabr.ru/post/308032/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как починить «сломанный» VPS сервер на Linux

Четверг, 18 Августа 2016 г. 11:36 (ссылка)





Мы в компании Ruvds запустили на нашем хостинге создание серверов с операционными системами Centos, Debian и Ubuntu Server!

Поэтому, мы объявляем конкурс «Как починить „сломанный“ VPS сервер на Linux». Попробуйте ваши силы в конкурсе, ведь в прошлый раз победитель справился за 3 часа. На этот раз мы немного усложнили задачу.



Условия конкурса

Нужно настроить веб-сервер nginx таким образом, чтобы при обращении на адрес http://your_vps_ip отображался сайт подготовленный для этих целей.



Важно

Файлы этого сайта сейчас размещены в директории: /home/administrator/contest_files.

Их нужно переместить на отдельный раздел размером 1gb или более (файловая система xfs), созданный путем уменьшения текущего раздела /dev/sda3



Что делать запрещено


  • использовать загрузку OS по сети

  • загружать на сервер новые файлы, которые не использовались при установке текущей версии ОС или не находились на сервере

  • нельзя устанавливать пакеты, которые не были установлены до этого

  • нельзя отключать файрвол

  • нельзя уменьшать размер других разделов (/dev/sda1, /dev/sda2)

  • нельзя повреждать файловую систему

  • использовать сервер для каких-либо других целей





Как начать

Отправить заявку на support@ruvds.com с пометкой «Конкурс для Linux»



Когда задача считается выполненной

Cайт доступен по адресу http://your_vps_ip, а вы предоставили детальный отчет о ваших действиях, которые позволили решить задачу.



Итоги конкурса и наш вариант решения задачи: 22 августа 2016



Призовой фонд конкурса

Первое место: VDS сервер, CPU 5x2.6ГГц, RAM 5 ГБ, Disk SSD 50 ГБ один год бесплатного пользования, диплом победителя, фирменная кружка от RUVDS.

Второе место: Скидка 70%, фирменная кружка от RUVDS

Третье место: Скидка 50%, фирменная кружка от RUVDS

Четвертое место: Скидка 30%, фирменная кружка от RUVDS
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307976/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<linux - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda