1.1 Um curso intensivo de Scheme

Guix usa a implementação Guile do Scheme. Para começar a brincar com a linguagem, instale-a com guix install guile e inicie um REPL—abreviação de read-eval-print loop—executando guile na linha de comando.

Alternativamente, você também pode executar guix shell guile -- guile se preferir não ter o Guile instalado em seu perfil de usuário.

Nos exemplos a seguir, as linhas mostram o que você digitaria no REPL; linhas que começam com “⇒” mostram resultados de avaliação, enquanto linhas que começam com “-|” mostram coisas que são exibidas. Veja Using Guile Interactively em Manual de referência do GNU Guile, para mais detalhes sobre o REPL.

• A sintaxe de Scheme se resume a uma árvore de expressões (ou s-expression no jargão Lisp). Uma expressão pode ser um literal, como números e strings, ou um composto que é uma lista entre parênteses de compostos e literais. #true e #false (abreviados #t e #f) representam os booleanos “true” e “false”, respectivamente.

  Exemplos de expressões válidas:

  "Hello World!"
  ⇒ "Hello World!"
  
  17
  ⇒ 17
  
  (display (string-append "Olá " "Guix" "\n"))
  -| Olá Guix!
  ⇒ #<unspecified>
  

• Este último exemplo é uma chamada de função aninhada em outra chamada de função. Quando uma expressão entre parênteses é avaliada, o primeiro termo é a função e o restante são os argumentos passados para a função. Cada função retorna a última expressão avaliada como valor de retorno.
• Funções anônimas —procedures na linguagem do Scheme — são declaradas com o termo lambda:

  (lambda (x) (* x x))
  ⇒ #<procedimento 120e348 em <porta desconhecida>:24:0 (x)>
  

  O procedimento acima retorna o quadrado do seu argumento. Como tudo é uma expressão, a expressão lambda retorna um procedimento anônimo, que por sua vez pode ser aplicado a um argumento:

  ((lambda (x) (* x x)) 3)
  ⇒ 9
  

  Os procedimentos são valores regulares, assim como números, strings, booleanos e assim por diante.

• Qualquer coisa pode receber um nome global com define:

  (define a 3)
  (define square (lambda (x) (* x x)))
  (square a)
  ⇒ 9
  

• Os procedimentos podem ser definidos de forma mais concisa com a seguinte sintaxe:

  (define (square x) (* x x))
  

• Uma estrutura de lista pode ser criada com o procedimento list:

  (list 2 a 5 7)
  ⇒ (2 3 5 7)
  

• Os procedimentos padrão são fornecidos pelo módulo (srfi srfi-1) para criar e processar listas (veja processamento de listas em Manual de referência do GNU Guile). Aqui estão alguns dos mais úteis em ação:

  (use-modules (srfi srfi-1)) ;importar procedimentos de processamento de lista
  
  (append (list 1 2) (list 3 4))
  ⇒ (1 2 3 4)
  
  (map (lambda (x) (* x x)) (list 1 2 3 4))
  ⇒ (1 4 9 16)
  
  (delete 3 (list 1 2 3 4))        ⇒ (1 2 4)
  (filter odd? (list 1 2 3 4))     ⇒ (1 3)
  (remove even? (list 1 2 3 4))    ⇒ (1 3)
  (find number? (list "a" 42 "b")) ⇒ 42
  

  Observe como o primeiro argumento para map, filter, remove e find é um procedimento!

• O quote desativa a avaliação de uma expressão entre parênteses, também chamada de expressão S ou “s-exp”: o primeiro termo não é chamado sobre os outros termos (veja quote em Manual de referência do GNU Guile). Assim, ele efetivamente retorna uma lista de termos.

  '(display (string-append "Hello " "Guix" "\n"))
  ⇒ (display (string-append "Hello " "Guix" "\n"))
  
  '(2 a 5 7)
  ⇒ (2 a 5 7)
  

• O quasiquote (`, uma crase) desativa a avaliação de uma expressão entre parênteses até que unquote (,, uma vírgula) a reative. Assim, nos fornece um controle refinado sobre o que é avaliado e o que não é.

  `(2 a 5 7 (2 ,a 5 ,(+ a 4)))
  ⇒ (2 a 5 7 (2 3 5 7))
  

  Observe que o resultado acima é uma lista de elementos mistos: números, símbolos (aqui a) e o último elemento é uma lista em si.

• Guix define uma variante de expressões simbólicas (S-expressions) com esteróides chamada G-expressions ou “gexps”, que vem com uma variante de quasiquote e unquote: #~ ( ou gexp) e #$ (ou ungexp). Eles permitem preparar código para execução posterior.

  Por exemplo, você encontrará gexps em algumas definições de pacotes onde eles fornecem código a ser executado durante o processo de construção do pacote. Eles se parecem com isto:

  (use-modules (guix gexp)           ; para que possamos escrever gexps
               (gnu packages base))  ; para 'coreutils'
  
  ;; Abaixo está uma expressão G representando código preparado.
  #~(begin
      ;; Invoca 'ls' do pacote definido pela variável 'coreutils'.
      (system* #$(file-append coreutils "/bin/ls") "-l")
  
      ;; Crie o diretório de saída deste pacote.
      (mkdir #$output))
  

  Veja Expressões-G em Manual de Referência do GNU Guix, para saber mais sobre gexps.

• Múltiplas variáveis podem ser nomeadas localmente com let (veja Local Bindings em Manual de referência do GNU Guile):

  (define x 10)
  (let ((x 2)
        (y 3))
    (list x y))
  ⇒ (2 3)
  
  x
  ⇒ 10
  
  y
  error→ No procedimento module-lookup: Variável não vinculada: y
  

  Use let* para permitir que declarações de variáveis posteriores se refiram a definições anteriores.

  (let* ((x 2)
         (y (* x 3)))
    (list x y))
  ⇒ (2 6)
  

• Palavras-chave normalmente são usados para identificar os parâmetros nomeados de um procedimento. Eles são prefixados por #: (hash, dois pontos) seguido por caracteres alfanuméricos: #:like-this. Veja Keywords em Manual de referência do GNU Guile.
• A porcentagem % normalmente é usada para variáveis globais somente-leitura no estágio de construção. Observe que é apenas uma convenção, como _ em C. Scheme trata % exatamente da mesma forma que qualquer outra letra.
• Os módulos são criados com define-module (veja Creating Guile Modules em Manual de referência do GNU Guile). Por exemplo

  (define-module (guix build-system ruby)
    #:use-module (guix store)
    #:export (ruby-build
              ruby-build-system))
  

  define o módulo guix build-system ruby que deve estar localizado em guix/build-system/ruby.scm em algum lugar no caminho de carregamento do Guile. Depende do módulo (guix store) e exporta duas variáveis, ruby-build e ruby-build-system.

  Veja Módulos de pacote em GNU Guix Reference Manual, para informações sobre módulos que definem pacotes.

Indo além: Scheme é uma linguagem que tem sido amplamente utilizada para ensinar programação e você encontrará muito material usando-a como veículo. Aqui está uma seleção de documentos para saber mais sobre o Scheme:

• A Scheme Primer, por Christine Lemmer-Webber e o Spritely Institute.
• Scheme at a Glance, por Steve Litt.
• Structure and Interpretation of Computer Programs, por Harold Abelson e Gerald Jay Sussman, com Julie Sussman. Coloquialmente conhecido como “SICP”, este livro é uma referência.

  Você também pode instalá-lo e lê-lo em seu computador:

  guix install sicp info-reader
  info sicp
  

Você encontrará mais livros, tutoriais e outros recursos em https://schemers.org/.

2.1 Tutorial sobre empacotamento

GNU Guix se destaca como o gerenciador de pacotes hackeável, principalmente porque usa GNU Guile, uma poderosa linguagem de programação de alto nível, um dos dialetos Scheme da família Lisp.

As definições de pacotes também são escritas em Scheme, o que capacita o Guix de maneiras muito exclusivas, ao contrário da maioria dos outros gerenciadores de pacotes que usam shell scripts ou linguagens simples.

• Utilize funções, estruturas, macros e toda a expressividade do Scheme para definições de seus pacotes.
• A herança facilita a personalização de um pacote, herdando-o e modificando apenas o que é necessário.
• Processamento em lote: toda a coleção de pacotes pode ser analisada, filtrada e processada. Construindo um servidor headless com todas as interfaces gráficas removidas? É possível. Quer reconstruir tudo, desde o código-fonte usando sinalizadores específicos de otimização do compilador? Passe o argumento #:make-flags "..." para a lista de pacotes. Não seria exagero pensar em Gentoo USE flags aqui, mas isso vai ainda mais longe: as mudanças não precisam ser pensadas de antemão pelo empacotador, elas podem ser programadas pelo usuário!

O tutorial a seguir cobre todos os fundamentos da criação de pacotes com Guix. Não pressupõe muito conhecimento do sistema Guix nem da linguagem Lisp. Espera-se apenas que o leitor esteja familiarizado com a linha de comando e tenha alguns conhecimentos básicos de programação.

• Um pacote “Hello World”
• Configuração
• Exemplo estendido
• Outros sistemas de construção
• Definição de pacote programável e automatizada
• Obtendo ajuda
• Conclusão
• Referências

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (synopsis "Hello, GNU world: An example GNU package")
    (description
     "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

(use-modules (guix packages)
             (guix download)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "my-hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, Guix world: An example custom Guix package")
  (description
   "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
  (home-page "https://www.gnu.org/software/hello/")
  (license gpl3+))

$ guix download mirror://gnu/hello/hello-2.10.tar.gz

Starting download of /tmp/guix-file.JLYgL7
From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz...
following redirection to `https://mirror.ibcp.fr/pub/gnu/hello/hello-2.10.tar.gz'...
 …10.tar.gz  709KiB                                 2.5MiB/s 00:00 [##################] 100.0%
/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i

$ guix download mirror://gnu/hello/hello-2.10.tar.gz.sig

Iniciando download de /tmp/guix-file.03tFfb
De https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz.sig...
seguindo redirecionamento para `https://ftp.igh.cnrs.fr/pub/gnu/hello/hello-2.10.tar.gz.sig'...
….tar.gz.sig 819B 1,2 MiB/s 00:00 [#################] 100,0%
/gnu/store/rzs8wba9ka7grrmgcpfyxvs58mly0sx6-hello-2.10.tar.gz.sig
0q0v86n3y38z17rl146gdakw9xc4mcscpk8dscs412j22glrv9jf
$ gpg --verify /gnu/store/rzs8wba9ka7grrmgcpfyxvs58mly0sx6-hello-2.10.tar.gz.sig /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
gpg: Assinatura feita em dom 16 nov 2014 01:08:37 PM CET
gpg: usando RSA chave A9553245FDE9B739
gpg: Boa assinatura de "Sami Kerola <kerolasa@iki.fi>" [desconhecido]
gpg: também conhecido como "Sami Kerola (http://www.iki.fi/kerolasa/) <kerolasa@iki.fi>" [desconhecido]
gpg: AVISO: Esta chave não é certificada com uma assinatura confiável!
gpg: Não há indicação de que a assinatura pertença ao proprietário.
Impressão digital da chave primária: 8ED3 96E3 7E38 D471 A005 30D3 A955 3245 FDE9 B739

$ guix package --install-from-file=my-hello.scm

$ guix package --list-installed=my-hello
my-hello	2.10	out
/gnu/store/f1db2mfm8syb8qvc357c53slbvf1g9m9-my-hello-2.10

  -f, --install-from-file=ARQUIVO
                         instala o pacote para o qual o código
                         dentro do ARQUIVO avalia

mkdir ~/my-channel

(define-module (my-hello)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (guix build-system gnu)
  #:use-module (guix download))

(define-public my-hello
  (package
    (name "my-hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (synopsis "Olá, mundo Guix: Um exemplo de pacote Guix personalizado")
    (description
     "GNU Hello imprime a mensagem \"Olá, mundo!\" e então sai. Ele
serve como um exemplo de práticas de codificação GNU padrão. Como tal, ele suporta
argumentos de linha de comando, vários idiomas e assim por diante.")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

;; ...
(define-public my-hello
  ;; ...
  )

my-hello

guix show -L ~/my-channel my-hello
guix build -L ~/my-channel my-hello

cd ~/my-channel
git init
git add my-hello.scm
git commit -m "Primeiro commit do meu canal."

(append (list (channel
                (name 'my-channel)
                (url (string-append "file://" (getenv "HOME")
                                    "/my-channel"))))
        %default-channels)

$ git clone https://git.savannah.gnu.org/git/guix.git

(define-module (gnu packages version-control)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix utils)
  #:use-module (guix packages)
  #:use-module (guix git-download)
  #:use-module (guix build-system cmake)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages python)
  #:use-module (gnu packages ssh)
  #:use-module (gnu packages tls)
  #:use-module (gnu packages web))

(define-public my-libgit2
  (let ((commit "e98d0a37c93574d2c6107bf7f31140b548c6a7bf")
        (revision "1"))
    (package
      (name "my-libgit2")
      (version (git-version "0.26.6" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "https://github.com/libgit2/libgit2/")
                      (commit commit)))
                (file-name (git-file-name name version))
                (sha256
                 (base32
                  "17pjvprmdrx4h6bb1hhc98w9qi6ki7yl57f090n9kbhswxqfs7s3"))
                (patches (search-patches "libgit2-mtime-0.patch"))
                (modules '((guix build utils)))
                ;; Remover software empacotado.
                (snippet '(delete-file-recursively "deps"))))
      (build-system cmake-build-system)
      (outputs '("out" "debug"))
      (arguments
       `(#:tests? #true                         ; Execute o conjunto de testes (este é o padrão)
         #:configure-flags '("-DUSE_SHA1DC=ON") ; Detecção de colisão SHA-1
         #:phases
         (modify-phases %standard-phases
           (add-after 'unpack 'fix-hardcoded-paths
             (lambda _
               (substitute* "tests/repo/init.c"
                 (("#!/bin/sh") (string-append "#!" (which "sh"))))
               (substitute* "tests/clar/fs.h"
                 (("/bin/cp") (which "cp"))
                 (("/bin/rm") (which "rm")))))
           ;; Execute verificações de forma mais detalhada.
           (replace 'check
             (lambda* (#:key tests? #:allow-other-keys)
               (when tests?
                 (invoke "./libgit2_clar" "-v" "-Q"))))
           (add-after 'unpack 'make-files-writable-for-tests
             (lambda _ (for-each make-file-writable (find-files ".")))))))
      (inputs
       (list libssh2 http-parser python-wrapper))
      (native-inputs
       (list pkg-config))
      (propagated-inputs
       ;; Essas duas bibliotecas estão em 'Requires.private' em libgit2.pc.
       (list openssl zlib))
      (home-page "https://libgit2.github.com/")
      (synopsis "Biblioteca que fornece métodos básicos do Git")
      (description
       "Libgit2 é uma implementação C pura e portátil dos métodos principais do Git
fornecida como uma biblioteca vinculável reentrante com uma API sólida, permitindo que você
escreva aplicativos Git personalizados de velocidade nativa em qualquer linguagem com vinculações.")
      ;; GPLv2 com exceção de vinculação
      (license license:gpl2))))

git clone https://github.com/libgit2/libgit2/
cd libgit2
git checkout v0.26.6
guix hash -rx .

#:make-flags (list (string-append "prefix=" (assoc-ref %outputs "out"))
                   "CC=gcc")

$ make CC=gcc prefix=/gnu/store/...-<out>

#:configure-flags '("-DUSE_SHA1DC=ON")

(define %standard-phases
  ;; Fases de construção padrão, como uma lista de pares de símbolos/procedimentos.
  (let-syntax ((phases (syntax-rules ()
                         ((_ p ...) `((p . ,p) ...)))))
    (phases set-SOURCE-DATE-EPOCH set-paths install-locale unpack
            bootstrap
            patch-usr-bin-file
            patch-source-shebangs configure patch-generated-file-shebangs
            build check install
            patch-shebangs strip
            validate-runpath
            validate-documentation-location
            delete-info-dir-file
            patch-dot-desktop-files
            install-license-files
            reset-gzip-timestamps
            compress-documentation)))

(add-to-load-path "/path/to/guix/checkout")
,use (guix build gnu-build-system)
(map first %standard-phases)
⇒ (set-SOURCE-DATE-EPOCH set-paths install-locale unpack bootstrap patch-usr-bin-file patch-source-shebangs configure patch-generated-file-shebangs build check install patch-shebangs strip validate-runpath validate-documentation-location delete-info-dir-file patch-dot-desktop-files install-license-files reset-gzip-timestamps compress-documentation)

(define* (unpack #:key source #:allow-other-keys)
  "Descompacte SOURCE no diretório de trabalho e altere o diretório dentro do
source. Quando SOURCE for um diretório, copie-o em um subdiretório do atual
diretório de trabalho."
  (if (file-is-directory? source)
      (begin
        (mkdir "source")
        (chdir "source")

        ;; Preservar carimbos de data/hora (definidos para a Época) na
        ;; árvore copiada para que as coisas funcionem de forma
        ;; determinística.
        (copy-recursively source "."
                          #:keep-mtime? #true))
      (begin
        (if (string-suffix? ".zip" source)
            (invoke "unzip" source)
            (invoke "tar" "xvf" source))
        (chdir (first-subdirectory "."))))
  #true)

(lambda* (#:key inputs outputs #:allow-other-keys)
  (let ((bash-directory (assoc-ref inputs "bash"))
        (output-directory (assoc-ref outputs "out"))
        (doc-directory (assoc-ref outputs "doc")))
    ;; ...
    #true))

$ guix import cran --recursive walrus

(define-public r-mc2d
    ; ...
    (license gpl2+)))

(define-public r-jmvcore
    ; ...
    (license gpl2+)))

(define-public r-wrs2
    ; ...
    (license gpl3)))

(define-public r-walrus
  (package
    (name "r-walrus")
    (version "1.0.3")
    (source
      (origin
        (method url-fetch)
        (uri (cran-uri "walrus" version))
        (sha256
          (base32
            "1nk2glcvy4hyksl5ipq2mz8jy4fss90hx6cq98m3w96kzjni6jjj"))))
    (build-system r-build-system)
    (propagated-inputs
      (list r-ggplot2 r-jmvcore r-r6 r-wrs2))
    (home-page "https://github.com/jamovi/walrus")
    (synopsis "Métodos Estatísticos Robustos")
    (description
      "Este pacote fornece uma caixa de ferramentas de testes estatísticos robustos
comuns, incluindo descritivos robustos, testes t robustos e ANOVA robusto.
Ele também está disponível como um módulo para 'jamovi' (veja
<https://www.jamovi.org> para mais informações). O Walrus é baseado no
pacote WRS2 de Patrick Mair, que por sua vez é baseado nos scripts e
trabalho de Rand Wilcox. Essas análises são descritas em profundidade no livro
'Introdução à Estimativa Robusta e Teste de Hipóteses'.")
    (license gpl3)))

$ guix refresh hello

$ guix refresh hello --update

(define-public adwaita-icon-theme
  (package (inherit gnome-icon-theme)
    (name "adwaita-icon-theme")
    (version "3.26.1")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnome/sources/" name "/"
                                  (version-major+minor version) "/"
                                  name "-" version ".tar.xz"))
              (sha256
               (base32
                "17fpahgh5dyckgz7rwqvzgnhx53cx9kr2xw0szprc6bnqy977fi8"))))
    (native-inputs (list `(,gtk+ "bin")))))

3.1 Login automático em um TTY específico

Embora o manual do Guix explique o login automático de um usuário para todas TTYs (veja auto-login to TTY em Manual de Referência do GNU Guix), alguns podem preferir uma situação em que um usuário está logado em um TTY com os outros TTYs configurados para fazer login com usuários diferentes ou com nenhum. Observe que é possível fazer login automático de um usuário em qualquer TTY, mas geralmente é aconselhável evitar tty1, que, por padrão, é usado para registrar avisos e erros.

Aqui está como se pode configurar o login automático para um usuário em um tty:

(define (auto-login-to-tty config tty user)
  (if (string=? tty (mingetty-configuration-tty config))
        (mingetty-configuration
         (inherit config)
         (auto-login user))
        config))

(define %my-services
  (modify-services %base-services
    ;; …
    (mingetty-service-type config =>
                           (auto-login-to-tty
                            config "tty3" "alice"))))

(operating-system
  ;; …
  (services %my-services))

Pode-se também compose (veja ‘Higher-Order Functions’ em guile, Manual de referência do GNU Guile) auto-login-to-tty para fazer login de vários usuários em vários ttys.

Finalmente, aqui está uma nota de cautela. Configurar o login automático em um TTY significa que qualquer pessoa pode ligar seu computador e executar comandos como seu usuário normal. No entanto, se você tiver uma partição raiz criptografada e, portanto, já precisar inserir uma senha quando o sistema inicializar, o login automático pode ser uma opção conveniente.

3.2 Customizando o Kernel

Guix é, em sua essência, uma distribuição baseada em código-fonte com substitutos (veja Substitutos em Manual de Referência do GNU Guix) e, como tal, construir pacotes a partir de seu código-fonte é uma parte esperada das instalações e atualizações regulares de pacotes. Dado este ponto de partida, faz sentido que sejam feitos esforços para reduzir a quantidade de tempo gasto na compilação de pacotes, e as recentes mudanças e atualizações na construção e distribuição de substitutos continuam a ser um tópico de discussão dentro do Guix.

O kernel, embora não exija uma superabundância de RAM para ser construído, leva muito tempo em uma máquina média. A configuração oficial do kernel, como é o caso de muitas distribuições GNU/Linux, erra pelo lado da inclusão, e é isso que realmente faz com que a construção demore tanto tempo quando o kernel é compilado a partir do código-fonte.

O kernel do Linux, entretanto, também pode ser descrito apenas como um pacote antigo normal e, como tal, pode ser personalizado como qualquer outro pacote. O procedimento é um pouco diferente, embora isso se deva principalmente à natureza de como a definição do pacote é escrita.

A definição do pacote do kernel linux-libre é na verdade um procedimento que cria um pacote.

(define* (make-linux-libre* versão gnu-revision fonte sistemas-suportados
                            #:key
                            (extra-version #f)
                            ;; Uma função que pega um arch e uma variante.
                            ;; Veja kernel-config para um exemplo.
                            (configuration-file #f)
                            (defconfig "defconfig")
                            (extra-options %default-extra-linux-options))
  ...)

O pacote linux-libre atual é para a série 5.15.x e é declarado assim:

(define-public linux-libre-5.15
  (make-linux-libre* linux-libre-5.15-version
                     linux-libre-5.15-gnu-revision
                     linux-libre-5.15-source
                     '("x86_64-linux" "i686-linux" "armhf-linux"
                       "aarch64-linux" "riscv64-linux")
                     #:configuration-file kernel-config))

Quaisquer chaves às quais não sejam atribuídos valores herdam seu valor padrão da definição make-linux-libre. Ao comparar os dois trechos acima, observe o comentário do código que se refere a #:configuration-file. Por causa disso, não é realmente fácil incluir uma configuração de kernel personalizada na definição, mas não se preocupe, existem outras maneiras de trabalhar com o que temos.

Existem duas maneiras de criar um kernel com uma configuração de kernel personalizada. A primeira é fornecer um arquivo .config padrão durante o processo de construção, incluindo um arquivo .config real como uma entrada nativa para nosso kernel personalizado. A seguir está um trecho da fase 'configure personalizada da definição do pacote make-linux-libre:

(let ((build  (assoc-ref %standard-phases 'build))
      (config (assoc-ref (or native-inputs inputs) "kconfig")))

  ;; Use um arquivo de configuração de kernel personalizado ou um padrão
  ;; configuration file.
  (if config
      (begin
        (copy-file config ".config")
        (chmod ".config" #o666))
      (invoke "make" ,defconfig)))

Abaixo está um exemplo de pacote de kernel. O pacote linux-libre não é nada especial e pode ser herdado e ter seus campos substituídos como qualquer outro pacote:

(define-public linux-libre/E2140
  (package
    (inherit linux-libre)
    (native-inputs
     `(("kconfig" ,(local-file "E2140.config"))
      ,@(alist-delete "kconfig"
                      (package-native-inputs linux-libre))))))

No mesmo diretório do arquivo que define linux-libre-E2140 está um arquivo chamado E2140.config, que é um arquivo de configuração real do kernel. A palavra-chave defconfig de make-linux-libre é deixada em branco aqui, então a única configuração do kernel no pacote é aquela que foi incluída no campo native-inputs.

A segunda maneira de criar um kernel customizado é passar um novo valor para a palavra-chave extra-options do procedimento make-linux-libre. A palavra-chave extra-options funciona com outra função definida logo abaixo dela:

(define %default-extra-linux-options
  `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
   ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #true)
   ;; Modules required for initrd:
   ("CONFIG_NET_9P" . m)
   ("CONFIG_NET_9P_VIRTIO" . m)
   ("CONFIG_VIRTIO_BLK" . m)
   ("CONFIG_VIRTIO_NET" . m)
   ("CONFIG_VIRTIO_PCI" . m)
   ("CONFIG_VIRTIO_BALLOON" . m)
   ("CONFIG_VIRTIO_MMIO" . m)
   ("CONFIG_FUSE_FS" . m)
   ("CONFIG_CIFS" . m)
   ("CONFIG_9P_FS" . m)))

(define (config->string options)
  (string-join (map (match-lambda
                      ((option . 'm)
                       (string-append option "=m"))
                      ((option . #true)
                       (string-append option "=y"))
                      ((option . #false)
                       (string-append option "=n")))
                    options)
               "\n"))

E no script de configuração personalizado do pacote ‘make-linux-libre‘:

;; A anexação funciona mesmo quando a opção não estava no arquivo.
;; A última prevalece se duplicada.
(let ((port (open-file ".config" "a"))
      (extra-configuration ,(config->string extra-options)))
  (display extra-configuration port)
  (close-port port))

(invoke "make" "oldconfig")

Portanto, ao não fornecer um arquivo de configuração, o .config começa em branco e então escrevemos nele a coleção de flags que desejamos. Aqui está outro kernel personalizado:

(define %macbook41-full-config
  (append %macbook41-config-options
          %file-systems
          %efi-support
          %emulation
          (@@ (gnu packages linux) %default-extra-linux-options)))

(define-public linux-libre-macbook41
  ;; XXX: Access the internal 'make-linux-libre*' procedure, which is
  ;; private and unexported, and is liable to change in the future.
  ((@@ (gnu packages linux) make-linux-libre*)
   (@@ (gnu packages linux) linux-libre-version)
   (@@ (gnu packages linux) linux-libre-gnu-revision)
   (@@ (gnu packages linux) linux-libre-source)
   '("x86_64-linux")
   #:extra-version "macbook41"
   #:extra-options %macbook41-config-options))

No exemplo acima, %file-systems é uma coleção de sinalizadores que habilitam suporte a diferentes sistemas de arquivos, %efi-support habilita suporte a EFI e %emulation habilita uma máquina x86_64-linux para atuar no modo de 32 bits também. O procedimento default-extra-linux-options é o definido acima, que teve que ser usado para evitar a perda das opções de configuração padrão da palavra-chave extra-options.

Tudo isso parece viável, mas como saber quais módulos são necessários para um sistema específico? Dois lugares que podem ser úteis para tentar responder a esta pergunta são o Gentoo Handbook e o documentação do próprio kernel. Pela documentação do kernel, parece que make localmodconfig é o comando que queremos.

Para realmente executar make localmodconfig primeiro precisamos obter e descompactar o código-fonte do kernel:

tar xf $(guix build linux-libre --source)

Uma vez dentro do diretório que contém o código-fonte, execute touch .config para criar um .config inicial e vazio para começar. make localmodconfig funciona vendo o que você já tem em .config e informando o que está faltando. Se o arquivo estiver em branco, você está perdendo tudo. O próximo passo é executar:

guix shell -D linux-libre -- make localmodconfig

e observe a saída. Observe que o arquivo .config ainda está vazio. A saída geralmente contém dois tipos de avisos. O primeiro começa com "WARNING" e pode ser ignorado no nosso caso. A segunda leitura:

module pcspkr did not have configs CONFIG_INPUT_PCSPKR

Para cada uma dessas linhas, copie a parte CONFIG_XXXX_XXXX para .config no diretório e anexe =m, para que no final fique assim:

CONFIG_INPUT_PCSPKR=m
CONFIG_VIRTIO=m

Após copiar todas as opções de configuração, execute make localmodconfig novamente para ter certeza de que você não tem nenhuma saída começando com “module”. Depois de todos esses módulos específicos da máquina, restam mais alguns que também são necessários. CONFIG_MODULES é necessário para que você possa construir e carregar módulos separadamente e não ter tudo embutido no kernel. CONFIG_BLK_DEV_SD é necessário para leitura de discos rígidos. É possível que existam outros módulos dos quais você precisará.

Este post não pretende ser um guia para configurar seu próprio kernel, portanto, se você decidir construir um kernel personalizado, você terá que procurar outros guias para criar um kernel adequado às suas necessidades.

A segunda maneira de definir a configuração do kernel faz mais uso dos recursos do Guix e permite compartilhar segmentos de configuração entre diferentes kernels. Por exemplo, todas as máquinas que usam EFI para inicializar possuem vários sinalizadores de configuração EFI necessários. É provável que todos os kernels compartilhem uma lista de sistemas de arquivos para suporte. Ao usar variáveis, é mais fácil ver rapidamente quais recursos estão habilitados e garantir que você não tenha recursos em um kernel, mas ausentes em outro.

No entanto, não foi discutido o initrd do Guix e sua personalização. É provável que você precise modificar o initrd em uma máquina usando um kernel customizado, já que certos módulos que devem ser compilados podem não estar disponíveis para inclusão no initrd.

3.3 API de imagem do sistema Guix

Historicamente, o Sistema Guix é centrado em uma estrutura operating-system. Esta estrutura contém vários campos que vão desde o gerenciador de boot e a declaração do kernel até os serviços a serem instalados.

Dependendo da máquina de destino, que pode ir de uma máquina x86_64 padrão a um pequeno computador de placa única ARM, como o Pine64, as restrições de imagem podem variar muito. Os fabricantes de hardware imporão diferentes formatos de imagem com vários tamanhos de partição e deslocamentos.

Para criar imagens adequadas para todas essas máquinas, é necessária uma nova abstração: esse é o objetivo do registro image. Este registro contém todas as informações necessárias para ser transformada em uma imagem autônoma, que pode ser inicializada diretamente em qualquer máquina de destino.

(define-record-type* <image>
  image make-image
  image?
  (name               image-name ;symbol
                      (default #f))
  (format             image-format) ;symbol
  (target             image-target
                      (default #f))
  (size               image-size  ;size in bytes as integer
                      (default 'guess))
  (operating-system   image-operating-system  ;<operating-system>
                      (default #f))
  (partitions         image-partitions ;list of <partition>
                      (default '()))
  (compression?       image-compression? ;boolean
                      (default #t))
  (volatile-root?     image-volatile-root? ;boolean
                      (default #t))
  (substitutable?     image-substitutable? ;boolean
                      (default #t)))

Este registro contém o sistema operacional a ser instanciado. O campo format define o tipo de imagem e pode ser efi-raw, qcow2 ou iso9660 por exemplo. No futuro, poderá ser estendido para docker ou outros tipos de imagem.

Um novo diretório nas fontes do Guix é dedicado à definição de imagens. Por enquanto existem quatro arquivos:

• gnu/system/images/hurd.scm
• gnu/system/images/pine64.scm
• gnu/system/images/novena.scm
• gnu/system/images/pinebook-pro.scm

Vamos dar uma olhada em pine64.scm. Ele contém a variável pine64-barebones-os que é uma definição mínima de um sistema operacional dedicado à placa Pine A64 LTS.

(define pine64-barebones-os
  (operating-system
   (host-name "vignemale")
   (timezone "Europe/Paris")
   (locale "en_US.utf8")
   (bootloader (bootloader-configuration
                (bootloader u-boot-pine64-lts-bootloader)
                (targets '("/dev/vda"))))
   (initrd-modules '())
   (kernel linux-libre-arm64-generic)
   (file-systems (cons (file-system
                        (device (file-system-label "my-root"))
                        (mount-point "/")
                        (type "ext4"))
                       %base-file-systems))
   (services (cons (service agetty-service-type
                            (agetty-configuration
                             (extra-options '("-L")) ; sem detecção de portadora
                             (baud-rate "115200")
                             (term "vt100")
                             (tty "ttyS0")))
                   %base-services))))

Os campos kernel e bootloader apontam para pacotes dedicados a esta placa.

Logo abaixo, a variável pine64-image-type também está definida.

(define pine64-image-type
  (image-type
   (name 'pine64-raw)
   (constructor (cut image-with-os arm64-disk-image <>))))

Ele está usando um registro do qual ainda não falamos, o registro image-type, definido desta forma:

(define-record-type* <image-type>
  image-type make-image-type
  image-type?
  (name           image-type-name) ;symbol
  (constructor    image-type-constructor)) ;<operating-system> -> <image>

O objetivo principal deste registro é associar um nome a um procedimento que transforma um isso é necessário, vamos dar uma olhada no comando que produz uma imagem de um arquivo de configuração operating-system:

guix system image my-os.scm

Este comando espera uma configuração operating-system mas como devemos indicar que queremos uma imagem direcionada a uma placa Pine64? Precisamos fornecer uma informação extra, o image-type, passando o sinalizador --image-type ou -t, desta forma:

guix system image --image-type=pine64-raw my-os.scm

Este parâmetro image-type aponta para o pine64-image-type definido acima. Portanto, ao operating-system declarado em my-os.scm será aplicado o procedimento (cut image-with-os arm64-disk-image <>) para transformá-lo em um imagem.

A imagem resultante se parece com:

(image
 (format 'disk-image)
 (target "aarch64-linux-gnu")
 (operating-system my-os)
 (partitions
  (list (partition
         (inherit root-partition)
         (offset root-offset)))))

que é a agregação do operating-system definido em my-os.scm ao registro arm64-disk-image.

Mas chega de loucura do Scheme. O que essa API de imagem traz para o usuário do Guix?

Pode-se executar:

mathieu@cervin:~$ guix system --list-image-types
Os tipos de imagem disponíveis são:

   - unmatched-raw
   - rock64-raw
   - pinebook-pro-raw
   - pine64-raw
   - novena-raw
   - hurd-raw
   - hurd-qcow2
   - qcow2
   - iso9660
   - uncompressed-iso9660
   - tarball
   - efi-raw
   - mbr-raw
   - docker
   - wsl2
   - raw-with-offset
   - efi32-raw

e escrevendo um arquivo operating-system baseado em pine64-barebones-os, você pode personalizar sua imagem de acordo com suas preferências em um arquivo (my-pine-os.scm) como este :

(use-modules (gnu services linux)
             (gnu system images pine64))

(let ((base-os pine64-barebones-os))
  (operating-system
    (inherit base-os)
    (timezone "America/Indiana/Indianapolis")
    (services
     (cons
      (service earlyoom-service-type
               (earlyoom-configuration
                (prefer-regexp "icecat|chromium")))
      (operating-system-user-services base-os)))))

execute:

guix system image --image-type=pine64-raw my-pine-os.scm

ou,

guix system image --image-type=hurd-raw my-hurd-os.scm

para obter uma imagem que pode ser gravada diretamente em um disco rígido e inicializada.

Sem alterar nada em my-hurd-os.scm, chamando:

guix system image --image-type=hurd-qcow2 my-hurd-os.scm

em vez disso, produzirá uma imagem Hurd QEMU.

3.4 Usando chaves de segurança

O uso de chaves de segurança pode melhorar sua segurança, fornecendo uma segunda fonte de autenticação que não pode ser facilmente roubada ou copiada, pelo menos para um adversário remoto (algo que você possui), para o segredo principal (uma senha - algo que você conhece). , reduzindo o risco de falsificação de identidade.

O exemplo de configuração detalhado abaixo mostra qual configuração mínima precisa ser feita em seu sistema Guix para permitir o uso de uma chave de segurança Yubico. Espera-se que a configuração também possa ser útil para outras chaves de segurança, com pequenos ajustes.

• Configuração para uso como autenticador de dois fatores (2FA)
• Desativando a geração de código OTP para um Yubikey
• Exigindo que um Yubikey abra um banco de dados KeePassXC

(use-package-modules ... security-token ...)
...
(operating-system
 ...
 (users (cons* (user-account
               (name "your-user")
               (group "users")
               (supplementary-groups
		'("wheel" "netdev" "audio" "video"
                  "plugdev"))           ;<- grupo de sistema adicionado
               (home-directory "/home/your-user"))
              %base-user-accounts))
 ...
 (services
  (cons*
   ...
   (udev-rules-service 'fido2 libfido2 #:groups '("plugdev")))))

guix shell ungoogled-chromium -- chromium chrome://settings/securityKeys

guix shell python-yubikey-manager -- ykman config usb --force --disable OTP

(use-package-modules ... security-token ...)
...
(operating-system
 ...
 (services
  (cons*
   ...
   (udev-rules-service 'yubikey yubikey-personalization))))

guix shell yubikey-manager-qt -- ykman-gui

3.5 Trabalho mcron de DNS dinâmico

Se o seu ISP (Internet Service Provider) fornece apenas endereços IP dinâmicos, pode ser útil configurar um serviço DNS (Domain Name System) dinâmico (também conhecido como DDNS (Dynamic DNS)) para associar um nome de host estático para um endereço IP público, mas dinâmico. Existem vários serviços que podem ser usados para isso; no job mcron a seguir, DuckDNS é usado. Também deve funcionar com outros serviços DNS dinâmicos que oferecem uma interface semelhante para atualizar o endereço IP.

O Job mcron é fornecido abaixo, onde DOMAIN deve ser substituído pelo seu próprio prefixo de domínio, e o token fornecido pelo DuckDNS é associado a DOMAIN e adicionado ao arquivo /etc/duckdns/DOMAIN arquivo .token.

(define duckdns-job
  ;; Atualize o IP do domínio pessoal a cada 5 minutos.
  #~(job '(next-minute (range 0 60 5))
	 #$(program-file
            "duckdns-update"
            (with-extensions (list guile-gnutls) ;required by (web client)
              #~(begin
                  (use-modules (ice-9 textual-ports)
                               (web client))
                  (let ((token (string-trim-both
                                (call-with-input-file "/etc/duckdns/DOMAIN.token"
                                  get-string-all)))
                        (query-template (string-append "https://www.duckdns.org/"
                                                       "update?domains=DOMAIN"
                                                       "&token=~a&ip=")))
                    (http-get (format #f query-template token))))))
         "duckdns-update"
         #:user "nobody"))

O Job então precisa ser adicionado à lista de trabalhos mcron do seu sistema, usando algo como:

(operating-system
 (services
  (cons* (service mcron-service-type
           (mcron-configuration
             (jobs (list duckdns-job ...))))
         ...
         %base-services)))

3.6 Conectando-se à VPN Wireguard

Para se conectar a um servidor VPN Wireguard, você precisa que o módulo do kernel esteja carregado na memória e um pacote que forneça ferramentas de rede que o suportem (por exemplo, wireguard-tools ou network-manager).

Aqui está um exemplo de configuração para Linux-Libre versão menor que 5.6, onde o módulo está fora da árvore e precisa ser carregado manualmente — as seguintes revisões do kernel o possuem integrado e, portanto, não precisam de tal configuração:

(use-modules (gnu))
(use-service-modules desktop)
(use-package-modules vpn)

(operating-system
  ;; …
  (services (cons (simple-service 'wireguard-module
                                  kernel-module-loader-service-type
                                  '("wireguard"))
                  %desktop-services))
  (packages (cons wireguard-tools %base-packages))
  (kernel-loadable-modules (list wireguard-linux-compat)))

Após reconfigurar e reiniciar seu sistema, você pode usar as ferramentas Wireguard ou NetworkManager para conectar-se a um servidor VPN.

• Usando ferramentas Wireguard
• Usando o NetworkManager

# nmcli connection import type wireguard file wg0.conf
Connection 'wg0' (edbee261-aa5a-42db-b032-6c7757c60fde) successfully added

$ nmcli connection up wg0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)

# nmcli connection modify wg0 connection.autoconnect no

3.7 Customizando um Gerenciador de Janelas

• StumpWM
• Bloqueio de sessão

(use-modules (gnu))
(use-package-modules wm)

(operating-system
  ;; …
  (packages (append (list sbcl stumpwm `(,stumpwm "lib"))
                    %base-packages)))

(use-modules (gnu))
(use-package-modules fonts wm)

(operating-system
  ;; …
  (packages (append (list sbcl stumpwm `(,stumpwm "lib"))
                    sbcl-ttf-fonts font-dejavu %base-packages)))

(require :ttf-fonts)
(setf xft:*font-dirs* '("/run/current-system/profile/share/fonts/"))
(setf clx-truetype:+font-cache-filename+ (concat (getenv "HOME")
                                                 "/.fonts/font-cache.sexp"))
(xft:cache-fonts)
(set-font (make-instance 'xft:font :family "DejaVu Sans Mono"
                                   :subfamily "Book" :size 11))

xss-lock -- slock &
exec stumpwm

(service screen-locker-service-type
         (screen-locker-configuration
          (name "slock")
          (program (file-append slock "/bin/slock"))))

3.8 Executando Guix em um Servidor Linode

Para executar o Guix num servidor hospedado por Linode, comece com um servidor Debian recomendado. Recomendamos usar a distribuição padrão como forma de inicializar o Guix. Crie suas chaves SSH.

ssh-keygen

Certifique-se de adicionar sua chave SSH para facilitar o login no servidor remoto. Isto é feito trivialmente através da interface gráfica do Linode para adicionar chaves SSH. Vá para o seu perfil e clique em adicionar chave SSH. Copie nele a saída de:

cat ~/.ssh/<username>_rsa.pub

Desligue o Linode.

Na aba Armazenamento do Linode, redimensione o disco Debian para ser menor. Recomenda-se 30 GB de espaço livre. Em seguida, clique em "Adicionar um disco" e preencha o formulário com o seguinte:

• Label: "Guix"
• Filesystem: ext4
• Defina-o para o tamanho restante

Na aba Configurações, pressione “Editar” no perfil Debian padrão. Em "Bloquear atribuição de dispositivo", clique em "Adicionar um dispositivo". Deve ser /dev/sdc e você pode selecionar o disco "Guix". Salvar alterações.

Agora "Adicionar uma configuração", com o seguinte:

• Etiqueta: Guix
• Kernel:GRUB 2 (está na parte inferior! Esta etapa é IMPORTANTE!)
• Bloquear atribuição de dispositivo:
• /dev/sda: Guix
• /dev/sdb: swap
• Dispositivo raiz: /dev/sda
• Desligue todos os auxiliares de sistema de arquivos/inicialização

Agora ligue-o novamente, inicializando com a configuração do Debian. Quando estiver em execução, faça ssh para o seu servidor via ssh root@<your-server-IP-here>. (Você pode encontrar o endereço IP do seu servidor na seção Resumo do Linode.) Agora você pode executar as etapas "instalar o guix de veja Instalação de binários em GNU Guix":

sudo apt-get install gpg
wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 -qO - | gpg --import -
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
./guix-install.sh
guix pull

Agora é hora de escrever uma configuração para o servidor. As principais informações estão abaixo. Salve o arquivo resultante como guix-config.scm.

(use-modules (gnu)
             (guix modules))
(use-service-modules networking
                     ssh)
(use-package-modules admin
                     package-management
                     ssh
                     tls)

(operating-system
  (host-name "my-server")
  (timezone "America/New_York")
  (locale "en_US.UTF-8")
  ;; Este código bobo irá gerar o grub.cfg
  ;; sem instalar o bootloader grub no disco.
  (bootloader (bootloader-configuration
               (bootloader
                (bootloader
                 (inherit grub-bootloader)
                 (installer #~(const #true))))))
  (file-systems (cons (file-system
                        (device "/dev/sda")
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))


  (swap-devices (list "/dev/sdb"))


  (initrd-modules (cons "virtio_scsi" ; Necessário para encontrar o disco
                        %base-initrd-modules))

  (users (cons (user-account
                (name "janedoe")
                (group "users")
                ;; Adicionando a conta ao grupo "wheel"
                ;; o torna um super-usuário
                (supplementary-groups '("wheel"))
                (home-directory "/home/janedoe"))
               %base-user-accounts))

  (packages (cons* openssh-sans-x
                   %base-packages))

  (services (cons*
             (service dhcp-client-service-type)
             (service openssh-service-type
                      (openssh-configuration
                       (openssh openssh-sans-x)
                       (password-authentication? #false)
                       (authorized-keys
                        `(("janedoe" ,(local-file "janedoe_rsa.pub"))
                          ("root" ,(local-file "janedoe_rsa.pub"))))))
             %base-services)))

Substitua os seguintes campos na configuração acima:

(host-name "my-server"); substitua pelo nome do seu servidor
; se você escolheu um servidor linode fora dos EUA, então
; use tzselect para encontrar uma string de fuso horário correta
(timezone "America/New_York"); se necessário, substitua o fuso horário
(name "janedoe"); substitua pelo seu nome de usuário
("janedoe" ,(local-file "janedoe_rsa.pub")) ; substitua pela sua chave ssh
("root" ,(local-file "janedoe_rsa.pub")) ; substitua pela sua chave ssh

A última linha no exemplo acima permite que você faça login no servidor como root e defina a senha root inicial (veja a nota no final desta receita sobre login root). Depois de fazer isso, você pode excluir essa linha da sua configuração e reconfigurar para evitar o login root.

Copie sua chave pública ssh (por exemplo: ~/.ssh/id_rsa.pub) como <seu-nome-de-usuário-aqui>_rsa.pub e coloque guix-config.scm no mesmo diretório. Em um novo terminal execute estes comandos.

sftp root@<endereço IP do servidor remoto>
put /caminho/para/arquivos/<nome de usuário>_rsa.pub .
put /caminho/para/arquivos/guix-config.scm .

No seu primeiro terminal, monte o drive guix:

mkdir /mnt/guix
mount /dev/sdc /mnt/guix

Devido à forma como configuramos a seção bootloader do guix-config.scm, apenas o arquivo de configuração grub será instalado. Então, precisamos copiar algumas das outras coisas do GRUB já instaladas no sistema Debian:

mkdir -p /mnt/guix/boot/grub
cp -r /boot/grub/* /mnt/guix/boot/grub/

Agora inicialize a instalação do Guix:

guix system init guix-config.scm /mnt/guix

Ok, desligue-o! Agora, no console Linode, selecione boot e selecione "Guix".

Depois de inicializar, você poderá fazer login via SSH! (A configuração do servidor terá mudado.) Você pode encontrar um erro como:

$ ssh root@<server ip address>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@     WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:0B+wp33w57AnKQuHCvQP0+ZdKaqYrI/kyU7CfVbS7R4.
Please contact your system administrator.
Add correct host key in /home/joshua/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/joshua/.ssh/known_hosts:3
ECDSA host key for 198.58.98.76 has changed and you have requested strict checking.
Host key verification failed.

Exclua o arquivo ~/.ssh/known_hosts ou exclua a linha incorreta começando com o endereço IP do seu servidor.

Certifique-se de definir sua senha e a senha do root.

ssh root@<endereço IP remoto>
passwd; para a senha root
passwd <nome de usuário>; para a senha do usuário

Talvez você não consiga executar os comandos acima neste momento. Se você tiver problemas para fazer login remotamente em sua caixa linode via SSH, então você ainda pode precisar definir sua senha root e de usuário inicialmente clicando na opção “Launch Console” em seu linode. Escolha “Glish” em vez de “Weblish”. Agora você deve conseguir fazer o ssh na máquina.

Viva! Neste ponto você pode desligar o servidor, excluir o disco Debian e redimensionar o Guix para o restante do tamanho. Parabéns!

A propósito, se você salvá-lo como uma imagem de disco neste momento, será fácil criar novas imagens Guix! Pode ser necessário reduzir o tamanho da imagem Guix para 6144 MB para salvá-la como uma imagem. Então você pode redimensioná-lo novamente para o tamanho máximo.

3.9 Executando Guix em um servidor Kimsufi

Para executar o Guix em um servidor hospedado por Kimsufi, clique na guia netboot, selecione Rescue64-pro e reinicie.

A OVH enviar-lhe-á por e-mail as credenciais necessárias para efetuar o ssh num sistema Debian.

Agora você pode executar as etapas "instalar guix de veja Instalação de binários em GNU Guix":

wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
./guix-install.sh
guix pull

Particione as unidades e formate-as, primeiro interrompa a matriz raid:

mdadm --stop /dev/md127
mdadm --zero-superblock /dev/sda2 /dev/sdb2

Em seguida, limpe os discos e configure as partições, criaremos uma matriz RAID 1.

wipefs -a /dev/sda
wipefs -a /dev/sdb

parted /dev/sda --align=opt -s -m -- mklabel gpt
parted /dev/sda --align=opt -s -m -- \
 mkpart bios_grub 1049kb 512MiB \
 set 1 bios_grub on
parted /dev/sda --align=opt -s -m -- \
 mkpart primary 512MiB -512MiB
 set 2 raid on
parted /dev/sda --align=opt -s -m -- mkpart primary linux-swap 512MiB 100%

parted /dev/sdb --align=opt -s -m -- mklabel gpt
parted /dev/sdb --align=opt -s -m -- \
     mkpart bios_grub 1049kb 512MiB \
     set 1 bios_grub on
parted /dev/sdb --align=opt -s -m -- \
     mkpart primary 512MiB -512MiB \
     set 2 raid on
parted /dev/sdb --align=opt -s -m -- mkpart primary linux-swap 512MiB 100%

Crie a matriz:

mdadm --create /dev/md127 --level=1 --raid-disks=2 \
  --metadata=0.90 /dev/sda2 /dev/sdb2

Agora crie sistemas de arquivos nas partições relevantes, primeiro as partições de inicialização:

mkfs.ext4  /dev/sda1
mkfs.ext4  /dev/sdb1

Então a partição raiz:

mkfs.ext4 /dev/md127

Inicialize as partições swap:

mkswap /dev/sda3
swapon /dev/sda3
mkswap /dev/sdb3
swapon /dev/sdb3

Monte a unidade guix:

mkdir /mnt/guix
mount /dev/md127 /mnt/guix

Agora é hora de escrever um arquivo os.scm de declaração do sistema operacional; aqui está uma amostra:

(use-modules (gnu) (guix))
(use-service-modules networking ssh vpn virtualization sysctl admin mcron)
(use-package-modules ssh tls tmux vpn virtualization)

(operating-system
  (host-name "kimsufi")

  (bootloader (bootloader-configuration
	       (bootloader grub-bootloader)
	       (targets (list "/dev/sda" "/dev/sdb"))
	       (terminal-outputs '(console))))

  ;; Adicionar um módulo de kernel para RAID-1 (conhecido como. "espelho").
  (initrd-modules (cons* "raid1"  %base-initrd-modules))

  (mapped-devices
   (list (mapped-device
          (source (list "/dev/sda2" "/dev/sdb2"))
          (target "/dev/md127")
          (type raid-device-mapping))))

  (swap-devices
   (list (swap-space
          (target "/dev/sda3"))
         (swap-space
          (target "/dev/sdb3"))))

  (issue
   ;;Conteúdo padrão para /etc/issue.
   "\
Este é o sistema GNU em Kimsufi. Bem-vindo.\n")

  (file-systems (cons* (file-system
		         (mount-point "/")
		         (device "/dev/md127")
		         (type "ext4")
		         (dependencies mapped-devices))
		       %base-file-systems))

  (users (cons (user-account
	        (name "guix")
	        (comment "guix")
	        (group "users")
	        (supplementary-groups '("wheel"))
	        (home-directory "/home/guix"))
	       %base-user-accounts))

  (sudoers-file
   (plain-file "sudoers" "\
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
guix ALL=(ALL) NOPASSWD:ALL\n"))

  ;; Pacotes instalados globalmente.
  (packages (cons* tmux nss-certs gnutls wireguard-tools %base-packages))
  (services
   (cons*
    (service static-networking-service-type
	     (list (static-networking
		    (addresses (list (network-address
				      (device "enp3s0")
				      (value "server-ip-address/24"))))
		    (routes (list (network-route
				   (destination "default")
				   (gateway "server-gateway"))))
		    (name-servers '("213.186.33.99")))))

    (service unattended-upgrade-service-type)

    (service openssh-service-type
	     (openssh-configuration
	      (openssh openssh-sans-x)
	      (permit-root-login #f)
	      (authorized-keys
	       `(("guix" ,(plain-file "ssh-key-name.pub"
                                      "ssh-public-key-content"))))))
    (modify-services %base-services
      (sysctl-service-type
       config =>
       (sysctl-configuration
	(settings (append '(("net.ipv6.conf.all.autoconf" . "0")
			    ("net.ipv6.conf.all.accept_ra" . "0"))
			  %default-sysctl-settings))))))))

Não se esqueça de substituir as variáveis server-ip-address, server-gateway, ssh-key-name e ssh-public-key-content pelos seus próprias valores.

O gateway é o último IP utilizável em seu bloco, portanto, se você tiver um servidor com IP ‘37.187.79.10’, seu gateway será ‘37.187.79.254’.

Transfira o arquivo de declaração do sistema operacional os.scm para o servidor por meio dos comandos scp ou sftp.

Agora só falta instalar o Guix com guix system init e reiniciar.

No entanto, primeiro precisamos configurar um chroot, porque a partição raiz do sistema de recuperação é montada em uma partição aufs e se você tentar instalar o Guix ele falhará na etapa de instalação do GRUB reclamando do caminho canônico de "aufs".

Instale os pacotes que serão usados no chroot:

guix install bash-static parted util-linux-with-udev coreutils guix

Em seguida, execute o seguinte para criar os diretórios necessários para o chroot:

cd /mnt && \
mkdir -p bin etc gnu/store root/.guix-profile/ root/.config/guix/current \
  var/guix proc sys dev

Copie o host resolv.conf no chroot:

cp /etc/resolv.conf etc/

Monte os dispositivos de bloco, o armazém e seu banco de dados e a configuração atual do guix:

mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev
mount --rbind /var/guix/ var/guix/
mount --rbind /gnu/store gnu/store/
mount --rbind /root/.config/ root/.config/
mount --rbind /root/.guix-profile/bin/ bin
mount --rbind /root/.guix-profile root/.guix-profile/

Faça chroot em /mnt e instale o sistema:

chroot /mnt/ /bin/bash

guix system init /root/os.scm /guix

Por fim, na interface do usuário (IU) da web, altere ‘netboot’ para ‘boot to disk’ e reinicie (também na IU da web).

Aguarde alguns minutos e tente fazer ssh com ssh guix@endereço IP do servidor> -i caminho para sua chave ssh

Você deve ter um sistema Guix instalado e funcionando no Kimsufi; Parabéns!

3.10 Configurando uma montagem vinculada

Para vincular a montagem de um sistema de arquivos, é necessário primeiro configurar algumas definições antes da seção operating-system da definição do sistema. Neste exemplo, vincularemos a montagem de uma pasta de uma unidade de disco rígido a /tmp, para evitar desgaste no SSD primário, sem dedicar uma partição inteira para ser montada como /tmp.

Primeiro, a unidade de origem que hospeda a pasta que desejamos vincular a montagem deve ser definida, para que a montagem de ligação possa depender dela.

(define source-drive ;; "source-drive" pode ser nomeado como você quiser.
   (file-system
    (device (uuid "UUID vai aqui"))
    (mount-point "/path-to-spinning-disk-goes-here")
    (type "ext4"))) ;; Certifique-se de definir isso para o tipo apropriado para sua unidade.

A pasta de origem também deve ser definida, para que o guix saiba que não é um dispositivo de bloco normal, mas uma pasta.

;; "%source-directory" pode receber qualquer nome de variável válido.
(define (%source-directory) "/caminho_para_ o_disco_vai_aqui/tmp")

Finalmente, dentro da definição file-systems, devemos adicionar a própria montagem.

(file-systems (cons*

                ...<other drives omitted for clarity>...

                ;; Deve corresponder ao nome que você deu à unidade
                ;; de origem na definição anterior.
                source-drive

                (file-system
                 ;; Certifique-se de que "source-directory" corresponde
                 ;; à sua definição anterior.
                 (device (%source-directory))
                 (mount-point "/tmp")
                 ;; Estamos montando uma pasta, não uma partição, então
                 ;; esse tipo precisa ser "none"
                 (type "none")
                 (flags '(bind-mount))
                 ;; Certifique-se de que "source-drive" corresponde ao
                 ;; nome que você deu à variável para a unidade
                 (dependencies (list source-drive))
                 )

                 ...<outras unidades omitidas para maior clareza>...

                ))

3.11 Obtendo substitutos pelo Tor

O daemon Guix pode usar um proxy HTTP para obter substitutos, aqui estamos configurando-o para obtê-los via Tor.

Aviso: Nem todo o tráfego do daemon Guix passará pelo Tor! Somente HTTP/HTTPS será encaminhado ao proxy; As conexões FTP, o protocolo Git, SSH, etc. ainda passarão pela rede aberta. Novamente, esta configuração não é infalível, pois parte do seu tráfego não será roteado pelo Tor. Use-o por sua conta e risco.

Observe também que o procedimento descrito aqui se aplica apenas à substituição de pacotes. Ao atualizar sua distribuição guix com guix pull, você ainda precisará usar torsocks se quiser rotear a conexão para os servidores de repositório git do guix através do Tor.

O servidor substituto do Guix está disponível como um serviço Onion, se você quiser usá-lo para obter seus substitutos através do Tor, configure seu sistema da seguinte forma:

(use-modules (gnu))
(use-service-module base networking)

(operating-system
  …
  (services
    (cons
      (service tor-service-type
              (tor-configuration
                (config-file (plain-file "tor-config"
                                         "HTTPTunnelPort 127.0.0.1:9250"))))
      (modify-services %base-services
        (guix-service-type
          config => (guix-configuration
                      (inherit config)
                      ;; ci.guix.gnu.org's  Serviço onion
                      (substitute-urls
                       "https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion")
                      (http-proxy "http://localhost:9250")))))))

Isso manterá um processo tor em execução que fornece um túnel HTTP CONNECT que será usado por guix-daemon. O daemon pode usar outros protocolos além do HTTP(S) para obter recursos remotos. A solicitação usando esses protocolos não passará pelo Tor, pois estamos apenas configurando um túnel HTTP aqui. Observe que substitutes-urls está usando HTTPS e não HTTP ou não funcionará, isso é uma limitação do túnel do Tor; você pode querer usar privoxy para evitar tais limitações.

Se você não deseja sempre obter substitutos através do Tor, mas usá-lo apenas algumas vezes, pule o guix-configuration. Quando você deseja obter um substituto da execução do túnel Tor:

sudo herd set-http-proxy guix-daemon http://localhost:9250
guix build \
  --substitute-urls=https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion …

3.12 Configurando NGINX com Lua

O NGINX pode ser estendido com scripts Lua.

Guix fornece serviço NGINX com capacidade de carregar módulos Lua e pacotes Lua específicos, e responder a solicitações avaliando scripts Lua.

O exemplo a seguir demonstra a definição do sistema com configuração para avaliar o script Lua index.lua na solicitação HTTP para o endpoint http://localhost/hello:

local shell = require "resty.shell"

local stdin = ""
local timeout = 1000  -- ms
local max_size = 4096  -- byte

local ok, stdout, stderr, reason, status =
   shell.run([[/run/current-system/profile/bin/ls /tmp]], stdin, timeout, max_size)

ngx.say(stdout)

(use-modules (gnu))
(use-service-modules #;… web)
(use-package-modules #;… lua)
(operating-system
  ;; …
  (services
   ;; …
   (service nginx-service-type
            (nginx-configuration
             (modules
              (list
               (file-append nginx-lua-module "/etc/nginx/modules/ngx_http_lua_module.so")))
             (lua-package-path (list lua-resty-core
                                     lua-resty-lrucache
                                     lua-resty-signal
                                     lua-tablepool
                                     lua-resty-shell))
             (lua-package-cpath (list lua-resty-signal))
             (server-blocks
              (list (nginx-server-configuration
                     (server-name '("localhost"))
                     (listen '("80"))
                     (root "/etc")
                     (locations (list
                                 (nginx-location-configuration
                                  (uri "/hello")
                                  (body (list #~(format #f "content_by_lua_file ~s;"
                                                        #$(local-file "index.lua"))))))))))))))

3.13 Servidor de música com áudio Bluetooth

MPD, o Music Player Daemon, é um aplicativo flexível do lado do servidor para tocar música. Programas clientes em diferentes máquinas na rede — um telefone celular, um laptop, uma estação de trabalho de mesa — podem se conectar a ele para controlar a reprodução de arquivos de áudio da sua coleção de música local. O MPD decodifica os arquivos de áudio e os reproduz em uma ou muitas saídas.

Por padrão, o MPD reproduzirá no dispositivo de áudio padrão. No exemplo abaixo, tornamos as coisas um pouco mais interessantes configurando um servidor de música headless. Não haverá interface gráfica de usuário, nenhum daemon Pulseaudio e nenhuma saída de áudio local. Em vez disso, configuraremos o MPD com duas saídas: um alto-falante bluetooth e um servidor web para servir fluxos de áudio para qualquer reprodutor de mídia de streaming.

O Bluetooth costuma ser bastante frustrante de configurar. Você terá que parear seu dispositivo Bluetooth e certificar-se de que o dispositivo seja conectado automaticamente assim que for ligado. O serviço do sistema Bluetooth retornado pelo procedimento bluetooth-service fornece a infraestrutura necessária para configurar isso.

Reconfigure seu sistema com pelo menos os seguintes serviços e pacotes:

(operating-system
  ;; …
  (packages (cons* bluez bluez-alsa
                   %base-packages))
  (services
   ;; …
   (dbus-service #:services (list bluez-alsa))
   (bluetooth-service #:auto-enable? #t)))

Inicie o serviço bluetooth e então use bluetoothctl para escanear dispositivos Bluetooth. Tente identificar seu alto-falante Bluetooth e escolher seu ID de dispositivo na lista resultante de dispositivos que é indubitavelmente dominada por uma desconcertante miscelânea de engenhocas de automação residencial de seus vizinhos. Isso só precisa ser feito uma vez:

$ bluetoothctl 
[NEW] Controller 00:11:22:33:95:7F BlueZ 5.40 [default]

[bluetooth]# power on
[bluetooth]# Changing power on succeeded

[bluetooth]# agent on
[bluetooth]# Agent registered

[bluetooth]# default-agent
[bluetooth]# Default agent request successful

[bluetooth]# scan on
[bluetooth]# Discovery started
[CHG] Controller 00:11:22:33:95:7F Discovering: yes
[NEW] Device AA:BB:CC:A4:AA:CD My Bluetooth Speaker
[NEW] Device 44:44:FF:2A:20:DC My Neighbor's TV
…

[bluetooth]# pair AA:BB:CC:A4:AA:CD
Attempting to pair with AA:BB:CC:A4:AA:CD
[CHG] Device AA:BB:CC:A4:AA:CD Connected: yes

[Meu alto-falante Bluetooth]# [CHG] Device AA:BB:CC:A4:AA:CD UUIDs: 0000110b-0000-1000-8000-00xxxxxxxxxx
[CHG] Device AA:BB:CC:A4:AA:CD UUIDs: 0000110c-0000-1000-8000-00xxxxxxxxxx
[CHG] Device AA:BB:CC:A4:AA:CD UUIDs: 0000110e-0000-1000-8000-00xxxxxxxxxx
[CHG] Device AA:BB:CC:A4:AA:CD Paired: yes
Pairing successful

[CHG] Device AA:BB:CC:A4:AA:CD Connected: no

[bluetooth]# 
[bluetooth]# trust AA:BB:CC:A4:AA:CD
[bluetooth]# [CHG] Device AA:BB:CC:A4:AA:CD Trusted: yes
Changing AA:BB:CC:A4:AA:CD trust succeeded

[bluetooth]# 
[bluetooth]# connect AA:BB:CC:A4:AA:CD
Attempting to connect to AA:BB:CC:A4:AA:CD
[bluetooth]# [CHG] Device AA:BB:CC:A4:AA:CD RSSI: -63
[CHG] Device AA:BB:CC:A4:AA:CD Connected: yes
Connection successful

[My Bluetooth Speaker]# scan off
[CHG] Device AA:BB:CC:A4:AA:CD RSSI is nil
Discovery stopped
[CHG] Controller 00:11:22:33:95:7F Discovering: no

Parabéns, agora você pode se conectar automaticamente ao seu alto-falante Bluetooth!

Agora é hora de configurar o ALSA para usar o módulo Bluetooth bluealsa, para que você possa definir um dispositivo ALSA pcm correspondente ao seu alto-falante Bluetooth. Para um servidor headless, usar bluealsa com um dispositivo Bluetooth fixo é provavelmente mais simples do que configurar o Pulseaudio e seu comportamento de troca de fluxo. Configuramos o ALSA criando um alsa-configuration personalizado para o alsa-service-type. A configuração declarará um tipo pcm bluealsa do módulo bluealsa fornecido pelo pacote bluez-alsa e, em seguida, definirá um dispositivo pcm desse tipo para seu alto-falante Bluetooth.

Tudo o que resta então é fazer o MPD enviar dados de áudio para este dispositivo ALSA. Também adicionamos uma saída MPD secundária que torna os arquivos de áudio atualmente reproduzidos disponíveis como um fluxo por meio de um servidor web na porta 8080. Quando habilitado, um dispositivo na rede pode ouvir o fluxo de áudio conectando qualquer reprodutor de mídia capaz ao servidor HTTP na porta 8080, independentemente do status do alto-falante Bluetooth.

O que se segue é o esboço de uma declaração operating-system que deve realizar as tarefas mencionadas acima:

(use-modules (gnu))
(use-service-modules audio dbus sound #;… etc)
(use-package-modules audio linux #;… etc)
(operating-system
  ;; …
  (packages (cons* bluez bluez-alsa
                   %base-packages))
  (services
   ;; …
   (service mpd-service-type
            (mpd-configuration
             (user "your-username")
             (music-dir "/path/to/your/music")
             (address "192.168.178.20")
             (outputs (list (mpd-output
                             (type "alsa")
                             (name "MPD")
                             (extra-options
                              ;; Use o mesmo nome que no ALSA
                              ;; configuração abaixo.
                              '((device . "pcm.btspeaker"))))
                            (mpd-output
                             (type "httpd")
                             (name "streaming")
                             (enabled? #false)
                             (always-on? #true)
                             (tags? #true)
                             (mixer-type 'null)
                             (extra-options
                              '((encoder . "vorbis")
                                (port    . "8080")
                                (bind-to-address . "192.168.178.20")
                                (max-clients . "0") ;no limit
                                (quality . "5.0")
                                (format  . "44100:16:1"))))))))
   (dbus-service #:services (list bluez-alsa))
   (bluetooth-service #:auto-enable? #t)
   (service alsa-service-type
            (alsa-configuration
             (pulseaudio? #false) ;nós não precisamos disso
             (extra-options
              #~(string-append "\
# Declarar o tipo de dispositivo de áudio Bluetooth \"bluealsa\" do módulo bluealsa
pcm_type.bluealsa {
    lib \""
#$(file-append bluez-alsa "/lib/alsa-lib/libasound_module_pcm_bluealsa.so") "\"
}

# Declarar tipo de dispositivo de controle \"bluealsa\" do mesmo módulo
ctl_type.bluealsa {
    lib \""
#$(file-append bluez-alsa "/lib/alsa-lib/libasound_module_ctl_bluealsa.so") "\"
}

# Defina o dispositivo de áudio Bluetooth real.
pcm.btspeaker {
    type bluealsa
    device \"AA:BB:CC:A4:AA:CD\" # identificador de dispositivo exclusivo
    profile \"a2dp\"
}

# Defina um controlador associado.
ctl.btspeaker {
    type bluealsa
}
"))))))

Aproveite a música com o cliente MPD de sua escolha ou um media player capaz de transmitir via HTTP!

4.1 Contêineres Guix

A maneira mais fácil de começar é usar guix shell com a opção --container. Veja Invocando guix shell em Manual de Referência GNU Guix para uma referência de opções válidas.

O snippet a seguir gera um processo de shell mínimo com a maioria dos namespaces não compartilhados do sistema. O diretório de trabalho atual é visível para o processo, mas qualquer outra coisa no sistema de arquivos não está disponível. Esse isolamento extremo pode ser muito útil quando você deseja descartar qualquer tipo de interferência de variáveis de ambiente, bibliotecas instaladas globalmente ou arquivos de configuração.

guix shell --container

O trecho a seguir gera um processo de shell mínimo como a maioria dos namespaces não compartilhados do sistema. O diretório de trabalho atual é visível para o processo, mas qualquer outra coisa no sistema de arquivos não está disponível. Esse extremo de isolamento pode ser muito útil quando você deseja descartar qualquer tipo de interferência de variáveis de ambiente, bibliotecas instaladas globalmente ou arquivos de configuração.

$ echo /gnu/store/*
/gnu/store/…-gcc-10.3.0-lib
/gnu/store/…-glibc-2.33
/gnu/store/…-bash-static-5.1.8
/gnu/store/…-ncurses-6.2.20210619
/gnu/store/…-bash-5.1.8
/gnu/store/…-profile
/gnu/store/…-readline-8.1.1

Não há muito que você possa fazer em um ambiente como esse além de sair dele. Você pode usar ^D ou exit para encerrar esse ambiente de shell limitado.

Você pode tornar outros diretórios disponíveis dentro do ambiente do contêiner; use --expose=DIRECTORY para montar o diretório fornecido como um local somente leitura dentro do contêiner, ou use --share=DIRECTORY para tornar o local gravável. Com um argumento de mapeamento adicional após o nome do diretório, você pode controlar o nome do diretório dentro do contêiner. No exemplo a seguir, mapeamos /etc no sistema host para /the/host/etc dentro de um contêiner no qual os GNU coreutils estão instalados.

$ guix shell --container --share=/etc=/the/host/etc coreutils
$ ls /the/host/etc

Da mesma forma, você pode evitar que o diretório de trabalho atual seja mapeado para o contêiner com a opção --no-cwd. Outra boa ideia é criar um diretório dedicado que servirá como o diretório home do contêiner e gerar o shell do contêiner a partir desse diretório.

Em um sistema estrangeiro, um ambiente de contêiner pode ser usado para compilar software que não pode ser vinculado a bibliotecas do sistema ou à cadeia de ferramentas do compilador do sistema. Um caso de uso comum em um contexto de pesquisa é instalar pacotes de dentro de uma sessão R. Fora de um ambiente de contêiner, há uma boa chance de que a cadeia de ferramentas do compilador estrangeiro e bibliotecas de sistema incompatíveis sejam encontradas primeiro, resultando em binários incompatíveis que não podem ser usados pelo R. Em um shell de contêiner, esse problema desaparece, pois as bibliotecas e executáveis do sistema simplesmente não estão disponíveis devido ao namespace mount não compartilhado.

Vamos pegar um manifesto abrangente que fornece um ambiente de desenvolvimento confortável para uso com R:

(specifications->manifest
  (list "r-minimal"

        ;; base packages
        "bash-minimal"
        "glibc-locales"
        "nss-certs"

        ;; Ferramentas comuns de linha de comando para o caso de o contêiner ficar muito vazio.
        "coreutils"
        "grep"
        "which"
        "wget"
        "sed"

        ;; Ferramenta de marcação R
        "pandoc"

        ;; Cadeia de ferramentas e bibliotecas comuns para "install.packages"
        "gcc-toolchain@10"
        "gfortran-toolchain"
        "gawk"
        "tar"
        "gzip"
        "unzip"
        "make"
        "cmake"
        "pkg-config"
        "cairo"
        "libxt"
        "openssl"
        "curl"
        "zlib"))

Vamos usar isso para executar o R dentro de um ambiente de contêiner. Por conveniência, compartilhamos o namespace net para usar as interfaces de rede do sistema host. Agora podemos construir pacotes R a partir da fonte da maneira tradicional, sem ter que nos preocupar com incompatibilidades ou incompatibilidades de ABI.

$ guix shell --container --network --manifest=manifest.scm -- R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
…
> e <- Sys.getenv("GUIX_ENVIRONMENT")
> Sys.setenv(GIT_SSL_CAINFO=paste0(e, "/etc/ssl/certs/ca-certificates.crt"))
> Sys.setenv(SSL_CERT_FILE=paste0(e, "/etc/ssl/certs/ca-certificates.crt"))
> Sys.setenv(SSL_CERT_DIR=paste0(e, "/etc/ssl/certs"))
> install.packages("Cairo", lib=paste0(getwd()))
…
* installing *source* package 'Cairo' ...
…
* DONE (Cairo)

The downloaded source packages are in
	'/tmp/RtmpCuwdwM/downloaded_packages'
> library("Cairo", lib=getwd())
> # sucesso!

Usar shells de contêiner é divertido, mas eles podem se tornar um pouco trabalhosos quando você quer ir além de apenas um único processo interativo. Algumas tarefas se tornam muito mais fáceis quando se assentam na fundação sólida de um Sistema Guix adequado e seu rico conjunto de serviços de sistema. A próxima seção mostra como iniciar um Sistema Guix completo dentro de um contêiner.

4.2 Contêineres do Sistema Guix

O Guix System fornece uma ampla gama de serviços de sistema interconectados que são configurados declarativamente para formar uma fundação GNU System sem estado confiável para quaisquer tarefas que você jogue nele. Mesmo ao usar o Guix em uma distribuição estrangeira, você pode se beneficiar do design do Guix System executando uma instância do sistema como um contêiner. Usando os mesmos recursos do kernel de namespaces não compartilhados mencionados na seção anterior, a instância do Guix System resultante é isolada do sistema host e compartilha apenas os locais do sistema de arquivos que você declara explicitamente.

Um contêiner do Sistema Guix difere do processo shell criado por guix shell --container em várias maneiras importantes. Enquanto em um shell de contêiner o processo containerizado é um processo de shell Bash, um contêiner do Sistema Guix executa o Shepherd como PID 1. Em um contêiner do sistema, todos os serviços do sistema (veja Serviços em Manual de Referência do GNU Guix) são configurados exatamente como seriam em um Sistema Guix em uma máquina virtual ou em bare metal — isso inclui daemons gerenciados pelo GNU Shepherd (veja Serviços do Shepherd em Manual de Referência do GNU Guix), bem como outros tipos de extensões para o sistema operacional (veja Composição de serviço em Manual de Referência do GNU Guix).

O aumento percebido na complexidade da execução de um contêiner do Guix System é facilmente justificado ao lidar com aplicativos mais complexos que têm requisitos mais altos ou mais rígidos em seus contextos de execução: arquivos de configuração, contas de usuários dedicadas, diretórios para caches ou arquivos de log, etc. No Guix System, as demandas desse tipo de software são satisfeitas por meio da implantação de serviços do sistema.

• Um banco de dados de contêineres
• Rede em contêineres

(service postgresql-service-type
         (postgresql-configuration
          (postgresql postgresql-14)))

(use-modules (gnu))
(use-package-modules databases)
(use-service-modules databases)

(operating-system
  (host-name "container")
  (timezone "Europe/Berlin")
  (file-systems (cons (file-system
                        (device (file-system-label "does-not-matter"))
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))
  (bootloader (bootloader-configuration
               (bootloader grub-bootloader)
               (targets '("/dev/sdX"))))
  (services
   (cons* (service postgresql-service-type
                   (postgresql-configuration
                    (postgresql postgresql-14)
                    (config-file
                     (postgresql-config-file
                      (log-destination "stderr")
                      (hba-file
                       (plain-file "pg_hba.conf"
                                   "\
local	all	all			trust
host	all	all	10.0.0.1/32 	trust"))
                      (extra-config
                       '(("listen_addresses" "*")
                         ("log_directory"    "/var/log/postgresql")))))))
          (service postgresql-role-service-type
                   (postgresql-role-configuration
                    (roles
                     (list (postgresql-role
                            (name "test")
                            (create-database? #t))))))
          %base-services)))

$ guix system container os.scm
As seguintes derivações serão compiladas::
/gnu/store/…-run-container.drv
…
compilando /gnu/store/…-run-container.drv...
/gnu/store/…-run-container

$ sudo /gnu/store/…-run-container
O contêiner de sistema está rodando como PID 5983
…

$ guix shell util-linux
$ sudo nsenter -a -t 5983
root@container /# pgrep -a postgres
49 /gnu/store/…-postgresql-14.4/bin/postgres -D /var/lib/postgresql/data --config-file=/gnu/store/…-postgresql.conf -p 5432
51 postgres: checkpointer
52 postgres: background writer
53 postgres: walwriter
54 postgres: autovacuum launcher
55 postgres: stats collector
56 postgres: logical replication launcher
root@container /# exit

pid=5983
ns="guix-test"
host="veth-test"
client="ceth-test"

# Anexe o novo namespace de rede "guix-test" ao PID do contêiner.
sudo ip netns attach $ns $pid

# Crie o par de dispositivos
sudo ip link add $host type veth peer name $client

# Mova o dispositivo cliente para o namespace de rede do contêiner
sudo ip link set $client netns $ns

sudo ip link set $host up
sudo ip addr add 10.0.0.1/24 dev $host

sudo ip netns exec $ns  ip link set lo up
sudo ip netns exec $ns  ip link set $client up
sudo ip netns exec $ns  ip addr add 10.0.0.2/24 dev $client

$ psql -h 10.0.0.2 -U test
psql (14.4)
Type "help" for help.

test=> CREATE TABLE hello (who TEXT NOT NULL);
CREATE TABLE
test=> INSERT INTO hello (who) VALUES ('world');
INSERT 0 1
test=> SELECT * FROM hello;
  who
-------
 world
(1 row)

sudo kill $pid
sudo ip netns del $ns
sudo ip link del $host

5.1 Ponte de rede para QEMU

Por padrão, o QEMU usa um back-end de rede host chamado “modo usuário”, o que é conveniente, pois não requer nenhuma configuração. Infelizmente, também é bastante limitado. Neste modo, o convidado VM (máquina virtual) pode acessar a rede da mesma forma que o host, mas não pode ser alcançado a partir do host. Além disso, como o modo de rede do usuário do QEMU depende do ICMP, ferramentas de rede baseadas em ICMP, como ping, não funcionam neste modo. Portanto, geralmente é desejável configurar uma ponte de rede, que permite que o convidado participe totalmente da rede. Isso é necessário, por exemplo, quando o convidado deve ser usado como um servidor.

• Criando uma interface de ponte de rede
• Configurando o script auxiliar da ponte QEMU
• Invocando QEMU com as opções de linha de comando corretas
• Problemas de rede causados pelo Docker

# nmcli con add type bridge con-name br0 ifname br0

# nmcli con add type bridge-slave ifname enp2s0 master br0

(privileged-programs
 (cons (privileged-program
         (program (file-append qemu "/libexec/qemu-bridge-helper"))
         (setuid? #t))
       %default-privileged-programs))

(extra-special-file "/etc/qemu/host.conf" "allow br0\n")

$ qemu-system-x86_64 [...] \
    -device virtio-net-pci,netdev=user0,mac=XX:XX:XX:XX:XX:XX \
    -netdev bridge,id=user0,br=br0 \
    [...]

mac_address="52:54:00:$(dd if=/dev/urandom bs=512 count=1 2>/dev/null \
                           | md5sum \
                           | sed -E 's/^(..)(..)(..).*$/\1:\2:\3/')"
echo $mac_address

(service iptables-service-type
             (iptables-configuration
              (ipv4-rules (plain-file "iptables.rules" "\
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i br0 -o br0 -j ACCEPT
COMMIT
"))

5.2 Roteamento de rede para libvirt

Se a máquina que hospeda suas máquinas virtuais estiver conectada sem fio à rede, você não poderá usar uma ponte de rede verdadeira, conforme explicado na seção anterior (veja Ponte de rede para QEMU). Nesse caso, a próxima melhor opção é usar uma ponte virtual com roteamento estático e configurar uma máquina virtual com libvirt para usá-la (por meio da GUI virt-manager, por exemplo). Isso é semelhante ao modo de operação padrão do QEMU/libvirt, exceto que, em vez de usar NAT (Network Address Translation), ele depende de rotas estáticas para unir o endereço IP da VM (máquina virtual) à LAN (rede local). Isso fornece conectividade bidirecional de e para a máquina virtual, necessária para expor serviços hospedados na máquina virtual.

• Criando uma ponte de rede virtual
• Configurando as rotas estáticas para sua ponte virtual

<network>
  <name>virbr0</name>
  <bridge name="virbr0" />
  <forward mode="route"/>
  <ip address="192.168.2.0" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.2.1" end="192.168.2.254"/>
    </dhcp>
  </ip>
</network>

virsh net-define /tmp/virbr0.xml
virsh net-autostart virbr0
virsh net-start virbr0

6.1 Perfis Guix na Prática

Guix fornece um recurso muito útil que pode ser bem estranho para novatos: profiles. Eles são uma maneira de agrupar instalações de pacotes e todos os usuários no mesmo sistema são livres para usar quantos perfis quiserem.

Seja você um desenvolvedor ou não, você pode descobrir que múltiplos perfis trazem grande poder e flexibilidade. Embora eles mudem um pouco o paradigma em comparação aos gerenciadores de pacotes tradicionais, eles são muito convenientes de usar depois que você entende como configurá-los.

Nota: Esta seção é um guia opinativo sobre o uso de múltiplos perfis. Ele é anterior ao guix shell e seu cache de perfil rápido (veja Invocando guix shell em Manual de Referência do GNU Guix).

Em muitos casos, você pode descobrir que usar guix shell para configurar o ambiente que você precisa, quando você precisa, dá menos trabalho do que manter um perfil dedicado. Sua escolha!

Se você estiver familiarizado com o ‘virtualenv’ do Python, você pode pensar em um perfil como um tipo de ‘virtualenv’ universal que pode conter qualquer tipo de software, não apenas software Python. Além disso, os perfis são autossuficientes: eles capturam todas as dependências de tempo de execução, o que garante que todos os programas dentro de um perfil sempre funcionarão em qualquer ponto do tempo.

Perfis múltiplos têm muitos benefícios:

• Separação semântica limpa dos vários pacotes que um usuário precisa para diferentes contextos.
• Vários perfis podem ser disponibilizados no ambiente no login ou em um shell dedicado.
• Os perfis podem ser carregados sob demanda. Por exemplo, o usuário pode usar vários shells, cada um deles executando perfis diferentes.
• Isolamento: programas de um perfil não usarão programas do outro, e o usuário pode até instalar versões diferentes dos mesmos programas nos dois perfis sem conflito.
• Deduplicação: Perfis compartilham dependências que são exatamente as mesmas. Isso torna o armazenamento de múltiplos perfis eficiente.
• Reproduzível: quando usado com manifestos declarativos, um perfil pode ser totalmente especificado pelo commit do Guix que estava ativo quando foi configurado. Isso significa que o mesmo perfil exato pode ser configurado em qualquer lugar e a qualquer hora, com apenas as informações de commit. Veja a seção sobre Perfis reproduzíveis.
• Atualizações e manutenção mais fáceis: vários perfis facilitam a manutenção de listas de pacotes em mãos e tornam as atualizações completamente sem atrito.

Concretamente, seguem alguns perfis típicos:

• As dependências de um projeto no qual você está funcionando.
• Suas bibliotecas de linguagens de programação favoritas.
• Programas específicos para laptop (como ‘powertop’) que você não precisa em um desktop.
• TeXlive (este pode ser muito útil quando você precisa instalar apenas um pacote para este documento que acabou de receber por e-mail).
• Jogos.

Vamos mergulhar na configuração!

• Configuração básica com manifestos
• Pacotes necessários
• Perfil padrão
• Os benefícios dos manifestos
• Perfis reproduzíveis

(specifications->manifest
 '("pacote-1"
   ;; Versão 1.3 do pacote-2.
   "pacote-2@1.3"
   ;; A saída "lib" do pacote-3.
   "pacote-3:lib"
   ; ...
   "pacote-N"))

GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
mkdir -p "$GUIX_EXTRA_PROFILES"/meu-projeto # se ainda não existir
guix package --manifest=/caminho/para/guix-meu-projeto-manifest.scm \
 --profile="$GUIX_EXTRA_PROFILES"/meu-projeto/meu-projeto

guix package --list-profiles

for i in $GUIX_EXTRA_PROFILES/*; do
  profile=$i/$(basename "$i")
  if [ -f "$profile"/etc/profile ]; then
    GUIX_PROFILE="$profile"
    . "$GUIX_PROFILE"/etc/profile
  fi
  unset profile
done

for i in "$GUIX_EXTRA_PROFILES"/meu-projeto-1 "$GUIX_EXTRA_PROFILES"/meu-projeto-2; do
  profile=$i/$(basename "$i")
  if [ -f "$profile"/etc/profile ]; then
    GUIX_PROFILE="$profile"
    . "$GUIX_PROFILE"/etc/profile
  fi
  unset profile
done

GUIX_PROFILE="path/to/my-project" ; . "$GUIX_PROFILE"/etc/profile

guix package --search-paths=prefix --profile=$my_profile"

guix package -m /caminho/para/guix-meu-projeto-manifest.scm \
 -p "$GUIX_EXTRA_PROFILES"/meu-projeto/meu-projeto

for profile in "$GUIX_EXTRA_PROFILES"/*; do
  guix package --profile="$profile" \
   --manifest="$HOME/.guix-manifests/guix-$profile-manifest.scm"
done

guix package -p "$GUIX_EXTRA_PROFILES"/meu-projeto/meu-projeto --list-generations

guix package -p "$GUIX_EXTRA_PROFILES"/meu-projeto/meu-projeto --switch-generations=17

env -i $(which bash) --login --noprofile --norc
. meu-projeto/etc/profile

guix install package-foo
guix upgrade package-bar

GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
GUIX_EXTRA=$HOME/.guix-extra

mkdir -p "$GUIX_EXTRA"/meu-projeto
guix pull --channels=channel-specs.scm --profile="$GUIX_EXTRA/meu-projeto/guix"

mkdir -p "$GUIX_EXTRA_PROFILES/meu-projeto"
"$GUIX_EXTRA"/meu-projeto/guix/bin/guix package \
 --manifest=/caminho/para/guix-meu-projeto-manifest.scm \
 --profile="$GUIX_EXTRA_PROFILES"/meu-projeto/meu-projeto

7.1 Começando

Como fazemos para “Guixificar” um repositório? O primeiro passo, como vimos, será adicionar um guix.scm na raiz do repositório em questão. Usaremos Guile como exemplo neste capítulo: ele é escrito em Scheme (principalmente) e C, e tem várias dependências — uma cadeia de ferramentas de compilação C, bibliotecas C, Autoconf e seus amigos, LaTeX, e assim por diante. O guix.scm resultante se parece com a definição de pacote usual (veja Definindo pacotes em Manual de Referência GNU Guix), só que sem o bit define-public:

;; O arquivo ‘guix.scm’ para Guile, para uso pelo ‘guix shell’.

(use-modules (guix)
             (guix build-system gnu)
             ((guix licenses) #:prefix license:)
             (gnu packages autotools)
             (gnu packages base)
             (gnu packages bash)
             (gnu packages bdw-gc)
             (gnu packages compression)
             (gnu packages flex)
             (gnu packages gdb)
             (gnu packages gettext)
             (gnu packages gperf)
             (gnu packages libffi)
             (gnu packages libunistring)
             (gnu packages linux)
             (gnu packages pkg-config)
             (gnu packages readline)
             (gnu packages tex)
             (gnu packages texinfo)
             (gnu packages version-control))

(package
  (name "guile")
  (version "3.0.99-git")                          ;número da versão funky
  (source #f)                                     ;nenhuma fonte
  (build-system gnu-build-system)
  (native-inputs
   (append (list autoconf
                 automake
                 libtool
                 gnu-gettext
                 flex
                 texinfo
                 texlive-base                 ;para "make pdf"
                 texlive-epsf
                 gperf
                 git
                 gdb
                 strace
                 readline
                 lzip
                 pkg-config)

           ;; Ao compilar cruzadamente, uma versão nativa do próprio Guile é
           ;; needed.
           (if (%current-target-system)
               (list this-package)
               '())))
  (inputs
   (list libffi bash-minimal))
  (propagated-inputs
   (list libunistring libgc))

  (native-search-paths
   (list (search-path-specification
          (variable "GUILE_LOAD_PATH")
          (files '("share/guile/site/3.0")))
         (search-path-specification
          (variable "GUILE_LOAD_COMPILED_PATH")
          (files '("lib/guile/3.0/site-ccache")))))
  (synopsis "Scheme implementation intended especially for extensions")
  (description
   "Guile is the GNU Ubiquitous Intelligent Language for Extensions,
and it's actually a full-blown Scheme implementation!")
  (home-page "https://www.gnu.org/software/guile/")
  (license license:lgpl3+))

um pouco de clichê, mas agora alguém que queira hackear o Guile só precisa executar:

guix shell

Isso lhes dá um shell contendo todas as dependências do Guile: aquelas listadas acima, mas também dependências implícitas, como a cadeia de ferramentas GCC, GNU Make, sed, grep e assim por diante. Veja Invocando guix shell em Manual de Referência do GNU Guix, para mais informações sobre guix shell.

Recomendação do chef: Nossa sugestão é criar ambientes de desenvolvimento como este:

guix shell --container --link-profile

... ou, para abreviar:

guix shell -CP

Isso dá um shell em um contêiner isolado, e todas as dependências aparecem em $HOME/.guix-profile, que funciona bem com caches como config.cache (veja Cache Files em Autoconf) e nomes de arquivos absolutos registrados em Makefiles gerados e similares. O fato de o shell rodar em um contêiner traz paz de espírito: nada além do diretório atual e das dependências do Guile é visível dentro do contêiner; nada do sistema pode interferir no seu desenvolvimento.

7.2 Nível 1: Construindo com Guix

Agora que temos uma definição de pacote (veja Começando), por que não tirar vantagem dela também para que possamos construir o Guile com o Guix? Deixamos o campo source vazio, porque o guix shell acima só se importa com as inputs do nosso pacote—para que ele possa configurar o ambiente de desenvolvimento—não com o pacote em si.

Para construir o pacote com Guix, precisaremos preencher o campo source, desta forma:

(use-modules (guix)
             (guix git-download)  ;para ‘git-predicate’
             …)

(define vcs-file?
  ;; Retorna verdadeiro se o arquivo fornecido estiver sob controle de versão.
  (or (git-predicate (current-source-directory))
      (const #t)))                                ;não em um checkout do Git

(package
  (name "guile")
  (version "3.0.99-git")                          ;número da versão funky
  (source (local-file "." "guile-checkout"
                      #:recursive? #t
                      #:select? vcs-file?))
  …)

Aqui está o que mudamos em comparação à seção anterior:

1. Adicionamos (guix git-download) ao nosso conjunto de módulos importados, para que possamos usar seu procedimento git-predicate.
2. Definimos vcs-file? como um procedimento que retorna true quando passado um arquivo que está sob controle de versão. Para uma boa medida, adicionamos um caso de fallback para quando não estamos em um checkout do Git: sempre retorna true.
3. Definimos source como um local-file—uma cópia recursiva do diretório atual ("."), limitado a arquivos sob controle de versão (o bit #:select?).

A partir daí, nosso arquivo guix.scm serve a um segundo propósito: ele nos permite construir o software com Guix. O ponto principal de construir com Guix é que é uma construção “limpa” — você pode ter certeza de que nada da sua árvore de trabalho ou sistema interfere no resultado da construção — e ele permite que você teste uma variedade de coisas. Primeiro, você pode fazer uma construção nativa simples:

guix build -f guix.scm

Mas você também pode compilar para outro sistema (possivelmente após configurar veja offloading em GNU Guix Reference Manual ou veja emulação transparente em Manual de referência do GNU Guix):

guix build -f guix.scm -s aarch64-linux -s riscv64-linux

… ou compilação cruzada:

guix build -f guix.scm --target=x86_64-w64-mingw32

Você também pode usar transformações de pacotes para testar variantes de pacotes (veja Opções de transformação de pacote em Manual de referência do GNU Guix):

# E se construíssemos com Clang em vez de GCC?
guix build -f guix.scm \
--with-c-toolchain=guile@3.0.99-git=clang-toolchain

# E quanto ao sinalizador configure pouco testado?
guix build -f guix.scm \
  --with-configure-flag=guile@3.0.99-git=--disable-networking

Útil!

7.3 Nível 2: O Repositório como Canal

Agora temos um repositório Git contendo (entre outras coisas) uma definição de pacote (veja Nível 1: Construindo com Guix). Não podemos transformá-lo em um channel (veja Canais em Manual de referência do GNU Guix)? Afinal, os canais são projetados para enviar definições de pacotes aos usuários, e é exatamente isso que estamos fazendo com nosso guix.scm.

Acontece que podemos realmente transformá-lo em um canal, mas com uma ressalva: precisamos criar um diretório separado para o(s) arquivo(s) .scm do nosso canal para que guix pull não carregue arquivos .scm não relacionados quando alguém puxar o canal — e no Guile, há muitos deles! Então, começaremos assim, mantendo um link simbólico guix.scm de nível superior para o bem do guix shell:

mkdir -p .guix/modules
mv guix.scm .guix/modules/guile-package.scm
ln -s .guix/modules/guile-package.scm guix.scm

Para torná-lo utilizável como parte de um canal, precisamos transformar nosso arquivo guix.scm em um módulo de pacote (veja Módulos de pacote em Manual de referência do GNU Guix): fazemos isso alterando o formulário use-modules no topo para um formulário define-module. Também precisamos realmente exportar uma variável de pacote, com define-public, enquanto ainda retornamos o valor do pacote no final do arquivo para que ainda possamos usar guix shell e guix build -f guix.scm. O resultado final se parece com isso (não repetindo coisas que não mudaram):

(define-module (guile-package)
  #:use-module (guix)
  #:use-module (guix git-download)   ;para ‘git-predicate’
  …)

(define vcs-file?
  ;; Retorna verdadeiro se o arquivo fornecido estiver sob controle de versão.
  (or (git-predicate (dirname (dirname (current-source-directory))))
      (const #t)))                                ;não em um checkout do Git

(define-public guile
  (package
    (name "guile")
    (version "3.0.99-git")                          ;número da versão funky
    (source (local-file "../.." "guile-checkout"
                        #:recursive? #t
                        #:select? vcs-file?))
    …))

;; Retorna o objeto do pacote definido acima no final do módulo.
guile

Precisamos de uma última coisa: um arquivo .guix-channel para que o Guix saiba onde procurar módulos de pacote em nosso repositório:

;; Este arquivo nos permite apresentar este repositório como um canal Guix.

(channel
  (version 0)
  (directory ".guix/modules"))  ;procure por módulos de pacote em .guix/modules/

Para recapitular, agora temos estes arquivos:

.
├── .guix-channel
├── guix.scm → .guix/modules/guile-package.scm
└── .guix
    └── modules
       └── guile-package.scm

E é isso: temos um canal! (Poderíamos fazer melhor e dar suporte a autenticação de canal para que os usuários saibam que estão extraindo código genuíno. Vamos poupá-lo dos detalhes aqui, mas vale a pena considerar!) Os usuários podem extrair deste canal por adicionando-o a ~/.config/guix/channels.scm, ao longo destas linhas:

(append (list (channel
                (name 'guile)
                (url "https://git.savannah.gnu.org/git/guile.git")
                (branch "main")))
        %default-channels)

Após executar guix pull, podemos ver o novo pacote:

$ guix describe
Geração 264 26 de maio de 2023 16:00:35 (atual)
  guile 36fd2b4
    repository URL: https://git.savannah.gnu.org/git/guile.git
    branch: main
    commit: 36fd2b4920ae926c79b936c29e739e71a6dff2bc
  guix c5bc698
    repository URL: https://git.savannah.gnu.org/git/guix.git
    commit: c5bc698e8922d78ed85989985cc2ceb034de2f23
$ guix package -A ^guile$
guile   3.0.99-git      out,debug       guile-package.scm:51:4
guile   3.0.9           out,debug       gnu/packages/guile.scm:317:2
guile   2.2.7           out,debug       gnu/packages/guile.scm:258:2
guile   2.2.4           out,debug       gnu/packages/guile.scm:304:2
guile   2.0.14          out,debug       gnu/packages/guile.scm:148:2
guile   1.8.8           out             gnu/packages/guile.scm:77:2
$ guix build guile@3.0.99-git
[…]
/gnu/store/axnzbl89yz7ld78bmx72vpqp802dwsar-guile-3.0.99-git-debug
/gnu/store/r34gsij7f0glg2fbakcmmk0zn4v62s5w-guile-3.0.99-git

É assim que, como desenvolvedor, você tem seu software entregue diretamente nas mãos dos usuários! Sem intermediários, mas sem perda de transparência e rastreamento de procedência.

Com isso em prática, também se torna trivial para qualquer um criar imagens Docker, pacotes Deb/RPM ou um tarball simples com guix pack (veja Invocando guix pack em Manual de Referência GNU Guix):

# Que tal uma imagem Docker do nosso instantâneo Guile?
guix pack -f docker -S /bin=bin guile@3.0.99-git

# E um RPM relocável?
guix pack -f rpm -R -S /bin=bin guile@3.0.99-git

7.4 Bônus: Variantes do pacote

Agora temos um canal real, mas ele contém apenas um pacote (veja Nível 2: O Repositório como Canal). Enquanto estamos nisso, podemos definir variantes de pacote (veja Definindo variantes de pacote em Manual de Referência do GNU Guix) em nosso arquivo guile-package.scm, variantes que queremos poder testar como desenvolvedores Guile—semelhante ao que fizemos acima com opções de transformação. Podemos adicioná-las assim:

;; Este é o arquivo ‘.guix/modules/guile-package.scm’.

(define-module (guile-package)
  …)

(define-public guile
  …)

(define (package-with-configure-flags p flags)
  "Retorna P com FLAGS como sinalizadores 'configure' adicionais."
  (package/inherit p
    (arguments
     (substitute-keyword-arguments (package-arguments p)
       ((#:configure-flags original-flags #~(list))
        #~(append #$original-flags #$flags))))))

(define-public guile-without-threads
  (package
    (inherit (package-with-configure-flags guile
                                           #~(list "--without-threads")))
    (name "guile-without-threads")))

(define-public guile-without-networking
  (package
    (inherit (package-with-configure-flags guile
                                           #~(list "--disable-networking")))
    (name "guile-without-networking")))


;; Retorna o objeto do pacote definido acima no final do módulo.
guile

Podemos construir essas variantes como pacotes regulares assim que tivermos puxado o canal. Alternativamente, a partir de um checkout do Guile, podemos executar um comando como este do nível superior:

guix build -L $PWD/.guix/modules guile-without-threads

7.5 Nível 3: Configurando a integração contínua

O canal que definimos acima (veja Nível 2: O Repositório como Canal) se torna ainda mais interessante quando configuramos continuous integration (CI). Há várias maneiras de fazer isso.

Você pode usar uma das principais ferramentas de integração contínua, como o GitLab-CI. Para fazer isso, você precisa ter certeza de executar jobs em uma imagem Docker ou máquina virtual que tenha o Guix instalado. Se fizéssemos isso no caso do Guile, teríamos um job que executa um comando shell como este:

guix build -L $PWD/.guix/modules guile@3.0.99-git

Fazer isso funciona muito bem e tem a vantagem de ser fácil de fazer na sua plataforma de CI favorita.

Dito isso, você realmente aproveitará ao máximo usando Cuirass, uma ferramenta de CI projetada para e fortemente integrada com Guix. Usá-la dá mais trabalho do que usar uma ferramenta de CI hospedada porque primeiro você precisa configurá-la, mas essa fase de configuração é bastante simplificada se você usar seu serviço Guix System (veja Integração Contínua em Manual de Referência GNU Guix). Voltando ao nosso exemplo, damos ao Cuirass um arquivo de especificação que é assim:

;; Arquivo de especificações do Cuirass para construir todos os pacotes do canal ‘guile’.
(list (specification
        (name "guile")
        (build '(channels guile))
        (channels
         (append (list (channel
                         (name 'guile)
                         (url "https://git.savannah.gnu.org/git/guile.git")
                         (branch "main")))
                 %default-channels))))

Ela difere do que você faria com outras ferramentas de CI em dois aspectos importantes:

• O Cuirass sabe que está rastreando dois canais, guile e guix. De fato, nosso próprio pacote guile depende de muitos pacotes fornecidos pelo canal guix—GCC, o GNU libc, libffi e assim por diante. Mudanças em pacotes do canal guix podem potencialmente influenciar nossa construção guile e isso é algo que gostaríamos de ver o mais rápido possível como desenvolvedores do Guile.
• Os resultados da compilação não são descartados: eles podem ser distribuídos como substitutos para que os usuários do nosso canal guile obtenham binários pré-compilados de forma transparente! (veja Substitutos em Manual de Referência do GNU Guix, para informações básicas sobre substitutos.)

Do ponto de vista de um desenvolvedor, o resultado final é esta status page listando avaliações: cada avaliação é uma combinação de confirmações dos canais guix e guile, fornecendo um número de trabalhos — um trabalho por pacote definido em guile-package.scm vezes o número de arquiteturas de destino.

Quanto aos substitutos, eles vêm de graça! Por exemplo, já que nosso jobset guile é construído em ci.guix.gnu.org, que executa guix publish (veja Invocando guix publish em Manual de Referência do GNU Guix) além do Cuirass, obtém-se automaticamente substitutos para compilações guile de ci.guix.gnu.org; nenhum trabalho adicional é necessário para isso.

7.6 Bônus: Construir manifesto

A especificação Cuirass acima é conveniente: ela constrói todos os pacotes em nosso canal, o que inclui algumas variantes (veja Nível 3: Configurando a integração contínua). No entanto, isso pode ser insuficientemente expressivo em alguns casos: pode-se querer trabalhos específicos de compilação cruzada, transformações, imagens Docker, pacotes RPM/Deb ou até mesmo testes de sistema.

Para conseguir isso, você pode escrever um manifest (veja Escrevendo manifestos em Manual de Referência do GNU Guix). O que temos para Guile tem entradas para as variantes de pacote que definimos acima, bem como variantes adicionais e compilações cruzadas:

;; Este é ‘.guix/manifest.scm’.

(use-modules (guix)
             (guix profiles)
             (guile-package)) ;importa nosso próprio módulo de pacote

(define* (package->manifest-entry* package system
                                   #:key target)
  "Retorna uma entrada de manifesto para pacote PACKAGE no sisteme SYSTEM,
opcionalmente compilado cruzado para alvo TARGET."
  (manifest-entry
    (inherit (package->manifest-entry package))
    (name (string-append (package-name package) "." system
                         (if target
                             (string-append "." target)
                             "")))
    (item (with-parameters ((%current-system system)
                            (%current-target-system target))
            package))))

(define native-builds
  (manifest
   (append (map (lambda (system)
                  (package->manifest-entry* guile system))

                '("x86_64-linux" "i686-linux"
                  "aarch64-linux" "armhf-linux"
                  "powerpc64le-linux"))
           (map (lambda (guile)
                  (package->manifest-entry* guile "x86_64-linux"))
                (cons (package
                        (inherit (package-with-c-toolchain
                                  guile
                                  `(("clang-toolchain"
                                     ,(specification->package
                                       "clang-toolchain")))))
                        (name "guile-clang"))
                      (list guile-without-threads
                            guile-without-networking
                            guile-debug
                            guile-strict-typing))))))

(define cross-builds
  (manifest
   (map (lambda (target)
          (package->manifest-entry* guile "x86_64-linux"
                                    #:target target))
        '("i586-pc-gnu"
          "aarch64-linux-gnu"
          "riscv64-linux-gnu"
          "i686-w64-mingw32"
          "x86_64-linux-gnu"))))

(concatenate-manifests (list native-builds cross-builds))

Não entraremos em detalhes deste manifesto; basta dizer que ele fornece flexibilidade adicional. Agora precisamos dizer ao Cuirass para construir este manifesto, que é feito com uma especificação ligeiramente diferente da anterior:

;; Cuirass spec file to build all the packages of the ‘guile’ channel.
(list (specification
        (name "guile")
        (build '(manifest ".guix/manifest.scm"))
        (channels
         (append (list (channel
                         (name 'guile)
                         (url "https://git.savannah.gnu.org/git/guile.git")
                         (branch "main")))
                 %default-channels))))

Alteramos a parte (build …) da especificação para '(manifest ".guix/manifest.scm") para que ele escolhesse nosso manifesto, e pronto!

7.7 Empacotando

Escolhemos Guile como exemplo prático neste capítulo e você pode ver o resultado aqui:

• .guix-channel;
• .guix/modules/guile-package.scm com o link simbólico de nível superior guix.scm;
• .guix/manifest.scm.

Hoje em dia, os repositórios são comumente recheados com arquivos dot para várias ferramentas: .envrc, .gitlab-ci.yml, .github/workflows, Dockerfile, .buildpacks, Aptfile, requirements.txt e outros. Pode parecer que estamos propondo um monte de arquivos adicionais, mas na verdade esses arquivos são expressivos o suficiente para substituir a maioria ou todos os listados acima.

Com alguns arquivos, obtemos suporte para:

• ambientes de desenvolvimento (guix shell);
• compilações de teste originais, incluindo para variantes de pacote e para compilação cruzada (guix build);
• integração contínua (com Cuirass ou com alguma outra ferramenta);
• entrega contínua aos usuários (via o canal e com binários pré-construídos);
• geração de artefatos de construção derivados, como imagens Docker ou pacotes Deb/RPM (guix pack).

Este é um bom (na nossa opinião!) conjunto de ferramentas unificadas para implantação de software reproduzível e uma ilustração de como você, como desenvolvedor, pode se beneficiar dele!

8.1 Ambiente Guix via direnv

Guix fornece um pacote ‘direnv’, que pode estender o shell após a mudança de diretório. Esta ferramenta pode ser usada para preparar um ambiente Guix puro.

O exemplo a seguir fornece uma função de shell para o arquivo ~/.direnvrc, que pode ser usada no repositório Guix Git no arquivo ~/src/guix/.envrc para configurar um ambiente de compilação semelhante ao descrito em veja Compilando do git em Manual de Referência do GNU Guix.

Crie um ~/.direnvrc com um código Bash:

# Obrigado <https://github.com/direnv/direnv/issues/73#issuecomment-152284914>
export_function()
{
  local name=$1
  local alias_dir=$PWD/.direnv/aliases
  mkdir -p "$alias_dir"
  PATH_add "$alias_dir"
  local target="$alias_dir/$name"
  if declare -f "$name" >/dev/null; then
    echo "#!$SHELL" > "$target"
    declare -f "$name" >> "$target" 2>/dev/null
    # Observe que adicionamos variáveis de shell ao gatilho da função.
    echo "$name \$*" >> "$target"
    chmod +x "$target"
  fi
}

use_guix()
{
    # Defina o token do GitHub.
    export GUIX_GITHUB_TOKEN="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

    # Unset 'GUIX_PACKAGE_PATH'.
    export GUIX_PACKAGE_PATH=""

    # Recrie uma raiz do coletor de lixo.
    gcroots="$HOME/.config/guix/gcroots"
    mkdir -p "$gcroots"
    gcroot="$gcroots/guix"
    if [ -L "$gcroot" ]
    then
        rm -v "$gcroot"
    fi

    # Pacotes diversos.
    PACKAGES_MAINTENANCE=(
        direnv
        git
        git:send-email
        git-cal
        gnupg
        guile-colorized
        guile-readline
        less
        ncurses
        openssh
        xdot
    )

    # Pacotes de ambiente.
    PACKAGES=(help2man guile-sqlite3 guile-gcrypt)

    # Obrigado <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00859.html>
    eval "$(guix shell --search-paths --root="$gcroot" --pure \
     --development guix ${PACKAGES[@]} ${PACKAGES_MAINTENANCE[@]} "$@")"

    # Predefina sinalizadores de configuração.
    configure()
    {
        ./configure
    }
    export_function configure

    # Execute make e, opcionalmente, construa algo.
    build()
    {
        make -j 2
        if [ $# -gt 0 ]
        then
            ./pre-inst-env guix build "$@"
        fi
    }
    export_function build

    # Predefina o comando push do Git.
    push()
    {
        git push --set-upstream origin
    }
    export_function push

    clear                        # Limpe a tela.
    git-cal --author='Seu nome' # Mostrar calendário de contribuições.

    #Mostrar ajuda de comandos.
    echo "
build          construir um pacote ou apenas um projeto se nenhum argumento for fornecido
configure      execute ./configure com parâmetros predefinidos
push           enviar para o repositório Git upstream
"
}

Cada projeto contendo .envrc com uma string use guix terá variáveis de ambiente e procedimentos predefinidos.

Execute direnv allow para configurar o ambiente pela primeira vez.

9.1 Configurando um nó principal

A abordagem recomendada é configurar um nó principal executando guix-daemon e exportando /gnu/store via NFS para nós de computação.

Lembre-se de que guix-daemon é responsável por gerar processos de compilação e downloads em nome dos clientes (veja Invocando guix-daemon em Manual de Referência do GNU Guix) e, de forma mais geral, acessando /gnu/store, que contém todos os binários de pacotes compilados por todos os usuários (veja O armazém em Manual de Referência do GNU Guix). “Cliente” aqui se refere a todos os comandos Guix que os usuários veem, como guix install. Em um cluster, esses comandos podem estar em execução nos nós de computação e queremos que eles conversem com a instância guix-daemon do nó principal.

Para começar, o nó principal pode ser instalado seguindo as instruções usuais de instalação binária (veja Instalação de binários em Manual de Referência do GNU Guix). Graças ao script de instalação, isso deve ser rápido. Assim que a instalação for concluída, precisamos fazer alguns ajustes.

Como queremos que o guix-daemon seja acessível não apenas do nó principal, mas também dos nós de computação, precisamos organizar para que ele escute conexões por TCP/IP. Para fazer isso, editaremos o arquivo de inicialização do systemd para guix-daemon, /etc/systemd/system/guix-daemon.service e adicionaremos um argumento --listen à linha ExecStart para que fique parecido com isto:

ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild --listen=/var/guix/daemon-socket/socket --listen=0.0.0.0

Para que essas alterações entrem em vigor, o serviço precisa ser reiniciado:

systemctl daemon-reload
systemctl restart guix-daemon

Nota: O bit --listen=0.0.0.0 significa que guix-daemon processará todas as conexões TCP de entrada na porta 44146 (veja Invocando guix-daemon em Manual de Referência do GNU Guix). Isso geralmente é bom em uma configuração de cluster onde o nó principal é acessível exclusivamente da rede local do cluster — você não quer que isso seja exposto à Internet!

O próximo passo é definir nossas exportações NFS em /etc/exports adicionando algo como isto:

/gnu/store    *(ro)
/var/guix     *(rw, async)
/var/log/guix *(ro)

O diretório /gnu/store pode ser exportado somente para leitura, pois somente guix-daemon no nó mestre poderá modificá-lo. /var/guix contém perfis de usuário conforme gerenciados por guix package; portanto, para permitir que os usuários instalem pacotes com guix package, isso deve ser de leitura e gravação.

Os usuários podem criar quantos perfis quiserem, além do perfil padrão, ~/.guix-profile. Por exemplo, guix package -p ~/dev/python-dev -i python instala o Python em um perfil acessível pelo link simbólico ~/dev/python-dev. Para garantir que esse perfil esteja protegido contra coleta de lixo — ou seja, que o Python não será removido de /gnu/store enquanto esse perfil existir —, diretórios home devem ser montados no nó principal também para que guix-daemon saiba sobre esses perfis não padrão e evite coletar softwares aos quais eles se referem.

Pode ser uma boa ideia remover periodicamente bits não utilizados de /gnu/store executando guix gc (veja Invocando guix gc em Manual de Referência do GNU Guix). Isso pode ser feito adicionando uma entrada crontab no nó principal:

root@master# crontab -e

... com algo assim:

# Todos os dias às 5h da manhã, execute o coletor de lixo para garantir
# pelo menos 10 GB estão livres em /gnu/store.
0 5 * * 1 /usr/local/bin/guix gc -F10G

Terminamos com o nó principal! Vamos dar uma olhada nos nós de computação agora.

9.2 Configurando nós de computação

Primeiro, precisamos de nós de computação para montar os diretórios NFS que o nó principal exporta. Isso pode ser feito adicionando as seguintes linhas a /etc/fstab:

head-node:/gnu/store    /gnu/store    nfs  defaults,_netdev,vers=3 0 0
head-node:/var/guix     /var/guix     nfs  defaults,_netdev,vers=3 0 0
head-node:/var/log/guix /var/log/guix nfs  defaults,_netdev,vers=3 0 0

... onde head-node é o nome ou endereço IP do seu nó principal. A partir daí, assumindo que os pontos de montagem existam, você deve conseguir montar cada um deles nos nós de computação.

Em seguida, precisamos fornecer um comando guix padrão que os usuários possam executar quando se conectarem ao cluster pela primeira vez (eventualmente, eles invocarão guix pull, que fornecerá a eles seu “próprio” comando guix). Semelhante ao que o script de instalação binário fez no nó principal, armazenaremos isso em /usr/local/bin:

mkdir -p /usr/local/bin
ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix \
      /usr/local/bin/guix

Precisamos então dizer ao guix para falar com o daemon em execução no nosso nó mestre, adicionando estas linhas ao /etc/profile:

GUIX_DAEMON_SOCKET="guix://head-node"
export GUIX_DAEMON_SOCKET

Para evitar avisos e garantir que o guix use o local correto, precisamos instruí-lo a usar os dados de local fornecidos pelo Guix (veja Configuração de aplicativo em Manual de Referência do GNU Guix):

GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
export GUIX_LOCPATH

# Aqui, devemos usar um nome de localidade válido. Tente "ls $GUIX_LOCPATH/*"
# para ver quais nomes podem ser usados.
LC_ALL=fr_FR.utf8
export LC_ALL

Por conveniência, guix package gera automaticamente ~/.guix-profile/etc/profile, que define todas as variáveis de ambiente necessárias para usar os pacotes—PATH, C_INCLUDE_PATH, PYTHONPATH, etc. Da mesma forma, guix pull faz isso em ~/.config/guix/current. Portanto, é uma boa ideia obter ambos de /etc/profile:

for GUIX_PROFILE in "$HOME/.config/guix/current" "$HOME/.guix-profile"
do
  if [ -f "$GUIX_PROFILE/etc/profile" ]; then
    . "$GUIX_PROFILE/etc/profile"
  fi
done

Por último, mas não menos importante, o Guix fornece conclusão de linha de comando, notavelmente para Bash e zsh. Em /etc/bashrc, considere adicionar esta linha:

. /var/guix/profiles/per-user/root/current-guix/etc/bash_completion.d/guix

Voilà!

Você pode verificar se tudo está no lugar efetuando login em um nó de computação e executando:

guix install hello

O daemon no nó principal deve baixar binários pré-compilados em seu nome e descompactá-los em /gnu/store, e guix install deve criar ~/.guix-profile contendo o comando ~/.guix-profile/bin/hello.

9.3 Acesso à rede

Guix requer acesso à rede para baixar código-fonte e binários pré-construídos. A boa notícia é que somente o nó principal precisa disso, já que nós de computação simplesmente delegam a ele.

É costume que nós de cluster tenham acesso, na melhor das hipóteses, a uma white list de hosts. Nosso nó principal precisa de pelo menos ci.guix.gnu.org nessa lista branca, pois é de lá que ele obtém binários pré-construídos por padrão, para todos os pacotes que estão no Guix propriamente dito.

A propósito, ci.guix.gnu.org também serve como um content-addressed mirror do código-fonte desses pacotes. Consequentemente, é suficiente ter unicamente ci.guix.gnu.org nessa lista branca.

Pacotes de software mantidos em um repositório separado, como um dos vários canais HPC, obviamente não estão disponíveis em ci.guix.gnu.org. Para esses pacotes, você pode querer estender a lista branca de modo que os binários de origem e pré-construídos (assumindo que os servidores desta parte forneçam binários para esses pacotes) possam ser baixados. Como último recurso, os usuários sempre podem baixar o código-fonte em sua estação de trabalho e adicioná-lo ao /gnu/store do cluster, assim:

GUIX_DAEMON_SOCKET=ssh://compute-node.example.org \
  guix download http://starpu.gforge.inria.fr/files/starpu-1.2.3/starpu-1.2.3.tar.gz

O comando acima baixa starpu-1.2.3.tar.gz e o envia para a instância guix-daemon do cluster via SSH.

Clusters com air-gapped exigem mais trabalho. No momento, nossa sugestão seria baixar todo o código-fonte necessário em uma estação de trabalho executando Guix. Por exemplo, usando a opção --sources de guix build (veja Invocando guix build em Manual de Referência do GNU Guix), o exemplo abaixo baixa todo o código-fonte do qual o pacote openmpi depende:

$ guix build --sources=transitive openmpi

…

/gnu/store/xc17sm60fb8nxadc4qy0c7rqph499z8s-openmpi-1.10.7.tar.bz2
/gnu/store/s67jx92lpipy2nfj5cz818xv430n4b7w-gcc-5.4.0.tar.xz
/gnu/store/npw9qh8a46lrxiwh9xwk0wpi3jlzmjnh-gmp-6.0.0a.tar.xz
/gnu/store/hcz0f4wkdbsvsdky3c0vdvcawhdkyldb-mpfr-3.1.5.tar.xz
/gnu/store/y9akh452n3p4w2v631nj0injx7y0d68x-mpc-1.0.3.tar.gz
/gnu/store/6g5c35q8avfnzs3v14dzl54cmrvddjm2-glibc-2.25.tar.xz
/gnu/store/p9k48dk3dvvk7gads7fk30xc2pxsd66z-hwloc-1.11.8.tar.bz2
/gnu/store/cry9lqidwfrfmgl0x389cs3syr15p13q-gcc-5.4.0.tar.xz
/gnu/store/7ak0v3rzpqm2c5q1mp3v7cj0rxz0qakf-libfabric-1.4.1.tar.bz2
/gnu/store/vh8syjrsilnbfcf582qhmvpg1v3rampf-rdma-core-14.tar.gz
…

(Caso você esteja se perguntando, isso é mais de 320 MiB de código-fonte compactado.)

Podemos então criar um grande arquivamento contendo tudo isso (veja Invocando guix archive em Manual de Referência GNU Guix):

$ guix archive --export \
    `guix build --sources=transitive openmpi` \
    > openmpi-source-code.nar

… e podemos eventualmente transferir esse arquivamento para o cluster em armazenamento removível e descompactá-lo lá:

$ guix archive --import < openmpi-source-code.nar

Esse processo precisa ser repetido toda vez que um novo código-fonte precisa ser trazido para o cluster.

Enquanto escrevemos isso, os institutos de pesquisa envolvidos no Guix-HPC não têm clusters air-gapped. Se você tem experiência com essas configurações, gostaríamos de ouvir feedback e sugestões.

9.4 Uso do Disco

Uma preocupação comum dos administradores de sistemas é se tudo isso vai consumir muito espaço em disco. Se alguma coisa vai esgotar o espaço em disco, serão conjuntos de dados científicos em vez de software compilado — essa é nossa experiência com quase dez anos de uso do Guix em clusters HPC. No entanto, vale a pena dar uma olhada em como o Guix contribui para o uso do disco.

Primeiro, ter várias versões ou variantes de um determinado pacote em /gnu/store não custa necessariamente muito, porque guix-daemon implementa a desduplicação de arquivos idênticos, e as variantes de pacote provavelmente terão vários arquivos em comum.

Conforme mencionado acima, recomendamos ter um cron job para executar guix gc periodicamente, o que remove o software não utilizado de /gnu/store. No entanto, sempre há a possibilidade de que os usuários mantenham muitos softwares em seus perfis, ou muitas gerações antigas de seus perfis, que são “ativos” e não podem ser excluídos do ponto de vista do guix gc.

A solução para isso é que os usuários removam regularmente gerações antigas de seus perfis. Por exemplo, o comando a seguir remove gerações com mais de dois meses de idade:

guix package --delete-generations=2m

Da mesma forma, é uma boa ideia convidar os usuários a atualizarem regularmente seus perfis, o que pode reduzir o número de variantes de um determinado software armazenado em /gnu/store:

guix pull
guix upgrade

Como último recurso, é sempre possível para os administradores de sistemas fazerem parte disso em nome de seus usuários. No entanto, um dos pontos fortes do Guix é a liberdade e o controle que os usuários têm sobre seu ambiente de software, então recomendamos fortemente deixar os usuários no controle.

9.5 Considerações de segurança

Em um cluster HPC, o Guix é normalmente usado para gerenciar software científico. Softwares críticos de segurança, como o kernel do sistema operacional e serviços do sistema, como sshd e o agendador de lotes, permanecem sob o controle dos administradores de sistema.

O projeto Guix tem um bom histórico de entrega de atualizações de segurança em tempo hábil (veja Atualizações de segurança em Manual de Referência do GNU Guix). Para obter atualizações de segurança, os usuários precisam executar guix pull && guix upgrade.

Como o Guix identifica exclusivamente variantes de software, é fácil ver se um pedaço vulnerável de software está em uso. Por exemplo, para verificar se a variante glibc 2.25 sem o patch de mitigação contra “Stack Clash”, pode-se verificar se os perfis de usuário fazem referência a ela:

guix gc --referrers /gnu/store/…-glibc-2.25

Isso informará se existem perfis que se referem a essa variante glibc específica.