EboxSpec
|
Size: 3681
Comment:
|
Size: 3805
Comment: Updated implementation plan
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| * '''Packages affected''': | * '''Packages affected''': openldap, samba, ntp-server, dhcp3-server, openvpn, network-manager-openvpn |
| Line 17: | Line 17: |
| EBox fill a huge gap in our Ubuntu Server offering. It provides easily configurable file and printer sharing, jabber service, ntp server, dhcp server, vrtual mail server, openvpn server, and other things we may want to add to it later. We have all these things already, but setting them up is difficult to new users. | EBox fill a big gap in our Ubuntu Server offering. It provides easily configurable file and printer sharing, jabber service, ntp server, dhcp server, vrtual mail server, openvpn server, and other things we may want to add to it later. We have all these things already, but setting them up is difficult to new users. |
| Line 26: | Line 26: |
| Line 29: | Line 28: |
| The packages will be based on the debian packages provided by the ebox developers themselves. Great care must be taken to make sure that any existing openvpn, samba, ldap, etc. configuration is either imported or at least backed up, so that reverting from an ebox installation will be a breeze. | eBox upstream has tended to consider eBox a server platform by itself, rather than simply a configuration frontend. This means that many things have been implemented by setting up separate instances of services with separate configuration files, etc. (e.g. LDAP data was kept in /var/lib/ebox/ldap). Also, when removing eBox, the system was back to the way it was before eBox was installed. We will be working towards making eBox work as more of a configuration frontend for the existing system services, so that eBox could be dropped in, used to configure stuff, ripped out, and everything will keep running. |
| Line 31: | Line 30: |
| An extra option will be added to the bootsplash (Install Ebox server). This would allow us to preseed things like network configuration since that is much more elegantly handled by ebox than by d-i. | To comply with Debian Policy certain changes must also be made.. When first enabling a new module in eBox it must ask the user if it's ok to overwrite his existing configuration. Also, if the user has made changes to his configuration since eBox last wrote it, eBox must it obvious to the user that his configuration files are about to be overwritten (or at least edited). With regard to installation, an extra option will be added to the bootsplash ("Install Ebox server"). This would allow us to preseed things like network configuration since that is much more elegantly handled by ebox than by d-i. |
| Line 39: | Line 40: |
| Ebox hijacks configuration files. For some of them, it imports the existing configuration, for others it just overwrites things. When overwriting, we should grab a backup (which will be restored when the ebox modules is removed again). In each configuration file managed by ebox, there will be a warning saying that the file is managed by ebox and any changes *will* be lost. There should be a reference to the templates used to generate the config file, so any local changes can be added to the templates. |
eBox has a mechanism for importing existing configurations. This should be thoroughly tested to make sure that eBox does not break things that already work. Also, the user must acknowledge that eBox is about start managing a service. |
| Line 52: | Line 51: |
| * Replace apache-perl (eek) with apache2.2 with mod_perl. ** Investigate how this affects reloading of modules, etc. * Figure out the order in which stuff needs to be done in the postinst script, and make it so. Leave gconf stuff to dh_gconf. * Replace ebox's init script with an upstart job description. * Be painfully sure that no existing configuration is overwritten. ** Ebox should work with a default postgresql config. If the user has deviated from the default postgresql config, it's HIS fault. Never try to override it or fix it. The process it too fragile. * Make ebox work without password authentication against postgresql. |
* Replace sudo with userv * Figure out how to handle complex (e.g. Samba) configuration (only changing the minimal necessary to achieve what the user asked in the eBox ui is practically impossible) * Be painfully sure that no existing configuration is overwritten without the user's consent. |
| Line 60: | Line 55: |
| * Upload the entire thing to Universe. |
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: ebox
Packages affected: openldap, samba, ntp-server, dhcp3-server, openvpn, network-manager-openvpn
Summary
Package ebox (http://www.ebox-platform.com/) for Ubuntu and provide it as an easily accessible installation option on the server cd.
Release Note
This version of Ubuntu features a new Ebox install option. Put in the server CD, select the Ebox option and just wait. You'll be greeted by a web interface allowing you to set up network and install other services.
Rationale
EBox fill a big gap in our Ubuntu Server offering. It provides easily configurable file and printer sharing, jabber service, ntp server, dhcp server, vrtual mail server, openvpn server, and other things we may want to add to it later. We have all these things already, but setting them up is difficult to new users.
Use Cases
- Mark runs a small business. He knows other companies have snazzy ways of sharing files and printers and he wants in on the fun.
Assumptions
Design
Implementation
eBox upstream has tended to consider eBox a server platform by itself, rather than simply a configuration frontend. This means that many things have been implemented by setting up separate instances of services with separate configuration files, etc. (e.g. LDAP data was kept in /var/lib/ebox/ldap). Also, when removing eBox, the system was back to the way it was before eBox was installed. We will be working towards making eBox work as more of a configuration frontend for the existing system services, so that eBox could be dropped in, used to configure stuff, ripped out, and everything will keep running.
To comply with Debian Policy certain changes must also be made.. When first enabling a new module in eBox it must ask the user if it's ok to overwrite his existing configuration. Also, if the user has made changes to his configuration since eBox last wrote it, eBox must it obvious to the user that his configuration files are about to be overwritten (or at least edited).
With regard to installation, an extra option will be added to the bootsplash ("Install Ebox server"). This would allow us to preseed things like network configuration since that is much more elegantly handled by ebox than by d-i.
UI Changes
It would be nice to have ebox more ubuntu-looking.
Migration
eBox has a mechanism for importing existing configurations. This should be thoroughly tested to make sure that eBox does not break things that already work. Also, the user must acknowledge that eBox is about start managing a service.
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
Outstanding Issues (a.k.a. the todo list)
Please do not add anything to this list without asking SorenHansen.
- Replace sudo with userv
- Figure out how to handle complex (e.g. Samba) configuration (only changing the minimal necessary to achieve what the user asked in the eBox ui is practically impossible)
- Be painfully sure that no existing configuration is overwritten without the user's consent.
- Don't have a default ebox password. Rather set it to something random and make it easy to reset from the console.
EboxSpec (last edited 2008-08-06 16:20:54 by localhost)