ubuntuusers.de

PostgreSQL Apt Repository - Linux downloads (Debian) on the following architectures: amd64, arm64, ppc64el und für Ubuntu (amd64, arm64, ppc64el)

Danke für die Hilfe

das hat funktioniert. Ich habe den text kopiert, ein script erstellt und nebenbei viel über repositories gelernt

https://www.postgresql.org/download/linux/debian/

vorher:

deb [arch=amd64 signed-by=/usr/share/keyrings/postgresql-archive-keyring.gpg] http://apt.postgresql.org/pub/repos/apt noble-pgdg mainCode

nachher

deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] https://apt.postgresql.org/pub/repos/apt noble-pgdg main

amd64 Pakete für einen ARM-Prozessor?

Ich bin immer wieder erstaunt, was dem Mann mit Hut alles auffällt! Dass es Unterschiede von amd zu arm beim kernel gibt, ja, aber bei den Programmen habe ich das noch nie bemerkt

root@pi4:~ fake $ dpkg -l | grep postgres
ii  postgresql                        17+278.pgdg24.04+1                      all          object-relational SQL database (supported version)
ii  postgresql-17                     17.5-1.pgdg24.04+1                      arm64        The World's Most Advanced Open Source Relational Database
ii  postgresql-client-17              17.5-1.pgdg24.04+1                      arm64        front-end programs for PostgreSQL 17
ii  postgresql-client-common          278.pgdg24.04+1                         all          manager for multiple PostgreSQL client versions
ii  postgresql-common                 278.pgdg24.04+1                         all          PostgreSQL database-cluster manager
ii  postgresql-common-dev             278.pgdg24.04+1                         all          extension build tool for multiple PostgreSQL versions
root@pi4:~ fake $

morgen mache ich weiter

weholei schrieb:

vorher:

deb [arch=amd64 signed-by=/usr/share/keyrings/postgresql-archive-keyring.gpg] http://apt.postgresql.org/pub/repos/apt noble-pgdg mainCode

nachher

deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] https://apt.postgresql.org/pub/repos/apt noble-pgdg main

Da bin ich jetzt auch mal neugierig geworden. Das arch=amd64 hättest du vermutlich auch ganz einfach durch ein arch=arm64 ersetzen können. Bei der Signatur sollte es keine Unterschiede geben. Was ich gegoogelt habe ist mainCode vs. main.

Die KI sagt zu

main:

This term is commonly used in programming to denote the primary function or entry point of a program. In the context of Debian packages, main doesn't have a specific meaning unless it's part of a file or directory name within the package.

mainCode:

This term is not a standard part of the Debian package structure. It might be a custom name used in a specific project or context, but it's not a general term in Debian packaging.

mainCode vs. main wäre demnach eigentlich auch kein Unterschied.

und so gibt es auch nur ein

ftp.postgresql.org/pub/repos/apt/dists/bookworm-pgdg/main/

aber kein

ftp.postgresql.org/pub/repos/apt/dists/bookworm-pgdg/mainCode/

Aber vielleicht kann das hier ja noch jemand mit besserem Hintergrundwissen als ich es habe aufklären.

@ adelaar, Danke

passd scho, dein Tip hat ja funktioniert

aber ich bin ab jetzt sozusagen im "Blindflug" unterwegs...

-----END CERTIFICATE-----
[Fri Jun 20 11:15:00 CEST 2025] Your cert is in: /home/letsencrypt/.acme.sh/xxxxxxx.dyndns.org/xxxxxxx.dyndns.org.cer
[Fri Jun 20 11:15:00 CEST 2025] Your cert key is in: /home/letsencrypt/.acme.sh/xxxxxxx.dyndns.org/xxxxxxx.dyndns.org.key
[Fri Jun 20 11:15:00 CEST 2025] The intermediate CA cert is in: /home/letsencrypt/.acme.sh/xxxxxxx.dyndns.org/ca.cer
[Fri Jun 20 11:15:00 CEST 2025] And the full-chain cert is in: /home/letsencrypt/.acme.sh/xxxxxxx.dyndns.org/fullchain.cer
[Fri Jun 20 11:15:00 CEST 2025] Installing cert to: /etc/letsencrypt/xxxxxxx.dyndns.org/rsa/cert.pem
/home/letsencrypt/.acme.sh/acme.sh: line 5937: /etc/letsencrypt/xxxxxxx.dyndns.org/rsa/cert.pem: No such file or directory
letsencrypt@pi4:~$ #

und habs vermasselt, denn das Verzeichnis xxxxx.dyndns.org gab es nicht, nur das nextcloud.meinedomain.de

Bevor ich noch mehr vermassele

kann ich den Befehl einfach wiederholen?

weholei schrieb:

und habs vermasselt, denn das Verzeichnis xxxxx.dyndns.org gab es nicht, nur das nextcloud.meinedomain.de

Das kann ich so nicht beantworten. Denn nextcloud.meinedomain.de wäre natürlich in ALLEN Konfigurationsdateien, in denen die Angabe# der Domain erforderlich ist, durch deine tatsächliche Domain (also z.B.xxxxx.dyndns.org) zu ersetzen gewesen. Zudem müssen auch einige Verzeichnisse passend angelegt werden.

Daher wäre zunächst von dir zu überprüfen, wo du im Eifer des copy and paste überall vergessen hast nextcloud.meinedomain.de durch xxxxx.dyndns.org zu ersetzen.

Hallo adelaar

Es freut mich, dass Du Dich nochmal gemeldet hast. Ich hätte vollstes Verständnis, wenn du entnervt abbrichst.

Ich hatte als RFT jahrelang Kunden betreut, die schwer von Begriff waren (-;

Aber die Anleitung ist so gut, dass ich mir zutraue, es zu schaffen - wenn auch nicht beim ersten Mal.

Ich werde also zuerst schauen, wo in der Anleitung "nextcloud.meinedomain.de" steht,

Dann, wenn ich die Verzeichnisstruktur unter "/etc/letsencrypt/xxxxxxx.dyndns.org" hergestellt habe, den Befehl wiederholen.

Die nächsten Befehle "Virtueller Host für Nextcloud" hab ich schon in einer Textdatei, in der die Domain durch suchen und ersetzen geändert wird, gespeichert.

Fail2ban funktioniert bereits. Die Diffie-Hellman-Parameter sind berteits erstellt. Postgressql Datenbanken kann ich mit Webmin sehen, anlegen und bearbeiten.

Wo werden die gespeichert? Zumindest nicht als Datenbank unter ihrem Namen als Datei!

weholei schrieb:

Postgressql Datenbanken kann ich mit Webmin sehen, anlegen und bearbeiten.

Wo werden die gespeichert? Zumindest nicht als Datenbank unter ihrem Namen als Datei!

/var/lib/postgresql/<version>/main/

ein

less /etc/postgresql/<version>/main/postgresql.conf

verrät die Details

Danke für den Hinweis. Denn eine Datenbank wird immer größer, als geplant. Wird sie einmal nicht größer, ist die Festplatte voll.

Das geht bei einem Raspi schnell

Gehe ich richtig, dass ich den Pfad nach /home/postgresql ändern kann?

data_directory = '/var/lib/postgresql/17/main'          # use data in another directory
                                        # (change requires restart)

Eine weitere Hürde:

root@pi4:~ fake $ service nginx restart
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
root@pi4:~ fake $ systemctl status nginx.service
× nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sat 2025-06-21 10:20:44 CEST; 14s ago
       Docs: man:nginx(8)
    Process: 7733 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
        CPU: 25ms

Jun 21 10:20:44 pi4 systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...
Jun 21 10:20:44 pi4 nginx[7733]: 2025/06/21 10:20:44 [emerg] 7733#7733: unknown directive "http2" in /etc/nginx/nginx.conf:12
Jun 21 10:20:44 pi4 nginx[7733]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jun 21 10:20:44 pi4 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jun 21 10:20:44 pi4 systemd[1]: nginx.service: Failed with result 'exit-code'.
Jun 21 10:20:44 pi4 systemd[1]: Failed to start nginx.service - A high performance web server and a reverse proxy server.
root@pi4:~ fake $ cd /etc/nginx/

habe das gefunden

https://forum.jellyfin.org/t-solved-nginx-http2-issues

und diese Zeile geändert

server {
    listen 443 ssl http2;
    listen [::]:443 ssl;

jetzt beschwert er sich über fehlende Zertifikate und hat recht

Jun 21 11:19:42 pi4 nginx[18258]: 2025/06/21 11:19:42 [emerg] 18258#18258: cannot load certificate "/etc/letsencrypt/xxxxxx.org/rsa/fullchain.pem": BIO_>

Bevor ich mir eine 7 tägige Sperre einhole frag ich lieber

root@pi4:/etc/nginx/conf.d fake $ su - letsencrypt
letsencrypt@pi4:~$ acme.sh --issue -d xxxxx.dyndns.org --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/xxxxxx.dyndns.org/rsa/key.pem --ca-file /etc/letsencrypt/weholei.dyndns.org/rsa/ca.pem --cert-file /etc/letsencrypt/xxxxxx.dyndns.org/rsa/cert.pem --fullchain-file /etc/letsencrypt/xxxxxx.dyndns.org/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"
[Sat Jun 21 11:04:12 CEST 2025] Domains not changed.
[Sat Jun 21 11:04:12 CEST 2025] Skipping. Next renewal time is: 2025-08-18T09:15:00Z
[Sat Jun 21 11:04:12 CEST 2025] Add '--force' to force renewal.
letsencrypt@pi4:~$ 

wie bekomme ich die fehlenden in etc/letsencrypt/xxxxxx.dyndns.org/rsa/fullchain.pem –

des etc/letsencrypt/xxxxxx.dyndns.org/rsa/ ist leer

im etc/letsencrypt/xxxxxx.dyndns.org/eee/ sind zertifikate

ich hab mit jetzt mal temporär einen "testserver.dyndns.org", damit könnte ich das ganze Prozedere zur Not wiederholen

weholei schrieb:

Gehe ich richtig, dass ich den Pfad nach /home/postgresql ändern kann?

Ich ändere grundsätzlich keine Pfade. Ich verwende stattdessen Bind-Mounts in der /etc/fstab

Das ist sehe viel übersichtlicher als immer einzeln irgendwelche Configs zu bearbeiten und dann dort womöglich einen Eintrag zu übersehen oder nach einiger Zeit tu vergessen was man wann wo so alles geändert hat.

jetzt beschwert er sich über fehlende Zertifikate und hat recht

LOL Dabei steht in der Anleitung im Abschnitt

Überprüfung der Konfiguration zur Zertifikats-Generierung

Doch halt! Bevor ihr nun mittels acme.sh die Generierung anschmeißt, solltet ihr auf jeden Fall vorher die Konfiguration einmalig manuell testen

Und es steht auch dort wie man das testet. Erst wenn der Test erfolgreich ist, sollten die Zertifikate erzeugt werden. Beachtet man das kann eigentlich nichts mehr schief gehen.

Danke für die Antwort

da hast leicht lachen

Der Test war ja erfolgreich - auch über dyndns!

ohne das certikats gedöns läuft er auch (wieder), sobald ich die Datei /etc/niginx/conf.d/*.conf entferne

eigentlich wollte ich nur wissen ob und wo ich diesen den Befehl für das acme.sh anwenden kann

Add '--force' to force renewal.

ich bin kein scipter

ich verstehe nur, er sagt, du hast doch schon ein zertifikt, warum willst du noch eines?

dann plan B. das ganze nochmal mit einer testdomain.dyndns.org

btw: kann man das erstellte Zertifikat auch für den mailserver verwenden? statt snakoil.pem ?

Was ist dein Problem?

Warum entfernst du irgendwelche *.conf?

Warum willst du ein neue Zertifikat wenn du schon eines hast?

Wenn du eines korrekt erzeugt hast, dann nimm das doch !!!

Willst du womöglich noch immer Zertifikate für nextcloud.meinedomain.de erzeugen, weil du noch immer nicht alles mit nextcloud.meinedomain.de bereinigt und durch die korrekte Domain ersetzt hast? Dann drehst du dich im Kreis.

Was ist dein Problem?

Warum entfernst du irgendwelche *.conf?

Um den Fehler nachzuvollziehen

Virtueller Host für Nextcloud

Nach den Snippets für die allgemeinen SSL-Einstellungen und für die Header, kann auch schon der virtuelle Host für Nextcloud selbst angelegt werden. 
Hier sind wieder die üblichen Dinge zu beachten: Die Datei muss wieder die Endung .conf tragen 
und kann ansonsten beliebig benannt werden. 
Wenn ihr wie ich die Domain als Dateinamen nutzt, dann solltet ihr hier wieder eure eigene Domain für die Nextcloud einsetzen.

nano /etc/nginx/conf.d/nextcloud.meinedomain.de.conf

Existiert eine Datei mit der Endung .conf versucht ngynx mit ssl zu starten

In dieser Datei .conf stehen die Pfade für die Zertifikate z.B /etc/letsencrypt/xxxxx.dyndns.org/rsa

bei mir steht aber in /etc/letsencrypt/xxxxx.dyndns.org/rsa nichts drin, weil ich bei der Erstellung gepatzt habe

root@pi4:/etc/nginx/conf.d fake $ service nginx restart
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
root@pi4:/etc/nginx/conf.d fake $ 

cannot load certificate "/etc/letsencrypt/weholei.dyndns.org/rsa/fullchain.pem"

existiert sie in /etc/nginx/conf.d/ nicht, startet er ohne Fehler und ich kann den test durchführen

root@pi4:~ fake $ service nginx restart
root@pi4:~ fake $ 

echo "Test" >> /var/www/letsencrypt/.well-known/acme-challenge/test.txt

Warum willst du ein neue Zertifikat wenn du schon eines hast?

ich habe nur den einen Teil in etc/letsencrypt/xxxxx.dyndns.org/ecc

das rsa fehlt

und nochmal eines erzeugen geht nicht

root@pi4:/etc/letsencrypt fake $ su letsencrypt
letsencrypt@pi4:/etc/letsencrypt$ acme.sh --issue -d xxxxxx.dyndns.org --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/desperado.dyndns.org/rsa/key.pem --ca-file /etc/letsencrypt/xxxxxx.dyndns.org/rsa/ca.pem --cert-file /etc/letsencrypt/xxxxxx.dyndns.org/rsa/cert.pem --fullchain-file /etc/letsencrypt/xxxxxx.dyndns.org/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"
[Sat Jun 21 22:52:49 CEST 2025] Domains not changed.
[Sat Jun 21 22:52:49 CEST 2025] Skipping. Next renewal time is: 2025-08-18T09:15:00Z
[Sat Jun 21 22:52:49 CEST 2025] Add '--force' to force renewal.
letsencrypt@pi4:/etc/letsencrypt$

Willst du womöglich noch immer Zertifikate für nextcloud.meinedomain.de erzeugen, weil du noch immer nicht alles mit nextcloud.meinedomain.de bereinigt und durch die korrekte Domain ersetzt hast? Dann drehst du dich im Kreis.

nein

Aus der Anleitung:

Als erstes werden die RSA-Zertifikate beantragt:

acme.sh --issue -d nextcloud.meinedomain.de --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/key.pem --ca-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/ca.pem --cert-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/cert.pem --fullchain-file /etc/letsencrypt/nextcloud.meinedomain.de/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Wurde hier am Ende eine Erfolgsmeldung ausgegeben, dann könnt ihr mit den ECDSA-Zertifikate fortfahren:

acme.sh --issue -d nextcloud.meinedomain.de --server letsencrypt --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/key.pem --ca-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/ca.pem --cert-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/cert.pem --fullchain-file /etc/letsencrypt/nextcloud.meinedomain.de/ecc/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Wenn ich duch nun also richtig verstehe hast du zwar ecc- aber keine rsa-Zertifikate.

Da die Erzeugung aber in zwei getrennten Schritten erfolgt, solltest du die fehlenden rsa-Zertifikate doch einfach nun auch einzeln nachträglich erzeugen können, denn die wurden ja noch nicht erzeugt. Allerdings könnte es sein, dass du - wegen diverser Fehlversuche - inzwischen für eine Woche gesperrt wurdest. Dann kann man nix machen.

Was das force renewal angeht. Da hilft Google und die KI doch gut weiter:

To force a certificate renewal, you typically need to add the --force or --force-renewal flag to the command used for renewing certificates. This is especially useful when a certificate is still within its validity period but needs to be renewed, or when there are issues preventing automatic renewal

acme.sh:

• To force a renewal with acme.sh, you would use the command: acme.sh --renew -d yourdomain.com --force

• This command forces acme.sh to attempt renewing the certificate for yourdomain.com, regardless of its current validity status

Aber meinem Verständnis nach nutzt das eh erst etwas wenn die rsa-Zertifikate erstmalig erzeugt wurden.

Danke für die Antwort

Wenn ich duch nun also richtig verstehe hast du zwar ecc- aber keine rsa-Zertifikate.

genau, weil ich bei der Erstellung des Verzeichnisse /etc/letsencrypt/xxxxxxx.dyndns.org/rsa/ nicht aufgepasst habe

Allerdings könnte es sein, dass du - wegen diverser Fehlversuche - inzwischen für eine Woche gesperrt wurdest. Dann kann man nix machen.

Deswegen mache ich jetzt Plan B

Diesen Eintrag musste ich ändern, sonst komme ich nicht weiter

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name nextcloud.meinedomain.de 192.168.178.60;

in

server {
    listen 443 ssl http2;
    listen [::]:443 ssl;
    #http2 on;
    # weholei auskomentiert      

dann schau mer mal, wie weit ich komme 😉

Die Anleitung gefällt mir immer besser, bietet auch tests zur Kontrolle für jemand, der wenig Ahnung hat und erklärt die Zusammenhänge

Immerhin tut sich schon was, wenn ich mit firefox auf die Dyndns-Adresse des testsevers gehe

404 Not Found nginx/1.24.0 (Ubuntu)

Wolle nur mitteilen: Nextcloud läuft.

Danke, auch für die Geduld