November 1998 - lir-wg - mailman.ripe.net

Performance of auto-dbm, Thu, 27 Nov 1998
by RIPE Database Administration 26 Nov '98

26 Nov '98

Dear Colleagues, We had some performance problems this morning and we had to temporarily stop updates in order to restore performance to its usual level. Updates were restarted as soon as we had finished working on this problem and the queue of updates was quickly processed. We appreciate your patience and we assure you that your updates were not lost. During this time, they were stored; there is no need to send them again. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

RIPE Database incident of 27th October
by Joao Luis Silva Damas 16 Nov '98

16 Nov '98

Dear all, the RIPE NCC Database group has been reviewing the events regarding the RIPE Database incident of 27 October. We have produced a report that can be found at http://www.ripe.net/db/incident.html All data sent to the database, related to this incident, is accessible through this URL. If you have any questions regarding this incident or otherwise related to the RIPE Database we will be glad to answer them. Best regards, Joao Damas RIPE DB Group RIPE NCC

1 0

Réf. : From Address Forged
by GALL Thierry TPC-SRD 06 Nov '98

06 Nov '98

Actually, the address was "forged" but only partially by Trevor, and Hostmaster was in copy of the mail, More over it was an attempt to repair the original error and to avoid the work necessary to rebuild all the links that have destroyed. Please apologize again for all these perturbations. Thierry GALL

6 7

Re: Massive changed in the Ripe Database..
by Petra Zeidler 05 Nov '98

05 Nov '98

Thus wrote Mike Norris (mike.norris(a)heanet.ie): > > well we should collect money for Mr. McBryan to spend him a > > two-week-last-minute-trip to ... lets say mallorca without > > internet access, then the community has time to fix all the > > mistakes he made :-))) > > Maybe he's signed up for one of the RIPE Local IR > training courses; wouldn't that be a lot better? shoot him to the moon? :-3 Would suit my feelings better .. anyone can err, but then messing with my repair work by faking our headers is way off bounds. This whole little escapade cost Xlink about 3 man-days work, and we're not finished mopping up yet. kind regards, Petra Zeidler -- [X] Xlink Internet Service GmbH | | i.A. Petra Zeidler, Neukundenanschluss | zeidler(a)xlink.net | | Vincenz-Prie_nitz-Stra_e 3 [X] D-76131 Karlsruhe | Tel: 0721/9652-220 [X] Fax: 0721/9652-209 | | Geschdftsf|hrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. | Auftrdge erledigen wir zu unseren Allgemeinen Geschdftsbedingungen. ---------------------------------------------------------------------[ ]

6 5

Re: Events of Tuesday, 27 October 1998.
by Daniel Karrenberg 03 Nov '98

03 Nov '98

Harvard , thank you for your support. It is indeed not straightforward to roll back specific changes in a database that receives thousands of upates each day which are not independent of each other. One thing we have leared from this is that it may be a good idea not to re-use handles before some time period has expired in order to facilitate tis process. However there are other interdependencies as well and it will be impossible to design a system to roll back any amount of changes consistently and repecting constraints such as authorisation. I further would like to point out to everyone that we do provide authorisation and authentication methods *for more than five years* already. Those who used them properly weree not affected by this mistake at all! If you want to be safe, all you have to do is to use authorisation on your objects. See ripe-120 on how to do that. mLaswly, and maybe unnecessarily, I'd like to stress that we indeed have backup procedures in place which are designed to cope with failures under our responsibility, such as machine or storage media problems. If you have any further questions, please do not hesitate to contact us. Kind regards Daniel Karrenberg RIPE NCC Manager > Havard.Eidnes(a)runit.sintef.no writes: > > It is important to understand that the data in the RIPE database is > maintained by the users of the database, and not by the RIPE NCC > itself. > > I suspect that the problem is that a backup cannot easily be used to > restore the current "desired" state (minus the unfortunate update). > The reason is that old NIC handles may have been recycled, i.e. > reassigned to another object, and that object can subsequently have > been referenced by an explicit use of that recycled NIC handle in an > update. Sure, the subsequent updates could perhaps be doctored to > remedy this, but that is perhaps not easily or quickly done, and would > also mean "intervention in the data maintenance" by the RIPE NCC. > > I would thus tend to turn the argument above on its head and say that > we collectively, the maintainers of the data in the RIPE database, > have made inadequate use of the already available methods for > protecting the data we maintain there from unauthorized updates or > removals.

4 6

Events of Tuesday, 27 October 1998
by RIPE Database Administration 03 Nov '98

03 Nov '98

Dear Colleagues, On Tuesday, 27 October 1998, a user of the RIPE Network Management Database accidentally deleted many [person] objects. The objects affected were either not maintained by a 'mntner' object or were maintained by a 'mntner' object with an authentication mechanism of NONE. The RIPE NCC has investigated this and learned that it was a genuine mistake by this user. When a person object is deleted, its nic-handle is available for re-use immediately. Therefore, you may find that a nic-handle now points to a different person or role object. We recommend that you check the consistency of your data i.e. see if the nic-handles in the admin-c, tech-c, and zone-c lines of your objects refer to the correct person or role objects. We understand that an attempt was made to re-create the deleted objects by the individual who originally deleted them. Please search for your person objects using both the name and the nic-handle. It is possible that your object has been re-created, but with a different nic-handle. If so, you must update your inetnum, route, mntner, etc. objects that refer to the previous nic-handles in the admin-c, tech-c, and zone-c lines. You should replace the old nic-handles with the new ones. To check whether a certain nic-handle is referenced anywhere, you can use the inverse look-up flag. For example, you can do: "whois -i admin-c,tech-c,zone-c <nic-handle>" to see if that nic-handle is referenced anywhere as admin-c, tech-c, or zone-c (e.g. as in domain objects). If one or more of your person and/or role objects have not been re-created, we suggest that you first try to re-create them using the original nic-handle. This way, you do not have to change any of the references that use this nic-handle. If the nic-handle has been re-used, you should try to create the person or role object with the AUTO-1 keyword. In this case, however, you will have to change the inetnum, domain, or other objects that reference this nic-handle to point to the new one. (Use the the "-i" flag mentioned above to find which objects reference the old nic-handle). The RIPE NCC shall, as a part of its service to the RIPE community, support users to restore their data to a consistent state. We estimate that this should take about one working day. Please note that it is the users responsibility to restore their own data. We would like to stress that the RIPE NCC operates the RIPE Database, however the responsibility for managing user data lies with the users. Mechanisms to protect data against unauthorised or unintentional modification exist for several years now. The RIPE NCC has always emphasized the importance of authentication mechanisms and has been recently working to introduce even stronger procedures. We encourage users to deploy these authentication mechanisms. Please read ripe-157, section 2.3 on how this works. If you have any problems with the RIPE Database, please send an email to <ripe-dbm(a)ripe.net>. Regards, The RIPE NCC Database Group.

2 2