Для параноиков, боящихся, что облачный менеджер украдет их пароли, тот же Bitwarden можно спокойно запустить в self-hosted режиме на своем собственном сервере. Стоящем где-то в своей серверной на своем железе (мы ведь не доверяем чужим датацентрам).
Лазер там не через всю площадь линзы идет. Там пучок мощных лучей. То окно "диаметром сантиметров 20" - это просто линза телескопа, через который пускают несколько тонких лучей для сведения на цели. Сделать лазерный луч такой апертуры - задача еще более сложная. Если капля или другой мусор попадут именно на участок, где идет луч, то там будет не 160 Вт, а прям несколько киловатт по сути.
Тут возникает проблема с обеспечением взаимной когерентности разных лазеров для фокусировки на произвольном расстоянии. Если вы не обеспечите когерентность разных лучей и их точную фокусировку (с точностью до микрометра), то получится не усиление мощности в точке фокусировки, а размазанная интерференционная картина. Фокусировать разные мощные лазеры на большом расстоянии в неконтролируемой среде (а вы не можете контролировать все флуктуации атмосферы на пути луча к цели) с микронной точностью - задача практически нерешаемая.
Этим сказкам про лазерное вундерваффе уже лет так 50. И все это время пытаются из лазеров боевую стрелялку сделать. Правда, постоянно получается примерно одинаковый результат.
Какие главные сдерживающие факторы? То есть, что мешает делать супермощные лазеры? Нет мощного источника/хранилища энергии или что-то ещё?
Мешает самая банальная вещь: атмосфера. При очень мощном лазерном импульсе начинают играть роль оптические эффекты в атмосфере, в том числе нелинейные: самодифракция, самофокусировка и т.п. В том числе может начаться банальная ионизация воздуха с рассеянием лазерного пучка на получающейся плазме. Поэтому плотность мощности в таких лазерных пучках всегда ограничена. И поразить удается только специально подобранные цели без защитного покрытия в идеальных условиях (отсутствие тумана, дождя и тп).
Практике по Ansible вам еще учиться и учиться, на мой личный взгляд. :) Для начала стоит осознать, что Ansible - это не запускалка баш-команд, как в вашем коде.
Это какой-то треш, простите. Использовать парсинг вывода дебага ansible в json формате с помощью однострочника на баше для извлечения значения одного ключа для записи в файл инвентаря, чтобы вызвать еще один башсибл?
Если вы проводите обновление путем накатки плейбука и обновления пакетов наживую, то по факту у вас получаются не эквивалентные образы. Различие точно будет набегать между тестовой версией и продакшеном, и даже между нодами одного кластера может со временем набежать заметная разница в конфигурации тех же пакетов и библиотек.
Пересборка образа занимает примерно то же время, что и накатка плейбуки на поднятые голые инстансы. Но при этом есть нормальная возможность того же масштабирования кластера. И получается нормальная immutable infrastructure.
Кстати, а как вы обновляете кластер при таком подходе? Сносите весь кластер, поднимаете с нуля новой версией кода, а потом восстанавливаете данные из бэкапа?
В этой части мануала я предполагаю, что у вас уже есть мастер-образ, на базе которого вы разворачиваете ВМ. Мы для этих целей используем Packer от тех же Hashicorp, чтобы подготовить Oracle Linux с нашими публичными ключами и системными пользователями, от имени которых будет работать Ansible.
Если все равно делаете образы, то почему сразу туда Vault с необходимыми настройками не запечь? Какой смысл поднимать из образа голый линукс, а потом накатывать на него плейбук для разворачивания Vault? Получается лишняя потеря времени на поднятие кластера. И инфраструктура получается не иммутабельная.
- name: Copy the certificates to the vault config dir for the first time
shell: |
rsync -L /etc/letsencrypt/live/{{ inventory_hostname }}/privkey.pem /etc/vault.d/privkey.pem
rsync -L /etc/letsencrypt/live/{{ inventory_hostname }}/fullchain.pem /etc/vault.d/fullchain.pem
chown vault:vault /etc/vault.d/privkey.pem
chown vault:vault /etc/vault.d/fullchain.pem
pkill -SIGHUP vault
args:
creates: /etc/vault.d/fullchain.pem
Зачем тут этот башсибл? Что мешало нормальный модуль copy использовать?
Какой-то откровенный детский сад в примерах, если честно. Начиная с откровенных антипаттернов вроде
when:
- "'device_roles_ss' in group_names"
или ignore_errors, и заканчивая непониманием базовых сообщений ansible-lint, при том, что линтер в полном выводе показывает даже ссылки на сами правила, на которых он триггернулся. Ну, и вообще... Текст ошибки "truthy value should be one of [false, true]" что, реально никак не понять без помощи нейросети? Серьезно?
В статье описан не способ противостоять терморектальному криптоанализу, а стойкий к потере устройств и паролей метод хранения шифрованных данных. Потерять телефон или ноут с мастер-паролем и не смочь после этого залогиниться в свою учетку с двухфакторкой - гораздо более реальный риск, чем стать жертвой криптоанализа в исполнении Джека Бауэра и других аналогичных товарищей.
У любого анальгетика ограниченный срок действия. Чуть подождать - и можно снова работать паяльником. Тру-шпионы вместо анальгетика быстродействующий яд используют на такой случай.
Для параноиков, боящихся, что облачный менеджер украдет их пароли, тот же Bitwarden можно спокойно запустить в self-hosted режиме на своем собственном сервере. Стоящем где-то в своей серверной на своем железе (мы ведь не доверяем чужим датацентрам).
Где вы видели лазерный луч диаметром 10см?
Лазер там не через всю площадь линзы идет. Там пучок мощных лучей. То окно "диаметром сантиметров 20" - это просто линза телескопа, через который пускают несколько тонких лучей для сведения на цели. Сделать лазерный луч такой апертуры - задача еще более сложная. Если капля или другой мусор попадут именно на участок, где идет луч, то там будет не 160 Вт, а прям несколько киловатт по сути.
Тут возникает проблема с обеспечением взаимной когерентности разных лазеров для фокусировки на произвольном расстоянии. Если вы не обеспечите когерентность разных лучей и их точную фокусировку (с точностью до микрометра), то получится не усиление мощности в точке фокусировки, а размазанная интерференционная картина. Фокусировать разные мощные лазеры на большом расстоянии в неконтролируемой среде (а вы не можете контролировать все флуктуации атмосферы на пути луча к цели) с микронной точностью - задача практически нерешаемая.
Этим сказкам про лазерное вундерваффе уже лет так 50. И все это время пытаются из лазеров боевую стрелялку сделать. Правда, постоянно получается примерно одинаковый результат.
Или дождь накапает или брызги от волн попадут. :)
А еще лучше представить, что будет, если коварный враг на цель уголковый отражатель пришпандорит. :)
Мешает самая банальная вещь: атмосфера. При очень мощном лазерном импульсе начинают играть роль оптические эффекты в атмосфере, в том числе нелинейные: самодифракция, самофокусировка и т.п. В том числе может начаться банальная ионизация воздуха с рассеянием лазерного пучка на получающейся плазме. Поэтому плотность мощности в таких лазерных пучках всегда ограничена. И поразить удается только специально подобранные цели без защитного покрытия в идеальных условиях (отсутствие тумана, дождя и тп).
Практике по Ansible вам еще учиться и учиться, на мой личный взгляд. :) Для начала стоит осознать, что Ansible - это не запускалка баш-команд, как в вашем коде.
Это какой-то треш, простите. Использовать парсинг вывода дебага ansible в json формате с помощью однострочника на баше для извлечения значения одного ключа для записи в файл инвентаря, чтобы вызвать еще один башсибл?
Если вы проводите обновление путем накатки плейбука и обновления пакетов наживую, то по факту у вас получаются не эквивалентные образы. Различие точно будет набегать между тестовой версией и продакшеном, и даже между нодами одного кластера может со временем набежать заметная разница в конфигурации тех же пакетов и библиотек.
Пересборка образа занимает примерно то же время, что и накатка плейбуки на поднятые голые инстансы. Но при этом есть нормальная возможность того же масштабирования кластера. И получается нормальная immutable infrastructure.
Этот ваш SIGHUP прекрасно делается через правильно сделанный systemd юнит, который все равно нужен.
Кстати, а как вы обновляете кластер при таком подходе? Сносите весь кластер, поднимаете с нуля новой версией кода, а потом восстанавливаете данные из бэкапа?
Если все равно делаете образы, то почему сразу туда Vault с необходимыми настройками не запечь? Какой смысл поднимать из образа голый линукс, а потом накатывать на него плейбук для разворачивания Vault? Получается лишняя потеря времени на поднятие кластера. И инфраструктура получается не иммутабельная.
Зачем тут этот башсибл? Что мешало нормальный модуль
copyиспользовать?Не очень понятно, чем именно ansible-pull не устроил? Зачем изобретать свой велосипед?
Какой-то откровенный детский сад в примерах, если честно. Начиная с откровенных антипаттернов вроде
или ignore_errors, и заканчивая непониманием базовых сообщений ansible-lint, при том, что линтер в полном выводе показывает даже ссылки на сами правила, на которых он триггернулся. Ну, и вообще... Текст ошибки "truthy value should be one of [false, true]" что, реально никак не понять без помощи нейросети? Серьезно?
А как у этих хваленых shell-команд с идемпотентностью?
В статье описан не способ противостоять терморектальному криптоанализу, а стойкий к потере устройств и паролей метод хранения шифрованных данных. Потерять телефон или ноут с мастер-паролем и не смочь после этого залогиниться в свою учетку с двухфакторкой - гораздо более реальный риск, чем стать жертвой криптоанализа в исполнении Джека Бауэра и других аналогичных товарищей.
У любого анальгетика ограниченный срок действия. Чуть подождать - и можно снова работать паяльником. Тру-шпионы вместо анальгетика быстродействующий яд используют на такой случай.