Below are the 20 most recent journal entries recorded in wtogami's LiveJournal:

[ << Previous 20 ]

Saturday, July 26th, 2008
3:10 am	Day 1: LTPS Hackfest Portland 2008 Developers from Debian, Fedora, Gentoo, OpenSuSE, Ubuntu and others met in Portland, OR for the LTSP Hackfest. We got a surprisingly large amount done during Day 1. We used gobby to collaboratively write notes and to fix up code during a collaborative review. It was great to see developers on 5 different distributions using a shared tool to work on common problems. DisklessWorkstations.com has been the primary sponsor of LTSP upstream development for many years now and they are the primary sponsor of the customary grand banquet Friday night. Red Hat chipped in a little as secondary sponsor to cover food on Saturday. Here is a link to today's notes in full detail, but here I write a summary so others may better understand. LDM - The LTSP Display Manager Scott Balneaves led the group in a live code review of the proposed LDM cleanup. The group suggested a few tiny improvements while others quietly added code cleanups in other parts of the same source file opened in the shared gobby session. It quickly was merged into ltsp-trunk and further testing ensued. No confirmed breakages yet. This will be tagged as ltsp-2.0.8 probably during Saturday. It was important to get this merge done ASAP since it contains lots of code cleanups and simplification, that enables addressing other LDM action items. The group went over the list of proposed LDM action items. At first it was believed that some would be inappropriate for the current LDM-2.x branch, however we later came to agreement that all of the proposed and accepted ideas could be implemented in ldm-2.x without breaking compatibility with older servers. Local Apps Implementation We spent the final hours going through the "Local Apps" plan. Local apps enables running of certain applications on the thin client itself, which is tremendously beneficial with otherwise bandwidth intensive media applications. For example, Firefox playing Youtube can easily overwhelm a 100mbit network with only two or three clients. For this reason there is a strong desire to be able to offload video intensive applications like Firefox to the client, creating a "hybrid" client. The recent openssh-5.1 release included statvfs in the sftp-server. sshfs (somehow) already had statvfs and in simple tests it seems to work. We do not yet know if it works well enough for firefox. Gideom Romm had already thought out the entire local apps implementation. Warren suggested a simplfication of the user/group portion to avoid pulling in libnss_extrausers. A theoretical but untested implementation is now 95% complete. We need a few supporting changes to do our first runtime tests on Saturday. Next LTSP Hackfest There is already planning underway for the next LTSP Hackfest to be in Maine around October 23rd. This makes it roughly a year after the previous Hackfest in Maine, at the same location. If you have any interest in LTSP or diskless clients, I can highly recommend hanging out at the next Hackfest. Accomodations are very affordable in the cozy motel during the tourist off-season near Acadia National Park. (Comment on this)
Monday, July 21st, 2008
9:14 pm	Civilization Revolution is Very Broken July 8th Civilization Revolution was released in America. I pre-ordered it from Amazon because the demo on PS3 was fun. I didn't receive it until July 14th. I can report that while the game can be quite fun, the game suffers from numerous crippling bugs and design problems. For this reason I must currently recommend AGAINST purchase at a steep price of $60. It pains me to write this negative recommendation because I am a huge fan of the Civ series and hope to have fun playing with my friends. Perhaps I will change my mind later if they fix most of these problems. HUGE DESIGN PROBLEM: NAT TRAVERSAL - CRIPPLED BY DEFAULT NETWORK GAMING A significant issue evident even during the PS3 demo was a problem in the game's network handling in Multiplayer. This is where you do a search for online games, and it tells you it failed to host, check your network connection. It turns out that you need to manually forward ports to your PS3 in order for the game to work reliably multiplayer (it seems it is possible to play without forwarding if you connect to another hosting player who is forwarded.) This demonstrates an immense failure of design. So many other games work just fine without manual port forwarding. Other multiplayer PS3 games like Warhawk work automatically with UPnP NAT traversal for the PS3 to report "NAT Type 2" in its network test. Why can the PS3 network test and other games like Warhawk work reliably with automatic UPnP NAT traversal and Civilization Revolution requires manual port forwarding? While my engineer geekiness can handle manual port forwarding, this is a terrible expectation to make of ordinary users. It is a great way to limit the attractiveness of your game when it fails by default. There appears to be some unconfirmed speculation that instability in the game hosting is due to the company decision to use the GameSpy network. From what I can tell GameSpy is only a matching service, while players require manually forwarded ports in order to play against each other. The XBox 360 version of Civ Rev apparently does not have this problem because the games are hosted on central servers. CRIPPLED MULTIPLAYER SEARCH AT AMERICAN PS3 RELEASE Immediately upon release they issued a patch to 1.10 which horribly crippled Multiplayer, a large reason why this game has any appeal. The 2K Games Forums are full of people screaming about this and numerous other bugs, and reportedly they are working on the 1.20 version to fix searches. What seems to be the issue is 1.10 incorrectly made all game searches look for "Scenario" games instead of ordinary games. This means that everyone attempting to search will find nobody, leading players to believe there really are no other players. Users can find other players by downgrading to 1.00 (delete the game, run it and refuse upgrade). However if they start a game with another user running 1.10 it is impossible to play due to resynching errors. It is only possible to play a multiplayer game currently if all players in the game are running the same version. A representative of the company said 1.20 will correct the search so players can easily find each other, and also prevent mixed version games. This bug alone is an incredible embarassment that will be very costly to the company. RACE CONDITIONS AND DEADLOCKS The forums are full of complaints of deadlocks and other quirks that can happen during a multiplayer game. I personally experienced the "dancing units" bug where combat can cause the game to get stuck. It seems to happen only rarely because an asynchronous event of another player must occur at an instant where you enter combat. In my case another player settled a new city in an adjacent spot to where I was attacking another player. Combat ensued, ended, and the game froze. Judging by the forum posts, it seems the company has not admitted this to be a confirmed problem, and it is not scheduled to be fixed in vesion 1.20. MISGUIDED PRIORITIES AT COMPANY Upon American release the company seemed very excited about talking about their upcoming Downloadable Content that players can purchase. This is extremely annoying to players on the 2K Games Forums and myself that they would prioritize the creation of downloadable content to squeeze more money out of players when the underlying game is so demonstrably broken. POOR COMMUNICATION/NEWS IN GAME Upon running the game and connecting to the network, there is no indication of news bulletins from the company to players like exists in other online console games like Warhawk. It might be helpful to have something that can display tips to users to warn them of the crippling NAT traversal problem and what to do about it. Or to talk about new things fixed in version upgrades. I soon leave on a business trip and return next week. I hope they issue the next update soon. I will reassess if the game is improved, and update this blog entry. (Comment on this)
Sunday, July 6th, 2008
1:42 am	Radicals Dreamer on Guitar Last weekend I took my first guitar lesson and bought a classical guitar Ibanez G850. This weekend was my second lesson. I am finding it to be very challenging and sometimes frustrating when I'm not progressing fast enough. But I feel inspired by various solo guitar performances on Youtube. Today I pre-paid and committed myself to 12 more lessons for a discount, and to give myself further incentive to keep practicing. My new favorite guitar video. Justin Lincoln did a superb job in arranging the rhythm guitar and singing parts of the Chrono Cross ending theme into a single guitar solo complete with video and tabs. I hope that one day I will be able to play this song. (Comment on this)
Sunday, June 22nd, 2008
1:02 am	素敵だね (Isn't It Wonderful?) I did some random web surfing to get my mind off the pain. I really like the musical themes from the Final Fantasy series.  I was delighted to discover that people have been putting videos of themselves playing guitar arrangements on Youtube.  Youtube a ton of this stuff.  Amazing platform of creativity it is.  A few that I liked... Acoustic Guitar: Tifa's Theme (FF7) Main Theme (FF7) Breezy (FF8) Eyes on Me (FF8) 600AD (Chronotrigger ... not FF but made by the same company and with equally memorable themes.) Melodies of Life (FF9) Check out this guy's playlist.  He arranged and played 32 FF songs for solo guitar.  Some are better than others, but I appreciate this guy's work. Electric Guitar: FF7 Battle Theme Chocobo Theme (This guy is playing bass and lead AT THE SAME TIME.  His attitude is funny too.  He has a few other videos where he does Zelda and Tetris with two guitars as well.) Chronotrigger Battle Theme (Entertaining watching the small kid play huge instruments.  First he lays down the bass line in a loop, then goes nuts on the guitar part.) An attractive Japanese girl put a lot of effort into dressing up as the character Yuna from Final Fantasy X and singing 素敵だね (Suteki dane), the theme song from the game.  I do admit that her face distracted me from a few anemic notes (...), but she did a good job reproducing the singing of Japanese folk singer Rikki.  As a former musician I have a lot of respect for the skill and especially *guts* it takes to post yourself on Youtube. During my most recent visit to Tokyo I was delighted to find that game music like this was somewhat mainstream, in the rotations of some radio stations and cafes.  I heard the original version of this song and a few instrumental arrangements of other Final Fantasy themes. 素敵だね acoustic guitar version.  This guy does a good job playing this commercial arrangement from a song book. This makes me seriously consider attempting to learn acoustic guitar.  How do I begin?  (I've done only woodwinds in the past.) (Comment on this)
Thursday, June 19th, 2008
4:02 pm	Keyboard Plan FUDCon Boston 2008 Hackfest The keyboard configuration in Linux has long been a huge mess of too many different ways of doing the same thing in different places and inconsistencies.  (Please correct me if I have any details wrong.) * Today there are two sets of keyboard layout data, kbd for the console and xkeyboard-config for X. * /etc/sysconfig/keyboard configures only the console keyboard layout. * When X runs, there is no connection of the console layout and X keyboard layout. * xorg.conf can specify a layout and options to use from xkeyboard-config (an upstream package with tables).  (Fedora/RHEL doesn't use this AFAIK.) * Or gdm reads a user-configured layout from ~/.dmrc, which can't always work because the home directory is not available in some cases before login. * After you have logged into GNOME, gnome-settings-daemon reads an optionally configured keyboard from gconf and uses it if available. * (Do other desktops like KDE have something else entirely?) With developers together during FUDCon Boston 2008 Hackfest, Jeremy Katz, Bill Nottingham and Adam Jackson had a chance to brainstorm a plan to improve this confusing mess. * We need to throw out the entirely separate kbd table.  Console keymap setting needs to happen from the shared xkeyboard-config.  ckbcomp from Debian exists.  Jeremy Katz is looking into adapting or rewriting it in C because there is some discomfort with the current perl implementation. * ajax already has some code to have X  set  the keyboard layout itself.  He plans on making it happen from whatever HAL tells it, which comes from /etc/sysconfig/keyboard on Fedora This still leaves the inconsistency of two separate user-specific keyboard layout options in ~/.dmrc and gconf.  But these at least do not (at least should not) happen if a user has not configured it. (Comment on this)
Wednesday, June 4th, 2008
5:30 am	Fedora Hawaii 2008 and LTSP thoughts David Cantrell and I gave a presentation about the Fedora Project and the new Fedora 9 release at the University of Hawaii. We gave out a number of 2GB USB sticks to promote Fedora 9's LiveUSB with persistence feature, since this is the safest way for people to try Fedora without risking their hard drive. This brings up two thoughts: 1) Intel Macs seem to be prevalent among our target user. 3 people seemed to want to try LiveUSB but they had Intel Macs. Our LiveUSB doesn't support EFI boot. Not sure if this would be possible to support in the future. 2) LiveUSB is a great way for people to try Fedora safely. But perhaps we should do something like Ubuntu's Wubi for an even safer and ultra-convenient way to try Fedora. It would be less fragile than USB, no worry of writing beyond overlay capacity and other possible causes of corruption. It appears that it wouldn't take a lot of work to implement for Fedora? In any case we might need to give it a different name because it clashes with the too prevalent Chinese input method. After the presentation we ate pizza and I talked with a number of folks. I met a former tech company engineer named Scott currently an educator at Kailua Intermediate. He has coding skills and was very interested in how to get involved in Fedora development. Then I met another educator from Kailua. They together manage ~4 LTSP labs at their school. They mentioned the need to port fl_teachertool to work with LTSP in Fedora 9. Since they both heavily rely on LTSP and have coding skills, this sounds like a promising opportunity to recruit a new developer to Fedora and to work with me on the K12Linux LTSP for Fedora project. I also had the opportunity to talk at length with R Scott Belford of the Hawaii Open Soure Education Foundation (HOSEF.org). At the time that I left Hawaii I was involved with getting Linux thin clients into only a few schools. I was surprised to hear that HOSEF had Linux thin clients and diskless workstations had since expanded to 40+ labs in both schools and community centers. Understandably they had to do deployments with software beyond just Fedora/K12LTSP because the technology fell so far behind. I learned from Scott that the Norwegian Skolelinux had a number of LTSP and diskless workstation features that LTSP upstream or Ubuntu does not yet have, like local apps support which is very important for multimedia. This is a bit surprising to hear. I have to check into this. He also mentioned that there is something else similar to teachertool that might be suitable. These were the first educators that I met in-person after the release of Fedora 9 with K12Linux. It is very important for me to get feedback like this. It seems that too many people use things, run into a problem and give up too easily without asking questions on the project list. (2 Comments |Comment on this)
Tuesday, May 20th, 2008
6:24 pm	Fedora Hawaii 2008 http://fedoraproject.org/wiki/Events/FedoraHawaii2008 For those of you in Honolulu, Hawaii.  June 3rd, 2008 at 6:00PM Warren Togami and David Cantrell present about the new Fedora 9 release at the University of Hawaii at Manoa.  Then we eat pizza.  See details at the above URL. (Comment on this)
Thursday, May 1st, 2008
12:25 am	LTSP in Fedora 9 Status UPDATED: LiveJournal screwed up all my links so posting this again with some updates. https://fedorahosted.org/k12linux/ LTSP (Terminal Server and Thin Client) support is now in very good shape for Fedora 9 release. Weekly development meetings and the development mailing list have proven to be very fruitful in knocking out bugs and enabling missing features. The latest documentation describing the status, installation and configuration instructions are forming at the K12Linux homepage. A few highlights of LTSP progress in Fedora: Most thin clients JUST WORK without any manual configurations. Most major thin client video chipsets are working very nicely in both F-8 and F-9 now. Remote sound seems to be working on F-8 and F-9 out of the box. "Local Storage Devices" like USB sticks and data CD's seem to be working well in F-9. Simply insert that type of storage into the thin client and it pops up on your desktop running on the terminal server. Your applications running on the terminal server see the files/directories of your local storage as if they are a local filesystem. When you're done with it simply unplug your memory stick or eject the CD. Note that if you want this to work on F-8 your user must be a member of the fuse group. Help Needed and Known Bugs: Reportedly on F-8 your local storage device icon isn't appearing on the desktop although the mount is working. This is working great on F-9.  Any ideas why this isn't working on F-8 (probably gnome-vfs related). Tracker of all known issues of LTSP in Fedora. Please visit our homepage, read about the software and try our InstallGuide. If you have any questions about LTSP or if you see bugs, please talk to us on our mailing list or online chat on irc.freenode.net channel #ltsp. (Comment on this)
Monday, March 17th, 2008
9:50 pm	Solid Thinkpad More than a year ago the hinge of my Thinkpad T41 broke.  In a very dumb move, I tried to use epoxy to glue the hinge back together.  That not only did not work, but it left a broken piece of the hinge stuck to the support structure.  pjones at the time pointed out that I could have just ordered a new hinge for $25.  Today I took home the picked over carcass of a dead Thinkpad T41 from the office.  I removed an intact LCD screen with hinges, and then attempted to remove the broken equivalent from my old T41.  I discovered my earlier epoxy stupidity.  Figuring I had little to lose at this point, I used a wood chisel and hammer in an attempt to break off the remaining pieces.  It took me ~100 strikes to chip it off.  I then put the laptop back together with the replacement LCD screen. To my amazement, the laptop booted with no problems and all devices seem to work.  Not bad for a 4+ year old abused laptop.  Seriously, does any other brand build this level of quality?  Dear Lenovo, DO NOT RUIN THIS BRAND. (Comment on this)
Wednesday, March 12th, 2008
10:10 pm	Recovering SELinux in Rawhide https://bugzilla.redhat.com/show_bug.cgi?id=436988 If you have been using Rawhide in the past few days then you probably had to use "selinux=0" in order to boot at all.  Well, it appears that enforcing=0 would have been sufficient but somebody told me selinux=0.  Anyhow, after upgrading to selinux-policy-3.3.1-14.fc9, I rebooted with SELinux fully enabled and enforcing.  It went through the customary full filesystem relabeling.  Then gdm promptly failed to work at all. https://bugzilla.redhat.com/show_bug.cgi?id=437211 It took me a while to figure out what was going on. Apparently while it was running as selinux=0 it wrote stuff in /tmp that wasn't relabeled during the full relabling.  Perhaps it is beyond the design of relabeling to be able to label arbitrary files in /tmp left by programs while they were operating with selinux=0?  In any case, you can recover from this kind of failure by wiping affected stuff from /tmp then restarting. (Comment on this)
Monday, March 10th, 2008
11:42 pm	LTSP5 for Fedora in rawhide Today ltsp and ltspfs passed package review so they should be in tomorrow's rawhide.  If you want to try it, the instructions and warnings written in the previous two blog posts apply. https://bugzilla.redhat.com/showdependencytree.cgi?id=188611&hide_resolved=1 A few of the more immediate TODO items are in the Bugzilla tracker here.  If you are interested in helping, here are a few of the easier problems that need fixing: Bug #436906: Find the proper pulseaudio launch parameters for ltsp-client. Bug #436907: Fix ltsp-server-initialize script.  Lots of little bash scripts that tweak settings on various things. Bug #436913: Fix cdpinger segfault.  First step is getting a core file and the backtrace. Bug #436916: Write a x86_64 kcikstart file for client chroot. Bug #436917: Write a ppc kickstart file for client chroot. Help to write more documentation in the Wiki. Next for me is one of the more difficult problems that scare me.  Horray. (Comment on this)
2:06 am	LTSP packages for review https://bugzilla.redhat.com/show_bug.cgi?id=436741 LTSP server and client package https://bugzilla.redhat.com/show_bug.cgi?id=428748 LTSP network filesystem ldm already passed review and is currently in rawhide.  This version contains a hack that allows ldm to work on F-9, so assuming the video driver in rawhide works, you should have a login screen and be able to login to a desktop session.  Bug #436230 remains as ldm needs to properly use xauth in order to handle different types of remote desktop connections in a secure fashion. Status Update ltsp-server-initialize remains broken, haven't had time to look at it yet. pulseaudio support is broken.  Somebody could fairly easily investigate if it can be fixed with different launch parameters.  See /usr/share/ltsp/ltsp-init-common in ltsp-client if you want to help. screen.d/xdmcp and ldm don't share any common X setup code, I need to fix this before Fedora 9. kvm's emulated rtl8139 seems to be broken with F-8 and F-9's kernel drivers.  Upgrade to kvm-63 in rawhide or for F-8 from my temporary repository if you want to use ltsp-vmclient.  kvm-63 defaults to e1000 emulation which works great.  It also defaults to -vmware-vga which works great for a F-8 guest, but unfortunately F-9's rawhide VMWare driver is currently broken. After these packages are accepted into rawhide, my next step is to do further reorganization upstream..  The mdkst source repository testing and release tool needs some rewriting, and upstream needs to agree on a release methodology for tagged versions and actual tarballs. (Comment on this)
Friday, March 7th, 2008
1:10 am	Help Needed: LTSP5 for Fedora I finally have LTSP5 mostly working.  It took many months of work to whip upstream into an actual upstream project (the hard part) and to adapt Debianisms or rewrite stuff to work with Fedora (slightly less hard).  It currently is ready for early testing.  I would really appreciate feedback and especially patches to help bang this into shape for Fedora 9.  Fedora 8 works a bit better than Fedora 9 currently.  See below for details. Packages of LTSP5 in Fedora ltsp-vmclient: (screenshot above) This package is a convenient way to test LTSP with PXE boot qemu-kvm.  You don't need the hassle of plugging in extra hardware in order to test your LTSP server setup. ltsp-client: This package installs into the client chroot only. ltsp-server: This package installs on the LTSP server only. ldm: This package contains the LTSP Display Manager.  LDM runs on the client, asking the user for username & password, and optionally to choose a desktop session (GNOME, KDE, XFCE, etc.) and non-default language.  When the user types a name and password it attempts to login to the server via SSH.  This needs perhaps the most work of all LTSP components before Fedora 9. ltspfs: Handles "local device" support for CD-ROM, floppy, and USB sticks.  These local devices are mounted and visible on the server. pulseaudio: Pulseaudio handles sound over the network. Important Scripts within ltsp-server ltsp-build-client: This script installs a client chroot into /opt/ltsp/i386.  If your host is Fedora 8, it installs a Fedora 8 chroot.  If Fedora 9 host, you get a Fedora 9 chroot.  You can override the OS of the chroot to install with --release=X.  These client chroots are mounted over the network by the thin clients, allowing them to boot and run ldm. ltsp-server-initialize: This script is meant to enable services and configure things to make a Fedora machine into a LTSP server.  Currently this doesn't work at all.  It needs lots of improvements to do the right thing, and even then it is probably is not entirely safe for all users.  See the directions below for minimal configurations necessary to run a LTSP server. ldiminfod: This is the main thing needed on a server in order to support LDM client connections.  It advertises to LDM clients available desktop sessions, languages and a "rating" of how busy the server is.  In the future ldminfod will be split into its own package. Status The current state is pre-alpha.  It might work, but all sorts of things could still change including the location or contents of config files. Remote sound with pulseaudio is currently broken.  The pulseaudio daemon flags called from /usr/sbin/ltsp-client-launch would be the first place I would look.  See /usr/share/ltsp/ltsp-init-common in ltsp-client if you want to help. ltsp-build-client on F8 host requires the livecd-tools from F9.  I put it into the temporary repository for F-8.  It is safe as long as you are not making any LiveCD's. LDM (default X connection type) is broken in a F-9 chroot due to Bug #436230.  If you understand how xauth works some help to fix LDM would be appreciated.  If you want to try LTSP with a Fedora 9 host use ltsp-build-client --release=8 to install a Fedora 8 chroot instead.  A possible alternative is to edit /var/lib/tftp/ltsp/i386/lts.conf and change SCREEN_07 to xdmcp instead of ldm.  You would get a plain X -query.  (Conversely you can test a Fedora 9 chroot on a Fedora 8 hosts with ltsp-build-client --release=9.) I could use some help getting these snapshots into package reviews for Fedora 9.  (Some packages already have earlier versions approved or in review.) See the Bugzilla Tracker for other current issues. TODO (in priority order) Fix Bug #436230 so LDM works in a F-9 chroot. Install k12ltsp-temporary .repo files into the client chroot so it can yum update itself. Submit all packages for review. Write iptables rules to allow dhcpd, NFS server and other needed services to work without disabling the firewall.  Lokkit integration?  I don't know what the best way is here. Fix ltsp-server-initialize so it actually works. Fix pulseaudio launching for remote sound. Detect  and fail upon mismatch between /etc/xinet.d/tftp setting and what it should be on the target OS during ltsp-build-client.  F-8 was /tftpboot while F-9 was /var/lib/tftp. LDM needs the ability to launch all sessions through Xsessions instead of running them directly like it does now.  For example, running gnome-session directly means the stuff in /etc/X11/xinit/xinitrc.d are bypassed. Fix cdpinger segfault. Verify that local devices (CD-ROM, floppy, USB key, etc.) are auto-mounted and visible on the server.  This possibly needs ConsoleKit integration so device permissions are set properly upon login (not sure). Implement NBD root handling in mkinitrd (better and faster than NFS for network boot) Make LDM's ldminfod "protocol" versioned. Move ldminfod into the LDM source tree and make it into its own sub-package.  It could be installed independently of ltsp-server. LDM needs to be localized, and to display language choices in native localizations depending on the default locale.  This will definitely need ldminfod protocol changes. Implement x86_64, ppc, and other arch client recipes. Implement optional offline install from media of client chroot (many target users don't have an Internet connection, or too slow) Installation Read all the above notes.  Lots of stuff is broken so you must be prepared. Install k12linux-temp-release [F8] [F9].  Until we have everything fully integrated into Fedora, this temporary repository will contain stuff needed for the LTSP server and clients. WARNING: This temp repository replaces two packages on Fedora 8.  A newer livecd-tools is needed on the host in order to install the client chroots.  A newer mkinitrd is needed in the client for network boot related functionality.  For safety purposes this mkinitrd is not in the k12linx-temp repository and it is installed only into the F8 chroot from the kickstart file. yum update livecd-tools yum install ltsp-server yum install ltsp-vmclient if you want the qemu-kvm PXE boot client launcher.  Requires hardware virtualization support or it will be very slow and possibly unusable. Uncomment the option_cache_value line in /etc/ltsp/ltsp-build-client.conf if you want to keep a local cache of packages to be installed in the client chroot.  This might be useful if you keep testing newer versions of ltsp-server and you will be reinstalling the client chroot.  Erase /var/cache/chroot if you no longer need this cache. ltsp-build-client The below steps can theoretically be done by running ltsp-server-initialize.  However it is currently broken.  Anyhow you probably want to do it manually yourself the first time so you know exactly what is going on. echo "/opt/ltsp *(ro,async,no_root_squash)" >> /etc/exports ifup ltspbr0 for service in xinetd ltsp-dhcpd rpcbind nfs sshd; do chkconfig $service on; service $service start; done for server in ldminfod nbdrootd nbdswapd; do chkconfig $server on; done Disable your firewall during these tests.  It will interfere with DHCP and other incoming connections. At this point ltsp-vmclient will theoretically work.  If you want to boot a real thin client read below. Network Setup I am experimenting with a unique way of handling LTSP networking by default.  LTSP5 in Fedora automatically configures itself to run on a virtual bridge device instead of a real Ethernet interface.  ifcfg-ltspbr0 is installed by default, creating bridge ltspbr0 with a default network of 172.31.100.0/24.  This network is self-contained on the server allowing internal testing with ltsp-vmclient if desired. If you want to connect real thin clients to this LTSP server, you must add Ethernet interfaces to this virtual bridge.  brctl addif ltspbr0 ethX can be used in a temporary fashion, which is handy if you are plugged directly into a single thin client for quick testing.  This can even be done on a laptop conveniently if you disable NetworkManager's auto-connect on the eth0 interface.  For permanent networks you would define a ifcfg-ethX interface to add itself to the bridge (no IP address needed for itself). This setup has two key benefits: Easier to Understand: Sysadmins only need to know to add an Ethernet interface to ltspbr0 if they want to connect thin clients through that interface.  This requires an explicit action and it is much easier than configuring interfaces and matching dhcpd.conf's in separate places. Safer: dhcpd can be explicitly limited to serve only to ltspbr0.  This reduces the chances of accidentally screwing your home/school/work/district-wide network by becoming a rogue DHCP server. =) I realize that this method of LTSP server network configuration is very different from the past.  I intend on better documenting it soon to make it easier to understand and deploy.  Your comments on this idea would be appreciated. FAQ Why are some locations like /opt/ltsp/i386 stupid? /opt/ltsp/$arch came from LTSP and has been in use for 8+ years now.  Upstream LTSP5 to be shared between Debian, Ubuntu, Gentoo, OpenSuSE and others all use that location.  It would be nice if everyone came to agreement on a new standard location, but nobody wants to fight that battle right now. Why are there no versions and everything is a snapshot? That's the way Ubuntu worked on this for the past 2 years. =(  I'm working on getting actual versions tagged and tarballed soon. GAH!!! LDM and/or LTSPFS is an ugly hack! That might be true, but they have working code already in production by thousands of sites today.  Where is your better implementation?  Write it and I'd be happy to consider switching. What about backporting to VERSION 5?  (I'm complying with the corporate master's goodspeak.) I hope that I can backport this to VERSION 5 later.  We can't realistically make progress on this until the tools and capabilities are standardized for Fedora 9.  Ask later. Tips Enable yum install or yum update in the client chroot: cp /etc/resolv.conf /opt/ltsp/i386/etc/resolv.conf (or set it appropriately) mount /proc Erasing client chroots: Make sure everything is unmounted from the chroot before you delete it.  Check /proc/mounts to be 100% sure stuff is unmounted, as /etc/mtab can lie to you if something was mounted within the chroot.  If ltsp-build-client failed for some reason, check for leftover bind mounts before erasing the wreckage and trying it again. If your thin client has Intel video, try enabling compiz after you login. =) How can I help? Test it!  Report bugs!  Ask questions.  fedora-devel-list or fedora-education-list are both fine places.  If you have a LiveJournal account you may reply to this blog post too.  In a few days there should be Bugzilla components for all these packages so you may be able to post real bugs there.  Please DO NOT SEND ME PERSONAL MAIL.  I am less likely to respond to personal mail than a public mailing list post. Get involved in development.  I wrote tools to make changing stuff and building your own installable test RPMS very quick and easy.  Here's a primer. yum install mkdst bzr rpmdevtools bzr get http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk cd ltsp-trunk ./mkdst --testrpm - This command attempts to build a test RPM based upon whatever is in the directory, whether it is local change checked in or not.  If the build fails it tells you what went wrong.  If you are doing this on a x86_64 host you will likely want to throw the .src.rpm into mock to build a i386 version if you want to upgrade the package in the chroot. Source Repositories LTSP https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk bzr get http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk LDM https://code.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk bzr get http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk LTSPFS https://code.launchpad.net/~ltsp-upstream/ltspfs/ltspfs-trunk bzr get http://bazaar.launchpad.net/~ltsp-upstream/ltspfs/ltspfs-trunk (6 Comments |Comment on this)
Friday, February 15th, 2008
5:17 pm	GNOME Autostart Bypass Hotkey? On Windows during startup you can hold down a key like Shift and it will startup your desktop without running some stuff (Startup folder?)  I thought GNOME had something similar to this a long time ago, but I see no sign of this today. It seems that we define things to startup in two places (or more): /etc/xdg/autostart/ /usr/share/gnome/autostart/ Does anyone know if GNOME has an existing hotkey that can be held down during session startup that prevents stuff like this from autostarting? (Comment on this)
Wednesday, February 6th, 2008
11:06 pm	LTSP in Fedora, a Status Update Work is progressing on the LTSP Fedora integration.  Some of the current problems... https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk ltsp.src.rpm builds ltsp-client and ltsp-server packages.  ltsp-server contains a script "ltsp-build-client" that upstream LTSP wants to be the common command to build a LTSP client chroot. LTSP client chroot  installation A chroot must be built and provided over the network, which is booted by the thin clients.  Earlier prototypes of LTSP on Fedora used the distro's own "anaconda" package with a kickstart file to install the chroot.  It was done this way because it was a quick and easy way to install into a chroot from kickstart definition and provide the user with progress indicators.  Unfortunately we keep running into problems on both target platforms Fedora 8 and Fedora 9 with various bugs and issues within Anaconda itself.  It has become clear that we cannot depend on Anaconda for a production version of LTSP because even if we have fixes for Anaconda, we cannot push updates to a stable release of that package. Jeremy Katz informed me that dramatic improvements are coming to Fedora 9 in the livecd creation tools.  It was made into a library so it should be easier to consume for non-LiveCD things now.  This is clearly the way forward for this part of the problem.  He said these should hit rawhide later this week. LDM Issues https://code.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk LDM is a simple display manager to handle ssh-based authentication between thin clients and terminal servers.  We initially ran into some issues due to Debian-specific assumptions made in LDM.  For example, Debian uses alternatives to provide the available desktop sessions instead of the GNOME/KDE standard of /usr/share/xsessions/*.desktop files.  Vagrant Cascadian discovered that Debian actually does ship those *.desktop files, so ldm was quickly modified to work upon those files instead of rely upon alternatives. LDM also used Debian's /etc/environment to find the system's default LANG.  We apparently don't have this, but it does live in a Fedora-specific /etc/sysconfig/i18n.  In order to maximize distro-neutrality in upstream's LDM we changed it to get LANG from the output of the locale command instead. There remains one major problem in LDM that prevents it from being usable on Fedora.  LDM currently in use on Debian uses locale -a in order to get a listing of available system supported languages.  This works on Debian where it returns only 17 languages.  But on Fedora 8 it returns 696 languages.  The LDM gtkgreeter as it is written now chokes on more than ~200 languages.  Even if it could handle that many languages it wouldn't be a usable interface at all with that many choices to scroll through. This particular problem wont be a quick fix.  What is the best way to represent an arbitrarily large number of languages in a login dialog chooser?  The old gdm wasn't exactly the best in usability in this regard.  I consulted Red Hat's Desktop team.  It turns out that Ray Strode and Jon Mccann has been thinking about exactly this problem for the current rewrite of gdm happening for upstream GNOME and Fedora 9. I decided to punt on this problem for now.  My goal is to get LDM working with minimal changes in the short-term, then later return to improve its interface later.  Perhaps by then the GNOME guys would have wrote their new shiny language chooser interface that could be re-used, and I would also have the opportunity to polish the LDM interface in some ways like displaying localized language names.  It is also a long-term goal to explore the possibility of "standardizing" LDM's protocol to make it suitable to support directly from more prevalent display managers like GDM. (Comment on this)
Monday, January 21st, 2008
11:33 am	Food Poisoning Fun weekend of food poisoning.  I will spare the gory details here.  This morning is the first day I have enough energy to walk and  keep down solid food.  I also discovered that I am allergic to Cipro. Hopefully I will be back up to speed at the office tomorrow. (Comment on this)
Tuesday, January 15th, 2008
11:38 pm	Post-FUDCon: K12Linux Status FUDCon was over the past weekend.  Eric Harrison and I planned on using the two hackfest days to get the bulk of the LTSP5 integration into Fedora done.  Unfortunately there proved to be far too many distractions of other things going on at FUDCon (cool shizzit going on).  I personally managed to resolve several  long standing issues in a few packages with only a few minutes of face-time with certain developers that I rarely see in person.  Subsequent to FUDCon, Toshio Kuratomi joined us for focused hacking on Monday and part of Tuesday.  Toshio was a huge boost to our efforts before he flew back to California mid-day Tuesday. https://bugzilla.redhat.com/showdependencytree.cgi?id=188611&hide_resolved=1 We are now *close* to having it work.  Starting from the LTSP5 Debian-centric upstream, each step along the way of this integration was done with the intent to make it suitable for upstream inclusion.  All packages except ltsp itself (contains ltsp-client and ltsp-server sub-packages) have been submitted for package review. https://bugzilla.redhat.com/show_bug.cgi?id=424591 Dear Jeremy or Peter, please review these sorely needed changes for mkinitrd to make it possible to support network booting from a single initrd image.  Note: This is NOT the bash-branch. Theoretically we could have it working in time for Fedora 9 Alpha freeze, which after the 1 week slip is now Tuesday, January 22nd.  I fear however that the gdm rewrite may make it unusable.  We will soon see. (2 Comments |Comment on this)
Tuesday, January 1st, 2008
11:59 pm	Testing Needed: pidgin and spamassassin for RHEL5 http://people.redhat.com/wtogami/temp/pidgin-RHEL5/ pidgin-2.3.1 for RHEL5 http://people.redhat.com/wtogami/temp/spamassassin-RHEL5/ Unreleased but upstream proposed 3.2.4 version of spamassassin. If you are using RHEL5, please help to test these unofficial packages.  I haven't tested them yet, so please be careful and be prepared to downgrade if necessary. Please report problems here in this blog thread. (Comment on this)
Monday, December 17th, 2007
4:42 pm	FUDCon 2008 Raleigh Transport Sharing http://fedoraproject.org/wiki/FUDCon/FUDConF9/ParticipantTravelPlans If you are flying in for FUDCon 2008 Raleigh, please add yourself to this page so ride sharing can be arranged to/from the airport.   (Comment on this)
Wednesday, December 12th, 2007
7:20 pm	AMD Geode Development Today the amd X.org driver is utterly broken in Fedora 8 for most AMD Geode hardware, and I found information about it to be difficult to find.  After a few hours of working on it... http://www.x.org/wiki/AMDGeodeDriver http://lists.x.org/mailman/listinfo/xorg-driver-geode We now have all known information surrounding the AMD Geode X.org driver in a centralized place on this Wiki page.  A new public discussion list was also created to centralize development, testing and debugging discussion that was previously balkanized. http://lists.x.org/archives/xorg-driver-geode/2007-December/000000.html Jordan Crouse of AMD wrote this hopeful welcome message to the new list.  It sounds that AMD has limited resources to work on the X driver, but Jordan is now making a good gesture to reach out to the distributions and build a community to multiply his efforts of driver development. Keep up this spirit of community building, Jordan.  Please encourage AMD to be a true community partner. (Comment on this)