Posts by Aljoscha

Du kannst dir mal Borg bzw. Borgmatic anschauen.

Quote from tab

Passt doch genau, du musst halt vom Normalpreis für den Standort Nürnberg ausgehen.

Richtig, hatte das mit der Auswahl nicht beachtet. Ich editiere mal.

Sehr coole Aktion und beim RS auch zugegriffen

The Problem is on netcups side. See

Ja ist auch bei mir in der App angezeigt. Kurios!

Vielen Dank für eure Einschätzung und Erfahrungswerte, dies war sehr hilfreich

Quote from NaN

Mir ist nicht klar, wofür du den CNAME brauchst. Wenn du die Domains sowieso bei deSEC hostest und deren API für den ACME-Client verwendest, kannst du den TXT-Record direkt dort anlegen, wo er gebraucht wird.

Da hast du mich falsch verstanden. Der Ausgangspunkt war, zwei Domains (domain1, domain2), von der eine zu deSEC übertragen wird und von dem aus die dns-challenge gehändelt wird und eine zweite, die sich durch eine Verlinkung über cname die Verschlüsselung aneignet.

Siehe auch: https://www.eff.org/deeplinks/…-dns-challenge-validation

-> Der Absatz: - Use a "Throwaway" Validation Domain -

Ich bin aus verschiedenen Gründen auch am Ende davon ausgegangen, dass auch du das so meinen musst. Nämlich:

Quote from NaN

In meinem Vorschlag verbleibt der größte Teil der DNS-Records bei Netcup und nur die _acme-challenge Subdomain wird zu deSEC ausgelagert, eben per CNAME (oder per Delegation mittels NS-Records).

Geht das? In den "Prerequisites" von dem certbot-dns-desec Plugin Dokumentation heißt es:

"To get a Let's Encrypt certificate for your domain $DOMAIN, you need a deSEC API token $TOKEN with sufficient permission for performing the

required DNS changes on your domain. Also make sure that your domain name has been delegated to deSEC

(in other words: make sure that the parent registry has the right NS records)."

Bei meinem Versuch einfach nur eine Subdomain zu deSEC zu übertragen, hat deSEC gemeckert. Erst als ich wirklich die ganze Domain genutzt habe, ging es.

Insofern habe ich die Informationen so zusammengetragen, wie es am meisten Sinn für mich gemacht hat.

Quote from NaN

Zu einem vollautomatischen Ablauf gehört noch etwas mehr: Du musst den ACME-Client natürlich regelmäßig aufrufen und solltest das Ergebnis, das neu ausgestellte Zertifikat, auch dem/den Nutzer(n) des Zertifikats (Reverse Proxy, Webserver, etc.) automatisch zur Verfügung stellen und auch automatisch dafür sorgen, dass das eingewechselte Zertifikat verwendet wird und nicht etwa das, was beim Start geladen wurde.

Danke für die Klärung.

Ich danke dir für die Mühen, ich will dir auch nicht weiter die Zeit klauen. Ich werde das jetzt von der Seitenlinie beobachten und sobald ich einen für mich gangbaren Weg gefunden habe, diesen in einem Testballon nochmal angehen.

Was mich Ende noch interessieren würde (Aber nur wenn du irgendwann mal Lust und Zeit hast), wäre eine Skizzierung, wo du wie deine Records setzt und wo du die Challenge initiierst.

Liebe Grüße

Hallo code.sport,

ja natürlich, guter Einwand. Neben den besagten mongodb Server vielleicht zwei oder drei weitere Server (zwei apis und ein websocket server allerdings sind die möglicherweise zunächst noch alle auf einen server um es schlank zu halten, will mich da jetzt nicht ganz festlegen). Was denkst du wäre da angemessen?

Hallo liebe Community,

ich mache mir gerade Gedanken über das richtige Monitoring. Die meisten Empfehlungen in diesem Forum gingen meinem Empfinden nach Richtung munin oder zabbix. Ich persönlich neige zu zabbix, insbesondere, da ich gern ein mongodb Server überwachen wollen würde und mit agent2 bei zabbix schon alles bereitgestellt zu sein scheint.

Was ich gern wissen würde und wozu ich bisher nichts finden konnte, sind die Systemanforderungen für zabbix. Sind diese ebenfalls so genügsam wie bei munin, bei dem ja ein 1€ Server zu reichen scheint. Hat da schon jemand Erfahrung?

Liebe Grüße

-- Zustand bei Start

Wir haben zwei Domains bei Netcup (domain1.com und domain2.com). Domain1.com soll genutzt werden um von einer Anwendung mit einem Server zu

kommunizieren. Genauer: api1.server.domain1.com, api2.server.domain1.com und webs.server.domain1.com sollen mit je einer API und einem

Websocket auf dem Server kommunizieren (mit z.B. nginx als reverse-Proxy). Dies sollen sie SSL-verschlüsselt tun. Dafür werden wir domain2.com nutzen.

Für domain2.com wollen wir als Namensserver deSEC (deSEC.io) nutzen. Dies bewerkstelligen wir wie in diesem Thread beschrieben:

Nun können wir die record-Einträge bei deSEC verwalten. Wir legen einen A-record an welcher auf unseren Server zeigt.

Wir loggen uns in unseren Server ein und installieren das Certbot plugin von deSEC. (Siehe auch: https://pypi.org/project/certbot-dns-desec/)

Wir installieren das Plugin mit:

python3 -m pip install certbot certbot-dns-desec

Als Nächstes brauchen wir den deSEC API Token. Hierzu heißt es:

"you need a deSEC API token $TOKEN with sufficient permission for performing the required DNS changes on your domain.

Also make sure that your domain name has been delegated to deSEC (in other words: make sure that the parent registry has the right NS records).

If you don't have a token yet, an easy way to obtain one is by logging into your account at deSEC.io. Navigate to "Token Management" and

create a new one. It's good practice to restrict the token permissions as much as possible, e.g. by setting the maximum unused period to

four months. This way, the token will expire if it is not continuously used to renew your certificate. Tokens can also be created using

the deSEC API."

(FRAGE: Vielleicht mag ja jemand schreiben wie man "maximum unused period to four months" einstellen könnte)

Mit unseren Domainnamen und unseren Token ausgestattet setzen wir nun an und verstauen diese an einem sicheren Ort:

DOMAIN=domain2.com
TOKEN=your-desec-access-token
sudo mkdir -p /etc/letsencrypt/secrets/
sudo chmod 700 /etc/letsencrypt/secrets/
echo "dns_desec_token = $TOKEN" | sudo tee /etc/letsencrypt/secrets/$DOMAIN.ini
sudo chmod 600 /etc/letsencrypt/secrets/$DOMAIN.ini

Dies kann natürlich nach eigenen Bedürfnissen abgeändert werden.

Nun ist es an der Zeit für unser wildcard certificate request:

certbot certonly \
    --authenticator dns-desec \
    --dns-desec-credentials /etc/letsencrypt/secrets/$DOMAIN.ini \
    -d "$DOMAIN" \
    -d "*.$DOMAIN"

(--authenticator dns-desec aktiviert das certbot-dns-desec plugin)

(Vermutung!) Nun wird in der shell ein Token angezeigt, diesen kopieren wir uns und setzen einen txt-record mit Namen

_acme-challenge.domain2.com und setzt den Token in das Content-Windows.

(FRAGE: Der TXT-Record wird händisch eingetragen und nicht automatisch über die deSEC API erzeugt, korrekt?)

(FRAGE: Als ein weiteres command line argument kann --dns-desec-propagation-seconds gesetzt werden. Dies setzt die Wartezeit

fest bevor die ACME server den DNS record verifizieren will. Kann man dies ignorieren oder sollte man hier einen Wert festlegen?)

(FRAGE: Ist hier wirklich sichergestellt das, dass wildcard certificate automatisch erneuert wird. Ich finde die Beschreibung leider

nicht eindeutig in ihrer Formulierung. Oder müssen wir noch etwas wie sudo certbot renew veranlassen?)

Als Nächstes wollen wir domain1.com per cname mit domain2.com verknüpfen, sodass die Kommunikation verschlüsselt stattfindet.

Hierfür setzen wir einen cname-record und lassen

_acme-challenge.sever.domain1.com auf _acme-challenge.domain2.com zeigen.

Dann legt man für die Subdomains von domain1 A-records an, die auf den Server zeigen.

(Ist das Wirklich so?)

Es wäre wirklich toll, wenn jemand, der sich auskennt, einmal das Setzen der records durchspielen kann. Ich habe das Gefühl, mein Vorschlag kann nicht passen.

Für einen guten abstrakten Überblick:

https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation

FRUST! ->

Ich muss sagen, sich über dieses Thema zu informieren, ist schlimm!

Ich habe mich jetzt viele Stunden damit beschäftigt, habe unterschiedliche Quellen gelesen und bin absolut unsicher, ob das so klappt.

Die Informationen sind teilweise widersprüchlich und/oder maximal knapp formuliert.

Das Forum war und ist da wirklich noch der Lichtblick für mich.

Für Leute, die sehr firm im Thema sind, ist das alles sicher kein Problem. Aber für Menschen, die sich da herantasten wollen, sind die, in meinen Augen teilweise einfach schlechten Docs eine Hürde, die nicht sein müsste. Ich weiß, das gehört hier nicht unbedingt hin, aber ich bin gerade maximal gefrustet.

Quote from Valkyrie

Hat jemand von euch schon probiert eine .de Domain über das CCP zu bestellen? Ich bekomme dort den regulären Preis angezeigt statt dem Aktionspreis.

Bei einer .com Domain wurde es richtig angezeigt und hat geklappt

Liegt eventuell an den 2 Euro Setup Kosten.

Quote from NaN

Wenn du für die Domains verschiedene Zertifikate beantragen wolltest, könntest du das so machen. Mit der DNS-01-Challenge kannst du stattdessen ein Wildcard-Zertifikat für alle direkten Subdomains von server.example.com ausstellen lassen und brauchst dafür nur einen TXT-Record unter _acme-challenge.server.example.com. Dieser Name kann über einen CNAME auf einen anderen Namen verweisen, wo dann der entsprechende TXT-Record sein muss. Das Wildcard-Zertifikat deckt dann api1.server.example.de, api2.server.example.de, webs.server.example.de und alle anderen direkten Subdomains von server.example.com ab (*.server.example.com), was die Konfiguration eines Reverse Proxy für alle diese Domains sehr einfach macht. Du brauchst dann auch nicht so viele Zertifikate ausstellen zu lassen und läufst weniger Gefahr, in Rate-Limits zu stolpern. Ein Zertifikat, das alle Subdomains auflistet (statt *), würde u.U. sehr groß werden und müsste immer neu ausgestellt werden, wenn neue Subdomains dazukommen.

Das ist ja sogar noch besser. Ich werde morgen mal einen detaillierten Schritt für Schritt Plan ausbuchstabieren und ihn hier zur Diskussion stellen. Dies dürfte dann ja eventuell für einige Leute interessant sein. Aber schon mal vielen Dank für deine Hinweise und Ergänzungen

Quote from DerRené

Gern, hier mal Auszüge meiner History der wichtigsten Befehle mit Kommentaren für dich: ...

Sehr cool danke dir

Quote from NaN

Die DNS-Challenge ist sehr zu empfehlen, weil damit auch Wildcard-Zertifikate möglich sind. Die sind besonders für Reverse Proxies sehr praktisch, die mehrere und z.B. für Testzwecke öfter mal wechselnde Subdomains bedienen sollen. Außerdem veröffentlicht man mit einem Wildcard-Zertifikat keine Liste der Subdomains, die man verwendet, an einer Stelle, wo sie von unzähligen Portscannern abgegriffen werden (in den CA-Logs).

Das ist nicht uninteressant. Vorstellbar wäre eine Anwendung, die mit mehreren APIs spricht oder auch einem Websocket Server. Jede hätte eine eigene Subdomain und die Anfragen würden von einem reverse Proxy an die entsprechenden Stellen verteilt werden und die verschlüsselte Kommunikation würde sich wie ein Schleier über diese Subdomains legen, ist das ein realistisches Szenario?

Quote from NaN

Ich wiederhole nochmal den Hinweis aus meiner ersten Antwort: Es ist nicht nötig, die Netcup API zu verwenden und folglich auch nicht, die API-Zugangsdaten auf dem Server zu hinterlegen, nur um die Letsencrypt DNS-01 Challenge zu absolvieren. Man kann die dafür nötige Subdomain mit dem TXT-Record, über den der Domainbesitz nachgewiesen wird, als CNAME anlegen und den TXT-Record dann z.B. bei deSEC mit deren API setzen, wenn man den CNAME auf eine Domain dort zeigen lässt. Das ist offiziell unterstützt, siehe die oben verlinkte Dokumentation. Durch das Anlegen eines CNAMEs für _acme-challenge.<YOUR_DOMAIN> macht man auch nichts kaputt und der ACME-Client hat gar keine Möglichkeit, auf die eigentliche Domain Einfluss zu nehmen, nur auf die Records am Ziel des CNAME. Das größte Problem an der Sache ist, dass deSEC im Moment keine Registrierungen für deren DynDNS Dienst zulässt.

Das ist für mich gerade ein wenig die Hürde, da ich Schwierigkeiten habe das nachzuvollziehen. Ich versuche es trotzdem mal gemixt mit dem, was ich auf

https://docs.certifytheweb.com/docs/dns/validation/

dazu erfahre und halluziniere ähnlich wie eine nicht sonderlich wissende KI.

Ich habe eine Domain example.eu bei Netcup. Für diese Domain würde ich gerne, dass api1.server.example.de, api2.server.example.de, webs.server.example.de auf einen Server zeigen und mit diesem verschlüsselt kommunizieren.

Ich erschaffe eine Subdomain mit dem Namen auth.example.de. Diese Subdomain liegt bei deSEC (geht das überhaupt, dass man nur eine Subdomain dort verwaltet?) Diese Subdomain hat einen eigenen Server und dort führt man die DNS-Challenge aus inklusive hook, sodass ein renewal passiert. Man erzeugt ein txt-record mit dem Namen _acme-challenge.auth.example.de und übergibt den Token dem Content-Window. Nun legt man auf Netcup für jede der obrigen subdomains cname record an mit dem eintrag _acme-challenge.subdomain zeigt nach _acme-challenge.subname.auth.example.de (Bsp. _acme-challenge.api1.server.example.de zeigt nach _acme-challenge.api1.server.auth.example.de).


Wenn ich René richtig verstehe wäre anstelle der Subdomain auth.example.de auch eine andere Domain (domain1 / domain2) möglich.


Das ist wahrscheinlich ganz furchtbar daneben. Vielleicht hat ja jemand eine verständliche Quelle, die das Vorgehen etwas farbenfroher beschreibt.


Quote from Virinum

Nur um das einmal kurz klarzustellen: Für die HTTP-Challenge ist nur der Port 80 zu öffnen. Und der muss ja auch nicht zwingend deine API ausliefern. Es reicht wenn darauf nur die Challenge abgerufen werden kann.

Richtig, vielen Dank für die Klarstellung.

Quote from Virinum

Wenn du aber zwingend die DNS-Challenge verwenden möchtest, verstehe ich noch nicht so ganz, wo du gerade hängst. Traust du dich nicht auf deSEC zu wechseln?

„Kaputt machen“ kann man schon einiges. Aber davon lässt sich auch eigentlich alles wieder selbstständig reparieren.

Ja, genau das war das Problem. Ich habe noch nicht in die Tiefe alles durchschaut und eine aufploppende Meldung, dass man seine Domain unbrauchbar machen könnte, hat mich zögern lassen. Der Gedanke war, dass ich schon im Vorhinein genau wissen wollte, was alles passiert, sobald ich den ersten Schritt gegangen bin. Das Internet kann da auch manchmal ein Fluch sein, mit den vielen unterschiedlichen Informationen. Na ja, ich habe dann doch den Schritt gewagt und kann meine Records für diese Domain nun über deSEC setzen. Der Server ist über http erreichbar, also so weit alles gut. Auch wenn der ursprüngliche Grund für den Umzug die DNS-Challenge war, nehme ich innerlich wieder Abstand davon. Abgesehen von der eventuell etwas zwanghaften Fixierung darauf, dass ich den Port 80 gerne geschlossen hätte, gibt es keine allzu gute Begründung.

Zudem sollte man besser nur in Tümpeln schwimmen, wenn man weiß wie man schwimmt und die Wassertiefe kennt. Hierzu aus einer von dir verlinkten Quelle:

"

Beachten Sie, dass die Angabe Ihrer vollständigen DNS-API-Anmeldedaten auf Ihrem Webserver die Auswirkungen eines Hackerangriffs auf den Webserver deutlich erhöht.

"

Ich denke, man sollte schon sehr genau wissen, was man da tut, und ehrlicherweise weiß ich es nicht.

Quote from DerRené

Acme.sh + Netcup API funzt einwandfrei. Seit Jahren im Einsatz bei mir. Gestern zuletzt beim neuen Projekt. Ich kann heute Abend gern die genutzten Befehle dazu ergänzen.

Wichtig: dns-sleep auf 630 setzen. Und DNSSEC natürlich aus, aber das sollte sich hier ja mittlerweile rumgesprochen haben.

Ich denke, das wäre für viele Leute interessant und ein guter Start, etwas zu lernen. Falls du die Lust findest, lass dich bitte nicht aufhalten

Ich habe noch einige letzte Verwirrungen bezüglich der dns challange. Es gibt einige umfangreiche Tutorials im Internet, wie dies zu bewerkstelligen ist.

Es gibt aber auch folgende Videoanleitung, welche super simple ist und vielleicht 50 Sekunden dauert. Dort muss auch kein CNAME record angelegt werden. Ist das Vorgehen dort koscher? Vielleicht hat ja jemand Lust, sich das anzuschauen, eine zweite Meinung würde mich doch sehr interessieren.

EDIT: Das Problem scheint wohl zu sein, dass in der verkürzten Version kein renewal möglich ist. Leider wurde das nicht deutlich aus der Anleitung. Dann ist wohl die etwas aufwendigere Methode zu bevorzugen.

Vielen Dank für die Zeit und die Hilfe, NaN!

Sorry, dass ich mich nicht zeitnahe zurückgemeldet habe, aber mich hat es krankheitsbedingt aus den Socken gehauen. Deswegen werde ich mich auch (wenn es gut läuft) erst morgen an die Umsetzung wagen und dann hoffentlich von einem Erfolg berichten

Hallo liebe Community.

Folgende Situation: Ich habe einen Server, auf dem eine API läuft und ich möchte die Kommunikation gerne über SSL verschlüsseln.

Die API ist nicht über Port 80 oder 443 zu erreichen. Im Grunde würde ich gerne die Ports 80 und 443 auch gar nicht nutzen (verschließen). Wenn man SSL über Certbot einrichtet, ist es aber erstmal (und auf Dauer) notwendig Ports 80 und 443 zu öffnen. Das habe ich jetzt auch testweise alles gemacht und es funktioniert ja auch soweit gut. Nun habe ich von "DNS-01 challenge" gehört, wonach man den TXT Record nutzen kann und dann die Validierung nicht mehr auf dem Server selber vornimmt, ergo 80 und 443 schließen kann.

Leider weisen anderer Forumseinträge darauf hin, dass Netcup diesbezüglich nicht geeignet sein soll. Alternativ kann man aber wohl auch deSEC nutzen (Was noch weitere Vorteilen wie DNSSEC bringt).

(Siehe auch: https://forum.netcup.de/netcup…-wie-geht-das-mit-dnssec/)

Dort habe ich mich auch angemeldet. Aber ehrlich gesagt verstehe ich nicht immer alles so perfekt und ich will nichts kaputt machen. Vielleicht kennt sich ja jemand besser aus und weiß Rat.

Was wäre ein vernünftiges Vorgehen, wenn man die Kommunikation verschlüsseln will und wie macht man das am besten mit z.B. deSEC oder alternativ Cloudflare.

Kann ich mit meiner dem Server zugewiesene Domain herumspielen? Oder kann man da was (dumm gefragt) kaputt machen?

Wie ist das mit der Erneuerung der Zertifikate, passiert das automatisch?

Oder meint ihr, man sollte die Finger davon lassen, wenn man noch nicht ganz so firm mit den Vorgängen ist?

Jeder Tipp ist willkommen.

Super vielen Dank H6G!

Hallo liebe Community,

ich habe vor einiger Zeit einen RS1000 mit 160gb bestellt, weil ich da eine REST API drauf laufen lassen wollte. Als Datenbank habe ich mongodb installiert. Nun crasht mongodb immer mal wieder. In den Logs ist zu sehen, dass es Probleme beim Schreiben gibt (FileStreamFailed: Failed to write to interim file buffer). Als möglicher Fehler wurde eine zu volle Festplatte angegeben.

df -h ergibt:

'Filesystem Size Used Avail Use% Mounted on
tmpfs 794M 996K 793M 1% 
/run/dev/vda3 8,8G 8,4G 0 100% 
/tmpfs 3,9G 0 3,9G 0% 
/dev/shmtmpfs 5,0M 0 5,0M 0% 
/run/lock/dev/vda2 974M 269M 638M 30% 
/boottmpfs 794M 4,0K 794M 1% /run/user/0'

Alles spielt sich auf /run/dev/vda3 ab. Ganz offensichtlich gibt es hier ein Problem. Ich finde hier auch nicht den zur Buchung passenden Speicherplatz.

fdisk -l ergibt unter anderem:

Disk /dev/vda: 160 GiB, 171798691840 bytes, 335544320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Die Festplatte scheint da zu sein. Ich vermute, ich habe bei der Einrichtung schon Fehler gemacht. Vielleicht hat jemand eine Idee wie ich das jetzt korrigiere, aber noch wichtiger, was ich am Anfang hätte besser machen können.

Jede Anmerkung ist willkommen.

Die Seite wirkt auf mich professionell.

Eine Coupon-Seite mit gültigen Coupons, ohne dass man von Werbung erschlagen wird, ist ’ne wirkliche Lücke. Die Idee finde ich super.

Nur das Angebot ist leider viel zu klein. Solltet ihr wirklich nur Coupons auflisten, bei denen ihr eine Provision erhaltet, ist das zu wenig. Ihr solltet meiner Meinung nach alles, was sinnvoll ist, dort abbilden. So macht es derzeit noch zu wenig Sinn, die Seite zu nutzen. Es ist aber ein guter Start