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]

OK. Instead of creating new accounts just to post the same content which is completely pointless, the thing you (and everyone who finds this idea important) can do is log into https://ideas.splunk.com and create or upvote a relevant idea there. If it gathers enough visibility it might get considered.

Just posting random rants here won't accomplish much.

[welker]

Whoa there, Sherlock! Let’s not assume every account here is just me in a trench coat and a fake mustache. Some of us have been lurking in the shadows, waiting for the perfect moment to echo the exact same frustrations in slightly different words. Totally different people, promise.

But hey, thanks for pointing out ideas.splunk.com! After only 13 years, it’s nice to know there’s an official wishing well where dreams of a YUM repo can go to...um, simmer? Who knows, maybe we’ll have a repo by the time this thread can vote or rent a car. Appreciate the tip!

[PickleRick]

Maybe not you, but there were at least two separate freshly created accounts with just one comment in this thread in their history, created within some 10 minutes of each other and posting a very similarily built comments. Accident? I doubt it.

The ideas portal has been alive for at least a few years now.

[welker]

I just created a feature request on ideas.splunk.com:

Provide a YUM repository for Splunk

Feel free to vote it up 😉

[sp1nx]

Just to clear things up—I’m not the same person, just a friend who happens to share the same frustration. We’re both in the trenches, managing Splunk forwarders on Linux, and trust me, it’s a shared experience we can all relate to.

We're not asking for much, just some consistency and automation in how we manage our installs. A proper YUM repo would save us from the ongoing dance of manual installs and updates, and help us maintain the stability and security that every sysadmin craves.

So no, I’m not the one who’s been posting under multiple accounts, but I am definitely right there with them, dealing with the same pain points. Let’s hope we can get some traction on this, and maybe one day, our dream of a YUM repo will be more than just a wish.

Cheers,
A Fellow Sysadmin Who Gets the Struggle

[bishopolis]

Happy 13th Birthday, posting #107735! Why, with everything going on, I missed your birthday again -- but you've changed your name! I know you're now "admin-security message-id 3439", and I'll try to remember, but if you want to go back to being #107735, I support you there as well. You be you! Wow. 13 years. I know we said 12 would be your year to leverage technology so well established that it's gone from 'new' to 'common' to 'unmentioned' to 'forgotten' to 'new again', but it's never too late to get on-board the 'trivially easy to configure and use' train. My, but it's easy. So much of this trail has been blazed before you by so, so many others - even in your own field - that it's almost a slam-dunk. Let's get you back on your feet, #10773--uh, 3439, and get you climbing up that hill back to the mainstream. Don't worry at the bright lights of the projects whizzing by on that mainstream. Your parents will be worried sick at where we found you, and they miss you and they just want to see you succeed. This is your year, 3439. Party with proper authentication and easy authorization like it's 1999 !

[patterc]

Before we know it, this post is going to be able to vote

[bishopolis]

The question is, what can a tween do? Can this question get a library card? Can it make a facebook account?

[welker]

Dear Splunk,

It's me again, your 13-year-old feature request. I'm a teenager now, full of angst and unfulfilled dreams. You know, like being a real YUM repo instead of a pipe dream.

Other software out there—Elastic, Docker—they've got their act together. They're hanging out in proper package managers, getting auto-updated, living the easy DevOps life. Meanwhile, I'm stuck here on the outside, manually downloaded and prayed over like it's still 1999.

Look, it's cool. I get it. Maybe you think I'm too risky. But come on, it's not like admins are out here setting YUM cron jobs willy-nilly for production servers. We’ve evolved, Splunk. We use staging environments. We test. Heck, we even read changelogs (sometimes).

So, how about it? Let’s make 2025 the year you give me a proper repo. Signed artifacts, authenticated HTTPS access—the works. I promise I won’t embarrass you. And if things go wrong? RPM rollback has my back.

Yours,
A Dream Deferred (but still hopeful) 13-year-old feature request

[klimenkosg]

Dear Splunk

I second this motion, with a few additional points for your consideration:

1. Manual Downloads Are So 2005: Logging into your website, hunting down the download link, and wrestling with wget is the DevOps equivalent of using a fax machine. Cool for retro vibes, but not ideal for modern enterprises.

2. RPM/YUM Best Practices: Providing a proper repo isn't just about convenience; it's about consistency, reliability, and automation. Signed RPMs and authenticated repos have been standard for decades. Even Bob's Open Source Project has a repo, and he works out of his garage.

3. Competitor Comparison: Elastic, Datadog, and the rest of the cool kids already have yum and apt repos. Don’t you want to sit at the popular table? Or at least not the “legacy tools” table?

4. Risk Management: Yes, we know, "unattended updates are risky!" But this isn't our first rodeo. We manage critical systems daily and don't just blindly yum update prod boxes. Give us the tools, and we'll handle the responsibility.

So, how about it, Splunk? Help us help you. We’ll even bake a cake for the 14th birthday of this request if that’s what it takes.

Yours in perpetual hope,
Another Disillusioned Admin

[sp1nx]

Dear Splunk,

Adding my voice here, because honestly, how is this still a thing? It’s like watching a toddler grow up but refusing to wear shoes because ‘barefoot builds character.’ We’re not trying to strip you of your rugged charm—we’re just asking you to stop tracking mud into the data center.

Look, it’s not just about convenience. A proper YUM repo means:

• Consistency: No more “Did we grab the right version from the website?” anxiety.
• Efficiency: Automation beats playing 'Where’s the Download Link?' every release.
• Security: Signed RPMs and authenticated repos mean we sleep better at night. (And you don’t want to mess with my sleep.)

You’re a billion-dollar company, not a weekend side project. If Bob’s Discount Monitoring Software has a YUM repo, so can you. Let’s not make this a 14th-birthday discussion, or worse, a sweet sixteen.

Yours in exasperation,
A Sysadmin Who Just Wants to Automate

[bishopolis]

Happy 12th Birthday, posting #107735 ! You're a tween now! Why, it seems like only yesterday we were commenting on how decade-old authentication code for Yum repo consumers makes the current auth wall completely pointless, and how easy it would be to set up a simple yum repo to make enterprise update staging and testing on-premise such a trivial thing. Now it's TWO decades old! Yay! Oh, how you've grown as the technology has aged. Remember all the times we've been told "we're just sorting it with [another group]" and progress went absolutely nowhere? Remember how we sadly pointed out the delayed development against its peers in that regard -- which is still a developmental delay today? This is your year, kiddo. Go on and be adequate!

[DanielPi]

Hi @bishopolis   - 

I’m a Community Moderator in the Splunk Community. 
This question was posted 12 years ago, so it might not get the attention you need for your question to be answered. We recommend that you post a new question so that your issue can get the  visibility it deserves. To increase your chances of getting help from the community, follow these guidelines in the Splunk Answers User Manual when creating your post.

Thank you! 

[bishopolis]

No, let's not let this one fade out. - the question is relevant - the context is relevant, as is the history - the goal is as trivial now, as then, to achieve - the continued "any day now" feeling is important Bump this one. Maybe it's okay for still-relevant issues to be still-relevant, even if it's hard for a small number of us to value something more than a fortnight old. Thanks for your suggestion.

[welker]

Any update on this? The way you release your software at the moment makes it impossible to automate the installation/the upgrade process of Splunk in a professional way.

[PickleRick]

Let me repeat myself and rephrase what I already wrote in https://community.splunk.com/t5/Security/Is-there-a-yum-rpm-repo-for-Splunk/m-p/606611/highlight/tru... in this thread.

You should _not_ be doing unattended updates, especially in a bigger environment, without doing a thorough risk analysis of possible downtime and such.

Apart from that, simple yum update or aptitude upgrade would _not_ leave you in a running state - you still have to run splunk manually at least once to accept license for a new version, perform updates if needed and so on. If you are able to automate _that_, providing source for package download is the least of your problems.

So while it might be indeed useful for your (or mine) splunk free at home, it is not something I would advise anyone to use in production environment.

Splunk is not something that I'd expect yum-cron to manage.

[bishopolis]

It's okay to repeat yourself. Your comment suggests you may not understand, and that's okay too. To give you a hint, RPMs are - as we know - signed manifests and content, which includes overlay files and scripts. The format allows for very detailed specification on what's required and all its dependencies. Yum will take those requirement specs and, since we know it's identical, repeatedly install exactly what we require, over and over again. It's consistent, and in a verifiable way. Not there yet? OK. You should know: this idea that YUM === "blindly installing anything in prod without assessment and no other workflow is possible" is verrrrrry nai--uh, simplistic. It's possible, sure; same as without it. Every tool can be used poorly. But using it properly really opens up some adequate features. And we'd like Splunk to be adequate. Here's the water, if it wants to drink. I *do* install a lot of things automatically. When working on the largest single-owner intranet in the world, careful automation helps. When I promote a version of software, I know it's going to get installed on all my hosts exactly as I want by specifying a nevra. This has been possible-- no, scratch that. This has been reliably consistent in a verifiable way with an excellent (simulated) rollback mechanism for 25+ years. People born AFTER this was a proven feature have learned to crawl, walk, run, add, multiply, converse, demonstrate, compete,learn, love, graduate and excel in a field; all in that time. People born after this feature was a feature could have learned this feature while looking after their own newborn children. EVERY competitor to Splunk figured it out in that time. Splunk has a willing army of volunteers who'd love to show them, I'm sure, but who also remain a valuable resource completely untapped. I hope Splunkisco can learn more about it and catch up to 1999. But look at the time: it's almost 5 months to the 13th birthday. See ya there!

[welker]

What lets you believe that I intend to do unattended updates? We implemented a very tight release process using tools like RH Satellite.

[PickleRick]

Then creating a custom repo and uploading a single package once in a while is really not that much of a nuissance, is it?

OK, I admit that maybe UF's could be easier available. In this case you could even risk unattended updates.

[bishopolis]

> Then creating a custom repo and uploading a single package once in a while is really not that much of a nuissance, is it? As a security person, you may need to review the risks of manual processes with manual validation of forgettable work. It's been well-discussed. We understood these risks in 2000 while producing, securing, and releasing Unix: a repeatable, verifiable, consistent process was not one compatible with manual work. It also was neither scalable nor reliable. I suspect the same is still true in 2023, enterprise space or not, and maybe even more important given the larger scale of resume-driven architecture design. For instance, you may discover with time that proper change control requires processes tested in non-prod to be replicated exactly for production, and you may realize that humans are imperfect even at 'nuissance'[sic] work like that, even after only a few repetitions. Are you confusing 'unattended' with 'unmonitored' or 'negligent'? That may be a little hasty. I've escaped the need to work around splunk's naivete, but I'm still happy to celebrate this birthday in the hopes they may one day learn to use tools built to improve their process and tested for the last 25+ years.