| Reseller Help: Reseller Tools Help : Going LIVE | |
| My Web server is a shared virtual host. Can I still install the OpenSRS client s | |
| Can I just use Quickstart instead of setting up OpenSRS Client scripts on my Web | |
| What do I need to run the OpenSRS client software? | |
| What is the OpenSRS policy on "spam" (unsolicited commercial Email)? | |
| What is the OpenSRS policy on our RSPs misrepresenting themselves as ICANN accre | |
| Why doesn't OpenSRS offer a nameserver for the use of RSPs? | |
| Where do I start? | |
| I just want to register a few domains. Is OpenSRS for me? | |
| In OpenSRS lingo, what do these terms mean? | |
| Do I have to do anything special to run the OpenSRS client software scripts on Microsoft Windows? | |
| Where can I download the OpenSRS Client software? | |
| How do I uncompress a *.tar.gz ("tarred and gzipped") file? | |
| When downloading a *.tar.gz file using Windows, the file was saved as a *.tar.tar! | |
| What is PERL? | |
| Where can I download the PERL modules? | |
| Do I need root access to my server to install the Full Access scripts? | |
| Can you help me set up Linux? | |
| Can you help me set up my web server? | |
Q:My Web server is a shared virtual host. Can I still install the OpenSRS client software scripts on it? | |
A:For more information on the theory behind virtual hosting and virtual servers, please see: whatis?com It may be possible so set up the OpenSRS client scripts on a virtually-hosted Web server, but much will depend on your working relationship with your service provider. The OpenSRS client software scripts were created with the assumption that you have root access to your server. A virtual hosting provider will very rarely, if ever, give out the root password for any of their servers. They may be willing to do the root-access tasks for you. This includes, but may not be limited to, installing the PERL modules, permissioning files appropriately, and setting the scripts to be executable by the Web server. Then you should be able to configure the scripts to your liking. It may be possible to install the PERL cryptography modules without root access. See this article help with root and non-root PERL module installation: http://www.rcbowen.com/imho/perl/modules.html Assuming these conditions are met, you still have one more hurdle. What's your IP address? One of the conditions for your client scripts to authenticate with the OpenSRS registration server is that its IP address must be in our IP allow list for your account. A virtual Web server usually answers to many IPs, at least one for each Web site hosted on it. The IP address of your specific Web site will not work for authentication purposes. The virtual Web server usually makes outbound connections identifying itself by one specific IP, the "gateway" IP address. This is the IP address we need to know. If your Web hosting provider will not give you this IP address (and some overly paranoid sysadmins erroneously consider giving out their server's IP to be against good security practices) you will never authenticate with our production server to register domains. If you can browse the Web from your server, you can find your IP address using an online script by Lawrence Goetz (this works with Lynx too): http://www.lawrencegoetz.com/programs/ipinfo/ You can also try this script from http://www.myip.dk | |
 | |
|
Q:Can I just use Quickstart instead of setting up OpenSRS Client scripts on my Web server? | |
A:Yes. Both Quick Start Access and Full Access utilize the OpenSRS system, though they access it through slightly different means. Quick Start Access allows Resellers to quickly and easily enter orders manually through the Reseller Web Interface or RWI. With Quick Start there is no need to develop code. Automated, real-time transaction processing is available from a Full Access implementation. This complete integration is achieved through an Application Program Interface or API that can be created using PERL or a variety of other programming languages. While there are two options, which is best for a particular Reseller depends on a number of factors, including; registration volumes, approach to customer support and desired level of process automation. | |
| |
|
Q:What do I need to run the OpenSRS client software? | |
A:In theory, the OpenSRS client software scripts are platform-independant. The OpenSRS client software scripts assume some familiarity with Unix systems administration, Web server administration, CGI scripting, and PERL. If you do not have these resources at your disposal, I would suggest you opt for the Quickstart process (which enables you to use our live Web interface only) as an interim solution while you get a contractor who has these skills. This FAQ contains a list of people who have offered their services as contractors specifically for OpenSRS client software script installation/maintenance/modification. The basic requirements for running the OpenSRS client scripts ("Full Access") are: 1. Web server which allows CGI execution (e.g. Apache, http://www.apache.org/) Versions 2.2 and above also needs an XML Parser. 2. PERL 5 (Minumum version 5.6) http://www.perl.com/ 3. PERL cryptography modules, downloaded separately from CPAN http://search.cpan.org/ Specifically, you need the PERL module Digest::MD5, and either Crypt::DES or Crypt::Blowfish. We recommend Blowfish - it's a faster and more cryptographically secure algorithim that has none of the platform-specific endian issues. DES is still supported for backward compatibility. A complete list of required modules is available via the verify_install.cgi Please note that you do not need Crypt::IDEA. It is an optional module which Crypt::CBC can link against, but it is not used by OpenSRS. 4. A valid username and password issued by OpenSRS. You can obtain a username and password for the testing environment (i.e. domain registrations won't actually appear on the Internet) here: https://horizon.opensrs.net/subscribe 5. A valid "private key". Once you have your username/password, you will need to login to the RSP admin area and generate your key. You can change this key at any time should you feel that it has been viewed by others. The RSP admin area of the test environment is located here: http://resellers-test.opensrs.net 6. Root access to the server is usually required to install/configure Apache and to install the PERL modules. If your Web site is virtually hosted, or you are unable to get root access to the server, you may need the server admin to perform these tasks for you. Non-root module installation may be possible too. Please refer to this article on root and non-root PERL module installation: http://www.rcbowen.com/imho/perl/modules.html 7. A dedicated connection to the Internet with a static IP address. We will need to know the main (a.k.a. gateway) IP address of the server running the scripts in order to allow you to access the live server. Note: RSPs are responsible for setting up their own payment systems. The OpenSRS Support Team can't offer any support in that area. Our customers have live clients successfully running on various flavours of Unix (Linux, BSD, Solaris and others), and Windows NT/2000 (thanks to a how-to written by a a discussion list participant). Much of the original development and testing was on RedHat Linux. The OpenSRS Support Team can offer some assistance getting the scripts to run on most common Unix platforms. Windows NT/2000 users are referred to a third-party how-to: http://www.atlcon.net/opensrs/nt-howto-v2.2.htm We encourage our customers to take advantage of the discussion lists to exchange ideas with other OpenSRS RSPs and developers. Details on joining can be found here: http://discuss.tucows.com | |
| |
|
Q:What is the OpenSRS policy on "spam" (unsolicited commercial Email)? | |
A:This policy is taken from the original discuss-list posting by Ross Wm. Rader: TUCOWS neither condones or endorses the use of bulk unsolicited commercial email to promote any aspect of your business. Section 12.1.b of the RSP Agreement is the governing formal policy when it comes to any sort of illegal activity. "The execution, delivery, and performance of this Agreement and the consummation by the Reseller of the transactions contemplated hereby will not, with or without the giving of notice, the lapse of time, or both, conflict with or violate (i) any provision of law, rule, or regulation, (ii) any order, judgement, or decree, (iii) any provision of corporate by-laws or constating documents, or (iv) any agreement or other instrument;" In every instance where it is sufficiently demonstrated that an RSP has violated any applicable law as it relates to the performance of the agreement during the term of the agreement is in violation of the agreement and will be subject to the terms of cancellation for material breach as outlined in the agreement. Translation: If an RSP breaks the law for the purpose of providing domain name sales (this includes fraud, theft, SPAM in some jursidictions), we will not hesitate to cancel their agreement with us. Note that this contractual term is in force in addition to others found in the agreement. Other provisions touch on the issue of SPAM in various ways. (ie, WHOIS data-mining etc.). Each situation is ostensibly a different case and will be treated accordingly. Summary While our agreements are the sole determinant of what we can reasonably expect from our partners, we hope that our RSPs undertake their burden in a manner similar to us. There are no absolutes in this world and going above and beyond the letter of an agreement and working to uphold the intent is what will ultimately set us apart as moral, ethical and solid businesses that customers and suppliers enjoy doing business with. We take our obligations very seriously. For a complete understanding of what our policy stance is based on, please review the Network Solutions Registrar License and Agreement, the ICANN Accreditation Agreement and our Registration Service Provider Agreement. These document represent 100% of our views on these and other very important issues. NSI RL&A - http://www.icann.org/nsi/nsi-rla-04nov99.htm ICANN Accreditation Agreement - http://www.icann.org/nsi/icann-raa-04nov99.htm OpenSRS RSP Agreements I hope this that clears up a few questions that some of you may have. If you need further information, please do not hesitate to contact me at your convenience. Thanks, Ross Wm. Rader | |
| |
|
Q:What is the OpenSRS policy on our RSPs misrepresenting themselves as ICANN accredited? | |
A:This policy is taken from the original discuss-list posting by Ross Wm. Rader: ICANN Accreditation ICANN has a very simple policy on this subject. Only ICANN accredited registrars can say that they are ICANN accredited. Additionally, only companies that have signed the ICANN Accreditation Agreement can display the ICANN logo in conjunction with domain name sales. These are trademarks and copyrights that they have sole right to license to third parties. We are a beneficiary of this right, none of our RSPs are. This is governed by the ICANN Accreditation Agreement that states: "Registrar is hereby granted a non-exclusive worldwide license to state during the term of this Agreement that it is accredited by ICANN as a registrar in the .com, .net, and .org TLDs. No other use of ICANN's name is licensed hereby. This license may not be assigned or sublicensed by Registrar." Again, simply put, we have no right to allow our RSPs to use any of ICANN's marks. Further, very few of you are ICANN Accredited, therefore you cannot say you are. We will cooperate with ICANN wherever required to assist with the enforcement of their legal rights. Summary While our agreements are the sole determinant of what we can reasonably expect from our partners, we hope that our RSPs undertake their burden in a manner similar to us. There are no absolutes in this world and going above and beyond the letter of an agreement and working to uphold the intent is what will ultimately set us apart as moral, ethical and solid businesses that customers and suppliers enjoy doing business with. We take our obligations very seriously. For a complete understanding of what our policy stance is based on, please review the Network Solutions Registrar License and Agreement, the ICANN Accreditation Agreement and our Registration Service Provider Agreement. These document represent 100% of our views on these and other very important issues. NSI RL&A - http://www.icann.org/nsi/nsi-rla-04nov99.htm ICANN Accreditation Agreement - http://www.icann.org/nsi/icann-raa-04nov99.htm I hope this that clears up a few questions that some of you may have. If you need further information, please do not hesitate to contact me at your convenience. Thanks, Ross Wm. Rader | |
| |
|
Q:Why doesn't OpenSRS offer a nameserver for the use of RSPs? | |
A:OpenSRS is a wholesale domain name registrar. We do not provide any ISP related service. Our full access RSPs are required to set up their own Web servers on a dedicated connection for using the OpenSRS client software scripts, therefore we also expect they can set up their own nameserver or at least arrange for nameservice with another service provider. More information on DNS (Domain Name Service) can be found here: http://www.oreilly.com/catalog/dns3/chapter/ch02.html If you're running a Linux server, you may also find this link useful: http://www.linux.org/help/ldp/howto/DNS-HOWTO.html | |
| |
|
Q:Where do I start? | |
A:If you haven't thoroughly read the material on our site then you are strongly recommended to do so: http://rrc.tucows.com/opensrs_platform/. If you are not yet signed up with OpenSRS and want to get started right away, feel free to follow the instructions located here. This will allow you to begin the RSP (Registration Service Provider or "reseller") application process. | |
| |
|
Q:I just want to register a few domains. Is OpenSRS for me? | |
A:Probably not. OpenSRS is a service for organizations that register at least 50 names a year. Many of our customers register much more than that. In order to register domains using OpenSRS, you will need to: * Complete and return our contractual agreements * Install our PERL based tool on a PERL capable machine. (Quickstart customers can start registering domains via our Web interface before they've completed the installation on their own server) * Pre-pay $95 (US dollars) non-refundable activation fee. If you want an easier process for registering domain names, Please Email sales@opensrs.org and they will give you a name of a few RSPs to contact. | |
| |
|
Q:In OpenSRS lingo, what do these terms mean? | |
A:"ICANN" is the Internet Corporation for Assigned Names and Numbers (ICANN), a non-profit corporation that was formed to assume responsibility for the IP address space allocation, protocol parameter assignment, domain name system management, and root server system management functions now performed under U.S. Government contract by IANA and other entities. http://www.icann.org/ "Registry" is the term used for the main database of an entire TLD. It is also sometimes used to describe the company that controls that database. For example, Versign controls the registry for com/net/org domains. CIRA is the Registry for .ca domains. A "Registrar" (or "Domain Name Registrar") is an organization like Network Solutions, OpenSRS, or the Canadian Domain Name Registry that has control over the granting of domains within certain TLDs (top level domains, like the generic: .com/.org/.net or country-specific: .ca/.us/.mx etc.). "Reseller" is a generic term for an RSP (Registration Service Provider), a term used to describe a customer of OpenSRS that resells domains. | |
| |
|
Q:Do I have to do anything special to run the OpenSRS client software scripts on Microsoft Windows? | |
A:We have customers currently running our scripts on the live system under Windows NT 4 and Windows 2000 with ActivePerl. One of these customers has written an OpenSRS NT "how-to" and graciously provided it to the OpenSRS community: http://www.atlcon.net/opensrs/nt-howto.htm We do not recommend and we will not support attempts to implement the client software on Windows 3.11/95/98 or Windows NT prior to version 4.0. Please do not ask us for help on these platforms. | |
| |
|
Q:Where can I download the OpenSRS Client software? | |
A:You can download the OpenSRS Client software from the Download Library (look in the "current" folder) at http://rrc.tucows.com/resources/downloads/current/ | |
| |
|
Q:How do I uncompress a *.tar.gz ("tarred and gzipped") file? | |
A:To uncompress it, the following commands work on Linux (for example): $ gunzip opensrs-client-2.2.tar.gz [This will "gunzip" it, and turn the ".tar.gz" into a ".tar".] $ tar -xvf opensrs-client-2.2.tar [This will use tar (Tape ARchive) to "untar" it, and create a new folder in the current directory and uncompress all the files into it.] See the man (manual) pages for gunzip and tar if you're having problems. | |
| |
|
Q:When downloading a *.tar.gz file using Windows, the file was saved as a *.tar.tar! | |
A:Some older browsers on the Windows platform simply don't know what to do with a *.tar.gz file. If you have an older browser, you might consider upgrading. As a workaround: in Netscape, right-click on the link for whichever is the most recent version and choose "Save Link As..." and then make sure the file is saved with the correct name and extensions (.tar.gz) as it appears on the Web page. This method may work for other browsers as well. | |
| |
|
Q:What is PERL? | |
A:The OpenSRS Client software has been written using PERL 5 (Practical Extraction and Reporting Language), a cross-platform, interpreted language that functions on a wide variety of platforms. For more information on PERL and how to set your system up to run PERL applications, tons of handy resources and tips can be found here: http://www.perl.com The minimum tested version is 5.6. Please use the latest stable version for your operating system. | |
| |
|
Q:Where can I download the PERL modules? | |
A:The PERL modules can be found by searching CPAN (the Comprehensive PERL Archive Network) at: http://search.cpan.org/ This article may help you if you have problems installing the modules: http://www.rcbowen.com/imho/perl/modules.html | |
| |
|
Q:Do I need root access to my server to install the Full Access scripts? | |
A:Although not the prefered method, it may be possible to install the PERL crypography modules without root access. See this article help with root and non-root PERL module installation: http://www.rcbowen.com/imho/perl/modules.html Unfortunately, OpenSRS Support can give only the most general assistance in installing PERL modules and scripts onto your server. Every system is different and you must be familiar with your set-up in order to get everything installed. | |
| |
|
Q:Can you help me set up Linux? | |
A:The support team can try to help you with specific questions relating to Linux and UNIX in the context of the OpenSRS client software scripts but installation and setup of Linux is outside the scope of our support. However, here are some good starting points to learn more about Linux: http://howto.tucows.com/ http://www.vlug.org/ | |
| |
|
Q:Can you help me set up my web server? | |
A:Web server setup and administration is outside the scope of support offered by the OpenSRS Support Team. The OpenSRS client software scripts assume some familiarity with Unix systems administration, Web server administration, CGI scripting, and PERL. If you do not have these resources at your disposal, I would suggest you opt for the Quickstart process (which enables you to use our live Web interface only) as an interim solution while you get a contractor who has these skills. This FAQ contains a list of people who have offered their services as contractors specifically for OpenSRS client software script installation/maintenance/modification. The Newbie's Guide to Installing Apache: http://apachetoday.com/news_story.php3?ltsn=2000-07-03-001-01-NW-LF-SW The Apache FAQ: http://www.apache.org/docs/misc/FAQ.html An excellent article on this subject can also be found at: http://www.usenix.org/sage/sysadmins/howto/2.apache.html | |
| |