From wtogami at redhat.com Mon Jun 2 02:46:10 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 Jun 2008 22:46:10 -0400 Subject: LDM ' changing the default session' In-Reply-To: <000001c8c31e$706a29a0$5a02a8c0@kim> References: <000001c8c31e$706a29a0$5a02a8c0@kim> Message-ID: <48435EF2.3030309@redhat.com> You can configure the default desktop in exactly the same way that you can configure it for a normal Fedora desktop. /etc/sysconfig/desktop http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/Reference_Guide/s2-sysconfig-desktop.html The DESKTOP= option should allow you to set this. Please try this because I don't have the ability to test it where I am. Let us know. Warren Andrew Osborne wrote: > > > I have installed Fedora 9/LTSP 5 with no problems (except using a > terminal with printer connected), and must congratulate all involved for > the best K12 yet. > > > > Is it possible to change the default from Gnome to KDE or something > else, may be in xsession? > > > > I?m aware that work is been done on LDM but is there a workaround for > the moment? > > > > > > Thanks in advance > > > > Andrew Osborne From wtogami at redhat.com Mon Jun 2 09:20:03 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Jun 2008 05:20:03 -0400 Subject: LDM ' changing the default session' In-Reply-To: <6befb72f0806020156sa976f04u33f32be6bf7f0d3e@mail.gmail.com> References: <000001c8c31e$706a29a0$5a02a8c0@kim> <48435EF2.3030309@redhat.com> <6befb72f0806020156sa976f04u33f32be6bf7f0d3e@mail.gmail.com> Message-ID: <4843BB43.6090102@redhat.com> Andrew Osborne wrote: > I have installed Fedora 9/LTSP 5 with no problems (except using > a terminal with printer connected), and must congratulate all > involved for the best K12 yet. > > > Is it possible to change the default from Gnome to KDE or > something else, may be in xsession? > > > I'm aware that work is been done on LDM but is there a > workaround for the moment? What you quoted talked about the DISPLAYMANAGER option. This option is only relevant to the prefdm script which is run at the very end of system boot after your services have started. prefdm on a normal Fedora system (and your LTSP server) runs gdm by default. Within your /opt/ltsp/i386 chroot /etc/sysconfig/desktop should contain DISPLAYMANAGER=DISPLAYMANAGER=/usr/sbin/ltsp-client-launch which launches the ldm. If you do not manually choose a session, LDM runs the /etc/X11/xinit/Xsession script without parameters. That script runs through a bunch of other scripts to decide what exactly to run. /etc/X11/xinit/Xclients contains the part that handles the DESKTOP option. This appears to be the way to set an alternate default session type. Warren Togami wtogami at redhat.com From amposborne at googlemail.com Mon Jun 2 09:02:35 2008 From: amposborne at googlemail.com (Andrew Osborne) Date: Mon, 2 Jun 2008 10:02:35 +0100 Subject: LDM ' changing the default session' Message-ID: <6befb72f0806020202w15ad620fvcd9c570d7d47d091@mail.gmail.com> Many thanks Warren to the speedy reply. I found this after Googling around:- I have installed KDE and this works. ____________________________________________________________________ In Fedora 9 there appears to be no GUI-based way of configuring this (e.g., via 'System Settings'). Nevertheless, it is pretty easy. You do need to become root to do it (e.g., 'sudo su'). The script: /etc/X11/prefdm is run at startup time; it looks for /etc/sysconfig/desktop and if it exists, 'sources' it. It then checks to see if the DISPLAYMANAGER variable is set and, if so, uses its value to try to determine which display manager to use (expecting it to be one of: GNOME, KDE, WDM, XDM). If this variable is not set, it tries to execute, in this order: gdm kdm wdm xdm So the first of these that runs successfully is the one that will be used, if the DISPLAYMANAGER variable is not set. On my system /etc/sysconfig/desktop did not exist, so prefdm was executing gdm. The solution, of course, is to create /etc/sysconfig/desktop and simply put this line in it: DISPLAYMANAGER=KDE If the file exists, of course, just make sure DISPLAYMANAGER is set as above. (Reference: http://mail.gnome.org/archives/garnome-list/2002-September/msg00028.html ________________________________________________________________________ In my case this does not work as I am using Win4Lin VDS to dish out 2000/XP desktops to a school system, I have installed the configuration with Fedora 8/LTSP 4.2 and Win4Lin VDS, in LDM i've been able to set the default session. I am at a lost to how I could set LDM to default to Win4Lin in Fedora9/LTSP5/Win4Lin VDS? the xsession for Win4Lin is mergepro.xsessions. Any help would be very appreciated. Thanks in advance Andrew Osborne -------------- next part -------------- An HTML attachment was scrubbed... URL: From amposborne at googlemail.com Mon Jun 2 10:58:31 2008 From: amposborne at googlemail.com (Andrew Osborne) Date: Mon, 2 Jun 2008 11:58:31 +0100 Subject: LDM ' changing the default session' In-Reply-To: <4843BB43.6090102@redhat.com> References: <000001c8c31e$706a29a0$5a02a8c0@kim> <48435EF2.3030309@redhat.com> <6befb72f0806020156sa976f04u33f32be6bf7f0d3e@mail.gmail.com> <4843BB43.6090102@redhat.com> Message-ID: <6befb72f0806020358m2a3a5112k88dda405584e6112@mail.gmail.com> Many thanks Warren, My knowledge of scripting is about 10% If you can help it would be very appreciated. I've found the xsession file I need to load. it is /opt/win4lin/bin/mergepro.xsession how could I load mergepro.xsession as the default? Thanks in advance Andrew. Here is the *xclients* file GSESSION="$(which gnome-session 2>/dev/null)" STARTKDE="$(which startkde 2>/dev/null)" # check to see if the user has a preferred desktop PREFERRED= if [ -f /etc/sysconfig/desktop ]; then . /etc/sysconfig/desktop if [ "$DESKTOP" = "GNOME" ]; then PREFERRED="$GSESSION" elif [ "$DESKTOP" = "KDE" ]; then PREFERRED="$STARTKDE" fi fi if [ -n "$PREFERRED" ]; then exec "$PREFERRED" fi # now if we can reach here, either no desktop file was present, # or the desktop requested is not installed. if [ -n "$GSESSION" ]; then # by default, we run GNOME. exec "$GSESSION" elif [ -n "$STARTKDE" ]; then # if GNOME isn't installed, try KDE. exec "$STARTKDE" fi # Failsafe. # these files are left sitting around by TheNextLevel. rm -f $HOME/Xrootenv.0 # Argh! Nothing good is installed. Fall back to twm { # gosh, neither fvwm95 nor fvwm2 is available; # fall back to failsafe settings [ -x /usr/bin/xsetroot ] && /usr/bin/xsetroot -solid '#222E45' if [ -x /usr/bin/xclock ] ; then /usr/bin/xclock -geometry 100x100-5+5 & elif [ -x /usr/bin/xclock ] ; then /usr/bin/xclock -geometry 100x100-5+5 & fi if [ -x /usr/bin/xterm ] ; then /usr/bin/xterm -geometry 80x50-50+150 & fi if [ -x /usr/bin/firefox -a -f /usr/share/doc/HTML/index.html ]; then /usr/bin/firefox /usr/share/doc/HTML/index.html & fi if [ -x /usr/bin/twm ] ; then exec /usr/bin/twm fi } -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Tue Jun 3 03:17:05 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Jun 2008 23:17:05 -0400 Subject: lts.conf In-Reply-To: References: <4834721D.8010301@redhat.com> <483475E6.9020801@redhat.com> Message-ID: <4844B7B1.3040108@redhat.com> Andrae Findlator wrote: > What happened to the lts.conf, it's blank. The /opt/ltsp/i386 chroot contains a blank lts.conf. The client grabs lts.conf from the tftp server during bootup. On F-9 the lts.conf is located at /var/lib/tftpboot/ltsp/i386/lts.conf Warren Togami wtogami at redhat.com From andrae.findlator at gmail.com Wed Jun 4 19:45:39 2008 From: andrae.findlator at gmail.com (Andrae Findlator) Date: Wed, 4 Jun 2008 14:45:39 -0500 Subject: LTSP 5 In-Reply-To: References: Message-ID: I am using fedora 9 with the LTSP 5 packages. A number of things are different in this outfit. Right now my issues are with Local printers and screen resolutions. How do I limit the client's screen resolution to 1024x768? Right now it seems to take the maximum resolution of the monitor. Also [00:E0:4C:AC:00:26] PRINTER_0_DEVICE=/dev/usblp0 The lts.conf options above should enable local printing on port 9100. Is there something else that needs to be done to enable local printing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Wed Jun 4 20:35:42 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 04 Jun 2008 16:35:42 -0400 Subject: LTSP 5 In-Reply-To: References: Message-ID: <4846FC9E.4010700@redhat.com> Andrae Findlator wrote: > > How do I limit the client's screen resolution to 1024x768? Right now it > seems to take the maximum resolution of the monitor. This is a current limitation of the way Fedora 9 configures X. We have no way of saying "Use X autoconfiguration except for the resolution." Your options are either: 1) Use xrandr after X started to change the resolution. 2) Drop an xorg.conf into your chroot at /etc/X11/xorg.conf. This however only works if all your clients have the same video card and desired resolution. I'm working on a long term solution to this problem. > > Also > > [00:E0:4C:AC:00:26] > PRINTER_0_DEVICE=/dev/usblp0 > > The lts.conf options above should enable local printing on port 9100. Is > there something else that needs to be done to enable local printing? Nice catch... it seems that we are not installing the jetpipe script into the client chroot. I'm fixing this for the next package version. Until then you could drop the script into /opt/ltsp/i386/usr/sbin and see if it works? Warren Togami wtogami at redhat.com From eharrison at mesd.k12.or.us Wed Jun 4 21:03:18 2008 From: eharrison at mesd.k12.or.us (Eric Harrison) Date: Wed, 4 Jun 2008 14:03:18 -0700 Subject: LTSP 5 In-Reply-To: <4846FC9E.4010700@redhat.com> References: <4846FC9E.4010700@redhat.com> Message-ID: <9e29091b0806041403p419ed80cm51f5caefc2a0f87b@mail.gmail.com> On Wed, Jun 4, 2008 at 1:35 PM, Warren Togami wrote: > Andrae Findlator wrote: >> >> How do I limit the client's screen resolution to 1024x768? Right now it >> seems to take the maximum resolution of the monitor. > > This is a current limitation of the way Fedora 9 configures X. We have no > way of saying "Use X autoconfiguration except for the resolution." > > Your options are either: > 1) Use xrandr after X started to change the resolution. > 2) Drop an xorg.conf into your chroot at /etc/X11/xorg.conf. This however > only works if all your clients have the same video card and desired > resolution. > > I'm working on a long term solution to this problem. If you do not want to (or cannot) use a hard-coded xorg.conf for all terminals, you can create a xorg.conf file and tell specific terminals to use it. For example, if you saved the xorg.conf file as /opt/ltsp/i386/etc/X11/xorg-1024x768.conf, you can add this to your lts.conf to tell only one terminal to use that config file: [00:E0:4C:AC:00:26] X_CONF=/etc/X11/xorg-1024x768.conf (where "00:E0:4C...." is the Mac address of the terminal) -Eric From dbond at nrggos.com.au Wed Jun 4 21:24:44 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Thu, 5 Jun 2008 07:24:44 +1000 Subject: LTSP 5 In-Reply-To: <4846FC9E.4010700@redhat.com> References: <4846FC9E.4010700@redhat.com> Message-ID: <4847081C.3070000@nrggos.com.au> Being able to set the screen resolution is a pretty big deal to me. Can I help? xrandr would seem to be the best solution as it does not allow resolutions that the card/monitor are unable to display so you can't end up with a non-working configuration. This is something that happens to me on occasions. Regards Darryl Bond Warren Togami wrote: > Andrae Findlator wrote: > >> How do I limit the client's screen resolution to 1024x768? Right now it >> seems to take the maximum resolution of the monitor. >> > > This is a current limitation of the way Fedora 9 configures X. We have > no way of saying "Use X autoconfiguration except for the resolution." > > Your options are either: > 1) Use xrandr after X started to change the resolution. > 2) Drop an xorg.conf into your chroot at /etc/X11/xorg.conf. This > however only works if all your clients have the same video card and > desired resolution. > > I'm working on a long term solution to this problem. > > >> Also >> >> [00:E0:4C:AC:00:26] >> PRINTER_0_DEVICE=/dev/usblp0 >> >> The lts.conf options above should enable local printing on port 9100. Is >> there something else that needs to be done to enable local printing? >> > > Nice catch... it seems that we are not installing the jetpipe script > into the client chroot. I'm fixing this for the next package version. > > Until then you could drop the script into /opt/ltsp/i386/usr/sbin and > see if it works? > > 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 Jun 5 04:09:16 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 05 Jun 2008 00:09:16 -0400 Subject: LTSP 5 In-Reply-To: <4847081C.3070000@nrggos.com.au> References: <4846FC9E.4010700@redhat.com> <4847081C.3070000@nrggos.com.au> Message-ID: <484766EC.8070601@redhat.com> Darryl Bond wrote: > Being able to set the screen resolution is a pretty big deal to me. > Can I help? > > xrandr would seem to be the best solution as it does not allow > resolutions that the card/monitor are unable to display so you can't end > up with a non-working configuration. This is something that happens to > me on occasions. > > Regards > Darryl Bond Are you sure? xrandr (the command line tool) can switch the resolution to something that doesn't work. GNOME's "Monitor Resolution Settings" capplet gives you the option to verify the resolution and goes back if you fail to click it within the timeout. The way this works it may not be a good idea to rely on xrandr, unless somebody has a particularly good idea. Warren Togami wtogami at redhat.com From dbond at nrggos.com.au Thu Jun 5 05:35:57 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Thu, 5 Jun 2008 15:35:57 +1000 Subject: LTSP 5 In-Reply-To: <484766EC.8070601@redhat.com> References: <4846FC9E.4010700@redhat.com> <4847081C.3070000@nrggos.com.au> <484766EC.8070601@redhat.com> Message-ID: <48477B3D.5030501@nrggos.com.au> I haven't tried it exhaustively but xrandr displays a list of resolutions that look reasonably valid. It can't be any worse than putting X_MODE_0 = 1234x765 Screen 0: minimum 640 x 400, current 1680 x 1050, maximum 1680 x 1050 default connected 1680x1050+0+0 0mm x 0mm 1680x1050 60.0* 1600x1024 60.0 1400x1050 60.0 1280x1024 75.0 60.0 1440x900 60.0 1280x960 60.0 1360x768 60.0 1152x864 75.0 70.0 60.0 1024x768 75.0 60.0 70.0 832x624 75.0 800x600 75.0 60.0 72.0 56.0 640x480 75.0 60.0 73.0 720x400 70.0 Darryl Warren Togami wrote: > Darryl Bond wrote: > >> Being able to set the screen resolution is a pretty big deal to me. >> Can I help? >> >> xrandr would seem to be the best solution as it does not allow >> resolutions that the card/monitor are unable to display so you can't end >> up with a non-working configuration. This is something that happens to >> me on occasions. >> >> Regards >> Darryl Bond >> > > Are you sure? > > xrandr (the command line tool) can switch the resolution to something > that doesn't work. > > GNOME's "Monitor Resolution Settings" capplet gives you the option to > verify the resolution and goes back if you fail to click it within the > timeout. > > The way this works it may not be a good idea to rely on xrandr, unless > somebody has a particularly good idea. > > 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 andrae.findlator at gmail.com Thu Jun 5 20:22:54 2008 From: andrae.findlator at gmail.com (Andrae Findlator) Date: Thu, 5 Jun 2008 15:22:54 -0500 Subject: K12Linux-devel-list Digest, Vol 4, Issue 3 In-Reply-To: <20080605160036.4313B619D75@hormel.redhat.com> References: <20080605160036.4313B619D75@hormel.redhat.com> Message-ID: Problem solved. I changed the rdesktop script in screen.d and added this line (commenting out the original) /usr/bin/xinit /opt/ltsp/i386/usr/bin/rdesktop.1024x768 This is the contents of /opt/ltsp/i386/usr/bin/rdesktop.1024x768 /usr/bin/xrandr -s 1024x768; /usr/bin/rdesktop 192.168.0.13 -f -u "" -d domain; So I guess xrandr might be the solution going forward. We could use -q to check for the possible resolutions and use -s to set the one to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrae.findlator at gmail.com Thu Jun 5 20:23:34 2008 From: andrae.findlator at gmail.com (Andrae Findlator) Date: Thu, 5 Jun 2008 15:23:34 -0500 Subject: K12Linux-devel-list Digest, Vol 4, Issue 3 In-Reply-To: References: <20080605160036.4313B619D75@hormel.redhat.com> Message-ID: Where do I find the jetpipe script -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Fri Jun 6 20:58:47 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 06 Jun 2008 16:58:47 -0400 Subject: Logo for K12Linux In-Reply-To: <8215CF8A27315F4A8F1A4A8DD65813643C96D3@wsc-mail-01.nwresd.k12.or.us> References: <8215CF8A27315F4A8F1A4A8DD65813643C96D3@wsc-mail-01.nwresd.k12.or.us> Message-ID: <4849A507.9020904@redhat.com> Paul Nelson wrote: > Hello Folks, > > I created a logo for https://fedorahosted.org/k12linux/ Here are links to png and xcf versions. > > http://k12ltsp.org/mediawiki/images/a/ad/K12linux_logo.png > http://pnelson.us/k12linux_logo.xcf > > I installed FC9 and LTSP and now have clients booting. I'm working on a simple walkthrough for th eK12LTSP wiki site but the documentation on fedorahosted.org/k12linux was enough to get me going. > https://fedorahosted.org/k12linux/ The logo is a little too big, but given the lack of anybody else doing anything we'll use it for now and consider it a "temporary" logo. Warren From wtogami at redhat.com Fri Jun 6 21:34:45 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 06 Jun 2008 17:34:45 -0400 Subject: ltsp-5.1.9 for testing Message-ID: <4849AD75.7080109@redhat.com> http://togami.com/~k12linux-temporary/ I just uploaded a build of ltsp-5.1.9 for both F-8 and F-9 in the k12linux-temporary repo. Please upgrade ltps-server on your server and ltsp-client in your chroot. Changes since F-9 release: - jetpipe script was missing from ltsp-client This should allow local printers to work if configured in lts.conf. - Fix NBD swap - Fix grabbing of lts.conf, it happens from the rootfs server now These are extremely minor changes. If this 5.1.9 seems good then I will push it to Fedora 9 updates soon. Warren Togami wtogami at redhat.com From eharrison at mesd.k12.or.us Sat Jun 7 03:41:04 2008 From: eharrison at mesd.k12.or.us (Eric Harrison) Date: Fri, 6 Jun 2008 20:41:04 -0700 Subject: ltsp-5.1.9 for testing In-Reply-To: <4849AD75.7080109@redhat.com> References: <4849AD75.7080109@redhat.com> Message-ID: <9e29091b0806062041r2313186cu2763cd6400beedbd@mail.gmail.com> On Fri, Jun 6, 2008 at 2:34 PM, Warren Togami wrote: > http://togami.com/~k12linux-temporary/ > I just uploaded a build of ltsp-5.1.9 for both F-8 and F-9 in the > k12linux-temporary repo. Please upgrade ltps-server on your server and > ltsp-client in your chroot. > > Changes since F-9 release: > - jetpipe script was missing from ltsp-client > This should allow local printers to work if configured in lts.conf. > - Fix NBD swap > - Fix grabbing of lts.conf, it happens from the rootfs server now > > These are extremely minor changes. If this 5.1.9 seems good then I will > push it to Fedora 9 updates soon. > > Warren Togami > wtogami at redhat.com > Hey Warren! I have had a few people ask me about adding back in the caching name server config. Attached are patches to do so. This is pretty simple, it is just a copy of /etc/named.conf (/etc/ltsp/named.conf) that listens on the ethernet ports & a copy of /etc/init.d/named (/etc/init.d/ltsp-named) that uses the modified config file. Nothing fancy. I would just push this, but best practices these days is to restrict access to recursive name servers. We firewall this off by default, so this is *probably* ok, but I could also be talked into adding an allow-query acl. What do you think? -Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: ltsp.diff Type: text/x-patch Size: 15768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ltsp.spec.diff Type: text/x-patch Size: 1588 bytes Desc: not available URL: From PNelson at nwresd.k12.or.us Sat Jun 7 14:37:01 2008 From: PNelson at nwresd.k12.or.us (Paul Nelson) Date: Sat, 7 Jun 2008 07:37:01 -0700 Subject: Logo for K12Linux References: <20080607034136.9AE356191B8@hormel.redhat.com> Message-ID: <8215CF8A27315F4A8F1A4A8DD65813643C971E@wsc-mail-01.nwresd.k12.or.us> Paul Nelson wrote: > Hello Folks, > > I created a logo for https://fedorahosted.org/k12linux/ Here are links to png and xcf versions. > > http://k12ltsp.org/mediawiki/images/a/ad/K12linux_logo.png > http://pnelson.us/k12linux_logo.xcf > > I installed FC9 and LTSP and now have clients booting. I'm working on a simple walkthrough for th eK12LTSP wiki site but the documentation on fedorahosted.org/k12linux was enough to get me going. > https://fedorahosted.org/k12linux/ The logo is a little too big, but given the lack of anybody else doing anything we'll use it for now and consider it a "temporary" logo. Warren OK, here's a smaller version: http://k12ltsp.org/mediawiki/images/f/ff/K12linux_logo_200.png Using the xcf file you can edit and resize at will: http://pnelson.us/k12linux_logo.xcf I also created a nicer LDM theme: http://dinghy.homelinux.org/ldm-ltsp-theme.gz ;-) Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2950 bytes Desc: not available URL: From nadavkav at gmail.com Fri Jun 6 07:15:09 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Fri, 6 Jun 2008 10:15:09 +0300 Subject: PulseAudio Client with ESD Server In-Reply-To: <4219988b0806031342h707b4357w559926a7bf49700f@mail.gmail.com> References: <4219988b0806031342h707b4357w559926a7bf49700f@mail.gmail.com> Message-ID: <4219988b0806060015p31e58de1k800c17d9e0fb6fcb@mail.gmail.com> Hi List :-) i hope this not old news to you all but i just figured out how to play sound with ALSA's PulseAudio Client/plugin and redirect it to ESD server on any Student's machine :-) i have fedora 8 installed (i have upgraded from k12ltsp fc6 with yum) with PulseAudio 0.9.10. (btw, it took some time for me to fix it to work and now that it works great) i was looking for a way to have it send audio to the esd servers on the student's computers. without the need to install PA servers on the student's machines and to have to compile new client environment with the ltsp-client-kit. i can control to volume with PA gui (which i could not with esd client) and i can use more applications that send audio to ALSA - which now send it over the net to esd servers. if you have PA setup already, i guess you have to issue : "pactl load-module module-esound-sink sink_name=student server=ws252:16001" and the set default sink to "student" from padevchooser UI and now... any thing that plays is redirected to the ws252 machine :-) if any of you needs more PA config files i'll post them here. i hope it helps ! nadav :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Tue Jun 10 17:37:26 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 10 Jun 2008 13:37:26 -0400 Subject: Warren in meeting June 15th Message-ID: <484EBBD6.6010408@redhat.com> Hey folks, I'm back from travelling now. This upcoming Sunday, June 15th at 10:30 eastern (1430 UTC) I will be back for the weekly meeting. https://fedorahosted.org/k12linux/wiki/Meetings Stuff for next meeting: * lts.conf options that we currently don't support because we rely on X autoconfiguration instead of configure-x.sh. * screen resolution (Our X developers suggest that users who need a resolution other than default to use a custom xorg.conf file.) * keyboard layout (code exists to fix it in the rhpl library. We need to either use it or copy it) I might consider making configure-x.sh optional but: - it might make things confusing because of inconsistent behavior. - it needs changes to work without Debian stuff. * What else do we need to fix to make K12Linux production ready? If you have thoughts about this now, please do write your ideas in this thread. Warren Togami wtogami at redhat.com From dbond at nrggos.com.au Wed Jun 11 21:37:45 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Thu, 12 Jun 2008 07:37:45 +1000 Subject: Warren in meeting June 15th In-Reply-To: <484EBBD6.6010408@redhat.com> References: <484EBBD6.6010408@redhat.com> Message-ID: <485045A9.9050708@nrggos.com.au> Making a custom xorg.conf for each chipset/resolution in a large environment is painful. I already have 15 or so different xorg.conf for dual screens, maintaining lots more would be a major hassle. I could live with it if the Driver in the Device section did not have to be explicitly set, ie autoprobe the driver like no xorg.conf does. Then I could share the same Xorg.conf for each resolution. Regards Darryl Warren Togami wrote: > Stuff for next meeting: > * lts.conf options that we currently don't support because we rely on X > autoconfiguration instead of configure-x.sh. > * screen resolution (Our X developers suggest that users who need a > resolution other than default to use a custom xorg.conf file.) > * keyboard layout (code exists to fix it in the rhpl library. We need > to either use it or copy it) > > I might consider making configure-x.sh optional but: > - it might make things confusing because of inconsistent behavior. > - it needs changes to work without Debian stuff. > > * What else do we need to fix to make K12Linux production ready? > > If you have thoughts about this now, please do write your ideas in this > thread. > > Warren Togami > wtogami at redhat.com > > 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 rogdepre at skynet.be Thu Jun 12 09:30:47 2008 From: rogdepre at skynet.be (RDP) Date: Thu, 12 Jun 2008 11:30:47 +0200 Subject: Warren in meeting June 15th In-Reply-To: <485045A9.9050708@nrggos.com.au> References: <484EBBD6.6010408@redhat.com> <485045A9.9050708@nrggos.com.au> Message-ID: <4850ECC7.9090806@skynet.be> Consistency ends where real live begins. Autoconfigure is a big step forward to make the X server more intelligent and works out of the box in many cases. Autodetecting dual screen graphic cards and configuring them accordingly, is still not part of this intelligence, I'm afraid. My example is another case, that will remain an exception for some time, I guess. OLPC Clients using the "AMD Geode LX" chipset. Autoconfigure defaults to a resolution of 800x600, while I need 1280x1024 for the display. For a correct configuration Horizsync, VertRefresh as well as the modeline for 1280x1024 have to be defined. Moreover a temporarily option is required to switch off fast rendering, due to a bug in the geode driver (Option "EXANoComposite" "yes"). I have no view of what the impact of the inconsistency will be by making configure-x.sh optional, but given the above examples, is there a way to avoid it,while keeping the other clients autoconfigured? K12linux production ready: I'm running a test setup for 3 weeks now and haven't come across any issues that can be related to ltsp or K12 functionality. I did a second successful FC9 install on the same machine/different drive 4days ago. Installing ltsp is as simple as: yum install -y ltsp*. The rest of the configuration could be done by a simple script. Today I will do another install on a different hardware. I also need to get the sound working on the clients, which i consider a configuration issue rather then a ltsp issue. So, from my personal experience, I cannot think of any other issues apart from the X config one. Regards Roger Darryl Bond wrote: > Making a custom xorg.conf for each chipset/resolution in a large > environment is painful. > I already have 15 or so different xorg.conf for dual screens, > maintaining lots more would be a major hassle. > > I could live with it if the Driver in the Device section did not have to > be explicitly set, ie autoprobe the driver like no xorg.conf does. > Then I could share the same Xorg.conf for each resolution. > > Regards > Darryl > > > > > Warren Togami wrote: >> Stuff for next meeting: >> * lts.conf options that we currently don't support because we rely on X >> autoconfiguration instead of configure-x.sh. >> * screen resolution (Our X developers suggest that users who need a >> resolution other than default to use a custom xorg.conf file.) >> * keyboard layout (code exists to fix it in the rhpl library. We need >> to either use it or copy it) >> >> I might consider making configure-x.sh optional but: >> - it might make things confusing because of inconsistent behavior. >> - it needs changes to work without Debian stuff. >> >> * What else do we need to fix to make K12Linux production ready? >> >> If you have thoughts about this now, please do write your ideas in this >> thread. >> >> Warren Togami >> wtogami at redhat.com >> >> > > 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. > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list > From dbond at nrggos.com.au Thu Jun 12 21:37:32 2008 From: dbond at nrggos.com.au (Darryl Bond) Date: Fri, 13 Jun 2008 07:37:32 +1000 Subject: Warren in meeting June 15th In-Reply-To: <4850ECC7.9090806@skynet.be> References: <484EBBD6.6010408@redhat.com> <485045A9.9050708@nrggos.com.au> <4850ECC7.9090806@skynet.be> Message-ID: <4851971C.3080609@nrggos.com.au> The business with the default resolution is as you say. My test machine has a monitor that is capable of 1280x1024 but I cannot get it to work with greater than 800x600 when I let it autoconfigure. The ltsp-vmclient is also similar. This is another issue that may be able to be fixed with xrandr. If xrandr settings were an administrative setting then users would not be able to get the videocard/monitor into an unrecoverable situation. If the administrator got it wrong then a reset of the terminal could get the new settings. Darryl RDP wrote: > Consistency ends where real live begins. > Autoconfigure is a big step forward to make the X server more > intelligent and works out of the box in many cases. > Autodetecting dual screen graphic cards and configuring them > accordingly, is still not part of this intelligence, I'm afraid. > My example is another case, that will remain an exception for some time, > I guess. > OLPC Clients using the "AMD Geode LX" chipset. > Autoconfigure defaults to a resolution of 800x600, while I need > 1280x1024 for the display. For a correct configuration Horizsync, > VertRefresh as well as the modeline for 1280x1024 have to be defined. > Moreover a temporarily option is required to switch off fast rendering, > due to a bug in the geode driver (Option "EXANoComposite" "yes"). > > I have no view of what the impact of the inconsistency will be by making > configure-x.sh optional, but given the above examples, is there a way to > avoid it,while keeping the other clients autoconfigured? > > K12linux production ready: > I'm running a test setup for 3 weeks now and haven't come across any > issues that can be related to ltsp or K12 functionality. I did a second > successful FC9 install on the same machine/different drive 4days ago. > Installing ltsp is as simple as: yum install -y ltsp*. The rest of the > configuration could be done by a simple script. > Today I will do another install on a different hardware. I also need to > get the sound working on the clients, which i consider a configuration > issue rather then a ltsp issue. > So, from my personal experience, I cannot think of any other issues > apart from the X config one. > Regards > Roger > > > Darryl Bond wrote: > >> Making a custom xorg.conf for each chipset/resolution in a large >> environment is painful. >> I already have 15 or so different xorg.conf for dual screens, >> maintaining lots more would be a major hassle. >> >> I could live with it if the Driver in the Device section did not have to >> be explicitly set, ie autoprobe the driver like no xorg.conf does. >> Then I could share the same Xorg.conf for each resolution. >> >> Regards >> Darryl >> >> >> >> >> Warren Togami wrote: >> >>> Stuff for next meeting: >>> * lts.conf options that we currently don't support because we rely on X >>> autoconfiguration instead of configure-x.sh. >>> * screen resolution (Our X developers suggest that users who need a >>> resolution other than default to use a custom xorg.conf file.) >>> * keyboard layout (code exists to fix it in the rhpl library. We need >>> to either use it or copy it) >>> >>> I might consider making configure-x.sh optional but: >>> - it might make things confusing because of inconsistent behavior. >>> - it needs changes to work without Debian stuff. >>> >>> * What else do we need to fix to make K12Linux production ready? >>> >>> If you have thoughts about this now, please do write your ideas in this >>> thread. >>> >>> Warren Togami >>> wtogami at redhat.com >>> >>> >>> >>> 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 amposborne at googlemail.com Thu Jun 12 09:09:01 2008 From: amposborne at googlemail.com (Andrew Osborne) Date: Thu, 12 Jun 2008 10:09:01 +0100 Subject: Warren in meeting June 15th In-Reply-To: <485045A9.9050708@nrggos.com.au> References: <484EBBD6.6010408@redhat.com> <485045A9.9050708@nrggos.com.au> Message-ID: <6befb72f0806120209q320048c7laf0aff5430225e67@mail.gmail.com> The ability to set the default desktop on the terminals (LDM) to any freedesktop.org-compliant display manager. Remove the ability to shutdown the server from a terminal in gnome. K12Linux logo at first boot? Andrew Osborne 2008/6/11 Darryl Bond : > Making a custom xorg.conf for each chipset/resolution in a large > environment is painful. > I already have 15 or so different xorg.conf for dual screens, > maintaining lots more would be a major hassle. > > I could live with it if the Driver in the Device section did not have to > be explicitly set, ie autoprobe the driver like no xorg.conf does. > Then I could share the same Xorg.conf for each resolution. > > Regards > Darryl > > > > > Warren Togami wrote: > >> Stuff for next meeting: >> * lts.conf options that we currently don't support because we rely on X >> autoconfiguration instead of configure-x.sh. >> * screen resolution (Our X developers suggest that users who need a >> resolution other than default to use a custom xorg.conf file.) >> * keyboard layout (code exists to fix it in the rhpl library. We need >> to either use it or copy it) >> >> I might consider making configure-x.sh optional but: >> - it might make things confusing because of inconsistent behavior. >> - it needs changes to work without Debian stuff. >> >> * What else do we need to fix to make K12Linux production ready? >> >> If you have thoughts about this now, please do write your ideas in this >> thread. >> >> Warren Togami >> wtogami at redhat.com >> >> >> > 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. > > > _______________________________________________ > 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 PNelson at nwresd.k12.or.us Fri Jun 13 01:41:28 2008 From: PNelson at nwresd.k12.or.us (Paul Nelson) Date: Thu, 12 Jun 2008 18:41:28 -0700 Subject: What else do we need to fix to make K12Linux production ready References: <20080611160031.5E55261A14F@hormel.redhat.com> Message-ID: <8215CF8A27315F4A8F1A4A8DD65813643C973F@wsc-mail-01.nwresd.k12.or.us> Hello Folks, I'm excited about how easy K12Linux was to setup in FC9. I've been thinking a lot about what it needs to be complete. Network defaults ready for use in schools: K12Linux is often installed by teachers experimenting with Linux and thin-clients in their classrooms. It's important to understand these folks as customers when making decisions about how to configure K12Linux. The two network card setup worked so well because these servers could be isolated from the network and could at the same time, create a network in a classroom or lab. Out of the box they had DNS, DHCPD and NAT working so the K12linux box would act as a gateway to the rest of the network and at the same time, create a rational, usable network inside the school or classroom (usable for other PCs too). I think it's important that the kind of scripting that Eric did in earlier releases finds its way into K12Linux for Fedora 9 as well. We also need to be sure we have answers for questions like: * Schools love to put their own graphics up on the welcome screens. We just need to make sure that the documentation is clear on stuff like that. * I want to have two servers, how do I do that and only have one /home and one authentication server? * I want to change the default settings for browsers to be sure they go through our Internet filter and I don't want the kids to change the settings * I want an easy way to reset a single user's settings and another script to do all user settings. * I want to have schooltool working so users can see my desktop and I can see theirs. Is there a way I can automatically put the link to something like that on every user's desktop? * I want to set defaults for things like Adobe PDF, Flash, OO default file saving format, and we want a common set of bookmarks * Kids need a shared folder space where they can put files and collaborate * We need an easy way to install the non-standard applications like Adobe Reader, Flash, java, etc.. * What about other cool education applications and stuff like Kedu? * and the #1 question ( I kid you not...) What typing programs are there for Linux? Harder issues: * How do I add a video driver for my xyz card that is supported in Xorg but isn't included in the default K12Linux install? * What are those scripts that you have to run to change the settings sometimes when installing K12Kinux or after making network changes? * Since these servers are used in schools, do we also install Moodle? I'm not trying to overwhelm you, it's just that these are the day-to-day issues that need to be addressed when using Linux in schools. Trust me, I know. There are other little things that will get you too, like xsane can go haywire and start filling a user's home folder with xsession errors, errors that include high-res image data. And then what happens when /home quietly fills up? That was a fun one. So you need apps like durep that will help admins quickly see who's using up disk space. If you can address all of the above then five years after moving to Linux on the desktop, you'll ask your teachers if they want to change back to Windows and you'll get the same answer I got, a resounding, 100% NO! Stay with Linux! We like it. ;-) Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4478 bytes Desc: not available URL: From wtogami at redhat.com Fri Jun 13 03:16:02 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 12 Jun 2008 23:16:02 -0400 Subject: Warren in meeting June 15th In-Reply-To: <6befb72f0806120209q320048c7laf0aff5430225e67@mail.gmail.com> References: <484EBBD6.6010408@redhat.com> <485045A9.9050708@nrggos.com.au> <6befb72f0806120209q320048c7laf0aff5430225e67@mail.gmail.com> Message-ID: <4851E672.5010902@redhat.com> Andrew Osborne wrote: > The ability to set the default desktop on the terminals (LDM) to any > freedesktop.org-compliant display manager. We are supposed to be able to do this with /etc/sysconfig/desktop which is supposed to work for both gdm and ldm, but I haven't found an option that will do it successfully. > > Remove the ability to shutdown the server from a terminal in gnome. https://bugzilla.redhat.com/show_bug.cgi?id=444552 This is a bug in GNOME. Thankfully it doesn't actually let the non-root user shutdown. > > K12Linux logo at first boot? first or all? I'm working with Fedora Art's Maureen Duffy on making a more attractive login screen for ldm. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Jun 13 14:39:06 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 13 Jun 2008 10:39:06 -0400 Subject: DNS In-Reply-To: <9e29091b0806062041r2313186cu2763cd6400beedbd@mail.gmail.com> References: <4849AD75.7080109@redhat.com> <9e29091b0806062041r2313186cu2763cd6400beedbd@mail.gmail.com> Message-ID: <4852868A.8020303@redhat.com> Eric Harrison wrote: > I have had a few people ask me about adding back in the caching name > server config. Attached are patches to do so. > > This is pretty simple, it is just a copy of /etc/named.conf > (/etc/ltsp/named.conf) that listens on the ethernet ports & a copy of > /etc/init.d/named (/etc/init.d/ltsp-named) that uses the modified > config file. Nothing fancy. > > I would just push this, but best practices these days is to restrict > access to recursive name servers. We firewall this off by default, so > this is *probably* ok, but I could also be talked into adding an > allow-query acl. > > What do you think? > I wonder if we're heading down a path of confusion by adding yet another ltsp-* service name. Reportedly dnsmasq with a proper config file can replace dhcpd, tftpd and named all in a single service. This at least sounds like it would be less confusing for the long-term. OTOH if we did do that, we can't migrate existing F-9 users during the release. Or do we just not have F-9 production users yet so we shouldn't worry about this? Do we keep dhcpd, tftpd and named as default? dnsmasq as default? Do we let users choose? The more completely redundant options the more confusing this gets. =( Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Jun 13 21:02:17 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 13 Jun 2008 17:02:17 -0400 Subject: RHEL5 LTSP5 backport problems Message-ID: <4852E059.7000907@redhat.com> So I'm plugging away at a RHEL5 backport of Fedora 9's LTSP5. Big problems... 1) RHEL5 (and CentOS) has a minimum of i686 kernel. There is no i586 kernel. I suppose this is a pretty big deal because i586 thin clients are still being sold new today. (AMD Geode, eBox/LTSP Term 1000, anything else?) 2) We cannot backport necessary changes to mkinitrd and push it in an official RHEL5 errata because the changes needed for thin clients are too invasive. Options? Scenario 1: Fedora in Chroot ============================ I am considering that a RHEL5 LTSP server might be better off with a Fedora client chroot in /opt/ltsp/i386. The server side would remain entirely RHEL + EPEL, while the client would be Fedora. Here is the line of reasoning... * Fedora provides the i586 kernel. * The Fedora X drivers have fewer problems on prevalent thin client hardware since they are newer and we put work into testing/fixing them with actual thin client hardware. * Since mkinitrd and kernel guarantee that you need an "unofficial" package replacing a RHEL core component in the chroot anyway, why not make the entire chroot "unofficial"? * This allows us to focus our limited LTSP R&D resources on a single OS (at least for the client). This significantly reduces the development and testing burden. * DRAWBACK: This is not a good solution because Fedora has updates for only ~13 months. Scenario 2: RHEL5 chroot ======================== * Somebody has to perpetually maintain an unofficial kernel.i586 that stays in sync with RHEL5. This cannot be a fully automatic job, and nobody wants to be stuck doing this for 5 years. * mkinitrd plus patches from Fedora 9 would need to be maintained unofficially and used only in the client chroot. For 5 years. * Both of these are EXTRA WORK that I or other people wouldn't be otherwise doing. Any time we spend on this distracts away from new development. It is POSSIBLE than this second scenario is actually a good idea, but I fear this is unrealistic given our resources today. Thoughts? Warren Togami wtogami at redhat.com From peter at scheie.homedns.org Fri Jun 13 23:36:45 2008 From: peter at scheie.homedns.org (Peter Scheie) Date: Fri, 13 Jun 2008 18:36:45 -0500 Subject: RHEL5 LTSP5 backport problems In-Reply-To: <4852E059.7000907@redhat.com> References: <4852E059.7000907@redhat.com> Message-ID: <4853048D.9030201@scheie.homedns.org> I don't know much about how repositories are maintained, but for Scenario 1, could the Fedora chroot be upgraded as new releases of Fedora come out? Or, since we build an entire Fedora chroot, how hard will it be to use new versions of Fedora to (re-)build the chroot? Peter Warren Togami wrote: > So I'm plugging away at a RHEL5 backport of Fedora 9's LTSP5. > > Big problems... > > 1) RHEL5 (and CentOS) has a minimum of i686 kernel. There is no i586 > kernel. I suppose this is a pretty big deal because i586 thin clients > are still being sold new today. (AMD Geode, eBox/LTSP Term 1000, > anything else?) > 2) We cannot backport necessary changes to mkinitrd and push it in an > official RHEL5 errata because the changes needed for thin clients are > too invasive. > > Options? > > Scenario 1: Fedora in Chroot > ============================ > I am considering that a RHEL5 LTSP server might be better off with a > Fedora client chroot in /opt/ltsp/i386. The server side would remain > entirely RHEL + EPEL, while the client would be Fedora. > > Here is the line of reasoning... > > * Fedora provides the i586 kernel. > * The Fedora X drivers have fewer problems on prevalent thin client > hardware since they are newer and we put work into testing/fixing them > with actual thin client hardware. > * Since mkinitrd and kernel guarantee that you need an "unofficial" > package replacing a RHEL core component in the chroot anyway, why not > make the entire chroot "unofficial"? > * This allows us to focus our limited LTSP R&D resources on a single OS > (at least for the client). This significantly reduces the development > and testing burden. > * DRAWBACK: This is not a good solution because Fedora has updates for > only ~13 months. > > Scenario 2: RHEL5 chroot > ======================== > * Somebody has to perpetually maintain an unofficial kernel.i586 that > stays in sync with RHEL5. This cannot be a fully automatic job, and > nobody wants to be stuck doing this for 5 years. > * mkinitrd plus patches from Fedora 9 would need to be maintained > unofficially and used only in the client chroot. For 5 years. > * Both of these are EXTRA WORK that I or other people wouldn't be > otherwise doing. Any time we spend on this distracts away from new > development. > > It is POSSIBLE than this second scenario is actually a good idea, but I > fear this is unrealistic given our resources today. > > 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 dbond at nrggos.com.au Fri Jun 13 23:37:40 2008 From: dbond at nrggos.com.au (Bond, Darryl) Date: Sat, 14 Jun 2008 09:37:40 +1000 Subject: DNS In-Reply-To: <4852868A.8020303@redhat.com> References: <4849AD75.7080109@redhat.com> <9e29091b0806062041r2313186cu2763cd6400beedbd@mail.gmail.com>, <4852868A.8020303@redhat.com> Message-ID: I wonder if we're heading down a path of confusion by adding yet another ltsp-* service name. Reportedly dnsmasq with a proper config file can replace dhcpd, tftpd and named all in a single service. This at least sounds like it would be less confusing for the long-term. OTOH if we did do that, we can't migrate existing F-9 users during the release. Or do we just not have F-9 production users yet so we shouldn't worry about this? Do we keep dhcpd, tftpd and named as default? dnsmasq as default? Do we let users choose? The more completely redundant options the more confusing this gets. =( Warren Togami wtogami at redhat.com I think the users should be able to choose. I am not familiar with the dnsmasq method, but I suspect that it would not be able to handle more complex configurations. The dhcpd can handle controls like if {} which I use a lot. That said, a single daemon that handles simple situations is also a very good thing. Regards Darryl 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 robark at gmail.com Sat Jun 14 05:14:39 2008 From: robark at gmail.com (Robert Arkiletian) Date: Fri, 13 Jun 2008 22:14:39 -0700 Subject: RHEL5 LTSP5 backport problems In-Reply-To: <4852E059.7000907@redhat.com> References: <4852E059.7000907@redhat.com> Message-ID: On Fri, Jun 13, 2008 at 2:02 PM, Warren Togami wrote: > So I'm plugging away at a RHEL5 backport of Fedora 9's LTSP5. > > Big problems... ... > > Thoughts? Hmm. Warren I question whether there is a need for RHEL5 + LTSP5 at this time. Eric already released a RHEL5 (CentOS 5) version based on LTSP 4.2 and RHEL6 is not that far away (I'm guessing 6 months). I would concentrate development on Fedora 9/10 for now. Especially local app support. As for the problem of no i586 in RHEL, I don't think there is a reasonable solution as the whole point of LTSP5 is to use the same packages (distro) for the chroot as the main OS. I don't think it's a good idea to go back to the old ltsp 4.x method of doing things (maintaining an internal ltsp distro) especially if local apps becomes a reality it will be a nightmare to maintain. So if people need a i586 kernel they may have no choice but to install Fedora LTSP and upgrade every summer if they want security updates. But if they can use i686 then I would love to see RHEL6 + LTSP version available. One other note, I believe newer clients will mostly be moving towards i686 anyway. Have you seen the new Asus Eee Box? At $300 I think it will be an excellent low power client capable of running local apps too. You can be sure Asus will have competition in this market too. Seems hardware vendors are rushing to compete in the newly discovered ultra small form factor linux market. :-) One other note: I would also like to see Red Hat offer RHEL6 + LTSP for sale. ie official support. I know of school districts that would be far more inclined to adopt LTSP solutions provided they could purchase official support. -- 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 amposborne at googlemail.com Sun Jun 15 12:18:58 2008 From: amposborne at googlemail.com (Andrew Osborne) Date: Sun, 15 Jun 2008 13:18:58 +0100 Subject: changing LDM to GDM Message-ID: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com> Is it possible to disable LDM and use GDM ? and if so does any one know a way? as this as been an issue with Debian based distros also and a way as been documented, I would expected this also to be and issue once K12Linux is available. my reasons - LDM does not let you select which server you connect to, critical if your allocated server is dead - LDM does not currently report "incorrect password", it just refreshes the screen with no error report - LDM does not follow the system themes, so your login screen does not match your user's theme - LDM does not allow you to save a default (KDE, etc) Andrew Osborne -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavkav at gmail.com Sun Jun 15 13:25:47 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Sun, 15 Jun 2008 16:25:47 +0300 Subject: changing LDM to GDM In-Reply-To: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com> References: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com> Message-ID: <4219988b0806150625l318d06a7yf99951ae8f4fb2c2@mail.gmail.com> we use KDM and are very happy and impressed with the way it can be configured :-) you can change it in "/etc/sysconfig/desktop" and choose the DM you like. this is what we use: DESKTOP=KDE DISPLAYMANAGER=KDE :-) 2008/6/15 Andrew Osborne : > Is it possible to disable LDM and use GDM ? and if so does any one know a > way? as this as been an issue with Debian based distros also and a way as > been documented, I would expected this also to be and issue once K12Linux is > available. > > my reasons > > - > > LDM does not let you select which server you connect to, critical if > your allocated server is dead > - > > LDM does not currently report "incorrect password", it just refreshes > the screen with no error report > - > > LDM does not follow the system themes, so your login screen does not > match your user's theme > - LDM does not allow you to save a default (KDE, etc) > > > Andrew Osborne > > > > > _______________________________________________ > 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 Jun 15 14:42:01 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 15 Jun 2008 10:42:01 -0400 Subject: changing LDM to GDM In-Reply-To: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com> References: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com> Message-ID: <48552A39.6030200@redhat.com> Andrew Osborne wrote: > Is it possible to disable LDM and use GDM ? and if so does any one know > a way? as this as been an issue with Debian based distros also and a way > as been documented, I would expected this also to be and issue once > K12Linux is available. Edit /var/lib/tftpboot/ltsp/i386/lts.conf and change SCREEN_07 to "xdmcp". This changes what the client does during boot. > > my reasons > > * > > LDM does not let you select which server you connect to, critical > if your allocated server is dead The above method will not allow this either if primary GDM server is the same as the dead server. How does this work for pre-LDM LTSP? > > * > > LDM does not currently report "incorrect password", it just > refreshes the screen with no error report This is actually an LDM bug. > > * > > LDM does not follow the system themes, so your login screen does > not match your user's theme I was planning on using this as an advantage by having a LDM-specific login theme for K12Linux. > > * LDM does not allow you to save a default (KDE, etc) > This should be configurable with /etc/sysconfig/desktop but it does seem to be broken at the moment. (Strangely, I can't even get it to work with GDM either. The option itself might have broke.) Warren Togami wtogami at redhat.com From dbond at nrggos.com.au Sun Jun 15 23:51:00 2008 From: dbond at nrggos.com.au (Bond, Darryl) Date: Mon, 16 Jun 2008 09:51:00 +1000 Subject: changing LDM to GDM In-Reply-To: <48552A39.6030200@redhat.com> References: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com>, <48552A39.6030200@redhat.com> Message-ID: >Edit /var/lib/tftpboot/ltsp/i386/lts.conf and change SCREEN_07 to ">xdmcp". This changes what the client does during boot. I didn't think that this allowed the local drives to work if you didn't use LDM. I had better test that assertion. >> >> * LDM does not allow you to save a default (KDE, etc) >> > This should be configurable with /etc/sysconfig/desktop but it does seem > to be broken at the moment. (Strangely, I can't even get it to work > with GDM either. The option itself might have broke.) /etc/sysconfig/desktop only configures which login manager you recieve when you use xdmcp. LDM must just use the last selected desktop?? Regards Darryl 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 Mon Jun 16 01:41:41 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 15 Jun 2008 21:41:41 -0400 Subject: changing LDM to GDM In-Reply-To: References: <6befb72f0806150518t4d2d5983o79a54f8700d48eb3@mail.gmail.com>, <48552A39.6030200@redhat.com> Message-ID: <4855C4D5.1070403@redhat.com> Bond, Darryl wrote: >> Edit /var/lib/tftpboot/ltsp/i386/lts.conf and change SCREEN_07 to > ">xdmcp". This changes what the client does during boot. > > I didn't think that this allowed the local drives to work if you didn't use LDM. I had better test that assertion. > I believe you are correct. > >>> * LDM does not allow you to save a default (KDE, etc) >>> > >> This should be configurable with /etc/sysconfig/desktop but it does seem >> to be broken at the moment. (Strangely, I can't even get it to work >> with GDM either. The option itself might have broke.) > > /etc/sysconfig/desktop only configures which login manager you recieve when you use xdmcp. LDM must just use the last selected desktop?? http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/ref-guide/ch-sysconfig.html At least in the past there were two options in /etc/sysconfig/desktop. One set the display manager and the other was the default desktop. The other option seems to no longer work for GDM. Warren Togami wtogami at redhat.com From dbond at nrggos.com.au Fri Jun 20 10:23:07 2008 From: dbond at nrggos.com.au (Bond, Darryl) Date: Fri, 20 Jun 2008 20:23:07 +1000 Subject: Wyse S50 Terminal sound Message-ID: Hi, I have a long sorry story of trying to get a new(ish) wyse S50 terminal working with LTSP. The Wyse terminal is based on a CS5535 sound chip on an Natsemi Geode I started with LTSP4.2 with a custom kernel with the CS5535 driver compiled in. I found that the ALSA test sounds would work but anything with a bit rate other that 48k would not play. I hacked the kernel driver to try to find what might be wrong and found the part that would not play anything but 48k. ALSA support was a patch on LTSP4.2 anyway. I send a bug report to the ALSA list and got a response from Jaya Kumar that said that the user space libraries would take care of it. But there was no hint of how to do that, nor could I find any documentation. I have not yet been able to find the trick to get the resampling to work correctly. I looked forward to trying a modern release of the kernel and ALSA support in LTSP. I have been trying to get it working with Fedora9 LTSP. No matter what I do I cannot get any further than the # export PULSE_SERVER=tcp:localhost:4713 # aplay /usr/share/sounds/alsa/Noise.wav aplay set_params:979: Unable to install hw params: when /usr/share/sounds/alsa/Noise.wav is, by the way, at 48k?? Now I am trying to understand where pulse stops and ALSA starts as ALSA used to be able to play this sample on LTSP4.2 Any hints as where to start. The Wyse terminals are otherwise very nice (except that it also autoprobes the VESA video driver instead of the nsc or geode driver) Regards Darryl 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 Fri Jun 20 14:45:23 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 20 Jun 2008 10:45:23 -0400 Subject: Wyse S50 Terminal sound In-Reply-To: References: Message-ID: <485BC283.30906@redhat.com> Bond, Darryl wrote: > Hi, > I have a long sorry story of trying to get a new(ish) wyse S50 terminal working with LTSP. > > The Wyse terminal is based on a CS5535 sound chip on an Natsemi Geode > > I started with LTSP4.2 with a custom kernel with the CS5535 driver compiled in. I found that the ALSA test sounds would work but anything with a bit rate other that 48k would not play. I hacked the kernel driver to try to find what might be wrong and found the part that would not play anything but 48k. ALSA support was a patch on LTSP4.2 anyway. > > I send a bug report to the ALSA list and got a response from Jaya Kumar that said that the user space libraries would take care of it. But there was no hint of how to do that, nor could I find any documentation. > > I have not yet been able to find the trick to get the resampling to work correctly. > > > I looked forward to trying a modern release of the kernel and ALSA support in LTSP. > I have been trying to get it working with Fedora9 LTSP. > > No matter what I do I cannot get any further than the > # export PULSE_SERVER=tcp:localhost:4713 > # aplay /usr/share/sounds/alsa/Noise.wav > aplay set_params:979: Unable to install hw params: You shouldn't need to export any variables for sound to Just Work on LTSP5. It is enabled by default. If it doesn't work then it is almost assuredly a driver bug. I'm told that CS5535 was in the "older GX" including your Geode and CS5536 was in Geode LX. Both use the snd-cs5535audio driver. I personally haven't tested any GX, but Geode LX here sound just works fine with LTSP5 on Fedora 9. It is possible that the driver is deficient on the older CS5535 hardware but I have no way of testing it here. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Jun 20 20:51:41 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 20 Jun 2008 16:51:41 -0400 Subject: xorg.conf and autodetection, resolution and keyboard layout Message-ID: <485C185D.3070800@redhat.com> Debian LTSP uses configure-x.sh which writes an xorg.conf before running X. Fedora LTSP by default has no xorg.conf when the client runs, because we rely on X autoconfiguration which works for the vast majority of hardware. This however means many of the XKB* layout related options and X_* options for forcing a screen resolution do not work. So I learned from ajax yesterday during FUDCon Boston 2008 something that I did not previously realize. xorg.conf with *only* screen resolution or layout options will not prevent autodetection of everything else (video driver mainly). This means we could use a significantly streamlined configure-x.sh for only a few options that people use. On a related matter, I'm 50% done writing a script that can be run from ldm's rc.d scripts that sets the keyboard layout without getting xorg.conf involved. By default in Fedora it would set the keyboard layout from /etc/sysconfig/keyboard (which is copied from the server during ltsp-build-client). If the user attempts an lts.conf override with XKB* options then it would use that instead. So this is one less thing that we need would need in configure-x.sh. Keep in mind though, that needing anything at all in xorg.conf is only for the minority of users. Warren Togami wtogami at redhat.com From dbond at nrggos.com.au Sat Jun 21 07:18:53 2008 From: dbond at nrggos.com.au (Bond, Darryl) Date: Sat, 21 Jun 2008 17:18:53 +1000 Subject: Wyse S50 Terminal sound In-Reply-To: <485BC283.30906@redhat.com> References: , <485BC283.30906@redhat.com> Message-ID: ________________________________________ From: k12linux-devel-list-bounces at redhat.com [k12linux-devel-list-bounces at redhat.com] On Behalf Of Warren Togami [wtogami at redhat.com] Sent: Saturday, June 21, 2008 12:45 AM To: Development discussion of K12Linux Subject: Re: Wyse S50 Terminal sound >> No matter what I do I cannot get any further than the >> # export PULSE_SERVER=tcp:localhost:4713 >> # aplay /usr/share/sounds/alsa/Noise.wav >> aplay set_params:979: Unable to install hw params: >You shouldn't need to export any variables for sound to Just Work on >LTSP5. It is enabled by default. If it doesn't work then it is almost >assuredly a driver bug. Yes, that is set to test it locally. It needs to use pulse audio. >I'm told that CS5535 was in the "older GX" including your Geode and >CS5536 was in Geode LX. Both use the snd-cs5535audio driver. I >personally haven't tested any GX, but Geode LX here sound just works >fine with LTSP5 on Fedora 9. It is possible that the driver is >deficient on the older CS5535 hardware but I have no way of testing it here. It's not that old , about a year. The model on the back is SX0, Winterm S50 Manufactured Nov, 2006. The thing boots linux from an encrypted flash partition and the sound works with the supplied linux. This is the response I got from the ALSA list > > Apparently your codec doesn't support VRA, so it cannot work except > > for 48kHz (or 96kHz in some cases). Usually other rates are converted > > via alsa-lib plugin. In the recent versions, the default PCM > > "default" does such conversions automagically (unless you specify > > explicitly the non-conversion, e.g., passing the device 'hw"). > > > > > > Takashi > > > The main application I need to run (Citrix ICA client) uses OSS sound. > It works fine with other sound cards and drivers. In this case it passes > 8000 to snd_ac97_set_rate(). OSS emulation also allows the automatic rate conversion, so it should work regardless whether the chip supports non-48kHz or not. > Do I need to make sure that I have a recent Alsalibs? It would appear > that I am using 1.0.10-0. > Does OSS use the alsalibs? Depends. If it's a user-space emulation, then yes. If it's a kerne-space emulation, then no. Darryl 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 nadavkav at gmail.com Sat Jun 21 14:12:20 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Sat, 21 Jun 2008 17:12:20 +0300 Subject: one year performance graphs and statistics for two server setups we use In-Reply-To: <4219988b0806210433k34dd068cu8134dfb37f0aa233@mail.gmail.com> References: <4219988b0806210433k34dd068cu8134dfb37f0aa233@mail.gmail.com> Message-ID: <4219988b0806210712t4e453fdbt9ba8822a8768503d@mail.gmail.com> we have 16 ltsp servers deployed in our district (Israel, Petach Tikwa). for smaller computer lab with maximum 24 terminals we use Core2Duo+2GB RAM setup and for 48/72 terminals (in a school) we use Quad+4GB RAM setup. i picked up two schools and extracted some graphs (generated by Cacti) from the last year, showing both server's setups. i also have sar statistics that are more fine if anyone cares to go through. (it 10MB gz data each) and (i use ksar to view it. great tool btw) http://docs.google.com/Doc?id=dfs4fjnj_190f58h9xfs what i always like to know about the servers is how much the cpu waits for IO or the NICs for buffers to fill ? and if the proxy needs more memory and does it get the web content fast enough... ? is samba's file sharing is optimized ? if any of you have any ideas how to monitor those bottle-necks please enlighten me :-) i love to get more quality stats next year. i hope you all enjoy, Nadav :-) From nadavkav at gmail.com Sat Jun 21 19:41:59 2008 From: nadavkav at gmail.com (Nadav Kavalerchik) Date: Sat, 21 Jun 2008 22:41:59 +0300 Subject: xorg.conf and autodetection, resolution and keyboard layout In-Reply-To: <485C185D.3070800@redhat.com> References: <485C185D.3070800@redhat.com> Message-ID: <4219988b0806211241i31fd0b66n49c8d623bef8d6b3@mail.gmail.com> hi wtogami :-) i am nadav that was IRCing with you last meeting. i upgrade FC6 to FC8 and everything worked fine and then to FC9 and many issues surfaced :-( i still did not wipe clean install FC9 as you suggest on your personal blog. but i will have time for it this week and so i let you know how it was progressing, especially with the hebrew and RTL issues (we sadly have all the time) 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" and a link to a backup of this file (to get the whole picture) http://www.eagle-israel.co.il/ltsp/opt_ltsp/i386/etc/lts.conf will i still need that ? On Fri, Jun 20, 2008 at 11:51 PM, Warren Togami wrote: > Debian LTSP uses configure-x.sh which writes an xorg.conf before running X. > > Fedora LTSP by default has no xorg.conf when the client runs, because we > rely on X autoconfiguration which works for the vast majority of hardware. > This however means many of the XKB* layout related options and X_* options > for forcing a screen resolution do not work. > > So I learned from ajax yesterday during FUDCon Boston 2008 something that I > did not previously realize. xorg.conf with *only* screen resolution or > layout options will not prevent autodetection of everything else (video > driver mainly). > > This means we could use a significantly streamlined configure-x.sh for only > a few options that people use. > > On a related matter, I'm 50% done writing a script that can be run from > ldm's rc.d scripts that sets the keyboard layout without getting xorg.conf > involved. By default in Fedora it would set the keyboard layout from > /etc/sysconfig/keyboard (which is copied from the server during > ltsp-build-client). If the user attempts an lts.conf override with XKB* > options then it would use that instead. > > So this is one less thing that we need would need in configure-x.sh. > > Keep in mind though, that needing anything at all in xorg.conf is only for > the minority of users. > > 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 Jun 22 08:13:26 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 22 Jun 2008 04:13:26 -0400 Subject: No Warren Sunday June 22nd Message-ID: <485E09A6.3020006@redhat.com> I wont be at the meeting in about 6 hours. Suffering from extreme insomnia and nothing changed in the code to talk about. If you have questions please just post them to this list. ltsp-5.1.9 is still in Fedora 9 updates testing mainly because I didn't push it to stable updates yet. AFAIK it works fine. Keyboard layout fixes are coming next. After FUDCon Boston 2008 during the past few days, I know exactly how to do it now at least. Warren Togami wtogami at redhat.com