Коллеги, добрый день!

В уже далеком по времени, но близком сейчас по погоде январе был проведен небольшой Хакатон составом ИСП РАН, Профископ, Базальт СПО и НТЦ Фобос-НТ.

Целью данной встречи было исследование возможности применения инструмента Natch при анализе решений в контейнерном исполнении, в виде распределенной архитектуры.

Модельным примером стал продукт CodeScoring.

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

Более подробно с процессом подготовки и результатами можете ознакомиться в статье на Хабр!

Поздравляю @aenix_io и @cozystack/@cozystack_ru

Бизнес-модель Ænix заключается в продаже подписки на Ænix Enterprise for Cozystack, в которую входят техническая поддержка с гарантиями по SLA, сопровождение платформы, professional services, а также энтерпрайзная функциональность (например, White Labeling и система биллинга).

Андрей Квапил, CEO Ænix: «Мы долго искали и тщательно выбирали инвестора — команду, которая понимает ценность того, что мы делаем, у которой есть опыт успешного инвестирования в похожие проекты, связи с институциональными инвесторами и потенциальными клиентами, а также опыт консультирования стартапов. И мы рады, что нашим партнером на этом пути стала именно команда Prospective Technologies. Кроме того, я благодарен всей нашей команде, ребятам из Ænix, внешнему сообществу пользователей и контрибьюторов, а также клиентов, которые поверили в нас и оказали серьезную поддержку».

Сергей Негодяев, Управляющий Партнер, Prospective Technologies: «Ænix решает важнейшую задачу для компаний, которым необходим контроль над своей инфраструктурой без потери гибкости современного облака. Вклад Cozystack в CNCF демонстрирует их приверженность инновациям с открытым исходным кодом, и мы рады поддержать их путь».

Ænix, основной разработчик open source-платформы Cozystack, привлек 300 тысяч долларов на стадии seed
https://habr.com/ru/companies/aenix/news/899586/

🛠 VmWare & Hardware version debug

Jenkins runs a powershell script and it creates a VM. Normally it works, but this morning I got this:

 

Virtual Machine [xxx] does not exist
Importing new Virtual Machine
New-VM : 4/4/2025 9:55:27 AM New-VM  An invalid argument "configSpec.guestId" was specified. 
At C:\...\powershell\commonScripts\Initialize-VM.ps1:247 char:14
+ ...    $newVM = New-VM -Name $VMName -ContentLibraryItem $templateObj -Da ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-VM], ViError
    + FullyQualifiedErrorId : ViCore_VMServiceImpl_DeployFromLibraryItem_ViNetException,VMware.VimAutomation.ViCore.Cm    dlets.Commands.NewVM

The first idea was that something has been changed in the powershell wrapper. But with the terraform I got more a less the same error. It was complaning about unsupported guest ID. In packer we explicitly specify rhel8_64Guest, but just in case I also decided to specify it in terraform https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#guest_id-1 and got different errors:

rhel8_64Guest:

│ Error: deploy error: An invalid argument "configSpec.guestId" was specified.
│ 
│   with module.Personal.vsphere_virtual_machine.ld-lgonchar-2,
│   on modules/Personal/ld-lgonchar-2.example.local.tf line 2, in resource "vsphere_virtual_machine" "ld-lgonchar-2":
│    2: resource "vsphere_virtual_machine" "ld-lgonchar-2" {

rockylinux_64Guest:

│ Error: cannot find OS family for guest ID "rockylinux_64Guest": could not find guest ID "rockylinux_64Guest"
│ 
│   with module.Personal.vsphere_virtual_machine.ld-lgonchar-2,
│   on modules/Personal/ld-lgonchar-2.example.local.tf line 2, in resource "vsphere_virtual_machine" "ld-lgonchar-2":
│    2: resource "vsphere_virtual_machine" "ld-lgonchar-2" {

However in the docs https://knowledge.broadcom.com/external/article/321876/determine-the-guest-os-from-a-vm-configu.html both of them exist. The next idea was to epoxrt list of guest IDs:

[VMware.Vim.VirtualMachineGuestOsIdentifier].GetEnumValues()

...
rhel8_64Guest
...
rockylinux_64Guest
almalinux_64Guest

and again... both of them exist. Also the windows VM were created without any problems. However, my workmate spotted that the different hardware version is available for customezation in web UI. I also found it in the doc https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#hardware_version-1. So, If I set the hardware_version param to 21 it works because rockylinux_64Guest is introduced.

What happens?
1. We used to have the VM hardware compatibility set to version 19. And the templates we created used to be detected as RHEL8. And compatibility for version 19 supported RHEL 8.
2. Weekly template rebuild happens
3. what's happening right now?
- The template is still defined as RHEL 8
- During deployment VMWare automatically detects it as Rocky Linux 8
- Vmware sets the Guest OS to rockylinux_64Guest.
- rockylinux_64Guest is not compatible with VM version 19
- When the VM is startted it get the error The guest operating system 'rockylinux_64Guest' is not supported.
4. The compat level in packer template was increased to 21 and rebuilt.

Why it happens?

1. The first idea was that VMWare tools was updated(we are installing the latest one). but it's the same
2. The Vcenter version is also the same.
3. The code is also the same.
4. Something else has been updated inside the VM template(we also install all updates) like firmware but i've not find the diff yet. also the kernel https://oraclelinux.pkgs.org/8/ol8-baseos-latest-x86_64/kernel-4.18.0-553.46.1.el8_10.x86_64.rpm.html was suspicious but I found nothing interesting in the release notes
5. i also upgraded rocky 8.6->8.10 at a test VM just to exclude the changes in the /etc/redhat-release

so.. I don't know why.. wip..

#vmware #debug #terraform

Зачем эти полумеры? Надо ставить 1 день, а потом двигаться к новому сертификату на каждый коннект

Участники ассоциации CA/Browser Forum, являющейся площадкой для координации совместной работы производителей браузеров и удостоверяющих центров, проголосовали за сокращение максимального времени жизни TLS-сертификатов. Максимальное время действия TLS-сертификатов будет сокращено с 398 до 47 дней, если в дальнейшем CA/Browser Forum не пересмотрит принятое решение.
. . .
Изменение намерены продвигать постепенно: начиная с 15 марта 2026 года максимальный срок действия TLS-сертификатов будет уменьшен до 250 дней, с 15 марта 2027 года - до 100 дней, а с марта 2029 года - до 47 дней.
. . .
За новое сокращение времени жизни TLS-сертификатов проголосовали 29 участников, 6 воздержались и никто не отдал голос против. Участники, проголосовавшие "за": Apple, Google, Microsoft, Mozilla, Amazon, Asseco Data Systems SA (Certum), Buypass AS, Certigna (DHIMYOTIS), Certinomis, DigiCert, Disig, D-TRUST, eMudhra, Fastly, GlobalSign, GoDaddy, HARICA, iTrusChina, Izenpe, NAVER Cloud Trust Services, OISTE Foundation, Sectigo, SHECA, SSL.com, SwissSign, Telia Company, TrustAsia, VikingCloud, Visa. Участники, которые воздержались: Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA.
. . .
Предполагается, что генерация короткодействующих сертификатов позволит быстрее внедрять новые криптоалгоритмы в случае выявления уязвимостей в ныне действующих, а также сократит угрозы безопасности. 
. . .
Кроме того, короткодействующие сертификаты станут стимулом для внедрения автоматических систем управления сертификатами, избавленными от человеческого фактора. При этом, изжитие практики ручного обновления сертификатов может привести и к негативным последствиям. Отмечается, что некоторые устройства, допускающие загрузку сертификатов только в ручном режиме, могут остаться с недействительными сертификатами из-за сложности организации ручного обновления каждые полтора месяца. Изменение также может негативно повлиять на бизнес удостоверяющих центров, не предоставляющих API для автоматического получения сертификатов.

Максимальное время жизни TLS-сертификатов сократят с 398 до 47 дней
https://www.opennet.ru/opennews/art.shtml?num=63069

Оригинал
https://mstdn.social/@jschauma/114325519681641946