Stéphane urged concentration on the two text configuration files. Alkis
Georgopoulos insightfully contributed in a useful post just prior to that:
It's possible that you have configured network manager with a "user
connection", i.e. that your network is only started after a user logs in
on the server.
If so, either make it a system connection (check [x] available to
all users), or use /etc/network/interfaces instead.
But Network Manager was already set with "[x] Available to all users,"
so that was not the problem.
However, the indirect reference to Network Manager vs.
/etc/network/interfaces goes toward the apparent source of the problem.
When I first started working with Ubuntu/Edubuntu/Lubuntu and LTSP
recently, it seemed to me that network configuration might be handled
via either the GUI available from the desktop or
/etc/network/interfaces. Not only that, but that the two methods were
not alternate interfaces to a single settings collection, but could
interplay and perhaps conflict. If Ubuntu follows Debian closely enough
on this, then I now find this confirmed by
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_desktop
(and undoubtedly by Ubuntu documentation as well).
But in my early testing with the two configuration methods, I found that
if I used /etc/network/interfaces, then the network system indicator on
the desktop would report "Device not managed" for both interfaces. And
that seemed like a needlessly troubling message, so I have preferred the
GUI interface. This leaves /etc/network/interfaces with just its
default entry for the loopback interface.
This approach has worked fine almost all the time on my Lubuntu setup.
(But as I noted in a previous post, not always.) On the Edubuntu setup,
isc-dhcp-server virtually always fails to start during boot, hence the
failed PXE boot and the spawning of this thread.
I have found out in the meantime (previously posted), that I can
manually start isc-dhcp-server post-boot, and then the client will
boot. This led to the further observation that if I boot the server
with the client powered on, isc-dhcp-server also starts during boot in
that circumstance, and then I can reboot the client and it will PXE
boot. This led me to surmise that the existing network configuration
would work if I were connecting the PC's through a switch instead of a
crossover cable.
What I have now found out is that if I use complete entries for eth0
(LTSP i/f) and eth1 in /etc/network/interfaces, then everything seems to
work. But indeed, I am left with status report "Device not managed" for
both interfaces in the network system indicator. ** Perhaps that is the
best that might be done at the moment? **
The only other solution that occurred to me to keep the network system
indicator tidy is to run some sort of a script that starts
isc-dhcp-server later in the boot process or post-boot. (This since I
have already discovered that manually starting the service will work.)
** Does anyone do such a thing? **
OTHER TESTS:
The material at the above link gave me to believe that something might
be done with just one-line "auto eth0" and/or "auto eth1" in
/etc/network/interfaces, and indeed, with just:
auto eth0
auto eth1
isc-dhcp-server started most of the time but not always, and the network
system indicator stayed tidy with no troubling status reports.
With:
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
auto eth1
the network system indicator stayed tidy, but isc-dhcp-server failed to
start on 1 of 3 boots.
The above troubleshooting has focused on the Edubuntu system that was
the impetus for this thread. I have not delved further into the Lubuntu
setup -- which only fails occasionally -- to see if I can arrive at a
configuration that produces rock-solid isc-dhcp-server startups AND
keeps the network system indicator tidy.
------------
I attach the two requested configuration files in their current form.
(And Stéphane, thanks for the bit of background on yourself. Since I
have come in from nowhere here, I still only have a bare idea of who's
who and with what authority they speak on any given topic.)
On 8/24/2012 12:39 PM, Stéphane Graber wrote:
The start condition for isc-dhcp-server is perfectly right, so far all
you've pasted shows that your configuration is wrong and that's the
problem.
Please attach /etc/ltsp/dhcpd.conf and /etc/network/interfaces, that
should help figure out what you did wrong.
(For what it's worth, I'm the maintainer for ifupdown and
isc-dhcp-server in Ubuntu as well as a member of the team maintaining
upstart, our init system.)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
auto eth1
iface eth1 inet dhcp
#
# Default LTSP dhcpd.conf config file.
#
authoritative;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.20 192.168.0.250;
option domain-name "example.com";
option domain-name-servers 192.168.0.1;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
# next-server 192.168.0.1;
# get-lease-hostnames true;
option subnet-mask 255.255.255.0;
option root-path "/opt/ltsp/i386";
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/i386/pxelinux.0";
} else {
filename "/ltsp/i386/nbi.img";
}
}
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
