Tim Heckman wrote: > Bob Proulx wrote: > >Tim Heckman wrote: > > > The last time dhclient was attempted with this would have been on > > > Debian 5.0. In our most recent Debian 6.0 template someone decided > > > to use dhcpcd, > > >What were they using before? > > In Debian 5.0 dhcp3-client was the package provided on the default > Debian install. Debian 6.0 has switched over to isc-dhcp-client > now. In 5.0 Lenny the dhcp3-client was the ISC DHCP 3.1.1. In 6.0 Squeeze the isc-dhcp-client is ISC DHCP 4.1.1-P1. For reasons I didn't follow closely the package name was changed. It is really just a naming cleanup action. Presumably to allow other dhcp clients to have a similar level of name and not to consume the obvious first class name itself. Presumably to allow Red Hat's pump or others better observed status in the package search listings. I guess. I don't know the actual reasons. I just know it was renamed. Along with the renaming came a consolidation of the directory names. They went from dhcp3 to dhcp. Again. They were dhcp in the version 2 days before version 3 when the directory was renamed to allow different configurations to coexist without clobbering each other. It was definitely time to consolidate and clean up the leftover lint. > >>but it requires additional configuration for someone to set their > >>own hostname later on. Not an ideal situation as it is not the > >>default dhcp system and so people do not expect it. > > > >Sorry but I don't understand. DHCP normally does not set the > >hostname. Normally DHCP only sets the network device address and > >associated configuration such as gateway and nameservers. Trying to > >set the name from the dhcp server isn't very common. People have done > >it on occasion. But it definitely isn't the mainstream. > > I was comparing dhcp3-client to dhcpcd. In dhcp3-client you only > needed to set your own hostname by placing information in > "/etc/hostname" and it worked. The "/sbin/dhclient-script" script > handled this perfectly. In Debian 6.0 it was switched to > isc-dhcp-client and a bug was introduced in Debian 6.0 (that's > filed, yet still outstanding) where this logic no longer works. Do you have the bug number handy? I would be interested in reading through it. 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. > >So you are actually trying to build a virtual machine disk image. > >That's great. But that doesn't explain why you can't simply assign a > >hostname then. I am sure you have a good reason but just haven't said > >yet why your hostname must be tied to the IP address. Instead of > >being independent of it. > > > >Every VPS I have used assigned me one or more IP addresses. That was > >set up in /etc/network/interfaces as a static assignment. At that > >point the choice of hostname was mine to make. > > Historically we've done this. When a new instance is created we > assign it with an IP address. Each of our IPs has a PTR record that > is partially derived from the address itself. For every other > distribution (Debian 5.0, Ubuntu 10.04 LTS, Ubuntu 11.10, ArchLinux, > CentOS 5/6, etc.) we set the hostname on first boot via DHCP and it > works. This has become the expected configuration on a freshly > booted instance. 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? > The only time I've seen that done is when you're running OpenVZ and > any administrator is able to jump in to your container. We do not > access customer's instances, nor do we only operate Debian-derived > distributions. 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? 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. > >>The purpose of this configuration is for a customer to deploy this > >>distribution template and be assigned an IP address, a hostname that > >>is not personal, and be good to go. They can then override dhcp > >>setting the hostname by placing information in '/etc/hostname'. > > > >I am still not seeing why you can't simply assign the IP address and > >then let the client pick their own hostname as they want. > > They are more than welcome to do that after the first boot, but this > is how it's been done historically and on all current distribution > templates. Gotcha. > >>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. > >>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. 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. Bob
Attachment:
signature.asc
Description: Digital signature