Replies: 4 comments 7 replies
-
|
You are right in observing that we only provide packages marked as for debian 9 in our repository. This is the same as for the yum repository. Generally speaking these packages marked for older distribution version will work but may encounter trouble sometimes with system dependencies. Did you try the debian-9 package on debian-11 and see if it worked or not? Docs are here for our repositories: https://cfengine.com/cfengine-linux-distros/ There are three alternatives to using the repos: cf-remote, quick install script and download pages. These are the three options we typically use and would recommend. The quick install script uses the packages available on the download page and selects the most recent LTS by default: https://cfengine.com/downloads/quick-install/ Here are the download pages for https://cfengine.com/downloads/cfengine-community/ and enterprise https://cfengine.com/downloads/cfengine-enterprise/ As for the upgrade path that's a bit unavoidable as many distributions will package our latest release regardless of LTS status and so then only the version number comparison is in effect. Hope that clears things up a bit. Let us know how we can help. |
Beta Was this translation helpful? Give feedback.
-
|
The quickinstall script only works with enterprise packages unfortunately. The reason Debian 11 packages aren't in the repository is only for lack of time and resources. We have an internal ticket waiting for attention in this regard. If a community member was interested in putting in some effort that would be appreciated. We wrote cf-remote in Python because it is a developer tool and so benefits from the higher level language available in Python. We primarily use it from one host via ssh credentials but other parts of CFEngine can benefit from Python as well such as custom promise modules and packages modules. You can easily install community with cf-remote with an optional argument: Which will by default install the LTS, currently 3.21.4. Most of our marketing efforts are done by developers like me and are focused on showing folks generally how CFEngine works, not specifically enterprise or community. :) Enterprise is free for 25 hosts so hobbyists and learners can easily get started that way. Hopefully we can get our repositories fixed up with the latest versions and for currently supported versions of distributions soon. |
Beta Was this translation helpful? Give feedback.
-
|
@craigcomstock Thanks for the answer, that helps a lot. :-) As tempting as it might be to try to put the effort in you mentioned I don't know if I'm up to the task. When asking on what'd required the answers might take so much time that doing it yourself might be quicker 😆. |
Beta Was this translation helpful? Give feedback.
-
|
@MasinAD Everything Craig wrote is correct, but I can perhaps add a bit more context;
I wrote the initial version of We've always provided packages for download on our website. (rpms, debs, msis, etc.). Downloading and installing them is still easy, and relatively common. Or putting them in your own repo server is another common approach. I'd consider all of this quite normal / standard ways of installing CFEngine among our users. On top of this, we have a quick install script. It basically allows you to copy a bash one-liner, and it will find and install the appropriate package for your host. From a user's perspective, it works well, at least for one or two hosts, but it doesn't really help you if you want something more (older version, more hosts, community instead of enterprise, etc.). From our perspective, it's always been kind of a maintenance burden, we have to update this script for every release, fix issues with platform detection, etc. It's not something we really want to expand, but we do see that our users find it valuable, so we've kept it around. Years ago, whenever I was manually testing new versions of CFEngine or even just an arbitrary package with my new features in it, my workflow could look like this:
If you think that sounds tedious, we agree. I started putting all of those things into a script which eventually became https://github.com/cfengine/core/blob/master/docs/cf_remote_demo.sh I use that script relatively often to spawn 6 different machines and install CFEngine nightly packages. It's also really easy to update if I want to also deploy some policy, or install a different version (like 3.18, or community). Over time, we've added more nice functionality to cf-remote. If you're interested in what you can do with it, see: https://cfengine.com/blog/2024/feature-friday-4-cf-remote/ https://pypi.org/project/cf-remote/ So, that leaves us with 4 ways of installing CFEngine:
Each of these has its advantages and disadvantages. If you don't want to use python / python tools, then
Also, keep in mind what platforms and installers we currently support;
So, all of this takes time to maintain and support, and helps explain the desire for a tool like
As Craig said, it's just a matter of time and resources. There is no separate team for Enterprise or anything like that. It's one team working on both CFEngine Community and Enterprise, and as Craig pointed out, we are here communicating with you, and you can go to our blog and see blog posts from the same people, etc. Paying customers can request features or platforms to be supported, or pay extra for us to provide support for something, and we do naturally prioritize that, but that's really it, there's no hidden agenda.
As Craig said, we have the oldest supported version there in the hope that it will also work on newer versions. If you, or anyone else, would like to help by maintaining some of these package repos (apt, yum, brew, arch, etc.) we'd applaud it, and be happy to collaborate with you. Hopefully that longer explanation and history makes sense, let me know if you have any other questions :) |
Beta Was this translation helpful? Give feedback.
-
|
@olehermanse Wow! Thanks for this exhausting explanation. I didn't get it right with Reasons, of course, I intend to completely ignore 😆 . Regarding the repo: I don't know if I'll find the time to look into it. I have a little bit of experience hosting a pacman repository and almost none of it hosting the others. But it sounds like something I could do with a little research. No promises, though. |
Beta Was this translation helpful? Give feedback.
-
|
Id just chime in that for upgrading hosts regularly, you could automate the seeding of the necessary binaries on the hub and use the standalone_self_upgrade.cf policy which is triggered when the class That all defaults to enterprise stuff, but you can override variables and have it work with community binaries. |
Beta Was this translation helpful? Give feedback.
-
|
To support @craigcomstock I also use the |
Beta Was this translation helpful? Give feedback.
-
|
I had a similar idea but I didn't want to mention it as long as I didn't know if there was some commercial interest in play. I think I'll go with that route, too. |
Beta Was this translation helpful? Give feedback.
-
|
@MasinAD @basvandervlies thanks for the questions and comments. Sounds like this is somewhat resolved for now so I will close. I have created https://northerntech.atlassian.net/browse/CFE-4392 to track any updates on this issue. Feel free to watch that ticket for updates. |
Beta Was this translation helpful? Give feedback.
-
|
Automating the upgrade of the agent is very useful at scale where it's
impractical to upgrade the agent manually.
Make sure you test it first -- I find a phased approach helpful to reduce
risk of breakage (e.g, 1%, 5%, 10%, 100%).
…On Thu, May 23, 2024 at 2:51 PM Nick Anderson ***@***.***> wrote:
Id just chime in that for upgrading hosts regularly, you could automate
the seeding of the necessary binaries on the hub and use the
standalone_self_upgrade.cf policy which is triggered when the class
default:trigger_upgrade is defined.
That all defaults to enterprise stuff, but you can override variables and
have it work with community binaries.
—
Reply to this email directly, view it on GitHub
<#5506 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD4GIG3FFWFA3YFXIKKYKLZDZQFHAVCNFSM6AAAAABHQTA72GVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKNBQGEZDM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Achieve real learning. Email ***@***.***
|
Beta Was this translation helpful? Give feedback.
-
apt selects the wrong package on Debian 11:
After removing the package and installing the downloaded .deb file from the downloads page:
So, the package for Debian 11 is clearly there. Some further experimentation:
Checking the list file:
There no packages for Debian 10, 11 or 12. I'd say whatever generates those files hasn't been updated to reflect packages for those Debian versions.
Another thing I noticed is that installing the LTS version 3.18.7 from the .deb file still leads to apt suggesting an upgrade to the non-LTS version 3.23.0:
Beta Was this translation helpful? Give feedback.
All reactions