I am trying to upgrade from Typo3 6.2 to a later version (to be determined). When I run the Core Update in the install tool the 'Fetched list of released versions' works, however, it is then followed by a 'General error'. In the log, this is the error:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1380898792: No version matrix found in registry, call updateVersionMatrix() first. | TYPO3\CMS\Install\Service\Exception\CoreVersionServiceException thrown in file /home/usr/public_html/typo3/sysext/install/Classes/Service/CoreVersionService.php in line 271. Requested URL: https://domain.dev/typo3/sysext/install/Start/Install.php?install[action]=importantActions&install[context]=backend&install[controller]=tool&install%5Bcontroller%5D=ajax&install%5Baction%5D=coreUpdateIsUpdateAvailable&_=1608549770287
I have looked around for ages and can't find a fix that works. I will be very grateful for any help, please.
I don't think that you can update such an old Version by the install-tool update mechanism any more. since that version a lot has changed.
newer versions of 6.2 are only available as paid service (ELTS) from the TYPO3 GmbH.
And I think the server structure also changed meanwhile so that old ULRs might fail.
your way of update should be a manual update to (any outdated version of) 7 LTS, then the same for 8 LTS until you come to 9 LTS and 10 LTS
on each version do the upgrade wizards and fresh up the extensions if possible (including the upgrade wizards of the extensions).
individual extensions need their own updates.
use the deprecation log on each version to identify possible failures for the next TYPO3 version.
somewhere between you might change the installation to composer installation, which will result in a cleaner update way (if you are familiar with composer). for the future it will be very helpful to understand composer.
Related
I've been to the Releases site for mod_auth_openidc and brought down the rpm. And attempting to install requires cjose but attempting to find and install that poses a problem as it seems to incorrectly test the version of jansson (e.g., 2.10 is though to be less than 2.3). Most of the documentation I find is years old. Trying to use yum brings in a very outdated version of the mod_auth_openidc (1.8.8) that fails to allow apache httpd to load if you have an OIDCDirectURL coded.
I'm trying to configure Apache HTTPD to call out to an OAUTH2 Server I've created but I can't get the old mod to work and I'd love to know where I can get the piece parts to allow the latest version to install. There are some old downloads on the Releases site if you page back to 2.0 but the libcjose0 is not an rpm.
Do I need to retrieve the dependencies from their github and build them? If someone has done this already and posted the assets I'm happy to retrieve them. I'm surprised RHEL 7 repos don't have the latest (or newer) versions of the mod_auth_openidc.
The version issue reported when trying to install cjose is a red herring. Based on this site I found I needed to install jansson-devel to get past the errant warning about versions.
Going here allowed me to retrieve a fairly recent version of cjose-0.5.1-1.el7.centos.x86_64.rpm which installed without complaints once jansson-devel was installed.
I was then able to install mod_auth_openidc-2.4.9-1.el7.x86_64.rpm from the github repo releases
I am now able to start apache httpd with the OIDCRedirectURI entry in httpd.conf
I upgraded the mettermost version from 4.4.1 to 4.5.
However, I got the error...
So, I tried to downgrade the version to 4.4.1, but the mattermost said "The database schema of the older version isn't supported".
Does anyone know how we should modify the database schema.
※browser: FireFox ESR 52
Unfortunately you can't downgrade a Mattermost install to a previous version through any officially supported path. You will need to revert to the database backup from before the upgrade in order to go back to version 4.4.
However, for the specific versions in question (reverting from 4.5 to 4.4) it is possible to do a downgrade as there are no database schema changes between these two versions. You will need to run the following SQL command in your Mattermost database:
UPDATE Systems SET Value='4.4.0' WHERE Name='Version';
You should then be able to run Mattermost 4.4.1 successfully on that database.
A penetration test has recently identified that one of our RHEL(6.7) servers running Apache 2.2.15 is vulnerable on a number of points and needs to be updated to the latest version 2.4. I have run yum update and it says that there are no packages marked for update. I understand that I will need to download the updates manually. There are a few questions I have around the requirement to upgrade Apache.
I am up to date on the 2.2 version tree. Does this mean that any security patches made to version 2.4 will be back patched to version 2.2.X as well?
I am running PHP (version 5.3.3) and MySQL (version 5.1.73) - will these be affected by upgrading the Apache version (Google tells me that there is no problem on both fronts - but I thought I'd ask before I started down this route).
If you experts tell me that I have no other choice but to upgrade, then I'm planning on using the instruction set here: https://unix.stackexchange.com/questions/138899/centos-install-using-yum-apache-2-4
Thank you in advance for your advice.
You could download the 2.4 source code from the Apache site and compile it. There's a setting which will configure for RedHat:
--enable-layout=RedHat
This setting will configure the paths for executables, configuration files, libraries etc in one go.
The following should be a reasonable starting point for a configuration line:
sh ./configure --enable-layout=RedHat --enable-mods-shared=all
then perform a make and make install
Do the same with a newer version of PHP (5.3.29 is available in the "old downloads" section, but try a newer version. Check the changes first though) and your problems should be lessened. Finally, MySQL or MariaDB is available for download and compilation too
Obviously, try all of this on a test machine first and back everything up. Your test machine should be as close as possible to your production machine. If you use something like VirtualBox to try it, you can take a snapshot at each point of the process and rollback if something goes wrong
I am trying to run my pharo2.0 application on CentoOS which was previously been installed in a mac. The original version is pharo2.0 so I need to run the same image CentoOS too, but I get an error which says this below :
/lib/libc.so.6: version `GLIBC_2.15' not found (required by xxxxx)
Should I be trying to upgrade the CentoOS and see if pharo2.0 works or port my whole application to a later version of pharo?
There is now a VM build especially for systems with an older libc version. In fact there is a build for Centos specifically (which has a slight variation in linkages from Debian), the latest version of which is permalinked here. See http://pharo.org/download#custom for more info.
I use Centos 6.5, I've installed apache 2.2 on my server by yum, I want to upgrade my apache to 2.4, but yum not support that, so I download apache 2.4.7 and install it to opt/apache/httpd-2.4.7 follow the tutorial here: Apache 2.4.x Manual install on RHEL 6.4 - No apache modules will load on start . I want to change environment variables to new apache version to write apache 2.4 modules (change include folder for header file, change "modules" folder when build with apxs,...). I think I must install another httpd-devel for apache 2.4.7, because I still not install httpd-devel-2.4.7, but I don't know how to install and use it instead of httpd-devel-2.2 by yum. I can not describe my problems clearly in English, so I hope you can understand it. I'm a newbie and I really need your help. Thank you!
CentOS is image of RHEL, which stands for Red Hat Enterprise Linux. RHEL is designed to be an "Enterprise class" operating system, in which you rely on software packages that are delivered from controlled repositories where they are made available only after being thoroughly tested for Enterprise level use.
From that point of view, its generally not a good idea to install packages from source code, or using third party RPMs, because once you do, your OS is no longer "Enterprise" class.
If you're trying to upgrade for security reasons, you shouldn't. Critical security updates are always backported in previous RPM releases, so you only have to update your current package from the same yum repo from where you got it first. The binary will still say it is Apache 2.2, but it will have the latest security updates.
If you need an actual feature of 2.4, the smart move is to upgrade your CentOS. It may seem like the harder option initially, but it never is in the long run.
In my experience these reports can be fairly basic/binary:
Are you running the latest version of the software? If no flag as security risk.
However this fails to take into account package managers which back port fixes to older versions and so often have addressed potential security issues.
By moving away from the packaged version you are making security updates more difficult (as can't do a simple "yum update" to address them anymore).
Apache 2.2 is still maintained for security and bug fixes - though how long for remains to be seen and it is falling further and further behind in features.
So often you just need to explain (and prove!) you have a regular patching process and so the "version of Apache" you are reporting is not really accurate in terms of security patching.
See here for more details: https://serverfault.com/questions/731657/pci-compliance-apache-versions/
Saying all that we moved to Apache 2.4 on centos a while back for some extra features we wanted and just upgrade it to the latest version as part of regular patching cycle and are not finding it too inconvenient. Yes it's not quite as simple as "yum update" but it's a decision we've made because of some features we required. Not a decision to be taken lightly as Garreth states but it had the added side effect of this not getting highlighted anymore in these sorts of security scans :-)
We made this decision despite upgrading to a newer version of Red Hat as that was still on an older version of Apache (2.4.7 if memory serves me correctly) which still missed a few features we required. Sometimes it's frustrating how far behind some of these "enterprise" versions are, but that's the downside when there are plenty of upsides to using them too (stability, security... etc.).