HOSTNAME in nfsroot boot is FQDN

[Justin Cattle]

Thanks for the input John.
Glad to here it's not just me :)


I could implement some workarounds in the various scripts, that's true.


I've been doing some digging, and although I don't have the real answer
yet, I don't believe it's a FAI problem as such, it's something about the
NFSROOT OS.  In my case, debian stretch.

This script does get the correct info from DHCP:

/usr/share/fai/dhclient-fai-script


If you change the content to log to a file:


perl /usr/lib/fai/dhclient-perl >/tmp/foo 2>&1


The file contains the correct HOSTNAME value.


Likewise, if you change the perl script itself:

--- dhclient-perl 2017-06-08 14:06:00.857442761 +0100
+++ usr/lib/fai/dhclient-perl 2017-06-08 16:28:03.015219588 +0100
@@ -29,7 +29,7 @@
 # map dhcp names to bootp names
 %names = qw/
   ip_address              IPADDR
-  host_name               HOSTNAME
+  host_name               FAI_HOSTNAME


The variable FAI_HOSTNAME appears with the correct short name you would
expect to find in HOSTNAME.

This makes me to think that something else is setting the HOSTNAME varialbe
in the environment, and that the FAI scripts don't then override that.

That part might be handled by the perl script, but my perl is non-existent,
and I don't really know if that's the case.


If that is all true, the question is what is setting the HOSTNAME
variable.  I've tried disabling /etc/init.d/hostname.sh, and
lib/systemd/system/systemd-hostnamed.service, but it doesn't seem to help.
Maybe something else in systemd, or even dracut.  But I can't find it...

In fact, just been looking some more, and the hostname is set before
/usr/sbin/fai runs , /proc/sys/kernel/hostname is set , so maybe it is
dracut?


I'd really like to get to the bottom of this before I implement workarounds.




Cheers,
Just

On 8 June 2017 at 17:30, John G Heim <jheim at math.wisc.edu> wrote:

> I posted about this problem approximately a year ago. I poked around in
> the source code a little but finally just made a workaround by adding a
> line to my class script:
>
> echo "${HOSTNAME}" | sed s/\.math\.wisc\.edu//
>
> So you end up with classes for both the fqdn and the hostname. The only
> problem with that seems to be that logs are created in /var/log/fai/<fqdn>/
> instead of /var/logs/fai/<hostname>/.
>
> I am a little surprised you're getting this in 5.3.6. I was running 5.0.3
> when I had the problem. I create a whole new FAI setup for 5.3.6 and I
> don't have the problem any more. Are you using 5.3.6 in the nfsroot? I'm
> not sure how FAI installs FAI itself inside the nfsroot but you might be
> running an older version there. I am also installing ubuntu zesty instead
> of xenial but I don't see how that could matter.
>
>
>
> On 06/08/2017 04:40 AM, Justin Cattle wrote:
>
>> Hi,
>>
>>
>> I've been testing migrating to fai 5 from 4.
>> I'm currently using fai-5.3.6, on Ubuntu xenial, but with a Debian
>> stretch nfsroot [ due to lack of dracut support in ubuntu ].
>>
>> When I build a host, the boot all works ok and the build process starts
>> fine.
>> However, the hostname of the instance is somehow getting set to the FQDN.
>>
>> It sounds like a small problem, but has a knock on effect on some of our
>> custom class assignment scripts.
>>
>> I know that dhcp is sending the correct host-name.
>>
>>
>> It looks like FAI set's the HOSTNAME variable from this script passed
>> from dhclient:
>>
>>     root      1531  0.0  0.0  21484  1076 ?        Ss   10:21   0:00
>>     dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf
>>     /usr/share/fai/dhclient-fai-script eth0
>>
>>
>> Am I right in thinking that?
>>
>> Any ideas on how I can fix or debug this so HOSTNAME is set to the
>> host-name requested from DHCP?
>>
>> It's not even obvious to me where the dhcp config for fai that calls that
>> script is set.
>>
>>
>> Any help or info is greatly appreciated.
>> Thanks!
>>
>>
>>
>> Cheers,
>> Just
>>
>> Notice:  This email is confidential and may contain copyright material of
>> members of the Ocado Group. Opinions and views expressed in this message
>> may not necessarily reflect the opinions and views of the members of the
>> Ocado Group.
>>
>> If you are not the intended recipient, please notify us immediately and
>> delete all copies of this message. Please note that it is your
>> responsibility to scan this message for viruses.
>>
>> Fetch and Sizzle are trading names of Speciality Stores Limited and
>> Fabled is a trading name of Marie Claire Beauty Limited, both members of
>> the Ocado Group.
>>
>> References to the “Ocado Group” are to Ocado Group plc (registered in
>> England and Wales with number 7098618) and its subsidiary undertakings (as
>> that expression is defined in the Companies Act 2006) from time to time.
>> The registered office of Ocado Group plc is Buildings One & Two, Trident
>> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
>>
>>

-- 


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 

 

If you are not the intended recipient, please notify us immediately and 
delete all copies of this message. Please note that it is your 
responsibility to scan this message for viruses. 

 

Fetch and Sizzle are trading names of Speciality Stores Limited and Fabled 
is a trading name of Marie Claire Beauty Limited, both members of the Ocado 
Group.

 

References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expression is defined in the Companies Act 2006) from time to time. 
 The registered office of Ocado Group plc is Buildings One & Two, Trident 
Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20170608/fa35d55d/attachment.html>