FW: What else do we need to fix to make K12Linux production ready
wtogami at redhat.com
Sat Sep 6 19:29:16 UTC 2008
Robert Arkiletian wrote:
> On Fri, Sep 5, 2008 at 8:14 AM, Paul Nelson <PNelson at nwresd.k12.or.us> wrote:
>> Network defaults ready for use in schools:
>> K12Linux is often installed by teachers experimenting with Linux and thin-clients in their classrooms. It's important to understand these folks as customers when making decisions about how to configure K12Linux. The two network card setup worked so well because these servers could be isolated from the network and could at the same time, create a network in a classroom or lab. Out of the box they had DNS, DHCPD and NAT working so the K12linux box would act as a gateway to the rest of the network and at the same time, create a rational, usable network inside the school or classroom (usable for other PCs too). I think it's important that the kind of scripting that Eric did in earlier releases finds its way into K12Linux for Fedora 9 as well.
> I agree with this Paul. I think we are going to be getting a lot of
> people frustrated with the virtual bridge networking configuration. I
> prefered it the way it was in k12ltsp.
> As far as I understand it there where 2 reasons for using ltspbr0
> 1) it's easy to connect vm's to test ltsp
> 2) people won't accidentally broadcast dhcp by connecting eth0 to the wan
> I don't really feel these are valid reasons because:
> 1) people who are going to test with vm's are going to be ltsp dev's,
> not the average teacher who wants to run a lab. Dev's have the ability
> to set this up themselves, they don't need it to be defualt. We need
> to make it easy for most people, not dev's. So it adds unneccessary
> 2) once the bridge connects to a real eth device (which you need if
> you are going to boot real clients) you can still accidentally
> broadcast dhcp
I think there is an understanding disconnect here. The bridge does make
it convenient to test it with the VM, but that isn't the primary purpose
for the bridge. It is perfectly possible with a combination of iptables
rules, an actual DNS server (K12Linux currently doesn't run one by
default), and dhcpd.conf options to do everything desired above, in a
similar manner to K12LTSP.
Including iptables rules by default is not straight forward because they
can easily conflict with any existing rules from
/etc/sysconfig/iptables, from libvirt and other sources. There is
unfortunately far too many ways one could configure iptables. I suppose
we could ship a basic config that should work for most people, but
disabled by default.
I think we should ship a DNS server pre-configured for ltspbr0. This is
straight forward and relatively easy to do. I just haven't done it yet
because it isn't needed for thin clients and nobody asked for it until now.
> So I'm not sure I understand why we are doing things this way.
> Second, apparently I understand that F9 + ltsp5 cannot provide an ip
> (via dhcp) to other stand alone OS's on the clients and act as a
> gateway. This used to work with k12ltsp. If this does not work it's a
> real problem because the only way I was able to get approval for my
> ltsp lab was that I could still boot Windows from the local HD's. Is
> this ability really gone? I tried testing last night but for some
> reason my F9 ltsp had it's ltsp-dhcpd service off and I couldn't get
> it to start again.
This is only a limitation of the current dhcpd.conf. It is perfectly
capable of serving IP's to non-thin clients on that network segment if
the dhcpd.conf is setup properly. If someone is willing to point out
exactly what dhcpd.conf changes are needed, I am willing to test it and
include it in the default dhcpd.conf.
wtogami at redhat.com
More information about the K12Linux-devel-list