Currently, our ignition gateway is sitting on a virtualized windows server. I have no access to the server other than to ignition via the web interface. Since it is x86 hardware/software, IT has a grip on it. I am curious how other organizations delegate server administration duties / access. Do the people responsible for developing using ignition have "root" access to the server?
It's not uncommon for IT departments to overreach and consequently interfere with our even disrupt operations.
3 Likes
I consider it essential, as there are things that cannot be troubleshot without it.
In particular, you can't get at the Ignition service's administration, nor get to the wrapper log file. There is logging that only goes there.
I find that the best way to keep non-cooperative IT folk out of the way is to deploy on a Linux server. The kind of IT that refuses to permit necessary access to a server tends to be the same kind of people that turn up their noses at non-Microsoft technology. Linux is like garlic to IT vampires.
12 Likes
This is exactly the situation i am in, it's all Micro$oft, Linux devices are supposedly not allowed on the network, even though some of our control related devices are built upon a Linux kernel. I had asked for direct access to the server almost a year ago, and was given the go around many times since waiting for a resolution. Yesterday i sent out a pretty loud email which resulted in a meeting being set for Monday morning with the IT manager.
I wanted to reach out and see what the "norm" is on this subject, and hope to get some (more) ammunition if i was not wrong in my thinking that we need to have direct access to the server. I have stated several reasons for my request, like the poor response time of IT when things go wrong, lack of ability to monitor the server for possible issues and alert, no ability to install 3rd party python libs, no ability to kill orphaned processes when i goof up, and as you mentioned, no access to the wrapper log. If you guys have any more ammo for me, i would appreciate it. I work for a global company that seems to be fairly rigid in policy so the more the merrier.
Not to start a whole other (related) discussion, but as far as network infrastructure goes, is it normal to have your controls network sharing hardware with the production/office network? Our controls network utilizes the same hardware that production uses for their PC's (and everything else on ethernet), albeit on a separate VLAN. So aside from setting static IP's in our devices, we have 0 control over that, and they seem to randomly change port configurations and put switch ports on the wrong VLAN. It's a mess.
Sadly, yes. Advisable, no.
Terminology point: I call controls networks "production networks". I call office networks that include tasks that are required for production (minutes-ish vs. hours-ish) "production networks".
Could you clarify, it appears you have referred to both network use cases as "production networks".
1 Like
It's not at all going to help you during a sit down with a closed brained IT type, but here is an article I read recently that illustrates one reason why Linux and Mac operating systems are superior to microsoft:
3 Likes
You can with script though, but much easier if you just have the right access needed in the first place.
I personally have admin access to all of my customers' scada servers. It's important for other things like changing perspective theme files and icons
3 Likes
Office activity in the plant that can tolerate extended downtime without stopping production would be a non-production activity.
Controls networks are obviously production networks.
Office networks may or may not be production networks. Often, an office network has both production and non-production activities because the facility is not wise enough to segregate them.
1 Like
Ignition developers should have OS level root/administrator. if you use VM, I think you should have VM rights.
Sometimes, my customs ask to use their database, that's the limit of what I can live with. So my company provides the igntion server machines as part of service.
1 Like
Our first Ignition Gateway is running on Windows Server 2012. Automation Engineers get Admin access accounts and do anything that they need to.
Our IT department prefers to deploy Linux when possible. So our second gateway is running on Linux. We have a great relationship with IT, so there aren't any issues. After a couple months IT gave me permissions to ssh into the machine. I know enough about about Linux, but I am more comfortable in Windows. But at least now I can restart the Gateway.
I don't worry too much about IT interfering anymore. We have had IT shutdown the plant in the past by accident. The backlash is so severe they are pretty timid of making changes in our environments. It still happens sometimes, but it is worth it for the support they provide. Not all IT departments are created equally, your results may vary. 
7 Likes
I LIKE your IT department. 
3 Likes
This means that Ignition's backend gateway is still not "background" enough. If the gateway webpage could take care of everything, then the ignition developer wouldn't need operating system privileges. But in reality, the gateway webpage can't even guarantee that it can still be accessed after a failure.
1 Like
Oh, puh-leeze! Try configuring Microsoft's IIS through IIS's web interface. Or Apache. Or Nginx. Or HAProxy.
Sorry for my English expression problem. What I mean is that the gateway web page does not have higher authority and priority than other modules, which leads to some problems that cannot be solved through the gateway web page. If the gateway web page has higher permissions and priority, then the ignition developer may not really need the OS permissions. But I also realized that this is very difficult, and the architecture of ignition was not designed in this way in the first place.
Simply not true. The Jetty webserver IS the ignition gateway root java object. There is nothing in Ignition with more permissions. That object is responsible for loading all of Ignition's modules.
1 Like
I have been granted admin rights to the server, although I am required to put in a ticket before performing reboots or software installation, or updating ignition, etc.. So things are better, but not what i was hoping for. I went into the meeting asking for a complete divorce so that we could roll a linux server, they gave me a pretty stern no on that subject stating that any server or computer is their problem, which i would gladly spare them of in this case but that isn't going to happen it seems.
So the next battle is going to be the x86 hardware that will be running our ignition panels, it seems they have the same attitude with that end of it, so that means windows, on the domain, anti-virus that randomly slows things to a craw, you get the point. To top it off, we can only use "approved" hardware which does not appear to include any kind of industrial-ish PC hardware that i am aware of.
So i am at a cross roads now, do i just give up on using ignition on the HMI side, or do i play the game and when(if, but likely) problems arise, play the game and see if we can do things "our way"? I have a feeling what will happen is it will still come back on us because we set it up knowing there would likely be issues.
Sorry for the rant, but hopefully some of you in better situations will appreciate it more after hearing the "policies" i'm dealing with.
Sigh. My condolences. /:
2 Likes
Been there. You have my sympathies as well.
2 Likes
I've been lucky to have a very cooperative IT function. One of the things they did for me was to setup a new vlan for our automation stuff. We called it the "Industrial vlan". We firewalled it and blocked everything, the opened the ports we needed for our PLC's, HMI's, etc. They let the automation team manage all the ip addresses and the device lists. IT is happy b/c we're running our weird Window7 stuff and PLC's on our own network and they're satisfied that the firewall will protect the enterprise network from any threats. Since it's just a vlan it rides on all their hardware, so it wasn't expensive to implement.
We created a wireless vlan as well to support the Vision-based display clients which are HDMI-stick windows PC's, but no Carbon Black, Symantec, or other corporate overhead.
It's worked pretty well. I've been trying to push my organization toward the Cisco/Rockwell Converged Plantwide Ethernet approach, but that's not going anywhere. Nobody in IT seems to see the need.
4 Likes