From buffalosolja at gmail.com Thu Nov 4 13:08:28 2010 From: buffalosolja at gmail.com (B Marl) Date: Thu, 04 Nov 2010 09:08:28 -0400 Subject: [K12OSN] An example of config file for fat client? Message-ID: <1288876108.2588.13.camel@t20.ENGINEERING2> I have done everything as in the Fat Client configuration under the Ubuntu LTSP, and it is still not using local devices? I have went through it a couple of times and don't see where I went wrong. I know its not booting off the original ltsp thin client because I moved the directory and watched the tftpd load fat64 (my chroot name). So I am really confused honestly (no different than before) on what I need to change. I adjusted things as well in accordance to Nubae's Habari Fat Client configuration and still doesn't see local devices; HDD, USB, CPU, etc. From dvanassche at gmail.com Thu Nov 4 13:47:53 2010 From: dvanassche at gmail.com (David Van Assche) Date: Thu, 4 Nov 2010 14:47:53 +0100 Subject: [K12OSN] An example of config file for fat client? In-Reply-To: <1288876108.2588.13.camel@t20.ENGINEERING2> References: <1288876108.2588.13.camel@t20.ENGINEERING2> Message-ID: Hi there, I'd suggest using either one approach or another. The fatclient built within the LTSP builds is slightly more limited than the fatclient plugin I created. Things such as local devs, printing, local sound, etc, all work with my app though there are many many reposrs and perhaps exx[;idg reasons to use the upstream version. It will (hopefully) keep work spirit for us as a team, thououflygh one can ever know On Thu, Nov 4, 2010 at 2:08 PM, B Marl wrote: > I have done everything as in the Fat Client configuration under the > Ubuntu LTSP, and it is still not using local devices? ?I have went > through it a couple of times and don't see where I went wrong. ?I know > its not booting off the original ltsp thin client because I moved the > directory and watched the tftpd load fat64 (my chroot name). ?So I am > really confused honestly (no different than before) on what I need to > change. ?I adjusted things as well in accordance to Nubae's Habari Fat > Client configuration and still doesn't see local devices; HDD, USB, CPU, > etc. > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > From news at siddall.name Thu Nov 4 13:49:18 2010 From: news at siddall.name (Jeff Siddall) Date: Thu, 04 Nov 2010 09:49:18 -0400 Subject: [K12OSN] Fullscreen localapp without a window manager Message-ID: <4CD2B9DE.1010902@siddall.name> I found a simple method to run fullscreen localapps without a window manager on a thin client. I use this setup for kiosks/appliances that don't have a keyboard/mouse/user. It has the major benefits of being extremely light on server resources while also preventing typical desktop environment annoyances (like pop up windows) which could cover the fullscreen app I really want to see. I am running LTSP5 on Fedora 13. This procedure should work on other Fedora releases (and maybe other LTSP releases too) but YMMV. I have successfully tested this with ooimpress and vlc, though firefox did not go fullscreen, even with rkiosk installed. The easiest way to begin is to run "switchdesk twm" (or whatever WM you choose, it doesn't matter) as the desired user. This will create a .Xclients and a .Xclients-default file in the user's home directory. Modify the .Xclients-default file so it contains only one line: exec Where is the script you want to run when the user logs in (ex: /usr/local/bin/vlc-ltsp-localapps.sh) The script should contain the ltsp-localapp command you want run on one line (ex: /usr/bin/ltsp-localapps vlc -f --deinterlace-mode=bob udp://@239.255.12.42) followed by: sleep 999d on the next line. The long sleep is required to prevent the script from returning anytime soon. Since ltsp-localapps returns immediately after spawning the localapp the script would normally exit immediately also, which would cause X to exit immediately also. I use this in combination with: LDM_AUTOLOGIN = True CONFIGURE_X = True X_MONITOR_OPTION_01 = "\"DPMS\" \"false\"" LDM_USERNAME = user LDM_PASSWORD = password in the lts.conf so the client immediately launches the fullscreen localapp on bootup. Someone with some desire could certainly create a much nicer set of scripts that could create a PID file in the user home directory on the client which the .Xclients-defaults script on the server could watch and then exit to restart X if the local-app ever died. In the simple setup I described above if the localapp dies it will just show a black screen for the next 3 years or so! I'll just hit the reset button when that happens. Jeff From dvanassche at gmail.com Thu Nov 4 13:54:11 2010 From: dvanassche at gmail.com (David Van Assche) Date: Thu, 4 Nov 2010 14:54:11 +0100 Subject: [K12OSN] An example of config file for fat client? In-Reply-To: References: <1288876108.2588.13.camel@t20.ENGINEERING2> Message-ID: Oopps... my message got split in the middle and doesn't quite make sense. What I meant to say is that fatclient (the nubae one) is kinda obsolete, even though at the time (pre lynx) it all worked like a charm.... ie, kind regards.Dav-d If you are having problems you can always go back to my script and compare to upstream to see what has changed. I remember the main cencer at the times secuurity and n On Thu, Nov 4, 2010 at 2:47 PM, David Van Assche wrote: > Hi there, > ? I'd suggest using either one approach or another. The fatclient > built within the LTSP builds is slightly more limited than the > fatclient plugin I created. Things such as local devs, printing, local > sound, etc, all work with my app ?though there are many many reposrs > and perhaps exx[;idg reasons to use the upstream version. ?It will > (hopefully) keep work spirit for us as a team, thououflygh one can > ever know > > On Thu, Nov 4, 2010 at 2:08 PM, B Marl wrote: >> I have done everything as in the Fat Client configuration under the >> Ubuntu LTSP, and it is still not using local devices? ?I have went >> through it a couple of times and don't see where I went wrong. ?I know >> its not booting off the original ltsp thin client because I moved the >> directory and watched the tftpd load fat64 (my chroot name). ?So I am >> really confused honestly (no different than before) on what I need to >> change. ?I adjusted things as well in accordance to Nubae's Habari Fat >> Client configuration and still doesn't see local devices; HDD, USB, CPU, >> etc. >> >> _______________________________________________ >> K12OSN mailing list >> K12OSN at redhat.com >> https://www.redhat.com/mailman/listinfo/k12osn >> For more info see >> > From buffalosolja at gmail.com Thu Nov 4 14:09:31 2010 From: buffalosolja at gmail.com (B Marl) Date: Thu, 04 Nov 2010 10:09:31 -0400 Subject: [K12OSN] An example of config file for fat client? In-Reply-To: References: <1288876108.2588.13.camel@t20.ENGINEERING2> Message-ID: <1288879771.2588.22.camel@t20.ENGINEERING2> Thanks guys I am just honestly so confused with projects and such that when I get to it everything is like started from square one. First I did it as it said directly on Ubuntu site but when I plugged in a USB device nothing happened and I couldn't mount it because the system didn't see it. I will start over again from scratch, should I start from a standard Ubuntu install or am I ok by using the LTSP version again? Sorry just need this done pretty soon for our lab and testing, (easier I thought to run LTSP than to have a ghost image for every pc). Thanks again guys are there any other tutorials anyone knows about or has this working themselves? On Thu, 2010-11-04 at 14:54 +0100, David Van Assche wrote: > Oopps... my message got split in the middle and doesn't quite make > sense. What I meant to say is that fatclient (the nubae one) is kinda > obsolete, even though at the time (pre lynx) it all worked like a > charm.... ie, > > kind regards.Dav-d > > If you are having problems you can always go back to my script and > compare to upstream to see what has changed. I remember the main > cencer at the times secuurity and n > > On Thu, Nov 4, 2010 at 2:47 PM, David Van Assche wrote: > > Hi there, > > I'd suggest using either one approach or another. The fatclient > > built within the LTSP builds is slightly more limited than the > > fatclient plugin I created. Things such as local devs, printing, local > > sound, etc, all work with my app though there are many many reposrs > > and perhaps exx[;idg reasons to use the upstream version. It will > > (hopefully) keep work spirit for us as a team, thououflygh one can > > ever know > > > > On Thu, Nov 4, 2010 at 2:08 PM, B Marl wrote: > >> I have done everything as in the Fat Client configuration under the > >> Ubuntu LTSP, and it is still not using local devices? I have went > >> through it a couple of times and don't see where I went wrong. I know > >> its not booting off the original ltsp thin client because I moved the > >> directory and watched the tftpd load fat64 (my chroot name). So I am > >> really confused honestly (no different than before) on what I need to > >> change. I adjusted things as well in accordance to Nubae's Habari Fat > >> Client configuration and still doesn't see local devices; HDD, USB, CPU, > >> etc. > >> > >> _______________________________________________ > >> K12OSN mailing list > >> K12OSN at redhat.com > >> https://www.redhat.com/mailman/listinfo/k12osn > >> For more info see > >> > > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see From robark at gmail.com Thu Nov 4 18:37:56 2010 From: robark at gmail.com (Robert Arkiletian) Date: Thu, 4 Nov 2010 11:37:56 -0700 Subject: [K12OSN] An example of config file for fat client? In-Reply-To: <1288876108.2588.13.camel@t20.ENGINEERING2> References: <1288876108.2588.13.camel@t20.ENGINEERING2> Message-ID: On Thu, Nov 4, 2010 at 6:08 AM, B Marl wrote: > I have done everything as in the Fat Client configuration under the > Ubuntu LTSP, and it is still not using local devices? ?I have went > through it a couple of times and don't see where I went wrong. ?I know > its not booting off the original ltsp thin client because I moved the > directory and watched the tftpd load fat64 (my chroot name). ?So I am > really confused honestly (no different than before) on what I need to > change. ?I adjusted things as well in accordance to Nubae's Habari Fat > Client configuration and still doesn't see local devices; HDD, USB, CPU, > etc. > If all you want is local apps then try DRBL. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From buffalosolja at gmail.com Thu Nov 4 18:51:57 2010 From: buffalosolja at gmail.com (B Marl) Date: Thu, 04 Nov 2010 14:51:57 -0400 Subject: [K12OSN] An example of config file for fat client? In-Reply-To: References: <1288876108.2588.13.camel@t20.ENGINEERING2> Message-ID: <1288896717.2576.9.camel@t20.ENGINEERING2> Actually our students are in a class where they are building computers, and we have a software to test these units. But it has to read the local devices on board in order to function correctly. This software tells you what needs attention (or what is not performing adequately). On Thu, 2010-11-04 at 11:37 -0700, Robert Arkiletian wrote: > On Thu, Nov 4, 2010 at 6:08 AM, B Marl wrote: > > I have done everything as in the Fat Client configuration under the > > Ubuntu LTSP, and it is still not using local devices? I have went > > through it a couple of times and don't see where I went wrong. I know > > its not booting off the original ltsp thin client because I moved the > > directory and watched the tftpd load fat64 (my chroot name). So I am > > really confused honestly (no different than before) on what I need to > > change. I adjusted things as well in accordance to Nubae's Habari Fat > > Client configuration and still doesn't see local devices; HDD, USB, CPU, > > etc. > > > > If all you want is local apps then try DRBL. > From robark at gmail.com Mon Nov 8 20:27:06 2010 From: robark at gmail.com (Robert Arkiletian) Date: Mon, 8 Nov 2010 12:27:06 -0800 Subject: [K12OSN] Life after LTSP Message-ID: In my opinion, the days of LTSP are numbered. For a few different reasons. 1) hardware is so cheap now. You can buy a brand new power efficient and fast desktop system for about $200 (not including monitor). Thin clients are actually *more* expensive now. 2) programs like flash and java based apps don't work and will never work well in an LTSP environment because they are multithreaded and utilize all cores on the server. So no matter how powerful a server, running many flash or java apps bring it to it's knees. Things were better when all apps were single threaded. As time goes on this will only get worse as cpu makers are increasing cores not mhz, so software makers are adapting by making apps utilize all cores. Local apps is a solution in the right direction but it brings with it other problems like using fuse (ltspfs) and other issues. The other problem with local apps, in an ltsp client, is that usually true thin client cpu's are weak (eg. Atom). The concept of Local apps is 180 degrees to what LTSP is about. 3) Things get even worse when you run video full screen because the data is being decoded (high cpu hit) at the server, then pushing *large* decompressed data across the lan. It just doesn't scale well. 4) If Ubuntu is successful with their move to Wayland display server (away from X), LTSP may not even work as Wayland has no network transparency as X does. Not sure if having X as a client itself on top of Wayland will work with LTSP. My guess is it will be troublesome because the client will need Wayland up first before X (which btw means it will also definitely need an opengl capable chipset). I suspect that unless the LTSP project goes back to the way they did things in LTSP 4, where they pretty much managed and built the chroot as a seperate distro, I think Wayland is going to break LTSP with the Muekow way of doing things. http://www.markshuttleworth.com/archives/date/2010/11 http://wayland.freedesktop.org/http://wayland.freedesktop.org/ So what do we do? Personally, I think there are at least a couple solutions. 1) Spice. The new remote VM technology that is in Fedora 14 and RHEL6. The management gui needs to get better in Fedora, but that's coming. Server requirements will be higher than ltsp as each desktop will have a VM running (not just a desktop and apps). But advantage will be complete customization per client and heterogeneous (windows+linux) environments ( at the expense of ease of administration, unless there are nice gui tools to manage multiple vm's simultaneously ) 2) DRBL. This is the route I have taken. It's similar to ltsp boot process via pxe but ALL processes run locally. Only the filesystem is remote via nfs. There is no need for special plumbing for sound or local devices. Everything works like a stand alone system. Except the first time to launch (not run) apps is slightly longer since the binary needs to be downloaded into local ram from the network before it can be run. One user can't hog ram or cpu. Full class of full screen video and flash, no problem. I even have had an entire class of students simultaneously install and run Ubuntu in a Virtualbox VM on top of the diskless client OS. Local apps with LTSP cannot do this. Although I do have dual gigabit nics for the lan and hardware raid 10 for the server. Each client can have it's own nfs mounted /etc and /var so there can still be customization per client. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From robark at gmail.com Mon Nov 8 20:46:48 2010 From: robark at gmail.com (Robert Arkiletian) Date: Mon, 8 Nov 2010 12:46:48 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: On Mon, Nov 8, 2010 at 12:27 PM, Robert Arkiletian wrote: > In my opinion, ?the days of LTSP are numbered. For a few different reasons. > > 1) > hardware is so cheap now. You can buy a brand new power efficient and > fast ?desktop system for about $200 (not including monitor). ?Thin I meant to say *diskless* desktop system. > > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot > process via pxe but ALL processes run locally. Only the filesystem is > remote via nfs. There is no need for special plumbing for sound or > local devices. Everything works like a stand alone system. Except the > first time to launch (not run) apps is slightly longer since the > binary needs to be downloaded into local ram from the network before > it can be run. One user can't hog ram or cpu. Full class of full > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of ?the diskless client OS. Local apps with LTSP cannot do this. > Although I do have dual gigabit nics for the lan and hardware raid 10 > for the server. Each client can have it's own nfs mounted /etc and > /var so there can still be customization per client. Plus you only need to manage the server, just like LTSP. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From news at siddall.name Mon Nov 8 20:59:28 2010 From: news at siddall.name (Jeff Siddall) Date: Mon, 08 Nov 2010 15:59:28 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: <4CD864B0.2010908@siddall.name> On 11/08/2010 03:27 PM, Robert Arkiletian wrote: > In my opinion, the days of LTSP are numbered. For a few different reasons. Yes and no. See my comments inline. > 1) > hardware is so cheap now. You can buy a brand new power efficient and > fast desktop system for about $200 (not including monitor). Thin > clients are actually *more* expensive now. Yes, hardware is petty cheap but even the most power efficient desktop systems are about 5 X the power of a typical thin client. Over the life of the client that can exceed the hardware cost. Plus any fanless system is still a slow systems, and LTSP can make those slow fanless clients feel like fast noisy desktops. Thin clients aren't any more expensive _if_ you don't buy expensive models! I still buy my TCs in parts and assemble and it can be done for low $100s, which is pretty reasonable. > 2) > programs like flash and java based apps don't work and will never work > well in an LTSP environment because they are multithreaded and utilize > all cores on the server. So no matter how powerful a server, running > many flash or java apps bring it to it's knees. Things were better > when all apps were single threaded. As time goes on this will only get > worse as cpu makers are increasing cores not mhz, so software makers > are adapting by making apps utilize all cores. Local apps is a > solution in the right direction but it brings with it other problems > like using fuse (ltspfs) and other issues. The other problem with > local apps, in an ltsp client, is that usually true thin client cpu's > are weak (eg. Atom). The concept of Local apps is 180 degrees to what > LTSP is about. Yup, these are somewhat difficult, but ultimately a clock cycle is a clock cycle and if your client is using 6 cores on your server it is probably faster than the one or two cores on their client. > 3) > Things get even worse when you run video full screen because the data > is being decoded (high cpu hit) at the server, then pushing *large* > decompressed data across the lan. It just doesn't scale well. Fully agree. Video is the real problem child for LTSP. I run dedicated video apps (VLC) as localapps but flash inside a browser (ex: YouTube) just doesn't work well on LTSP. > 4) > If Ubuntu is successful with their move to Wayland display server > (away from X), LTSP may not even work as Wayland has no network > transparency as X does. Not sure if having X as a client itself on top > of Wayland will work with LTSP. My guess is it will be troublesome > because the client will need Wayland up first before X (which btw > means it will also definitely need an opengl capable chipset). I > suspect that unless the LTSP project goes back to the way they did > things in LTSP 4, where they pretty much managed and built the chroot > as a seperate distro, I think Wayland is going to break LTSP with the > Muekow way of doing things. > > http://www.markshuttleworth.com/archives/date/2010/11 > http://wayland.freedesktop.org/http://wayland.freedesktop.org/ Yeah, that is an issue, though I expect X won't just disappear in the real near term. > So what do we do? Personally, I think there are at least a couple solutions. > > 1) > Spice. The new remote VM technology that is in Fedora 14 and RHEL6. > The management gui needs to get better in Fedora, but that's coming. > Server requirements will be higher than ltsp as each desktop will have > a VM running (not just a desktop and apps). But advantage will be > complete customization per client and heterogeneous (windows+linux) > environments ( at the expense of ease of administration, unless there > are nice gui tools to manage multiple vm's simultaneously ) Yes, this is better than distributed fat clients but not much since you need hardware for all the clients in the server. Agreed that having a set of tools to manage multiple VMs would help keep administration manageable. > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot > process via pxe but ALL processes run locally. Only the filesystem is > remote via nfs. There is no need for special plumbing for sound or > local devices. Everything works like a stand alone system. Except the > first time to launch (not run) apps is slightly longer since the > binary needs to be downloaded into local ram from the network before > it can be run. One user can't hog ram or cpu. Full class of full > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of the diskless client OS. Local apps with LTSP cannot do this. > Although I do have dual gigabit nics for the lan and hardware raid 10 > for the server. Each client can have it's own nfs mounted /etc and > /var so there can still be customization per client. This seems to be the best option out there today if LTSP has some serious issues in a particular environment (ex: see item 3 above). Ultimately I think a hybrid environment is probably required for most organizations. If you can use LTSP it is the lightest weight -- both for hardware and administration. After that DRBL keeps the admin benefits but requires full desktop hardware on the client side. VMs keep the client light (presumably) but have serious server side hardware and administration requirements. NX fits is there close to LTSP too. The right solution is whatever works in a given environment. Jeff From ltsp at symbio-technologies.com Mon Nov 8 22:26:32 2010 From: ltsp at symbio-technologies.com (Gideon Romm) Date: Mon, 8 Nov 2010 17:26:32 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: <4CD864B0.2010908@siddall.name> References: <4CD864B0.2010908@siddall.name> Message-ID: Keep in mind, LTSP is multi-dimensional, as well. We have the ability to run: 1. All apps on the server 2. Most apps on the server, some on the client (localapps) 3. Most apps on the client, some on the server (fat client + remote apps) 4. All apps on the client (remote apps) We also have the ability to: 1. Connect to the boot server for applications 2. Connect to a load balancer-managed app server (LTSP cluster) 3. Connect to a dedicated remote server for app server 4. Connect to a VM Along with the ability to do so with: 1. LDM (X-over-ssh) 2. XDMCP 3. NX 4. Your desired protocol here .... And most of what we work on is making all of this simpler to set up. So, while we may see in many countries a gradual decline in the use of LTSP as a single server that connects low-end clients to itself to run all applications, that does not mean that LTSP will go away, because LTSP is not a one-dimensional project. Plus, we have way too much fun as devs getting together in Southwest Harbor, Maine every year to code and drink beer. :) Here's a toast to the freedom to use LTSP as you need! -Gadi From microman at cmosnetworks.com Mon Nov 8 22:57:22 2010 From: microman at cmosnetworks.com (Terrell Prude' Jr.) Date: Mon, 08 Nov 2010 17:57:22 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: <4CD88052.3080100@cmosnetworks.com> For now, that may be true in a lot of K-12 cases. But remember that all this stuff goes in cycles. Years ago, you had armies of X-terms and Sun thin clients TFTP-booting and such. I remember using them in college. Then we went to armies of thick clients. Later, LTSP took us right back because of the economics of hardware. Now we're cycling away from that again. Flash has always been a problem. However, hopefully HTML5 will help out with that going forward. I've always despised Flash anyway. In corporate environments in particular, where employees are typically expected to be doing work instead of watching movies all day, the video/Flash issue isn't nearly as problematic. Most office personnel need a word processor, spreadsheet, a Web browser, and little else. Further, the huge maintenance issues that thick clients (especially Microsoft thick clients) go away with LTSP environments. So, maybe K12-specific LTSP might not be as good a fit as it was 5 years ago, but I'd still consider outfitting a classroom with it if it met the educational requirements. --TP Robert Arkiletian wrote: > In my opinion, the days of LTSP are numbered. For a few different reasons. > > 1) > hardware is so cheap now. You can buy a brand new power efficient and > fast desktop system for about $200 (not including monitor). Thin > clients are actually *more* expensive now. > > 2) > programs like flash and java based apps don't work and will never work > well in an LTSP environment because they are multithreaded and utilize > all cores on the server. So no matter how powerful a server, running > many flash or java apps bring it to it's knees. Things were better > when all apps were single threaded. As time goes on this will only get > worse as cpu makers are increasing cores not mhz, so software makers > are adapting by making apps utilize all cores. Local apps is a > solution in the right direction but it brings with it other problems > like using fuse (ltspfs) and other issues. The other problem with > local apps, in an ltsp client, is that usually true thin client cpu's > are weak (eg. Atom). The concept of Local apps is 180 degrees to what > LTSP is about. > > 3) > Things get even worse when you run video full screen because the data > is being decoded (high cpu hit) at the server, then pushing *large* > decompressed data across the lan. It just doesn't scale well. > > 4) > If Ubuntu is successful with their move to Wayland display server > (away from X), LTSP may not even work as Wayland has no network > transparency as X does. Not sure if having X as a client itself on top > of Wayland will work with LTSP. My guess is it will be troublesome > because the client will need Wayland up first before X (which btw > means it will also definitely need an opengl capable chipset). I > suspect that unless the LTSP project goes back to the way they did > things in LTSP 4, where they pretty much managed and built the chroot > as a seperate distro, I think Wayland is going to break LTSP with the > Muekow way of doing things. > > http://www.markshuttleworth.com/archives/date/2010/11 > http://wayland.freedesktop.org/http://wayland.freedesktop.org/ > > So what do we do? Personally, I think there are at least a couple solutions. > > 1) > Spice. The new remote VM technology that is in Fedora 14 and RHEL6. > The management gui needs to get better in Fedora, but that's coming. > Server requirements will be higher than ltsp as each desktop will have > a VM running (not just a desktop and apps). But advantage will be > complete customization per client and heterogeneous (windows+linux) > environments ( at the expense of ease of administration, unless there > are nice gui tools to manage multiple vm's simultaneously ) > > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot > process via pxe but ALL processes run locally. Only the filesystem is > remote via nfs. There is no need for special plumbing for sound or > local devices. Everything works like a stand alone system. Except the > first time to launch (not run) apps is slightly longer since the > binary needs to be downloaded into local ram from the network before > it can be run. One user can't hog ram or cpu. Full class of full > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of the diskless client OS. Local apps with LTSP cannot do this. > Although I do have dual gigabit nics for the lan and hardware raid 10 > for the server. Each client can have it's own nfs mounted /etc and > /var so there can still be customization per client. > > > From Steven at SimplyCircus.com Mon Nov 8 23:29:07 2010 From: Steven at SimplyCircus.com (Steven Santos) Date: Mon, 8 Nov 2010 18:29:07 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: > -----Original Message----- > From: k12osn-bounces at redhat.com [mailto:k12osn-bounces at redhat.com] On > > In my opinion, the days of LTSP are numbered. For a few different > reasons. > > 1) > hardware is so cheap now. You can buy a brand new power efficient and > fast desktop system for about $200 (not including monitor). Thin > clients are actually *more* expensive now. Agreed. > 2) > programs like flash and java based apps don't work and will never work > well in an LTSP environment because they are multithreaded and utilize > all cores on the server. So no matter how powerful a server, running > many flash or java apps bring it to it's knees. Things were better > when all apps were single threaded. As time goes on this will only get > worse as cpu makers are increasing cores not mhz, so software makers > are adapting by making apps utilize all cores. Local apps is a > solution in the right direction but it brings with it other problems > like using fuse (ltspfs) and other issues. The other problem with > local apps, in an ltsp client, is that usually true thin client cpu's > are weak (eg. Atom). The concept of Local apps is 180 degrees to what > LTSP is about. Yes and no. Local apps is a solution to some of the problems of LTSP. I think the future of computing will involve running apps locally that make sense to run locally, and running apps remotely where it makes sense to, and running diskless fats (DRBL) where it makes sense. But I am not sure the current model is it. I think we will see a rise in app servers and processing servers and more local apps with LTSP to tie it together. I also think VM's will play a rather large part in this. > 3) > Things get even worse when you run video full screen because the data > is being decoded (high cpu hit) at the server, then pushing *large* > decompressed data across the lan. It just doesn't scale well. No, but this should generally be a local app. > 4) > If Ubuntu is successful with their move to Wayland display server > (away from X), LTSP may not even work as Wayland has no network > transparency as X does. Not sure if having X as a client itself on top > of Wayland will work with LTSP. My guess is it will be troublesome > because the client will need Wayland up first before X (which btw > means it will also definitely need an opengl capable chipset). I > suspect that unless the LTSP project goes back to the way they did > things in LTSP 4, where they pretty much managed and built the chroot > as a seperate distro, I think Wayland is going to break LTSP with the > Muekow way of doing things. > > http://www.markshuttleworth.com/archives/date/2010/11 > http://wayland.freedesktop.org/http://wayland.freedesktop.org/ > > So what do we do? Personally, I think there are at least a couple > solutions. > > 1) > Spice. The new remote VM technology that is in Fedora 14 and RHEL6. > The management gui needs to get better in Fedora, but that's coming. > Server requirements will be higher than ltsp as each desktop will have > a VM running (not just a desktop and apps). But advantage will be > complete customization per client and heterogeneous (windows+linux) > environments ( at the expense of ease of administration, unless there > are nice gui tools to manage multiple vm's simultaneously ) > > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot > process via pxe but ALL processes run locally. Only the filesystem is > remote via nfs. There is no need for special plumbing for sound or > local devices. Everything works like a stand alone system. Except the > first time to launch (not run) apps is slightly longer since the > binary needs to be downloaded into local ram from the network before > it can be run. One user can't hog ram or cpu. Full class of full > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of the diskless client OS. Local apps with LTSP cannot do this. > Although I do have dual gigabit nics for the lan and hardware raid 10 > for the server. Each client can have it's own nfs mounted /etc and > /var so there can still be customization per client. > > > -- > Robert Arkiletian > Eric Hamber Secondary, Vancouver, Canada > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see From robark at gmail.com Tue Nov 9 03:07:36 2010 From: robark at gmail.com (Robert Arkiletian) Date: Mon, 8 Nov 2010 19:07:36 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: <4CD864B0.2010908@siddall.name> References: <4CD864B0.2010908@siddall.name> Message-ID: On Mon, Nov 8, 2010 at 12:59 PM, Jeff Siddall wrote: > On 11/08/2010 03:27 PM, Robert Arkiletian wrote: >> In my opinion, ?the days of LTSP are numbered. For a few different reasons. > > Yes and no. ?See my comments inline. > >> 1) >> hardware is so cheap now. You can buy a brand new power efficient and >> fast ?desktop system for about $200 (not including monitor). ?Thin >> clients are actually *more* expensive now. > > Yes, hardware is petty cheap but even the most power efficient desktop > systems are about 5 X the power of a typical thin client. ?Over the life > of the client that can exceed the hardware cost. ?Plus any fanless > system is still a slow systems, and LTSP can make those slow fanless > clients feel like fast noisy desktops. I am going to measure my clients power usage tomorrow. I have Dell Opitiplex dual core Celeron e1400 (2Ghz) cpu with Intel Q43 chipset. and 2GB ram. Wondering if anyone has measured the power usage of a true thin client (eg. Atom) system. > > Thin clients aren't any more expensive _if_ you don't buy expensive > models! ?I still buy my TCs in parts and assemble and it can be done for > low $100s, which is pretty reasonable. > >> 2) >> programs like flash and java based apps don't work and will never work >> well in an LTSP environment because they are multithreaded and utilize >> all cores on the server. So no matter how powerful a server, running >> many flash or java apps bring it to it's knees. Things were better >> when all apps were single threaded. As time goes on this will only get >> worse as cpu makers are increasing cores not mhz, so software makers >> are adapting by making apps utilize all cores. Local apps is a >> solution in the right direction but it brings with it other problems >> like using fuse (ltspfs) and other issues. The other problem with >> local apps, in an ltsp client, is that usually true thin client cpu's >> are weak (eg. Atom). The concept of Local apps is 180 degrees to what >> LTSP is about. > > Yup, these are somewhat difficult, but ultimately a clock cycle is a > clock cycle and if your client is using 6 cores on your server it is > probably faster than the one or two cores on their client. > >> 3) >> Things get even worse when you run video full screen because the data >> is being decoded (high cpu hit) at the server, then pushing *large* >> decompressed data across the lan. It just doesn't scale well. > > Fully agree. ?Video is the real problem child for LTSP. ?I run dedicated > video apps (VLC) as localapps but flash inside a browser (ex: YouTube) > just doesn't work well on LTSP. > Flash is on it's way down as youtube switches so html5/webm. Apple is helping flash die too. >> 4) >> If Ubuntu is successful with their move to Wayland display server >> (away from X), LTSP may not even work as Wayland has no network >> transparency as X does. Not sure if having X as a client itself on top >> of Wayland will work with LTSP. My guess is it will be troublesome >> because the client will need Wayland up first before X (which btw >> means it will also definitely need an opengl capable chipset). I >> suspect that unless the LTSP project goes back to the way they did >> things in LTSP 4, where they pretty much managed and built the chroot >> as a seperate distro, I think Wayland is going to break LTSP with the >> Muekow way of doing things. >> >> http://www.markshuttleworth.com/archives/date/2010/11 >> http://wayland.freedesktop.org/http://wayland.freedesktop.org/ > > Yeah, that is an issue, though I expect X won't just disappear in the > real near term. > I agree X will be around for a long time. >> So what do we do? Personally, I think there are at least a couple solutions. >> >> 1) >> Spice. The new remote VM technology that is in Fedora 14 and RHEL6. >> The management gui needs to get better in Fedora, but that's coming. >> Server requirements will be higher than ltsp as each desktop will have >> a VM running (not just a desktop and apps). But advantage will be >> complete customization per client and heterogeneous (windows+linux) >> environments ( at the expense of ease of administration, unless there >> are nice gui tools to manage multiple vm's simultaneously ) > > Yes, this is better than distributed fat clients but not much since you > need hardware for all the clients in the server. ?Agreed that having a > set of tools to manage multiple VMs would help keep administration > manageable. > >> 2) >> DRBL. This is the route I have taken. It's similar to ltsp boot >> process via pxe but ALL processes run locally. Only the filesystem is >> remote via nfs. There is no need for special plumbing for sound or >> local devices. Everything works like a stand alone system. Except the >> first time to launch (not run) apps is slightly longer since the >> binary needs to be downloaded into local ram from the network before >> it can be run. One user can't hog ram or cpu. Full class of full >> screen video and flash, no problem. I even have had an entire class of >> students simultaneously install and run Ubuntu in a Virtualbox VM on >> top of ?the diskless client OS. Local apps with LTSP cannot do this. >> Although I do have dual gigabit nics for the lan and hardware raid 10 >> for the server. Each client can have it's own nfs mounted /etc and >> /var so there can still be customization per client. > > This seems to be the best option out there today if LTSP has some > serious issues in a particular environment (ex: see item 3 above). > > Ultimately I think a hybrid environment is probably required for most > organizations. ?If you can use LTSP it is the lightest weight -- both > for hardware and administration. ?After that DRBL keeps the admin > benefits but requires full desktop hardware on the client side. ?VMs > keep the client light (presumably) but have serious server side hardware > and administration requirements. ?NX fits is there close to LTSP too. > > The right solution is whatever works in a given environment. > > Jeff > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From charlie at smbis.com Tue Nov 9 04:57:27 2010 From: charlie at smbis.com (Charlie) Date: Mon, 08 Nov 2010 23:57:27 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: <4CD864B0.2010908@siddall.name> Message-ID: <1289278647.4347.2.camel@d820> The Foxconn NetBox-nT410 I'm using with Ubuntu 10.10 LTSP as a thin-client pulls between 13 and 14 watts while in use. On Mon, 2010-11-08 at 19:07 -0800, Robert Arkiletian wrote: > On Mon, Nov 8, 2010 at 12:59 PM, Jeff Siddall wrote: > > On 11/08/2010 03:27 PM, Robert Arkiletian wrote: > >> In my opinion, the days of LTSP are numbered. For a few different reasons. > > > > Yes and no. See my comments inline. > > > >> 1) > >> hardware is so cheap now. You can buy a brand new power efficient and > >> fast desktop system for about $200 (not including monitor). Thin > >> clients are actually *more* expensive now. > > > > Yes, hardware is petty cheap but even the most power efficient desktop > > systems are about 5 X the power of a typical thin client. Over the life > > of the client that can exceed the hardware cost. Plus any fanless > > system is still a slow systems, and LTSP can make those slow fanless > > clients feel like fast noisy desktops. > > I am going to measure my clients power usage tomorrow. I have Dell > Opitiplex dual core Celeron e1400 (2Ghz) cpu with Intel Q43 chipset. > and 2GB ram. Wondering if anyone has measured the power usage of a > true thin client (eg. Atom) system. > > > > > Thin clients aren't any more expensive _if_ you don't buy expensive > > models! I still buy my TCs in parts and assemble and it can be done for > > low $100s, which is pretty reasonable. > > > >> 2) > >> programs like flash and java based apps don't work and will never work > >> well in an LTSP environment because they are multithreaded and utilize > >> all cores on the server. So no matter how powerful a server, running > >> many flash or java apps bring it to it's knees. Things were better > >> when all apps were single threaded. As time goes on this will only get > >> worse as cpu makers are increasing cores not mhz, so software makers > >> are adapting by making apps utilize all cores. Local apps is a > >> solution in the right direction but it brings with it other problems > >> like using fuse (ltspfs) and other issues. The other problem with > >> local apps, in an ltsp client, is that usually true thin client cpu's > >> are weak (eg. Atom). The concept of Local apps is 180 degrees to what > >> LTSP is about. > > > > Yup, these are somewhat difficult, but ultimately a clock cycle is a > > clock cycle and if your client is using 6 cores on your server it is > > probably faster than the one or two cores on their client. > > > >> 3) > >> Things get even worse when you run video full screen because the data > >> is being decoded (high cpu hit) at the server, then pushing *large* > >> decompressed data across the lan. It just doesn't scale well. > > > > Fully agree. Video is the real problem child for LTSP. I run dedicated > > video apps (VLC) as localapps but flash inside a browser (ex: YouTube) > > just doesn't work well on LTSP. > > > > Flash is on it's way down as youtube switches so html5/webm. Apple is > helping flash die too. > > >> 4) > >> If Ubuntu is successful with their move to Wayland display server > >> (away from X), LTSP may not even work as Wayland has no network > >> transparency as X does. Not sure if having X as a client itself on top > >> of Wayland will work with LTSP. My guess is it will be troublesome > >> because the client will need Wayland up first before X (which btw > >> means it will also definitely need an opengl capable chipset). I > >> suspect that unless the LTSP project goes back to the way they did > >> things in LTSP 4, where they pretty much managed and built the chroot > >> as a seperate distro, I think Wayland is going to break LTSP with the > >> Muekow way of doing things. > >> > >> http://www.markshuttleworth.com/archives/date/2010/11 > >> http://wayland.freedesktop.org/http://wayland.freedesktop.org/ > > > > Yeah, that is an issue, though I expect X won't just disappear in the > > real near term. > > > > I agree X will be around for a long time. > > >> So what do we do? Personally, I think there are at least a couple solutions. > >> > >> 1) > >> Spice. The new remote VM technology that is in Fedora 14 and RHEL6. > >> The management gui needs to get better in Fedora, but that's coming. > >> Server requirements will be higher than ltsp as each desktop will have > >> a VM running (not just a desktop and apps). But advantage will be > >> complete customization per client and heterogeneous (windows+linux) > >> environments ( at the expense of ease of administration, unless there > >> are nice gui tools to manage multiple vm's simultaneously ) > > > > Yes, this is better than distributed fat clients but not much since you > > need hardware for all the clients in the server. Agreed that having a > > set of tools to manage multiple VMs would help keep administration > > manageable. > > > >> 2) > >> DRBL. This is the route I have taken. It's similar to ltsp boot > >> process via pxe but ALL processes run locally. Only the filesystem is > >> remote via nfs. There is no need for special plumbing for sound or > >> local devices. Everything works like a stand alone system. Except the > >> first time to launch (not run) apps is slightly longer since the > >> binary needs to be downloaded into local ram from the network before > >> it can be run. One user can't hog ram or cpu. Full class of full > >> screen video and flash, no problem. I even have had an entire class of > >> students simultaneously install and run Ubuntu in a Virtualbox VM on > >> top of the diskless client OS. Local apps with LTSP cannot do this. > >> Although I do have dual gigabit nics for the lan and hardware raid 10 > >> for the server. Each client can have it's own nfs mounted /etc and > >> /var so there can still be customization per client. > > > > This seems to be the best option out there today if LTSP has some > > serious issues in a particular environment (ex: see item 3 above). > > > > Ultimately I think a hybrid environment is probably required for most > > organizations. If you can use LTSP it is the lightest weight -- both > > for hardware and administration. After that DRBL keeps the admin > > benefits but requires full desktop hardware on the client side. VMs > > keep the client light (presumably) but have serious server side hardware > > and administration requirements. NX fits is there close to LTSP too. > > > > The right solution is whatever works in a given environment. > > > > Jeff > > > > _______________________________________________ > > K12OSN mailing list > > K12OSN at redhat.com > > https://www.redhat.com/mailman/listinfo/k12osn > > For more info see > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From news at siddall.name Tue Nov 9 16:25:19 2010 From: news at siddall.name (Jeff Siddall) Date: Tue, 09 Nov 2010 11:25:19 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: <4CD864B0.2010908@siddall.name> Message-ID: <4CD975EF.3080603@siddall.name> On 11/08/2010 10:07 PM, Robert Arkiletian wrote: > On Mon, Nov 8, 2010 at 12:59 PM, Jeff Siddall wrote: >> On 11/08/2010 03:27 PM, Robert Arkiletian wrote: >>> In my opinion, the days of LTSP are numbered. For a few different reasons. >> >> Yes and no. See my comments inline. >> >>> 1) >>> hardware is so cheap now. You can buy a brand new power efficient and >>> fast desktop system for about $200 (not including monitor). Thin >>> clients are actually *more* expensive now. >> >> Yes, hardware is petty cheap but even the most power efficient desktop >> systems are about 5 X the power of a typical thin client. Over the life >> of the client that can exceed the hardware cost. Plus any fanless >> system is still a slow systems, and LTSP can make those slow fanless >> clients feel like fast noisy desktops. > > I am going to measure my clients power usage tomorrow. I have Dell > Opitiplex dual core Celeron e1400 (2Ghz) cpu with Intel Q43 chipset. > and 2GB ram. Wondering if anyone has measured the power usage of a > true thin client (eg. Atom) system. Yes, definitely. I measure the power consumption of all my systems. My typical Atom based clients are D945GSEJTs and they run about 14 W at the plug. The board itself is spec'd somewhere in the 12 W range. A very low power desktop system with a 45 W TDP single core Sempron LE-1200, M2N PV-VM board and 80 GB Seagate ATA HD still runs at 57 W idle, 86 W at 100% CPU. The hard drive runs about 9 W so you can remove that much for a diskless system. By comparison, a relatively modern Phenom II X4 940, with dual Seagate 250 GB SATA runs at 71 W idle and 171 W with the CPU running 100% Jeff From robark at gmail.com Tue Nov 9 23:09:22 2010 From: robark at gmail.com (Robert Arkiletian) Date: Tue, 9 Nov 2010 15:09:22 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: <4CD975EF.3080603@siddall.name> References: <4CD864B0.2010908@siddall.name> <4CD975EF.3080603@siddall.name> Message-ID: On Tue, Nov 9, 2010 at 8:25 AM, Jeff Siddall wrote: > On 11/08/2010 10:07 PM, Robert Arkiletian wrote: >> On Mon, Nov 8, 2010 at 12:59 PM, Jeff Siddall wrote: >>> On 11/08/2010 03:27 PM, Robert Arkiletian wrote: >>>> In my opinion, ?the days of LTSP are numbered. For a few different reasons. >>> >>> Yes and no. ?See my comments inline. >>> >>>> 1) >>>> hardware is so cheap now. You can buy a brand new power efficient and >>>> fast ?desktop system for about $200 (not including monitor). ?Thin >>>> clients are actually *more* expensive now. >>> >>> Yes, hardware is petty cheap but even the most power efficient desktop >>> systems are about 5 X the power of a typical thin client. ?Over the life >>> of the client that can exceed the hardware cost. ?Plus any fanless >>> system is still a slow systems, and LTSP can make those slow fanless >>> clients feel like fast noisy desktops. >> >> I am going to measure my clients power usage tomorrow. I have Dell >> Opitiplex dual core Celeron e1400 (2Ghz) cpu with Intel Q43 chipset. >> and 2GB ram. Wondering if anyone has measured the power usage of a >> true thin client (eg. Atom) system. > > Yes, definitely. ?I measure the power consumption of all my systems. > > My typical Atom based clients are D945GSEJTs and they run about 14 W at > the plug. ?The board itself is spec'd somewhere in the 12 W range. > > A very low power desktop system with a 45 W TDP single core Sempron > LE-1200, M2N PV-VM board and 80 GB Seagate ATA HD still runs at 57 W > idle, 86 W at 100% CPU. ?The hard drive runs about 9 W so you can remove > that much for a diskless system. > > By comparison, a relatively modern Phenom II X4 940, with dual Seagate > 250 GB SATA runs at 71 W idle and 171 W with the CPU running 100% Got some numbers from my kill-a-watt meter: Dell Optiplex 760 (running DRBL client) e1400 dual core Celeron (Allendale 65nm) 2.0Ghz Q43 Intel chipset 2 GB ram gnome desktop + FF(google.ca) = 45W gnome desktop + FF(youtube 720p fullscreen) = 60-65W (fluctuates) A real dual core Atom thin client running LTSP ~ 19W (I don't have an Atom based thin client to test. This is from some googling ymmv) Assume average usage is 49W for the Dell over a work day. 49-19= 30W difference (omitting monitor) 30W * 8hrs/day * 190 work days/school year = 45.6 KWh for 1 system/year Assume a large school has 180 systems. 180 systems * 45.6 KWh/system/year = 8208 KWh/year for 1 school At $0.08/KWh for electricity for public sector K-12 schools (this varies where you live) (see http://www.eia.doe.gov/electricity/epm/table5_6_a.html) 8208 KWh/year * $0.08/KWh = $656.64 / year/ school savings using fat diskless vs thin client Oh course this will vary depending on your own systems but it gives a ball park. If a district has say 15 schools of this size that's almost $10,000 savings per year for a district. But that's assuming you have 100% homogeneous systems (rarely the case). If I have made any errors or omissions please correct me. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From rowens at ptd.net Wed Nov 10 02:38:08 2010 From: rowens at ptd.net (Rob Owens) Date: Tue, 9 Nov 2010 21:38:08 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: <20101110023808.GA8043@aurora.owens.net> On Mon, Nov 08, 2010 at 12:27:06PM -0800, Robert Arkiletian wrote: > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot > process via pxe but ALL processes run locally. Only the filesystem is > remote via nfs. There is no need for special plumbing for sound or > local devices. Everything works like a stand alone system. Except the > first time to launch (not run) apps is slightly longer since the > binary needs to be downloaded into local ram from the network before > it can be run. One user can't hog ram or cpu. Full class of full > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of the diskless client OS. Local apps with LTSP cannot do this. > Although I do have dual gigabit nics for the lan and hardware raid 10 > for the server. Each client can have it's own nfs mounted /etc and > /var so there can still be customization per client. > Does DRBL have provisions for running a different architecture on the server and the clients? Last I checked it did not. Of course that's only an issue if you're using old clients, and pretty soon "old clients" will be 64 bit anyway. I'll add another option to the list. I've never tested it, but Debian Live has network version which downloads an entire compressed live image from a server to a client. I think it can be done either via pxe or a syslinux menu. This allows each client to run a live system (similar to a live cd or live usb) without having to physically distribute a cd to the clients. As I understand it, you can use a USB flash drive to save your files and settings (it's referred to as "persistence"). I wonder if the persistence files could also be installed on a central server. In any case, a network-distributed Debian Live would be similar to DRBL in practice. It might require less per-client configuration, since a live system is designed to boot and run on just about anything. It would definitely be architecture independent. An amd64 server could serve out images for i386, ARM, etc. I'm not sure if other distros have a similar option with their live systems or not. -Rob From robark at gmail.com Wed Nov 10 05:25:43 2010 From: robark at gmail.com (Robert Arkiletian) Date: Tue, 9 Nov 2010 21:25:43 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: <20101110023808.GA8043@aurora.owens.net> References: <20101110023808.GA8043@aurora.owens.net> Message-ID: On Tue, Nov 9, 2010 at 6:38 PM, Rob Owens wrote: > On Mon, Nov 08, 2010 at 12:27:06PM -0800, Robert Arkiletian wrote: >> 2) >> DRBL. This is the route I have taken. It's similar to ltsp boot >> process via pxe but ALL processes run locally. Only the filesystem is >> remote via nfs. There is no need for special plumbing for sound or >> local devices. Everything works like a stand alone system. Except the >> first time to launch (not run) apps is slightly longer since the >> binary needs to be downloaded into local ram from the network before >> it can be run. One user can't hog ram or cpu. Full class of full >> screen video and flash, no problem. I even have had an entire class of >> students simultaneously install and run Ubuntu in a Virtualbox VM on >> top of ?the diskless client OS. Local apps with LTSP cannot do this. >> Although I do have dual gigabit nics for the lan and hardware raid 10 >> for the server. Each client can have it's own nfs mounted /etc and >> /var so there can still be customization per client. >> > Does DRBL have provisions for running a different architecture on the > server and the clients? ?Last I checked it did not. ?Of course that's > only an issue if you're using old clients, and pretty soon "old clients" > will be 64 bit anyway. No. Unfortunately, server and clients must be same arch. Only one exception see below. > > I'll add another option to the list. ?I've never tested it, but Debian > Live has network version which downloads an entire compressed live image > from a server to a client. ?I think it can be done either via pxe or > a syslinux menu. ?This allows each client to run a live system (similar > to a live cd or live usb) without having to physically distribute a cd > to the clients. > Apparently, DRBL can do this too with DSL or Puppy ( or other small live linux iso) But I have not tried it yet. http://drbl.sourceforge.net/one4all/techrpt.php?c=drbl-SL.sh&t=Load%20Small%20GNU/Linux%20%28DSL,%20PuppyLinux,%20INSERT,%20or%20PLD%29%20into%20DRBL%20environment > As I understand it, you can use a USB flash drive to save your files and > settings (it's referred to as "persistence"). ?I wonder if the > persistence files could also be installed on a central server. > > In any case, a network-distributed Debian Live would be similar to DRBL > in practice. ?It might require less per-client configuration, since a > live system is designed to boot and run on just about anything. ?It > would definitely be architecture independent. ?An amd64 server could > serve out images for i386, ARM, etc. > > I'm not sure if other distros have a similar option with their live > systems or not. > BTW DRBL is made by the same guys that make Clonezilla. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From Steven at SimplyCircus.com Wed Nov 10 23:34:55 2010 From: Steven at SimplyCircus.com (Steven Santos) Date: Wed, 10 Nov 2010 18:34:55 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: K12LTSP was a success because it did everything we needed it to do, and it did it with little fuss. What if the future is not in a given tech, but in the concept or what Eric did way back when? Why couldn't we come up with a system where you use one DVD to setup and install a complete working linux network for a school. This should allow for all network services commonly needed in a school setting, including: - Student administration - Admin / Teacher desktops (DRBL) - SIS including classes, grade, etc - Accounting - Classroom Services - Student desktops (DRBL) - Moodle virtual classroom - School Wide Wiki - Lab services - Writing lab (LTSP) - Science lab (DRBL) - Library Services - KOHA / OPEC - Library desktops (DRBL) - Common network services - School-wide print services - Restricted Internet access, filtering and local caching - Lunchroom / School Store - POS terminals Step 1: setup the servers - DNS / DHCP servers - 389 Directory Server - Set up the network admin group (auto) - Set up the office/admin group (auto) - Set up the teacher group (auto) - Set up the Lunchroom group (auto) - Set up the schoolstore group (auto) - Set up the student groups (auto, by class, graduating year) - Set up software access groups (interactive) - NIS / Kerbos (using 389DS) - Generate certificates - Copy certificates to USB drive or NFS share for later use - SAMBA4 (setup using LDAP/NIS authentication) - Set up domain for use with windows clients - MySQL server (setup using LDAP/NIS authentication) - CUPS print server (setup using LDAP/NIS authentication) - File Server (/home server) - DRBL Server (setup using LDAP/NIS authentication) - SQUID web proxy (restrict net access / setup with LDAP) - Setup the virtual servers - Remote Access Server (remote. / ptpp server setup using LDAP) - Mail server (mail. / setup using LDAP) - Apache server (www. and web. / setup using LDAP) - Koha server (library. / setup using LDAP) - School Tool (sis. / setup using LDAP) - Moodle (moodle. / setup using LDAP) Step 2: setup the DRBL (Diskless Remote Boot in Linux) boot images - Staff desktops with NIS/LDAP authentication. - Standard education image with NIS/LDAP authentication - Library PC image / standard image with addition of a local, no pwd acct, but with restrictions on what apps it can launch without being logged in as a standard user - Kiosks image / web browser only, no local log-in option, fixed start page - Point of Sale terminals Hmmm... --- Steven Santos Director, Simply Circus, Inc. Email: Steven at SimplyCircus.com Gym: 86 Los Angeles Street Newton, MA 02458 Mail: 14 Pierrepont Road Newton, MA 02462 Phone: 617-527-0667 Fax: 617-934-1870 Web: www.SimplyCircus.com From gerrylist at drouillard.ca Thu Nov 11 00:13:28 2010 From: gerrylist at drouillard.ca (Gerald Drouillard) Date: Wed, 10 Nov 2010 19:13:28 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: <4CDB3528.3040007@drouillard.ca> On 11/10/2010 6:34 PM, Steven Santos wrote: > K12LTSP was a success because it did everything we needed it to do, and it > did it with little fuss. > > What if the future is not in a given tech, but in the concept or what Eric > did way back when? > > Why couldn't we come up with a system where you use one DVD to setup and > install a complete working linux network for a school. This should allow > for all network services commonly needed in a school setting, including: > Don't forget a phone/sip server... http://www.sipfoundry.org/ -- Regards -------------------------------------- Gerald Drouillard Technology Architect Drouillard & Associates, Inc. http://www.Drouillard.biz From charlie at smbis.com Thu Nov 11 01:24:54 2010 From: charlie at smbis.com (Charlie) Date: Wed, 10 Nov 2010 20:24:54 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: <1289438694.1739.258.camel@d820> So realistically, DRBL is limited as well since it requires like architecture on the server and client, as in you can't have a really robust x64 based LTSP server and a x86 based client solution. Not much use in running a high end server hardware system on a 32bit x86 OS. On Mon, 2010-11-08 at 12:27 -0800, Robert Arkiletian wrote: > In my opinion, the days of LTSP are numbered. For a few different reasons. > > 1) > hardware is so cheap now. You can buy a brand new power efficient and > fast desktop system for about $200 (not including monitor). Thin > clients are actually *more* expensive now. > > 2) > programs like flash and java based apps don't work and will never work > well in an LTSP environment because they are multithreaded and utilize > all cores on the server. So no matter how powerful a server, running > many flash or java apps bring it to it's knees. Things were better > when all apps were single threaded. As time goes on this will only get > worse as cpu makers are increasing cores not mhz, so software makers > are adapting by making apps utilize all cores. Local apps is a > solution in the right direction but it brings with it other problems > like using fuse (ltspfs) and other issues. The other problem with > local apps, in an ltsp client, is that usually true thin client cpu's > are weak (eg. Atom). The concept of Local apps is 180 degrees to what > LTSP is about. > > 3) > Things get even worse when you run video full screen because the data > is being decoded (high cpu hit) at the server, then pushing *large* > decompressed data across the lan. It just doesn't scale well. > > 4) > If Ubuntu is successful with their move to Wayland display server > (away from X), LTSP may not even work as Wayland has no network > transparency as X does. Not sure if having X as a client itself on top > of Wayland will work with LTSP. My guess is it will be troublesome > because the client will need Wayland up first before X (which btw > means it will also definitely need an opengl capable chipset). I > suspect that unless the LTSP project goes back to the way they did > things in LTSP 4, where they pretty much managed and built the chroot > as a seperate distro, I think Wayland is going to break LTSP with the > Muekow way of doing things. > > http://www.markshuttleworth.com/archives/date/2010/11 > http://wayland.freedesktop.org/http://wayland.freedesktop.org/ > > So what do we do? Personally, I think there are at least a couple solutions. > > 1) > Spice. The new remote VM technology that is in Fedora 14 and RHEL6. > The management gui needs to get better in Fedora, but that's coming. > Server requirements will be higher than ltsp as each desktop will have > a VM running (not just a desktop and apps). But advantage will be > complete customization per client and heterogeneous (windows+linux) > environments ( at the expense of ease of administration, unless there > are nice gui tools to manage multiple vm's simultaneously ) > > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot > process via pxe but ALL processes run locally. Only the filesystem is > remote via nfs. There is no need for special plumbing for sound or > local devices. Everything works like a stand alone system. Except the > first time to launch (not run) apps is slightly longer since the > binary needs to be downloaded into local ram from the network before > it can be run. One user can't hog ram or cpu. Full class of full > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of the diskless client OS. Local apps with LTSP cannot do this. > Although I do have dual gigabit nics for the lan and hardware raid 10 > for the server. Each client can have it's own nfs mounted /etc and > /var so there can still be customization per client. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Nov 11 02:13:24 2010 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 10 Nov 2010 20:13:24 -0600 Subject: [K12OSN] Life after LTSP In-Reply-To: <1289438694.1739.258.camel@d820> References: <1289438694.1739.258.camel@d820> Message-ID: <4CDB5144.2060303@gmail.com> On 11/10/10 7:24 PM, Charlie wrote: > So realistically, DRBL is limited as well since it requires like architecture on > the server and client, as in you can't have a really robust x64 based LTSP > server and a x86 based client solution. Not much use in running a high end > server hardware system on a 32bit x86 OS. It should be pretty straightforward to run a virtual machine under xen, kvm, vmware, or virtualbox running DRBL per NIC (or perhaps VLAN) if you have a larger server. Home directories could be nfs-shared from the host and mounted to both VMs and clients. Or, maybe the DRBL mode that lets you boot the clients from a live-CD type image could be used. -- Les Mikesell lesmikesell at gmail.com From news at siddall.name Thu Nov 11 03:19:04 2010 From: news at siddall.name (Jeff Siddall) Date: Wed, 10 Nov 2010 22:19:04 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: <1289438694.1739.258.camel@d820> References: <1289438694.1739.258.camel@d820> Message-ID: <4CDB60A8.9040701@siddall.name> On 11/10/2010 08:24 PM, Charlie wrote: > So realistically, DRBL is limited as well since it requires like > architecture on the server and client, as in you can't have a really > robust x64 based LTSP server and a x86 based client solution. Not much > use in running a high end server hardware system on a 32bit x86 OS. Yes but... I suspect they envisioned that anyone running DRBL would be running relatively recent fat client hardware which would be 64 bit anyway. Even the current generation of the lowly Atom CPU (D4xx and D5xx) and the previous generation 330 support 64 bit. Jeff From robark at gmail.com Thu Nov 11 06:22:26 2010 From: robark at gmail.com (Robert Arkiletian) Date: Wed, 10 Nov 2010 22:22:26 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: <1289438694.1739.258.camel@d820> References: <1289438694.1739.258.camel@d820> Message-ID: On Wed, Nov 10, 2010 at 5:24 PM, Charlie wrote: > So realistically, DRBL is limited as well since it requires like > architecture on the server and client, as in you can't have a really robust > x64 based LTSP server and a x86 based client solution. Not much use in > running a high end server hardware system on a 32bit x86 OS. > I know wikipedia is not perfect but.... 64bit has been around since ~2004-2005. I pasted relevant stuff below. http://en.wikipedia.org/wiki/Intel_64#Intel_64 Intel 64 is Intel's implementation of x86-64. It is used in newer versions of Pentium 4, Celeron D, Xeon and Pentium Dual-Core processors, the Atom 230, 330, D510, N450, and N550, and in all versions of the Pentium D, Pentium Extreme Edition, Core 2, Core i7, Core i5 and Core i3 processors. http://en.wikipedia.org/wiki/List_of_Intel_microprocessors#Pentium_4E Pentium 4E * Introduced February 2004 * built on 0.09 ?m (90 nm) process technology Prescott (2.4A, 2.8, 2.8A, 3.0, 3.2, 3.4, 3.6, 3.8) 1 MB L2 cache ... * LGA 775 versions are in the 5xx series (32-bit) and 5x1 series (with Intel 64) * The 6xx series has 2 MB L2 cache and Intel 64 Pentium 4F * Introduced Spring 2004 * same core as 4E, "Prescott" * 3.2?3.6 GHz * starting with the D0 stepping of this processor, Intel 64 64-bit extensions has also been incorporated http://en.wikipedia.org/wiki/Celeron#Prescott-256 In mid-2005, Intel refreshed the Celeron D with Intel 64 and XD Bit (eXecute Disable) enabled. Model numbers increase by 1 over the previous generation (e.g., 330 became 331). This only applied to LGA 775 Celeron Ds. There are no Socket 478 CPUs with 64-bit or XD Bit capabilities. http://en.wikipedia.org/wiki/AMD64#AMD64 "The AMD64 instruction set is implemented in AMD's Athlon 64, Athlon 64 FX, Athlon 64 X2, Athlon II, Athlon X2, Opteron, Phenom, Phenom II, Turion 64, Turion 64 X2, and later Sempron processors." http://en.wikipedia.org/wiki/Athlon_64 The Athlon 64 is an eighth-generation, AMD64-architecture microprocessor produced by AMD, released on September 23, 2003. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From lighthumor at hotmail.com Thu Nov 11 14:19:07 2010 From: lighthumor at hotmail.com (michael howard) Date: Thu, 11 Nov 2010 09:19:07 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: > So what do we do? Personally, I think there are at least a couple solutions. > > 1) > Spice. The new remote VM technology that is in Fedora 14 and RHEL6. ... > 2) > DRBL. This is the route I have taken. It's similar to ltsp boot There is also Multiseat/ultra-thin client, and similar ideas, which seem to be growing. Even lighter systems, cabling, costs and energy than LTSP/thin clients. The displays are sometimes local to the server via multi-monitors, so no bitmaps-over-lan bandwidth problems with video, games. etc. It's been adopted quite a bit in Brazil, as has LTSP. Microsoft launched a multiseat product. http://wiki.c3sl.ufpr.br/multiseat/index.php/Mdm ( <- debian-ubuntu compatible open source ) http://www.microsoft.com/multipoint/ http://www.userful.com/products/userful-multiseat-linux http://www.ndiyo.org/news http://www.thinnetworks.com.br/index.php?option=com_content&view=article&id=29&Itemid=103 But thin clients in general seem to be doing fine, similar technologies to LTSP are continuing to do well, all with the same local-media-and-devices problems - motion video, audio in/out, games-animation-3d, multiple USB local devices, local removable media. But Linux/Unix has a huge advantage in the shared-memory, X.org, native multiuser, source access, etc. Big-fat clients, with tons of video, storage, processing, connectivity, will of course always have advantages. But growing clouds, distributed-processing, clusters and smartphones seem like huge confirmations that it is far from being the only model any more. If anything it seems that LTSP has ever more technologies and directions to choose from and grow towards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robark at gmail.com Thu Nov 11 19:24:49 2010 From: robark at gmail.com (Robert Arkiletian) Date: Thu, 11 Nov 2010 11:24:49 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: Sorry to those of you who are on the Edubuntu list but I'm copy/pasting a message from that list to this one as I think it's an interesting topic. On Tue, Nov 9, 2010 at 6:30 AM, Jonathan Carter (highvoltage) wrote: ... > > Either way, cheap devices are certainly going to change things > eventually. Everyone's walking with more and more powerful computers in > their pockets. All that they might need is a bigger keyboard and screen > to connect to in their classrooms. > > I think it will cause a whole bunch of new challenges for schools and > software companies. How are commercial educational products going to be > licensed? Per school? Will students have to buy it theirselves? How will > software be managed and deployed? I know that I certainly wouldn't want > to give my school (if I had one) root access to my device to do stuff on > it without me knowing about it. My guess is that in a few years from > now, students will do most of their work on web enabled devices that > connect to their school's web services. I'm probably stating the obvious > with that, since it's already happening in many schools, but even then I > think there'll be some use for some desktops running in a diskless > environment. Hi Jonathan, I think you hit the nail on the head. Things are changing. I've been a high school teacher for 14 years. Recently, I've been seeing more and more students coming to school with their own laptops. This transition to students having their own mobile devices has already happened in colleges/universities. Currently, the big push at the secondary level is getting wireless access to the entire school. Focus is slowly shifting away from traditional computer lab infrastructure to one where kids bring their own mobile device (or maybe the school provides one). It brings up the question: what about kids that can't afford their own laptops? Also, who manages these systems? They don't belong to the school. We can't touch them. About the only thing we can do is have a terms of use agreement pop up when they connect and ask them to agree (maybe register their name with their mac address) but that's about it. Right now if an english teacher wants his/her students to access the web they need to book a computer lab to use for that period. I don't think that's going to be the case in the future. I remember when no students had cell phones, now almost all do. This also brings up the possibility of introducing ebooks. Publishers of textbooks are already seeing this demand from post secondary institutions. No more giant backpacks full of textbooks. In addition, imagine instead of photocopying a handout for all students a teacher just posts the handout to a website which all students access instantly. Photocopying costs at my school are huge. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From Steven at SimplyCircus.com Thu Nov 11 21:00:31 2010 From: Steven at SimplyCircus.com (Steven Santos) Date: Thu, 11 Nov 2010 16:00:31 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: The issue of students having access to software could be solved easily enough by issuing a VM image to each student. Need and update? DL a new image from the server. --- Steven Santos Director, Simply Circus, Inc. Email: Steven at SimplyCircus.com Gym: 86 Los Angeles Street Newton, MA 02458 Mail: 14 Pierrepont Road Newton, MA 02462 Phone: 617-527-0667 Fax: 617-934-1870 Web: www.SimplyCircus.com > -----Original Message----- > From: k12osn-bounces at redhat.com [mailto:k12osn-bounces at redhat.com] On > Behalf Of Robert Arkiletian > Sent: Thursday, November 11, 2010 2:25 PM > To: Support list for open source software in schools. > Subject: Re: [K12OSN] Life after LTSP > > Sorry to those of you who are on the Edubuntu list but I'm > copy/pasting a message from that list to this one as I think it's an > interesting topic. > > On Tue, Nov 9, 2010 at 6:30 AM, Jonathan Carter (highvoltage) > wrote: > ... > > > > Either way, cheap devices are certainly going to change things > > eventually. Everyone's walking with more and more powerful computers > in > > their pockets. All that they might need is a bigger keyboard and > screen > > to connect to in their classrooms. > > > > I think it will cause a whole bunch of new challenges for schools and > > software companies. How are commercial educational products going to > be > > licensed? Per school? Will students have to buy it theirselves? How > will > > software be managed and deployed? I know that I certainly wouldn't > want > > to give my school (if I had one) root access to my device to do stuff > on > > it without me knowing about it. My guess is that in a few years from > > now, students will do most of their work on web enabled devices that > > connect to their school's web services. I'm probably stating the > obvious > > with that, since it's already happening in many schools, but even > then I > > think there'll be some use for some desktops running in a diskless > > environment. > > Hi Jonathan, > > I think you hit the nail on the head. Things are changing. I've been > a high school teacher for 14 years. Recently, I've been seeing more > and more students coming to school with their own laptops. This > transition to students having their own mobile devices has already > happened in colleges/universities. > > Currently, the big push at the secondary level is getting wireless > access to the entire school. Focus is slowly shifting away from > traditional computer lab infrastructure to one where kids bring their > own mobile device (or maybe the school provides one). It brings up the > question: what about kids that can't afford their own laptops? Also, > who manages these systems? They don't belong to the school. We can't > touch them. About the only thing we can do is have a terms of use > agreement pop up when they connect and ask them to agree (maybe > register their name with their mac address) but that's about it. > > Right now if an english teacher wants his/her students to access the > web they need to book a computer lab to use for that period. I don't > think that's going to be the case in the future. I remember when no > students had cell phones, now almost all do. > > This also brings up the possibility of introducing ebooks. Publishers > of textbooks are already seeing this demand from post secondary > institutions. No more giant backpacks full of textbooks. In addition, > imagine instead of photocopying a handout for all students a teacher > just posts the handout to a website which all students access > instantly. Photocopying costs at my school are huge. > > > -- > Robert Arkiletian > Eric Hamber Secondary, Vancouver, Canada > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see From SHarbour at nwresd.k12.or.us Fri Nov 12 15:23:29 2010 From: SHarbour at nwresd.k12.or.us (Sean Harbour) Date: Fri, 12 Nov 2010 15:23:29 +0000 Subject: [K12OSN] Life after LTSP Message-ID: <2F00F05A36DEBE4CA6FF253FF64ED8DD017E91@wsc-mail-02.intra.nwresd.k12.or.us> Why indeed? I've thought about this type of school server farm setup a bit. You would have a master template that defined the services, and a pool of resources consisting of one or more servers. The template would define the how the services were distributed among the resources, with a reasonably sane default for the initial install. Adding more resources after the initial installation and template choices would be as quick as PXE booting an additional "server", and a few automated DNS changes triggered by the template would migrate services to the newly provided resource(s). This type of architecture should be very simple to migrate to a cloud based architecture later on if hosting prices continue to fall. Couple it with a shared file system such as Redhat GFS and some utilities such as heartbeat or DRBD, and high availability becomes a relatively simple addition. A minimal implementation could run on one box, and expand from there. I would really like to see the ability to eliminate any dependencies on the initially installed hardware by making it simple to migrate nodes to new hardware as well. For example, do a pilot installation on an old desktop, add a good server later, and simply checkmark "Migrate an existing server node to new hardware" somewhere on a web form, and follow the prompts. Once you had at least two nodes up, at the bare minimum each node should be able to replicate all the other services of the other node in case of a node failure, perhaps by a manual setting change in the web template interface on the surviving node. This is sort of a "borg" mentality, but it should scale to dozens of servers with ease, and provide a reasonably simple, albeit manually triggered, safeguard against server failure. To recap, each server would be pretty much identically configured, but most services would be disabled unless the node was the designated primary for a particular service. I would try to NOT integrate most of the various service management GUIs into the project with the exception of perhaps a few key services needed, such as PXE, LDAP and DNS. Is there a project out there that already implements this type of "master template" architecture? Skole Linux is the only one I am aware of that tries to address the implementation from scratch of a complete educational institution relevant server network. I have not evaluated Skole Linux for a while, but it might be a good resource to consider. http://wiki.debian.org/DebianEdu/Documentation/Lenny/Architecture Come up with a snazzy name for the project, like "The Borg Initiative" that would get people's attention, spend some effort on marketing our intentions so we can recruit interested talent, and focus on building a simple, modular framework that makes it as easy as possible to add new services and maintain and upgrade the infrastructure. I think we'd have a winner. Anybody want to host a project outline wiki page? Sean Harbour Senior Network Engineer Northwest Regional Education Service District 503-614-1448 sharbour at nwresd.k12.or.us Hillsboro, OR >Message: 1 >Date: Wed, 10 Nov 2010 18:34:55 -0500 >From: "Steven Santos" >To: "'Support list for open source software in schools.'" > >Subject: Re: [K12OSN] Life after LTSP >Message-ID: > >AAAAAA==@SimplyCircus.com> > >Content-Type: text/plain; charset="us-ascii" > >K12LTSP was a success because it did everything we needed it to do, and it >did it with little fuss. > >What if the future is not in a given tech, but in the concept or what Eric >did way back when? > >Why couldn't we come up with a system where you use one DVD to setup and >install a complete working linux network for a school. This should allow >for all network services commonly needed in a school setting, including: > > - Student administration > - Admin / Teacher desktops (DRBL) > - SIS including classes, grade, etc > - Accounting > > - Classroom Services > - Student desktops (DRBL) > - Moodle virtual classroom > - School Wide Wiki > > - Lab services > - Writing lab (LTSP) > - Science lab (DRBL) > > - Library Services > - KOHA / OPEC > - Library desktops (DRBL) > > - Common network services > - School-wide print services > - Restricted Internet access, filtering and local caching > > - Lunchroom / School Store > - POS terminals > > > Step 1: setup the servers > - DNS / DHCP servers > - 389 Directory Server > - Set up the network admin group (auto) > - Set up the office/admin group (auto) > - Set up the teacher group (auto) > - Set up the Lunchroom group (auto) > - Set up the schoolstore group (auto) > - Set up the student groups (auto, by class, graduating year) > - Set up software access groups (interactive) > - NIS / Kerbos (using 389DS) > - Generate certificates > - Copy certificates to USB drive or NFS share for later use > - SAMBA4 (setup using LDAP/NIS authentication) > - Set up domain for use with windows clients > - MySQL server (setup using LDAP/NIS authentication) > - CUPS print server (setup using LDAP/NIS authentication) > - File Server (/home server) > - DRBL Server (setup using LDAP/NIS authentication) > - SQUID web proxy (restrict net access / setup with LDAP) > - Setup the virtual servers > - Remote Access Server (remote. / ptpp server setup using >LDAP) > - Mail server (mail. / setup using LDAP) > - Apache server (www. and web. / setup using LDAP) > - Koha server (library. / setup using LDAP) > - School Tool (sis. / setup using LDAP) > - Moodle (moodle. / setup using LDAP) > > > Step 2: setup the DRBL (Diskless Remote Boot in Linux) boot images > - Staff desktops with NIS/LDAP authentication. > - Standard education image with NIS/LDAP authentication > - Library PC image / standard image with addition of a local, no pwd >acct, but with restrictions on what apps it can launch without being logged >in as a standard user > - Kiosks image / web browser only, no local log-in option, fixed start >page > - Point of Sale terminals > > > >Hmmm... > >--- >Steven Santos >Director, Simply Circus, Inc. > Email: Steven at SimplyCircus.com > Gym: 86 Los Angeles Street > Newton, MA 02458 > Mail: 14 Pierrepont Road > Newton, MA 02462 > Phone: 617-527-0667 > Fax: 617-934-1870 > Web: www.SimplyCircus.com From peter at scheie.homedns.org Sat Nov 13 02:29:03 2010 From: peter at scheie.homedns.org (Peter Scheie) Date: Fri, 12 Nov 2010 20:29:03 -0600 Subject: [K12OSN] Life after LTSP In-Reply-To: <2F00F05A36DEBE4CA6FF253FF64ED8DD017E91@wsc-mail-02.intra.nwresd.k12.or.us> References: <2F00F05A36DEBE4CA6FF253FF64ED8DD017E91@wsc-mail-02.intra.nwresd.k12.or.us> Message-ID: <4CDDF7EF.8080300@scheie.homedns.org> The guys at revolutionlinux.com are the primary developers of LTSP Cluster, which is perhaps similar to what you are talking about. They have customer schools with thousands of thin clients on LTSP (Ubuntu). Stephane Graber is one of the primary devs for LTSP, and I believe Francis Giradeau, one of Revolution's founders, did his master's thesis on clustering LTSP servers. You can regularly find them on #ltsp. Peter Sean Harbour wrote: > Why indeed? > > I've thought about this type of school server farm setup a bit. You would have a master template that defined the services, and a pool of resources consisting of one or more servers. The template would define the how the services were distributed among the resources, with a reasonably sane default for the initial install. Adding more resources after the initial installation and template choices would be as quick as PXE booting an additional "server", and a few automated DNS changes triggered by the template would migrate services to the newly provided resource(s). This type of architecture should be very simple to migrate to a cloud based architecture later on if hosting prices continue to fall. > > Couple it with a shared file system such as Redhat GFS and some utilities such as heartbeat or DRBD, and high availability becomes a relatively simple addition. A minimal implementation could run on one box, and expand from there. I would really like to see the ability to eliminate any dependencies on the initially installed hardware by making it simple to migrate nodes to new hardware as well. For example, do a pilot installation on an old desktop, add a good server later, and simply checkmark "Migrate an existing server node to new hardware" somewhere on a web form, and follow the prompts. > > Once you had at least two nodes up, at the bare minimum each node should be able to replicate all the other services of the other node in case of a node failure, perhaps by a manual setting change in the web template interface on the surviving node. This is sort of a "borg" mentality, but it should scale to dozens of servers with ease, and provide a reasonably simple, albeit manually triggered, safeguard against server failure. To recap, each server would be pretty much identically configured, but most services would be disabled unless the node was the designated primary for a particular service. > > I would try to NOT integrate most of the various service management GUIs into the project with the exception of perhaps a few key services needed, such as PXE, LDAP and DNS. > > Is there a project out there that already implements this type of "master template" architecture? > > Skole Linux is the only one I am aware of that tries to address the implementation from scratch of a complete educational institution relevant server network. I have not evaluated Skole Linux for a while, but it might be a good resource to consider. > > http://wiki.debian.org/DebianEdu/Documentation/Lenny/Architecture > > Come up with a snazzy name for the project, like "The Borg Initiative" that would get people's attention, spend some effort on marketing our intentions so we can recruit interested talent, and focus on building a simple, modular framework that makes it as easy as possible to add new services and maintain and upgrade the infrastructure. > > I think we'd have a winner. > > Anybody want to host a project outline wiki page? > > Sean Harbour > Senior Network Engineer > Northwest Regional Education Service District > 503-614-1448 > sharbour at nwresd.k12.or.us > Hillsboro, OR > > >> Message: 1 >> Date: Wed, 10 Nov 2010 18:34:55 -0500 >> From: "Steven Santos" >> To: "'Support list for open source software in schools.'" >> >> Subject: Re: [K12OSN] Life after LTSP >> Message-ID: >> >AAAAAA==@SimplyCircus.com> >> >> Content-Type: text/plain; charset="us-ascii" >> >> K12LTSP was a success because it did everything we needed it to do, and it >> did it with little fuss. >> >> What if the future is not in a given tech, but in the concept or what Eric >> did way back when? >> >> Why couldn't we come up with a system where you use one DVD to setup and >> install a complete working linux network for a school. This should allow >> for all network services commonly needed in a school setting, including: >> >> - Student administration >> - Admin / Teacher desktops (DRBL) >> - SIS including classes, grade, etc >> - Accounting >> >> - Classroom Services >> - Student desktops (DRBL) >> - Moodle virtual classroom >> - School Wide Wiki >> >> - Lab services >> - Writing lab (LTSP) >> - Science lab (DRBL) >> >> - Library Services >> - KOHA / OPEC >> - Library desktops (DRBL) >> >> - Common network services >> - School-wide print services >> - Restricted Internet access, filtering and local caching >> >> - Lunchroom / School Store >> - POS terminals >> >> >> Step 1: setup the servers >> - DNS / DHCP servers >> - 389 Directory Server >> - Set up the network admin group (auto) >> - Set up the office/admin group (auto) >> - Set up the teacher group (auto) >> - Set up the Lunchroom group (auto) >> - Set up the schoolstore group (auto) >> - Set up the student groups (auto, by class, graduating year) >> - Set up software access groups (interactive) >> - NIS / Kerbos (using 389DS) >> - Generate certificates >> - Copy certificates to USB drive or NFS share for later use >> - SAMBA4 (setup using LDAP/NIS authentication) >> - Set up domain for use with windows clients >> - MySQL server (setup using LDAP/NIS authentication) >> - CUPS print server (setup using LDAP/NIS authentication) >> - File Server (/home server) >> - DRBL Server (setup using LDAP/NIS authentication) >> - SQUID web proxy (restrict net access / setup with LDAP) >> - Setup the virtual servers >> - Remote Access Server (remote. / ptpp server setup using >> LDAP) >> - Mail server (mail. / setup using LDAP) >> - Apache server (www. and web. / setup using LDAP) >> - Koha server (library. / setup using LDAP) >> - School Tool (sis. / setup using LDAP) >> - Moodle (moodle. / setup using LDAP) >> >> >> Step 2: setup the DRBL (Diskless Remote Boot in Linux) boot images >> - Staff desktops with NIS/LDAP authentication. >> - Standard education image with NIS/LDAP authentication >> - Library PC image / standard image with addition of a local, no pwd >> acct, but with restrictions on what apps it can launch without being logged >> in as a standard user >> - Kiosks image / web browser only, no local log-in option, fixed start >> page >> - Point of Sale terminals >> >> >> >> Hmmm... >> >> --- >> Steven Santos >> Director, Simply Circus, Inc. >> Email: Steven at SimplyCircus.com >> Gym: 86 Los Angeles Street >> Newton, MA 02458 >> Mail: 14 Pierrepont Road >> Newton, MA 02462 >> Phone: 617-527-0667 >> Fax: 617-934-1870 >> Web: www.SimplyCircus.com > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > From robark at gmail.com Sat Nov 13 04:00:21 2010 From: robark at gmail.com (Robert Arkiletian) Date: Fri, 12 Nov 2010 20:00:21 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: On Mon, Nov 8, 2010 at 12:27 PM, Robert Arkiletian wrote: > 4) > If Ubuntu is successful with their move to Wayland display server > (away from X), LTSP may not even work as Wayland has no network > transparency as X does. Not sure if having X as a client itself on top > of Wayland will work with LTSP. My guess is it will be troublesome > because the client will need Wayland up first before X (which btw > means it will also definitely need an opengl capable chipset). I > suspect that unless the LTSP project goes back to the way they did > things in LTSP 4, where they pretty much managed and built the chroot > as a seperate distro, I think Wayland is going to break LTSP with the > Muekow way of doing things. I think the url below explains it pretty well. The good news: Seems Wayland may yet get some kind of network remoting protocol. http://www.osnews.com/story/24029/Fedora_To_Eventually_Move_to_Wayland_Too Fedora devel list has a very interesting and long thread about the Wayland issue. http://lists.fedoraproject.org/pipermail/devel/2010-November/thread.html The times they are a changing. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From rowens at ptd.net Tue Nov 16 01:32:37 2010 From: rowens at ptd.net (Rob Owens) Date: Mon, 15 Nov 2010 20:32:37 -0500 Subject: [K12OSN] speaking of DRBL... Message-ID: <20101116013237.GE29430@aurora.owens.net> I ran into some bugs trying to install it, and I can't get any response from their mailing list. Is it still active? My message has been awaiting moderator approval for several days now, and I haven't seen any other postings made in the meantime. Sorry for the off-topic post, but I know there are at least a couple DRBL users here. -Rob From rowens at ptd.net Tue Nov 16 01:34:59 2010 From: rowens at ptd.net (Rob Owens) Date: Mon, 15 Nov 2010 20:34:59 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: <1289438694.1739.258.camel@d820> References: <1289438694.1739.258.camel@d820> Message-ID: <20101116013459.GF29430@aurora.owens.net> On Wed, Nov 10, 2010 at 08:24:54PM -0500, Charlie wrote: > So realistically, DRBL is limited as well since it requires like > architecture on the server and client, as in you can't have a really > robust x64 based LTSP server and a x86 based client solution. Not much > use in running a high end server hardware system on a 32bit x86 OS. > True, but for DRBL you don't need a high-end server. It's just serving NFS shares. So you could conceivably run a 32-bit DRBL server and do just fine. Unless, that is, you were trying to run DRBL and LTSP on the same server. In that case, you have conflicting requirements (32 bit for DRBL, 64 bit and loads of RAM for LTSP). -Rob From rowens at ptd.net Tue Nov 16 01:36:37 2010 From: rowens at ptd.net (Rob Owens) Date: Mon, 15 Nov 2010 20:36:37 -0500 Subject: [K12OSN] Life after LTSP In-Reply-To: <1289438694.1739.258.camel@d820> References: <1289438694.1739.258.camel@d820> Message-ID: <20101116013637.GG29430@aurora.owens.net> On Wed, Nov 10, 2010 at 08:24:54PM -0500, Charlie wrote: > So realistically, DRBL is limited as well since it requires like > architecture on the server and client, as in you can't have a really > robust x64 based LTSP server and a x86 based client solution. Not much > use in running a high end server hardware system on a 32bit x86 OS. > True, but for DRBL you don't need a high-end server. It's just serving NFS shares. So you could conceivably run a 32-bit DRBL server and do just fine. Unless, that is, you were trying to run DRBL and LTSP on the same server. In that case, you have conflicting requirements (32 bit for DRBL, 64 bit and loads of RAM for LTSP). -Rob From robark at gmail.com Tue Nov 16 04:01:03 2010 From: robark at gmail.com (Robert Arkiletian) Date: Mon, 15 Nov 2010 20:01:03 -0800 Subject: [K12OSN] speaking of DRBL... In-Reply-To: <20101116013237.GE29430@aurora.owens.net> References: <20101116013237.GE29430@aurora.owens.net> Message-ID: On Mon, Nov 15, 2010 at 5:32 PM, Rob Owens wrote: > I ran into some bugs trying to install it, and I can't get any response > from their mailing list. ?Is it still active? ?My message has been > awaiting moderator approval for several days now, and I haven't seen any > other postings made in the meantime. > > Sorry for the off-topic post, but I know there are at least a couple > DRBL users here. > Sorry for the off topic reply. I would have kept it off list but there may be others in the same boat. There is one showstopper bug that I reported. But It's a very easy fix. In Fedora 13 one cannot use nomodeset kernel parameter for intel or nvidia video chipsets. remove the word 'nomodeset' from /tftpboot/nbi_img/pxelinux.cfg/default label drbl ... append initrd=initrd-pxe.img devfs=nomount drblthincli=off selinux=0 nomodeset Delete nomodeset from the end of the that line. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From robark at gmail.com Wed Nov 17 23:16:28 2010 From: robark at gmail.com (Robert Arkiletian) Date: Wed, 17 Nov 2010 15:16:28 -0800 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: On Mon, Nov 8, 2010 at 12:27 PM, Robert Arkiletian wrote: > screen video and flash, no problem. I even have had an entire class of > students simultaneously install and run Ubuntu in a Virtualbox VM on > top of ?the diskless client OS. I forgot that I actually took a video of the server load when doing this. I think I had about 20 students in the class. http://www.youtube.com/watch?v=261fB3BmEOw -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada From dvanassche at gmail.com Thu Nov 18 15:36:22 2010 From: dvanassche at gmail.com (David Van Assche) Date: Thu, 18 Nov 2010 16:36:22 +0100 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: I do have to agree with original poster here though. A systems become more advanced and the telepathy underlying layer starts to be well user, there is little left for LTSP to dp, other than be a centralised commmand centre which somehow manages temp/ph/etc calculations. Its still got anoterh god 10 years.... but I think we'll see thinkg thatt will blow away our minds like LTSP did back in the day.... I raise a toast to an old frind, Cheers D On Thu, Nov 18, 2010 at 12:16 AM, Robert Arkiletian wrote: > On Mon, Nov 8, 2010 at 12:27 PM, Robert Arkiletian > wrote: > > screen video and flash, no problem. I even have had an entire class of > > students simultaneously install and run Ubuntu in a Virtualbox VM on > > top of the diskless client OS. > > I forgot that I actually took a video of the server load when doing > this. I think I had about 20 students in the class. > > http://www.youtube.com/watch?v=261fB3BmEOw > > -- > Robert Arkiletian > Eric Hamber Secondary, Vancouver, Canada > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvanassche at gmail.com Thu Nov 18 15:36:22 2010 From: dvanassche at gmail.com (David Van Assche) Date: Thu, 18 Nov 2010 16:36:22 +0100 Subject: [K12OSN] Life after LTSP In-Reply-To: References: Message-ID: I do have to agree with original poster here though. A systems become more advanced and the telepathy underlying layer starts to be well user, there is little left for LTSP to dp, other than be a centralised commmand centre which somehow manages temp/ph/etc calculations. Its still got anoterh god 10 years.... but I think we'll see thinkg thatt will blow away our minds like LTSP did back in the day.... I raise a toast to an old frind, Cheers D On Thu, Nov 18, 2010 at 12:16 AM, Robert Arkiletian wrote: > On Mon, Nov 8, 2010 at 12:27 PM, Robert Arkiletian > wrote: > > screen video and flash, no problem. I even have had an entire class of > > students simultaneously install and run Ubuntu in a Virtualbox VM on > > top of the diskless client OS. > > I forgot that I actually took a video of the server load when doing > this. I think I had about 20 students in the class. > > http://www.youtube.com/watch?v=261fB3BmEOw > > -- > Robert Arkiletian > Eric Hamber Secondary, Vancouver, Canada > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at fragakis.com Fri Nov 19 04:55:17 2010 From: william at fragakis.com (William Fragakis) Date: Thu, 18 Nov 2010 23:55:17 -0500 Subject: [K12OSN] speaking of DRBL... In-Reply-To: References: Message-ID: <1290142517.5162.140.camel@server-192.168.0.254.ltsp> And I thought it was something I was doing that kept my Atoms from fully booting. Went nuts for a couple of months trying all sorts of things before I had to back burner the project. I could get the LiveCD to run fine but I wanted a Fedora desktop for a number of reasons. Thanks, William On Tue, 2010-11-16 at 12:00 -0500, k12osn-request at redhat.com wrote: > Message: 4 > Date: Mon, 15 Nov 2010 20:01:03 -0800 > From: Robert Arkiletian > To: "Support list for open source software in schools." > > Subject: Re: [K12OSN] speaking of DRBL... > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Nov 15, 2010 at 5:32 PM, Rob Owens wrote: > > I ran into some bugs trying to install it, and I can't get any > response > > from their mailing list. ?Is it still active? ?My message has been > > awaiting moderator approval for several days now, and I haven't seen > any > > other postings made in the meantime. > > > > Sorry for the off-topic post, but I know there are at least a couple > > DRBL users here. > > > > Sorry for the off topic reply. I would have kept it off list but there > may be others in the same boat. > > There is one showstopper bug that I reported. But It's a very easy > fix. > > In Fedora 13 one cannot use nomodeset kernel parameter for intel or > nvidia video chipsets. > > remove the word 'nomodeset' from > > /tftpboot/nbi_img/pxelinux.cfg/default > > label drbl > ... > > append initrd=initrd-pxe.img devfs=nomount drblthincli=off selinux=0 > nomodeset > > Delete nomodeset from the end of the that line. > > -- > Robert Arkiletian > Eric Hamber Secondary, Vancouver, Canada > > From brcisna at eazylivin.net Fri Nov 19 14:04:00 2010 From: brcisna at eazylivin.net (Barry Cisna) Date: Fri, 19 Nov 2010 08:04:00 -0600 Subject: [K12OSN] K12LTSP with BigBlueButton Message-ID: <1290175440.30337.15.camel@localhost.localdomain> Hello All, Just wanted to share with all the listee's here. This may or may not be of interest to anyone here,but if you have not heard of BigBlueButton ,it may be worth checking into. The BBB dev's have a repository now for installing this on Centos 5.x now that makes it fairly simple to install via rpm's, although the version will be outdated compared to the Ubuntu and VM versions. We have used it at times at school for 'helper' situations. Long story longer,is BBB is very similar to Webex,with not quite so many features. You may prefer to run BBB in a VM (they have a pre-made VM image) which is setup very easily as well. One thing to keep in mind if you do decide to install via rpm's on Centos 5 server it will hijack your www directory. If you do not want this to happen there are instructions on how to install BBB manually and you can specify a sub-dir ,such as /var/www/html/bbb. It is very fast even on TC's ,as we do use a squid proxy server. You would think using flash as much as it does it would be dog slow. This is not the situation. We have also used it across a vpn / remote buildings and works fine as well, FYI. http://www.bigbluebutton.org Take Care, Barry From lars.schade at berlin.de Fri Nov 19 17:27:59 2010 From: lars.schade at berlin.de (Lars Schade) Date: Fri, 19 Nov 2010 18:27:59 +0100 Subject: [K12OSN] k12linux on f14/centos6 Message-ID: <1290187679.7049.4.camel@localhost> Hi there, I recently installed fedora14 with the intention to run k12linux just to learn that there is an old defunct package in the distribution. Since I need to make plans for a server I run for a small non-profit nature park administration, I am curious to learn whether there are plans to provide rpm's for f14 or preferentially even for centos6 (which is based on f12/13 and to appear soon?) in the near future, say before the end of the year? I followed the discussion on the future of LTSP with interest but think I stick to it for the time being. And I would really like to also stick to redhat/fedora/centos. Is there any insider knowledge out there on the future of LTSP on f14/centos6? Thanks, Lars From news at siddall.name Fri Nov 19 17:47:46 2010 From: news at siddall.name (Jeff Siddall) Date: Fri, 19 Nov 2010 12:47:46 -0500 Subject: [K12OSN] k12linux on f14/centos6 In-Reply-To: <1290187679.7049.4.camel@localhost> References: <1290187679.7049.4.camel@localhost> Message-ID: <4CE6B842.9070702@siddall.name> On 11/19/2010 12:27 PM, Lars Schade wrote: > Hi there, > > I recently installed fedora14 with the intention to run k12linux just to > learn that there is an old defunct package in the distribution. > > Since I need to make plans for a server I run for a small non-profit > nature park administration, I am curious to learn whether there are > plans to provide rpm's for f14 or preferentially even for centos6 (which > is based on f12/13 and to appear soon?) in the near future, say before > the end of the year? > > I followed the discussion on the future of LTSP with interest but think > I stick to it for the time being. And I would really like to also stick > to redhat/fedora/centos. > > Is there any insider knowledge out there on the future of LTSP on > f14/centos6? I too would like to see LTSP on CentOS 6, but I am pretty sure CentOS 6 won't be out until sometime in 2011. In the mean time I am on Fedora 13. No issues there. Jeff From toddobryan at gmail.com Fri Nov 19 18:21:07 2010 From: toddobryan at gmail.com (Todd O'Bryan) Date: Fri, 19 Nov 2010 13:21:07 -0500 Subject: [K12OSN] Good source that accepts POs? Message-ID: Does anyone have a good company to use that will accept purchase orders? NewEgg has the lowest prices on some stuff I want to order, but won't take POs... Todd From gspurgeon at dageek.co.uk Sat Nov 20 09:45:48 2010 From: gspurgeon at dageek.co.uk (Gavin Spurgeon) Date: Sat, 20 Nov 2010 09:45:48 +0000 Subject: [K12OSN] k12linux on f14/centos6 In-Reply-To: <1290187679.7049.4.camel@localhost> References: <1290187679.7049.4.camel@localhost> Message-ID: <4CE798CC.4000005@dageek.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/2010 17:27, Lars Schade wrote: > Hi there, > > I recently installed fedora14 with the intention to run k12linux just to > learn that there is an old defunct package in the distribution. > > Since I need to make plans for a server I run for a small non-profit > nature park administration, I am curious to learn whether there are > plans to provide rpm's for f14 or preferentially even for centos6 (which > is based on f12/13 and to appear soon?) in the near future, say before > the end of the year? > > I followed the discussion on the future of LTSP with interest but think > I stick to it for the time being. And I would really like to also stick > to redhat/fedora/centos. > > Is there any insider knowledge out there on the future of LTSP on > f14/centos6? Yes I can give you a little bit of a heads up on the F14 side of things, https://bugzilla.redhat.com/show_bug.cgi?id=652896 and also https://bugzilla.redhat.com/show_bug.cgi?id=598134 As you can see, I was working on LTSP in F13 and and got the package working fully on I386 & x86_64. As I can also see that Warren seems to have gone AWOL again, On monday when I get to work I will take over BZ652896 and again work to get the .rpm's for F14 I386 and x86_64 pushed up to the official repos. I will keep the BZ up2date with my progress, so please keep an eye on it. If the package gets into F13/F14 we have a very good chance of getting it into RHEL or with a little more work on my part, we might be able to get it into CentOS. Sorry it has been like this, I didn't want to mess with Warren's packages once he said he was back (2010-09-25) but it looks like he has gone AWOL again, so I will get back on to it and get LTSP updated and in to the official repos for both F13 and F14 as soon as I can. - -- Gavin Spurgeon. AKA Da Geek - ---------------------------------------------------------------------- "The happiest of people don't necessarily have the best of everything, they just make the most of everything that comes along their way.." -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkznmMsACgkQvp6arS3vDir4UgCg2H1BC6nu9qftol46doSU5Adv cR8AniGTZorPN0mOoT4HuSkPpAK5gdUP =KDlF -----END PGP SIGNATURE----- -- This message was scanned by DaGeek Spam Filter and is believed to be clean. From gspurgeon at dageek.co.uk Sat Nov 20 09:47:47 2010 From: gspurgeon at dageek.co.uk (Gavin Spurgeon) Date: Sat, 20 Nov 2010 09:47:47 +0000 Subject: [K12OSN] k12linux on f14/centos6 In-Reply-To: <4CE6B842.9070702@siddall.name> References: <1290187679.7049.4.camel@localhost> <4CE6B842.9070702@siddall.name> Message-ID: <4CE79943.9010104@dageek.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jeff, > I too would like to see LTSP on CentOS 6, but I am pretty sure CentOS 6 > won't be out until sometime in 2011. In the mean time I am on Fedora > 13. No issues there. Are you using my .rpm's on your F13 system, Just out of interest ? I have had a few people e-mail me that have used them but its always nice to find more. - -- Gavin Spurgeon. AKA Da Geek - ---------------------------------------------------------------------- "The happiest of people don't necessarily have the best of everything, they just make the most of everything that comes along their way.." -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkznmUMACgkQvp6arS3vDiqUnACgw3n92IItqiORGunAd6QyRfK6 A3EAoMled1FHbmqBEfJTzRLPkOSGGxE0 =D2mq -----END PGP SIGNATURE----- -- This message was scanned by DaGeek Spam Filter and is believed to be clean. From news at siddall.name Sat Nov 20 16:01:42 2010 From: news at siddall.name (Jeff Siddall) Date: Sat, 20 Nov 2010 11:01:42 -0500 Subject: [K12OSN] k12linux on f14/centos6 In-Reply-To: <4CE79943.9010104@dageek.co.uk> References: <1290187679.7049.4.camel@localhost> <4CE6B842.9070702@siddall.name> <4CE79943.9010104@dageek.co.uk> Message-ID: <4CE7F0E6.8040108@siddall.name> On 11/20/2010 04:47 AM, Gavin Spurgeon wrote: > > Hi Jeff, > >> I too would like to see LTSP on CentOS 6, but I am pretty sure CentOS 6 >> won't be out until sometime in 2011. In the mean time I am on Fedora >> 13. No issues there. > > Are you using my .rpm's on your F13 system, Just out of interest ? > > I have had a few people e-mail me that have used them but its always > nice to find more. I'm just using the F12 stuff in the standard repo: ltsp-server.i686 5.1.95-1.fc12 @updates Is that yours? Jeff From peter at beetlebolt.com Sat Nov 20 19:50:19 2010 From: peter at beetlebolt.com (Peter k) Date: Sat, 20 Nov 2010 14:50:19 -0500 Subject: [K12OSN] Good source that accepts POs? In-Reply-To: References: Message-ID: CDW does. You'll be assigned a sales rep who will take care of you. For thin clients, I enjoy working with Alex of disklessworkstations.com . Their prices are very competitive and their customer support is superb. -peter On Fri, Nov 19, 2010 at 1:21 PM, Todd O'Bryan wrote: > Does anyone have a good company to use that will accept purchase > orders? NewEgg has the lowest prices on some stuff I want to order, > but won't take POs... > > Todd > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at beetlebolt.com Sat Nov 20 20:11:31 2010 From: peter at beetlebolt.com (Peter k) Date: Sat, 20 Nov 2010 15:11:31 -0500 Subject: [K12OSN] Good source that accepts POs? In-Reply-To: References: Message-ID: Oh, and I don't work for either company. -Peter Kolbe Tech Coordinator Bard High School Early College 525 E Houston St New York, NY 10002 On Sat, Nov 20, 2010 at 2:50 PM, Peter k wrote: > CDW does. You'll be assigned a sales rep who will take care of you. For > thin clients, I enjoy working with Alex of disklessworkstations.com . > Their prices are very competitive and their customer support is superb. > -peter > > > On Fri, Nov 19, 2010 at 1:21 PM, Todd O'Bryan wrote: > >> Does anyone have a good company to use that will accept purchase >> orders? NewEgg has the lowest prices on some stuff I want to order, >> but won't take POs... >> >> Todd >> >> _______________________________________________ >> K12OSN mailing list >> K12OSN at redhat.com >> https://www.redhat.com/mailman/listinfo/k12osn >> For more info see >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddobryan at gmail.com Sun Nov 21 01:27:14 2010 From: toddobryan at gmail.com (Todd O'Bryan) Date: Sat, 20 Nov 2010 20:27:14 -0500 Subject: [K12OSN] Good source that accepts POs? In-Reply-To: References: Message-ID: Thanks! For other people looking, I also discovered that www.tigerdirect.com and www.superbiiz.com will accept POs. On Sat, Nov 20, 2010 at 3:11 PM, Peter k wrote: > Oh, and I don't work for either company. > -Peter Kolbe > Tech Coordinator > Bard High School Early College > 525 E Houston St > New York, NY 10002 > > On Sat, Nov 20, 2010 at 2:50 PM, Peter k wrote: >> >> CDW does. You'll be assigned a sales rep who will take care of you. For >> thin clients, I enjoy working with Alex of disklessworkstations.com . Their >> prices are very competitive and their customer support is superb. >> -peter >> >> On Fri, Nov 19, 2010 at 1:21 PM, Todd O'Bryan >> wrote: >>> >>> Does anyone have a good company to use that will accept purchase >>> orders? NewEgg has the lowest prices on some stuff I want to order, >>> but won't take POs... >>> >>> Todd >>> >>> _______________________________________________ >>> K12OSN mailing list >>> K12OSN at redhat.com >>> https://www.redhat.com/mailman/listinfo/k12osn >>> For more info see >> > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > From jwoltz at gmail.com Sun Nov 21 01:35:47 2010 From: jwoltz at gmail.com (J.C. Woltz) Date: Sun, 21 Nov 2010 01:35:47 +0000 Subject: [K12OSN] Good source that accepts POs? In-Reply-To: References: Message-ID: <1398024785-1290303348-cardhu_decombobulator_blackberry.rim.net-1039666566-@bda881.bisx.prod.on.blackberry> Tigerdirect's parent/sister company globalgoved.com will assign you a sales rep and accept POs Sent from my mobile. -----Original Message----- From: "Todd O'Bryan" Sender: k12osn-bounces at redhat.com Date: Sat, 20 Nov 2010 20:27:14 To: Support list for open source software in schools. Reply-To: "Support list for open source software in schools." Subject: Re: [K12OSN] Good source that accepts POs? Thanks! For other people looking, I also discovered that www.tigerdirect.com and www.superbiiz.com will accept POs. On Sat, Nov 20, 2010 at 3:11 PM, Peter k wrote: > Oh, and I don't work for either company. > -Peter Kolbe > Tech Coordinator > Bard High School Early College > 525 E Houston St > New York, NY 10002 > > On Sat, Nov 20, 2010 at 2:50 PM, Peter k wrote: >> >> CDW does. You'll be assigned a sales rep who will take care of you. For >> thin clients, I enjoy working with Alex of disklessworkstations.com . Their >> prices are very competitive and their customer support is superb. >> -peter >> >> On Fri, Nov 19, 2010 at 1:21 PM, Todd O'Bryan >> wrote: >>> >>> Does anyone have a good company to use that will accept purchase >>> orders? NewEgg has the lowest prices on some stuff I want to order, >>> but won't take POs... >>> >>> Todd >>> >>> _______________________________________________ >>> K12OSN mailing list >>> K12OSN at redhat.com >>> https://www.redhat.com/mailman/listinfo/k12osn >>> For more info see >> > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > _______________________________________________ K12OSN mailing list K12OSN at redhat.com https://www.redhat.com/mailman/listinfo/k12osn For more info see From toddobryan at gmail.com Wed Nov 24 03:45:03 2010 From: toddobryan at gmail.com (Todd O'Bryan) Date: Tue, 23 Nov 2010 22:45:03 -0500 Subject: [K12OSN] Nice case for building a fat client Message-ID: I just got one of these cases. A MicroATX motherboard fits into it very snugly, but it's a very nice overall size: http://www.superbiiz.com/detail.php?name=CA-0526S15&title=Evercase-E0526-S15-150W-Mini-ITX-Case-Black The power supply is above part of the motherboard, so you might want to try your parts before buying a bunch, but if you want something that's not much bigger than a typical thin client, I think this fits the bill. Add an inexpensive mobo, a CPU, and RAM, and it's all less than $200 for a pretty powerful machine. I've been creating my fat-client image to try to get it running and will report back once everything is installed and working. Todd From fluhmann at gmail.com Sat Nov 27 03:07:17 2010 From: fluhmann at gmail.com (Jeremy Fluhmann) Date: Fri, 26 Nov 2010 21:07:17 -0600 Subject: [K12OSN] Good source that accepts POs? In-Reply-To: References: Message-ID: We use purchase orders with NewEgg. Our business manager set it up. You have to go through their "Business" site - http://www.neweggbusiness.com/ >From their FAQ - http://www.neweggbusiness.com/HelpInfo/FAQDetail.aspx?Module=25 Can I use a Purchase Order and defer payment? If you want to place a purchase order and defer payment, you must first apply for a Net Term Account. After you submit your Net Term application online, please allow 5-10 business days for processing. Please note: NeweggBusiness Accounting will contact your company's authorized person for verification. Please note that NeweggBusiness will review your credit limit usage every 3 months and reserve the right to modified or cancel the approved limits Cheers, Jeremy -- Jeremy Fluhmann *Technology Director* *Winters ISD* *Futuristic - Analytical - Ideation - Relator - Learner*** *http://twitter.com/jfluhmann* *http://jfluhmann.edublogs.org* On Fri, Nov 19, 2010 at 12:21 PM, Todd O'Bryan wrote: > Does anyone have a good company to use that will accept purchase > orders? NewEgg has the lowest prices on some stuff I want to order, > but won't take POs... > > Todd > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From webmaster at appznstuff.com Sun Nov 28 07:41:47 2010 From: webmaster at appznstuff.com (Paul Grant) Date: 27 Nov 2010 23:41:47 -0800 Subject: [K12OSN] Paul Grant invites you. Message-ID: <20101128074147.10097.qmail@vps20048.managemyvps.com> Dear , You have been invited by your friend Paul Grant to participate in a research program. Currently there are companies that are looking for individuals who are interested in reviewing and testing the new Apple iPad applications and games. After the review the participants may keep the iPad. For more details or to register to our program, follow the link below: http://www.appznstuff.com Best Regards, Paul Grant and BTest Team. ___ This message was intended for k12osn at redhat.com, and was sent on behalf of Paul Grant From bfristen at shaw.ca Sun Nov 28 16:38:04 2010 From: bfristen at shaw.ca (Brian Fristensky) Date: Sun, 28 Nov 2010 10:38:04 -0600 Subject: [K12OSN] Users can't login Message-ID: <4CF2856C.1040209@shaw.ca> I'm still baffled by a problem with LTSP 5.2.4-5 on Fedora 13. This started when I upgraded to F13 last Sept., but I haven't had the time to delve into this problem for awhile. I'm going to repost my question as a starting point for working the problem. It may not even be an LTSP problem per se, but I've got to start somewhere. But first I'll add that Sergio suggested re-running ltsp-update-sshkeys, which I have done, with no change in the result. So here's what I wrote some time ago: ---------------------------------------------------------------- I have just done a clean install of Fedora 13 on my x86_64 system, and installed LTSP that comes with F13, along with all updates. I can get the image to download by PXE, and I get the blue k12Linux login screen. However, after typing a userid and password, I see the message Verifying password, please wait. The screen goes black for a moment and flashes a message (too fast to be readable), and then returns to the blue login screen again. I have listed some relevant information below, but I am stumped. Anyone have any insights? RELEVANT INFO ------------------- - On the server, the user's $HOME/.Xauthority file gets a new modification time each time a login is attempted. --------------------- - $HOME/.xsession-errors does not get changed. ------------------------ - /var/log/ldm.log does not exist on the server. In my lts.conf file, SYSLOG_HOST is set to the ip address of the server ------------------------- - on the server, /var/log/secure has the following messages from a failed login attempt for user 'birch' Sep 6 17:16:21 orpheus sshd[7721]: Accepted password for birch from 192.168.1.110 port 33405 ssh2 Sep 6 17:16:21 orpheus sshd[7721]: pam_unix(sshd:session): session opened for user birch by (uid=0) Sep 6 17:16:21 orpheus sshd[7724]: Received disconnect from 192.168.1.110: 11: disconnected by user Sep 6 17:16:21 orpheus sshd[7721]: pam_unix(sshd:session): session closed for user birch So I THINK the problem is not password authentication, but something that happens after. ------------------------------------ on the server, /var/log/messages has the following entries for the same login: Sep 6 17:16:23 orpheus xinetd[2621]: START: ldminfod pid=7741 from=::ffff:192.168.1.110 Sep 6 17:16:23 orpheus xinetd[2621]: EXIT: ldminfod status=0 pid=7741 duration=0(sec) Sep 6 17:16:23 orpheus xinetd[2621]: START: ldminfod pid=7744 from=::ffff:192.168.1.110 Sep 6 17:16:23 orpheus xinetd[2621]: EXIT: ldminfod status=0 pid=7744 duration=0(sec) Sep 6 17:16:24 orpheus xinetd[2621]: START: nbdrootd pid=7747 from=::ffff:192.168.1.110 Sep 6 17:16:24 orpheus nbd-server: connect from 192.168.1.110, assigned file is /opt/ltsp/images/i386.img Sep 6 17:16:24 orpheus nbd-server: Size of exported file/device is 315498496 Sep 6 17:16:24 orpheus nbd-server: Disconnect request received. Sep 6 17:16:24 orpheus xinetd[2621]: EXIT: nbdrootd status=0 pid=7747 duration=0(sec) Sep 6 17:20:12 orpheus gdm-simple-greeter[7278]: WARNING: Failed to send buffer Sep 6 17:20:12 orpheus NetworkManager[2341]: [1283811612.460757] [nm-manager.c:1328] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Sep 6 17:20:12 orpheus NetworkManager[2341]: [1283811612.557950] [nm-manager.c:1328] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name Sep 6 17:20:14 orpheus rtkit-daemon[2898]: Sucessfully made thread 7883 of process 7883 (/usr/bin/pulseaudio) owned by '505' high priority at nice level -11. Sep 6 17:20:14 orpheus rtkit-daemon[2898]: Sucessfully made thread 7923 of process 7883 (/usr/bin/pulseaudio) owned by '505' RT at priority 5. Sep 6 17:20:14 orpheus rtkit-daemon[2898]: Sucessfully made thread 7929 of process 7883 (/usr/bin/pulseaudio) owned by '505' RT at priority 5. Sep 6 17:20:15 orpheus rtkit-daemon[2898]: Sucessfully made thread 7987 of process 7987 (/usr/bin/pulseaudio) owned by '505' high priority at nice level -11. Sep 6 17:20:15 orpheus pulseaudio[7987]: pid.c: Daemon already running. Sep 6 17:20:16 orpheus setroubleshoot: SELinux not enabled, setroubleshootd exiting... -------------------------------------------------------- I have tried reinstalling LTSP several times. On thing I do note is that ltsp-build-client gives the following messages: Installing: sed ##################### [ 52/430] install-info: No such file or directory for /usr/share/info/sed.info.gz Installing: grep ##################### [ 96/430] install-info: No such file or directory for /usr/share/info/grep.info.gz Installing: which ##################### [ 97/430] install-info: No such file or directory for /usr/share/info/which.info.gz Installing: libidn ##################### [ 98/430] install-info: No such file or directory for /usr/share/info/libidn.info.gz Installing: util-linux-ng ##################### [194/430] install-info: No such file or directory for /usr/share/info/ipc.info Installing: gnupg2 ##################### [273/430] install-info: No such file or directory for /usr/share/info/gnupg.info /usr/sbin/setenforce: SELinux is disabled Cleaning up chroot /opt/ltsp/i386 sed: warning: failed to get security context of /etc/inittab: No data availablesed: warning: failed to get security context of /etc/sysconfig/readonly-root: No data availablesed: warning: failed to get security context of /etc/rwtab: No data availablesed: warning: failed to get security context of /etc/rc.d/rc.sysinit: No data availablesed: warning: failed to get security context of /etc/fstab: No data availablesed: warning: failed to get security context of /etc/init.d/halt: No data availablesed: warning: failed to get security context of /etc/init.d/halt: No data availablesed: warning: failed to get security context of /etc/init.d/halt: No data availableUpdating /var/lib/tftpboot directories for chroot: /opt/ltsp/i386 Removing /var/lib/tftpboot/ltsp/i386/vmlinuz-2.6.34.7-56.fc13.i686 Removing /var/lib/tftpboot/ltsp/i386/vmlinuz-2.6.34.6-54.fc13.i686 grep: /opt/ltsp/i386/proc/mounts: No such file or directory info: LTSP client installation completed successfully -- ============================================ Brian Fristensky 971 Somerville Avenue Winnipeg MB R3T 1B4 CANADA bfristen at shaw.ca 204-261-3960 ============================================ From brcisna at eazylivin.net Sun Nov 28 18:32:34 2010 From: brcisna at eazylivin.net (Barry Cisna) Date: Sun, 28 Nov 2010 12:32:34 -0600 Subject: [K12OSN] Users can't login Message-ID: <1290969154.24817.11.camel@localhost.localdomain> Brian, 1. Can user John Doe log into the server console itself with no probs,firstly? It appears when you do a manual install of the ltsp client you are ending up with a multitude of errors. Are you sure you done the ltsp chroot routine correctly before trying to build the ltsp client? From what you explain,it seems you are familiar with the chroot thing from previous ltsp installs? 2. Did you do an yum update to the server side itself before installing the ltsp client by chance? 3. Please post your /etc/hosts file here when you have a chance? 4. Did you set static ip addresses on both nics when initially installing ltsp ( and have not changed the ip's since)?? A few things to try and narrow stuff down . Barry From Steven at SimplyCircus.com Sun Nov 28 21:24:12 2010 From: Steven at SimplyCircus.com (Steven Santos) Date: Sun, 28 Nov 2010 16:24:12 -0500 Subject: [K12OSN] K12Linux... In-Reply-To: <4CF2856C.1040209@shaw.ca> References: <4CF2856C.1040209@shaw.ca> Message-ID: Can our networks be set up using a series of VM's? Is this the future of our networks? - Pre-configured LDAP VM. Script to edit the domain name used, tools for managing it. - Pre-configured LAN Services VM. Gets some basic config from LDAP, tools for managing DNS/NFS/CUPS/etc - Pre-configured email VM. Setup uses defaults set in LDAP VM, users managed via LDAP - Pre-configured MySQL Database server VM. Setup uses defaults set in LDAP VM. Managed via LDAP - Pre-configured RBDL server VM (one for each arch?). Clients and server users controlled via LDAP - Pre-configured LTSP server. Setup uses defaults set in LDAP VM. Managed via LDAP - Pre-configured KOHA server. Setup uses defaults set in LAN VM. Managed via LDAP This sets up an ecosystem whereby VM's can be moved around as needed. you rely on one or two VM's (LDAP and LAN services) that would be built on LTS builds. Other services, being VM's, can be updated as needed. Apps can be added as appliances, using remote X sessions. Resource hungry apps can be done as local VM's on clients. Thoughts? --- Steven Santos Director, Simply Circus, Inc. Email: Steven at SimplyCircus.com Gym: 86 Los Angeles Street Newton, MA 02458 Mail: 14 Pierrepont Road Newton, MA 02462 Phone: 617-527-0667 Fax: 617-934-1870 Web: www.SimplyCircus.com From bfristen at shaw.ca Sun Nov 28 21:26:01 2010 From: bfristen at shaw.ca (Brian Fristensky) Date: Sun, 28 Nov 2010 15:26:01 -0600 Subject: [K12OSN] Users can't login In-Reply-To: <1290969154.24817.11.camel@localhost.localdomain> References: <1290969154.24817.11.camel@localhost.localdomain> Message-ID: Barry, Thanks for a speedy reply. ----- Original Message ----- From: Barry Cisna Date: Sunday, November 28, 2010 1:45 pm Subject: Re: [K12OSN] Users can't login To: K12LTSP > Brian, > > 1. Can user John Doe log into the server console itself with no > probs,firstly? Yes. All users can login at the console. >It appears when you do a manual install of the ltsp > client you are ending up with a multitude of errors. > Are you sure you done the ltsp chroot routine correctly before > trying to > build the ltsp client? From what you explain,it seems you are familiar > with the chroot thing from previous ltsp installs? Yes, I have done numerous installs of LTSP over recent years, and have a written step by step protocol that has worked well in the past. In essence it is the steps from https://fedorahosted.org/k12linux/wiki/InstallGuide followed by /usr/sbin/ltsp-build-client --arch i386 cd /etc/yum.repos.d cp -p *.repo /opt/ltsp/i386/etc/yum.repos.d setarch i386 /usr/sbin/chroot /opt/ltsp/i386 mount /proc -t proc proc yum update yum yum update After yum is complete, exit the chroot by typing 'exit'. sudo ltsp-update-kernels sudo ltsp-update-sshkeyssudo ltsp-update-image This has worked well for some time, with various installs. > 2. Did you do an yum update to the server side itself before > installingthe ltsp client by chance? always. see above > 3. Please post your /etc/hosts file here when you have a chance? 192.168.1.103??? orpheus??? # Added by NetworkManager 127.0.0.1??? localhost.localdomain??? localhost ::1??? orpheus??? localhost6.localdomain6??? localhost6 #24.66.94.159??? shawnews.wp.shawcable.net??? shawnews 64.59.128.135??? shawmail.wp.shawcable.net??? shawmail 130.179.16.26??? antares.cc.umanitoba.ca??? antares .... and many more remote servers > 4. Did you set static ip addresses on both nics when initially > installing ltsp ( and have not changed the ip's since)?? I only have one NIC and an ltsp bridge. I shouldn't think that would cause the problem I've observed, because clearly, the thin client is finding the image and downloading it and booting normally. > A few things to try and narrow stuff down . Now we get our hands dirty... > > Barry > > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Sun Nov 28 22:38:12 2010 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 28 Nov 2010 16:38:12 -0600 Subject: [K12OSN] K12Linux... In-Reply-To: References: <4CF2856C.1040209@shaw.ca> Message-ID: <4CF2D9D4.6060506@gmail.com> On 11/28/10 3:24 PM, Steven Santos wrote: > Can our networks be set up using a series of VM's? > > Is this the future of our networks? > > - Pre-configured LDAP VM. Script to edit the domain name used, tools for > managing it. > - Pre-configured LAN Services VM. Gets some basic config from LDAP, tools > for managing DNS/NFS/CUPS/etc > - Pre-configured email VM. Setup uses defaults set in LDAP VM, users > managed via LDAP > - Pre-configured MySQL Database server VM. Setup uses defaults set in LDAP > VM. Managed via LDAP > - Pre-configured RBDL server VM (one for each arch?). Clients and server > users controlled via LDAP > - Pre-configured LTSP server. Setup uses defaults set in LDAP VM. Managed > via LDAP > - Pre-configured KOHA server. Setup uses defaults set in LAN VM. Managed > via LDAP > > This sets up an ecosystem whereby VM's can be moved around as needed. you > rely on one or two VM's (LDAP and LAN services) that would be built on LTS > builds. Other services, being VM's, can be updated as needed. > > Apps can be added as appliances, using remote X sessions. Resource hungry > apps can be done as local VM's on clients. > > Thoughts? There's a substantial performance hit for running in VMs. I could see it for specialized things like the LDAP server, although if ClearOS adds replication to theirs that runs out of the box, it might make more sense to run ClearOS on one server for most network services and home directories. -- Les Mikesell lesmikesell at gmail.com From SHarbour at nwresd.k12.or.us Mon Nov 29 17:25:37 2010 From: SHarbour at nwresd.k12.or.us (Sean Harbour) Date: Mon, 29 Nov 2010 17:25:37 +0000 Subject: [K12OSN] K12OSN Digest, Vol 81, Issue 16 In-Reply-To: References: Message-ID: <2F00F05A36DEBE4CA6FF253FF64ED8DD06D1FF@wsc-mail-02.intra.nwresd.k12.or.us> >On 11/28/10 3:24 PM, Steven Santos wrote: >> Can our networks be set up using a series of VM's? >> >> Is this the future of our networks? >> >> - Pre-configured LDAP VM. Script to edit the domain name used, tools for >> managing it. >> - Pre-configured LAN Services VM. Gets some basic config from LDAP, tools >> for managing DNS/NFS/CUPS/etc >> - Pre-configured email VM. Setup uses defaults set in LDAP VM, users >> managed via LDAP >> - Pre-configured MySQL Database server VM. Setup uses defaults set in LDAP >> VM. Managed via LDAP >> - Pre-configured RBDL server VM (one for each arch?). Clients and server >> users controlled via LDAP >> - Pre-configured LTSP server. Setup uses defaults set in LDAP VM. Managed >> via LDAP >> - Pre-configured KOHA server. Setup uses defaults set in LAN VM. Managed >> via LDAP >> >> This sets up an ecosystem whereby VM's can be moved around as needed. you >> rely on one or two VM's (LDAP and LAN services) that would be built on LTS >> builds. Other services, being VM's, can be updated as needed. >> >> Apps can be added as appliances, using remote X sessions. Resource hungry >> apps can be done as local VM's on clients. >> >> Thoughts? >There's a substantial performance hit for running in VMs. I could see it for >specialized things like the LDAP server, although if ClearOS adds replication to >theirs that runs out of the box, it might make more sense to run ClearOS on one >server for most network services and home directories. >-- > Les Mikesell > lesmikesell at gmail.com Splitting services out over more VMs means more servers to manage, and possibly enough performance hit to noticeably affect latency sensitive services such as thin client hosting. Using tools like Spacewalk and Puppet to auto deploy, configure and manage servers and services considerably lessens the advantages of a virtualized infrastructure. Of course, you can use those tools to manage VMs as well, letting you mix and match as you like. I would like to see a guide on using the above mentioned tools or similar to deploy/manage LTSP Cluster. Does anybody have any leads? Thanks, Sean Harbour Senior Network Engineer Northwest Regional Education Service District Hillsboro, OR 97124 sharbour at nwresd.k12.or.us 503-614-1448 From cisna-barry at wc235.k12.il.us Tue Nov 30 12:11:22 2010 From: cisna-barry at wc235.k12.il.us (Barry Cisna) Date: Tue, 30 Nov 2010 06:11:22 -0600 Subject: [K12OSN] Users can't login Message-ID: <1291119082.29819.48.camel@hi2.wc235.k12.il.us> Brian, In your etc/hosts file ,,,append to the ; 127.0.0.1 ,,,,servername.domainname servername ,,,along with the localhost.localdomain localhost entries Reboot the the server ,,service network restart ,,,will not do it, See if this helps? You are showing the actual servername *only* in your ipv6 setting, as your hosts file reads right now,,(No ipv4 entry)for localhost. ::1 orpheus localhost6.localdomain6 localhost6 >From the errors that are showing up in the ltsp build it appears there are most likely multiple problems. See what happens. Barry From monteslu at cox.net Tue Nov 30 14:56:12 2010 From: monteslu at cox.net (Luis Montes) Date: Tue, 30 Nov 2010 07:56:12 -0700 Subject: [K12OSN] k12linux on f14/centos6 In-Reply-To: <4CE798CC.4000005@dageek.co.uk> References: <1290187679.7049.4.camel@localhost> <4CE798CC.4000005@dageek.co.uk> Message-ID: <4CF5108C.7090207@cox.net> Gavin Spurgeon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 19/11/2010 17:27, Lars Schade wrote: > >> Hi there, >> >> I recently installed fedora14 with the intention to run k12linux just to >> learn that there is an old defunct package in the distribution. >> >> Since I need to make plans for a server I run for a small non-profit >> nature park administration, I am curious to learn whether there are >> plans to provide rpm's for f14 or preferentially even for centos6 (which >> is based on f12/13 and to appear soon?) in the near future, say before >> the end of the year? >> >> I followed the discussion on the future of LTSP with interest but think >> I stick to it for the time being. And I would really like to also stick >> to redhat/fedora/centos. >> >> Is there any insider knowledge out there on the future of LTSP on >> f14/centos6? >> > > Yes I can give you a little bit of a heads up on the F14 side of things, > https://bugzilla.redhat.com/show_bug.cgi?id=652896 > and also > https://bugzilla.redhat.com/show_bug.cgi?id=598134 > > As you can see, I was working on LTSP in F13 and and got the package > working fully on I386 & x86_64. As I can also see that Warren seems to > have gone AWOL again, On monday when I get to work I will take over > BZ652896 and again work to get the .rpm's for F14 I386 and x86_64 pushed > up to the official repos. I will keep the BZ up2date with my progress, > so please keep an eye on it. > > If the package gets into F13/F14 we have a very good chance of getting > it into RHEL or with a little more work on my part, we might be able to > get it into CentOS. > > Sorry it has been like this, I didn't want to mess with Warren's > packages once he said he was back (2010-09-25) but it looks like he has > gone AWOL again, so I will get back on to it and get LTSP updated and in > to the official repos for both F13 and F14 as soon as I can. > > - -- > > Gavin Spurgeon. > AKA Da Geek > > - ---------------------------------------------------------------------- > "The happiest of people don't necessarily have the best of everything, > they just make the most of everything that comes along their way.." > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.12 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkznmMsACgkQvp6arS3vDir4UgCg2H1BC6nu9qftol46doSU5Adv > cR8AniGTZorPN0mOoT4HuSkPpAK5gdUP > =KDlF > -----END PGP SIGNATURE----- > > -- > This message was scanned by DaGeek Spam Filter and is believed to be clean. > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > > It's been a few years, so I don't remember the exact details, but there was something stopping ltsp5(muekow) from working in CentOS 5. Did that blockage get rectified with RHEL 6? I'm currently on a very outdated fedora/ltsp5 version and would love to be able to upgrade the school to ltsp5/CentOS6 ASAP. I'm only able to do these types of upgrades during the summer, or possible during the Christmas break. I'd be happy to help with any testing to move this along. Luis From news at siddall.name Tue Nov 30 17:36:18 2010 From: news at siddall.name (Jeff Siddall) Date: Tue, 30 Nov 2010 12:36:18 -0500 Subject: [K12OSN] k12linux on f14/centos6 In-Reply-To: <4CF5108C.7090207@cox.net> References: <1290187679.7049.4.camel@localhost> <4CE798CC.4000005@dageek.co.uk> <4CF5108C.7090207@cox.net> Message-ID: <4CF53612.5070302@siddall.name> > It's been a few years, so I don't remember the exact details, but there > was something stopping ltsp5(muekow) from working in CentOS 5. Did that > blockage get rectified with RHEL 6? I think there were a lot of issues, including missing PulseAudio, that broke things. RHEL 6 is based on Fedora 12/13 which both support LTSP5 so I don't think there will be a lot of pain getting LTSP5 + RHEL/CentOS 6 working. Jeff