On Wed, 2017-07-26 at 21:17 +0200, Thomas Lange wrote: > And we have dots in FQDN, which are currently also not allowed in > class names. Should we truncate the FQDN before defining the hostname > as a class or replace the dots with the underscore?
if this is implemented, i'd say replace the dots w/underscores, similar to the nis/yp example in the fai-class man page. subdomains can have meaning and short hostnames should not be presumed to be unique in an organization. however, please bear in mind that making this change is likely to prove disruptive for anyone expecting the current behavior. and the current class-naming rules are documented, even to the hostname-class exception. also (see below) i'm not sure hyphens are the problem here. @Thomas - are you able to reproduce this failure mode? as i mentioned, we install a lot of hosts w/hyphens in their name w/o issue. @Arcady - could you check the version of bash that you're using and confirm that `/bin/bash` on your system isn't a symlink to `dash` or something? and/or try setting the $classes variable manually to exclude the hostname's hyphen and test again? i can generate this error by trying to run `dash fetch-basefile` regardless of whether $classes includes a hyphen or not. might be a bash-ism and somehow a non-bash shell is trying to run it? % export classes="vmops0.us.archive.org" % dash ./fetch-basefile ./fetch-basefile: 59: ./fetch-basefile: Bad substitution % export classes="vm-ops0.us.archive.org" % dash ./fetch-basefile ./fetch-basefile: 59: ./fetch-basefile: Bad substitution % bash ./fetch-basefile No basefile matching a class name was found at [FAI_BASEFILEURL] andy -- andrew bezella <abeze...@archive.org> internet archive