Thursday, September 29, 2011

Managing menus in Edubuntu for LTSP fatclients

While one might imagine it would be a simple thing to delete a few games from the computer menu, such was not the case.  One solution that was great but is currently full of bugs is Sabayon--it needs constant update and it doesn't get it.  A solution that was more efficient but just designed for menu management is Edubuntu menu-editor is working in Lucid, but appears to not work well with the Games menu for specific reason.  The approach I used successfully and document below is a combination of edubuntu menu-editor and deleting applications.  Thanks to Hyperbyte for a great link, mgariepy for help with menueditor and alkisg for help deleting files (not as easy as it sounds).

Using Edubuntu menu-editor with fatclients
This is difficult because one has to use the menu editor while sitting at the fatclient, create the profile, associate it with the group you want it associated with, and finally unpack the tarred profile into the chroot in the right place and more the .listing file to the correct place as well. [arg! the following is white background because it was copied from my googledoc I use as my tech log--oh well.]
  1. At the fatclient opened Applications/system/Edubuntu menu editor and made a profile where no games were active, called the profile mrgg.
  2. Went to System>Administration>Edubuntu menu editor--Profile manager
  3. Imported the mrgg profile and associated it with the group: testg1.
  4. I edited the /etc/desktop-profiles/testg1-mrgg.listing and removed the group name from the top and bottom (XDG_DATA and XDG_CONFIG) lines.  I did this since I wanted it applied to ALL users, irrespective of their group.  just left the semi-colons delineating the fields of info.  Looks like this (note the ;; this had the group name testg1)
    1. XDG_DATA-testg1-mrgg;XDG_DATA;/etc/edubuntu-menueditor/mrgg/share;10;;#This file is managed by ProfileManager, Do not edit by hand
      XDG_CONFIG-testg1-mrgg;XDG_CONFIG;/etc/edubuntu-menueditor/mrgg/xdg;10;;#This file is managed by ProfileManager, Do not edit by hand
  5. Still on the fatclient I cd’ed to the chroot with cd /opt/ltsp/i386/etc/edubuntu-menueditor/ and made a folder in which to untar the profile: sudo mkdir mrgg
  6. Then I cp the mrgg tar to /opt/ltsp/i386/etc/edubuntu-menueditor/mrgg and extracted it while in the .../edubuntu-menueditor directory with: sudo tar -xzvf mrgg/
  7. I cp the profile.listing file (testg1-mrgg.listing) to the chroot: sudo cp /etc/desktop-profiles/testg1-mrgg.listing /opt/ltsp/i386/etc/desktop-profiles/
  8. updated the image, rebooted and the education and internet menus were as I had configured, presenting a simple list of necessary apps and nothing more--very nice!...
  9. but the games menu was untouched!  Next to get rid of the unwanted games...
Deleting the games
  1. To remove the games I got this command: "sudo apt-get remove gnome-games-common gbrainy" from here.  It worked great, however...
  2. that still left 2 games “Potato Guy” and Ri-Li so I tried entered the chroot with: sudo ltsp-chroot -c -p and typed: sudo apt-get remove ktuberling (the package name of potato guy) BUT, this also wanted to remove ubuntu-edu-secondary.  Not good.  I knew there were a lot of apps I liked in that package.
Removing individual applications that are part of a package
  1. Instead of removing the apps I could have made them non-executable with chmod -x $(which ktuberling) 
  2. Another approach is to find out what the package ubuntu-edu-secondary contains, then by “installing” all these apps separately will mark them all as “manually installed” so removing  the package ubuntu-edu-secondary will not remove any of the apps.  Finally, I just need to remove the 2 games, leaving everything else.  This is what I did:
    1. apt-cache show ubuntu-edu-secondary | egrep '^Depends|^Recommends'
    2. and it will show: Depends: dia-gnome, inkscape, kalgebra, kalzium, kbruch, kig, kmplot, kstars, ktouch, ktuberling, kturtle, kwordquiz, marble, parley, qcad, ri-li, step, vym
    3. apt-get install dia-gnome inkscape kalgebra kalzium kbruch kig kmplot kstars ktouch ktuberling kturtle kwordquiz marble parley qcad ri-li step vym Marks them as manually installed.
    4. Now I can sudo apt-remove ktubering, and even though it also removes the package ubuntu-edu-secondary, it removes none of the included apps.
    5. And finally I also sudo apt-remove ri-li and I am done!  All menus are as they need to be!

Thursday, September 15, 2011

Using sch-scripts (Classroom Administrator) on a fatclient

sch-scripts was designed to be run on the ltsp server, but can also be run on its thin clients as well.  So, to make it work on fatclients one may use the 'new' ltsp command: ltsp-remoteapps.  But, it needs to be used as a superuser and the ltsp-remoteapps doesn't forward back the authentication prompt i.e. you can't say: ltsp-remoteapps sudo sch-scripts.  Here is the corresponding part of the #edubuntu dialog:

: dgroos: I want to install sch-scripts into the new fat client on which I'm working.
: dgroos: The image is on the server I used last year though I did delete the thin client image.
: dgroos: I already installed the client and am wondering about the server sch-scripts app.
: dgroos: How can I launch it if I can't gain super-user permissions?
: dgroos: (I saw you say on a forum that you can't sudo with fat clients).
: alkisg: dgroos: the sch-scripts client connects to the sch-daemon network service through a server socket in /var/...
: alkisg: A fat client doesn't have access to that socket
: alkisg: So, even if you could sudo, you wouldn't access the sch-daemon, so sch-scripts wouldn't work
: alkisg: So the teacher needs to either sit on the server, or on a thin client
: alkisg: The sch-scripts GUI won't work if it's ran from a fat client
: alkisg: So, the best you can do, is to ssh -X or vnc to the server, and run sch-scripts from there. Or to use a thin client for the teacher. Or something similar.
: dgroos: That was it--I thought you were running it from a fat client but it was from the server...
: alkisg: Or to use remoteapps
: alkisg: Maybe that last is the best option
: dgroos: hmmm remoteapps--I'll look it up.  Thanks!  I'll come back with a question, perhaps
: alkisg: dgroos: markit wants to sponsor an i18n sch-scripts version, we may have a new i18n sch-scripts version soon
: dgroos:  congrats and great and thanks!
: dgroos: alkisg: and, if I can help with the translation en_us let me know, I'd like to help.
: alkisg: dgroos: very nice, I'll tell the other dev doing the i18n to send you the translations for proof-reading
: alkisg: As our english of course are not good enough for main language
: dgroos: also, I could help during the end of Dec with Spanish as I'll be with my Guatemalan-inlaws who could help.
: dgroos: I say again yer English is good very! than mine.
: alkisg: Sounds good too, but it might be better for the first spanish teacher that actually uses the program, to do the translation too
: dgroos: sure.
: alkisg: (translations need maintanance over time, as anything else in the software world)
: dgroos: (as I experienced!  Just let me know)
: dgroos: I've had no luck finding any info on how to use ltsp-remoteapps.  Do I just type: "ltsp-remoteapps sch-scripts"?
: alkisg: You also need some lts.conf setting about remoteapps
: alkisg: Let me find the exact name...
: alkisg: REMOTE_APPS=True
: alkisg: And you'll need to do something about the sudo part
: alkisg: (sudo sch-scripts, might not work with remote apps and need to edit sudoers instead)
: dgroos: In some list-server e-mails Todd O' wrote the following about using fat clients: "I was able to get root access by doing:"
: dgroos: $ sudo chroot /opt/ltsp/amd64 passwd -u root
: dgroos: $ sudo chroot /opt/ltsp/amd64 passwd
: dgroos: and setting the password.
: dgroos: does that relate?
: alkisg: dgroos: the clue here is "you almost never need sudo on fat clients"
: alkisg: Let's start there. WHY do you need sudo?
: dgroos: Quoted from above: "alkisg: (sudo sch-scripts, might not work with remote apps and need to edit sudoers instead)"
: alkisg: On the server
: dgroos: just trying to make sense of that statement...
: alkisg: Ah ok let me explain more
: alkisg: If you were sitting on the server and tried: sudo sch-scripts, what would happen?
: alkisg: You'd get a password prompt
: alkisg: Remoteapps unfortunately won't allow a text-based prompt etc
: alkisg: So you'll need a way around that problem
: alkisg: With sudoers, you can configure certain users or groups to be able to run "sudo sch-scripts" without the need of a password
: alkisg: All this on the server
: alkisg: So, when you try "ltsp-remoteapps sudo sch-scripts", you won't get a password prompt from the server, and it'll just run
: alkisg: Makes a bit more sense now?
: dgroos: got it.  So how might I find a how to about setting this up?
: dgroos:
: alkisg: Let me give you my greek page, I think google translate will be enough...
: dgroos:
: alkisg:
: dgroos: Thanks!  (of course our district has a filter on that page because of 'proxy avoidance' but I'll find a work around!)
:alkisg: Basically it's this:
:alkisg: sudo VISUAL=gedit visudo
:dgroos: interesting--I put it into google translate and it went through
:alkisg: And in the end of the file:
:alkisg: teacher ALL=NOPASSWD: /usr/sbin/sch-scripts
: alkisg: Haha google rocks
: dgroos: so I can put this line several times: teacher ALL=NOPASSWD: /usr/sbin/sch-scripts  but just using a different name for the different teachers?  Do you think there will be issues if  teachers are using this concurrently?
: alkisg: You can use a group there instead if you prefer, but yeah of course you can put it several times
: alkisg: I think groups need a % in their name (syntax-wise)
: alkisg: The sch-scripts daemon is designed to have as many GUI connections as you like
: alkisg: So not a problem for concurrrent users
: dgroos: I'll put this dialog on my blog for future reference, thanks
: alkisg: So it would be:
: alkisg: %teachers ALL=NOPASSWD: /usr/sbin/sch-scripts

Monday, September 12, 2011

Making Lucid authenticate via district LDAP/Active Directory servers and make home folders

Success!  After years of effort (semi-literally), students now authenticate while sitting at their LTSP fatclients to our district LDAP!  The first time they log in, it also creates a home directory for them on the local server.  Here's what I did (but don't follow these directions blindly--it would be a bummer if your system was different and somehow you got locked out of your system and you had to open things up with a live disk and then troubleshoot).

I spent several days reading up and testing on a test setup at my house.  I did try winbind and I did try webmin and though the latter was very good, it wouldn't take me all the way, therefore I finally ended up using likewise-open which worked great.  Of course the following description doesn't tell the few-day long side journeys I made.  So, based on my long-journey success (thanks go out to Doug Roberts with the MPS!) I then set out to make this work on my other server.  As you can see in the following notes it didn't go via simple recipe but it wasn't too hard, just long.
  1. I started by following the CLI directions on this page:  It was very easy for me to follow, though it didn't include directions on how to make the file (just use the command sudo touch) nor that most all of the commands should be done with sudo.  I also added a few notes to give more details as needed...
    1. While installing the files mentioned in the first directions on the page referenced above, a package configuration screen--"ldap-auth-config" showed up, this is how I answered each screen:
      1. (As recommended on various web pages, I deleted the default ldapi:/// set value on the first page to ldap://
      2. Next I set the search base to the tree containing the students: OU=Buildings,DC=education,DC=mpls,DC=k12,DC=mn,DC=us
      3. I guessed at the LDAP version as 2... (later changed to 1)
      4. I said "No" to make local root Database admin
      5. I said "No" to 'does the LDAP database require login'
      6. There was no 6... but I did get a warning which I ignored: update-rc.d: warning: libnss-ldap start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (none)
    2. Oops, recognized I made a typo and had to redo the ldap-auth-config 5 steps above with: sudo dpkg-reconfigure ldap-auth-config
    3. To make the home folders I continued on the instructions on the above mentioned page...
      1. After making the page/script and running sudo pam-auth-update it took me to another package configuration page and I made sure that every item had an asterisk  before it, EXCEPT: "Winbind NT/Active Directory authentication".  The AD authentication will be done soon with likewise-open.  This step makes sure that all of these methods would be used in the authentication process.
    4. For local groups I checked what a non-privledged user had on my server and made sure to include them all on the last line of the /etc/security/group.conf file, suchly: *;*;*;Al0000-2400;adm,fax,tape,dip,video,plugdev,fuse,audio,cdrom,dialout,floppy
    5.  That is all the further I needed to go on that page, skipping everything after "LDAP Host Access Authorization".
  2.  To get the most correct likewise open I added the likewise key with: sudo apt-key adv --keyserver --recv-keys AAFDD5DB, the sudo apt-get update the sudo apt-get install (arg! I found later that I should have done: 
    1. sudo aptitude update
      sudo aptitude safe-upgrade
  3. I followed the very good directions on this page:
    1. did sudo apt-get-install likewise-open
      1. again it went into the package configuration screen and...
      2. I just left the screen blank as I don't need kerberos...
      3. It went through a verbos process that didn't mean any errors, no worries...
    2. then did sudo apt-get install likewise-open-gui
    3. I double checked that /etc/ldap.conf had the correct base (about 10 lines down) and it did.
    4. The main command to interact with the likewise software is: /usr/bin/domainjoin-cli
    5. So, to join the district's domain I: 
      1. sudo domainjoin-cli join (that's all on 1 line...)
      2. When asked I typed in the user's password.
    6. I got the message: SUCCESS (you should reboot before going on...) so I did...
  4. Now I did some likewise-open configs to make it so that:
    1. students can log in with just their username and not DOMAIN\username
    2. Change the automatic location where the home directories will be created.
  5. Follow the directions here:  This explains a bit the process of updating the .reg (aka registry) file (skip the install--we already did it).  It uses .reg files instead of .conf files like the previous versions of likewise-open.  Thus, the .reg files have to be checked out, edited, then checked back in. 
    1. in the post the person describes how to make it so that a person can log in with just their username, not needing DOMAIN\username (with setting, in two places: "AssumeDefaultDomain"=dword:00000001)  But before saving this and doing the 2 commands after that, instead...
    2. Change the line from: from likewise's default location....  "HomeDirTemplate"="%H/likewise-open/%D/%U"     to: "HomeDirTemplate"="%H/ad/%U"  (I had to change this in 3 or 4 places.)  The %D means the domain name.
  6. And... logging in with just username didn't work.  So, I checked out the /etc/ldap.conf file with the working machine, found discrepancies, and changed them to the good setting:
    1. current had: uri ldap:// and the good had uri ldap://
    2. current had: ldap_version 2 and the good had ldap_version 1
  7. Current didn't have values for so change to good values: nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,couchdb,daemon$
    bindpw [my ldap password here]
    scope one
    tls_checkpeer no
  8. Still didn't work so then I purged winbind via NX and synaptic... then restarted, still didn't work, then...
  9. check step 2 above--didn't do the upgrade thing! figured that after adding the new ppa, then updating then upgrade it would get me the new likewise-open but had to follow directions as shown in parens in step 2! but that didn't work.  next...
  10. I went to webmin, clicked on unused modules, then clicked on "LDAP_Client", clicked on configure, set the file to /etc/ldap.conf and saved it.
  11. Then, clicked on the last icon, the LDAP Browser and it said: The LDAP browser cannot be used : The Net::LDAP Perl module needed for talking to the LDAP server is not installed. Click here to have Webmin download and install it now
  12. yes I did this, (and in webmin changed the tree depth to entire tree but don't think that was it since the other setup doesn't require it... 

Monday, September 05, 2011

The new 4-computers per table design...

Ideally, the tables support 4 students with independent access to computers, ie, 1 computer per student.  Therefore, this shows the idea on how to place all the hardware in the space of the table.  This is a top view showing the SFF computers (those are the smaller 'squares').  

The next larger square, the one centered in the middle, is a piece of masonite, 2 ft square.  This hides all the cables in the middle, and also supports the flat panel displays.  The 5 inch diameter hole in the middle serves as an escape route for the heat generated--it will probably need a fan built into it to let sufficient heat escape.  

The flat panel monitors rest exactly above the computers.