UbuntuEasyBusinessServer

Differences between revisions 24 and 25
Revision 24 as of 2007-05-28 11:35:04
Size: 13665
Editor: 3e6b503c
Comment:
Revision 25 as of 2007-05-28 14:19:27
Size: 14833
Editor: dsl-148-36
Comment:
Deletions are marked like this. Additions are marked like this.
Line 121: Line 121:
== Existing pro{ject,duct}s === === Existing pro{ject,duct}s ===
Line 125: Line 125:
=== Base on eBox === ==== Base on eBox ====
Line 130: Line 130:
 * Separation between frontend (web interface) and backend (configuration file generation).
 * Uses a template engine for file generation.
Line 133: Line 135:
Line 134: Line 137:
 * It's coded in Perl
 * Its configuration handling is not as graceful as one could wish.

=== Base on Conga ===
 * It's coded in Perl. Uses mason for the template engine.
 * Its configuration handling is not as graceful as one could wish : configuration files are overwritten even if they have been changed outside ebox. The configuration information is stored in an xml file and then configuration files are generated from there.

==== Base on Conga ====
Line 147: Line 150:
=== Do it all ourselves === ==== Do it all ourselves ====
Line 192: Line 195:

Comment by MathiasGug on 2007-05-28 : Related to configuration files generation in ebox : it would be better to detect when configuration files have been modified locally, ie not by ebox. If so warn the user about it and put the configuration file and his corresponding module out of ebox control (make the module unavailable in ebox for example). That way, advanced sysadmins can still administer the server if they don't want to use ebox. As soon as end user start to play with the configuration files directly, it can be assumed that they know what they're doing and ebox should get out of their way.
Yast uses the same approach, which raised some comments from users at UDS Sevilla : they want to have the choice to use Yast (if it suits them) or not (if they need more control).

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.

Summary

This spec describes Ubuntu's Easy Business Server, a configuration utility aimed at making it easy for non-technical businesses set up an Ubuntu based server for various things.

Rationale

The free software universe in general, and Ubuntu in particular, already provides most of the tools and infrastructure components needed to fulfill the needs of small businesses. What we need is good integration between these components and easy configuration.

Use Cases

  • Mark runs a small business and has almost no computer experience. He doesn't want to store the documents he creates on the local PCs and laptops, because those have to be re-installed sometimes when they get viruses. He wants his documents to be safe, and know that everything is backed up as well. So Mark wants a new server but to utilise his existing network infrastructure.
  • Alan has a small business which needs a backend storage for office files. He needs a simple interface to setup and configure the new server he has bought.
  • Soren has been running this software for a year in his small business. He's now grown up and wants to use the user database for authentication on his network. He'd like to be able just set up the clients and ready to go. His guru friends say he should be using interoperable standards like ldap and kerberos. Soren (being a sensible man) agrees.
  • John is a Sysadmin with experience in other Microsoft-Branded OSes. He expects that Ubuntu Easy Bussiness Server brings similar features 'out-of-the-box' as Microsoft-branded OSes. He expects a simple way to connect remotely to the server configured out-of-the-box (VNC will be fine).

Scope

For the first iteration (gutsy release cycle), the following things will have priority:

  • Initial setup (IP address (range), company name, etc)
  • File server
    • Sharing of files
    • Limitation of access to files
    • User based access
  • Print server
  • Incremental backup to an attached USB disk

For Gutsy, "only" the above will be prioritised.

Over time, the following services will be included, too:

  • Groupware
    • Mail server (internal and external)
      • Multiple domains
      • Aliases
      • vacation integration
    • Calendar server
      • Sharing of free/busy schedule
    • Contact Management (Added by gQuigs 2007-3-15)
      • Optional: Storing telephone call information
    • Jabber or IRC server
  • Infrastructure
    • DHCP
    • DNS
    • Time
    • Firewall/Internet gateway
    • VPN

Design

The single most important keyword is simplicity.

The goal is to provide a file and print server that will blow the users away. On the path to file and print nirvana we also find user/group management, so that's included, too.

The interface will be web based and some means of accessing it on the machine's console will be provided.

The interface will in every possible way help the user make good decisions. (E.g. when creating users, the admin will be encouraged to add them to groups (creating those groups in the process) based on the users' functions. This will preempt the need to make this inevitable transition when the company grows to more than 4-5 people.)

While providing a really simple frontend, the backend will set up a system that any experienced admin will find professional and pleasing to work with. (E.g. creating a group will not only add that group to LDAP, but also create a logical volume, format it with XFS, and share it via samba to the members of that group.)

Each user and group will automatically be assigned a storage space on the server as well as given access to a storage space shared among all users.

Printer sharing will include autodetection of any sort of newly available printer (USB, Zeroconf, etc.).

The scope of the project as been narrowed down to a file/print server. These two services, however, will be top-of-the-pops, shiny, no-fuss magic.

Implementation

Installation

  • Either its own CD or a prominently displayed install option on the existing server CD
  • Based on the alternate installer, although network configuration will be preseeded to local-only
  • On completed installation an X-server will be fired up (no desktop!) with a fullscreen web browser (kiosk mode, probably) pointed at the configuration interface.

Administration interface

  • By default the server boots into text mode and a trivial dialog-style app that allows various operations like 'start admin interface' (X/browser) or 'reboot machine'.
  • We want an X server with just a browser (in kiosk mode); it is convenient and reassuring for users and provides a good rescue interface.

Network configuration

  • For the initial use case above we assume that there is a separate router which gives an IP to the server, so that we do not need to worry about network configuration, DHCP, and multiple network cards:

    The Internet <=> DSL Router <=> Network with Server and clients

User management

  • The user database will be in LDAP and Kerberos will used for authentication
    • Rationale: If the environment grows up, they'll have a sensible authentication framework in place already.
  • When creating new users, a list of common groups will be shown suggesting to create them and add the new user to them.
    • This is to help the admin create a sensible user/group scheme right from the start rather than have to migrate to it later.
    • Should it possible for the user then to add additional groups and be able to use the same 'radio' button joining click?
      • This user management interface should be on the server at startup/configuration, but then available through a Web browser with the same fuctionality from a remote machine on the Internal network.
  • Consider using system-tools-backends for this: when teaching it to know about LDAP, we get a problem solved for Edubuntu as well and get coherent handling with desktops; it only has light dependencies which we want for hal usage anyway

File sharing

  • Samba / (CIFS+unix extensions)
  • Everything should be announced via ZeroConf for easy access

    • Only useful for Linux and Apple clients. Samba announces itself anyway through nmbd broadcasts etc.

Backup

  • Backup
    • Focus on an external USB harddrive.
    • rsync? rdiff-backup? rsnapshot!
      • If the system is being considered for future growth and there is time, consider Amanda?
    • Remote backups being provided as a value-add by the vendor of the server/software?
    • -( BackupPC? )-

Printer sharing

  • Make the cups server share them via the network (allows cups clients to see them easily)
  • Announce via zeroconf
  • CUPS alegedly has a postscript driver that can be used.
  • Questions:
    • Which of our existing means of configuring printers can be easily used for this? (Directly or by porting certain bits of it)

Existing pro{ject,duct}s

There a generally three ways to go about this:

Base on eBox

eBox is a free software solution with a similar goal as ours. It provide a long list of services among them are file and print services.

Pros:

  • It has got a long list of working plugins.
  • Separation between frontend (web interface) and backend (configuration file generation).
  • Uses a template engine for file generation.
  • It's based on Debian.
  • It's there.

Cons:

  • It's coded in Perl. Uses mason for the template engine.
  • Its configuration handling is not as graceful as one could wish : configuration files are overwritten even if they have been changed outside ebox. The configuration information is stored in an xml file and then configuration files are generated from there.

Base on Conga

Conga is a RedHat project designed to administer clusters.

  • Pros
    • It's coded in Python
    • Initial review shows what looks like a sound design (master/agent separation, etc.)
  • Cons
    • It's geared towards clusters rather than single machines, which is our use case
    • It's made for RedHat

Do it all ourselves

We could also just start from scratch.

  • Pros
    • We can choose the development platform
    • It's fun!
  • Cons
    • A lot of work!

Screenshots

These screenshots predate the discussion at UDS. Expect major changes! I imagine it will look something like this (these are just mock ups): http://linux2go.dk/uebs-scrshots/mail.png http://linux2go.dk/uebs-scrshots/user.png http://linux2go.dk/uebs-scrshots/users.png http://linux2go.dk/uebs-scrshots/network.png

Data preservation and migration

Unresolved issues

BoF agenda and discussion

Comments

Comment by ArtCancro on 2007-03-15: may I suggest Citadel [http://www.citadel.org] as the groupware component? It would save an awful lot of work because it's got all of the mail and calendar stuff built in.

Comment by PaulKishimoto on 2007-03-20: I added UbuntuServerTasks and AdministerServerViaWebInterface to the related specs list. The former has already been approved, and the creator seems to know something about tasksel, which sounds like it would be useful.

Comment by SorenHansen on 2007-03-20: UbuntuServerTasks (and tasksel) is not quite what I'm after. Those tasks are simply a collection of existing packages. E.g. a web server task would just install apache and a number of interpreters. This spec is more about configuration. AdministerServerViaWebInterface on the other hand looks very similar to this. Interesting.

Comment by PaulKishimoto on 2007-03-22: I'm not a packaging expert, but I suspect .deb install scripts for different groupware packages may interact with each other and modify configuration files. I imagined a use case where Bob installs Ubuntu Server from a CD, chooses certain tasks (ie. package sets), adds the "uebs" package, and then points a web browser at the new server. Several of the tasks in UbuntuServerTasks install the groupware UEBS would configure, so instead of depending on packages directly it could recognizes and enable modules for only those packages which are installed.

I also should have mentioned two blog posts by Herman Bos from Planet Ubuntu: http://dev.osso.nl/herman/blog/2006/12/27/management-framework-2/ and http://dev.osso.nl/herman/blog/2007/01/31/ambition-readjustment/. I'm not sure what you had planned, a client-server model would make it possible to use either the web client or develop a PyGTK client to run on an administrator's desktop. He might have some helpful thoughts on this.

Comment by SorenHansen on 2007-03-22: Yes, postinst scripts might change configurations and whatnot, but that will not be a problem here. When installing uebs, it will "take over" the proper configuration files. Besides, the configuration file handling outlined should mitigate any problems that might arise from other things (possibly a human) changing the configuration files. UEBS will also be modular in nature, so if someone doesn't want certain bits managed, he will just not install the corresponding module. Only when used as an install option (the common use case, I suspect) will all modules be enabled by default. I've also seen Heman Bos' blog posts, but as far as I can tell, we're solving different problems here. That said, there might very well be basis for some cooperation along the way. By the way: Please don't just insert extra spaces here and there unless there's a reason. It's a pain to go through the diffs and try to figure out what was changed. Smile :-)

Comment by EdwardMurrell on 2007-04-13: Have you considered using Kerberos for authentication? NFSv4 practically requires it, and it would mean that you get automagic secure authentication. If you're already implementing DNS and NTP, then you're halfway there. If you need some help on intergrating it with LDAP, I can feed you the work I've done to get it going here.

Comment by SorenHansen on 2007-04-13: This has turned into a Summer of Code project for me. My main focus is going to be on getting the framework together and building all the groupware-like plugins. The target group for this is mostly the not-so-technical bunch of people who want to use Ubuntu as a server, and I think Kerberos is a bit out of scope for them. Nevertheless, there's nothing per se wrong with having a Kerberos plugin available. I can ping you when the plugin API starts to stabilize, then maybe you can work on the plugin your self. Thanks for your input

Please also add jabber and wiki, as both authenticate off of ldap this should be reasonable, also another great addition would be dyndns, though that's a little pie in the sky. ~~~

Comment by AndyB on 2007-05-15: Don't reinvent the wheel. A good webinterface wich meets a lot of these requirement already exists: eBox (www.ebox-platform.com) It's written in Perl and based on Debian, so the changes should not be too big. I think if a collaboration comes up, that would be a very successful one.

Comment by MathiasGug on 2007-05-28 : Related to configuration files generation in ebox : it would be better to detect when configuration files have been modified locally, ie not by ebox. If so warn the user about it and put the configuration file and his corresponding module out of ebox control (make the module unavailable in ebox for example). That way, advanced sysadmins can still administer the server if they don't want to use ebox. As soon as end user start to play with the configuration files directly, it can be assumed that they know what they're doing and ebox should get out of their way. Yast uses the same approach, which raised some comments from users at UDS Sevilla : they want to have the choice to use Yast (if it suits them) or not (if they need more control).


CategorySpec

UbuntuEasyBusinessServer (last edited 2012-11-09 15:46:51 by 41)