Hi there,
From where i can download all the versions for sensu core? (Centos,Ubuntu,Windows,MAC,debian etc…)
why it’s removed from the website?
our company and a lot of other companys using the open source core version.
can you please share a link to download the latest version?
thanks.
Hey!
Sorry about that, it looks like we inadvertently lost the Download links when we transitioned to the new website. I don’t think we realized that the Sensu Core documentation was referencing links on the main Sensu site in some case, and not just using the repositories.sensuapp.org links.
Here are the links to the directory structures containing the Sensu Core packages for each of the supported platforms.
For everyone reading this, please note Sensu Core becomes EOL December 31 2019.
OSX:
http://repositories.sensuapp.org/osx/
Windows:
https://repositories.sensuapp.org/msi/
Freebsd:
http://repositories.sensuapp.org/freebsd/
AIX:
http://repositories.sensuapp.org/aix/
Solaris 10:
http://repositories.sensuapp.org/solaris/pkg/
Solaris 11:
http://repositories.sensuapp.org/solaris/ips/
Yum (RedHat,Centos etc…):
These instructions should still work:
https://docs.sensu.io/sensu-core/1.8/platforms/sensu-on-rhel-centos/#install-sensu-core-repository
And you should be able to find the rpm packages in this directory tree:
http://repositories.sensuapp.org/yum/
Apt (Debian, Ubuntu etc…):
These instructions should still work:
https://docs.sensu.io/sensu-core/1.8/platforms/sensu-on-ubuntu-debian/#install-sensu-core-repository
And you should be able to find the dpkg packages in this directory tree:
http://repositories.sensuapp.org/apt/pool/
thanks for this @jspaleta !
one question, next year do will still have the option to install plugins from git and the reops will still stay online?
we really need them!
waiting for your comment.
@jspaleta it’s critical to leave the all repo and website available for download and install after EOD.
Please confirm.
a lot of companies are still using sensu core.
Hey,
I fully expect the Sensu Core repository to remain available for some time after EOL to give the community a chance to fork it and maintain it with community resources. I expect binary package downloads to be disabled soon after EOL
We may need to have a discussion about how stewardship of the Sensu Core codebase transitions without causing undue confusion. Because the codebase is MIT licensed, the external community could take over maintainership of the codebase in a forked repository at any point, but there some additional considerations that require some transition discussion. One of the sticky points in a transition from a Sensu Inc. maintained project to a community maintained fork are probably going to be how to handle transitioning of the EOL’d gems in the rubygem repository. As the rubygem package repository doesn’t incorporate vendor namespacing, it presents a difficulty when projects fork as only one version of the gem can be “blessed”.
What is going to happen with the “Sensu Community Plugins” is a different but related discussion. If a community group does step forward to maintain the Sensu Core codebase, then obviously there will be some interest to continue to support the Sensu Core event model for handler and mutator plugins. If a group doesn’t step forward, I would expect that at some point Sensu Community Plugins will deprecate support for the Sensu Core event model just due to lack of the ability to test effectively. I should stress, nothing is decided as a matter of policy for the Sensu Plugins github organization with regard to the EOL status of Sensu Core. I’ve done work to make it possible for existing Ruby based plugins to work with Sensu Go, but no work has been planned to remove support for Sensu Core from existing plugins.
Hi jspaleta,
I have a Docker Container Running sensu Core 0.26 ,
Thanks.
Hey!
I’m not sure if there was ever an official docker container released for Sensu Core under the Sensu namespace at docker hub. You are most lilkely using a community contributed docker image for Sensu Core.
Translating existing Sensu Core configs is still partly a manual process, the translator gem helps to some extent but you’ll definitely need to transition workloads manually.
I personally don’t think it makes sense to have the translator in a dedicated Docker image, though someone could produce one easily as the translator really is just an aid in a migration process and not a fully automated task.
If you are planning to migrate to Sensu Go, I’m not sure there is much value in first upgrading to Sensu Core 1.8. But if you are planning to stick with Sensu Core and help interested external community maintain a forked version of the codebase, then I think it makes since to upgrade to Sensu Core 1.8 before EOL so you can be prepared to help the code transition as an external community maintained codebase.
With regard to migrating to Sensu Go, i would recommend that you stand up Sensu Go in parallel with your Sensu Core configuration during the transition, so you can migrate workloads without disrupting your existing alerting. The Sensu Core service elements will not conflict with the Sensu Go backend. And it is possible to run a Sensu Core client side by side with a Sensu Go agent as long as they aren’t both trying to use the same local event port.