Использование снапшотов LVM как точки восстановления

Это вольный перевод найденного в инете комментария. В ubuntu синтаксис немного отличается в части указания названия томов, например не "lvrename lvm root root-old", а "lvrename /dev/lvm/root /dev/lvm/root-old". В остальном все соответствует.

Потребуется несколько перезагрузок.

Для начала переименуем оригинальный root во что-то новое, чтобы дать это имя снапшоту.:

# lvrename lvm root root-old

# lvcreate -n root -s lvm/root-old -L 10G

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

# lvrename lvm root root-new

# lvrename lvm root-old root

# reboot

Если мы хотим откатить изменения и вернуть все как было, выполняем (из старой системы)

# lvremove lvm/root-new

Если мы хотим применить изменения, выполняем (из старой истемы)

# lvconvert --merge lvm/root-new

или из новой системы

# lvrename lvm root root-new

# lvconvert --merge lvm/root-new

# lvrename lvm root-old root

# reboot

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

Тормозит Lightroom 5, неожиданное решение

Долгое время страдал от диких тормозов в лайтруме. Тормоза были при скроллинге фоток во вьювере, при их обработке - решительно во всех местах лайтрума, причем независимо от размера каталога. В инете можно нагуглить приличное количество решений проблемы - изменение размера кэша Camera RAW, или включение поддержки использования видеокарты (в какой-то версии лайтрума) - но все они мне не помогли.
Совершенно неожиданно проблема таилась в совершенно неожиданном месте - в галочке "Использовать системное сглаживание шрифтов"

Невероятно, но факт - когда-то я видимо зачем-то снял эту галку и забыл о ней, и все это время страдал от тормозов, но после возвращения этой опции назад тормоза улетучились! Что это было - непонятно, но надеюсь кому-то эта галка поможет как и мне =))

Как избавиться от вируса EIMG001.exe и NsCpuCNMiner32.exe в большой сети

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

Для этого нужно иметь под рукой файлы вируса (большой самораспаковывающийся архив EIMG001.exe и файлы самого майнера, которые можно достать из него:  NsCpuCNMiner32.exe и NsCpuCNMiner64.exe). Политика запрета будет выглядеть примерно так (кликабельно):

Указаны два варианта: через Software Restriction Policies, или Application Control Policies - оба в целом равноценны. В обоих случаях файлы можно добавлять по имени или по хэшу, предпочтителен второй вариант на случай попыток вируса переименовать исполняемые файлы.

Как перенести Linux с одного mdamd-raid на другой

Сегодня я бы хотел поговорить о такой серьезной с точки зрения надежности вещи, как линуксовый софтварный рейд. А, вернее, показать, как можно спасти систему, которая требует замены дисков, на которых она и была установлена. Я рассмотрю 2 дистрибутива линукса - CentOS 7 и Debian 8 - которые будут поставлены в идентичные исходные условия. Также, так как тема мне кажется достойной лишней наглядности, помимо традиционных скриншотов и текста, в конце я оставлю ссылки на видео, в которых полностью показана вся процедура: от момента установки исходной системы, до восстановления ее работоспособности на новых дисках.

Общая часть: приготовление и восстановление бэкапа

В качестве исходной системы у нас Дебиан/Центось, установленные на один ext4-раздел, который зеркалится на 2 физических диска (скриншоты с центоси).

Легким движением руки выдираем один из дисков, создавая деградацию рейда.

Время делать бэкап =)

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

tar -czpvf /mnt/backup.tgz --exclude=/dev --exclude=/proc --exclude=/sys --exclude=/mnt /  

Эта команда создаст сжатую копию всего корня, за исключением трех директорий содержимое которых регенерируется автоматически, и директории /mnt, в которой у нас в данном случае нет ничего, кроме файла бэкапа.

Когда бэкап приготовился, гасим машину и устанавливаем 2 новых харда, которые составят новое зеркало.
Также я использую убунтовый live cd "Boot-Repair" для дальнейших операции, но, собственно, встроенной функцией автоматического восстановления пользоваться не буду. Так что на месте этого диска может быть любой другой Live CD, главное чтобы совпадала архитектура и были доступны утилиты mdadm, chroot, и parted (в моем случае он идет с GUI)

Итак, теперь у нас есть машинка с тремя дисками: половинка бывшего рейда, от которой нам нужен только файл бэкапа; и два новых неотформатированных диска.

После загрузки с лайва, закрываем все выплывающие окошки и открываем редактор разделов. sda1 - бэкап, sdb и sdc - пустые

На дисках sdb и sdc создаем таблицу разделов (Device -> Create Partition Table). Я использую GPT, потому что она подразумевает возможность использования разделов большого объема, а также создает дополнительные сложности для восстановления системы.

После создания таблицы, на обоих дисках создаем симметричную конфигурацию: 2 неотформатированных раздела - первый большой под систему, второй маленький (я оставил буквально 10 мегабайт в конце диска).

Второй раздел нужен для установки загрузчика GRUB2 на GPT. Также необходимо этим разделам добавить флаг. После применения разметки, нужно кликнуть правой мышкой по разделу, выбрать Manage Flags и отметить флаг bios_grub. Это необходимо сделать также на обоих новых дисках.

Теперь, когда разделы подготовлены, открываем терминал и первым делом я устанавливаю mdadm, так как его нет на этом Live CD.

1 2	sudo bash apt install mdadm

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

(Warning! Обратите внимание, что в результате выполнения первой команды, при восстановлении центоси создается устройство /dev/md127, а при восстановлении дебиана - /dev/md0. Нижеследующий блок справедлив для центоси)

1 2 3 4 5 6 7

# сканируем систему на наличие рейдов # эта команда создаст устройство, в моем случае /dev/md127 - нашу # половинку зеркала с бэкапом mdadm --assemble --scan # создаем папку /mnt/backup и монтируем в нее найденный рейд mkdir /mnt/backup mount /dev/md127 /mnt/backup

Файлик бэкапа у нас в каталоге /mnt/backup/mnt/, теперь нужно приготовить новый рейд и залить на него бэкап.

1 2 3 4 5 6 7 8 9 10 11 12 13

# создаем новое устройство рейда # имя может быть любым незанятым, # например /dev/md1 # --level=1 - зеркало # --raid-devices=2 - 2 диска в рейде mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1 # форматируем новый рейд mkfs.ext4 /dev/md1 # создаем директорию и монтируем рейд в нее mkdir /mnt/root mount /dev/md1 /mnt/root # распаковываем архив tar -xpvf /mnt/backup/mnt/backup.tgz -C /mnt/root/

После распаковки нужно чрутнуться в корень восстанавливаемой системы.

1 2 3 4 5 6 7 8 9 10 11

# создаем недостающие директории mkdir /mnt/root/dev mkdir /mnt/root/proc mkdir /mnt/root/sys mkdir /mnt/root/mnt # к первым трем монтируем рабочие директории лайва mount -o bind /dev/ /mnt/root/dev/ mount -o bind /proc/ /mnt/root/proc/ mount -o bind /sys/ /mnt/root/sys/ # чрутимся chroot /mnt/root/

С этого момента пути восстановления дебиана и центоси расходятся

Debian

После чрута выполняем команду 

blkid

Она покажет ID нашего рейда /dev/md1.

Этот ID нужно прописать в /etc/fstab вместо имеющегося там.

Далее выполняем

1 2 3 4 5 6 7 8 9 10

# прописываем в конфиг данные актуального рейда mdadm --detail --scan | grep md1 > /etc/mdadm/mdadm.conf # пересобираем initrd update-initramfs -u # обновляем конфиг загрузчика update-grub2 # устанавливаем загрузчик на оба # физических диска grub-install /dev/sdb grub-install /dev/sdc

Собственно всё. Вытаскиваем старые диски, отключаем сидиром, перезагружаемся и видим наш дебиан в целости и сохранности.

CentOS

С центосью возни чуть больше, чем с дебианом, но ненамного.

После чрута правим /etc/fstab, заменяя айдишник корня на имя устройства. В нашем случае /dev/md1
(Attention! на картинках ниже везде используется /dev/md0 - не обращайте внимания, просто я его так назвал во время экспериментов с центосью)

После этого правим /etc/dracut.conf, раскомментируем параметр mdadmconf и присвоим ему значение yes.

Далее выполняем 

mdadm --detail --scan | grep md1

Эта команда выдаст ID нашего нового рейда.

Этот ID нужно указать в файлике /etc/default/grub вместо старого

Теперь

1 2 3 4 5 6 7 8 9 10 11 12 13 14

# прописываем в конфиг данные актуального рейда mdadm --detail --scan | grep md1 > /etc/mdadm.conf # пересобираем initrd, # смотрим на ВАШ файлик *.img в директории /boot # и меняем версию по аналогии, если она отлична от моей dracut /boot/initramfs-3.10.0-514.el7.x86_64.img 3.10.0-514.el7.x86_64 --force # обновляем конфиг загрузчика grub2-mkconfig -o /boot/grub2/grub.conf # устанавливаем загрузчик на оба # физических диска grub2-install /dev/sdb grub2-install /dev/sdc # создаем специальный файлик, без которого магии не случится touch /.autorelabel

Перезагружаемся (один раз система перезагрузится автоматически - это нормально) и радуемся ожившей системе.

Вот и сказке конец

Обещанное в начале видео:

Abaqus: Unable to validate FLEXnet server

На днях с коллегой  столкнулись с проблемой при установке abaqus, на которую потратили бессовестно много времени. Ошибка возникала при указании сервера лицензий (FlexLM) и в сокращенном виде звучала как "Unable to validate FLEXnet server".

Сервер лицензий при этом исправно работал, пинговался и, в целом, не показывал хоть сколько-нибудь адекватных предпосылок для такого облома. К несчастью выгуглить реальную причину так и не удалось ("Technical details" инсталлятора оказались бесполезны), попытки обновить сервер до последней версии к успеху не привели, а причина оказалась довольно проста. Выяснить ее удалось, установив рядом с абакусом сервер лицензий (но без запуска).

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

А потом, добавив в hosts имя сервера лицензий (в нашем случае мы работаем с айпишниками), повторили запрос но уже подставив это имя. И о чудо - утилита выдала в консоль список доступных лицензий. 

Оказалось, что FlexLM крайне щепетильно относится к запросам клиентов, и требует чтобы запрос шел или по имени, или по айпишнику, и зависит это от того, что написано в файлике с лицензией! В нашем случае там было указано имя сервера, поэтому при попытке обратиться по IP - сервер считал что спрашивают, возможно, кого-то другого =) Исправить проблему оказалось довольно просто - всего-то нужно поменять имя на IP в первой строке файла лицензий. Можно было бы обращаться к серверу по имени - в большинстве случаев это вообще более правильный подход, но в конкретно нашем случае первый вариант был много проще.