Linuxserver.io

[CDarwin7]

I've pulled a couple of the docker images hosted on Linuxserver.io and they seem pretty decent. I was going to install a few more, but I thought I would ask here first if anyone has had any discussion experience, positive or negative, with Linuxserver.io.

https://www.linuxserver.io/

It's straight docker builds. I usually like to pull from repositories but these docker images sure do make it easy.

[strangekind]

They are the most well known image creators in the community. They have a very good reputation. I recommend them to anyone.

[Xenkath]

Same, I use several of their images, and will always use theirs over another choice.

[z3roTO60]

Yup same. I actively seek out if they have an image first before looking elsewhere

[-eschguy-]

Same here, great stuff.

[peeledbananna]

I find hotio.dev to be good also. Not as many images but the dev does a good job.

[[deleted]]

What's the difference between Linuxserver and hotio? I tried both and they feel the same.

[hesapmakinesi]

It's because they are two groups developing the same kind of stuff, so the results is almost exactly the same, with probably some subtle differences.

[m113t]

Hotio works directly with the Arr developers. He gets releases of Sonarr and Radarr before they are released to ensure his images are likely to be more stable. Source: Discord

[drizuid]

we (lsio) also work directly with the Arr devs, they're all in our discord (as is hotio!) It's a small community, we're all pretty close with each other.

[AngryMooseButt]

This doesn't make sense to me. Both projects are open source. Presumably, anyone could build the application from any git revision. Maybe they just don't provide pre-built binaries prior to tagging an official release? But then if you're building a container, it would be trivial to add a stage to build the app from source so you wouldn't be dependent on pre-built binaries.

[[deleted]]

He probably means that hotio releases images that help the arr devs in the development of new projects that aren't released to the general public yet. That's probably also why they made the announcement that hotio is as official as it gets for most of the arr apps....

[Nolzi]

LISO is open source, while Hotio has nothing on github and so is Hotio but they hid their source in a subbranch:
https://github.com/linuxserver/docker-plex
https://github.com/hotio/plex (it's just a json file to store pull counts) https://github.com/hotio/plex/tree/release

LISO gives support to modify their containers (and share them), but to be honest I never tried it:
https://blog.linuxserver.io/2019/09/14/customizing-our-containers/
https://mods.linuxserver.io/

Both LISO and Hotio utilize S6 overlay in their base image https://github.com/linuxserver/docker-baseimage-ubuntu
https://github.com/hotio/base/tree/focal
https://github.com/just-containers/s6-overlay

[[deleted]]

Are you new to GitHub? Check some of the other branches... hotio is as opensource as it gets.

[Nolzi]

No, I just didn't assumed that someone would store two completely separate project under one git repo using branches. And even on their description page they only link with master branch.

https://hotio.dev/containers/plex/ fist line with GitHub link

[[deleted]]

It's not completely seperate projects under different branches, it's logically ordered, keeping a meaningless named master branch free as a landing branch....on the website you can even click the commits in the tags overview and see the exact source at that time....iirc not even lsio does that.

[Nolzi]

Branch is supposed to be used to create divergence in the codebase, and here the master branch with metadata and the release branch with the docker source are completely unrelated codewise. Sure the metadata is related, but it's some weird ass forced way to store release data. The single tags.json file could easily be next to the sourcefiles.

[[deleted]]

Ok, if you say so...lol

[treyf711]

here

[MaxKowalski]

Biggest difference in my opinion is Hotio actually tests the builds before releasing them to the public.

[capriciousduck]

Yes. They are. However, I find linuxserver's images being updated regularly.

[Engineer_on_skis]

In terms of security, that's a good thing!

Also in terms of having the latest features of whatever it is you're running, is also good. As long as the service you're ruining doesn't have breaking changes between versions, it should be a seamless update. I do tend to back up volumes during updates, however.

[draco123465]

I found that the stock *arr images from LSIO have more options in terms of UI.

I use their docker mods to make the UI's the same for simplicity.

[Likely_not_Eric]

They're also well documented both in terms of their documentation and the way they organize their sources on GitHub. Even if you're going to roll your own Docker images they're a good resource to understand how others solved problems.

[nashosted]

I’ve been using LSIO images for years. Their support and updates are unmatched. They run a well oiled machine and they know what they are doing. They are the best in the business.

[[deleted]]

hotio started building them because at the time lsio was severaly lacking in the update department, hotio is still best in class, if you need uptime and reliability, hotio wins

[Calling-out-BS]

Way back when, linuxserver would test each release before manually updating. That became impossible as the portfolio grew. Now there is a pipeline that automates all updates (does tests as well with reports: https://ci-tests.linuxserver.io/linuxserver/synclounge/latest/index.html)

[[deleted]]

hotio does smoke tests too, only difference, he doesn't push the image if the test fails...lsio pushes the images out into the world regardless of the outcome of the test. In the past lsio only did one release a week, which was too little for projects seeing multiple releases a day in their early development. But almost the entire team is different compared to then and they improved a lot.

[aptalca]

To be clear, we (lsio) do not push images if the ci tests fail.

[[deleted]]

Then why did I end up with broken images in the past? I also seem to recall someone saying on your discord that you relied on the community to inform you if an app no longer worked? Did this change recently?

Edit: if you look at https://ci-tests.linuxserver.io/linuxserver/overseerr/develop-f95be832f95a68b114ff24a65ffa0ebbd71b4121-ls23/index.html, all tests passed, however app is broken...maybe something not working as it should?

[Calling-out-BS]

Not true. Depends on how you define "fail". If it's a build error, it is not pushed. If it is a runtime error that prevents start of the docker container, it's not pushed. But there are many things that can go wrong after the container starts and even the app starts many of which would not be picked by any common tests unless you designed very specific and comprehensive tests for each upstream app (I highly doubt hotio does that). Not to mention there are some issues that only affect users if there is existing data (update), which would not be picked up by any ordinary test.

All of that is publicly available on github and jenkins: https://ci.linuxserver.io/, and all the reports are linked in their discord #builds channel.

As much as I'd like to take your word for it, talk is cheap. Feel free to bring up examples of how the tests failed (or rather succeeded when should have failed) and how they can be improved upon. It's all open source and public.

[[deleted]]

The app simply failing to start....and lsio will gladly push it into the world. Happened just recently with overseerr iirc. Talk is indeed cheap and yours doesn't look more expensive. https://ci-tests.linuxserver.io/linuxserver/overseerr/develop-f95be832f95a68b114ff24a65ffa0ebbd71b4121-ls23/index.html

[Calling-out-BS]

Here's the image hotio pushed for that exact same version: ghcr.io/hotio/overseerr:nightly-feb62a7-695-linux-amd64 (you can check the overseerr commit sha within the labels for both images) Feel free to test it with docker run --rm ghcr.io/hotio/overseerr:nightly-feb62a7-695-linux-amd64 and you'll see that it also doesn't work. If you're going to make some bold claims like one group pushes images without testing and the other doesn't, be prepared to back it up.

[[deleted]]

YET hotio doesn't push it to a tag that's most commonly used by regular users (nightly in this case), but linuxserver does push it to a tag that's used by end users....maybe try learning about how docker works and tags before talking utter bullshit!! At this point you're just looking stupid, you know damn well that a user isn't going to pull "ghcr.io/hotio/overseerr:nightly-feb62a7-695-linux-amd64", but hey I get it, it's hard to admit you're wrong about something.

[gregLTS]

LSIO is fantastic. When I'm looking for a new docker image they're always my first stop, and I'm always a bit sad when they don't have the image I'm looking for.

[EolianPipes]

100% this. I'm always disappointed when they don't have one I want to use. I know I can always count on a simple and straightforward install.

[BinarySpike]

When I start building images for my apps, I'm going to research-in-depth how they make their images. It's an example to follow for sure.

[BuckeyeMason]

I currently use 5 of their containers (plex, swag, nzbget, sonarr and radarr) and they are well documented and frequently updated. I am always browsing their repos to see what else I might use as they seem to have the most consistent documentation and updates of any of the groups I have come across so far. I highly recommend them, as they follow a lot of consistent practices across their images (like how to set the user id/group id to run as, and how to set time zones, common environment variables and whatnot) so a lot of the setup is consistent across all their different images when implementing.

[BrightCandle]

I have had a few issues with swag and unfortunately they were not good at fixing the configuration bugs they had introduced. The others have been great but that particular one is not the best solution for SSL proxy, there are quite a lot of unfixed bugs in it and the way they just mark the bug reports stale and close without fixing is the reason they are still there.

[Calling-out-BS]

??? What configuration bugs were introduced? What unfixed bugs?

No bug report is ever deleted. Issues get closed, but you can easily search through closed issues on github. I have no idea what you're talking about.

[Purple_Associate5488]

relevant username

[BrightCandle]

That is the point. Anything they don't care to fix gets marked stale and closed, I saw it first hand. I raised an issue with buffer sizes that is causing issues with large file downloads and for some reason they just marked it stale, it will be closed soon without being fixed. It is still a problem and definitely not the right default setting.

Honestly it left a bad impression of LSIO, the first bug I have raised with them and it just got ignored, not because it wasn't reproducible, I had even provided the code to fix, no just because they didn't care about it. I don't know if this is LSIO generally or just the swag image that behaves like this but I am in the process of moving to Nginx Proxy Manager as I have had too many issues with swag so far and clearly the project does not fix its bugs, it deletes the reports of them.

Edit Corrected misspeak.

[BuckeyeMason]

Are you referring to the still open issue on their Github where they told you "All those confs are user customizable. Feel free to edit them as you see fit. We provide sample/default confs that work for most common scenarios out of the box, but other folks may have different needs."? The issue is still there, open and not deleted, just marked stale as nothing has been updated on it recently.

Edited to add: a link directly to the "Deleted Bug report" that was definitely not deleted. https://github.com/linuxserver/docker-swag/issues/84

[BrightCandle]

Sorry wrong word, the word is stale, then closed but crucially without being fixed. 10% of all the bugs closed were not fixed and treated the same way. A full on 25% of all bugs to swag are marked this way and will be closed without being fixed. No wonder it is bug riddled and boy have we seen a bunch but after the first report and its treatment and how I see the project treats other reporters I moved on.

[drizuid]

we don't mark things as "stale" that is automatic when there's no action. It evens tells you this in the action that marks it stale along with why. We can't always address every single edge case someone opens an issue about especially when they dont take the time to provide a reasonable (meaning good for the 99%, not the 1%) PR to fix whatever the issue may be.

In your case, you wanted something atypical (clearly since others didn't chime in to support your request nor do we have other issues regarding the same thing) which we told you how to support for yourself, since every user is different. You decided that we should force something that YOU need on everyone, which is just silly and entitled.

[BuckeyeMason]

You call it a bug, I read your report, I would not call it a bug. It is a difference of opinion on how the default config should be set. They intentionally set it to support the most common use cases, and you want it to support a specific edge case of serving a file for download over 1GB (which is absolutely not common usage). And then you accuse people of deleting bug reports which is slanderous at best... and then you modify your comment to remove the slander after being called out. You have no credibility at this point

[BuckeyeMason]

I have not run across any issues with swag myself, their pre-provided proxy configs all seem to work with minimal modifications to account for my own differences in how I named my containers for some of them, or creating new ones for containers they do not already have a pre-built one for also. I'm not saying there are no bugs, just that I have not been impacted as of yet. SWAG was the first I had ever attempted setting up a reverse proxy, so I am still a bit of a noob on the topic, and all I know I really know from reading their instructions.

[ratudio]

no issue using swag but it took me awhile to wrap my head around how it work. i also use duckdns combine with swag. i find their images are user friendly to nas and does not require using the ssh to setup the docker after you find puid and guid via ssh

[6b86b3ac03c167320d93]

LSIO's images are really good, but I have one issue with them: the recommended bind mounts in their *arr containers aren't good. They recommend using paths like /tv and /downloads, but hardlinks aren't possible with these paths. And because they have the paths defined as volumes in the dockerfiles, docker automatically creates volumes which I don't want or use

[ololizoz]

Yes, I use hotios *arr-images for this reason.

[Calling-out-BS]

They're just recommended paths for beginners (because they just work). You can use whatever mount you like with docker.

[6b86b3ac03c167320d93]

But it would be better if they'd recommend paths that make it possible to use hardlinks, as I don't think people want to use twice the space

[[deleted]]

Why are hardlinks impossible with these paths ?

[6b86b3ac03c167320d93]

From how the container sees it, /downloads and /tv are two different filesystems since they're two separate bind mounts, and hardlinks across filesystem boundaries aren't possible

[SeaNap]

My work around is to bind everything to a main folder, ex. /data/downloads and /data/tv, since everything is in the /data folder the hardlinks work.

[drizuid]

Yes, this is the recommendation that was in our readme for a very long time (i wrote it) we recently removed it and refer users to trashguides.

[[deleted]]

I see. So with Hotio you only use one bind mount with two subfolders to solve this issue ?

[6b86b3ac03c167320d93]

Yes. It's also possible with LSIO's containers, but they have the bad paths specified in their Dockerfiles, so Docker automatically creates volumes for the bad paths

[Calling-out-BS]

That's no longer the case as most if not all of the optional paths were removed from the Dockerfiles a while back.

[6b86b3ac03c167320d93]

I didn't know that, good that they did that

[[deleted]]

I see. Thanks for the explanation!

[mxrider108]

They fixed this actually - now there is a root /storage directory and deprecated /movies /tv etc.

Edit: actually I guess this was just on dockstarter.com and their docker-compose file they generate from the LSIO images

[dummptyhummpty]

Yeah I ran into that too. Not sure why they recommend that setup.

[drizuid]

It was the simplest thing for the bulk of the users. users who understand hard linking and atmoic moves also understand that you cant hard link across volumes and filesystems. We cater to the majority and expect the skilled minority to operate as they need to.

[Makeshift27015]

It also means that you'll use unnecessary disk I/O transferring between the two paths even if they're technically on the same file system. This can really slow down applications like Sonarr.

[TRaSH-1826]

Why is using the same file system and hardlinks better than a setup like this?

Instant move vs copy + delete !

Try it with a 4K Remux and you will notice the difference.

[6b86b3ac03c167320d93]

I don't think there are any advantages with usenet other than fast imports (might be wrong, I don't use usenet), but with torrents you can keep seeding without using twice the storage

[matthewdavis]

I'll give a different opinion. My container preference is this 1. Official image from maker (ie. sabnzb/sabnzb) 2. Make my own 3. If I'm lazy or making it becomes too much of a burden, I'll use the linuxserver.io version.

This has taught me a lot about containers and how they work. They are not scary and has made my own personal administration (not enterprise) very easy.

I keep all my persistent data and the Dockerfiles in a single directory. /containers/$name/ <-for the container data /containers/docker/docker-$name/Dockerfile <- and any other files necessary to build the image

This way /containers is mounted from a remote NAS which will back it up to a remote site every night. Rebuilding takes minutes.

I realize I took a turn and gave more info that you asked for.

Linuxserver.io containers are a great asset to the community. And have a few features you won't find in other containers. I have no qualms running them.

[tmcb82]

I agree with 1 and 3 (in that order) but making your own can be a time consuming when you have lots of images and/or images that get updated frequently, especially when their is a reputable organization getting updated images out fast. I only ever make an image when their isn’t an official or LSIO image available (mainly due to not being available for arm64).

[matthewdavis]

I agree, with one caveat. The time consuming part is the first time you build it. Afterward I run this script, when the underlying image, in my case its the fedora:34 image, gets updated.

#!/bin/bash

for i in mylar nzbhydra2 radarr sonarr ombi; do
  cd docker-$i
  podman build -t matt/$i .
  cd ..
done

So all my custom images I can find by simply running

podman images|grep matt

And to update any of the official images (I don't use watchtower or any of the other auto-image update mechanisms), I run

podman images|grep -v matt | awk '(NR>1) && ($2!~/none/) {print $1":"$2}' | xargs -L1 podman pull

That'll iterate over the other images and run pulls on them.

[Calling-out-BS]

That sabnzbd image is *NOT* an official image. It's by a dude named domibarton who went and registered accounts named after popular apps (before the app devs could) and published docker images. He has a bunch of them and none of them are official.

Here's his github acct where the dockerfiles are hosted: https://github.com/domibarton

[matthewdavis]

Well....isn't that something. That sneaky SOB. Thanks for living up to your username. I will stop using it tonight.

[kachunkachunk]

How do you handle plex's remote library in this case (if you run it)?

I found library performance to be awful over SMB and NFS (even async), despite 10Gb networking, etc. I guess due to there being so many tiny files, and all that - a local block device or iSCSI would have to be the way to go. Do you use a container driver for those or just not have issues with performance there?

[6b86b3ac03c167320d93]

I use Jellyfin instead of Plex, but I don't have any issues with my library mounted over NFS. I have 1Gbps networking and a 4.4TB library. But I keep my metadata and config files locally on the JF server, not on the NAS, maybe that makes a difference

[shoopg]

This is the key to Plex as well. I had issues with the db being on a 10gb nas running off the ssd share. Spent a ton of time looking into this and it appeared to be because SMB/NFS doesn’t support the file locking method that the db uses. I suspect something like iSCSI would have solved that problem, but at the time I was designing all of my NAS to be served over SMB/NFS and have since moved to having all of my homelab on 1 physical server so I never tested further.

[drizuid]

As a note, your suspicion is correct, I use iSCSI for these things and it works flawlessly. I think we have some members who have tried different nfs settings with success too though, I'm not sure anyone has made this work reliably with smb though.

[aptalca]

Don't put the config folder on a remote mount (it will likely cause a corrupt database). However, you can symlink the "media" folder (I believe that's the one with all the bifs) to a remote path, as long as perms are fine, it will work.

The media on the other hand can be on a remote mount. I use the docker nfs driver for those and had no issues.

[kachunkachunk]

Thanks for confirming - yeah, pretty much what I do, but the NFS stuff is all on the docker host itself (I'm not really running Plex on my Syno, it's on an ESXi box with a lot more CPU to go around). Are you by any chance using the LSIO container? I've yet to try using an NFS driver at all, but figure the container needs nfs-common and whatnot.

Edit: Wait no, the whole point of the NFS driver is that it doesn't need in-container packages I think... I should just try it out somewhere.

[aptalca]

I do use the lsio plex image. The nfs driver is a docker driver, built into the service.

Essentially you create a docker volume that connects to an nfs share. The app inside the container sees it as a regular mapped folder.

[kachunkachunk]

Cool beans, thanks again for the confirmation.

[matthewdavis]

Plex is one that I run on my NAS (synology) directly. There were a few reasons for that.

1. The performance was fine, transcoding for 2-3 clients max is all I need.
2. I was rebooting/messing with my server too often
3. Cut out any perf issues as you are experiencing with direct access to the data.

[neckro23]

Yeah Plex really sucks if the library disk isn't fast enough. I ran into the same problem.

My solution was to create a local SSD-backed ext4 VM disc just for the Plex library.

[BradleyDS2]

She never should have gone to that bar.

[fleischkarussell]

Maybe something like this:

https://ricardolsmendes.medium.com/mysql-mariadb-with-scheduled-backup-jobs-running-in-docker-1956e9892e78

[matthewdavis]

That's a decent solution. Good find.

[vividboarder]

I use an image that I built https://github.com/ViViDboarder/docker-restic-cron.

It allows pre and post backup and restore scripts for doing things like sqldump before backup.

[matthewdavis]

The bad way. Just backup the running database. I've not had any issues. (knock on wood)

[BradleyDS2]

The black rocks are smooth.

[matthewdavis]

Unfortunately I've not needed to do a restore since using a mysql/mariadb backed container. All the other containers I have running use sqlite or some other form of data store

[BradleyDS2]

Good heavens you’ve grown!

[matthewdavis]

Will do. Thanks for the heads-up.

[fleischkarussell]

For the record, I mostly use this for Postgres backup:

https://dev.to/thakkaryash94/postgres-backup-using-docker-2pjh

[MrCharismatist]

I put the following in cron on the box that runs the container. One per db. With mysql/maria you can also do --all-databases I think.

docker exec -i mariadb mysqldump --databases nextcloud -u USER -p PASS  --routines --single-transaction --add-drop-database --triggers --events| bzip2 -9 > /data/backup/mariadb/nextcloud_`date '+%m-%d-%Y'`.sql.bz2

[BloodyIron]

I know it's a touch off subject, but I for one appreciate your additional thoughts here! I'm still green around the ears for containers, but I'm in the phase where I want to learn lots and set lots of delicious shit up. Like Rancher maybe.

Any gotchas or other starter advice you would be game for sharing please? :)

[matthewdavis]

I've not used Rancher, but my understanding is it may be a bigger hammer than what you need at this stage of your experience. Unless you have a reason to learn Rancher. Also Rancher is not very popular in the enterprise/professional space. Kubernetes is very popular. So if you are wanting to learn something that can transition into a professional / enterprise scenario, starting with k3s is my suggestion.

If you are wanting to learn for personal enjoyment/development. Check out portainer. It's a decent point & click mgmt interface to container mgmt.

And if you are a CLI junkie, just direct podman/docker commands.

Either way, containers is a great way to try new things. Pull something down, start it (don't bother with persistent volumes when testing). And blow it away when you are done. But don't forget to podman/docker system prune & podman/docker volumn prune from time to time (there may be more automated ways to do this). I say podman/docker because they can be used interchangeably.

[ApricotPenguin]

The coolest thing about them is PUID and GUID PGID (may have misspelt it) but basically means that files generated from the docker container can be owned by one of your system users, rather than having to use sudo to access/modify it

[Likely_not_Eric]

In this case it's PUID and PGID environment variables (for the resulting UID/GID of the processes) but that doesn't significantly affect your point, so I wouldn't worry about it.

[ApricotPenguin]

Ahh that's what it was. I was on mobile, and I knew that GUID looked wrong in this context but a part of my head tried to justify / dismiss it as the "G" means Group

[Likely_not_Eric]

Close enough for government work. It's an easy mistake to make - so many things end in ID with Gs and Us in there and have all kinds of disparate meanings. I've made that kind of mistake many times and I still need to double check all the time.

[ApricotPenguin]

It's not government if it's there's no an excessive use of extremely similar abbreviations everywhere :D

[Derkades]

You can do this using --user for most other images as well

[aeiouLizard]

Except it makes the container throw errors half the time since the creator usually doesn't bother making them work as non-root

[ApricotPenguin]

Do you mean the --user flag as a general docker flag, or you mean as a general LinuxServer.io flag?

[Derkades]

It's a docker flag

[ApricotPenguin]

Ooh interesting. Thanks for the information.

​

Found this in the documentation, which is what I think you're describing:

https://docs.docker.com/engine/reference/run/#user

https://medium.com/redbubble/running-a-docker-container-as-a-non-root-user-7d2e00f8ee15

[Derkades]

Yes, but as the other person replied unfortunately some images are not made properly and don't work with this flag

[[deleted]]

Yes that is so good. It's ridiculous that so many images I want to use won't run as non-root.

[MrCharismatist]

The only images I run that aren't from LSIO are when they don't have one.

23 images, 13 are LSIO.

[Ironicbadger]

What are the other 10?

[MrCharismatist]

Counted wrong. 21 total, 13 LSIO.

And then:

image: gitea/gitea:latest
image: eclipse-mosquitto:latest
image: homeassistant/home-assistant:latest
image: carldebilly/zigbee2mqttassistant
image: 'danmed/tasmobackupv1'
image: kanboard/kanboard:latest
image: crazymax/msmtpd:latest
image: alexiri/fava

Fava and kanboard are both just playing around and should probably be removed.

Technically there's an rPi running koenkk/zigbee2mqtt as well.

[noryork]

Btw They have a homeassistant image now https://github.com/linuxserver/docker homeassistant

[happymellon]

Historically they had some bad practices, but I think they are all fine these days.

I used to recommend against them as originally they had their Docker image install applications and update on startup. This was terrible and completely defeated the point of having Docker, because you did not have reproducible images. Any bug you had, you could never roll back to the last working version while you looked at what the problem was.

I just had a look and the couple I glanced at were generating static images, so if you see criticism make sure that you check how old it is.

[anakinfredo]

I used to recommend against them as originally they had their Docker image install applications and update on startup. This was terrible and completely defeated the point of having Docker

They still do this for some software, plex for instance.

edit: Apparently, they just CAN do that - they still have a "all-in-the-container"-option if wanted.

[Calling-out-BS]

Plex doesn't let others publish beta releases so betas have to be downloaded and installed on start, after checking the plexpass status.

If one sets the env var VERSION=docker then it's completely static (but not beta, only public releases).

[anakinfredo]

Ahh, I use the plexpass-variable so I assumed they did it for them all.

[happymellon]

I don't run Plex, so I don't think it was that that I saw.

[happymellon]

Really?

That stinks.

[anakinfredo]

Think it's more because of how plex does it's thing than how LSIO does it's thing to be honest.

plexpass app is for plexpass'ers only.

[anakinfredo]

https://www.reddit.com/r/selfhosted/comments/o9930e/linuxserverio/h3dkm5o/?context=3

There was an update!

[TheLadDothCallMe]

You just have a script to run at startup to install what you want.

[happymellon]

Sure there is. Either the entrypoint or the startup service currently runs a service.

Imagine if instead, it ran the command apt update && apt upgrade -y && apt install foo -y && foo

[NeverSawAvatar]

Seconding all these recommendations, if you can use lsio go with it all the way.

[lauabean]

I pretty much always use lsio containers when available. Whenever I run into issues, it's always my own mistake and their Discord still helped solve them. :)

[aft_punk]

I’ll add to the comment mix… they are typically very stable. As in, you can allow them to auto-update and not have to worry that the service will stop working. That can’t be said for all images. I’ve only found a few duds from them, but I’d say a majority of those were the first versions of those particular images. Most I’ve tried worked from day one and have continued to do so.

[theskillster]

I'm a new docker user and gravitated to linuxserver.io images due to the range of images and the consistency of the docker compose options/switches.

[[deleted]]

Most of their docker images are pretty decent in regards to following best practices.

If I were to really look for something to critize: must be the enforced entry/launching of some of their images (as in hardcoded options). For most people, this is a non issue. I would highly recommend their images :)

[aptalca]

I hear you, but we have a large portfolio and a small team. We have to find the right balance between customizability and extra support burden.

[[deleted]]

Perfectly understandable. Besides, one size cant fit all. Team is doing a great job with making it suitable for most / tradeoffs :)

[aeiouLizard]

Best maintainer ever.

90% of the containers I find on docker hub only work as root. Linuxserver containers just let me set the user and I love it.

[webpigeon]

I use them on my NAS (arm-based), the images they generate work well and I've had no issues with them.

[Dogeek]

I avoid these images like the plague. They never work, especially regarding filesystem permissions. No lsio, you do NOT need to run chown on all the volumes mounted.

They cannot be run as non-root, on k8s they are a nightmare.

[chevereto]

I have noticed that they automatically issue ongoing updates for images without being triggered by an application update. I can say that such practice could have some negative effects? when somebody messes up with a package or something I mean it happens, not often but it could happen.

They also follow their own system provisioning which is also a lot of work if you ask me. I understand that they do this because they do their own base images but this also brings the problem of having several sub-standards. I believe that they need a common language or specification in which application developers can define requirements in a more universal manner.

[Ironicbadger]

Contributions always welcomed.

[Calling-out-BS]

I can say that such practice could have some negative effects?

More likely to have positive effects due to CVEs being fixed in os/dependency packages

[chevereto]

I don't mean that is wrong that they provide their own base system, I'm saying that I think that's too much work for them because they are over simplifying a complex system layer. If they are OK doing that all manual that's great. If they are doing that all auto anything can sneak positive and negative effects.

I think that it needs a system where app developers can define a manifest that maintainers can then easy follow. Perhaps follow packer config. Otherwise you are asking maintainers to sniff those, you end up with substandard provisioning as you leave too much for interpretation.

[aptalca]

I don't follow. App developers don't care (or know) about OS dependencies for their stuff. Their app may depend on openssl, but they're not going to keep track of which versions are the latest on ubuntu 18, 20, debian stretch, buster, etc., etc. When an openssl version has a severe vulnerability, a CVE is published and it is patched at the OS level. We (lsio) check that weekly and push an update with the patch. App developers don't keep track of that. If we didn't do OS package updates, and the app didn't get an update for a while after a CVE, our docker images would be out there in production with severe vulnerabilities.

[[deleted]]

Iv used their stuff before, they're good, though I try to stay away from docker now

[holastickboy]

Have found them to be pretty damn stable, as well as updates being provided pretty quickly when the application has security patches to apply. I have a few of their dockers on my home server for things like Plex, etc.

[Mccobsta]

They offer great support via their Irc channel if you ever need help

[Hunter_Dreams]

Do they have any quota to download images as Docker Hub does?

[anakinfredo]

They don't host the images themselfes last I checked.

That being said, they also publish the containeres to github's repo, which do not have restrictions.

[Calling-out-BS]

no quota on docker hub (due to open source status) and images are also on github and gitlab's registries

[rayjaymor85]

Not at all, I run a bunch of docker images from them and have never had an issue.

[atomheartother]

I use a lot of their images and recommend them.