# /usr/portage über nfs ?

## thengelh

Hallo zusammen,

ich habe einen Server und zwei clients mit Gentoo Linux. In den Clients habe ich nur alte kleine Platten drin und bin schon fast am Anschlag.

Auf dem Server habe ich noch massig Platz. Deshalb meine Idee /usr/portage auf den Server zu legen und über nfs zu mounten.

1.) Spricht irgendwas dagegen ? (auser Performance beim emergen)

2.) Da die Clients die selben Pakete installiert haben kann ich für beide das gleiche Verzeichniss verwenden ?

Danke im vorraus

Thomas

----------

## gerry

Das sollte helfen

http://tobias.scherbaum.info/gentoo/faq/index.php?sid=1097&aktion=artikel&rubrik=004&id=58&lang=de

----------

## amne

Neue URL für die FAQ:

http://www.gentoofaq.org/45-de-2

----------

## xces

 *thengelh wrote:*   

> 1.) Spricht irgendwas dagegen ? (auser Performance beim emergen)

 

Das kompilieren selbst ist nicht langsamer. Lediglich das entpacken des Quelltexts dauert etwas länger, aber das fällt bei einem 100MBit/s oder schnellerem Netzwerk nicht auf.

 *thengelh wrote:*   

> 2.) Da die Clients die selben Pakete installiert haben kann ich für beide das gleiche Verzeichniss verwenden ?

 

Ja. Die Informationen, welche Programme installiert sind, werden in /var/db/pkg/ gespeichert und nicht in /usr/portage. In /usr/portage befinden sich tatsächlich nur die Ebuilds und in /usr/portage/distfiles die heruntergeladenen Archive.

----------

## moe

Habe hier /usr/portage/distfiles per NFS auf meinen Clienten gemountet, dadurch muss ich nicht auf gleiche Hardware und Aktualität der einzelnen Clienten achten. Für den Rest habe ich einen localen rsync-mirror.

Beim Entpacken der Archive dauerts etwas länger, aber dadurch dass man sehr selten etwas aus dem Internetz holen muss, wird die Zeit locker wett gemacht.

Was ich mich schon immer gefragt habe, aber nie wirklich nach ner Antwort gesucht habe: Wenn ich das komplette /usr/portage zentral auslagere, wie sieht es dann mit emerge sync aus? Emerge lädt doch nicht nur ebuilds herunter, sondern aktualisiert noch eine Datenbank, oder? Wenn ich als Client nie emerge sync mache, da der NFS-Server ja nen aktuellen Portagetree hat, fehlt dann nicht etwas?

Gruss Maurice

----------

## EV-8

Da moe's Frage immer weiter in den Tiefen des Forums versinkt und ich mir dieselben Gedanken mache, zitiere ich seine Frage zur Auffrischung nochmal.

 *moe wrote:*   

> Wenn ich das komplette /usr/portage zentral auslagere, wie sieht es dann mit emerge sync aus? Emerge lädt doch nicht nur ebuilds herunter, sondern aktualisiert noch eine Datenbank, oder? Wenn ich als Client nie emerge sync mache, da der NFS-Server ja nen aktuellen Portagetree hat, fehlt dann nicht etwas?

 

Was macht emerge sync außer /usr/portage zu aktualisieren?

----------

## /dev/blackhawk

Eine genaue Antwort die explizit Deine Frage betrifft, kann ich die leider nicht geben. Aber ein paar persönliche Erfahrungen bzgl. Auslagern von '/usr/portage'.

Ich mounte das komplette '/usr/portage' des Servers über das des Clients. Vorteil der ganzen Sache ist, dass bei Ausfall des Servers immer noch ein, wenn auch älteres Portage, auf dem Client vorhanden ist. Dieses kann wieder per 'emerge sync' upgedatet werden. Desweiteren kannst Du den 'sync'-Befehl sowohl am Client als auch am Server ausführen.

Probleme bzgl der Aktualität, hatte ich noch nie. Das 'world'-File liegt ja in '/var/cache/edb/'.  mann sollte halt aupassen, dass währen eines 'emerge sync' keiner der Clients bzw. der Server irgendetwas zu 'emergen' versucht, das könnte unter umständen zu Problemen führen.

Ich persönlich finde dieses System hervorragend, da mein Server nicht 24/7 läuft und ich trotzdem verschiedene Sachen emergen kann, auch wenn der Server nicht läuft. Du solltest in diesem Fall nicht vergessen, die 'distfiles' die hier runtergeladen werden, sobald der Server wieder läuft, auch auf diesen zu kopieren.

MFG

/dev/blackhawk

----------

## limes

ich bin auch kurz davor portage sowie distfiles zentral über nfs bereitzustellen. 

Ansich ist eine Synchronisation eine Synchronisation, wie schlau gelle  :Laughing:  , und könnte somit wie schon /dev/blackhawk schrieb von jedem beliebigen Rechner, ob Clients oder Server durchgeführt werden.

Wäre da nicht am Ende eines jeden emerge sync dieses  *emerge sync wrote:*   

> >>> Updating Portage cache...  ...done!

 

Das macht mir ein wenig Sorgen.

Mal abgesehen von world und virtuals, wäre es nicht sinnvoll, oder sogar notwendig, Teile aus /var/cache/edb/... mit auszulagern? Welche wären dies?

----------

## hulmeman

mount -t nfs *.*.*.*:/usr/portage/distfiles /usr/portage/distfiles

Works OK for me!

----------

## xces

 *limes wrote:*   

> Wäre da nicht am Ende eines jeden emerge sync dieses  *emerge sync wrote:*   >>> Updating Portage cache...  ...done! 
> 
> Das macht mir ein wenig Sorgen.

 

Wieso macht dir das Sorgen?

 *limes wrote:*   

> Mal abgesehen von world und virtuals, wäre es nicht sinnvoll, oder sogar notwendig, Teile aus /var/cache/edb/... mit auszulagern? Welche wären dies?

 

Wenn du auf all deinen Maschinen immer die selben Programme installiert hast, wieso nicht. Ansonsten machst du so mehr kaputt, da in /var/cache/edb/ nicht nur allgemeine Informationen gespeichert werden. Über /var/cache/edb/dep könnte man hingegen mal nachdenken. Darin werden die Abhängigkeiten der Ebuilds gespeichert.

----------

## hurra

Bei mir klappst bisher ohne Probleme.

/usr/portage liegt am Serevr, täglich wird frisch gesynct (am Server).

Cu Hurra

----------

## limes

Ich habe mich da wohl nicht gut ausgedrückt. Lassen wir die distfiles mal außer acht.

Folgendes Szenario:

Server und Clients sind alles x86-Systeme mit unterschiedlich installierter Software und Konfiguration.

Die Clients haben keinen lokalen portage tree.

Dieser wird ihnen ausschließlich vom NFS-Server bereitgestellt. Die Synchronisation von portage erfolgt auch ausschließlich durch den Server.

Bei jeder Synchronisation wird nun die Datenbank auf dem Server aktualisiert. ">>> Updating Portage cache... ...done!"

Nun kommen wir zu dem Punkt den moe schon angesprochen hat:

Die Clients bekommen vom Server zwar einen neuen portage tree bereitgestellt, verfügen allerdings über eine veraltete lokale Datenbank. <-- Meine Sorgen  :Rolling Eyes: 

Um dies zu verhindern, wäre es doch nötig die Teile der Datenbank, die allgemeine Informationen über den aktuellen portage tree beinhalten, zusätzlich auszulagern!? 

 *xces wrote:*   

> Über /var/cache/edb/dep könnte man hingegen mal nachdenken

 Mir ist aufgefallen daß dort nur Abhängigkeiten der lokal installierten Pakete gelistet werden. 

Welche Daten außer /usr/portage/* werden bei der Synchronisation zusätzlich aktualisiert?

(die für alle Systeme von Nöten sind)

edit: update betr. /var/cache/edb/dep

----------

## sobaka

 *Quote:*   

> Die Clients bekommen vom Server zwar einen neuen portage tree bereitgestellt, verfügen allerdings über eine veraltete lokale Datenbank. <-- Meine Sorgen Rolling Eyes
> 
> 

 

Dass ist nicht ein Problem, eigentlich. Ein 

```

# emerge metadata

```

aktualisiert die Datenbank. Ein cron-job kann ja das machen.  :Smile: 

----------

## moe

 *sobaka wrote:*   

> 
> 
> Dass ist nicht ein Problem, eigentlich. Ein 
> 
> ```
> ...

 

Danke, genau das war die Frage..

Auf meinen Rechnern werd ich das vielleicht nicht machen, die 500MB hab ich noch Platz, aber für Gentoo als usermode linux "client" ist das sehr interessant.

Gruss Maurice

----------

## stiwi

ich habe schon seit langer zeit auf meinen servern das /usr/portage über nfs gemounted. bis jetzt ohne probleme. nun wollte ich mal testen, was passiert, wenn ich am nfs-client "emerge sync" mache. resultat: nach dem runterladen der neuen ebuilds kommen folgende fehlermeldungen (da wo normalerweise "updating portage cache" steht):

...

Failed cache update: app-doc/phrack-02 "Corruption detected when reading key 'phrack-02': [Errno 1] Operation not permitted"                                                                                                                   /

Failed cache update: app-doc/phrack-03 "Corruption detected when reading key 'phrack-03': [Errno 1] Operation not permitted"                                                                                                                   |

Failed cache update: app-doc/phrack-04 "Corruption detected when reading key 'phrack-04': [Errno 1] Operation not permitted"                                                                                                                   \

Failed cache update: app-doc/phrack-05 "Corruption detected when reading key 'phrack-05': [Errno 1] Operation not permitted"                                                                                                                   -

...

...

Failed cache update: app-doc/phrack-52 "Corruption detected when reading key 'phrack-52': [Errno 24] Too many open files: '/usr/portage/metadata/cache/app-doc/phrack-52.portage_lockfile'"                                                    /

Failed cache update: app-doc/phrack-53 "Corruption detected when reading key 'phrack-53': [Errno 24] Too many open files: '/usr/portage/metadata/cache/app-doc/phrack-53.portage_lockfile'"                                                    -

Failed cache update: app-doc/phrack-54 "Corruption detected when reading key 'phrack-54': [Errno 24] Too many open files: '/usr/portage/metadata/cache/app-doc/phrack-54.portage_lockfile'"                                                    \

Failed cache update: app-doc/phrack-55 "Corruption detected when reading key 'phrack-55': [Errno 24] Too many open files: '/usr/portage/metadata/cache/app-doc/phrack-55.portage_lockfile'"                                                    |

Failed cache update: app-doc/phrack-56 "Corruption detected when reading key 'phrack-56': [Errno 24] Too many open files: '/usr/portage/metadata/cache/app-doc/phrack-56.portage_lockfile'"                                                    \

Failed cache update: app-doc/phrack-57 "Corruption detected when reading key 'phrack-57': [Errno 24] Too many open files: '/usr/portage/metadata/cache/app-doc/phrack-57.portage_lockfile'"                                                    -

...

und in /var/log/syslog steht:

...

Oct 28 14:05:59 xyzrechner kernel: RPC: sendmsg returned error 1

Oct 28 14:05:59 xyzrechner kernel: lockd: RPC call returned error 1

Oct 28 14:05:59 xyzrechner kernel: RPC: sendmsg returned error 1

Oct 28 14:05:59 xyzrechner kernel: lockd: RPC call returned error 1

Oct 28 14:05:59 xyzrechner kernel: RPC: sendmsg returned error 1

Oct 28 14:05:59 xyzrechner kernel: lockd: RPC call returned error 1

Oct 28 14:05:59 xyzrechner kernel: RPC: sendmsg returned error 1

Oct 28 14:05:59 xyzrechner kernel: lockd: RPC call returned error 1

...

was kann denn das nun sein ?

----------

## .maverick

Ich kann das Problem zwar nicht genau zuordnen, aber es liegt ja scheinbar an dem Portage-Cache. Wäre es da nicht einer Überlegung wert gerade diesen auf den Server auszulagern?

Da ich mal davon ausgehe, dass du einen mySQLd installiert hast schau dir doch das hier mal an: https://forums.gentoo.org/viewtopic.php?t=202050

Du müsstest da ja dann nur bei Schritt 5 in der Zeile mit den defaultOptions den host auf deinen Server richten statt auf localhost.

----------

## stiwi

problem gefunden. der rpc.lockd port (32768) auf dem server und auf den clients war in den firewall(s) gesperrt  :Sad: 

----------

