Hi Marcelo,
We do not currently have an estimate on the creation of the proposed catalog - we are currently investigating the best ways to consolidate existing and future OpenDXL community topic/message information.
We do not have a set release date for any of the packages as of yet. However, there are several releases planned for the next few months specifically centering around the OpenDXL Node-RED extension, so you can expect to see updates fairly soon.
We're excited to provide this new tool to the community, and we're working to get it into your hands as soon as possible!
When it comes to determining the danger posed by external files, there are a number of reputation providers that have OpenDXL solutions available for community use (many of which can be found under the Threat Detection category.
As far as hooking up those solutions to tools like Jabber or Lync, an intermediary tool or service hook would need to be created that made use of the above Threat Detection solutions. We encourage community members like yourself with unique requirements to experiment, and feel free to use existing solutions to create new ones that address needs such as these!
McAfee Advanced Threat Defense (ATD) is a prerequisite for this client to work as intended, but does not need to be on the same system. The OpenDXL ATD Fortinet Python Client is designed to be run on any system on your network that can communicate with your DXL Broker(s).
Let me know if any part of the configuration instructions is not clear.
Nolan
Additionally you can configure the services on the system to start the start the Docker daemon on system boot. Which, once started, would adhere to the restart policy you have configured using the link in chrissmith's post above.
The new OpenDXL JavaScript Client is a Node.js-based client that should provide the flexibility you're looking for, check out the documentation to help you get started!
Certificate-based topic authorization configuration settings that have been set on one ePO Server in a Multi-ePO environment will be applied to the entire Multi-ePO fabric, as long as all ePO Extensions and DXL Brokers in the Multi-ePO environment are DXL 4.0 and above.
It may take up to 24 hours by default for certificate-based topic authorization policy to propagate across the entire Multi-ePO fabric.
There is an upcoming solution for smoothly integrating DXL services and events with Node-RED. It will allow users to hook up any tool or service to Node-RED and easily send or receive DXL messages.
In the meantime, the OpenDXL Data Bridge solution is currently available and incorporates some Node-RED functionality.
The OpenDXL Java Client does not currently have a scheduled release date, unfortunately. Our development team is listening and is definitely aware of the community demand for a Java client that works with OpenDXL - as it is, our current aim is to bring it in scope as soon as possible.
For a client with a third-party certificate (such as one generated by the steps you referred to in the OpenDXL Python Client Documentation) to be able to connect to a broker in any DXL fabric, that certificate/authority must be imported into ePO and distributed to the DXL brokers on that fabric.
In a Multi-ePO environment, an ePO server and the brokers on its DXL fabric will not export third party certs to the other ePOs/fabrics. The administrator must perform this action manually in the ePO Server Settings for "DXL Certificates (Third Party)" for any other fabric in the Multi-ePO environment to which the client is expected to be able to connect.
The minimum version of the OpenDXL Python Client that supports the CLI is 4.0.0.416, which is the most recent version at the time of this post.
The CLI for this version of the client currently supports:
(Copied from release notes)
By design, DXL will only deliver messages to clients that are connected at the time they are published and does not provide a mechanism for storing messages for later use.
However, it is certainly possible to build a solution that handles the storage itself. In fact, there are upcoming solutions expected in the near future to provide features that will provide at least some degree of this functionality.
We have contacted the solution developer over this issue, if there is indeed a bug or some other problem (documentation, perhaps) it should be addressed in the near future.
In the meantime, you can protect against this error by checking the length of the command line arguments supplied to the script to handle the problem gracefully. For example:
It looks like you are trying to use an application generated by OpenDXL Bootstrap's application-template generation function, rather than a client based on the client-template. This is apparent for two reasons: the name of your client file is app.py, which is the default name of the client file created by the application template, and this error in your output:
TypeError: object of type 'DxlClient' has no len()
This is a result of the difference in the __init__ used for OpenDXL Bootstrap application templates and client templates.
In the application template, the __init__ for your client will look like this:
In the client template, it will look like this:
As you can see, the constructor in the application template does not take in a DxlClient as an argument, and is instead attempting to use the DxlClient you passed it as a file path.
The Fix:
The simplest way to fix this issue would be to generate a new client template using the instructions found here: OpenDXL Bootstrap Tutorial Part 4: Create Client Wrapper.
When running the distribution script generated by OpenDXL Bootstrap, the Python Wheel library is required for the script to be able to create a .whl package. You can check if you have the Wheel library installed by entering > pip show wheel .
If wheel is already installed, you will see an output similar to this:
If wheel is not installed, you will see a blank response:
To install the Wheel library, simply use > pip install wheel from the command line.
Yes, that is the most likely scenario.
It is correct that calling dxlclient.client.DxlClient.add_event_callback() with subscribe_to_topic set to True or leaving it to the default value (also True) will automatically subscribe the DxlClient to the specified topic in the topic parameter. This means that there is no need for your client code to subscribe to the topic as an additional step.
The sample code for dxlclient.client.DxlClient.subscribe() specifically sets the subscribe_to_topic parameter of add_event_callback() to False to prevent the automatic subscription, and justify the usage of separately calling subscribe() for the code example.
As for why you would ever want to call subscribe() yourself, that depends on the specific needs of your client.
* As a quick note, the Certificate Authority (CA) and certs (key-pair for client) are required for all OpenDXL Python Client solutions, not just the OpenDXL ePO DXL Service.
The steps for generating the CA and certs, and the following import/export actions can be found in the OpenDXL Python Client SDK documentation:
Yes, in almost every case outgoing DXL messages should be encoded and incoming messages should be decoded.
Because the DXL message payload is simply binary data, failing to encode data types that have system dependencies (or other factors) can result in an unexpected format for the data when it is received. By using .encode(), the message sender standardizes the format of the payload so that the receiver(s) can use a matching .decode() call and smoothly interpret the payload as intended.
To help simplify the process of writing your DXL client code, we recommend using OpenDXL Bootstrap. The bootstrapper includes the MessageUtils class, which provides methods for basic encoding/decoding objects and managing Python dictionaries as JSON payloads.
clara_kt is correct. In almost all cases, it is simpler and generally safer to use the Python keyword with to avoid having to make the call directly. See the example below: