Crovaxon

Da ich jetzt zufällig über die Unraid 7 patch notes gestolpert bin, hast du evt. Glück und das ist kein Problem in dieser Version mehr das wird wohl sein worauf Squid hinweisen wollte. https://docs.unraid.net/unraid-os/release-notes/7.0.0/#docker

Yeah, the lack of SSL / the registry being ran insecure seems to be the general issue. I finally got some traction in the German subforum with my thread there and in the end what had helped was switching to Gitea, which I had planned to reverse proxy out anyway (and Gitea also includes their own Docker registry). After I did that and moved some of my images over to its registry, I switched the containers to the public HTTPS URL of it and voila, no more problems for Unraid to detect image updates. Approaching Gitea directly without HTTPS also made Unraid not able to do version checks, so it indeed must be a secured registry it seems.

So, ich hab das mal ne Weile im Auge behalten, hatte auch mal nen Test gemacht, wo ich den port vom Registry docker auf 80 geschubst habe, um ne portnummer bei der repo URL zu vermeiden, Falls die repo:tag Erkennung da irgendeine Rolle spielen sollte. Aber auch dies änderte nix daran, dass Unraid bei diesem Container auf "Not Available" sprang nach einem check for updates. Ich denke Unraid mag schlicht keine insecure Docker Registries. Meine mittlerweile auch publike Gitea Instanz funktioniert derweil als alternative Docker Registry tadellos über die öffentliche URL angesprochen. Ich könnte jetzt zwar auch den alten Registry container durch mein Reverse Proxy lotsen, aber da ich eh Gitea habe und die Registry dort ebenso gut funktioniert, bleib ich jetzt einfach bei der und ziehe meine images dorthin um. Das Thema hat sich also für mich erstmal gegessen. Danke für die Anteilnahme.

Do you know by any chance if for Unraid's update check it takes a look at the repository link to identify the image tag to test against? Or if that is what would be fixed in the coming release? Given the screenshot of my previous post I get the sneaking suspicion that update checks fall flat because insecure repositories would typically be running on non default HTTP ports. Everything that is not 80 or 443 you need to specify in the URL as ip:port/image and the supposed Tag on my affected container starts at the port number, which is of course not the real image tag. Specifying ":latest" in the repo link does not change that behavior.

So, ich habe mich mal dran gemacht und mein Gitea auch mal nach draußen gehängt... Damit hat es jetzt eine schöne URL und ich hab einen container auf diese URL umgebogen. Und siehe da, nun klappts. Ich hab mal "Check for updates" laufen lassen und während meine alten auf der separaten registry laufenden Container weiterhin "Not available" melden, zeigt der neue auf meiner publiken Gitea Registry nun schön "up-to-date". Und ich hab auch ne schleichende Vermutung, woher das Problem stammt. Ohne jetzt Unraid's Quellcode zu wälzen... (es ist jetzt schon ein bissl spät und ich will ins Bett ) aber ich glaube Unraid macht es sich einfach beim Identifizieren von Repository und Image(plus Tag). Da wird einfach nach dem Doppelpunkt gesucht, weil dahinter kann dann ja nur ein Image Tag folgen, gell? Das haben wir bei einer lokalen IP auf einem nicht standard HTTP port allerdings nicht 😉dort gibts potenziell zwei Doppelpunkte, der erste bei der Portangabe und evt. ein zweiter für ein spezifisches Image Tag. Einmal oben mit meiner insecure registry auf port 5000, unten jetzt auf meiner publiken Gitea URL. Man sieht schon dass der erkannte Tag bei der insecure bereits nicht kosher ist. Da wurde einfach nach dem ersten Doppelpunkt vom Image Tag ausgegangen. Es hilft auch nicht, ":latest" spezifisch im Repository des Containers anzugeben. Das erste auftauchende Doppelpunkt wird als Tag Trennzeichen verwendet Ob dies nur rein visuell ist oder ob Unraid für sich selber auch so das image identifiziert, um damit dann das Repository auf Unterschiede zum laufenden Image zu testen ist jetzt hier die Frage. Ist natürlich nur ein Verdacht. Wenn es nicht so umständlich wäre, jetzt Port 80 bei mir mal frei zu machen, damit ich Docker Registry auf dem default HTTP Port horchen lassen kann, könnte man dies mal so testen, ob dies dann reibungslos funktionieren würde, wenn man dann 127.0.0.1/imagename ohne Portangabe einfach machen könnte und Unraid dann damit klar kommt. Mal schauen, vielleicht finde ich einen Moment morgen, damit ich das mal umbiegen und testen kann. Auf jeden Fall kann ich bestätigen, dass mit der Public URL es jetzt auch klappt.

Jo, hatte ich auch in selten Fällen, aber das sollte bei DockerHub usw. ja nicht die norm sein. Bei mir allerdings schon Mittlerweile ist der wieder umgesprungen auf "Not Available", wohl als ich gerade einen anderen Docker aus den community apps installiert habe und Unraid's Routine die Container durchgelaufen ist. Der JSON vom betroffenen Container sieht so aus: "local": "sha256:06e0e7f673fc011da77724d331921ba3bf26dc1619e58079d0a470eb820d56cc", "remote": null, "status": "undef" Remote ist jetzt schlicht null. Gitea hat da leider auch nicht geholfen. Vermutlich ist es eben doch die Tatsache, dass es insecure betrieben wird. Ich finds zwar affig, lokal direkt auf der Maschine miteinander sprechende Prozesse mit HTTPS absichern zu müssen, aber denke da komm ich nicht dran vorbei. @ich777, sprichst du deine Registry bzw. Gitea von einer public URL an, also von außen erreichbar oder ist das immer noch alles intern und der Container selbst ist mit HTTPS abgesichert?

Probier ich mal, ich hab gerade dasselbe image auf Gitea's Registry geschubst und einen meiner Container auf dessen repo umgestellt. Soweit ist es grün, aber das ist auch der Fall mit der standalone Registry gewesen nach dem ersten Erstellen oder nach einem force update, das war immer irgendwann auf "Not Available" gehüpft. Mal beobachten.

Ich seh auch grad in dem JSON, dass meine eigenen Container da jeweils "local": null, "remote": null, "status": "undef" stehen haben, dann auch kein Wunder dass keine Versionsabfrage klappt jetzt nur noch herausfinden, wo bei Unraid der Schuh drückt...

Ah das ist doch schonmal gut zu wissen. Es gibt ja den Standard Tag "Latest". Pushes auf ein Repo ohne Angabe eines Tags versieht diesen Push immer automatisch mit "Latest", oder man setzt halt händisch "Latest" in Kombination mit anderen Tags, damit "Latest" auch auf diesen bestimmten Push zeigt. Ich habe bei meinen Docker Selbstversuchen jetzt nicht speziell getagged, also zeigt "Latest" ja auch auf meinen letzten Push. Ich gebe bei meinen Containern in Unraid als Repo dann halt auch keinen speziellen Tag in Unraid an (also einfach localhost:5000/imagename), dieser holt dann standardgemäß auch "Latest". Und da ich generell hier noch unerfahren bin was Docker Bauen und eben die Registry angeht, war ich mir nicht sicher ob das Tagging da in irgendeiner Weise eine Rolle spielt. Aber dass da nur hashes verglichen werden macht ja Sinn. Und ja, Unraid muss dann wohl Schwierigkeiten haben, den Hash vom Remote abzufragen.

Ich hatte bereits mit images selber basteln angefangen bevor ich mittlerweile auch Gitea für mich entdeckt habe für Quellcode. Ich hatte images bei mir auf meinem Rechner gebaut und brauchte einfach ne repository zum drauf schubsen und abrufen und da kam Docker Registry als eigener container ganz gelegen. Das Gitea auch die Registry übernehmen kann hab ich gesehen und behalte ich weit im Hinterkopf, ich würde ja vorher lieber wirklich genau wissen, worauf Unraid's Erkennung für Updates auf einem Docker Image fußt. Sonst hab ich am Ende ja auch wieder denselben Salat, ob ich lokal auf der Maschine Gitea oder die standalone Registry absichern muss Kann ich beizeiten versuchen, statt localhost mal 127.0.0.1 oder die lokale IP zu nehmen. Was mich ja initial wundert ist, wie Unraid denn da eig. vorgeht. Es ja nicht so, dass das Ansprechen der registry nicht klappt, ich kann ja initial den Container aufsetzen oder auch bei bereits laufenden Containern das aktuelle Image über "Force Update" ziehen. Nur Unraid's Versionserkennung klappt kein bisschen. Tagst du deine Images noch auf irgendeine spezielle Weise?

Docker Registry, auch in den community apps verfügbar. Einfach add container, als repository "localhost:5000/imagename" und halt Rest ausfüllen wie es das eigene Image unterstützt Und ich persönlich hab da einfach nicht die Notwendigkeit gesehen, da ein Zertifikat vorzusetzen, wenn ich die Registry gar nicht außerhalb meines LANs ansprechen kann/will. Wenn ich das je mal exposen möchte, würde ich das eh über einen Reverse Proxy machen, der macht dann TLS. Zumindest Unraid selbst bzw. andere container können ja direkt mit dem Registry Container reden.

Ne bislang noch nicht. Bisherige Vermutung ist, dass die registry hinter https abgesichert sein muss, meine läuft über http, also insecure. Is there any thread about that? Would be very interested to keep an eye on this. Might this be because of my registry being insecure? It's all running purely local so I did not bother securing it via SSL cert nor am I operating a local DNS for my LAN space where I could put registry for secure access behind. Additionally I am still a greenhorn when it comes to docker creation, so I am also not sure if I have to observe anything specific about image tags or so for Unraid's image versioning to properly pick up that there is a newer version in the registry. Is anything more than just tagging it latest required?

Arrived here following after the crumbs of "exit status 255" errors, I had been using an old version of the script. Removed it from my go file and set up the new one as a userscript now. Seems all good and working now according to logs. Again thanks for this script and the effort to extend the life of cache SSDs

Hey folks, I had attempted to ask this over in Lounge and a couple other places before, because I am absolutely not sure if the fault isn't somewhere with me and the way I am doing it, but those attempts all remained unanswered, so I am trying for support this time. I am hosting my own Docker Repository as its own container, to push my own images to and make use of them for custom dockers I want to use within Unraid's docker tab. The Unraid version is 6.12.8. This all works pretty well, with one minor but slightly irritating thing: any of my custom dockers that refer to my local repository all sooner or later show "Not available" for its version. Which makes wanting to have them pull updates a little hassle. I always have to go into the advanced menu and have them force update to get the latest image I pushed and then have to remove the dangling left over image. It works of course but I would hope to solve this and have the process be a little smoother. It might fairly well be that I am doing something wrong with the whole setup. Is it because it is an insecure docker repository, aka running on HTTP? I don't expose it anywhere, the purpose of this registry is to be just used by Unraid itself so I'd hope not to have route it through a proxy and a deal with issuing a local cert. I might do that if its a requirement but I would be glad to hear first if that is truly necessary for Unraid to be able to do version checks on a repository.

Genau. Wenn du deine domain URL für Filebrowser ansurfst, sollte NPM bereits HTTPS verwenden! Und um zu gewährleisten das auch wirklich nur HTTPS von außen nutzbar ist, eben das "Force SSL" aktivieren in dem Eintrag zu Filebrowser in NPM. Check in deinem Webbrowser mal wenn du deine DuckDNS Adresse für den Filebrowser ansurfst, ob du oben in der Adresszeile dir die volle URL anzeigen lassen kannst. Steht da bereits https in der Zeile (bei Chrome muss man doppelt reinklicken, dann gibts die vollständige URL)? Oder sieh dir die Website Informationen an (bei Chrome z.B. ist dass das Symbol ganz links innerhalb der Adresszeile). Da sollte dann sowas stehen wie "Die Verbindung ist sicher" und du kannst dir das im Detail anschauen, vor allem das dahinter liegende Zertifikat, da sollte dann auch deins stehen, welches NPM per Lets Encrypt erzeugt hat.