Abrir a ferramenta App Center e outros aplicativos, como o Desktop Security e o atualizador de firmware, resulta em uma página em branco com a mensagem de erro: "Não foi possível criar sessão GX" no Ubuntu Budgie 24.10. Suspeito que o problema esteja relacionado à GPU Nvidia 3050, ao driver Nvidia mais recente e ao sistema gráfico X11. Soluções alternativas, como fazer o downgrade dos drivers Nvidia ou reinstalar o software problemático, não funcionam. Pesquisei online e parece ser um bug conhecido. Você encontrou alguma solução? Ou atualizar para o recém-lançado Ubuntu 25 é a única opção?
Estou com um problema ao configurar meu firewalld para ter um link perfeito com o docker e o fail2ban.
Primeiro, o que quero alcançar é a seguinte configuração de roteamento de tráfego:
[PUBLIC] ->
[FIREWALLD] -> (
[143/tcp FORWARD PORT] -----> [DOCKER/143/tcp]
[ 22/tcp] -----> [openssh locally running]
)
falha2banimento
Configurei o fail2ban para ouvir meu contêiner docker, verificar erros de autenticação e configurar um ban usando firewall-cmd. Isso funciona até agora. Assim que eu erro de autenticação 3 vezes, ele envia um comando para o firewalld.
Encaminhamento de porta
Eu também configurei o encaminhamento de porta para o docker. Estou configurando explicitamente, porque não quero que o docker destrua minha rede. Talvez isso seja algo que eu não precise no futuro, mas é configurado por meio da StrictForwardPorts=yesconfiguração. https://firewalld.org/2024/11/strict-forward-ports
Meta
O objetivo é que sempre que um gatilho fail2ban acontecer, o IP não tenha mais acesso à porta 143 (encaminhada) e (talvez) nem às outras. Mas, a princípio, eu gostaria de banir por porta.
Problema
O problema atualmente é que, se uma regra de rejeição avançada for criada, ela bloqueará a porta 22 para esse IP, mas não a porta 143.
Tentativas
Eu também tentei colocar o IP na dropzona, dando a ele a prioridade -10. Mesmo resultado de erro. A porta 22 é descartada, mas a 143 ainda funciona.
O que estou fazendo errado? Aqui está minha configuração de zona da última tentativa:
docker (active)
target: ACCEPT
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: br-0aa8d4b5dde7 docker0
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule priority="-999" family="ipv4" source address="192.168.178.44" reject
drop (active)
target: DROP
ingress-priority: -10
egress-priority: -10
icmp-block-inversion: no
interfaces:
sources: 192.168.178.44
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
public (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
port=143:proto=tcp:toport=143:toaddr=172.18.0.2
source-ports:
icmp-blocks:
rich rules:
rule priority="-999" family="ipv4" source address="192.168.178.44" reject
Como visto: Na verdade, o endereço 192.168.178.44 deveria estar totalmente bloqueado para a zona pública. Mas não está. Além disso, adicionei o IP à drop zone. Parece que a prioridade da drop zone está funcionando, pois minha conexão SSH é descartada em vez de rejeitada, mas a porta 143 ainda está acessível
Atualização 1: Algumas informações de depuração
$ sudo firewall-cmd --get-policies
allow-host-ipv6 docker-forwarding
Atualização 2: --info-policy=docker-forwarding
docker-forwarding (active)
priority: -1
target: ACCEPT
ingress-zones: ANY
egress-zones: docker
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules: `
Atualização 3:
Outra ideia que me veio à mente foi criar outra política com prioridade -10, contendo a regra rica:
sudo firewall-cmd --permanent --new-policy ban-pre-routing
sudo firewall-cmd --permanent --policy ban-pre-routing --add-ingress-zone ANY
sudo firewall-cmd --permanent --policy ban-pre-routing --add-egress-zone HOST
sudo firewall-cmd --permanent --policy ban-pre-routing --set-priority -10
sudo firewall-cmd --permanent --policy ban-pre-routing --add-rich-rule="rule family=ipv4 source address=192.168.178.44 port port=143 protocol=tcp reject"
Ainda sem efeito. Meu Host *.44 ainda pode se conectar à máquina. Se eu deixar de fora a port port=143 protocol=tcpparte, ele bloquearia a máquina para ssh - enquanto ainda seria capaz de acessar a porta 143.
Atualização 4: Usando a Atualização 3 com a política configurada para egress zone docker, não resulta em diferença. Minhas configurações estão assim agora:
$ sudo firewall-cmd --list-all-policies
allow-host-ipv6 (active)
priority: -15000
target: CONTINUE
ingress-zones: ANY
egress-zones: HOST
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv6" icmp-type name="neighbour-advertisement" accept
rule family="ipv6" icmp-type name="neighbour-solicitation" accept
rule family="ipv6" icmp-type name="redirect" accept
rule family="ipv6" icmp-type name="router-advertisement" accept
ban-pre-routing (active)
priority: -10
target: CONTINUE
ingress-zones: ANY
egress-zones: docker
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="192.168.178.44" port port="143" protocol="tcp" reject
docker-forwarding (active)
priority: -1
target: ACCEPT
ingress-zones: ANY
egress-zones: docker
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
E para zonas:
$ sudo firewall-cmd --list-all --zone=public
public (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
port=143:proto=tcp:toport=143:toaddr=172.18.0.2
source-ports:
icmp-blocks:
rich rules:
$ sudo firewall-cmd --list-all --zone=drop
drop
target: DROP
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
$ sudo firewall-cmd --list-all --zone=docker
docker (active)
target: ACCEPT
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: br-c5f172e4effe docker0
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Tenho um programa que executará um conjunto de comandos em novas instalações de servidor e preciso alterar uma entrada em um arquivo para cada instalação. Precisamos alterar o DNS padrão de 127.0.0.X (que é o padrão, pois instala sem uma conexão com a Internet) para 8.8.8.8
Eu estava usando o seguinte comando:
sudo awk '{sub(/#DNS=/,"DNS=8.8.8.8")}' /etc/systemd/resolved.conf
no entanto, isso não parece estar funcionando no gawk/nova versão do sistema operacional.
sudo gawk '{gensub(/#DNS=/,"DNS=8.8.8.8")}' /etc/systemd/resolved.conf
O que estou fazendo errado? Existe uma maneira melhor de alterar a entrada DNS padrão?
Sistema operacional do servidor atual:Ubuntu 24.04.2-live-server
Sistema operacional do servidor anterior:Ubuntu 20.04.6-live-server
EDITAR:
Arquivo de entrada de linha de amostra:
#DNS=
#FallbackDNS=
#Domains
O comando deve encontrar a primeira linha acima e substituí-la por DNS=8.8.8.8"mas não é".
Saída desejada:
DNS=8.8.8.8
#FallbackDNS=
#Domains
Quando executo o comando awk, o arquivo ainda lê:
#DNS=
#FallbackDNS=
#Domains
Além disso, ele deve encontrar e substituir apenas uma correspondência exata de#DNS=
Qual comando e sintaxe substituirão #DNS=por DNS=8.8.8.8?
Após uma falha (o navegador travou), tentei uma reinicialização forçada e, na inicialização, apareceu esta tela, que não consigo ignorar apenas pressionando Enter.
Isso já aconteceu antes e, depois de várias tentativas e pressionando vários botões, ele finalmente inicializou novamente, mas não tenho certeza do porquê
Meu laptop costumava ter Windows, mas eu o apaguei e instalei o Ubuntu.
O que está acontecendo aqui?
Eu uso um systemdserviço para iniciar vários processos quando o Ubuntu 20.04 é inicializado.
# MyApp start app service
[Unit]
Description=MyApp start service
Requires=network-online.target
After=network-online.target
[Service]
Type=simple
ExecStartPre=/bin/sleep 20
ExecStart=/etc/init.d/MyApp.sh start
ExecStop=/etc/init.d/MyApp.sh stop
LimitMEMLOCK=infinity
LimitCORE=infinity
RemainAfterExit=yes
User=admin
[Install]
#WantedBy=multi-user.target
#WantedBy=graphical.target
WantedBy=basic.target
Todos os meus processos iniciam após a inicialização do sistema. No entanto, após alguns minutos, o nível de usuário systemdsai e remove todos os semáforos criados pelos meus processos.
Parece que posso definir RemoveIPC=No configuration /etc/systemd/logind.confpara impedir que o usuário systemdremova os semáforos.
Mas por que o usuário systemdsaiu? Devo usar o comando sudo loginctl enable-linger adminpara impedir que ele saia?
Obrigado!
Estou colaborando em uma implantação que visa fornecer Hadoop, Hive e Impala para fins de aprendizado e ensino. Usamos o Ubuntu 22.04 como sistema base em uma VM.
Enquanto tudo relacionado ao HDFS, Hadoop e Hive está funcionando bem (incluindo PostgreSQL para Hive Metastore), a instalação do Impala está sendo um desafio muito difícil. Eu apliquei os comandos recomendados na Documentação do Apache para construir o Impala, e então executei make install.
Após a construção, ao tentar executar catalogdo serviço, ele não inicia, registrando o seguinte:
cat /tmp/catalogd.pc.hadoop.log.ERROR.20250311-114741.4782
Log file created at: 2025/03/11 11:47:41
Running on machine: pc
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
E0311 11:47:41.450573 4782 logging.cc:256] stderr will be logged to this file.
E0311 11:48:10.130164 4782 catalog.cc:101] NoSuchMethodError: org.apache.hadoop.hive.metastore.IMetaStoreClient.getThriftClient()Lorg/apache/hadoop/hive/metastore/api/ThriftHiveMetastore$Client;
. Impalad exiting.
Picked up JAVA_TOOL_OPTIONS: -Dsun.java.command=catalogd
statestorede admissiondestão trabalhando.
Usando o commit 34b17db7b473d6729ac6c9cf139fcf410f18d941 do Impala e o Hive 4.0.1 pré-compilado.
Não consigo mais montar meu HDD. Depois da última vez que o usei, cliquei em " Remover com segurança " no meu navegador de arquivos, e agora não consigo mais ler dados nele.
Aqui estão alguns comandos de diagnóstico que executei:
# fdisk -l
Disk /dev/sdb: 465.73 GiB, 500074283008 bytes, 976707584 sectors
Disk model: Elements 10A8
Units: sectors of 1 × 512 = 512 bytes
Sector size (logical / physical): 512 bytes / 512 bytes
I/O size (minimum / optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xf2c19c1e
Device Boot Start End Sectors Size Id Type
/dev/sdb1 256 976707583 976707328 465.7G 7 HPFS/NTFS/exFAT
# fsck.exfat /dev/sdb1
exfatprogs version : 1.2.2
too long label. 139
failed to read volume label
invalid start cluster of allocate bitmap. 0x34c04c90
failed to read bitmap
failed to verify root directory.
/dev/sdb1: clean. directories 1, files 0
# mount /dev/sdb1 /media/myself/Medias/
mount: /media/myself/Medias: can't read superblock at address /dev/sdb1.
dmesg(1) may have more information after failed mount system call.
Aqui estão as mensagens vistas dmesgao tentar o comando de montagem anterior:
[ 1439.474346] exFAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 1439.516358] exFAT-fs (sdb1): failed to read sector(0xd57a397000)
[ 1439.516365] exFAT-fs (sdb1): failed to load upcase table
[ 1439.516367] exFAT-fs (sdb1): failed to recognize exfat type
Estou testando o TestDisk para analisar/reparar meu HDD, mas como posso repará-lo?
Não tenho problemas para inicializar meu sistema. Esta pergunta é sobre como reparar uma unidade externa usada para armazenamento de dados.
Tenho uma configuração de volume lógico lvm2 e preciso adicionar um novo disco a ele, e sei como fazer isso da maneira "padrão" sem problemas. No entanto, gostaria de adicionar o disco de uma forma mais "granular" e não tenho certeza se isso é possível.
O único volume físico atualmente conectado ao volume lógico existente é um M.2 nvme, enquanto o novo disco é um SSD SATA mais lento. Se eu conectá-lo da maneira "padrão", novos dados serão divididos entre esses dois discos, diminuindo a velocidade do throughput.
Agora, o sistema de arquivos dentro do volume lógico tem diretórios com diferentes requisitos de velocidade de acesso, por exemplo: acesso rápido para um diretório contendo filmes 4K e velocidade de acesso menos crítica para fotos ou áudio em outros diretórios.
Então a questão é, é possível fazer isso usando lvm? Como eu disse, acho que não, porque AFAIK não há link entre lvm e o sistema de arquivos. Quais são minhas opções para atingir esse objetivo?
Minha maneira anterior era montar o novo disco em /mnt, mover os dados do diretório para lá e substituir o diretório anterior por um link simbólico para o novo ponto de montagem; isso é confuso.
Agradecemos antecipadamente por quaisquer informações.
Usei o Homebrew para instalar o Node no Ubuntu 16.04.4 LTS:
brew install node
Gostaria de usar o NodeJS versão 18.8.0 ou superior até <20.0.0.
Corri então:
nvm install 18.18.2
Entretanto, não consigo obter a versão desejada do NodeJS:
user@server:~/test$ nvm use 18.18.2
Now using node v18.18.2 (npm v10.9.2)
user@server:~/test$ nvm --version
0.40.1
user@server:~/test$ node --version
v23.7.0
Aqui está a lista de versões de instalação do NVM:
user@server:~/test$ nvm ls
v14.15.5
v16.20.2
v18.18.2
-> system
default -> node (-> v18.18.2)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v18.18.2) (default)
stable -> 18.18 (-> v18.18.2) (default)
lts/* -> lts/jod (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.21.3 (-> N/A)
lts/gallium -> v16.20.2
lts/hydrogen -> v18.20.7 (-> N/A)
lts/iron -> v20.18.3 (-> N/A)
lts/jod -> v22.14.0 (-> N/A)
O computador está executando o Ubuntu 16.04.4 LTS 64 bits. A execução nvm use 16.20.2funciona bem e me dá o nodejs 4.2.6 (verificado com nodejs --version). Gostaria de usar o Node versão 5.6.0 ou superior nele, então tentei executar:
user@server:~/test$ nvm use 18.18.2
Mas recebo o erro:
node: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by node)
node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node)
O erro ocorre porque a versão 18.18.2 do Node.js requer uma versão mais recente do glibc (2.25, 2.27 ou 2.28) que não está instalada.
Como posso instalar o Node versão 5.6.0 ou superior no Ubuntu 16.04?