Okta (beta) integration
Has anyone successfully configured the SumoJanus Okta integration? Documentation seems to be lacking a lot of details.
-
So, the https://help.sumologic.com/Send-Data/Applications-and-Other-Data-Sources/Okta/Collect-Okta-Logs instructions, including the script is crap (sorry).
First off, the script is overly engineered for no good reason, here's a simple version that just works:
#!/bin/bash
JAVAPATH="/usr/local/SumoCollector/jre/bin"
if [ "$1" = "-s" ]; then
echo "Setup mode"
runMode="-s"
else
runMode="-r"
fi
$JAVAPATH/java -jar /home/sumojanus/januscore*.jar ${runMode} OktaCollector-1.0.0.jar -e 1800I'll probably iterate on that to add paths instead of hard coding it in, but for now, this works as expected. Also, I had to create the /usr/local/SumoCollector/conf directory and copy config.properties and log4j.properties from $PATH/sumojanus/conf/ to get rid of a bunch of errors related to log4j. Oddly enough, the collector was looking in that path for the two files, so copying them there fixed my issue. Be sure to also chgrp -R the sumojanus directory with sumologic_collector to avoid permission issues.
Once I fixed those two things, everything else began to behave as expected. Hopefully, this will help someone else.
-
First you need to unpack the sumojanus-dist file (one time - this is for the SumoJanus framework), then sumojanus-Okta (or other bundles like Box or Salesforce) over the same sumojanus folder in that order. The "conf" folder is already included with the SumoJanus framework, so if you don't see it, my guess is the framework file was not unpacked, or you didn't unpack the Okta bundle over the framework folder ("sumojanus")
You should have the following structure after these steps:
sumojanus/
- bin/
-- <a bunch of .md, .bash and .bat files depending on the bundles used>
- bundle/
-- SumoConfigService-.XYZ.jar
-- SumoUtils-XYZ.jar
- conf/
-- config.properties
-- log4j.properties
-- sumologic.properties
- januscore-XZY.jar
- README.md
- VERSION.md
- data/
- sumo-bundle/
-- <some jars depending on the bundles used>
Once both files are unzipped, modify the sumologic.conf according to the specific bundle instructions (this config file is shared across all bundles) and follow instructions for each specific bundle.
Finally, all bundle scripts must be called from under the "sumojanus" folder. E.g: ./bin/SumoJanus_Okta.bat -s , or ./bin/SumoJanus_Box.bat -s , ...
The error on "Could not create a framework" is very likely caused by calling the script under the "bin" folder
-
To make it work on a Windows server I had to do the following:
- I followed Duc Ha's guide and extracted sumojanus-dist to C:\, creating a sumojanus folder and deleted the macosx folder. I then extracted the sumojanus-okta to c:\, afterwards I copied everything in the folder to c:\sumojanus.
- I copied januscore-xyz.jar to c:\sumojanus\bin\
- Following Iterable inc's advice., I copied the conf folder to c:\sumojanus\bin\
- I had to copy the entire bin folder in the c:\sumojanus.
- I was then able to follow this guide starting @ "edit the properties file": https://help.sumologic.com/Send-Data/Applications-and-Other-Data-Sources/Okta/Collect-Okta-Logs
-
Graham, Iterable:
Glad to hear it's working now - you shouldn't have to do that much. SumoJanus is separate and independent of the Sumo Collector - the only thing it needs is a JRE, which for convenience can be found under a Sumo Collector directory (hence the JAVAPATH setting to point to it ). The Sumo Collector basically just calls SumoJanus as calling a script - so as part of configuring a script source (NOT a script action) for it, you need to set the right calling script path AND set the working directory (which is the full path to the sumojanus folder). Also SumoJanus needs to do some book keeping, so the collector (or rather the user the collector is running under) needs to have permissions to write to the SumoJanus folder.
You can totally call SumoJanus manually by going to right under sumojanus (don't go to "bin"), then call:
./bin/<the_script_for_the_bundle>
If you call from under "bin", then things will not work, my guess is that why you had to copy all those other things over there.
As for log4j config, it's under <sumojanus>/conf/log4j.properties, along with all other config files.
-
Does anyone have this working on a Windows Collector? I seem to be having issues with the batch file script itself. Here is what mine looks like
REM Make sure JAVAPATH below is correct for your environment
@echo off
set JAVAPATH=E:\Program Files\Sumo Logic Collector\jre\bin"
if [%1]==[-s] (
echo Setup mode
set runMode=-s
) else (
set runMode=-r
)%JAVAPATH%\java.exe -jar E:\sumojanus\sumojanus\bin\januscore-1.0.jar %runMode% OktaCollector-1.0.1.jar -e 1800
-
Jim,
Is the issue you are having one where you are seeing a JAVA related error message when the script is run? Using the Java listed in the Sumo Logic Collector install is likely to cause potential issues down the road if it isn't causing it up front. Why? because the Java that is provided with the collector isn't always configured and located in the DriveLetter:\Program Files\Sumo Logic Collector\jre\bin" directory.
If Java is there for now, great. If it's in something other than that like DriveLetter:\Program Files\Sumo Logic Collector\java1.8_201\bin", that means that if you want to use the JRE provided with the collector on Windows, you will need to adjust the JAVAPATH designation in the .bat file.
One way to ensure that Java is always in the same path (even if the collector gets upgraded) is to install the Java 1.8 JRE onto the Windows machine yourself, and point the JAVAPATH in the .bat file to that Java's bin location.
If the issues isn't java related, can you provide more details on what the errors are that you are seeing?
-
Hi Adam,
At the moment I think the issue is the script syntax within the batch file.
This is what I get when trying to run the bat file.
C:\>E:\sumojanus\sumojanus\bin\SumoJanus_Okta.bat
C:\>REM Make sure JAVAPATH below is correct for your environment
'E:\Program' is not recognized as an internal or external command,
operable program or batch file. -
Jim,
Got it. The culprit in this situation is likely the "working directory". Assuming that everything is located in the E:\sumojanus\sumojanus directory, try to run the .bat file while "in" the e:\sumojanus\sumojanus directory. Since the .bat file is looking at a path for the stuff it needs underneath where it is launched, if you are on C: when you execute, it won't run properly.
so: e:\sumojanus\sumojanus, then .\bin\SumoJanus_okta.bat
that should work.
--Adam
-
Thanks Adam. I am a lot further than I was. After executing this from the sumojanus directory instead of the bin directory I am now getting an Activator start error. I am probably making this more difficult than it is, but it is really frustrating and SumoLogic support keeps referring me to the document they have.
11 Apr 2019 08:47:13,679 INFO OktaCollectorActivator:90 - com.sumologic.content.tools.apiclient.service.output.ISumoOutputService FOUND!
11 Apr 2019 08:47:13,695 INFO OktaCollectorActivator:90 - Now searching for config sections:
SumoLogic auto-deploy install: org.osgi.framework.BundleException: Activator start error in bundle com.sumologic.content.tools.apiclient.OktaCollector [3]. - java.lang.Exception: No configuration available
11 Apr 2019 08:47:13,695 INFO OktaCollectorActivator:90 - com.sumologic.content.tools.apiclient.service.output.ISumoOutputService FOUND!
11 Apr 2019 08:47:13,726 INFO OktaCollectorActivator:90 - Now searching for config sections:
ERROR: Bundle com.sumologic.content.tools.apiclient.OktaCollector [3] Error starting/stopping bundle. (org.osgi.framework.BundleException: Activator start error in bundle com.sumologic.content.tools.apiclient.OktaCollector [3].)
java.lang.Exception: No configuration available
at com.sumologic.content.tools.apiclient.bundles.oktacollector.OktaCollectorActivator.start(OktaCollectorActivator.java:101)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2220)11 Apr 2019 08:47:13,726 ERROR SumoJanus:443 - Unable to load bundle with jar file: nullat org.apache.felix.framework.Felix.startBundle(Felix.java:2138)
at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1557)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:338)
at java.lang.Thread.run(Unknown Source) -
Jim,
My understanding (and I am getting some verification on that) is that the 'felix' framework errors can be ignored, as that doesn't relate to the data we actually get back from Okta and is only a framework thing. If you can you confirm in that output that you aren't getting 'bad token' errors, you should be all set to get data once you have the Script Source configured to run the script. Just be sure to configure the working directory field configured the same way I described earlier for you to run it at the command line.
If you are getting bad token type errors, than you need to go into Okta as an admin to get an API token. If you had done that in the past, be aware that after 30 days, if a token hasn't been used, Okta disables it so you need to re do it. I am assuming that the token you have was generated within the last 30 days, so that shouldn't be an issue, but want to make sure.
-
Ok thanks. My token is valid. The error I think that is crashing it is this:
11 Apr 2019 08:47:13,726 INFO OktaCollectorActivator:90 - Now searching for config sections:
ERROR: Bundle com.sumologic.content.tools.apiclient.OktaCollector [3] Error starting/stopping bundle. (org.osgi.framework.BundleException: Activator start error in bundleOr are you saying that is part of the "felix" framework error?
-
Hi Jim,
Sorry for the experience.
1) +1 with Adam, in general for any SumoJanus-based script, if you test from the shell, you need to run from under sumojanus folder:
bin/SumoJanus_Okta.bat ..
or
bin/SumoJanus_SFDC.bat ..
It seems you got over that point.
2) As for any stacktrace, most of the lines are just cascade error and usually the main exception will reveal the cause. In your example, I see "java.lang.Exception: No configuration available" which tells me the Okta configuration is not there (See Step 4 https://help.sumologic.com/07Sumo-Logic-Apps/20SAML/Okta/Collect-Okta-Logs). Can you check?
-
Since we are talking about WIndows deployment, another issue I have seen occasionally is an exception related to felix-cache. This happens when SumoJanus (which uses Apache Felix) fails to write cache files to the sumojanus folder. In that case either you need to rerun it on a shell with admin privilege, or right click the folder, go to Security and uncheck Read Only option for that folder.
Please sign in to leave a comment.
Comments
16 comments