StudentControlPanelSpec

Differences between revisions 5 and 7 (spanning 2 versions)
⇤ ← Revision 5 as of 2006-10-22 11:40:14 →
Size: 6438
Editor: 84-45-238-195
Comment:
← Revision 7 as of 2006-11-07 23:15:29 → ⇥
Size: 7463
Editor: 207
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
Roadmap for upgrading the implementation of student-control-panel Roadmap for bringing more functionallity into student-control-panel
Line 14: Line 14:
To control LTSP connections in a school environment, an application that interacts with the ltsp server and the clients is needed. An initial implementation of this application tailored for the Ubuntu LTSP implementation called student-control-panel was uploaded to dapper. It currently implements basic connection control: it shows a list of the users and the ip each client they are using, allows the administrator to cut the connection for one, more or all users, and can show the currently running processes of a single user.
The current scope is to control a standalone LTSP server, in case we start to implement clustering and the like, a network aware backend has to be implemented in a future version of student control panel.

More features are needed to provide a full student control application for school environments.		 Student control Panel is an application to control LTSP client conections on a standalone edubuntu server. It was first introduced in edgy on the edubuntu CD and is installed by default in the edubuntu classroom server. The spec for edgy done in paris wasnt completely implemented and additional requirements have come up from the users. this spec describes the advanced needs for the program like working with multiple servers, filter options for the userlist, screen sharing and deep vnc integration as well as removing the edubuntu branding to make it a rather generic LTSP connection control tool.
Line 21: Line 18:
Dr. Miller teaches biology in an ltsp equipped class. He has several students he suspects to secretly browse the web while he is not looking. Using student-control-panel he can monitor the students desktops via vnc to see if his suspicion is true. Dr. Miller teaches biology in an LTSP equipped class. He has several students he suspects to secretly browse the web while he is not looking. Using the "Class overview" button in student-control-panel he is able to get a fullscreen view of tiled small VNC windows for the whole class to monitor the students desktops.
Line 23: Line 20:
Miriam teaches about free software in a class that uses a ltsp setup. She wants to demonstrate several free software apps she wants to start up on all students desktops. She hits ctrl-a to select all students in student-control-panel and clicks on the execute button which brings up a dialog to execute a command on all selected desktop simultaneously. Miriam teaches about free software in a class that uses a LTSP setup. She wants to demonstrate several free software apps she wants to start up on all students desktops. She hits Ctrl-a to select all students in student-control-panel and clicks on the execute button which brings up a dialog to execute a command on all selected desktop simultaneously.
Line 25: Line 22:
Anselmo has one student he doesn't want to be able to access the commandline from his desktop, since this specific student is known to write harmful scripts. Anselmo right clicks on the student's name in student-control-panel and selects the lock down option there. Pessulus, the gnome lockdown editor pops up and Anselmo checks the "Disable Commandline" checkbox. Anselmo is school administrator and has several classes that connect to the LTSP server at the same time. He gets a call from the biology teacher who wants all his students to be locked out. To be able to administer only a single class, he uses the predefined filter from the pulldown filter menu in the gui he has set up earlier and manages the task.
Line 27: Line 24:
Michael has several students who are not listening in his lesson, he presses the lock button from within student-control-panel and is able to lock the students keyboards and mice Michael has several students who are not listening in his lesson, he presses Ctrl-a to select all students, clicks the lock button from within student-control-panel and the students desktops are all locked with a blank screensaver.
Line 31: Line 28:
Easy handling of student LTSP connections on a single LTSP server. Enhancement of the easy handling of student LTSP connections on a single LTSP server.
Line 35: Line 32:
=== Plugin framework upgrade === === Multiple server control ===
Line 37: Line 34:
 * The current student-control-panel plugin framework allows for server side only plugins. It would be advantageous to provide both server side and client side plugin components. The current framework uses a single class with a register function stored in a python module file. The proposed idea would be to modify the dbus routines to allow information to be passed back from the client to the server. This would then allow much more complex plugins to be created, such as chat programs and initiation of simple file transfers.

 * Many of the new proposed features could then be implemented over this plugin frame work

=== Update of GUI ===

 * Updating of many of the GUI elements of the current SCP such as
  * Button alignment
  * Simple/advanced for running application
  * Icons added to process window
  * Drop banner
  * Add menu / toolbar		  * The backend code will be split out to a commandline module. All functions currently called internally by the gui will be directly callable, i.e. the current populate_userlist function will return the userlist to stdout instead of feeding the gui treeview. The gui will in return be able to read key->value pairs in the above example that would be userlist="user1,user2,...". Since student-control-panel is designed to manage LTSP ssh connections, we can rely on a running ssh server and use ssh for the transport ... a dedicated student-control-panel user will be created on install for whom a ssh key_id will be generated from the postinst script of the package. if remote access is desired, this key_id needs to be copied to the master server into the ~/.ssh/authorized_keys file. The gui part, if called with the yet to implement --server <IP> parameter will then establish an ssh tunnel and execute the backend as if it were locally connected.
Line 52: Line 38:
 * Creation of a gnome applet that will act as an assistance helper for users. They will be able to click and ask for assistance. Possibly also used to drag and drop answers for a teachers specified question.  * A notification area icon will be added to the LTSP users session that is able to send messages via the already implemented dbus interface to the teacher (currently thats only possible from the teacher to the client, this applet will work in the opposite direction). If a user clicks on the icon, an input window with text input field and "Send" button pops up. If the user enters something in the input field and cliecks the send button, the teacher gets a notification about that on his desktop if he's logged in.
Line 56: Line 42:
 * A system for locking keyboards and mice, as well as blanking a workstation would be a good idea. This could simply be achieved by starting the xscreensaver program on the clients machine but running as a different user. This would allow the password to be unknown to the client and the process could then be killed automatically by the server on removing the blank/lock restriction.  * Through the existing remote execution capability of student-control-panel it is possible to texecute commands in the users session. Currently teachers hit the execute button and enter gnome-screensaver-command --lock to lock the clients screen on demand. A shortcut button that does this directly will be added to the gui.
Line 60: Line 46:
 * It has been recognised that SCP has applications outside of the school/education setting. It is proposed to rename the package and give it a more generic feel.  * It has been recognised that SCP has applications outside of the school/education setting. It is proposed to rename the package and give it a more generic feel by removing the edubuntu branding from the GUI.

=== Filter functionallity of the userlist ===

 * A toolbar will be added to the top of the GUI window that will have filtering functions for the userlist.

 * The above mentioned toolbar will also add the opportunity to assign a student to a group, this user->group relationship will be stored in a textfile that builds the base for a per-group filtering. Every time student-control-panel starts or the file gets changed by a teacher the file will be read and a pulldown menu located in the toolbar will be filled with the defined groupnames.
Line 74: Line 66:
=== To be written ===

 * sharing screen -> exec vnc on the clients desktop connected to your session
 * mini vnc preview in the userlist
 * tiled vnc overview of the complete class on demand

Summary

Roadmap for bringing more functionallity into student-control-panel

Rationale

Student control Panel is an application to control LTSP client conections on a standalone edubuntu server. It was first introduced in edgy on the edubuntu CD and is installed by default in the edubuntu classroom server. The spec for edgy done in paris wasnt completely implemented and additional requirements have come up from the users. this spec describes the advanced needs for the program like working with multiple servers, filter options for the userlist, screen sharing and deep vnc integration as well as removing the edubuntu branding to make it a rather generic LTSP connection control tool.

Use cases

Dr. Miller teaches biology in an LTSP equipped class. He has several students he suspects to secretly browse the web while he is not looking. Using the "Class overview" button in student-control-panel he is able to get a fullscreen view of tiled small VNC windows for the whole class to monitor the students desktops.

Miriam teaches about free software in a class that uses a LTSP setup. She wants to demonstrate several free software apps she wants to start up on all students desktops. She hits Ctrl-a to select all students in student-control-panel and clicks on the execute button which brings up a dialog to execute a command on all selected desktop simultaneously.

Anselmo is school administrator and has several classes that connect to the LTSP server at the same time. He gets a call from the biology teacher who wants all his students to be locked out. To be able to administer only a single class, he uses the predefined filter from the pulldown filter menu in the gui he has set up earlier and manages the task.

Michael has several students who are not listening in his lesson, he presses Ctrl-a to select all students, clicks the lock button from within student-control-panel and the students desktops are all locked with a blank screensaver.

Scope

Enhancement of the easy handling of student LTSP connections on a single LTSP server.

Design and Implementation

Multiple server control

  • The backend code will be split out to a commandline module. All functions currently called internally by the gui will be directly callable, i.e. the current populate_userlist function will return the userlist to stdout instead of feeding the gui treeview. The gui will in return be able to read key->value pairs in the above example that would be userlist="user1,user2,...". Since student-control-panel is designed to manage LTSP ssh connections, we can rely on a running ssh server and use ssh for the transport ... a dedicated student-control-panel user will be created on install for whom a ssh key_id will be generated from the postinst script of the package. if remote access is desired, this key_id needs to be copied to the master server into the ~/.ssh/authorized_keys file. The gui part, if called with the yet to implement --server <IP> parameter will then establish an ssh tunnel and execute the backend as if it were locally connected.

Assistance Applet

  • A notification area icon will be added to the LTSP users session that is able to send messages via the already implemented dbus interface to the teacher (currently thats only possible from the teacher to the client, this applet will work in the opposite direction). If a user clicks on the icon, an input window with text input field and "Send" button pops up. If the user enters something in the input field and cliecks the send button, the teacher gets a notification about that on his desktop if he's logged in.

Blank / Lock Workstations

  • Through the existing remote execution capability of student-control-panel it is possible to texecute commands in the users session. Currently teachers hit the execute button and enter gnome-screensaver-command --lock to lock the clients screen on demand. A shortcut button that does this directly will be added to the gui.

Generalisation of SCP

  • It has been recognised that SCP has applications outside of the school/education setting. It is proposed to rename the package and give it a more generic feel by removing the edubuntu branding from the GUI.

Filter functionallity of the userlist

  • A toolbar will be added to the top of the GUI window that will have filtering functions for the userlist.

  • The above mentioned toolbar will also add the opportunity to assign a student to a group, this user->group relationship will be stored in a textfile that builds the base for a per-group filtering. Every time student-control-panel starts or the file gets changed by a teacher the file will be read and a pulldown menu located in the toolbar will be filled with the defined groupnames.

Remote desktop access

  • Student Control Panel will use vnc for remote desktop access. A function using the vncclient package is already completely implemented in the current student control panel code but disabled in the GUI since the handling on the LTSP client side wasn't clear yet; we will now fix that by adding a vnc server application (x11vnc) to the LTSP client chroot.
  • For the client implementation the x11vnc package will have to be installed in the client chroot.
    • The package will get a preseedable debconf option (suggestion: ltsp-client-mode), if this option is set to true, the postinst script installs an initscript which starts x11vnc connected to localhost:0 at boottime of the client and makes it read a custom password from a file thats located in the client chroot.
    • Student Control Panel will generate this password dynamically on every startup of the Student control Panel GUI (using PASSWORD=$(pwgen -c -n -s 20 1) should suffice here) and rewrite the password in the file. Since x11vnc reads the password on every new connection from that file it *could* affect existing Student Control Panel sessions. Because of this Student Control Panel will not start if there is already a running instance but spill a warning to first close the old one.
  • Since we dont want to run apt-get install from Student Control Panels postinst script in the LTSP client chroot, we can't just install x11vnc at install time of the student-control-panel package.
    • A "first start popup window" will be added to the GUI, with a checkbox "Dont show this window again" and a button "Install remote desktop access".

    • Choosing the latter option will execute a script /usr/share/student-control-panel/install-client-vnc.sh which will run  apt-get install x11vnc  in the LTSP client chroot with the above described option preseeded.

To be written

  • sharing screen -> exec vnc on the clients desktop connected to your session

  • mini vnc preview in the userlist
  • tiled vnc overview of the complete class on demand

Outstanding issues

  • Determine the best default options (compression, scaling of the windowsize etc) for x11vnc to be added to the initscript by user feedback during developent.

CategorySpec

StudentControlPanelSpec (last edited 2009-07-24 03:09:44 by 201)