<p dir="ltr">Blargh! Lousy vendor. But their investors are happy and _that's_ what matters.</p>
<p dir="ltr">Me being the a$$hole I am, I would slap their crap in a vm on their supported versions of everything for their "support" and run the live stuff on the most current, locked down system outside of the 3 letter agencies. If there's a problem, verify it on the crap platform and yell for a solution.</p>
<p dir="ltr">There's tons of code that was written for specific hardware cases that can't be updated (mostly winders but I've seen some Linux as well). The only solution is to wall it off and setup deep packet inspection on the data stream associated with it. Or sneakernet it.</p>
<div class="gmail_quote">On May 12, 2015 9:12 AM, "Beddingfield, Allen" <<a href="mailto:allen@ua.edu">allen@ua.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In our case, we have one application that has existed since the 80s, and apparently was last significantly updated in the late 90s/early 2000s when hitting a web interface and loading a huge and bloated Java application (which requires a specific version of Java) was more common. It originated on AIX, then I get the feeling they got it working on Linux and didn’t want to touch it again. They give a very specific set of instructions, with the exact disk layout they want, and they only support RHEL 5.6 currently. No patches, no firewall, and no tcp wrappers configured - starting to runlevel 5. They also have a Windows version that they treat the same way - no patches, no firewall, etc…<br>
I pointed out the stupidity of this, and the vendor’s response - to list off all of the government agencies and corporations using it without problem. We have it firewall off, and the devices it controls on a private subnet - after I insisted. The vendor just wanted to put it on a public IP. They originally only supported RHEL 5.3 - then they sent over some bastardized upgrade procedure to update to 5.6. Instead of just using yum to update it - they insisted on copying the DVD to the local drive, pointing yum there, and doing the update….heaven forbid it may actually pull in a patch.<br>
The other one is a product that is about that old…it requires RHEL 6.1 exactly, and runs under Tomcat. You can apply patches, but they don’t support patching the gcc compiler on it, and a few libraries. It is like navigating a mine field to not accidentally update one of them as a dependency.<br>
<br>
We have tested internally, and both applications work 100% on a fully patched system, but it is not a “supported config” by the lousy vendors.<br>
<br>
Allen B.<br>
--<br>
Allen Beddingfield<br>
Systems Engineer<br>
The University of Alabama<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 5/11/15, 10:02 PM, "Jeff Hubbs" <<a href="mailto:jhubbslist@att.net">jhubbslist@att.net</a>> wrote:<br>
<br>
><br>
>Which in my view was a state of affairs common in the 1980s and 1990s<br>
>that we sought refuge from with Linux and other Open Source software. I<br>
>got tired of being painted into platform corners with this or that piece<br>
>of software; it's a shame people have let themselves get right back into<br>
>that regime again.<br>
>_______________________________________________<br>
>Ale mailing list<br>
><a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
><a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
>See JOBS, ANNOUNCE and SCHOOLS lists at<br>
><a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>