From wtogami at redhat.com Wed Jul 2 03:01:57 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 01 Jul 2008 23:01:57 -0400 Subject: Keyboard Layout settings from lts.conf Message-ID: <486AEFA5.10109@redhat.com> https://admin.fedoraproject.org/updates/F9/pending/ldm-2.0.7-1.fc9 http://kojipkgs.fedoraproject.org/packages/ldm/2.0.7/1.fc9/ This update to ldm-2.0.7 makes it possible to set the XKB* keyboard layout options as specified in lts.conf. Prior to this Fedora had no way of setting the keyboard layout because we do not use configure-x.sh which uses ugly hacks to write an xorg.conf based on lts.conf options. ldm-2.0.7 also adds translations for Portuguese (pt) and Greek (el). NOTE: Non-default screen.d sessions like xdmcp will not set the keyboard layout from this fix. I intend on fixing that in a different way in ltsp-client later. Upgrade Note: Be sure to upgrade this package inside your LTSP client chroot which is likely in /opt/ltsp/i386. ldm is useless on the server. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Jul 2 03:06:33 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 01 Jul 2008 23:06:33 -0400 Subject: xorg.conf and autodetection, resolution and keyboard layout In-Reply-To: <4219988b0806211241i31fd0b66n49c8d623bef8d6b3@mail.gmail.com> References: <485C185D.3070800@redhat.com> <4219988b0806211241i31fd0b66n49c8d623bef8d6b3@mail.gmail.com> Message-ID: <486AF0B9.9030500@redhat.com> Hi Nadav, see the previous post on the list. ldm-2.0.7 should make it possible to specify these XKB* options from lts.conf with ldm logins. But read below... Nadav Kavalerchik wrote: > > anyways... > back to your post. here is a snap of how we use (ltsp 4.2) to configure > X in lts.conf : > XKBSYMBOLS = "us(pc101)" > XKBMODEL = "pc101" > XKBLAYOUT = "us,il" > XKBRULES = "xorg" > #XKBOPTIONS = "grp:alt_shift_toggle,grp_led:scroll" > > # hebrew nikud support (Win+Num) > XKBOPTIONS = "grp:alt_shift_toggle,grp_led:scroll,lv3:lwin_switch" > XKBVARIANT = ",si1452" > It appears that you have some bad syntax above. I checked with the Debian and Ubuntu maintainers of LTSP and they agree. You shouldn't have more than one XKBLAYOUT, and XKBVARIANT beginning with a comma character appears to be wrong. Anyway, please give ldm-2.0.7 a try with fixed syntax and let the list know if it does the job. Warren Togami wtogami at redhat.com From nadavkav at gmail.com Wed Jul 2 07:41:37 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Wed, 2 Jul 2008 10:41:37 +0300 Subject: xorg.conf and autodetection, resolution and keyboard layout In-Reply-To: <486AF0B9.9030500@redhat.com> References: <485C185D.3070800@redhat.com> <4219988b0806211241i31fd0b66n49c8d623bef8d6b3@mail.gmail.com> <486AF0B9.9030500@redhat.com> Message-ID: <4219988b0807020041h29e3e50es9a80304a831b8bc2@mail.gmail.com> well, it works with the comma and it works with setxkbmap command too :-) (example: setxkbmap -model pc104 -layout il,us -variant ,basic) but i can always change the layout sequence and the change the variant sequence too so their will be no comma and a variant afterwards. no biggy :-) i have installed your latest ltsp5 packages and i have issues :-( 1. i can not get the tftp to send the kernel to the terminal. i follow your instructions on the k12ltsp page without any problems (almost) and i am unable to boot the terminal (and the virtual terminal too) i use eth1 for the terminals and eth0 for the internet. i never used a bridge before and i suspect it is the issue here, although it looks operational. i got wireshark on and i am getting tftp request but no file is sent from the server to the terminal. 2. i found the *ltsp-server-initialize *script and tried it but got error ipcalc unable to compute 192.168.0.254 so i got inside the script and changed it to 192.168.10.254 for it to work. i hope i didnt break it and i change the interface to eth1 too. 3. i had to stop and disable the dhcpd and start ltsp-dhcpd and point it to my dhcpd-k12ltsp.conf file with our terminal's defaults. 4. remarking the line /tftpboot didn't help since the script ltsp-build-client was parssing the file and finding it inside the remark (i took me some time to fegure it out) so i had to remove it complitly and chage it to /var/lib/tftp in /etc/xinetd.d/tftp file. after fixing this little issue with tftp the build-client finished smoothly with no errors :-) runnning the vmclient i get no dhcpd error and the boot hangs. i set ltsp-dhcpd to listen to eth1 is that ok ? it seems to work for the actual terminals but not for the vmclient. :-) On Wed, Jul 2, 2008 at 6:06 AM, Warren Togami wrote: > Hi Nadav, see the previous post on the list. ldm-2.0.7 should make it > possible to specify these XKB* options from lts.conf with ldm logins. But > read below... > > Nadav Kavalerchik wrote: > >> >> anyways... >> back to your post. here is a snap of how we use (ltsp 4.2) to configure X >> in lts.conf : >> XKBSYMBOLS = "us(pc101)" >> XKBMODEL = "pc101" >> XKBLAYOUT = "us,il" >> XKBRULES = "xorg" >> #XKBOPTIONS = "grp:alt_shift_toggle,grp_led:scroll" >> >> # hebrew nikud support (Win+Num) >> XKBOPTIONS = "grp:alt_shift_toggle,grp_led:scroll,lv3:lwin_switch" >> XKBVARIANT = ",si1452" >> >> > It appears that you have some bad syntax above. I checked with the Debian > and Ubuntu maintainers of LTSP and they agree. You shouldn't have more than > one XKBLAYOUT, and XKBVARIANT beginning with a comma character appears to be > wrong. > > Anyway, please give ldm-2.0.7 a try with fixed syntax and let the list know > if it does the job. > > > Warren Togami > wtogami at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Thu Jul 3 17:16:21 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 03 Jul 2008 13:16:21 -0400 Subject: LDM_DIRECTX=yes by default? Message-ID: <486D0965.5040405@redhat.com> The current default of LTSP5 is to tunnel *everything* from the ldm login session through an ssh tunnel. This increases security a lot, but decreases usability of the default configuration since it scales very poorly. For example, a server that might be able to handle 40 clients with LDM_DIRECTX=yes might handle only ten with everything through the ssh tunnel. (These are made up numbers.) If lts.conf has LDM_DIRECTX=yes, then the login and password is encrypted by ssh, but X is unencrypted over the network. This makes the desktop performance a little better, but more importantly it allows the LTSP server to scale to a similar number of simultaneous clients as the old XDMCP-based LTSP4.2. This is bad for security, but if our goal is to have something usable out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we should do it? How do people feel about this? Warren Togami wtogami at redhat.com From monteslu at cox.net Thu Jul 3 19:14:44 2008 From: monteslu at cox.net (monteslu at cox.net) Date: Thu, 3 Jul 2008 12:14:44 -0700 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> Message-ID: <20080703151444.TEQYW.493086.imail@fed1rmwml38> I found that on edubuntu 7.04 I could not get thumbdrives working on thin clients when LDM_DIRECTX was set to yes, however performance of tunneling everything through SSH was just awful. Anything with the slightest amount of animation was choppy. I'd say make the default LDM_DIRECTX=yes, but make sure that local devices still automatically mount and popup nautilis/dolphin on the thin clients. Luis ---- Warren Togami wrote: > The current default of LTSP5 is to tunnel *everything* from the ldm > login session through an ssh tunnel. This increases security a lot, but > decreases usability of the default configuration since it scales very > poorly. For example, a server that might be able to handle 40 clients > with LDM_DIRECTX=yes might handle only ten with everything through the > ssh tunnel. (These are made up numbers.) > > If lts.conf has LDM_DIRECTX=yes, then the login and password is > encrypted by ssh, but X is unencrypted over the network. This makes the > desktop performance a little better, but more importantly it allows the > LTSP server to scale to a similar number of simultaneous clients as the > old XDMCP-based LTSP4.2. > > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list From steven at simplycircus.com Thu Jul 3 19:55:12 2008 From: steven at simplycircus.com (Steven Santos) Date: Thu, 3 Jul 2008 15:55:12 -0400 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> Message-ID: I can see reasons for both, but given the facts you present, I would default to yes. _____ Steven Santos Director, Simply Circus, Inc. Email: Steven at SimplyCircus.com Mail: 14 Pierrepont Road Newton, MA 02462 Phone: 617-527-0667 Web: www.SimplyCircus.com > -----Original Message----- > From: k12linux-devel-list-bounces at redhat.com > [mailto:k12linux-devel-list-bounces at redhat.com]On Behalf Of Warren > Togami > Sent: Thursday, July 03, 2008 1:16 PM > To: Development discussion of K12Linux > Subject: LDM_DIRECTX=yes by default? > > > The current default of LTSP5 is to tunnel *everything* from the ldm > login session through an ssh tunnel. This increases security a lot, but > decreases usability of the default configuration since it scales very > poorly. For example, a server that might be able to handle 40 clients > with LDM_DIRECTX=yes might handle only ten with everything through the > ssh tunnel. (These are made up numbers.) > > If lts.conf has LDM_DIRECTX=yes, then the login and password is > encrypted by ssh, but X is unencrypted over the network. This makes the > desktop performance a little better, but more importantly it allows the > LTSP server to scale to a similar number of simultaneous clients as the > old XDMCP-based LTSP4.2. > > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > > From eharrison at mesd.k12.or.us Thu Jul 3 20:23:23 2008 From: eharrison at mesd.k12.or.us (Eric Harrison) Date: Thu, 3 Jul 2008 13:23:23 -0700 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> References: <486D0965.5040405@redhat.com> Message-ID: <9e29091b0807031323s2c58eb47y6baa3783e9bad280@mail.gmail.com> I vote for LDM_DIRECTX=yes and note it in the docs & add a comment in the config file. -Eric On 7/3/08, Warren Togami wrote: > The current default of LTSP5 is to tunnel *everything* from the ldm > login session through an ssh tunnel. This increases security a lot, but > decreases usability of the default configuration since it scales very > poorly. For example, a server that might be able to handle 40 clients > with LDM_DIRECTX=yes might handle only ten with everything through the > ssh tunnel. (These are made up numbers.) > > If lts.conf has LDM_DIRECTX=yes, then the login and password is > encrypted by ssh, but X is unencrypted over the network. This makes the > desktop performance a little better, but more importantly it allows the > LTSP server to scale to a similar number of simultaneous clients as the > old XDMCP-based LTSP4.2. > > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > -- Eric Harrison Technology Services Multnomah Education Service District (503)257-1554 cell: (971)998-6249 From dbond at nrggos.com.au Thu Jul 3 21:42:51 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Fri, 4 Jul 2008 07:42:51 +1000 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> References: <486D0965.5040405@redhat.com> Message-ID: <486D47DB.8090409@nrggos.com.au> I agree, Most LTSP applications are on a protected LAN (or should be). Encrypting X is a great idea if the traffic has to travel over an uncontrolled network and should be available but need not be the default. Losing the local devices is more of an issue. Regards Darryl Bond Warren Togami wrote: > The current default of LTSP5 is to tunnel *everything* from the ldm > login session through an ssh tunnel. This increases security a lot, but > decreases usability of the default configuration since it scales very > poorly. For example, a server that might be able to handle 40 clients > with LDM_DIRECTX=yes might handle only ten with everything through the > ssh tunnel. (These are made up numbers.) > > If lts.conf has LDM_DIRECTX=yes, then the login and password is > encrypted by ssh, but X is unencrypted over the network. This makes the > desktop performance a little better, but more importantly it allows the > LTSP server to scale to a similar number of simultaneous clients as the > old XDMCP-based LTSP4.2. > > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company. From wtogami at redhat.com Thu Jul 3 21:59:18 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 03 Jul 2008 17:59:18 -0400 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D47DB.8090409@nrggos.com.au> References: <486D0965.5040405@redhat.com> <486D47DB.8090409@nrggos.com.au> Message-ID: <486D4BB6.9070801@redhat.com> Actually... I just retested F9 LTSP with a thin client and localdev. with or without LDM_DIRECTX my USB stick seems to work just fine. This isn't the case for you folks? Warren Togami wtogami at redhat.com Darryl Bond wrote: > I agree, Most LTSP applications are on a protected LAN (or should be). > Encrypting X is a great idea if the traffic has to travel over an > uncontrolled network and should be available but need not be the default. > > Losing the local devices is more of an issue. > > > Regards > Darryl Bond From monteslu at cox.net Thu Jul 3 22:28:55 2008 From: monteslu at cox.net (monteslu at cox.net) Date: Thu, 3 Jul 2008 15:28:55 -0700 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D4BB6.9070801@redhat.com> Message-ID: <20080703182855.WPXJA.495805.imail@fed1rmwml38> This may have just been a bug during the edubuntu 7.04 timeframe. If you have local devices working with LDM_DIRECTX=yes, then my personal opinion is to definitely make it the default. Luis ---- Warren Togami wrote: > Actually... I just retested F9 LTSP with a thin client and localdev. > with or without LDM_DIRECTX my USB stick seems to work just fine. This > isn't the case for you folks? > > Warren Togami > wtogami at redhat.com > > Darryl Bond wrote: > > I agree, Most LTSP applications are on a protected LAN (or should be). > > Encrypting X is a great idea if the traffic has to travel over an > > uncontrolled network and should be available but need not be the default. > > > > Losing the local devices is more of an issue. > > > > > > Regards > > Darryl Bond > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list From amposborne at googlemail.com Thu Jul 3 22:56:30 2008 From: amposborne at googlemail.com (Andrew Osborne) Date: Thu, 3 Jul 2008 23:56:30 +0100 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> References: <486D0965.5040405@redhat.com> Message-ID: <6befb72f0807031556j31f3c288rc58f1363cf713cbe@mail.gmail.com> I would agree Warren , I have now a working and used test setup with 10 Terminals connected to Fedora 8/LTSP5 in a Primary School, sound and video is in heavy use, with LDM_DIRECTX=yes enabled the terminals are more responsive. I would expect if one wanted more security then having an option to set it is more logical, than removing it. 2008/7/3 Warren Togami : > The current default of LTSP5 is to tunnel *everything* from the ldm login > session through an ssh tunnel. This increases security a lot, but decreases > usability of the default configuration since it scales very poorly. For > example, a server that might be able to handle 40 clients with > LDM_DIRECTX=yes might handle only ten with everything through the ssh > tunnel. (These are made up numbers.) > > If lts.conf has LDM_DIRECTX=yes, then the login and password is encrypted > by ssh, but X is unencrypted over the network. This makes the desktop > performance a little better, but more importantly it allows the LTSP server > to scale to a similar number of simultaneous clients as the old XDMCP-based > LTSP4.2. > > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavkav at gmail.com Fri Jul 4 07:56:08 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Fri, 4 Jul 2008 10:56:08 +0300 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <6befb72f0807031556j31f3c288rc58f1363cf713cbe@mail.gmail.com> References: <486D0965.5040405@redhat.com> <6befb72f0807031556j31f3c288rc58f1363cf713cbe@mail.gmail.com> Message-ID: <4219988b0807040056i7c222bccx8eaf3bb2af047c24@mail.gmail.com> we do not care for security :-) it is better we get usable interface that can show videos and sound than have the X session encrypted ??? so kids in school feel safe ? i do not understand why implement this feature in the first place ? 2008/7/4 Andrew Osborne : > I would agree Warren , I have now a working and used test setup with 10 > Terminals connected to Fedora 8/LTSP5 in a Primary School, sound and video > is in heavy use, with LDM_DIRECTX=yes enabled the terminals are more > responsive. > > I would expect if one wanted more security then having an option to set it > is more logical, than removing it. > > > > 2008/7/3 Warren Togami : > > The current default of LTSP5 is to tunnel *everything* from the ldm login >> session through an ssh tunnel. This increases security a lot, but decreases >> usability of the default configuration since it scales very poorly. For >> example, a server that might be able to handle 40 clients with >> LDM_DIRECTX=yes might handle only ten with everything through the ssh >> tunnel. (These are made up numbers.) >> >> If lts.conf has LDM_DIRECTX=yes, then the login and password is encrypted >> by ssh, but X is unencrypted over the network. This makes the desktop >> performance a little better, but more importantly it allows the LTSP server >> to scale to a similar number of simultaneous clients as the old XDMCP-based >> LTSP4.2. >> >> This is bad for security, but if our goal is to have something usable >> out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we >> should do it? >> >> How do people feel about this? >> >> Warren Togami >> wtogami at redhat.com >> >> _______________________________________________ >> K12Linux-devel-list mailing list >> K12Linux-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/k12linux-devel-list >> > > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavkav at gmail.com Fri Jul 4 07:58:09 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Fri, 4 Jul 2008 10:58:09 +0300 Subject: boot / network issues with new install FC9 Message-ID: <4219988b0807040058n236f935bm709820ba5ed6836d@mail.gmail.com> i have installed your latest ltsp5 packages and i have issues :-( 1. i can not get the tftp to send the kernel to the terminal. i follow your instructions on the k12ltsp page without any problems (almost) and i am unable to boot the terminal (and the virtual terminal too) i use eth1 for the terminals and eth0 for the internet. i never used a bridge before and i suspect it is the issue here, although it looks operational. i got wireshark on and i am getting tftp request but no file is sent from the server to the terminal. 2. i found the *ltsp-server-initialize *script and tried it but got error ipcalc unable to compute 192.168.0.254 so i got inside the script and changed it to 192.168.10.254 for it to work. i hope i didnt break it and i change the interface to eth1 too. 3. i had to stop and disable the dhcpd and start ltsp-dhcpd and point it to my dhcpd-k12ltsp.conf file with our terminal's defaults. 4. remarking the line /tftpboot didn't help since the script ltsp-build-client was parssing the file and finding it inside the remark (i took me some time to fegure it out) so i had to remove it complitly and chage it to /var/lib/tftp in /etc/xinetd.d/tftp file. after fixing this little issue with tftp the build-client finished smoothly with no errors :-) runnning the vmclient i get no dhcpd error and the boot hangs. i set ltsp-dhcpd to listen to eth1 is that ok ? it seems to work for the actual terminals but not for the vmclient. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From weba at ancollege.org Sat Jul 5 18:45:04 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Sun, 6 Jul 2008 00:15:04 +0530 Subject: ltsp server initialise script problem Message-ID: <32a1284d0807051145w30b60ff0u7571552fbb65db32@mail.gmail.com> the command "ltsp-server-initialize -y" terminates with the following verbose help me to trouble shoot ..... [root at localhost hdd2]# ltsp-server-initialize -y /usr/share/ltsp//scripts.d//09-disable-suspend-hibernate: Resolved address "xml:readwrite:/etc/gconf/gconf.xml.defaults" to a writable configuration source at position 0 Resolved address "xml:readwrite:/etc/gconf/gconf.xml.defaults" to a writable configuration source at position 0 running hosts-update Can't call method "broadcast" without a package or object reference at /usr/share/ltsp//scripts/hosts-update line 20. From rogdepre at skynet.be Sun Jul 6 08:08:23 2008 From: rogdepre at skynet.be (roger depreeuw) Date: Sun, 06 Jul 2008 10:08:23 +0200 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> References: <486D0965.5040405@redhat.com> Message-ID: <48707D77.5000903@skynet.be> Warren Togami wrote: > The current default of LTSP5 is to tunnel *everything* from the ldm > login session through an ssh tunnel. This increases security a lot, but > decreases usability of the default configuration since it scales very > poorly. For example, a server that might be able to handle 40 clients > with LDM_DIRECTX=yes might handle only ten with everything through the > ssh tunnel. (These are made up numbers.) > > If lts.conf has LDM_DIRECTX=yes, then the login and password is > encrypted by ssh, but X is unencrypted over the network. This makes the > desktop performance a little better, but more importantly it allows the > LTSP server to scale to a similar number of simultaneous clients as the > old XDMCP-based LTSP4.2. > > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > LDM_DIRECTX=yes makes a big difference in speed on my test system. A simple test, to see the difference, i do by launching a youtube video in firefox. But making this the default may conflict with the general phylosophy of fedora and K12 on how secure a system should be, ie firewall is also running by default and needs to be reconfigured to open up certain ports or services. As long as the admin can control it i don't see an issue. I do have 2 other issues that puzzle me. What happened to NBDSWAPD. Did i miss something along the line? And also, i need lts.conf in both places if i want a shell on one screen and ldm on another. I need the default setting and client specific setting in the tftpboot download area and a deault only seeting in chroot /optltsp/i386/etc. Is this correct? Regrds Roger From robark at gmail.com Sun Jul 6 20:54:29 2008 From: robark at gmail.com (Robert Arkiletian) Date: Sun, 6 Jul 2008 13:54:29 -0700 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <486D0965.5040405@redhat.com> References: <486D0965.5040405@redhat.com> Message-ID: On Thu, Jul 3, 2008 at 10:16 AM, Warren Togami wrote: ... > This is bad for security, but if our goal is to have something usable > out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we > should do it? > > How do people feel about this? > Not sure how one would exploit this security hole? So traffic is not encrypted. It travels from the client to the switch to the server. How is someone on another client or even with a laptop on the lan going to sniff keystrokes? If they fake the MAC address of a client that X session will break anyway. Unless one is root on the server and captures traffic with wireshark on the internal nic I can't see how to spy on the traffic. With ldm_directx=yes My only concern is if I can safely su to root from a client without having to worry about some clever kid sniffing my root password. If this is not safe then please enlighten me as to the exploit method as security through obscurity is no security. -- Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada Fl_TeacherTool http://www3.telus.net/public/robark/Fl_TeacherTool/ C++ GUI tutorial http://www3.telus.net/public/robark/ From wtogami at redhat.com Mon Jul 7 02:54:23 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 06 Jul 2008 22:54:23 -0400 Subject: LDM_DIRECTX=yes by default? In-Reply-To: References: <486D0965.5040405@redhat.com> Message-ID: <4871855F.7070502@redhat.com> Robert Arkiletian wrote: > On Thu, Jul 3, 2008 at 10:16 AM, Warren Togami wrote: > ... >> This is bad for security, but if our goal is to have something usable >> out-of-the-box in a similar fashion to how K12LTSP was, then perhaps we >> should do it? >> >> How do people feel about this? >> > > Not sure how one would exploit this security hole? So traffic is not > encrypted. It travels from the client to the switch to the server. How > is someone on another client or even with a laptop on the lan going to > sniff keystrokes? If they fake the MAC address of a client that X > session will break anyway. Unless one is root on the server and > captures traffic with wireshark on the internal nic I can't see how to > spy on the traffic. > > With ldm_directx=yes > My only concern is if I can safely su to root from a client without > having to worry about some clever kid sniffing my root password. > > If this is not safe then please enlighten me as to the exploit method > as security through obscurity is no security. > This isn't really security through obscurity. It is known to be completely wide open and unencrypted on the wire. This is no worse than how LTSP worked in past years. Except with LDM at least your initial login and password are encrypted. If you want to make it unencrypted for ordinary clients but encrypted for specific clients, you could use MAC addresses in lts.conf to control LDM_DIRECTX for those specific clients. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Jul 7 02:58:25 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 06 Jul 2008 22:58:25 -0400 Subject: LDM_DIRECTX=yes by default? In-Reply-To: <48707D77.5000903@skynet.be> References: <486D0965.5040405@redhat.com> <48707D77.5000903@skynet.be> Message-ID: <48718651.9000202@redhat.com> roger depreeuw wrote: > I do have 2 other issues that puzzle me. > What happened to NBDSWAPD. Did i miss something along the line? > And also, i need lts.conf in both places if i want a shell on one screen > and ldm on another. I need the default setting and client specific > setting in the tftpboot download area and a deault only seeting in > chroot /optltsp/i386/etc. Is this correct? > If lts.conf is successfully grabbed from the server, then it replaces whatever lts.conf is in /opt/ltsp/i386. So you only need to change lts.conf in one location, the tftpboot directory. NBD swap should be enabled by default in Fedora 9 LTSP. It should be giving you 256MB swap by default. If you aren't seeing it then there might be a bug. Also the default lts.conf runs a shell on VT2 through VT6 with X on VT7. This remains because it is helpful to me in debugging/testing and it doesn't really harm anything. I will likely remove the VT2 through VT6 from the default configuration before Fedora 10. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Jul 7 19:46:06 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Jul 2008 15:46:06 -0400 Subject: ltsp-server-initialize thoughts Message-ID: <4872727E.4050105@redhat.com> I'm thinking that we should remove ltsp-server-initialize from the documentation so newbie users don't use it and get burned. It is clearly not ready today, and knowing what to do to "fix" is not straight forward due to it not being clear which interface should be attached to the bridge. If you personally want to work on ltsp-server-initialize then please do. You don't need permission from anyone. Post your questions, comments and patches to this list for others to review. Thoughts? Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Jul 7 19:50:49 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Jul 2008 15:50:49 -0400 Subject: RHEL5 and fuse Message-ID: <48727399.6020104@redhat.com> So I got LTSP5 working on a RHEL5 server (with the F9 client chroot), except for ltspfs for local device support. RHEL5 doesn't have fuse kernel modules and userspace, and this is something that cannot be added to EPEL because external kernel modules are not allowed there. I think I will make RHEL5 LTSP without local device support, but it should work if people install a few unofficial packages that we could provide from our site. http://dag.wieers.com/rpm/packages/dkms-fuse/ This package plus some fuse userspace and ltspfs should be enough. Given that we cannot make LTSP5 on RHEL5 work without Fedora bits, it is already unsupported. Adding these more unsupported packages to the host shouldn't create much more difficulty. Thoughts? I think I'll just do it soon and put it online for people to test. Warren Togami wtogami at redhat.com From dbond at nrggos.com.au Mon Jul 7 21:34:25 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Tue, 8 Jul 2008 07:34:25 +1000 Subject: RHEL5 and fuse In-Reply-To: <48727399.6020104@redhat.com> References: <48727399.6020104@redhat.com> Message-ID: <48728BE1.9010706@nrggos.com.au> What is the RedHat's policy for adding additional kernel modules? It isn't verboten as I have seen some drivers added to RHEL4. Centos has the Centos Plus repository that has extra useful kernel modules like jfs. Pity RH don't have likewise. Still, RHEL targets Enterprise servers. The stuff LTSP needs is pretty squarely in the desktop end. I know that RH purport to support enterprise desktops but while the equivalent of Fedora Extras doesn't exist then I don't think they are really trying. Darryl Warren Togami wrote: > So I got LTSP5 working on a RHEL5 server (with the F9 client chroot), > except for ltspfs for local device support. > > RHEL5 doesn't have fuse kernel modules and userspace, and this is > something that cannot be added to EPEL because external kernel modules > are not allowed there. > > I think I will make RHEL5 LTSP without local device support, but it > should work if people install a few unofficial packages that we could > provide from our site. > > http://dag.wieers.com/rpm/packages/dkms-fuse/ > This package plus some fuse userspace and ltspfs should be enough. > > Given that we cannot make LTSP5 on RHEL5 work without Fedora bits, it is > already unsupported. Adding these more unsupported packages to the host > shouldn't create much more difficulty. > > Thoughts? I think I'll just do it soon and put it online for people to > test. > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company. From ashley.gale3 at gmail.com Mon Jul 7 23:57:30 2008 From: ashley.gale3 at gmail.com (Ashley Gale) Date: Tue, 08 Jul 2008 09:57:30 +1000 Subject: ltsp-server-initialize thoughts In-Reply-To: <4872727E.4050105@redhat.com> References: <4872727E.4050105@redhat.com> Message-ID: <4872AD6A.6090406@googlemail.com> Hi Warren, Ho do you fix it if you have run ltsp-server-initialize? Or am I better doing a fresh install. Regards Ashley (Newbie who does not know how to fix it and put it in) Warren Togami wrote: > I'm thinking that we should remove ltsp-server-initialize from the > documentation so newbie users don't use it and get burned. > > It is clearly not ready today, and knowing what to do to "fix" is not > straight forward due to it not being clear which interface should be > attached to the bridge. > > If you personally want to work on ltsp-server-initialize then please > do. You don't need permission from anyone. Post your questions, > comments and patches to this list for others to review. > > Thoughts? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > From wtogami at redhat.com Tue Jul 8 03:02:20 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Jul 2008 23:02:20 -0400 Subject: RHEL5 and fuse In-Reply-To: <48728BE1.9010706@nrggos.com.au> References: <48727399.6020104@redhat.com> <48728BE1.9010706@nrggos.com.au> Message-ID: <4872D8BC.6000204@redhat.com> Darryl Bond wrote: > What is the RedHat's policy for adding additional kernel modules? It > isn't verboten as I have seen some drivers added to RHEL4. > > Centos has the Centos Plus repository that has extra useful kernel > modules like jfs. Pity RH don't have likewise. > Still, RHEL targets Enterprise servers. The stuff LTSP needs is pretty > squarely in the desktop end. I know that RH purport to support > enterprise desktops but while the equivalent of Fedora Extras doesn't > exist then I don't think they are really trying. > > > Darryl > You sir have to get your facts straight. http://fedoraproject.org/wiki/EPEL Here addresses one of your concerns. Warren From wtogami at redhat.com Tue Jul 8 03:03:46 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Jul 2008 23:03:46 -0400 Subject: ltsp-server-initialize thoughts In-Reply-To: <4872AD6A.6090406@googlemail.com> References: <4872727E.4050105@redhat.com> <4872AD6A.6090406@googlemail.com> Message-ID: <4872D912.2090000@redhat.com> That's part of the reason why I am suggesting that we don't point users at it now. It cannot do a complete job of setting up a server without a serious amount of more work. At least if you follow the steps in the documentation you know exactly what you did and what to do to undo it. Warren Ashley Gale wrote: > Hi Warren, > > Ho do you fix it if you have run ltsp-server-initialize? Or am I better > doing a fresh install. > > Regards > Ashley > (Newbie who does not know how to fix it and put it in) > > Warren Togami wrote: >> I'm thinking that we should remove ltsp-server-initialize from the >> documentation so newbie users don't use it and get burned. >> >> It is clearly not ready today, and knowing what to do to "fix" is not >> straight forward due to it not being clear which interface should be >> attached to the bridge. >> >> If you personally want to work on ltsp-server-initialize then please >> do. You don't need permission from anyone. Post your questions, >> comments and patches to this list for others to review. >> >> Thoughts? From dbond at nrggos.com.au Tue Jul 8 03:16:49 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Tue, 8 Jul 2008 13:16:49 +1000 Subject: RHEL5 and fuse In-Reply-To: <4872D8BC.6000204@redhat.com> References: <48727399.6020104@redhat.com> <48728BE1.9010706@nrggos.com.au> <4872D8BC.6000204@redhat.com> Message-ID: <4872DC21.6060206@nrggos.com.au> Ha, I'm all embarrassed now;) I hadn't heard of EPEL. I have been building the Fedora pkgs from SRPMS on RHEL. Darryl Warren Togami wrote: > Darryl Bond wrote: > >> What is the RedHat's policy for adding additional kernel modules? It >> isn't verboten as I have seen some drivers added to RHEL4. >> >> Centos has the Centos Plus repository that has extra useful kernel >> modules like jfs. Pity RH don't have likewise. >> Still, RHEL targets Enterprise servers. The stuff LTSP needs is pretty >> squarely in the desktop end. I know that RH purport to support >> enterprise desktops but while the equivalent of Fedora Extras doesn't >> exist then I don't think they are really trying. >> >> >> Darryl >> >> > > You sir have to get your facts straight. > > http://fedoraproject.org/wiki/EPEL > Here addresses one of your concerns. > > Warren > > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company. From aatrof at gmail.com Wed Jul 9 08:08:43 2008 From: aatrof at gmail.com (Aleksander Trofimowicz) Date: Wed, 9 Jul 2008 10:08:43 +0200 Subject: Fwd: proposal for a few changes to ltsp package In-Reply-To: <759d30a60807071128p536774a1ma76f0ec582bc3c69@mail.gmail.com> References: <759d30a60807071128p536774a1ma76f0ec582bc3c69@mail.gmail.com> Message-ID: <759d30a60807090108wafe07c1y92eefeee873fb325@mail.gmail.com> ---------- Forwarded message ---------- From: Aleksander Trofimowicz Date: 2008/7/7 Subject: proposal for a few changes to ltsp package To: wtogami at redhat.com Hello, Relates to ltsp-5.1.9-1.fc9.src.rpm. While using the ltsp-server package I found a couple of small errors in bash scripts, I guess. Basically errors results from wrong expectations of what ipcalc should give on its output. At least this is the case when I use ipcalc found in initscripts-8.76.2-1.x86_64 package on Fedora 9. Another change fixes a regexp error. I prepared patch against a sources of the package. There is also question about dhcpd-update perl script. Beside that the bad handling of ipcalc output applies here too, I wonder what the purpose of this script is, as it requires the very same network, namely 192.168.0.0/24, in a /etc/ltstp/dhcpd.conf file. Or maybe I missed something? -- cheers, aleksander trofimowicz -------------- next part -------------- A non-text attachment was scrubbed... Name: some.patch Type: application/octet-stream Size: 1428 bytes Desc: not available URL: From weba at ancollege.org Thu Jul 10 11:20:53 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Thu, 10 Jul 2008 16:50:53 +0530 Subject: proposal for a few changes to ltsp package In-Reply-To: <759d30a60807090108wafe07c1y92eefeee873fb325@mail.gmail.com> References: <759d30a60807071128p536774a1ma76f0ec582bc3c69@mail.gmail.com> <759d30a60807090108wafe07c1y92eefeee873fb325@mail.gmail.com> Message-ID: <32a1284d0807100420y52b138e1hf38de9d6a2ada5f4@mail.gmail.com> yes Aleksander you are perfectly right. the ltsp-server-intitialise and dhcpd-update scripts are buggy i am releasing the bug fixed scripts in few hours from now after a thorough test please also make it clear to use ltspbr0 interface in ltsp-server.conf file ....located at /etc/ltsp to start your ltsp-server-initialise script actually in my thought the " ltsp-server-initialise - y " command needs not be invoked when we are using a bridge device to handle all dhcp request from ......ltsp clients ltsp-bridge device concept is new and i am working on the ltsp -server -initialise script to get along with it .... On 7/9/08, Aleksander Trofimowicz wrote: > ---------- Forwarded message ---------- > From: Aleksander Trofimowicz > Date: 2008/7/7 > Subject: proposal for a few changes to ltsp package > To: wtogami at redhat.com > > > Hello, > > Relates to ltsp-5.1.9-1.fc9.src.rpm. > > While using the ltsp-server package I found a couple of small errors > in bash scripts, I guess. Basically errors results from wrong > expectations of what ipcalc should give on its output. At least this > is the case when I use ipcalc found in initscripts-8.76.2-1.x86_64 > package on Fedora 9. Another change fixes a regexp error. I prepared > patch against a sources of the package. > > There is also question about dhcpd-update perl script. Beside that the > bad handling of ipcalc output applies here too, I wonder what the > purpose of this script is, as it requires the very same network, > namely 192.168.0.0/24, in a /etc/ltstp/dhcpd.conf file. Or maybe I > missed something? > > -- > cheers, > aleksander trofimowicz > From weba at ancollege.org Thu Jul 10 19:07:25 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Fri, 11 Jul 2008 00:37:25 +0530 Subject: LTSP-SERVER-INITIALIZE script fixed !!!!!! Message-ID: <32a1284d0807101207l2957f741g4cc2b1b812c5e35f@mail.gmail.com> please test the following scripts as the modifications for the ltsp-server-initialise script and its helper script dhcpd-update place the ltsp-server-initialise script in your /usr/sbin directory place the dhcpd-update script in your /usr/share/ltsp/scripts directory and use the command ltsp-server-initialise -y it should work ..... please comment the progress -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpd-update Type: application/octet-stream Size: 2003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ltsp-server-initialize Type: application/octet-stream Size: 4758 bytes Desc: not available URL: From wtogami at redhat.com Thu Jul 10 19:25:31 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 10 Jul 2008 15:25:31 -0400 Subject: ltsp-5.1.11 heading to Fedora 9 updates Message-ID: <4876622B.90509@redhat.com> https://admin.fedoraproject.org/updates/F9/pending/ltsp-5.1.11-1.fc9 - LDM_DIRECTX=yes unencrypted X by default in lts.conf This is for performance and scalability. Turn it off if you want security. - Fix chroot install that was broken by livecd-tools update - own /var/lib/ltsp to silence tmpwatch selinux errors I pushed it straight into stable because livecd-tools broke chroot installing and this has to be in updates ASAP. I hope I didn't break anything. Warren Togami wtogami at redhat.com From lars.schade at berlin.de Sun Jul 13 16:10:51 2008 From: lars.schade at berlin.de (Lars Schade) Date: Sun, 13 Jul 2008 18:10:51 +0200 (CEST) Subject: selinux problem Message-ID: <1215965451.171567-13348@marvin6.daybyday.de> Dear K12-fedora developers, I am aware that I am posting to a developer's list while I am a user, but since there seems to be no user mailing list yet... Just ignore my mail if my question is too basic. I am trying to set up ltsp with fedora 9 and followed the online instructions. When I run ltsp-build-client I get the following info: [root at test ltsp]# ltsp-build-client Autoconfigured Kickstart: /etc/ltsp/kickstart/Fedora/9/ltsp-i386.ks Installing into /opt/ltsp/i386 Mounting /opt/ltsp/i386 for chroot installation Retrieving http://fedora.tu-chemnitz.de/pub/linux/fedora/linux/releases/9/Everything/i386/os/repodata/repomd.xml ...OK Retrieving http://fedora.tu-chemnitz.de/pub/linux/fedora/linux/releases/9/Everything/i386/os/repodata/primary.sqlite.bz2 ...OK Retrieving http://togami.com/~k12linux-temporary/fedora/9/i386/repodata/repomd.xml ...OK Retrieving http://togami.com/~k12linux-temporary/fedora/9/i386/repodata/primary.xml.gz ...OK Retrieving http://ftp-stud.hs-esslingen.de/pub/fedora/linux/updates/9/i386/repodata/repomd.xml ...OK Retrieving http://ftp-stud.hs-esslingen.de/pub/fedora/linux/updates/9/i386/repodata/primary.sqlite.bz2 ...OK No such package firstboot-tui to remove No such package vixie-cron to remove Error creating image : Unable to disable SELinux because the installed package set did not include the file /usr/sbin/lokkit error: LTSP client installation ended abnormally The file /usr/sbin/lokkit exists, should it also exist in the chroot? Or do I have to disable SElinux during installation amd setup of LTSP? Or is LTSP generally incompatible with SElinux? Or can I change th eSElinux rules to work with LTSP? BTW, is it a problem, that firstboot-tui and vixie-cron are missing? Any help is appreciated! - Lars From wtogami at redhat.com Mon Jul 14 15:17:45 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 14 Jul 2008 11:17:45 -0400 Subject: selinux problem In-Reply-To: <1215965451.171567-13348@marvin6.daybyday.de> References: <1215965451.171567-13348@marvin6.daybyday.de> Message-ID: <487B6E19.4030208@redhat.com> Lars Schade wrote: > Error creating image : Unable to disable SELinux because the installed package set did not include the file /usr/sbin/lokkit > error: LTSP client installation ended abnormally An update of livecd-tools that ltsp-build-client relies upon to install the chroot broke LTSP's installer. This is fixed in ltsp-5.1.11 but apparently a Fedora update push hasn't happened in 4 days. Should go out soon. Warren From wtogami at redhat.com Mon Jul 14 20:04:48 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 14 Jul 2008 16:04:48 -0400 Subject: LTSP-SERVER-INITIALIZE script fixed !!!!!! In-Reply-To: <32a1284d0807101207l2957f741g4cc2b1b812c5e35f@mail.gmail.com> References: <32a1284d0807101207l2957f741g4cc2b1b812c5e35f@mail.gmail.com> Message-ID: <487BB160.90100@redhat.com> nilakhya chatterjee wrote: > please test the following scripts as the modifications for the > ltsp-server-initialise script and its helper script dhcpd-update > > place the ltsp-server-initialise script in your /usr/sbin directory > > > place the dhcpd-update script in your /usr/share/ltsp/scripts directory > > > and use the command ltsp-server-initialise -y > > Thanks for looking at it. Here are some comments... 1) Could you please submit proposed changes as unified diff format patches? bzr diff does unidiff by default. Otherwise diff -u will do it. 2) I don't understand the purpose of dhcpd-update. Can anybody explain? And is this really safe? > @@ -39,8 +52,8 @@ > while ($nm[$i] == "255") { > if ($net) { > $net = $net . "."; > - $orignet = $orignet . "."; > - } > + $orignet = $orignet . "."; > + } > $net = $net . $nw[$i]; > $orignet = $orignet . $orignw[$i]; > ++$i; > 3) Why this change? Warren From weba at ancollege.org Tue Jul 15 13:32:59 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Tue, 15 Jul 2008 19:02:59 +0530 Subject: DHCPD-UPDATE explained as far i know :-) Message-ID: <32a1284d0807150632w3762f067y7b40382df2fd214e@mail.gmail.com> dhcpd-update script is actually used to modify the values of ip pool in the "dhcpd.conf" file located in the /etc/ltsp directory particularly in case when we modify the ltspbr0 ip address ( address of the ltsp server) in ifcfg-ltspbr0 (/etc/sysconfig/network-scripts/) previously when we used eth0 device in case of a bridge device the administrator himself or with the ltsp-utils package set the ip of the eth0 device which was constantly referenced for dhcpd.conf file modification suitable for ltsp server based processes. now as the default dhcpd.conf & ifcfg-ltspbr0 file is bundled with LTSP-SERVER distribution using the ip pool 172.31.100.0/24 along with the default ip of 172.31.100.254 for the ltspbr0 device instead of 192.168.0.0/24 ip pool used previously. ltsp-server-initialise , dhcpd-update script was left unedited with the default pool still 192.168.0.0 /24 which creates the whole confusion. either we dont touch the ltsp-server-initialize part and continue doing manual /etc/export (nfs) and /etc/hosts configuration or we carefully use the new updated dhcpd-update script,that also requires the understanding of ltsp-server.conf and ifcfg-ltspbr0 files. i think while not using the ltsp-server-initialize script makes us more responsive in terms of creating all configurations , it also somehow limits the customization of ip pool we may use with the bridge so the updated ltsp-server-initialise not only helps auto configuration thats what nubies like, it actually helps customize our server ip pool that we all administrators love. thanks for writing warren -------------- next part -------------- A non-text attachment was scrubbed... Name: diff file dhcpd update Type: application/octet-stream Size: 1825 bytes Desc: not available URL: From weba at ancollege.org Tue Jul 15 13:49:37 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Tue, 15 Jul 2008 19:19:37 +0530 Subject: LTSP-SERVER-INITIALIZE script fixed !!!!!! In-Reply-To: <487BB160.90100@redhat.com> References: <32a1284d0807101207l2957f741g4cc2b1b812c5e35f@mail.gmail.com> <487BB160.90100@redhat.com> Message-ID: <32a1284d0807150649y6fb43abeuaabfdeb415197593@mail.gmail.com> answer to the first part of your question ..... please view attachment answer to third part of your question ..... - $orignet = $orignet . "."; - } + $orignet = $orignet . "."; + } there is no actual working differences in above lines they are not different except mis alignment caused the diff to show changes answer to the second part of your question ..... dhcpd-update script is actually used to modify the values of ip pool in the "dhcpd.conf" file located in the /etc/ltsp directory particularly in case when we modify the ltspbr0 ip address ( address of the ltsp server) in ifcfg-ltspbr0 (/etc/sysconfig/network-scripts/) previously when we used eth0 device in case of a bridge device the administrator himself or with the ltsp-utils package set the ip of the eth0 device which was constantly referenced for dhcpd.conf file modification suitable for ltsp server based processes. now as the default dhcpd.conf & ifcfg-ltspbr0 file is bundled with LTSP-SERVER distribution using the ip pool 172.31.100.0/24 along with the default ip of 172.31.100.254 for the ltspbr0 device instead of 192.168.0.0/24 ip pool used previously. ltsp-server-initialise , dhcpd-update script was left unedited with the default pool still 192.168.0.0 /24 which creates the whole confusion. either we dont touch the ltsp-server-initialize part and continue doing manual /etc/export (nfs) and /etc/hosts configuration or we carefully use the new updated dhcpd-update script,that also requires the understanding of ltsp-server.conf and ifcfg-ltspbr0 files. i think while not using the ltsp-server-initialize script makes us more responsive in terms of creating all configurations , it also somehow limits the customization of ip pool we may use with the bridge so the updated ltsp-server-initialise not only helps auto configuration thats what nubies like, it actually helps customize our server ip pool that we all administrators love. thanks for writing warren On 7/15/08, Warren Togami wrote: > nilakhya chatterjee wrote: >> please test the following scripts as the modifications for the >> ltsp-server-initialise script and its helper script dhcpd-update >> >> place the ltsp-server-initialise script in your /usr/sbin directory >> >> >> place the dhcpd-update script in your /usr/share/ltsp/scripts directory >> >> >> and use the command ltsp-server-initialise -y >> >> > > Thanks for looking at it. Here are some comments... > > 1) Could you please submit proposed changes as unified diff format > patches? bzr diff does unidiff by default. Otherwise diff -u will do it. > > 2) I don't understand the purpose of dhcpd-update. Can anybody explain? > > And is this really safe? > > >> @@ -39,8 +52,8 @@ >> while ($nm[$i] == "255") { >> if ($net) { >> $net = $net . "."; >> - $orignet = $orignet . "."; >> - } >> + $orignet = $orignet . "."; >> + } >> $net = $net . $nw[$i]; >> $orignet = $orignet . $orignw[$i]; >> ++$i; >> > > 3) Why this change? > > Warren > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff file dhcpd update.txt URL: From wtogami at redhat.com Tue Jul 15 17:49:31 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 15 Jul 2008 13:49:31 -0400 Subject: LTSP-SERVER-INITIALIZE script fixed !!!!!! In-Reply-To: <32a1284d0807150649y6fb43abeuaabfdeb415197593@mail.gmail.com> References: <32a1284d0807101207l2957f741g4cc2b1b812c5e35f@mail.gmail.com> <487BB160.90100@redhat.com> <32a1284d0807150649y6fb43abeuaabfdeb415197593@mail.gmail.com> Message-ID: <487CE32B.7070408@redhat.com> Attached is a cleaned up patch of Nilakhya's changes. I will commit it if somebody else reviews it, probably Eric Harrison since he did most of the past ltsp-server-initialize work. Eric your thoughts? Warren Togami wtogami at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpd-ltsp.patch Type: text/x-patch Size: 4600 bytes Desc: not available URL: From weba at ancollege.org Thu Jul 17 13:10:02 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Thu, 17 Jul 2008 18:40:02 +0530 Subject: ltspbr0 centric real thin clients my recipe' Message-ID: <32a1284d0807170610i780701a8qd0388ae41e7e0f5e@mail.gmail.com> i have a stable installation of real thin clients with a single ethernet device eth0 added to the ltspbr0 device i have noticed that adding the ethernet interface eth0 to the ltspbr0 bridge using the command " brctl addif ltspbr0 eth0" is temporary as the bridge is reset after every boot so to make the settings permanent i did following please suggest any different and better way of doing the same 1 . create a shell script named "ltsp_bridge" and place it in the /etc/init.d with executable permission ( script is shown below) #!/bin/sh brctl ltspbr0 addif eth0 2. create a symbolic link named "S98ltsp_bridge" in the folder /etc/rc.d/rc5.d ( command is given below) ln -s /etc/init.d/ltsp_bridge /etc/rc.d/rc5.d/S98ltsp_bridge 3. reboot the server to enjoy permanent settings for the ltspbr0 based server. best of luck !!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dyoung at mesd.k12.or.us Thu Jul 17 14:57:08 2008 From: dyoung at mesd.k12.or.us (Dan Young) Date: Thu, 17 Jul 2008 07:57:08 -0700 Subject: ltspbr0 centric real thin clients my recipe' In-Reply-To: <32a1284d0807170610i780701a8qd0388ae41e7e0f5e@mail.gmail.com> References: <32a1284d0807170610i780701a8qd0388ae41e7e0f5e@mail.gmail.com> Message-ID: <994441ae0807170757u513d1c21t6768c6b1bb59da39@mail.gmail.com> 2008/7/17 nilakhya chatterjee : > i have a stable installation of real thin clients with a single ethernet > device eth0 added to the ltspbr0 device > > i have noticed that adding the ethernet interface eth0 to the ltspbr0 > bridge using the command " brctl addif ltspbr0 eth0" is temporary as the > bridge is reset after every boot so to make the settings permanent i did > following please suggest any different and better way of doing the same You can persistently add an interface to a bridge using sysconfig/network-scripts: [dyoung at dyoung ~]$ cat /etcsysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=xx:xx:xx:xx:xx:xx ONBOOT=yes TYPE=Ethernet BRIDGE=ltspbr0 -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From dyoung at mesd.k12.or.us Thu Jul 17 14:58:54 2008 From: dyoung at mesd.k12.or.us (Dan Young) Date: Thu, 17 Jul 2008 07:58:54 -0700 Subject: ltspbr0 centric real thin clients my recipe' In-Reply-To: <994441ae0807170757u513d1c21t6768c6b1bb59da39@mail.gmail.com> References: <32a1284d0807170610i780701a8qd0388ae41e7e0f5e@mail.gmail.com> <994441ae0807170757u513d1c21t6768c6b1bb59da39@mail.gmail.com> Message-ID: <994441ae0807170758s1540e64emb5a4745e48fcb734@mail.gmail.com> On Thu, Jul 17, 2008 at 7:57 AM, Dan Young wrote: > [dyoung at dyoung ~]$ cat /etcsysconfig/network-scripts/ifcfg-eth1 Rather: /etc/sysconfig/network-scripts/ifcfg-eth1 -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From balmquist at mindfirestudios.com Thu Jul 17 18:55:35 2008 From: balmquist at mindfirestudios.com (Almquist Burke) Date: Thu, 17 Jul 2008 13:55:35 -0500 Subject: ltspbr0 centric real thin clients my recipe' In-Reply-To: <32a1284d0807170610i780701a8qd0388ae41e7e0f5e@mail.gmail.com> References: <32a1284d0807170610i780701a8qd0388ae41e7e0f5e@mail.gmail.com> Message-ID: <73292706-8B80-4494-878B-B263E9874E11@mindfirestudios.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 17, 2008, at 8:10 AM, nilakhya chatterjee wrote: > i have a stable installation of real thin clients with a single > ethernet device eth0 added to the ltspbr0 device > > i have noticed that adding the ethernet interface eth0 to the > ltspbr0 bridge using the command " brctl addif ltspbr0 eth0" is > temporary as the bridge is reset after every boot so to make the > settings permanent i did following please suggest any different and > better way of doing the same > There are actually instructions on this in the project wiki at https://fedorahosted.org/k12linux/wiki/InstallGuide -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iEYEARECAAYFAkh/lacACgkQxWV7OPa/g5GkgQCfe7htprkvXpvDGKFATvDaTOpL AxMAn3h71TIT25MOhjTzNZBHvPQ7J01w =2o5F -----END PGP SIGNATURE----- From lars.schade at berlin.de Mon Jul 21 11:02:57 2008 From: lars.schade at berlin.de (Lars Schade) Date: Mon, 21 Jul 2008 13:02:57 +0200 (CEST) Subject: f-spot does not start Message-ID: <1216638177.171567-17270@marvin5.daybyday.de> Hello, I am testing a setup with real thin clients. Things seem to work ok except for the use of f-spot from the thin clients. f-spot works fine on the server as do gimp and gthumb or openoffice from the clients. Only f-spot fails to start with the following message: [lars at test ~]$ f-spot Initializing Mono.Addins Starting new FSpot server Query: SELECT photos.id, photos.time, photos.uri, photos.description, photos.rol l_id, photos.default_version_id, photos.rating FROM photos WHERE photos.id NOT IN (SELECT photo_id FROM photo_tags WHERE tag_id = 2) ORDER BY photos.time Query: SELECT photos.id, photos.time, photos.uri, photos.description, photos.rol l_id, photos.default_version_id, photos.rating FROM photos WHERE photos.id NOT IN (SELECT photo_id FROM photo_tags WHERE tag_id = 2) ORDER BY photos.time The program 'f-spot' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 396 error_code 1 request_code 143 minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [lars at test ~]$ Can you reproduce the problem in your environments? Do the error code mean something to you? Any ideas? Any help is appreciated. -Lars From wtogami at redhat.com Mon Jul 21 20:34:18 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 21 Jul 2008 16:34:18 -0400 Subject: Prototype: RHEL5 Server for LTSP5 Message-ID: <4884F2CA.9030906@redhat.com> I got a basic thin client to work on a RHEL5 server. Here are some basic notes and instructions so people can give it a try. https://fedorahosted.org/k12linux/wiki/RHEL5Server The permanent RHEL5 instructions will be here when I (or someone else?) gets around to writing it. Current Limitations =================== 1) The client chroot is Fedora 9. Too many changes are necessary to make RHEL5 work as a client. 2) ltsp-build-client cannot run on RHEL5 because it needs newer libraries than what are available. So I provide a pre-built Fedora 9 client chroot in a 155MB tarball. See instructions below. 3) ltspfs (local storage devices) is broken. 4) Sound doesn't work. #3 and #4 might be something simple, but I currently cannot prioritize looking at it. Let the list know if you REALLY need this. Install Instructions ==================== 1) Install ltsp-server http://togami.com/~k12linux-temporary/rhel/5/ Yum repos. All you really need is ltsp-server on your RHEL5 server, and it will pull in everything else it needs as deps. 2) Configure the server exactly as described in https://fedorahosted.org/k12linux/wiki/InstallGuide with one exception. Instead of ltsp-build-client, you must untar the client chroot. I provide the client chroot here: http://people.redhat.com/wtogami/temp/fedora9-ltsp-chroot-20080721.tar.bz2 cd /opt/ltsp tar xfvj FILENAME.tar.bz2 ltsp-update-sshkeys ltsp-update-kernels That's all! Let me know if this works for you, or if you have any patches to improve the broken parts. Warren Togami wtogami at redhat.com From henryhartley at westat.com Mon Jul 21 20:49:41 2008 From: henryhartley at westat.com (Henry Hartley) Date: Mon, 21 Jul 2008 16:49:41 -0400 Subject: Prototype: RHEL5 Server for LTSP5 In-Reply-To: <4884F2CA.9030906@redhat.com> Message-ID: <403593359CA56C4CAE1F8F4F00DCFE7D07E209AC@MAILBE2.westat.com> On Monday, July 21, 2008 4:34 PM, Warren Togami wrote: >> >> I got a basic thin client to work on a RHEL5 server. Here are some >> basic notes and instructions so people can give it a try. >> >> https://fedorahosted.org/k12linux/wiki/RHEL5Server >> >> The permanent RHEL5 instructions will be here when I (or someone >> else?) gets around to writing it. Sorry to be a pest but that link gives me a "Page RHEL5Server not found". Or do I just need to wait? -- Henry From wtogami at redhat.com Tue Jul 22 18:42:17 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 22 Jul 2008 14:42:17 -0400 Subject: Prototype: RHEL5 Server for LTSP5 In-Reply-To: <4884F2CA.9030906@redhat.com> References: <4884F2CA.9030906@redhat.com> Message-ID: <48862A09.9080502@redhat.com> Warren Togami wrote: > https://fedorahosted.org/k12linux/wiki/RHEL5Server I put the instructions and expanded on it at the URL above. Warren From weba at ancollege.org Wed Jul 23 04:14:34 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Wed, 23 Jul 2008 09:44:34 +0530 Subject: This workstation is not authorized to connect to the server PROBLEM Message-ID: <32a1284d0807222114q27b5bfd0mb7e9bd738d5f66b4@mail.gmail.com> the ldm login prompt shows the following message This workstation is not authorized to connect to the server there exist many explainations to it 1. http://www.mail-archive.com/ubuntu-bugs at lists.ubuntu.com/msg504534.html 2 . https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/151386 3. https://wiki.edubuntu.org/DebugThinClientLogin can anyone clearly explain it for final and suggest the solution -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Sat Jul 26 07:41:04 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 26 Jul 2008 03:41:04 -0400 Subject: Day 1: LTSP Hackfest Portland 2008 Message-ID: <488AD510.4060502@redhat.com> http://wtogami.livejournal.com/26811.html I wrote up a summary of what happened today at day one of the Hackfest in Portland. We got a large amount done, with two days of of Hackfest. Check out the links to the more detailed notes and theoretical local apps implementation. Warren Togami wtogami at redhat.com From weba at ancollege.org Sat Jul 26 21:01:23 2008 From: weba at ancollege.org (nilakhya chatterjee) Date: Sun, 27 Jul 2008 02:31:23 +0530 Subject: Day 1: LTSP Hackfest Portland 2008 In-Reply-To: <488AD510.4060502@redhat.com> References: <488AD510.4060502@redhat.com> Message-ID: <32a1284d0807261401v30524d74mdc0a62a556a5cc23@mail.gmail.com> its good 2 read through the " ldm " improvements .....waiting for tomorrows .....posts apart from that i have realised that only few helper scripts for ltsp-server-initialize function now, and many have already been removed from the /usr/share/ltsp/script.d directory also the nfs auto-configuration through ltsp-server-initialise script / manual configuration adds /opt/ltsp *(ro, root_squash) which is not so secure ....... rather changing it to /opt/ltsp 172.31.100.0/255.255.255.0 (ro,root_squash) ....... and please also bring ltsp-server-initialize thoughts of mine in the hackfest ....... wish you all another great day !!! On 7/26/08, Warren Togami wrote: > > http://wtogami.livejournal.com/26811.html > I wrote up a summary of what happened today at day one of the Hackfest > in Portland. We got a large amount done, with two days of of Hackfest. > Check out the links to the more detailed notes and theoretical local > apps implementation. > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Sun Jul 27 20:50:00 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 27 Jul 2008 16:50:00 -0400 Subject: Get Compiz Fallback Patch from Ubuntu Message-ID: <488CDF78.3030101@redhat.com> Dear Warren, http://packages.ubuntu.com/hardy/compiz-core Note to self. Get the compiz detection patch from Ubuntu so clients that login without GL support with compiz enabled will fallback instead of failing entirely. Warren Togami wtogami at redhat.com From andrae.findlator at gmail.com Tue Jul 29 15:34:01 2008 From: andrae.findlator at gmail.com (Andrae Findlator) Date: Tue, 29 Jul 2008 10:34:01 -0500 Subject: Wireless and blue tooth Message-ID: I have not been able to get my wireless adapter or blue tooth to work. Does any one have wireless or blue tooth working on fedora? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Tue Jul 29 21:56:09 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 29 Jul 2008 17:56:09 -0400 Subject: Wireless and blue tooth In-Reply-To: References: Message-ID: <488F91F9.20209@redhat.com> Andrae Findlator wrote: > > > I have not been able to get my wireless adapter or blue tooth to work. > Does any one have wireless or blue tooth working on fedora? Is this LTSP related? You might get better luck asking on a Fedora list, or http://fedoraforum.org/ is pretty good for end-user support. Lots of people have working wireless and bluetooth out of the box in Fedora. You should talk to fedoraforum.org to get help in debugging your issues. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Jul 29 23:39:19 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 29 Jul 2008 19:39:19 -0400 Subject: Full Report: LTSP Hackfest Portland 2008 Message-ID: <488FAA27.7040306@redhat.com> http://wtogami.livejournal.com/27023.html Please read details about what happened at the Hackfest event in Portland. Big changes coming soon, and plans for further improvements were formed. Warren Togami wtogami at redhat.com From robark at gmail.com Wed Jul 30 02:41:49 2008 From: robark at gmail.com (Robert Arkiletian) Date: Tue, 29 Jul 2008 19:41:49 -0700 Subject: Full Report: LTSP Hackfest Portland 2008 In-Reply-To: <488FAA27.7040306@redhat.com> References: <488FAA27.7040306@redhat.com> Message-ID: On Tue, Jul 29, 2008 at 4:39 PM, Warren Togami wrote: > http://wtogami.livejournal.com/27023.html > Please read details about what happened at the Hackfest event in Portland. "xrexecd exits immediately on Fedora because it is unable to connect to the X server due to some Xauthority permission problems. Scott and Warren began a little debugging and found some some differences in Fedora with stricter permissions. More work is required on xrexecd to properly handle XAUTHORITY access in both X forwarded and non-forwarded modes of operation. Warren hopes to get this working in the next week or two. It is very exciting for us LTSP hackers to have this soon working since this has been the most desired feature for years." Not sure but I might be able to help with this. Fl-tt uses a trick I learned from one of Eric's former co-workers (Shahms King). It basically discovers the pid of the display manager then it yanks out the location of the mit magic cookie from the process in proc and uses it to launch a program as that user with su on his/her display by setting the display and xauth with env. Robert Arkiletian Eric Hamber Secondary, Vancouver, Canada Fl_TeacherTool http://www3.telus.net/public/robark/Fl_TeacherTool/ C++ GUI tutorial http://www3.telus.net/public/robark/