I need the external script because I can not access the network drive. The ignition service could not run under the different account, as it's on a different domain than what our server is on.
It's the only work around I could come up with.
Are you sure this will work? (I would expect it to not work, as the python will run with the same credentials as the Ignition service.)
I think you need to change your architecture, or get IT to put in the appropriate cross-domain trust relationships.
But it's not working. As evidenced by the Did not work ;( message.
EDIT: Sorry, got interrupted for a bit. The reason it didn't work is that system.util.execute will run under the same user that runs it. The service still doesn't have access to the share.
Wait what do you mean the same "user that runs it"? Are you talking about the ignition client user or the local system user? As in, my user account for ignition is villm24, that's who it's running under?
Given the image, the account that's currently logged in is the administrator account correct?
The ignition service is running under local system, which would be the administrator account correct?
The external script is using an account that has access to the drive. When I run the script via the python console, it works great. No issues what so ever. If I run it using system.util.execute, nothing happens, I don't get any errors anywhere.
I'm not sure if it'll work, I'll have to keep trying. You guys know more than me. If corporate would give our account access to their domain/resources this thread wouldn't exist.
No, the Local System account has no network privileges. You need to run the service itself (that service config page) as a suitable domain user. Nothing to do with logging into Ignition. This is Ignition (the service) gaining credentials on your network.
3 Likes
I've tried many many solutions up until now. Corporate is making things difficult, but I hope they go through and allow the IT team to give us access to the drive.
One last question, as I've exhausted all possibilities I believe, can the ignition service run under an account from a different domain? If not I'll request that our administrator account have trust access.
I wouldn't think so, unless the domains trust each other.
Trust is domain to domain, not account to domain, IIUC.
{ I'm not a Windows expert, fwiw. I avoid it like the plague because it is a plague. }
2 Likes
While I haven't had the need to map drives using Ignition, in reading through this thread, I think your best bet is to go back to how you were originally doing it due to the fact that you're needing to use alternate credentials on a different domain. I think where you were messing up according to @JordanCClark is that you were mapping the drive M to \\<REDACTED>\cad\cad2\drawings2\ but then using M:\\<REDACTED>\cad\cad2\2 and getting an error that it's not a directory. You have to keep in mind that it's appending that path onto your original drive mapping, so the path you were essentially trying to access was \\<REDACTED>\cad\cad2\drawings2\<REDACTED>\cad\cad2\2 which probably doesn't exist, which is why you got the error.
So in another example you gave, you would probably go back to your original network mapping, then your input path or param1 would be M:\0\Current\0W390082-.GP4 substituting the proper slashes as I'm not sure how Ignition will want them. The other issue you're going to have is this will execute on the gateway since you're using perspective (maybe that's your intent), so it won't be on the user's PC, but on the gateway where it downloads the file.
4 Likes
Right, the idea is to copy one of those drawings to a local folder where it is accessible to ignitions gateway, at which point we can use some of ignitions functions to download the file to the clients computer.
Ok, I'll give it another shot! So use the wrapper right and restart the service, then when I go to invoke the drive in script just use M:\0\current\somefile.gp4? I swear I've already done this, but I'll try again and let you guys know how it goes. Lastly, is what I have correct?
I will try this as well, although when I was doing that on my laptop I would get an error from the subprocess module that said something to the affect of "There's already one connection to the server, you can not have any more than one", which lead me to unmapping the drive on my computer for it to work.
Sorry I've been hard to work with, to everyone on this post, I appreciate the help and will do my best to browse the forums and help others where I can. I'm glad this community is helpful and kind.
I've played with this and here's my the relevant lines from my working ignition.conf file:
wrapper.share.1.location=\\<REDACTED>\Projects
wrapper.share.1.target=P:
wrapper.share.1.type=DISK
wrapper.ntservice.account=Ignition
wrapper.ntservice.password=<REDACTED>
wrapper.share.1.account=<REDACTED>
wrapper.share.1.password=<REDACTED>
wrapper.share.1.shutdown.unmap=TRUE
wrapper.share.1.startup.max_retries=2
wrapper.share.1.startup.retry_interval=10
For the ntservice account/password I used the local account of the username/password the Ignition service was running under (in my case it was a local account). For the share account, I connected to a domain (computer was not connected to this domain and even on a different network, so it was routed), but was in the form of DOMAIN\username
One note is that your share location cannot end in a backslash - even the Tanuki documentation mentions that this will break it. See: wrapper.share.<n>.* Properties - Java Service Wrapper
I also enabled the wrapper.debug=TRUE for testing and found in the logs the following (wasn't necessary to use debug for this, but when it wasn't working, this gave me the error - just make sure to comment it back out when done testing):
INFO | wrapper | 2024/04/24 14:25:51 | Attempting to map the "\\<REDACTED>\Projects" share to "P:"...
INFO | wrapper | 2024/04/24 14:25:51 | Mapped "P:".
Once working, I just accessed the file such as system.file.fileExists('P:\myfile.txt')
Another note...this does NOT work in Linux. This seems to be Windows onlym and you must be using a separate account for the Ignition service (it won't work running as LOCAL SYSTEM).
2 Likes
Also be aware that if your target share is not available when Ignition is restarted, Ignition will take longer to start up, due to those retries. And if your target share ever disconnects, it won't reconnect until you restart the Ignition service.
Using the service wrapper's drive mapping ability is not fit for production use. Full stop.
2 Likes
I haven't tried it out yet as we need to restart the ignition service, But this has to be the solution. I was using the same domain/user for the .ntservice when I probably should have been using our local account....
I was thinking about what you wrote.
If we lose connection to the mapping, we won't be able to access the drive which is fine, but it won't affect other systems tied to ignition will it? I don't mind it disconnecting and having to wait till end of production to restart the service and remap the drives, I just don't want ignition to come to a halt because a mapped drive was disconnected.
No, just whatever you configured in Ignition to use that mapped drive will be affected.
1 Like
Worked like a charm!!!!
One last question please.
I will be meeting with a "security" team member and he's going to ask me how the Ignition platform is going to access the network drive. I am 100 percent certain his main question is going to "is it using clear text to establish a connection and what protocol and ports will this be happening on? I am not to versed in Ignition to answer that, could you please provided us with some information regarding this please?
Ignition itself doesn't make the connection. It delegates to the Windows OS with either the credentials supplied in ignition.conf for a drive letter mapping, or the implicit credentials of the service user for UNC paths (not using a drive letter).
Have your IT team read this entire topic.
Ask them to help you use UNC paths for the most robust implementation.