In order to run a certain software package that runs as a java applet I had to install Centos 3.8 on a 32-bit server. After installation I upgraded the installation using yum after repointing the configuration file to vault.centos.org. This worked fine, however, I still have to resolve two problems: - I'd would like to make the EPEL repository available but have not been able to find if old EPEL software packages are stored somewhere else for non-supported versions of CentOS? - I am trying to get Java 1.4.1 running in SeaMonkey Mozilla 5.0, the latest version I have been able to find for Centos 3.8, but have not had success to date. My current understanding is that I need to create a symbolic link to a Java .so file in the Mozilla plugin directory but must be doing something wrong since I cannot get Java to show up as a plugin using about:plugins in SeaMonkey Mozilla.
Is anyone able to offer suggestions?
Thank you.
H
On 09/01/16 10:08, H wrote:
In order to run a certain software package that runs as a java applet I had to install Centos 3.8 on a 32-bit server. After installation I upgraded the installation using yum after repointing the configuration file to vault.centos.org. This worked fine, however, I still have to resolve two problems:
- I'd would like to make the EPEL repository available but have not been able to find if old EPEL software packages are stored somewhere else for non-supported versions of CentOS?
- I am trying to get Java 1.4.1 running in SeaMonkey Mozilla 5.0, the latest version I have been able to find for Centos 3.8, but have not had success to date. My current understanding is that I need to create a symbolic link to a Java .so file in the Mozilla plugin directory but must be doing something wrong since I cannot get Java to show up as a plugin using about:plugins in SeaMonkey Mozilla.
Is anyone able to offer suggestions?
There is a JVM available that runs just fine on all new supported versions of CentOS (5.11, 6.7 and 7.2) and EPEL as well. My suggestion is you install and run something that is supported and not full of major security holes.
If you choose to run something years out of date such as CentOS 3, regardless of the reason, you are quite on your own, it is already broken and you get to keep the pieces.
Peter
That was not helpful - I explained that I had to run this version.
On January 8, 2016 5:18:36 PM EST, Peter peter@pajamian.dhs.org wrote:
On 09/01/16 10:08, H wrote:
In order to run a certain software package that runs as a java applet
I had to install Centos 3.8 on a 32-bit server. After installation I upgraded the installation using yum after repointing the configuration file to vault.centos.org. This worked fine, however, I still have to resolve two problems:
- I'd would like to make the EPEL repository available but have not
been able to find if old EPEL software packages are stored somewhere else for non-supported versions of CentOS?
- I am trying to get Java 1.4.1 running in SeaMonkey Mozilla 5.0, the
latest version I have been able to find for Centos 3.8, but have not had success to date. My current understanding is that I need to create a symbolic link to a Java .so file in the Mozilla plugin directory but must be doing something wrong since I cannot get Java to show up as a plugin using about:plugins in SeaMonkey Mozilla.
Is anyone able to offer suggestions?
There is a JVM available that runs just fine on all new supported versions of CentOS (5.11, 6.7 and 7.2) and EPEL as well. My suggestion is you install and run something that is supported and not full of major security holes.
If you choose to run something years out of date such as CentOS 3, regardless of the reason, you are quite on your own, it is already broken and you get to keep the pieces.
Peter _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2016-01-08, H agents@meddatainc.com wrote:
That was not helpful - I explained that I had to run this version.
That was probably partly Peter's point: you are very unlikely to get any helpful responses if you are running 3.8, and you are therefore likely on your own. That's probably not the response you were hoping for but it may be the best response you're going to get.
--keith
On 1/8/2016 2:21 PM, H wrote:
That was not helpful - I explained that I had to run this version.
you WANT to run something completely unsupported from about 10 years ago which apparently requires software thats known to be insecure and buggy as all heck. its 2015, not 2005, 10 years is an eternity in the computer industry.
whatever this 10 year old application is you're trying to get running, it needs to be dragged into a present day state of support. if this requires reimplementing the clientside applet entirely, so be it. Do note, Java applets running in web browsers are an almost entirely deprecated technology as there's been a non-stop stream of security problems with the whole java applet concept and implementation. J2SE 1.4, a version that was new in 2002, was desupported in 2008.
re; EPEL, as I understand, EPEL drops old versions like a rock the minute they are desupported.
On 01/09/2016 11:43 AM, John R Pierce wrote:
On 1/8/2016 2:21 PM, H wrote:
That was not helpful - I explained that I had to run this version.
you WANT to run something completely unsupported from about 10 years ago which apparently requires software thats known to be insecure and buggy as all heck. its 2015, not 2005, 10 years is an eternity in the computer industry.
whatever this 10 year old application is you're trying to get running, it needs to be dragged into a present day state of support. if this requires reimplementing the clientside applet entirely, so be it. Do note, Java applets running in web browsers are an almost entirely deprecated technology as there's been a non-stop stream of security problems with the whole java applet concept and implementation. J2SE 1.4, a version that was new in 2002, was desupported in 2008.
Just for your information I was working for a local ISP a few months ago, that uses microwave radio links to connect various hilltop radio access points and thus provide high speed internet access to rural clients in hard to reach terrain. Some of the kit used had a management interface that ONLY ran on an old, very specific version of java. No, the supplier was not interested in providing updates, what they provided - worked. The network was essentially private, thus difficult for the great unwashed to gain access and then in some way compromise the system. BTW, the particular version of java was only supported on WindozeXP and an old version of IE - thus it ran in a virtualbox and was only made alive when access to the radio system was required. welcome to the real world of 2016, there are lots of bespoke systems providing real value and definitely not affordable to replace in the cut throat world of a local ISP.
re; EPEL, as I understand, EPEL drops old versions like a rock the minute they are desupported.
On Jan 8, 2016, at 10:03 PM, Rob Kampen rkampen@kampensonline.com wrote:
welcome to the real world of 2016, there are lots of bespoke systems providing real value and definitely not affordable to replace in the cut throat world of a local ISP.
This is a sad truth, but it doesn’t mean that CentOS or EPEL should even *try* to support them.
If you’re going to run an unsupported, out of date, insecure system, you will have to run your own infrastructure to support it.
Also, if it were me, I’d be trying to get the bare minimum requirements running on a supported OS, perhaps in a VM or container.
-- Jonathan Billings billings@negate.org
But I did not ask for a current version of Centos to support my usecase, did I?
On January 9, 2016 1:04:33 PM EST, Jonathan Billings billings@negate.org wrote:
On Jan 8, 2016, at 10:03 PM, Rob Kampen rkampen@kampensonline.com wrote:
welcome to the real world of 2016, there are lots of bespoke systems
providing real value and definitely not affordable to replace in the cut throat world of a local ISP.
This is a sad truth, but it doesn’t mean that CentOS or EPEL should even *try* to support them.
If you’re going to run an unsupported, out of date, insecure system, you will have to run your own infrastructure to support it.
Also, if it were me, I’d be trying to get the bare minimum requirements running on a supported OS, perhaps in a VM or container.
-- Jonathan Billings billings@negate.org
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 01/09/2016 01:59 PM, H wrote:
But I did not ask for a current version of Centos to support my usecase, did I?
All I can tell you is that CentOS 3.(anything) is no longer secure at all. If this machine in any way touches the internet, expect that it will be hacked. You can try to minimize the issues by only opening ports that are absolutely required, but there issues that would be rated critical if that branch was being maintained.
On top of that, java is one of the least secure packages out there, and they have critical updates all the time .. which means if that is what you want to do on this box, then it is doubly insecure.
But that is your call, not mine.
EPEL was never released for RHEL-3 / CentOS-3 (that I can find). There were not even any of these extra packages for EL3: http://centos.karan.org
If you must use a CentOS-3.x .. you should use 3.9, which is 3.8 + the updates from here:
http://vault.centos.org/3.9/updates/
But, I want to reiterate, it will in no way be even close to secure.
Thanks, Johnny Hughes
That is very similar to my usecase. Thank you.
On January 8, 2016 10:03:16 PM EST, Rob Kampen rkampen@kampensonline.com wrote:
On 01/09/2016 11:43 AM, John R Pierce wrote:
On 1/8/2016 2:21 PM, H wrote:
That was not helpful - I explained that I had to run this version.
you WANT to run something completely unsupported from about 10 years ago which apparently requires software thats known to be insecure and
buggy as all heck. its 2015, not 2005, 10 years is an eternity in the computer industry.
whatever this 10 year old application is you're trying to get
running,
it needs to be dragged into a present day state of support. if this
requires reimplementing the clientside applet entirely, so be it.
Do
note, Java applets running in web browsers are an almost entirely deprecated technology as there's been a non-stop stream of security problems with the whole java applet concept and implementation. J2SE 1.4, a version that was new in 2002, was desupported in 2008.
Just for your information I was working for a local ISP a few months ago, that uses microwave radio links to connect various hilltop radio access points and thus provide high speed internet access to rural clients in hard to reach terrain. Some of the kit used had a management interface that ONLY ran on an old, very specific version of java. No, the supplier was not interested in providing updates, what they provided - worked. The network was essentially private, thus difficult for the great unwashed to gain access and then in some way compromise the system. BTW, the particular version of java was only supported on WindozeXP and an old version of IE - thus it ran in a virtualbox and was only made alive when access to the radio system was required. welcome to the real world of 2016, there are lots of bespoke systems providing real value and definitely not affordable to replace in the cut throat world of a local ISP.
re; EPEL, as I understand, EPEL drops old versions like a rock the minute they are desupported.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
That is correct, not only do I want to, I need to.
Thank you for your explanation of the EPEL policy.
On January 8, 2016 5:43:55 PM EST, John R Pierce pierce@hogranch.com wrote:
On 1/8/2016 2:21 PM, H wrote:
That was not helpful - I explained that I had to run this version.
you WANT to run something completely unsupported from about 10 years ago which apparently requires software thats known to be insecure and buggy
as all heck. its 2015, not 2005, 10 years is an eternity in the computer industry.
whatever this 10 year old application is you're trying to get running, it needs to be dragged into a present day state of support. if this requires reimplementing the clientside applet entirely, so be it. Do note, Java applets running in web browsers are an almost entirely deprecated technology as there's been a non-stop stream of security problems with the whole java applet concept and implementation. J2SE 1.4, a version that was new in 2002, was desupported in 2008.
re; EPEL, as I understand, EPEL drops old versions like a rock the minute they are desupported.
-- john r pierce, recycling bits in santa cruz
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Sun, 10 Jan 2016, H wrote:
That is correct, not only do I want to, I need to.
It seems like RH 3.8 was around the time of Fedora Core 3-5 so you might be able to install packages from the Fedora archive:
http://dl.fedoraproject.org/pub/archive/fedora/linux/core/
Otherwise you could rebuild source packages from there with:
rpmbuild --rebuild ...
-- Ian
Thank you. I was able to resolve the problem: apparently there was some incompatibility between SeaMonkey Mozilla 1.0.9 and Java 1.4.1_09 caused by different compiler versions.
I downloaded Mozilla 1.7.13 from the Mozilla website and Java 1.4.2_19 from Oracle's archive and was able to get it to work. The Java applet (LSI eArrayDirector) now runs and I will use it to configure the fibre channel array tomorrow.
On January 9, 2016 6:00:14 PM EST, Ian Mortimer i.mortimer@uq.edu.au wrote:
On Sun, 10 Jan 2016, H wrote:
That is correct, not only do I want to, I need to.
It seems like RH 3.8 was around the time of Fedora Core 3-5 so you might be able to install packages from the Fedora archive:
http://dl.fedoraproject.org/pub/archive/fedora/linux/core/
Otherwise you could rebuild source packages from there with:
rpmbuild --rebuild ...
-- Ian _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
H -
Ian Mortimer -
John R Pierce -
Johnny Hughes -
Jonathan Billings -
Keith Keller -
Leon Fauster -
Peter -
Rob Kampen