Is there a yum/rpm repo for Splunk?

[stefanlasiewski]

I'm installing Splunk on an Enterprise Linux 6.1 machine.

The Install on Linux instructions talk about a RPM, but don't explain where the RPM is.

A Yum/RPM repository would be helpful in terms of installation, updates and would speed up the deployment of security updates

This would also help with security updates. In our case Splunk doesn't always notify us that there is a security update available and Splunk security updates are not announced via email. If Splunk provided yum & apt repos, then checking for security update could be as simple as yum check-update splunk or yum upgrade splunk.

Does Splunk.com provide a Yum/RPM repository for the Splunk application?

[PickleRick]

Honestly, I have no idea why you're trying to make it personal.

Nevertheless - a simple, easily documentable procedure which must be performed once a few months is not that hard to do. And in a typical production environment there are so many other steps you have to perform if you have a proper change control process in place that adding one additional one is really not that biggie.

Sorry, that's my personal opinion. You may not share it, that's fine, but it's not a reason to start being offensive.

And providing a "ready to use" source of packages for updates which can easily go haywire is just asking for trouble. I might not use it, you might not use it, but there will be many people who would happily just add the repo to yum and enable yum-cron (or the debian equivalent). And that would obviously end badly. And people would start blaming the vendor (just as I blame Microsoft for very badly written RPMs).

So not providing the repo might actually be a safer choice here. Yeah, there are some dissatisfied users but it's a minor nuisance for them. A bit annoying, but not severe. A stopped or even broken production server because some admin did one yum upgrade too far could mean much more potential loss.

[bishopolis]

I'm sorry you're deciding it's offensive. If you're confused about release management, proper artifact validation or why we enable signed artifacts from signed sources via pre-programmed tools to avoid human error, it's just an opportunity for learning; nothing more. 'Once a few months'? I hope you're updating your OSS-based gear more often, as even back then the response time for bad actors was very fast. And, too, the longer between releases, the less often a manual process will even *notice* a valid update is in the queue to test and promote internally. If you don't know that, please don't be offended. A bad RPM update is trivial to back out due to how RPMs are built. It's actually a really great thing. If you're assuming these ones will be bad, then it's a fixable problem and far from irremediable . Because you only hose the test rig. Right? Again, please don't be insulted if you're just discovering this now. Broken servers a nothing. Terraform-taint the test rigs and re-apply. Again, please don't let this insult you somehow, and I'm sorry if discovery has that effect. You can surely get there from anywhere you may be now, and it's just a matter of resources and planning. There's absolutely no reason a valid repo isn't provided, and dreaming up contingencies to solve on the downstream side is great brainstorming for customers themselves, but no reason to withhold adequacy. And, it starts to sound like an excuse by Year Eleven. Have a great day. Try not to be insulted!

[PickleRick]

That's what I was talking about. You make assumptions about me and you try to talk from position of superiority even though nothing warrants that.

Let me give you the benefit of a doubt and assume that it's either because english is not your native language (mine either) or you're young and full of yourself and think that your point of view is the onky valid one. In such case, don't worry, most people, including yours trully, grow out of this phase.

Let me just tell you that no, sometimes a bad rpm update is not that easy to rollback. Just like any other update. If your data gets damaged what good to you is that you can redeploy the software? Regardless of whether it's terraform, puppet, ansible, your own bash scripts or even SCCM, if your data is damaged... well, you're in deep heap of manure.

That's why - for example - you have separate packages for different postgres major versions in most distributions - so that nothing gets accidentally updated in such a way that would render your environment inoperable.

Also I'm pretty sure "once every few months" is a pretty accurate desciption of splunk release history.

And that's pretty much it. And these are my last words in this thread. I described my point of view. You may agree with it but don't have to. There's nothing else to be gained here.

Have a nice life.

[bishopolis]

HAPPY  late 11th Birthday, question #107735 !!  

Many happy returns.

In related news, authenticated HTTPS access to yum repos are still a thing since 2005, and easy to set up to back onto any number of authentication and authorization services.  There's absolutely no reason why this is technically a challenge, and looking at similar offerings by competitors we know other roadblocks can be overcome.

Let's hope for good news any day now!

[bishopolis]

We missed the 10th birthday for this one, guys.

I was going to get a cake and everything.

But, no worries, the 11th birthday for this bug is right around the corner!

[wduckett]

Silly that this hasn't been addressed in 11 years... lol

[PickleRick]

You know, after being initially annoyed with lack of a repo as such, I must say that after giving it some thought I don't think it's that much of a problem.

Yes, not having a static (or semi-static) address to download the software from which could be easily incorporated into your script or puppet/ansible/chef/whatever mechanics is a bit frustrating but the repo as such...

Honestly, I wouldn't want my servers to go on and to a yum upgrade just because I have yum-cron set up and there is a new version available. It can make sense in your all-in-one lab installation without any serious data. But in production? What if the new version does introduce some changes which are not fully compatible with your config? What if upgrade fails? Splunk is relatively chatty on upgrade whereas rpm operation should be completely "hands-off". (here a small piece of rant - Microsoft produces worst rpms I've ever seen - they require you to manually accept license during install).

So I don't think that repo as such is that much needed or that it's that good idea at all.

But not having to go through all the hassle with logging in to Splunk's website just to get the download link which you can supply to your wget would be a major help.

[grangerx]

Hi all,

I improved the yum repo creation/update script I made:

It's a bash script that uses CURL to determine what files are available on the splunk download site, then 
downloads the available packages and uses createrepo to turn them into a valid YUM repo.

It checks/downloads RPMs for :
splunk-enterprise and splunk-universal-forwarder

It also includes an /etc/cron.d/ file that can be used to execute the script every night at 03:00 local time.

https://github.com/grangerx/splunk-yum-repo

Note: You'll have to give it a splunk.com login for it to be able to download the packages from splunk.com.

[AlanMoen]

This shouldn't be rocket surgery. But I expect that, since Splunk was acquired by Cisco, this will never be resolved directly.

Thanks to grangerx for doing God's Splunk's work.

[bishopolis]

I think we're up to 7 years and one month (happy late anniversary!) as the response time for this requirement so far, with only a few promises of progress to go by.

Any tangible update?

[bishopolis]

Happy 8th birthday, question 33933 !

It's been 96 months since you were first recorded.

And while the RPM technology hasn't changed significantly in 21 years, it's still a really big challenge.

Hang in there, question 33933 !

[patterc]

happy 9th bday!

seriously though... c'mon splunk

[mfaine]

I agree. There is no valid reason in 2018/2019 to not have a package repository. They are a major software vendor, it's inexcusable.

[bishopolis]

2 months later.

Have they published a proper repo yet?

A software repo with automatic updates is a tiny, tiny bit of what makes an 'Enterprise' company an Enterprise company, and it's valuable for so many reasons that we all should understand by now. Even if we're using Puppet (chef for us) to manage config, config management doesn't magically absolve sysadmins from the need to be adequate -- and installable artifacts (Hi BruceJackson) are best-practice for a very, very good reason.

I think everyone here wants Splunk to be awesome -- for some of us starting this journey, we've been told so many great things. I'm hoping they've published a repo and just forgotten to update this particular thread, so if anyone found one can you show me where I overlooked it?

[amiracle]

Still working on this internally. Hope to have a response soon.

[Intermediate]

amiracle could you please provide us all an update? Even if your work didn't go anywhere it would be helpful to have closure.

[amiracle]

The latest update I can give is that I'm working with our IT organization to establish the repo and will post more updates as I get closer to having this done.

[Intermediate]

Hello,
It's been another two months. Do you think this is likely to happen or is it just too hard internally?

[Intermediate]

Thank you.

[bishopolis]

3 months later (76 months overall). Any updates?

Right now, Splunk is considered Not Enterprise Capable due to the broken update stream.

"Day 2" problems are important in the Enterprise.

[bishopolis]

81 months total. Any luck this is our lucky month?