ispman/docs/devel CVS-Rules,NONE,1.1 CustomerMan,NONE,1.1 misc_design_issues,NONE,1.1
Cory Petkovsek <[email protected]>
| Newsgroups | gmane.comp.isp.ispman.cvs |
|---|---|
| Message-ID | <[email protected]> |
Update of /cvsroot/ispman/ispman/docs/devel In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26617/devel Added Files: CVS-Rules CustomerMan misc_design_issues Log Message: Created devel dir; Adding customerman design docs; moved cvs-rules --- NEW FILE: CVS-Rules --- From: Joerg Delker <[email protected]> To: ispman-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Subject: [Ispman-developers] CVS: the new way of developing Hi Folks, I'm glad to announce the redesign of the ISPMan cvs. To get you all on track, let my explain the changes with the help of some ascii-art. First have a look at the old tag/branch structure: ======================================================= O | | |\_______________________ ... | REL_0_8 (branch) \ | | | * REL_1_0 (tag) | | |\__________________ | REL_0_9 (branch) \ | | * REL_1_0 (tag) * REL_1_0 (tag/branch) | |\_______________... | | | ==============snip=============snap==================== The above is just a rough excerpt of the previous cvs (the detailed view is much more confusing) The 4 major problems here: 1) There are a LOT of branches (and sub branches), leading to some very "deep versioning" 2) No tags on the way. There is no way back to some known working state. 3) The main trunk (HEAD) is differing very much from branches, making merging a nightmare 4) REL_1_0 tag is spreading over several branches, specifying both tag and branch. Ok, besides people who still work on pre-1.0 versions, we just remember this lesson and forget about that stuff. Now to the new cvs: ==============snip=============snap==================== | * experimental (tag) |\_______________________... | experimental-branch (branch) | * dev_1_1 (tag) <=== We are here right now | | * dev_1_2 (tag) | (...) maybe further dev_1_x tags | * rel_1_x (tag) |\______________________... | rel_1_x-branch (branch) | * dev_1_(x+1) (tag) | ... ======================================================= What happened here? First of all, the current HEAD was tagged "experimental" and branched off in the "experimental-branch" to move this "far ahead development thread" out of the way (see Rule #8). By doing this we practically "saved" HEAD in this new branch and can pull code from there or continue experimental development if necessary. Next step: To continue development on the "productive version" REL_1_0, which is tagged all over the old structure, HEAD was adjusted to match REL_1_0, resulting practically in a rollback of the trunk to the latest REL_1_0 release. This was tagged "dev_1_1" then, marking the kick-off for the current development version. So currently, the equation holds REL_1_0 = dev_1_1 (= HEAD). The latter one will continue on of course. Future steps: Main development (for the former REL_1_0 version) will continue on HEAD now. This will be bugfixes as well as new code (eventually from "experimental-branch"). As soon as we believe that we have a halfway decent working state in HEAD or we want to mark the current state whatsoever, we TAG it with some "dev_x_y" incremental tag (see Rule #3). Eventually, when there is some really nice state in HEAD or Atif just believes that it's time for a new public release it get's tagged with an incremental "rel_x_y" and also get branched of as "rel_x_y-branch" (see Rule #6,#8). Development will continue in HEAD, important bugfixes of the public release go into the rel_x_y-branch and merged back to HEAD (Rule #5,#6). This will just continue over and over until we have "the perfect ISPMan" ;)) Ok, let's put this into some simple rules: Rule 1: --> Focus main development on HEAD Every change in branches must eventually be merged back to HEAD sometime. Remember: The more is developed on branches, the more difficult it will be to get it back into HEAD. Rule 2: --> Make small logical changes to files --> and document them when commiting. Committing five bugfixes and two new coded features in one shot makes testing and troubleshooting a nightmare. Split it up in small chunks. Rule 3: --> Tag the milestones To easily recover to specific states and have common reference points (bug reports, etc.) it's important to tag the trunk/branch once a while. There is no golden rule *when* to do this but do it at least for known stable versions. Rule 4: --> Tag completely When tags are applied, do it always on the complete trunk/branch you are on ("cvs tag" in root of your repository). Never ever tag/update/commit across different branches! Rule 5: --> Tag your merge When changes are merged back to the trunk, remember to tag the releases of the involved files in your branch (e.g. dev_x_y-branch-merge1). This makes later merging again much easier. If possible, try to merge your entire branch to HEAD (if your changes allow that) Additional comment (jdelker 2004-06-20): This rule is abandoned for now. Currently, fixes are merged immediately to HEAD on a manual basis without tagging. Rule 6: --> New branch for public releases Releases we put in tar files for download, should be branched off (see also Rule #8) The branch should be used mainly for bugfixes we merge back to the trunk. Try to develop new features directly on HEAD. Rule 7: --> New branches for experimental ideas If you have some big things in mind and you don't know if it all will work out eventually, ask for a experimental branch (e.g. "dev_1_x-altvhosts"; see also Rule #8). But focus on your idea, we have to merge it back soon Rule 8: --> Set branch point tags For every branch we split of the trunk, there should be a "branch point tag" set. Otherwise there is no way back to the state when we branched off. Example: For a new "release branch" (as in Rule #6) we set a "rel_x_y" tag on HEAD ("cvs tag rel_x_y") and branch off with a "rel_x_y-branch" branch tag ("cvs tag -b rel_x_y-branch"). Rule 9: --> no branch of branches Don't let us fall back to the old days. There should not be a need to, anyhow. Rule 10: --> No retagging Same as #8 Last comment: If anybody is not that familiar with cvs and is unsure how to get along in some situations, I will be glad to help. Very last comment: This document will be on HEAD as README.cvs, so everyone has it handy when he needs it. I want to consider it's content a working guideline, which we can change anytime if rules are inadequate. Good nite, Joerg --- NEW FILE: misc_design_issues --- - In future, domain ownership should be linked so one customer can own multiple domains. Perhaps this is already done with the client login. - Domain type should be modifiable, perhaps tying in with domain services and specified dns host. - FTP Access is also domain login password. This should be made more clear. --- NEW FILE: CustomerMan --- CustomerMan Design Document =========================== Sat Jun 26 16:31:44 PDT 2004 CustomerMan needs work. It doesn't work well under mod_perl and to make it so, it might as well be redesigned. Here are requirements and specifications documents that are precursor to the redesign. Straight forward requirements are not discussed in the specs. Requirements ------------ System - Secure login and session handling (currently not done). - Session info will be stored either in ldap tree if there is a place for it, or in /tmp. - Data is stored and read from ldap tree. - Runs under CGI as well as mod_perl with strict and taint mode on. User - Nonfunctional - Input data will be checked for validity. (currently not all of it is). - Interface will be intuitive to work with. (its kind of clunky now). User - Functional - Manages http authentication usernames (web users) - Manages email accounts, aliases, forwarding (domain user) - Manages email lists - Manages domain signature (does this actually work, currently?) - Manages virtual hosts - Manages DNS - Provides vhost log downloads - Displays quotas: No users/vhosts, amount of space - Displays server statistics: perl/php, versions and paths - Displays web statistics: webalizer/awstats - Support framework for mysql databases (not in first release). Specifications -------------- Platform - Customerman will be available from the main ispman.domain.com login screen. Perhaps in future it will be available as customerdomain.com/ispman, but not in the first release. Security - A non-guessable session id will be insert into an expirable cookie upon successful authentication. This session ID will also go into the ldap tree or in /tmp with an expiry date. - Each action will be checked to see if the cookie has a valid session id. - All input data will be validated against the type of input expected. - Runs with taint mode and strict on to promote more secure programming. Interface - Layout will be based around functional categories (email accounts, lists, vhosts) rather than operation (add, modify) as is done currently. Misc - Mod_perl compiles the perl script only once, thus some perl functions are only run once (such as BEGIN and END blocks). In order to support mod_perl and CGI, these CustomerMan will be designed to run only at runtime. Perl 5.6 and later is required in order for mod_perl to override die() and exit() functions. Running under Apache::Registry is also required for this override. Design ------ - CustomerMan does not provide any functions for other modules, thus does not need it's own package. Functions used throughout ispman should be in the ispman library (ie /lib and in the package). CustomerMan should therefore utilize this library as much as possible. Templates in cgi-bin/tmpl/customerMan/*.tmpl have all non-data output CGI: htdocs/control_panel/index.cgi Support functions: lib/* User connects control_panel/index.cgi: [5] A counter is retreived from /tmp/ispman-sessions. If it is >=100 expired session files /tmp/ispman-session-* are removed. [10] System checks for an authorized session id in a cookie upon each page access. If the session is valid, commands are carried out [15]. Else is the user logging in? [20]. Else the login screen is shown from template. Script exits. [20] The supplied domain and password are verified against the ldap tree. If the credentials are valid A random number is generated. The connecting ip address is retreived. The date, ip and domain are written to /tmp/ispman-session-######## where # is the random number. The number is given back to the browser in a 1 hour cookie. Browser is forwarded to the script again. Return. Else a templated error message is displayed. Return. [15] What are the category and command requested? (One indent is category, two indents is action, three indents if any are pseudo code. Each action returns. All data is stored in ldap tree.) default Show templated summary screen[50]. Return. Misc Logout /tmp/ispman-session-######## is removed. Cookie is removed from client. Browser is forwarded to the script again. Return. Domain Accounts (email/ftp) Add account Modify name, password, (email*) Delete account Add/Modify/Delete alias Add/Modify/Delete forward Lists Add/Delete list Modify list members VHosts Add/Delete vhost Modify permission settings Add/Modify/Delete web alias Add/Modify/Delete web redirect Add/Modify/Delete web access accounts Add/Modify/Delete web access control lists Access Log files Domain signature (does this actually work, currently?) Add/Modify/Delete signature DNS Add/Modify/Delete NS/MX/A/CNAME/other? records [50] Overview information: Server statistics: perl/php, versions and paths quotas: Number of email accounts, web users, vhosts, amount of space Web statistics: webalizer/awstats ---- * Email: In another release, modification of email address and moving of underlying files should be supported. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com