[Debian-NP-Commits] r177 - trunk/docs/report/report-docbook

micah debian-np-devel@lists.alioth.debian.org
Fri, 16 Jul 2004 22:03:58 -0600


Author: micah-guest
Date: Fri Jul 16 22:03:57 2004
New Revision: 177

Modified:
   trunk/docs/report/report-docbook/appendix-cdd.xml
   trunk/docs/report/report-docbook/appendix-development_environment.xml
Log:
Finished docbooking Appendix D: CDD
Fixed <> symbols being backwards in the Appendix on dev environment


Modified: trunk/docs/report/report-docbook/appendix-cdd.xml
==============================================================================
--- trunk/docs/report/report-docbook/appendix-cdd.xml	(original)
+++ trunk/docs/report/report-docbook/appendix-cdd.xml	Fri Jul 16 22:03:57 2004
@@ -0,0 +1,276 @@
+<?xml version="1.0" encoding='UTF-8'?>
+<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "docbookx.dtd">
+
+<appendix>
+ <title>Appendix D: Customized Debian Distributions (CDD)</title>
+ <sect1>
+  <title>Introduction</title>
+    
+    <para>The CDD (Custom Debian Distribution) project was born a few
+    months back in order to build infrastructure and documentation to
+    make building customized Debian distributions both easy as well as
+    standardized for the purposes of mutual benefit. The first
+    Customized Debian distribution (Debian Junior) came out in the
+    beginning of 2000, afterwards a number of like-minded projects
+    like it followed, such as Skolelinux (now named Debian-Edu),
+    Debian-Med, Debian Multimedia Distribution (DEMUDI), Debian-BR (a
+    Brazilian localized distribution), and of course Debian-NP. During
+    Debconf3 in Oslo, several developers who are involved in the
+    different customized Debian distributions got together and found
+    that instead of individually working on similar problems and not
+    sharing the results, that there was a strong potential for mutual
+    benefit. At the OSWC conference in Malaga a workshop on this issue
+    took place, resulting in the beginning of a paper which describes
+    the philosophy of Custom Debian Distributions, and the techniques
+    which are used to manage those projects, and good overview of how
+    this is important to the vitality and quality of Debian a a
+    whole. This paper is a work in progress, and Debian-NP contributed
+    to its growth during Debconf, and continues to do so.</para>
+
+    <para>The main goal of a customized Debian distribution is to
+    enhance the role of Debian as the missing link between upstream
+    software developers and end users. Debian contains nearly 10,000
+    packages of different software, and this number is constantly
+    increasing. There is no single user who needs all these packages,
+    but is interested in only a subset of thee packages, but how does
+    the user find out which packages are the ones that they, or their
+    organization needs?</para>
+
+    <para>Custom Debian Distributions try to provide a solution for
+    special groups of target users with different skills and
+    interests. Not only do they provide pre-selected collections of
+    specific program packages identified as the best suited for
+    particular groups, but they also ease installation and
+    configuration for the intended purpose.</para>
+
+  </sect1>
+
+  <sect1>
+    <title>CDD infrastructure</title>
+
+    <para> Creating a CDD means fundamentally to solve the following
+    problems, among others:</para>
+
+    <itemizedlist>
+
+      <listitem>
+	<para>Package selection</para>
+      </listitem>
+
+      <listitem>
+	<para>Configuration tasks</para>
+      </listitem>
+
+      <listitem>
+	<para>Localization tasks</para>
+      </listitem>
+
+    </itemizedlist>
+
+    <para>Package selection is the process of identifying what
+    software is to b included in the CDD. A package is a single file
+    which contains all of the files necessary to implement a set of
+    related commands or features, and is the method of software
+    delivery used by Debian. In order to install a particular CMS, web
+    server, etc. one installs a package which places the program in
+    the correct location, creates a configuration file, and installs
+    the appropriate documentation. It is then up to the system
+    administrator to configure this package to their needs. Package
+    selection is a task that is expected to be developed by everyone
+    who attempts to realize a Custom Debian Distribution, it is part
+    and parcel of deciding what software will be included.</para>
+
+    <para>Some CDDs (such as Debian-NP) require considerable effort to
+    create particular configurations, others (like Debian-BR) require
+    only the selection of the locale for each software.</para>
+
+    <para>The CDD infrastructure's main goal is to create tools to
+    accomplish the package selection, configuration and localization
+    as well as a policy and guidelines that define the common
+    customization methodology. It has been difficult to define what
+    the common customization needs are.</para>
+
+    <sect2>
+      <title>CDD-dev</title>
+      
+      <para>Before Debian-NP went to Porto Alegre, the CDD project had
+      already created two Debian packages that contain some tools to
+      help in the customization work. These packages are cdd-common
+      and cdd-dev. </para>
+    </sect2>
+
+    <sect2>
+      <title>CDD-common</title>
+
+      <para>The "cdd-common" package provides a number of scripts that
+      help in the configuration of users and groups, insert those
+      users and groups in the LDAP environment, create the mailserver
+      configuration and so on. </para>
+    </sect2>
+
+  </sect1>
+
+  <sect1>
+    <title>DebianNP's CDD enhancements</title>
+    <sect2>
+      <title>Goals</title>
+
+      <para>During Debconf, Debian-NP designed an enhanced CDD
+      infrastructure. Our infrastructure was designed to achieve four
+      goals:</para>
+
+      <itemizedlist>
+	<listitem>
+	  <para>1.Install from scratch the CDD</para>
+	</listitem>
+
+	<listitem>
+	  <para>Convert an already installed Debian System to the
+	CDD</para>
+	</listitem>
+
+	<listitem>
+	  <para>Install the CDD by means of a live-cd (Morphix) for
+	demo purposes (note that once Morphix is started, it can be
+	also installed)</para>
+	</listitem>
+
+	<listitem>
+	  <para>Use from a lessdisks terminal server</para>
+	</listitem>
+	
+      </itemizedlist>
+    </sect2>
+
+    <sect2>
+      <title>Process for accomplishing this methodology</title>
+
+      <sect3>
+	<title>Contribute to the community</title>
+
+	<para>First of all the CDD scripts, packages, configurations,
+	etc. should be included in the Debian archive. This also
+	complies with some of the "social" aspects of the Debian
+	Community by contributing back work that can be shared by
+	other users, developers, CDDs etc.</para>
+	
+      </sect3>
+
+      <sect3>
+	<title>Meta-packages</title>
+
+	<para>Next, each CDD should be organized into
+	meta-packages. This way, installing a meta-package through
+	traditional package installation means, will install all
+	packages declared as dependencies. Following the Debian
+	Policy, the meta-packages cannot override the configuration of
+	other packages. Those meta-packages should follow this naming
+	convention: &lt;cdd&gt;-&lt;task&gt;. </para>
+
+	<para>Meta-packages are packages that depend on subset list of
+	packages, so installing a meta-package will install the entire
+	list of dependencies. During our work at Debconf, we created a
+	number of these meta-packages.  We were able to create the
+	following meta-packages: </para>
+
+	<itemizedlist>
+	  
+	  <listitem>
+	    <para><filename>np-base-server</filename> - this
+	  metapackage contains the minimal set of required software
+	  that all servers will have installed, and conversely, not
+	  installed (ie. it will remove packages that are not part of
+	  the package)</para>
+	  </listitem>
+	  
+	  <listitem>
+	    <para><filename>np-mail-server</filename> - this
+	  metapackage contains the mail-server components that would
+	  be overlayed on-top of the base-server meta-package, it
+	  contains the mail transfer agent, the spam/virus filtering
+	  software and all the necessary dependencies</para>
+	  </listitem>
+
+	  <listitem>
+	    <para><filename>np-ldap-server</filename> - this
+	  metapackage contains the LDAP server components, including
+	  the LDAP server and the backend database, this can be
+	  overlayed ontop of the np-base-server package. To create a
+	  LDAP server.</para>
+	  </listitem>
+
+	  <listitem>
+	    <para><filename>np-workstation</filename> - this
+	  metapackage contains the package lists, and dependencies
+	  necessary to create the workstation version of Debian-NP.</para>
+	  </listitem>
+
+	  </itemizedlist>
+
+	<para>These metapackages are modularized so that they can be
+	individually installed to create a Debian-NP mail-server on an
+	existing installed Debian machine, or are integrated together
+	in the full Debian-NP server installation from a CD.</para>
+
+      </sect3>
+
+      <sect3>
+	<title>Common interface</title>
+
+	<para>We came up with the method of creating the package named
+	&lt;cdd&gt;-common that contains an interface which lets the user
+	configure their own meta-packages. In this way, configuration
+	work is done "outside" post-installation stage and it does not
+	break the Debian Policy. Moreover, such interface could be
+	called from the debian-installer (realizing goal 1, CD install
+	from scratch), every time the system administrator requires it
+	(realizing goal 2, conversion of an existing system), or in
+	more general situations (realizing goals 3 and 4, live CDs as
+	well as diskless terminal server scenarios).</para>
+
+	<para>This interface on which we are currently working on,
+	should be able to update the menu interface when new
+	meta-packages are installed/removed from the system.</para>
+
+      </sect3>
+
+      <sect3>
+	<title>Configuration</title>
+
+	<para>Each CDD will require certain configuration and
+	customization, we were unable to find the best way to handle
+	such configuration, due to the nature of packages having
+	different configuration requirements, complexities and unique
+	structure created by the maintainer that are not reconcilable
+	into one common configuration interface. We decided that there
+	were four different acceptable methods to resolve the
+	configuration issue, and each depends on the situation.We can
+	use either debconf, cfengine, hand-written scripts or use
+	configuration files that do diversions.</para>
+
+      </sect3>
+    </sect2>
+ </sect1>
+
+</appendix>
+
+
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: xml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-namecase-general:t
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-parent-document:nil
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+sgml-indent-step:1
+sgml-indent-data:1
+sgml-set-face:t
+End:
+-->
\ No newline at end of file

Modified: trunk/docs/report/report-docbook/appendix-development_environment.xml
==============================================================================
--- trunk/docs/report/report-docbook/appendix-development_environment.xml	(original)
+++ trunk/docs/report/report-docbook/appendix-development_environment.xml	Fri Jul 16 22:03:57 2004
@@ -83,7 +83,7 @@
    <sect3>
     <title>Subversion repository checkout</title>
 	
-    <para> <command>svn checkout svn+ssh://&gt;username&lt;@debian np.alioth.debian.org/svn/debian-np bagunca </command></para>
+    <para> <command>svn checkout svn+ssh://&lt;username&gt;@debian np.alioth.debian.org/svn/debian-np bagunca </command></para>
    </sect3>
 
   </sect2>