brunnels

There is no configuration option to disable this via the gui. The apcupsd plugin notify is a simple bash script that sends anything coming from the apcupsd as an alert. Have a look at /usr/local/emhttp/plugins/dynamix.apcupsd/apcupsd.notify. So to disable it you can copy that file to /boot/config/ and then modify it like so: # # Send system notify message from apcupsd # read MESSAGE if [[ $MESSAGE != *"Change them NOW" ]]; then /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Alert" -s "UPS Alert" -d "$MESSAGE" -i "alert" fi then add this into /boot/config/go before the `/usr/local/sbin/emhttp &` line # disable apcupsd change battery alerts if [ -r /boot/config/apcupsd.notify ]; then fromdos </boot/config/apcupsd.notify >/usr/local/emhttp/plugins/dynamix.apcupsd/apcupsd.notify fi

Awesome work. Thank you. I'm testing it out now. One note so far. The verbose on the uninstall logging to the webpage makes it take a really long time delete all the files in the virtual environment

Found slackbuilds for most of those: pbr six enum34 pycparser cffi idna ipaddress cryptography PyYAML pyperclip pyparsing wcwidth stevedore PrettyTable unicodecsv pyzmq Didn't see them for these: asn1crypto pyghmi contextlib2 cmd2 cliff python-six and python-idna are actually in official repos.

I was thinking on this more last night and since a lot of small python packages get installed by pip could you just run the pip install during the plugin install script? It's pretty fast so I don't think it would be a problem. Another alternative which would probably be useful for a lot of people or other plugins would be a new plugin for "persistent pip" that essentially restores the state of /usr/lib64/python2.7/site-packages/ from the flash drive on boot.

I installed a bunch of build packages I download from slackware64-current repo and ran the slackbuild for subprocess32 I linked before. Then I installed that package, libvirt-python (from slackware64-current), and python-setuptools (from slackware64-current). Finally I ran `pip install virtualbmc` None of the build packages were needed for the install detailed in the log file. I did a reboot to make sure they were all gone before doing it. I attached the log and list of packages I installed to make the slackbuild. Also my subprocess package in case it helps. virtualbmc-install.txt build-packages.txt subprocess32-3.5.2-x86_64-2_SBo.tgz

Basically it lets you use ipmitool to control VM's over the network Power the virtual machine on, off, graceful off, NMI, and reset Check the power status Set the boot device Get the current boot device Very useful for automation tools that already support ipmi for these tasks for baremetal servers. Here's an example of how it's configured and used. https://x-vps.com/blog/?p=16

I've been working with ipmi and vm's recently and I think VirtualBMC would be a great addition to this plugin. You already have libvirt-python and the only other requirement to get it installed via pip is subprocess32 (if using python 2) which I had no problem building once I installed the build dependencies in unraid from slackware64-current repo. Pip will build it fine but the slackbuild is more convenient. Would you consider adding it? I would be happy to help or collaborate.

Can you please add libguestfs-tools? Does anyone have a docker container for building all the nerdpack packages or is there a guide or post about creating your own build environment? I searched around but didn't find anything.

I'm getting the same. Fix until binhex fixes the /root/init.sh is to add the following to the container post arguments: /bin/sh -c "mkdir -p /var/lib/lidarr && /root/init.sh"

I would check your routes in the container and host because I didn't see anything like that. To get into the container do "docker exec -it container-name /bin/sh" then type "ip route".

Fix for my issue was to create a new docker image file and reinstall all my containers. Not sure what happened.

After latest update I'm getting. Same error in lidarr. container_linux.go:265: starting container process caused "exec: \"/usr/bin/tini\": stat /usr/bin/tini: no such file or directory"

I just updated and the startup failed with: container_linux.go:265: starting container process caused "exec: \"/usr/bin/tini\": stat /usr/bin/tini: no such file or directory"

This is doable if you add a host route to the container and also to unraid. Here's my setup: container IP is 10.0.0.200 unraid IP is 10.0.0.199 router IP is 10.0.0.254 container name is smb4ad Unraid part is easy, I just go to the network settings and add a route: IP: 10.0.0.200 Gateway: 10.0.0.254 metric: 1 Next I create a script: /boot/config/smb4ad_route.sh containing the following: pid=$(docker inspect -f '{{.State.Pid}}' smb4ad) mkdir -p /var/run/netns ln -s /proc/${pid}/ns/net /var/run/netns/${pid} ip netns exec ${pid} ip -4 route add 10.0.0.199 via 10.0.0.254 rm -rf /var/run/netns Then I edit /boot/config/go and add the following to the end: docker events --filter "container=smb4ad" | awk '/container start/ { system("/boot/config/smb4ad_route.sh") }' & Finally, because I don't want to reboot unraid, I run the same command but use nohup to detach it from the terminal: nohup docker events --filter "container=smb4ad" | awk '/container start/ { system("/boot/config/smb4ad_route.sh") }' & What the command is doing is monitoring docker start events for my container and running the script to add the route to the container. The same result could also be accomplished by adding "--cap-add NET_ADMIN" to the container options and running a startup script in the container to add the route but that gives your container special permissions that aren't really desirable.