Замена STS сертификата на vCenter

Менял я недавно vCenter сертификат с названием «STS Signing Certificate». Делал этот через веб-интерфейс клиента .
После нажатия на «Actions» — «Refresh with vCenter certificate» сертификат в интерфейсе успешно обновился, но появилось уведомление о необходимости всех систем. Я на всякий случай перезагрузил весь vCenter.  Сертификат как видно на скриншоте выдался на 8 лет до 2033 года. После этого я зашел по ssh на vCenter и запустил скрипт vCert.sh , с помощью которого проверил статус сертификатов.  В отчете  работы скрипта показывалось несколько ошибок. Путем некоторых манипуляций я перевыпустил еще раз «STS Signing Certificate». При такой манипуляции скрипт выпустил сертификат уже только на 2 года, при этом некоторые ошибки все еще висели:
«Checking VMDir certificate» и «Check STS VECS store configuration»

Для решения проблемы с «Checking VMDir certificate» я для начала выгрузил  отчет, который может сгенерировать скрипт vCert. В нем нашел такой сертификат:
Service Principal (Solution User) Certificates
Service Principal: WebClient_2014.05.19_021659
Issuer: O=VMware, Inc., OU=LogBrowser_2014.05.19_021659, CN=VMWARE/emailAddress=support@vmware.com
Subject: O=VMware, Inc., OU=LogBrowser_2014.05.19_021659, CN=VMware default certificate/emailAddress=support@vmware.com
Not Before: May 18 09:18:50 2014 GMT
Not After : May 16 09:18:57 2024 GMT
SHA1 Fingerprint : C6:7A:73:97:5C:CB:42:AC:48:55:72:0B:5E:8D:C7:5E:7B:0B:D9:FD
Signature Algorithm: sha256WithRSAEncryption
Subject Key Identifier:
Key Usage:
|_Digital Signature
|_Key Encipherment
|_Data Encipherment
Extended Key Usage:
|_TLS Web Server Authentication
Subject Alternative Name entries:
|_DNS:VMWARE
Other Information:
|_Is a Certificate Authority: No
|_Issuing CA in VMware Directory/VECS: No

Из-за него и возникала эта ошибка. Для его удаления я зашел в пункты меню 3 и затем 10, где скрипт vCert ругался на неиспользуемый сертификат (смотри скриншот ниже).  Я его удалил и после этого ошибка «Checking VMDir certificate» пропала

С ошибкой «Check STS VECS store configuration LEGACY» побороться оказалось также просто,  необходимо выполнить  команды
sed -i 's/STS_INTERNAL_SSL_CERT/MACHINE_SSL_CERT/' /usr/lib/vmware-sso/vmware-sts/conf/server.xml
/usr/lib/vmware-vmafd/bin/vecs-cli store delete --name STS_INTERNAL_SSL_CERT

и затем рестартовать одну из служб

service-control --restart vmware-stsd

Если закончилось место на vCenter

В случае, если место на одном из разделов  vCenter заканчивается или оно закончилось, то, логично, надо попробовать его очистить. Но у меня дело в том, что раздел /storage/log заполнился только на 80% при этом он занимает только 10 ГБ, поэтому проще его увеличить в 2 раза. Что для этого нужно?
1) определяем какие логические тома у нас сигнализируют о нехватке места
df -h
2) сопоставляем диски с точками монтирования
lsblk
3) сопоставляем диски и шины SCSI
lsscsi
4) расширяем диск виртуальной машины, у которой номер шины совпадает с найденным командой lsscsi (скриншот я сделал уже после расширения диска)

5) скриптом /usr/lib/applmgmt/support/scripts/autogrow.sh расширяем диск vCenter. После выполнения скрипта df -h убеждаемся, что диск расширился

Обновление прошивки сетевой карты HP приводит к ее сбою

На днях обновлял прошивки на серверах HP поколения G10. Для этого есть  образ P81142_001_gen10spp-2025.03.00.00-SPP2025030000.2025_0319.35.iso — официальный от HPE.
Когда очередь подошла к серверу ProLiant DL360 Gen10 с установленной сетевой платой HP FlexFabric 10Gb 2port 534FLR-SFP+, то по началу все прошло успешно. Сервер обновил 5 прошивок и перезагрузился. Но, как только загрузился гипервизор ESXi, стало понятно что пошло что-то не по плану — гипервизор не видел сетевую плату. В настройках BIOS плата тоже не была видна
Попробовал сначала выполнить Cold Boot- не помогло. Попробовал откатить System ROM на предыдущую версию — не помогло. Попробовал спросить Deepseek — он ничего умного не сказал.
К слову, патч который ставится на сетевую плату выглядел так:

А так выглядел список того, что у меня требовалось обновить, за исключением 4 пункта — он тут выключен, т.к. это уже другой сервер с такой же конфигурацией и здесь я обновление прошивки сетевой карты отключил

И вот некоторое время пришла идея отключить шину PCI и заново ее включить. Заходим в RBSU — PCIe Device Configuration

Выбираем слот шины PCIe , в котором должна отображаться сетевая карта и выбираем PCIe Device Disable — Disabled.

На скриншотах сетевая карта уже видна, у вас же это название не будет отображаться. Далее сохраняем настройки и перезагружаемся. Я загрузил полностью операционную систему и затем ее перезагрузил, снова зайдя в эти настройки и включил PCI-устройство. Снова сохранил настройки, перезагрузился и, о чудо, сетевая карта снова стала доступной.
Теперь можно спать спокойно 🙂

Бекап логов виртуального MS SQL средствами Veeam Backup

Развитие Veeam Backup не стоит на месте. Уже достаточно давно в нем появилась возможность делать бекап логов MS SQL другим способом, в случае если сервер не физический, а в виде виртуальной машины. Как известно, всегда было это сделать 2 способами:
1) по сети,  подключаясь по протоколам rpc и smb к шаре admin$ для установки временной службы. После завершения сеанса бекапа логов, служба удалялась
2) через API ESXi (VIX). Логика аналогичная первом варианту — копировался exe файл внутрь ВМ, он запускался как служба. После сеанса все удаляется.
Оба эти способа были очень не стабильны (по крайней мере у меня). Могло такое быть, что время самого бекапа удлинялось, бекап логов завершался ошибками или он переставал делаться вовсе, не сообщая о проблемах.
VeeamТеперь же есть новый способ — ставится постоянный агент на сервер, логи которого требуется резервировать.
Каков порядок настройки?
1) ставим на виртуальную машину следующие компоненты
Veeam Guest Agent
Veeam Transaction Log Backup Service
Veeam Installer Service
Все их можно взять с сервера Veeam Backup & Replication в каталоге
C:\Program Files\Veeam\Backup and Replication\Backup\Packages
В результате в установленных программах и в сервисах должна быть такая картина:

2) заходим в настройки задания бекапа логов и ставим галочку у пункта «Use persistent guest agent»

Use persistent guest agent
После всего этого сможете заметить, что время на бекап логов сократится в разы

Синий экран с кодом ошибки 0x0000007B

После бекапа виртуальной машины средствами Veeam Backup на виртуализации proxmox и последующего восстановления на хосте ESXi, виртуальная машина в некоторых случаях у меня не запускалась. Сразу при загрузке возникал синий экран и код ошибки 0x0000007B. В моем случае все эти ошибки возникали на виртуальных серверах с Windows Server 2003 (да-да, до сих пор у меня встречается такой хлам).
Для решения данной проблемы надо воспользоваться старым iso-образом
Hiren’s BootCD, в котором есть скрипт fix_hdc.cmd для правки реестра
Для его запуска надо пройти в меню Programs — Registry (смотри скриншот выше) и ответить на пару вопросов скрипта.

Переезд на новый домен

Как некоторые наверно заметили, вчера я настроил переадресацию на мой новый домен для личных заметок — vinote.ru. Решил больше не продлевать домен onix.me. Во первых — он очень не выгоден для сайта с небольшим трафиком, во вторых — название сайта никак не ассоциировалось с его содержанием. Заодно еще получу небольшой опыт переезда сайт на другой домен.  В дальнейшем еще возможны различные проблемы с доступностью, но постараюсь надолго это не затягивать. Спасибо, что читаете мои записи.

vROPS не синхронизирует Metadata (vSphere Tags) из VMware vSphere

Боролся с такой проблемой — перестал получать обновления vSphere Tags  в систему VMware Aria Operations (vRops).  Нашел статью у вендора, где решается подобная проблема. В логах я не нашел такую ошибку как указано в статье, но мне помогла рекомендация рестартовать службу. В 7 версии Vsphere она называется «vAPI Endpoint». Её перезагрузка мне и помогла.

Канал в телеграм

Привет! Создал недавно канал в Telegram.
Он совсем не связан с IT. Мне интересно фотографировать, поэтому решил свои ежедневные фото куда-то выкладывать. Самому же потом будет интересно смотреть как проходила жизнь день за днем. Заходите https://t.me/photodaylife

Ошибка «Unable To Reach The AWCP Endpoint : https://awcp.air-watch.com/provisioningportal/CSRGenerationHandler.aws/v1»

Столкнулся с такой ошибкой при попытке обновления сертификата APNs на Workspace One:Статья на сайте разработчика мне никак не помогала, т.к. она была старая и решение той проблемы было выполнено давно.
Я начал проверять сетевой трафик Wireshark и обнаружил такое поведение:
на стандартное приветствие TLS Handshake: Hello


удаленный сервер awcp.air-watch.com отвечает Handshake Failure

После этого вспомнили, что на серверах Workspace One ранее были отключены старые ключи шифрования. Включили их снова и после этого ошибка пропала.