COWPOKE(1) General Commands Manual COWPOKE(1)
BEZEICHNUNG
cowpoke - baut ein Debian-Quellpaket in einer fernen Cowbuilder-Instanz
ÜBERSICHT
cowpoke [Optionen] Paketname.dsc
BESCHREIBUNG
lädt ein Debian-Quellpaket auf einen cowbuilder-Rechner hoch und baut
es, wahlweise signiert es außerdem das Ergebnis und lädt es in eine
»incoming«-Warteschlange hoch.
OPTIONEN
Die folgenden Optionen sind verfügbar:
--arch=Architektur
gibt die Debian-Architektur(en) an, für die gebaut wird. Es kann
eine durch Leerzeichen getrennte Liste von Architekturen benutzt
werden, um für alle in einem einzigen Durchgang zu bauen. Gül-
tige Architekturnamen sind jene, die durch dpkg-architecture(1)
für DEB_BUILD_ARCH zurückgegeben werden.
--dist=Distribution
gibt die Debian-Distribution(en) an, für die gebaut wird. Es
kann eine durch Leerzeichen getrennte Liste von Distributionen
benutzt werden, um für alle in einem einzigen Durchgang zu
bauen. Es können entweder Codenamen (wie sid oder squeeze) oder
Distributionsnamen (wie unstable oder experimental) verwendet
werden, aber Sie sollten üblicherweise durchgehend dabei blei-
ben, den einen oder anderen zu benutzen, da dieser Name in Da-
teipfaden benutzt wird und um alte Pakete für Vergleichsberichte
zu orten.
Es ist nun auch möglich, mit dieser Option lokal definierte Na-
men zu benutzen, wenn sie zusammen mit der Option BASE_DIST in
einer Konfigurationsdatei verwendet werden. Dies erlaubt die
Verwaltung und Benutzung eigens konfigurierter Bau-Chroots, die
Paketabhängigkeiten aus den Backports-Archiven oder einem loka-
len Depot beziehen können. Außerdem sind andere ungewöhnliche
Optionszusammenstellungen möglich, ohne die Chroots zu verunrei-
nigen, die zum sauberen Bauen und Hochladen in die Hauptdepots
gedacht sind. Lesen Sie die die Beschreibung von BASE_DIST wei-
ter unten.
--buildd=Rechner
gibt den fernen Rechner an, auf dem gebaut werden soll.
--buildd-user=Name
gibt den fernen Benutzernamen an, unter dem gebaut wird.
--create
erstellt das ferne cowbuilder-Wurzelverzeichnis, falls es noch
nicht existiert. Falls diese Option nicht übergeben wird, ist es
für die angegebene --dist oder --arch ein Fehler, über kein exi-
stierendes cowbuilder-Wurzelverzeichnis an der erwarteten Stelle
zu verfügen.
Der --buildd-user muss das Recht haben, auf dem Baurechner das
RESULT_DIR zu erstellen oder ein Administrator mit den nötigen
Rechten muss es zuerst erstellen und diesem Benutzer (oder einer
Gruppe, der er angehört) Schreibzugriff darauf geben, damit
diese Option erfolgreich ist.
--return=[Pfad
kopiert Ergebnisse des Bauens nach Pfad. Falls Pfad nicht ange-
geben wurde, dann werden sie an das aktuelle Verzeichnis zurück-
gegeben. Der angegebene Pfad muss existieren, er wird nicht er-
stellt.
--no-return
kopiert Ergebnisse des Bauens nicht nach RETURN_DIR (setzt eine
Pfadeinstellung hierfür in den Konfigurationsdateien außer
Kraft).
--dpkg-opts='Option1 Option2 …'
gibt zusätzliche Optionen an, die an dpkg-buildpackage(1) über-
geben werden. Mehrere Optionen werden durch Leerzeichen ge-
trennt. Dies wird alle in DEBBUILDOPTS angegebenen Optionen in
der pbuilderrc des Baurechners außer Kraft setzen.
--create-opts='Cowbuilder-Option'
gibt zusätzliche Argumente an, die unverändert an Cowbuilder
weitergereicht werden, wenn eine Chroot zum ersten Mal (mittels
der obigen Option --create) erstellt wird. Falls mehrere Optio-
nen weitergereicht werden müssen, sollte diese Option separat
für jede einzelne angegeben werden.
Z.B. --create-opts "--othermirror" --create-opts "deb http://…"
Diese Option wird jede für eine Chroot in den Cowpoke-Konfigura-
tionsdateien angegebene CREATE_OPTS außer Kraft setzen.
--update-opts='Cowbuilder-Option'
gibt zusätzliche Argumente an, die unverändert an Cowbuilder
weitergereicht werden, wenn die Chroot aktualisiert wird. Falls
mehrere Optionen weitergereicht werden müssen, sollte diese Op-
tion separat für jede einzelne angegeben werden.
Diese Option wird jede für eine Chroot in den Cowpoke-Konfigura-
tionsdateien angegebene UPDATE_OPTS außer Kraft setzen.
--build-opts='Cowbuilder-Option'
gibt zusätzliche Argumente an, die unverändert an Cowbuilder
weitergereicht werden, wenn ein Paket gebaut wird. Falls mehrere
Optionen weitergereicht werden müssen, sollte diese Option sepa-
rat für jede einzelne angegeben werden.
Diese Option wird jede für eine Chroot in den Cowpoke-Konfigura-
tionsdateien angegebene BUILD_OPTS außer Kraft setzen.
--sign=Schlüsselkennung
gibt den Schlüssel an, mit dem Pakete signiert werden. Dies wird
jedes SIGN_KEYID, das für eine Chroot in den Cowpoke-Konfigura-
tionsdateien angegeben wurde, außer Kraft setzen.
--upload=Warteschlange
gibt die Dput-Warteschlange an, in die signierte Pakete hochge-
laden werden. Dies wird jede UPLOAD_QUEUE, die für eine Chroot
in den Cowpoke-Konfigurationsdateien angegeben wurde, außer
Kraft setzen.
--help zeigt eine kurze Zusammenfassung der verfügbaren Optionen und
der aktuellen Konfiguration.
--version
zeigt die aktuelle Versionsinformation.
KONFIGURATIONSOPTIONEN
Wenn cowpoke ausgeführt wird, werden die folgenden Optionen von globa-
len, benutzer- und objektbezogenen Konfigurationsdateien gelesen, falls
vorhanden. Dateipfade können absolut oder relativ sein, letztere sind
zum BUILDD_USER-Home-Verzeichnis relativ. Da die Pfade bei der Benut-
zung typischerweise in Anführungszeichen stehen, wird darauf keine
Tilde-Expandierung durchgeführt.
Globale Vorgaben
Dies gilt für jede Architektur und Distribution in einem einzelnen Cow-
poke-Aufruf.
BUILDD_HOST
die Netzwerkadresse oder FQDN der Baumaschine auf der cowbuilder
konfiguriert ist. Dies könnte durch die Befehlszeilenoption
--buildd außer Kraft gesetzt werden.
BUILDD_USER
der nicht privilegierte Benutzername für Operationen auf der
Baumaschine. Dies ist standardmäßig der lokale Name des Benut-
zers, der cowpoke ausführt (oder ein Benutzername, der in der
SSH-Konfiguration für BUILDD_HOST angegeben wurd), und kann
durch die Befehlszeilenoption --buildd-user außer Kraft gesetzt
werden.
BUILDD_ARCH
die Debian-Architektur(en), für die gebaut wird. Dies muss zu
DEB_BUILD_ARCH der benutzten Bau-Chroot passen. Standardmäßig
ist es die Architektur des lokalen Rechners, auf der cowpoke
ausgeführt wird. Sie könnte durch die Befehlszeilenoption --arch
außer Kraft gesetzt werden. Hier könnte eine durch Kommas ge-
trennte Liste (in Anführungszeichen) verwendet werden, um um für
alle hieraus in einem einzigen Durchgang zu bauen.
BUILDD_DIST
die Debian-Distribution(en), für die gebaut wird. Eine durch
Leerzeichen getrennte Liste von Distributionen (in Anführungs-
zeichen) kann benutzt werden, um alle in einem einzigen Durch-
gang zu bauen. Dies könnte durch die Befehlszeilenoption --dist
außer Kraft gesetzt werden.
INCOMING_DIR
der Installationspfad auf der Baumaschine, in der das Quellpaket
anfangs platziert wird. Dies muss durch den BUILDD_USER schreib-
bar sein.
PBUILDER_BASE
die Wurzel des Dateisystems für alle Pbuilder-COW- und Ergebnis-
dateien. Architektur- und distributionsspezifische Unterver-
zeichnisse werden normalerweise darunter erstellt. Der APT-Zwi-
schenspeicher und die temporären Bauverzeichnisse werden ebenso
unterhalb dieses Pfads liegen.
SIGN_KEYID
Falls diese Option gesetzt ist, wird erwartet, dass sie die
GPG-Schlüsselkennung zur Übergabe an debsign(1) enthält, falls
die Pakete aus der Ferne signiert werden sollen. Sie werden um
Bestätigung gebeten, ob Sie die Pakete signieren möchten, nach-
dem das Bauen aller Pakete abgeschlossen ist. Falls diese Option
nicht gesetzt oder eine leere Zeichenkette ist, wird kein Ver-
such unternommen, Pakete zu signieren. Sie kann auf einer Archi-
tektur- oder Distributionsspezifischen Basis mittels der weiter
unten beschriebenen Option Architektur_Distribution_SIGN_KEYID
oder jeweils beim Aufruf mit der Befehlszeilenoption --sign au-
ßer Kraft gesetzt werden.
UPLOAD_QUEUE
Falls diese Option gesetzt ist, wird erwartet, dass sie eine
»host«-Angabe für dput(1) enthält, die verwendet wird, um sie
nach dem Signieren hochzuladen. Sie werden um Bestätigung gebe-
ten, ob Sie die Pakete nach dem Signieren hochladen möchten.
Falls diese Option nicht gesetzt oder eine leere Zeichenkette
ist, wird kein Versuch unternommen, diese Pakete hochzuladen.
Falls SIGN_KEYID nicht gesetzt ist, wird diese Option ganz igno-
riert. Sie kann auf einer architektur- oder distributionsspezi-
fischen Basis mittels der weiter unten beschriebenen Option Ar-
chitektur_Distribution_UPLOAD_QUEUE oder jeweils beim Aufruf mit
der Befehlszeilenoption --upload außer Kraft gesetzt werden.
BUILDD_ROOTCMD
der Befehl, der zum Erlangen von Root-Rechten auf der fernen
Baumaschine benutzt wird. Falls nicht gesetzt, ist die Vorgabe
sudo(8). Dies ist nur nötig, um cowbuilder aufzurufen und ihm zu
erlauben, in seine Chroot zu gelangen, daher könnten Sie diesen
Nutzer darauf beschränken, diesen Befehl mit ausgeweiteten Rech-
ten auszuführen. Ein Eintrag wie der folgende in »sudoers« wird
es ermöglichen, cowbuilder ohne einen zusätzlich nötigen Pass-
worteintrag aufzurufen:
Ihrbenutzer ALL = NOPASSWD: /usr/sbin/cowbuilder
Alternativ könnten Sie SSH mit einem weitergeleiteten Schlüssel
oder irgendeinem anderen Mechanismus, der Ihrer lokalen Zu-
griffsrichtlinie entspricht, verwenden. Die Benutzung von su -c
ist hier nicht wirklich passend, da seine Maskierungsanforderun-
gen sich etwas vom Rest unterscheiden.
DEBOOTSTRAP
das Hilfswerkzeug, das beim Erstellen einer neuen Chroot benutzt
wird. Alternativen sind debootstrap oder cdebootstrap.
RETURN_DIR
Falls gesetzt, werden Paketdateien, die Ergebnis des Bauens
sind, in den Pfad (lokal oder in der Ferne) kopiert, auf den
dies gesetzt ist. Der Pfad muss existieren, er wird nicht ange-
legt. Diese Option ist standardmäßig nicht gesetzt und kann mit
--return oder --no-return überschrieben werden.
Architekur- und distributionsspezifische Optionen
Dies sind Variablen der Form $arch_$dist_VAR, die nur für ein bestimm-
tes Architektur-/Distributions-Bauziel gelten.
Architektur_Distribution_RESULT_DIR
Der Verzeichnispfad auf der Baumaschine, in dem die resultieren-
den (Quell- und Binär-)Pakete abgelegt werden und wo ältere Ver-
sionen der Pakete, die vorher gebaut wurden, gefunden werden
können. Falls irgendwelche derartigen älteren Pakete existieren,
wird debdiff benutzt, um das neue Paket mit der vorhergehenden
Version zu vergleichen, nachdem das Bauen abgeschlossen ist. Das
Ergebnis wird in das Bauprotokoll eingefügt. Dateien darin müs-
sen für den BUILDD_USER für Plausibilitätsprüfungen mit lin-
tian(1) und debdiff(1) und das Hochladen mit dput(1) lesbar
sein. Falls diese Option für irgendwelche Architektur- und Dis-
tributionskombinationen nicht angegeben ist, dann wird $PBUIL-
DER_BASE/$arch/$dist/result vorgegeben.
Architektur_Distribution_BASE_PATH
das Verzeichnis, in dem die CoW-Master-Dateien vorliegen werden
(oder erzeugt werden, falls die Befehlszeilenoption --create
übergeben wurde). Falls diese Option für irgendwelche Architek-
turen und Distributionen nicht angegeben wurde, dann wird
$PBUILDER_BASE/$arch/$dist/base.cow vorgegeben.
Architektur_Distribution_BASE_DIST
der Codename, der anstelle von Distribution als Option --distri-
bution an Cowbuilder übergeben wird. Dies ist nötig, wenn Dis-
tribution ein lokal bedeutsamer Name ist, der irgendeiner spezi-
ell konfigurierten Bau-Chroot wie »wheezy_backports« zugewiesen
wurde und nicht der Debootstrap bekannte offizielle Suite-Name
einer Distributionsveröffentlichung ist. Diese Option kann nicht
auf der Befehlszeile außer Kraft gesetzt werden, da dies selten,
wenn nicht sogar nie, für einzelne Aufrufe von Cowpoke sinnvoll
wäre. Falls diese Option nicht für eine Architektur- und Distri-
butionskombination angegeben wurde, wird als Voreinstellung Dis-
tribution genommen.
Architektur_Distribution_CREATE_OPTS
ein Bash-Feld, das zusätzliche Optionen enthält, die unverändert
an Cowbuilder weitergegeben werden, wenn diese Chroot zum ersten
Mal (mittels der Option --create) erstellt wird. Dies ist nütz-
lich, wenn Optionen wie --othermirror zum Erstellen speziali-
sierter Chroots wie »wheezy_backports« erwünscht werden. Stan-
dardmäßig ist dies nicht gesetzt. Alle darin gesetzten Werte
werden außer Kraft gesetzt, falls auf der Befehlszeile die Op-
tion --create-opts übergeben wird.
Jedes Element dieses Feldes entspricht einem einzelnen Argument
(im Sinne von ARGV), das an Cowbuilder übergeben wird. Dadurch
wird sichergestellt, dass Argumente, die Leerräume enthalten
oder merkwürdige Maskierungsanforderungen oder andere Sonderzei-
chen haben, nicht verwürfelt werden, ehe Cowbuilder sie bekommt.
Die Initialisierung von Bash-Feldern geschieht in folgender
Form:
OPTS=( "Arg1" "Arg 2" "--option" "Wert" "--opt=Wert" "etc.
etc." )
Architektur_Distribution_UPDATE_OPTS
ein Bash-Feld, das zusätzliche Optionen enthält, die jedesmal,
wenn die Basis dieser Chroot aktualisiert wird, unverändert an
Cowbuilder weitergereicht werden. Es verhält sich ähnlich der
oben beschriebenen CREATE_OPTS-Optionen, außer dass es beim Ak-
tualisieren der Chroot tätig wird.
Architektur_Distribution_BUILD_OPTS
ein Bash-Feld, das zusätzliche Optionen enthält, die jedesmal,
wenn in dieser Chroot ein Paket gebaut wird, unverändert an Cow-
builder weitergereicht werden. Dies ist nützlich, wenn Sie Op-
tionen wie --twice verwenden, um die sich Cowpoke nicht direkt
kümmern muss. In anderen Fällen verhält es sich ähnlich der oben
beschriebenen CREATE_OPTS, außer dass es während der Bauphase
von Cowbuilder tätig wird.
Architektur_Distribution_SIGN_KEYID
ein optionales Architektur- und ein distributionsspezifisches
Außer-Kraft-Setzen für die globale Option SIGN_KEYID.
Architektur_Distribution_UPLOAD_QUEUE
ein optionales Architektur- und ein distributionsspezifisches
Außer-Kraft-Setzen für die globale Option UPLOAD_QUEUE
KONFIGURATIONSDATEIEN
/etc/cowpoke.conf
globale Konfigurationsoptionen; setzen die fest kodierten Vorga-
ben außer Kraft
~/.cowpoke
Konfigurationsoptionen pro Benutzer; werden jede globale Konfi-
guration ignorieren
.cowpoke
Konfigurationsoptionen pro Projekt; werden jede Konfiguration
pro Benutzer oder globale Konfiguration überstimmen, falls cow-
poke aus dem Verzeichnis aufgerufen wird, in dem sie existieren.
Falls die Umgebungsvariable COWPOKE_CONF gesetzt ist, gibt sie
eine zusätzliche Konfigurationsdatei an, die alles vorhergehende
außer Kraft setzt. Optionen, die explizit auf der Befehlszeile
angegeben werden, ignorieren alle Konfigurationsdateien.
COWBUILDER-KONFIGURATION
Um eine cowbuilder-Instanz zu konfigurieren. die mit cowpoke benutzt
wird, wird nichts sonderlich Spezielles benötigt. Erstellen Sie sie
einfach in der Variante, die Sie mit »cowbuilder --create« gemäß der
cowbuilder-Dokumentation benötigen. Dann konfigurieren Sie cowpoke mit
dem Benutzer, der Architektur und den zum Zugriff benötigten Pfadinfor-
mationen auf den Rechnern, von denen Sie es aufrufen wollen (oder kon-
figurieren Sie cowpoke alternativ mit dem Pfad, der Architektur und der
Distributionsinformation und übergeben Sie ihm beim ersten Aufruf die
Option --create). Der Baurechner, der cowbuilder ausführt, benötigt
kein lokal installiertes cowpoke.
Auf der Baumaschine sollten die Pakete lintian und devscripts für Plau-
sibilitätsprüfungen nach dem Bauen installiert sein. Nach Beendigung
werden das Bauprotokoll und die Ergebnisse der automatischen Prüfungen
in INCOMING_DIR aufgezeichnet. Falls Sie signierte Pakete hochladen
möchten, wird die Baumaschine außerdem erforden, dass dput(1) instal-
liert und für die Benutzung des durch die UPLOAD_QUEUE angegebenen
Alias »Rechner« konfiguriert ist. Falls rsync(1) sowohl auf der lokalen
als auch auf der Baumaschine verfügbar ist, wird es für die Übertragung
des Quellpakets benutzt (dies könnte bei einigen Übertragungen der
orig.tar.* Bandbreite sparen, wenn aufeinander folgende Debian-Revisio-
nen gebaut werden).
Der Benutzer, der cowpoke ausführt, muss SSH-Zugriff auf die Baumschine
als BUILDD_USER haben. Dieser Benutzer muss in der Lage sein, cowbuil-
der als Root durch Benutzen von BUILDD_ROOTCMD aufzurufen. Zur Instal-
lation auf der Baumaschine werden keine Schlüssel zum Signieren benö-
tigt (und werden ignoriert, wenn sie dort sind). Falls das Paket si-
gniert ist, werden die Schlüssel auf dem Rechner, die cowpoke ausführt,
erwartet.
Wenn cowpoke aufgerufen wird, wird es zuerst versuchen, das cowbuil-
der-Image zu aktualisieren, falls dies nicht bereits am selben Tag ge-
tan wurde. Dies wird durch das Vorhandensein oder Fehlen einer cowbuil-
der-$arch-$dist-update-log-$date-Datei im Verzeichnis INCOMING_DIR ge-
prüft. Sie können die Datei verschieben, entfernen oder mit touch ak-
tualisieren, falls Sie wünschen, dass das Image außerhalb des üblichen
Zyklus aktualisiert wird. Ihr Inhalt protokolliert die Ausgabe von cow-
builder während des Aktualisierens (oder Erstellens) des Bauwurzelver-
zeichnisses.
ANMERKUNGEN
Da cowbuilder eine Chroot erstellt und Sie, um dies zu tun, Root-Rechte
benötigen, erfordert cowpoke außerdem zu einem bestimmten Grad Root-Zu-
griff. Daher ist es denkbar, dass all die schrecklichen Dinge, die da-
bei schiefgehen können, auch bei Ihnen schiefgehen. cowbuilder war be-
kannt dafür, versehentlich Dateisysteme, die mit der Option »bind« au-
ßerhalb der Chroot eingehängt sind, zu vernichten und es ist leicht
möglich, dass noch Schlimmeres passiert. Seien Sie daher vorsichtig,
bewahren Sie gute Sicherheitskopien der Dinge auf, die Sie nicht auf
Ihrer Baumaschine verlieren möchten und verwenden Sie cowpoke, um alles
auf einem Rechner zu verwahren, die nicht Ihre modernste Entwicklerki-
ste mit Ihren letzten paar Stunden nicht übergebener Arbeit ist.
SIEHE AUCH
cowbuilder(1), pbuilder(1), ssh-agent(1), sudoers(5)
AUTOR
cowpoke wurde von Ron <ron@debian.org> geschrieben.
ÜBERSETZUNG
Diese Übersetzung wurde mit dem Werkzeug po4a <URL:https://po4a.org/>
durch Chris Leick c.leick@vollbio.de im Juli 2012 erstellt und vom
deutschen Debian-Übersetzer-Team korrekturgelesen. Bitte melden Sie
alle Fehler in der Übersetzung an debian-l10n-german@lists.debian.org
oder als Fehlerbericht an das Paket devscripts. Sie können mit dem fol-
genden Befehl das englische Original anzeigen »man -L C Abschnitt deut-
sche_Handbuchseite«.
28. April 2008 COWPOKE(1)
Generated by dwww version 1.15 on Sat Jun 29 01:46:24 CEST 2024.