Posts by Scott Brown

After my letsEncrypt issue the other day I thought it best to make sure that phpSwitcher was also updated to current version... Unfortunately, while the plugin itself seemed to update properly, the compilation of the php versions and (eventual) install did not.

simply using the command

perl php_compiler.pl

resulted in a failed update of the installed php versions.

When you report an issue for the PhpSwitcher plugin you need give us the following information:

1. Your distribution and its codename
   • i-MSCP 1.5.3 Build: 20180516 Codename: Ennio Morricone
2. The i-MSCP httpd server implementation you're using (Fcgid, FPM)

   
   

   • FPM
3. The PhpSwitcher plugin affected by the problem
   • 5.0.3
4. The PhpSwitcher plugin version from which you're updating (if your're updating)
   • 4.0.3
5. The exact error message
   • I: Cleaning COW directory
     [ERROR] main: An error occurred while executing MAKE(1) target(s) for PHP 5.3.29: /usr/lib/pbuilder/pbuilder-modules: line 487: /var/cache/pbuilder/build/cow.26226/usr/sbin/policy-rc.d: No such file or directory
   
   (see full log below)
6. The PHP version status for which you have a problem
   • version is still available from the panel
7. Whether or not the involved PHP version is a compiled or packaged PHP version
   • Log seems to indicate that it found sources from the previous build
     [INFO] Scanning PHP site for the PHP 5.3 sources...
     [INFO] Found PHP 5.3 sources at http://php.net/distributions/php-5.3.29.tar.gz
     [INFO] The PHP 5.3.29 sources are already present in the /usr/local/src/phpswitcher directory. Skipping download.
     [INFO] Extracting the PHP 5.3.29 archive into /usr/local/src/phpswitcher/php-5.3.29 ...
8. The exact steps (without any assumption) to reproduce the problem

Nothing seems to be interfering with the existing installed versions, so I've left the system as is.

Thanks for the help!

Quote from Nuxwin

Good morning,

Can we access the server to investigate?

I've added your ssh key - will pm you the server name

I received notice today that LE SSL renewals were not occurring, and I noticed the plugin version was out of date - obvious first choice, update the plugin.

However, upon activation, the plugin spat out the error

a quick scan of the code led me to

which when run interactively produced

It seems to want to install a prior version of libssl1.1 -- because when I try and upgrade libssl1.1 it tells me that I'm already running the right version.

attempting to force the install does no good (which is probably a good thing - it would probably break other packages)

It seems to be half installed at this point - there's a Plugin directory at /var/www/imscp/gui/plugins/LetsEncrypt/ and there's the letsencrypt database table (from the old version I'm guessing) but LE doesnt show in any menu, and it's showing an error on the plugin list.

Config info:

Debian GNU/Linux 9.11 (stretch)

i-MSCP 1.5.3 Build: 20180516 Codename: Ennio Morricone

LetsEncrypt 3.5.0 (downloaded today)

PHP 7.1.24-1+0~20181112093455.10+stretch~1.gbp09a4fd (cli) (phpSwitcher 4.0.3 is also installed)

PHP-FPM mode

apt-get upgrade does hold back some packages - but none are (to my knowledge) ssl dependent

The following packages have been kept back:

icu-devtools libapache2-mod-php7.1 libargon2-0 libicu-dev libicu57 libtidy-dev libxml2 libxml2-dev linux-image-amd64 php7.1-cgi php7.1-cli php7.1-common

php7.1-curl php7.1-fpm php7.1-gd php7.1-gmp php7.1-imap php7.1-intl php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql php7.1-opcache php7.1-pspell

php7.1-readline php7.1-soap php7.1-xml php7.1-zip php7.2-cli php7.2-common php7.2-json php7.2-opcache php7.2-readline

0 upgraded, 0 newly installed, 0 to remove and 33 not upgraded.

Dont know if you need this or not, but including it as it's part of the 'standard list of things'

Quote from Nuxwin

We are talking about PHP 4.4, 5.2 here...

I realize that, but simplemind wanted to go even further.... and that would be a problem for me.

As long as you don't drop 5.3 and up, I'm ok... but my whole reason for purchasing phpSwitcher was for a client who needed 5.3 for his app.

One day, he's going to have to do a (painful) upgrade, but for now, its not in the cards.

I do like the idea for SSL management... that will definitely take the pain out of managing certs.

And yes you're right - when I looked back, I was using NuSoap from my ispcp box to query a windows server running WSP I cant find what code I was using to pull stats from the other ipscp box. Might have just been a dump of a data set.... too long ago to keep straight.

Looking forward to new SSL Management functionality in a future release

Quote

You can normally already provide a wildcard SSL certificate. Regarding ability to share an SSL certificate, we need to review our database schema first. Also, I'm waiting for Let's Encrypt wildcard SSL certificate support.

Yes - and I already do add the wildcard certs - multiple times. That's why I've made the suggestion

Wow - I didn't realize Lets Encrypt did an about face on it. Last I read they were dead against it... (I did some work on the Windows SolidCP panel for LetsEncrypt support last year... I've been down that road). Interesting that they decided on DNS validation... they didn't like that idea as that wasn't validating the host the cert was being installed on. Times change I guess.

regarding the db - yes, I didn't think this was going to be the easier part. I'm sure it wont be a simple drop in... maybe store the Wilds off in a separate table, and allow them to be copied into the existing dialogue through a button? I dunno.. just a very simplistic approach.

Would need some way to manage the wildcard certs too. This is getting more complicated.

Ok, while we're complicating things - how about having the panel watch the expiry of certs too, and warn/email customers when their cert is about to expire (configurable by the reseller) i mean, if we're getting complicated, why not go all the way lol...

I'll stop dreaming now - this is your project/product, I'm just a happy user.

Quote

Could you clarifiy a bit?

Just a simple tool to take a wildcard cert and install it across a set of servers in a single action - rather than having to log into each and perform the SSL reconfigure task on each individually.

Obviously it would have to validate that it was indeed being given a cert with a CN=*.domain.tld (is it valid in the subj alt names? - I've only ever seen it in the CN...), and some way to know what other machines to install to (I'm thinking only services and panel only, and only if they already use a matching cert, unless an override flag is given with the request (example use case - to update individual certs on various machines to a single wildcard).

Doesn't sound so simple after all. But useful/time saving for sure. Some of your large clients could save a lot of time with something like this.

I remember back in the ispcp days there was a soap layer exposed - if that still exists that might be leveraged with the proper security (I can't remember if ispcp did a lot of security type validation on it's soap calls). Definitely wouldnt want some nefarious entity to be able to start overwriting your systems. I guess this sort of presumes the clients would be pre-registered with the master so that a proper security context could be created between them.

yes, definitely not on the simple side.

I'm not sure how "multi" the panel is of recent releases so I dont know how much/any of this is already in place, but this would aid in the central management of i-mscp farms.

Let me know if if this help paint the picture better.

There are 2 places which can benefit from enhanced processing of wildcard SSL certs. (having just spent an hour on this due to a cert renewal ... its something I know could be improved...)

During the install, Certificates are asked for twice. IF a wildcard cert is presented in the services dialogues, then the panel question could be preceded with a 'reuse services wildcard cert?" question and save the time re-entering something that is already known.

In the Panel itself, give the ability to enter a wildcard cert for the domain, and when adding SSL for any sub-domains, allow the selection of the wildcard - or the existing functionality. Updating the single instance should (obviously) update all the subdomans that are using it. The time savings and convenience of setting up/maintaining single entries would be a considerable improvement.

A tool to "spray" a new cert out to existing i-mscp installed servers would also be a huge benefit to those with multiple servers.

While not many users are apt to purchase wildcard certs, I know people with multiple servers, and those with multiple subdomains, would find it very useful.

(no rush for me though - I'm good for another year )

I have 2 systems - a test VM and a production VM.

The test VM (debian 7.9, imscp 1.2.9) was done, and followed the steps to shutdown the imscp daemons, and then followed the steps at https://www.rootusers.com/how-…heezy-to-debian-8-jessie/ to upgrade the system.

On my test system, I found that PHP-APC should have been removed prior to the install (I guess I glanced over that in my prep stages)... so I had some flunky errors there, and also found that a minor fix to the apache config, followed by a reinstall of Imscp would get the system up and running again. Not a big deal. It worked. And it has been running fine for a few weeks now.

Today I tried the production VM (also debian 7.9, imscp 1.2.9 - only difference really is in the SSL certs and domain being hosted). The upgrade followed the same steps, and other than pre-removal of PHP-APC was processed the same way. The reinstall returned errors in the upgrade step (which I sort of expected from the apache issue) but even after fixing it, the website failed to come back online after the reinstall of imscp.

So I rolled back the VM to the pre-install snapshot, and began digging. Based on a post here, which had similar issues :

http://i-mscp.net/index.php/Th…Bpurge%2Bapache#post38593

I started again, with the modified update. This time, imscp did not error out - but the (only) website on that machine was returning Error 500.

Clearly, something funky is going on.

Is there a definitive recipe for upgrading an I-Mscp server running on a Wheezy box to Jessie? Trial and error is not a lot of fun, and I want to take the prod VM up and down like a yoyo while I work this out.

Thanks