NetXMS Support Forum

It would be good to disable syslog retention without disabling the syslog receiver and the log parser. Housekeeping keeps killing our NetXMS database server.

Some easy instructions for running EmailRelay 2.0.0 on 127.0.0.1:25 on Windows with an upstream SMTPS server.

• This configuration is for SMTPS and which uses publicly trusted TLS certificates that need to be verified.
• Assumes one is using SMTPS on port 465, change smtp.example.com to your desired SMTPS server.

1) Extract emailrelay-2.0-w64 into C:\NetXMS\emailrelay on the same system as the NetXMS server, change paths to suit your own environment
2) Create spool directory: C:\NetXMS\emailrelay\spool
3) Create config directory: C:\NetXMS\emailrelay\config
4) Place a Trusted CA Certificate bundle into C:\NetXMS\emailrelay\config\cacert.pem (Eg: From Mozilla or curl for public CAs or you'll need to make your own if your SMTPS server uses certificates signed by an internal CA)

5) Create C:\NetXMS\emailrelay\config\email.auth and put in any relevant authentication
Example: client plain [email protected] PasswordHere


6) Create batch file to start emailrelay.exe: C:\NetXMS\emailrelay\start-emailrelay.bat
start "emailrelay" "C:\NetXMS\emailrelay\emailrelay.exe" --interface=127.0.0.1 --interface=127.0.0.1 --port=25 --as-proxy=smtp.example.com:465 --client-auth=C:\NetXMS\emailrelay\config\email.auth --client-tls-connection --client-tls-required  --client-tls-server-name=smtp.example.com --client-tls-verify=C:\NetXMS\emailrelay\config\cacert.pem --spool-dir=C:\NetXMS\emailrelay\spool --pid-file=C:\NetXMS\emailrelay\emailrelay.pid --no-syslog
Change smtp.example.com to your desired SMTPS server.

7) Create C:\NetXMS\emailrelay\emailrelay-service.cfg
dir-config="C:\NetXMS\emailrelay\config"

8 ) Run as Administrator to install service:
C:\NetXMS\emailrelay\emailrelay-service --install

Remember to document the existence of the cacert.pem bundle and the need to manually update it.

It would be good if Event Processing Filtering Scripts, DCI Transformation Scripts etc. could be linked to scripts in the Script Library (not imported from Script Library, although that could be good too).
Not only would this allow for rapid reuse in a centralised manner, it would allow for easier change management if a script snippet is reused in many places. Currently, changing a calculation in a script snippet that's used by lots of DCI Transformation scripts across multiple objects would mean you have to go into each one and change it, if it was linked to a script in the Script Library, it would only need to be changed once.

This would be good, we utilise command line utilities to do it currently.

Would be good to be able create Windows Performance Counter DCIs using NXSL CreateDCI.

If there's one thing I've learned from using NetXMS and it's strict MIB parser is that most vendors MIBs don't follow best practices and also come prebundled with out of date IEEE and other common MIBs.

Does anyone else on here use the syslog feature with InnoDB? We keep having catastrophic performance issues when using it in any production capacity. How do others deal with this?

Would you please consider adding in nested group membership support for the LDAP Sync feature for Active Directory users?

AD supports Rule OID 1.2.840.113556.1.4.1941 (LDAP_MATCHING_RULE_IN_CHAIN) which is a special extended match operator that walks the chain of ancestry in objects all the way to the root until it finds a match (Requires DN).

We use it for our LdapSearchFilter already for importing users in nested groups, eg:
(&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=ACL-NetXMS-Users,OU=ACL,DC=example,DC=local))

-but, of course, this filter alone does't help when it comes to user membership of imported groups. Maybe it could be configured as a flag in Server Configuration that changes the group membership behaviour? I think LDAPConnection::updateMembers is responsible and would need to be changed?

I would support this too.

I should have looked more closely, even at my old nxshell scripts. Thanks.

For those looking to do this in SQL, here is some information:

Relevant data is kept in the object_properties table.
object_properties.status_prop_alg is the Propagate Status Method and acceptable values are defined in nxcldefs.h:307.

Default:
object_properties.status_prop_alg = 0

Unchanged:
object_properties.status_prop_alg = 1

Fixed to value:
object_properties.status_prop_alg = 2
object_properties.status_fixed_val is the Status it will be fixed to, acceptable values are 0 through 4 (netobj.cpp:1682) as defined in nxcldefs.h:138.

Relative with offset:
object_properties.status_prop_alg = 3
object_properties.status_shift is the offset applied to the actual status value.

Severity Based:
object_properties.status_prop_alg = 4
object_properties.status_translation is the mapping of actual status values to propogated ones. It is split into 4 segments of 2 characters which essentially represent the status integer for the respective slot.
First segment is the propagated status for a Warning status.
Second segment is the propagated status for a Minor status.
Third segment is the propagated status for a Major status.
Fourth segment is the propagated status for a Critical status.

So object_properties.status_translation of "00010303" would yield Normal (00 which is 0) being propagated for Warning, Warning (01 which is 1) being propagated for Minor, Major (03 which is 3) being propagated for Major and Major being propagated for Critical.

Example SQL Snippet (MySQL):
Set all matching interfaces (Interfaces with names that starts with "ge-") of node of ID 1234 to propagate status on a severity based (severity translated) basis and use the provided translation mapping:

UPDATE object_properties
INNER JOIN interfaces ON interfaces.id = object_properties.object_id
SET object_properties.status_prop_alg = 4, object_properties.status_translation = "01020303"
WHERE interfaces.node_id = 1234 AND object_properties.name LIKE "ge-%"


If I've made any mistakes, please let me know.

In NXShell, would you please consider implementing a AbstractObject.setStatusPropagationMethod or Interface.setStatusPropagationMethod method, or some other implementation that allows us to set status propagation, to allow for things like setting the status propagation of interfaces? Setting this up manually for many interfaces over many nodes is very tedious.

Someone else was, more or less, asking about this back in 2013 as well.

Are we able to have a board dedicated to it in SMF for the meanwhile?

We're using MariaDB, ALTER TABLE eventually failed, we just cleared the table in the end.
It would be useful if nxdbmgr check [check.cpp CheckDatabase() ?] would do a schema sanity check to see if the database matches the version is claims to be, I don't think it does this?

After looking at upgrade_v22.cpp I think I know what happened.
When the installer automatically tried to upgrade the database, it got stuck on ALTER TABLE syslog ADD zone_uin integer which caused the installer to exit abnormally and the subsequent errors from that.
I believe this happened because the syslog table is so large that ALTER TABLE syslog ADD zone_uin integer was taking a long time and the installer didn't like that too much. Is there an installer option to run the install without it doing the database upgrade within the installer? I think we'd prefer to run it manually ourselves in the future.