/v1/config/packages fails when dot (.) is in the host name - probably since 2.13.3

Hi Guys,
I ask for your help with an API call.
Since upgrading to 2.13.6 the /v1/config/packages API endpoint fails when the hostname contains a dot (.) and for this reason the package will not be created.

curl -k -s -u xx:xx -H ‘Accept: application/json’ -X POST ‘url…/v1/config/packages/test.host.com?pretty=1’
“error”: 400,
“status”: “Invalid package name ‘test.host.com’.”

If I replace the dot with underscore, then the API accepts it.

“results”: [
“code”: 200,
“package”: “test_host_com”,
“status”: “Created package.”

Since we have ca. 150 hosts already defined with the dot (.) in the package name, it causes now a bit of a headache for us.

Is it a feature or a bug?

I tried with the %2E escape character but this gives us the same result unfortunately.

curl -k -s -u xx:xx -H ‘Accept: application/json’ -X POST ‘url/v1/config/packages/test%2Ehost%2Ecom?pretty=1’
“error”: 400,
“status”: “Invalid package name ‘test.host.com’.”

Any idea how to use the dot with this API call in the future?
Best regards!

icinga2 - The Icinga 2 network monitoring daemon (version: r2.13.6-1)
Version: 2.13.6-1+ubuntu20.04
Ubuntu 20.04.5 LTS (Focal Fossa)
Enabled features: api checker command ido-mysql mainlog notification syslog

as a newbie I’m limited for 2 URLs in the post which I exceeded with the package names. in the curl call the payload after the POST is obviously ‘https://localhost:5665/v1/config/packages/…’

I hope this helps for clarifying.
Thank you for considering this.

Hello @alpha!

It’s a feature.

Those already existing packages should still work.


yes, existing packages with dots do work, but we need to change a lot in our schemes to comply with the new syntax. We used FQDN with dots now we need to use host_domain_tld format.

What was to reason for dropping the dot in the package name?

Any chance to have it back?

Could you live with 2+ dots in a row (..) still not being allowed? And with that package name can’t be just “.”?