Mateusz's picture

Hi,

I installed new Magento image with Magento 2.2.5 and php 7.0, adminer, webmin. Evertyhing its ok. But my attetion is:

LOW:

- On the end turnkey installation in the summary admin panel is "domain/admin" but admin panel is generated on the another site for example in env.xml 'frontName' => 'admin_XXXXX'

 

HIGH:

- Installator use Apache web server and use www-data user which is owner Magento directory path /var/www/magento. Magento is application which should use own shell user which for example must use Composer to deploy plugin etc. The composer can not be used as root and www-data is no shell user. After installation, there is also work related to the addition and configuration of a new user.

PROPOSE:

- Change apache for nginx

- Install varnish

- Install redis

 

Best Regards

 

Forum: 
Tags: 
Jeremy Davis's picture

Thanks for your feedback on our Magento appliance. We really appreciate and always try to take stuff on board. Having said that, we have a huge array of users with different desires, needs and preferences. So "getting it right" by everyone's standards, is near impossible. I'll try to respond to your points in order:

Note re the admin URL: Thanks for that. I recall noticing that the admin URL used a random string when I did testing, but I didn't note it at the time. My bad! Also, I'm not sure if that's setup on install, or on launch. If it's on install, then perhaps we should ideally be regenerating it on firstboot (and display it on the confconsole). Regardless, we shoudl document it for now. I've opened a new issue.

Composer running as root: Thank you for raising this. As far as I understood it, the biggest issue with using composer as the root user is that it will affect the file permissions (stuff will be owned by root, rather than www-data). That may have implications for the webapp itself and could potentially cause issues.

However, a quick read here actually alerted me to the real potential security issues! I was aware that there had been noises about security concerns, but I was under the impression that that was the usual "Ubuntu user" type noise about "shouldn't ever run as root" and the only real world issue was permissions. It seems I was wrong!

I have opened an issue for this too. At the very least we should clearly document how to use the www-data user somewhere obvious. But we should also consider your suggestion of adding a "composer" user (member of the www-data group).

Even though www-data user does not have a shell by default, that doesn't mean that you can't run as that user with a shell! So to open a shell session as the www-data user, try this:

su - -c /bin/sh www-data
su - www-data -c /bin/sh

Then you're running as the user: www-data! :)

Re your proposals. I quite like Nginx and I know that it is hugely popular, but we do have reasons why we don't use it by default. First thing worth noting is that it's actually only better at serving static content, it actually can't serve dynamic content. So for a PHP web app such as Magento you have to run a separate PHP processor (usually PHP-FPM). Now that PHP7 has implemented many of the improvements that PHP-FPM provided, you should find that Apache using mod_php should actually be able to process PHP faster! Admittedly, any advantage in PHP processing is often lost several times over because of the resource overhead of mod_php being loading into memory when serving static content, so in the real world, it's rare to see significant improvement, but it's worth mentioning.

Apache also has a range of module and plugins which makes it very flexible. Most of them are packaged for Debian, so we can leverage the auto security updates. It also has fantastic documentation and a Webmin module that makes it quite newb friendly. It also has support for .htaccess files which Nginx is missing. Whilst that doesn't necessarily have any direct impact for Magento or other projects which don't rely on .htaccess files, we do have PHP apps in the library which do. So to be able to use Apache as a common component with decent default config reduces our maintenance overheads.

Your suggestion for Varnish is a good one. Again, I've opened an issue for that. The interesting thing about that is that it caches the static content, so likely would boost Apache performance much more that Nginx, although again real world results would depend on your specific use case.

Redis I'm not so familiar with personally. I'm sure it provides advantages and we probably should consider including it with some apps. In the near future, we'll likely provide a standalone Redis server. Whether we'd move to pre-integrate it with other appliances, I'm not sure.

Thanks again for sharing your thoughts. We really appreciate it and I hope to at least include documentation for usage of composer and note the Magento admin url.

Good luck with it all and please feel free to share any more thoughts you have.

Mateusz's picture

Hi,


Many thanks for your response and thanks for taking my comments. I try use your command but I get: 

root@magtest .../www/magento# su -c /bin/sh www-data
This account is currently not available.
 

I use new installation as I wrote earlier.

 

Best Regards

Mateusz

Jeremy Davis's picture

My apologies - I had the order wrong. It should have been:

su - www-data -s /bin/sh

That will teach me for posting stuff from memory and not double checking it first!

Also please note that the extra dash (-) between su and www-data is somewhat important. Unless you include that, you will not be getting the www-data user's environment (will still have root's).

Jeremy Davis's picture

Firstly, you may actually find bash a better shell to use if you are doing things on the commandline as the www-data user (although it shouldn't matter too much for most things). I.e.:

su - www-data -s /bin/bash

Also, if you only want to run a single command, you can append the command on the end preceded by the -c switch. I.e. as a (not very useful) example:

su - www-data -s /bin/sh -c 'ls /var/www/magento'

Note the quotes around the command (double quotes are ok too). If you use a single command you don't need them, but if there are any spaces etc, you need to quotes otherwise it will try to process them as arguments for su.

L. Arnold's picture

I tried the lower switch of user:

It gave me a $ input line.

I then added

composer require Magento/data-migration-tool:2.1.7  (TKL 14.2)

and got a string of errors

(I would post a pic but cannot seem to.  Also not doing well copying from Webshell into this Box)

Anyway,  started down the road.


ps. I probably need to jump to TKL 15 but I need to run TKLDEV to build the right package it seems.

L. Arnold's picture

I was not able to run

composer update

but ran 

dir

saw I was in /var/www

went

cd magento

composer update

and update started.

got a few warnings  at the end then

but working forward

seems to have upgraded composer right now.  Magento next.

L. Arnold's picture

who knows why the PHP command is needed there but here it is again:

php bin/magento setup:upgrade

Closes with "please rerun Magento Compile command".

I don't think this is compiled. but running:  

php bin/magento setup:di:compile

Composer.json still says I am at version 2.17 but lets see:

I am probably nukeing everything from here but it did compile.  JSON did not update...

(lets see if I can at least start Apache)

https://devdocs.magento.com/guides/v2.3/comp-mgr/cli/cli-upgrade.html

says I need to create a project etc. etc.  Seems that is a install from source guidance but perhaps I am wrong.

(no varnish service,,, per above near the end)

seems I just downloaded everything again.....  

To the end.  not starting on a browser.  Webshell and Webmin are working at least.

------------  OK.  will do a fresh version and try to parse this more.

referential below.  A bit dated already.

https://magento.stackexchange.com/questions/98332/how-to-update-magento2-using-composer

 

Jeremy Davis's picture

If you are using TurnKey v14.2 or later appliance, then we download the code via a shallow git clone, then install with Composer. If you wish to see how it was installed, please check the build code (conf script is likely the logical starting point) at the relevant version tag (e.g. v15.0).

According to that doc page you linked to (i.e. Upgrading via composer), the proper instructions for updating (as per the way we installed) is instead this page. Perhaps you might have better luck following those instructions?

FWIW if you check the appliance page that includes links to the "official" Magento v1.x to 2.x migration guide and they note that there is a data migration tool. I don't know anything about it, but I suggest you give that a go for migrating data from older v1.x Magento sites.

Hopefully that gives you a bit more background. As far as further Magento specifics go, please feel free to ask, but I don't know a whole lot about it, so you may be better off seeking advice from seasoned Magento users (e.g. Magento stack exchange?).

L. Arnold's picture

Thanks Jeremy,

You noted:  

 and they note that there is a data migration tool.

I did try that first but got the error that there is no DataMigration tool for that version.  I have not verified that by looking in the repository, but I assumed then that the best thing to do would be to upgrade Magento to current version via Composer, then run the DataMigration tool for the current version.  That was the plan.

I will get back to this soon.  I will study the Migration guide and the Composer guides you linked above.  

 

Jeremy Davis's picture

Hmm, I'm not really sure...

I was just having a look at the migration tool and whilst I can't 100% confirm that it should apply to Magento 2.1.7, I do note that it refers to migrating from "Magento 1.x to 2.x" which suggests that it should apply to you. However, there are a few things I've noticed from my reading....:

Firstly, apparently you can not "upgrade" from v1.9 to 2.x; you must "migrate". I.e. you essentially need to migrate your data from your old v1.9.x Magento, to a new v2.x Magento. They can be installed and running on the same system, but it's likely easier to migrate the data to a new TurnKey server (rather than trying to do it on a single server. But perhaps I'm missing something...?!

Next up, the migration tool explicitly notes that PHP >= 7.1 is required, although I also note that some others running PHP 7.2 have hit issues and apparently, for everything to work smoothly, you explicitly need PHP7.1?! Having said that, there is also a report that someone using PHP7.1 was still having issues, so perhaps the PHP7.0 provided by TurnKey v15.4 Magento appliance might do the trick? Although please note, that includes Magento 2.3.x, so may be newer than you want. The previous TurnKey appliance, v15.3 included Magento 2.2.8, with PHP7.0.

So TBH, I don't have any clear and certain ideas on how to proceed. Although, if you care to document the steps you take and any issues you hit along the way, I'm happy to assist as best I can.

If you want the input of Magento experts, then probably the best place to ask is either the Magento forums or the Magento Stack Exchange.

Hope that helps, at least a little...

L. Arnold's picture

Your note on how to run certain commands with  -su www-data

su - www-data -s /bin/bash

is very important for running composer and in turn installing Magento's DataMigration Tool.

https://devdocs.magento.com/guides/v2.3/migration/migration-tool-install.html

https://devdocs.magento.com/guides/v2.3/migration/migration-migrate-settings.html

Lots to work through there.

Once Composer has loaded the DataMigration tool you need to "exit" the "su - www-data" above back to root (in TKL Magento 15.4 anyway)

This is the sort of command you need to run from Root to get things going. 

Magento Says USE:

bin/magento migrate:settings [-r|--reset] {<path to config.xml>}

TKL Shell syntax that brought some of 1.9.3.6 Magento over to 2.3.1.  

bin/magento migrate:settings /var/www/magento/data-migration-tool-2.3.1/etc/opensource-to-opensource/1.9.3.6/config.xml

 

I have not done well yet with the [-r | --reset] (but likely just "-r "or "--reset" if it is used)

I won't belabor this further here.  The config.xml and settings.xml have many many components.

This is a reasonable outline of the Magento Migration process that is not coming from Magento itself:

https://www.goivvy.com/blog/magento-2-migration

Add new comment