October 1995 - db-wg - mailman.ripe.net

Re: db under solaris
by RIPE Database Manager 18 Oct '95

18 Oct '95

Dear All, First of all: thanks for all your reports! I am not sure what to believe now ... I did some further research. I got a report from Chua Koon Teck at 20 Apr 1995 that it was possible to run at least the whois daemon on Solaris 2.4 with perl5 (yes!): > Anyway, I am using perl5.001 and it seem to be fine so far. But you will > need to edit the defines.pl and defaults.pl file under the lib > directory. The newer version of perl require a backslash before the @ > symbol. So Tony please also look at the defines.pl and defaults.pl files for the @ signs (will of course be changed in the next distribution). If you still don't succeed I am happy to help you further but then I need some more details about error messages and of course I want to hear from Chua Koon Tek about the current state of their database. Kind regards, David Kessens RIPE NCC Database maintainer PS I don't think the db-wg is the platform for this kind of implementation detail questions. Let we first try to find out what happened and send a report to the db-wg when (un)successfull! -------- tonyb <tonyb(a)pipex.net> writes: * RIPE Database Manager wrote: * > * > * >Hi Tony, * > * >If you use perl4 and change the SOCK_STREAM variable to 2 instead of 1 * >it should work. This value is used and hardcoded more then once in the * >code. In the next distribution this will be handled from the Makefile but * >that doesn't help you now ... * > * Hi David, thanks for the reply, I had managed to find the cause of that * one. Unfortunately as guy davies has now confirmed the dbdoesn't work on * solaris :-( * * We will have to wait for the next version. Any idea of the expected date * or release ? * * Thansk * ____ * / \/ * /<>/\// * Tony Barber Phone : +44(0)1223 250122 * Technical Support Email : support(a)pipex.net * *

1 0

Server updates for WWWhois
by Paolo Bevilacqua 16 Oct '95

16 Oct '95

Hello, As requested at the last WG meeting, i'm going to complete the list of the whois servers supported by the Web interface that is available at: http://black.uni.net/cgi-bin/whois After this step you're welcome to install this script at your site. Please mail me about the known servers and the associated email address for updates.

1 0

db under solaris
by tonyb 12 Oct '95

12 Oct '95

Hi, has anyone managed to tweak the perl whois server to run under Solaris ? Is it an easy fix ? Thanks ____ / \/ /<>/\// Tony Barber Phone : +44(0)1223 250122 Technical Support Email : support(a)pipex.net

2 1

RE: Inconsistent NIC handles
by Wilfried Woeber, UniVie/ACOnet 10 Oct '95

10 Oct '95

Dear Janos! >Theoretically the NIC handle is supposed to uniquely identify the person. More precisely: ... a uniquely assigned Handle is supposed to... >The problem I noticed is that somebody (inadvertently) registered a person >with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the >RIPE database. This is a perfectly legal situation, as long as the person being described has a unique handle assigned already, probably from the InterNIC. Obtaining a unique handle from the RIPE-NCC (of the form xyz999-RIPE) and then registering the person object *without* the "-RIPE" suffix string is clearly an error. The overall scheme is that the InterNIC has in the past assigned, and continues to do so, handles of the form xyz999. Every other source of unique handles assignes strings of the form xyz999-suffix, the suffix being unique in itself. The string "-RIPE" is used for the RIPE Handles. Registries in the Asia/Pacific region are reported to use suffix strings derived from the ISO3166 country codes. >The result is an inconsistency between the two databases >(RIPE and Internic). One gets different answers, depending on whom one asks the >question. Not necessarily so! The IneterNIC is expected to accept handles assigned by other regsitries interchangably when importing data (objects) from other sources. Btw, has this been tried by anyone recently? Please feel free to ask more questions if this is still in the dark :-) Wilfried. PS: If you could point out the affected objects we could possibly find out what went wrong or if there is really a flaw in the logistics... -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

3 3

RE: Inconsistent NIC handles
by zsako＠banknet.net 09 Oct '95

09 Oct '95

> From woeber(a)cc.univie.ac.at Mon Oct 9 11:39:50 1995 Dear Wilfried, > >The problem I noticed is that somebody (inadvertently) registered a person > >with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the > >RIPE database. > > This is a perfectly legal situation, as long as the person being > described has a unique handle assigned already, probably from the > InterNIC. I know, this is how I am registered myself (JZ38). > >The result is an inconsistency between the two databases > >(RIPE and Internic). One gets different answers, depending on whom one asks the > >question. > > Not necessarily so! The IneterNIC is expected to accept handles > assigned by other regsitries interchangably when importing data > (objects) from other sources. I am sorry if I was not clear enough. This is not a theoretical question. A mistake had actually been made. I did not (and still do not) want to make public (to such a big audience) the concrete case, since I do not want to offend the person (and the registry in last instance) who made this mistake. I will let you know by private mail. (I had already notified David before I sent the original message). > PS: If you could point out the affected objects we could possibly find > out what went wrong or if there is really a flaw in the logistics... See above. Best regards, Janos

1 0

Inconsistent NIC handles
by zsako＠banknet.net 09 Oct '95

09 Oct '95

Dear all, I have just come accross a problem with the RIPE database. I am sorry to bother you if this has already been discussed. What I noticed is an inconsistency problem between the different databases that keep the same type of information (in this case _person_ objects). Theoretically the NIC handle is supposed to uniquely identify the person. The problem I noticed is that somebody (inadvertently) registered a person with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the RIPE database. The result is an inconsistency between the two databases (RIPE and Internic). One gets different answers, depending on whom one asks the question. I can think of two approaches to solve this problem: - First is checking for the "-RIPE" suffix in the "nic-hdl" attribute when updating a person object (whenever nic-hdl is not empty) - Second is checking (whenever possible) for inconsistencies with the apporpriate database (in our case one could check the person object in the Internic database). I think the first approach can be too restrictive (it would not allow for redundant data between the databases, which otherwise can be useful for saving bandwidth on frequent queries). This would nevertheless have the benefit of preventing people from registering the same thing in several places (and forget to update some of them eventually). Probably the badwidth saving can be better addressed with the sites that keep the large databases 'mirroring' each other. The second approach can be too complicated in case one would like to check more than just the name of the person. There might be problems with the name as well in case of several 'first' names for example. Nevertheless I feel some basic check would be welcome... Best regards, Janos Zsako

1 0

Mailing List
by Sushant Pujari 04 Oct '95

04 Oct '95

Hi, I would appreciate if you could add me to the mailing list. I might be using the ripe code for my work. Thanks -pujari

1 0

(temorary) solution for the database index problems ?!?!
by RIPE Database Manager 02 Oct '95

02 Oct '95

Dear all, The last days I did some further research with Benoit Grange and Willi Huber (they both run SUN OS, so we could use each others binaries) on the recent indexing problems. This morning I found out that the problems disappear when you don't use the '-p' prime option in netdbm. This option adds dummy objects to the database to make the lookups faster. So for the temporary solution: Do *NOT* use the '-p' option in netdbm !!! I am not sure yet if there is a bug in the code or that certain 'dbm' versions cause the problems. I will investigate further ... Kind regards, David Kessens RIPE NCC Database software maintainer --------

4 7

RIPE22: proposal for draft agenda, DB-WG
by Wilfried Woeber, UniVie/ACOnet 02 Oct '95

02 Oct '95

This is the 1st proposal of a draft agenda for the DB-WG at RIPE 22 in Amsterdam. **Message to the NCC (automatic? :-) WG scheduling department: If at all possible - please have the DB-WG meeting scheduled in the streams as late as possible. Thank you! As always, additons, comments, etc. welcome! Apologies if I missed something obvious... Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 22, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff . who's taking the minutes? . WG-agenda 1. DB-SW review . new or proposed functionality . recent bug fixes, scaling issues, portability . RIPE Handles 2. User interface(s) . stronger authentication of updates, e.g. PGP . Web interfaces for search and/or updates 3. External interfaces . DB-exchange . first steps towards distributing the database 4. Input from other WGs . extensions for the router object (input from Mbone WG?) Z. AOB WW, 28.9.1995 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

3 2

Unsubscribe
by Oliver Smith 02 Oct '95

02 Oct '95

Unsubscribe [Sorry if this hits the list by accident; the db-wg-list address didn't work for me?]

1 0