Why did Universal forwarder 9.1.0 (linux) change owner?

[auradk]

I just started rolling out universal forwarder 9.1.0.1 on a few machines. To my horror i noticed that splunk again made a significant change in a minor release. The forwarder is now owner by user "splunkfwd" instead of "splunk".

I can only see this change in https://docs.splunk.com/Documentation/Forwarder/9.1.0/Forwarder/Installanixuniversalforwarder#Instal...

There are no other mention or warning about this.

Am I  the only one who needs to change a significant amount of automation/installation scripts for this change? 

I know tarball is one workaround, but really?

[chadmedeiros]

This is a really cavalier response to such a major change. It is not a simple task to 'update automation' in large organizations, where you also need to consider multiple legacy systems.

As was mentioned above, Splunk has never officially supported the installation of both Enterprise and Forwarder on the same server, so who does this change benefit?

[auradk]

I get it they want to distinguish between server and forwarder with different owners, but in my opinion that is way too late now.
First the scenario of having both server and forwarder together must be a tiny tiny fraction of what is setup out there - finding it hard to see why you would at all.
Second more than a decade with splunk as the owner makes this change something you should not take lightly if you have just a little respect for your customers. The impact on automation, security and plain familiarity far outweigh the need to separate the server and forwarder. At least this should have been an option not the default. 
Then the unprofessional way of doing this in a minor patch without any warnings just makes me furious. I get the same ticks from when they also in a minor patch changed from initd to systemd. 
I created a support case asking them to revert or come up with some options. 

[PickleRick]

Let me disagree here.

While there can be a valid scenario when you run both full Splunk Enterprise instance as well as the forwarder on one machine it's such an unusual (and unsupported) scenario that it's up to the admin to work out a good method of installing it that way (like one instance deployer from RPM and other from tgz). Introducing a completely unforeseen undocummented and - frankly - unwanted change into the package is a very ugly thing.

Sorry to say, but this is not something a respectable packager should do.

To make things even uglier - the "fix" introduced in RPM install scripts leaves you with two splunk-related users on your machine - one is the old one called "splunk", another is the new one called "splunkfwd". Of course if you had any permissions granted to the splunk user they won't "migrate" to the splunkfw user so simple upgrading forwarder package might actually break your installation. That's something that should never happen!

If you want to introduce changes and have stuff that is backwards-incompatible, look at Debian's packaging. While I might not love Debian nowadays for some reasons, they have always had very sound packages and package naming conventions - if upgrading package from version X.Y.Z to version X.Y+1.A introduces some irreversible changes, you just do separate lines of packages and tell the users to knowingly and intentionally migrate (see for example postgresql packages).