Introdução a Distribuições Linux

Introdução

Esse post tem a missão de introduzir o contexto de distribuições do Linux, suas diferenças e trazer uma ótica analítica para distros (distribuições) fora da curva.

Para começar, temos alguns esclarecimentos a serem considerados em todas as distribuições.

Release model

Uma dos principais pontos na escolha de uma distribuição é seu modelo de lançamento (release model).Hoje temos basicamente dois modelos, a fixed version (também conhecida como point release distributions) e a rolling release.

Basicamente, fixed version são releases que são congeladas com determinadas versões dos softwares e apenas recebem suporte com bugfixes, patches críticos e de segurança até a próxima release.

Esse, é o caso do Debian, CentOS, Ubuntu, etc. Cada um com possui um lagging entre a release do upstream e a incorporação da atualização no devido repositório, e isso depende bastante da política da distribuição. , gGeralmente, distribuições voltadas ao uso de servidores tendem a utilizar esse tipo de distribuição devido à estabilidade e ao tempo de suporte, que costuma variar entre 3 e 15 anos.

É importante destacar que existem distribuições fixed versions que não são LTS, um exemplo é o próprio Ubuntu, que utiliza versões não LTS para iterar no desenvolvimento, ou seja, há uma divisão entre Long Term Support (LTS), que possuem um período de suporte maior e as Short Term Support (STS) usadas primariamente para desenvolvimento.

As distribuições rolling release são o contrário, elas não têm o freezing de uma versão. A distribuição está em constante desenvolvimento, recebendo tanto novas versões de software como fixes e patches de segurança. Geralmente usada em desktops, tem algumas vantagens como sempre estar com o software mais atualizado e não necessitar de reinstalações para upgrades.

Alguns exemplos são o Arch Linux, NixOS e OpenSUSE Tumbleweed. É possível encontrar algumas informações com referência a rolling como “stream”, principalmente após o lançamento do CentOS Stream.

Como uma variação do rolling release ainda existem as semi rolling release, que são um pouco mais difíceis de encontrar, mas basicamente consistem numa base mais conservadora e o resto seguindo o modelo rolling.Uma distribuição que segue esse fluxo é o Funtoo, um fork do Gentoo onde é possível deixar “categorias” do sistema em releases diferentes, como, por exemplo ter a stack de vídeo mais recente e manter o resto do sistema na release estável. Tecnicamente é possível reproduzir o mesmo em outras distribuições, por exemplo o NixOS e o Debian, já que são flexíveis o suficiente para lidar com múltiplos repositórios e prioridade entre eles.

Apesar do “medo” que existe em executar distribuições rolling release, essas distribuições passam por um processo de testing igualmente rigoroso queao as da LTS, às vezes até mais., Nesse ponto, podemos destacar o NixOS e o OpenSUSE, que tem pipelines de CI\CD bem estruturadas e rigorosos testes que eliminam uma boa parte dos problemas, testando individualmente e no seu ecossistema além dos testes de cada aplicação.

No entanto, isso pode variar entre as distribuições… , o Arch Linux, por exemplo, segue o Git Flow e tem um grupo dedicado para testes além de uma política de estar o mais perto do upstream possível, o que às vezes podem levar a pacotes quebrados.

Dependendo da distribuição, é possível utilizar o backporting, isso é, ter componentes mais novos compilados para uma base antiga. No entanto, há argumentos de que esse tipo de processo acaba tornando a distribuição em um “Frankenstein”, pois o upstream costuma testar extensivamente o ambiente atual, não o antigo.

Init system

Um init é o primeiro processo que sobe com o sistema também tem a responsabilidade de gerenciar os serviços da distribuição

Apesar de não tão pronunciável hoje, temos distribuições com inits diferentes, geralmente variando entre a versão da distribuição e o objetivo dela. ,O Systemd é ocomo principal, acompanhado de sysvinit em legados (+6 anos) e OpenRC, runit e s6 em distribuições alternativas.

O Systemd tem basicamente uma nova camada de abstração para gerenciar serviços que visa simplificar as coisas, tendo uma integração bem enraizada no sistema, hoje possuindo o controle de diversas partes do SO, como NTP, containers (cgroups e nspawn), locale, logs (journal), logind, cron e muitos outros, enquanto as alternativas citadas trabalham primariamente com shell scripts.

Por esse motivo, o Systemd é completamente vinculado ao Linux, já os outros inits tem uma flexibilidade maior a custo de manutenção e são comuns no mundo BSD e Illumos (Solaris).

Comunidade

Na questão de comunidade, o que geralmente podemos avaliar é o tamanho, localidade e canais. , tTodas as distribuições possuem Git, IRC (ou Matrix devido àa migração do Freenode) e Mailing Lists, esses são os principais canais para novidades, acompanhamento/desenvolvimento e dúvidas.

Depois disso, cada distribuição tem seu ecossistema: , existem distribuições que mantêm fóruns e wikis próprios, assim como canais de comunicação mais “descontraídos”, a exemplo do Telegram e Discord. Por outro lado, outras utilizam fóruns mais genericosgenéricos, como LinuxQuestions, Reddit, etc.

A comunidade é algo fundamental, está ligada diretamente a oferta de pacotes, nível de maturidade, manutenção e inúmeros processos críticos em relação à distribuição.

Um ponto importante na vida de uma distribuição são seus mantenedores/guardiões. Distribuições que ficam completamente abaixo de um BDFL (Benevolent Dictator for Life) correm o risco de se perder no caso de abandono dar o projeto, e até desparecer ou morrer.

Inclusive, algumas distribuições já passaram isso, como é o caso do CentOS com o desaparecimento do fundador Lance Davis, Gentoo com a saída do Daniel Robbins e mais recentemente no Void Linux com o também desaparecimento do fundador Juan Romero.

, Nno entanto, em todos os casos a comunidade se organizou e assumiu o controle da distribuição, por isso muitas distribuições têm um grupo core que cuida m das partes mais críticas da distribuição e permitem um controle descentralizado. Assim,em casos extremos, a continuidade da distribuição é garantida.

A cooperação entre distribuições/comunidades também é extremamente importante, desde coisas simples como fixar bugs em distribuições rolling release primeiro e depois importar os patches para as distribuições LTS, como colaborações diretas com o upstream a fim de definir padrões.

Essa cooperação também é fundamental para a manutenção a longo prazo de uma distribuição, pois ela passa de um punhado de pacotes em torno do Linux para um agente ativo no ecossistema complexo que gira em torno do sistema.

Gerenciador de pacotes

Um pacote é basicamente uma coleção de arquivos que inclui ao menos um binário e que pertence  a uma aplicação ou biblioteca, compactado junto a metadata necessária, que informa dependências, versão, assinaturas, etc.

Um gerenciador de pacote é uma das coisas mais críticas do sistema.Ele é responsável pelo processo de gerenciamento de pacotes, como o próprio nome já diz, cuidando de tarefas como resolução de dependências, instalação, atualização, configuração e remoção de pacotes.

Existem dois tipos de gerenciador de pacotes, binary based e source based. Os binary based são aqueles em que o gerenciador manipula os binários diretamente, geralmente compilados pela distribuição, um vendor oficial ou de um repositório de terceiro. Algumas distribuições que se encaixam aqui são o Debian e CentOS .

Nesse tipo de distribuição, o usuário “aceita” o que o desenvolvedor escolheu como padrão para as opções de compilação do pacote, isso é, o desenvolvedor determina itens como, por exemplo, flags de compilação, suporte a instruções de CPU específicas e a feature matrix da aplicação (habilitar/desabilitar funcionalidades específicas).

Enquanto isso, nas source based (também chamadas de meta distribuição), tudo que é entregue é uma receita base daquele pacote. Você é responsável por compilar o pacote e tem a liberdade de o modificar como quiser, esse é o caso do Gentoo, por exemplo.

A desvantagem é clara para computadores mais fracos, no entanto, distribuições assim permitem o uso de um cache para evitar as builds constantes, como o NixOS, que, apesar de ser source based, tem um binary cache gigantesco, possibilitando o uso de inúmeros pacotes sem a necessidade de compilação.

Distribuições da mesma família compartilham um mesmo gerenciador de pacotes em comum, por exemplo, a família Debian tem como gerenciador de pacotes o dpkgs e a Red Hat o RPM.

Dependendo da distribuição, existem “frontends” para seus gerenciadores de pacotes, como o exemplo citado anteriormente, Debian-likes tem os apt* e Red Hat-likes tem o yum, dnf e zypper. Esses frontends têm como responsabilidade abstrair e simplificar os gerenciadores de pacotes, adicionando funções como busca, sincronização com os repositórios da distribuição etc.

Existem inúmeros gerenciadores de pacotes, não só para distribuições, como também para linguagens de programação, como no caso do Python com o pip, por exemplo:

• RPM (Red Hat likes, frontends Yum, DNF e Zypper)
• dpkg (Debian likes, frontends apt*)
• Portage
• Nix

Os gerenciadores de pacotes são uma parte fundamental do sistema, basicamente um divisor de águas, já que determinam como vai ser uma interação fundamental com o SO.

Nix, Flatpaks, Snaps e AppImages

Existem outros gerenciadores de pacotes que podem ser instalados em qualquer distribuição e não comprometem o gerenciador de pacote principal, são eles:

• Nix
• Flatpaks
• Snaps
• AppImage

Vale ressaltar que o suporte destes na distribuição pode variar… , geralmente Snaps estão mais voltados à família Debian e Flatpaks, à fámilia Red Hat. O Nix e o AppImage são mais “genéricos” e mais velhos nessa área, geralmente voltados a workstations, com intuito de isolar pacotes para o usuário ou de instalar pacotes específicos de maneira mais fácil ou atualizada que pelo gerenciador de pacotes/repositório principal.

Flatpaks, Snaps e AppImages também são usados para redistribuir alguns softwares proprietários, como a Steam, enquanto tem algum tipo de isolamento e são geralmente mais pesados (em storage) do que os tradicionais, pois são autocontidos, isso é, a aplicação vem com todas as dependências necessárias dentro de uma caixa e pronta para ser usada.

O diferencial do Nix, nesse caso, é a capacidade de gerenciar múltiplas versões de programas, como o NodeJS, Python e Ruby, ser declarativo e reproduzível, podendo entregar um arquivo que contêm toda a descrição de um ambiente de desenvolvimento configurado, similar a um docker-compose, mas sem qualquer overhead, e possuindo um alto nível de portabilidade, suporte a rollback e transações atômicas por padrão.

Repositórios

Os repositórios, ou repos, são onde os pacotes junto com a metadata ficam. No caso das distribuiçõe binary based, todo o pacote é baixado, geralmente envolvendo mirrors http(s) e (s)ftp (s). No caso das source based, costumam utilizar um repositório Git que contêm todas as “receitas” dos pacotes disponíveis para distribuição.

O que é incluído no repositório oficial da distribuição depende somente dela e de sua política de empacotamento. Algumas distribuições possuem política específicas para a não inclusão de software proprietário, outras de atualização (como o caso das LTS) somente a cada release, etc.

Distribuições baseadas na família Debian e Red Hat (RH) geralmente têem acesso a mais repositórios de terceiros, sejam terceiros oficiais como o software vendor ou SIGs (grupos de interesse) específicos, além do EPEL para os RH-like.

Suporte a software proprietário

O uso de software proprietário é um pouco mais complexo e algo que varia bastante entre as distribuições. Se o software é algo mais “universal”, como a Steam, as distribuições geralmente as empacotam.

Quando são aplicações mais específicas os vendors geralmente optam por entregar .deb ou .rpm, às vezes tar.gz, que possibilitam o empacotamento para outras distribuições. No entanto, muitas vezes isso fica restrito às famílias Debian e Red Hat, assim como o suporte também.

Além da questão de disponibilidade, existem pontos como suporte e políticas de aceite. Dependendo da distribuição, é possível que existam pacotes proprietários diretamente no repositório principal, que podem ser usados com o aceite da licença.

Kernel

A maior parte das distribuições utilizam um kernel Linux levemente modificado para atender as suas necessidades. Em distribuições source based, o processo de patching para tunning de uma demanda de Infraestrutura é bem simples, já que já existe a “receita” pronta.

Além disso, em distribuições assim, geralmente existe opção de escolher executar kernels diferentes do Vanilla (original, sem patches), os chamados patchsets, que são basicamente conjuntos de patches para o kernel que têem alguma finalidade específica, como o Ck e o Zen – que visam melhorar a performance para desktops,.

Também são bem mais fáceis de lidar caso seja necessário o tunnig de configurações do kernel. É possível fazer o mesmo em distribuições binary based, levando um pouco mais de tempo e alguns cuidados extras.

É importante destacar que não existem “incompatibilidades” entre os kernel e/ou patches de cada distribuição, afinal, ele é o item que é compartilhado entre todas as distribuições (caso contrário, não seriam uma distribuição Linux), independentemente de init, userland, libc, etc. Um exemplo claro disso é o Funtoo (fork do Gentoo), que utiliza por padrão o kernel do Debian.

Userland

Aqui é um ponto que pode mudar bastante a interação com o SO:, basicamente, existem dois grandes userlands, o GNU e o BSD. Algumas das distribuições analisadas possuem a capacidade de mudar parcialmente ou completamente para o respectivo userland, mudando ferramentas básicas como tar, top e outras ferramentas que interagimos no dia a dia como operador.

Libc

Outra parte do coração de uma distribuição é sua libc. Existem duas grandes libc atualmente, sendo as outras mais voltadas para ambientes embarcados.

Temos a GNU LibC (glibc) e a Musl. A glibc é padrão e uma boa parte das distribuições fazendo parte da userland do GNU e a Musl que vem com a intenção de ser mais simples, rápida e segura.

A glibc tem um grau de compatibilidade muito grande, o que faz ela ser um pouco mais “inchada” que as demais – geralmente é a única que os vendors proprietários suportam.

A Musl é padrão em distribuições como o Alpine Linux, comumente utilizada em containers.

Know how

Esse ponto é mais voltado à dificuldade em manter um parque com essa distribuição… as famílias Debian e Red Hat são simples de operar, especialmente com ferramentas como o Ansible e Puppet. No entanto, distribuições mais específicas como Arch, Gentoo, NixOS e Slackware podem precisar de conhecimentos além do básico.

Origem

Esse ponto determina se a distribuição é original (não baseada em outras) ou um fork (baseado em alguma distribuição).

NixOS

A primeira parte dessa séerie não poderia começar com outra distro (dica , para entender o porquê: é só olhar o perfil no Github do autor ): , o NixOS é uma distribuição baseada no gerenciador de pacotes Nix, que começou como um projeto de pesquisa iniciado em 2003 pelo Eelco Dolstra. O NixOS utiliza configurações declarativas para definir todo o sistema, permitindo transações atômicas e rollbacks simples em caso de problemas.

Existem duas branches no sistema, a estável – que entra em freezing semelhante as distribuições LTS –, com duas releases por ano com suporte de até 1 ano cada, sendo que o upgrade é sempre o caminho preferido. E  a “instável”, onde o desenvolvimento da distribuição ocorre de fato. A branch instável é uma rolling release.

O init do NixOS é o Systemd e é uma peça fundamental. A userland é primariamente baseada no GNU com liberdade de substituição de ferramentas pela do BSD, tem suporte a musl e diversas arquiteturas.

Todo o desenvolvimento acontece no Github, com CI\CD apoiado pelo Github Actions, Hydra e Cachix. A comunidade é mais nicho, composta primariamente de desenvolvedores com experiência em linguagens funcionais, além de startups e consultorias da Europa como sponsors.

O desenvolvimento é 100% transparente e acontece tanto no Github quanto no fórum e Matrix oficiais da distribuição, sendo que qualquer um pode opinar. Além disso, temos times dedicados para diversas áreas, como kernel, segurança, golang, systemd, KDE, GNOME etc.

Uma boa parte do processo de manutenção é automatizado, deixando os mantenedores focados no que realmente precisa de atenção na distribuição.

Apesar da curva de aprendizado um pouco mais íngreme, o NixOS despenha perfeitamente o papel de workstation e servidor, trazendo excelentes funcionalidades, como:

• Configuração declarativa
• Upgrades confiáveis
• Transações atômicas
• Rollbacks extremamente simples
• Builds reproduzíveis
• Source based com binary cache gigante
• Consistente
• Suporte ao gerenciamento de pacote multiusuário

Com o NixOS não existe a necessidade de outras ferramentas de IAC como o Ansible ou Puppet pois o SO é completamente baseado em código, incluindo ambientes que podem ser gerenciados pelo Nix, possibilitando a portabilidade entre distribuições, por exemplo.

Na verdade, parte do que o NixOS é hoje é uma perfeita representação de alguns desejos DevOps, principalmente de imutabilidade e definição * as code. e eEle casa perfeitamente com orquestradores de infraestrutura como o Terraform ou como host para o Kubernetes.

O repositório é um dos maiores, com mais de 60 mil pacotes, e com a possibilidade de fácil criação de overlays (repositórios externos). Existe também uma boa gama de outros repositórios, geralmente focados em nichos específicos, como, por exemplo, o suporte a Rust da Mozilla.

Além da curva de aprendizado íngreme, outro ponto de consideração é o suporte ao software proprietário…, esse é um ponto complexo, pois o NixOS não é compatível com o FH. Logo, binários aleatórios encontrados na internet tendem a não funcionar sem alterações, com exceção de binários como os do Go, que são autocontidos.

• NixOS para monitoramento

{ config, pkgs, lib, inputs, modulesPath, ... }:

{
  # Perfil base para VPS
  imports = [ (modulesPath + "/profiles/qemu-guest.nix") ];
  # fstab
  fileSystems."/" = {
    device = "nix/nixos";
    fsType = "zfs";
  };
  fileSystems."/boot" = {
    device = "/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx";
    fsType = "ext4";
    options = [ "noatime" "nodiratime" "discard" ];
  };
  fileSystems."/home" = {
    device = "nix/home";
    fsType = "zfs";
  };
  fileSystems."/root" = {
    device = "nix/root";
    fsType = "zfs";
  };
  swapDevices = [{ device = "/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx"; }];
  # Bootloader + kernel
  boot.loader.grub.devices = [ "/dev/vda" ];
  boot.kernelPackages = pkgs.linuxPackages_latest;
  boot.loader.grub.enable = true;
  boot.loader.grub.version = 2;
  boot.consoleLogLevel = 7;
  boot.cleanTmpDir = true;
  boot.loader.grub.copyKernels = true;
  boot.loader.grub.zfsSupport = true;
  boot.zfs.devNodes = "/dev/disk/by-uuid";
  boot.initrd.availableKernelModules = [ "ata_piix" "uhci_hcd" "virtio_pci" "sr_mod" "virtio_blk" ];
  # Pacotes do sistema
  environment.systemPackages = with pkgs; [
    tmux
    wget
    vim
    git
    nixfmt
    zoxide
    fzf
    nvd
    direnv
    any-nix-shell
    file
    bat
    ripgrep
    fd
    dig
    lsof
    alertmanager-bot
  ];
  # Autoupgrade
  system.autoUpgrade.enable = true;
  system.autoUpgrade.flake = "/etc/nixos";
  system.autoUpgrade.flags = [
    "--update-input"
    "nixpkgs"
    "--recreate-lock-file"
    "--no-write-lock-file"
  ];
  system.autoUpgrade.allowReboot = true;
  # Segurança
  nix.trustedUsers = [ "root" "@wheel" ];
  nix.allowedUsers = [ "@wheel" ];
  security.auditd.enable = true;
  security.audit.enable = true;
  security.audit.rules = [ "-a exit,always -F arch=b64 -S execve" ];
  security.sudo.enable = false;
  # Rede
  networking.hostId = "a0e8ea23";
  networking.useDHCP = false;
  networking.interfaces.ens3.useDHCP = true;
  networking.hostName = "deathstar";
  networking.firewall.allowedTCPPorts = [ 22 80 443 ];
  networking.firewall.allowedUDPPorts = [ ];
  # Serviços
  services = {
    logrotate = { enable = true; };
    fail2ban = { enable = true; };
    openssh = {
      enable = true;
      permitRootLogin = "no";
      allowSFTP = false;
      challengeResponseAuthentication = false;
      passwordAuthentication = false;
      ports = [ 22 ];
      startWhenNeeded = true;
    };
    grafana = {
      port = 3000;
      enable = true;
      domain = "grafana.machines.com";
    };
    prometheus = {
      listenAddress = "127.0.0.1";
      checkConfig = true;
      enable = true;
      configText = builtins.readFile ./extra/prometheus.yaml;
      alertmanager = {
        enable = true;
        listenAddress = "127.0.0.1";
        extraFlags = [ "--cluster.advertise-address=127.0.0.1:9093" ];
        configText = builtins.readFile ./extra/alertmanager.yaml;
      };
      exporters = {
        systemd = {
          enable = true;
          listenAddress = "localhost";
        };
        node = {
          enable = true;
          listenAddress = "localhost";
        };
        domain = {
          enable = true;
          listenAddress = "localhost";
        };
        blackbox = {
          enable = true;
          listenAddress = "localhost";
          configFile = extra/blackbox.yaml;
        };
      };
    };
    nginx = {
      enable = true;
      recommendedTlsSettings = true;
      recommendedGzipSettings = true;
      recommendedOptimisation = true;
      recommendedProxySettings = true;
      virtualHosts = {
        "prometheus.machines.com" = {
          forceSSL = false;
          enableACME = false;
          locations."/" = {
            proxyPass = "http://localhost:9090";
          };
        };
        "alertmanager.machines.com" = {
          forceSSL = false;
          enableACME = false;
          locations."/" = {
            proxyPass = "http://localhost:9093";
          };
        };
        "grafana.machines.com" = {
          forceSSL = false;
          enableACME = false;
          locations."/" = {
            proxyPass = "http://localhost:3000";
          };
        };
        "_" = {
          forceSSL = false;
          enableACME = false;
          locations."/" = {
            extraConfig = ''
              deny all;
              return 444;
            '';
          };
        };
      };

    };
  };
  # Provisiona as regras do Alert Manager
  environment.etc."alert.rules" = { source = ./extra/alert.rules; };
}

O código acima tem tudo que você precisa para subir uma VM com:

• Sistema de arquivos baseado no ZFS
• GRUB, Kernel e fstab configurados
• Pacotes base
• Autoupgrade por padrão
• Hardening básico (sem sudo, auditd e operações de pacotes somente por grupos especificos)
• Firewall configurado
• Serviços base como ssh, logrotate e fail2ban
• Grafana, Prometheus e AlertManager subindo já configurados
• Exporters basicos como systemd, node, domain e blackbox já configurados
• Proxy reverso com o NGINX com as configurações recomendadas

Tudo isso com uma única linguagem, testada previamente pelos mantenedores e em 174 linhas!

• Nix para dependências de projeto

Você não precisa do NixOS para usar o Nix e ter todos seus benefícios.Tome como exemplo o código abaixo:

{ pkgs ? import <nixpkgs> { } }:
with pkgs;
mkShell {
  buildInputs = [ terraform_1_0_0 graphviz figlet lolcat google-cloud-sdk ];
  shellHook = ''
    echo Ready to terraform! | figlet | lolcat
  '';
}

Esse código é responsável por lhe dar um shell com os programas definidos previamente, ou seja, você não precisa instalar todos os componentes do seu projeto na sua máquina de desenvolvimento! Pode passar a gerenciá-los como deveria, por projeto!

Sem mais conflito de versões, variáveis de ambiente soltas ou interações estranhas!

Você define o que precisa para seu projeto e o Nix te entrega um shell com tudo.Além disso, existem ferramentas dedicadas a automatizar esse processo simplesmente por dar um cd na pasta do seu projeto como o Lorri e o Direnv.

Conclusão

Isso é tudo pessoal! Espero que tenham gostado da primeira parte do Introdistro, e quem sabe, despertado a curiosidade sobre o ecossistema Nix!

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA