guarantee RFC standardized hostname

[Kevin Fitzgerald]

I made a bit of a syntax tweak and am getting closer to an answer I think.

regex portion:
       if exists host-name and option host-name ~= "[A-Za-z0-9\.\-]+"

With this configuration, all hostnames seem to fail the regex even if they
seem to include only allowed characters.  Everything is falling thru to the
else condition, which tacks a dhcp- to the front of the generated host
name.  I even tried writing a trivial regex that should match anything like
".+", but to no avail.  Still won't seem to match.

On Thu, Aug 25, 2011 at 1:36 PM, Kevin Fitzgerald <kwfitzgerald at ualr.edu>wrote:

> I tried Glenn's suggestion, and while it did parse correctly, it does not
> seem to have had the desired results.  I watched the logs and soon enough
> "android_xxxxyyyyyzzzzzz123" rolled thru.
>
> I was worried that it seemed too good to be true.  I am not convinced that
> it isn't a small syntax error that I have to work out, so I will play around
> with this some more.
>
>
> On Thu, Aug 25, 2011 at 9:35 AM, Glenn Satchell <
> glenn.satchell at uniq.com.au> wrote:
>
>> man dhcp-eval
>> ...
>>     data-expression-1 ~= data-expression-2 data-expression-1  ~~
>>     data-expression-2
>>
>>       The ~= and ~~ operators (not  available  on  all  systems)
>>       perform  extended  regex(7)  matching of the values of two
>>       data  expressions,  returning  true  if  data-expression-1
>>       matches  against the regular expression evaluated by data-
>>       expression-2, or false if it does not match or  encounters
>>       some  error.   If  either the left-hand side or the right-
>>       hand side are null, the result  is  also  false.   The  ~~
>>       operator  differs from the ~= operator in that it is case-
>>       insensitive.
>>
>> So you might want something like this then, where you list all the "good"
>> characters in the regex string on the right? I haven't tested this, but I'm
>> sure you get the idea...
>>
>> if exists host-name and option host-name ~~ "[a-z0-9.-]+" {
>>
>>        ddns-hostname = concat (lcase (option host-name) , "-" ,
>> binary-to-ascii(10 , 8 , "-" , leased-address));
>> }
>> else {
>>        ddns-hostname = concat("dhcp-" , binary-to-ascii(10 , 8 , "-"
>> leased-address));
>> }
>>
>> regards,
>> -glenn
>>
>>
>> On 08/25/11 07:25, Kevin Fitzgerald wrote:
>>
>>> Hi Group,
>>>
>>> For quite some time we have been generating DHCP ddns hostnames as
>>> follows:
>>>
>>> if exists host-name {
>>>         ddns-hostname = concat (lcase (option host-name) , "-" ,
>>> binary-to-ascii(10 , 8 , "-" , leased-address));
>>>         }
>>>     else {
>>>         ddns-hostname = concat("dhcp-" , binary-to-ascii(10 , 8 , "-" ,
>>> leased-address));
>>>         }
>>>
>>> This is not an uncommon format.  It helps us ensure unique host names on
>>> our network.  Lately I notice a handful of user devices that present
>>> host names with invalid characters, such as android_blah or "nintendo
>>> 3ds" with a space in the middle (no quotes).
>>> What are you folks doing to mitigate this?  As it stands these users do
>>> not receive valid NS records and we get a bevy of log messages when
>>> illegal characters are in the hostname.
>>>
>>> - I have seen mention of the use of regex in the man pages for
>>> dhcp-eval.  Is there a method to examine the host-name for invalid
>>> characters, replacing them with a hyphen or otherwise?    (Is there
>>> REGEX evaluation available within dhcpd.conf)
>>> - if there is no way to do a character by character replace, can I fail
>>> down to my else condition, simply prepending dhcp- to the front of the
>>> IP address?
>>> --
>>> K. Fitzgerald
>>> UALR Information Technology Services
>>>
>>>
>>>  ______________________________**_________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/**listinfo/dhcp-users<https://lists.isc.org/mailman/listinfo/dhcp-users>
>>
>
>
>
> --
> Kevin Fitzgerald
> UALR Information Technology Services
> 501-916-5019
>
>


-- 
Kevin Fitzgerald
UALR Information Technology Services
501-916-5019
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20110825/d370152b/attachment.html>