Community Developer
  • Posts

  • Joined

  • Last visited

Everything posted by overbyrn

  1. Awesome, thanks Dan. That'll be a huge help. Now, if you ever feel the desire to give UD the option to have per-device SMB and NFS share permissions, you can have my first born. Well, no... no you can't, it's a bit late for that. But you'll have my undying gratitude Big overhaul to the code there though, so do understand if you don't have the time or inclination. Thanks once again, overbyrn
  2. Hi Dan, Is it possible with UD as it stands to export a mount as NFS but with specific parameters, much like can be done with regular shares when exporting as NFS? I'm guessing not, but figured I'd ask. Admittedly it's a bit of an edge-case scenario, but would be very helpful to me at least if it was possible to tweak the NFS export parameters, rather than standard Public with read/write access. I guess also that would mean having to change NFS export from a global setting to per-mount, as I notice that /etc/exports- get's populated with all mounted devices once NFS export is set to enabled. I was going to take a look under the hood at your code and see if I could find where /etc/exports- gets written. Before using UD, I used to have a manually created exports- at /boot/config which got auto-added to /etc/export when exportfs was called. Is there something similar perhaps, whereby you store a copy of exports- or do you generate during plugin run only? I could go out an manually change /etc/exports- myself, but that's messy for all kinds of reasons. Would appreciate your thoughts. Regards, overbyrn
  3. I compiled it, but zero clue if it's what you need or will help. Was built against Slackware Current, which I think is what 6.2 is based on. ./configure --prefix=/usr Configuration on Mon Aug 1 20:38:13 EDT 2016: Host: i686-pc-linux-gnu -- slackware Slackware 14.2 Apcupsd version: 0.7.5 (13 June 2016) Source code location: . Install binaries: /sbin Install config files: /etc/apcupsd Install man files: ${prefix}/share/man Nologin file in: /etc PID directory: /var/run LOG dir (events, status) /var/log LOCK dir (for serial port) /var/lock Power Fail dir /etc/apcupsd Compiler: g++ 5.3.0 Preprocessor flags: -I/usr/local/include Compiler flags: -g -O2 -fno-exceptions -fno-rtti -Wall Linker: gcc Linker flags: -L/usr/local/lib Host and version: slackware Slackware 14.2 Shutdown Program: /sbin/shutdown Port/Device: /dev/ttyS0 Network Info Port (CGI): 3551 UPSTYPE brazil UPSCABLE simple drivers (no-* are disabled): apcsmart dumb net no-usb snmp no-net-snmp pcnet modbus no-modbus-usb no-test brazil enable-nis: yes with-nisip: enable-cgi: no with-cgi-bin: /etc/apcupsd with-libwrap: enable-pthreads: yes enable-dist-install: yes enable-gapcmon: no enable-apcagent: no https://dl.dropboxusercontent.com/u/572553/apcctrl-0.7.5-x86_64-1rj.txz Send me a PM if you need to get in touch as I rarely check the forum these days. Regards, overbyrn
  4. It's okay, you can name the original person. He won't mind I'm glad someone took up the mantle to make the plugins work for later unRAID versions. Good job!
  5. I think the situation is far better than you think. Look at the sheer number of available containers at this point that our community has created in < 1 year compared to how many plugins exist. Yes, there are probably some containers that aren't up to snuff totally just yet, but most definitely are. And for those that don't want containers, VMs are available and still a better solution than Plugins. I realize that Plugins are what brought us Dynamix to begin with, but your use case is a rare one compared to the majority of plugins that are essentially just installing 3rd party apps like Plex, Dropbox, etc. We already have enough packages to maintain on our own with the OS itself, we don't need to be maintaining even more that have nothing to do with unRAID OS. If someone wants to carry that torch, great, we won't stop them, but it won't be Lime Technology. The only packages we want to support are those required by the OS to support the functionality we deliver. A step in the wrong direction in my opinion. JonP, it's very clear from this thread that you're a big proponent of Docker containers over plugins. Fair enough, that's your prerogative. Others may not wish to embrace that aspect yet and perhaps would rather stick to plugins. If you're going to do a 180 on what Limetech currently bakes into the build, then perhaps you go the whole hog and remove the plugin architecture altogether? Too strong? Probably, but it feels as though Limetech is doing an about face from what it previously recognized as an in issue in v5. I agree with Bonienl, the problem with maintaining Python and Perl outside core unRAID is the possibilities of one plugin clashing with another. If we ignore the 'use containers instead' argument for a moment, I'd like to give an example of one such case... At the point which most plugins standardized on Python 2.7, there came an issue where a number of plugins were using a build of Python widely distributed by forum member piotrasd. One the one hand this worked well as the build contained a few extras over a native python package from more traditional channels. But the other side of the coin was that it caused headaches for other plugin authors who chose to use python packages from more regular distribution channels. Do a search for python-2.7.3-i686-5PTr.txz. You'll soon see what I mean. The piotrasd version contained python-cheetah, which would usually be a separate dependency. Easy enough to fix, but a pain all the same. I think expecting someone in the community to maintain a master plugin is the wrong way to go about it. I understand you do not wish to bloat the unRAID image and only want to bundle what is needed for unRAID to function, but a balance has to be found and currently it feels as this action is as much about engineering folks onto containers as it is anything else.
  6. The first two are available as v5 and v6 plugins here: http://lime-technology.com/forum/index.php?topic=39169.0 I'm working on Airvideo HD. I have it running on unRAID v6 as bare-bones install. Currently trying to reduce the number of dependencies by rebuilding VLC without some of the unnecessary components / plugins.
  7. Thanks for your help RobJ, tis appreciated. Yep, life went from zero to 100 this past year or so. Moved to US from UK last Jun, moved from NH to WI for new job. Now a little more settled but still got lots to learn about living here. US driving road test next week, filing taxes etc. Not a lot of room for plugins, but it's my guilty pleasure and I still tinker whenever I get a chance. All the best, overbyrn
  8. Hello Mods, Could I trouble one of you to close these old plugin design topics please and point to a single consolidated one instead? Ones to close: http://lime-technology.com/forum/index.php?topic=27230.0 http://lime-technology.com/forum/index.php?topic=20848.0 http://lime-technology.com/forum/index.php?topic=23287.0 http://lime-technology.com/forum/index.php?topic=23423.0 New topic to point to: http://lime-technology.com/forum/index.php?topic=39169.0 Many thanks, overbyrn
  9. 64bit version built with --libdir=/usr/lib64 ... https://truck.it/p/FEKiQ6R-2m
  10. Hi PhAzE, Here ya go... x86 ImageMagick Q8 without X11, with webp : https://truck.it/p/nZbhP4PLl6 x64 ImageMagick Q8 without X11, with webp : https://truck.it/p/gLjxSRCO2w I used libwebp 0.4.2 during compilation of ImageMagick. I was going to use the latest source 0.4.3, but I saw on pkgs.org there wasn't a premade slackware package for the latest version, so I grabbed the 0.4.2 libwebp source and used that. You'll need to install the 0.4.2 txz that you already have and then hopefully as I've built ImageMagick against the same version, all will be well. I also changed the prefix to /usr You can see it correctly detected libwebp during configuration from this pastebin; http://pastebin.com/3ccLz09w
  11. edit; imagemagick Q8 with x11 x86/unraid5 - https://truck.it/p/kJB4lxCKKX imagemagick Q8 with x11 x64/unraid6 - https://truck.it/p/vg1CuO9o7v imagemagick Q8 without x11 x86/unraid5 - https://truck.it/p/pvSVGbSe8z imagemagick Q8 without x11 x64/unraid6 - https://truck.it/p/rPCUYKZr3A Thanks for these! I used the Q8 no x11 and it looks like it worked perfectly. I had to edit the tar so it wasn't in the usr/local folder anymore, just /usr, and edited teh doinst.sh file for the same thing, and I have the Media Browser Beta up and running. It feels a lot faster with ImageMagick now. Nice... glad I was able to help. I could always alter the --prefix to /usr and recompile, but sounds like you have it working well for the moment all the same. Did you get the build VMs working? It used my local VMs here and all it took was pretty much 2-3 steps. I'm happy to talk you through the process some time if you want? I'll pm you my skype id. Dunno what TZ you're in (I'm CST), but feel free to ping me. Regards, overbyrn
  12. See above, versions with and without X11
  13. edit; imagemagick Q8 with x11 x86/unraid5 - https://truck.it/p/kJB4lxCKKX imagemagick Q8 with x11 x64/unraid6 - https://truck.it/p/vg1CuO9o7v imagemagick Q8 without x11 x86/unraid5 - https://truck.it/p/pvSVGbSe8z imagemagick Q8 without x11 x64/unraid6 - https://truck.it/p/rPCUYKZr3A
  14. Here's the result of my configure; http://pastebin.com/AESETrTS I didn't change anything on the default ./configure. I'm going to say it defaulted to Q16 as can see this "-DMAGICKCORE_QUANTUM_DEPTH=16" within the configure result. Presumably, that can be changed to Q8 if needed. I've some free time today as currently recovering from some surgery. Let me know if you need a version compiled with Q8 instead. I'm also looking at how tricky it would be to compile a fully static version so you'd not have to deal with a bunch of dependency packages.
  15. PhAzE, compiled these from source a few mins ago. Don't know if they'll help you. You'll need to resolve a whole bunch of dependencies before being able to run the ImageMagick binaries. unraid5 - ImageMagick-6.9.1-0-i686-1.txz - https://truck.it/p/ov1y9ejVsd unraid6 - ImageMagick-6.9.1-0-x86_64-1.txz - https://truck.it/p/qfOWXGvfNJ Regards, overbyrn
  16. Hey Overbyrn, that would be fantastic! I haven't decided fully if I'm going to her into package making yet but I was looking at the nzbget installs. Doesn't look like there are any good pre built binaries I can use so I might need to build like you used to. We can figure out the best way to transfer them soon. Also thanks again for all your work on your plugins. PhAzE, sent you a PM with links to download the NZBGet build VMs from some cloud space I have.
  17. PhAzE, if you intend to do an nzbget plugin, I can provide two pre-built vm's which have everything needed to compile nzbget. I've scripted the whole process so it's quite simple. You pass an svn revision number to the build script and it updates, compiles and generates the nzbget slackware package. One vm is for 32bit based on slack13.1 and the other slack14 for x64. I have them both as single .ova files which could be run using vmware workstation, fusion player or deployed to an ESXi. Let me know if you're interested. Regards, overbyrn
  18. http://duckdns.org Up to four free dynamic names. Updater clients for all platforms. Or just do it from cron; eg. echo url="https://www.duckdns.org/update?domains=myduckdnsdomanname&token=5f3f34gff-3786-4169-a5af-751e3335cfb1&ip=" | curl -k -o /opt/duckdns/duck.log -K -
  19. Phaze (and others creating v6/plgman compatible plugins), don't bother creating and downloading png files. Instead generate them from inline code and save directly to your plugin directory underneath /usr/local/emhttp/plugins eg. Instead of <!-- Download application and web GUI icons --> <FILE Name="/boot/config/plugins/&name;/images/information.png"> <URL>--no-check-certificate https://raw.githubusercontent.com/PhAzE-Variance/AppSupport/master/information.png</URL> </FILE> do <FILE Name="/usr/local/emhttp/plugins/&name;/information.png" Type="base64"> <INLINE> iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAAK/INwWK6QAAABl0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAKcSURBVDjLpZPLa9RXHMU/d0ysZEwmMQqZiTaP0agoaKGJUiwIxU0hUjtUQaIuXHSVbRVc+R8ICj5WvrCldJquhVqalIbOohuZxjDVxDSP0RgzyST9zdzvvffrQkh8tBs9yy9fPhw45xhV5X1U8+Yhc3U0LcEdVxdOVq20OA0ooQjhpnfhzuDZTx6++m9edfDFlZGMtXKxI6HJnrZGGtauAWAhcgwVnnB/enkGo/25859l3wIcvpzP2EhuHNpWF9/dWs/UnKW4EOGDkqhbQyqxjsKzMgM/P1ymhlO5C4ezK4DeS/c7RdzQoa3x1PaWenJjJZwT9rQ1gSp/js1jYoZdyfX8M1/mp7uFaTR8mrt29FEMQILr62jQ1I5kA8OF59jIItVA78dJertTiBNs1ZKfLNG+MUHX1oaURtIHEAOw3p/Y197MWHEJEUGCxwfHj8MTZIcnsGKxzrIURYzPLnJgbxvG2hMrKdjItjbV11CYKeG8R7ygIdB3sBMFhkem0RAAQ3Fuka7UZtRHrasOqhYNilOwrkrwnhCU/ON5/q04vHV48ThxOCuoAbxnBQB+am65QnO8FqMxNCjBe14mpHhxBBGCWBLxD3iyWMaYMLUKsO7WYH6Stk1xCAGccmR/Ozs/bKJuXS39R/YgIjgROloSDA39Deit1SZWotsjD8pfp5ONqZ6uTfyWn+T7X0f59t5fqDhUA4ry0fYtjJcWeZQvTBu4/VqRuk9/l9Fy5cbnX+6Od26s58HjWWaflwkusKGxjm1bmhkvLXHvh1+WMbWncgPfZN+qcvex6xnUXkzvSiYP7EvTvH4toDxdqDD4+ygT+cKMMbH+3MCZ7H9uAaDnqytpVX8cDScJlRY0YIwpAjcNcuePgXP/P6Z30QuoP4J7WbYhuQAAAABJRU5ErkJggg== </INLINE> </FILE>
  20. Yes, I get what you meant. What I was meaning is that within the 'plugin' script, the general methodology looks to be that a check method is used to perform a check of the local version against remote version, the update method is used to download the later version to tmp and then subsequently calls the install method to perform the install (again). So if you build your install method to ensure it tears down the areas you need refreshing, then calling the update method will perform an installation, creating new versions of the files where required. You can also call multiple methods, allowing the same bash script to be used across more than one method; <!-- The 'install' script. --> <FILE Name="/tmp/plugins/tmp" Run="/bin/bash" Method="install update" Type="text"> <INLINE> if [ ! -d /tmp/plugins/builtin/&name; ]; then mkdir -p /tmp/plugins/builtin mv /usr/local/emhttp/plugins/&name; /tmp/plugins/builtin else rm -r /usr/local/emhttp/plugins/&name; fi tar -xf /boot/config/plugins/&name;/&name;-&version;.tar.gz -C /usr/local/emhttp/plugins mv /usr/local/emhttp/plugins/&name;-&version; /usr/local/emhttp/plugins/&name; </INLINE> </FILE>
  21. I have figured out how to do this, but I wonder if an 'update' method would be appropriate. I used a combination of check, update and install methods from /usr/local/emhttp/plugins/plgMan/plugin.
  22. Tom, thanks for the explanation. I've previously used info gleaned from the code in plgman to help understand the new plugin structure (install/remove/check, anon scripts etc). I appreciate you're working on plugin documentation and I imagine it's low priority, but I'd be interested in anything you can share as I'm currently going through all my plugins (dropbox, ssh, btsync, beets, airvideo, lms, denyhosts, nzbget) and making them v6 compliant. It'd be great to get them right first time. Regards, overbyrn