Perguntas[centos](computer)

Quando tento enviar uma notificação pelo OpenProject no CentOS 9, recebo um erro:

falha na verificação do certificado (não foi possível obter o certificado do emissor local)

Quando tento testar diretamente com o OpenSSL, consigo acessar o servidor SMTP e não recebo o erro.

O comando OpenSSL que funciona:

openssl s_client -CApath /etc/ssl/certs -starttls smtp -connect serer:587 -cert /etc/ssl/certs/tls-cert.pem -key /etc/ssl/certs/tls-cert.key -CAfile tls-cert-bundle.pem -servername "ServerName"

Alguém tem alguma ideia do porquê recebo esse erro?

PS: Verifiquei o arquivo de configuração no HTTPD para o OpenProject e ele fornece o caminho correto para o certificado TLS.

Tenho o SqlServer legado ao qual tento me conectar, mas a conexão falha devido a um erro de handshake TLS. Depois de analisar o tráfego com o Wireshark, parece que encontrei o motivo: o certificado é assinado usando o Algorithm Id: 1.2.840.113549.1.1.5( sha1WithRSAEncryption). Portanto, se o cliente indicar rsa_pkcs1_sha1 (0x0201)suporte (usando signature_algorithmsa extensão no Client Hello), o servidor responderá corretamente (foi testado no Windows), caso contrário, o servidor apenas fechará a conexão imediatamente. Porém não consegui habilitá-lo usando o openssl 3. Versão TLS: 1.2

O que eu tentei:

1. Definir SECLEVEL=0 ( CipherString = ALL@SECLEVEL=0)
2. Adicionado CypherSuites que foi aceito em teste de conexão bem-sucedido (comoTLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c))
3. Garantido que o provedor legado esteja carregado e ativo (usando openssl list -providers)
4. Algoritmo desejado explicitamente adicionado em SignatureAlgorithms. Mas não tenho certeza se fiz isso corretamente. Assim:SignatureAlgorithms = RSA+SHA1:ecdsa_sha1:rsa_pkcs1_sha1:...
5. config_diagnostics = 1
6. Garantido que RSA e SHA1 possam ser usados ​​em contextos diferentes ( openssl dgst -sha1 ./file.txt, openssl genrsa)

Ainda assim, tudo relacionado ao SHA1 é ignorado da extensão subscription_algorithms quando o handshake TLS é iniciado e, portanto, a conexão é fechada pelo servidor.

Além disso, por algum motivo, openssl list -digest-algorithmsé impresso sha1WithRSAEncryption => SHA1em Legacyseção, não em Providedseção. Não está claro para mim nos documentos o que essas seções significam

versão do openssl : 3.2.2

PS Por favor, tenha em mente que não sou competente em CypherSuites, algoritmos de assinatura e assim por diante e como isso afeta uns aos outros. Apenas tentando se conectar ao servidor.

PS 2. POR FAVOR, não me diga que SHA1 é inseguro e preciso atualizar o certificado em um servidor que não possuo.

Ao atualizar um pacote, o yum resolve e atualiza todas as dependências automaticamente. Existe um sinalizador/opção ao fazer o downgrade de pacotes. Por exemplo, tenho o php82 instalado e estou tentando voltar para o php 74.

sudo yum downgrade php-7.4.33-8.el7.remi.x86_64

que retorna o erro:

Error: Package: php-tidy-8.2.9-2.el7.remi.x86_64 (@remi-php82)

Também posso adicionar php-tidyitens à lista de downgrade, mas haverá dezenas dessas dependências. Posso apenas instruir o yum a fazer o downgrade automático de todos eles também?

Estou usando o seguinte para detectar a NIC LAN privada.

export PRIVATE_LAN=`ip a|grep "inet 192"|tr -s ' '|cut -d' ' -f8`

Isso é robusto para longo prazo? Depende da formatação do comando ip.

Mesmo que o mlocatepacote esteja instalado com dnf install mlocateo updatedbcomando não está agendado para ser executado.

Isso significa locate <filename>retornar resultados vazios.

Como você habilita updatedba execução automática sem criar seus próprios scripts ou tarefas cron?

Eu tenho um servidor CentOS mínimo sem acesso à internet. Vamos chamá-lo de servidor A .

Meu destino é construir um arquivo de script de shell para instalar uma versão específica de um arquivo RPM local para um aplicativo. Digamos que o aplicativo de destino seja o Apache. O problema é que cada RPM tem dependências.

Em um servidor diferente onde há acesso à internet, que chamo de servidor B , faço o download do pacote:

wget http://repo.okay.com.mx/centos/7/x86_64/release/httpd-2.4.35-5.el7.x86_64.rpm

Em seguida, mova-o para o servidor A e tente instalá-lo:

rpm -i httpd-2.4.35-5.el7.x86_64.rpm

captura de tela da dependência de instalação do yum:

Tem vários requisitos:

rpm -qpR httpd-2.4.35-5.el7.x86_64.rpm

procurar captura de tela de dependências:

Não consigo entender alguns dos requisitos:

1- O que é /etc/mime.types? Eu não tenho esse arquivo. De onde posso obtê-lo?

2- Alguns pacotes são mencionados várias vezes como

systemd-utils
systemd-utils
systemd-utils

O que isto significa?

3- Alguns pacotes possuem múltiplas variações. Qual deles devo instalar? libc.so

4- Parece que a lista está ordenada alfabeticamente. Qual a ordem de instalação?

5- O dnf repoquerycomando também fornece uma lista diferente. Qual devo seguir?

captura de tela de repoquery dnf:

6- Não existe uma forma mais automática de realizar o que procuro?

Em um novo rocky9 vm, o LVM2 NÃO vê os PVs recém-anexados sob LUKS.

===

O objetivo final é migrar um servidor "repo" simples (que contém arquivos iso) do centos8 para o rocky9.

Eu tenho um rocky9 linux vm recém-instalado. Ele inicializa bem e tem LUKS e LVM.

Enquanto as VMs antigas e novas foram interrompidas, peguei as <disk>...</disk>seções dos discos de dados e as adicionei ao new-ish /etc/libvirt/qemu/repo9.xml, e fiz um arquivo /usr/bin/systemctl reload libvirtd. Ele vê os discos.

Também peguei as entradas /etc/crypttabe as migrei para o novo host repo9.

Após uma nova reinicialização, ele solicita o luks PW e eu o forneço uma vez (mesmo pw para todos os dispositivos).

# /bin/cat /etc/redhat-release
Rocky Linux versão 9.0 (Blue Onyx)

Sim, blkid os vê.

# /usr/sbin/blkid | grep -i luks

/dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10: UUID="52oE6g-azSo-95kU-3NGu-Hyfq-tcN6-XKcQe5" TYPE="LVM2_member"
/dev/sda2: UUID="2f5518cd-8453-4660-abe0-b2550b30ba10" TYPE="crypto_LUKS" PARTUUID="42a79f19-02"
/dev/vda1: UUID="5c44226e-3bc5-4b04-b369-beea69f6ca8c" TYPE="crypto_LUKS" PARTUUID="82535424-01"
/dev/vdb1: UUID="a50cd287-d4d2-4301-bd44-d3937e4d9df3" TYPE="crypto_LUKS" PARTUUID="9f2b9d8e-01"
/dev/vdc1: UUID="b893a690-a1a0-4021-b078-1d971fe156d2" TYPE="crypto_LUKS" PARTUUID="abbfb472-01"
/dev/vdd1: UUID="7e42260f-9739-4d8a-8e07-5cc19590d460" TYPE="crypto_LUKS" PARTUUID="40333c29-01"
/dev/mapper/luks-b893a690-a1a0-4021-b078-1d971fe156d2: UUID="tqgPNb-Jbos-IlCG-nWD9-8yMP-5ZII-jyvZb0" TYPE="LVM2_member"
/dev/mapper/luks-5c44226e-3bc5-4b04-b369-beea69f6ca8c: UUID="mnraHG-RX5m-eEmV-uYhr-UEng-x8JT-5YKZ3P" TYPE="LVM2_member"
/dev/mapper/luks-7e42260f-9739-4d8a-8e07-5cc19590d460: UUID="pSuS4s-e5vc-r3wV-PhBq-d7Nt-Myjf-RxZ5t0" TYPE="LVM2_member"
/dev/mapper/luks-a50cd287-d4d2-4301-bd44-d3937e4d9df3: UUID="odlXGf-Hzzd-C30f-cNML-wEFb-UVEA-IZYdzf" TYPE="LVM2_member"

E lsblk os vê.

# /usr/bin/lsblk

NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0   14G  0 disk  
├─sda1                                          8:1    0  900M  0 part  /boot
└─sda2                                          8:2    0 11.7G  0 part  
  └─luks-2f5518cd-8453-4660-abe0-b2550b30ba10 253:0    0 11.7G  0 crypt 
    ├─vg00-slash                              253:1    0 9000M  0 lvm   /
vda                                           252:0    0    8G  0 disk  
└─vda1                                        252:1    0    8G  0 part  
  └─luks-5c44226e-3bc5-4b04-b369-beea69f6ca8c 253:4    0    8G  0 crypt 
vdb                                           252:16   0    7G  0 disk  
└─vdb1                                        252:17   0    7G  0 part  
  └─luks-a50cd287-d4d2-4301-bd44-d3937e4d9df3 253:5    0    7G  0 crypt 
vdc                                           252:32   0   15G  0 disk  
└─vdc1                                        252:33   0   15G  0 part  
  └─luks-b893a690-a1a0-4021-b078-1d971fe156d2 253:6    0   15G  0 crypt 
vdd                                           252:48   0   90G  0 disk  
└─vdd1                                        252:49   0   90G  0 part  
  └─luks-7e42260f-9739-4d8a-8e07-5cc19590d460 253:9    0   90G  0 crypt 

A saída acima é ruim, pois só vai até a entrada luks (para não-vg00). Uma saída de aparência adequada deve ter o LV sob luks, como:

vdd                                           252:48   0   90G  0 disk  
└─vdd1                                        252:49   0   90G  0 part  
  └─luks-7e42260f-9739-4d8a-8e07-5cc19590d460 253:9    0   90G  0 crypt 
    ├─vg01-opt                                253:7    0  500M  0 lvm   /opt
    ...

Aqui está a saída dos comandos do arquivo, que diz que o luks-* aponta para dm- e o dm- são do tipo LUKS.

# /usr/bin/file -s /dev/mapper/luks-*

/dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10: symbolic link to ../dm-0
/dev/mapper/luks-5c44226e-3bc5-4b04-b369-beea69f6ca8c: symbolic link to ../dm-4
/dev/mapper/luks-7e42260f-9739-4d8a-8e07-5cc19590d460: symbolic link to ../dm-9
/dev/mapper/luks-a50cd287-d4d2-4301-bd44-d3937e4d9df3: symbolic link to ../dm-5
/dev/mapper/luks-b893a690-a1a0-4021-b078-1d971fe156d2: symbolic link to ../dm-6

# /usr/bin/file -s /dev/dm-[04956]

/dev/dm-0: LVM2 PV (Linux Logical Volume Manager), UUID: 52oE6g-azSo-95kU-3NGu-Hyfq-tcN6-XKcQe5, size: 12566134784
/dev/dm-4: LVM2 PV (Linux Logical Volume Manager), UUID: mnraHG-RX5m-eEmV-uYhr-UEng-x8JT-5YKZ3P, size: 8586788864
/dev/dm-5: LVM2 PV (Linux Logical Volume Manager), UUID: odlXGf-Hzzd-C30f-cNML-wEFb-UVEA-IZYdzf, size: 7513047040
/dev/dm-6: LVM2 PV (Linux Logical Volume Manager), UUID: tqgPNb-Jbos-IlCG-nWD9-8yMP-5ZII-jyvZb0, size: 16102981632
/dev/dm-9: LVM2 PV (Linux Logical Volume Manager), UUID: pSuS4s-e5vc-r3wV-PhBq-d7Nt-Myjf-RxZ5t0, size: 96618938368

Então eu tento etapas manuais para ver os PVs.

# /usr/sbin/pvscan #(only finds the pv for vg00)
PV /dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10 VG vg00 lvm2 [<11,70 GiB / 980,00 MiB livre] Total: 1 [<11,70 GiB] / em uso: 1 [<11,70 GiB] / em nenhum VG: 0 [0 ]

# /usr/sbin/pvs #(only finds the pv for vg00)
PV VG Fmt Attr PSize PFree
/dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10 vg00 lvm2 a-- <11,70g 980,00m

Aqui está a versão do lvm2:

# /usr/bin/rpm -q lvm2
lvm2-2.03.14-4.el9.x86_64

E as configurações são todas padrão, sem filtros de rejeição ruins, aceita tudo.

# /usr/bin/rpm -qV lvm2
(sem saída)

# /usr/sbin/lvm dumpconfig
config { } local { } dmeventd { } ativação { } global { } shell { } backup { } log { } alocação { } dispositivos { }

# /bin/cat /etc/crypttab
luks-2f5518cd-8453-4660-abe0-b2550b30ba10 UUID=2f5518cd-8453-4660-abe0-b2550b30ba10 none discard
luks-5c44226e-3bc5-4b04-b369-beea69f6ca8c UUID=5c44226e-3bc5-4b04-b369-beea69f6ca8c none discard
luks- a50cd287-d4d2-4301-bd44-d3937e4d9df3 UUID=a50cd287-d4d2-4301-bd44-d3937e4d9df3 none discard
luks-b893a690-a1a0-4021-b078-1d971fe156d2 UUID=b893a690-a1a0-4021-b078-1d971fe156d2 none discard
luks-7e42260f- 9739-4d8a-8e07-5cc19590d460 UUID=7e42260f-9739-4d8a-8e07-5cc19590d460 nenhum descarte

Eu tento mencionar explicitamente uma configuração inline para filtrar-> aceitar itens relevantes, mas sem sorte:

# /usr/sbin/pvscan  --config 'devices { filter = [ "a|.*|" ] } '

/usr/sbin/pvscan  --config 'devices { filter = [ "a|.*|" , "a|/dev/mapper/luks-*|" , "a|/dev/dm-*|" ] } '

PV /dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10 VG vg00 lvm2 [<11,70 GiB / 980,00 MiB livre] Total: 1 [<11,70 GiB] / em uso: 1 [<11,70 GiB] / em nenhum VG: 0 [0 ]

Mas aqui está um vislumbre de esperança.

O ÚNICO truque que tenho que torna os PVs do LVM visíveis é se eu os especificar após --devices :

# /usr/bin/pvs --devices $(echo /dev/mapper/luks-* | tr ' ' ',' )

  PV                                                    VG   Fmt  Attr PSize   PFree  
  /dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10 vg00 lvm2 a--  <11.70g 980.00m
  /dev/mapper/luks-5c44226e-3bc5-4b04-b369-beea69f6ca8c vg01 lvm2 a--   <8.00g      0 
  /dev/mapper/luks-7e42260f-9739-4d8a-8e07-5cc19590d460 vg01 lvm2 a--   89.98g      0 
  /dev/mapper/luks-a50cd287-d4d2-4301-bd44-d3937e4d9df3 vg01 lvm2 a--   <7.00g      0 
  /dev/mapper/luks-b893a690-a1a0-4021-b078-1d971fe156d2 vg01 lvm2 a--  <15.00g   5.13g

Mas se eu executá-lo sem --devices, novamente ele volta a não ver os PVs.

# /usr/sbin/pvs

  PV                                                    VG   Fmt  Attr PSize   PFree  
  /dev/mapper/luks-2f5518cd-8453-4660-abe0-b2550b30ba10 vg00 lvm2 a--  <11.70g 980.00m

Eu tentei uma atualização do yum, não muitos patches ainda, apenas kernel* e binutils, mas eles não ajudaram.

Por que meu LVM2 não está vendo a maioria dos PVs no LUKS?

Todas as idéias seriam muito apreciadas!!

Obrigada.

Estou tentando executar um comando:

perl bin/smartpca.perl -i merged.eigenstrat.34string.length.geno -a merged.eigenstrat.34string.length.snp -b merged.eigenstrat.34string.length.ind -o merged.eigenstrat.34string.length.pca -p merged.eigenstrat.34string.length.plot -e merged.eigenstrat.34string.length.eval -l merged.eigenstrat.34string.length.log

que resulta no erro:

smartpca: error while loading shared libraries: liblapacke.so.3: cannot open shared object file: No such file or directory

quando tento pesquisar no Google ou yum search liblapacknão recebo nada.

Como posso instalar esta liblapackebiblioteca?

No el7 havia linhas no grub.cfg como linux16 /vmlinuzcarregar um kernel e criar itens de menu. No el8, esses itens de menu não são listados no grub.cfg após um arquivo grub2-mkconfig -o /boot/grub2/grub.cfg.

Eu gosto de ver a lista de itens de menu do kernel para verificar as versões às vezes.

Onde eles estão armazenados no el8?

Eu tenho o EPEL instalado no CentOS9

$> sudo dnf repolist
repo id                                           repo name
appstream                                         CentOS Stream 9 - AppStream
baseos                                            CentOS Stream 9 - BaseOS
epel                                              Extra Packages for Enterprise Linux 9 - x86_64
epel-next                                         Extra Packages for Enterprise Linux 9 - Next - x86_64
extras-common                                     CentOS Stream 9 - Extras packages

mas nmonnão foi encontrado:

$> sudo dnf -y install nmon
Last metadata expiration check: 0:01:46 ago on Wed 20 Apr 2022 14:49:52 CEST.
No match for argument: nmon
Error: Unable to find a match: nmon

(Tenho certeza de que funcionou no CentOS8 há alguns meses)