Release Candidate Environment
Information About Services
|command line||whois-rc.ripe.net, port 43|
|command line, TEST Database||whois-test-rc.ripe.net, port 43|
|syncupdates, TEST Database||http(s)://syncupdates-test-rc.db.ripe.net|
|REST API, TEST Database||http(s)://rest-test-rc.db.ripe.net|
|mailupdates||rc-dbm _at_ ripe _dot_ net|
Differences From Live RIPE Database
- For each mntner object in the Release Candidate database, the passwords have been set to the object id. For example, the object:
inetnum: 188.8.131.52 - 184.108.40.206
can be changed by supplying the password: ninja-mnt. Regardless of the passwords used in the live RIPE Database, in the Release Candidate database they have been adjusted to reflect the mntner id.
- The databases are snapshots of live RIPE Database data, dummified in the beginning of each new testing period. The dummification of personal data follows the rules described here: Proposed algorithm
- No emails are sent from the Release Candidate system. This means no response from mailupdates submissions to the Release Candidate database, no ack or notify emails are sent by the Release Candidate database.
As in the live RIPE Database, Access Control Lists (ACLs) are active. Even though the personal data in the Release Candidate database is dummified, ACLs are active to ensure it operates in the same way as the production system.
Even though the Release Candidate database contains a snapshot of the live data from the start of the testing period, no changes made to the Release Candidate database will have any impact on the live RIPE Database data. The two are completely separated.
Any scripts or automated processes you use to maintain your data in the RIPE Database can be used with the Release Candidate database - simply adjust the URLs accordingly. The whole purpose is to allow you to test your processes as closely as possible to the actual RIPE Database using newly developed and released software.