ironicbadger

As a user, I would definitely prefer this. Cramming support for 10 dockers into a single thread makes it very difficult to find relevant information. Done. I invite you to go look at the top of this subforum now. All you can see is my 7 threads and a jillion pinned ones. Come on LT, sort this out! Appreciate it, hopefully others follow suit. Do you have a link to each thread from your repo post? That'd be helpful as well. Good idea. I'll get on that.

Merged already. Thanks.

With notifications why does it matter? And the users have asked for it, so we should oblige.

You see, this is why collab is great.

I'll get to that! Only just made them, gimme a chance!

As a user, I would definitely prefer this. Cramming support for 10 dockers into a single thread makes it very difficult to find relevant information. Done. I invite you to go look at the top of this subforum now. All you can see is my 7 threads and a jillion pinned ones. Come on LT, sort this out!

This thread is the official support thread for LinuxServer's NZBget container. OP will be updated later with more relevant info.

This thread is the official support thread for LinuxServer's Quassel-core (IRC) container. OP will be updated later with more relevant info.

This thread is the official support thread for LinuxServer's Plex container.

This thread is the official support thread for LinuxServer's Mcmyadmin container.

This thread is the official support thread for LinuxServer's CouchPotato container.

This thread is the official support thread for LinuxServer's Sonarr container.

This thread acts as the official support channel for LinuxServer's Smokeping container. I'll update this OP with more info about what Smokeping is / does later but if you want a badass example of what it can do then take a look at http://smokeping.ucdavis.edu/cgi-bin/smokeping.fcgi.

We always welcome contributors, fork it on Github and send us a pull when you're done. Oh and join us on IRC freenode #linuxserver.io to discuss specifics if you wish.

Welcome, glad you like it. Its neat isn't it? I haven't added that feature yet. I wasn't totally convinced of Smokepings stability yet but its just been running for a week for me at hone and on my VPS. I guess I can tick that box and move onto features. You can of course modify the Targets file in /config volume to change the ping targets. I'll get around to sorting out the email thing hopefully by the end of this week if work quietens down a bit.

Thanks for all the help with the teething issues chaps. We're new at these XMLs!!

That is essentially true, but there are certains things that if implemented can make a docker more suitable for unraid, uid and gid being the main one, using the TZ variable (passed with the bind time feature from the template) in containers where timezones are important is another, although the TZ variable can be passed manually from the comnand line of course on non-unraid boxes. If you're building a container you're on the command line anyway...

There are some 'best practices' appearing on these forums for unRAID Dockers but I can't for the life of me figure why they'd want to depart from the standard Docker thinking. As I keep saying, Docker is just a packaging mechanism and is completely platform agnostic (or should be if done right). Basically what I'm saying is, any Docker guide will do. Docker is Docker, even on unRAID.

Create an unraid organisation on github and BOOM.

It does? How is auto-updating on startup using `apt-get update -y` any different from what `docker build` would do as part of a Dockerfile? If malicious people are able to get their malware into the upstream repo's we're all f**ked anyway. Not going to happen. At the risk of being incendiary, comparing a forum hack which are (sadly) now common place to a repository hack is not a fair comparison at all. The only scenario in which I agree with your comprising of where they pull the auto-update from is if the code is hosted on some random web-server that isn't git or something. Most updates are likely to be `apt-get update -y` or similar as I've already stated if this mechanism gets compromised then a lot bigger problems than Docker containers exist. Imagine all the servers around the world that would go down. Sheesh. Long story short, I don't believe auto-updating poses any greater risk. In fact, arguably it increases the lifespan of the container meaning that end users are not reliant upon the maintainer to update software if problems are found. There are dozens of containers on Docker hub which have old, outdated software and it's a huge problem that Docker is trying to address. Noone has found the silver bullet yet, if you have then we're all ears.

I saw this at the time but thought a reminder couldn't hurt.

I didn't build the image and have no idea how to So kinda stumped at this point. Prior to this I'd exec into the docker and start the script and leave it, but now the tower is headless so can't do it. Give us some more info then. What's the script you need to run? Which container etc....

I'd rebuild the image using the Dockerfile to run your script at build time or modify the CMD to include your script somehow. Does that suit your needs?

https://github.com/docker/notary That will go some way to helping when it's released. You can always verify containers do what they advertise by viewing their Dockerfile's on github etc. It requires knowing a little about Linux to understand the innards though. You can look at the containers on Docker hub too and review the comments to see if anybody has raised such an issue. With a fully open-sourced solution like Docker it's highly unlikely anyone would try anything nefarious and not get caught. Docker is just a packaging mechanism and whilst it's possible to include unsolicited packages within this structure, a self-policing community such as this will go a long way towards solving your concerns.

perhaps adding another thread isn't the best idea considering the title but I think this sub-forum has too many pinned threads. I suggest splitting the Docker subforum into sections like 'Getting started / Guides / How-tos', 'Now you're up and running, here's where to find support', 'Repositories and Container dicussion / maintainer announcement threads / look at the new shiny we've released!'. I dont think it need be any more complex than that. Reduce the number of pinned threads to a bare minimum too. It's way too much at present.