Erstellen eines Paket-Repositorys unter Linux : Fedora und Debian
Einleitung
Dieser Artikel ist die logische Fortsetzung unseres PXE-Artikels, denn nachdem Sie dies gelesen haben, werden Sie in der Lage sein, über das Netzwerk zu booten UND die Distribution Ihrer Wahl tatsächlich zu installieren. Es gibt jedoch auch andere Verwendungszwecke, um ein eigenes Repository zu erstellen. Zum Beispiel Bandbreite. Wenn Sie ein Netzwerk verwalten und auf allen Systemen (oder einigen) dieselbe Verteilung ausgeführt wird, ist es für Sie einfacher, einfach in Verbindung mit einem nahegelegenen Spiegel zu resynchronisieren und Updates selbst bereitzustellen. Als nächstes haben Sie vielleicht einige Pakete von Ihnen erstellt, die Ihre Distribution im Hauptbaum nicht akzeptiert, aber die Benutzer finden sie nützlich. Holen Sie sich einen Domainnamen, richten Sie einen Webserver ein und los geht's. Wir werden hier nicht auf die Einrichtung eines Webservers eingehen, sondern nur auf grundlegende Installationsaufgaben und die grundlegende Einrichtung eines Repositorys für Fedora- oder Debian-Systeme. Daher wird von Ihnen erwartet, dass Sie über die notwendige Hardware (den Server und die notwendige Netzwerkausrüstung, je nach Situation) und einige Kenntnisse über Linux und Webserver verfügen. Also, fangen wir an.
Anmerkung:Dieser Artikel wurde von unserer vorherigen Domain linuxcareer.com verschoben.
Erstellen eines Repositorys auf Fedora-Systemen
Installieren der Tools
Fedora verfügt über ein Tool namens createrepo, das die anstehende Aufgabe vereinfacht. Alles, was wir also installieren müssen, ist das und httpd als Webserver:
# yum install createrepo httpd Einrichten der Repositories
Nachdem wir Ihren Webserver eingerichtet haben, gehen wir nun davon aus, dass das Stammverzeichnis ar /var/www ist. Wir müssen die notwendigen Verzeichnisse in einer organisierten Angelegenheit erstellen (fühlen Sie sich frei, sie bei Bedarf nach Geschmack anzupassen oder einfach dem offiziellen Layout zu folgen):
# cd /var/www/html
# mkdir -p fedora/15/x86_64/base
# mkdir fedora/15/x86_64/updates
Das war's fürs Erste. Alles, was wir tun müssen, ist, die erstellten Ordner zu resynchronisieren und sicherzustellen, dass wir genügend Speicherplatz zur Verfügung haben:
# rsync -avrt rsync://ftp.heanet.ie/pub/fedora/linux/releases/15/Everything\
/x86_64/os/Packages/ /var/www/html/fedora/15/x86_64/base
Verwenden Sie nun createrepo für den Basisordner:
# createrepo /var/www/html/fedora/15/x86_64/base
Dies ist zwingend erforderlich, da dadurch das repodata-Verzeichnis erstellt wird, das yum benötigt, wenn es Ihr Repository verwendet. Wiederholen wir nun den gleichen Schritt wie oben, aber dieses Mal erhalten wir die Updates:
# rsync -avrt rsync://ftp.heanet.ie/pub/fedora/linux/\
updates/15/x86_64/ /var/www/html/fedora/15/x86_64/updates
Zum Schluss empfehlen wir Ihnen, zu überprüfen, ob httpd so eingestellt ist, dass es beim Booten startet, und auch cron zu verwenden, um regelmäßig Updates zu erhalten:
# systemctl enable httpd.service
# crontab -e
Denken Sie daran, dass der hinzuzufügende rsync-Befehl der zweite ist, der sich auf Updates bezieht, und dass systemctl nur auf Fedora 15 oder höher verfügbar ist. Verwenden Sie ntsysv oder chkconfig auf älteren Fedora-Systemen.
Client-Einrichtung
Sie müssen den Computern, die Updates von Ihrem Server erhalten, mitteilen, wo sie zu finden sind, also beginnen wir mit der Erstellung der .repo-Dateien:
this will be base-lan.repo
[base-lan]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://192.168.1.2/fedora/$releasever/$basearch/base
enabled=1
Make sure you disable the official .repo files with enabled=0
gpgcheck=0
this will be updates-lan.repo
[updates-lan]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
baseurl=http://192.168.1.2/fedora/$releasever/$basearch/updates
gpgcheck=0
Machen Sie jetzt einfach eine
# yum update
und schon kann es losgehen.
Signieren von Paketen
Wie einer unserer Leser darauf hingewiesen hat, sollte man sich bei der Installation von Paketen über Sicherheitsprobleme im Klaren sein. Software kann von kompromittierten Servern heruntergeladen werden und bösartige ausführbare Dateien enthalten. Yum (und apt, zypper und andere Paketverwaltungssysteme) überwindet dieses Problem durch die Verwendung von GPG-Schlüsseln. Wir haben über das Spiegeln eines Fedora-Repositorys gesprochen. Diese Pakete sind bereits signiert, und die Schlüssel können in /etc/pki/rpm-gpg gefunden werden. Wenn Sie jemals ein offizielles Fedora-Repository als Client verwendet haben, bevor Sie Ihre lokalen Repositories aktiviert haben, enthält dieses Verzeichnis bereits die erforderlichen Schlüssel. Wenn nicht, können die Schlüssel von getfedora.org/keys/ heruntergeladen werden. Jetzt müssen wir unsere .repo-Dateien ändern, um gpgcheck zu aktivieren und yum mitzuteilen, wo sich die Schlüssel befinden.
These are the only lines that need to be changed
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
Wenn Sie ein lokales Repository für benutzerdefinierte Pakete verwenden, wird sich yum darüber beschweren, dass Ihre benutzerdefinierten Pakete nicht signiert sind. Sie können entweder das yum-Flag –nogpgcheck verwenden, wenn Sie der Betreuer des Spiegels/Repositorys sind und nur Pakete für Ihre Organisation bereitstellen, oder auf sichere Weise auch die benutzerdefinierten Pakete signieren. Dies liegt daran, dass der Server, auf dem sich das benutzerdefinierte/lokale Repository befindet, ebenfalls kompromittiert sein kann. Sie müssen also einen GPG-Schlüssel auf dem Server erstellen und rpm verwenden, um das benutzerdefinierte Paket zu signieren:
gpg --gen-key
gpg --list-sigs
Wie Sie sehen können, lautet die USERID in unserem Fall "Linux Career <user@linuxcareer.com>". Nun zur Veröffentlichung des Wichtigen:
$ gpg --armor --export "USERID" > my.key.file.asc
$ gpg --keyserver pgp.mit.edu --send-key "USERID"
Natürlich wird Ihre USERID unterschiedlich sein, also ändern Sie die Informationen entsprechend. Beachten Sie, dass auf Fedora 16, auf dem wir dies getestet haben, die ausführbare Datei gpg2 anstelle von gpg heißt.
Wir müssen nur eine .rpmmacros-Datei im Home-Verzeichnis des Benutzers erstellen, der die Pakete signieren wird, und Folgendes dort einfügen:
%_signature gpg
%_gpg_name USERID
%_gpgbin /usr/bin/gpg2
Der Befehl zum Signieren eines Pakets lautet nun, da alles festgelegt ist:
$ rpm --addsign name_of_package.rpmJetzt verwendet der Client, der von Ihrem benutzerdefinierten Repository herunterlädt, 'rpm –import $key", um diese benutzerdefinierten Pakete herunterladen zu können.
Erstellen eines Repositorys auf Debian-Systemen
Installation
Da die Repository-Struktur von Debian verworrener ist, werden Sie feststellen, dass es auf der Serverseite etwas mehr Arbeit erfordert, aber weniger auf der Client-Seite. Zu jeder Zeit wird es drei Abschnitte geben: stable, testing und unstable (experimentelle nicht mitgezählt), die jeweils drei Komponenten haben, je nachdem, wie Pakete lizenziert sind: main, contrib und non-free. Es ist Ihre Entscheidung, welchen Teil der Distribution Sie gespiegelt haben möchten, aber es ist unsere Pflicht, Sie zu warnen: Debian hat viel mehr Pakete zu bieten als Fedora, so dass der Speicherplatzbedarf erheblich steigen wird. Es gibt viele Tools, die Sie verwenden können, um ein benutzerdefiniertes Repository mit Ihren eigenen benutzerdefinierten Paketen zu erstellen, aber wir werden uns vorerst an offizielle Pakete halten. Daher kehren wir zu unserem Setup für den PXE-Artikel zurück und erstellen ein lokales Repository für die Installation. Wir benötigen einen Webserver, also installieren wir ihn:
# aptitude install apache2
Stellen Sie sicher, dass Apache konfiguriert und gestartet ist, bevor Sie fortfahren.
Einrichtung des Servers
Das Standard-Root-Verzeichnis, genau wie in Fedora, ist /var/www, also lassen Sie uns dort ein Debian-Verzeichnis erstellen:
# mkdir /var/www/debian
Die Debian-Leute empfehlen ftpsync, eine Sammlung von Perl-Skripten, die Ihnen helfen sollen, das, was Sie brauchen, auf Ihren lokalen Spiegel zu bekommen. Von besonderem Interesse ist die Option --exclude, da Sie nicht den gesamten Inhalt eines Debian-Archivs erhalten möchten (nur amd64, nur main und contrib, nur squeeze, ohne CDs, etc.). Wenn Sie ein Repository erstellen möchten, das nach der Installation verwendet werden soll, verweisen Sie einfach Ihre /etc/apt/sources.list auf das Verzeichnis, das die Pakete enthält (Sie haben dort bereits ein funktionierendes Modell) und das war's. Zum Beispiel:
deb http://192.168.1.2/debian squeeze main contrib
Aber sehen wir uns im Detail an, was Sie herunterladen müssen, wenn Sie keine Lust haben, ftpsync zu verwenden. Debian (und Ubuntu, und wahrscheinlich auch andere Debian-Derivate) haben ein Paket namens apt-utils, das unter anderem das Programm apt-ftparchive anbietet, das wir für unser benutzerdefiniertes Repository verwenden werden. Also...
# aptitude install apt-utils
wird das erforderliche Tool auf Ihrem System installiert. Wir haben das Basisverzeichnis bereits auf unserem Webserver erstellt, daher benötigen wir Unterverzeichnisse, die auf unsere Bedürfnisse zugeschnitten sind:
# cd /var/www/debian
# mkdir -p pool/main
# mkdir pool/contrib
# mkdir -p dists/squeeze/main/binary-amd64
# mkdir -p dists/squeeze/contrib/binary-amd64
# mkdir .cache
Nun, da wir die Verzeichnisstruktur eingerichtet haben, erstellen wir die notwendigen Konfigurationsdateien, um apt-ftparchive zu helfen, unsere Software zu finden und zu indizieren. Bitte beachten Sie, dass Sie dieses Setup verwenden können, um offizielle Debian-Pakete zu spiegeln oder ein Repository mit Ihren eigenen Paketen zu erstellen, da die Schritte gleich sind.
Die erste der beiden Dateien, die wir erstellen müssen (beide werden in /var/www/debian leben), heißt apt-release.conf.
# cd /var/www/debian
# $editor apt-release.conf
Der Inhalt, der sich auf unsere Bedürfnisse bezieht, wie oben gezeigt, würde wie folgt aussehen:
APT::FTPArchive::Release::Codename "squeeze";
APT::FTPArchive::Release::Origin "linuxcareer.com";
APT::FTPArchive::Release::Components "main contrib";
APT::FTPArchive::Release::Label "Linuxcareer.com Debian Repo";
APT::FTPArchive::Release::Architectures "amd64";
APT::FTPArchive::Release::Suite "squeeze";
Sie können auch apt-ftparchive verwenden, um Konfigurationsdateien basierend auf den Befehlszeilenargumenten zu generieren. Verwenden Sie den Ansatz, den Sie bevorzugen.
Die zweite Konfigurationsdatei heißt apt-ftparchive.conf und ihr Inhalt würde wie folgt aussehen:
Dir {
ArchiveDir ".";
CacheDir "./.cache";
};
Default {
Packages::Compress ". gzip bzip2";
Contents::Compress ". gzip bzip2";
};
TreeDefault {
BinCacheDB "packages-$(SECTION)-$(ARCH).db";
Directory "pool/$(SECTION)";
Packages "$(DIST)/$(SECTION)/binary-$(ARCH)/Packages";
Contents "$(DIST)/Contents-$(ARCH)";
};
Tree "dists/squeeze" {
Sections "main contrib";
Architectures "amd64";
}
Wie Sie sehen können, ist die Syntax in Bezug auf beide Dateien sehr selbsterklärend.
Zum Beispiel laden wir nun eine .deb von einem Debian-Spiegelserver herunter, um unsere Idee richtig zu veranschaulichen.
# cd /var/www/debian/pool/main
# wget -c ftp://ftp.heanet.ie/mirrors/ftp.debian.org/debian/pool/main/\
p/patch/patch_2.6.1.85-423d-3_amd64.deb
Lassen Sie uns nun den Inhalt generieren (dies muss jedes Mal wiederholt werden, wenn Sie Pakete hinzufügen oder entfernen).
# cd /var/www/debian
# apt-ftparchive generate apt-ftparchive.conf
# apt-ftparchive -c apt-release.conf release dists/squeeze > \
dists/squeeze/Release
Diese Aktionen führten das aus, was als "Erstellen des Repositorys" bezeichnet wird. Fügen Sie nun, wie oben beschrieben, eine Zeile zu Ihrer sources.list hinzu und Sie können auf Ihr Software-Repository zugreifen. Sollten Sie ein Debian-Spiegelserver werden müssen und immer noch keine Lust auf ftpsync haben, verwenden Sie rsync mit dem entfernten Verzeichnis pool/$section und holen Sie sich einen Kaffee oder so. Verwenden Sie auch einen Spiegel, überladen Sie ftp.debian.org bitte nicht.
Signieren von Paketen
Wenn Sie ein CD/DVD-/Blu-Ray-Image verwenden möchten, um Ihren Clients Inhalte bereitzustellen, ist die Release-Datei auf den optischen Medienimages standardmäßig nicht signiert. Wenn Sie jedoch den Inhalt eines Spiegels resynchronisieren, müssen Sie wahrscheinlich nichts tun. Wenn Sie über ein benutzerdefiniertes Repository verfügen, gehen Sie wie folgt vor. Generieren Sie zunächst, wie im Fedora-Beispiel, den GPG-Schlüssel:
$ gpg --gen-key
Jetzt, wegen des Fehlers #639204 in Debsign (letzte Aktualisierung im August), scheint es, dass wir einen alternativen Weg einschlagen müssen. Da Debian-Pakete im Grunde nur ar-Archive sind, werden wir den niedrigeren Weg verwenden, um unsere Pakete zu signieren:
$ ar x package_name.deb
$ cat debian-binary control.tar.gz data.tar.gz > tempfile
$ gpg -abs -o _gpgorigin tempfile
$ ar rc package_name.deb _gpgorigin debian-binary control.tar.gz data.tar.gz
Also, was wir hier gemacht haben, war, die .deb Datei mit ar zu eXtractieren, ihren Inhalt mit einer temporären Datei zu verketten (achten Sie auf die Reihenfolge), diese Datei zu signieren und dann die .deb in ihren ursprünglichen Zustand zurückzuversetzen. Jetzt müssen wir den GPG-Schlüssel exportieren (wie Sie sehen können, unterscheidet sich der Prozess nicht so sehr von dem, der auf Fedora angewendet wird).
$ gpg --export -a > mydebsign.asc
Lassen Sie uns nun den Schlüssel für die weitere Verwendung extrahieren:
$ gpg --fingerprint
Merken Sie sich die letzten vier Gruppen im Schlüssel-Fingerabdruck (wie unten zu sehen), da dies die Schlüssel-ID ist, die wir später verwenden werden.
Stellen Sie auf dem Clientcomputer sicher, dass debsig-verify installiert ist, und erstellen Sie dann einen Ort für den Schlüssel:
# mkdir /usr/share/debsig/keyrings/$key_id
Wie Sie im Screenshot sehen können, lautet unsere Beispielschlüssel-ID 8760C540B4FC5C21. Importieren wir nun den Schlüssel:
# gpg --no-default-keyring --keyring \
/usr/share/debsig/keyrings/$key_id/debsign.gpg --import mydebsign.asc
Jetzt kommt der knifflige Teil: Wir benötigen eine Richtliniendatei für die Schlüssel. Die verwendete Sprache ist XML, aber keine Sorge: In /usr/share/doc/debisg-verify/examples finden Sie eine Datei namens generic.pol, die irgendwo hinkopiert werden kann, um bearbeitet und umbenannt zu werden. Ein Beispiel für eine solche Datei könnte wie folgt aussehen:
<Policy xmlns="http://www.debian.org/debsig/1.0/">
<Origin Name="Linux Career" id="8760C540B4FC5C21"
Description="Package offered by Linux Career"/>
<Selection>
<Required Type="origin" File="debsign.gpg" id="8760C540B4FC5C21"/>
</Selection>
<Verification MinOptional="0">
<Required Type="origin" File="debsign.gpg" id="8760C540B4FC5C21"/>
</Verification>
</Policy>Was Sie oben sehen, ist nur der wesentliche Teil der Richtliniendatei. Nachdem Sie das Beispiel überprüft und die erforderlichen Änderungen vorgenommen haben, speichern Sie diese Datei in /etc/debsig/policies/$key_id/$policy_name.pol. Wenn Sie nach diesem Schritt die Schritte korrekt ausgeführt haben, können Sie debsig-verify mit dem Paketnamen als Argument verwenden, um Ihre heruntergeladenen Pakete zu überprüfen. Vielen Dank an PurpleFloyd für seinen hilfreichen Artikel zu diesem Thema.
Client-Einrichtung
Starten wir also unseren Client-Rechner, stellen Sie sicher, dass er für das Booten aus dem Netzwerk eingerichtet ist, und wählen Sie, wenn Sie aufgefordert werden, einen Spiegel auszuwählen, "Informationen manuell eingeben". Geben Sie die IP Ihres Servers ein, dann den Standort relativ zu /var/www (in unserem Fall Debian) und Sie sollten bereit für die Installation sein.
Schlussfolgerung
Man kann nie genug betonen, wie wichtig es ist, Bandbreite zu sparen, selbst in einem kleinen Netzwerk. Natürlich gibt es noch weitere Vorteile eines Local Mirror-Ansatzes, wie z. B. die Bereitstellung maßgeschneiderter Software für Ihr Unternehmen (spezielle Patches oder einfach nur Änderungen, um den Bedürfnissen des Unternehmens besser gerecht zu werden) oder die Bereitstellung Ihrer Software, die für Ihre bevorzugte Distribution verpackt ist.