Re: Getty is spawning to early
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
Re: Re: Getty is spawning to early
John Hasler writes: Ok. Is the idea to image all the machines identically and then configure them automatically via dhcp? If so why do they need locally configured hostnames at all? By default all of our distribution templates set the hostname of the system, via DHCP, to match the default PTR record we define for IP addresses. All of our ranges have default PTRs that are unique to that one address. As we've done this for many years it is the expected default. To change this would require we re-tool all current templates. -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/4ed27d97.40...@gmail.com
Re: Re: Re: Getty is spawning to early
Bob Proulx wrote: Tim Heckman wrote: Luckily the two of these issues won't come in to play here. This is going to be used on a system that does not have X installed and will have a static IP address. We use DHCP to assign the address as it is easier to deploy a new distribution for our customers. The language you are using is confusing. If it has a static address then you wouldn't be assigning it using dhcp. I think you really mean to say that you have your dhcp server configured to assign addresses by ethernet address? So that the dhcpd will always be assigning the same address? That isn't the same as a static ip address. The language used can really confuse things sometimes. My apologies for using such convoluted terminology. Our customers are assigned an IP address and the backend systems configure the DHCP servers to only provide that instance with that IP address. So you are correct that DHCP is configured to assign the IP address based on the MAC address. 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. 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. In my case I ended up setting the hostname to localhost. Since the client machines are true thin clients without any external services they don't need to have a hostname. That worked best for me. Perhaps it is something that might be a good option for you? Then it would be very similar to any live-cd boot system. This doesn't work unfortunately. I work for a popular cloud-services (VPS) provider and this is the template that is being built for deployment of Debian 6.0 systems moving forward. This is the only thing holding me back from being able to replace the current template. 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. 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. 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. 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. 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
Re: Re: Re: Getty is spawning to early
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
Re: Getty is spawning to early
Tim writes: The $new_host_name variable is the hostname that was provided by the dhcp server. Ok. Is the idea to image all the machines identically and then configure them automatically via dhcp? If so why do they need locally configured hostnames at all? -- John Hasler -- 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/87borywupz@thumper.dhh.gt.org
Re: Getty is spawning to early
set DELAYLOGIN=yes in /etc/default/rcS. -- John Hasler -- 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/87obvzx1yu@thumper.dhh.gt.org
Re: Re: Getty is spawning to early
John, Thank you for replying back as well as the idea to set this option. I wish it had been this easy but it appears that this option does not affect how getty prints the login prompt. I believe this may only affect someone trying to log in and not how it prints. If you have any further ideas it would be greatly appreciated! -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/4ed028a7.8080...@gmail.com
Re: Re: Getty is spawning to early
John, Thank you for replying back as well as the idea to set this option. I wish it had been this easy but it appears that this option does not affect how getty prints the login prompt. I believe this may only affect someone trying to log in and not how it prints. If you have any further ideas it would be greatly appreciated! -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/4ed030c9.1060...@gmail.com
Re: Getty is spawning to early
Tim Heckman wrote: I have an interesting problem that should actually be seen as a compliment to Debian. My system is booting so fast that the /sbin/getty is spawning before DHCP sets the hostname. So I get a prompt like this: Debian GNU/Linux 6.0 (none) hvc0 (none) login: If I log in, the hostname is set, and when logging back out it appears as well. Am I correct in assuming that you have modified /sbin/dhclient-script to set the hostname from the dhcp'd hostname? (That is what I did when I was doing this.) This configuration is destined to be used for mass deployments of Debian Squeeze. So simply hardcoding the hostname is not a solution, unfortunately. Is there an easy way to slow down when getty is launched so that I leave enough time for the hostname to be set? I am curious if you have worked with this type of a system previously. I have and I was never satisified with it. For example if the hostname changes due to a dhcp changed IP address while the system is running then X Windows gets very upset and there were other problems. In my case I ended up setting the hostname to localhost. Since the client machines are true thin clients without any external services they don't need to have a hostname. That worked best for me. Perhaps it is something that might be a good option for you? Then it would be very similar to any live-cd boot system. Bob signature.asc Description: Digital signature
Re: Re: Getty is spawning to early
Bob Proulx wrote: Am I correct in assuming that you have modified /sbin/dhclient-script to set the hostname from the dhcp'd hostname? (That is what I did when I was doing this.) I've created a dhclient-exit-hook script to handle the processing. This checks whether the hostname should be set and completes the process. Only sets it if it really is needed. I am curious if you have worked with this type of a system previously. I have and I was never satisified with it. For example if the hostname changes due to a dhcp changed IP address while the system is running then X Windows gets very upset and there were other problems. Luckily the two of these issues won't come in to play here. This is going to be used on a system that does not have X installed and will have a static IP address. We use DHCP to assign the address as it is easier to deploy a new distribution for our customers. 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, 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. In my case I ended up setting the hostname to localhost. Since the client machines are true thin clients without any external services they don't need to have a hostname. That worked best for me. Perhaps it is something that might be a good option for you? Then it would be very similar to any live-cd boot system. This doesn't work unfortunately. I work for a popular cloud-services (VPS) provider and this is the template that is being built for deployment of Debian 6.0 systems moving forward. This is the only thing holding me back from being able to replace the current template. 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'. It's a unique use-case, but in theory it should work. Getty is just a bit too energetic. :p 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. -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/4ed04060.3070...@gmail.com
Re: Getty is spawning to early
Tim Heckman writes: I've created a dhclient-exit-hook script to handle the processing. This checks whether the hostname should be set and completes the process. Only sets it if it really is needed. Try killing getty in your script (init will respawn it). You may also need to delay logins so that the user can't log in too early. BTW how is your script setting the hostname? -- John Hasler -- 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/87hb1rwq6m@thumper.dhh.gt.org
Re: Re: Getty is spawning to early
John Hasler writes: Tim Heckman writes: I've created a dhclient-exit-hook script to handle the processing. This checks whether the hostname should be set and completes the process. Only sets it if it really is needed. Try killing getty in your script (init will respawn it). You may also need to delay logins so that the user can't log in too early. I'm not sure why but I hadn't thought of this. I was hoping to implement a delay instead of having to kill getty. I wouldn't want to nuke getty while someone was logged in doing something as, in theory, it is possible the hook could be invoked by dhclient. But there would need to be a weird situation for the logic to be in place to cause it to happen. However, it seems like it may be the best option. I'll need to do some testing this weekend/next week and determine if this fits my needs. BTW how is your script setting the hostname? When hook gets called by /sbin/dhclient-script and has some variables available to help determine if the hostname should be set. Here is a pastebin of the script itself: - http://pastie.org/2917845 In short: if /etc/hostname's size 0 and the variable $new_host_name is non-zero and current hostname != hostname obtained by DHCP then: set the hostname and regenerate /var/run/motd The $new_host_name variable is the hostname that was provided by the dhcp server. Thanks for the suggestion John it looks like it may be the winner. If anyone has any further ideas, or suggestions, I'm all ears! -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/4ed06f93.9060...@gmail.com
Re: Re: Getty is spawning to early
Tim Heckman wrote: I've created a dhclient-exit-hook script to handle the processing. This checks whether the hostname should be set and completes the process. Only sets it if it really is needed. Ah, very good. In this case it is six of one and a half dozen of the other. Either way should be fine. Luckily the two of these issues won't come in to play here. This is going to be used on a system that does not have X installed and will have a static IP address. We use DHCP to assign the address as it is easier to deploy a new distribution for our customers. The language you are using is confusing. If it has a static address then you wouldn't be assigning it using dhcp. I think you really mean to say that you have your dhcp server configured to assign addresses by ethernet address? So that the dhcpd will always be assigning the same address? That isn't the same as a static ip address. File /etc/network/interfaces with a static address: iface eth0 inet static address 192.168.1.101 netmask 255.255.255.0 gateway 192.168.1.1 dns-search example.com dns-nameservers 0.0.0.0 # local caching named File /etc/network/interfaces with a dynamically assigned address: iface eth0 inet dhcp The language used can really confuse things sometimes. 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? 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. In my case I ended up setting the hostname to localhost. Since the client machines are true thin clients without any external services they don't need to have a hostname. That worked best for me. Perhaps it is something that might be a good option for you? Then it would be very similar to any live-cd boot system. This doesn't work unfortunately. I work for a popular cloud-services (VPS) provider and this is the template that is being built for deployment of Debian 6.0 systems moving forward. This is the only thing holding me back from being able to replace the current template. 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. 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. 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. :-) 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. Good luck! Bob signature.asc Description: Digital signature
Re: Re: Getty is spawning to early
Tim Heckman wrote: John Hasler writes: Try killing getty in your script (init will respawn it). You may also need to delay logins so that the user can't log in too early. I'm not sure why but I hadn't thought of this. I was hoping to implement a delay instead of having to kill getty. I wouldn't want to nuke getty while someone was logged in doing something ... If someone has logged in using getty then the getty isn't running anymore since it exec's the login process. It is only the process id that is special. Since the getty exec's the login process the process id is maintained. When the login process exits the pid exits. When the pid exits then init notices and responds the getty as per the configuration in /etc/inittab. So if someone has logged in then getty is already gone and replaced by the login process. If you only kill a getty then you won't be killing the login process. Having said that, I don't think you can eliminate the race condition between checking the name one instant for being getty and then trying to kill it thinking it is getty and okay and having it change to a different process name due to a login at that same instant. I don't know of a way to avoid that race condition. But setting DELAYLOGIN=yes may help since it will push logins off until later. The two combined may be okay. ... as, in theory, it is possible the hook could be invoked by dhclient. But there would need to be a weird situation for the logic to be in place to cause it to happen. Uhm... what? :-) Bob signature.asc Description: Digital signature
