jkm9000

Thanks!

Came here to ask the same thing.

Reading that, all I could think of is Homer saying "That's how I was raised and I turned out TV." That's a whole lot of TV you've got going there!

You beat me to it, but I was just going to say that something like this seems like it would make sense for a 6.x release (where x >= 1). I gave up on AFP ages ago with unRAID, but I do have a dedicated TimeCapsule so it isn't too critical. I would love to see it improved, but not at the expense of what has already been outlined for a Q3 release. Surely that's reasonable.

That should handle any other lurking edge cases from the CLI output and be a lot more stable moving forward.

New version fixed my issue, thanks!

Here you go.

Thanks for this One cosmetic issue. I have a custom plex Dockerfile which gets started like so: docker run -d \ --name="plex" \ -v /etc/localtime:/etc/localtime:ro \ -v /mnt/cache/appdata/plex:/config \ -v /mnt/user:/data \ -p 1900:1900/udp \ -p 15353:5353/udp \ -p 32400:32400 \ -p 32410:32410/udp \ -p 32412:32412/udp \ -p 32413:32413/udp \ -p 32414:32414/udp \ -p 32469:32469 \ plex Under the name column I get this: 0:15353->5353/udp, 0.0.0.0:32400->32400/tcp, 0.0.0.0:32410->32410/udp, 0.0.0.0:32412->32412/udp, 0.0.0.0:32413->32413/udp, 0.0.0.0:32414->32414/udp, 0.0.0.0:32469->32469/tcp plex The other containers show just the --name= value.

Gotcha. You could always have other users drop their public key in the build directory. If it's there use it. If not, it just would not enable ssh.

You only need to build the container once though. The real advantage here is that you're using a unique key instead of a public (insecure) one. Or maybe I'm missing something?

boot2docker is great when you are using an OS without support for Linux containers. Since unRAID's kernel has support for this, it's an extra layer that isn't needed.

I think their points apply more to the enterprise than the home user. I'm certainly not going to setup one container for an app itself, another to edit the config of that app, another to view the logs, and another to be able to restart the app. That seems like a lot of complexity for a home media server. For a situation with lots of developers, that approach makes much more sense. I don't think there is one "best way" to use docker because the ways it can be used vary so much.

You can pass along your own public key as outlined here https://github.com/phusion/baseimage-docker#using-your-own-key nsenter might be another option https://github.com/jpetazzo/nsenter

Good points. Valid. To quote the phusion README: "By the time that you've gotten all that right, you've reinvented baseimage-docker. Using baseimage-docker will save you from this effort."

It's worth noting that phusion isn't some random guy, it's the company behind Passenger among other things. As far as distros go, it's great you want to run with the one's you've mentioned. I'm going in a different direction though.

Care to share your dockers? I've looked at creating some dockers with that as a base, but just can't find the time to finish. I'm using SAB & NzbDrone now, and will probably look into adding a torrent app one of these days. I hate to add to the noise, especially in a thread about moderator approval for dockers But it's quite simple, their docs give a template Dockerfile to use with a note on where to add your own build instructions. So all I've done so far is to take any Ubuntu docker, change the base image to phusion's and then put the body of the ubuntu file into the appropriate section. Perhaps later I could post them in another thread. But I'm also still playing around with some concepts/config and they just released a new tagged version today I need to checkout.

I had posted this before, but that thread has since been deleted. I've been using this as the base image for a lot of apps and it has worked out very well so far: https://github.com/phusion/baseimage-docker I like that it's based on ubuntu, so the app repositories are available. It also avoids upstart which, as grumpy mentioned, has a lot of issues with docker. They've done quite a bit to make it compatible with docker, and it is currently the #3 most popular repository on docker's hub. I'm all for thin versions of Linux, but at the same time, the bigger distros tend to have more packages available and there's less fussing about to get some random app working unless you want to go down the compile path. Not really trying to convince anyone or fuel a distro war. I'm sold on it for now and thought others might like the approach.

Sorry I should have been more clear, emhttp was still running and port 80 would connect. Issuing a GET / command would return nothing and eventually the connection dropped. Furthermore there was nothing unusual in the syslog... I had been doing a drive rebuild and had a syslog tail running the whole time as well as a display hooked up to see any errors that might show up there. Yes, I have 16 GB of RAM but I have had that for around a year and a half and the system has been rock solid. So if others have problems with more memory it has not impacted me and I run several add-ons. Only 2 things have changed recently. 1 Upgraded unraid from rc4 to rc8 and 2. Upgraded simpleFeatures to v 1.0.5. I have seen other people having issues since upgrading sF to 1.0.5 so that seems the likely candidate to me as I'm not seeing reports of this happening with rc8 (perhaps I've missed). My post drive rebuild parity check is nearing completion so I will be able to reboot with the older sF and see if that helps. I am having emhttp issues as well. See here: http://lime-technology.com/forum/index.php?topic=23274.msg205583#msg205583 As mentioned I have uninstalled the SimpleFeatures CORE plugin and since then (>5 days) I have had no WEBUI crashes. http://lime-technology.com/forum/index.php?topic=23274.msg211818#msg211818 I am running with 4GB memory.

Are you running simpleFeatures 1.0.5? I am having the same problem since upgrading to that version. Earlier versions had no problems but there are others in this thread having the same thing w/ 1.0.5 http://lime-technology.com/forum/index.php?topic=12698.msg212637#msg212637 Not sure what is going on but once I am able to reboot I am going to downgrade simpleFeatures and see if I get my stability back. With an earlier version I had no issues for months. Now I am locked out of the web UI but absolutely nothing gets logged and the system is otherwise stable.

I'm having the same problem. Happened while doing a drive rebuild too All the drive lights are still going and nothing in the syslog so I think it's still doing the rebuild. These are the plugins I have installed: simpleFeatures.active.streams-1.0.5-noarch-1.plg* simpleFeatures.activity.monitor-1.0.5-noarch-1.plg* simpleFeatures.core.webGUI-1.0.5-noarch-1.plg* simpleFeatures.disk.health-1.0.5-noarch-1.plg* simpleFeatures.email.notify-1.0.5-noarch-1.plg* simpleFeatures.log.viewer-1.0.5-noarch-1.plg* simpleFeatures.system.info-1.0.5-noarch-1.plg* simpleFeatures.system.stats-1.0.5-noarch-1.plg* telnet localhost 80 hangs as well, so not a browser issue. Is there any logs I can look at / provide before I reboot? Looks like I am suffering from this now as well.

I have a samsung (HD203WI) that I've isolated as the source for some very slow parity checks. Previously I was getting 90MB/sec+ parity checks on a 12 disk + parity system, but the past few days have been around 23MB/sec. Nothing showed up in syslog and the SMART tests all passed. However, when I run hdparm I get some interesting results: root@Hal:~# hdparm -tT /dev/sdk /dev/sdk: Timing cached reads: 19782 MB in 2.00 seconds = 9915.27 MB/sec Timing buffered disk reads: 28 MB in 3.10 seconds = 9.02 MB/sec root@Hal:~# hdparm -tT /dev/sdl /dev/sdl: Timing cached reads: 21672 MB in 1.99 seconds = 10864.71 MB/sec Timing buffered disk reads: 280 MB in 3.00 seconds = 93.26 MB/sec /dev/sdk is the Samsung drive which just tested @ 1.68 MB/sec and is going to be replaced. It is definitely the drive as I've moved another drive to its slot and it tests fine, move the Samsung to a known good port/cable and it remains slow. I have actually seen this once before in an iMac... drive performance was abysmal yet every hardware test passed with flying colors. Once I replace the drive, I'm going to setup automated hdparm tests once a week in case this happens again. But I am really curious what causes this when all tests pass and nothing gets logged. Any ideas?

Right, those lines are only so that the modules can be compiled, which happens once. The final package includes the binaries. On my way out, but I can add a section to the wiki page with more information later.

Both. You install the app then make a package so it will persist across reboots. It won't install properly without changing the symlinks.

5.0 scripts. Made one change to the first script to grab the correct kernel: [ ! -e "linux-$KVERSION.tar.gz" ] && wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-$KVERSION.tar.gz Then before installing VirtualBox, I ran the lines above to correct the lib/modules links. The only other change from the wiki was in the second script, since I used the latest VirtualBox: VBOXVERSION="4.1.18"

Ran into a problem getting things working with v5.0-rc4 and wanted to share how I got things working with VirtualBox-4.1.18-78361-Linux_x86.run I used the scripts on the wiki with the only changes being pointing the kernel source to the v3.0 url as others have noted and bumping the version number in the package making script. The problem is that the kernel modules used by VirtualBox were not being built, so nothing worked. To fix this, I did the following: rm /lib/modules/3.0.33-unRAID/build rm /lib/modules/3.0.33-unRAID/source ln -s /usr/src/linux /lib/modules/3.0.33-unRAID/build ln -s /usr/src/linux /lib/modules/3.0.33-unRAID/source Once these changes are made, the kernel modules get built and installed. Haven't setup anything beyond building the package yet, but the modules do show up in lsmod so hopefully I'm set. Confirmed working well, first vm up and running!