Recentemente, no debian 13 trixie os pacotes do minetest passar a se chamar Luanti. Uma otima atualização para ficar mais próximo do jogo, mas um arraso para quem rodava servidores hospedados na versão antiga. Várias coisas mudaram de lugar, e um bom resumo das alterações pode ser encontrado no Readme do pacote luanti-server.

Aqui em casa, além do jogo normal, gostamos de rodar as versões VoxeLibre e Mineclonia ambas com uma proposta mais próxima do Minecraft.

Para fazer a coisa “acontecer”, supondo que você já tenha instalado o pacote luanti-server, montei o servidor da seguinte forma.

em /etc/luanti foram criados dois arquivos para cada jogo. Usando o mineclonia como exemplo, criei os arquivos mineclonia.conf com o seguinte conteúdo:
> prometheuslisteneraddress=0.0.0.0:30001 map-dir=/var/lib/luanti/mineclonia/world name=rico port=30001 default_game=mineclonia

e um mineclonia.env com o seguinte conteúdo:
> LUANTI_GAMEID=mineclonia

feito isso, é hora de obter a versão do Mineclonia em questão do git na pasta correta. Penei um pouco para achar, mas deve ser feito em /var/lib/private/luanti

git clone https://codeberg.org/mineclonia/mineclonia.git

após clonado, recomendo mudar o proprietário e grupo para luanti-server atráves do comando chown -Rf luanti-server:luanti-server /var/lib/private/luanti/mineclonia

Feito isso, basta iniciar o servidor via systemctl da seguinte forma
systemctl start luanti-server@mineclonia

o @mineclonia que compõe o comando refere-se ao arquivo .conf criado em /etc/luanti.

Pronto, com isso você deve levantar um servidor com consideral menos esforço que eu. Fique de olho no parâmetro port=e no prometheus_listener para não tentar levantar o servidor em uma porta já utilizada.

Boa jogatina e divirta-se!

#minetest #debian #luanti #voxelibre #mineclonia

Esperançoso que o pool onde realmente estão os dados estava intacto, comecei a tarefa de tentar recuperar tudo. Felizmente, dada situações pregressas, eu tinha pelo menos alguma idéia de quais os discos realmente estavam envolvidos no pool que queria recuperar.

Desde o meu post anterior sobre zfs, comecei a usar a boa prática de adicionar os discos pelo seu número serial, conforme estão em /dev/disk/by-uuid em vez de usar os clássicos /dev/sdX ou coisa assim, que as vezes mudam a qual disco se referem. Pelo menos comigo, aconteceu mais de uma vez.

Enfim, após reinstalar o sistema em um disco a parte (resolvi por enquanto abandonar a idéia de ter o root em zfs) começa o trabalho de descobrir quais discos fazem parte do pool e remonta-lo Após preparar o novo sistema para o zfs e adicionar alguns discos do pool antigo, um simples zpool import começou a me encher de esperança

  pool: dados
     id: 1176411848024315794
  state: DEGRADED
status: The pool was last accessed by another system.
 action: The pool can be imported despite missing or damaged devices.  The
	fault tolerance of the pool may be compromised if imported.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY
 config:

	dados                          DEGRADED
	  raidz1-0                     DEGRADED
	    ata-ST32000644NS_9WM7LQT3  ONLINE
	    ata-ST32000644NS_9WM7N07E  UNAVAIL
	    wwn-0x5000cca224c5ea5c     ONLINE

Otimo, o pool estava lá. Com um disco a menos, mas estava lá. A partir daí, um zpool import dados -f fez o trabalho de deixar o pool disponível.

agora, para substituição do disco ausente, coloquei o pool offline com zpool offline dados ata-ST32000644NS_9WM7N07E e depois um zpool replace dados ata-ST32000644NS_9WM7N07E /dev/disk/by-id/ata-ST32000644NS_9WM7KY7S como sempre, tomando cuidado para usar o /dev/by-id para evitar que os discos se movimentem para um outro /dev/sdX em alguma manipulação futura dos cabos.

dessa forma, só bastou fazer um zfs mount -a e pronto, os datasets estavam montados e disponíveis.

Agora é configurar snapshots e backups para não precisar contar com a sorte no próximo incidente :)

#zfs #debian #recovery

Notice: Missing Signed-By in the sources.list(5) entry for 'http://deb.debian.org/debian'

Humm. teria eu feito algo de errado?

Resolvi dar uma olhada nos novos arquivos de source.list gerados, agora presentes em /etc/apt/sources.list.d/

Logo encontrei o erro no arquivo debian-backports.source:

# Modernized from /etc/apt/sources.list
Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: 

O campo Signed-By: havia ficado em branco. Ao fuçar um pouco no site do debian, achei isso, sugerindo que preenche o campo com /usr/share/keyrings/debian-archive-keyring.gpg

Feito isso e pans, problema resolvido :) vamos esperar que isso seja corrigido no modernize-sources antes do lançamento do Debian Trixie

#debian #apt #modernize-sources

Por exemplo, olhe isso aqui:

  pool: dados
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Feb 19 11:27:10 2025
	389G scanned at 862M/s, 34.8G issued at 77.2M/s, 389G total
	34.8G resilvered, 8.96% done, 01:18:15 to go
config:

	NAME                             STATE     READ WRITE CKSUM
	dados                            DEGRADED     0     0     0
	  mirror-0                       DEGRADED     0     0     0
	    replacing-0                  DEGRADED     0     0     0
	      16849396304634906415       UNAVAIL      0     0     0  was /dev/sda1
	      ata-ST32000644NS_9WM5X8TR  ONLINE       0     0     0  (resilvering)
	    sdb                          ONLINE       0     0     0

errors: No known data errors

Nesse caso, temos esse disco com esse identificador “16849396304634906415”. Como saber no fim das contas, qual disco é esse? Ele já foi /dev/sda1, mas como o meu lsblk mostra:

# lsblk 
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 111,8G  0 disk 
sdb      8:16   0   1,8T  0 disk 
├─sdb1   8:17   0   1,8T  0 part 
└─sdb9   8:25   0     8M  0 part 
sdc      8:32   0 223,6G  0 disk 
├─sdc1   8:33   0   512M  0 part /boot/efi
├─sdc2   8:34   0 222,1G  0 part /
└─sdc3   8:35   0   976M  0 part [SWAP]
sdd      8:48   0   1,8T  0 disk 
├─sdd1   8:49   0   1,8T  0 part 
└─sdd9   8:57   0     8M  0 part 
sde      8:64   1     0B  0 disk

esse não é necessáriamente mais o caso, visto que meu pool usa discos de 1.8TB e o atual /dev/sda tem apenas 111,8GB.

Não me pergunte porque, mas essas coisas acontecem. Em todo caso, decidi tomar um novo caminho, a partir de agora, faço os pools a a partir que consta em /dev/disk/by-id

# ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root  9 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA -> ../../sdc
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA-part3 -> ../../sdc3
lrwxrwxrwx 1 root root  9 fev 19 11:07 ata-SATA_SSD_181210101001015 -> ../../sda
lrwxrwxrwx 1 root root  9 fev 19 11:27 ata-ST32000644NS_9WM5X8TR -> ../../sdd
lrwxrwxrwx 1 root root 10 fev 19 11:27 ata-ST32000644NS_9WM5X8TR-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 fev 19 11:27 ata-ST32000644NS_9WM5X8TR-part9 -> ../../sdd9
lrwxrwxrwx 1 root root  9 fev 19 11:07 ata-ST32000644NS_9WM7KRXX -> ../../sdb
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-ST32000644NS_9WM7KRXX-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-ST32000644NS_9WM7KRXX-part9 -> ../../sdb9
lrwxrwxrwx 1 root root  9 fev 19 11:07 usb-Multiple_Card_Reader_058F63666485-0:0 -> ../../sde
lrwxrwxrwx 1 root root  9 fev 19 11:07 wwn-0x5000000000000000 -> ../../sda
lrwxrwxrwx 1 root root  9 fev 19 11:27 wwn-0x5000c500353451fe -> ../../sdd
lrwxrwxrwx 1 root root 10 fev 19 11:27 wwn-0x5000c500353451fe-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 fev 19 11:27 wwn-0x5000c500353451fe-part9 -> ../../sdd9
lrwxrwxrwx 1 root root  9 fev 19 11:07 wwn-0x5000c5003ec2f9c0 -> ../../sdb
lrwxrwxrwx 1 root root 10 fev 19 11:07 wwn-0x5000c5003ec2f9c0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 fev 19 11:07 wwn-0x5000c5003ec2f9c0-part9 -> ../../sdb9

Não que seja a coisa mais compreensível do mundo, mas pelo menos aí você pode usar o serial do disco (que normalmente vem estampado na etiqueta) para identificar qual disco você precisa trocar quando o seu pool der pau, aí fica muito mais simples. No meu caso, rodei: zpool replace dados 16849396304634906415 /dev/disk/by-id/ata-ST32000644NS_9WM5X8TR

e já sei que o disco 9wm5x8tr substitui o anterior que deu pau. Futuramente, pretendo adotar essa prática também para quando for criar um novo pool, ai evito essa incerteza de que, quando eventualmente o disco der pau (e vai dar) eu consigo saber qual devo trocar.

#zfs #debian