My solution to this issue is to have multiple servers running the OpenSRS software. The servers are at different locations. If one of the servers goes down the registrations are redirected to one of the other servers. The IP's of each server is logged at OpenSRS. so If I am doing maintenance on a weekend and take a server off line, The other servers can process the requests.
If you are involved in on line ecommerce you need server redundancy of this nature, and I recommend you investigate a setup such as this. Michael At 02:51 PM 12/23/2001 -0500, Charles Daminato wrote: >I'll look into getting this added in a maintenance cycle. As for b), any >co-lo that does not provide you IP addresses with plenty of time to notify >your own suppliers/customers/whathave you is not a very good co-lo > >The only problem being security. If your RWI password gets compromised, >then someone will then have access to change your Crypt key (a level of >security) AND add IPs to your list (another level of security). I'll >discuss internally and see what we can do... > >Charles Daminato >TUCOWS Product Manager >[EMAIL PROTECTED] > >On Sun, 23 Dec 2001, dnsadmin wrote: > > > > > There should be an option in the RWI to modify "in real-time" the IP > address > > used for the registration server allow list. > > > > There are times (during OpenSRS non-business hours) when: > > ========================================================= > > > > a) A server becomes corrupt, and another server at a different IP address > > needs to take over the Manage.cgi and Domain registration duties. > > > > b) Someone moves networks during the weekend (or late at night) and > needs to > > update the current IP address for the registration server allow list. > > > > c) Where someone incorrectly gave the wrong IP address by mistake on Friday > > to OpenSRS staff, and has to wait the entire weekend to pass before this > > mistake can be corrected. > > > > If the feature was logged, and resellers were responsible for whatever IP > > address they added, I think there is no issue preventing such a feature > from > > being utilized. > > > >
