All perguntas(unix)

Eu sei que esse é um assunto popular, mas não consigo encontrar a solução certa para o meu problema. No meu PC, eu uso scp e ssh com firmware OpenWrt, geralmente eu uso Debian ou Linux Mint sem nenhum problema, mas eu fiz uma instalação nova e agora tenho problemas com o backup da minha configuração de firmware. Aqui está o que eu uso há 2 anos sem nenhum problema.

#  openwrt_backup
# Create tar_main
ssh [email protected] sysupgrade -b /tmp/backup-main-$(date +%F).tar.gz

# Copy to local dir
scp -O [email protected]:/tmp/backup-*.tar.gz james@ninja:/run/media/james/E/openWrt_backup/

O problema agora é que depois do segundo comando, transferir o backup para o meu PC local, nada acontece:

james@ninja:~> scp -O [email protected]:/tmp/backup-*.tar.gz james@ninja:/run/media/james/E/openWrt_backup/
james@ninja:~>      # empty answer??

Ideia? Obrigado

Meu computador da universidade usa Debian 10, e mesmo sendo bem antigo, ele tem uma combinação de teclas que eu realmente gosto: ao pressionar a tecla Alt, clicar em qualquer parte de uma janela a trata como se eu estivesse clicando na barra superior. Além disso, com o clique direito, posso controlar o tamanho da janela.

Gostaria de replicar esse comportamento no meu laptop pessoal Ubuntu 21.10. Você sabe como posso fazer isso?

Tenho um problema ao instalar um comando local no Kali Linux. Primeiro tentei entrar no seguinte

sudo apt install local

e me deu o seguinte erro

Erro: Não foi possível localizar o pacote aclocal

e então instalei o autotools-dev que encontrei neste link https://askubuntu.com/questions/45480/how-do-i-install-aclocal , lá dizia para primeiro instalar o autotools-dev para isso e depois instalar o comando aclocal, mas então estava me dando erro no Kali.

O Debian 11 traz o gnome-tweaks 3.34 que tem um menu de barra "Top Bar". Eu particularmente confio na opção "Seconds". Essa atualização regular da tela me ajuda a ter confiança de que uma conexão VNC ainda não foi desconectada.

Estou atualizando a frota para o Debian 13 que vem com o gnome-tweaks 46.1. Percebi que não há um menu "Top Bar".

Isso foi movido para algum lugar? Estou tentando encontrar algo nas notas de lançamento do upstream , mas o único lançamento no gitlab tem 7 anos.

Mostrar linhas passadas por here-document no stdout:

cat <<EOF
foo
bar
baz
EOF
foo
bar
baz

Quero corresponder uma string com grep via pipe:

cat <<EOF
foo
bar
baz
EOF 
|grep 'ba'

Por que não é possível passar o stdout pelo pipe para o comando grep?

Estou tentando criar uma regra udev que monte meu dispositivo pelo seu uuid, para que eu possa ler seu conteúdo posteriormente.

Meu arquivo udev está localizado no /etc/udev/rules.d/99-local.rules, e este é o seu conteúdo:

ACTION=="add", ENV{ID_FS_UUID}=="12CB-F616", SYMLINK+="masterkey", RUN+="/usr/bin/mountkey.sh"

O script executado pela regra udev consiste em:

LOG_FILE="/tmp/mount-key.log"

mount /dev/masterkey /mnt/masterkey >  "$LOG_FILE"

MOUNT_POINT="$(findmnt -n -o TARGET --source '/dev/masterkey')"

echo "Device mounted at $MOUNT_POINT" >> "$LOG_FILE"

O problema é que quando o udev invoca o comando mount, aparentemente ele não funciona e nem o comando produz nenhuma saída, bem como a variável de ambiente MOUNT_POINT no arquivo de log, embora o udev realmente crie o link simbólico da chave mestra .

O arquivo de log se parece com isto:

Device mounted at 

Eu comprovei que ele não montou a partição após executar lsblk:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1   3.8G  0 disk 
└─sda1        8:1    1   3.8G  0 part 
...

Editei o script e, em vez disso, executei-o com sudo , mas obtive a mesma saída acima. Então, decidi executar o comando mount como root sem esperar por uma senha (pensando que era o problema), editei o /etc/sudoersarquivo com visudo e adicionei a linha com o campo NOPASSWD para mount para o usuário root , assim:

root ALL=(ALL:ALL) ALL
root ALL=NOPASSWD:/usr/bin/mount 

Também tentei escrever para executá-lo de diferentes maneiras:

ACTION=="add", ENV{ID_FS_UUID}=="12CB-F616", SYMLINK+="masterkey", RUN+="/bin/bash -c '/usr/bin/mountkey.sh'"

ACTION=="add", ENV{ID_FS_UUID}=="12CB-F616", SYMLINK+="masterkey", RUN+="/bin/bash -c 'sudo /usr/bin/mount /dev/masterkey /mnt/masterkey'"

ACTION=="add", ENV{ID_FS_UUID}=="12CB-F616", SYMLINK+="masterkey", RUN+="/bin/bash -c '/usr/bin/mount /dev/masterkey /mnt/masterkey'"

Também fiz tudo isso com sh (com #!/bin/sh) e de nenhuma dessas formas funcionou. Então parece que não tem problema nenhum em invocar o script e criar o symlink, mas executar o binário mount de qualquer forma que ele seja apresentado.

E nem é meu binário de montagem , porque quando eu executo:

sudo mount /dev/sdnx /mnt/masterkey

funciona corretamente.

Depois de muitas tentativas sem ver nenhuma pista sobre qual poderia ser o problema, alterei a regra do udev para esta:

ACTION=="add", ENV{ID_FS_UUID}=="12CB-F616", RUN+="/bin/bash -c '/usr/local/bin/mountkey.sh $ID_FS_UUID'"

E meu script bash:

#!/bin/bash
UUID="$1"
DEVICE=$(blkid -o device -t UUID="$UUID")
echo "$UUID\n$DEVICE" > "/tmp/mountkey.log"

mount $DEVICE /media/masterkey

Mas, nossa! surpresa, nada mudou.

SISTEMA VM

Vagrant (archlinux/archlinux)

Kernel 6.10.10-arch1-1

SISTEMA REAL

Tentei executar a regra udev dentro da minha máquina real, que é:

Arco linux / 6.13.2-arch1-1

Mas ainda obtive o mesmo resultado (nenhuma partição montada no sistema).

Então, ao fazer isso, descobri que o problema está em um dos arquivos (a regra udev ou o script bash).

Após desbloquear o disco, a verborragia usual mudou e havia uma mensagem sobre baixar firmware. Quero descobrir o que estava acontecendo, então tentei dmsg -

% sudo dmsg
[    0.000000] microcode: microcode updated early to revision 0xf8, date = 2023-09-28
[    0.000000] Linux version 6.1.0-30-amd64 ([email protected]) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12)

A mensagem do microcódigo é muito vaga. É incomum?

Como posso determinar qual firmware tenho, o que devo ter e o que está disponível?

Editar: topo do changelog.Debian

intel-microcode (3.20241112.1~deb12u1) bookworm; urgency=medium

  * Build for bookworm
  * All trixie-only changes (from 3.20240813.2) are reverted on this branch

 -- Henrique de Moraes Holschuh <[email protected]>  Sat, 07 Dec 2024 14:49:05 -0300

intel-microcode (3.20241112.1) unstable; urgency=medium

  * New upstream microcode datafile 20241112 (closes: #1086483)
    - Mitigations for INTEL-SA-01101 (CVE-2024-21853)
      Improper Finite State Machines (FSMs) in the Hardware logic in some
      4th and 5th Generation Intel Xeon Processors may allow an authorized
      user to potentially enable denial of service via local access.
    - Mitigations for INTEL-SA-01079 (CVE-2024-23918)
      Potential security vulnerabilities in some Intel Xeon processors
      using Intel SGX may allow escalation of privilege.  Intel disclosed
      that some processor models were already fixed by a previous
      microcode update.
    - Updated mitigations for INTEL-SA-01097 (CVE-2024-24968)
      Improper finite state machines (FSMs) in hardware logic in some
      Intel Processors may allow an privileged user to potentially enable a
      denial of service via local access.
    - Mitigations for INTEL-SA-01103 (CVE-2024-23984)
      A potential security vulnerability in the Running Average Power Limit
      (RAPL) interface for some Intel Processors may allow information
      disclosure.  Added mitigations for more processor models.
  * Updated Microcodes:
    sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800
    sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256
    sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037
    sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037
    sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037
    sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232
    sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435
    sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240
    sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160
    sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123
    sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123
    sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128
    sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283
  * source: update symlinks to reflect id of the latest release, 20241112
  * Update changelog for 3.20240910.1 and 3.20240813.1 with new information:
    INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models,
    and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for
    some processor models.

 -- Henrique de Moraes Holschuh <[email protected]>  Thu, 14 Nov 2024 15:37:40 -0300

Digamos que executei um comando

foo a b c d e f

Posso então usar $!para acessar o último argumento desse comando, ou seja, se eu digitar

echo !$

ele se transforma em echo f. Da mesma forma, posso usar

echo !:4

para acessar o 4º elemento, d, mas isso significa que tenho que contar da esquerda. Existe uma notação para acessar o enésimo elemento da direita?

Tenho um novo sistema de arquivos em mente, mas a estrutura torna impossível implementar mais de um link físico para cada inode. ("." e ".." são tratados de forma diferente.)

Ele não foi criado para ser um sistema de arquivos raiz, mas pode ser usado como um sistema de arquivos de uso geral em /home, etc.

• Links físicos são comumente usados ​​fora dos diretórios do sistema (Linux)?

• Quais problemas os usuários podem sofrer se não tiverem suporte para links físicos?

Eu esperava que esses dois comandos fornecessem a mesma contagem de quantas linhas no meu arquivo contêm uma letra:

grep -c '[A-Z,a-z]' archive_for_TO.050225
11873
grep '[A-Z,a-z]' archive_for_TO.050225 | wc -l
11859

O arquivo é muito grande para ser postado aqui, mas eu me pergunto se há alguns casos/explicações comuns sobre o porquê de o segundo comando aparentemente encontrar 14 linhas correspondentes a menos que o primeiro. Por exemplo, isso indica que o arquivo de texto tem algumas inconsistências em como as linhas são separadas (retorno de caractere ou avanço de linha ou ambos)?