##(see the SpecSpec for an explanation) ''Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.'' * '''Launchpad Entry''': UbuntuSpec:ltsp-software-management * '''Packages affected''': == Summary == Altough there are ways to add icons and menus to a user or group profile, there is (maybe) need for some kind of software repository, from which teachers and other educators can choose to add certain programs to a user or group profile. These could be programs installed via the standard apt-get method, or via other means. The admin tool of gcompris is a possible example of what I have in mind. user and group profiles should not rely on system users and groups. Preferably that should be an LDAP backend, while other backends should be possible too. == Release Note == * None. == Rationale == * Teachers need a very simple way of adding (prepackaged) software to user and group profiles. == Use Cases == * Sonja is a teacher of children age 4-6. She has 30 children in her class, but only 2 thin clients, which are connected to a school wide LTSP installation. For each student, she creates a profile. Students can, in the beginning of the year, only access one application. There is no need for panels, menus, desktop icons and the like. She wants the application to start full-screen whenever one of her students log in. If the student somehow logs out, the student doesn't get a desktop, but goes back to the login screen. * Sonja allows those students that have completed the goal of the initial application, to access another application. It might be that the student is presented with a small menu, from where she can choose these two apps; or it might be that the student can only access the newly added application. In any case, Sonja needs to be able to quickly add one or more application to that users profile. * Tjuri needs unsupported software for his students. In his curriculum, there are some applications that don't run natively under GNU/Linux, but they can be made to run with CrossOver, Wine, Win4Lin, or one of the virtualization platforms like Qemu or Vmware. The System Manager has configured this software on the school server, and all Tjuri has to do is to add the application to a user or group profile. * William H. teaches children from age 6 - 8. He gets all the children that were formerly in Sonja's class. He does not need to recreate all the users from scratch, but he just moves or copies those profiles into his administration panel. He inherits all the software, notes, progress indicators from Sonja's former pupils. * Ada is a System Manager at the school. She needs to update one of the applications. She does so on the server, and all students automatically start using the updated application the next time they login. * Steve is a System Administrator for the school district. He manages 15 ltsp servers spread over various locations. He can access the servers remotely. He needs one central software repository, where the developers constantly add new software packages. The servers troughout the school district notice updates and changes, and synchronize their local repositories with the central server == Assumptions == * None == Design == * There needs to be some packaging mechanism that allows for non-supported software to be easily integrated * Some form of Central Database or Directory is needed, most likely a tree structure like in LDAP * For teachers, some form of Drag and Drop would ease administration * Software may be locally installed or be accessed to a terminal server, vnc server or the like * Maybe zeroinstall can be used for this: http://0install.net/ == Implementation == * Enhance and narrow down the spec. * Choose likely candidates for components, database, programming languages * Follow closely the progress in other specs that deal with student-control-panel, edubuntu-profile-and-network-session-management, ltsp-management-gui, edubuntu-menus-completion and other specs that deal with management issues. === UI Changes === * Choose lightweight desktop where appropriate. * make full-screen applications possible * make sure that if a user is logged out, he or she is going back to the login screen (where appropriate) === Code Changes === * No idea. === Migration === * No idea == Test/Demo Plan == * Make a simplified version of this in Ruby with an LDAP backend and study the feasibility. == Brainstorm == * I see a lot of different needs for different age groups. A kid 12-16 years might need a full desktop (gnome or kde), a private home directory, the possibility to change his or her password, maybe even choose between desktops, running virtual machines, etc etc. On the other had, a kid that can't read or write yet, might need a special way to login to the machine, maybe with autologin (now in ldm) or swipe cards, or rfid, or a special usb stick with a token on it. Kids age 4 need maybe 3 or 4 apps, that teach them some basic computer skills, like mouse handling (gcompris has some nice games for that) and basic reading material. * I think the edubuntu community should, maybe, focus on partitioning the entire ubuntu interface for different age groups, or at least find some way for teachers to enable or disable certain interfaces. * I think, for very young kids, they should switch on the machine and drop into the app that they need at that moment. It should be easy for the teacher to change that app. * I think that locking down with pessulus or making profiles with sabayon is not the logical way to go for the younger kids. Locking down a panel is useless if you only want to present one app, or two apps. What is needed is a way to present two big customized buttons, that are easy recognizable, so a kid can choose easily between the apps it is allowed to use. 2 buttons, 3, 4, whatever is usefull for that age. * I think the system for younger kids should be permissive instead of restrictive, like 'add this app to that user, or group, instead of lock down this this and that. * For older kids, lock down some parts of a full desktop is much more useful. * With the standard LTSP approach, there is a real problem with graphically stupid software, like flash... the only solution I see is running local browsers to make sure the networktraffic is decreased. Local apps and local swap are possible already. Just make it easier and more standard to run stuff locally. * Thinking of larger (worldwide) deployments, systems like 0install are interesting. A teacher can go to the website of some new app, copy the URL into the admin interface, and voila, it gets installed on the server. This opens up a whole range of educational software/content providers to participate in edubuntu. * the 'screen-scripts' in ldm are a great way to realize some of this stuff. == Outstanding Issues == == BoF agenda and discussion == ---- CategorySpec CategoryEdubuntuSpec