O comando Linux atexecuta o trabalho mesmo se eu fizer logoff da sessão de logon atual, certo? Mesmo se o sistema for reiniciado?
Se sim, qual é o serviço de segundo plano por trás dele? Se o trabalho, uma vez agendado, puder sobreviver a um logoff e/ou reinicialização, precisa haver um daemon/serviço de algum tipo.
Eu, como muitos, uso o VS Code para meu desenvolvimento. A maioria dos meus clientes hoje em dia precisa de trabalho feito em projetos existentes, o que, nem preciso dizer, eu não confio por padrão.
Então, para evitar ter que executar o código deles na minha máquina, eu executo VMs onde implanto os projetos deles e uso SFTP para montar a VM no host, depois abro /run/user/1000/gvfs/...no VS Code e faço o trabalho.
Isso funciona bem, exceto que funções como pesquisa profunda (ou como quer que seja chamado, estou falando de ctrl+ shift+ f) ou pesquisa de arquivo ( ctrl+ p) levam muito tempo. Aparentemente, o vscode precisa indexar o projeto e então eles funcionam como esperado, mas o problema é que na próxima vez que eu montar a VM, ele precisa indexá-la novamente.
Existe alguma maneira de dizer ao VS Code para manter o índice? Ou literalmente qualquer outra maneira de atingir meu objetivo de ser capaz de desenvolver como se estivesse desenvolvendo localmente sem correr o risco de executar os projetos na minha máquina?
Um nó na minha rede de repente se tornou inacessível do meu laptop e telefone, mas é acessível de outros nós. Ele também não consegue alcançar meu laptop ou telefone, mas consegue alcançar outros nós e alcançar a internet.
Isso aconteceu do nada. É um sistema relativamente novo e não me lembro de ter alterado nada. No entanto, pode ter coincidido com a instalação do Docker no computador em questão.
Uma visão geral da rede:
192.168.1.1- Roteador192.168.1.10- Repetidor sem fio192.168.1.20- HTPC.192.168.1.90- Computador portátil.Tanto o HTPC quanto o laptop estão conectados ao Wi-Fi principal.
O HTPC pode fazer ping em outros nós:
root@htpc:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=13.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=8.35 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 8.351/11.147/13.943/2.796 ms
root@htpc:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.05 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.87 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 3.045/3.456/3.868/0.411 ms
root@htpc:~# ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=4.74 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=63 time=5.26 ms
^C
--- 192.168.1.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 4.738/5.001/5.264/0.263 ms
Entretanto, ele não consegue fazer ping no laptop:
root@htpc:~# ping 192.168.1.90
PING 192.168.1.90 (192.168.1.90) 56(84) bytes of data.
From 192.168.1.20 icmp_seq=1 Destination Host Unreachable
From 192.168.1.20 icmp_seq=2 Destination Host Unreachable
From 192.168.1.20 icmp_seq=3 Destination Host Unreachable
From 192.168.1.20 icmp_seq=4 Destination Host Unreachable
From 192.168.1.20 icmp_seq=5 Destination Host Unreachable
From 192.168.1.20 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.90 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6145ms
pipe 4
root@htpc:~#
Sua tabela de roteamento se parece com isso, e o firewall ufw está desabilitado:
root@htpc:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 600 0 0 wlo1
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-a221f258ed7f
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlo1
root@htpc:~# ufw status
Status: inactive
Suas regras de tabelas de IP:
root@htpc:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (2 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Sua tabela ARO:
_gateway (192.168.1.1) at d4:24:dd:5d:22:9d [ether] on wlo1
? (192.168.1.10) at 30:23:03:dc:1c:19 [ether] on wlo1
Fazer ping no htpc do laptop não funciona, mas é claro que o laptop pode se comunicar com todos os outros nós:
kopf@prkbook ~ ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
ping: sendto: Host is down
Request timeout for icmp_seq 2
ping: sendto: Host is down
Request timeout for icmp_seq 3
ping: sendto: Host is down
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
^C
--- 192.168.1.20 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss
kopf@prkbook ~ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=5.044 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=10.624 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.044/7.834/10.624/2.790 ms
Tabela ARP do laptop:
? (192.168.1.1) at d4:24:dd:5d:22:9d on en0 ifscope [ethernet]
? (192.168.1.10) at 30:23:3:dc:1c:19 on en0 ifscope [ethernet]
? (192.168.1.20) at (incomplete) on en0 ifscope [ethernet]
? (192.168.1.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
mdns.mcast.net (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
Alguém tem alguma ideia de qual outro problema pode estar aqui?
Recebi ontem meu controlador HBA Tri-Mode Lenovo 430-16i LSI SAS3416 9400-16i 12G IT Mode NAS AU PCIe e a instalação ocorreu bem, fisicamente falando.
O firmware é atualizado e o controlador está sendo executado no modo JBOD (modo IT em alguns outros controladores).
O único cabo que estou usando é parecido com um: Mini SAS/SFF-8643 para 4 cabos SATA de 7 mm .
No entanto, nem o Linux nem o Windows veem o HDD SATA temporário que conectei. Li todos os manuais que pude encontrar e supostamente há um utilitário Ctrl-R neste controlador, mas nenhuma combinação de segurar Ctrl ou pressionar Ctrl- Rdurante a inicialização abrirá o utilitário Ctrl- R.
O que posso verificar? O HDD está bom - funciona com cabo SATA-SATA normal direto para a placa-mãe.
Eu tentei executar storcli64e consegui uma tonelada de informações sobre o controlador, então ele definitivamente está sendo detectado. lspcino Linux mostra o controlador como ele é. Até o Windows instalou automaticamente o driver correto. Mas, curiosamente, a ajuda para storcli64diz que eu deveria ser capaz de executar coisas como esta:
storcli64 /c0 show personality
E retornar ao modo atual (RAID|JBOD), mas que diz "Comando não suportado".
Também tentei o LSI Storage Authority e ele vê o controlador sem problemas. Cabos diferentes, mesmo problema. Mas todos os cabos são do mesmo modelo.
Eu até tentei atualizar o firmware da Intel como sugerido aqui . O HBA ainda funcionava e era detectado normalmente, mas ainda sem drives. A única diferença era o suporte para NVMe, do qual não preciso.
De acordo com meu entendimento do Secure Boot, ele provavelmente funciona assim:
Minha pergunta é: por que o Debian tornou o arquivo .der e as chaves públicas diretamente disponíveis em seu código-fonte? Isso significa que se um invasor de alguma forma obtiver acesso root a um sistema, ele pode assinar kernels modificados com as chaves públicas do Debian, quebrando o modelo de segurança. Agora, obter acesso root é certamente difícil de um ataque executado remotamente, mas não é completamente impossível.
Ou meu entendimento do mecanismo Secure Boot está errado, ou há outro propósito pelo qual essas chaves são disponibilizadas publicamente. Por favor, corrija meu entendimento.
O que curl --interface tun0faz? De acordo com man: Perform an operation using a specified interface. You can enter interface name, IP address or host name.Parece estar usando SO_BINDTODEVICE para conseguir isso. Aqui está o que me deixa confuso: pelo que entendi, quando um programa quer enviar um pacote para um destino específico, cabe à tabela de roteamento decidir qual interface usar como origem. Esta opção parece substituir isso de alguma forma. Então o que acontece se não houver uma rota (na tabela de roteamento), que usaria essa interface e alcançaria esse destino?
Caso um (um túnel que foi criado pela sing-box):
ip a:
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 9000 qdisc fq state UNKNOWN group default qlen 500
link/none
inet 172.18.0.1/30 brd 172.18.0.3 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::717d:757a:23db:789b/64 scope link stable-privacy
valid_lft forever preferred_lft forever
ip route:
172.18.0.0/30 dev tun0 proto kernel scope link src 172.18.0.1
curl example.com --interface tun0faz o que deve fazer (como, no entanto?) e solicita example.com por meio de tun0.
Caso dois (interface wireguard):
ip a:
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.230.116.1/24 scope global wg0
valid_lft forever preferred_lft forever
ip route:
10.230.116.0/24 dev wg0 proto kernel scope link src 10.230.116.1
O resultado é:connect to 142.44.215.161 port 80 failed: No route to host
Como ele sabe que, de fato, não há rota até lá?
Entendo que esses túneis são operados por programas de espaço do usuário (ou kernelspace). Isso é como um FuseFS onde esses programas podem simplesmente retornar "não, não permitido" quando não gostam de um IP de destino (ou "sim, posso fazer isso de qualquer maneira", mesmo que, de acordo com a tabela de roteamento, eles não devam enviar para lá)? Isso significa que a tabela de roteamento é completamente ignorada quando SO_BINDTODEVICE é usado? E se eu usasse eth0 em vez de tun0? É uma interface física, ela usaria a tabela de roteamento para descobrir se é possível rotear esse pacote? Finalmente, é possível fazer curl example.com --interface 172.18.0.1. Surpreendentemente, isso não é equivalente a --interface tun0, e não tem sucesso. Por que isso?
Estou usando uma conexão TCP para determinar o Path MTU (PMTU) extraindo o MSS da resposta SYN-ACK.
No entanto, não tenho certeza se esse método permanece confiável em casos em que a rota entre meu ponto de extremidade e o servidor é assimétrica.
Pelo que li, o MSS no SYN-ACK reflete a MTU do destino da conexão e pode ser reduzido por qualquer nó ao longo do caminho de retorno se tiver uma MTU menor.
Mas quando os caminhos de ida e volta diferem, pois eles podem atravessar diferentes saltos com MTUs variáveis, então posso obter resultados imprecisos. Existe uma maneira de conter toda a jornada de ida e volta no valor MSS recebido por SYN_ACK ?
Obrigado
Eu tenho um disco que está usando GPT, e há apenas 1 partição (Ext4) nele, de acordo com UEFI , a primeira 16 Bytesdelas GPT Partition Entry Arraydeve ser a Partition Type GUID. Então eu extraí minhas partições Partition Type GUIDe li a primeira 32 Digitsdelas, já que está em formato hexadecimal. Então eu obtive o GUID af3dc60f838472478e793d69d8477de4, depois de verificar com a lista na wikipedia, descobri que esse GUID em particular não significa nada. Então isso levantou a questão: Quem decide o tipo GUID e seu tipo correspondente? E há uma lista completa para o Tipo e seu GUID ou o meu simplesmente não existe? O GPT Partition Entry Arraycom zeros finais cortados:
af3dc60f838472478e793d69d8477de4e18058ef52250344ba2f0ae31c057fa60008000000000000ffb7c0d10100000000000000000000006500780074003400740062
Não me lembro qual é o termo certo, mas meu sistema faz um congelamento estranho de vídeo e mouse por 3 a 10 segundos em intervalos aleatórios. O áudio do vídeo continua ininterrupto e nunca experimentei isso enquanto jogo. Tenho um sistema novo e, na minha humilde opinião, de primeira linha que construí no final de 2024. 16 núcleos AMD, 64 GB de RAM DDR5, NVMe de 5ª geração, RTX 4090. Não estou tentando me exibir, mas parece que meu hardware não seria o problema.
Estou executando o Fedora SilverBlue 41 e isso tende a acontecer depois de alguns dias após a inicialização, com suspensão regular. Reinicializar o sistema parece redefinir o problema por alguns dias até que ele comece novamente. Acho que isso geralmente acontece de 4 a 5 vezes por hora, mas talvez mais ou menos. Não tenho certeza. Nem sempre acontece quando um vídeo está sendo reproduzido. Meu último sistema / sistema mais antigo executando o Fedora SilverBlue 40 não tinha esse problema. Eu olhei os logs (mas talvez perdi os logs certos), dmesg, uso de recursos, testei o estresse do NVMe, executei o MemTest e não consegui determinar a causa raiz.
Não sei se isso pode ser um problema de hardware que não entendo ou se é uma opção de configuração ou algo específico do Linux ou algo específico do Fedora ou SilverBlue.
ATUALIZAÇÃO: Parece iniciar após aproximadamente 12 horas de atividade.
Por algum motivo, o X11/lightdm trava ao pressionar o botão de energia do monitor. Em vez disso, executar xset dpms force offcoloca o monitor no modo de baixo consumo de energia, o que é bom e funciona em torno do pressionamento do botão de energia problemático.
Executando Arch Linux.
Após pressionar uma tecla para voltar a funcionar, a tela ficará em branco quando o computador estiver ocioso por vários minutos. Gostaria de desabilitar esse comportamento.
Como você escreveria um alias bash (por exemplo, off) que:
Por exemplo:
alias off='xset dpms force off ; wait until keypress ; xset -dpms'
Existe uma solução mais simples?