Problem after upgrade to exim-4.94-1.el7 on CentOS 7 Topic is solved

[layanto]

Is this exim issue fixed in HestiaCP or myVestaCP?

[compiz]

Here is a CentOS Fork: https://github.com/madeITBelgium/vesta

So by running
curl -O https://raw.githubusercontent.com/madeI ... migrate.sh
bash vst-install-rhel-migrate.sh

We will move to your fork? That easy? I am thinking of doing it!
Is there any changelog to see what's what vs vanila vesta?
for example is that exim problem solved in your fork?

[dpeca]

Is this exim issue fixed in HestiaCP or myVestaCP?

Debian has no this issue, so nothing to fix in Hestia and myVesta.
Debian is known for keeping the same version of software and just patching them with security fixes, so it's very rare for Debian that updates brakes something.

[peters]

The issue is caused by the EPEL package exim-4.94-1.el7, any CentOS system that uses the EPEL repo for exim got this issue. On Debian/Ubuntu this issue is not there because they stay on an older version and patch it as dpeca already mentioned. This is quiet a good approach, if you look on paid hosting panels like cPanel or Directadmin they do it the same way and have their own repos to control the process.

[dpeca]

On Debian/Ubuntu this issue is not there because they stay on an older version and patch it, as dpeca already mentioned.

One of the reasons why me and Hestia developers uses Debian/Ubuntu only.

[peters]

I also prefer CentOS, however I think that it doesn´t make sense to fragmentate further and create a Hestia/MyVesta CentOS version. In my opinion it´s already critical that two projects like MyVesta and Hestia beside VestaCP exist instead of putting all effort into one new project. Of course there was a good reason for it, but to be honest I´m not sure which one to choose now if I migrate to Debian/Ubuntu or should I stay on CentOS and migrate to Tjebbes Made IT release.

[edica]

I have the same doubt. The problem that Debian I used a few times.

I also prefer CentOS, however I think that it doesn´t make sense to fragmentate further and create a Hestia/MyVesta CentOS version. In my opinion it´s already critical that two projects like MyVesta and Hestia beside VestaCP exist instead of putting all effort into one new project. Of course there was a good reason for it, but to be honest I´m not sure which one to choose now if I migrate to Debian/Ubuntu or should I stay on CentOS and migrate to Tjebbes Made IT release.

[dpeca]

I also prefer CentOS, however I think that it doesn´t make sense to fragmentate further and create a Hestia/MyVesta CentOS version. In my opinion it´s already critical that two projects like MyVesta and Hestia beside VestaCP exist instead of putting all effort into one new project. Of course there was a good reason for it, but to be honest I´m not sure which one to choose now if I migrate to Debian/Ubuntu or should I stay on CentOS and migrate to Tjebbes Made IT release.

First of all, at the moment when Hestia was born, I already had many servers with my own "quite a lot modified VestaCP" (at that moment fork didn't have a name).
So, it was not easy to port all those features (that I already had) to HestiaCP.
Simply, porting all those features would took too much time.
Plus, it would probably bring bugs... and I didn't want to "play" with production servers of my clients... they are paying me for stable servers.

Secondly, to be honest, reason for staying with my fork is to have total control of code and builds, because I don't want to wake up one morning and realize that 120 servers of my company is down because something went wrong during auto-update of hosting panel.
I know how my servers are configured, and I'm careful with commits.

When someone other is pushing new releases... well... everything can be expected... at least because he don't know if I'm using something specific on my servers.

So, it's subjective reason - specific to me and my company.

I'm not making myVesta to be competition to Vesta, I'm not making myVesta in order to get Vesta users and to have wide reach...
I'm making myVesta primarly for my own company... and because Serghey stopped to make official builds with fixes.
My fork is public just because friends asked me to share it with everyone.

It's comletely your decision what will you use... try all three and see what is working best for your needs.

I will maintain my fork for sure because I'm doing a business with it.
But if you need faster development and many new features - Hestia is better option because they have much more developers.
Of course, rapid development has it's own risks with code stability... but that brings us to the beginning of this post :)


I didn't researched Tjebbes Made IT fork, maybe it's wonderful fork too.

[tjebbeke]

So by running
curl -O https://raw.githubusercontent.com/madeI ... migrate.sh
bash vst-install-rhel-migrate.sh

We will move to your fork? That easy? I am thinking of doing it!
Is there any changelog to see what's what vs vanila vesta?
for example is that exim problem solved in your fork?

I suggest you to first take good backups or snapshot of your server. It is tested, but you never know what goes wrong.

- My fork is completely in sync (or almost) with the official vesta version, I'm only 7 commits behind.
- I added extra features:
-> IPv6 Support
-> Plugin support (beta and in development)
-> Letsencrypt on vesta CP
-> Automated testing at every commit: https://travis-ci.org/madeITBelgium/vesta
Here you can see all issues, features: https://github.com/madeITBelgium/vesta/ ... s%3Aclosed

The original goal of my fork was to test new features (IPv6 Support: https://github.com/serghey-rodin/vesta/pull/1139, Plugin system: https://github.com/serghey-rodin/vesta/issues/1132)
At this moment I have no intention to rebrand or change the vesta core. I only want a clean and easy alternative for the official repo with some important and good new features (IPv6, Plugins, ...), wich I hope will come ever to the official repo.

[dpeca]

The original goal of my fork was to test new features (IPv6 Support: https://github.com/serghey-rodin/vesta/pull/1139

is that pull request outdated?
i mean, did you make new commits about ipv6 after 2017 ?
if yes, should we close this PR?