NetXMS Support Forum

Hi all, upgraded recently to 4.1.283 server and nxmc. 

Just tried a walk with the MIB explorer and noticed that the "OID as text" column is not being populated for anything in the entire compiled MIB tree that netxms uses.

So the OID as text column at the bottom of the panel and the field on the right of the explorer are both only displaying ".iso" rather than the text path as in the past.

Tried recompiling with nxmibc and still the same.  Has anyone else noticed this?

edit:
to clarify, the MIB tree on the left has the OID as text built properly in the tree.  But that same tree path is not shown in the OID as text fields.  See attached screenshot.

The fact the tree works makes me think the compiler is building properly and perhaps its a bug in the nxmc?

Hi, I tried updating using the package, and using the netxms-keyring.gpg however I found I still got the old version expiring on the 24/3 with those.

Seemed only the third option (curl --proto '=https' --tlsv1.2 -sSf https://packages.netxms.org/netxms.gpg | apt-key add -) gave me the updated key and allowed apt update to work?

Hi after installing the windows x64 agent 4.0.2088 I can see in the windows event log errors under eventid 1000 regarding openssl and sqlite:


- Cannot load user agent notifications (local database is unavailable)
- Compile time OpenSSL version (101010bf) does not match runtime OpenSSL version (1010107f)
- Unable to load database driver module "sqlite.ddr": The specified module could not be found.
- Cannot load SQLite database driver
- Local database unavailable


I've noticed the agent seems to stop occasionally and some polls from the management console complains about missing policy database.  Is this related to the sqlite.ddr module missing on the agent side?


[09.02.2022 13:46:10] Checking node's capabilities...
[09.02.2022 13:46:10]    Checking NetXMS agent...
[09.02.2022 13:46:10]    NetXMS agent is active
[09.02.2022 13:46:10]    Reading list of available Windows Performance Counters...
[09.02.2022 13:46:11]    168 counters read
[09.02.2022 13:46:11]    File manager is not available
[09.02.2022 13:46:11]    Checking agent policy deployment
[09.02.2022 13:46:11]       Cannot get policy inventory from agent (Agent database failure)


Thanks for the great work all.  I notice NPI files aren't published for the agent binaries, are they no longer needed to upload a package for deployment?

Thanks Alex, I'm assuming I've got jetty on that VM from testing out the nxmc web console in the past.  Seems the 1.x series on my VM is not vulnerable to this CVE in any case.

This github repo has hashes of vulnerable versions of the library and the link to the apache repo suggest ver 1.x might also be vulnerable too. 

I'm guessing installing jetty for the web console is what brings in log4j dependencies?

Hi, is netxms affected by log4j CVE-2021-44228?

Running a search on a debian VM with netxms installed shows:

# find / -name *log4j*
/var/lib/dpkg/info/liblog4j1.2-java.md5sums
/var/lib/dpkg/info/liblog4j1.2-java.list
/usr/share/java/slf4j-log4j12-1.7.22.jar
/usr/share/java/log4j-1.2-1.2.17.jar
/usr/share/java/log4j-over-slf4j.jar
/usr/share/java/ant-apache-log4j-1.9.9.jar
/usr/share/java/slf4j-log4j12.jar
/usr/share/java/log4j-1.2.jar
/usr/share/java/log4j-over-slf4j-1.7.22.jar
/usr/share/java/ant-apache-log4j.jar
/usr/share/maven-repo/org/apache/ant/ant-apache-log4j
/usr/share/maven-repo/org/apache/ant/ant-apache-log4j/debian/ant-apache-log4j-debian.pom
/usr/share/maven-repo/org/apache/ant/ant-apache-log4j/debian/ant-apache-log4j-debian.jar
/usr/share/maven-repo/org/apache/ant/ant-apache-log4j/1.9.9/ant-apache-log4j-1.9.9.jar
/usr/share/maven-repo/org/apache/ant/ant-apache-log4j/1.9.9/ant-apache-log4j-1.9.9.pom
/usr/share/maven-repo/org/slf4j/log4j-over-slf4j
/usr/share/maven-repo/org/slf4j/log4j-over-slf4j/1.7.22/log4j-over-slf4j-1.7.22.pom
/usr/share/maven-repo/org/slf4j/log4j-over-slf4j/1.7.22/log4j-over-slf4j-1.7.22.jar
/usr/share/maven-repo/org/slf4j/log4j-over-slf4j/debian/log4j-over-slf4j-debian.jar
/usr/share/maven-repo/org/slf4j/log4j-over-slf4j/debian/log4j-over-slf4j-debian.pom
/usr/share/maven-repo/org/slf4j/slf4j-log4j12
/usr/share/maven-repo/org/slf4j/slf4j-log4j12/1.7.22/slf4j-log4j12-1.7.22.jar
/usr/share/maven-repo/org/slf4j/slf4j-log4j12/1.7.22/slf4j-log4j12-1.7.22.pom
/usr/share/maven-repo/org/slf4j/slf4j-log4j12/debian/slf4j-log4j12-debian.jar
/usr/share/maven-repo/org/slf4j/slf4j-log4j12/debian/slf4j-log4j12-debian.pom
/usr/share/maven-repo/log4j
/usr/share/maven-repo/log4j/log4j
/usr/share/maven-repo/log4j/log4j/1.2.17/log4j-1.2.17.jar
/usr/share/maven-repo/log4j/log4j/1.2.17/log4j-1.2.17.pom
/usr/share/maven-repo/log4j/log4j/1.2.x/log4j-1.2.x.jar
/usr/share/maven-repo/log4j/log4j/1.2.x/log4j-1.2.x.pom
/usr/share/doc/liblog4j1.2-java
/usr/share/ant/lib/ant-apache-log4j.jar
/usr/share/jetty9/resources/log4j.properties


I've read online that some say log4j ver. 1.x is not vulnerable to the JNDI issue, but can't confirm that myself.  Is netxms affected do you think?  Or are these jars brought in with openjdk/jetty only and not used?

I was worried that would be the case.  I'll look into some scripts to do this.

Cheers.

Hi gdodd I also get this error on latest agents when deploying it centrally to working agents.  In the past when I had this error it was because the agent version string had a build hash in the version string and the NPI had the correct version string.  Editing the NPI manually fixed that until the next agent release, but that doesn't seem to be the issue here, agent version and NPI seem to match for me.

Also having issues on older agents upgrading with .part01 appended to the end of installer transfers.  Have you had any of those issues too?

Quote from: gdodd on October 05, 2021, 04:10:21 AM
- Fixed bug in centralized agent upgrade on Windows

Does that mean once server and agent are on 3.9.298, future centralized agent upgrades should work? Or should it work with just server on 3.9.298?

I am trying to upgrade Windows agents 3.9.280 from Linux server 3.9.298 and get the "Agent's version doesn't match..." error message.

Still not having much luck with deploying central package upgrades even with new 3.9.298 for server/console and with agent packages.

Still get "file transfer failed" errors deploying to older windows nodes (since 3.9.235) that have not have their agents manually removed and re-installed locally (this in win7/10 32/64bit).  I can see in c:\netxms\var\ that there are duplicate copies of the 3.9.298 installer with part0 through part7 appended to the exe 1024 bytes each).  Does NX-2129 apply to agent deployment?

On the machines that I manually removed the agents and deleted the c:\netxms folder I'm also getting an error "Agents version doesn't match package version after upgrade" after central deployment even though as far as I can see NPI version string and installed agent version match (no build hash in the agent version for eg).

Where do agent install logs get saved locally, can't see anything in c:\netxms\logs (after taking ownership from SYSTEM).

Looks to be running under system, and hardened permissions are under that user. 

Server version is on 3.9.280, trying to upgrade windows 32/64 agents to 3.9.280 from a mix of 3.9.156 and 3.9.235

Perhaps not hardened permissions though, I've got one win10 and one win server 2016 that weren't installed with hardened permissions and had the same issue attempting to install from package manager.  Manual uninstall and reinstall of agent seems to fix it in that I don't then get file transfer failed errors in package manager when running a deployment (completed). 

I guess I only know if package manager install truly works when the next agent version is released to see if upgrades on these completed nodes also succeed then?

So definitely still getting the file transfer errors in .280 server/NXMC. 

If I manually uninstall the agent package on windows and take ownership of the c:\netxms folder and remove it (due to hardened system permissions) and then reinstall the agent package from scratch it starts working (in terms of file transfer and agent upgrades in the package manager).

So it looks like I might have to manually remove and reinstall out of band to netxms to get back to working.

Could it be an issue with hardened system permissions causing the file transfer / install to fail?  Guess you need logs next?

+1

Just tried new server and agent versions of .280 and still getting the same error when trying to push the agent install package to the end clients (files transfer failed).

Also if I manually try and run the windows 64bit installer I'm seeing errors about entry points in ssl libraries from the looks of it. Will attach some examples in the morning.

Great, thanks Filipp