Wie es aussieht werde ich wohl nicht um ports herum kommen.
Ich glaube ich trete die Idee in die Tonne, bin gerade dabei
postgreSQL zu compilieren,
nach 2 Stunden Abh�ngigkeiten habe ich
vergessen was ich eigentlich haben wollte und jetzt sind 6 Stunden
rum und er baut 3100 cxx Objekte f�r rust zusammen...
Ich glaube ich trete die Idee in die Tonne, bin gerade dabei
postgreSQL zu compilieren,
Sorry, aber: /warum/ tust Du das �berhaupt?
nach 2 Stunden Abh�ngigkeiten habe ich
vergessen was ich eigentlich haben wollte und jetzt sind 6
Stunden rum und er baut 3100 cxx Objekte f�r rust zusammen...
Wenn man denn unbedingt will, baut man sowas auf potenteren Kisten und installiert dann die Packages. Poudriere ist Dein Freund, wenn Du das automatisieren willst.
Sorry, aber: /warum/ tust Du das �berhaupt?
Eigentlich weil ich mir einen lokalen Nextcloud Server hinstellen
m�chte, der vielleicht auch sp�ter mit dem passenden Handy Client von meinen Eltern genutzt werden k�nnte.
Ich nehme die langen Laufzeiten in Kauf (kann auch sein, dass es nur
auf single core l�uft und sich da noch was auf optimieren l�sst),
wenn ich nicht in jeder jail von vorn anfangen muss. Daher war die
Idee den portstree in den jails zu teilen, welches sich dann �ber
einen nullfs Eintrag in der jail.fstab relativ leicht l�sen liesse.
Das erscheint mir erstmal einfacher, als auch noch einen eigenen Repo Server aufzusetzen.
Eigentlich weil ich mir einen lokalen Nextcloud Server hinstellen
m�chte, der vielleicht auch sp�ter mit dem passenden Handy
Client von meinen Eltern genutzt werden k�nnte.
Dir ist schon klar, da� der Aufwand daf�r nicht unerheblich ist und es relativ g�nstig gehostete L�sungen gibt?
Warum baust Du �berhaupt selber? Die meisten Pakete sollten doch bin�r v�llig in Ordnung sein. Du kannst nat�rlich den Portstree wie
beschrieben �ber nullfs teilen und in jeder jail separat "make
install" aufrufen. Etwas nachhaltiger w�re vielleicht "make package"
und die anschlie�ende Verteilung der pkgs.
Dann kommt halt noch eine neue Software zur Paketverteilung hinzu.
Warum selbst compilieren:
# pkg show "nextcloud*"
nextcloud-php82-26.0.0_1
Weil nextcloud kein postgres drin hat.
Ich bin nicht so mega-fit in schmutzigen L�sungen, aber so als Idee:
Ich bin nicht so mega-fit in schmutzigen L�sungen, aber so als Idee:
Der Ablauf w�re sicher ein interessantes Experiment, aber ich glaube
f�r t�glichen nutzen w�re ich damit im Fehlerfalle noch mehr
�berfordert.
Da h�tte der shared portstree noch den Vorteil sich einfach mit
snapshots einfrieren zu lassen.
Mir w�re die Methode "einmal saurer
Apfel" mit langen Compilierungszeiten, aber daf�r relativ Upgrade
sicher, etwas lieber.
Wenn ich das richtig verstanden habe, wird auf einen Datenbank Server doch per IP zugegriffen? Wie tauglich w�re die Idee mysql und pgres jeweils in eine jail zu setzen und die dann versuchsweise einzeln an nextcloud zu koppeln?
Kann man machen, benutze ich im Moment auch so (z.B. f�r postgres und redmine). Der wesentliche Vorteil ist normalerweise, da� man nur einen Datenbank-Server braucht, auf den man dann mit unterschiedlichen Applikationen zugreifen kann (wenn man denn mehrere hat).
Damit k�nntest Du wenigstens die postgres-Jail komplett mit pkg
bespielen, das w�re in Deinem Fall vielleicht ein weiterer Vorteil.
Wie verhalten sich die Installer, wenn abh�ngige Pakete wie SQL durch einen anderen Server bereit gestellt werden?
Ich verstehe die Frage nicht ganz. Du meinst, Du installierst ein
Paket wie redmine oder nextcloud, die eine Datenbank (den Server) ben�tigen? Das wird vom Installer komplett ignoriert, darum mu�t Du
Dich selber k�mmern. Die Datenbank k�nnte ja sonstwo sein.
Technisch mu� postgres dann �berhaupt nicht offen im Netz verf�gbar
sein. Man kann in den Jails mit unterschiedlichen LocalHost-Adressen arbeiten und die Datenbank-Anbindung nur intern dar�ber laufen lassen.
Es hat etwas gedauert, aber jetzt reagiert die jail bei ping sowohl
auf ihre localhost als auch auf auf ihre netzinterne IP. Neu f�r mich ist, dass es sozusagen eine postgres interne firewall gibt und man gezielte IPs f�r client Zugriff freischalten kann bzw. muss.
Ich habe pgadmin auf Windows installiert und konnte nach der
Anpassung der pg_hba.conf zugreifen. Gef�llt mir richtig gut, ich
Ich w�rde das nicht Firewall nennen, aber ja, man mu� den externen
Zugriff freischalten. Kann man auch f�r alle tun, aber das ist halt weniger sicher. Defaultm��ig l�uft das nur auf localhost.
Wenn der Zugriff nicht direkt von dort passiert, kann man sich die entsprechenden Ports z.B. auch per SSH-Tunnel 'rausziehen.
Ich habe pgadmin auf Windows installiert und konnte nach der
Anpassung der pg_hba.conf zugreifen. Gef�llt mir richtig gut,
Habe ich noch nie benutzt, bisher habe ich das immer direkt editiert.
Sysop: | Angel Ripoll |
---|---|
Location: | Madrid, Spain |
Users: | 2 |
Nodes: | 8 (0 / 8) |
Uptime: | 14:20:25 |
Calls: | 908 |
Files: | 55 |
Messages: | 68,081 |