On Thu, 2008-06-12 at 22:25 +0300, Mircea Carasel wrote: > Hi, > First of all thanks a lot Kevin for your review. > I would like to share on the list some comments and explanations > regarding the implementation of this feature, based on your comments: > > 1) - When backup is performed it is uploaded on the ftp server on the > location that is exposed by the supplied ftp username/password. > Depending on what username/password is provided by accessing the > Backup/Restore Ftp Configuration page the backups will be uploaded in > that location. > For instance the administrator can configure the FTP server with how > many user he wants - each user having therefore a coresponding uploading > location > The location that is specified in the sipxconfig.properties - ftpBackup > - is used in the ftp backup process like this: > First the files are temporary saved on local sistem in the ftpBackup > directory (located in the same path as the "backup" directory -> > /usr/local/sipx/var/sipxdata) > and then are uploaded on the ftp server in the location exposed by the > username/password provided in the FTP Backup/Restore Configuration page > When the user issues another ftp backup operation the previous temporary > savings are deleted > > So my opinion is that in fact the sipXconfig should not be aware of the > remote ftp path where the backup is uploaded - this path is > automatically exposed with the FTP connection, depending on the > username/password supplied. So the administrator should configure the > FTP server itself with what users he wants - with what paths he desires. > In this way the Backup/Restore is easy to handle - we can have one ftp > server with many users and therefore many remote ftp upload paths. > We can pick any path we want just by providing the coresponding > username/password
In general, it's not a good idea to make the correct operation of a sipXecs feature depend on the administrator having correctly set up the configuration of some other system (witness all the trouble we've had with DNS and DHCP). In this case, allowing an optional directory path would seem to add some flexibility that would reduce the need for external configuration (essentially, that path needs to be configured either in the ftp server or in our system anyway, so I think it's better if it's in ours). -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
