Suportar versões atuais de Ubuntu, Debian, OpenWRT

[hmh]

Status:

• Ubuntu Jammy Jellyfish (22.04.x) -- 64bit only
• Ubuntu Focal Fossa (20.04.x) -- 64bit only
• Debian Bookworm (12.x) -- x86: 32 and 64-bit; ARM: 64-bit only
• Debian Bullseye (11.x) -- x86: 32 and 64-bit; ARM: 64-bit only
• Debian Buster (10.x) -- x86: 32 and 64-bit; ARM: 64-bit only -- limited support, EOL soon
• Mint 18, 19, 20
• OpenWRT 18.06.x ar71xx
• OpenWRT 19.07 ar71xx
• OpenWRT 19.07 ath79
• OpenWRT 21.02 ath79
• TurrisOS 6.4+ (Omnia) -- must install package "simetbox-openwrt-turrisos"
• OpenWRT 22.x ath79 -- interface LuCI do SIMETBox pode precisar de atualização
• RPI Raspbian -- apenas via código fonte

Em geral, outros sistemas operacionais e versões funcionam, mas com alguns problemas de integração e/ou empacotamento.

ARM 32-bits funciona perfeitamente, porém não distribuímos binários. Basta compilar diretamente do código fonte.

[farribeiro]

Olá, @hmh!

Como ficou o pacote do agente CLI do simet?

Como disse anteriormente, na issue #6 é extremamente vantajoso a inclusão deste simet ao agente ISPTools.

Abraços
Fábio Rodrigues Ribeiro

[hmh]

O agente CLI está empacotado faz tempo, mas só Ubuntu/Debian por enquanto. Tenho feito inclusive "pré-releases" do dito cujo já compilado via github.

Um exemplo em docker também faz parte do pacote faz tempo.

Edit: o agente CLI não está em beta há algum tempo. Visualizador está disponível, ele roda o navegador para acessar os resultados.

[farribeiro]

E a adesão, tem telemetria?

[hmh]

Edit: na versão de produção temos telemetria de:

• qual a versão do medidor (para detectarmos problemsa de atualização na frota, etc)
• quando um medidor registrou-se pela primeira vez, e data de último contato do medidor (para sabermos se é um medidor ativo ou não e podermos limpar registros antigos)
• qual o nome (Ubuntu, Debian, Mint...) e versão do sistema operacional em que o medidor foi instalado (para direcionar esforços de suporte e manutenção de compatibilidade)

O usuário pode, opcionalmente, configurar o medidor para enviar alguns metadados para seu registro (um hostname -- não precisa ser o do computador, e uma descrição). Usado por ISPs e organizações que possuem muitos medidores.

Fora isso, nas medições, guardamos as versões do medidor e sistema operacional, além da geolocalização (com precisão reduzida para "setor censitário" -- não guardamos a geolocalização exata).

[pedroaugustosmribeiro]

Poderia preparar um pacote para o Raspberrypi 1B (Raspbian/Debian Buster 10.x armhf), por favor?

[hmh]

O pacote fonte (debian) funciona no Rasbpian, basta baixar ele no SDK, e fazer o build. Mas a RPI 1B tem pouca capacidade de CPU e conectividade, não sabemos o quanto vai medir.

Em RPI 4B, mede perto de 1Gbps. Em RPI 3, é limitado pelo bus interno da RPI e pode ficar errático quando lota esse bus.

Colocar os pacotes fonte em um formato mais fácil de usar para RPI (junto com um guia, se necessário) está na lista de tarefas, mas não temos uma previsão neste momento.

Edit: os binários de instalação e nosso repositório APT suporta ARM64 (em Debian e Ubuntu). Infelizmente, ARM 32-bits só é suportado via build direto do código fonte, devido a um bug do QEMU.

[pedroaugustosmribeiro]

Ok, obrigado. Já consegui compilar a partir do próprio repositório e rodar no RPI 1B. Não serve para testes de velocidade (a interface dele é limitada a 100 Mbps), mas pode servir para verificar conectividade, latência, jitter, etc.

[hmh]

@pedroaugustosmribeiro bom, ele deveria servir para medições até perto de 100Mbps, se não "lotar" a CPU da RPI 1B.

[pedroaugustosmribeiro]

sim, porém minha conexão é de 300 Mbps, vai saturar de todo modo. Uso a RPI 1B porque é o que eu tenho, modelo 4 serial o ideal mesmo.

[hmh]

Atualizei diversos comentários para refletir a atualidade na versão de produção.

Mais detalhes sobre telemetria e dados que coletamos encontram-se na política de privacidade do medidor. Seguimos a lei brasileira (LGPD).