search

cypht-org / cypht

Cypht: Lightweight Open Source webmail aggregator [PHP, JS]
http://cypht.org
GNU Lesser General Public License v2.1
976 stars 153 forks source link

Web based configuration script #17

Open jasonmunro opened 9 years ago

jasonmunro commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 7 years ago

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

jasonmunro commented 7 years ago

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

jasonmunro commented 5 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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: https://github.com/jasonmunro/cypht/issues/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 commented 2 years ago

I was thinking about this yesterday. Beyond a standard installer, we should have something to set up tests: https://github.com/jasonmunro/cypht/issues/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 commented 2 years ago

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 commented 2 years ago

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

Here are examples of recipes:

marclaporte commented 1 year ago

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

marclaporte commented 1 year ago

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: https://github.com/roundcube/roundcubemail/issues/4972#issuecomment-640747464

marclaporte commented 11 months ago

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

marclaporte commented 7 months ago

We are working on the docs here: https://github.com/cypht-org/cypht-website/pull/46