15.3. Å lage en pakkebrønn for APT

Falcot Corp begynte gradvis å vedlikeholde en rekke Debian-pakker, enten lokalt endret fra eksisterende pakker, eller laget fra bunnen av, for å distribuere interne data og programmer.

For å gjøre utplassering lettere ønsker de å integrere disse pakkene i et pakkearkiv som kan brukes direkte av APT. Av åpenbare vedlikeholdsgrunner ønsker de å skille interne pakker fra lokalt ombygde pakker. Målet for de samsvarende oppføringene i en /etc/apt/sources.list.d/falcot.list-fil er som følger:

deb http://packages.falcot.com/ updates/
deb http://packages.falcot.com/ internal/

Administratorene setter derfor opp en virtuell maskin på deres interne HTTP-tjener, med /srv/vhosts/packages/ som roten til det tilhørende nettområdet. Håndteringen av selve arkivet er delegert til mini-dinstall-kommandoen (i den tilsvarende navngitte pakken). Dette verktøyet holder et øye med en incoming/-mappe (i vårt tilfelle, /srv/vhosts/packages/mini-dinstall/incoming/), og venter på nye pakker der; når en pakke er lastet opp, blir den installert i et Debian-arkiv på /srv/vhosts/packages/. Kommandoen mini-dinstall leser *.changes-filen som opprettes når Debian-pakken blir generert. Disse filene inneholder en liste med alle andre filer knyttet til den versjonen av pakken (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz, eller tilsvarende med andre komprimeringsverktøy), og disse åpner for at mini-dinstall får vite hvilke filer som skal installeres. *.changes-filer inneholder også navnet på måldistribusjonen (ofte unstable) nevnt i den siste debian/changelog-inngangen, og mini-dinstall bruker denne informasjonen til å avgjøre hvor pakken skal installeres. Dette er grunnen til at administratorer alltid må endre dette feltet før de bygger en pakke, og setter det til internal, eller updates, avhengig av måldistribusjonen. mini-dinstall genererer deretter filene som kreves av APT, for eksempel Packages.gz.

ALTERNATIV apt-ftparchive, aptly, og reprepro

Hvis mini-dinstall ser for omfattende ut for dine Debian-arkivbehov, kan du også bruke apt-ftparchive-kommandoen. Dette verktøyet skanner innholdet i en katalog, og viser (i sine standard utdata) en samsvarende Packages-fil. I tilfellet Falcot Corp kunne administratorer laste pakkene direkte inn i /srv/vhosts/packages/updates/, eller /srv/vhosts/packages/internal/, og så kjøre de følgende kommandoer for å lage Packages.gz-filene:

$ cd /srv/vhosts/packages
$ apt-ftparchive packages updates >updates/Packages
$ gzip updates/Packages
$ apt-ftparchive packages internal >internal/Packages
$ gzip internal/Packages

Kommandoen apt-ftparchive sources åpner for å lage Sources.gz-filer på en lignende måte.

reprepro and aptly er mer avanserte verktøy tiltenkt samme formål. De kan produsere, håndtere og synkronisere et antall pakkebrønner, speile andre pakkebrønner, og håndplukke pakker fra offisielle pakkebrønner og tilby dem lokalt, opprette signaturer for de genererte pakkeindeksene, og dermed tilby signerte pakkebrønner. reprepro lagrer pakker og sjekksummer i en Berkeley DB-databasefil, slik at ingen databasetjener behøves. aptly tilbyr samme funksjonalitet, men kan også være enklere å håndtere. Beklageligvis er ingen av dem i aktiv utvikling, tross at de har flest funksjoner.

reprepro har mye dokumentasjon og eksempler i /usr/share/doc/reprepro/, mens aptly har rikholdig nettbasert dokumentasjon.

→ https://www.aptly.info/

Å sette opp mini-dinstall krever oppsett av en ~/.mini-dinstall.conf-fil; i Falcot Corp-tilfellet er innholdet som følger:

[DEFAULT]
archive_style = flat
archivedir = /srv/vhosts/packages

verify_sigs = 0
mail_to = admin@falcot.com

generate_release = 1
release_origin = Falcot Corp
release_codename = stable

[updates]
release_label = Recompiled Debian Packages

[internal]
release_label = Internal Packages

En avgjørelse verdt å merke seg er generasjonen Release-filer for hvert arkiv. Dette kan hjelpe til med å administrere pakkeinstallasjonsprioriteringer med hjelp av /etc/apt/preferences-oppsettsfilen (se Seksjon 6.2.5, «Styring av pakkeprioriteter» for detaljer).

SIKKERHET mini-dinstall og tillatelser

Etter at mini-dinstall er designet for å kjøres som en vanlig bruker, er det ikke nødvendig å kjøre den som rot. Den enkleste måten er å sette opp alt innen brukerkontoen som tilhører administratoren med ansvar for å lage Debian-pakker. Ettersom bare denne administratoren har de nødvendige tillatelsene til å sette filer inn i incoming/-katalogen, kan vi utlede at administratoren har autentisert opprinnelsen til hver pakke før utplasseringen, og mini-dinstall trenger ikke å gjøre det igjen. Dette forklarer verify_sigs = 0-parameteret (noe som betyr at signaturene ikke behøver å være bekreftet). Men hvis innholdet i pakkene er sensitivt, kan vi snu innstillingen, og velge å godkjenne en ring med nøkler som inneholder offentlige nøkler til personer med lov til å lage pakker (satt opp med extra_keyrings-parameter); mini-dinstall vil så sjekke opprinnelsen til hver innkommende pakke ved å analysere signaturen integrert i *.changes-filen.

Å påkalle mini-dinstall starter faktisk en bakgrunnsprosess i bakgrunnen. Så lenge denne bakgrunnsprosessen kjører, vil den se etter nye pakker i incoming/-mappen hver halvtime. Når en ny pakke kommer, vil den bli flyttet til arkivet, og riktige Packages.gz og Sources.gz-filer blir fornyet. Hvis det å kjøre en bakgrunnsprosess er et problem, kan og mini-dinstall påkalles manuelt i rekkefølge (med -b-valget) hver gang en pakke blir lastet inn i incoming/-mappen. Andre muligheter som ligger i mini-dinstall er dokumentert på sin mini-dinstall(1)-manualside.

EKSTRA Å generere et signert arkiv

For å sikre autentisiteten kontrollerer APT-pakken en kjede med kryptografiske signaturer for pakkene den håndterer før de installeres (se Seksjon 6.6, «Sjekking av pakkeautensitet»). Private APT-arkiver kan så bli et problem, ettersom maskinene som bruker dem vil holde på med å vise advarsler om usignerte pakker. En flittig administrator vil derfor integrere privatarkiver med den sikre APT-mekanismen.

For å hjelpe til med denne prosessen inkluderer mini-dinstall et release_signscript-oppsettsalternativ som tillater å spesifisere et skript som skal brukes til å generere signaturen. Et godt utgangspunkt er sign-release.sh-skriptet fra mini-dinstall-pakken i /usr/share/doc/mini-dinstall/examples/; lokale endringer kan være relevante.