Bob Proulx wrote:
Do you have the bug number handy? I would be interested in reading
through it.
Certainly:
- Debian Bug #609851 - incorrect variables used to set hostname in
dhclient-script
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609851
I haven't noticed any behavior differences between ISC dhcpd version 3
in Lenny or version 4 in Squeeze with regards to having a hostname set
or having the dhcp client set the hostname. In my environment I had
customized dhclient-script in both cases to allow me to set the
hostname from the dhcp client and so I may have covered up the problem
you have hit. The logic between the versions is different but because
I customized the dhclient-script this would have hidden any issue with
the default logic. Hence why I would like to look at the bug report.
For me both versions behaved the same with regards to the default
behavior of having a hostname set and for my customized behavior of
having the client set the hostname from the assigned dhcp ip address.
I also did as you indicated in another message of using the PTR record
assigned to the ip address to obtain the desired hostname.
The short version of the bug is that the "dhclient-script" script uses
variables that are not initialized. The one if statement to set the
hostname will never be true because of this reason.
So primarily the problem is that you don't have a process in place to
automatically set up /etc/hostname to the desired name upon the first
provisioning, boot, deployment? You have previously used the dhcpd
assignment and the dhcp client hook script to do this. Put it in the
master image template and then it gets copied and deployed
automatically. That always worked before and you were happy and
stopped there. But now things are different. That process is not
working now. You are unhappy and looking for a solution. Is that a
reasonable reading?
I'd say somewhat reasonable. However, I would say things aren't broken
by rather they aren't working the way they should. As far as I am aware
we've not had to "fight" with other distributions to get it working.
Debian Squeeze seems to be the first one giving us a battle.
In previous versions we used the regular dhclient hook script. The
logic existed there to do it properly.
Are you open for some ideas and brainstorming? I understand that you
have a heterogeneous environment with various distributions. But once
it is in your master image template that part is unique to each
distribution image right? You simply want to have it all work
automatically without any manual interaction right? And it only needs
to do the action exactly once at the first boot and then it can be a
fixed static name with a fixed static address after that right?
I'm definitely up for some ideas. If I was not able to resolve the race
condition I want to see what other things I can do to resolve this.
I'd prefer to have DHCP set the hostname at every boot, if possible,
until our customer sets one themselves. However, if this can't be done
than I will do it only on first boot.
Different ideas...
1) Create a local isc-dhcp-client deb package with dhclient-script
modified for your purpose. Use 4.1.1-P1-15~special1 or similar
that will be guaranteed to have an earlier version than the stock
version. Code it to do the right thing for your environment. If
it is upgraded to the stock version that is fine and desired (as I
understand it) since the work it was tasked to do of setting up
/etc/hostname will already have been done. Any later upgrade would
completely clean up the customization and become a completely stock
system which would be perfect. A disadvantage is that admins that
follow you on this may not be versed in creating packages. It is a
simple process but would be a barrier to entry for some admins.
2) Hack /sbin/dhclient-script directly. Sure it is part of the
isc-dhcp-client package. Sure hacking it will cause it to fail an
md5sum check. But that is okay, isn't it? It is your hack and you
are in control of it. If the package is reinstalled later then it
will replace the hacked version with the packaged version and fix
everything. Since it's not a "conffile" it will simply be
replaced. But by that time it will have done its job and set
/etc/hostname and all will be fine to be replaced with the stock
version. Just a hack of /sbin/dhclient-script is simpler than
creating a full package. The process is fairly transparent and is
understandable by almost any admin that follows you.
3) Create a local boot time /etc/init.d/vpsprovider script that does
the same thing. This would be slightly simpler than creating the
full package replacement. This would be slightly more complicated
than hacking /sbin/dhclient-script but could handle more
complicated situations. For example it could check if the hostname
was the unconfigured hostname and then set it exactly once and then
clean up after itself leaving no trace of itself behind. That
would have the advantage that the result would be indistinguishable
from a stock system. For example after updating /etc/hostname it
could then remove itself as part of the cleanup. It could even do
this action and then reboot so that when the machine settles it is
guaranteed to settle in a known good final state. I suggest this
because I have done this many times and if care is taken the result
is excellent. But a disadvantage is that people tend to have a
hard time wrapping their mind around boot time scripts. I don't
know what it is about it but people get very confused about what
happens at boot time. And if it were to modify itself by cleaning
up afterward this would be beyond the capabilities of some admins.
A sad but true statement.
4) Try using 'pump' or other dhclients instead. I haven't tried them
on Debian since the ISC client works fine for my purposes. But
since you have mentioned the heterogeneous environment with lots of
distros then you might have expertise using a different client and
this would allow you to leverage it and apply it to your problem.
Me, personally, if I were a paying client I wouldn't like this as
much if I had selected Debian (or Ubuntu) as a system image from a
virtual image list but I mention it anyway as a possibility. If I
were hit with this I would think, "Huh? Can I switch it back to
the standard install one?" and probably try just that and always
wonder why a non-default dhclient was initally installed and assume
it was someone being parochial. So I don't consider this as good
of a solution but you are free to disagree.
All of the above possibilities would provide a completely automated
configuration upon the first boot of the image. There isn't a need to
manually access the booted image. Option 2 above is probably the
simplest and most direct option.
In all cases I really recommend leaving the configuration with a
static ip address configuration in /etc/network/interfaces. It just
makes things a much more reliable setup.
Thank you for the ideas. I'll need to go over each one thoroughly this
week and do some testing.
I wish I could set the hostname statically but it becomes an issue if
our customer decides to migrate their instance to a different facility.
If a customer has static IP addresses configured migrations to a
different facility can become more difficult. If they start the
migration and forget to change their IP they land in the new facility
with broken networking. Using DHCP avoids this.
>>It's a unique use-case, but in theory it should work. Getty is just
>>a bit too energetic. :p
>
>If you are setting up a virtual machine image then that isn't that
>unique of a case. :-)
Indeed. But having DHCP set the hostname is definitely a unique use-case.
Yes. And as an important point you only really want to do it once.
That is different from always needing to set a dynamic hostname based
upon the ip address. And much better.
In my case I was needing to do it every time forever for the life of
the image for a thin client application. (And having done it I was
never happy with it. I eventually migrated things away from that
method.) But for you it is a usefully important point that you only
need to bootstrap yourself into a working configuration. After the
/etc/hostname is set on the first boot then you can leave the
configuration frozen at that state. That is better.
I've not ripped through all of our other templates. But I *believe* all
are set dynamically. But it checks to see whether the DHCP hostname
should be used, or the one set in "/etc/hostname" (or whichever
depending on the distro).
>>Thanks for the insight and input, Bob. If I wish I would be able to
>>use one of your recommendations as it would be easier. But just
>>doesn't fit my needs.
>
>I am sure you have reasons but so far I don't see it yet.
Hopefully I've been able to clear up some confusion about my reasons
behind this.
Yes. Thank you for the additional information. It was useful for me
to have a better understanding of your problem. And hopefully I was
able to repay that effort with what I hope to be useful discussion and
ideas.
Definitely. I'll be putting some to the test to see if I can work
around it moving forward.
BTW... Every time you reply your mailer adds another "Re: " to the
subject line. You probably want to look into that problem. It is a
little bit annoying.
Good old Thundebird. Sigh. I had not been paying attention to the
subject that Thunderbird was setting. Not to get too far off-topic but
I definitely need to work on a better work-flow for reading/replying to
mailing lists. It's a bit of a rigmarole the way I do it now.
Thanks again!
-Tim
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ed3438e.4000...@gmail.com
