David Tonhofer's questions

Suponha que eu tenha instalado o pacote ongres-scramno Fedora 40.

Então

$ rpm --query --requires ongres-scram

me dá uma lista de "tags de dependência" que são necessárias para ter este pacote instalado:

javapackages-filesystem
mvn(com.ongres.stringprep:saslprep)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
rpmlib(RichDependencies) <= 4.12.0-1

Por outro lado

$ rpm --query --provides ongres-scram

me dá "tags de dependência" que são fornecidas pela instalação:

mvn(com.ongres.scram:common) = 2.1
mvn(com.ongres.scram:common:pom:) = 2.1
ongres-scram = 2.1-13.fc40

A tag de dependência javapackages-filesystemé resolvida por um pacote correspondente:

$ rpm --query --whatprovides javapackages-filesystem
javapackages-filesystem-6.2.0-9.fc40.noarch

A tag de dependência mvn(foo)certamente tem a ver com um processo de construção baseado no maven e pode ser resolvida:

$ rpm --query --whatprovides "mvn(com.ongres.stringprep:saslprep)"
ongres-stringprep-1.1-12.fc40.noarch
$ dnf provides "mvn(com.ongres.stringprep:saslprep)"
...
ongres-stringprep-1.1-12.fc40.noarch : RFC 3454 Preparation of Internationalized Strings in pure Java
...

Mas a tag de dependência rpmlib(foo)não foi resolvida:

$ rpm --query --whatprovides "rpmlib(FileDigests)"
no package provides rpmlib(FileDigests)
$ dnf provides "rpmlib(FileDigests)"
Error: No matches found....

Pode ser que a tag represente um requisito no sistema para construir o pacote RPM. Mas o que a fornece?

Além disso, parece

rpmlib(FileDigests) <= 4.6.0-1

indica a necessidade de uma versão bem antiga já que a atual rpmé 4.19.1.1?

Percebi que openssl x509 -in $FILE -textàs vezes exibe o número de série de um certificado X.509 (um número inteiro positivo de até 20 bytes, portanto o bit mais significativo em 0), às vezes como uma "string de octetos" e às vezes como um número inteiro com sua representação hexadecimal a seguir.

Por exemplo, aqui está o número de série de um certificado na cadeia "Letsencrypt" (número de série de 16 bytes, mas o MSB é 1, algo está errado?):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1

Aqui está um certificado do "pacote de certificados" do sistema (número de série de 8 bytes, MSB é 0)

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6828503384748696800 (0x5ec3b7a6437fa4e0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES

Outro do mesmo pacote (número de série de 16 bytes, MSB é 0):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0c:e7:e0:e5:17:d8:46:fe:8f:e5:60:fc:1b:f0:30:39
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA

O certificado QuoVadis Root CA 2(número de série de 2 bytes):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1289 (0x509)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

Aqui está um com número de série de 9 bytes (MSB corretamente em 0):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            11:00:34:b6:4e:c6:36:2d:36
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=RO, O=CERTSIGN SA, OU=certSIGN ROOT CA G2

E um do mesmo provedor, um certificado com número de série de 6 bytes:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 35210227249154 (0x200605167002)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RO, O=certSIGN, OU=certSIGN ROOT CA

Parece bastante aleatório. Existe um significado particular em haver duas maneiras de imprimir o número de série?

Configurar:

Fedora 30 com uma máquina virtual KVM/qemu rodando Ubuntu 18.04.1.

(Esta configuração porque eu quero executar o RStudio e no meu Fedora 30, e ele apenas vomita e morre imediatamente em algum lugar no subsistema gráfico nouveau - mas funciona bem em uma VM Ubuntu).

Problema:

Copiar e colar na VM é um PITA correto quando o RStudio está em execução.

Depois que a VM foi iniciada, copiar e colar entre o host e a VM funciona bem, e copiar e colar dentro da VM também funciona bem (por exemplo, KWrite to KWrite)

Depois que o RStudio for iniciado na VM, copiar e colar inicialmente continua a funcionar (algumas vezes), mas logo começa a "travar". Isso se aplica tanto ao RStudio quanto ao KWrite e acontece tanto para copiar e colar na VM quanto do host para a VM. O processo de recebimento na VM congela e aparentemente espera por algo. No entanto, a máquina virtual continua a funcionar normalmente (por exemplo, você pode exercitar o shell, executar topetc. iotop)

O processo de recebimento acorda novamente após 10 a 30 segundos, momento em que o texto colado pode ter sido recebido ... ou não. Após um primeiro soluço, a colagem geralmente falha, e isso inclui copiar e colar da VM para o host. A colagem no KWrite demora 10 segundos até que o cursor retorne sem o conteúdo da área de transferência. O RStudio se comporta de forma mais catastrófica, às vezes matar o processo é a única solução.

Se alguém deixar a VM sozinha por algum tempo, novamente terá a chance de algumas ações de copiar e colar bem-sucedidas, e os bloqueios ocorrerão novamente.

Reiniciar spice-vdagent( systemctl start spice-vdagentd) na máquina convidada (não no host onde aparentemente não faz nada) interrompe um travamento e pode dar a oportunidade de executar algumas cópias e colar novamente. Mas essa ação está repleta de algum risco, pois eu tive toda a GUI congelada em algum momento.

Como resolver?

O que devo procurar?

Eu usei xclipboardno host para ver o que passa pela área de transferência. Nada inesperado visto.

PS

A VM recebeu muita RAM (10GiB), o que parece necessário, pois tricotar até mesmo arquivos de malha não muito grandes envolvendo mapas de intensidade fará com que fique pandocsem memória.

O RStudio às vezes congela por alguns segundos quando estou trabalhando nele, novamente sem travar todo o sistema. Parece que a troca ou a coleta de lixo estava entrando em ação, mas nada está acontecendo na E/S ou na CPU. Irritante, mas sobrevivente.

Eu tenho um Lenovo ideapad 110-15ISK antigo com o Fedora 30 instalado (e um SSD criptografado com LUKS como armazenamento).

Quando eu inicializo esta máquina:

1. O logotipo "Lenovo" (na verdade apenas um texto) é exibido brevemente.
2. A tela do gerenciador de inicialização é exibida com kernels selecionáveis
3. Eu seleciono um kernel.
4. O logotipo "Lenovo" é exibido brevemente.
5. Um widget de entrada de texto de senha é exibido com o logotipo "fedora(∫)" na parte inferior da tela.
6. Insiro a senha para descriptografar o SSD LUKS-ified.
7. O processo de inicialização continua enquanto o seguinte é exibido:
   1. O logotipo "Lenovo" no meio da tela e
   2. O logotipo "fedora(∫)" na parte inferior da tela.
8. Finalmente, a tela de login do KDE assume.

Por que (7) acontece? Como é possível ter o "mashup de logotipo" a menos que o Fedora venha com uma seleção especial de logotipos de fabricantes para exibir? Porque nesse ponto, é o systemd que se encarrega do monitor (talvez através do framebuffer ). É bem misterioso.

Executando lsblk(um excelente comando para obter informações sobre a configuração do disco a partir de scripts e linguagens de alto nível independentes do sistema operacional) no Fedora 29 da seguinte forma:

$ lsblk --output NAME,FSTYPE,ROTA,PARTTYPE,TYPE,RAND,TRAN

NAME                   FSTYPE            ROTA PARTTYPE TYPE  RAND TRAN
sda                                         0          disk     0 sata
├─sda1                 ext4                 0 0x83     part     0 
└─sda2                 LVM2_member          0 0x8e     part     0 
  ├─fedora_root        ext4                 0          lvm      0 
  └─fedora_swap        swap                 0          lvm      0 
sdb                                         0          disk     0 sata
└─sdb1                 ext4                 0 0x83     part     0 
sdc                                         1          disk     1 sata
└─sdc1                 linux_raid_member    1 0xfd     part     1 
  └─md127              crypto_LUKS          1          raid1    0 
    └─luks_mdraid      ext4                 1          crypt    0 
sdd                                         1          disk     1 sata
└─sdd1                 linux_raid_member    1 0xfd     part     1 
  └─md127              crypto_LUKS          1          raid1    0 
    └─luks_mdraid      ext4                 1          crypt    0 

Aqui pedimos o seguinte (a lista de colunas disponíveis pode ser obtida emitindo lsblk --help):

• NAME : nome do dispositivo (bem organizado em uma árvore)
• FSTYPE: tipo de sistema de arquivos
• ROTA : este é um "dispositivo rotacional" (ferrugem giratória, DVD etc.)
• PARTTYPE : tipo de partição UUID (valores definidos em fdisk)
• TIPO: tipo de dispositivo
• RAND : "adiciona aleatoriedade"
• TRAN: tipo de transporte do dispositivo

Ok, então o dispositivo "adiciona aleatoriedade" conforme RAND. Mas em que contexto? E para que valor? Parece ter algo a ver com o dispositivo ser "rotacional". O que significa "adiciona aleatoriedade"?

No meu CentOS, a yum updatetraz o seguinte:

(6/38): iwl1000-firmware-39.31.5.1-62.el7_39.31.5.1-62.2.el7_5.noarch.drpm                                                                                                                                            
(7/38): iwl105-firmware-18.168.6.1-62.el7_18.168.6.1-62.2.el7_5.noarch.drpm                                                                             
(8/38): iwl135-firmware-18.168.6.1-62.el7_18.168.6.1-62.2.el7_5.noarch.drpm                                                                             
(9/38): iwl2000-firmware-18.168.6.1-62.el7_18.168.6.1-62.2.el7_5.noarch.drpm                                                                            
(10/38): iwl2030-firmware-18.168.6.1-62.el7_18.168.6.1-62.2.el7_5.noarch.drpm                                                                           
(11/38): iwl3160-firmware-22.0.7.0-62.el7_22.0.7.0-62.2.el7_5.noarch.drpm                                                                                                                                             

etc.

Estes são os chamados "pacotes de firmware". Por exemplo, vamos encontrar alguns deles que estão instalados:

rpm --query --all | grep firmware

e, em seguida, consulte suas informações:

rpm --query --info iwl105-firmware-18.168.6.1-62.2.el7_5.noarch

e obtemos:

Summary     : Firmware for Intel(R) Centrino Wireless-N 105 Series Adapters
Description :
This package contains the firmware required by the iwlagn driver
for Linux to support the iwl105 hardware.  Usage of the firmware
is subject to the terms and conditions contained inside the provided
LICENSE file. Please read it carefully.

OK, bem.

Eu nem tenho esse tipo de hardware, pois esta é uma VM.

Então, pergunta:

O que os pacotes de firmware realmente fazem?

São instalações "one-shot" que executam um executável opaco (imediatamente? na próxima inicialização?) pelo menos, o flashing de hardware está sempre repleto de janelas do DOS que aparecem, EULAs que precisam ser clicados e barras de progresso que precisam ser suportadas) e, em seguida, marca o pacote como "instalado".

Eles modificam o initramfs para que um blob binário seja carregado por um módulo do kernel ou algo aconteça na próxima inicialização?

Eu tenho um servidor MariaDB no CentOS 7. O servidor deve desempenhar o papel de escravo e replicar o servidor mestre remoto. O servidor mestre remoto pode ser acessado por meio de um túnel SSH. A "entrada" do túnel SSH está em 127.0.0.1:3307.

Conectar-se a este endpoint usando o programa cliente MariaDB funciona.

No entanto, o servidor MariaDB não consegue se conectar. No log de erros do MySQL, encontra-se: Slave I/O: error connecting to master '[email protected]:3307' - retry-time: 60 maximum-retries: 86400 message: Can't connect to MySQL server on '127.0.0.1' (13 "Permission denied"), Internal MariaDB error code: 2003.

Evidentemente, pensa-se imediatamente no SELinux colocando o kibosh em conexões fora do padrão de saída de um servidor MariaDB.

Depois de colocar o SELinux no modo permissivo (editar /etc/selinux/confige reiniciar), o bom processo fociforme consegue se conectar.

Vamos examinar /var/log/audit/audit.logquais logs de eventos de negação do SELinux (entre outros) usando ausearch(mais informações sobre auditd em " uma breve introdução ao auditd ")

ausearch --comm mysqld

Isso fornece entradas como:

time->Wed Mar 21 18:52:53 2018
type=PROCTITLE msg=audit(1521654773.504:120): proctitle="/usr/sbin/mysqld"
type=SYSCALL msg=audit(1521654773.504:120): arch=c000003e syscall=42 success=no exit=-115 a0=41 a1=7fd1f4028ad0 a2=10 a3=72 items=0 ppid=1 pid=1342 auid=4294967295 uid=27 gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 tty=(none) ses=4294967295 comm="mysqld" exe="/usr/sbin/mysqld" subj=system_u:system_r:mysqld_t:s0 key=(null)
type=AVC msg=audit(1521654773.504:120): avc:  denied  { name_connect } for  pid=1342 comm="mysqld" dest=3307 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket

( syscall 42 é sys_connect)

Muito legal.

Agora, ainda tenho que ler o Manual (e talvez nem ajude), então a pergunta:

Que comando devo executar para permitir que o MariaDB se conecte a 127.0.0.1:3307? Porque eu quero reativar o SELinux .

Depois de voltar da hibernação do laptop, meu Fedora 27 entrou em um estado estranho em que:

1. No console gráfico, nenhuma entrada é aceita, até mesmo a atividade do mouse é desconsiderada
2. No console de texto, qualquer entrada de teclado é precedida por '^[' (seria CTRL+'1 caractere após Z'?). Portanto, quando quero fazer login, vejo ^[r^[o^[o^[te, uma vez que logino tempo limite de espera pela entrada, é o fim do jogo: não há mais entrada. O LED Capslock está inativo, o LED Numlock está ativo.

Lembro de ter visto isso na tela de boot de uma Sun SPARCstation nos anos 90...

O que está acontecendo exatamente e como posso corrigi-lo (exceto reiniciar a máquina)?

Edit : Esta foi uma ocorrência "única" na máquina em questão. Após uma reinicialização, o problema desaparece. Pode ser devido a uma falha de hardware ou qualquer bug aleatório. Embora seja devido a um modo extra especial do terminal I/O, gostaria de saber mais.