A jornada de um usuário de BSD testando o Alpine Linux

 (rubenerd.com)
1 pontos por GN⁺ 2024-04-28 | 1 comentários | Compartilhar no WhatsApp
  • Um usuário que usa com frequência desktop BSD, chroot e jail testa o Alpine Linux e considera que seu design focado em segurança, simplicidade e eficiência de recursos soa familiar para usuários de BSD
  • Graças ao tamanho reduzido e às dependências limitadas, o Alpine é amplamente usado não só como imagem base de contêineres, mas também em sistemas embarcados, roteadores, dispositivos móveis, servidores e desktops
  • A instalação é feita executando setup-alpine no ambiente live, configurando em sequência opções básicas como mapa de teclado, rede, fuso horário, SSH e NTP
  • Após o primeiro boot, aparece a combinação de OpenRC, musl e busybox, com elementos como /etc/rc.conf e crond(8) se aproximando da experiência de rc ao estilo BSD
  • Depois de verificar o gerenciamento de pacotes com apk, a configuração de repositórios e até a possibilidade de instalar ZFS, a impressão é boa o bastante para considerar seriamente o Alpine como principal distribuição Linux candidata para testes e servidores

O caráter do Alpine familiar para usuários de BSD

  • O Alpine Linux é uma distribuição Linux independente, não comercial e de uso geral para power users que valorizam segurança, simplicidade e eficiência de recursos
  • Os binários em espaço de usuário são compilados com PIE (Position Independent Executables) e proteção contra stack smashing, com foco em reduzir certos zero-days e explorações de vulnerabilidades
  • O Alpine é um projeto mais antigo do que se poderia imaginar, a ponto de Natanael Copa ter discutido as origens do projeto em 2005
  • Assim como os sistemas da família BSD, ele é usado em sistemas embarcados, roteadores e dispositivos móveis, além de servidores e desktops comuns
  • Pelo tamanho reduzido e pelas dependências limitadas, é amplamente usado como imagem base para contêineres Linux, e também há ferramentas como alpine-chroot-install para executá-lo facilmente em chroot(8)
    • Esse é um ponto especialmente interessante para quem usa bastante chroot(8) no NetBSD e jail no FreeBSD para testes e implantação

Experiência de instalação

  • O Alpine oferece várias builds, incluindo ARM, PPC64, x86 e x86_64
  • A imagem ISO para Xen foi iniciada em uma VM, mas a escolha veio de uma leitura equivocada de Dom0 como DomU
    • Dom0 se refere ao hipervisor Xen e não é um convidado
    • Ainda assim, o boot e a instalação prosseguiram como em uma ISO padrão
  • A instalação consiste em fazer login como root com senha em branco no ambiente live e executar setup-alpine
  • Durante a instalação, itens básicos como mapa de teclado, rede, fuso horário e autenticação do root são configurados em sequência
  • É possível injetar chaves SSH na etapa inicial
    • Isso é útil ao implantar grupos de VMs ou servidores depois com ferramentas de orquestração
    • Também ajuda em ambientes de hospedagem que não oferecem console OOB
  • É possível escolher servidor SSH e cliente NTP, permitindo selecionar OpenSSH e openntpd
  • O processo de instalação detecta corretamente que está rodando no Xen
  • Também é possível configurar LVM, mas desta vez foi escolhida a configuração padrão que o Alpine chama de partição sys
    • Essa configuração usa ext4

Configuração do sistema vista após o primeiro boot

  • Após o primeiro boot, é possível confirmar em dmesg(1) que o sistema está usando OpenRC
  • OpenRC é um sistema init portátil, pequeno, rápido, eficiente, transparente e seguro
  • Para usuários acostumados a escrever scripts rc ao estilo BSD, o OpenRC é muito familiar
    • Elementos como /etc/rc.conf e crond(8) se conectam à experiência de usuário de BSD
  • Com distribuições Linux que usam OpenRC, como Devuan, Gentoo e Alpine, o Linux volta a parecer interessante
  • Além do OpenRC, o Alpine inclui musl e usa busybox
    • musl e busybox são mais limitados que GCC e GNU coreutils, mas contribuem para o tamanho reduzido do sistema base e para a redução da superfície de ataque
  • llvm também está disponível
  • O MirBSD Korn shell também é oferecido como pacote e é um dos shells interativos preferidos

Gerenciamento de pacotes e repositórios

  • O gerenciador de pacotes padrão do Alpine é o apk
  • Como é comum no Linux, o apk atualiza o sistema base e os pacotes juntos, sem separá-los
  • Ainda não foi verificado se ele pode ser executado a partir de uma cópia sem privilégios, como no BSD
  • pkgsrc também pode ser usado, mantendo uma alternativa disponível
  • A configuração dos repositórios fica em /etc/apk/repositories
    • Ao descomentar a segunda URL fornecida pelo instalador, é possível ativar o repositório community
    • O Alpine também tem um repositório testing, e também é possível adicionar repositórios próprios
  • O uso é simples, embora hábitos antigos às vezes levem a digitar apt install por engano em vez de apk add
  • A interface web oficial de pacotes fica em pkgs.alpinelinux.org
  • Os repositórios do Alpine também podem ser consultados em pkgs.org

ZFS e avaliação como candidato para servidores

  • Depois de instalar alguns pacotes, foi possível montar a configuração de “ferramentas essenciais” usada em um notebook apenas com console
  • Um dos pacotes mais surpreendentes foi o ZFS
    • A instalação e o carregamento do módulo do kernel puderam ser feitos com dois comandos
# apk add zfs zfs-lts


# modprobe zfs
  • Configurar o sistema de arquivos raiz em ZFS pode ser mais complicado
  • Ainda não foi verificado como a configuração do ZFS se comportará após upgrades
  • Só pela experiência até agora, a impressão é boa o suficiente para considerar seriamente a migração para o Alpine como principal distribuição Linux para testes e servidores
  • Entre os pontos positivos estão ver apenas um pequeno número de processos reconhecíveis em htop(1) e lsof(1), o uso do OpenRC, o gerenciamento de pacotes aparentemente simples e a configuração fácil
  • A avaliação é que, se existir um “Occam’s Linux” moderno e funcional, o Alpine é algo próximo disso
  • Caso seja necessário ter mais funcionalidades do que as oferecidas pelo busybox, seria possível experimentar uutils, mas em servidores a necessidade parece baixa

Leituras relacionadas

1 comentários

 
GN⁺ 2024-04-28
Comentários do Hacker News

  • Do ponto de vista de segurança, hoje em dia a maioria dos binários Linux é compilada como PIE
    Se você rodar checksec em qualquer binário aleatório do Ubuntu, verá essa característica, e dá para instalar o checksec com pip install pwntools
    Por outro lado, até onde eu sei, a GLIBC tem a implementação de heap mais reforçada, com mais mitigações contra double free e outros ataques ao heap
    Então, por esse lado, dá para dizer que o Alpine é menos seguro por usar musl, mas o fato de ser um sistema pequeno e fácil de entender é uma vantagem real em segurança

    • Não entendo bem por que “um sistema pequeno e fácil de entender” seria argumento a favor da glibc. Na verdade, me parece o contrário
    • Eu sempre rodo checksec em tudo nos nós Alpine, e todos os processos aparecem assim. O output completo é longo demais para incluir, mas nunca vi algo compilado pelo Alpine sem essas flags
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • Vale a pena conferir a libc do OpenBSD também
    • Do ponto de vista de segurança no Linux, eu diria que, se alguém consegue executar qualquer código no sistema, já era. O Linux é cheio de brechas, e o motivo de não haver tanto malware quanto no Windows é que pouca gente usa Linux no desktop, então os criadores de malware não o visam tanto
      Sinceramente, acho que tanto o Windows moderno quanto o macOS têm uma arquitetura de segurança melhor

  • Eu também sou do pessoal do BSD e, por acaso, esta semana rodei Alpine pela primeira vez em uma VM sobre bhyve
    O ponto central é o BusyBox. Se os utilitários de /bin e /sbin não precisam ser binários independentes, o espaço de usuário fica bem pequeno e o boot é rápido. Instalando algo como Tmux e zsh, já foi suficiente para a maioria dos usos Unix
    Para chegar ao ambiente final, acabei instalando bastante coisa com apk, mas no geral foi a melhor experiência com Linux que tive em muito tempo. Seria bom ter ZFS por padrão e uma ligação virtio mais explícita, ajustada à execução do bhyve baseada em ZFS

    • Uso e distribuo FreeBSD há mais de 20 anos, e honestamente não gosto de entrar em caixas GNU/Linux. Há tanta variação e inconsistência que o sistema parece uma bagunça. Chega ao ponto de parecer mais “razoável” entrar em um servidor Windows
      Ainda assim, fico feliz em saber que pode existir uma distro Linux sensata, e se eu precisar de uma máquina Linux vou experimentar. Só que isso acontece bem raramente
    • Fico curioso sobre o quanto você quer dizer com ZFS “embutido por padrão”. O Alpine é uma das poucas distribuições que oferecem módulos binários do kernel para ZFS, então praticamente basta um comando apk para instalar
      A wiki do Alpine também tem uma documentação bem boa para instalar o sistema raiz em ZFS: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • O ZFS funciona muito bem no Alpine. Alpine + ZFS é minha configuração padrão de servidor há anos

  • Se você é usuário de BSD, pode gostar também do Void Linux. É uma distribuição criada pelo xtraeme, desenvolvedor do NetBSD, tem versões com glibc e musl, e usa runit como sistema de init
    Também dá para compilar pacotes a partir do código-fonte com xbps-src
    https://voidlinux.org/

    • Eu usava Arch e, depois de procurar uma alternativa sem SystemD com uma sensação parecida com a do Arch, acabei ficando no Void. Fui de Void em vez de Alpine por causa do suporte a glibc, que me permitia usar drivers NVidia. Claro, eu sei do “vaias para a NVidia”
    • Gosto muito do Void. Meu sistema principal é Arch por causa da grande seleção de pacotes e da conveniência do systemd, mas já instalei Void para parentes e em três máquinas minhas, e foi excelente
      Só vale avisar que eu usei apenas uma instalação xfce com mudanças mínimas. Em configurações multiusuário mais complexas, o runit pode dar um pouco mais de trabalho que o systemd, já que vem com menos recursos prontos
    • Há alguns anos, houve problemas ao usar Rust no voidlinux+musl. Felizmente, no Void dá para reinstalar facilmente com glibc
    • Chimera também pode ser uma boa. Como boa parte do userland das ferramentas centrais vem do FreeBSD, deve ser bem familiar para usuários de BSD
    • Também existe o CRUX. É a distro que serviu de base para o Archlinux

  • Eu esperava que alguém comentasse que as man pages tão celebradas pelos BSDs não vêm incluídas por padrão no Alpine. Esse foi um dos motivos para eu não usar Alpine no meu notebook de viagem, e hoje uso OpenBSD
    Será que deixei passar alguma opção de configuração para que a documentação seja sempre instalada ao baixar pacotes no Alpine? Ou a única saída é instalar manualmente os pacotes -doc toda vez?

    • Se você sempre quiser documentação, basta instalar o metapacote docs. Depois disso, ele puxa os pacotes *-doc correspondentes ao que você instalar
    • Como é o suporte a hardware ao usar OpenBSD em notebook?

  • Sinceramente, não entendo nem um pouco por que as pessoas acham algo como o OpenRC atraente. Se for um modelo baseado em supervisão, acho melhor do que qualquer abordagem que fique vazando PID, gravando em arquivo PID e esperando que, 3 semanas depois, aquele valor ainda aponte para o daemon que foi executado
    Além disso, em alguns casos fazem pgrep por um nome específico de processo para realizar tarefas de gerenciamento de serviço. Concordo até certo ponto com a ideia de que não se deve reiniciar tudo automaticamente por padrão, mas na prática essa é praticamente a única vantagem que esse grupo consegue apresentar
    E no fim essas coisas dependem muito de syslog, que é tecnologia dos anos 80 pura e simples. Ferramentas como multilog ou svlogd poderiam até ser melhoradas para oferecer com mais facilidade uma visão centralizada da ordem dos eventos entre várias ferramentas, mas essa ideia de agrupar logs em categorias vagas e deixar qualquer um registrar qualquer coisa com qualquer nome em qualquer lugar parece estranha

    • Vale notar que o Alpine vem tentando há anos encontrar um substituto para o OpenRC, mas não encontrou uma alternativa adequada. Também há tentativas de torná-lo uma distribuição independente de sistema de init
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • Ainda assim, a principal alternativa é o systemd, e ele foi projetado de um jeito inseguro que continua abrindo espaço para CVEs novos e interessantes
      Há coisa demais dentro do PID1, e ele é escrito em uma linguagem sem segurança de memória. Não vejo motivo técnico para que isso não pudesse ser dividido em um PID1 mínimo e alguns programas setuid
      Fora a possibilidade de rodar systemd dentro de contêineres Docker, não me vem mais nada à cabeça; e a Red Hat/IBM provavelmente não desejaria isso com tanta força, já que prefere usar suas próprias ferramentas de conteinerização, como o systemd-nspawn. Do jeito que está estruturado hoje, não vejo como isso possa algum dia se justificar do ponto de vista de segurança

  • O Alpine tem uma vantagem interessante. Quando um usuário de Nix quiser se exibir com gerenciamento declarativo de pacotes, dá para editar /etc/apk/world diretamente e rodar apk fix para mostrar como fazer isso sem Nix

    • Em geral, o jeito do Gentoo é melhor. Os pacotes instalados manualmente ficam em /var/lib/portage/world, os conjuntos escolhidos em /var/lib/portage/world_sets, e as definições dos conjuntos podem ficar em /etc/portage/sets/
      Isso permite separar pacotes por categoria, instalar apenas alguns deles nos sistemas que precisam e ainda adicionar comentários aos arquivos como quiser. O equivalente ao apk fix seria emerge -uDU @world && emerge -c, embora seja mais verboso
      O Alpine também permite criar algo parecido com conjuntos com apk add -t setname pkg1 pkg2 pkg3, e isso cria um pacote fictício que depende dos pacotes selecionados. Eu normalmente faço scripts de shell em /etc/apk/sets/ para imitar a sensação do Gentoo, mas nem sempre fica igual
    • No tempo que o Nix leva para avaliar a flake do meu sistema, eu consigo reinstalar o Alpine do zero
    • É legal, mas o Nix/OS faz muito mais do que apenas instalação declarativa de pacotes

  • Lembro que antigamente havia textos sobre desempenho ao rodar Alpine no Docker, recomendando usar Debian/Ubuntu
    Texto sobre Alpine lento:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Texto favorável ao Alpine:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    Fico curioso se isso ainda vale hoje

    • Pelo menos uma boa parte das reclamações específicas já foi resolvida. Como o próprio primeiro link admite no final, agora já existem wheels Python compatíveis com Alpine, e o problema de DNS foi corrigido há bastante tempo
      Ainda assim, seria interessante rodar benchmarks e ver os números reais em termos de desempenho

  • O musl ainda não suporta pthread_attr_setaffinity_np, certo? Nesse caso, alguns softwares não podem ser executados, e o maior exemplo é o PyTorch

    • Se uma carga de trabalho sensível a desempenho depende de glibc por causa dessa performance, então parece que bastaria rodar só essa aplicação em um contêiner
      Em muitas situações, simplicidade ou segurança importam mais do que desempenho

  • O meio-termo razoável que encontrei entre BSD e Linux é o Slackware. Assumidamente com cara de Unix, sem ser complicado, e ainda com uma rica árvore própria de ports via Slackbuilds

    • O Slackware tentou competir com distribuições desktop, mas perdeu o rumo por não se dedicar de verdade a isso
      Antigamente eu gostava dele por ser uma distribuição mínima que não atrapalhava, e achava que era voltada para um público um pouco mais técnico
      Mas, ao investigar problemas, a comunidade às vezes agia com hostilidade só porque eu não tinha feito a instalação completa. Diziam que instalação completa era o jeito recomendado, e se você não fizesse isso apareciam problemas de dependência idiotas, como o mplayer não funcionar porque o samba não estava instalado
      Vejo o Alpine como uma melhoria em todos os aspectos em relação ao Slackware
    • Respeito quem usa Slackware, mas a falta de gerenciamento de dependências parece incômoda

  • Então o Alpine Linux na verdade não era GNU/Linux. Eu não sabia
    Nesse caso seria BusyBox/Linux?

    • Pode chamar só de Alpine Linux. Pelo que sei, o BusyBox não tem nada a ver com aqueles surtos ocasionais de autopromoção que vazam do RMS, então tudo bem