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
