lordhepipud / icingaweb2-module-windows Goto Github PK

Checking the memory with the icingacli with percentage values is using wrong comparison:

icingacli windows check memory --host "example.com" --warning_percent 10 --critical_percent 5

Expected Behavior

The check should become warning once the free memory usage is below 10% and critical while it is below 5%

Current Behavior

The check will return Ok at the moment and goes warning / critical in case the memory usage is below or equal 10%

Possible Solution

Fix the comparison

The error I had with the icinga-module-windows
Icinga/icinga-powershell-framework#12

was caused by an error in this update statement:
/usr/share/icingaweb2/modules/windows/library/Windows/CheckResultApi/ApiHandler.php, line 97:
Filter::expression('host_id', '=', $this->json['fqdn'])

should be:
Filter::expression('host', '=', $this->json['fqdn'])

We should add a handling allowing the user reschedule the fetching of Host informations for each single side to allow a better view of current data for checks beeing set with a high delay.

There should be an easy way to determine if a Windows Host is pending a reboot caused by Windows updates.

This should be added to the Updates view including to the Host Overview itself.

The interface overview for the network bandwith is currently displayed as KB, MB or GB which should corretly be KB/s, MB/s or GB/s

Expected Behavior

The interface overview for the network bandwith should corretly be KB/s, MB/s or GB/s

Current Behavior

The interface overview for the network bandwith is currently displayed as KB, MB or GB

Possible Solution

Add custom formater for traffic/s

We should be able to get a detailed view of Network Hardware informations to determine which hardware is installed.

Hosts are not displayed under the Hosts view. What conditions must be met on the host?

Running Icinga Cli checks for the Windows Module for unapproved hosts might cause crashes / wrong outputs.

Expected Behavior

The module should return a warning and a message that the host is not approved

Current Behavior

The module tries to check the data for the hosts, which might run into problems

Possible Solution

Add check if the host is approved before executing the module.

Some hardware devices do not provide the max capacity value (bandwith) for the interface. This will result in possible broken usage bars.

Expected Behavior

The usage bar should use the hardware information and - if available - fall back to the performance counter bandwith in case the hardware is not providing the limit itself.

Current Behavior

The capacity is displayed as 0

Possible Solution

Add fallback to performance counter bandwith in case available.

Add a view for Windows Time Server and NTP configuration to easily have a look on the configuration.

In addition make these informations checkable by Icinga 2.

Hello,
nice module. I try it on my test system.
I got the following errors at step:
mysql -umyuser -p icinga_windows < /usr/share/icingaweb2/modules/windows/schema/mysql.sql

ERROR 1067 (42000) at line 50: Invalid default value for 'timestamp'
ERROR 1101 (42000) at line 66: BLOB, TEXT, GEOMETRY or JSON column 'proc_cmd' can't have a default value
ERROR 1101 (42000) at line 286: BLOB, TEXT, GEOMETRY or JSON column 'help' can't have a default value
ERROR 1101 (42000) at line 294: BLOB, TEXT, GEOMETRY or JSON column 'network_addresses' can't have a default value
ERROR 1101 (42000) at line 313: BLOB, TEXT, GEOMETRY or JSON column 'dependent_services' can't have a default value
ERROR 1101 (42000) at line 313: BLOB, TEXT, GEOMETRY or JSON column 'service_handle' can't have a default value
ERROR 1101 (42000) at line 313: BLOB, TEXT, GEOMETRY or JSON column 'depends_on' can't have a default value

My environment is:
Ubuntu 16.04
MySQL 5.7
Icinga2 2.9
Icingaweb2 2.6.2

After some little modifications the import works:

54c54
<       `timestamp` TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP,
---
>       `timestamp` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
77c77
<   `proc_cmd` LONGTEXT NOT NULL DEFAULT '',
---
>   `proc_cmd` LONGTEXT NOT NULL,
290c290
<   `help` TEXT NOT NULL DEFAULT '',
---
>   `help` TEXT NOT NULL,
306c306
<   `network_addresses` TEXT NOT NULL DEFAULT '',
---
>   `network_addresses` TEXT NOT NULL,
317c317
<   `dependent_services` TEXT NOT NULL DEFAULT '',
---
>   `dependent_services` TEXT NOT NULL,
319,320c319,320
<   `service_handle` TEXT NOT NULL DEFAULT '',
<   `depends_on` TEXT NOT NULL DEFAULT '',
---
>   `service_handle` TEXT NOT NULL,
>   `depends_on` TEXT NOT NULL,

But now i got an error an agent error:

2018-29-11 15:45:22.994 [Debug]: {"status":"error","message":"SQLSTATE[22007]: Invalid datetime format: 1292 Truncated incorrect DOUBLE value: 'testclient.test.de', query was: UPDATE host_list SET os = :os, version = :version, port = :port WHERE host_id = 'testclient.test.de'"}
2018-29-11 15:45:22.996 [Debug]: Remote Server Output: 500

Many thanks for all your work.
Hopefully i don't forget any thing.

Add a timer similar to Icinga Web 2 checks for the Host overview, determining when the last PowerShell connection has been established.

We should also sort the Host list by inactive hosts.

The Pending Update detail view is displaying if an update is downloaded or requires a reboot. The status however is checked wrongly, causing the status to always remain No.

Expected Behavior

The status should display properly if the update is downloaded or requires a reboot.

Current Behavior

Both status informations will always display No, regardless of the status.

Possible Solution

Fix the comparison of the values of the current status.

In addition to the Network Hardware view, we should be able to include the routing tables for each interface available.

Add views for each single Hardware Disk to get a detailed look on the hardware itself.

In general it should be possible to install Windows Updates from the Icinga Web 2 module, in case the following requirements apply:

• The PowerShell Module is running with sufficient permissions to install updates
• The PowerShell Module has the command for installing updates enabled (disabled by default)
• The Icinga Web 2 users inherits the permission to install updates

If one of the above requirements is not fulfilled, this feature is disabled within the Web Module

We should add a better visibility for pending schema migrations of the database to inform the user about required changes.

This could be handeled similar to the Icinga Director (the blue bubble at the navigation) including a Apply Pending Schema Migration button at the top of the host overview.

The handling of the module to build the Host FQDN being registered on the Web is returning wrongly the Workgroup in some cases. This should either include the DNS Suffix or leave only the hostname

Expected Behavior

A Workgroup should never be attached to the hostname

Current Behavior

In case the host is not part of a Domain, the Workgroup is attached, like example.WORKGROUP

Possible Solution

Properly fetch the hostname by using

[System.Net.Dns]::GetHostEntry('localhost').HostName

Installing updates from the Module itself should in general be possible. This will require the following:

• The PowerShell Module has to be running with sufficient permissions to allow this feature
• The 'command' for installing updates has to be enabled within the PowerShell module (disabled by default)
• The Icinga Web 2 User requires the permission to be able to install updates

Right now we have a dependency on the Icinga Director which we should remove in order to keep compatibility with future releases of the module.

Possible Solution

Replace the Icinga Director dependency with

• ipl
• incubator

Some Bios manufactures / hypervisors are not returning a service tag for the bios, resulting on no way to load the Bios information details view

Expected Behavior

The link for bios details should be displayed regardless of the service tag being set.

Current Behavior

The service tag including the link for the host bios details is not displayed-

Possible Solution

Add an extension to the Bios Service tag called (Details) or some similar way

With the current DB schema, disk informations will break the DB insert query because the total sector integer length is too small.

Expected Behavior

The total sector could should be written regardless of it's length

Current Behavior

The insert fails with an SQL error

2018-12-12 18:49:11.014 [Debug]: {"status":"error","message":"SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'total_sectors' at row 1, query was: INSERT INTO host_hardware_disk (host_id, disk_id, description, firmware_revision, drive_reference, caption, total_heads, model, size, partitions, serial_number, scsi_target_id, scsi_logical_id, scsi_port, media_type, bytes_per_sector, total_tracks, total_cylinders, scsi_bus, signature, total_sectors, sectors_per_track, manufacturer, capabilities) VALUES (:host_id, :disk_id, :description, :firmware_revision, :drive_reference, :caption, :total_heads, :model, :size, :partitions, :serial_number, :scsi_target_id, :scsi_logical_id, :scsi_port, :media_type, :bytes_per_sector, :total_tracks, :total_cylinders, :scsi_bus, :signature, :total_sectors, :sectors_per_track, :manufacturer, :capabilities)"}
2018-12-12 18:49:11.014 [Debug]: Send modules Bios,Windows,Cpu,Disk,Memory,Network,Hardware results to server. Received result: 500

Possible Solution

Fix DB schema to allow larger amount of total sector bytes