Комментарии 9
Не думал, что новый редактор такой неудобный, прошу прощения за корявые листинги. Надеюсь ни у кого не пойдет кровь из глаз.
Столкнулся с проблемой - при перезапуске сервисов (service-control --start --all) не запускалась служба vpostgres. Начал копать, обнаружил что она подвисает на моменте, когда пытается получить список из стора TRUSTED_ROOT_CRLS. Отдельно сервис vpostgres запустился, правда заняло это несколько минут.
В этом сторе очень много CRL-сертификатов - около 3000. Это нормально, так должно быть?
![](https://habrastorage.org/getpro/habr/upload_files/54b/e14/d8a/54be14d8a28573418d5d47b6a0ca4bf7.png)
Тут вылезла ещё одна бага после продления сертификата MACHINE_SSL_CERT кнопкой renew в админке vCenter 7.0 из-за чего падала проверка в VDT:
Traceback (most recent call last):
File "/root/vdt/scripts/vc_auth_cert_check.py", line 557, in trustCheck
elif self.subjectkey in self.authkey:
TypeError: 'in ' requires string as left operand, not NoneType
В сертификате не было кучи полей, видимо из-за отсутствия дефолтного certool.cfg. Так что хотя бы в первый раз надо продлить его через certificate-manager. И не забудьте заменить сертификат VMDIR на новый.
И ещё один баг при обновлении в рамках ветки 7.0, когда ссылка на загрузку сертификатов VMCA стала выдавать 404 из-за пропавшего линка на директорию:
Проверяем наличие сертификатов в линкуемой директории:
ls -l /var/lib/vmware-vpx/docRoot/certs/
В ней должно быть два файла вида abcd0123.0 и abcd0123.r0, которые периодически выгружает демон vmafdd.
Пересоздаём линк на директорию из которой vpxd собирает архив и отдаёт клиентам при клике по ссылке на главной странице:
ln -s /var/lib/vmware-vpx/docRoot/certs /etc/vmware-vpx/docRoot/certs
Недавно опубликовали прекрасный инструмент для мониторинга и управления сертификатами (включая Solution Users) - vCert (virtham.us)
Наткнулся на ещё один баг после штатного продления сертификата STS через админку vCenter Server 7.0. После неё задания от плагинов даже после перерегистрации в MOB вместо нормальных описаний отображались лейблами вида:
com.ibm.tsm.tasks.backup_vm_scheduled.label
А в vCert.sh задублировалась проверка и ругалась на истёкший сертификат:
Checking STS Tenant 1 signing certificate EXPIRED
Checking STS Tenant 1 signing certificate EXPIRED
Checking STS Tenant 1 signing certificate VALID
Checking STS Tenant 1 CA certificate VALID
Решилось удалением старого (TenantCredential-1) сертификата из базы stsd через LDAP, который заменил новый (TenantCredential-2) после продления через админку.
Выгружаем сертификаты из базы и проверяем список доверенных, где должен быть только новый сертификат:
ldapsearch -h localhost -p 389 -D "cn=administrator,cn=users,dc=vsphere,dc=local" -W -b "cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local" "(objectclass=vmwSTSTenantCredential)"
ldapsearch -h localhost -p 389 -D "cn=administrator,cn=users,dc=vsphere,dc=local" -W -b "cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local" "(objectclass=vmwSTSTenantTrustedCertificateChain)"
Удаляем старый после создания офлайн снепшота VCSA и перезагружаемся:
ldapdelete -h localhost -p 389 -D "cn=administrator,cn=users,dc=vsphere,dc=local" -W "cn=TenantCredential-1,cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local"
В базе stsd много всякого мусора после обновлений с миграциями и никакие сбросы её не чистят.
Продлеваем сертификаты vCenter правильно