are there packages replacing the ancient perl version in CentOS 7 with a more recent one, like 5.24? At least the state feature is required.
Don’t call it ancient, boy, or I’ll beat you with my cane!
Have you checked the Software Collections?
Since when is Perl 5.16 “ancient?” It’s only 4 years old.
CentOS 5 just left supported status, which shipped Perl 5.8.8 from first release to last, which means I’ll probably still be limited to Perl 5.8 features for a few years yet, since the remaining CentOS 5 boxes I’m supporting can’t be upgraded and won’t likely be turned off until they fall over dead. That makes Perl 5.10 “the future” from my perspective.
If this sort of stance seems risible to you, you probably shouldn’t be using CentOS. This is what distinguishes a “stable” type of OS from a “bleeding edge” one.
According to the docs,[*] that feature has been in Perl since 5.10. This appears to confirm it:
$ perl -e “use feature ‘state'” && echo yes
Are you looking for something else, or do you have a simple test case that shows what’s provided in CentOS 7 is insufficient?
Perl 5.24 is available in SCL, in the CentOS-sclo-rh repository.
[root ~]# yum info rh-perl524-perl Name : rh-perl524-perl Arch : x86_64
Epoch : 4
Version : 5.24.0
Release : 379.el7
Size : 6.0 M
Repo : CentOS-sclo-rh/x86_64
Summary : Practical Extraction and Report Language
Warren Young schrieb:
Living in the past seldwhen is a good idea.
When a version of a software has been released 20 years ago, that doesn´t mean it´s more stable than a version of that software which is being released today.
Of course, you can consider “never change the version of the software” as something making for a stable OS. But what about the bug fixes?
Ah, yes, that does work. Sorry, I guess it was signatures rather than state. I´m getting
Feature “signatures” is not supported by Perl 5.16.3 at …
with CGI scripts. And who knows what else might cause problems.
The software has been written with perl 5.20.1, which is already rather old.
Yes, that’s how SCL works. A lot of system software uses perl (and python and gcc) so replacing the installed version without testing the effect it might have on the system is not advisable. i.e. things will break. The whole point of the RHEL/CentOS is that the versions of software are stable (strong and stable even) and that everything is exhaustively tested to make sure things work.
All (!) that the ‘scl enable’ command does is to set environment variables for things like PATH and LD_LIBRARY_PATH. If you can do that for the CGI environment, then it will pick up the correct perl version. But don’t ever be tempted to make updated versions the default.
Not “software”, Warren said “OS” – it’s the whole ecosystem that is more stable if the versions of the software that’s within it are kept consistent.
Critical bug fixes are back ported, if appropriate, into the version of the software packaged with the OS – that is the point of the commitment by RH to support the OS.
As far as I can see it hadn’t been released when RHEL7 was released, so there’s no chance of it being the default version.
As others have said, if you need bang up-to-date versions of software, then RHEL/CentOS is not for you.
Pete Biggs schrieb:
That´s a good thing. I thought they were more about security updates than bug fixes.
So far, the perl version is the only problem I´ve found. I´d prefer getting things to work with CentOS rather than using multiple different distributions on the servers, including the VMs. It would make things easier.
I don’t propose to teach you about my problems — they are, after all, mine, and I’m coping with them quite well, thank you — but I’ll give you a glimpse into someone else’s as a lesson: the San Francisco Bay Area Rapid Transit System was still running on PDP-8s as of several years ago, and may still be doing so.
As I understand it, they were using a modified PDP-8/e, which is 1970 tech. Note that I didn’t say “1970’s.” I mean the year nineteen hundred and seventy, A.D. The PDP-8/e is just an enhanced version of the original PDP-8 from 1965, which is itself not a huge departure from the PDP-5, from 1963.
And you know what? The PDP-8/e is still well suited to the task. Trains haven’t changed that much in the intervening decades, and the construction techniques used by that era of computer mean it’s still repairable with little more than a soldering iron.
We have 40-cent microcontrollers with equivalent computing power to a PDP-8/e today that run on far less power, but you’d have to pile up a bunch of I/O interfacing in front of them to make it as electrically capable and robust as a PDP-8/e, and you’d have to re-develop all the software, too.
The modern tendency would not be to use one of those 40-cent micros, it would instead be to put a gigahertz class Linux PC in its place, with all the concomitant risks.
Try getting a modern Internet worm into a PDP-8! Good luck not blowing the 4k word field boundary.
…which makes it younger than the C89 standard some still stick to over in C land. And younger than C99. And younger than C++-98. And C++-93.
By your lights, the C/C++ world is positive decrepit for not immediately tossing everything and insisting on C11 and C++-14.
Actually, it does, provided it’s still being maintained, as Perl 5.8.8 was up to a few months ago. Software that gets no new features also gets no new bugs. Therefore, the overall bug count can only go down.
The distinction you may be looking for is that there is a fine line between “stable” and “moribund.” RHEL/CentOS rides that line much closer than some other OSes, but it actively stays on the good side of the line.
After that end-of-support date, sometimes all it takes to slip over to the bad side of the line is a new exploit or similar, but decades-old exploit targets are very rare.
More commonly, something changes in the environment to make the old software unsuitable, as happened with BIND 4 and Apache 1.3. You couldn’t drag either of those forward into the modern world without major rework, so people running on them were forced to transition.
I don’t see that happening with Perl 5.8. It was an uncommonly good release of a language that was already quite stable by that point. It is, after all, the fourth major version after Perl 5.0. You’d *expect* it to be stable by that point.
The only question then, is whether you can live without the new features. I can.
Red Hat was backporting them up until a few months ago.
Now we just get to see how fast it bit-rots without Red Hat’s support.
I don’t expect it to do so quickly.
Again, see the docs:
I note that this feature is still marked experimental and subject to removal.
…And you’re lecturing me about stability?
mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 7.
That must be someone’s backport. As someone who migrated a mod_perl based app off of mod_perl several years ago, I recommend that you do not use it, unless you have old mod_perl based software that you cannot migrate to newer technologies like FastCGI, Plack, etc.
I hope this does not strike you as inconsistent with respect to my prior posts, since that would be to construct a false equivalence between abandoned software and maintained stable software that is getting no new features.
Also, you speak of CGI. CGI is not at all the same thing as mod_perl. You use one or the other, not both together. You’d know it if you were using mod_perl.
Warren, thanks a lot for this long and extremely instructive post!! I’m with you on all counts.
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
Not replacing the existing system Perl is a feature, not a bug. It allows the ‘Enterprise’ side of CentOS to keep going with no unexpected surprises.
It all depends on how you launch your CGI, but in general there shouldn’t be a problem beginning your script with
Warren Young schrieb:
Trains are a technology well over a hundred years old. If they can be driven by technology about 50 years old and if there´s no better alternative and if you can keep it working, then why not.
Still living in the past seldwhen is a good idea.
It doesn´t matter how many years exactly it was.
Bug fixes may also introduce new bugs. Usually, derelict versions of software are not being maintained anymore but replaced by more recent versions.
I´m aware of that, and the docs do not say that it will be removed, only that it may. That is no more and no less what is usually being said about experimental features in perl.
Not at all; it seems to me that you are the one wanting to lecture about stability.
It doesn´t matter. I do not want to rewrite the software to accomodate an ancient version of perl that has already been replaced by several more recent versions.
You wouldn´t rewrite the software that runs your trains either despite hardware which is already 50 years old my be removed in the future with more certainty than the feature signatures from perl.
Understanding “stability” as “not changing over long periods of time” is certainly one possible understanding. Stability of that kind is simply not feasible within an environment that continues to change, sometimes on a daily basis, and entities that do not change simply die out.
What is it using instead?
The rh-httpd24 does not seem to use a more recent version of perl.
Migrating it is one thing I need look into.
Not at all — the point is that software usually becomes abandoned once a more recent version becomes available.
I never really cared what it´s using because it simply works. Only it doesn´t work on CentOS because the perl version it uses is too old.
Since I don´t want to rewrite the software, what else can I do but look for a way to get it to work before concluding that CentOS is not suited for this purpose.
There are various options. We use mod_fcgid + Plack here.
And atop that, Dancer, if you care. http://perldancer.org/ Join me on the Dancer ML if you want to talk further about it.
And that’s what we keep trying to tell you: in the RHEL/CentOS world, that simply is not the case, because there is a multibillion-dollar entity ensuring that it is not so.
All hail the benefactors!
As a side note, here is why RHEL (and therefore CentOS, since we rebuild RHEL source code to create our base OS) has old software:
If you just spent $5,000,000.00 on a new Point of Sales software for a couple thousand stores, you might want to keep it in production for a bit longer than 6 months on a linux install. You also would like to make sure the system is secure, etc.
There are 2 concepts for updating .. RHEL/CentOS provides a secure OS
that works for 10 years without major changes to ABI/API server related systems .. other distros do updates every 6 months, etc. If you are looking for latest and greatest/cutting edge type functionality .. CentOS is likely not the OS you want.
If you are looking for an OS that runs like you installed it for 10
years and remains secure, then CentOS is the OS you want.
This is one of the advantages of Plack vs mod_perl, by the way: decoupling the Perl version from the web server version.
Are you certain you don’t mean LD_LIBRARY_PATH here?
Beware that some layers of the OS actively redefine LD_LIBRARY_PATH in order to avoid security exploits. I wouldn’t be surprised if systemd did that in some cases, for good cause.
Johnny Hughes schrieb:
The problem is that the expensive POS software doesn´t run on CentOS
because the perl version CentOS uses is too old. It is so old that you don´t need to look for the greatest or latest software to run into problems; it suffices when you look for something that works.
Since there is a recent perl version available, there has to be some way to use it.
Another path to explore is to ask the expensive software producer, as they make a Linux version, why they do not offer a version certified for RHEL?
I think you are looking for CentOS software collections: https://wiki.CentOS.org
# yum install CentOS-release-scl
# yum install rh-perl524
Life is a compromise. If the expensive POS software isn’t designed to run on RHEL/CentOS then you will need to run it on a different OS. I
know your desire is to keep everything the same, but that’s the compromise. No doubt there is – but the compromise is the amount of work necessary to get it functioning in a satisfactory and stable way.
I wonder if you might be better of using something like Fedora since it’s relatively close in structure to CentOS – it really depends on how many machines you need to support and if the 6 month upgrade cycle is going to be too onerous. If nothing else it might tide you over until RHEL 8 – which might well be based on Fedora 26 or 27 if you look at other upgrade cycles.
From perldoc perlsub:
WARNING: Subroutine signatures are experimental. The feature may be
modified or removed in future versions of Perl.
And according to perldelta the signature syntax did change between 5.20
and 5.24. This is bleeding edge. My perl code is deployed on CentOS, but I also test it on Fedora to ensure an upgrade path. I think you should have a talk with your developers or software vendor about the supported deployment environment and path for perl and system upgrades.
Not if the developers were developing on Enterprise Linux .. which they would be.
In all seriousness, you might want to checkout openshift-origin from the PAAS SIG:
Openshift can be used to create both development/testing and production environments where you can easily deploy docker containers with specific SCL software installed together. It can also be configured so that the developers can deploy their own test instances, etc.
There is a supported path by Red Hat for production deployments and even free development available at https://openshift.io/ .
It is fairly easy to have multiple dev environments, etc. using some combination of openshift.io, openshift-origin (the community upstream)
on CentOS, or openShift Container Platform (the supported version from Red Hat).
Warren Young wrote:
I need to look into that when I have time. Test have shown that lighttpd apparently is somewhat faster than apache2, and I´m planning to use it instead of apache for what apache is doing atm.
That´s a good thing, though it can be difficult to run systems using ancient software.
I was looking at the output of ‘env’ when perl524 was enabled and verified that when having LIBRARY_PATH set in the shell, the library is being found.
It would require further testing to find out if setting LD_LIBRARY_PATH
makes a difference.
However, I even created a symlink to the library and it still couldn´t be loaded, so this is just weird.
It needs to at least present a warning it decides to override things explicitly set by the admin, like in a unit file.
Anyway, I´ve given up on this, and the current plan is to use a VM or another machine with a different distribution to provide the service. That will probably be Debian, and we have a VM running Debian anyway, so I might just use that.
You may want to check the following paradigm (from another open source perl-based application) to create a Perl environment within your system, avoiding to tamper with it:
We are running it in production for years and has been great in maintenance and operation (despite my initial fears).
Alternatively, you can use a container. See for example:
Nikolaos Milas wrote:
That´s for network monitoring.
Containers are a bit quirky; I´m running two at home and one of them every now and then gets its /dev/null deleted on reboots, which causes trouble. I wouldn´t want that to happen here. Networking capabilities are also limited.
Other than that, I agree that it would probably be better to use a container for the purpose rather than another VM.
I wonder if it wouldn’t have been faster to just backport the app to Perl 5.16? How hard could it be? It’s not like Perl 5.16 is a hopelessly lame and incapable language.
The recommendation to replace mod_perl with mod_fcgid comes from the RHEL 7 release notes: http://goo.gl/fZxHw9
After sending that message, I remembered that we rejected that option once we found out that when you build your app under Plack, it serves content via a Perl web server using a standard interface called PSGI. That Perl web server normally binds to localhost on a high-numbered TCP port, so we just stood Apache up in front of it as a reverse proxy. That avoids the security hassles of binding to TCP port 80, and it lets us foist the static content serving load off on Apache, so that the Perl layer serves only dynamic content.
There are many PSGI-aware web servers:
The default used by Plack is HTTP::Server::Simple, which is probably fast enough for your purposes if CGI remains appropriate for your app.
If you were already trying to get off CGI to make the app faster, many of the alternatives in that list will get you that speed.
The mod_fcgid method may be easier to port to, since you’re already using CGI, however.
This is generally true only at fairly high loads, up in the thousands of connections per second. Distinguishing this also requires that the bottleneck be in the web server, not in the web app it’s serving.
Since your app is currently running via CGI, one of two conditions is true:
1. You have chosen well: CGI is appropriate for your application, in which case all web servers with the features you need are interchangeable, because the bottleneck is CGI, not the web server.
2. You have chosen poorly: CGI is slowing your app down enough that end users notice the speed hit, in which case you need to get off CGI before you start chasing nonstandard web servers, because speeding up the web server won’t solve the primary bottleneck.
(“Nonstandard” meaning that lighttpd is not in the stock CentOS 7 repos. You have to reach out to EPEL to get it.)
This is not to say that different web servers don’t have advantages even in the CGI case. I run nginx in one extra-small VPS because I don’t have the RAM to run Apache. I couldn’t put enough load on that server to tell any speed difference between Apache and nginx without running it out of CPU or network bandwidth first.
“You keep using that word. I do not think it means what you think it does.”
— Inigo Montoya
It would be possible. There are reasons to use that feature, though, and those reasons remain.
I have no idea. I´m not a web developer, so I´m using CGI as a simple means for the users to use the programs, with a few of the advantages a web browser offers for displaying stuff. There are less than 10 users.
Perl is pretty fast, and most of the work is being done by the database, so I´m not sure how using an alternative to CGI could make things go faster. Apparently it´s possible to save the overhead of compiling the perl programs and of opening connections to the database for every request. Currently, it is questionable if things would go so much faster as to be worthwhile spending days or weeks on changing and debugging a working system.
I simply had the impression that responses came faster, with me being the only user. So what would speak against using lighttpd?
I consider CentOS as pretty much unusable without software from additional sources. It´s not like all its advantages disappear when using such software, and it´s not like all the required software is included. It´s also not like such software doesn´t work.
There isn´t an ideal solution, either, so why not use CentOS for its significant advantages and adjusting it according to what´s needed. So far, it´s working great.
See above, it was merely my impression, not a relevant test. If it works as well and if users get the same impression, it´s fine. If it doesn´t work, I can still use apache.
If we’re talking less than one full page hit per second, then it doesn’t much matter what technology you use. You won’t be able to tell from the end user’s perspective.
(“One” meaning the page and all its static assets, not the inflated count from all the PNGs, JS files, etc. that may be pulled in by the page proper.)
There are many reasons CGI is relatively slow.
1. If you have many connections per second, you need a parallelizable technology to make things go fast. If everything chokes down to a single thread, you’ve got a serious bottleneck when the CPS count gets high enough.
2. CGI re-launches the cgi-bin/* programs on every page hit. Since Perl doesn’t leave behind “compiled” forms of the program as some other dynamic languages do (e.g. *.pyc in Python, *.beam in Erlang) it has to do the entire re-compilation over again.
With FastCGI or Plack, the app remains running once launched, serving hit after hit using the same instance.
3. A follow-on advantage from the above is that you also don’t have to re-establish other runtime resources like DB connections, file handles, application state, etc. You can just keep it in RAM and access it repeatedly on each hit.
But again, down below about 1 CPS, the differences cease to matter, unless you’ve got the sort of app where the difference between a response time of 50 vs 100 ms matters.
Not really. With only 10 clients, you likely have 1 or 0 concurrent hits at any one time, which means any web server is probably fast enough. You could probably swap out Apache for HTTP::Server::Simple and still not notice the speed hit.
If you had to serve thousands of CPS or needed to serve the app in very little RAM, it might be worth switching from Apache to nginx or lighttpd, but since neither applies in your case, you might as well stick with Apache, since that’s the standard web server in CentOS.
Along these lines, SpeedyCGI forms an interesting middle ground between apache-layer perl runtimes and simple CGI re-execution.
If your perl scripts are already mod_perl-safe or have been written with persistency in mind (properly preparing SQL statements, reusing handles, clean variables, etc.), a simple shebang exchange can give you quite a large performance boost, as you’re trading an entire perl compilation and execution for a small C wrapper that connects to an existing perl runtime.
Although upstream hasn’t had any changes to it in nigh 15 years, it’s still right there and available in EPEL 7 as perl-CGI-SpeedyCGI. I’d suggest giving it a shot.