bisko.be - Dev

Rodando o Ollama com GPUs antigas no CachyOS

Sat, 28 Feb 2026 00:00:00 GMT

TL;DR;

O ollama-cuda no CachyOS vem (neste momento) com suporte apenas para compute >= 7.5.

Se você tem GPUs mais antigas, com compute anterior, você TEM QUE fazer uma de 2 coisas:

Compilar o ollama-cuda a partir do código-fonte, com suporte aos targets de compute mais antigos
Instalar o ollama-vulkan

Eu escolhi o ollama-vulkan e está funcionando perfeitamente!

Hora da história

Hoje tive a inspiração de finalmente desligar minha VM com Windows 11 e migrá-la para o Linux.

Os requisitos eram conseguir rodar:

Ollama - para a mágica dos modelos locais
Docker - para desenvolvimento remoto
Steam - para jogar
Jellyfin - para o arquivo de vídeos caseiros

Agora vou focar apenas no Ollama, porque foi uma experiência interessante e me fez pensar por que as coisas não são mais óbvias.

A máquina tem 2 GPUs:

GTX 1070 - 8GB
GTX 970 - 4GB

Eu queria rodar o Ollama nelas, para brincar com modelos locais e ver como poderia integrá-los em alguns projetos. Por exemplo: anonimizar dados localmente, fazer uma implementação não destrutiva do OpenClaw que sirva para os meus casos de uso, OCR local para documentos que escaneio com o celular, automatizar algumas coisas do gerenciamento cotidiano de uma casa.

Então, naturalmente, instalei o ollama e o ollama-cuda, já que tenho 2 GPUs Nvidia aqui, esperando que funcionasse sem problemas, já que estava funcionando no Windows poucos minutos antes.

Iniciei o Ollama, carreguei o qwen3:8b para um experimento rápido e… estava rodando na CPU 🤔

As GPUs eram perfeitamente capazes de manter o modelo na VRAM, mas por algum motivo o Ollama escolhia rodá-lo na CPU.

Depois de tentar descobrir o motivo pelos logs, pedi ajuda ao Claude, que chegou a uma conclusão bem desanimadora:

The logs tell the story clearly. Both your GPUs are detected but then filtered out because they fail CUDA initialization:

  "filtering device which didn't fully initialize" id=GPU-eb132a13-b9f4-40e3-d85d-60f211dfd21e ... library=CUDA
  "filtering device which didn't fully initialize" id=GPU-550263c8-37e2-2a25-c0b6-10cc7511ed20 ... library=CUDA

  The reason is the CUDA library bundled with Ollama 0.17.4 was compiled for these architectures only:

  CUDA.0.ARCHS=750,800,860,870,880,890,900,1000,1030,1100,1200,1210

  The minimum supported compute capability is 7.5 (Turing / RTX 20xx series). Your GPUs are older than that:

  ┌──────────┬────────────────────┬──────────────┐
  │   GPU    │ Compute Capability │ Architecture │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 1070 │ 6.1                │ Pascal       │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 970  │ 5.2                │ Maxwell      │
  └──────────┴────────────────────┴──────────────┘

  Neither is in the supported list, so CUDA initialization fails for both, and Ollama falls back to CPU-only inference.

  Your options:

  1. Downgrade Ollama to an older version that still included Pascal/Maxwell support (pre-0.6.x era had broader arch coverage, but check release notes for specifics).
  2. Build Ollama from source with CUDA_ARCHITECTURES="52;61;75;80;86" to include your GPU architectures.
  3. Upgrade GPUs to at least an RTX 2060 or newer (compute 7.5+).

Isso foi meio decepcionante para mim, porque quero usar as GPUs o máximo possível antes de partir para uma nova.

Eu não queria realmente recompilar o Ollama a partir do código-fonte, já que ele deveria funcionar de cara, e fiquei muito confuso sobre por que não funcionava, sendo que na instalação do Windows ele suportava essas arquiteturas.

Essas placas também apareciam como suportadas no site do Ollama!

Para resumir uma longa história de pesquisas no Google:

Acontece que o ollama-cuda vem apenas com os requisitos listados acima… e a sugestão foi instalar o ollama-vulkan.

Depois de fazer isso, tudo passou a funcionar muito bem!

[Linux] Recuperando uma sessão desconectada do `apt dist-upgrade`

Wed, 23 Oct 2024 00:00:00 GMT

Hoje eu estava atualizando minha instalação do Proxmox remotamente pelo console embutido, mas esqueci o que estava fazendo e fechei a aba no meio do processo.

O resultado foi que não consegui me conectar de novo, já que os pacotes continuavam sendo atualizados em segundo plano e a atualização tinha feito uma pergunta sobre substituir um arquivo e estava esperando pela minha resposta.

Ou seja, eu conseguia entrar via SSH, mas não podia fazer nada, porque o processo ainda esperava uma resposta num console ao qual eu não conseguia me conectar, já que a interface não abria.

Depois de uma olhada rápida por aí, tropecei em uma thread do Serverfault que mencionava o uso do reptyr para assumir o controle da sessão de terminal via SSH.

Estou registrando aqui exatamente o que foi feito para recuperar a sessão e terminar a atualização:

A partir deste comentário:

git clone https://github.com/nelhage/reptyr
cd reptyr
make install

Isso instalou o reptyr na máquina.

Depois procurei todas as sessões abertas com ps ax | grep pts para encontrar o processo que eu queria.

Então encontrei o processo mais acima na árvore de chamadas que tinha um pts associado a ele e me anexei a ele pelo seu PID:

reptyr -T 1390511

Aí eu consegui terminar a atualização! 🎉

[Linux] Syncthing – sistema de arquivos somente leitura ao rodar como serviço

Wed, 06 Apr 2022 00:00:00 GMT

Já faz alguns meses que uso o Syncthing para sincronizar minha cópia de trabalho com um servidor de desenvolvimento local.

No começo, eu o usava logando e rodando manualmente pela CLI. Estava funcionando bem, então nem pensei duas vezes quando passei a rodá-lo como serviço. Ele iniciou, sincronizou alguns dados, tudo certo.

Até que não estava, claro! 🙂

Acontece que eu não percebi um monte de erros aparecendo nos logs dizendo que o sistema de arquivos no servidor de desenvolvimento era somente leitura, e isso estava fazendo o Syncthing não sincronizar nada.

Achei que fosse um bug e que ele só estava mostrando Out of Sync para as pastas, mas que na verdade estava sincronizando. Pois é, eu estava errado.

Depois de algumas horas depurando e sem encontrar nenhuma pista nos fóruns em algumas buscas no Google, cheguei a um artigo sobre o Syncthing na ArchWiki, que mencionava exatamente o meu caso:

read-only file system error on /etc although run as root

Era exatamente o meu caso de uso, exceto que a pasta problemática não era /etc, e sim /usr/local/src.

Bem, depois de ler o que dizia, descobri que, se você roda o Syncthing (ou qualquer coisa) via systemd e tem ProtectSystem configurado como full para o serviço, alguns diretórios ficam somente leitura por padrão. /usr é um desses caminhos.

Para resolver, você precisa adicionar uma nova linha na configuração do serviço e reiniciar o serviço (e rodar daemon-reload):

ReadWritePaths=/usr/local/src

Depois disso, o Syncthing deve funcionar normalmente.

[Linux] Executando vários comandos em vários servidores em paralelo

Mon, 19 Apr 2021 00:00:00 GMT

Tenho um cluster de Raspberry Pis em casa rodando Docker Swarm. Para manter tudo em ordem, todos usam a mesma configuração – usuários, versões do Docker, etc.

Às vezes, algumas atualizações exigem rodar a mesma coisa em todos os nós do cluster – por exemplo – criar uma nova rede macvlan do Docker.

Para fazer isso, é preciso rodar os mesmos comandos em todos os nós manualmente, entrando via ssh em cada um deles, executando os comandos e passando para o próximo.

Como estou tentando reduzir meu trabalho a longo prazo e deixar tudo o mais organizado possível, comecei a procurar maneiras de rodar comandos em todos os nós ao mesmo tempo.

Iteração 1: Script Python customizado

A primeira iteração foi criar um script Python customizado. Por um lado, era para aprender um pouco melhor Python; por outro, eu não tinha encontrado uma forma boa de rodar os comandos de um jeito mais nativo.

Como era de se esperar (ei, ainda tenho pouca experiência com a linguagem 🙂 ), ele virou uma bagunça inchada muito rápido e quebrava com facilidade.

Eu precisava achar outro jeito de fazer isso, sem ter que reaprender o que eu fiz 3 semanas atrás e o que quebrou da última vez.

Iteração 2: `pssh`

Pesquisando por aí, esbarrei no [pssh](https://linux.die.net/man/1/pssh), que consegue rodar coisas em paralelo via SSH.

Considerando tudo, foi bem fácil colocá-lo para funcionar.

O problema era que, para rodar algumas das coisas, eu precisava executá-las via sudo. Ficar passando senhas por aí não era o ideal, então tive que pesquisar de novo para descobrir como enviar a senha do sudo quando o servidor remoto a pedisse.

Acontece que é bem fácil se você topar com o comentário certo no StackOverflow.

A versão resumida (TL;DR;) é:

stty -echo; printf "Password: "; read PASS; stty echo; echo "${PASS}" | \
pssh -h <HOSTFILE> -o /tmp/output -t 0 -I "`cat ./commands.sh`"

O -I "`cat ./commands.sh`" precisa ser feito exatamente assim (entre aspas e crases desse jeito); caso contrário, ele não executa os comandos direito. A senha vai ser enviada como um comando separado, e não captada como entrada do sudo.

A outra pegadinha é que, por causa de como isso está montado, é preciso rodar o sudo com o parâmetro -S, para que ele leia a senha corretamente.

Descobrindo a senha numérica de um arquivo zip usando apenas utilitários de linha de comando

Mon, 14 Sep 2020 00:00:00 GMT

Hoje recebi minha fatura mensal do meu provedor de internet e algo me pareceu estranho.

A fatura, contida no e-mail, estava em um arquivo ZIP com senha.

Sem falar o quão estranho foi receber um anexo em formato ZIP nos dias de hoje (spam, malware, phishing, etc.), a senha que escolheram me pareceu muito fraca.

É a data de nascimento do titular da conta no formato YYMMDD.

Fiz um cálculo bem grosseiro de cabeça enquanto estava na academia e deu um número bem pequeno de combinações possíveis. Depois de usar uma ferramenta online para calcular quantos dias se passaram (já que nem todas as combinações resultariam em uma data válida) desde 1900-01-01, descobri que as combinações são apenas 44.075 (até 2020-09-14).

Sabendo que ferramentas otimizadas que usam o poder da GPU para quebrar hashes conseguem fazer tentativas na casa dos milhões por segundo, eu quis ver quão rápido a senha poderia ser descoberta sem usá-las, usando apenas a CLI do Linux/macOS (já que só tinha acesso a uma VPS enquanto estava na academia).

Cheguei ao seguinte código, que funciona no macOS:

echo {1..44000} | xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" | xargs -P 16 -I{} sh -c 'unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255'

O comando é bem simples em seu funcionamento, mesmo parecendo complicado.

echo {1..44000} gera os números de 1 a 44.000 e os repassa para a próxima etapa.

xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" – pega a entrada da primeira etapa e gera datas no formato YYMMDD, aproveitando a funcionalidade do date de “aumentar” uma data com uma quantidade específica. Nesse caso, seria subtrair X dias da data atual, onde X é o número gerado na primeira etapa. Dessa forma, conseguimos gerar datas de hoje até os anos 1900.

A terceira etapa é a mais interessante, então vou dividi-la em duas partes:

xargs -P 16 -I{} sh -c '...'

Isso pega as datas geradas na etapa 2 e executa um comando em cada uma dessas datas. -P 16 aqui significa que isso vai rodar em 16 processos paralelos, para tornar a varredura dos dados mais rápida. O mesmo truque é aplicado na etapa 2 para acelerar a geração das datas.

A segunda parte é onde as tentativas acontecem:

unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255

O que isso faz é primeiro tentar descompactar o arquivo zip usando a senha gerada na etapa 2. Se for bem-sucedido, ele imprime (echo) a senha descoberta e então exit 255 força o xargs a parar de rodar. Não queremos continuar tentando senhas se a correta já foi encontrada.

No fim das contas, foi uma decisão bem ruim escolher isso como senha do arquivo, porque rodar o comando acima leva apenas cerca de 10 segundos para descobrir a senha correta da minha fatura. Não muito mais para qualquer outra pessoa.

Lidando com código espaguete em PHP: usando funções anônimas para extrair pedaços de código de template

Sat, 08 Aug 2020 00:00:00 GMT

Recentemente tenho ajudado um amigo a entender um código e a descobrir como modificá-lo para funcionar bem com chamadas assíncronas ao backend. Um bônus seria conseguir escrevê-lo de um jeito mais modular e reutilizável.

O código é um plugin de WordPress escrito com uma abordagem bem legada: lógica de negócio e de frontend misturadas num lugar só. Manipulação de dados feita no meio do código de template, e coisas do tipo.

Basicamente, o que você via em sites PHP no começo dos anos 2000, antes de todas as incríveis adições de OOP à linguagem e de um monte de frameworks maduros.

O caso em que eu estava trabalhando hoje era o seguinte: você tem uma tabela que mostra um monte de registros. Precisávamos adicionar vários filtros à tabela e fazê-la funcionar via AJAX, para atualizar a interface rapidamente, sem recarregar a página inteira do Admin do WordPress.

Filtrar os dados foi fácil: um array_filter inline rapidinho para filtrar os dados antes de passá-los ao código do template (para manter o mesmo estilo de código, isso também ficou no arquivo de template 😇).

O problema apareceu quando começamos a trabalhar para tornar a tabela renderizável via AJAX.

Ela está no meio de um monte de outros códigos de template e de negócio. Se quiséssemos limitar a saída via AJAX só à tabela, só tínhamos algumas maneiras de fazer isso.

A primeira seria envolver o HTML antes e depois da tabela em ifs ENORMES para garantir que ele não fosse renderizado.

Outra seria extrair o template para um arquivo separado e incluí-lo na ação de AJAX que definiríamos no código do plugin.

Funções anônimas para o resgate!

Pensando em como lidar com isso da maneira mais simples possível, tentei definir uma função PHP normal que conteria o código da tabela, mas havia um problema.

O código roda dentro de um método de uma classe. Há referências a $this no template da tabela. Se não queremos mudar muito o código, teríamos que passar $this como argumento da função. Pois é, isso não funciona, já que você não pode passar $this como parâmetro 🤷‍♂️.

Fiquei meio decepcionado por termos que reescrever um monte de coisas no template, e havia bastantes referências com as quais precisávamos tomar cuidado para que tudo continuasse funcionando.

Então lembrei que o site não roda em PHP 5.2, mas em PHP 7, e que funções anônimas seriam suportadas.

E elas têm um recurso bem prático, em que você define quais variáveis do escopo de quem chama serão passadas para a função quando ela for chamada. Por exemplo:

$table_function = function() use ( $pages, $current_page, $items ) {
    // ... Table render code
}

Isso permite referenciar diretamente $pages ou $items no corpo da função.

O recurso incrível aqui é que você também pode passar $this como uma variável no escopo da função!

Agora conseguimos extrair totalmente o código de renderização da tabela para uma função separada, que podemos chamar isoladamente durante a chamada AJAX!

Claro que é preciso ter muito cuidado com as variáveis usadas dentro do corpo da função, pois elas precisam estar definidas, então atenção a onde a função de AJAX pode ser chamada.

Para nós, isso significa que vamos adicionar uma pequena ação na classe principal que ainda vai dar require no arquivo, mas teremos mais controle para desativar todas as outras saídas que aconteceriam.

Arduino/ESP32: Desabilitando o watchdog de tarefas

Wed, 29 Apr 2020 00:00:00 GMT

Recentemente andei brincando com a funcionalidade multicore do ESP32 e com a fixação de tarefas em núcleos específicos.

Eu estava usando o AutoConnect para dar suporte à conexão WiFi sem guardar credenciais no código e para oferecer atualizações OTA pela interface web.

Era para um projeto que ia controlar alguns coolers de CPU de 4 pinos com PWM que ficam no meu armário de servidores, para resfriar o ar lá dentro. Para isso, eu queria dividir a lógica em duas tarefas.

Uma tarefa para cuidar das APIs, leitura de sensores, atualizações, WiFi etc., e outra para cuidar da interrupção e do controle PWM dos ventiladores.

Tudo certo, as tarefas foram criadas, mas ao rodar o código, se eu colocava o ESP32 no modo em que você precisa se conectar a ele para dizer a qual rede WiFi ele deve se conectar, ele começava a ter um comportamento estranho: resetava o controlador a cada poucos segundos e eu não conseguia fazer a conexão funcionar.

Foi um momento chato, ter que desmontar o controlador do lugar dele e ligar no USB para gravar um firmware novo.

Depois de fazer isso, percebi que o erro vinha do watchdog:

Task watchdog got triggered. The following tasks did not feed the watchdog in time:

IDLE (CPU 1)
Tasks currently running:
CPU 0: ManageTask
CPU 1: ControllerTask

Pesquisando, parece que isso é disparado pelo Task Watchdog do ESP32, que garante que as tarefas tenham a sua vez de executar na CPU.

E também parecia que o AutoConnect não era muito flexível quando rodava dentro de uma tarefa, em comparação a rodar fora de uma, direto com todo o resto do código e das funcionalidades.

Fuçando um pouco e tentando coisas diferentes, parece que a forma mais fácil de sair dessa situação é simplesmente desabilitar o watchdog e torcer para que as coisas sejam executadas a tempo 🙂 A tarefa não é crítica, então tudo bem esperar mais tempo para ela terminar o que está fazendo.

Para desabilitar o watchdog, você precisa fazer duas coisas:

Primeiro, incluir o header esp_task_wdt.h. Para isso, adicione #include <esp_task_wdt.h> na sua seção de includes.

Segundo, fazer o watchdog não resetar o controlador e esperar mais tempo. Para isso, você precisa adicionar esp_task_wdt_init(30, false); no início do código da sua Task.

void manage_core_task(void *pv_parameters) {
    esp_task_wdt_init(30, false);
    // .... rest of the code ...
}

Isso vai definir o timeout do watchdog para 30 SEGUNDOS e desabilitar o reset do controlador caso ele seja disparado.

Se você quiser que o controlador ainda seja resetado depois que o watchdog disparar, mude o segundo parâmetro da chamada da função de false para true.

Configurando uma YubiKey para assinar commits do Git

Wed, 08 Jan 2020 00:00:00 GMT

Eu venho usando uma YubiKey como chave de autenticação em 2 fatores e para assinar meus commits do Git. Até alguns dias atrás eu usava uma YubiKey 4. Como meu computador atual não tem nenhuma porta USB-A, faz mais de um ano que eu ando com adaptadores de USB-A para USB-C na mochila, e usar a chave tem sido um incômodo. Por isso decidi que era hora de migrar para a minha YubiKey 5C “nova” e ficar livre de ter que carregar esses adaptadores.

Na verdade, eu já tinha a chave há um tempo: comprei junto com uma YubiKey 4 de reposição, que precisei por causa do problema do TPM da Infineon identificado por eles. Mas só agora decidi que era hora de migrar para a chave nova.

O outro motivo para fazer isso agora é que minhas chaves GPG antigas expiraram e eu precisei reemiti-las, então posso aproveitar para usar a chave para assinar meus commits do Git.

A loucura do GPG

Se você já lidou com chaves GPG no passado (ou lida atualmente), sabe que pode ser bem difícil colocá-las para funcionar de forma correta e segura se você nunca fez isso antes. Manter as chaves mestras offline, trocar chaves públicas de um lado para o outro, reemitir chaves depois que expiram, possivelmente assiná-las com chaves anteriores para verificá-las, revogar chaves… Não é fácil seguir as boas práticas nem na teoria. Na prática, as coisas ficam extremamente complicadas.

A maioria dos tutoriais online manda usar a linha de comando para gerar as chaves, navegando por menus com um padrão de design nada comum, e é uma dor de cabeça geral para fazer tudo funcionar. A maioria deles diz para usar uma máquina offline, como um Raspberry PI, e/ou gerar as chaves mestras e subchaves offline e manter a chave mestra fora do seu computador.

🤯

Eu lido com isso todo começo de janeiro há quase 4 anos. Eu morro de medo do momento em que aparece o erro a seguir, avisando que minhas chaves de assinatura expiraram.

error: gpg failed to sign the data
fatal: failed to write commit object

Este ano decidi que era hora de tentar deixar esse processo muito mais fácil, usando a geração de certificados embutida na própria chave e evitando todo o trabalho de gerar chaves GPG e afins.

Geração de chaves direto na YubiKey

Ainda vamos ter que usar a interface de linha de comando, mas é um pouco mais óbvio, já que tem menos etapas.

Primeiro precisamos configurar nosso cartão/dispositivo.

Configuração do cartão/dispositivo

Execute gpg --card-status no terminal e você deve ver algo assim:

Reader ………..: Yubico Yubikey 4 OTP U2F CCID
Application ID …: <Serial number>
Version ……….: 2.1
Manufacturer …..: Yubico
Serial number ….: <Device serial number>
Name of cardholder: unspecified
Language prefs …: en
Sex …………..: unspecified
URL of public key : \[not set\]
Login data …….: <e-mail or nothing>
Signature PIN ….: not forced
Key attributes …: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 9

Se você viu algo parecido e nenhum erro apareceu, pode continuar.

Execute gpg --card-edit

Você vai cair em uma interface de linha de comando, mostrando as mesmas informações do início e, embaixo, um prompt de comando gpg/card>.

Digite admin e aperte return/enter.

Agora você pode digitar help para descobrir como alterar as informações do dono e os PINs do cartão.

Uma coisa que você PRECISA fazer é trocar os PINs padrão do cartão. São dois. O primeiro é o PIN que você usa para acessar as chaves no cartão. O segundo é o PIN de “Admin” ou PUK (Personal Unblocking Code, o código pessoal de desbloqueio).

Para isso, digite passwd e você verá um menu:

gpg/card> passwd  
gpg: OpenPGP card no. <Serial number> detected

1 - change PIN  
2 - unblock PIN  
3 - change Admin PIN  
4 - set the Reset Code  
Q - quit

Digite 1 e siga as instruções para atualizar o seu PIN. O PIN padrão é 123456.

Depois de terminar, escolha 3 para trocar o PIN de Admin. O padrão é 12345678.

Com os dois PINs trocados, volte ao menu principal para terminar de atualizar as informações da chave.

Os comandos que você pode usar são:

name – para alterar o nome do titular do cartão
login – para alterar o endereço de e-mail ou o login do titular do cartão

Depois disso, podemos passar para a geração das chaves propriamente dita.

Geração das chaves

Agora é hora de gerar as chaves de verdade.

Para isso, digite generate.

Vão te perguntar Make off-card backup of encryption key? (Y/n), mas, como diz a documentação da YubiKey, isso é só um backup de fachada e não cria um backup completo das chaves secretas, então tanto faz responder Yes ou No. Eu respondo No(n).

Se já houver chaves armazenadas no cartão, vão perguntar se você quer substituí-las:

gpg: Note: keys are already stored on the card!

Replace existing keys? (y/N)

Verifique se você não vai substituir algo importante do qual não tem backup e continue com Y. Se houver algo importante, é melhor cancelar todo o processo com Ctrl+C.

Vão pedir o PIN do cartão que você definiu antes.

Depois você terá que escolher por quanto tempo as chaves serão válidas:

Please specify how long the key should be valid.
        0 = key does not expire
      <n> = key expires in n days
     <n>w = key expires in n weeks
     <n>m = key expires in n months
     <n>y = key expires in n years
 Key is valid for? (0)

Se você quer que as chaves sejam válidas por apenas 1 ano, digite 1y.

Vão pedir para você confirmar a data de expiração. Confira se está tudo certo e confirme.

Depois vão pedir as informações do dono da chave:

Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: <Your name>
Email address: <Your e-mail>
Comment: <Comment is optional>
 You selected this USER-ID:
     "<Your name> <comment> <your e-mail>
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Type `O` to confirm if everything seems correct.

Depois vão pedir o seu PIN de Admin ou PUK. Ele é necessário porque será feita uma operação de escrita no cartão.

Então, se tudo estiver certo, a YubiKey vai começar a piscar e continuar assim por um tempo (para mim leva uns cinco minutos).

Quando terminar, você verá a seguinte mensagem:

gpg: key <Short ID> marked as ultimately trusted
gpg: revocation certificate stored as '/Users/bisko/.gnupg/openpgp-revocs.d/<LONG ID>.rev' public and secret key created and signed.

Anote o <Short ID>, pois vamos usá-lo mais adiante.

Neste ponto você pode sair do prompt do GPG com quit ou Ctrl+C.

Agora é hora de salvar a chave pública, para que possamos reutilizar a chave em outro computador.

Para isso, execute o seguinte comando:

gpg --armor --export <Short ID> > <Short ID>.asc

Isso vai exportar a chave pública para um arquivo chamado <Short ID>.asc. Ele será usado no futuro se você quiser usar a YubiKey em outro computador ou se perder a sua configuração do GPG.

Para restaurar a chave pública no seu chaveiro, você precisa fazer:

gpg --import < <Short ID>.asc
gpg: key <Short ID>: public key "Your Name <your@email>" imported
gpg: Total number processed: 1
gpg: imported: 1

Uma observação muito importante. Se for uma instalação nova do GPG ou outro computador, o GPG não vai reconhecer as chaves do cartão sozinho. Você precisa executar gpg --card-status para que ele leia o cartão e identifique as chaves nele.

Configurando o Git para assinar

Para configurar o Git para assinar seus commits, você precisa adicionar o seguinte ao seu ~/.gitconfig.

Na seção [user], você precisa adicionar (ou atualizar) a seguinte linha:

signingkey = 0x<Short ID>

Depois, se você quiser assinar todos os seus commits, adicione o seguinte no final do arquivo:

[gpg]
  program = /usr/local/bin/gpg
[commit]
  gpgsign = true

Isso fará o Git assinar todos os seus commits.

Para configurar o GitHub, você precisa adicionar sua chave pública ao seu perfil. Para isso, vá em GitHub -> Settings -> SSH and GPG keys -> New GPG key.

Você verá uma caixa de texto, onde precisa colar todo o conteúdo do arquivo <Short ID>.asc que geramos acima.

Se quiser copiar o conteúdo do arquivo (no macOS), você pode fazer:

cat <Short ID>.asc | pbcopy

Isso copia o conteúdo do arquivo inteiro para a área de transferência.

Cole na caixa de texto do GitHub e clique no botão Add GPG key.

Depois disso, você pode tentar fazer um commit e um push para o GitHub e deve ver o lindo selo Verified.

Depuração

Às vezes as coisas não funcionam de primeira. Para reunir mais informações, você pode tentar o seguinte:

Assinando com o GPG

Primeiro, tente assinar algo com a chave:

gpg -s <file>

Se isso falhar, tente descobrir por quê. Eu não sou especialista para ajudar nessa parte.

Confira a saída do Git com GIT_TRACE=1 git commit -am “test”

Isso mostra exatamente o que o Git faz enquanto tenta realizar o commit e assiná-lo. Vai te dar uma pista de por que a assinatura pode estar falhando.

Dali você também pode ver que o Git executa o seguinte comando:

/usr/local/bin/gpg --status-fd=2 -bsau <Key ID>

Você pode tentar executá-lo manualmente para ver se ele dá um erro mais útil.

e1000e eth0: Detected Hardware Unit Hang

Wed, 18 Dec 2019 00:00:00 GMT

Recentemente, meu servidor doméstico e host de VMs começou, do nada, a perder a conectividade de rede. Por fora parecia que ele ainda estava funcionando, mas eu não conseguia acessá-lo remotamente de nenhuma forma. O adaptador ethernet parecia ligado, segundo o switch, então o problema devia estar em algum lugar do software.

Não seria a primeira vez que um driver causaria travamentos na conexão de rede. No passado, já me ferrei com drivers de WiFi bugados em computadores Linux e Windows.

Depois de fuçar um pouco nos logs do sistema, me deparei com o seguinte:

vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state

Aí ele resetava o adaptador de rede e, depois de um tempo, fazia tudo de novo, até a máquina ficar completamente offline.

Procurando respostas na internet, encontrei esta thread no ServerFault.

Causa

Lendo várias fontes e listas de relatórios de bugs, parece que a melhor forma de reproduzir o problema é colocar o dispositivo numa situação de alta largura de banda, ou seja, transmitir grandes quantidades de dados que saturem a interface.

No meu caso, isso costumava acontecer quando eu estava transmitindo mídia do servidor Plex local para algum dispositivo. Pela forma como a rede está montada, a VM Windows que roda a instância do Plex precisa buscar o arquivo de mídia em um compartilhamento de rede NFS em outro dispositivo, transcodificá-lo na VM e só então enviá-lo ao dispositivo de reprodução.

Isso soma bastante tráfego de rede, geralmente ~40-100mbit/s, dependendo do dispositivo que reproduz o arquivo e da qualidade do arquivo de origem.

O mesmo problema apareceu ao transmitir jogos via Steam Link para a nossa Apple TV. A conexão é cabeada, mas não é incomum a rede cair. Acho que está relacionado ao mesmo problema, mas vou ficar de olho para ver se acontece de novo depois da correção.

Possível correção

Parece que uma possível correção seria desabilitar GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) e GRO (Generic Receive Offload) na interface de rede*:

ethtool -K eth0 gso off gro off tso off

Apliquei isso na minha configuração e estou esperando para ver se realmente resolve o problema a longo prazo.

Notas de rodapé

* Essas opções têm a ver com delegar a segmentação de pacotes ao controlador da interface de rede para reduzir o uso de CPU da máquina. Mais detalhes podem ser encontrados neste artigo da Wikipédia.

Snippets: Executando um registro de imagens Docker local/privado em um swarm

Fri, 11 Oct 2019 00:00:00 GMT

Hoje eu estava tentando gerar uma imagem Docker a partir de um projeto Node.js e queria fazer o deploy no meu swarm local de testes.

Infelizmente, se alguém constrói uma imagem Docker local, essa imagem fica armazenada e acessível apenas no nó em que foi criada, e os outros nós do swarm não conseguem acessá-la.

A solução é enviar (push) a imagem para um registro Docker (registry), de onde ela pode ser baixada (pull) por todos os nós do swarm.

Criando o registro

Para instanciar um serviço de registro no swarm, execute:

docker service create —name registry —publish 5000:5000 registry:latest

Isso vai criar o serviço de registro e executá-lo no swarm, tornando-o acessível a todos os nós do swarm.

Enviando uma imagem para o registro

Para enviar uma imagem para o registro, você precisa fazer duas coisas – tagear e então fazer o push da imagem.

Aqui vai um exemplo de como construir e tagear a imagem de uma vez só:

docker build . -t localhost.localdomain:5000/:latest

E como enviá-la para o registro:

docker push localhost.localdomain:5000/:latestUsando a imagem em um serviço/container/etc

Para usar a imagem em um serviço ou em um container, você especifica o caminho completo de cima, ou seja, localhost.localdomain:5000/<image-name>:latest.

Os nós do swarm vão ter acesso à imagem e conseguirão baixá-la e executá-la.

Nota importante sobre o endereço do registro

Na maioria dos tutoriais por aí, a URL do registro aparece como localhost:5000. Infelizmente isso não funciona e normalmente dá timeout quando se tenta usá-la. Se trocarmos para localhost.localdomain, funciona!

Não sei por que isso acontece, já que tanto localhost quanto localhost.localdomain resolvem para 127.0.0.1.

Snippets: Mapeie a tecla Section sign do teclado Apple para o acento grave ( § para ` )

Wed, 31 Jul 2019 00:00:00 GMT

Já faz um tempo que uso os teclados da Apple, mas quando você mora na Europa não é fácil encontrar os com layout americano, que é o que estou acostumado a usar.

No macOS existe um jeito “fácil” de remapear o teclado com apenas um comando no terminal:

watch -n1 -x hidutil property -m ’{“ProductID”:592, “VendorID”:1452}’ —set ’{“UserKeyMapping”:[{“HIDKeyboardModifierMappingSrc”:0x700000035,“HIDKeyboardModifierMappingDst”:0x700000064}]}’

O que esse trecho de código faz é mudar o mapeamento da tecla Section ( § ) para escrever a tecla de crase/til ( `/ ~ ).

A parte watch -n1 -x faz isso a cada segundo, porque às vezes o macOS gosta de perder a configuração, geralmente quando o computador entra em repouso ou quando o teclado é desconectado e conectado de novo.

Note que, em algumas versões do macOS, o utilitário watch não vem instalado e precisa ser obtido por meio de algo como Homebrew ou MacPorts.

O código acima funciona com o teclado externo da Apple com USB e layout europeu com letras búlgaras. Pode ser necessário um pequeno ajuste nos valores hexadecimais das teclas para outros tipos de teclado.

Uma variação do comando funciona bem para o mesmo tipo de teclado no próprio MacBook Pro. Basta trocar a posição dos valores 0x700000035 e 0x700000064.

Andei pensando em escrever uma ferramenta para fazer isso automaticamente por mim, mas neste momento acho que vale mais a pena investir em um teclado novo com o layout certo 🙂

Resetando/Reiniciando o controle remoto da Apple TV

Sun, 17 Feb 2019 00:00:00 GMT

Ontem à noite, durante a visita de uns convidados, consegui mergulhar o controle remoto da nossa Apple TV na água. Falta de sono e copos instáveis resultam em acidentes.

O controle estava funcionando bem ontem à noite, mas hoje parou de funcionar. Não responde a nenhuma ação. Tentei bater na palma da mão, sacudir para tirar a água. Não ajudou em nada.

Achamos que ele tinha ido embora dessa para uma melhor e começamos a procurar o pote de arroz nos armários.

Fui pesquisar na internet, mais como uma piada, para ver se dava para tentar “reiniciá-lo”.

Um guia prestativo me orientou a pressionar e segurar os botões Aumentar Volume e Menu por 2-3 segundos para resetar o controle e colocá-lo em modo de pareamento.

Fiquei muito surpreso quando realmente funcionou!

Então, se algo parecer estranho, tente resetar o controle primeiro. Se não funcionar, aí sim você pode partir para o arroz e a intervenção no hardware.

TL;DR;

Segure Menu + Aumentar Volume por 2-3 segundos
Espere alguns segundos
Tente interagir com a Apple TV

bisko.be - Dev

Rodando o Ollama com GPUs antigas no CachyOS

TL;DR;

Hora da história

[Linux] Recuperando uma sessão desconectada do `apt dist-upgrade`

[Linux] Syncthing – sistema de arquivos somente leitura ao rodar como serviço

[Linux] Executando vários comandos em vários servidores em paralelo

Iteração 1: Script Python customizado

Iteração 2: pssh

A versão resumida (TL;DR;) é:

Descobrindo a senha numérica de um arquivo zip usando apenas utilitários de linha de comando

Lidando com código espaguete em PHP: usando funções anônimas para extrair pedaços de código de template

Arduino/ESP32: Desabilitando o watchdog de tarefas

Configurando uma YubiKey para assinar commits do Git

A loucura do GPG

Geração de chaves direto na YubiKey

Configuração do cartão/dispositivo

Geração das chaves

Configurando o Git para assinar

Depuração

Assinando com o GPG

e1000e eth0: Detected Hardware Unit Hang

Snippets: Executando um registro de imagens Docker local/privado em um swarm

Snippets: Mapeie a tecla Section sign do teclado Apple para o acento grave ( § para ` )

Resetando/Reiniciando o controle remoto da Apple TV

Iteração 2: `pssh`