Jump to content

tinglis1

Community Developer
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

4 Neutral

About tinglis1

  • Rank
    Advanced Member

Converted

  • Gender
    Male
  • Location
    Adelaide

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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-api-connect-and-control-unraid-servers-through-home-assistant-via-mqtt/154198 https://community.home-assistant.io/t/unraid-monitoring/53775
  2. 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
  3. 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. -e 'pipework_cmd=bro.5 @CONTAINER_NAME@ 192.168.5.40/32@192.168.5.1'
  4. Assuming the scope of the encryption is to prevent access to the data on the drives if removed from the host then the following types of authentication methods could be useful: - GUI password - unRAID USB hardware id - separate USB hardware id or key file. The later two options would allow for automatic authentication on boot. The last option would allow for easier securing of the drives. In my case my unraid USB is internal, so removing it for periods such as going on holiday etc. to protect from theft of the whole server is not viable. Sent from my iPhone using Tapatalk
  5. 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. Sent from my iPhone using Tapatalk
  6. 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
  7. I haven't used openhab for a while now. It looks like they have changed the container tags. Checkout https://hub.docker.com/r/openhab/openhab/tags/ On a side note, I have moved to using HomeAssistant.io. I have achieved more with that in the last 6 months than I did with Openhab in years. Sent from my iPhone using Tapatalk
  8. @gareth_iowc How did you get on with those tests? Sent from my iPhone using Tapatalk
  9. 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
  10. The use of the internal docker networking functions are discussed here https://lime-technology.com/forum/index.php?topic=51335.0
  11. Can you try the following. - Try without the mac option to see if that is having an impact. -e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.119/24@192.168.1.1 - What is the pipework log saying? If it is showing errors please post a sample of the log. - Some containers do not play well with network functions. I have tried both pipework and the inbuilt docker networking tools but have found the same results for both. Can you try setting the ip on another container.
  12. Previously discussed here. https://lime-technology.com/forum/index.php?topic=51335.0
  13. I did not assign anything to the nic, just left it as up. I have stopped testing docker networking with my server now I started to get very strange results. By manually creating the bridge between the docker network and eth1 using brctl all of my traffic from VM's and dockers (even using pipework, not sure about docker networking) started to come from my unraid host ip on eth0. This caused havoc in my system as low priority traffic was considered high priority as it was coming from my unraid ip. I will put the Docker networking testing on hold again as the trouble is not worth it while I have a solution that currently works.
  14. Just to clarify. I have not tried dns setting using pipework. I have pipework giving dockers their own static IP and then using my router to manage traffic priority or pushing the traffic through a vpn if necessary.
  15. I had turned on bridging but wanted it off. so rather than reboot I just deleted the bridge. I will turn the bridge off next time I shut my array down. I didn't realise the network setting persisted after reboot. The bridge between the docker bridge and the nic wont though as these commands are done in unraid not docker. There is a lot more to do, especially around the nic bridging, before this would be ready for inclusion in the gui. Also at the moment the docker network option is only available to those with a spare nic. This is already possible using pipework and much simpler than the docker networking method. At the moment this has to many balancing parts that make it suitable for my non development dockers.