Magento 2.4.2 install via SSH

Since we just had an inquiry about this – from Magento version 2.4 you can no longer install Magento using the browser as you used to with previous versions. In a previous article (HERE) I had already informed about the preparations for a Magento installation with Composer. This article ended with that, that the installation would now be installed by calling up the domain to be used and stored in the hosting and pointing to the Magento root directory.

So this is no longer possible and when you call up the domain, you get an info, that there is a redirect error and the url domain.xyz/pub/setup cannot be reached.

Then call up the URL domain.xyz/setup, you then get the not much more meaningful message “Welcome to Magento Admin, your online store headquarters.
Please review Terms & Agreement and read Getting Started to learn how to install Magento using the command line.”

If you now click on the link to “Getting Started” will you be on the “Advanced Install” Page directed, which attests, that you can use SSH / CLI needs to install.

(SHORT interim note with the request also the P.S. to be considered below, as there MAY be another option.) I will not go into that further now, but rather describe the concrete way, which is now necessary, to install Magento 2.4.x.. With the following command, which of course can be edited to a large extent, the actual Magento installation is carried out:

php bin/magento setup:install --base-url="https://domain.xyz/" --db-host="localhost" --db-name="hierderdbname" --db-user="hierderdbuser" --db-password="hierdasdbpasswort" --admin-firstname="admin" --admin-lastname="istrator" --admin-email="admin@emailadresse.xyz" --admin-user="admin" --admin-password="admin123" --language="de_DE" --currency="EUR" --timezone="Europe/Berlin" --use-rewrites="1" --backend-frontname="hierdieadminurlhinterdomain.xyz" --search-engine="elasticsearch7" --elasticsearch-host="localhost" --elasticsearch-port="9200" --elasticsearch-index-prefix="shopprefix"

This is, of course, a fairly extensive one (and far from being exhausted with all possibilities) command. Details are available on the Magento page. And of course there can also be different information. For Magento 2.4.2 is Elasticsearch requirement. We use version 7. Who version 6 used, just wears 6 a. Just look at the individual details, what is necessary for oneself.

Sidenote:
Because you can quickly get problems with Elasticsearch access (Magento checks this during installation), you can test the possible connection to the Elasticsearch service directly via SSH in the event of problems or before the installation. Use the following command to do this:
curl -XGET https://localhost:9200
Should the ES server not be local now, but externally, Of course you can too
curl -XGET https://pfadzumelasticsearchserver.xyz:9200
use. Username and password are then required, it can also be like that
curl -XGET https://User name:passwort@pfadzumelasticsearchserver.xyz:9200
And finally, of course, the port can also differ from 9200 be. In this case, use the port specified by the hoster. In the specific case of Rackspeed, it was the port 443

The installation should then be completed, usually comes the next problem. Call up the URL on which the shop should now be available, you usually get one 404 – Page not found. In – thank you very much! Why can't anything just work??

This is an innovation from Magento 2.4.2 responsible, which, according to Magento, should increase the level of security. There is also an official one for this manual, that tells you, that one “Virtual Host” should create.

Our host has us following workaround recommended and implemented:

1. Creation of a new folder in the web space (outside of the current root folder. Example: We used the public_html directory for the Magento installation. The domain points to this directory. A new directory has now been created at the same directory level, so that “public_html” and “newdirectory” are on the same level.)
2. All Magento data from the current directory (with me “public_html”) Move to the directory you just created.
3. Remove the old folder (here “public_html”) and creation of a symlink (“Linking”) “public_html” (to which the domain then refers), the on the directory and there the subfolder “pub” refers (so for example “newdirectory / pub”). You have to be in the root directory of the server or. where the domain points. The command would be via SSH, for example.

ln -s neuesverzeichnis/pub public_html

This corresponds to the logic of first storing the complete path to the desired destination and then the path to the link / Symlink. It is of course important to consider the correct server path – By the way, you can find the current path by entering the command “pwd” find out via SSH.

Then Magento should then be reachable normally. In my specific case, the system had come up with a little surprise and showed when called

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

In this case then quickly the file .maintenance.flag (in Magento 1 it was still called maintenance.flag and was in the root directory) in the var / directory.

That's it then “already”. Was it easy – or?

P.S. What I haven't tried and still on mine “To-Do-Liste” is: It would be conceivable, that after the step with the symlink (Here) evtl. the installation via browser also works again and you do not have to install via SSH. If someone has tried that, please leave a comment.

P.P.S. and one more thing at the end: Pay attention to it, that you stored a working email address for the creation of the administrator account during the installation AND, that this address can also receive mail from a source, which were not sent via an SMTP server but via a PHP script. background is, that you already have the first login as an administrator - after entering your username and password- the two-factor authorization is requested (2FA) zu aktivieren. The system has just sent an email to the email address stored for this purpose. This doesn't work – there is only a workaround.

1. Deactivation of 2FA via SSH / CLI: To do this, enter the following command:

bin/magento module:disable Magento_TwoFactorAuth

This generally deactivates 2FA.

2. Change of the stored mail address to a, which does not place such high demands on the source. E.g.. GMX works with us mostly in contrast to Host Europe. The easiest way to do this is to use the database and then the table “admin_user” – there change the mail and again – if necessary. after deleting the cookies or using the private mode ’- register.

Tipp

from Magento 2 neat (let's call it evil) Bring bloatware, does it in my opinion. It makes sense to look after a new installation which extensions, which Magento brings along are really useful and which are not. The well-known Magento expert Andreas von Studnitz has created a very useful function here, which can be downloaded from Github (HERE). This creates a file when it is called, which shows all functions, which have no dependencies (for the standard operation of the shop) and could be disabled.

After deactivating the extensions, noticeable increases in performance can be achieved.
AvS also gives the instructions, how to use its extension after use (you only do it once) can uninstall again. Tolles Tool!

And another little tip, in order to be able to deactivate many extensions quickly: Drag the modules-removable.csv file into Excel or Calc, a new column with

bin/magento module:disable

and then merge this column and the column with the extension names in another column.

You can then simply copy & Paste in putty deactivate the extensions.