Vejo que o provedor azurermazurerm_monitor_metric_alert tem , mas não parece oferecer suporte a alertas de cota do Azure . Vários AIs acham que posso usar azurerm_monitor_metric_alertcom um escopo como `/subscriptions/${data.azurerm_subscription.current.subscription_id}/providers/Microsoft.Compute/locations/${location}/providers/Microsoft.Quota/quotas/standardDPLDSv5Family"

mas esse não parece ser o caso. Parece ser impossível gerenciar alertas de cota de assinatura via terraform. Isso está certo?

De acordo com o CVE-2022-0778 do Ubuntu, esta versão deve abordar o CVE. No entanto, quando olho para a versão OpenSSL, não posso dizer que é 1.1.1n. Vejo que foi construído em 9 de março antes de:

• OpenSSL disponibilizando a fonte ao público
• Gerenciadores de distribuição do Ubuntu importando o OpenSSL 1.1.1n em seu repositório (que pode ser apenas um repositório público)

Então, como eu saberia que isso é realmente 1.1.1n?

Sistema Ubuntu 18.04 após atualização

OpenSSL 1.1.1  11 Sep 2018
built on: Wed Mar  9 12:13:40 2022 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,
--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-vxXVMf/openssl-1.1.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE 
-DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM 
-DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

Mantenedor de distribuição

Repositório do Ubuntu: https://git.launchpad.net/ubuntu/+source/openssl

Tag:

* 3b83ed56dea2b735e31731fd042b52ff869f9a97 - 
(tag: import/1.1.1n-1, origin/debian/sid) 1.1.1n-1 
(patches unapplied) (c: Wed, 16 Mar 2022 04:33:58 +0000) 
(a: Tue, 15 Mar 2022 19:46:18 +0100) <Sebastian Andrzej Siewior>%

applied/1.1.1n-1
*   d4d5eeef3576b16013c48abc435c5da889cedf1b - (tag: applied/1.1.1n-1, 
origin/applied/debian/sid) 1.1.1n-1 (patches applied) 
(c: Wed, 16 Mar 2022 04:33:58 +0000) 
(a: Tue, 15 Mar 2022 19:46:18 +0100) <Sebastian Andrzej Si

Eu tenho dois sistemas Windows vinculados ao AWS CloudHSM v2 (o cavium HSM). Em um, gerei o CSR e aceitei/adicionei o certificado adquirido com esse CSR. Eu posso assinar e a chave privada é extraída corretamente do HSM por meio do Key Container.

A outra assinatura é o meu sistema de assinatura de produção e está funcionando corretamente com o certificado existente, mas quando tento adicionar o novo certificado, não Key Containerestá configurado. Estou acostumado a precisar executar o processo de reparo, mas neste caso não tenho ID para fornecer o arquivo.

1. Autenticar"\Program Files\Amazon\CloudHSM\tools\set_cloudhsm_credentials.exe" --user REDACTED --password "..."
2. Adicione o certificadocertutil -addstore my my-new-cert.crt
3. Despejar os detalhes da lojacertutil -store my > cert_store_details.txt

    Serial Number: REDACTED
    Issuer: CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, O=DigiCert, Inc., C=US
     NotBefore: 1/25/2022 12:00 AM
     NotAfter: 1/25/2023 11:59 PM
    Subject: CN=REDACTED, C=US, SERIALNUMBER=REDACTED, OID.1.3.6.1.4.1.311.60.2.1.2=Delaware, OID.1.3.6.1.4.1.311.60.2.1.3=US, OID.2.5.4.15=Private Organization
    Non-root Certificate
    Cert Hash(sha1): REDACTED
    No key provider information
    Cannot find the certificate and private key for decryption.

Normalmente, eu criaria um repair.txt assim com Key Containerid entre o =e &no no Containerentanto, não tenho um desses, então estou sem sorte

        [Properties]
        11 = "" ; Add friendly name property
        2 = "{text}" ; Add Key Provider Information property
        _continue_="Container=&"
        _continue_="Provider=Cavium Key Storage Provider&"
        _continue_="Flags=0&"
        _continue_="KeySpec=2"    

Se eu apenas executar um reparo , será certutil -repairstore my "REDACTED"solicitado um cartão inteligente. Ah, e esta máquina é um Windows Core 2016 (portanto, não há interface do usuário ou interface do usuário limitada).

Ao tentar construir um tarball centos rootfs da maneira mais difícil (veja centos docs ), minha execução do criador de mídia ao vivo trava com:

Comando

livemedia-creator --make-tar --iso=/root/boot8.iso \
--ks=/root/centos-8.ks --image-name=centos8-docker.tar.xz

Ponto de parada

Domain installation still in progress. You can reconnect to 
the console to complete the installation process.

• Não é possível conectar com o virsh
• Não é possível usar a opção vnc

Então, eu não posso fazer um tarball rootfs que eu usaria para fazer uma imagem base docker. Deixo correr por algumas horas, nada de útil nos logs e percebo que algo interativo está acontecendo, mas não consigo acessar o console

Alguém já viu as tentativas funcionarem em uma tarefa win_chocolatey ansible?

O seguinte parece falhar na primeira tentativa sem novas tentativas e estou obtendo tempos limite no nível ansible enquanto o choco tenta instalar um pacote.

- name: Install Chocolatey
  win_chocolatey:
    name: a_package
    env: choco
  retries: 3

Você usou tentativas com sucesso com tarefas win_chocolatey?

Solução possível Usando a sugestão de Henrik e um bloco, tenho novas tentativas mais uma operação de resgate/captura para buscar o choco log em caso de erros após as tentativas

- name: install applications
  block:
  - win_chocolatey:
      name: "{{ item }}"
      source:  "{{ choco_artifactory_source }}"
    register: result
    until: result.rc == 0
    retries: 3
    with_items:
      - wget
      - curl
  rescue:
  - fetch:
      src: "{{ choco_log }}"
      dest: "{{ agent_log_dir }}"
      flat: yes