All perguntas(unix)

Estou usando o Almalinux, caso isso seja relevante aqui.

Usamos LUKS2 no disco local, com LVM no topo - então /dev/sda1 e 2 não são criptografados, mas /dev/sda3 é criptografado e usado para o sistema operacional.

Também usamos clevis/tang para fazer a descriptografia automática (e isso está funcionando bem).

Quando construímos via kickstart, definimos uma senha temporária ao criptografar e construir - e então, quando terminamos a construção inicial, usamos o ansible para definir senhas de boa qualidade, de acordo com nossas práticas de proteção/segurança.

Então isso envolve um script que faz o equivalente a:

cryptsetup luksOpen -S 0 --test-passphrase /dev/sda3 && cryptsetup luksChangeKey -S0 --force-password --batch-mode 

(E, claro, a senha de compilação 'padrão' é testada e substituída por uma do nosso sistema de gerenciamento de chaves).

Isso começou a falhar recentemente e estou um pouco perplexo sobre o que pode estar dando errado.

Definitivamente funciona em nossa 'compilação' inicial, que usa uma imagem de compilação um pouco desatualizada, mas depois mudamos dnf updatepara a revisão atual e agora não conseguimos mais usar luksChangeKey ou luksAddkey.

# Adding new keyslot 2 by passphrase, volume key provided by passphrase (-1).
# Selected keyslot 2.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Keyslot 1 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /dev/sda3.
# Opening lock resource file /run/cryptsetup/L_8:3
# Verifying lock handle for /dev/sda3.
# Device /dev/sda3 READ lock taken.
# Reusing open ro fd on device /dev/sda3
# Device /dev/sda3 READ lock released.
# Verifying key from keyslot 0, digest 0.
# Keyslot 2 assigned to digest 0.
# Trying to allocate LUKS2 keyslot 2.
# Found area 548864 -> 806912
# Running argon2id() benchmark.
# PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 72 ms)
# PBKDF benchmark: memory cost = 227555, iterations = 4, threads = 4 (took 264 ms)
# PBKDF benchmark: memory cost = 1048576, iterations = 6, threads = 4 (took 1982 ms)
# Benchmark returns argon2id() 6 iterations, 1048576 memory, 4 threads (for 512-bits key).
# JSON does not fit in the designated area.
# Not enough space in header json area for new keyslot.
# Rolling back in-memory LUKS2 json metadata.
# Releasing crypt device /dev/sda3 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/sda3.
Command failed with code -1 (wrong or missing parameters).

Gostaria de saber se alguém pode me ajudar a entender o que está errado aqui e o que preciso fazer para remediar.

Existe uma opção de 'tamanho do cabeçalho inicial' que eu possa especificar em nossas compilações? Ou um parâmetro para cryptsetup? Ou estou "apenas" encontrando um bug? (Mas não estou convencido de que algo tão amplamente usado como cryptsetupvai ter um bug do tipo 'ninguém pode mudar suas senhas')

É assim que o cabeçalho LUKs aparece em um host de exemplo.

LUKS header information
Version:           2
Epoch:             5
Metadata area:     16384 [bytes]
Keyslots area:     16744448 [bytes]
UUID:              
Label:             (no label)
Subsystem:         (no subsystem)
Flags:           (no flags)

Data segments:
  0: crypt
    offset: 16777216 [bytes]
    length: (whole device)
    cipher: aes-xts-plain64
    sector: 512 [bytes]

Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2id
    Time cost:  9
    Memory:     1048576
    Threads:    4
    Salt:       
    AF stripes: 4000
    AF hash:    sha256
    Area offset:32768 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
  1: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      pbkdf2
    Hash:       sha256
    Iterations: 1000
    Salt:       
    AF stripes: 4000
    AF hash:    sha256
    Area offset:290816 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
Tokens:
  0: clevis
    Keyslot:    1
Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 105025
    Salt:       
    Digest:    

Estou esquecendo de algo profundo? Como dito, tenho certeza de que isso funciona se eu não "atualizar" a caixa para um kernel mais novo, então minha solução alternativa atual é construí-la, recodificar manualmente e então continuar a atualizá-la, mas isso parece... abaixo do ideal.

cryptsetup versões 2.6.0 e 2.7.2

head -c 1M /dev/sda3 | strings -n 128 

reformatado:

{
  "keyslots": {
    "0": {
      "type": "luks2",
      "key_size": 64,
      "af": {
        "type": "luks1",
        "stripes": 4000,
        "hash": "sha256"
      },
      "area": {
        "type": "raw",
        "offset": "32768",
        "size": "258048",
        "encryption": "aes-xts-plain64",
        "key_size": 64
      },
      "kdf": {
        "type": "argon2id",
        "time": 7,
        "memory": 1048576,
        "cpus": 4,
        "salt": "(removed)"
      }
    },
    "1": {
      "type": "luks2",
      "key_size": 64,
      "af": {
        "type": "luks1",
        "stripes": 4000,
        "hash": "sha256"
      },
      "area": {
        "type": "raw",
        "offset": "290816",
        "size": "258048",
        "encryption": "aes-xts-plain64",
        "key_size": 64
      },
      "kdf": {
        "type": "pbkdf2",
        "hash": "sha256",
        "iterations": 1000,
        "salt": "(removed)"
      }
    }
  },
  "tokens": {
    "0": {
      "type": "clevis",
      "keyslots": [
        "1"
      ],
      "jwe": {
        "ciphertext": "(removed)",
        "encrypted_key": "",
        "iv": "(removed)",
        "protected": "",
        "tag": "(removed)"
      }
    }
  },
  "segments": {
    "0": {
      "type": "crypt",
      "offset": "16777216",
      "size": "dynamic",
      "iv_tweak": "0",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    }
  },
  "digests": {
    "0": {
      "type": "pbkdf2",
      "keyslots": [
        "0",
        "1"
      ],
      "segments": [
        "0"
      ],
      "hash": "sha256",
      "iterations": 88086,
      "salt": "(removed)",
      "digest": "(removed)"
    }
  },
  "config": {
    "json_size": "12288",
    "keyslots_size": "16744448"
  }
}

Edição 2: A história se complica: luksHeaderBackup e depois uma restauração falha.

Mas matar o 'slot 0' e adicionar uma chave ainda funciona. (Supondo que o 'slot 1' você pode extrair, mas nos meus casos clevis-luks-passfunciona bem o suficiente)

Como abrir o terminal fish com um atalho de teclado como ctl-alt-tno ambiente de trabalho Gnome rodando no Debian ?

Passos que tomei:

1. Instalei o fish shell e executei-o no gnome-terminal .
2. Execute com sucesso a interface gráfica do terminal do Fish Shell a partir da lista de aplicativos em settings>applications.
3. Verifiquei o arquivo fish.desktop/usr/share/applications para encontrar o comando exec

[Desktop Entry]
Version=1.0
Type=Application
Terminal=true
# This file is for use in appimages, which rewrite the path.
# Other uses would have to replace these with the correct path.
Exec=fish
Name=fish
Comment=The user-friendly command line shell
Icon=fish
# "Shell" would be the proper category, but it's reserved so we can't use it.
Categories=ConsoleOnly;System;

4. Criei um atalho de teclado emSettings>Keyboard>Keyboard Shortcuts>View And Customize Shortcuts>Custom Shortcuts>Set Custom Shortcut

Mas pressionar ctl-alt-tnão abre o terminal de peixes.

O que podemos fazer com este arquivo: /sys/block/md0/md/fail_last_dev?

Não consigo encontrar nenhuma informação sobre isso na mdpágina do manual. Na seção SYSFS INTERFACEdiz: This interface is documented more fully in the file Documentation/md.txt. Mas também não consigo encontrar fail_last_devlá. Está apenas no código.

Tenho um script baixado da Internet, cujo começo se parece com isso:

echo "alias myip='curl -s https://api.ipify.org/'" >> ~/.bash_profile
echo "alias myiplookup='ip2cc \$(curl -s https://api.ipify.org/)'" >> ~/.bash_profile

Eu o uso em uma máquina macOS e, como esperado, ele cria um .bash_profilearquivo no meu $HOMEdiretório, com as linhas correspondentes:

alias myip='curl -s https://api.ipify.org/'
alias myiplookup='ip2cc $(curl -s https://api.ipify.org/)'

Há dois bashes nessa máquina:

• bash 3.2, fornecido com o próprio macOS
• bash 5.2, instalado usando Homebrew

Mas independentemente de qual desses ataques eu tente, quando eu digito myipou myiplookup, eu recebo a command not foundmensagem.

Aqui está o que eu tentei, passo a passo:

1. Inicie o aplicativo Terminal. Ele será aberto com uma sessão zsh.
2. Digite bash(para bash 5.2) ou /bin/bash(para bash 3.2)
3. Digite myip. bash mostra a command not foundmensagem.

O que estou fazendo errado?

Pressionei Ctrl+Alt+F3porque esta é uma tecla de atalho para um dos programas que estou usando e, quando a pressionei, todas as quatro telas ficaram pretas e em branco.

Não sei como voltar para meus desktops normais. Pressionar o botão de energia no Steam Deck não parece fazer nada. Ele fica preto e branco.

Pressionar Ctrl+Alt+F3novamente não me retorna à minha área de trabalho normal.

Também conectei meus monitores externos, teclado, mouse e todas as minhas coisas via Type C, mas ainda tenho o mesmo problema. A tela está preta e em branco. Não há literalmente nada na tela.

Encontrei outras pessoas online reclamando sobre isso também e elas estão dizendo para pressionar, Ctrl+Alt+F7o que eu fiz, mas nada acontece.

Como faço para sair dessa tela preta em branco (Ctrl+Alt+F3) no SteamOS e retornar ao meu ambiente de trabalho normal do KDE?

Eu instalei o Mac Ports e sua versão bash no 10.15 Catalina, mas quando abro o terminal, ainda sou recebido com a versão antiga do bash da Apple e estou perdendo todos os ports do Mac que instalei. Eles estão lá, mas apenas na nova versão do bash.

(1) Nas Preferências do Sistema da Apple, na seção Avançado de Usuários e Grupos, inseri o caminho bash das Portas do Mac /opt/local/bin/bash, mas não teve efeito algum.

(2) Alterar as preferências do Terminal para /opt/local/bin/bash(veja a sugestão abaixo de Tim Kennedy) também não teve efeito.

Esta é a situação após a aplicação destas duas alterações:

$ echo $BASH_VERSION
5.2.32(1)-release

$ bash -version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc.

$ which bash
/bin/bash

Há também um post relacionado « again… bash version mac didn't change », mas ele cobre a versão Homebrew e não Mac Ports e também não resolve esse problema. Ele contém, no entanto, algumas outras informações úteis.

(3) A aplicação da solução do artigo acima mencionado também não teve efeito:

$ chsh -s /opt/local/bin/bash
Changing shell for admin.
Password for admin: 
chsh: /opt/local/bin/bash: non-standard shell

$ which bash
/bin/bash

(4) A sugestão de edição do /etc/shellsarquivo também não surtiu efeito.

Finalmente, a sugestão de Marc Wilson sobre o $PATH (veja abaixo) me levou à solução. Meu /etc/pathsinicialmente parecia assim:

/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

Quando coloquei o diretório Mac Ports /opt/local/binantes do local bash da Apple /bin, usando sudo vi /etc/paths, finalmente consegui. Agora, quando abro o Terminal, recebo:

$ echo $BASH_VERSION
5.2.32(1)-release

$ bash -version
GNU bash, version 5.2.32(1)-release (x86_64-apple-darwin19.6.0)

$ which bash
/opt/local/bin/bash

$ figlet it works
 _ _                        _        
(_) |_  __      _____  _ __| | _____ 
| | __| \ \ /\ / / _ \| '__| |/ / __|
| | |_   \ V  V / (_) | |  |   <\__ \
|_|\__|   \_/\_/ \___/|_|  |_|\_\___/
  

Obrigado a todos!

Em algum momento no passado, sempre que eu tentava uma sshconexão com um servidor sem especificar a senha, ssheu tentava todas as chaves, ssh-agenta ponto de, se houvesse muitas chaves, meu endereço IP ser bloqueado por muitas falhas de conexão.

O comportamento parece ter mudado, pois mesmo que haja uma única chave válida na ssh-agentlista, tenho que incluí-la no comando, por exemplo ssh -i ~/.ssh/alternate-key user@host.

Isso se deve a alguma alteração na configuração ou a uma alteração no comportamento do sshpróprio executável?

Estamos tendo um problema ao tentar definir uma variável local em uma função com nameref.

O código do script é o seguinte:

#!/usr/bin/bash
msg=hello
myparam=''

superfunc () {
productfile=$1
local -n refmyparam=$2
}

superfunc $msg $myparam
echo $myparam

Ao executá-lo, obtemos o erro:

 line 7: local: `': not a valid identifier

Usamos GNU bash, versão 5.2.21

Considere este programa simples ( abort.py) que escreve algum texto em stdoute stderre então trava ( abort()).

import os
import sys

print("end stdout")
print("end stderr", file=sys.stderr)
os.abort()

Quando executo no terminal, ambas as saídas para stdoute stderrsão produzidas corretamente.

$ python3 abort.py 
end stdout
end stderr
Aborted (core dumped)

Entretanto, se eu redirecionasse stdoute/ou stderrusasse outro programa (talvez para fins de registro), ele não funcionaria mais.

$ python3 abort.py | cat
end stderr

$ python3 abort.py |& cat

$ python3 abort.py | tee -a logs
end stderr

$ python3 abort.py |& tee -a logs

# file `logs` is unchanged

Na verdade, se o programa ( abort.py) produz muitos textos para stdoute stderr, apenas a última seção deles é perdida da perspectiva do programa receptor na outra ponta do pipe. Eu também tentei executar o programa em um script bash e executar esse script, mas o resultado é o mesmo.

Por que isso está acontecendo e como devo corrigir?

Fundo

O exemplo acima é obviamente artificial. O cenário do mundo real é que eu estava depurando um programa grande que ocasionalmente travava (segfault ou abortava) após rodar por dias. Ele produz muitos logs para ambos stdoute stderr, mas a informação mais importante sobre sua falha (como rastreamento de pilha) é impressa no final, logo antes da falha acontecer. Eu tenho um pipeline de log configurado em um script bash (envolve alguns teee gzippor exemplo), mas descobri que a última seção do log salvo está sempre faltando, o que é frustrante.

Qual é a maneira correta de adicionar algo à $PATHvariável no macOS?

• Por exemplo, posso fazer isso em .zshrc:

  path+=$HOME/foo/bar
  

• ...mas parece que nesse caso o caminho modificado estará disponível apenas para uso interativo e, portanto, a solução mais robusta é colocá-lo .zshenv.

• ...Mas por outro lado algumas pessoas dizem (veja os comentários desta resposta) que modificar o caminho .zshenvnão é uma boa ideia. (E, se entendi corretamente, eles assumem que o caminho deve ser alterado .zshrcou talvez usar alguma outra maneira...)

• Eu também li este e este artigo.

No entanto, ainda não entendi qual arquivo usar para isso, e como exatamente. Alguém poderia explicar como se eu tivesse cinco anos?