Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Flatly)
  • No Skin
Collapse
Brand Logo

NetXMS Forum

N

noel

@noel
Unfollow Follow
About
Posts
17
Topics
7
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Script based DCIs broken after update
    N noel
    Support

    Thanks for the info, after reading the docs about Agent External Metrics I converted the actions to shell form metrics and now it works fine.

    (Before I read the docs I tried the format you provided, but that had some issues which didn't trigger an alarm so I have no idea what was wrong with that.)


  • Script based DCIs broken after update
    N noel
    Support

    I recently upgraded our NetXMS server (and agent) listed below:
    netxms-agent:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
    netxms-server:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
    and later (due to this issue)
    netxms-agent:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm)
    netxms-server:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm).

    I had two similar DCIs like this: origin: script, metric: Ping("1.1.1.1",1)

    And the following script behind:

    if ($2) {
    	cmd = "ping-suli";
    } else {
    	cmd = "ping-voda";
    }
    println("Using: " .. cmd);
    res = $node.executeAgentCommandWithOutput(cmd, $1);
    if (res.length == 0) return null;
    return res;
    

    Both DCIs error with the following: Script (Ping) execution error: Error 14 in line 8: Function or operation argument is not an object

    But if I use the execute script function with params: "1.1.1.1",1 to run the ping on the same node I get the expected result:

    Using: ping-suli
    
    
    *** FINISHED ***
    
    Result: 25.2
    

    This issue started after the first upgrade and persisted after the second.


  • (Option to) Don't interpolate missing data
    N noel
    Feature Requests

    I have several DCIs for ping times that do not report data if the ping fails and display them on a dashboard, but currently netxms interpolates between all data points, it would be nice if it took the polling rate into account and instead of interpolating a large gap, it would fill the gap with a specific color.

    Attached two images how it currently looks like and how I imagined this feature. As you can see on the first image it's barely visible that there were missing pings, but on the second you can tell that at a glance.


    line-chart.png

    line-chart-no-interpolation.png


  • nxdbmgr migration fails, too large record
    N noel
    Support

    Attached the database list and two binary files created with psql copy, one is just the message value, the other is the entire record.


    bad-log.bin

    bad-log-message.bin

    db-list.txt


  • nxdbmgr migration fails, too large record
    N noel
    Support

    The old server has already been shutdown, but I'll try my best to get the info from it this week. I'll be able to post the entire record as-is since it didn't contain any sensitive data iirc.

    I no longer have the failed record error message, but in the original post you can see the start of the message, it just continued with all the fields of the failed record.


  • nxdbmgr migration fails, too large record
    N noel
    Support

    I used pg_dump and psql to migrate the database to the new location, which was successfull. Currently I'm waiting on the timescale conversion to complete.

    Edit: TimescaleDB inplace migration also completed successfully. NetXMS is now running on the new host.


  • nxdbmgr migration fails, too large record
    N noel
    Support

    Old db:

    netxms=# \d win_event_log
                            Table "public.win_event_log"
          Column      |          Type           | Collation | Nullable | Default
    ------------------+-------------------------+-----------+----------+---------
     id               | bigint                  |           | not null |
     event_timestamp  | integer                 |           | not null |
     node_id          | integer                 |           | not null |
     zone_uin         | integer                 |           | not null |
     origin_timestamp | integer                 |           | not null |
     log_name         | character varying(63)   |           |          |
     event_source     | character varying(127)  |           |          |
     event_severity   | integer                 |           | not null |
     event_code       | integer                 |           | not null |
     message          | character varying(2000) |           |          |
     raw_data         | text                    |           |          |
    Indexes:
        "win_event_log_pkey" PRIMARY KEY, btree (id)
        "idx_win_event_log_node" btree (node_id)
        "idx_win_event_log_timestamp" btree (event_timestamp)
    

    New db:

    netxms=# \d win_event_log
                             Table "public.win_event_log"
          Column      |           Type           | Collation | Nullable | Default
    ------------------+--------------------------+-----------+----------+---------
     id               | bigint                   |           | not null |
     event_timestamp  | timestamp with time zone |           | not null |
     node_id          | integer                  |           | not null |
     zone_uin         | integer                  |           | not null |
     origin_timestamp | integer                  |           | not null |
     log_name         | character varying(63)    |           |          |
     event_source     | character varying(127)   |           |          |
     event_severity   | integer                  |           | not null |
     event_code       | integer                  |           | not null |
     message          | character varying(2000)  |           |          |
     raw_data         | text                     |           |          |
    Indexes:
        "win_event_log_pkey" PRIMARY KEY, btree (id, event_timestamp)
        "idx_win_event_log_node" btree (node_id)
        "idx_win_event_log_timestamp" btree (event_timestamp)
    Triggers:
        ts_insert_blocker BEFORE INSERT ON win_event_log FOR EACH ROW EXECUTE FUNCTION _timescaledb_functions.insert_blocker()
    

    I also checked the length of the problematic record in the old db:

    netxms=# select length(message) from win_event_log where id = 7335338;
     length
    --------
      2000
    (1 row)
    

    I tried the normal to normal migration but it failed with the same error.

    Additional info:
    Old db version:

    postgres=# select version();
                                                                    version
    ----------------------------------------------------------------------------------------------------------------------------------------
     PostgreSQL 14.15 (Ubuntu 14.15-0ubuntu0.22.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
    (1 row)
    

    New db version:

    postgres=# select version();
                                                           version
    ---------------------------------------------------------------------------------------------------------------------
     PostgreSQL 15.10 (Debian 15.10-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
    (1 row)
    

  • nxdbmgr migration fails, too large record
    N noel
    Support

    I'm trying to migrate NetXMS from a physical host to an LXC container and also upgrade to TimescaleDB.

    I installed NetXMS 5.1.3 in the container and initialized a postgres 15 database with timescaledb, then I upgraded the existing host to the same version and stopped the service in both locations.

    Then I run

    nxdbmgr migrate old_netxmsd.conf
    

     which started the migration, but failed with a Windows Event log:

    Migrating table win_event_log
    SQL query failed (22001 ERROR:  value too long for type character varying(2000)):
    INSERT INTO win_event_log (id,event_timestamp,node_id,zone_uin,origin_timestamp,log_name,event_source,event_severity,event_code,message,raw_data) VALUES (?,to_timestamp(?),?,?,?,?,?,?,?,?,?)
    Failed input record:
    

    (Truncated the event data, but it was also printed.)

    I thought about removing records in the source db which violate the new constraints to complete the migration, but what about new records that netxms will attempt to insert in the new db?

    What should I do in this case?


  • Should Agent IDs be unique?
    N noel
    Support

    I just deployed 30+ PCs from a sysprepped image with WDS and noticed that all agent IDs are the same, but - so far - it didn't cause any issues and I can't see alerts related to this - like you get for duplicate MAC addresses. So I'm wondering does it have to be unique? If so, what step(s) should I take during sysprepping in the future (and also now after the deploy) to make it unique? If not, then what's the purpose of that ID?
    Tried looking it up in the admin guide, but couldn't find anything related to imaging with an agent install or what's the role of this ID.


  • Customizable syslog in dashboard
    N noel
    Feature Requests

    I like to keep an eye on our squid proxy traffic on the dashboard, but I'm only interested in the message column, which gets squished by the first 6 columns, I can resize them one-by-one to zero width but that also gets lost on a refreh.
    I'd like to see an option to hide columns and/or save their width percentages.


  • Windows Even Log parser rule causes server crash
    N noel
    Support

    Finally with the next regex I managed to get it working, so it's only matching admin users' logins:

    Virtuális fiók:\t\tNem.*Emelt szintű jogkivonat:\t\tIgen.*Fióknév:\t\t(\w+).*Fiók tartománya:\t\t(?!NT AUTHORITY)
    

  • Windows Even Log parser rule causes server crash
    N noel
    Support

    I did manage to get events when trying simple regexes that didn't try to match multiple lines of windows log messages.
    But I'm a bit confused now about what is the tested string, since the docs only mention single lines, but the windows event is multiple lines and when I simply put (.*) as the match regex, in the event %1 was a multi line string with the full windows event message; which is strange since as far as I know . matches everything except new line; but either way the regex I used had . and explicit \r\n matched multiple times so it should've catched each case, also it worked when I tested it on regexr.com


  • Windows Even Log parser rule causes server crash
    N noel
    Support

    I tried creating a template and added a log parser policy with the following content:

    <parser checkInterval="1" name="Admin activity parser">
       <macros/>
       <file>*Security</file>
       <rules>
          <rule name="Login">
             <match repeatCount="0" repeatInterval="3600" reset="false">Emelt szintű jogkivonat:\s+Igen(?:.|\r\n)+Fióknév:\s+(\w+)</match>
             <event>VV_ADMIN_LOGON</event>
             <id>4624</id>
             <push group="1"></push>
             <agentAction action=""></agentAction>
          </rule>
       </rules>
    </parser>
    

    It didn't crash the server however it also doesn't trigger the event, I tried to:

    • reduce the checkInterval from the default 10000 to 1 (what is the unit for this?)
    • make the regex match the whole message
    • use literal \r\n and \t in the expression

    I made sure that the template is applied to the node I'm testing with, and in the windows events view I can see the windows event for the login. Also I'm still running netxmsd from gdb and I can only see entries like this and nothing else when I log into an account on the client:

    *D* [agent.conn.10794   ] AgentConnectionEx::onWindowsEvent(): Received event from agent at 10.255.7.114, node ID 1814
    

  • Windows Even Log parser rule causes server crash
    N noel
    Support

    Attached the full bt output. I'll also try the suggested method and get back with the results.


    gdb.txt


  • Windows Even Log parser rule causes server crash
    N noel
    Support

    Hi,

    I'm trying to set up a log parser rule that would trigger an event if an administrator logs on to a monitored computer, however this rule causes the NetXMS server to crash with segmentation fault.

    NetXMS Server versions that I've tried: 4.5.3, 4.5.4

    The parser which causes the crash (made it with the GUI then switched to the XML view):

    <parser name="Default parser">
       <macros/>
       <rules>
          <rule name="Admin logon">
             <match repeatInterval="0" reset="false">Emelt szintű jogkivonat:\s+Igen(?:.|\n)+Fióknév:\s+(\w+)</match>
             <event>VV_ADMIN_LOGON</event>
             <id>4624</id>
             <agentAction action=""></agentAction>
          </rule>
       </rules>
    </parser>
    

    Windows event 4624 is created when a user logs in and with this rule I'd like to check if they're an administrator and what is their name. (The monitored desktops run Windows 10 with Hungarian language.)

    How could I solve this?


  • executeAgentCommand fails successfully
    N noel
    Support

    TLDR: Use $ErrorActionPreference = "Stop" so the agent knows one of the script's command failed.

    Found the root cause, but I forget to post it here. Despite several issues and discussions on winget-cli's github suggesting it can be run in system context it turns out that it is in fact impossible. So when i tried to execute it with the agent it returned instantly with a non zero exit code, but the ps script returned normally due to the lack of $ErrorActionPreference = "Stop" which would have caused the agent to recognise the script had failed.

    For now I'll use chocolatey with a custom caching proxy that rewrites packages - so even external resources can be cached locally by nginx - until MS figures out how to create a usable package manager.

    P.S.
    Thank you for the tip about auto termination, I'll keep that in mind. Also sorry for the late reply.


  • executeAgentCommand fails successfully
    N noel
    Support

    I'd like to automate the installation of applications on Windows 10 machines with winget and two scripts.
    I have the following script on the host in c:\wg.ps1

    $p=Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
    echo "Winget path is: '$p'"
    & "$p\winget" $args
    

    (This script fixes MS logic to not make winget available from the system context.) It works fine when invoked from an elevated cmd like this:

    powershell -Command c:\wg install -e -h --accept-package-agreements --accept-source-agreements --log c:\install-log.txt --scope machine --id Notepad++.Notepad++
    

    I also have the following nx script to install a few programs:

    pkgIds = %(
    "VeyonSolutions.Veyon --custom /NoMaster",
    "Git.Git",
    'Microsoft.VisualStudioCode --custom "--add \"Microsoft.VisualStudio.Workload.ManagedDesktop;includeRecommended\" --add \"Microsoft.VisualStudio.Workload.NetWeb;includeRecommended\""',
    "GIMP.GIMP",
    "Inkscape.Inkscape",
    "OpenJS.NodeJS",
    "ApacheFriends.Xampp.8.2",
    "Oracle.VirtualBox",
    "RARLab.WinRAR",
    "mcmilk.7zip-zstd",
    "Notepad++.Notepad++",
    "Python.Python.3.11",
    "AivarAnnamaa.Thonny",
    "Ghisler.TotalCommander",
    "Adobe.Acrobat.Reader.64-bit",
    "Postman.Postman"
    );
    
    println("Installing winget packages");
    for (pkg : pkgIds) {
        print("Installing " . pkg . ": ");
        cmd = "-Command c:\wg install --accept-package-agreements --accept-source-agreements --log c:\install-log.txt -h -e --scope machine --id " . pkg;
        res = $node->executeAgentCommand("ps", cmd);
        println(res ? "OK" : "FAILED");
    }
    println("End of winget installation");
    

    and the ps action is defined like this in the agent config:

    Action = ps:powershell $1
    

    When I run the script it scrolls through all the packages in about 2 sec and prints OK for all of them when they clearly didn't succeed.
    By now I spent 3-4 days with this issue and I just can't figure out where is the problem and I'm out of ideas what to try.
    I verified that the wg.ps1 works by executing it from cmd, I verified that the nx script works by replacing the wg script with one that prints the args to a txt file.

  • Login

  • Don't have an account? Register

  • Login or register to search.
Powered by NodeBB Contributors
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups