tinglis1
-
Posts
76 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by tinglis1
-
-
There is some work being done on this by the Home Assistant community.
Might be worth seeing what they have done.
https://community.home-assistant.io/t/unraid-monitoring/53775
-
Have you got pipework working with other docker containers with using the vlan bridge?
If so then it is likely to do with the br0.5 interface. It could be the name or it could be the way it is handled by pipework.
Have you tried nested quotes? This may help if it is a naming issue.
Have a look at the code for pipework if you want as well.
https://github.com/jpetazzo/pipework/blob/master/pipework
The interface name is transfer to the variable ‘IFNAME’
Sent from my iPhone using Tapatalk -
On 03/12/2017 at 1:13 AM, brambo23 said:
I am currently trying to use Pipework for my docker containers. I'm trying to use a vlan interface bro.5 which I confirmed works by setting up a VM on that interface.
I added a extra variable
-e 'pipework_cmd=bro.5 MineOS 192.168.5.40/[email protected]'the Pipework log states that
/entrypoint.sh: line 363: export: `Extra Parameters=-e 'pipework_cmd=bro.5 MineOS 192.168.5.40/[email protected]'': not a valid identifierWhat exactly am I doing wrong?
I tried some other variants of the command line but i get the same eror everytime
I set the network type to none. I also tried just using the bro interface on dhcp and it did not seem to work either.
any help would be appreciated
I no longer use this as feature as i am using the inbuilt networking in unraid 6.4.
I would suggest following the instructions earlier in the thread from unevent.
QuoteLeave "@CONTAINER_NAME@" exactly as it is
-e 'pipework_cmd=bro.5 @CONTAINER_NAME@ 192.168.5.40/[email protected]' -
What do you mean by this step? as is doesn't sound right. Are you showing the advanced settings and putting the code in the extra parameters section? It sounds like your adding a variable instead.
then I click at the bottom add container variable. I name it pipework and in the value section I type this:
-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.2.88/[email protected]'
Sent from my iPhone using Tapatalk -
The code @CONTAINER_NAME@ automatically enters the container name.
It should work if you use that instead of the container name.
Sent from my iPhone using Tapatalk -
@gareth_iowc
How did you get on with those tests?
Sent from my iPhone using Tapatalk
-
It still works with that version I think. I am currently using 6.3rc without issue.
Can you try it with a static ip instead of dhcp. I have had issues with dhcp in the past.
Also check your network settings to make sure br0 is active. Try 'ifconfig' to see if it is there.
I will have a look in more detail at your setting when I'm near my unraid computer next.
Sent from my iPhone using Tapatalk
-
Is there a way to have this download through a different nic. specifically a usb wifi adapter. rather than the main nic uraid is using?
You may be able to do this with the pipework docker. I have not tried it but you do need to specify an interface. usually it is br0.
-
I have found the fix for unRAID 6.2. I have updated the opening post to reflect the current install requirements.
Choosing the correct version
By default docker templates grab the 'latest' build this may cause you issues.
For unRAID 6.0 and 6.1 you need to use
dreamcat4/pipework:1.1.5
For unRAID 6.2 you need to use
dreamcat4/pipework:1.1.6
An additional environmental variable is required for unRAID 6.2. If using the Community Application templates this will be already in place.
-e DOCKER_API_VERSION=1.22
Feel free to try the 1.1.6 version on unraid 6.0 or 6.1 as I haven't tested it but I expect that it will fail.
-
There has been a new version of pipework pushed to the latest tag. This will break the compatibility with unraid as we are not up to date on the docker versions.
In the mean time add the tag of 1.1.5 to the docker template to get the last working version for 6.1.
The repository should look like this:
dreamcat4/pipework:1.1.5
unraid 6.2 will partially work with this version as discussed earlier.
I am working on a fix to this at the moment. It is to do with docker api versions so I am learning that quickly to try and come up with a backward compatible solution.
-
I'm not sure what causing you issues but am wondering if it is related to your host NIC somehow.
Do you have more than one NIC?
What shows up when you ifconfig on unRAID?
-
I have finally found the problem that causes Pipework to not work correctly on unraid 6.2.
I have mentioned it to the author of the docker container but they have previously stated that they no longer support it, so probably not going to be much happening there.
You can check out the GitHub issue here if you are interested.
I might have a go at fixing it myself if I get the time.
-
Hi,
I have a feature request for some form of unraid API.
I have been using Unraid for along time now and was using with with esxi. Since v6 it has taken over as my host machine and I am doing more with it than ever.
I did notice there was a previous request for this in December 2014, Link, for an API but this was highlighted as not a priority at the time and given that unraid v6 was still in early beta stages this makes sense.
At the moment almost all the control requires ssh/telnet or web console access. This to me poses a potential security risk and think that an API might be able to provide access to some of the commonly used functions without providing access to all the system functions of unraid.
Some of the features that I would like to see in this this API are below:
- Access token to bypass the basic authentication for API.
- Possible multiple tokens with different access. example tokens, Global, Docker only, VM only, System only, Docker and VMs only, Plugins.... This could be managed via a webpage with automatically generated token but be able to be manually set or regenerated.
- Some form of system/docker/vm overview that is easily obtained. I use Zeron's jsonvars plugin to provide me with information about the server for some of my home automation applications and monitoring. I also use SNMP and each has there own advantages.
- Potentially make the API available for plugins to publish information.
- Docker remote control. Ability to start/stop/restart containers would be the starting point. I am sure there would be other things that people might like to see.
- VM remote control. Ability to start/stop/restart vm's would be the starting point. This might be a work around the physical power button problem that has been requested, for example an arduino, home automation system or even IFTTT could be used to send commands.
- Unraid system control. Starting, stopping, powerdown, restart, start parity, spinup, spindown check etc. This should probably should be limited to non destructive system functions as to limit malicious/accidental control.
- This may make it easier for third-parties to develop monitoring plugins or integration into automation systems.
- There could be an option to provide some form of share control. I have recently become more Ransom-ware aware and have put in processes to try an limit damage in the event of an attack. Some of the suggestions on this forum are to change the user share from read-only to write when needed. An API could potentially change a share from read/write status of a share. The control of this could handled by the user in the form of a script or webpage etc.
- Possibility to run command-line command/scripts. This goes against my non-destructive comment above but could be useful for anything not covered by the API. It probably should have it own API token.
- There is the possibility that this may be able to be done as a plugin. It might be a good starting location but I still think an API should be part of the core unraid functionality.
I have noticed a few businesses/enterprises these days embracing API strategies, (example Telstra Australia) and they usually cite the collaboration, efficiency and development benefits. I have seen first-hand what having everybody developing their own backdoor/link to systems can have, especially on the inability to control system load and when trying to upgrade/change systems.
The development and documentation of an API is no small task but I think it might unlock some key development/features for the future of unraid.
-
3
-
6
- Access token to bypass the basic authentication for API.
-
I don't know if this helps you but I have been playing with a docker container (librenms) that uses nginx and will not start on unraid due to a IPv6 related issue. I have a work around where I edit the nginx config to stop listening on the IPv6 port and that fixes it, until the image reloads. I am experimenting with more permanent solutions at the moment.
-
If you have tried running this docker container with unraid 6.2 you may have had issues as I did in getting this to work.
I haven't found a proper solution yet but I have found that it works if I restart the pipework container after starting/restarting the container that i have assigned an ip too. Far from an ideal fix but I am happy I have dedicated ip's for my dockers while I find a better solution.
I did give network features in docker 1.10 (unraid 6.2) a good go but couldn't get it to work.
-
On second thought I might create two plugins. One for the latest build and one for the fixed build number 1.1.3.
-
I have done some reading on the docker image tagging. It by default grabs the one tagged latest. From what I can tell dreamcat4 uses a combination of latest, stable and build numbers as tags.
I may look at modifying the plugin so that it grabs a build with a tag that is stable with unraid. This would hopefully prevent it from breaking like this again.
-
ryryonline, if the only thing you have changed is the docker image repository then you should be able to do it with the advanced options in the docker settings. This may make the docker usable again.
Change the repository to the one you used in the command line.
-
I am thinking about removing the beta tag from this docker container. The actual container is managed by someone else and appears to be stable. The only beta part was the unraid container configuration.
With the beta tag removed it may attract a few more people to try it out.
Anybody got any thoughts on this?
-
Pipework has been working well for me but I ran into one issue...
If I use it with saarg's TVHeadEnd containers, TVH cannot discover my HDHomerun devices. If I take Pipework out of the mix, TVH sees the devices fine.
Any ideas?
John
John,
I have a tvheadend docker image using 'tobbenb/tvheadend-unstable:latest' running with my HDhomerun dual tuner. I did a quick test by assigning a pipework IP address to my existing tvheadend container and I had no issue using the tuner via tvheadend with a kodi frontend.
The only change I made was to change the network type from host to none and added the extra parameter
-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.110/[email protected]'
-
Are you checking the success by the pinging the container? The IP address on the docker page is actually set by a separate setting on the advanced settings page (it has a known issue that makes it difficult to change.) and is not representative of the pipework assigned ip.
Check that the pipework docker is running with privileges. This is found when looking at advanced settings.
Watch the unraid log when the transmission docker is starting. It should show messages about he interface being created and becoming active. Can't remember the exact messages (I am nowhere near my computer at the moment). This might give some insight into what is failing. The best interface will have generated name, not br0.
Also it maybe worth trying a reboot. When trying to figure out how to get pipework running I had made so many network connections I got weird results. It also allowed me to test the ability for pipework to assign the correct ip on startup.
-
The interface is defined in the docker container additional parameters. I have used 'br0', you could try substitute that for your choice of interface on your docker.
You may need to bridge the nic to be able to use it, there is some more info on this here https://lime-technology.com/forum/index.php?topic=34872.msg325436#msg325436.
I don't use my second interface port so haven't tested it.
-
Here is a couple of screen shots of the configuration that is working for me.
Are you trying to set a static or dynamic IP?
I have the 'Nerd Pack' plugin installed. I don't think this should make any difference but there is always a chance is might be.
Pipework docker
JDownloader2
This has a static IP set.
Edit: Updated image paths to github address
-
This is an unraid implementation of the dreamcat4/pipework image on the Docker Hub.
I use pipework to assign a static IP to a docker container. This has made it possible to move away from VM's to docker containers for some of my main applications.
Choosing the correct version
By default docker templates grab the 'latest' build this may cause you issues.
For unRAID 6.0 and 6.1 you need to use
dreamcat4/pipework:1.1.5
For unRAID 6.2 you need to use
dreamcat4/pipework:1.1.6
An additional environmental variable is required for unRAID 6.2. If using the Community Application templates this will be already in place.
-e DOCKER_API_VERSION=1.22
Installation (Preferred):
Use Community Application to install.
http://lime-technology.com/forum/index.php?topic=40262.0
Installation:
Add the template repository to unraid Docker Template Repositories:
https://github.com/tinglis1/docker-containers/tree/master/
Install and run the pipework docker container. No configuration is required for the pipework container. You may want to set the container to autostart.
Container configuration
Set the container network mode to 'none' and then add the additional parameters input in the container advanced configuration. The additional parameters are documented at dreamcat4/pipework and jpetazzo/pipework.
An example extra parameters config for a static IP:
-e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.100/[email protected]'
In this example the ethernet port used is 'br0', the IP is static at 192.168.2.100 with a /24 network and a gateway of 192.168.1.1.
More Info
I have put some more detailed documentation at https://github.com/tinglis1/docker-containers/tree/master/pipework.
Also check out dreamcat4/pipework and jpetazzo/pipework.
Problems with mounted media shares going "limp" while used by plex
in Docker Engine
Posted
Did you ever resolve this issue?
I have recently moved Plex to a container on a secondary unraid server and am having the exact same issue.
I tend to notice it when the media scanning isn’t picking up new content. I found it really strange that the file still play though.
To fix it I unmount and mount the share again and then it works. If I try to start the Plex docker when the share mount is in this weird state I get the execution error you posted.