kopia lustrzana https://github.com/linuxserver/docker-documentation
Deployed 09d4fdbf
with MkDocs version: 1.4.3
rodzic
a174dff177
commit
713113c9cc
|
@ -12,7 +12,7 @@ sudo<span class=w> </span>dpkg<span class=w> </span>-i<span class=w> </span>libs
|
|||
<span class=nb>echo</span><span class=w> </span><span class=s2>"deb http://deb.debian.org/debian buster-backports main"</span><span class=w> </span><span class=p>|</span><span class=w> </span>sudo<span class=w> </span>tee<span class=w> </span>-a<span class=w> </span>/etc/apt/sources.list.d/buster-backports.list
|
||||
sudo<span class=w> </span>apt<span class=w> </span>update
|
||||
sudo<span class=w> </span>apt<span class=w> </span>install<span class=w> </span>-t<span class=w> </span>buster-backports<span class=w> </span>libseccomp2
|
||||
</code></pre></div> </li> <li> <p>Option 3</p> <p>Reinstall/update your OS to a version that still gets updates.</p> <ul> <li>Any distro based on DebianStretch does not seem to have this package available</li> <li>DebianBuster based distros can get the package trough backports, as outlined in point 2.</li> </ul> <p _=% endhint=endhint>{% hint style="info" %} RaspberryPI OS (formerly Raspbian) Can be upgraded to run with a 64bit kernel</p> </li> <li> <p>Symptoms</p> </li> <li> <p>502 errors in <strong>Jellyfin</strong> as seen in <a href=https://github.com/linuxserver/docker-jellyfin/issues/71>linuxserver/docker-jellyfin#71</a></p> </li> <li><code>Error starting framework core</code> messages in the docker log for <strong>Plex</strong>. <a href=https://github.com/linuxserver/docker-plex/issues/247>linuxserver/docker-plex#247</a></li> <li>No WebUI for <strong>Radarr</strong>, even though the container is running. <a href=https://github.com/linuxserver/docker-radarr/issues/118>linuxserver/docker-radarr#118</a></li> <li>Images based on our Nginx base-image(Nextcloud, SWAG, Nginx, etc.) fails to generate a certificate, with a message similar to <code>error getting time:crypto/asn1/a_time.c:330</code></li> <li><code>docker exec <container-name> date</code> returns 1970</li> </ul> <h2 id=lscr>What is lscr.io</h2> <p>LSCR is a vanity url for our images, this is provided to us in collaboration with <a href=https://about.scarf.sh/ >scarf.sh</a>. It is not a dedicated docker registry, rather a redrection service. As of writing it redirects to GitHub Container Registry(ghcr.io). </p> <p>Aside from giving us the ability to redirect to another backend, if nesseceary, it also exposes telemetry about pulls, historically only available to the backend provider. We base some decisions on this data, as it gives us a somewhat realistic useage overview (realative to just looking at pulls on DockerHub).</p> <p>We have some blogpost related to how we utilize Scarf:</p> <ul> <li><a href=https://www.linuxserver.io/blog/end-of-an-arch>End of an Arch</a></li> <li><a href=https://www.linuxserver.io/blog/unravelling-some-stats>Unravelling Some Stats</a></li> <li><a href=https://www.linuxserver.io/blog/wrap-up-warm-for-the-winter>Wrap Up Warm For Winter</a></li> </ul> <h3 id=lscr-no-connect>I cannot connect to lscr.io</h3> <p>Due to the nature of Scarf, it sometimes happen to get into larger blocklists focusing on privacy.</p> <p>If you still want to help us getting a better overview of over containers, you should add <code>gateway.scarf.sh</code> to the allowlist in your blocklist solution.</p> <p>If Scarf is on the blocklist, you will get a error message like this when trying to pull a image:</p> <div class=highlight><pre><span></span><code>Error response from daemon: Get "https://lscr.io/v2/": dial tcp: lookup lscr.io: no such host
|
||||
</code></pre></div> </li> <li> <p>Option 3</p> <p>Reinstall/update your OS to a version that still gets updates.</p> <ul> <li>Any distro based on DebianStretch does not seem to have this package available</li> <li>DebianBuster based distros can get the package trough backports, as outlined in point 2.</li> </ul> <p _=% endhint=endhint>{% hint style="info" %} RaspberryPI OS (formerly Raspbian) Can be upgraded to run with a 64bit kernel</p> </li> <li> <p>Symptoms</p> </li> <li> <p>502 errors in <strong>Jellyfin</strong> as seen in <a href=https://github.com/linuxserver/docker-jellyfin/issues/71>linuxserver/docker-jellyfin#71</a></p> </li> <li><code>Error starting framework core</code> messages in the docker log for <strong>Plex</strong>. <a href=https://github.com/linuxserver/docker-plex/issues/247>linuxserver/docker-plex#247</a></li> <li>No WebUI for <strong>Radarr</strong>, even though the container is running. <a href=https://github.com/linuxserver/docker-radarr/issues/118>linuxserver/docker-radarr#118</a></li> <li>Images based on our Nginx base-image(Nextcloud, SWAG, Nginx, etc.) fails to generate a certificate, with a message similar to <code>error getting time:crypto/asn1/a_time.c:330</code></li> <li><code>docker exec <container-name> date</code> returns 1970</li> </ul> <h2 id=lscr>What is lscr.io</h2> <p>LSCR is a vanity url for our images, this is provided to us in collaboration with <a href=https://about.scarf.sh/ >scarf.sh</a>. It is not a dedicated docker registry, rather a redrection service. As of writing it redirects to GitHub Container Registry(ghcr.io). </p> <p>Aside from giving us the ability to redirect to another backend, if nesseceary, it also exposes telemetry about pulls, historically only available to the backend provider. We base some decisions on this data, as it gives us a somewhat realistic useage overview (realative to just looking at pulls on DockerHub).</p> <p>We have some blogpost related to how we utilize Scarf:</p> <ul> <li><a href=https://www.linuxserver.io/blog/end-of-an-arch>End of an Arch</a></li> <li><a href=https://www.linuxserver.io/blog/unravelling-some-stats>Unravelling Some Stats</a></li> <li><a href=https://www.linuxserver.io/blog/wrap-up-warm-for-the-winter>Wrap Up Warm For Winter</a></li> </ul> <h3 id=lscr-no-connect>I cannot connect to lscr.io</h3> <p>Due to the nature of Scarf as a Docker gateway which gathers usage metrics, some overzealous privacy-focused blocklists will include its domains.</p> <p>If you want to help us in getting a better overview of how people use our containers, you should add <code>gateway.scarf.sh</code> to the allowlist in your blocklist solution.</p> <p>Alternatively, you can use Docker Hub or GHCR directly to pull your images, although be aware that all public registries gather user metrics, so this doesn't provide you with any real benefit in that area.</p> <p>If Scarf is on the blocklist, you will get a error message like this when trying to pull a image:</p> <div class=highlight><pre><span></span><code>Error response from daemon: Get "https://lscr.io/v2/": dial tcp: lookup lscr.io: no such host
|
||||
</code></pre></div> <p>This is however a generic message, to rule out a service-interuption, you should also see if you can resolve the backend provider.</p> <p>Using dig:</p> <div class=highlight><pre><span></span><code>dig<span class=w> </span>ghcr.io<span class=w> </span>+short
|
||||
dig<span class=w> </span>lscr.io<span class=w> </span>+short
|
||||
</code></pre></div> <p>Using nslookup:</p> <div class=highlight><pre><span></span><code>nslookup<span class=w> </span>ghcr.io
|
||||
|
|
File diff suppressed because one or more lines are too long
440
sitemap.xml
440
sitemap.xml
Plik diff jest za duży
Load Diff
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Plik binarny nie jest wyświetlany.
Ładowanie…
Reference in New Issue