coppit

Okay, I just pushed an update with these changes: - Capture errors from "curl". Show them, and make them nonfatal. - Treat "good" and "nochg" without an IP as successes. (Even though this violates the API.) - Note that in my testing I saw "nochg" even when my credentials were invalid - Wait 30 minutes before retrying when the status is 911, as requested in the API docs.

Yeah, sorry about that. The new way is better, and I was thinking that not too many people were using this container yet. Wha??? "nochg" violates the API. It should be "nochg<space><ip>". Sigh. I guess I can treat that as a success. Are you sure that the domain is working right?

Hm... That's not supposed to happen. I suppose I could ignore empty string. Or at least tolerate it happening intermittently before failing. I suspect that curl had trouble connecting, but didn't dump any error since I'm running with the "silent" flag. I'll try to improve that. cron jobs don't send logs to "docker logs". Plus I want to stop if there's a problem. Otherwise your account can get blocked. I'll update it to be more tolerant of network failures.

Nice! Can I link directly? i.e. Will it be there for a while?

I've updated the container to make it easier. The first time you run it, it will create a noip.conf file. Edit the file, then start it again. You should be good to go!

Right. That should work.

No-Ip requires an interactive setup. Did you do the command line step as described on the web page? If you used the unraid template without setting it up with the command line, I could see that causing a problem. You might find duckdns easier to use, if you don't want to deal with the command line.

In case anyone is wondering how to get Windows machines monitored: Open control panel In "Turn windows features on and off", install SNMP Open "Services" and double-click SNMP Service (Not SNMP Trap) On the security tab, set the community to "public" and accept SNMP packets from your UNRAID server As far as temps, it looks like you have to install a 3rd party module to enable capture of the temps. http://serverfault.com/questions/156536/how-can-i-monitor-cpu-temperature-in-windows-over-snmp

But do let me know if you see any important setting that survives a stop/start of the container but not a delete/recreate. I can fix those.

I think it might be a FileBot problem with the Linux version. Even if I simply stop and start the FileBot app without restarting the container, the app doesn't remember the input directory. IFAICT, the only thing it remembers is the main panel selection.

Fixed. Link is https://www.dropbox.com/s/agued77qhqhdaii/cap.png?dl=0 I don't know how much time you want to spend debugging this, but I've updated the container to drop a filebot.conf file into the config directory when it starts. You can set DEBUG=1 in there to have it dump the raw events that it gets from inotifywatch. They're very confusing (and sometimes very surprising and enlightening), but might help you understand what's going on. Perhaps I need to add a new event to my list of "things that should trigger a FileBot run". This can happen depending on how long things take. In the config file you'll see a few different settings for controlling how eagerly we run FileBot. For example, I doubled the "settle time" from 5 seconds to 10 seconds. That means that the directory needs to be idle for more than 10 seconds before we'll run FileBot.

Dang sorry about that. Fixed and tested. I also switched to a specific mirror. When fixing it I noticed the version change yet again from -1.txz to -2.txz. It looks like the various mirrors have slightly different package versions. Note: Because the version dropped from 5.7.3 to 5.7.2, folks will need to manually uninstall and reinstall. "Upgrade" won't work.

Edit: Fixed link Whoops! Is should look like this: https://www.dropbox.com/s/agued77qhqhdaii/cap.png?dl=0 Actually, all your settings were ignored. The container has a default umask of 0000, which is why it happened to work even though the user/group was still root/root (again the default). I didn't have it searching for changes recursively. So one way the above could happen is: 1) Subdir gets created 2) FileBot sees it, and processes it 3) File gets put in subdir 4) FileBot misses it. I've enabled recursive monitoring, so you should be good now.

I confess that I haven't looked very hard at what PhaZe has done, except to see that he's building is now tarball, which I'd like to avoid. Weird. I'll update it. I'm not sure I want to require a reboot to clean up, but that does point to a solution: 1) Uninstall snmp 2) Remove the /boot/packages/perl...txz file 3) Leave perl installed on the system, so that other plugins don't break unexpectedly 4) When the user reboots, the other installed plugins will re-download perl...txz and reinstall it. Boot is a little slower during #4, but that's a one-time issue. Everything should work correctly. Plugin updated for these two issues. Thanks!

Thinking about this some more, the umask might have been setting the group permissions so that the file wasn't writable. (And my newperms automated runner was "fixing" it, which is why I didn't see this.) I've updated the container again with umask support. You'll need to update the environment variables again, setting 3 of them instead of the one UGID one before: "USER_ID=99", "GROUP_ID=100", and "UMASK=0000". Hopefully that fixes it for you. It looks to me that FileBot creates the files with 0664 permissions.

Hm.. what user do you have that share mounted as? What were you trying to do, rename the file or something? Can you telnet/ssh into your server, and do: ls -l /path/to/that/file id -ng mount_username For example, I mounted the share using user "privacy" which has group "users". FileBot creates the file for me with owner "nobody", but group "users". The file permissions are -rw-rw-rw, where the second rw means that group "users" can read and write the file. Since "privacy" is in that group, I can rename the file just fine. If that all looks good, maybe try checking the permissions on the parent dir: ls -ld /path/to/that

SNMP is a standard way to get raw data from devices, for monitoring purposes. With this package, you can hook your UNRAID server up to a monitor, and track things like network usage, cpu activity, even user logins. https://raw.githubusercontent.com/coppit/unraid-snmp/master/snmp.plg I recommend installing zukhov's Observium docker container. It can then track your server's status. See the Observium website for some idea of what it might look like. Here's an example pic. The plugin reports disk temperatures and share free space using the "disktemp" and "sharefree" extensions. For example: snmpwalk -v 2c localhost -c public 'NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp"' However I don't know how to get Observium to track them. Help would be appreciated! Warning: This plugin has only been tested for UNRAID 6. This plugin requires that you install Nerd Tools first. That's how it gets perl.

How are shared dependencies handled? e.g. SNMP requires perl. If I install perl, then later uninstall it when the plugin gets uninstalled, will that potentially break some other plugin that also installed perl (as a no-op)? Or should we have a standard perl plugin, and have SNMP fail with a helpful error message if perl can't be found?

Excellent question. It triggers when the file is closed in write mode, not when it's created, read, or written. inotify is a bit funky. For example, it also triggers for new directories, for the case where someone copies a directory containing a ton of files into the watch dir. I thought about allowing the user to customize the events, but given how funky inotify is, I figured that would be too complicated for most users. Note that this doesn't prevent your command from stomping all over a file that's being written, after being triggered by another file that was write-closed. So, for example, you wouldn't want a command that moves files out of the watch dir blindly -- it would need to use lsof or something to determine which are safe to move. Here's the full list of file events: ATTRIB CLOSE_WRITE,CLOSE MOVED_TO MOVED_FROM DELETE And dir events: ATTRIB,ISDIR CREATE,ISDIR MOVED_TO,IS_DIR MOVED_FROM,IS_DIR DELETE,ISDIR

Okay, it's fixed. But you need to do three things: Click on your container, then the "Advanced" button in the top right, and add a new environment variable called "UGID" with value "99:100" Run "chown nobody:users /path/to/config/*" When you first run it, it will exit and complain in the logs about a filebot.sh version change. You'll need to edit your filebot.sh, bumping the version number to 2 and changing /root to /files People who create new FileBot containers from my template repository won't have any problems, but existing containers will need a manual update.

Edit Jun26: Updated for the new USER_ID, GROUP_ID, and UMASK config settings. Hi all, I've created a container that uses inotify to watch a directory for changes, then invoke a user-specified command. Documentation is here: https://registry.hub.docker.com/u/coppit/inotify-command/ The easiest way to use it is to paste this URL into your template repositories, then use the template when creating a new container: https://github.com/coppit/docker-templates You create a config file for each dir/command pair. There are lots of ways to use this. Here's an example: newperms.conf, for running newperms whenever there's a change in the cache directory: WATCH_DIR=/dir2 SETTLE_DURATION=5 MAX_WAIT_TIME=30 MIN_PERIOD=30 COMMAND="/root/newperms /dir2" USER_ID=0 GROUP_ID=0 UMASK=0000 # This is important because chmod/chown will change files in the monitored directory IGNORE_EVENTS_WHILE_COMMAND_IS_RUNNING=1 sagetv.conf, for telling SageTV to rescan its imported media when the media directory changes: WATCH_DIR=/dir1 SETTLE_DURATION=5 MAX_WAIT_TIME=05:00 MIN_PERIOD=10:00 COMMAND="wget -nv -O /dev/null --auth-no-challenge http://sage:[email protected]:8080/sagex/api?c=RunLibraryImportScan&1=" USER_ID=0 GROUP_ID=0 UMASK=0000 # This is not important because the above is a "fire and forget" asynchronous operation IGNORE_EVENTS_WHILE_COMMAND_IS_RUNNING=0 Then I create a container that maps the proper directories for /dir1 and /dir2, and also the newperms utility: docker run --name=inotify-command -d -v /etc/localtime:/etc/localtime \ -v /mnt/vms/docker-config/inotify-command:/config:rw \ -v /mnt/user/Media:/dir1 -v /mnt/cache:/dir2:rw \ -v /usr/local/sbin/newperms:/root/newperms coppit/inotify-command

Doh. Yeah, I can fix that. I set up a cron job to run newperms on my cache drive, because transmission does this too. So I didn't notice that these containers have this problem.

Do you literally build and run them in the VM, or have you set DOCKER_OPTS="-H tcp://tower..." so that the containers run in unraid? That's what I was planning to do, since I have one or two containers that I may not share on Docker hub.

I'd like to move my development off of my unraid server. Has anyone worked through setting up TLS on the daemon, so that you connect remotely? Edit: I figured it out, so I'll edit this top post to be a HOWTO. First, I didn't bother setting up security because docker is only exposed on my LAN. If you want security, check out the Docker docs. [*]On your unraid sever, edit /boot/config/docker.cfg, adding two -H options:[br] DOCKER_OPTS="--storage-driver=btrfs -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375" [*]On your remote machine, install the docker client. Then either add the -H tcp://tower:2375 option to your docker command, or put export DOCKER_HOST=tcp://tower:2375 into your ~/.bashrc. When you're done, you can run "docker ps", "docker build" or whatever from your dev machine, with all the action happening on your unraid server. I like this better because I'm on my normal dev machine, with github credentials, my favorite GUI editor, etc.

Does NzbGet write to its /data directory (which you mapped to /mnt/user)? And if so, are the files/directories that it writes to on some non-cache drive? What happens if you configure FileBot's output dir to be /mnt/user? When I get a chance I'll do some experiments, but I don't know how filebot could be somehow telling unraid to spin up the drives, or what I could do to prevent that. The only thing I could imagine doing is filing a bug against unraid.