JacobPeddicord

Revision 5 as of 2010-03-21 21:48:25

Clear message

Jacob Peddicord

Contact information

Project

  • Project Name: Upstart compatible services-admin

  • Project Description:
    • The previous service administration tool was able to list available services and enable/disable them. I plan to create a new services tool from scratch with a few goals in mind:
      • Ease of use - it should display the necessities needed to manage services, while not getting too technical
        • (though some technical knowledge is assumed if a user is messing around with services)
      • Properly secured using PolicyKit

      • Compatibility with Upstart and old-style SysV scripts
      • Configurable - should be able to change properties of services and reload them
      • Package and Launchpad integration - provide methods to uninstall the services' package and to report a bug on it
  • If you would be willing and able to do other projects instead, which ones?
    • Clipboard improvements would be another idea that interests me, having been a victim of the "copy, close, paste, realize nothing happened" model.
  • Why did you like this idea?
    • Upstart has replaced nearly all of the old boot scripts from /etc/init.d with newer, more concise jobs in /etc/init. The syntax of these files is easy to read, but powerful. That's the same idea in mind here: there should be an easy to use but powerful tool around to manage both Upstart jobs and older SysV scripts. It seems like something that would complement Upstart nicely.

      In addition, I'm a server administrator myself and have messed around with Upstart & boot scripts. I'd love to be able to bring this functionality to the desktop in the form of a nice interface.

  • Please describe a tentative project architecture or an approach to it:
    • There are a few main components that make up this idea:
      • Backends - One common internal API should be used for managing services. This could be accessed using PolicyKit. Two backends would then be used:

        • upstart - managed using dbus
        • sysv - managed via /etc/init.d/ scripts and the service command

      • Management - Services should be able to:
        • be stopped & started

        • be restarted
        • change whether they run on boot
        • have their configuration reloaded (backend-dependent)
        • send other custom signals depending on the service
        • possible for a dependency tree to be calculated for upstart jobs
      • Configuration - To configure service properties, I've thought of a few ideas. One that would most likely work out would include shipping configuration "description" files, either with this project or with service packages themselves. These files would include information on:
        • Variables available for configuration and their types
        • Possible values/constraints
        • Where the actual configuration file(s) is/are stored
        • What needs to happen once the configuration is changed (force-reload, restart, etc)
        • Possibility to launch an external application to configure a service (big maybe here)
      • Package integration - Poll dpkg for information on which package owns a particular service
        • Provide an option to uninstall that package (via aptd or synaptic)
        • Ability to report a bug on that package for a specific service via apport & ubuntu-bug

  • Give us details about the milestones for this project
    • First milestone
      • Interface skeleton should be designed
      • Upstart backend should be functioning
      • Services should be able to be disabled/enabled/stopped/started/restarted
  • Why will your proposal benefit Ubuntu?
    • Both Mac OS X and Windows offer system utilities to administer services. Ubuntu used to, though with a rather limited applet. Having a full-fledged but easy-to-use application to administer and configure services would greatly benefit the user experience.

      The use of a graphical application would free up the need to use the terminal to configure services. It would make configuration quicker and safer. Instead of needing to launch a root editor to change a setting, a user would only need to set some options in a PolicyKit-managed application. It would make Ubuntu look more friendly to both the tweaking end-user and to the enterprise market, since many businesses may want to be able to easily disable services and set policies on what can be run.

Open Source

  • Please describe any previous Open Source development experience
  • Why are you interested in Open Source?

Availability

  • How long will the project take? When can you begin?
  • How much time do you expect to dedicate to this project? (weekly)
  • Where will you based during the summer?
  • Do you have any commitments for the summer? (holidays/work/summer courses)
  • Please designate a back up student (in case you need to withdraw your application)

Other

  • Have you ever participated in a previous GSoC? (describe your project)
  • Have you applied for any other 2010 Summer of Code projects? If yes, which ones?
  • Why did you apply for the Google Summer of Code ?
  • Why did you choose Ubuntu as a mentoring organisation?
  • Why do you want to participate and why should Ubuntu choose you?