What is the correct way to install specific hestia release version?

Community Support
1

I assume I download/wget/etc. and extract the archive from Releases · hestiacp/hestiacp · GitHub and run the local install file.

Will this work completely as expected i.e. install only that version and not cross-mix versions by pulling some hestia code from github or other sources? Any issues with this approach?

I ask because I poked around in the code and there are a few direct references/checks to github and hestiacp.com like:

https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install-$type.sh

release_branch_ver=$(curl -s https://raw.githubusercontent.com/hestiacp/hestiacp/release/src/deb/hestia/control | grep "Version:" | awk '{print $2}')

RHOST='apt.hestiacp.com'

The purpose of my question is:

I don’t see a default way to install a specific hestia version. IMO: Having a stable versions and stable inter-relationships of all applications and their dependencies to install for production environments in critical.

One of the first things I did with Hestia is turned off auto-update, so I can test new versions on a development server before deploying into production, lest the new updated hestia version breaks something (which I regularly see folks having issues with).

Plus the fact that hestia requires specific stable versions of everything from the OS on down so it would make sense to treat hestia in the same way.

2

You can’t install any version from the release branch. As it will always take the latest version.

Also al lot of changes will be made so with older versions it might create conflicts…

1 Like
3

thanks for your reply @eris

Per my post, not trying install from the release branch

download/wget/etc. ARCHIVE i.e. zip/tar.gz from

https://github.com/hestiacp/hestiacp/releases/

4

We don’t provide the packages prebuild on any other means except via apt…

5

Thanks for your reply @eris.

I don’t actually know the ins and outs of how you do our system and it sounds like my main point is getting missed.

Topic title:

Correct way to install specific hestia release version?

I need to be able to install specific version releases…

which you provide in the form of zip/tar.gz at:

https://github.com/hestiacp/hestiacp/releases/

It sounds like

Will not work.

So… Can you please let me know the:

Correct way to install specific hestia release version?

Thanks!

6

You don’t. You install the current version.

What is your actual objective that has you so focused on installing an obsolete version of HestiaCP? Are you trying plan an upgrade between specific release versions via a lab simulation? You would be better off working on cloned disk images than trying to recreate a passed moment in time.

7

Thanks for you reply @linkp

The answer to your question was in my initial post:

8

I read it again, and it still makes no sense. There is zero reason to not automatically upgrade HestiaCP as soon as the release is published in the repo.

Your quest to do otherwise makes no sense whatsoever.

9

Thanks for your reply @linkp

It sounds like you are not understanding what I am intending to communicate.

There actually is one giant reason not to do that:

SO YOU DON’T BREAK YOUR PRODUCTION ENVIRONMENT.

The only thing that me (and I’d guess most people/organizations using their systems professionally) auto update are critical security updates…

SO YOU DON’T BREAK YOUR PRODUCTION ENVIRONMENT.

I’ve only been using hestia for a few months but I regularly see folks reporting that an upgrade or auto update breaks their production environment.

If I’m understanding you right, I would flip your question on it’s head and say:

I have no idea why versioning is not supported by hestia, especially since hestia REQUIRES that everything else it uses be a stable version from the OS on down. It seems very unprofessional, especially since hestia says it is professional tool for professionals.

There is a reason why hestia supports Ubuntu 22.04 LTS so it can reliably build/test against a set of stable version of applications/tools. To put it another way: We are not auto-updating to the latest Ubuntu version…

SO YOU DON’T BREAK YOUR PRODUCTION ENVIRONMENT.

While I already do create cloned disk images, having no way to create and test a system from scratch with specific versions that I know will work because the only link in the chain that doesn’t support that is hestia is a workaround/hack. Which is why I asked my question.

I want to move my servers to new versions only after I have done development testing using stable versions of ALL applications/tools. And to do this professionally, without awork around/hack I need to be able to install the specific version of hestia that works for my infrastructure at the time.

I shift my infrastructure at regular intervals to more updated versions only after development testing, and nothing gets auto-updated except critical security patches. Most organizations do this.

SO YOU DON’T BREAK YOUR PRODUCTION ENVIRONMENT.

10

In eclvery case here they broke their HestiaCP becuase they overwrote their modified config file with stock templates from the OS.

Every single time, it is user error, not HestiaCP that breaks the production environment.

I manage to not break my production environments by not aimlessly overwriting modified running configurations. If you can manage that, you’ll be light years ahead of everyone who has ever posted here trying to blame updates for their own lack of experience.

Good luck on your mission, even if I don’t agree with its value.

11

Thanks for your reply @linkp

It sounds like you are wanting to express your opinion and are also not happy with folks who don’t know how to use hestia fully and are talking about something other than I am talking about.

Professional systems aren’t auto-updated (except critical security) and versioning is available for testing/development. Among many things, I’m glad this is the case for air traffic control systems and banking systems.

I’m building a professional infrastructure with open source tools and I like most things about hestia. But simply trying to get answer to my question:

What is the correct way to install specific hestia release version?

Given there are actual versioned releases on github, I’m assuming there is a way to do that, even if I have to write some new code to support it, figure out how to create apt packages or whatever. That’s fine. I understand from past experience in this community that I’m unlikely to change anyone’s mind. I’m still committed to using hestia because it is the best (actually) open source tool I’ve found.

I am hoping to get enough bones from @eris to understand how to make versioning work without hacking, and I know full well my solution is not likely to be included in the repo.

12

Have you looked into apt-pinning?

13

I hadn’t heard of it until you mentioned it. I looked it up. It sounds useful in certain situations, but I’m not sure how it applies to this one.

Given that Ubuntu 22.04 LTS is the OS needed for hestia, when set to security updates only, all the versions stay stable. Hestia is the only wildcard here. Because installing 22.04 LTS with a specific hestia version will give me the same dependable infrastructure right now or next year.

Am I missing something with apt pinning?

14

It won’t work as we have 1 rolling release we don’t have the time to maintain an additional 4 to 6 extra releases…

And It would be to expensive for us to maintain…

We have patched many security bugs in the last and w useally do it in the last release only…

With an few exceptions where some EOL Os was EOL a few weeks before…

15

Thanks for your reply @eris.

My question was pretty straight forward and keeps getting side tracked. I never asked about security maintenance of past releases. I know you aren’t going to do it.

What is the correct way to install a specific version of hestia?

Please just give me some basic information so I can figure out how to get started and I can do it for my professional development/testing purposes. I’m sure you know how it can be done.

Thanks!

16

Build the packages your self…

1 Like
17

For those who might find it useful in the future, skip all the nonsense in this thread. The direct answer via @eris and me:

Use the instructions at to build the version of the package you want:

https://hestiacp.com/docs/contributing/building.html#installing-hestia-from-a-branch

Default instructions will clone the main branch

IMPORTANT! MISSING FROM DOCUMENTATION: then checkout the tag of the version you want:

git checkout tags/1.8.8

And the rest of the instructions will work to install hestia from your local compiled package.

18

Hello,

I can understand all your statements 100%. I also wondered whether and how it is possible to install an older version if the latest one is faulty. I thought you could specify it in the hst-install-ubuntu.sh at the line: “# Define software versions
HESTIA_INSTALL_VER=‘1.7.7’”

But I have never tried this.

Also have a look at https://myvestacp.com/. Focused on security and stability, with a lot of security improvements.

best regards

20

MyVesta is a totally different version then Hestia…

Also
HESTIA_INSTALL_VER=‘1.7.7’”

Won’t really work as the installer is also version depended… So a 1.7.x will not be compatible with 1.8.x version …

1 Like
21

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.