@djacquens  I just released the app "Fuse Box" on splunkbase for just this purpose. https://github.com/splunk-soar-connectors/fuseboxutility/blob/next/README.md It should be available in the new apps UI if interested in giving it a try. ... View more

There isn't a simple way to do this that I know of. Local is treated differently and the literal repo name "local" seems to be tied directly to both the default and handling the repository as local only.  You can remove the local repository with some database shenanigans on the scm table. that will remove the default entry and require you to select the repo to store the content in. If you add a remote repo after that with the name local, that repository will then be the default but because it is the "local" named repo, the platform will not execute commands to sync updates made to that repo to the remote repository. You can ssh into the system and run the push commands yourself but that would be a fairly tedious process.  I think your best option if you really just didnt want the local default would be to remove the local repo and manually select the correct repo every time, but that isn't going to gain you much other than preventing accidental commits to local. ... View more

I know this is old, but I solved this with a custom app to short circuit a playbook. The app checks a list to see if the identifiers for the current event have already been seen. If it is already in the list then it outputs a True and the playbook can be halted and handled as a duplicate. If it hasnt been seen before, the app outputs false and the playbook can proceed as the first instance of this event ingested.  This all works because apps do have locks. If the app is set to lock and only have one concurrent run, then adding this check as the first step in the playbook will break the race condition you are dealing with.  The only significant downside is that this will effectively turn your ingest pipeline into a serial stream which can be problematic for especially high volumes of events. ... View more

There is a lot of context here for some app operations like widget generation but its not terribly useful beyond the scope of debugging an app issue. I would suggest adding it to the logrotate conf and setting it to roll daily. I wouldn't personally keep more than 7 days. Really if you are debugging an app, historical records are much less useful that active debugging.  ... View more

@ktsplunksoar, @phanTom 100 percent correct on this whether we are talking about supported or unsupported options. I have tried every version I can think of for hacking together a short circuit in prompts with a default or an auto fill. Without a feature addition, there is no way to do this. ... View more

I'll be there. I invited a few people but who knows if they will make it ... View more

count me in as well ... View more

I have seen this happen a couple of ways. The most frequent but unobvious one is that your login session has expired but the playbook editor was still open. If that is not the case, then I would check on phantoms running processes and make sure decided is running along with the rest of the phantom services. Worst case scenario, try restarting the phantom platform by running /opt/phantom/stop_phantom.sh followed by /opt/phantom/bin/start_phantom.sh ... View more

You might modify the title with [Solution] or add the answer and select your own answer as the solution.  Just so that anyone else having the issue knows that this is an answer and not just someone else asking for help with the same problem. ... View more

Multiple people have reported this in the Phantom community slack. If you haven't already, definitely submit a support ticket and add an entry at ideas.splunk.com with your support ticket number attached.  ... View more

"Easier depends on experience in each platform and available resources. If you have phantom and you are already using it for other automation, then yes, it is likely to be simpler. I wouldn't recommend setting up a phantom instance for this single case. And if your experience in phantom is limited, it may be much faster to go the splunk app route. Phantom introduces more moving parts to your process so adding phantom for adding a user to an AD group doesn't make sense but using phantom that is already operational and part of your porcess anyway could very much make the job easier. ... View more

I highly recommend naming your playbooks concisely based on what they are intended to do at a high level. The primary reason that I suggest this is that within the mission control view, you have a limited width for displaying the playbooks execution history. If you prepend playbook names with a lot of metadata you end up only seeing a truncated version of the playbook name in the activity pane and that truncated detail ends up giving you no context for what the playbook actually did. I highly suggest using the name of the playbook as simply a high level description of what the playbook does ie "Infected Workstation Remediation". You can use the description field in the playbook to add a detailed description of how it accomplishes that. Tags are very effectively used to demonstrate teams that are using it as well as object types that are used in it. As of 4.5 (I think) your playbook listing provides you apps , actions, assets, and playbooks used so you don't need to specify that content in the name. Attempting to keep this kind of data in a playbook name can be exceedingly problematic since this metadata will change over time and you will have to update playbook names which in turn requires wiki documentation to be updated, and phantom calls to sub-playbooks to be updated, etc. The fewer changes you have to make to top level playbook names over time, the less trouble it will cause you. ... View more

Im not completely certain I follow the question. It seems you executed a prompt2 within the context of a custom function? If that is the case, you can still access the data you need as long as you specified a name and a callback for the prompt2. If you didnt specify a name then you will have a hard time manually specifying the action results. If you dont define a callback then the playbook wont wait for the prompt to be addressed and your results will always be null. The VPE doesnt know to look for the action results from custom functions like that so you will have to specify them manually: ... View more

No. I have never been in a situation where I wanted to drop the default app library. ... View more

If these are custom apps that you have written, i have tackled automated deployment is kind of a sketchy way but it will work. Log onto the phantom server via ssh and clone your app repository to the file system where ever you want it stored Write a script that does the following: • Pull the latest from the repo • Pull the current app versions from the phantom API • Check the current app version for each app in the repo • If the repo version is different, run phantoms compile script with -i to install it to the server Cron that script to your desired frequency or create a playbook that you can run adhoc that will run the script. I prefer cron because then you dont have to tangle with the permissions for the phantom-worker to run the script and execute all the required commands. Its a little clunky but it gets you out of the business of creating and manually uploading custom app tgz files. ... View more

There are ways that you can accomplish this in a playbook but none of them are strategically sound options if you want to maintain a stable and consistent phantom environment. In general, looping playbooks is one of the easiest ways to make sure that your phantom host stops processing any other automation which is not what you are going for here. I am listing three good options here in order of level of effort. I recommend suggestion 1 but any of them will work. 1 ) You could write a python script that uses the rest api to check for containers that have owners set but have not run your playbook yet and execute the playbook from there. You can schedule that cron job fairly frequently without having any serious impact on performance. 2 ) Another option would be to create a playbook that essentially does the same thing as the cron script described and use a timer asset and label to execute that playbook. you will take a larger performance hit running it this way especially if you have a lot of automation going. But this does allow you to keep your automation in the UI and not hiding in a cron script. 3 ) A better option than the timer would be to write a simple custom phantom app and use the on_poll function to execute the operation described in the cron script above. ... View more

Can you provide the name of the app you are trying to set up? Its pretty hard to check out the problem without being able to look at the app itself. ... View more