Complete the automatic (cli) install process

[m33m33]

Hello there,

I am giving Friendica a try on Linux + Docker.

It seems other admins have difficulties setting up a new instance from scratch.

1. The automatic install using command line only is incomplete, this PR proposes a solution about that:
   When desired environment variables are set, don't leave the install halfway, the doc says "Automatic installation" it should leave the instance in a usable state right away. Otherwise the admin fallbacks to the WebUI install wizard.
   It may fix issues like Docker Instructions fail to result in usable installation #134

2. The WebUI install (wizard) is stuck in a loop, as Docker Compose Install Not able to complete Install Wizard #266 I have a similar problem.
   But at this time this is above my skills to help about that.

Hope it helps

[m33m33]

Note that I debated alone about the admin password generation.

That’s the only solution I have in mind for a completely automated install without adding something even weaker, like a new environment variable FRIENDICA_ADMIN_PASSWORD … something more robust will be needed for deploying Friendica on enterprise grade hosting (Kubernetes and anything that prevent the admin to actually read the generated password)

The app (friendica) docker compose up looks like that now:
`
friendica-1 | Starting Friendica installation ...
friendica-1 | Initializing setup...
friendica-1 | Complete!
friendica-1 |
friendica-1 | Checking environment...
friendica-1 | NOTICE: Not checking .htaccess/URL-Rewrite during CLI installation.
friendica-1 |
friendica-1 | Complete!
friendica-1 |
friendica-1 | Creating config file...
friendica-1 | Complete!
friendica-1 |
friendica-1 | Checking database...
friendica-1 | Complete!
friendica-1 |
friendica-1 | Inserting data into database...
friendica-1 |
friendica-1 | Complete!
friendica-1 |
friendica-1 | Installing theme
friendica-1 | Complete
friendica-1 |
friendica-1 |
friendica-1 | Installation is finished
friendica-1 |
friendica-1 | Adding the administrator account named: admin [NOTE: mailbox name from FRIENDICA_ADMIN_MAIL]
friendica-1 | msmtp: account default not found: no configuration file available
friendica-1 | Setting password
friendica-1 | Password changed.
friendica-1 |
friendica-1 | YOUR ADMINISTRATOR PASSWORD IS: cYyo2DEr6dxXHKJ10YMkuSpAp/s+tYL4sPIvL3mD [NOTE: random]
friendica-1 | NOTE IT DOWN AND CHANGE IT ON FIRST LOGIN
friendica-1 |
friendica-1 | Installation finished

`

[MrPetovan]

Looks good to me, but I'm not a Docker guru, I'll summon people with more knowledge than me.

[ne20002]

Thank you for your contribution, @m33m33.

Maybe @nupplaphil can say something to the --admin option in the install_options?

I'm currently trying to do a rework on the friendica devcontainer (in friendica project) to make as much similar to the docker setup (with the apache) as possible. As the devcontainer is based on the docker compose this shall give an easy to use test environment for changes on the docker setup.

[ne20002]

Isn't it the idea of creating the admin account with the --admin parameter in the install_options? I'm not sure if it doesn't work with the install_options but to me it looks suspicious to have this on two places.

[m33m33]

I don’t know about install_options, this patch simply mimics the command lines calling console user/password.

[ne20002]

I refer to the lines with the friendica install in lines 158,159.

echo "Starting Friendica installation ..."
run_as "php /var/www/html/bin/console.php autoinstall $install_options"

Within the install_options there is the --admin parameter with
--admin "'$FRIENDICA_ADMIN_MAIL'"

I believe this is for creating the admin account so I wonder why you see a need to add it afterwards.
But I have no deeper knowledge of what autoinstall does.

I also wonder if the problem with the creating of the admin account is a docker image problem only or if this also applies to plain installation. In this case the fix should be in the autoinstall implementation.

[m33m33]

Within the install_options there is the --admin parameter with
--admin "'$FRIENDICA_ADMIN_MAIL'"

I will have a look at what this does if I can

I also wonder if the problem with the creating of the admin account is a docker image problem only or if this also applies to plain installation. In this case the fix should be in the autoinstall implementation.

At this time with stable release: the WebUI wizard is also stuck in a loop on my system (you go through all the 3 config screen then blank page, refresh and you go again). This is why I abandoned it and went for the command line only.

[m33m33]

To me it seems it only collects the administrator's email and put it in the configuration file :

Console.php => AutomaticInstallation.php => Installer.php and you see it here in createConfig()

[m33m33]

I too have a very limited understanding of Friendica internals, like 5%.

My point is installing a new instance now 80% of the time would be in a docker container, and it must gives a functional instance right away, otherwise it's an early disapointment and they are so many turnkey options to choose (I'm trying Sharkey next to Friendica because I used to host a Misskey-Foundkey instance, firing up a dockerized Sharkey instance is a no brainer: 2 mins and you're up). I think Friendica's installation process should make reasonable assumptions and go full automatic like that (and of course for experienced admins have a manual way to install). I understand that Friendica is trying hard to be compatible with many environments, from a managed LAMP stack to docker or bare metal fully manual install, that's a good thing since I don't know many other Fediverse instances that can do that, no critics here, just trying to get beginer admins like me a push to get in the saddle ;)

[ne20002]

Ok, thank you for digging into it.

Having the cli install working and the web install not seems to be better than having none of them working. But I still wonder why the web install is not working and if there is a common reason.

[m33m33]

I'll summon people with more knowledge than me.

Ask them if this can be problematic for headless installation, I’m not 100% sure displaying the password during initialization is better than asking for an environment variable or something

[ne20002]

@m33m33, I believe the adding of the creation of the admin user is no problem. But changes like this needs to be made in the Dockerfile templates. ;)

Also, I prefer to create less commits by using git commit --amend and git push -f so subsequent changes made are merged into a single commit. Makes the handling much easier.

[m33m33]

@m33m33, I believe the adding of the creation of the admin user is no problem. But changes like this needs to be made in the Dockerfile templates. ;)

Not sure about that, it you create the first administrator password in the dockerfile, will it be hardcoded in the image ? everybody downloading the image from docker hub would end with the same admin password ?
I have seen others projects using the entrypoint script to do initialization work, maybe it's not best practices either, don't know for sure. Maybe @MrPetovan 's docker guru friends knows better.

Also, I prefer to create less commits by using git commit --amend and git push -f so subsequent changes made are merged into a single commit. Makes the handling much easier.

Noted, until now with limited ressources here I use the github online code editor.

[ne20002]

Oh, sorry. Not Dockerfile template but entrypoint.sh template. ;)
The one in the root folder. The files in the versioned directories are generated from the template files.

Also, I don't see a problem with the printing of the password to the console during install. If one misses it or don't look for it it is still possible to set a new password for the user with the console (as before).
Updating the documentation would be a good idea anyway.

Maybe it's easier to create a new PR.

[ne20002]

I have done some deeper digging into the setup procedure for the docker install and friendica install as described here.

I'm now unsure if the idea of adding the admin user like proposed in this PR is a good idea. If this is how we want to do it, it means that the standard way by registering the admin user on the start/login page won't work anymore. It's either this or that. Manuall adding via console will still work if there are problems with the web ui register.

Anyhow, the documentation needs some updating to make the procedure and the required SMTP setup more clear.

And I believe the whole process needs some rework (at least for the docker install).

[m33m33]

Maybe this:

• if there is not enough informations to start the webUI, the admin account is created on console
• if the webui is started (how can we know?), let the user create an admin account

The point is, to me, the promise of an automatic install should ends up with a complete, running instance. Admin account included. Else it add unwanted difficulties for new admins, and like I said it's a turndown.

[ne20002]

it add unwanted difficulties for new admins, and like I said it's a turndown.
I agree with the argument.

Anyway, I'll close this PR due to

• the changes are made in the wrong file(s). The files in the version directories are created/overwritten by the update script. Changes like this must be made in the template files.
• We have two variants to create the admin user already (even though they are somehow broken or need better documentation)

If we add the user like in this proposal, the creation of the admin user by registering in the login screen wont work anymore.

I see kinda three stages for the install of a friendica system with the docker images:

• prequisites: like msmtp. This needs to be documented accordingly.
• friendica install: this is the install of friendica system
• setup/configuration: this includes the configuration options that are available from plain friendica and I believe it would be good if the docker install behaves identical. This shall also reduce diverging or missleading documentation.

I see it important to first document correctly and completely the existing variants and make them work again.

I believe we can then afterwards decide if creating the admin user like proposed in this PR is a good idea. And we need to document this also fully and correctly. But first I want to fix the registering.

The variants for the setup are:

• web based wizard
• autoinstall based on env variables

The variants for creating the admin user are:

• by registering on the first start/login screen
• by using the console commands inside the docker container

I appreciate the work you've done and your tests have been very helpfull. I do hope we get the already existing variants and the hickups we've faced fixed and documented.

Documenting on how to add the user with the console shall be the first to document. I'm sure when someone can create a system with a docker compose setup he can also create the user manually when given a howto do this.