Toggle sidebar

acme.sh setzt keine script-eigenen ssh-Befehle ab

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Nein, ich habe nur über Aufgabenplaner installiert. Alle sonstigen Befehle habe ich händisch im acme-Terminal (neues Fenster mit Befehl sh) eingegeben.

Das mit dem --rm war mir schon bewusst, also Absicht und weil's im ersten Moment funktioniert hat. Ich konnte aber die Sache mit dem Volume reproduzieren.

Ich habe in der Berechtigungsübersicht von /docker/acme gefunden:

unknown_usesr.jpg

Nach meinem Reset heute, habe ich die User nochmal "sauber" händisch angelegt und nicht über *.dss wiederhergestellt, aber die drei UID/GID sind nicht mehr im System vorhanden.
 
Ich hab grad mal bei mir geschaut. Ich führe ja auch als Scripte im ACME-Container über den Aufgabenplaner des DSM aus, z.B.
Code: 
docker exec neilpang-acme.sh1 /acme.sh/acme_renew.sh
(neilpang-acme.sh1 ist mein Containername)
Müsste dann nicht auch z.B.
Code: 
docker exec neilpang-acme.sh1 acme.sh --set-default-ca --server letsencrypt
oder
Code: 
docker exec neilpang-acme.sh1 /usr/local/bin/acme.sh --set-default-ca --server letsencrypt
gehen?

Wozu die ganzen anderen Parameter?
 
(DNS) Das einzige, was ich in der Richtung gemacht habe (k.A., wessen Tipp ich da beherzigt habe, weil ich ihn gut fand ;)):

Lokaler IPv4 DNSS über die DS (Adguard+Unbound) und damit die Clients das alle schön "befolgen", in der Fritte (Filter) im Zugangsprofil "Standard" eine DNS-Sperre gesetzt, dafür die DS aber ins Profil "Unbeschränkt" verschoben.

Edit: Schreibfehler
 
Zuletzt bearbeitet:
Kannst du denn, wenn du nur ins Terminal vom Container gehst (ohne Volumes oder was auch immer nötig damit du da rein kommst :D) und dann ein curl Befehl absetzen? Also curl http://google.de reicht schon. Nur um zu sehen, ob dein Container Domains auflösen kann.
 
Ergebnis

Code: 
/ # curl http://google.de                                                       
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">   
<TITLE>301 Moved</TITLE></HEAD><BODY>                                           
<H1>301 Moved</H1>                                                               
The document has moved                                                           
<A HREF="http://www.google.de/">here</A>.                                       
</BODY></HTML>

nslookup funktioniert auch.
 
Dann kann das ja an der DNS sperre nicht liegen...
Könntest du mal den docker run Befehl posten? Ich hab gerade keine Idee woran das bei dir liegen könnte.

Edit: hast du mal --debug 2 angehängt?
 
Der "LE CA" Befehl

Code: 
/ # acme.sh --set-default-ca --server letsencrypt --debug 2                    
[Fri Feb  9 16:51:28 UTC 2024] _selectServer try snames='zerossl.com,zerossl'  
[Fri Feb  9 16:51:28 UTC 2024] _selectServer try snames='letsencrypt.org,letsencr
ypt'                                                                            
[Fri Feb  9 16:51:28 UTC 2024] _selectServer match letsencrypt                  
[Fri Feb  9 16:51:28 UTC 2024] Selected server: https://acme-v02.api.letsencrypt.
org/directory                                                                  
[Fri Feb  9 16:51:28 UTC 2024] Lets find script dir.                            
[Fri Feb  9 16:51:28 UTC 2024] _SCRIPT_='/usr/local/bin/acme.sh'                
[Fri Feb  9 16:51:28 UTC 2024] _script='/root/.acme.sh/acme.sh'                
[Fri Feb  9 16:51:28 UTC 2024] _script_home='/root/.acme.sh'                    
[Fri Feb  9 16:51:28 UTC 2024] Using default home:/root/.acme.sh                
[Fri Feb  9 16:51:28 UTC 2024] Using config home:/acme.sh                      
[Fri Feb  9 16:51:28 UTC 2024] LE_WORKING_DIR='/root/.acme.sh'                  
https://github.com/acmesh-official/acme.sh                                      
v3.0.8                                                                          
[Fri Feb  9 16:51:28 UTC 2024] Using server: https://acme-v02.api.letsencrypt.org
/directory                                                                      
[Fri Feb  9 16:51:28 UTC 2024] Running cmd: setdefaultca                        
[Fri Feb  9 16:51:28 UTC 2024] Changed default CA to: https://acme-v02.api.letsen
crypt.org/directory

Irgendwo scheint's mit dem Zugriff auf den docker container oder dem Pfad zu haken, oder irre ich mich?
 
Zur Erinnerung: Das Problem war ja, dass bei @*kw* acme.sh bei Aufruf ohne Pfad (/usr/local/bin) nur CPU und RAM braucht, egal mit welchen Parametern, bis der Container platzt. Mit Pfad ging's. Die Ursache haben wir nicht gefunden. Bei mir ist das nicht so, obwohl ansonsten (Script-Version/Größe, PATH ...) alles gleich ist.

Edit: und hängt er dann wieder oder kommt der Prompt.
 
Und wo ist dann das Problem? Führen andere Parameter wieder zum Hänger?
 
Ich probiere derzeit ausschließlich im docker container. Fakt: ohne eingebundenes Volume funktioniert es, mit „kackt er ab“.

Edit: egal, ob per Aufgabe oder @alexhell Befehl als temporärer Container
 
Dann schau mal über die Filestation nach den Rechten von /volume1/docker und /volume1/docker/acme

Bei mir siehts da so aus:
1707499156164.png

1707499246553.png

also vererbt und Owner ist root
 
Alles identisch...nothing new. 🥺
 
Ich habe jetzt mal einen Anfrage in github aufgemacht. Mal sagen, was die Community dort sagt. Ich habe gestern auch lang und breit nach Lösungen, bzw. Ansätzen im Thema "Zugriff" geschaut, aber nichts gefunden.
 
Man kann das Wochenende auch schöner verbringen. ;) Viel gelesen, viel probiert.

  1. mit dem Docker Containern >3.0.7 muss es wohl Probleme geben, der führt beim deployhook auch Fehlern. User sind zurück auf 3.0.6
  2. 3.0.6 führt bei mir immer noch zu Problemen, Status unverändert
> Plan B
 
Lösung:

Keine Ahnung, ob das jetzt nur für meine Konstellation gilt oder mit der Neuinstallation von DSM am WE zu tun hat?

Unter anderem nach viel Lesen ist Fakt, acme.sh über die den Containermanager zu installieren, führt aktuell zu Problemen bei den Besitzrechten.

Ich habe mich auf der Konsole als root angemeldet und den Container nochmal über docker run neilpang/acme.sh:latest installiert. Jetzt funktioniert auch das Terminal wieder.

Jetzt teste ich mich im anderen Thema nur noch durch Versionen in Bezug auf den deployhook.

Danke für die Hilfe und ich berichte! :)
 
Als root


PS: Du warst zu schnell, ich dachte ich bekomme den edit noch unbehelligt durch. 😄
 

Additional post fields

NAS-Central - Ihr Partner für NAS Lösungen
NAS-Central - The Home of NAS
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat 

Hosted by netcup
IT Lösungen mit NAS Servern
IT Firma Trier
Fotograf Trier
   
Oben Unten