Datapotomus
-
Posts
37 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Datapotomus
-
-
# Generated settings: IFNAME[0]="br0" BRNAME[0]="br0" BRSTP[0]="no" BRFD[0]="0" BRNICS[0]="eth0" PROTOCOL[0]="ipv4" USE_DHCP[0]="no" IPADDR[0]="192.168.1.253" NETMASK[0]="255.255.255.0" GATEWAY[0]="192.168.1.1" DNS_SERVER1="1.1.1.1" DNS_SERVER2="192.168.1.1" DNS_SERVER3="8.8.8.8" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" IFNAME[1]="br1" BRNAME[1]="br1" BRNICS[1]="eth1" BRSTP[1]="no" BRFD[1]="0" PROTOCOL[1]="ipv4" USE_DHCP[1]="no" IPADDR[1]="192.168.1.252" NETMASK[1]="255.255.255.0" GATEWAY[1]="192.168.1.1" IFNAME[2]="br2" BRNAME[2]="br2" BRNICS[2]="eth2" BRSTP[2]="no" BRFD[2]="0" PROTOCOL[2]="ipv4" USE_DHCP[2]="no" IPADDR[2]="192.168.1.251" NETMASK[2]="255.255.255.0" GATEWAY[2]="192.168.1.1" SYSNICS="3"
Here you go.
Like I said, the most baffling thing about it. Is that it worked just fine with the previous version of unraid when I downgraded. As well as naturally working before the upgrade.
-
Hey All,
I've been running into an issue after upgrading to 6.7.2 . Where br2 becomes the default route.
The issue with this is that I don't have anything plugged into br2. I am currently only using br0, because it is my 10G link. br1, and br2 are only 1G links. So, I really don't want to use them.
I was able to fix this by modifying the route table manually. However, if I modify it manually after a reboot it reverts right back.
The weird thing is also if I downgrade back to 6.6.7 I don't have this issue.
So, my primary question is what is the best option for making the br0 route persistent across reboots?
-
I figured the issue out a little later. Posting the solution now. I needed to make a copy of the serverconfig.xml, and named it serverconfig_new.xml. Then I changed it in the docker configuration page GAME_PARAMS to -configfile=serverconfig_new.xml -logfile 7DaysToDie_Data/output_log.txt $@. After that 7DTD worked just fine.
Thanks for the work on the container.
-
1
-
-
7DTD docker log.txtHey all I'm running into an issue with the 7DTD container. I got it started with no issue.I shut down the container. I make the changes to the serverconfig.xml then start it back up. As soon as I start it back up my changes seemed to get revered back to the default. I did make sure that the files saved, by exiting, and opening it back up, and it does save, but the second I start the container back up it wipes the file.
Has anyone else run into this, and figured out a way to not have it wipe?
-
Thanks. That worked.
-
Sorry if I wasn't clear enough. What I am trying to say is how do you set additional options via the webui that you would need to run after the container. Like they have in the example.
How would I pass the bolded parameters to the container from the webUI.
ethereum/client-go --fast --cache=512 -
Can someone tell me how to set additional flags in the web UI for docker containers that go after the run.
An example I am trying to run is this:
docker run -d --name ethereum-node -v /Users/alice/ethereum:/root \ -p 8545:8545 -p 30303:30303 \ ethereum/client-go --fast --cache=512However, when I add them to the extra parameters option in the web UI it looks like it tries to run them before the container. I receive this error when attempting to put them in the extra parameters field.
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="ethereum-node" --net="host" -e TZ="America/New_York" -e HOST_OS="unRAID" -e "TCP_PORT_8545"="8545" -e "TCP_PORT_30303"="30303" -v "/mnt/user/perm/docker_apps/ethereum-node/":"/root":rw "--cache=512" ethereum/client-go
unknown flag: --cache
See 'docker run --help'.
The command failed.So it looks like the extra parameter feild seems to set it before hand not after like I need it.
-
I guess I would add to the question with are there like a settings.xml or another configuration file you could set up https with? I agree with the VPN comment, because I wouldn't open up my NAS externally. I would still like my NAS to be configured for https. I could see small offices that might also like this functionality.
-
Limetech is currently working on a container that should be better supported than this one. The main thing I don't like about using a VM, is the additional overhead in resources that using another OS requires.
-
Are there any plans on you guys putting making crashplan available through the limetech templates? I saw that there is a repo, but it doesn't look like it has been published to the hub yet.
-
I have submitted a ticket to code 42 requesting that they change the link to a more generic "latest" link. That way if you do attempt to create a new container you should be able to just download the latest version, and not have to do a download then an upgrade. This would still require a change on the source repository. However, the link would only have to be changed one more time in the source repository.
-
I'm running into an issue after the update as well. I attempted to even clear out my crashplan docker configuration directory, and start with a new container and image. It just now sits on "upgrading" when opening the GUI in windows.
-
Hey just wondering if this was going to be updated for 4.2 looking at the install. It looks like it is still pulling from 3.7.
JAVACOMMON=`which java` # Downloading Crashplan wget -nv http://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_3.7.0_Linux.tgz -O - | tar -zx -C /tmp # Installation directory
Wondering if the new link can be added?
http://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.2.0_Linux.tgz
Routing issue with persistence problems after upgrade
in General Support
Posted
Ok, so I sort of figured it out. If I turn off bridging on eth1, and eth2 then leave it on, on eth0, then bridge them all together it seems to work correctly.
# Generated settings: IFNAME[0]="br0" BRNAME[0]="br0" BRSTP[0]="yes" BRFD[0]="0" BRNICS[0]="eth0 eth1 eth2" PROTOCOL[0]="ipv4" USE_DHCP[0]="no" IPADDR[0]="192.168.1.253" NETMASK[0]="255.255.255.0" GATEWAY[0]="192.168.1.1" DNS_SERVER1="192.168.1.254" DNS_SERVER2="192.168.1.1" DNS_SERVER3="1.1.1.1" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" SYSNICS="1"If someone has a better way to do this than bridging ports that aren't even plugged in I'm all ears. However, it does look like doing this does seem to persist after reboot.