[Debian-NP-Commits] r91 - trunk/docs/report

[Marco Presi]

Author: zufus
Date: Sun Jun 20 08:24:04 2004
New Revision: 91

Modified:
   trunk/docs/report/04techwork
Log:
wrote some words


Modified: trunk/docs/report/04techwork
==============================================================================
--- trunk/docs/report/04techwork	(original)
+++ trunk/docs/report/04techwork	Sun Jun 20 08:24:04 2004
@@ -1,28 +1,231 @@
  - Technical overview
+---------------------   
+ This chapter covers the technical aspects we have worked on at Porto
+ Alegre and following days.  
+
+  - CDD Infrastructure
+  --------------------
+    . CDD document
+
+    CDD (Custom Debian Distribution) is a project born few months ago
+    that aims to build an infrastucture available to who wants to
+    customize Debian to his own needings. Actually there are many Custom
+    Debian Project (official and non). Among the official ones, we
+    recall Debian-Edu, Skolelinux, Debian-Multi-Media (DEMUDI),
+    Debian-Med, Debian-Br-CDD (a portoguese version of Deboan) and our
+    project Debian-NP.
+
+    Create a CDD means foundamentally solve some (or all) of the
+    following points:
+
+    o) Package selection
+    o) Configuration tasks
+    o) Localization tasks
+    o) ..............
+
+    As it could be intuitive, "Package Selection" is a task that it is
+    espected to be developed by every-one who attempts to realize a
+    Custom Debian.
+
+    Some CDD (as Debian-NP) require also a strong effort to create some
+    particular configurations, other (like Debian-BR) require only to
+    customize the localization choosen.
+
+    CDD Infrastucture main target is to create some tools to accomplish
+    these tasks, and a Policy (more general than the Debian one) that
+    defines the correct way to do a customization.
+
+    One major difficulty experienced by the CDD team is to define which
+    are the common needings that "Customizers" have. There are a lot of
+    debates about this in the various mailing-lists dedicated to CDD.
+
+    Before Porto Alegre, the CDD project, created 2 debian packages that
+    contains some tool help in the customization work. These packages
+    are cdd-common and cdd-dev.
+
+    We used mainly "cdd-dev" that provides some scripts (Makefiles, and
+    so on) to create meta-packages (i.e. a list of packages to be
+    included in the customized distribution).
+
+    "cdd-common" instead, provides a number of scripts that help in the
+    configuration of users and groups, insert those users and group in
+    LDAP environment and so on. Those are very powerful tools, but as we
+    indicate in the following, we still not need them in Debian-NP.
+
+    During the stage in POA, we have proposed a design for CDD, enhanced
+    a package that help in the creation of installation CD, and started
+    using debtags as tool to select packages.
+
+    Let's start to see our proposal for CDD. Our Infrastructure was
+    designed to achiev 4 GOAL:
+
+    1) Install from scratch the CDD.
+    2) Convert an already installed Debian System to the CDD
+    3) Install the CDD by means of a live-cd (Morphix) for demo puropse
+       (pls note that once Morphix is started, can be also installed)
+    4) Use from a lessdisc terminal.
+
+
+    We strongly believe that this could be a widely accepted framework
+    to create CDD, and all our technical work was developed wich this
+    design in mind.
+
+    - How this can be accomplished:
+
+    o) First all the CDD stuff (script, packages, and so on) should be
+    included in Debian archive. This also complain with some "social"
+    aspect of Debian Community.
+
+    o) Next, each CDD should be organized in meta-package. 
+    Meta-packages, are packages that contains almost nothing, except for
+    a dependencies list. In such a way, installing a meta-package via
+    apt (or other interfaces to dpkg) will install all packages declared
+    as dependencies. Following the Debian Policy, the meta-packages
+    cannot override the configuration of other packages. Those
+    meta-packages could follow this naming convention: <cdd>-<task>. In
+    our case we choosed np-mail-server, np-workstation, and so on.
+
+    o) Create a package named <cdd>-common that contains an interface that
+    let the user to configure his own meta-packages. In this way,
+    configuration work is done "outside" post-installation stage and it
+    not breaks Debian Policy. Moreover, such interface could be called
+    from debian-installer (realizing goal 1), every time the sysadmin
+    requires it (realizing goal 2), or in more general situations
+    (realizing goal 3 and 4).
+    This interface, on which we are currently working on, should be able
+    to update his menu interface when new meta-packages are
+    installed/removed from the system.
+
+    o) The four environment dealed above, could require some additional
+    packages. It depends on each case, and on the willing of the
+    Customization team.
+
+    o) The configuration matter can be resolved in 4 different way:
+       - using debconf
+       - using cfengine
+       - using hand written scripts
+       - using conf files divertion.
+
+       It's actually impossible to choose which is the best way to
+       handle configuration files. It strictly depends on the packages,
+       on his complexity, and on the mainteiner.
+
+
  - Installer work
    . Overview
+
+   Installer is derived from debian-installer (last development
+   versions). As such, it has all the characteristics of Debian
+   Installer: it can be run from CD, from Network, from floppies, and so
+   on. It is translated in many languages (see how many).
+
+   In particular we have studied _how_ the debian-installer could be
+   customized, learning almost all we need from other exsistent
+   customized debian-installers (Skolelinux one and Debian-BR one).
+
    . Accomplishments
+   
+   Actually we have a working installer that let us to:
+
+   - Choose a profile (Server or Workstation).
+   - Install the system (with auto-partitioning) based on the profile
+     choosed.
+
+   We decided to base Debian-NP on those two profile
+   (Server/WorkStation) after the definition of our social
+   specifications.
+
+   . Udeb 
+   To accomplish this, we have create few udeb packages to modify
+   installer behavior. 
+
+   Debian-installer has 2 stage. In the 1st stage the installer takes
+   care to do some basic stuff (partitioning, copy the debian-base
+   system, install boot-loader and so on.). The program that handle the
+   first stage can be modified adding some udeb packages. udeb packages
+   are minimal debian packages that contains mainly scripts to be run in
+   the 1st stage installer. udebs specify also the order of
+   execution. In this way the debian-installer can be easily
+   modified. We created 2 udeb packages:
+
+   o) debian-np-profile: it asks for wich kind of installation must be
+      performed and save the answer in /etc/debian-np/profile 
+
+   o) debian-np-install: it makes the main modifications. It install in
+      the system 2 partition tables (on for server and the other one for
+      workstation) for automatic partitioning stuff, override some
+      Debian defaults (this is needed to replace exim with postfix),
+      insert some scripts for network configuration, and accomplish
+      other minor things.
+
+   In the 2nd stage, debian-installer run base-config
+   program. base-config install all meta-packages and configure them. In
+   this point we should insert in the near future the configuration
+   interface we mentioned above. For the moment it simply install
+   np-mail-server package (or np-workstation) and configure them.
+
+   Installation of meta-packages is accomplished by a script that
+   install np-workstation or np-server meta-pakages (depending on which
+   choice was made in the 1st stage installation).
+
+   The accomplish these target on the installer we needed about one week
+   of work, because of a lack of documentation on debian-installer,
+   bugs, and so on. Also we have to consider that to test an
+   installation cycle we need about 20 minutes to build an ISO image,
+   and about 30 minutes to complete the installation.
+
+
+   . ISO image build
+
+   This work was based mainly on debian-cdd-cdtools package, developed
+   by Otavio Salvador and Debian-br crew. With this tool that we have
+   adapted and called debian-np-cdtool, we are able to generate a working
+   ISO image, providing these information:
+    o) a package selection list
+    o) a base-system package list
+    o) 1st stage udeb list
+
+    We have considered to test also PICAX a different tool to create ISO
+    installation image wrote by Progeny that should be much more easy to
+    use. We planned to test it in the next weeks.
+
  - Debian-NP Internet Server
     . Package selection
     . LDAP Schema
  - Debian-NP Workstation
     . Package selection
- - CDD Infrastructure
-    . CDD document
+
+
+
  - Development plan
     . subversion
 	  - overview
 	  - usage
+
+	  svn checkout svn+ssh://<username>@debian-np.alioth.debian.org/svn/debian-np bagunca
+
 	  - layout
+
+	  /branches
+	  /people
+	  /trunk	  
+
   	  - communication
 	  	- mailing list
-		  - debian-np-commits
+		  o) debian-np@lists.debian.org
+		  o) debian-np-commits@lists.alioth.debian.org
 		- project tracking
-		  - CIA
-		  - IRC bot
+		Another big news is the addition of one bot in IRC channel. His name
+		is CIA-3 and this is used to talk in channel each commit in our
+		repository. In next days we will adding a mailing list where the
+		commits will be available too and if you want to use this service, you
+		only need to subscribe to debian-np-commits@lists.alioth.debian.org
+
 	. Developer communication
 		  - IRC
+		    o) #debian-np, #debian-custom on freenode
 		  - developer mailing list
+		    o) debian-np-devel@lists.alioth.debian.org
 
 
 --------