We find that in many cases the Forwarder Management Interface is very slow. Some folks prefer to handle modifying serverclass.conf manually, others prefer the UI. Does this present a problem, as long as we don't step on each other's toes?
Also, it looks like Forwarder Management uses apps/search/local/serverclass.conf while the people that have been weaned on manually managing the serverclass.conf file use etc/system/local/serverclass.conf ... Is there a way to force the Forwarder Management UI to use etc/system/local instead of using the one in the 'search' app?
So I just set up a DS myself, and it looks like edits through the GUI actually went to the file at /etc/system/local. I tested with both admin and with another user who's default app was search.
This would be the file that your manual editors will have to use.
AFAIK, there is no way to force the Forwarder Management UI to use the system-level serverclass.conf file
It would be best if you had only one serverclass.conf file. So if you want to manually edit the file and use the GUI, you will have to user
There is no problem, as long as two people are not trying to edit the file simultaneously. Also, never forget that you need to run
splunk reload deploy-server
after any manual edit to serverclass.conf - otherwise the edits in the file will not go into effect until the next Splunk restart. And the edits won't appear in the GUI either, which could lead to confusion...
^ Second that best to only have one serverclass.conf file. This can end up causing problems later if you don't get it straightened out soon....apps won't deploy properly, etc.