mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 04:56:03 +03:00
[GH-ISSUE #17] Web based configuration script #15
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jasonmunro on GitHub (Aug 19, 2015).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/17
Originally assigned to: @jasonmunro on GitHub.
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 on GitHub (Aug 19, 2015):
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 on GitHub (Aug 19, 2015):
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 on GitHub (Aug 19, 2015):
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 on GitHub (Aug 19, 2015):
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 on GitHub (Oct 26, 2016):
Is there any news on this ticket yet? It would be great if it could be used on a shared hosting-environment.
@jasonmunro commented on GitHub (Nov 1, 2016):
@Kroesss, Sorry, this is still pretty low on my priority list right now.
@jasonmunro commented on GitHub (Sep 24, 2018):
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:
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 on GitHub (Oct 30, 2020):
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 on GitHub (Nov 1, 2020):
What kind of advertisement is this? Please stop that.
Thank you!
@marclaporte commented on GitHub (Nov 17, 2020):
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.
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:
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 on GitHub (Aug 14, 2022):
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 on GitHub (Aug 16, 2022):
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 on GitHub (Aug 22, 2022):
Over 10 million installs: https://packagist.org/packages/deployer/deployer
Here are examples of recipes:
@marclaporte commented on GitHub (Dec 8, 2022):
Related: https://github.com/YunoHost-Apps/cypht_ynh
@marclaporte commented on GitHub (Feb 22, 2023):
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 on GitHub (Oct 7, 2023):
I wonder: Should we invest our time in a web-based installer or improve our Docker package?
@marclaporte commented on GitHub (Feb 12, 2024):
We are working on the docs here: https://github.com/cypht-org/cypht-website/pull/46
@marclaporte commented on GitHub (Dec 18, 2024):
We have massively improved our Docker packaging: https://github.com/cypht-org/cypht-docker/issues/31
@IrAlfred commented on GitHub (Sep 26, 2025):
Due to security concerns related to the web-based installation method for Cypht, which would require a thorough security analysis, and because this is a low-priority issue (as root access is needed regardless), we are closing this for now. The standard installation process for Cypht is already well-documented and simplified on the official website https://cypht.org/install, which covers various contexts including manual installation, Docker, Tiki, and YunoHost.
@marclaporte commented on GitHub (Feb 25, 2026):
@IrAlfred Why is root access needed? Is there not a workaround?
@marclaporte commented on GitHub (Feb 25, 2026):
A user wrote "What I'm getting from this is that, unfortunately, the idea of a lightweight, easy to deploy PHP webmail client is dead, with no like for like alternatives on the horizon?" Source: https://github.com/the-djmaze/snappymail/issues/1911#issuecomment-3960544535
What can we learn from Snappymail?
https://github.com/the-djmaze/snappymail/wiki/Installation-instructions
Looking at the options on https://wikisuite.org/Webmail-and-groupware-comparison, the other active, standalone (and thus that require an installer) and in PHP are Roundcube and Cypht.
Here is the doc for Roundcube, (the most popular PHP webmail):
https://github.com/roundcube/roundcubemail/blob/master/docs/INSTALL.md
Cypht is a great PHP webmail but it's not easy enough to install for traditional shared web hosting.
https://www.cypht.org/install/
I accept that this is low priority as we have better docs, along with Docker and Yunohost installs. But eventually, we should have an easier shared hosting option. So I am re-opening this issue.