Comments

16 comments

  • Avatar
    Iterable Inc.

    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 1800

    I'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. 

    1
    Comment actions Permalink
  • Avatar
    Graham Bush

    Thanks for the help. Sumologic support has not been helpful.

    I am running this on a windows server and keep getting 

    <ERROR SumoJanus:499 - Could not create framework: java.
    lang.NullPointerException>

    Did you encounter this problem on linux and any idea what the problem might be?

    0
    Comment actions Permalink
  • Avatar
    Duc Ha

    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

     

    1
    Comment actions Permalink
  • Avatar
    Graham Bush

    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
    0
    Comment actions Permalink
  • Avatar
    Duc Ha

    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. 

     

     

     

     

     

    0
    Comment actions Permalink
  • Avatar
    Jim Baucom

    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

    0
    Comment actions Permalink
  • Avatar
    Adam Steckelman

    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?

    1
    Comment actions Permalink
  • Avatar
    Jim Baucom

    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.

     

     

    0
    Comment actions Permalink
  • Avatar
    Adam Steckelman

    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

    1
    Comment actions Permalink
  • Avatar
    Jim Baucom

    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: null

    at 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)

    0
    Comment actions Permalink
  • Avatar
    Adam Steckelman

    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.

     

    0
    Comment actions Permalink
  • Avatar
    Jim Baucom

    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 bundle 

     

    Or are you saying that is part of the "felix" framework error?

    0
    Comment actions Permalink
  • Avatar
    Adam Steckelman

    Jim,

    If you have time for a zoom session today, I will send you a zoom invite for 1pm and we can both look at what's been done, and what's possibly causing this.

    --Adam

    0
    Comment actions Permalink
  • Avatar
    Jim Baucom

    That would be great.  Is that 1PM CDT ?

    0
    Comment actions Permalink
  • Avatar
    Duc Ha

    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? 

    0
    Comment actions Permalink
  • Avatar
    Duc Ha

    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.

    0
    Comment actions Permalink

Please sign in to leave a comment.