Been using SQL Linux in a container for my lab for ages works well apart from the fact that you can’t install the EDD database on it due to the requirement of Named Pipes protocol
3 Likes
I was surprised but pleased to see this upcoming change for Kinetic Cloud. Generally, Linux-based operating systems are considered among the most secure. I started in the Unix environment and Linux followed and was influenced by Unix. We are working on moving to Kinetic Cloud and I’m looking forward to additional security features related to user access that may become available after the move to Linux.
AI Overview - Generally, Linux-based operating systems and security-focused distributions like Qubes OS and Tails are considered among the most secure, due to their open-source nature, strong security features, and smaller target for malware, while macOS also enjoys a reputation for security.
1 Like
Me too! I was working at an EDI company and we used HP-UX, Aix (IBM), Ultrix (DEC), and Solaris (Sun). Slackware was my first foray into Linux. Pick the wrong video driver and you could pop your monitor!
2 Likes
Me three… SCO System 5 and Xenix
2 Likes
Hi Tim
Is there any concern about VB.NET code running after this change?
Any VB.Net code will be on the client, not on the server. So no.
You need to get on your migration to the browser though…
2 Likes
Even if there was some server code in VB (which there isn’t), VB is still compatible with the latest .NET, on any platform it supports… VB, C# or F# is just syntax, the actual code is in .NET itself…
2 Likes
That requirement exists in the validation code of the installer only. Once you have passed validation, you can simply turn off Named Pipes and EDD keeps working. In fact, the EDD installer only checks the configured value, never the actual value. I am sure you can think of a similar trick to get the EDD database on a Linux instance.
2 Likes
BTW, 2025.1.4 itself works just fine in my Linux Kubernetes test lab. Even with ARM64 nodes! Although you could probably use an SQL Linux container as a database server, you still need a Windows VM to run SSRS and the Task Agent service. So might as well run SQL Server there too.
1 Like
Fair point SQL Linux does have named pipes at all so no dice there.
Interested to know more about your app server containers though, can you elaborate. Spent ages a long while ago to get one stood up but ended up drawing a blank.
1 Like
I’d just like the installer not to the check to be honest It is really not necessary.
I wonder how we can set up and configure the Epicor App Server in a Linux container. Are there any guides or manuals on how to do it?
I’m trying to set up one for testing.
Thanks,
I entered a case for this issue. It was closed because the verdict was that Named Pipes are required. The fact that I proved they technically weren’t did not change it.
The EDD installer is notoriously overzealous in its validations. Early versions insisted on it that SSL certificates had a Subject Alternative Name (SAN) even if the certificate was made for a single DNS name, already in the Subject. Luckily, a checkmark to disable SSL verifications exists now.
2 Likes
Definitely that installer needs some work… But then again there is no free lunch
I’m not sure I can share my Dockerfile, build scripts and helm chart right now.
This is what your Dockerfile should do:
- start with Microsoft’s Linux dotnet container: mcr.microsoft.com/dotnet/sdk:8.0
- Unzip the release Server.zip from the base ISO
- Unzip the update Server.zip from the UD.exe
These Server.zips can be extracted using 7-Zip, either from the GUI or the CLI, without needing to run any installer on Windows. - Your entrypoint should be: dotnet /your/path/to/Bin/Epicor.Ice.Hosting.ApiHost.dll
Then there is a lot of tweaking of your Ingress controller to get things right.
And you need to write and include some script that uses a Kubernetes configmap to edit the Config/Host.config file prior to starting dotnet, so your container will find the MSSQL backend (among other parameters) and still be configuration-neutral.
In the end, I replaced mcr.microsoft.com/dotnet/sdk:8.0 with a real Linux container (fedora:latest) and installed dotnet using dnf. The Linux tools that came with the Microsoft containers were too flaky to run my script reliably.
1 Like
Thanks. I was trying to use a Windows server container and remotely install… Which just was not happening
Prior to 2025.1, you should use a Windows container. 2025.1 is the first release to be both platform (Windows, Linux) and architecture (x86_64, aarch64) independent.
3 Likes
I know @JeffLeBert has been working hard to get Epicor to work in Linux.
1 Like
I asked Isreal at last years Insights if there was any way that they could deliver a container that could be used for developers. I think I even raised an idea about it… Nothing.
I also raised it with @Vaibhav_Vohra at the Epiusers meetup… Maybe something will come of it… It would be a very handy thing to have…
It looks like your questions are more around the container and the environment the container runs in. I played with that years ago for Windows containers but haven’t looked at it since. Ask me C# questions instead. 
1 Like