Posts by anarking

Hey folks,

I didn't really feel like going through phpSwitcher plugin, so I went from PHP 7.1 to 7.4, and made a few modifications to imscp that allowed `--reconfigure php` to finish successfully, and so far, the panel, all sites, backups, and other daemon operations, etc., appear to be working properly on 7.4.21 (with ionCube loader, as well).

Side note: it is now under mpm_prefork instead of mpm_event. It could surely be done with any other, as well.

I do not have phpSwitcher plugin, so I have not tested phpSwitcher compatibility with a change to the base PHP, however, from the lines I saw that were holding up PHP 7.4, I don't believe it should be an issue.

If anyone cares, I can share the changes to imscp.conf, /var/www/imscp/engine/PerlLib/iMSCP/Requirements.pm, and /var/www/imscp/engine/PerlLib/Servers/httpd/apache_php_fpm/installer.pm

Not sure it's worth making a PR to github, as I'm sure there's more testing needed, and all of fluser's nice PRs are going ignored, so *shrug*

that's pretty extraneous, and definitely not a default. but could be a cool plug-in! get coding

I upgraded from 12.04 to 14.04.1 with i-mscp 1.1.13 just fine. the big thing that made it go smoothly, i believe, was to allow Ubuntu setup to replace all config files with Ubuntu defaults again.

After the Ubuntu install was done, I ran i-mscp autoinstall again, and everything was great. The PHP Switcher plugin came in very handy for any sites that had PHP5.5 incompatibilities.

I have a Varnish How-To in another section. It will need updating after the soon-to-be change of the admin panel port, but works. You need a good working knowledge of Varnish to implement it successfully.

I don't know how to turn it into a plug-in yet

Also what makes it difficult for having i-MSCP controlling any aspect of it are the custom .vcl settings necessary per domain, but is possible with a big chunk of work.

That would probably be the initial implementation, just having a basic configuration of caching, and being able to add a domain. Later on, add feature of clients being able to control custom vcl files.

Backup system revamp I think is more important than this for now.

well said.

@MasterTH check probably the master.vcl file, perhaps you forgot to replace "somedomain.com" and "anotherdomain.com" etc. with your domain(s). that is just an example file. you need an entry for any domain you want handled (or not handled).

i meant back-end just as everything imscp controls for hosting, and panel as front to it, but okay sticking to correct nomenclature of back-end just as imscp daemon.

okay i'm coming around, but as with plesk and like someone else mentioned, maybe best not to tie up nginx entirely with it, though sounds like you have some plans already here.

i will either reverse proxy to the panel, or most likely have a second IP for it. I think a dedicated IP option and staying port 80 and 443 is an important option, and will be a common configuration. that and/or making it a separate server entirely (nice small, isolated central panel server). you probably already have thought of that for longer term goal though, i bet.

either/any way, great work

Awesome! But I really think we should use duplicity. I mean, it's done by the rdiff guys and uses rdiffdir for part of it, just is better all-around.

http://duplicity.nongnu.org/
"All the code here is GPLed (free software). Duplicity is also part of the Fedora,Debian, and Ubuntu distributions of GNU/Linux."

rdiff has shortcomings and isn't efficient with compression. duplicity will also allow people to restore to certain times or fetch a full backup of a certain time, and we can easily set retention time by reseller/customer/hosting package. everything compressed, using rsync for minimal processing.

since I moved to Germany I lost all my other hobbies, so I have time and can help, Nux.

I'm late to the discussion...

I hope this does not mean that the panel must now default to a different port. Everyone will then have to setup something to redirect users. No user will ever remember to put :8080 or the like, and that is ugly. This is kind of backwards. Panel should be port 80 and running on the front reverse-proxy to all sites, despite the extra server load.

If this is a necessary step to the end goal of making i-mscp truly multi-server, in that the front-end will eventually communicate to back-end servers via CLI, then I am all for it

I think it is a bad idea to have the panel on a different port. If anything, then nginx must become the reverse-proxy for everything to keep the control panel on port 80, and the rest sit behind on Apache. This will make any Varnish setup very difficult, but so be it.

But in this case, it really should be architected like so, I believe...

Option 1: Single-server: Control Panel + Back-end - Control Panel runs Nginx, the back-end as usual on Apache.
Option 2: Multi-server A: Control Panel + Back-end - Control Panel runs Nginx, and can communite with local back-end and other servers on Apache.
Option 3: Multi-server B: Control panel standalone - Control Panel runs Nginx. communicates with Back-End on other servers.

For Option 2 & 3: Back-end standalones with Apache only, to be controled by master control panel, for option 2 and 3.

Unless this is the eventual plan for such a move, no one will really care if the control panel is up but the websites are down : / Only to grab their files and run away.

If the plan gets closer to multi-server, YAY!

I've run into this, where it didn't create the NameVirtualHost entry (entries if with SSL for IP:80 and 443) in /etc/apache2/sites-available/00_nameserver.conf

Make those two lines at the bottom of the conf file and it should figure it out correctly.

i'm using my own tutorial to make sure i get all the little pieces haha. will also check and make sure nothing has changed with it for latest git master.