#lego — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #lego, aggregated by home.social.
-
We're starting a new #LEGO build today! The LEGO Game Boy set that is! Let's get this set started (and maybe completed) today! Streaming at https://www.twitch.tv/ra_zim
#furry #vtuber #twitch #stream #streaming #streamer #live #livestream #twitchstreamers #transformation #TF #Nintendo #Gameboy
-
We're starting a new #LEGO build today! The LEGO Game Boy set that is! Let's get this set started (and maybe completed) today! Streaming at https://www.twitch.tv/ra_zim
#furry #vtuber #twitch #stream #streaming #streamer #live #livestream #twitchstreamers #transformation #TF #Nintendo #Gameboy
-
Bring Nintendo's beloved video game to life with the LEGO Animal Crossing Blathers’s Museum Collection Building Set.
On sale now: amzn.to/3RErSgU
#LEGO #Nintendo #AnimalCrossing #Puzzles #Artist #Games #TV #Art #GameDev #GamingSky #ArtSky #PromoSky -
Bring Nintendo's beloved video game to life with the LEGO Animal Crossing Blathers’s Museum Collection Building Set.
On sale now: amzn.to/3RErSgU
#LEGO #Nintendo #AnimalCrossing #Puzzles #Artist #Games #TV #Art #GameDev #GamingSky #ArtSky #PromoSky -
Bring Nintendo's beloved video game to life with the LEGO Animal Crossing Creative Houses: Seasons of Fun Building Set.
On sale now: amzn.to/4bjjAlm
#LEGO #Nintendo #AnimalCrossing #Puzzles #Artist #Games #TV #Art #GameDev #GamingSky #ArtSky #PromoSky -
Bring Nintendo's beloved video game to life with the LEGO Animal Crossing Creative Houses: Seasons of Fun Building Set.
On sale now: amzn.to/4bjjAlm
#LEGO #Nintendo #AnimalCrossing #Puzzles #Artist #Games #TV #Art #GameDev #GamingSky #ArtSky #PromoSky -
"He was like, 'no, I don't want that, I want this one'" - LEGO Pokémon Designers Talk Kids & Prototype Pikachus
-
"He was like, 'no, I don't want that, I want this one'" - LEGO Pokémon Designers Talk Kids & Prototype Pikachus
-
#LEGO #StarWars UCS A-wing Starfighter KURZ REVIEW | Set 75275 - https://setdb.de/lego-75275/
-
#LEGO #StarWars UCS A-wing Starfighter KURZ REVIEW | Set 75275 - https://setdb.de/lego-75275/
-
Continuing to work my way through all my MegaBloks Pokémon kits, we come to a different Pika-clone, Dedenne.
Another adorable electric rodent, this time a dual fairy type. This figure was a little more annoying with the rubbery antennae / whiskers to get them set up, but that was the hardest part. The tail is a long rubbery thing. For display purposes, I have to keep it in Dedenne's hand or it is all over the place.
The last picture also includes MDMRN Twin 1's (12 YO) hand. For her birthday, I got her an Eevee kit and she wanted to show it off too if I was showing off Dedenne.
Anyway, very cute kit! I have I think about 3 more of them left before I'm out of 'em to build.
I hope I run into more of them randomly in the wild cause they're fun and I'm building quite the team of 'Mons at my work desk.
#Photo #Photograph #MegaBloks #Pokemon #Toy #Toys #Pokemon30 #Lego #NotLego #MegaConstrux #Dedenne
-
Continuing to work my way through all my MegaBloks Pokémon kits, we come to a different Pika-clone, Dedenne.
Another adorable electric rodent, this time a dual fairy type. This figure was a little more annoying with the rubbery antennae / whiskers to get them set up, but that was the hardest part. The tail is a long rubbery thing. For display purposes, I have to keep it in Dedenne's hand or it is all over the place.
The last picture also includes MDMRN Twin 1's (12 YO) hand. For her birthday, I got her an Eevee kit and she wanted to show it off too if I was showing off Dedenne.
Anyway, very cute kit! I have I think about 3 more of them left before I'm out of 'em to build.
I hope I run into more of them randomly in the wild cause they're fun and I'm building quite the team of 'Mons at my work desk.
#Photo #Photograph #MegaBloks #Pokemon #Toy #Toys #Pokemon30 #Lego #NotLego #MegaConstrux #Dedenne
-
"Slanted Magazine 47 - Digital Tools" published my line-typography-generator for drawing machines "Unknown Letters" and the undergraduate course "Build Drawbots and Learn to Code" i developed together with Felix Baumgärtner.
https://www.slanted.de/product/slanted-magazine-47-digital-tools
Look at this vast list of tools:
https://www.slanted.de/news/digital-tools
https://unknownletters.m05.de -
Migration von Certbot zu Lego
https://blog.sengotta.net/migration-von-certbot-zu-lego/Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.
das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492
Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.
Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.
Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.
Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.
In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.
Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.
Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:
lego accounts register --email [email protected] -a --path /etc/legoWie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Nun kann man sein erstes Zertifikat erstellen:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego legt diese dann in /etc/lego/certificates ab.
Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Muss im webserver konfiguriert sein certificates: test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootDas ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.
Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:
lego --config /etc/lego/lego.yamlJetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetund
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNun können wir den systemd daemon neu laden und den timer starten und aktivieren:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerUnd das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.
Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.
#certbot #desecio #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
Migration von Certbot zu Lego
https://blog.sengotta.net/migration-von-certbot-zu-lego/Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.
das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492
Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.
Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.
Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.
Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.
In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.
Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.
Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:
lego accounts register --email [email protected] -a --path /etc/legoWie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Nun kann man sein erstes Zertifikat erstellen:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego legt diese dann in /etc/lego/certificates ab.
Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Muss im webserver konfiguriert sein certificates: test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootDas ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.
Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:
lego --config /etc/lego/lego.yamlJetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetund
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNun können wir den systemd daemon neu laden und den timer starten und aktivieren:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerUnd das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.
Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.
#certbot #desecio #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
Migrating from Certbot to Lego
https://blog.sengotta.net/migrating-from-certbot-to-lego/Many of you know the problem: you just want to make a small adjustment on your VPS or homelab and than you stumble upon this unsolved problem you dont have the motivation to tackle for the last couple of months.
That happened to me today, i just wanted to test a new piece of software for which i needed a TLS certificate. No big deal, but than i have seen that the Certbot on my Debian Bookworm stull suffers a nasty bug and does not cleanup the TXT records for the DNS-01 challange after retrieving a new cert: https://github.com/certbot/certbot/issues/10492
Yes i know, that is only a cosmetic problem. But it is not the only problem i had with certbot in the last couple of months. In march i had the problem of the broken OVH DNS Addon in Debian Trixie.
To solve the problem i could have switch over to the certbot docker install, like i have done on my Debian Trixie machine, but that introduces another problem. One of my domain is managed via desec.io, a cool free german DNS hosting service. The problem is there is no official docker for their DNS-01 addon, which means i would have to maintain my own docker image for that. Sorry i but i dont want to do that.
So what to do now? I didnt wanna mess with Python virtual environments so a native install of certbot is a nogo. I remembered that in march someone told me about Lego an acme client written in Go, with a massive amount of supported DNS-01 capeable DNS providers. One thing i really like about it is that it is only one static go binary. Really easy to update without messing with the package management. Maybe in the foreseeable future i will craft a small bash script that does the updates.
At the first glimpse it seemed rather complicated to work with the config file, but when you break it down it is really good structured and easy.
In my case i have two providers that verify via DNS-01 and one that verifies via http-01 webroot challenge. So the acme client never has to bind to port 80 which means not interruption while getting new certs.
Getting it running is quite easy. Download the Lego binary from github, unpack it, move it to a suitable location (i chose /usr/local/sbin) and make it executeable. After that i created the folder /etc/lego to hold all the configs and the certificates.
What you can directly do is generating an account:
lego accounts register --email [email protected] -a --path /etc/legoHow to proceed depends on the verification challenges you need to use. Just an example what i did for my OVH domains which i use with DNS-01. I am working with .env- Files for storing credentials of my DNS Provider. So generate a file called /etc/lego/.env.ovh and fill it with the credentials described in the Lego wiki in my case Application Key, Application Secret, Consumer Key and the endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Now i can get my first certificate:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego will store the certs in /etc/lego/certificates
But now i want to automate that so i will craft a lego.yaml in /etc/lego which tells Lego how to handle multiple domains verification methods etc. Mine looks like this:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Needs to be deliverd by webserver certificates: test.example.desec: #Free name to choose, will be the name of certifcate file challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootThis is just an example, definately have a look into the Wiki, and remember its yaml, so only spaces, no tabs etc.
If you have setup the config file like this you can simply get or renew certificates colling lego only with the config as argument:
lego --config /etc/lego/lego.yamlFor me in my case i have than just created a systemd timer and a service unit so Lego runs periodically. They are stored in /etc/systemd/system/lego-renew.timer and /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetand
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNow we reload the systemd daemon, start and enable the timer:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerAnd that it. Now Lego should take care of your certificates. Of course you now have to change your nginx etc. config files to point to the new location of the certificates, yeah there was a reason why i postponed that task so long.
I hope this post could help someone or is at least interesting. If not: at least i know what i have done here in six months.
#certbot #desecio #homelab #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
Migrating from Certbot to Lego
https://blog.sengotta.net/migrating-from-certbot-to-lego/Many of you know the problem: you just want to make a small adjustment on your VPS or homelab and than you stumble upon this unsolved problem you dont have the motivation to tackle for the last couple of months.
That happened to me today, i just wanted to test a new piece of software for which i needed a TLS certificate. No big deal, but than i have seen that the Certbot on my Debian Bookworm stull suffers a nasty bug and does not cleanup the TXT records for the DNS-01 challange after retrieving a new cert: https://github.com/certbot/certbot/issues/10492
Yes i know, that is only a cosmetic problem. But it is not the only problem i had with certbot in the last couple of months. In march i had the problem of the broken OVH DNS Addon in Debian Trixie.
To solve the problem i could have switch over to the certbot docker install, like i have done on my Debian Trixie machine, but that introduces another problem. One of my domain is managed via desec.io, a cool free german DNS hosting service. The problem is there is no official docker for their DNS-01 addon, which means i would have to maintain my own docker image for that. Sorry i but i dont want to do that.
So what to do now? I didnt wanna mess with Python virtual environments so a native install of certbot is a nogo. I remembered that in march someone told me about Lego an acme client written in Go, with a massive amount of supported DNS-01 capeable DNS providers. One thing i really like about it is that it is only one static go binary. Really easy to update without messing with the package management. Maybe in the foreseeable future i will craft a small bash script that does the updates.
At the first glimpse it seemed rather complicated to work with the config file, but when you break it down it is really good structured and easy.
In my case i have two providers that verify via DNS-01 and one that verifies via http-01 webroot challenge. So the acme client never has to bind to port 80 which means not interruption while getting new certs.
Getting it running is quite easy. Download the Lego binary from github, unpack it, move it to a suitable location (i chose /usr/local/sbin) and make it executeable. After that i created the folder /etc/lego to hold all the configs and the certificates.
What you can directly do is generating an account:
lego accounts register --email [email protected] -a --path /etc/legoHow to proceed depends on the verification challenges you need to use. Just an example what i did for my OVH domains which i use with DNS-01. I am working with .env- Files for storing credentials of my DNS Provider. So generate a file called /etc/lego/.env.ovh and fill it with the credentials described in the Lego wiki in my case Application Key, Application Secret, Consumer Key and the endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Now i can get my first certificate:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego will store the certs in /etc/lego/certificates
But now i want to automate that so i will craft a lego.yaml in /etc/lego which tells Lego how to handle multiple domains verification methods etc. Mine looks like this:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Needs to be deliverd by webserver certificates: test.example.desec: #Free name to choose, will be the name of certifcate file challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootThis is just an example, definately have a look into the Wiki, and remember its yaml, so only spaces, no tabs etc.
If you have setup the config file like this you can simply get or renew certificates colling lego only with the config as argument:
lego --config /etc/lego/lego.yamlFor me in my case i have than just created a systemd timer and a service unit so Lego runs periodically. They are stored in /etc/systemd/system/lego-renew.timer and /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetand
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNow we reload the systemd daemon, start and enable the timer:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerAnd that it. Now Lego should take care of your certificates. Of course you now have to change your nginx etc. config files to point to the new location of the certificates, yeah there was a reason why i postponed that task so long.
I hope this post could help someone or is at least interesting. If not: at least i know what i have done here in six months.
#certbot #desecio #homelab #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
-
-
#lego
Wir haben wieder Sets im Angebot / Lieferung nur innerhalb der Schweiz, oder Abholung in Solothurn, bei Interesse DM:
Verkaufspreis exklusive Lieferkosten:LEGO® Star Wars™
Millennium Falcon™
9-14 | #75105 | 1330 Teile
Jahr: 2015
https://www.lego.com/de-de/service/building-instructions/75105
VB: 50 -
#lego
Wir haben wieder Sets im Angebot / Lieferung nur innerhalb der Schweiz, oder Abholung in Solothurn, bei Interesse DM:
Verkaufspreis exklusive Lieferkosten:LEGO® Star Wars™
Millennium Falcon™
9-14 | #75105 | 1330 Teile
Jahr: 2015
https://www.lego.com/de-de/service/building-instructions/75105
VB: 50 -
#lego
Wir haben wieder Sets im Angebot / Lieferung nur innerhalb der Schweiz, oder Abholung in Solothurn, bei Interesse DM, Verkaufspreis exklusive Lieferkosten:LEGO® CREATOR Expert
Pariser Restaurant
16+ | #10243 | 2469 Teile
Jahr: 2014
https://www.lego.com/de-de/service/building-instructions/10243
VB: 120LEGO® CREATOR Expert
Detektivbüro
16+ | #10246 | 2262 Teile
Jahr: 2015
https://www.lego.com/de-de/service/building-instructions/10246
VB: 1603in1
Fahrradladen & Café
9-14 | #31026 | 1023 Teile
Jahr: 2014
https://www.lego.com/de-de/service/building-instructions/31026
VB: 30 -
#lego
Wir haben wieder Sets im Angebot / Lieferung nur innerhalb der Schweiz, oder Abholung in Solothurn, bei Interesse DM, Verkaufspreis exklusive Lieferkosten:LEGO® CREATOR Expert
Pariser Restaurant
16+ | #10243 | 2469 Teile
Jahr: 2014
https://www.lego.com/de-de/service/building-instructions/10243
VB: 120LEGO® CREATOR Expert
Detektivbüro
16+ | #10246 | 2262 Teile
Jahr: 2015
https://www.lego.com/de-de/service/building-instructions/10246
VB: 1603in1
Fahrradladen & Café
9-14 | #31026 | 1023 Teile
Jahr: 2014
https://www.lego.com/de-de/service/building-instructions/31026
VB: 30 -
#LEGO #StarWars Mos Eisley Cantina KURZ REVIEW | Set 75290 - https://setdb.de/lego-75290/
-
#LEGO #StarWars Mos Eisley Cantina KURZ REVIEW | Set 75290 - https://setdb.de/lego-75290/
-
RE: https://chaos.social/@fluepke/116993881059590324
Bei mir war es irgendein #Lego-Katalog, wo ich mich wunderte, warum sie das Wort „Zugehör“ fälschlicherweise mit B geschrieben hatten 😉
-
Runnig your own server incl. TLS stuff is always quite funny. You only want to try a new service and you need a certificate for it. In the progress of obtaining this you realize the still unsolved certbot problem where is does not delete old acme challenges from OVH. Okay there ist no update for that using certbot on Debian 12. Okay i could switch to the docker version of certbot, but that does not include the desec.io DNS Provider provider plugin, which i need for the new domain.
I could now make my own docker container for that, and keep that updated.
Or i make that switch to the Lego acme client which includes numerous DNS Providers and cleans up acme challenges in OVH just fine.
Btw still have no certificates for the new domain 🫠️
#desec #ovh #letsencrypt #certbot #lego #selfhosting
@homelab -
Runnig your own server incl. TLS stuff is always quite funny. You only want to try a new service and you need a certificate for it. In the progress of obtaining this you realize the still unsolved certbot problem where is does not delete old acme challenges from OVH. Okay there ist no update for that using certbot on Debian 12. Okay i could switch to the docker version of certbot, but that does not include the desec.io DNS Provider provider plugin, which i need for the new domain.
I could now make my own docker container for that, and keep that updated.
Or i make that switch to the Lego acme client which includes numerous DNS Providers and cleans up acme challenges in OVH just fine.
Btw still have no certificates for the new domain 🫠️
#desec #ovh #letsencrypt #certbot #lego #selfhosting
@homelab -
😁 (we need a Snoopy and a Woodstock emojis 😅)
-
😁 (we need a Snoopy and a Woodstock emojis 😅)
-
Meine Frau hatte Spaß mit einem Friends-Set. Wir haben uns mit der Villa beschäftigt und sind aktuell dabei das Set ein wenig spaciger zu gestalten. So dass es eben in die Stadt hinein passt.
-
Meine Frau hatte Spaß mit einem Friends-Set. Wir haben uns mit der Villa beschäftigt und sind aktuell dabei das Set ein wenig spaciger zu gestalten. So dass es eben in die Stadt hinein passt.
-
#LEGO #StarWars UCS Snowspeeder KURZ REVIEW | Set 75144 - https://setdb.de/lego-75144/
-
#LEGO #StarWars UCS Snowspeeder KURZ REVIEW | Set 75144 - https://setdb.de/lego-75144/
-
-
-
This is (sadly) completely fake (and no doubt AI slop, apologies) but boy I wish it wasn’t. I’d buy it faster than you could blink and pay almost any price. Holy cow it would be amazing. #LEGO #Space1999
-
This is (sadly) completely fake (and no doubt AI slop, apologies) but boy I wish it wasn’t. I’d buy it faster than you could blink and pay almost any price. Holy cow it would be amazing. #LEGO #Space1999
-
This is why I love #Lego — they engineered the #StarTrek Enterprise bridge set to have 1701 parts!
https://www.lego.com/en-gb/product/star-trek-uss-enterprise-ncc-1701-bridge-11385?age-gate=grown_up
