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?

[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.

[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.

[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.

[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.