Не думаю, что номер "утекает". Скорее мошенники просто берут произвольный номер, а в системе быстрых платежей можно совершенно легально по этому номеру проверить, привязан ли он к любому из банков и узнать имя, отчество и первую букву фамилии человека, к счету которого этот номер привязан в этом банке.
Чуть раньше до этого мы видели сцену после сражения с Саруманом в Изенгарде, когда волшебник уже лишился всех своих сил. И когда Фродо произнес следующее:
Тут у вас ошибка — Фродо никогда не встречался с Саруманом в Изенгарде, он в это время был с Сэмом на пути в Мордор. Указанная сцена была уже в самом конце, после возвращения в Шир.
Хорошо бы еще добавить в статью про использование GTID при репликации — довольно давно появилось уже, и реально полезно и удобно в большинстве случаев.
Для вытягивания информации со сбойного диска рекомендую обратить внимание на ddrescue — гораздо удобнее, чем копировать данные с умирающего диска в образ обычным dd. И больше шансов успеть утянуть максимум информации, в случае если ошибки чтения диска прогрессируют.
Подготавливаем crypttab для созданного шифрованного раздела:
blkid /dev/sda3
echo LVM UUID=НАШ_UUID_ИЗ_ВЫВОДА_ПРЕДЫДУЩЕЙ КОМАНДЫ crypt_disks luks,discard,initramfs,keyscript=decrypt_keyctl >> /etc/crypttab
Обновляем initramfs:
update-initramfs -u -k all
После этого хорошо бы проверить, что внутри нашего нового initramfs попала информация о нашем зашифрованном разделе. Я делаю примерно так:
unmkinitramfs /boot/НАШ_INITRAMFS /tmp/initramfs
и проверяю в debian 9 содержимое /tmp/initramfs/conf/conf.d/cryptroot, а в debian 10 — содержимое /tmp/initrams/cryptroot/crypttab
Далее — по накатанной дороге:
pvcreate /dev/mapper/LVM
vgcreate vg0 /dev/mapper/LVM
... and so on ...
и работаем с LVM, как нам удобно. В частности, root я обычно кладу туда же (boot оставляю нешифрованным на /dev/sda1).
После всех этих операций получаем следующее:
при перезагрузке на стадии initramfs загрузка приостанавливается, и поднимается dropbear, к которому можно подключиться по ssh от имени пользователя root по ключу, публичную часть которого мы задали на стадии настройки. При подключения по ssh после аутентификации мы получаем предложение ввести passphase, которую мы задали при формировании зашифрованного раздела. Так же passphase можно ввести в обычной консоли с клавиатуры. После ввода корректной passphase производится разблокировка диска, соединение ssh сбрасывается, dropbear останавливается и продолжается нормальная загрузка (при этом зашифрованный диск уже доступен, lvm с него подцепляется автоматически).
Конечно, при желании, в crypttab можно запихнуть не один зашифрованный раздел, а несколько. Например, предположим, что у нас есть желание получить зашифрованный swap на разделе /dev/sda2:
Если при этом задать тот же passphase, что и для первого зашифрованного раздела, то при загрузке его потребуется ввести один раз, т.к. скрипт decrypt_keyctl в initramfs кеширует введенное значение и пытается применить его ко всем дискам, которые требуется расшифровать. Если поставить разные passphase, то придется по очереди ввести их все.
Функция в целом приятная, из того, что хотелось бы добавить по результатам использования — определение оператора и региона, чтобы не держать для этой цели отдельное приложение. Определение оператора для мобильных — обязательно с использованием БДПН (база данных перенесенных номеров), так как MNP никто не отменял.
А что в таких случаях делают? И что делать пациенту, если такое произошло? И, кстати, как он сам может быстро понять, что у него проблемы с флэпом? Вопрос для меня не праздный — сам после LASIC'а, 10 лет прошло после операции, но тем не менее.
У моей бабушки тоже был рак груди в 30 с небольшим лет. Это было в 60-ые годы, врачи не верили, что она выживет, однако лечить не отказались. Грудь удалили, были химии, облучения, но болезнь отступила… Она очень любила жизнь и очень хотела жить, несмотря ни на что, думаю, это сыграло для нее ключевую роль. Она умерла в этом сентябре, не дожив 20 дней до 85 лет. Сердце. Но в заключении вскрытия оказалось, что рак тоже вернулся — в бронхе.
Не думаю, что номер "утекает". Скорее мошенники просто берут произвольный номер, а в системе быстрых платежей можно совершенно легально по этому номеру проверить, привязан ли он к любому из банков и узнать имя, отчество и первую букву фамилии человека, к счету которого этот номер привязан в этом банке.
Тут у вас ошибка — Фродо никогда не встречался с Саруманом в Изенгарде, он в это время был с Сэмом на пути в Мордор. Указанная сцена была уже в самом конце, после возвращения в Шир.
Хорошо бы еще добавить в статью про использование GTID при репликации — довольно давно появилось уже, и реально полезно и удобно в большинстве случаев.
Наверно Вы имели введу CloudFront, если речь про AWS
Для вытягивания информации со сбойного диска рекомендую обратить внимание на ddrescue — гораздо удобнее, чем копировать данные с умирающего диска в образ обычным dd. И больше шансов успеть утянуть максимум информации, в случае если ошибки чтения диска прогрессируют.
Ещё раз, диски расшифровывается ДО монтирования root-раздела на стадии работы initramfs.
Подтягиваем пакеты и делаем шифрованный раздел — заготовку под LVM
Подготавливаемся к удаленной разблокировке по SSH:
Переносим в dropbear SSH-ключ нашего хоста, чтобы при подключении для разблокировки ssh не ругался на то, что ключ изменился:
Готовим dropbear для удаленной разблокировки пользователем с нашим ssh-ключем:
Подготавливаем crypttab для созданного шифрованного раздела:
Обновляем initramfs:
После этого хорошо бы проверить, что внутри нашего нового initramfs попала информация о нашем зашифрованном разделе. Я делаю примерно так:
и проверяю в debian 9 содержимое /tmp/initramfs/conf/conf.d/cryptroot, а в debian 10 — содержимое /tmp/initrams/cryptroot/crypttab
Далее — по накатанной дороге:
и работаем с LVM, как нам удобно. В частности, root я обычно кладу туда же (boot оставляю нешифрованным на /dev/sda1).
После всех этих операций получаем следующее:
при перезагрузке на стадии initramfs загрузка приостанавливается, и поднимается dropbear, к которому можно подключиться по ssh от имени пользователя root по ключу, публичную часть которого мы задали на стадии настройки. При подключения по ssh после аутентификации мы получаем предложение ввести passphase, которую мы задали при формировании зашифрованного раздела. Так же passphase можно ввести в обычной консоли с клавиатуры. После ввода корректной passphase производится разблокировка диска, соединение ssh сбрасывается, dropbear останавливается и продолжается нормальная загрузка (при этом зашифрованный диск уже доступен, lvm с него подцепляется автоматически).
Конечно, при желании, в crypttab можно запихнуть не один зашифрованный раздел, а несколько. Например, предположим, что у нас есть желание получить зашифрованный swap на разделе /dev/sda2:
Если при этом задать тот же passphase, что и для первого зашифрованного раздела, то при загрузке его потребуется ввести один раз, т.к. скрипт decrypt_keyctl в initramfs кеширует введенное значение и пытается применить его ко всем дискам, которые требуется расшифровать. Если поставить разные passphase, то придется по очереди ввести их все.