kbulgrien's questions

No SCO OpenServer 5.0.7 MP5, ao tentar usar qualquer utilitário baseado em ssh, o seguinte é retornado e nenhuma conexão SSH pretendida ocorre:

PRNG not seeded

Como isso é resolvido (a condição persiste na reinicialização)?

Os scripts de inicialização do sistema parecem idênticos entre o sistema funcionando e o não funcionando.

A resposta dada para Linux e vários UNIX é que é preciso verificar a existência de, ou permissões atribuídas a, /dev/random e/ou /dev/urandom . Este UNIX não possui esses dispositivos em um sistema em funcionamento, portanto, essas respostas são inúteis.

O SELinux é um modo permissivo para ajudar a evitar problemas operacionais durante uma transição para uma nova implantação de servidor RHEL7. Embora alguns problemas do SELinux sejam bastante fáceis de revisar e resolver com um mínimo de confiança, acho o seguinte um tanto desconcertante.

O AVC é o seguinte:

type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

audit2why disse:

type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

audit2allow disse:

#============= postfix_postdrop_t ==============

#!!!! The file '/var/spool/postfix/public/pickup' is mislabeled on your system. 
#!!!! Fix with $ restorecon -R -v /var/spool/postfix/public/pickup
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

O aviso parece implicar que alguma parte do problema deve ser corrigida executando algo como:

# restorecon -R -v /var/spool/postfix/public/pickup
# ls -lZ /var/spool/postfix/public/pickup
srw-rw-rw-. postfix postfix unconfined_u:object_r:postfix_public_t:s0 /var/spool/postfix/public/pickup

Os problemas registrados na auditoria do SELinux, no entanto, não parecem mudar depois que isso é feito, então, aparentemente, há mais a ser feito. Presumivelmente, alguns dos problemas estão relacionados à menção audit2allow de:

allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

Parece estranho que um problema do SELinux com um serviço muito bem estabelecido como o postfix exija a intervenção do administrador.

Provavelmente, um caminho para resolver o problema pode ser ao longo das linhas de:

# echo 'type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
  | audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp

Dito isso, parece imprudente simplesmente fazer coisas para desaparecer os problemas de auditoria sem uma melhor compreensão de por que tal mudança deve ser considerada legítima.

Isso é realmente um problema de rotulagem ou é apenas um efeito colateral do "permitir" ausente e, alguém pode comentar se essa é uma alteração legítima e esperada que um administrador deve fazer para que uma instalação do postfix funcione sem problemas sob SELinux?

Por favor, não sugira desligar o SELinux. Certamente essa é uma opção, mas prefiro aprender como deixá-la ligada e aprender a discernir o curso de ação adequado para fazê-lo quando surgirem questões dessa natureza.

NOTA: Os comandos audit2allow -M ..e acima mencionados semanage -iresolvem problemas do SELinux sem reetiquetagem, mas ainda não está claro se uma reetiquetagem pode ter evitado a necessidade de criar a política. Ainda não está claro se resolver o problema dessa maneira é esperado e/ou normal.

#============= postfix_postdrop_t ==============

#!!!! This avc is allowed in the current policy
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

Tendo encontrado recentemente um servidor de terminal Windows NT 4.0 muito antigo que ainda está em uso, trabalhando fora do local e tendo que fazer suporte remoto, tornou-se necessário usar esse sistema realmente antigo às vezes. Vários sistemas Windows e Linux estão disponíveis para uso, mas ficou claro que a maioria das imagens do Windows que tenho disponíveis (Windows XP SP3 e superior) não oferecem suporte à conexão com o Windows NT 4.0 Terminal Server.

No momento, a maneira como o servidor de terminal Windows NT 4.0 é acessado, um RDPs em um sistema Windows XP SP3 que possui uma cópia de carregamento lateral dos arquivos .exe e .dll do cliente RDP 5.1. Então, a partir daí, conecta-se ao NT 4.0 Terminal Server. Para mim, isso significa fazer um salto RDP duplo.

Pode-se realmente gostar de ser capaz de RDP diretamente para o sistema NT 4.0 ou XP SP3, conforme necessário, sem ter que passar pelo antigo cliente RDP na caixa XP SP3 especialmente configurada para chegar ao sistema NT 4.0.

Para tornar a solução ainda melhor, seria ideal fazer isso no Linux em vez do Windows. Um bom número de postagens on-line que dizem que os clientes RDP modernos não fazem isso, mas seria bom pensar que isso não é totalmente verdade, mesmo que seja verdade.

Freerdp w/ Remmina funciona bem para conectar à caixa XP SP3, mas não para a caixa NT 4.0.

Existe uma solução RDP para Linux que ainda suporte conexões RDP 4.x?