July 30, 2007

Backups Update - Domain backups working fully

Filed under: Miscellaneous — edg @ 5:08 pm

This is what a backup of domain.com currently contains:

domain.com_web.tar
domain.com_webcp_data.txt
domain.com_metadata.txt
ironman_1185832487.tar

In order, domain.com_web.tar is the backup from the apache module for domain.com, domain.com_webcp_data.txt is the backup of the info webcp holds about the domain, domain.com_metadata.txt is the metadata file containing a list of files in the backup. ironman_xxx.tar is a backup of the ironman user from the domain.

OK there need to be some changes, probably domain.com_web.tar should become domain.com_apache.tar, ironman_xxx should become domain_ironman_xxx (because unix_users are different in 0.6). It is a start though. I still have to refine things and this is only domain backup but that means everything else should work ok without much modification. At the moment backup file names just come from the module but you could easily get the module to call a hook from the backups module to get the name (something Gyrbo suggested and i think pdrake suggested as well).

Whether the tar files need times in their names or indexes or seals or anything like that i don’t know. Also currently data is only serialized between the frontend and backend parts so nothing is serialized in the backup_manager itself…. it could easily be done if necessary for security though. Also for security and performance forking might be a good idea for each backup to be forked by the backup manager hook. Forking of hooks that the backend calls for a module may be a good feature and would be one way of ensuring backups are forked.

I think webcp could benefit from a method of exchanging data between different hooks rather than just being able to use data between functions in the same hook. I would hope this could be done with variables rather than file or database access.
EdG

ps any suggestions are welcome and as i said there’s quite a bit still to be done but i’ve finally got a system that can make a complete backup of a domain and all of its selected users.

Backups progress 2

Filed under: New Features — edg @ 11:23 am

Right now the main thing i’m working on is how a backup of a reseller/domain is done recursing through the users and domains to be backed up. At the moment a reseller backup will provide a choice of domains to backup but all users under those domains will be backed up so backing up the domains and users is part of this. Also how various hooks work together to build the backup. A backup manager function is in charge which calls the relevant hooks.

I’m beginning to realise how useful some of the techniques of last years computer science lectures are in this. E.g. splitting things into functions where code gets too complex and the manjana(sp?) principles like if you need a specific function to do something write the empty function and write the rest as if that function exists, then work on the function, allowing you to skip thinking about the specifics for the moment…

Also i can’t imagine my life without a text editor like Crimson editor :D it is without a doubt the best and most functional editor i’ve ever found. Most useful are things like opening and saving files to a remote ftp server so i can save direct to my test machine and the ability to have multiple files open in tabs, also indenting, saving a backup file every time you save and conversion to unix file types are great. It has a huge number of features and i would recommend it to anyone.

I found the project features useful when manually editing Visual Basic form files for my a level computing project :D

For anyone not developing on windows i would recommend something called CUTE which is an awesome text editor….although you’ll probaly have to compile it its worth the trouble. Or there’s always GEdit.
EdG

Users.

Filed under: Miscellaneous — edg @ 10:52 am

I was just thinking about how every user of webcp is a user at some level but if you want to backup domains you have to look at domains, not the users who own them, makes sense but would it be easier if we just used various users inside webcp and store domains as users? obviously there has to be a concept of a domain just would it be easier if a user was more than the user concept we have now.

July 29, 2007

Backups progress

Filed under: New Features — edg @ 10:52 am

Okay, i thought i’d provide an update as to what’s going on with the backups module. Everything functions fine as to creating a backup and the process for restore is very similar but putting domain backups inside reseller backups and things like that are more complicated. Due to this i have followed the policy of one run of backup.php means one reseller, domain or user backup so far.

I have since decided to move backup.php to backups_backup and to make this run as a hook. The alternative was forking a backup function (which would have been very similar to just calling the hook anyway). If the hooks method doesn’t work out i will go back to the forking idea. But for now i’m working towards easy maintainability which means hooks.

I just committed an update in the CVS to webcp.php to improve the method used to tell the backend to call a hook. This now allows you to send $data to it in the $extra part of commit with the module to run rather than just the module to run. Whether data is global or not isn’t really helpful to me because obviously the backend and frontend are seperate so data has to be sent anyway. Now you can call a hook with some data in the backend from the frontend. In future i think forking the call_hook would be a good idea for security and performance. Maybe the seal should be checked or something i don’t know.

The idea is to register hooks as follows to allow a single call to call_hook(’server:commit:backup’, $data) to run the whole process from start to finish.

// Setup backup hooks
register_hook('server:commit:backup', 'backups_backup');
register_hook('server:commit:backup', 'backups_generate_archive');
register_hook('server:commit:backup', 'backups_ftp_archive');
register_hook('server:commit:restore', 'backups_ftp_archive');
register_hook('server:commit:restore', 'backups_restore');

Clearly calling server:commit:backup will be done by webcp.php using commit(’module’….). The idea is that the backup, generate_archive, ftp_archive and any other functions will all run on the data in sequence (i may have to sepcify priority to confirm they run in order i know there’s a way to do that with register_hook). This should make maintaining the module simple if all goes to plan.

Right now i’m working on moving to hooks rather than relying on calling backup.php from the backend with specific data and gathering it later.
EdG