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. ... View more

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! ... View more

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! ... View more

> 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. ... View more

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! ... View more

cp splunkforwarder*.rpm /opt/splunkrepo Here's where that post skips over the part we want, but does add some flash and finish we can figure ourselves. ... View more

This is done by accepting the terms of service when a user logs in and downloads the software. The solution is that users can create their own Yum [Repos] and update them using the cURL command listed in the Download page for each version. Once you've setup your own private repo, then you can run yum install splunkforwarder -y and install your forwarder. It's trivially done by ensuring customers use their own custom credentials to access the repo, embedded in the yum repo URL.  This also provides excellent logging which I'm sure will be the next insurmountable micro-obstacle. ... View more

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! ... View more

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 ! ... View more

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? ... View more

To reiterate what @martin_mueller said: typically NO path statement takes wildcards typically you'll need a symlink to point to the correct one you're on Enterprise Linux: you'll have the links managed for you when you install the proper package, your JAVA_HOME is just /usr/lib/jvm/jre and it never changes so, simply install -m755 <(echo export JAVA_HOME=/usr/lib/jvm/jre) /etc/profile.d/javahome.sh .. and you're done. Extra credit: add that into the RPM you use to pull in the JRE, but remember that we don't have a yum repo yet so don't link in db-connect as a dependency if you do. (Check out https://answers.splunk.com/answers/33933 for the trivial repo question; it shouldn't be long, now) ... View more

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

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. ... View more

https://www.rfaircloth.com/2017/03/07/automating-splunk-deployment-redhatcentos-poor-mans-edition/ says: %triggerin -- splunkforwarder /opt/splunkforwarder/bin/splunk enable boot-start --accept-license --answer-yes service splunk stop mkdir -p /opt/splunkforwarder/etc/apps/org_all_deploymentclient/local Did you try this route and find it was no good? I'll build a similar trigger-laden package like this in a heartbeat ! ... View more

Fantastic! But don't be teasing us, now 😉 Soon as you have info I'd love to hear it -- of course! ... View more

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? ... View more

wget https://download.splunk.com/products/splunk/releases/6.6.3/linux/splunkforwarder-6.6.3-e21ee54bc796-linux-2.6-x86_64.rpm --2017-10-24 16:44:47-- https://download.splunk.com/products/splunk/releases/6.6.3/linux/splunkforwarder-6.6.3-e21ee54bc796-linux-2.6-x86_64.rpm Resolving download.splunk.com (download.splunk.com)... 13.33.151.73, 13.33.151.8, 13.33.151.155, ... Connecting to download.splunk.com (download.splunk.com)|13.33.151.73|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2017-10-24 16:44:47 ERROR 404: Not Found. ... View more