Patchwork [V2] base-files: provide a mechanism to skip creation of the hostname file

login
register
mail settings
Submitter Mark Asselstine
Date Aug. 28, 2012, 6:20 p.m.
Message ID <1346178028-2036-1-git-send-email-mark.asselstine@windriver.com>
Download mbox | patch
Permalink /patch/35471/
State New
Headers show

Comments

Mark Asselstine - Aug. 28, 2012, 6:20 p.m.
The existence of a /etc/hostname file causes any hostname provided on
the kernel command line or via dhcp to be overwritten by the
initscripts 'init.d/hostname.sh'. This change allows you to set a
value of 'none' for 'hostname' which will skip the creation of the
/etc/hostname file by the base-files package.

Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
---
V2: Koen Kooi didn't want to see the handling of the hostname variable
    changed so I removed those changes and just focused on the creation
    of the /etc/hostname file.

  Changes from V1:
  * patch renamed, was 
    "base-files: allow for more flexibility related to hostname",
  * removed the rename of hostname to MACHINE_HOSTNAME
  * removed the addition made to meta/conf/local.conf.sample

 meta/recipes-core/base-files/base-files_3.0.14.bb |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
Phil Blundell - Aug. 28, 2012, 6:38 p.m.
On Tue, 2012-08-28 at 14:20 -0400, Mark Asselstine wrote:
> +	if [ "${hostname}" != "none" ]; then

This magic string value seems a bit unwholesome.  Can't you just check
against the empty string?

Also, if the problem is that the static hostname set here is overriding
the one from dhcp or the command line, I wonder whether this just
indicates that the priority of them is wrong and the scripting should be
adjusted so that the static file has lower priority than the other two
things.

p.
Mark Asselstine - Aug. 28, 2012, 6:53 p.m.
On August 28, 2012 19:38:04 Phil Blundell wrote:
> On Tue, 2012-08-28 at 14:20 -0400, Mark Asselstine wrote:
> > +	if [ "${hostname}" != "none" ]; then
> 
> This magic string value seems a bit unwholesome.  Can't you just check
> against the empty string?

The 'none' was suggested by a colleague and I just ran with it, but yes an 
empty string would work just fine and be less 'unwholesome' as you say.

> 
> Also, if the problem is that the static hostname set here is overriding
> the one from dhcp or the command line, I wonder whether this just
> indicates that the priority of them is wrong and the scripting should be
> adjusted so that the static file has lower priority than the other two
> things.


hostname.sh doesn't leave much room for priority

---snip---
if test -f /etc/hostname
then
        hostname -F /etc/hostname
fi
---snip---

looking at this you can see my logic, don't create the /etc/hostname file get 
rid of the overwrite.

Mark

> 
> p.
Ross Burton - Aug. 28, 2012, 7:16 p.m.
On 28 August 2012 19:53, Mark Asselstine <mark.asselstine@windriver.com> wrote:
> hostname.sh doesn't leave much room for priority
>
> ---snip---
> if test -f /etc/hostname
> then
>         hostname -F /etc/hostname
> fi
> ---snip---
>
> looking at this you can see my logic, don't create the /etc/hostname file get
> rid of the overwrite.

But surely this should be running very early in the boot, and a
DHCP-assigned name should be running afterwards?

Ross
Mark Asselstine - Aug. 28, 2012, 8:01 p.m.
On August 28, 2012 20:16:30 Burton, Ross wrote:
> On 28 August 2012 19:53, Mark Asselstine <mark.asselstine@windriver.com> 
wrote:
> > hostname.sh doesn't leave much room for priority
> > 
> > ---snip---
> > if test -f /etc/hostname
> > then
> > 
> >         hostname -F /etc/hostname
> > 
> > fi
> > ---snip---
> > 
> > looking at this you can see my logic, don't create the /etc/hostname file
> > get rid of the overwrite.
> 
> But surely this should be running very early in the boot, and a
> DHCP-assigned name should be running afterwards?

That hasn't been what I have observed, and doesn't cover the command line 
case. If you have an NFS root this would also not be the case as init will be 
run after the network is setup and root mounted.

Mark



> 
> Ross
Ross Burton - Aug. 28, 2012, 8:11 p.m.
On 28 August 2012 21:01, Mark Asselstine <mark.asselstine@windriver.com> wrote:
>> But surely this should be running very early in the boot, and a
>> DHCP-assigned name should be running afterwards?
>
> That hasn't been what I have observed, and doesn't cover the command line
> case. If you have an NFS root this would also not be the case as init will be
> run after the network is setup and root mounted.

There was an implied "and if this isn't the case, a bug should be
filed".  I hadn't thought about NFS-root though.

Ross
Mark Asselstine - Aug. 30, 2012, 5:20 p.m.
On August 28, 2012 21:11:47 Burton, Ross wrote:
> On 28 August 2012 21:01, Mark Asselstine <mark.asselstine@windriver.com> 
wrote:
> >> But surely this should be running very early in the boot, and a
> >> DHCP-assigned name should be running afterwards?
> > 
> > That hasn't been what I have observed, and doesn't cover the command line
> > case. If you have an NFS root this would also not be the case as init will
> > be run after the network is setup and root mounted.
> 
> There was an implied "and if this isn't the case, a bug should be
> filed".  I hadn't thought about NFS-root though.
> 
> Ross

Thanks for your thoughts on this.

Is there anything else I can contribute here?

Mark
Mark Hatle - Sept. 7, 2012, 6:09 p.m.
On 8/30/12 12:20 PM, Mark Asselstine wrote:
> On August 28, 2012 21:11:47 Burton, Ross wrote:
>> On 28 August 2012 21:01, Mark Asselstine <mark.asselstine@windriver.com>
> wrote:
>>>> But surely this should be running very early in the boot, and a
>>>> DHCP-assigned name should be running afterwards?
>>>
>>> That hasn't been what I have observed, and doesn't cover the command line
>>> case. If you have an NFS root this would also not be the case as init will
>>> be run after the network is setup and root mounted.
>>
>> There was an implied "and if this isn't the case, a bug should be
>> filed".  I hadn't thought about NFS-root though.
>>
>> Ross
>
> Thanks for your thoughts on this.
>
> Is there anything else I can contribute here?

I found a bug with this patch.  If you are building with the deb packaging then 
the conffiles is set to /etc/hostname, but the file may not always be created... 
this causes a failure condition when generating .deb packages.

i.e.:

-CONFFILES_${PN} = "${sysconfdir}/fstab ${sysconfdir}/hostname"
+CONFFILES_${PN} = "${sysconfdir}/fstab ${@['', 
'${sysconfdir}/hostname'][(d.getVar('hostname', True) != '')]}"


> Mark
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Patch

diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 6bab040..dfcca78 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -107,10 +107,12 @@  do_install () {
 }
 
 do_install_basefilesissue () {
-	if [ -n "${MACHINE}" -a "${hostname}" = "openembedded" ]; then
-		echo ${MACHINE} > ${D}${sysconfdir}/hostname
-	else
-		echo ${hostname} > ${D}${sysconfdir}/hostname
+	if [ "${hostname}" != "none" ]; then
+		if [ -n "${MACHINE}" -a "${hostname}" = "openembedded" ]; then
+			echo ${MACHINE} > ${D}${sysconfdir}/hostname
+		else
+			echo ${hostname} > ${D}${sysconfdir}/hostname
+		fi
 	fi
 
 	install -m 644 ${WORKDIR}/issue*  ${D}${sysconfdir}