torrus/doc/devdoc/reqs.0.1.pod

   1 #  requirements.pod: The pre-planning document
   2 #  Copyright (C) 2002  Stanislav Sinyagin
   3 #
   4 #  This program is free software; you can redistribute it and/or modify
   5 #  it under the terms of the GNU General Public License as published by
   6 #  the Free Software Foundation; either version 2 of the License, or
   7 #  (at your option) any later version.
   8 #
   9 #  This program is distributed in the hope that it will be useful,
  10 #  but WITHOUT ANY WARRANTY; without even the implied warranty of
  11 #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  12 #  GNU General Public License for more details.
  13 #
  14 #  You should have received a copy of the GNU General Public License
  15 #  along with this program; if not, write to the Free Software
  16 #  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
  17
  18 # $Id: reqs.0.1.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $
  19 # Stanislav Sinyagin <ssinyagin@yahoo.com>
  20 #
  21 #
  22
  23 =head1 RRFW Requirements Version 0.1
  24
  25 Date: Jun 29 2003; Last revised: Aug 05 2003
  26
  27 In this article, I describe the important changes that are planned
  28 for RRFW version 0.1.X.
  29
  30 =head1 Independent datasource trees
  31
  32 As noted by many users, RRFW lacks the scalability when the number of
  33 network devices is more than 100. The XML compiler takes minutes to
  34 process the configuration, and the Collector process initialization time
  35 is too long.
  36
  37 Christian Schnidrig E<lt>christian.schnidrig@gmx.chE<gt> has proposed
  38 a solution to split the database into several subsystems, each
  39 being compiled separately, and with separate collector process.
  40 In his concept, there is a "global" datasource tree, and
  41 "subsystem" trees, each making a subset of global datasource nodes.
  42
  43 I propose to have a number of independent datasource trees, without
  44 any superset. This would ease the administrator's work, and add more
  45 security.
  46
  47 =head2 Changes in rrfw-siteconfig.pl
  48
  49 Instead of C<@RRFW::Global::xmlFiles>, the following hash will contain
  50 the information about the trees:
  51
  52   %RRFW::Global::treeConfig = (
  53     'tree_A' => {
  54       'description' => 'The First Tree',
  55       'xmlfiles' => ['a1.xml', 'a2.xml', 'a3.xml'],
  56       'run' => { 'collector' => 1, 'monitor' => 1 } },
  57     'tree_B' => {
  58       'description' => 'The Second Tree',
  59       'xmlfiles' => ['b1.xml', 'b2.xml'],
  60       'run' => {} }
  61    );
  62
  63 In this hash, the keys give the tree names, I<xmlfiles> points to an array
  64 of source XML files, I<run> points to the names of the daemons that
  65 would be automatically launched for the tree.
  66
  67 Two additional arrays: C<@RRFW::Global::xmlAlwaysIncludeFirst> and
  68 C<@RRFW::Global::xmlAlwaysIncludeLast> will give a list of source XML
  69 files that are included in every tree, in the beginning or in the end of
  70 the XML files list.
  71
  72 =head2 ConfigTree object internals
  73
  74 There will be no such thing as globalInstance. All methods and procedures
  75 that need to reference the current ConfigTree object will have it as
  76 argument.
  77
  78 C<RRFW::ConfigTree::new()> will have a mandatory argument "TreeName".
  79
  80 =head2 Database structure
  81
  82 All datasource trees will share one BerkeleyDB environment. The
  83 BDB environment home directory will stay the same, defined by I<dbhome>
  84 config variable.
  85
  86 For each tree, the database files will be placed in a separate subdirectory
  87 of a subdirectory of I<dbhome>.
  88
  89
  90 =head2 User interface
  91
  92 All relevant command-line executables will support the following
  93 options:
  94
  95 =over 4
  96
  97 =item * --tree <tree_name>
  98
  99 Specifies the datasource tree for processing;
 100
 101 =item * --all
 102
 103 If applicable, performs the operation on all available trees.
 104
 105 =back
 106
 107 When in verbose mode (B<--verbose>), the command-line programs must
 108 print the tree names they operate with.
 109
 110 The web interface will take the PATH_INFO string as the tree name.
 111 For mod_perl handler, it will be also possible to prohibit
 112 PATH_INFO selection, and to configure the tree name in Apache
 113 configuration.
 114
 115 When no PATH_INFO is given to the web interface handler,
 116 a special superlevel menu may be shown with the list of available trees.
 117
 118 It will also be possible to specify tree-specific renderer attributes, like
 119 C<%RRFW::Renderer::styling>, C<$RRFW::Renderer::companyName>, etc.
 120
 121 B<Plain CGI interface will not be supported> As Renderer gets more complex,
 122 CGI initialization time will increase. Also it will become harder to support
 123 two user interfaces with similar functionality.
 124
 125
 126 =head2 Daemons launch master
 127
 128 There will be a master process that will launch collector and monitor
 129 daemons for each tree. It will be configurable from a separate file,
 130 specifying the daemons and execution parameters for each tree.
 131
 132 The master process will watch the child processes and issue warnings in the
 133 events of child process termination.
 134
 135 Stopping the master process will stop all child daemons gracefully.
 136
 137
 138 =head1 Separate database for non-datasource objects
 139
 140 In RRFW version 0.0.X, all the parameters for datasources, views,
 141 monitors, and tokensets are stored in F<configuration.db> database.
 142
 143 As proposed by Christian Schnidrig, storing all non-datasource
 144 objects information in a separate database would improve the scalability.
 145
 146 In RRFW version 0.1.X, datasource parameters will be stored in
 147 F<ds_config.db>, and all other object's parameters in F<other_config.db>.
 148
 149 The XML compiler will have a new option, B<--nods>, which disables
 150 processing of E<lt>datasourcesE<gt> elements in the input XML files.
 151
 152 In addition to C<ConfigurationReady> flag, there will be a flag that indicates
 153 the readiness of datasource tree only.
 154
 155 All these measures will allow faster administration and testing of
 156 non-datasource objects, and will prevent the collector from unneeded
 157 interruptions.
 158
 159
 160 =head1 User privileges
 161
 162 User privileges will apply to the tree level: across one datasource tree
 163 a given user will have uniform privileges.
 164
 165 Each user belongs to one or more groups. Privileges are assigned to
 166 groups only, not to individual users. Groups are one-level deep: they
 167 consist of users only. Probably in the future groups will consist
 168 of groups too.
 169
 170 In the beginning, only one privilege will be implemented: I<DisplayTree>.
 171 The design should be flexible enough to add more privileges in the future.
 172 Examples: I<GenerateReport>, I<Debug>, I<ScheduleTask>, and so on.
 173
 174 Privileges maintenance interface will include a command-line utility.
 175 In the future, a web interface is also possible. In this case, a new
 176 privilege will be added: I<EditPrivileges>.
 177
 178 Privileges editor will include the following functions:
 179
 180 =over 4
 181
 182 =item * add/delete group
 183
 184 =item * add/delete user
 185
 186 =item * change user password
 187
 188 =item * add/delete user membership in a group
 189
 190 =item * edit privileges for groups and trees
 191
 192 =item * list group members
 193
 194 =item * list groups a user belongs to
 195
 196 =item * list privileges for a given group or user
 197
 198 =item * list privileges and groups (or users) for a given tree
 199
 200 =item * export/import the privileges database to/from XML
 201
 202 =back
 203
 204 Privileges logics implementation must be separate from the database backend.
 205 At first, BerkeleyDB backend will be supported. In the future, LDAP
 206 backend is possible.
 207
 208 =head1 Author
 209
 210 Copyright (c) 2003 Stanislav Sinyagin ssinyagin@yahoo.com