Illegal characters not allowed
- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Illegal characters not allowed
Do you have it documented anywhere what characters are not allowed to be used in the name and description fields?
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Illegal characters not allowed
Yes, though it took some looking.
http://nagios.sourceforge.net/docs/3_0/ ... ml#service
One thing to also avoid is '$', unless you intend to access a macro.
http://nagios.sourceforge.net/docs/3_0/ ... ml#service
It's never a bad idea to just assume that the allowed chars are: A–Z, a–z, and 0–9. This offers 62 uniq digits or base62, using just these you should be able to express quite a bit with little effort.Service wrote:service_description;: This directive is used to define the description of the service, which may contain spaces, dashes, and colons (semicolons, apostrophes, and quotation marks should be avoided). No two services associated with the same host can have the same description. Services are uniquely identified with their host_name and service_description directives.
One thing to also avoid is '$', unless you intend to access a macro.
Re: Illegal characters not allowed
What do you do if a service name you are checking contains a "$"
SQL 2005 and above services use this for named instances. mssql$instancename
Is there an escape character we can use in the check string?
SQL 2005 and above services use this for named instances. mssql$instancename
Is there an escape character we can use in the check string?
Re: Illegal characters not allowed
If there is an easy way, it's not documented. The writer of the check command should have some idea how to do this. If I was writing a check I'd replace some other char for '$', like '~' as in 's/~/$/g'.
I would try '\$' and other unix/windows like escapes.
I would try '\$' and other unix/windows like escapes.
- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Re: Illegal characters not allowed
Thanks for this mmestnik 
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Illegal characters not allowed
I did find the answer in the other forum. Either put the service name in single quotes with an escape $ 'mssql$$instancename' which I confirmed worked, or without quote as with a \
mssql\$$instancename
mssql\$$instancename
Re: Illegal characters not allowed
So $$ passes as a $, the null/blank macro(this I did not know). After that you'd need the '\' or '''(s) to escape the '$' from shell expansion.
- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Re: Illegal characters not allowed
For anyone interested, after looking at some code I was able to find the following.
I assume that these are the values allowed, anything else is illegal.
/[^a-zA-Z0-9 .\:_-]/
if (form.tfName.value.match(/[^a-zA-Z0-9 .\:_-]/))
I assume that these are the values allowed, anything else is illegal.
/[^a-zA-Z0-9 .\:_-]/
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Illegal characters not allowed
So rather all of these:
Code: Select all
for ech in {0,1,2}{0,1,2,3,4,5,6,7}{0,1,2,3,4,5,6,7}; do echo -e '\0'$ech; done | grep -a '[a-zA-Z0-9 .:_-]' | tr -d '\n' | hexdump -C
00000000 20 2d 2e 30 31 32 33 34 35 36 37 38 39 3a 41 42 | -.0123456789:AB|
00000010 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 |CDEFGHIJKLMNOPQR|
00000020 53 54 55 56 57 58 59 5a 5f 61 62 63 64 65 66 67 |STUVWXYZ_abcdefg|
00000030 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 |hijklmnopqrstuvw|
00000040 78 79 7a |xyz|
00000043- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Re: Illegal characters not allowed
Awesome, thats a nice bit of code btw 
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.