icinga hostgroup object_name interpretet as integer causes postgres error

[cschra]

Expected Behavior

Hostgroups can have simple numbers as object_name and matching can also done with integers.

Current Behavior

Activitylog detail tab and some other pages are not displayed. Instead a stacktrace is shown.

Possible Solution

My temporary solution is to check for integer value and convert it to string -> this is a bit ugly but does the job.

director/library/Director/Objects/IcingaObjectGroups.php:186

         if (is_int($group)) {
             $group = "$group";
         }

Steps to Reproduce (for bugs)

icingacli director hostgroup create "5" --json "{"display_name":"Test"}"
pull an element in via director import run (in my case via sql query)
This element in my case has a type 5 which will be matched to the hostgroup
when trying to sync/roll out the following stacktrace is shown:

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: character varying = integer
ZEILE 1: ...ga_hostgroup.* FROM icinga_hostgroup WHERE (object_name = 5)
^
TIP: No operator matches the given name and argument types. You might need to add explicit type casts., query was: SELECT icinga_hostgroup.* FROM icinga_hostgroup WHERE (object_name = 5)

#0 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Db/Statement.php(303): Zend_Db_Statement_Pdo->_execute()
#1 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute()
#2 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Db/Adapter/Pdo/Abstract.php(265): Zend_Db_Adapter_Abstract->query()
#3 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Db/Adapter/Abstract.php(759): Zend_Db_Adapter_Pdo_Abstract->query()
#4 /usr/share/icingaweb2/modules/director/library/Director/Data/Db/DbObject.php(725): Zend_Db_Adapter_Abstract->fetchRow()
#5 /usr/share/icingaweb2/modules/director/library/Director/Data/Db/DbObject.php(1324): Icinga\Module\Director\Data\Db\DbObject->loadFromDb()
#6 /usr/share/icingaweb2/modules/director/library/Director/Objects/IcingaObjectGroups.php(203): Icinga\Module\Director\Data\Db\DbObject::load()
#7 /usr/share/icingaweb2/modules/director/library/Director/Objects/IcingaObjectGroups.php(181): Icinga\Module\Director\Objects\IcingaObjectGroups->add()
#8 /usr/share/icingaweb2/modules/director/library/Director/Objects/IcingaObjectGroups.php(140): Icinga\Module\Director\Objects\IcingaObjectGroups->add()
#9 /usr/share/icingaweb2/modules/director/library/Director/Objects/IcingaObject.php(1163): Icinga\Module\Director\Objects\IcingaObjectGroups->set()
#10 /usr/share/icingaweb2/modules/director/library/Director/Data/Db/DbObject.php(349): Icinga\Module\Director\Objects\IcingaObject->setGroups()
#11 /usr/share/icingaweb2/modules/director/library/Director/Objects/IcingaObject.php(791): Icinga\Module\Director\Data\Db\DbObject->set()
#12 /usr/share/icingaweb2/modules/director/library/Director/Data/Db/DbObject.php(480): Icinga\Module\Director\Objects\IcingaObject->set()
#13 /usr/share/icingaweb2/modules/director/library/Director/Objects/IcingaObject.php(733): Icinga\Module\Director\Data\Db\DbObject->setProperties()
#14 /usr/share/icingaweb2/modules/director/library/Director/Web/Widget/ActivityLogInfo.php(632): Icinga\Module\Director\Objects\IcingaObject->setProperties()
#15 /usr/share/icingaweb2/modules/director/library/Director/Web/Widget/ActivityLogInfo.php(429): Icinga\Module\Director\Web\Widget\ActivityLogInfo->createObject()
#16 /usr/share/icingaweb2/modules/director/library/Director/Web/Widget/ActivityLogInfo.php(464): Icinga\Module\Director\Web\Widget\ActivityLogInfo->newObject()
#17 /usr/share/icingaweb2/modules/director/library/Director/Web/Widget/ActivityLogInfo.php(132): Icinga\Module\Director\Web\Widget\ActivityLogInfo->newConfig()
#18 /usr/share/icingaweb2/modules/director/application/controllers/ConfigController.php(224): Icinga\Module\Director\Web\Widget\ActivityLogInfo->showTab()
#19 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Controller/Action.php(516): Icinga\Module\Director\Controllers\ConfigController->activityAction()
#20 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(76): Zend_Controller_Action->dispatch()
#21 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Controller/Front.php(954): Icinga\Web\Controller\Dispatcher->dispatch()
#22 /usr/share/php/Icinga/Application/Web.php(294): Zend_Controller_Front->dispatch()
#23 /usr/share/php/Icinga/Application/webrouter.php(105): Icinga\Application\Web->dispatch()
#24 /usr/share/icingaweb2/public/index.php(4): require_once(String)
#25 {main}

Your Environment

• Director version (System - About): 1.11.0
• Icinga Web 2 version and modules (System - About): 2.12.0
• Icinga 2 version (icinga2 --version): r2.14.0-1
• Operating System and version: CentOS 7
• Webserver, PHP versions: php 8.0.30, Apache

maybe related to #2297

[Thomas-Gelf]

Hi @cschra,

using numbers as hostgroup names is a very, very bad choice. That's similar to configuring your servers with numeric host names and wondering, why your network packets go elsewhere. If I could have imagined people doing this, there would have been a check in place preventing this from the beginning. Right now I have no chance to roll this back, as there seem to be setups doing exactly this.

Your fix isn't wrong, it can be applied, and it fixes this issue with PostgreSQL. Just: there might be other tricky/hidden bugs, that might bite you. The most problematic part are array keys, as PHP automatically converts string array keys to integers, when they look like such. Of course this is silly, and PHP core developers would implement it differently today. But as of this writing, it is as it is. Code parts where this could became a problem are lookup/cache tables, membership checks and similar.

I'm not saying that there are such bugs, but there have been related ones, and there might be others. We'll fix this, but please do yourself a favour and use alphanumeric Hostnames. If your names are IDs from an external system: prefix them with some character.

Best,
Thomas

[cschra]

Hi @Thomas-Gelf, thanks for your fast reply.
The naming schema is historically grown and not that easy to change. Funny thing is, that this became a thing when we switched to postgres as mariadb probably does not care so much about types. However, as we were unaware of this bad practice, we will now try to have a alphanumeric hostgroup object_name.

As this still produces errors, shall I open a PR for the change, so that at least this error is fixed?

[Thomas-Gelf]

Not trying to blame you, nobody defined that it should be forbidden. The same way, nobody hinders you from using numeric hostnames. It's just... not the best choice, and you must live with "funny" consequences like this one:

A PR against the current master (or v1.11.0, as it doesn't differ) would be great! Your patch doesn't fit my current version of that file.

Thanks,
Thomas