Понадобилось для мониторинга баз. Не все, но наиболее распространенные значения. Взято с MSExchange 2010
Get-MailboxDatabaseCopyStatus -Identity * | ForEach-Object {$_.Status.value__}
Get-MailboxDatabaseCopyStatus -Identity * | ForEach-Object {$_.Status}3 ⇒ Failed 4 ⇒ Seeding 5 ⇒ Suspended 6 ⇒ Healthy 7 ⇒ ServiceDown 8 ⇒ Initializing 9 ⇒ Resynchronizing 11 ⇒ Mounted 12 ⇒ Dismounted 13 ⇒ Mounting 15 ⇒ DisconnectedAndHealthy 16 ⇒ FailedAndSuspended 17 ⇒ DisconnectedAndResynchronizing
Поимел тут дамп базы данных — текстовик на 40 гигов.
Для понимания проблемы: дамп состоит из двух основных блоков
[блок команд создания таблиц]
[блок команд вставки строк]
Первый блок небольшой, на 150 строк. Второй – все остальные гиги, которые выглядят как
Импортируется обычно все командой
cat dump.sql | mysql basename
то есть файл просто читается в пайп и mysql выполняет команды из него.
И в чем подстава.
Во-первых у дампа в начале не хватало пары команд — это выяснилось сразу при попытке импорта и легко выгуглилось. Во-вторых — в блоке импорта строк, ВО ВСЕХ строках отсутствовало начало: «INSERT INTO tablename VALUES»
Я не нашел такой чудо-редактор, который смог бы на редактирование хотя бы открыть этот мегадамп, поэтому к сути.
Сделал два вспомогательных файла:
1.sql – с недостающими командами,
2.sql – с первыми 150 строками, которые про создание таблиц, и первым недостающим «INSERT INTO tablename VALUES» — для начала блока импорта — который я добавил вручную.
Свел задачу к:
— как бы в один поток прочитать сначала эти два файла,
— а потом третий – только в нем пропустить первые строки, а во оставшихся — заменять концы строк с «);» на «); INSERT INTO tablename VALUES», чтобы каждая новая строка начиналась с корректной команды,
— и все это точно также запихать в пайп и отдать mysql.
Оказывается есть такая магия!
{cat 1.sql 2.sql; sed -n -e 's/);/); INSERT INTO tablename VALUES /g;151,$ p' dump.sql;} | mysql basename
конструкция команд внутри {} дает общий вывод, который можно направить в пайп и в mysql.
cat 1.sql 2.sql - просто читает два файла подряд
чтение основного файла отдаем седу, с двумя его командами
sed -n -e 's/);/); INSERT INTO tablename VALUES /g;152,$ p' dump.sql;
здесь ^-- меняем ";)" на "); INSERT..." --^ ^-- --^ - выводим файл со 151 строки
Долго не мог понять почему возникает сабжевая ошибка. В норме, при включенном vSphere DRS виртуальные машины должны автоматически перекидываться на хосты, на которых непосредственно лежат их файлы (если точнее, симпливити дублирует каждую виртуалку, так чтобы 2 хоста имели полный локальный доступ к ней). В моем же случае виртуалки балансировались классически — по загруженности хостов, то есть vmotion работал, но по какой-то причине игнорировал симпливитийную привязку к хранилищу.
Оказалось, причина была в установленной галке «For availability, distribute a more even number of virtual machines across hosts» в настройках vSphere DRS. Вероятно задача равномерного распределения оказалась приоритетнее и полностью отрубила балансировку по доступу к хранилищу. Вывод: если возникла подобная проблема — стоит начать с того чтобы выставить дефолтные настройки DRS
Также могу порекомендовать цикл постов о принципах работы Simplivity:
Удивительно, как в нашу жизнь влетают новые площадки — соцсети, мессенджеры — и как новых же пользователей на них пытаются завлечь старыми ШОКИРУЮЩИМИ интересностями.
Вот телеграм-канал рекламирует себя:
Читать продолжение я, конечно, не стал, но подумал — что если загуглить кусок начала этой истории?
Забил в гугл «В 1985 году 13-летний Тайлер Керк (герой фотографии) прошел кастинг на съемку в рекламе шоколадной пасты Nutella» и, первой же ссылкой, получил исчерпывающий обзор этого фейка (копия в веб-архиве), а еще несколькими ссылками ниже — еще один, чуть менее подробный, но датированный еще несколькими годами ранее, а конкретно — 2012-м годом.
То есть, уже минимум в 2012-м (!) данная история была разоблачена, а на современных платформах этот фейк все еще продвигает каналы! Не знаю какой вывод из этого можно сделать и что сказать в заключение, кроме того что: мойте руки перед едой, а также будьте бдительны, используете поисковики, проверяйте информацию — не каждая «удивительная» новость, поразившая вас в самое сердечко, будет столь же безобидной, будучи принятой на веру.
Pixel_Devil пишет:
На двух прошлых стримах мой зритель рассказывал, как в 90х годах он был свидетелем реабилитации неврологических больных при помощи управления в играх для Sega Mega Drive мышцами тела. Я сначала не поверил, но он был настойчив и прислал доказательство.
На скриншоте привожу цитату из книги Юрия Гольдблата «Основы реабилитации неврологических больных» 2017г. Также для управления мышцами в играх использовались консоли Денди.
Собственно, цитата:
При работе с детьми старше 5 лет. подростками и молодежью в 1990-е гг. использовался биокомпьютерный игровой тренажер «Био-Битман», состоявший из игровой приставки «Денди», «Битман» или «Сега» и аппарата ЭМГ-БОС «Миотоник-03». Биопотенциалы тренируемой мышцы после преобразования в этом аппарате изменяли игровую ситyацию на экране телевизора, перемещая транспортные средства со скоростью, зависящей от объема и качества выполняемого движения. Появление или исчезновение, тональность и громкость звукового сигнала также были связаны с достижением порогового интервала выполняемого задания — например, амплитуды тренируемого мышечного сокращения.
(с) Ю. Гольдблат «Основы реабилитации неврологических больных» 2017
Любопытно, что тогда уже возникла в чьих-то умах идея игроизировать лечебный процесс при помощи доступных консолей. Интересно, была ли это первая такая попытка, или игровой формы достигали и раньше, какими-то другими путями?
Скан страницы
Ошибка: «Неустранимая ошибка TLS. Произошла ошибка рукопожатия или, возможно, версия TLS или сертификат, используемые сервером, несовместимы»
Решение: в настройках пролистать до конца, открыть редактор настроек, изменить параметр
security.ssl.enable_ocsp_must_staple = false
Долгое время на своем ноуте (Dell Vostro 5470) не мог заставить по-человечески работать видюху NVIDIA GK208M [GeForce GT 740M], которая по уму должна включаться по запросу приложений, в остальное время уступая работу по отрисовке графики интегрированной интеловской карточке. Все эти Bumblebee нифига не захотели работать, но на вики дебиана (внезапно) нашлась инструкция — как заставить нвидиевский чип работать постоянно (а почему бы, собственно, и нет — энергосбережение мне нафиг не уперлось).
Коротенько как это сделать при использовании SDDM.
Сначала накатываются дрова
wajig install nvidia-driver
Выясняются ID шины для обеих видюх
lspci
... 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) ... 09:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1) ...
Теперь создаем файл /etc/X11/xorg.conf (обратите внимание, что запись ID в нем отличается от вывода lspci)
Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "PCI:9:0:0"
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration"
EndSection
Section "Device"
Identifier "intel"
Driver "modesetting"
BusID "PCI:0:2:0"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSectionТак как я использую SDDM в качестве дисплей-менеджера, то для него в файл /usr/share/sddm/scripts/Xsetup дописываются строки:
xrandr --setprovideroutputsource modesetting NVIDIA-0 xrandr --auto xrandr --dpi 96
Ну и чтобы не было тиринга, в конец файла /etc/modprobe.d/nvidia.conf дописывается строка
options nvidia-drm modeset=1
после чего выполняется команда
update-initramfs -u
Теперь после перезагрузки ускорение работает.
Источник: https://wiki.debian.org/NVIDIA%20Optimus#Using_NVIDIA_GPU_as_the_primary_GPU
Данный пост возник в результате моей собственной попытки понять, как именно можно добиться отказоустойчивости в конфигурации с EFI-загрузчиком и корнем системы на RAID-массиве. Базовая проблема заключается в том, что разделы с файлами EFI не могут быть расположены на рейде, что приводит к курьезной ситуации, когда сам линукс установлен на рейд, но загрузчик оказывается только на одном диске. Как оказалось, выход конечно есть, но требует дополнительных манипуляций. Я пошел длинным путем и решил описать установку дебиана через Live-CD при помощи debootstrap, что позволяет акцентировать внимание на момент установки загрузчика.
В самом низу будет видео, демонстрирующее все описанные ниже шаги.
Исходная позиция: система с двумя неразмеченными дисками, загруженная с Live-CD
Размечаем первый диск.
Следующий набор команд создаст на диске GPT-таблицу c двумя разделами: 1 — EFI-раздел на 100 Мб, 2 — раздел под будущее зеркало, размером в 10 Гб
fdisk /dev/sda g n 1 [default] +100M t 1 n 2 [default] +10G w
Скопируем конфигурацию разделов на второй диск, чтобы они были идентичны
sfdisk -d /dev/sda | sfdisk /dev/sdb
Отформатируем первые разделы дисков в FAT32
mkfs.fat -F32 /dev/sda1 mkfs.fat -F32 /dev/sdb1
Создадим зеркало md0 из вторых разделов дисков sda и sdb
mdadm --create --metadata=0.90 /dev/md0 -l 1 -n 2 /dev/sda2 /dev/sdb2
Форматируем и монтируем рейд
mkfs.ext4 /dev/md0 mount /dev/md0 /mnt
При помощи утилиты debootstrap скачиваем и разворачиваем на смонтированном рейде основу дебиана
debootstrap --arch amd64 stable /mnt https://deb.debian.org/debian
Переходим в свежую систему при помощи chroot
mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt
Устанавливаем пароль root
passwd
Создаем директорию под файлы EFI
mkdir /boot/efi
Выясняем ID рейда и прописываем содержимое fstab
blkid /dev/md0 vi /etc/fstab
UUID="..." / ext4 errors=remount-ro 1 1 /dev/sda1 /boot/efi vfat umask=0077 0 1
Важно: рейд указываем через ID, EFI-раздел — по имени.
Монтируем согласно fstab (рейд уже смонтирован, то есть по факту домонтируем EFI)
mount -a
Устанавливаем в нашу систему поддержку рейдов, что потребуется в дальнейшем для корректной работы загрузчика.
apt update apt install mdadm
Опционально настроим локали и часовой пояс
apt install locales dpkg-reconfigure locales dpkg-reconfigure tzdata
Установим ядро
apt install linux-image-amd64
Установим и настроим загрузчик
apt install grub-efi update-grub2
Проинсталлируем GRUB на диски
grub-install /dev/sda grub-install /dev/sdb
В момент инсталляции загрузчика на sda каталог /boot/efi/ заполняется файлами. Для отказоустойчивости необходимо скопировать эти файлы с sda1 на sdb1…
mkdir /boot/efi2 mount /dev/sdb1 /boot/efi2 cp -RT /boot/efi /boot/efi2
… и добавить второй диск в список UEFI, чтобы система знала, что на нем тоже есть все необходимые файлы
efibootmgr -c -g -d /dev/sdb -p 1 -L "debian 2" -l '\EFI\debian\shimx64.efi'
Таким образом у нас оба диска будут в списке загрузчика и при смерти любого из них система будет способна загрузиться.
Используя утилиту efibootmgr в дальнейшем можно удалить из списка замененные диски, а для добавленных дисков нужно будет повторить шаги второго диска:
1. скопировать таблицу разделов,
2. отформатировать первый раздел и скопировать на него файлы EFI,
3. добавить второй раздел в существующий рейд,
4. заинсталлировать на диск grub,
5. добавить этот диск в UEFI.
Выходим из chroot
exit
Перезагружаемся
reboot
Обеспечить отказоустойчивость системы на рейд-массиве можно путем создания EFI-раздела на каждом диске, копировании на него файлов EFI и добавлении в список загрузчика при помощи утилиты efibootmgr.
Видео, в котором я последовательно показываю весь процесс с момента создания виртуальной машины:
Прошло 3 года с последнего теста Google Translate (посвященного их нейросети, которая с 2017го года должна эпически улучшать качество перевода). Для этого я сделал несколько прямых и обратных переводов — пришло время повторить!
Как и в прошлые разы — перевод туда и обратно.