FW: What else do we need to fix to make K12Linux production ready

[Luis Montes]

Warren Togami wrote:
> 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
>> complexity.
>>
>> 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.
>

There is definitely and understanding disconnect. The two benefits you 
have listed on the doc are bridging is easier to understand and that 
it's safer.
Is primary purpose is to keep people from running rogue dhcp severs on 
their networks?
I don't think the added complexity of the virtual networking is worth 
it.  And any testing can benefit can also be attained by using any other 
virtualization software with the ltsp server as a guest OS.

>>
>> 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.
>

I've spent a couple of hours this evening trying to get eth0 working as 
my one NIC and listening to dhcp requests to no avail.
The default install worked ok, and I bridged eth0 to ltspbr0 but of 
course my stand alone workstations on the same network got the 173.x.x.x 
addresses.

So I remove the BRIDGE=ltspbr0 from the ifcf-eth0 file, restart the 
network and just try to edit the dhcp.conf to use the 192.168.0.x 
network that I've used in the past.  The eth0 network is configured to 
use the 192.168.0.x network but I can't even start dhcpd. In fact I cant 
seem to even ping my 192.168.0.1 gateway.

I've tried disabling the firewall as well. Is there some other 
configuration that keeps eth0 from sending and receiving?

I'd like to know how to go about removing the bridge networking and 
sticking with the standard fedora networking setup for 1 or 2 NICs.



Thanks,

Luis