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.

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.

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