Ross Boylan wrote: > On Fri, 2012-08-31 at 23:28 -0600, Bob Proulx wrote: > [lots of great stuff] > > Thank you for sharing that information. > > I think also the hostname sometimes may be set by a dhcp server, right?
Well... It may be configured to do so. But only very rarely have I
ever seen that actually configured in such a way. So it might. But
having that type of configuration in the environment isn't great in my
opinion. For example then you really need to track hosts by ethernet
addresses. Because any other name for the machine might change. Now
if you are creating some type of very thin client network boot that
may be fine. But if the machine is going to have *any* local
configuration at all then I think it is trouble.
On Debian the way to configure dhcp to set the local hostname is
through modifying the hooks associated with the /sbin/dhclient-script
script. (Or modifying the script itself anyway. But then you must
merge on an upgrade.)
man dhclient-script
See the set_hostname() function in that script. I have usually hacked
it to unconditionally set the hostname from the $new_host_name
variable. Because by the time that is executed the current_hostname
is already set and that snippet isn't triggered normally. But that is
one way that you can configure the system to cause the local hostname
to be set from the dhcp provided name.
Again, I don't recommend this. Dynamic hostnames drove me to madness
on a school site. I eventually migrated away from it.
> Is it possible to set the hostname inside a chroot to something other
> than the main system's name?
No. The value of the hostname is held by the kernel. A chroot shares
the same kernel as the rest of the host system. Therfore there can
only be one hostname for both the underlying host and the programs
running in the chroot. Which makes sense since chroot(2) simply
changes where the root filesystem ("/") points, moving it to another
sub-directory. Everything else, process space, everything is shared.
> I tried editing the chroot's /etc/hostname
> without effect. The snipped explanation said /etc/hostname takes effect
> because of some init scripts; since they never ran in the chroot that
> explains why simply editing that file does not work.
Right.
> Since hostname is set in the kernel and the chroot shares the kernel
> with the host system, it sounds as if they have to have the same name.
Exactly!
> Put differently, if I did run the necessary startup script inside the
> chroot it would also change the hostname of the host system. Is that
> right?
Yes. If you did run them in the chroot you would find that the
hostname was changed globally outside the chroot too. There is only
one kernel running.
It is really rather strange that the kernel holds the hostname
information at all. It doesn't need it. Programs (libc really) could
just as easily get the hostname from a file. Probably this is
historical because the kernel also holds uname(2) information. Which
is another one of those legacy rather troublesome back alleys that
doesn't play nicely. Never did.
> It may be relevant that the chroot shares key system info with the host.
> The host fstab sets things up with
> /dev/daisy/chroot /mnt/chroot ext3 defaults 0 2
> proc-testing /mnt/chroot/proc proc defaults 0 0
> sysfs-testing /mnt/chroot/sys sysfs defaults 0 0
> /dev /mnt/chroot/dev rbind defaults,rbind 0 0
That is rather typical.
> I know the sharing is insecure, but things didn't work right inside the
> chroot unti I did it.
I don't see anything inherently insecure about it. If you have an
example that would be great.
> I care about the chroot hostname mostly for 2 reasons: the prompt
> displayed in the shell and the name that appears in syslog. The former
> I could fix by resetting the PS1 environment variable, but I don't know
> if there's anything I can do about syslog.
If you need/want more separation than a chroot there have been a
variety of solutions over the years. Starting with a chroot on one
end of the scale and ending with having a full virtual machine. All
are heavier. Most have support issues.
Bob
signature.asc
Description: Digital signature
