X-Git-Url: http://git.freeside.biz/gitweb/?p=freeside.git;a=blobdiff_plain;f=torrus%2Fdoc%2Fdevdoc%2Freqs.0.1.pod;fp=torrus%2Fdoc%2Fdevdoc%2Freqs.0.1.pod;h=49698d370ab41bb1de427fd62f088cbd877fb968;hp=0000000000000000000000000000000000000000;hb=74e058c8a010ef6feb539248a550d0bb169c1e94;hpb=35359a73152b3d7a9ad5e3d37faf81f6fedb76e8 diff --git a/torrus/doc/devdoc/reqs.0.1.pod b/torrus/doc/devdoc/reqs.0.1.pod new file mode 100644 index 000000000..49698d370 --- /dev/null +++ b/torrus/doc/devdoc/reqs.0.1.pod @@ -0,0 +1,210 @@ +# requirements.pod: The pre-planning document +# Copyright (C) 2002 Stanislav Sinyagin +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. + +# $Id: reqs.0.1.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $ +# Stanislav Sinyagin +# +# + +=head1 RRFW Requirements Version 0.1 + +Date: Jun 29 2003; Last revised: Aug 05 2003 + +In this article, I describe the important changes that are planned +for RRFW version 0.1.X. + +=head1 Independent datasource trees + +As noted by many users, RRFW lacks the scalability when the number of +network devices is more than 100. The XML compiler takes minutes to +process the configuration, and the Collector process initialization time +is too long. + +Christian Schnidrig Echristian.schnidrig@gmx.chE has proposed +a solution to split the database into several subsystems, each +being compiled separately, and with separate collector process. +In his concept, there is a "global" datasource tree, and +"subsystem" trees, each making a subset of global datasource nodes. + +I propose to have a number of independent datasource trees, without +any superset. This would ease the administrator's work, and add more +security. + +=head2 Changes in rrfw-siteconfig.pl + +Instead of C<@RRFW::Global::xmlFiles>, the following hash will contain +the information about the trees: + + %RRFW::Global::treeConfig = ( + 'tree_A' => { + 'description' => 'The First Tree', + 'xmlfiles' => ['a1.xml', 'a2.xml', 'a3.xml'], + 'run' => { 'collector' => 1, 'monitor' => 1 } }, + 'tree_B' => { + 'description' => 'The Second Tree', + 'xmlfiles' => ['b1.xml', 'b2.xml'], + 'run' => {} } + ); + +In this hash, the keys give the tree names, I points to an array +of source XML files, I points to the names of the daemons that +would be automatically launched for the tree. + +Two additional arrays: C<@RRFW::Global::xmlAlwaysIncludeFirst> and +C<@RRFW::Global::xmlAlwaysIncludeLast> will give a list of source XML +files that are included in every tree, in the beginning or in the end of +the XML files list. + +=head2 ConfigTree object internals + +There will be no such thing as globalInstance. All methods and procedures +that need to reference the current ConfigTree object will have it as +argument. + +C will have a mandatory argument "TreeName". + +=head2 Database structure + +All datasource trees will share one BerkeleyDB environment. The +BDB environment home directory will stay the same, defined by I +config variable. + +For each tree, the database files will be placed in a separate subdirectory +of a subdirectory of I. + + +=head2 User interface + +All relevant command-line executables will support the following +options: + +=over 4 + +=item * --tree + +Specifies the datasource tree for processing; + +=item * --all + +If applicable, performs the operation on all available trees. + +=back + +When in verbose mode (B<--verbose>), the command-line programs must +print the tree names they operate with. + +The web interface will take the PATH_INFO string as the tree name. +For mod_perl handler, it will be also possible to prohibit +PATH_INFO selection, and to configure the tree name in Apache +configuration. + +When no PATH_INFO is given to the web interface handler, +a special superlevel menu may be shown with the list of available trees. + +It will also be possible to specify tree-specific renderer attributes, like +C<%RRFW::Renderer::styling>, C<$RRFW::Renderer::companyName>, etc. + +B As Renderer gets more complex, +CGI initialization time will increase. Also it will become harder to support +two user interfaces with similar functionality. + + +=head2 Daemons launch master + +There will be a master process that will launch collector and monitor +daemons for each tree. It will be configurable from a separate file, +specifying the daemons and execution parameters for each tree. + +The master process will watch the child processes and issue warnings in the +events of child process termination. + +Stopping the master process will stop all child daemons gracefully. + + +=head1 Separate database for non-datasource objects + +In RRFW version 0.0.X, all the parameters for datasources, views, +monitors, and tokensets are stored in F database. + +As proposed by Christian Schnidrig, storing all non-datasource +objects information in a separate database would improve the scalability. + +In RRFW version 0.1.X, datasource parameters will be stored in +F, and all other object's parameters in F. + +The XML compiler will have a new option, B<--nods>, which disables +processing of EdatasourcesE elements in the input XML files. + +In addition to C flag, there will be a flag that indicates +the readiness of datasource tree only. + +All these measures will allow faster administration and testing of +non-datasource objects, and will prevent the collector from unneeded +interruptions. + + +=head1 User privileges + +User privileges will apply to the tree level: across one datasource tree +a given user will have uniform privileges. + +Each user belongs to one or more groups. Privileges are assigned to +groups only, not to individual users. Groups are one-level deep: they +consist of users only. Probably in the future groups will consist +of groups too. + +In the beginning, only one privilege will be implemented: I. +The design should be flexible enough to add more privileges in the future. +Examples: I, I, I, and so on. + +Privileges maintenance interface will include a command-line utility. +In the future, a web interface is also possible. In this case, a new +privilege will be added: I. + +Privileges editor will include the following functions: + +=over 4 + +=item * add/delete group + +=item * add/delete user + +=item * change user password + +=item * add/delete user membership in a group + +=item * edit privileges for groups and trees + +=item * list group members + +=item * list groups a user belongs to + +=item * list privileges for a given group or user + +=item * list privileges and groups (or users) for a given tree + +=item * export/import the privileges database to/from XML + +=back + +Privileges logics implementation must be separate from the database backend. +At first, BerkeleyDB backend will be supported. In the future, LDAP +backend is possible. + +=head1 Author + +Copyright (c) 2003 Stanislav Sinyagin ssinyagin@yahoo.com