Я, конечно, понимаю, что автор статьи новичок в Puppet и документацию, если и читал, то по диагонали (извините, создается именно такое ощущение)
По поводу зависимостей, то там точно нет apache ни в каком виде.
Полный список зависимостей на пустом CentOS 7
Installing:
puppet-server noarch 3.6.2-3.el7 epel 24 k
Installing for dependencies:
augeas-libs x86_64 1.4.0-2.el7 base 355 k
facter x86_64 2.4.1-1.el7 epel 101 k
hiera noarch 1:1.3.4-5.el7 epel 25 k
libselinux-ruby x86_64 2.5-6.el7 base 120 k
libyaml x86_64 0.1.4-11.el7_0 base 55 k
pciutils x86_64 3.5.1-1.el7 base 93 k
puppet noarch 3.6.2-3.el7 epel 1.2 M
ruby x86_64 2.0.0.648-29.el7 base 68 k
ruby-augeas x86_64 0.5.0-1.el7 epel 23 k
ruby-irb noarch 2.0.0.648-29.el7 base 89 k
ruby-libs x86_64 2.0.0.648-29.el7 base 2.8 M
ruby-shadow x86_64 1.4.1-23.el7 epel 14 k
rubygem-bigdecimal x86_64 1.2.0-29.el7 base 80 k
rubygem-io-console x86_64 0.4.2-29.el7 base 51 k
rubygem-json x86_64 1.7.7-29.el7 base 76 k
rubygem-psych x86_64 2.0.0-29.el7 base 78 k
rubygem-rdoc noarch 4.0.0-29.el7 base 319 k
rubygem-rgen noarch 0.6.6-2.el7 epel 84 k
rubygems noarch 2.0.14.1-29.el7 base 216 k
Updating for dependencies:
pciutils-libs x86_64 3.5.1-1.el7 base 46 k
По поводу mcollective, то его можно поставить не только для 4.x, но и для 3.x просто почитав документацию или какой-то гайд, вроде этого
А вообще, очень странный выбор Puppet 3.8.x, ведь третья ветка Puppet была выпущена в 2012 году, а сейчас уже аж середина 2017 и… использовать продукт пятилетней давности с кучей ограничений — как-то странно, не находите? А если учесть, что Puppet-CE, т.е. 4.х отличается от 3.х примерно так же, как Windows 10 от Windows 98, то выбор очень странный
Я к тому, что в Puppet 4.x есть возможность работать как в режиме agent-less, так и в класическом варианте с агентами, а так же есть куча решенных проблем с производительностью (используется JRuby + LLVM), масштабируемостью/отказоустойчивостью (можно иметь сколько угодно мастеров, а не один) и много чего еще
Но даже используя Puppet 3, совершенно не нужно знать Ruby, но нужно хотя бы почитать документацию и статьи о том, как правильно сделать версионность, прикрутить Hiera, PuppetDB, разные окружения, автоматизировать доставку Puppet манифестов из git, сделать CICD и т.д.
Это все есть в документации, могу показать, если хотите :-)
Мое мнение — Puppet одна из самых старых систем управления конфигурациями (что в данном случае достоинство) и явно заслуживает внимания как раз из-за того, что у него низкий порог вхождения, отсутствует необходимость знания языков, вроде Python для ansible, а так же огромное комьюнити (просто посмотрите на Puppet Forge и покажите, что там нет того, что нужно Вам). Плюс ко всему есть огромная гибкость и встроенная поддержка git как системы контроля версий, — мечта любого DevOps
Помимо прочего, есть и коммерческая версия, если у Вас вдруг enterprise и есть крупный продукт с парой тысяч серверов, где нельзя допускать простоя и экспериментов. Ну и puppet play в придачу — гуглите :-)
Мой опыт использования Puppet — более 5000 агентов и несколько geo-распределенных мастеров с HA + hiera с шифрованием и подписями данных коммитером + PuppetDB + r10k, интеграция с JIRA, Jenkins, Zabbix, Graphite и т.д.
Пока что ни одна система управления конфигурациями не дала мне тех возможностей, что есть в Puppet
Не хотел Вас задеть и уж тем более — переходить на личности
Комментарий я написал не касательно статьи — тут я ничего сказать не могу, т.к. те предложения с которыми ко мне приходят рекрутеры из Германии в принципе релевантны тому, что написано в статье, но мои ожидания немного выше, так что я пока не планирую релокацию, может когда стану старше
Я же отвечал на тред с Вашим комментарием о том, как работаю рекрутеры вообще и Вы в частности. Вы считаете, что Ваш подход — правильный, я же Вам описываю как оно обстоит на практике у меня, причем в довольно крупной компании — лидере рынка в своем сегменте и довольно известной в мире.
В частности у нас есть метрика для рекрутинговых агенств — процент попадания кандидатов на техническое интервью. От этого показателя напрямую зависит доход агенства и сам факт что мы с ним работаем, минимальный нижний порог — 95%, норма 97,3%
Смотрите, я работаю как раз тем «нанимающим менеджером» и мне достаточно даже одной минуты, чтобы решить — стоит ли человека приглашать на интервью или нет, так что я могу за день «отсмотреть» человек 300-400 с перерывом на обед и всякие митинги и т.д.
HR/рекрутеры которые работают у нас или из внешних агенств работают с такой же скоростью, но на самом деле проблема в том, что в реальной практике в ИТ у вас не бывает даже 50 резюме в день, но может в Германии — другое дело или в крупном агенстве, которое ведет параллельно 15-20 клиентов (50-100 позиций)
Вам тут уже сказали — Вы просто плохой рекрутер, лично я бы с таким работать не стал. Если агенство присылает нам некачественных кандидатов больше чем 5% — мы его меняем (случай из реальной практики, опять же)
Опять же, специфика ИТ, — на позиции Senior и выше (а это больше 80% позиций — джуниоров мало кто хочет) примерно половина кандидатов приходит через сторонние источники вроде митапов, программы bring a friend и через прямой поиск по конкурентам, а так чтобы компанию, даже если она платит на 10-20% выше рынка заваливали резюме — это фантастика. Дефицит кадров такой что на одного senior примерно 25-30 вакансий
Расскажу на примере той же Вертики, очень уж нравится мне их архитектура, при том, что она остается в чем-то postgres-like
У них есть superuser, который просто системный пользователь и у него всегда тип авторизации только пароль, при этом он рекомендуется к использованию только для запуска/остановки базы, бэкапов и других сервисных функций + давать права pseudosuperuser'ам. При этом у него есть сетевой доступ
А вот как раз pseudosuperuser это уже роль и она хранится в самой БД и соответственно делегируется другим пользователям через GRANT pseudosuperuser TO username;
То есть тут четко разделяется сервисный уровень и уровень доступа к данным
При этом реализуется полная и частичная репликация на WAL уровне, т.к. просто объекты (страницы) принадлежащие конкретным схемам, таблицам и т.д. копирутся просто как файлы, а каталог формируется в виду снапшота (каталог описывает какой логической сущности какие файлы/страницы соответствуют)
Правда стоит отметить, что все-таки Вертика не реляционная база, хоть и ACID
UDP: ну да и у них нет авторизации типа ident и access
Для таблицы вроде grants не нужна атомарность на уровне БД же.
При создании сессии пользователя или даже при попытке выполнения SQL мы проверяем в системной таблице в памяти — имеет ли он на это право, если да — генерируем исключение, если нет — выполняем его SQL
Зачем тут атомарность? Мы просто заменим правку HAL + релоад на механизм хранения этих данных «рядом» с данными в БД
Ну не записали мы grant — свет выключили — во-первых у нас есть юзер postgres с полными правами (кстати в упомянутой Vertica есть dbadmin, он как root в Linux внутри БД) и мы можем накатить грантов после того как сервер оживет. Вариантов с непустой БД и отсутствием прав на нее для некоего админа представить сложно
В общем да, соглашусь, что вопрос не простой. Можно вести отдельный WAL-лог — единственное что на ум приходит, с другой стороны очевидно, что это костыль
Я говорю только о системных, специальных таблицах, которые являются аналогом hal, то есть это гранты, но в более гибком смысле. Они могут (и скорее всего даже должны) храниться отдельно, а не как типичная таблица и находиться после старта БД в памяти, но записываться на диск само собой
В таком случае WAL писать не нужно, как и ломать физическую репликацию, достаточно добавить ключ, вроде того — синхронизировать гранты или нет
Я бы тоже сильно возражал против изменения текущей схемы физической репликации, но её и не нужно ломать, просто заменить HAL на что-то более удобное и гибкое
Посмотрите как сделано в HP Vertica, которая, кстати, была основана на кодовой базе PostgreSQL, но потом ушла сильно в сторону
Там есть два варианта — full backup / copy cluster или репликация, так вот в первом случае переносится вся база, включая гранты, а во втором случае переносятся только структура таблиц и данные, соответсвенно легко можно назначить разные права на master/replica.
Думаю такое же поведение можно продумать и для PostgreSQL — сделать два режима репликации — с переносом прав (системных таблиц) или нет.
Или же сделать еще проще и дать возможность исключать таблицы (она есть в логической репликации же) и соответственно по дефолту включить таблицы отвечающие за права в blacklist
p.s. но я не возьмусь даже за proposal, не то что за реализацию, к сожалению(((
По поводу мышей, не воспринимайте как «идолопоклонство», никто ничего лучше Apple mouse (IMHO), не придумал — низкопрофильная, соответственно изгиб руки минимален, плюс к этому можно двигать двумя пальцами, а не всей рукой. Если туда же добавить apple keyboard, которая толщиной ещё меньше мыши, всё ещё проще становится
Как по мне — проблема не столь актуальна (может только для меня), если используешь удобные лично для тебя девайсы. У меня это не просто одно из, а основное требование к работадателю, если я обсуждаю оффер — клавиатура, мышь, монитор, кресло. Если работодатель не готов потратить максимум 20% моей зарплаты за месяц, чтобы сделать мою работу комфортной (что увеличит мою же производительность), то идти к нему работать себя не уважать
Нет же, наоборот, проверяется так же, только уже смотрятся диффы, потом собирается в изолированном окружении и только потом уходит апдейт на основной билд сервер
То есть проверка апдейтов делается так же как и любого другого кода, разве что быстрее, т.к. как правило объем изменений не такой большой (диффы)
Именно! Помимо зловредных вещей некоторые вполне себе крупные компании имеют в своем софте код, который отправляет «обезличенные» аналитические данные о работе системы. При этом в open source версии (в коде) этого участка нет, а в бинарном пакете от вендора есть
Конечно в ToA или в лицензии об этом прописано, но если нам не хочется, чтобы что-то куда-то отправлялось, — мы просто собираем из сорцов
Это даже не уязвимость, это сбор данных пользователя, например. Или авто-баг репорты.
По разному. В любом случае пишется баг-репорт разработчику. Если команда, которой нужен был компонент не нашли альтернативы или фикс тривиальный, то после внутреннего тестирования помимо баг репорта будет еще и пулл-реквест
Но иногда или пакет плохо поддерживается (или вообще разработку забросили), или же фикс нетривиальный и требует времени чуть ли не больше, чем разработка фичи/функционала с нуля — в таком случае скорей всего будут искать альтернативу или писать руками
Это баг, но это не уязвимость. Любой софт содержит баги, прям вот любой. Делать аудит на баги и делать работу QA другой компании (или open source проекта) — слишком затратно, ради просто включения в проект.
Если баг проявляется у вас лично — пишите баг репорт и его поправят или сразу пулл реквест, если вы у себя его поправили уже. Если баг вам не мешает спать по ночам, то смело игнорируйте, если он не несет угрозы ИБ
Тот же RHEL делает аудит кода. Бесплатный, только плата за поддержку. Тот же GRSecurity тоже делает. Это из тех кто «на устах»
Крупные компании тоже проводят свой аудит, особенно если работают в тех сферах, где защита информации — основная задача (финансы, крипта, всякий enterprise)
По поводу зависимостей, то там точно нет apache ни в каком виде.
Installing:
puppet-server noarch 3.6.2-3.el7 epel 24 k
Installing for dependencies:
augeas-libs x86_64 1.4.0-2.el7 base 355 k
facter x86_64 2.4.1-1.el7 epel 101 k
hiera noarch 1:1.3.4-5.el7 epel 25 k
libselinux-ruby x86_64 2.5-6.el7 base 120 k
libyaml x86_64 0.1.4-11.el7_0 base 55 k
pciutils x86_64 3.5.1-1.el7 base 93 k
puppet noarch 3.6.2-3.el7 epel 1.2 M
ruby x86_64 2.0.0.648-29.el7 base 68 k
ruby-augeas x86_64 0.5.0-1.el7 epel 23 k
ruby-irb noarch 2.0.0.648-29.el7 base 89 k
ruby-libs x86_64 2.0.0.648-29.el7 base 2.8 M
ruby-shadow x86_64 1.4.1-23.el7 epel 14 k
rubygem-bigdecimal x86_64 1.2.0-29.el7 base 80 k
rubygem-io-console x86_64 0.4.2-29.el7 base 51 k
rubygem-json x86_64 1.7.7-29.el7 base 76 k
rubygem-psych x86_64 2.0.0-29.el7 base 78 k
rubygem-rdoc noarch 4.0.0-29.el7 base 319 k
rubygem-rgen noarch 0.6.6-2.el7 epel 84 k
rubygems noarch 2.0.14.1-29.el7 base 216 k
Updating for dependencies:
pciutils-libs x86_64 3.5.1-1.el7 base 46 k
По поводу mcollective, то его можно поставить не только для 4.x, но и для 3.x просто почитав документацию или какой-то гайд, вроде этого
А вообще, очень странный выбор Puppet 3.8.x, ведь третья ветка Puppet была выпущена в 2012 году, а сейчас уже аж середина 2017 и… использовать продукт пятилетней давности с кучей ограничений — как-то странно, не находите? А если учесть, что Puppet-CE, т.е. 4.х отличается от 3.х примерно так же, как Windows 10 от Windows 98, то выбор очень странный
Я к тому, что в Puppet 4.x есть возможность работать как в режиме agent-less, так и в класическом варианте с агентами, а так же есть куча решенных проблем с производительностью (используется JRuby + LLVM), масштабируемостью/отказоустойчивостью (можно иметь сколько угодно мастеров, а не один) и много чего еще
Но даже используя Puppet 3, совершенно не нужно знать Ruby, но нужно хотя бы почитать документацию и статьи о том, как правильно сделать версионность, прикрутить Hiera, PuppetDB, разные окружения, автоматизировать доставку Puppet манифестов из git, сделать CICD и т.д.
Это все есть в документации, могу показать, если хотите :-)
Мое мнение — Puppet одна из самых старых систем управления конфигурациями (что в данном случае достоинство) и явно заслуживает внимания как раз из-за того, что у него низкий порог вхождения, отсутствует необходимость знания языков, вроде Python для ansible, а так же огромное комьюнити (просто посмотрите на Puppet Forge и покажите, что там нет того, что нужно Вам). Плюс ко всему есть огромная гибкость и встроенная поддержка git как системы контроля версий, — мечта любого DevOps
Помимо прочего, есть и коммерческая версия, если у Вас вдруг enterprise и есть крупный продукт с парой тысяч серверов, где нельзя допускать простоя и экспериментов. Ну и puppet play в придачу — гуглите :-)
Мой опыт использования Puppet — более 5000 агентов и несколько geo-распределенных мастеров с HA + hiera с шифрованием и подписями данных коммитером + PuppetDB + r10k, интеграция с JIRA, Jenkins, Zabbix, Graphite и т.д.
Пока что ни одна система управления конфигурациями не дала мне тех возможностей, что есть в Puppet
Комментарий я написал не касательно статьи — тут я ничего сказать не могу, т.к. те предложения с которыми ко мне приходят рекрутеры из Германии в принципе релевантны тому, что написано в статье, но мои ожидания немного выше, так что я пока не планирую релокацию, может когда стану старше
Я же отвечал на тред с Вашим комментарием о том, как работаю рекрутеры вообще и Вы в частности. Вы считаете, что Ваш подход — правильный, я же Вам описываю как оно обстоит на практике у меня, причем в довольно крупной компании — лидере рынка в своем сегменте и довольно известной в мире.
В частности у нас есть метрика для рекрутинговых агенств — процент попадания кандидатов на техническое интервью. От этого показателя напрямую зависит доход агенства и сам факт что мы с ним работаем, минимальный нижний порог — 95%, норма 97,3%
Смотрите, я работаю как раз тем «нанимающим менеджером» и мне достаточно даже одной минуты, чтобы решить — стоит ли человека приглашать на интервью или нет, так что я могу за день «отсмотреть» человек 300-400 с перерывом на обед и всякие митинги и т.д.
HR/рекрутеры которые работают у нас или из внешних агенств работают с такой же скоростью, но на самом деле проблема в том, что в реальной практике в ИТ у вас не бывает даже 50 резюме в день, но может в Германии — другое дело или в крупном агенстве, которое ведет параллельно 15-20 клиентов (50-100 позиций)
Вам тут уже сказали — Вы просто плохой рекрутер, лично я бы с таким работать не стал. Если агенство присылает нам некачественных кандидатов больше чем 5% — мы его меняем (случай из реальной практики, опять же)
Опять же, специфика ИТ, — на позиции Senior и выше (а это больше 80% позиций — джуниоров мало кто хочет) примерно половина кандидатов приходит через сторонние источники вроде митапов, программы bring a friend и через прямой поиск по конкурентам, а так чтобы компанию, даже если она платит на 10-20% выше рынка заваливали резюме — это фантастика. Дефицит кадров такой что на одного senior примерно 25-30 вакансий
У них есть superuser, который просто системный пользователь и у него всегда тип авторизации только пароль, при этом он рекомендуется к использованию только для запуска/остановки базы, бэкапов и других сервисных функций + давать права pseudosuperuser'ам. При этом у него есть сетевой доступ
А вот как раз pseudosuperuser это уже роль и она хранится в самой БД и соответственно делегируется другим пользователям через GRANT pseudosuperuser TO username;
То есть тут четко разделяется сервисный уровень и уровень доступа к данным
При этом реализуется полная и частичная репликация на WAL уровне, т.к. просто объекты (страницы) принадлежащие конкретным схемам, таблицам и т.д. копирутся просто как файлы, а каталог формируется в виду снапшота (каталог описывает какой логической сущности какие файлы/страницы соответствуют)
Правда стоит отметить, что все-таки Вертика не реляционная база, хоть и ACID
UDP: ну да и у них нет авторизации типа ident и access
При создании сессии пользователя или даже при попытке выполнения SQL мы проверяем в системной таблице в памяти — имеет ли он на это право, если да — генерируем исключение, если нет — выполняем его SQL
Зачем тут атомарность? Мы просто заменим правку HAL + релоад на механизм хранения этих данных «рядом» с данными в БД
Ну не записали мы grant — свет выключили — во-первых у нас есть юзер postgres с полными правами (кстати в упомянутой Vertica есть dbadmin, он как root в Linux внутри БД) и мы можем накатить грантов после того как сервер оживет. Вариантов с непустой БД и отсутствием прав на нее для некоего админа представить сложно
В таком случае WAL писать не нужно, как и ломать физическую репликацию, достаточно добавить ключ, вроде того — синхронизировать гранты или нет
Я бы тоже сильно возражал против изменения текущей схемы физической репликации, но её и не нужно ломать, просто заменить HAL на что-то более удобное и гибкое
Пример: www.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/SystemTables/CATALOG/GRANTS.htm — весь Catalog хранится в datapath, но он отделен от данных, то есть таплы для grants можно копировать (fullbackup), а можно и не копировать
Там есть два варианта — full backup / copy cluster или репликация, так вот в первом случае переносится вся база, включая гранты, а во втором случае переносятся только структура таблиц и данные, соответсвенно легко можно назначить разные права на master/replica.
Думаю такое же поведение можно продумать и для PostgreSQL — сделать два режима репликации — с переносом прав (системных таблиц) или нет.
Или же сделать еще проще и дать возможность исключать таблицы (она есть в логической репликации же) и соответственно по дефолту включить таблицы отвечающие за права в blacklist
p.s. но я не возьмусь даже за proposal, не то что за реализацию, к сожалению(((
Это проблема платформы, на iOS любые разрешения запрашиваются в момент обращения к требуемой функциональности (камера, аудио, фото/видео стоп и тд)
Так что тут, имхо, не в приложении проблема — они спрашивают все, что им может пригодиться, если это ведроид
По поводу мышей, не воспринимайте как «идолопоклонство», никто ничего лучше Apple mouse (IMHO), не придумал — низкопрофильная, соответственно изгиб руки минимален, плюс к этому можно двигать двумя пальцами, а не всей рукой. Если туда же добавить apple keyboard, которая толщиной ещё меньше мыши, всё ещё проще становится
Как по мне — проблема не столь актуальна (может только для меня), если используешь удобные лично для тебя девайсы. У меня это не просто одно из, а основное требование к работадателю, если я обсуждаю оффер — клавиатура, мышь, монитор, кресло. Если работодатель не готов потратить максимум 20% моей зарплаты за месяц, чтобы сделать мою работу комфортной (что увеличит мою же производительность), то идти к нему работать себя не уважать
То есть проверка апдейтов делается так же как и любого другого кода, разве что быстрее, т.к. как правило объем изменений не такой большой (диффы)
А еще рекомендую почитать www.csoonline.com/article/3157377/application-development/report-attacks-based-on-open-source-vulnerabilities-will-rise-20-percent-this-year.html (на английском), очень интересная статья по этому поводу. Думал перевести на Хабр, но не уверен, что найду время
Мы же тут вроде о зависимостях говорим. Пока зависимость не нуждается в обновлении, её собранный артефакт не нуждается в повторной сборке.
При наличии CICD пересобирается только то, что требует пересборки
Конечно в ToA или в лицензии об этом прописано, но если нам не хочется, чтобы что-то куда-то отправлялось, — мы просто собираем из сорцов
Это даже не уязвимость, это сбор данных пользователя, например. Или авто-баг репорты.
Но иногда или пакет плохо поддерживается (или вообще разработку забросили), или же фикс нетривиальный и требует времени чуть ли не больше, чем разработка фичи/функционала с нуля — в таком случае скорей всего будут искать альтернативу или писать руками
Если баг проявляется у вас лично — пишите баг репорт и его поправят или сразу пулл реквест, если вы у себя его поправили уже. Если баг вам не мешает спать по ночам, то смело игнорируйте, если он не несет угрозы ИБ
Крупные компании тоже проводят свой аудит, особенно если работают в тех сферах, где защита информации — основная задача (финансы, крипта, всякий enterprise)
Плюс код как правило смотрит минимум 4 глаза