I'm using splunk 6.1.3 with a deployment server.
I distribute indexes.conf to my indexers via an indexer serverclass.
When the deployment client receives the updated indexes.conf, the client creates the new directory ... ie: /indexes/test/colddb and /indexes/test/db
The problem though, is that while the owner of those directories is the right user (splunk), the group affinity is always root, and that index is not writeable until I manually change it to the default group that splunk is associated with.
This is a NIS+ environment and I'm wondering if that's causing me a problem. I have added the splunk user to /etc/passwd and the associated group to the /etc/group file ... but the problem still persists.
total 16
drwx------ 4 splunk root 4096 Aug 26 19:23 .
drwxr-xr-x 7 splunk service 4096 Aug 26 19:23 ..
drwx------ 2 splunk root 4096 Aug 26 19:23 colddb
drwx------ 3 splunk root 4096 Aug 26 19:23 db
Is there an issue with Splunk being able to operate in a NIS+ environment?
Thank you.
Ok ... So this appears to have nothing to do with NIS+ but more to do with the way 'enable boot-start -user splunk' sets up init.d/splunk. splunk-launch.conf specifies the user that Splunk will run as, but I believe that because 'service splunk start' gets executed as root, the effective group ID that gets set at startup time is root ...
I have no problem if I run: sudo -u splunk $SPLUNK_HOME/bin/splunk start
Or, if I modify /etc/init.d/splunk to precede the start/stop/status and restart commands with:
/bin/su - splunk -c ... ie:
/bin/su - splunk -c "/apps/splunk/bin/splunk stop"
I would consider this a bug though. Not sure how others feel about that.
Yes, this is a defect in early 6.1.x with how the SPLUNK_OS_USER feature was implemented. It has been fixed in current releases.
Essentially, if $SPLUNK_HOME/etc/splunk-launch.conf says the user should be 'splunk' but you run it as root, it tries to become splunk user. There was a flaw in how this was done that has been remedied.