Tenho alguns servidores baremetal executando RHEL, que anteriormente tinham alguns problemas com travamentos de java/JVM e, ocasionalmente, algumas mensagens de erro de memória em nível de kernel. Os servidores agora estão quase todos ociosos, pois as cargas de trabalho foram movidas para outro lugar, aguardando a substituição da memória.

Depois de ler a postagem de Aleksey Shipilёv Please test your memory , gostaria de executar o memtester no host para ver se ele detectaria esses problemas sem precisar reinicializar. Normalmente, usaríamos apenas o memtest86+ "normal" na reinicialização, mas pode ser interessante ter alternativas.

Quanto tempo levaria para concluir uma execução do memtester em um servidor da era de 2016 com 3 TB de memória?

Estou tentando configurar um virtualenv no meu tcsh e quando executo um shell bash consigo executar este comando perfeitamente

source ./venv/bin/activate 

Mas quando executo esse mesmo comando de um tcsh recebo essa mensagem de erro

missing "}" .

Como posso consertar isso?

• Fiz o seguinte ontem à noite (antes da meia-noite de domingo na Alemanha):

• Data de hoje

$ LC_TIME="en.GB.UTF8" date --iso-8601
2025-01-12

• Data de hoje (dia da semana

$ LC_TIME="en.GB.UTF8" date +%u
7

$ LC_TIME="en.GB.UTF8" date +%a
Sun

Emitir

• Como a semana começa de segunda a domingo, a segunda-feira desta semana deve ser 2025-01-06

$ LC_TIME="en_GB.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_IE.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_IN.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_US.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_DE.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_JP.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_DK.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_CA.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

$ LC_TIME="en_AU.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

Outra observação

Fiz isso hoje em 2025-01-13 (na Alemanha)

$ LC_TIME="en_AU.UTF-8" date -d "this-week-sunday" --iso-8601
2025-01-19
$ LC_TIME="en_AU.UTF-8" date -d "last-week-sunday" --iso-8601
2025-01-12
$ LC_TIME="en_AU.UTF-8" date -d "next-week-sunday" --iso-8601
2025-01-26

Emitir

Então, hoje parece estar dando resultados parcialmente corretos. O que está errado na saída de hoje: se da saída de ontem this-week-mondayestava 2025-01-13assim, de alguma forma o computador estava contando domingo como o primeiro dia da semana em cada localidade (que mostrei acima). Então "this-week-sunday"deveria ser ontem e não 2025-01-19 (como mostrado hoje).

Resumo

Ontem

$ LC_TIME="en_GB.UTF-8" date -d "this-week-monday" --iso-8601
2025-01-13

Hoje

env -i bash --norc --noprofile
bash-5.2$ LC_TIME="en_AU.UTF-8" date -d "this-week-sunday" --iso-8601
2025-01-19

Problema : Então, se ontem (2025-01-12, domingo) this-week-mondayfoi dia 13, hoje this-week-sundaydeveria ser ontem e não . 2025-01-19 Por que estou recebendo a data errada?

O bashshell expande parâmetros não definidos para a string vazia por padrão. No entanto, não consigo encontrar documentação oficial afirmando isso em lugar nenhum. É?

Quero executar um servidor de e-mail para mim (estou inclinado a usar o postfix), mas preciso que ele seja parecido com isto:

[MUA] <-> [MTA inicial] <--> [MTA externo]

O Home MTA fica em um servidor de virtualização na minha casa e só aceita e-mails do MTA externo (por meio de sua configuração, mas também do firewall). O MTA externo só aceita e-mails para meu domínio, tem DKIM/SFP e (inicialmente, de qualquer forma) não vai entregar e-mails para ninguém, exceto meu MTA doméstico.

Acho que se eu fizer isso direito, isso deve me impedir de ser colocado na lista negra e também de doxxar meu IP residencial, já que esse não será o MTA listado usando os registros MX dos meus domínios. Eu penso nisso quase como um bastião ou servidor de salto, mas para e-mail em vez de ssh.

1. isso é possível fazer?
2. em que mais eu deveria pensar? Por exemplo, encontrei uma página falando sobre como evitar e-mails de retrodispersão, o que não tinha me ocorrido.
3. Estou assumindo que o MTA-para-MTA pode ser criptografado e autenticado. Isso é SASL?
4. Existe um termo para esse tipo de configuração para que eu possa encontrar uma configuração básica e partir daí? Por exemplo, isso é chamado de relé inteligente com um satélite ou algo assim?

EDIT: Acho que eu gostaria de desabilitar o SMTP em favor do SMTPS e configurar o postfix para não aceitar e-mails de saída de um usuário não autenticado. Isso impede que spammers usem meu MTA para enviar e-mails, certo? Se for esse o caso, por que ainda é geralmente recomendado não executar seu próprio servidor de e-mail devido a ter que lidar com todo o spam?

Atualmente, estou usando o arquivo "hosts" para isso, mas está ficando mais difícil mantê-lo em várias estações de trabalho...

Gostaria de configurar um servidor de nomes em nossa rede local que possa substituir ou anexar hosts a domínios existentes.

Por exemplo, sql.ourdomain.tldé definido no "master dns" SOA dns.ourdomain.tldcom IN A 80.90.100.200e eu gosto de sobrescrevê-lo IN A 192.168.15.5em nosso servidor de nomes local.

Então é "responder localmente primeiro, encaminhar cada NXDOMAIN para um resolvedor diferente"

Acho que existe uma solução porque "pihole" faz coisas parecidas.

Comecei a aprender sobre tty(s) e sinais do Linux e tive alguns problemas.

Estou lendo e usando o livro The TTY demystified como referência.

Criei dois programas simples de golang.

Pai:

package main

import (
    "fmt"
    "syscall"
    "time"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    for {
        fmt.Println("hi from parent")
        time.Sleep(time.Second * 10)
    }
}

Criança:

package main

import (
    "fmt"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    signal.Ignore(syscall.SIGTSTP) // golang's way to handle (ignore) signal

    for {
        fmt.Println("hi from child")
        time.Sleep(time.Second * 5)
    }
}

Eles são bem simples. Ambos apenas imprimem uma mensagem para tty a cada 5/10 segundos. A única diferença é que o filho ignora o sinal SIGTSTP (ctrl-z). Então, quando eu pressiono ctrl-z, ele suspende o pai, mas não o filho. É exatamente o que eu esperava. No entanto, o que eu não esperava é que todo o grupo fosse movido do primeiro plano para o grupo de segundo plano. Isso contrasta com The TTY demystified . Especificamente:

Quando todos os processos no trabalho em primeiro plano foram suspensos , o líder da sessão lê a configuração atual do dispositivo TTY e a armazena para recuperação posterior. O líder da sessão continua a se instalar como o grupo de processos em primeiro plano atual para o TTY usando uma chamada ioctl. Então, ele imprime algo como "[1]+ Stopped" para informar ao usuário que um trabalho foi suspenso.

Ele diz que somente quando todos os processos no trabalho em primeiro plano forem suspensos , o líder da sessão (shell/bash) moverá o grupo para o trabalho em segundo plano...

Resultado de ps l -t /dev/pts/0antes e depois de ctrl-z:

yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1747467 1747441  20   0  14288  5632 do_wai Ss   pts/0      0:00 bash
0  1000 1747496 1747467  20   0 1225432 1792 ep_pol Sl+  pts/0      0:00 ./parent
0  1000 1747501 1747496  20   0 1225424 1664 ep_pol Sl+  pts/0      0:00 child
yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1747467 1747441  20   0  14288  5632 do_sel Ss+  pts/0      0:00 bash
0  1000 1747496 1747467  20   0 1225432 1792 do_sig Tl   pts/0      0:00 ./parent
0  1000 1747501 1747496  20   0 1225680 1792 ep_pol Sl   pts/0      0:00 child

Se eu mover o ignore ( signal.Ignore(syscall.SIGTSTP)) do filho para o pai, então tudo funciona como deveria (do meu ponto de vista). O filho suspende (T), o pai retoma normalmente (R/S), mas o grupo ainda é o trabalho de primeiro plano.

yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1749437 1749410  20   0  14420  5632 do_wai Ss   pts/0      0:00 bash
0  1000 1749957 1749437  20   0 1225448 1920 ep_pol Sl+  pts/0      0:00 ./parent
0  1000 1749962 1749957  20   0 1225412 1664 ep_pol Sl+  pts/0      0:00 child
yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1749437 1749410  20   0  14420  5632 do_wai Ss   pts/0      0:00 bash
0  1000 1749957 1749437  20   0 1225448 1920 ep_pol Sl+  pts/0      0:00 ./parent
0  1000 1749962 1749957  20   0 1225668 1792 do_sig Tl+  pts/0      0:00 child

Por que isso está acontecendo? O que estou perdendo?

Após a atualização aptpara a versão >= 2.9.19, as assinaturas SHA1 e RSA1024 são rejeitadas.

Há uma seção em seu changelog que diz:

apt (2.9.19) instável; urgência=média

• Substitua GnuTLS e gcrypt por OpenSSL
• Substitua o GnuPG pelo Sequoia nas plataformas Debian suportadas
  • métodos: Adicionar novo método sqv
  • debian: Adicionar política padrão para permitir autoassinaturas SHA-1 até 2026
  • debian: Conecte sqv ao pacote build

Então pensei que isso permitiria que uma política aceitasse assinaturas SHA1, mas talvez eu tenha entendido errado.

Sei que os arquivos acessados ​​recentemente são armazenados em cache na RAM, mas há um cache para comandos frequentes?

Por exemplo, se eu executar cat file.txtvárias vezes, file.txtele será armazenado em cache após o primeiro comando.

1. Mas se eu executar ps auxvárias vezes, a saída do primeiro comando será armazenada em cache em algum lugar?
2. Cada aplicativo tem seu próprio cache para comandos frequentes; por exemplo git log?

Depois de ler esta pergunta relacionada , acho que o termo correto para isso é memorização .

No Linux, qual é a melhor maneira para um programa detectar quando "um evento" acontece que altera as atribuições de ttys para dispositivos USB?

Especificamente, tenho uma caixa Linux com alguns dispositivos conectados (nesse caso, um dongle USB Zigbee 3.0 e um adaptador serial RS232). Por um motivo desconhecido ( dmesgsaída incluída abaixo), o dispositivo USB para o adaptador serial simplesmente mudou de /dev/ttyUSB1 para /dev/ttyUSB2.

Meu aplicativo precisa fechar o primeiro dispositivo e reabrir o novo dispositivo, mas não tenho uma boa maneira de detectar que isso ocorreu. Eu executo meu aplicativo como um usuário regular (não root), embora o usuário seja group dialout, portanto, por padrão, ele tem permissões para abrir/escrever em dispositivos /dev/tty...

Existe uma maneira padrão para um usuário não root ser notificado quando ocorrerem alterações no USB?

Caso contrário, a mesma pergunta vale para o root? - neste caso, criarei um processo daemon apenas para encaminhar a notificação.

saída dmesg:

[379860.188382] usb usb1-port1: disabled by hub (EMI?), re-enabling...
[379860.188447] usb 1-1: USB disconnect, device number 4
[379860.190728] usb 1-1: failed to send control message: -19
[379860.191332] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
[379860.191370] ch341 1-1:1.0: device disconnected
[379860.471428] usb 1-1: new full-speed USB device number 5 using ohci-pci
[379860.672320] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.54
[379860.672334] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[379860.672338] usb 1-1: Product: USB2.0-Ser!
[379860.675389] ch341 1-1:1.0: ch341-uart converter detected
[379860.693520] usb 1-1: ch341-uart converter now attached to ttyUSB1
[568726.990913] usb usb1-port1: disabled by hub (EMI?), re-enabling...
[568726.990978] usb 1-1: USB disconnect, device number 5
[568726.992847] usb 1-1: failed to send control message: -19
[568726.993907] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
[568726.993938] ch341 1-1:1.0: device disconnected
[568727.270327] usb 1-1: new full-speed USB device number 6 using ohci-pci
[568727.467843] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.54
[568727.467856] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[568727.467860] usb 1-1: Product: USB2.0-Ser!
[568727.470926] ch341 1-1:1.0: ch341-uart converter detected
[568727.489050] usb 1-1: ch341-uart converter now attached to ttyUSB2

Observação: até onde sei, nada aconteceu com esta caixa, ela estava parada (sem supervisão) na mesa e funcionando bem por pelo menos 24 horas, então esse "evento" ocorreu.

Não há um hub externo, ambos os cabos USB são conectados na parte traseira da caixa. Sei que há um chip "hub USB" dentro da maioria dos PCs, então é provável que seja a isso que o dmesgesteja se referindo.

Na pior das hipóteses, provavelmente posso:

• Identifique a falha de gravação dentro do meu aplicativo.
• Listar todos os dispositivos /dev/tty...
• Use udevadmpara identificar cada tty.
• Reconecte-se ao correto.

Estou apenas perguntando para ver se há algo melhor (ou seja, ser notificado imediatamente em vez de esperar a próxima gravação para detectar a falha).