Web based configuration script

[jasonmunro]

Currently we have a set of CLI scripts to create the Cypht configuration and add/remove/modify user accounts (when using the DB authentication method). It would be great to have a web based version of these to make installation easier, especially for shared hosting environments.

[dumblob]

In my opinion this is quite a minor issue. In fact, this is a thing of a system-specific configuration tools or principles. It might be some packaging system (rpm, deb, pkgbuild, ebuild, etc.), it might be some configuration system (ansible, chef, puppet, etc.), it might be some specific GUI application, it might be just a text editor (nvim, emacs, nano, etc.). The only solution which from my experience works is well-defined configuration file semantics with well-known structure (e.g. JSON) at a well-known location (e.g. /etc/).

[jasonmunro]

I agree, but this is a big blocker to adoption, and if people can't try out the software it's hard to build momentum behind it. We include CLI helper scripts for a few things already, it's not too much of a stretch to "web-ify" them. My main concern with both the configuration arrangement we already have and a web based setup script is security.

[dumblob]

Right, what I meant was "begin with a thoroughly defined configuration file (in terms of semantics and syntax)" as the core feature and "end with a simple web GUI operating upon this well-defined configuration file".

And it's true, that unification is the way to go. Not a set of different user-space scripts with varying interfaces.

Regarding security, do you mean the need to introduce authentication and at the same time providing bug-free web app being safe when reading/writing the configuration file(s)?

[jasonmunro]

thanks for the clarification. That is very much the approach I'm taking. The "defined" file is the hm3.ini file, the output is the rc file (serialized array). The web interface is just a way to manage both without a text editor and cli commands, but it ultimately will use the same code path.

WRT security, the issue is authentication. CLI commands have an implicit authentication associated with them (even that is not ideal), but providing a web interface to "bootstrap" an installation is worrisome, if for no other reason than it gives people an easy way to shoot themselves in the foot :)

[Kroesss]

Is there any news on this ticket yet? It would be great if it could be used on a shared hosting-environment.

[jasonmunro]

@Kroesss, Sorry, this is still pretty low on my priority list right now.

[jasonmunro]

As of today I have disabled the half ass web based configuration builder we had in the scripts directory. I did this for a number of reasons as described in the commit:

1. It does not work
2. While only available in debug mode, it's not secure
3. Even if I get it working, it's not going to be easy to use and hard to maintain.
4. I'm seriously considering trashing the idea completely

As much as I understand why people want a web based installer, I just don't think it makes sense with the Cypht install process.

[marclaporte]

For folks that need this today: Cypht is bundled in Tiki, and Tiki is shared hosting friendly since 2002! As a bonus, you get CardDAV and CalDAV support (Beta).
https://info.tiki.org/Benefits
https://dev.tiki.org/Cypht-integration

[Yamakasi]

For folks that need this today: Cypht is bundled in Tiki, and Tiki is shared hosting friendly since 2002! As a bonus, you get CardDAV and CalDAV support (Beta).
https://info.tiki.org/Benefits
https://dev.tiki.org/Cypht-integration

What kind of advertisement is this? Please stop that.

Thank you!

[marclaporte]

Here is why this is relevant information:

The topic of this issue is to be able to install Cypht via a web installer like most PHP web apps. So the typical use case of a web control panel like Virtualmin, ISPconfig or the well-known proprietary alternatives.

1. Create DB (via the web control panel)
2. Get the source (ex.: via a .zip)
3. Unzip the source in a web accessible folder and point a browser to it.
4. You will then get a web installer. Answer the questions (ex.: the previously created database info)

The fact that this is missing is "a big blocker to adoption" as stated by Jason.

AFAIK, there is only one way today to get Cypht with a web-based installer, and it's via Tiki. Tiki has tons of features but they are all optional. So you can activate only Cypht. So basically, Cypht can use Tiki's installer. Cypht and Tiki share the same license and programming language, so it's even easy to move/copy code as appropriate.

We are "upstream first" as explained here:
https://www.redhat.com/en/blog/upstream-first-turning-openstack-nfv-platform
Every webmail enhancement Tiki makes is first proposed to be in Cypht. And if it's out of scope, it will go in Tiki only. Here are some discussions about scope:

• Attachments preview: what is the scope of Cypht? #382
• Batch sending of emails #115

We should make a Cypht Webmail profile to make it even easier: https://profiles.tiki.org/

And my goal is to get other PHP web apps to adopt Cypht in the same way. The first opens the way. The more projects do, the more eyeballs and developers we have. Cypht + Packagist is for Cypht, for Tiki and for all future projects that will embed Cypht:
#311

In a nutshell:

1. Cypht is awesome
2. We'd like Cypht to be easier to install
3. One great way is for Cypht to have a web-based installer.
4. From Jason's last comment, it seems unlikely to happen
5. My suggestion is a real world workaround available now
6. It does not stop any effort to create a Cypht-specific web installer
7. All webmail enhancements are done directly in Cypht when appropriate. So Cypht and Tiki have a win-win relationship. There is no downside or tradeoff.

Tiki has over 1 million downloads and it is promoting Cypht, so it makes perfect sense for Cypht to promote Tiki as well.

Best regards,

[marclaporte]

I was thinking about this yesterday. Beyond a standard installer, we should have something to set up tests:
#596

Perhaps this could be done with Composer? Tiki already gets Cypht from Composer so this is well-tested: https://dev.tiki.org/How-to-upgrade-Cypht-within-Tiki-via-Composer

[marclaporte]

A few years back, we did some research for https://dev.tiki.org/Generic-PHP-app-deployment-tools-which-are-written-in-PHP
In the end, we opted to continue work on our Tiki-specific tool: https://doc.tiki.org/Manager (which started in 2008 or so)

When the time comes to work on this, let's see if we can reuse an existing project. Let's make it super easy for web hosting providers and control panels to provide and maintain Cypht.

[marclaporte]

Over 10 million installs: https://packagist.org/packages/deployer/deployer

Here are examples of recipes:

• https://github.com/deployphp/deployer/tree/master/recipe
• https://github.com/deployphp/deployer/tree/master/contrib

[marclaporte]

Related: https://github.com/YunoHost-Apps/cypht_ynh

[marclaporte]

We'll work on improving the process to avoid this:
"I'm really totally lost with this, my best best would have been Cypht, but after days of trying to install it, I'm about to give up because I just can't get it to work (stuck at the login screen and doesn't go further although everything is setup and configured properly)." Source:
roundcube/roundcubemail#4972 (comment)

[marclaporte]

I wonder: Should we invest our time in a web-based installer or improve our Docker package?

[marclaporte]

We are working on the docs here: cypht-org/cypht-website#46

[marclaporte]

mprove our Docker package

We have massively improved our Docker packaging: cypht-org/cypht-docker#31