All perguntas(server)

Tenho dois hosts do Windows Server 2019 que não conseguem iniciar o serviço do servidor SSSH do OpenSSH após a instalação das seguintes atualizações do Windows:

.NET Framework 4.8
Outubro de 2024 Atualização cumulativa
Ferramenta de remoção de software malicioso

A data de modificação mudou para ontem à noite em todos os arquivos em C:\Windows\System32\OpenSSH:

Diretório OpenSSH

A tentativa de iniciar o serviço resulta em:

"O Windows não pôde iniciar o serviço SSH OpenSSH no computador local. Erro 1067: O processo foi encerrado inesperadamente"

Não há nada no arquivo de log SSH ao tentar iniciar. O Log de Eventos não fornece detalhes úteis que eu possa encontrar além de dizer "O serviço OpenSSH SSH Server foi encerrado inesperadamente. Ele fez isso 8 vezes."

Tenho um PC com Windows 10 que serve como controlador de uma máquina de corte a laser. O PC tem atualizações desativadas para garantir que nada mude que possa causar um problema futuro ou incompatibilidade com a máquina à qual ele é dedicado.

Como ele não receberá atualizações do Windows, não confio neste PC e quero mantê-lo isolado do resto da minha rede.

No entanto, ele precisa ter acesso a um compartilhamento de rede (em um NAS) para poder acessar seus programas de corte a laser e arquivos relacionados.

Eu já tenho o PC em sua própria sub-rede e vlan que é isolada do resto da rede, e que não tem acesso à internet. Mas dar a ele acesso à unidade compartilhada da rede dá a ele acesso a esse importante recurso compartilhado.

Quais são as práticas recomendadas para permitir o acesso a uma unidade compartilhada por um PC não confiável como este?

Eu administro um site científico, chamo de site.org, que é espelhado em três locais, todos listados no DNS como site.org para que os clientes escolham um espelho específico aleatoriamente. Os espelhos individuais são server1.site.org, etc. O certificado LetsEncrypt cobre site.org mais os nomes dos espelhos. Todos os espelhos estão dentro de universidades que estão doando largura de banda; não tenho financiamento para pagar pela largura de banda sozinho.

Uma universidade, univ.edu, decidiu recentemente que para "controle de segurança da comunicação https" (palavras deles) todos os sites dentro de sua rede devem estar atrás de seu certificado curinga *.univ.edu. A implementação deles é que no firewall, quando eles veem uma conexão de porta 443, eles interceptam o handshake SSL e substituem seu próprio certificado. Meu servidor nunca vê o handshake do certificado. O navegador do cliente vê o certificado *.univ.edu e o rejeita porque ele não cobre site.org. Pedi que o IP do meu servidor fosse colocado na lista de permissões para passagem, e eles disseram que fazer isso "não era possível".

Para mim, substituir o certificado deles pelo meu parece um ataque de adversário no meio. Para ser justo, não sei se eles estão realmente sentados lá e monitorando o tráfego, mas não vejo nada que os impeça de fazer isso. Não dou a mínima para o monitoramento para meus próprios propósitos (tudo no site é público de qualquer maneira), mas parece uma má ideia para mim, embora torne muito mais fácil para eles gerenciarem certificados para sites dentro do univ.edu.

Então: é normal que grandes organizações usem uma abordagem AITM para gerenciar certificados? Isso é realmente só porque eles querem bisbilhotar todas as conexões (de entrada, mas não de saída)? Há razões que eu não pensei para que isso seja uma Má Ideia?

Fundamentalmente, estou procurando argumentos fortes que eu possa usar para convencê-los a sair de sua posição. Se eles não cederem, temo que terei que desligar o espelho, o que seria triste para meus usuários, porque esse espelho tem uma largura de banda muito melhor para o continente em que está localizado. (Sugestões alternativas seriam apreciadas, no entanto!)

Estou configurando um GPO OU para firewall e outras configurações para recomendações do CIS SCA. Eu tive um problema com as configurações do firewall. Os PCs na OU estão recebendo todas as configurações de GPO exatamente como você esperaria, e tudo está funcionando bem; No entanto, após um período de tempo desconhecido, algumas horas ou no dia seguinte, no controlador de domínio, as configurações de GPO da OU para "Windows Defender Firewall com configurações avançadas de segurança" estão de volta aos padrões, como se eu não tivesse alterado nada - todas as outras configurações de GPO estão definidas como eu tinha e permanecem.

Então, o problema está no controlador de domínio, não no cliente incluído na UO.

Configuração do computador\Políticas\Configurações do Windows\Configurações de segurança\Firewall do Windows Defender com Segurança Avançada

Configurações: Estado:

• Ativando todos os 3 (Domínio, Privado, Firewall Público)
• Bloquear entrada (padrão)
• Permitir saída (padrão)

Configurações:

• Exibir notificação = Não
• Mesclagem de regras: aplicar regras de firewall local = Não
• Aplicar regras de segurança de conexão local = Não

Registro

• %SystemRoot%\System32\logfiles\firewall\domainfw.log (privatefw.log e publicfw.log respectivamente)
• Limite de tamanho 16.384
• Log de pacotes descartados = Sim
• Registrar conexões bem-sucedidas

Observação* O firewall está gravando com sucesso em todos os 3 arquivos.

• Windows Server 2019, os PCs são Dell Wyse ThinClients Windows 10 Enterprise LTSC
• NÃO há outros GPOs, exceto Domínio Padrão e Controladores de Domínio Padrão...

Estou travado. Alguém já viu isso antes ou tem sugestões?

Obrigado pelo seu tempo,

Gostaria de remover uma pasta no meu servidor FTP, hospedado pelo PureFtpd, em um script, para automatizar essa tarefa. Tenho um script bash como esse:

#!/bin/sh

HOST=myhost.com
USER=my-user
PASSWORD=my-password

ftp -inv $HOST <<EOF
user $USER $PASSWORD
cd /folder_A
ls
rmdir -r assets
bye
EOF

O servidor fornece este feedback:

Connected to myhost.com.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 1 of 160 allowed.
220-Local time is now #####. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 5 minutes of inactivity.
331 User my-user OK. Password required
230-Your bandwidth usage is restricted
230 OK. Current restricted directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
250 OK. Current directory is /folder_A
200 PORT command successful
150 Connecting to port 49849
drwxr-xr-x    3 3012       my-user          3 Oct  8 07:29 .
drwxr-xr-x   11 3012       my-user         16 Oct  7 22:49 ..
drwxr-xr-x    3 3012       my-user         13 Oct  7 22:46 assets
226-Options: -a -l 
226 3 matches total
550 Can't remove directory: No such file or directory
221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
221 Logout.

Entendo que a pasta "assets" não existe, mas a exploração do Filezilla me mostrou que a pasta ainda está presente.

Tentei executar sem sucesso o seguinte comando:

rmdir -r /folder_A/assets

Muitas buscas no Google não forneceram nenhuma solução. A próxima ideia é tentar o ChatGPT...

Estou recebendo o erro abaixo - estou fazendo isso na minha máquina local com o Docker Desktop - para sua informação

web-1 | 2024/10/08 01:08:24 [emerg] 12#12: bind() para 10.101.121.15:443 falhou (99: Não é possível atribuir o endereço solicitado) web-1 | nginx: [emerg] bind() para 10.111.121.13:443 falhou (99: Não é possível atribuir o endereço solicitado)

http {

      upstream backend {
          server cluster_1.ingress.com:443;
          server cluster_2.ingress.com:443; max_fails=2 fail_timeout=1s;
      }


      server {
            listen cluster_1.ingress.com:443;
            location / {
         resolver dns-default.openshift-dns;
         proxy_pass https://backend;

                   proxy_pass_request_headers on;
                   proxy_ssl_server_name on;
                   proxy_ssl_name cluster_1.ingress.com;
                   proxy_set_header Host cluster_1.ingress.com;
            }
      }

         server {
                  listen cluster_2.ingress.com;
                  location / {
                       resolver dns-default.openshift-dns;
                      proxy_pass "https://cluster_2.ingress.com";        
                   proxy_pass_request_headers on;
                   proxy_ssl_server_name on;
                   proxy_ssl_name cluster_2.ingress.com;
                   proxy_set_header Host cluster_2.ingress.com;
                  }
            }


    server {
         listen 8080 default_server;
         listen [::]:8080 default_server;
         root /usr/share/nginx/html;
         server_name _;

         add_header Access-Control-Allow-Origin * always;
         add_header Access-Control-Allow-Credentials true;
         add_header Access-Control-Allow-Headers Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range;
         add_header Access-Control-Allow-Methods GET,POST,OPTIONS,PUT,DELETE,PATCH;


         location / {
                   resolver dns-default.openshift-dns;
         proxy_pass $backend;
         }

  }
}

Configurei o registro PTR no servidor DNS da nossa organização. A pesquisa reversa funciona na nossa rede, mas de uma rede diferente, não funciona.

Parece-me que algo precisa ser feito pelo registro regional da Internet (RIR).

Não tenho ideia de como entrar em contato com eles. Então por que eles fariam o que eu quero?

Posso simplesmente configurar os registros PTR e, se eu fizer isso corretamente, ele funcionará?

Preciso do RIR para fazer alguma coisa?

É assim que todo mundo está fazendo?

PS: Estou confortável com DNS, mas DNS reverso é meio confuso para mim por enquanto (sou novo nisso).

Estou executando o slurm 21.08.5 instalado via apt.

Meu cluster tem 4 máquinas gpu (nd-gpu[001-005]) com 8 gpus cada. Posso executar trabalhos como

srun --gres=gpu:8 nvidia-smi -L

E eu vejo minhas gpus. Eu também posso agendar trabalhos reais com qualquer um de 0 a 8 gpus. No entanto, o agendamento de recursos não está funcionando corretamente. Se eu executar:

 srun --gres=gpu:1 sleep 1000

O nó inteiro será alocado e não poderei usar as 7 GPUs restantes naquele nó.

O que se segue é o gres.conf:

NodeName=nd-gpu001 Name=gpu File=/dev/nvidia0
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia1
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia2
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia3
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia4
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia5
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia6
NodeName=nd-gpu001 Name=gpu File=/dev/nvidia7
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia0
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia1
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia2
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia3
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia4
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia5
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia6
NodeName=nd-gpu002 Name=gpu File=/dev/nvidia7
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia0
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia1
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia2
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia3
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia4
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia5
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia6
NodeName=nd-gpu003 Name=gpu File=/dev/nvidia7
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia0
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia1
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia2
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia3
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia4
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia5
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia6
NodeName=nd-gpu004 Name=gpu File=/dev/nvidia7

o slurm.conf:

# See the slurm.conf man page for more information.  
#  
ClusterName=cluster  
SlurmctldHost=nd-cpu01  
SlurmctldHost=nd-cpu02  
#  

#GresTypes=  
#GroupUpdateForce=0  

ProctrackType=proctrack/cgroup  
ReturnToService=1  
SlurmctldPidFile=/var/run/slurmctld.pid  
SlurmctldPort=6817  
SlurmdPidFile=/var/run/slurmd.pid  
SlurmdPort=6818  
SlurmdSpoolDir=/var/spool/slurmd  
SlurmUser=slurm  
StateSaveLocation=/home/slurm/slurmctd  
TaskPlugin=task/affinity,task/cgroup  

# TIMERS  
InactiveLimit=0  
KillWait=30  

MinJobAge=300  

SlurmctldTimeout=120  
SlurmdTimeout=300  
Waittime=0  

# SCHEDULING  
SchedulerType=sched/backfill  
SelectType=select/cons_tres  

# LOGGING AND ACCOUNTING  
JobCompType=jobcomp/none  
JobAcctGatherFrequency=30  
SlurmctldDebug=info  
SlurmctldLogFile=/var/log/slurmctld.log  
SlurmdDebug=info  
SlurmdLogFile=/var/log/slurmd.log  

# COMPUTE NODES  
GresTypes=gpu
NodeName=nd-gpu[001-004] Sockets=2 CoresPerSocket=56 ThreadsPerCore=1 State=UNKNOWN Gres=gpu:8
PartitionName=debug Nodes=ALL Default=YES MaxTime=INFINITE State=UP

e o cgroups.conf:

ConstrainDevices=yes

Tenho um servidor que roda o Proxmox VE 8.2 (baseado no Debian 12), totalmente atualizado, que usa SAN multipath. Lá temos um espaço alocado, dez dispositivos de 2T cada, que são vistos 16 vezes cada (o número de caminhos) e que são mapeados em 10 dispositivos virtuais multipathed e coletados em um único grupo LVM, onde um volume lógico é esculpido. Sem problemas nesta parte.

Ele foi inicializado "on the fly" e estava funcionando bem, até que o host foi reiniciado. Depois disso, notei que sempre que alguém executa qualquer comando relacionado ao LVM ( lvs, etc.) no shell do sistema, ele emite o aviso no formato:

WARNING: Device mismatch detected for <LV> which is accessing <list of devices like
 /dev/sdak, /dev/sdaz, /dev/sdbn, ...> instead of <list of the devices
 like /dev/mapper/oamdwhdg-01, /dev/mapper/oamdwhdg-02, ...>

Na realidade, estes /dev/mapper/oamdwhdg-XXsão os dispositivos multipercurso, eles foram nomeados dessa forma por razões operacionais em /etc/multipath.conf:

multipaths {
...
    multipath {
        wwid 36...
        alias oamdwhdg-04
    }
...
}

Ou seja, por qualquer motivo, o LV é mapeado usando dispositivos de backend, em vez de usar dispositivos virtuais multicaminho.

Então atualizei o filtro em /etc/lvm/lvm.conf, que agora se parece com isto:

global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|.*|" ]

(Eu atualizei , não adicionei, estava global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]antes com o comentário added by pve-manager to avoid scanning ZFS zvols and Ceph rbds. Acredito que meu filtro seja muito mais rigoroso que esse.)

/dev/sda3é o disco local onde o PVE está instalado e contém o VG pveque não depende do SAN, então é o único /dev/sd...que não usa multipath e foi incluído na lista de permissões.

Testei esse filtro usando vgscane ele mostra que ambos os grupos podem ser encontrados.

Então eu executei update-initramfse reiniciei. Durante a inicialização, o servidor falhou no shell de emergência . Quando eu cheguei Ctrl+Dlá, ele, no entanto, inicializou quase normalmente: o VG multipathed é visto, mas não ativado (como se vgchange -an oamdwhdgainda não tivesse sido executado). Mas então eu o ativei manualmente perfeitamente normalmente com o comando dito e ele funcionou perfeitamente.

Suspeito que isso seja porque o multipath não foi inicializado corretamente antes do LVM no initramfs, então ele tentou configurar mapeamentos usando dispositivos /dev/sdXX. Mas por que ele falhou no shell de emergência quando adicionei o filtro, eu não entendo.

Duas perguntas (muito relacionadas) aqui: por que o shell de emergência, também conhecido como o que está errado, e como fazê-lo funcionar conforme o esperado?

Boa tarde, me deparei com o problema de não ser possível anexar o MetalLB ao K3S, tenho um cluster com 3 masters e 3 workers

NAME            STATUS   ROLES                       AGE    VERSION
master-node-1   Ready    control-plane,etcd,master   4d2h   v1.30.5+k3s1
master-node-2   Ready    control-plane,etcd,master   4d1h   v1.31.1+k3s1
master-node-3   Ready    control-plane,etcd,master   4d1h   v1.31.1+k3s1
worker-node-1   Ready    <none>                      4d1h   v1.31.1+k3s1
worker-node-2   Ready    <none>                      4d     v1.31.1+k3s1
worker-node-3   Ready    <none>                      4d     v1.31.1+k3s1

inicialmente, tentei instalar o MetalLB desta forma

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml

configuração

# config.yml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.0.170-192.168.0.180

com essa abordagem o Load Balancer estava funcionando, não estava estável no tap, com 50% de probabilidade era impossível entrar no site. Então descobri que essa é uma abordagem desatualizada. Tentei uma nova

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml

configuração

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: k3s-lb-pool
  namespace: metallb
spec:
  addresses:
  - 192.168.0.170-192.168.0.180
  autoAssign: true
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: k3s-lb-pool
  namespace: metallb

mas recebo um erro

Error from server (InternalError): error when creating "metalLB-config.yaml": Internal error occurred: failed calling webhook "ipaddresspoolvalidationwebhook.metallb.io": failed to call webhook: Post "https://metallb-webhook-service.metallb.svc:443/validate-metallb-io-v1beta1-ipaddresspool?timeout=10s": no endpoints available for service "metallb-webhook-service"
Error from server (InternalError): error when creating "metalLB-config.yaml": Internal error occurred: failed calling webhook "l2advertisementvalidationwebhook.metallb.io": failed to call webhook: Post "https://metallb-webhook-service.metallb.svc:443/validate-metallb-io-v1beta1-l2advertisement?timeout=10s": no endpoints available for service "metallb-webhook-service"

mas o namespace ainda está funcionando corretamente

root@master-node-1:~# kubectl get pod -n=metallb-system
NAME                          READY   STATUS    RESTARTS        AGE
controller-86f5578878-9ddsr   1/1     Running   2 (3m31s ago)   4m57s
speaker-5j47x                 1/1     Running   0               4m56s
speaker-6drpd                 1/1     Running   0               4m56s
speaker-ccpmq                 1/1     Running   0               4m56s
speaker-jfpch                 1/1     Running   1 (3m12s ago)   4m56s
speaker-mps8b                 1/1     Running   0               4m57s
speaker-t9lx2                 1/1     Running   0               4m56s

(Peço desculpas antecipadamente, o inglês não é minha língua nativa)