Ага, «безопасность обратно пропорциональна удобству». Всё это может произойти, когда все установлено, как у нас сейчас — на одном сервере. Когда ftp — немного больше, чем доступ к своей папочке и код правиться на живом сервере. Т.е. тест, девелопмент, продакшен, — эдакий continious integration, — по-хардкору.
В статье есть только на уровне доп.ссылок материалы о логировании iptables и прочем. О мониторинге — нужно писать отдельную статью. Вот чесслово, был бы материал/книга, которая назывался бы «Безопасность сервера. Регламенты и рецепты управления» — сел бы и перевел.
Если к первому вашему комменту вернуться, то вот что я скажу
Честно говоря не вижу никаких преимуществ перед тем же apparmor + нормальное распределение прав + iptables
Не могу ответить, т.к. настройка AppArmor/SElinux для меня начинается и заканчивается одной командой конфига:
В чем же преимущество над AppArmor/SElinux у нашей виртуализации? Могу ответить лишь о части перечисленного в тексте: Масштабируемость/Оптимизация/Простота мониторинга. «Безопасность» и «Простота использования» немного не ясны для меня, но что-то уже начинает проясняться.
Вижу минус в неэффективности использования памяти, размазанному файловому кешу и большей нагрузке на процы (да и на диск тоже).
Честно говоря, сейчас я вижу общую нагрузку всех проектов, общее потребляемое ими количество памяти, общую нагрузку и общие ошибки. Мне легче и проще выстроить с ноля сервер и его стек, чем оставить инструкцию для будущих поколений, что и почему у нас так странно работает и выглядит, и оптимизировать каждый новый сайт/приложение на сервере в поисках причин сжираемой памяти и дисковой нагрузки. После такой настройки можно брать специалиста по конкретному узкому кругу вопросов и, не передавая ему рутовые пароли, давать настраивать и оптимизировать «от и до» на отдельной секьюрно-огороженной виртуальной машине
Когда я ломаю сайт в вашей схеме, я автоматически получаю доступ к БД как минимум под учёткой для работы с сайтом (ибо в конфигах сайта эти данные есть), к рассылке почты и мемкешу. То есть я спокойно смогу сделать фишинговый сайт и/или разослать спам или поддосить кого-нибудь. То же самое я смогу сделать и на обычном хостинге, где все службы на одном физическом компе
Вот когда вы будете ломать проксирующий сервер или бэкенд статики и скриптовый бэкенд, которые доступны только для этого самого проксирующего сервера по локалке, то наверно речь идет о сплойтах, SQLInjection, XSS и прочем, у меня будут оганиченные права к БД (чуть ли не SELECT-only), а CMS будут под версионным контролем и всякие робкие вздрагивания будут логироваться и мониторится системой уведомления… Т.е. тут комплекс мер нужен, а не просто виртуалки. Это ясно. А в какой схеме вам будет тяжело получить доступ к БД/мэмкешеду?
192.168.1.13 - сам сервер БД
192.168.1.10 - LightHTTPD/Nginx под статику
192.168.1.11 - бэкенд Apache+php+...
В iptables забит доступ к машине с БД
-A INPUT -m state --state NEW -s 192.168.1.10 -m tcp -p tcp --dport 3306 -j ACCEPT
-A INPUT -m state --state NEW -s 192.168.1.11 -m tcp -p tcp --dport 3306 -j ACCEPT
1. В самих конфигах приложения (допустим установлен WPress) порт/логин/пароль будут фигурировать явным образом. Т.е. не понятно, от кого/чего мы защитимся, перевесив порты. Я вот пока не понимаю, зачем серверу статики доступ к БД, но это видимо станет ясно по ходу перевода. Ну или вернемся сюда позднее и внесем дополнительные примечания. Ваш коммент будет свидетелем. ;)
Логирование — предложение более чем интересное. Я бы добавил к ссылке в статье об iptables, предложенной авторами оригинального материала, свой перевод. Как вам? Замечания/предложения?
2. По поводу минимальных прав. Если пользователь foo — админ, то может быть пусть будут у него эти права? Он у нас удаленно может зайти только через phpMyAdmin на фронт/бэкэнд серверах апача и Nginx.
Можно внести это в примечание к статье и дать ссылку или перевод на доп.статьи о правах. Авторы оригинального перевода тупо отослали к доками MySQL. А на хабре по этой теме ничего нет, вроде бы. Или я не нашел. Может вы какой-то материал/ссылку на эту тему видели? Или из перечисленного что-то хотелось бы иметь в переводном виде?
А тут одна БД с одним пользователем. Просто этот пользователь будет прописан в конфигах, а у него права нераеально избыточные. Надеюсь дальше задумка автора как-то себя обнаружит. У нас ведь с БД собирается общаться не фронт-энд. Может есть тут какая-то логика, хоть и не очень ясная.
Александр, не надрывайтесь за зря. Все же был тут некоторый момент не очень с умом обыгранный, чего уж теперь щеки дуть. Приоритет в статье, ударение не туда поставили и не так подали. По тому основное сообщение стало второстепенным, а второстепенное — основным. При всем том количестве тронутых, здесь еще толпы здоровых людей и то, что они ничего интересного не увидели для себя — не их вина. Да и местные евреи подкачали. Какая там у Израиля доля в аудитории хабра? ½ миллиона посетителй ежемесячно? Ну значит в постсоветском пространстве их не меньше. Почему молчание? Потому что текст топорный и даже вписываться не хочется. ;) Выдыхайте, Александр, выдыхайте.
Конечно тут будет некоторый оверхед. Но если будет мониторинг, если под БД в 50Мб не будет выделено 50 процессов, при учете того, что стоит memcached а к самой БД идет не более 500 запросов в сутки, из которых 490 — селекты… Что бы все это надежно отмониторить неплохо бы разделить и выявить, что и сколько в стэке реально требует ресурсов, думаю не жалко и 10% от производительности на это дело потратить. Пока же все без оверхедов, как-то само по себе «работает и слава яйца» — ну о какой оптимизации и мониторинге может быть речь в подобном случае? Реально на том проекте, из-за которого меня на переводы потянуло, я не видел, что бы процессор нагружался хотя бы до 10%. Постоянный idle. А вот диски — уже визжат. Особенно на выходных, когда бэкап, настроенный из plesk-панели, на 8 часов кряду вгоняет всю систему в полумертвое состояние. А это происходит из-за беспорядка на дисках. Почему там беспорядок? Потому что нет регламента никакого. Почему нет регламента никакого? Потому что всем удобнее позвать кого-то, кто решит очевидные проблемы, подкинув следующему за ним админу пачку новых проблем. И вот так и получается этот круг ненависти, где все друг-другу гадят таким милым и незатейливым образом.
Меня соблазнил munin тем, что под него можно легко писать плагины. Кто б мне сказал, что надо было задаться вопросом «а каких тебе плагинов не хватало в nagios?».
Та же фигня с админами. «Был, сделал, ушел». Куда они уходят и почему становясь как будто бы профессионалами, частенько превращаются в ленивых парнокопытных — это отдельная тема для разговора.
Я пока еще не начал вирутализировать проекты, но пока склоняюсь в сторону KVM, во всяком случае это более «модная тема» обсуждать, как последний лучше подходит для 6-й версии CentOS.
А кто вам сказал, что я — админ? ;) Просто возникает необходимость делать что-то хорошо или искать тех, кто знает и делает много лучше тебя. А как это проверить? Сделать хорошо хотя бы раз самостоятельно. Вобщем, общая беда всех технических проектов.
В любом случае, спасибо за комменты. Чувствую, что в чем-то моя и ваша ситуации похожи между собой. ;)
У нас виртуальная сеть, об каких коммутаторах речь? Стаит-сервер стоит в ДЦ Хецнера, хочется сделать его девелопмент-тест-продакшеном для пары тройки проектов, которые в прокаченном виде легко и недорого будут деплоится на новые машина уже в настроенном контейнере, или в облака уходить, по достижению каких-то серьезных показателей посещаемости и нагрузки на имеющуюся железяку.
lighttpd не я придумал использовать, мне вообще кажется, что в рунете он редкость (относительная). Кто-то собирает непонятные мне конфиги из кеширующего энджинкса и ставит перед ним варниш. Зачем так делать — ума не приложу. Но, блин, ведь делают зачем-то? Сейчас допереведем этот цикл, а по фидбэку в комментах станет ясно, что еще нужно/можно посмотреть, так как академической литературы по построению ± сложных архитектур на один-два дэдика с пятью-десятью проектами на борту я не знаю. Есть идеи, что поискать?
У меня не меньше «претензий» к материалу. Т.е. мы либо учимся, взвешивая варианты, либо читаем такик tutorial'ы. Зачем оно лично мне надо? Комментарии. Ваш в том числе. Например, в прошлой статье этого цикла вы мне «подарили» аббревиатуру «NOC», и по этому тэгу я на одном только хабре нашел много интересного материала.
Критика тех или иных подходов в архитектуре сервера, основанная на вашей практики, порождает точки входа в google. По моему это уже ценно. Выше в комментариях вылезли вопросы о портах в различных версиях протокола NFS, хотя само использование этого протокола, как наиболее/наименее подходящего для работы никем еще не обсуждалось, а камни в прошлой статье уже кидались в нее.
Было бы интересно послушать альтернативные взгляды на архитектуру. Меня не покидает чувство, что автор текста, так же как и я, когда сидит на сервере, то протоколирует putty в лог-файл, исправляет ошибочные шаги, удаляет лишнее и получается вот такой вот пошаговый инструктаж. Честь ему за то и хвала, т.к. у меня не хватило сил довести свои протоколы настройки до цельной статьи.
Сами cyberciti.biz, авторы этого текста, позиционируют себя как большой FAQ. На него же похож howtoforge.com И у первых и у вторых я смотрю доп.материалы по возникающим вопросам и было бы здорово, если у меня получилось бы зацепить этим материалом темы для следующих переводов. Перевести многостраничные гайды по линуксу или фре — ну это вообще не формат сайта, хотя переводя вчитываешься гораздо глубже.
Я побоялся делать интро от себя, рассказывая, с какой проблемой столкнулся и для чего меня понесло в виртуализацию, которую в данном материале и виртуализацией назвать не выходит. Найду материал по своей тематике — сразу сюда притащу.
Если в общих чертах, то есть дефицит доступной информации, best practics от серьезных администраторов. Т.е. у меня есть задача — сайт с немаленькой аудиторией. Есть серверное хозяйство, которое нужно не только настроить раз в 5 лет и забыть, но и мониторить. Почему об этом никто из администраторов, настраивавших этот сервер прежде, не говорил владельцам ресурсов? Ну, потому что они — специалисты и они решили, что в нашем случае это не нужно. А когда настанет глубокая попа, когда кто-нибудь обнаружит, что есть проблемы в файловой системе, а SMART сыпет ошибки уже пол-года, тогда придет следующий администратор, перенесет все хозяйство на правильную архитектуру, поставит системы аналитики и мониторинга и до следующего «абзаца» все будут прибывать в неведении, что скрипт-кидиз давно и с любовью льют шелы через дырявый загрузчик картинок сайта в исполняемую директорию, а в движке сайта используется один популярный шелл в качестве менеджера файлов.
В прошлом материале завязался небольшой диалог с пользователем EugeneBond, который мне может оказаться более полезным, чем всякие туториалы. Ваш комментарий окажется более информационным чем вся статья. Т.е. переводится только ради разговора на эту тему. Если есть темы и нюансы, о которых есть что почитать на английском, но хотелось бы пообсуждать на русском языке — «бери, переводи, читай комменты». Мне ссылку можно бросить, если это по теме и будет интересно — почитаю, переведу, запощу, обсудим. Вот такой я хитрец. Ваши знания в обмен на мои переводы. ;)
Помоему вся эта «публичная история» — отличный прием и способ найти джуниора/специалиста. Немного раньше срока вскрыты карты, а так могло разрастись до рунетовского масштаба. Премию получили бы за вирусный маркетинг. Рано, рано вскрыли карты.
Да и у нас не много, но они же приходят и уходят, следят и мусорят, ставят и удаляют, а потом черт ногу сломит разобрать, что половину бы неплохо, для порядка, стереть к такой-то матери, что бы новый входящий не мучался вопросом, с какого края ему подойти к серверу. Каждый чточку мусорит, а в конце — помойка. Сейчас заведем журнал, регламенты, переставим все хозяйство и будем чаи гонять, но это все потом.
Мониторите через munin+nasios или какое-то более общее решение нашли? Уже третью неделю пытаюсь прикручивать метрики munin'овские (отдельная задача) попутно разбирая, что же это все значит и откуда что растет (в смысле нагрузок и iowait'ов). Будет готова метрика на фаервол — будем думать, видимо на новом сервере, куда и мигрируем. Всплыли неполадки в файловой системе, теперь мониторим SMART и потеем от мысли, что что-нибудь схлопнится раньше переезда. Как в одной хорошей лекции по мониторингу серверов тут, на хабре, говорил мужик из Битрикса — никакой романтики. Кровь и мозги на стенах.
Могучих сисадминов не видел, чудаков — да, могучих не встречал. Это какой-то полумифический кадр, который где-то есть, но стоит попробовать приблизится к нему — и его сразу же нет.
Как у вас управление виртуалками выстроена? В плане, если все порты наружу, кроме 80/443 закрыто? Что-то из этого набора? На центОСе или Дебиане? Любопытно просто. Не очень бурная аудитория по администрированию серверов вообще в рунете, проще сиськи найти. Я бы у вас интервью взял, было бы круто, если вдруг и вам взбредет это в голову. ;)
Т.е. если я под эту архитектуру попытаюсь впихнуть сервера разработки и тест.сервера — вся избыточность и секьюрность утеряет всякий и без того хлипкий смысл? Мне кажется, что заморочиться с iptables на гостевых системах все же имеет смысл.
У нас сейчас чудовищная ситуация — разработчики «шастают» по ssh на большой сервер, на котором крутится несколько проектов, с общей нагрузкой в 250k посетителей, и меня это хозяйство повергает в ужасное уныние. Сижу, смотрю мониторинг и не понимаю, где и что вызвало скачки нагрузки, кто долбит дисковую систему, а кто сожрал память.
Безусловно, я сплю и вижу, что выстрелит очередной проект и я «выкину» его в готовом контейнере за пару часов вовне. Этому будет посвящена вторая статья цикла. Надеюсь на ваше пристальное внимание.)
Там вопрос был в том, что если будет скомпрометирован один из узлов этого виртуал-нета, то не хотелось бы, что бы остальные постигла такая же участь из-за открытых портов во все стороны. Пока у самого не появилось ясности, как будет организовано управление узлами. Будет ли это все же открытый наружу ssh-канал или это VNC в духе Аркипеловского. Тема для меня актуальная, но новая и тут я в полуслепую тыкаюсь.
2,5 тысячи лет назад жил Будда. Т.е. «буддисты» говорили об это максимум две тысячи лет назад — историческая диффузия редко исчисляется десятилетиями, следовательно фраза о «нескольких тысячах лет назад» не совсем корректна.
В статье есть только на уровне доп.ссылок материалы о логировании iptables и прочем. О мониторинге — нужно писать отдельную статью. Вот чесслово, был бы материал/книга, которая назывался бы «Безопасность сервера. Регламенты и рецепты управления» — сел бы и перевел.
Если к первому вашему комменту вернуться, то вот что я скажу
Не могу ответить, т.к. настройка AppArmor/SElinux для меня начинается и заканчивается одной командой конфига:
Буду, наверно, разбираться и с SElinux, но пока мы прислушиваемся к авторам туториала и, временно, его выключаем.
В чем же преимущество над AppArmor/SElinux у нашей виртуализации? Могу ответить лишь о части перечисленного в тексте: Масштабируемость/Оптимизация/Простота мониторинга. «Безопасность» и «Простота использования» немного не ясны для меня, но что-то уже начинает проясняться.
Честно говоря, сейчас я вижу общую нагрузку всех проектов, общее потребляемое ими количество памяти, общую нагрузку и общие ошибки. Мне легче и проще выстроить с ноля сервер и его стек, чем оставить инструкцию для будущих поколений, что и почему у нас так странно работает и выглядит, и оптимизировать каждый новый сайт/приложение на сервере в поисках причин сжираемой памяти и дисковой нагрузки. После такой настройки можно брать специалиста по конкретному узкому кругу вопросов и, не передавая ему рутовые пароли, давать настраивать и оптимизировать «от и до» на отдельной секьюрно-огороженной виртуальной машине
Вот когда вы будете ломать проксирующий сервер или бэкенд статики и скриптовый бэкенд, которые доступны только для этого самого проксирующего сервера по локалке, то наверно речь идет о сплойтах, SQLInjection, XSS и прочем, у меня будут оганиченные права к БД (чуть ли не SELECT-only), а CMS будут под версионным контролем и всякие робкие вздрагивания будут логироваться и мониторится системой уведомления… Т.е. тут комплекс мер нужен, а не просто виртуалки. Это ясно. А в какой схеме вам будет тяжело получить доступ к БД/мэмкешеду?
Ну… мне заплатят за настрйоку. )))
www.symantec.com/connect/articles/securing-apache-step-step
www.symantec.com/connect/articles/securing-mysql-step-step
www.symantec.com/connect/articles/securing-php-step-step
У нас БД висит на виртуалке 192.168.1.13/vm04,
доступ к ней есть у пользователя foo с трех машин:
В iptables забит доступ к машине с БД
1. В самих конфигах приложения (допустим установлен WPress) порт/логин/пароль будут фигурировать явным образом. Т.е. не понятно, от кого/чего мы защитимся, перевесив порты. Я вот пока не понимаю, зачем серверу статики доступ к БД, но это видимо станет ясно по ходу перевода. Ну или вернемся сюда позднее и внесем дополнительные примечания. Ваш коммент будет свидетелем. ;)
Логирование — предложение более чем интересное. Я бы добавил к ссылке в статье об iptables, предложенной авторами оригинального материала, свой перевод. Как вам? Замечания/предложения?
2. По поводу минимальных прав. Если пользователь foo — админ, то может быть пусть будут у него эти права? Он у нас удаленно может зайти только через phpMyAdmin на фронт/бэкэнд серверах апача и Nginx.
Можно внести это в примечание к статье и дать ссылку или перевод на доп.статьи о правах. Авторы оригинального перевода тупо отослали к доками MySQL. А на хабре по этой теме ничего нет, вроде бы. Или я не нашел. Может вы какой-то материал/ссылку на эту тему видели? Или из перечисленного что-то хотелось бы иметь в переводном виде?
www.greensql.com/articles/mysql-security-best-practices
dev.mysql.com/doc/mysql-security-excerpt/5.6/en/index.html
dev.mysql.com/doc/mysql-security-excerpt/5.6/en/topic-mysql-security-faq.html
3. Вы предлагаете запретить доступ к БД с сервера БД? Уточните, я не совсем понимаю.
4. Я так понял, вы предлагаете сделать так, как это описано в 7-м пункте приведенной чуть выше ссылки?
Или ссылку вменяемую.
www.zatulin.ru/institute/sbornik/040/13.shtml
www.sup.com/entrepreneurs.html
wiki
www.russianwashingtonbaltimore.com/charters_schools
Я решил их всех сделать. ;)))
Та же фигня с админами. «Был, сделал, ушел». Куда они уходят и почему становясь как будто бы профессионалами, частенько превращаются в ленивых парнокопытных — это отдельная тема для разговора.
Я пока еще не начал вирутализировать проекты, но пока склоняюсь в сторону KVM, во всяком случае это более «модная тема» обсуждать, как последний лучше подходит для 6-й версии CentOS.
А кто вам сказал, что я — админ? ;) Просто возникает необходимость делать что-то хорошо или искать тех, кто знает и делает много лучше тебя. А как это проверить? Сделать хорошо хотя бы раз самостоятельно. Вобщем, общая беда всех технических проектов.
В любом случае, спасибо за комменты. Чувствую, что в чем-то моя и ваша ситуации похожи между собой. ;)
lighttpd не я придумал использовать, мне вообще кажется, что в рунете он редкость (относительная). Кто-то собирает непонятные мне конфиги из кеширующего энджинкса и ставит перед ним варниш. Зачем так делать — ума не приложу. Но, блин, ведь делают зачем-то? Сейчас допереведем этот цикл, а по фидбэку в комментах станет ясно, что еще нужно/можно посмотреть, так как академической литературы по построению ± сложных архитектур на один-два дэдика с пятью-десятью проектами на борту я не знаю. Есть идеи, что поискать?
Критика тех или иных подходов в архитектуре сервера, основанная на вашей практики, порождает точки входа в google. По моему это уже ценно. Выше в комментариях вылезли вопросы о портах в различных версиях протокола NFS, хотя само использование этого протокола, как наиболее/наименее подходящего для работы никем еще не обсуждалось, а камни в прошлой статье уже кидались в нее.
Было бы интересно послушать альтернативные взгляды на архитектуру. Меня не покидает чувство, что автор текста, так же как и я, когда сидит на сервере, то протоколирует putty в лог-файл, исправляет ошибочные шаги, удаляет лишнее и получается вот такой вот пошаговый инструктаж. Честь ему за то и хвала, т.к. у меня не хватило сил довести свои протоколы настройки до цельной статьи.
Сами cyberciti.biz, авторы этого текста, позиционируют себя как большой FAQ. На него же похож howtoforge.com И у первых и у вторых я смотрю доп.материалы по возникающим вопросам и было бы здорово, если у меня получилось бы зацепить этим материалом темы для следующих переводов. Перевести многостраничные гайды по линуксу или фре — ну это вообще не формат сайта, хотя переводя вчитываешься гораздо глубже.
Я побоялся делать интро от себя, рассказывая, с какой проблемой столкнулся и для чего меня понесло в виртуализацию, которую в данном материале и виртуализацией назвать не выходит. Найду материал по своей тематике — сразу сюда притащу.
Если в общих чертах, то есть дефицит доступной информации, best practics от серьезных администраторов. Т.е. у меня есть задача — сайт с немаленькой аудиторией. Есть серверное хозяйство, которое нужно не только настроить раз в 5 лет и забыть, но и мониторить. Почему об этом никто из администраторов, настраивавших этот сервер прежде, не говорил владельцам ресурсов? Ну, потому что они — специалисты и они решили, что в нашем случае это не нужно. А когда настанет глубокая попа, когда кто-нибудь обнаружит, что есть проблемы в файловой системе, а SMART сыпет ошибки уже пол-года, тогда придет следующий администратор, перенесет все хозяйство на правильную архитектуру, поставит системы аналитики и мониторинга и до следующего «абзаца» все будут прибывать в неведении, что скрипт-кидиз давно и с любовью льют шелы через дырявый загрузчик картинок сайта в исполняемую директорию, а в движке сайта используется один популярный шелл в качестве менеджера файлов.
В прошлом материале завязался небольшой диалог с пользователем EugeneBond, который мне может оказаться более полезным, чем всякие туториалы. Ваш комментарий окажется более информационным чем вся статья. Т.е. переводится только ради разговора на эту тему. Если есть темы и нюансы, о которых есть что почитать на английском, но хотелось бы пообсуждать на русском языке — «бери, переводи, читай комменты». Мне ссылку можно бросить, если это по теме и будет интересно — почитаю, переведу, запощу, обсудим. Вот такой я хитрец. Ваши знания в обмен на мои переводы. ;)
Мониторите через munin+nasios или какое-то более общее решение нашли? Уже третью неделю пытаюсь прикручивать метрики munin'овские (отдельная задача) попутно разбирая, что же это все значит и откуда что растет (в смысле нагрузок и iowait'ов). Будет готова метрика на фаервол — будем думать, видимо на новом сервере, куда и мигрируем. Всплыли неполадки в файловой системе, теперь мониторим SMART и потеем от мысли, что что-нибудь схлопнится раньше переезда. Как в одной хорошей лекции по мониторингу серверов тут, на хабре, говорил мужик из Битрикса — никакой романтики. Кровь и мозги на стенах.
Могучих сисадминов не видел, чудаков — да, могучих не встречал. Это какой-то полумифический кадр, который где-то есть, но стоит попробовать приблизится к нему — и его сразу же нет.
Как у вас управление виртуалками выстроена? В плане, если все порты наружу, кроме 80/443 закрыто? Что-то из этого набора? На центОСе или Дебиане? Любопытно просто. Не очень бурная аудитория по администрированию серверов вообще в рунете, проще сиськи найти. Я бы у вас интервью взял, было бы круто, если вдруг и вам взбредет это в голову. ;)
У нас сейчас чудовищная ситуация — разработчики «шастают» по ssh на большой сервер, на котором крутится несколько проектов, с общей нагрузкой в 250k посетителей, и меня это хозяйство повергает в ужасное уныние. Сижу, смотрю мониторинг и не понимаю, где и что вызвало скачки нагрузки, кто долбит дисковую систему, а кто сожрал память.
Безусловно, я сплю и вижу, что выстрелит очередной проект и я «выкину» его в готовом контейнере за пару часов вовне. Этому будет посвящена вторая статья цикла. Надеюсь на ваше пристальное внимание.)
Но науч.поп. – сытный.