Vesta Control Panel - Forum

Seems somehow the problem is to do with upgrading from Ubuntu 16 to 18. It does actually work now on a fresh install of 18 (although it didn't for a long time). Would a fresh install be an option for you?

Hey I upgraded from 18.04 and not from 16.
According to vestaCP website it's not compatible with 18.10.1 yet.

I could do a full backup and reinstall everything, I did the update because wordpress is now compatible with php 7.3 and speeds up the websites by 9%.

I'll see maybe i'll just wait and use Vesta as CLI I was able to do the Backup that way so i can probably create new sites that way too.

I'll contact VestaCP about the issue and ask them if there is a patch coming out soon to support 18.10.1.

vesta is not compatible with 18.10, but we have a plans to support it after 0.9.8-24

Do you have an ETA on that, Is there a quick fix or workaround for now ?

Oh, right, so it installed OK On 18.04, but you upgraded to 18.10 to get PHP 7.3? Well you know, its pretty easy to bump PHP up to 7.3 on an existing install. In retrospect that probably would have been an easier path! :-)
For the record, it goes something like this

I will try this on a test server since the other one is a live server. :(
Should of done this the other way around lol.

imperio wrote: ↑

Fri Mar 22, 2019 3:12 pm

vesta is not compatible with 18.10, but we have a plans to support it after 0.9.8-24

Did the update and I still cannot conect to the admin panel. Did you guys do the switch from libcurl3 to 4 yet ?

p4r4norm4l wrote: ↑

Wed Apr 17, 2019 8:25 pm

imperio wrote: ↑

Fri Mar 22, 2019 3:12 pm

vesta is not compatible with 18.10, but we have a plans to support it after 0.9.8-24

Did the update and I still cannot conect to the admin panel. Did you guys do the switch from libcurl3 to 4 yet ?

Can you write more about this problem?

found a workaround by copying /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0 from another working system and modifying the init script by adding LD_PRELOAD before starting command:

start_nginx() {
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0 start-stop-daemon --start --quiet --pidfile $NGINX_PID \
--retry 5 --exec $NGINX_DAEMON --oknodo
}

start_php() {
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0 start-stop-daemon --start --quiet --pidfile $PHP_PID \
--retry 5 --exec $PHP_DAEMON --oknodo
}

stop_nginx() {
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0 start-stop-daemon --stop --quiet --pidfile $NGINX_PID \
--retry 5 --oknodo --exec $NGINX_DAEMON
}

stop_php() {
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0 start-stop-daemon --stop --quiet --pidfile $PHP_PID \
--retry 5 --oknodo --exec $PHP_DAEMON
}


So far I succeded to have the backend functional again, the cron jobs using the new curl (4.5.0) are working and everything seems to be ok.

Given that Ubuntu 16.04/18.04 uses systemd, you can also overrule the environment by creating a service config:
Add to the new config file:
Don't forget to update the daemon:
And restart the service: