This has probably been answered before but I can’t find any post about it.
I have a functioning D6 setup on my LAN. All slaves and the repo exist on the LAN.
But now I want to setup the system such that I am functioning in two locations. The D6 renderfarm in one location and me and my workstations in another.
The first step is to connect remotely using Monitor to the D6 repo. The repo seems to use port 27017. I have setup port forwarding on my LAN modem/router such that port 27017 is forwarded to PC20 (the server with the repo). I also added an exception to the Windows Firewall on the repo server for TCP port 27017.
When on the remote computer, I try to start Deadline Monitor and since it has the normal repo location specified, it errors and says it can’t find the repo… as expected. But then I try to give it the IP address to get there but it still says it can’t find the repo.
Am I missing something in order to make Monitor connect to the repository?
On the LAN setup, the repo is entered like this:
\PC20\D-Drive\DeadlineRepository6
How should it be entered when connecting to an IP address that is going to forward it to the correct repo machine? I’ve tried several permutations of the address but nothing works.
Can you let me know what the error you get is? I suspect the issue might be that the remote machines don’t have a DNS entry for the machine hosting the Database, but getting the error in text or screenshot would be really helpful in narrowing it down.
Given that you need to permit access on a port-by-port basis from your remote location, it may be that you need to also permit the ports for Windows file system (SMB). With Deadline 6 the earlier Repository was split into two parts, a “global database component” and a “global file system component”. The database component uses port 27017 and stores “jobs, settings, and slave configurations” (thinkboxsoftware.com/deadline-6-installrepo/), but the “global file system component” relies on access to the Windows file system on the repository machine:
"The Repository is the global file system component of the Deadline® Render Farm Management System. It stores the plugins, scripts, logs, and any auxiliary files (like scene files) that are submitted with the jobs. The Clients access the Repository via a shared network path. "
Monitor needs access to the Submission scripts, for example, so if SMB hasn’t been permitted from your remote location Monitor would likely report it can’t connect to the Repository. Here’s one of many lists describing which ports are involved (alloytm.com/2011/01/30/microsoft … smb-ports/).
Attached are the errors shown when trying to start the Monitor.
The first question is… given that I am trying to run the Monitor remotely, what would be the proper way of inputting the Repo pathname in the dialog box? Normally on the LAN, it would simply be the path “\PC20\D-Drive\DeadlineRepository6”. But since I am connecting remotely and have forwarded the 27017 port from the router to the Repo machine, I am simply giving it the IP address such as NNN.NNN.NNN.NNN or \NNN.NNN.NNN.NNN. The errors come from trying these formats.
I have checked and both the remote system and the Repo system have File & Printer Sharing turned on in the Windows Firewall. I have port forwarded the ports used by the File & Printer Sharing ports (shown in the Windows Firewall) to the Repo system. Still, I get the same errors when trying to start the Monitor on the remote system.
Clearly, the 27017 port is required by Deadline. I have forwarded the ports that are shown as used by File & Printer Sharing in the Windows Firewall. Are there other ports that Deadline requires?
I am not very knowledgable about IT/IP stuff and I don’t want to expose myself to danger by opening up ports that I shouldn’t. But I have been able to configure my remote computing setup such that I can totally control my renderfarm and the remote Backburner setup is already functioning fine and I want to get Deadline functioning remotely as well.
One last suggestion, along similar lines. Deadline doesn’t know how to authenticate you to the Windows file system running on your repo machine. It might be useful to mount the repo machine’s Deadline Repository folder from your remote machine using the normal Windows tools (e.g. “Map Network Drive”) first. This would give you some sense of whether Monitor was involved or not. If you can authenticate and map that share successfully (I’d try the \nnn.nnn.nnn.nnn\sharename format), then the router configuration is fine for Windows SMB access. If this part fails, then you haven’t got a working configuration for reaching the Repository. Sometimes it’s just that you need to enter your login as "<your login> rather than just when you authenticate; the repo machine needs to know whether to look for your credentials on some organizational domain or as a local account on the repo machine. Assuming your remote credentials are valid on the repo machine you should also have access to the Repository folders (so click a few to be sure they open). Now launch Monitor. If it’s successful then the issue was with the authentication piece; you need to authenticate in the standard Windows way to the repo machine before you launch Monitor. If you can connect to the repo machine successfully via “Map Network Drive” but launching Monitor fails (and your other LAN based machines don’t fail so it’s not a “re-install the Repository” issue), then I think the next step would involve confirming that you have access to the MongoDB:
“Authentication: If you set up MongoDB to require authentication, this needs to be enabled, and you must enter the User Name and Password. Note that if you installed MongoDB with the Repository Installer, authentication is disabled.”
These are just some fundamental pieces we’ve gone through in accessing our Deadline 5.2 Repository remotely (this version didn’t use MongoDB) and (except for launching the VPN needed here) have covered things we’ve run into. There may be some additional wrinkles in Deadline 6 but these steps would still rule out some common issues.
Apologies for taking so long to get back to you. In my experience the answer to ‘what path to use’ really depends on how you are connecting. In general, I use VPN to connect to the network, then use the path the sys admin gives me. For example
“\server.mydomain.com\repo” while ensuring the dbconnect.xml file has an additional entry on the hostname line for the location of the database when connected by one such user, for example “server;server.mydomain.com” which will have the remote Deadline machine try both of those options. Can you verify how the remote machine is connecting to your network if different? Thanks.
Sorry for the delay in getting back to this… been swamped as usual.
Thanks for all the ideas.
Currently, I can remotely power ON and OFF servers via IPMItool commands and WOL commands. I can remotely connect to machines via RDP and TVNC. File transfers via FTP. I have setup numerous port forwards on the router and ports on the firewall to enable all this. Backburner is remote rendering.
At the moment, I haven’t setup a VPN as I can currently do everything I need without one (and my internet connection on one end is slow so the VPN interaction might be slow). But I’m starting to think I may have to setup VPN just to make Deadline work.
I tried the SMB suggestions earlier but was not able to make it work. I have a new router setup now and will look into that again.
As far as the Repo path… I have been trying things like “\hostname.dyndns.org” or the direct WAN IP address. There is a router port forward setup to forward port 27017 to the repo machine (PC20). So I would assume that when it goes to that URL, which is a router with a port forward, it would see the port forward to PC20 and be trying to go there. But as was mentioned earlier, it sounds like a single port is not enough with Deadline and more file sharing has to happen to make it work. So a VPN may be in order. I will keep trying to get the file sharing working as well.
The dbconnect.xml has a line:
PC20
Should I use a comma to separate the entries? PC20,hostname.dyndns.org
I could already run Deadline Monitor remotely (using RDP or TVNC to run Monitor on the Repo machine) and submit a MAX job that I had FTPed over earlier. But submitting to Deadline this way is a huge hassle compared to being able to submit directly from within MAX or from RPM. So I need to get this working from within a remote MAX session.
The issue you have is that 27017 is only the port for the database, the repo doesn’t use a specific port, it uses normal network file sharing protocols. I am not sure how to make it work without a VPN. For the dbConnect.xml, yes, you would want to put the hostname of the machine hosting the database from outside of the local network, but that won’t solve the inability to access the repository, unless you also make that repo folder shared so it is accessible from outside the network. Hmm… If the same machine, let’s call it host.dyndns.org, is hosting repo and database, and you set your network so that the machine’s shares are accessible from outside and within the network, then both internal and external machines should be able to access it. I don’t know how well this would work, but you could try it.
I never could get Deadline to work remotely via opening SMB ports, etc. So I installed OpenVPN and now when I have a VPN connection going, I am able to open the Monitor and also submit a job to D6 from within a remote MAX session and it seems to work as normal.
But… when I submit my test MAX job to D6 it renders but is only rendered by the repo machine. The other slaves are shown in the Monitor list in orange as ‘idle’ but do not participate in the render. Then I go to look at the slaves and they all say License - Expired/Invalid. WTF!
Nothing has changed on the slaves or their network and they have always been able to connect to the repo machine (also the license machine) without issues. The license server is specified as @hostname as it has always been. I can navigate across the network from each slave to the license machine no problem. When I try to specify the license file explicitly, it still says license expired/invalid.
I turn off the Windows Firewall on the license machine and the license become permanent.
Nothing has changed on the firewall regarding Deadline. The same Deadline license port exception that has always been there is still there. If I turn the firewall back on the licenses go invalid again. OFF and they’re good again.
I just want to verify that you have an opening in the firewall for the lmgrd process, usually 27000, but also the thinkbox.exe process, which uses a random port unless specified. Often the second part is where the issues lies. Hope that helps.
I checked the firewall on the repo machine and there was not an exception for the lmgrd port 27000 or the thinkbox.exe program. I have been running Deadline fine for a year without these exceptions in the firewall. When I added these exceptions to the firewall… it made no difference. The slaves (Win7) still can not get their licenses from the repo machine (WinServer 2003).
If I turn off the firewall completely… they get their licenses fine. If I turn off the firewall on the LAN connection only… they get their licenses fine. If I turn the firewall back on, they can’t get their licenses.
I have ports open for:
Deadline Launcher
Deadline Pulse
Deadline Repo Port 27017
Deadline Slave
Thinkbox Flexnet Port 1556
Thinkbox Lmgrd Port 27000
Thinkbox.exe
Still… slaves can not get their licenses while the firewall is on.
For this kind of problem you might want to run the freely downloadable TCPView (technet.microsoft.com/en-us/sysi … 97437.aspx) on your repo machine. It reports what network connections you have and the applications supporting them. If you turn your firewall off and let a Slave connect there is a “Remote Address” column in the TCPView display that will let you locate the Slave by IP (or DNS – there’s a toggle on the menu). Once you find it, just follow along that row to the left to see which application is supporting that connection. Right-clicking on the name will give you some options to display the program responsible for the connection.
I’ve never had luck getting Windows to automatically forward the ports the vendor daemon is using.
To force what ports they should use instead of the random one it gets every startup, you can modify the line in your license file that reads:
VENDOR thinkbox
to be
VENDOR thinkbox PORT=27010
That should make sure you can reliably forward that port outbound through the firewall.
Thanks again to all for the ideas. It is finally sorted.
Back when I was setting up Deadline 5.2, to get the slaves to see the licenses, the port was specified in the license file as port 1556. The exception in the firewall for the license server was port 1556. Then I installed Deadline 6 and made no changes to the D6 license file or firewall and it was working fine for a long time until the other day.
After Edwin’s comment, I went and checked the D6 license file and the older 5.2 license file. I then added the specified port 1556 to the D6 license file and it then matched up to the existing firewall exception and now all slaves are rendering again when the job has been submitted from a remote MAX over the VPN (and MAX locally).
