Future OS Compatibility

[outrolled]

As Vesta is back in active development, we need to identify if it is worth focusing on multiple Linux flavors, or if we should focus on a single one that gets better support and documentation. What would be your preference?
As the new maintainers, we believe that focusing on a single OS such as Ubuntu will enable us to provide a better and more stable product, however the community input is important to drive our roadmap.

[anton-reutov]

I agree with you. I think we need to focus on Ubuntu/Debian

[Skamasle]

I think almalinux is better choise a8 has support until 2029 Just support one system is easy. El lun, 26 feb 2024 15:09, Anton Reutov ***@***.***> escribió:

…

I agree with you. I think we need to focus on Ubuntu/Debian — Reply to this email directly, view it on GitHub <#2296 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEVO5PF2VYT64A7EASJ4RDYVSJQVAVCNFSM6AAAAABDZNGQQKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOJTGA3DS> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[justanthonylee]

Thats a bad choice, Alma has 0.1% web server percent of the market and Ubuntu is over 10%. Would be silly to limit to a system that’s so small.

[outrolled]

I agree with anthonyrossbach, Alma is a good CentOS replacement, but it is too niche when compared to other distros. If we use an OS that is not easily available on VPS providers and other cloud vendors, it will limit the benefit that Vesta can offer to the community.

[Skamasle]

Yes but alma es new system yet, and if choise alma is easy to support all others rpm based system, vz8, rocky8 most of people who used CentOS 7 prefer rpm based system, and they will migrate in June of this year. And if the choise is debian and Ubuntu what will be the difference with hestiacp ? Very similar panels, with very similar features , support same systems, and exclude all users who want rpm systems. And why not support rpm systems also, is easiest support almalinux8 until 2029 and 9 than multiple debian and Ubuntu lts each few years. Vesta always focus better support to centOS El lun, 26 feb 2024 16:41, Anthony Lee ***@***.***> escribió:

…

Thats a bad choice, Alma has 0.1% web server percent of the market and Ubuntu is over 10%. Would be silly to limit to a system that’s so small. — Reply to this email directly, view it on GitHub <#2296 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEVO5JFJ4V7DHMNOXKMLITYVSUKFAVCNFSM6AAAAABDZNGQQKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOJUGI2DC> . You are receiving this because you commented.Message ID: ***@***.***>

[insound]

Sounds like a sharm. Definition between rhel based and debian im the most way is installer. Then only ways and several configs. We should continue developing in both ways, but rhelbased must have.

[outrolled]

I understand a lot of sysadmins prefer RHEL, but what would be the advantages of maintaining RHEL compatibility? Would you have any company policies that stop you from using DEB? I think that if a considerable amount of users are required to use RHEL based distros, it would make a better case to maintain both. I had some very negative experiences dealing with RHEL licensing in the past, so I may be a bit biased.
I think that going a similar path to HestiaCP is not an issue, as they are a fork from Vesta, we could get a more homogeneous ecosystem where end users benefit from.

[Stage4000]

Remember, this is an open source project that they left abandoned in a broken state for 4 years. If you're on an apt system, use Hestia. Also, saying Hestia is just a fork from Vesta isn't exactly fair, since they actually focus on security and they have maintained their code consistently. I don't agree that having the Vesta team working on apt systems would benefit anyone, it will stretch their team and resources even thinner when there is already a BETTER option out there. I don't use RHEL either, so I don't really have an opinion on that, but at least it would be a better use of their time.

[insound]

I guess will be better focus on all rhel based 8 and maybe 9 in future distributives like roky linux 8, alma linux 8, oracle linux etc.

[outrolled]

I'm the new maintainer, thank you so much for adding your opinion here. My personal preference is to focus on a widely popular OS that we can focus on fully supporting. Another factor to consider is the future roadmap - I am keen to add CI/CD and container management to Vesta, so things can start to diverge between different Linux flavors depending on the direction we go. For example, I am a fan of Linux Containers (LXC) and it works out of the box in Ubuntu quite beautifully.
So far, I think that investing on Debian flavors with a focus on Ubuntu (e.g. you can run it on any Debian distro but official support is only Ubuntu) would give us the right balance of focus and stability.
I have also created a twitter poll where we got more results so far: https://twitter.com/vestacp/status/1761949825183236257

[AlecRust]

Don't take this the wrong way, I may be missing something, but why maintain Vesta? Especially if you want to drop support for non-Ubuntu installs.

Hestia is very similar, with considerably less tech debt and more maintenance activity.

Just feels like it's duplicate work. We would very much appreciate your contributions over on Hestia..

[outrolled]

@AlecRust you have a valid point, and I agree there is a lot of duplicate work, but we control Vesta's vision and direction in the long term, and I expect to start having different features that would not necessarily make their way into Hestia. Let's say we double down on container orchestration, but Hestia decides to focus only on LAMP - if this type of thing happens, the community will have more options, so its a win-win long term.
I am also investing on bringing a full-time maintainer to Vesta - this will allow us to refactor a lot of the project, and improve the capacity to push and review code. The core product will always be GPL, however my goal is to have paid plugins or add on features (let's say a billing management system for hosting companies like WHMCS) where we would use the proceeds to reinvest in Vesta.
I been a fan of Vesta for so many years, it deserves a bit of love once again.

[artscripts]

Long-suffering Vesta, I’m glad that finally, someone will take charge and continue to develop an excellent panel. Regarding the choice of the OS on which to further develop the panel, I have two feelings. On the one hand, I understand that developing the panel only for Debian or any other system will make the work of programmers easier. But if we take into account all the people who used Vesta, who installed them on all kinds of OSes and really waited and are waiting for the update of this panel, it will be a little disappointing, we will find ourselves out of work.

[outrolled]

That is a great point @artscripts - I am thinking about releasing at least 1 more RHEL compatible update to get all the CentOS people a longer security runway. If the community can contribute with a RHEL compatible option, I would fully support.
I think that maybe we can have a core OS/Flavour that we provide really good coverage/updates etc, but we could have other OS flavors that can be community supported.
I am trying to balance getting Vesta back in top shape, with spreading ourselves too thin with the current funding I can invest.

[outrolled]

Adding the X (Twitter) vote for reference as well. https://x.com/vestacp/status/1761949825183236257?s=20

[comfuzio]

Thanks for your work guys!
I have voted on ubuntu since this seems a good distro to built upon and I am more familiar with it ever since I left my CentOS at version 8.
I would like to suggest maybe a dockerized version of vesta.
I was running for long time my wordpress sites via docker compose in the portainer's gui. It was fast and easy but it used way too much ram compared to having a web server, so I have switched to myvestacp. I believe you can make a dockerized version of vesta which in turn will be able to run on any host running docker.
Also on the same note IF you do a dockerized version, please give the option to choose what we want to install or not because I have moved my mail server to mailcow (again dockerized) and I am not switching back to the mail server of the panels

[t4ba]

Vote for debian

[thunder-esc]

Hi, when I saw the banner that vesta will be updated/maintained again I was so happy, then I arrived here and it seems that the new developer is only interested in Ubuntu maybe Debian all the joy went out the window. There are a few Vesta forks actively supported for Ubuntu and Debian but nothing for RHEL. So, I guess is indeed that time to completely forget about Vesta. Goodbye good old friend!

@outrolled -> Good luck with the new project!

[outrolled]

@thunder-esc I haven't written clearly here, but we decided to build Vesta 2.0 with Go (Golang) and LXC (Linux Containers) to have the broadest OS support. As long as your OS supports lxc, you will be able to run Vesta. Ubuntu will be the main supported version, but we are aiming to allow it to run on almost any Linux flavor (including RHEL), and on different architectures like ARM.

[DeRaja]

@outrolled
I refer to your comment as below:

I haven't written clearly here, but we decided to build Vesta 2.0 with Go (Golang) and LXC (Linux Containers)

One of the most stricking feature of Vesta has been a tight integration of bash scripts. There are not many panels existing with such an integration.

At the time, when Vesta died, or let's say today when it began to sleep (until it wakes up!), I made a comparitive analysis of other panels. There are a couple of them, which I had considered. Hestia was a clear winner above all. It was based on Ubuntu. Having an experience on Linux for 27 years, it didn't pinch me at all to work on Ubuntu. I merely had to modify some of my bash scripts, which had a with minimum impact. But I gained a stable panel, well maintained by a group of enthustiatic youngsters.

Bash integration is one of the most important and interesting feature of Vesta. This has been - for god's sake - carried forward in Hestia. It was indeed a great thing that this enthustiatic youngsters did not dream of aborting this greatest feature inbibed in it's very core at the time of creating a continuum or parallel on a new system.

Using Golang is your narrow perception because you can, or may enthustiastically want to code. Should others, who worked and are willing to work further, should now learn Golang too?

Many administrators will stick with their panel and will not be willing to move to the new face of "Vesta with Golang" because the central technology of bash - and it's extra-ordinary ease of use - will be missing. If you do not want to beleive my future prediction, try this out.

Restructering and refractoring "Vesta with Golang", you will ruin the minimum possibility to bring "Vesta with bash" back to life.

[outrolled]

@DeRaja thank you for your input. We are trying to balance everyone's input and the needs of the community with a more modern approach on how we build Vesta. Our goal is to enable containerization, and for Vesta to run on almost any Linux Distribution without a lot of maintenance work required from our end.

We are working on containers that will come with editable recipes (using Cloud Init) - each recipe includes everything to run a website (or service) inside a container, so there is nothing stopping "recipes" using Bash to configure nginx, apache, php, virtualhosts, etc inside this container - this will enable almost any OS/Container/Stack to work inside Vesta, and for people to develop and share those recipes that work best for their preferred stack/language etc. The goal here is that you could take a RHEL recipe and adjust it for your needs, without having to change the code for vesta itself (vesta would handle SSL provisioning, virtual hosts, deployment builds, backups etc).
I think that once we complete the release candidate, you will be able to see how this could make it easier to manage your preferred stack - and we will also open up the recipes for community to contribute with their preferred stack.

If we completely miss the mark with this approach for your use case, I am happy that there are actively maintained forks that are doing a good job in keeping the legacy architecture moving forward and that they will continue free to use under GPLv3.

I hope that you can give the new version of Vesta a go once we complete the new release candidate, and to contribute Bash based recipes for setting up and managing specific stacks.

[DeRaja]

@outrolled!

Thanks for your reaction.

It took a lot of effort to change to Hestia from Vesta. This dead state had put my non-commercial activities to a complete halt.

Further, using scripts of other enthusiastic youngsters is anathor challenge because decisions are made that - in many cases - do not match with many others in the community. This isn't a shocking thing when using an open source. For example, now you come up with your fantacy of container based develpment activity. It's life is predictable only until your activities (including a small group) remain live.

As a result, I beleive in a principle, what is working, let is remain as it works. I am not plannig to implement any further changes in the next five to ten years (I have to finish certain non-commercial projects, which are - as of today half cooked). Thus, I am also not looking for advices from anyone on next steps after the revival of Vesta, in whatever the form it may be, and am not planning to contribute in any form due to zero availability of time.

I just wanted to share my views, however strange or rigid they may look like (from view point of others), which is also a contribution.

[outrolled]

@DeRaja a contribution is a contribution, thanks for the feedback!

[pdapnz]

Hi, will Vesta 1.0 be open to accepting pull requests with bug fixes with subsequent releases of official updates?

[outrolled]

@pdapnz we are calling the next version of Vesta 2.0 to make it less confusing given a 1.0 candidate existed in the past. Yes, the new version will continue to be open source and we will encourage community contributions.

[DeRaja]

Hello Everyone!

This question has its source in the very basic and fundamentally flawed decisions, which I had objected during the times before 5-6 years during its active development. So let me reformulate your question for a debate:

Can we modify the current version to seperate the code between the logic of Vesta and the OS commands related logic? The answer to this question should be yes.

In fact, I had modified the installer and had developed multiple bash scripts to install on Centos as well as on Ubuntu. At that time, Vesta suddenly died.

In my conceptual design, I had two main dir /system and /sh. I could seperate the code of detection of the OS. Once that happens, all commands related to that OS will be used. They are not hundreds. One can make it. One can start with a mini project and thereafter expand slowly on different functions. Only then one can identify different nature of reactions (or output logic) of different packages on different OS.

For example, start with a small and simple installation of one service, let us say email. Work on OS detection, install the same package on two or three systems and study where certain changes should be made and how these commands can be loaded differently.

In addition, one can develop the installer, which I did, such that every service and configuration is modular. Only then my suggestion above works. Such a generic modular design also helps at a later date for re-installing as well as changing service package occilating between for e.g. Apache and Apache+Nginx, etc. after an install.

As vesta was never developed modular, this drawback is technically flawed design exists as well as is happily accepted by all young coders of Hestia. No one ever gave a thought to redesign this aspect and were only interested to continue development in their own interest based on the ready made and existing concept.

There can be a command converter too, which can work as input command and having an alias.for that specific OS related output command.

Because the development of Vesta never ever took place from a GENERIC POINT OF DESIGN, such a logic was never considered.

Thus your question has an inherent logic of limitation and does not trigger an accomodaction of infinite OS or better said a generic logic.