From Daniel.Karrenberg at ripe.net Tue Feb 15 09:55:37 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 15 Feb 1994 09:55:37 +0100 Subject: rr-impl list created Message-ID: <9402150855.AA01210@reif.ripe.net> The mailing list "Routing Registry Implementors" has been created. Membership is closed to Routing Registry Implementors. rr-impl has the following initial members: ala at Merit.edu dfk at ripe.net dsj at merit.edu epg at merit.edu lpj at merit.edu marten at ripe.net rlr at merit.edu tony at ripe.net rr-impl will be archived. The archive is private to list members. For all list administrivia, please mail rr-impl-request at ripe.net. Daniel -------- Logged at Tue Feb 15 10:49:02 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Feb 15 10:48:56 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 15 Feb 1994 10:48:56 +0100 Subject: routing registry In-Reply-To: Your message of Mon, 14 Feb 1994 18:02:49 EST. <9402142302.AA05211@fox.merit.edu> Message-ID: <9402150948.AA01231@reif.ripe.net> > dsj at merit.edu writes: > > As a side note, it would probably be beneficial to set up some sort of > > mail group for this sort of discussion. It might only have a lifetime > > of a few weeks but who knows. has been created. I'll give a few quick answers. Tony and Marten will fill in the gaps, I'm sure. > > (0) What checks are performed on the RIPE database. > > For example, > > (a) Policy conflicts such as AS X is announcing AS A to AS Y, but AS > Y isn't > > listening. > > (b) Syntax checking on as-in, as-out and various address fields. The tool prcheck does this. At this point we leave it to the users themselves to use the tools. > > (1) How are checks performed on the RIPE database. > > For instance, are there scripts which run out of cron to verify polic > y > > conflicts, etc. We do some regular checks on the database and store the results for pickup with FTP. Some of this is just syntax and not done too regularly. We daily compare policy information with what we see in well connected routers and flag the difference. See ftp.ripe.net:ripe/as. The conflict output is sent to operational mailing lists once a week. > > (2) What happens as a result of these checks? > > For instance, if a problem is found with some "as-in" field, is email > > sent automically to someone? And if so, to whom? Not at this point. > > (3) What happens if I register a net twice? The the present entry gets overwritten. > > (4) Can we really send (on a short-term basis) _all_ our registration dat > a? > > Will we break anything? Not to our knowledge. We will store the info with a separate source ID. This will require some changes to the tools. No big deal though. > > (5) How does one go about unregistering a net from the RIPE db? Just vi > > the file from within my guardian account? The network entry can be deleted by sending in an update with a pseudo attribute "delete:". A net can be removed from a group (AS, community) by removing it from the guardian file. > > (6) What is the process for handing out new accounts? How does a new net > work > > service provider get an account on ftp.ripe.net to register his/her d > ata? By sending a mail message to us at ncc at ripe.net. > > (7) Is the only RIPE db input method by logging in and vi'ing some files? > > In other words, there doesn't exist an email interface, etc. Updates and new entries can be sent by mail to . They will get processed automatically. We process around 15k a month. Guarded *objects* and requests with user questions can be sent to and be processed manually (about 60/month). > > I remember hearing something about fax and phone in orders. Does thi > s > > really occur and if so, how often? Thnakfully only for the Internet registry (address allocation) end of the business. Daniel -------- Logged at Tue Feb 15 11:36:53 MET 1994 --------- From Tony.Bates at ripe.net Tue Feb 15 11:36:39 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 15 Feb 1994 11:36:39 +0100 Subject: routing registry In-Reply-To: Your message of Tue, 15 Feb 1994 10:48:56 MET. <9402150948.AA01231@reif.ripe.net> Message-ID: <9402151036.AA07467@ncc.ripe.net> Daniel Karrenberg writes: * * > dsj at merit.edu writes: * > > As a side note, it would probably be beneficial to set up some sort o * f * > > mail group for this sort of discussion. It might only have a lifetim * e * > > of a few weeks but who knows. * * has been created. * * I'll give a few quick answers. Tony and Marten will fill in the gaps, * I'm sure. * Trying now ;-). * > > (0) What checks are performed on the RIPE database. * > > For example, * > > (a) Policy conflicts such as AS X is announcing AS A to AS Y, but * AS * > Y isn't * > > listening. As dfk said prcheck does this and is run by the providers. We have some plans to integrate this into the S/W when the PRIDE routines and more generalised. * > > (b) Syntax checking on as-in, as-out and various address fields. * Well actually, there is basic syntax checking which makes sure syntax is correct but has no real knowledge of the semantics (prcheck has this) as yet. As I said above it will be integrated in. * The tool prcheck does this. At this point we leave it to the users * themselves to use the tools. * * > > (1) How are checks performed on the RIPE database. * > > For instance, are there scripts which run out of cron to verify p * olic * > y * > > conflicts, etc. * * We do some regular checks on the database and store the results for * pickup with FTP. Some of this is just syntax and not done too * regularly. * * We daily compare policy information with what we see in well connected * routers and flag the difference. See ftp.ripe.net:ripe/as. The * conflict output is sent to operational mailing lists once a week. * There is also a job which fully syntax checks the database and this is mailed from time to time. The problem is in the old (totally different) S/W we had a looser syntax check and some errors creeped in before the new S/W. * > > (2) What happens as a result of these checks? * > > For instance, if a problem is found with some "as-in" field, is e * mail * > > sent automically to someone? And if so, to whom? * * Not at this point. * Nope - awaits the integration of prcheck type routines into DB update S/W. * > > (3) What happens if I register a net twice? * * The the present entry gets overwritten. * Yes - providing the changed field is newer. * > > (4) Can we really send (on a short-term basis) _all_ our registration * dat * > a? * > > Will we break anything? * * Not to our knowledge. We will store the info with a separate source ID. * This will require some changes to the tools. No big deal though. * It definately shouldn't. It is just a question of indexing a new sourced database and away we go. * > > (5) How does one go about unregistering a net from the RIPE db? Just * vi * > > the file from within my guardian account? * * The network entry can be deleted by sending in an update with a pseudo * attribute "delete:". * * A net can be removed from a group (AS, community) by removing it from * the guardian file. * * > > (6) What is the process for handing out new accounts? How does a new * net * > work * > > service provider get an account on ftp.ripe.net to register his/h * er d * > ata? * * By sending a mail message to us at ncc at ripe.net. * * > > (7) Is the only RIPE db input method by logging in and vi'ing some fi * les? * > > In other words, there doesn't exist an email interface, etc. * * Updates and new entries can be sent by mail to . * They will get processed automatically. We process around 15k a month. * Guarded *objects* and requests with user questions can be sent to * and be processed manually (about 60/month). * * > > I remember hearing something about fax and phone in orders. Does * thi * > s * > > really occur and if so, how often? * * Thnakfully only for the Internet registry (address allocation) end of * the business. * * Daniel * * -Tony. -------- Logged at Wed Feb 16 00:08:36 MET 1994 --------- From dsj at merit.edu Wed Feb 16 00:07:10 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 15 Feb 1994 18:07:10 -0500 Subject: High-level thoughts (Tuesday edition) Message-ID: <199402152307.SAA00419@merit.edu> Daniel, Tony, What great response last night! Thanks! We're continuing to try to come up to speed on your system. We've got a few very general questions, some architectural thoughts, and a few specific things to ask you, too. On the general side, we've got the following objectives for this routing pilot project: - Seamless interoperation with RIPE tools across all ASs - Get the pilot up extremely quickly Then, for the longer run: - Share code, projects, etc. with RIPE as appropriate - (long term) maintain ability of RIPE and Merit to add local functionality to seve non-mutual requirements. Would you guys be interested in doing some joint development down the road, assuming coding needs worked out? One of the obvious options for us to get RIPE-compatible functionality running quickly would be for us to take your system and run it here. At first glance, does that seem like a reasonable plan to you? Has it been done before? (e.g. has anyone else gathered all the pieces necessary to run a full local RIPE implementation yet?) Assuming you are willing, we'd like to grab a copy of your stuff and see how far we can get at bringing it up tomorrow. I know the pr*tools are available for anonymous FTP. Is the full source there as well? If not, is there a way we could get at the code? (A guest account, or some such?) Also, to get some feeling and operational practice in this, we thought it might be useful for us to join the RIPE db as an NSP. Some day not too far away we'll want to get AS 690 represented (at least as much as possible), but for now we wondered if we could register as AS 689 (the NSFNET Test Net AS). This would let us try entering various policy descriptions, nets, etc., , but it should not interfere much with anybody's actual processing since none of your ASs will have any interactions with 689. Would that be ok? How can we set this up? Any cautions about kinds of data not to enter? (Is there any standard text you send to new ASs who would like to register with you?) We've just come across RIPE-108, which seems like a pretty crucial document for us to read to understand your system. Are there others you'd point us to? (besides RIPE-81++?) More specific thoughts follow soon... Thanks, -Dale -------- Logged at Wed Feb 16 00:40:54 MET 1994 --------- From dsj at merit.edu Wed Feb 16 00:40:50 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 15 Feb 1994 18:40:50 -0500 Subject: More questions on how to join the data Message-ID: <199402152340.SAA02448@merit.edu> Daniel, Tony, Yesterday we'd suggested a two approaches for merging the combined RIPE and Merit Registry Pilot databases: either by our FTPing files, or via putting up servers. We've done some more thinking about how this needs to work (which so far has involved a lot of guessing at how your software works). I've got a couple simple questions about that; and then there's a rather larger section below sketching out some implications and tradeoffs. In a third message, I'll pass on some questions Andy has about his project to "see how far he can get at bringing up the RIPE db on a Merit machine tomorrow". ---- The simple questions are about the "whois" approach. As I type this, the list is beginning to look longer than "simple", but I'm doing it first because we feel we have a better handle on what these options would involve, since we currently know little of RIPE's internal software architecture. 1) prtraceroute seems to get all its data via the RIPE whois server. Is this true? Is it also true of all the other pr*tools? (or do some of them go elsewhere for their information: e.g. to ftp'd versions of ripe.db, or compiled versions, etc. Do the non-user tools also work this way? (E.g. does your mail parser do verifications that require a local copy of ripe.db, or does it get all of its data through whois, too?) 2) The prtraceroute command has a "-h " flag in the manpage. Does this work? Could it be used to cause prtraceroute to look to a Merit whois server for all of its information? (Andy though he saw something in a ReadMe file that said this wouldn't work). Would it work for all other pr*tools, too? *IF* this general approach would work, it would have the great advantage of reducing the number of questions that we would have to be bothering you with; we could do our database developments more independently than if we were sharing full or nearly-full code. (On the other hand, if we both do take the approach of communicating closely and sharing a lot of code, there are definite advantages to that approach, too). Within this "separate whois" approach, there are a couple of options for "combining" our data with yours: 1) Modifying the pr*tools so that they look first at one place (e.g. RIPE), then look at the other(s) if they do not find the information they are looking for. This avoids having to change the RIPE whois server, but it probably leads to poor heuristics about where to get data and poor network usage. 2) Modifying the RIPE whois server so that it polls other whois servers when it does not have the needed data locally. This would be transparent to users: RIPE would seem to have all information. 3) Rwhois philosophy: RIPE whois server is still the "top" "root-level" server everyone uses, but RIPE whois may send redirects to modified pr*tools which would then make additional queries themselves to other rr tools. 4) Any of the above, but with RIPE, Merit, (and others?) all acting as possible "root" servers, which would refer queries they cannot answer to other servers. ---- And then there is the main opposing architecture, which Daniel said he preferred for the short run: FTPing all into to RIPE, which would continue to be the sole info server. Question 1: Do you all ready have this problem solved? (In which case we can stop thinking about it?) If there are all ready RIPE-clones gathering data anywhere, and you all ready have the solution designed to combine their data with yours, then we should probably just join in that solution. If not, here are some questions we came up with this afternoon: Which file(s) would you want to recieve? One big "ripe.db"-like file? One for ASs, one for nets, etc? What would you want to do about guarded attributes? One strawman implementation would be for us to create logins for each AS on a machine here, which would have the same semantics as the ones that you create. Each night (or whatever) we would send those to you, and you would put them into identically named accounts on your machine (if this is the way that your software expects the data to be stored). Or: there are an awaful lot of more elegant ways to achieve this result, but they might require more modifications to existing software. What levels of validation and syntax checking would you expect to be performed before you received the data? If we were running your software as a front-end, then we might have your same validation software automatically. Does that validation software require that the entire ripe.db be on a local machine? (Same question as above). (If it just does syntax checking, probably that can be done without access to other db information). -------------------- Any ideas about how to work out these kinds of issues? Again, if you all ready know how this should be done, we'll just use your solution. Perhaps we could look at a conference call early Thursday morning US time (late Thursday afternoon your time), if we manage to get much of a look at your code tomorrow. -------- Logged at Wed Feb 16 00:48:51 MET 1994 --------- From dsj at merit.edu Wed Feb 16 00:48:38 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 15 Feb 1994 18:48:38 -0500 Subject: RIH: ("Request for Hints on How to Learn Your System") Message-ID: <199402152348.SAA02601@merit.edu> Daniel, Tony, Ok, here's the last one. Sorry this takes so much information! Andy is about to try to bring up your software. It is often a bit of a task to walk into someone else's production environment and figure out what's going on, so we're trying to anticipate the kinds of things that we'll need to do to get this working. Here's a draft of what he thinks he may be doing tomorrow. If you can suggest better approaches, more documentation we haven't found, specific suggestions... PLEASE! :-) > Hi Guys. > > In thinking about how we can quickly put up a useful registry, one of the > obvious options was to simply grab all your software and try to port it > to a machine here. We would like to examine this option very closely in > say, the next 24 hours. :-) What's involved with setting up a RIPE db > "system" and where can we find the code/scripts/etc. > > Steps I can imagine.... > > (0) ftp to ftp.ripe.net and pull files A, B, C from X, Y, and Z directories > Presumably A,B,C constist of things like the email parser, the restricted > shell for guardians, scripts that move data between files and into the > "master" db file, the RIPE whois server, etc. > (1) If they do not already exist, set up similar directories on the new > machine. > If A,B,C are C programs and not scripts... > (2) Try to compile (if C, C++) A, B, C in their new directories. > (3) Sort through compiler errors due to our using a different compiler and > go back to (2). > (4) Find out the directory strucuture into which all registered data goes. > For example where is information parsed from email dumped. > (5) Create said directories and files. > (6) Find out new unix accounts need to be set up - and how they are to be > set up. (PATH variables, restricted shells, email addresses, etc). > (7) Create said accounts and set up environments. > (8) Find out what checker programs are run and if they are done by hand, > by the registering party or by cron. > (9) Learn to run said checker programs. > (10) Have some lunch. > (11) After lunch, try to send some test data to the email parser sitting on > the new machine. > (12) Try to enter some test data as a "guardian". > (13) Spend time trying to figure out why (11) and (12) are not working. > (14) Give up on (13) and set up a conference call with you guys in hopes > of sorting through things. > > What do you guys think? What would your list look like? Rumor has it that > Andrew Partan has been through this, yes? > > Thanks a lot! > > Andy > -------- Logged at Wed Feb 16 09:35:33 MET 1994 --------- From Daniel.Karrenberg at ripe.net Wed Feb 16 09:35:26 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Feb 1994 09:35:26 +0100 Subject: High-level thoughts (Tuesday edition) In-Reply-To: Your message of Tue, 15 Feb 1994 18:07:10 EST. <199402152307.SAA00419@merit.edu> Message-ID: <9402160835.AA02033@reif.ripe.net> Folks, what follows is top-of-the-head stuff to give you information because I am pressed for time. Architectural thinking may follow later. > "Dale S. Johnson" writes: > On the general side, we've got the following objectives for this > routing pilot project: > > - Seamless interoperation with RIPE tools across all ASs > - Get the pilot up extremely quickly > Then, for the longer run: > - Share code, projects, etc. with RIPE as appropriate > - (long term) maintain ability of RIPE and Merit to add local > functionality to seve non-mutual requirements. Correct. > Would you guys be interested in doing some joint development down the > road, assuming coding needs worked out? Yes, if it makes sense by all means. I thought that was clear. > One of the obvious options for us to get RIPE-compatible functionality > running quickly would be for us to take your system and run it here. > At first glance, does that seem like a reasonable plan to you? Very much so. > Has it > been done before? (e.g. has anyone else gathered all the pieces > necessary to run a full local RIPE implementation yet?) Yes and no. We have several replicated databases. Noone is using all the automatic updating components. Also the current software distribution is "beta" status because there is no documentation on installation and operation. > Assuming you > are willing, we'd like to grab a copy of your stuff and see how far we > can get at bringing it up tomorrow. I know the pr*tools are available > for anonymous FTP. Is the full source there as well? If not, is there > a way we could get at the code? (A guest account, or some such?) ncc.ripe.net:~ftp/dbase-beta/dbase-beta.tar.Z (directory not readable, file is retrievable) This is still lacking some of the guarded attribute stuff but should give you an idea about what effort it will take to get it up and running. > Also, to get some feeling and operational practice in this, we thought > it might be useful for us to join the RIPE db as an NSP. > Some day not > too far away we'll want to get AS 690 represented (at least as much as > possible), but for now we wondered if we could register as AS 689 (the > NSFNET Test Net AS). This would let us try entering various policy > descriptions, nets, etc., , but it should not interfere much with > anybody's actual processing since none of your ASs will have any > interactions with 689. Would that be ok? Very much so. > How can we set this up? Send the as-object to . It will show up with source: RIPE for the time. > Any cautions about kinds of data not to enter? (Is there any > standard text you send to new ASs who would like to register with you?) There is an AS numebr application form in the doc store with some boiler plate info. ripe-81++ holds. > We've just come across RIPE-108, which seems like a pretty crucial > document for us to read to understand your system. Are there others > you'd point us to? (besides RIPE-81++?) We would like to be able to point you to a recent one about the database per se. But that is in the works and there is no draft worth speaking of yet. Get the old ones. See ftp.ripe.net:ripe/docs/ripe-docs/ripe-index.txt Daniel -------- Logged at Wed Feb 16 09:47:17 MET 1994 --------- From Daniel.Karrenberg at ripe.net Wed Feb 16 09:47:11 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Feb 1994 09:47:11 +0100 Subject: More questions on how to join the data In-Reply-To: Your message of Tue, 15 Feb 1994 18:40:50 EST. <199402152340.SAA02448@merit.edu> Message-ID: <9402160847.AA02061@reif.ripe.net> > "Dale S. Johnson" writes: > ---- > 1) prtraceroute seems to get all its data via the RIPE whois > server. Is this true? Yes. > Is it also true of all the other > pr*tools? (or do some of them go elsewhere for their information: > e.g. to ftp'd versions of ripe.db, or compiled versions, etc. Yes. We are contemplating to set up a separate server with a pre-computed topology map for some of this. So far only preliminary thoughts. > Do the non-user tools also work this way? (E.g. does your > mail parser do verifications that require a local copy of > ripe.db, or does it get all of its data through whois, too?) These need a local copy. > 2) The prtraceroute command has a "-h " flag in the manpage. > Does this work? Yes, as documented. > Could it be used to cause prtraceroute to > look to a Merit whois server for all of its information? Yes. > (Andy though he saw something in a ReadMe file that said this > wouldn't work). Would it work for all other pr*tools, too? Yes. We are planning to implement some heuristics for server selection as well. We are currently setting up more replicated RIPE databases so we will need this. > *IF* this general approach would work, it would have the great advantage > of reducing the number of questions that we would have to be bothering > you with; we could do our database developments more independently than > if we were sharing full or nearly-full code. (On the other hand, if we > both do take the approach of communicating closely and sharing a lot > of code, there are definite advantages to that approach, too). > > Within this "separate whois" approach, there are a couple of options for > "combining" our data with yours: > > 1) Modifying the pr*tools so that they look first at one place > (e.g. RIPE), then look at the other(s) if they do not find > the information they are looking for. This avoids having to > change the RIPE whois server, but it probably leads to > poor heuristics about where to get data and poor network > usage. > > 2) Modifying the RIPE whois server so that it polls other > whois servers when it does not have the needed data locally. > This would be transparent to users: RIPE would seem to have > all information. > > 3) Rwhois philosophy: RIPE whois server is still the "top" > "root-level" server everyone uses, but RIPE whois may send > redirects to modified pr*tools which would then make additional > queries themselves to other rr tools. > > 4) Any of the above, but with RIPE, Merit, (and others?) all > acting as possible "root" servers, which would refer queries > they cannot answer to other servers. I think eventually you want 4. For the time being I would prefer simple replication of *all* data at all servers. > And then there is the main opposing architecture, which Daniel said he > preferred for the short run: FTPing all into to RIPE, which would > continue to be the sole info server. That's not what I meant. I mean replicating the info at *all* servers. > Question 1: Do you all ready have this problem solved? (In which case > we can stop thinking about it?) No. > If there are all ready RIPE-clones > gathering data anywhere, and you all ready have the solution designed > to combine their data with yours, then we should probably just join in > that solution. The database software supports multiple "sources". What this comes down to is that the whois server can respond to queries using multiple data sets. Standard is to use only the RIPE data set. You can also query specific data sets or all. Thry whois -h whois.ripe.net "-a 192.87.45" and see some out of date copies of other sources. > If not, here are some questions we came up with this afternoon: > > Which file(s) would you want to recieve? One big "ripe.db"-like file? > One for ASs, one for nets, etc? Your choice. > What would you want to do about guarded attributes? One strawman > implementation would be for us to create logins for each AS on a > machine here, which would have the same semantics as the ones that > you create. Each night (or whatever) we would send those to you, > and you would put them into identically named accounts on your machine > (if this is the way that your software expects the data to be stored). > Or: there are an awaful lot of more elegant ways to achieve this > result, but they might require more modifications to existing software. I think this is a good strawman. > What levels of validation and syntax checking would you expect to be > performed before you received the data? If we were running your software > as a front-end, then we might have your same validation software > automatically. Does that validation software require that the entire > ripe.db be on a local machine? Only the part you are updating I would think. (Same question as above). (If it just > does syntax checking, probably that can be done without access to > other db information). > > -------------------- > > Any ideas about how to work out these kinds of issues? Again, if you > all ready know how this should be done, we'll just use your solution. > Perhaps we could look at a conference call early Thursday morning > US time (late Thursday afternoon your time), if we manage to get much > of a look at your code tomorrow. OK. I will be out but Tony and Marten are here. Daniel -------- Logged at Wed Feb 16 09:51:35 MET 1994 --------- From Daniel.Karrenberg at ripe.net Wed Feb 16 09:51:29 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Feb 1994 09:51:29 +0100 Subject: RIH: ("Request for Hints on How to Learn Your System") In-Reply-To: Your message of Tue, 15 Feb 1994 18:48:38 EST. <199402152348.SAA02601@merit.edu> Message-ID: <9402160851.AA02073@reif.ripe.net> > "Dale S. Johnson" writes: > Daniel, Tony, > > Ok, here's the last one. Sorry this takes so much information! Nope. If this leads to results its time well spent. We should have more documentation anyway, our fault. > > > > (0) ftp to ftp.ripe.net and pull files A, B, C from X, Y, and Z directori > es > > Presumably A,B,C constist of things like the email parser, the restri > cted > > shell for guardians, scripts that move data between files and into th > e > > "master" db file, the RIPE whois server, etc. Already sent that one. > > (1) If they do not already exist, set up similar directories on the new > > machine. > > If A,B,C are C programs and not scripts... > > (2) Try to compile (if C, C++) A, B, C in their new directories. It is *all* in perl. So you need a reasonably stable perl interpreter and little else. > > (3) Sort through compiler errors due to our using a different compiler an > d > > go back to (2). Not a problem. > > (4) Find out the directory strucuture into which all registered data goes > > For example where is information parsed from email dumped. Directly into the database files, plus logged. > > (5) Create said directories and files. Yes. unfortunately no support for that as far as I know. Marten? We could make a guest account so you could look at our stuff here. > > (6) Find out new unix accounts need to be set up - and how they are to be > > set up. (PATH variables, restricted shells, email addresses, etc). > > (7) Create said accounts and set up environments. > > (8) Find out what checker programs are run and if they are done by hand, > > by the registering party or by cron. > > (9) Learn to run said checker programs. > (10) Have some lunch. > > (11) After lunch, try to send some test data to the email parser sitting > on > > the new machine. > > (12) Try to enter some test data as a "guardian". > > (13) Spend time trying to figure out why (11) and (12) are not working. > > (14) Give up on (13) and set up a conference call with you guys in hopes > > of sorting through things. > > > > What do you guys think? What would your list look like? Rumor has it th > at > > Andrew Partan has been through this, yes? Yes. With an older version of th software. I would suggest that you at first just set up the database stuff w/o guardian accounts and test the normal update procedure. Once that works set up the guardians. Daniel -------- Logged at Wed Feb 16 10:11:28 MET 1994 --------- From Marten.Terpstra at ripe.net Wed Feb 16 10:11:21 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 16 Feb 1994 10:11:21 +0100 Subject: RIH: ("Request for Hints on How to Learn Your System") In-Reply-To: Your message of Tue, 15 Feb 1994 18:48:38 EST. <199402152348.SAA02601@merit.edu> Message-ID: <9402160911.AA11034@ncc.ripe.net> "Dale S. Johnson" writes OK, here we go for the db implementation stuff. I might miss some history, have not been in for two days, and have not yet read all the mails on this yet. * > (0) ftp to ftp.ripe.net and pull files A, B, C from X, Y, and Z directorie * s * > Presumably A,B,C constist of things like the email parser, the restric * ted * > shell for guardians, scripts that move data between files and into the * > "master" db file, the RIPE whois server, etc. * > (1) If they do not already exist, set up similar directories on the new * > machine. * > If A,B,C are C programs and not scripts... * > (2) Try to compile (if C, C++) A, B, C in their new directories. * > (3) Sort through compiler errors due to our using a different compiler and * > go back to (2). * > (4) Find out the directory strucuture into which all registered data goes. * > For example where is information parsed from email dumped. * > (5) Create said directories and files. * > (6) Find out new unix accounts need to be set up - and how they are to be * > set up. (PATH variables, restricted shells, email addresses, etc). * > (7) Create said accounts and set up environments. * > (8) Find out what checker programs are run and if they are done by hand, * > by the registering party or by cron. * > (9) Learn to run said checker programs. > (10) Have some lunch. * > (11) After lunch, try to send some test data to the email parser sitting o * n * > the new machine. * > (12) Try to enter some test data as a "guardian". * > (13) Spend time trying to figure out why (11) and (12) are not working. * > (14) Give up on (13) and set up a conference call with you guys in hopes * > of sorting through things. My suggestion: - get the db software - check and change the config - follow the instructions to run a secondary server for the RIPE like info - follow the instructions to do some simply updating - try and do some automatic updating through the email interface - try and change some bits in the config - contact me if this all goes well, so I can explain the guardian bits some more, because that is hardly documented yet. The database software will already generate a complete directory structure for you, all that is needed to run the stuff, including logging and all other things needed. Don;t start with the fancy guardian stuff until you understand the rest of the software. -Marten PS If you already picked up the software, get the latest version, many of the guarded stuff was not yet in the ftpable version, I just put up a new version. -------- Logged at Wed Feb 16 16:02:36 MET 1994 --------- From dsj at merit.edu Wed Feb 16 16:01:17 1994 From: dsj at merit.edu (dsj at merit.edu) Date: Wed, 16 Feb 94 10:01:17 -0500 Subject: request for Merit guest account Message-ID: <9402161501.AA10742@fox.merit.edu> Hi-- A guest account might help a lot. Is anyone there now who could do this for us? > From: Daniel Karrenberg > > > (4) Find out the directory strucuture into which all registered data goes > > > For example where is information parsed from email dumped. > > Directly into the database files, plus logged. > > > > (5) Create said directories and files. > > Yes. unfortunately no support for that as far as I know. > Marten? > We could make a guest account so you could look at our stuff here. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------- Logged at Wed Feb 16 23:19:11 MET 1994 --------- From ala at merit.edu Wed Feb 16 23:17:46 1994 From: ala at merit.edu (Andrew Adams) Date: Wed, 16 Feb 1994 17:17:46 -0500 Subject: Progress Today.... Message-ID: <199402162217.RAA19462@merit.edu> Well, we made much great progress today installing RIPE db stuff on a Merit machine here. Things have gone wonderfully so far. Installation was smooth and we've been playing with adding a few nets, people, ASs, etc to a copy of the ripe.db file using the 'dbupdate' command. Congratulations to you guys for making the software so easy to install! :-) Guess this means that we probably won't need a conference call tomorrow! So having gone though all this today, do you think we're ready to play with the "guarded object" stuff? A more specific question concerns the MAILTXT lines in the conf file. It's not clear from the comments that precede those lines how exactly they should look. Where are the $ variables defined? Thanks a lot. Andy -------- Logged at Thu Feb 17 12:17:32 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Feb 17 12:17:09 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 17 Feb 1994 12:17:09 +0100 Subject: Progress Today.... In-Reply-To: Your message of Wed, 16 Feb 1994 17:17:46 EST. <199402162217.RAA19462@merit.edu> Message-ID: <9402171117.AA02564@ncc.ripe.net> Andrew Adams writes * * Well, we made much great progress today installing RIPE db stuff * on a Merit machine here. Things have gone wonderfully so far. * Installation was smooth and we've been playing with adding a few * nets, people, ASs, etc to a copy of the ripe.db file using the * 'dbupdate' command. Congratulations to you guys for making the software * so easy to install! :-) Thank you. * So having gone though all this today, do you think we're ready * to play with the "guarded object" stuff? OK, first, I have made quite some changed this morning, because most of the guarded stuff was kind of hardcoded (mail messages and the like) and the database software has a habit of mailing out loads of things, so I included a testmode, which will cause all mails that would normally be send to people updating the database, or guardians etc, to be send to one configurable address, so you can test, and not bother other people with acknowledgement and other mails. I have included the changes below. What you do is unshar the shell archive below, replace dbupdate.pl, cleandb.pl, notify.pl and rconf.pl in the src directory by the new ones supplied in the shar file, go to the top directory and say "make install". Then there is a file with the additions you should make to the config, called conf.additions. Put this somewhere in the conf file, and modify where you need. * A more specific question concerns the MAILTXT lines in the conf * file. It's not clear from the comments that precede those lines * how exactly they should look. Where are the $ variables defined? There are not defined, but determined based on whatever the program is evaluating at the time. For instance, when dbupdate is handling an email message, $FROM will be set to the From or Reply-To field from the current mail message, $SUBJECT is set to the Subject line of the current mail message etc. These are things that cannot be determined in advance, but depend on the input. I thought it would be nice to put them in like this. MAILTXT simply takes the body of the acknowledgement message that will be send back to someone who did an update using email. Some more message coming up, mainly about the things that are still hardcoded (which are attributes that affect software behaviour) and the guarded stuff. I'll split them into bits (so I can also keeep them for my own documentation ;-) -Marten #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh conf.additions <<'END_OF_conf.additions' X# Run database sw in test mode? Testmode will cause ALL mail acks and other X# mail messages to be send to DEFMAIL defined further below. X XTESTMODE 1 X X# GRDCONFLICT - Text including header to be used in case of guardian X# conflicts. To field simply defaults to "guardian". It must be a X# local account/alias to mail to. X XGRDCONFLICT From: RIPE Database Conflict Handler XGRDCONFLICT Subject: Guarded attributes conflicts found XGRDCONFLICT XGRDCONFLICT Dear Guardian, XGRDCONFLICT XGRDCONFLICT One or more conflicts have been found regarding guarded XGRDCONFLICT attributes in the RIPE database. Some of the conflicts XGRDCONFLICT concern the guarded values you are a guardian for. XGRDCONFLICT XGRDCONFLICT Please verify and correct the conflicts below. XGRDCONFLICT The guarded values for objects below have been set to XGRDCONFLICT the value they had in the database before this guarded XGRDCONFLICT attributes run. XGRDCONFLICT XGRDCONFLICT Kind Regards, XGRDCONFLICT RIPE Database Conflict Department XGRDCONFLICT ------ X X# SPLITMSG - Message (including header) to be send when a block of X# network numbers has been split due to guarded attribute addition. X# The To field is always the email address that last changed the X# network block. Some variables to be used here as well: X# $BEGINADDRESS - first address of the block that was split X# $ENDADDRESS - last address of the block that was split X XSPLITMSG From: RIPE Database Management XSPLITMSG Subject: $BEGINADDRESS - $ENDADDRESS has been split XSPLITMSG XSPLITMSG XSPLITMSG Dear last changer of the RIPE database entry XSPLITMSG $BEGINADDRESS - $ENDADDRESS, XSPLITMSG XSPLITMSG This is to notify that network block $BEGINADDRESS - $ENDADDRESS XSPLITMSG has been split due to the addition of guarded attributes. It has XSPLITMSG been split into the objects displayed below in the RIPE database. XSPLITMSG XSPLITMSG Please update your local information accordingly, XSPLITMSG XSPLITMSG RIPE Database Maintenance Department END_OF_conf.additions if test 2010 -ne `wc -c dbupdate.pl <<'END_OF_dbupdate.pl' X#!PERL X X# $RCSfile: dbupdate.pl,v $ X# $Revision: 0.26 $ X# $Author: marten $ X# $Date: 1994/02/17 09:39:43 $ X X# This is a client that will update objects read from a file directly X# in the database, without interference of updated. X# It will update the object in the database that is linked to the X# source field of the object, so better make sure you have a source field X# and that it has a database associated to it ... X X at INC = ("LIBDIR", @INC); X Xrequire "rfc822.pl"; Xrequire "enwrite.pl"; Xrequire "rconf.pl"; Xrequire "enparse.pl"; Xrequire "defines.pl"; Xrequire "dbadd.pl"; Xrequire "dbopen.pl"; Xrequire "adderror.pl"; Xrequire "getopts.pl"; Xrequire "entype.pl"; Xrequire "misc.pl"; Xrequire "syslog.pl"; Xrequire "handle.pl"; X X# Parse options: X# X# -l logfile - log output to file in stead of STDOUT X# -v - verbose output (LONGACK) X# -M - treat input file (or STDIN) as mail and compose X# and send ack mail back X# -A - assume "assign" mode, only add will be allowed X# usually set by parsing mail headers X# -H - handle assignment mode. Will only accept persons X# with nic-handle "assign" and return person entry X# with the handle assigned and filled in. X# (very RIPE database dependent) X X&Getopts('l:vMAH'); X X# Need this below for running perl in tainted mode. X X$ENV{"PATH"} = ""; X$ENV{"SHELL"} = "/bin/sh"; X$ENV{"IFS"} = ""; X X# Read config file from RIPEDBCNF, or set to default. X X$conffile=$ENV{"RIPEDBCNF"}; X$conffile= "DEFCONFIG" unless $conffile; X&rconf($conffile); X X# Save STDOUT X Xopen(SAVEOUT, ">&STDOUT"); X X# Open one ack file. Proper handling (stdout, logfile or mail) is handled X# all the way at the end .... But, we open the logfile if needed already X# because we need to exit if we cannot even create that file ... X# If -M option is specified, -l is overruled. X Xif ($opt_l) { X open(LOGFILE, ">$opt_l") || die "Cannot create $opt_l: $!"; X} X Xopen(STDOUT, ">$TMPDIR/dbupdack.$$") || X &syslog("ERRLOG", "cannot create tmp ack file: $!"); X X# Make STDOUT unbuffered X Xselect(STDOUT); $| = 1; X X# X# printstat ( arg ) X# X# int arg /* 0=failed, 1=ok, 2=noop */ X# X# prints verbose version of the update result. X# X Xsub printstat { X X local($stat) = @_; X local($type) = &entype(*entry); X X if (&hasdelete(*entry)) { X print "Delete "; X } else { X print "Update "; X } X if ($stat == 1) { print "OK: ";} X elsif ($stat == 2) { print "NOOP: ";} X else { print "FAILED: "; } X X print "[$ATTL{$type}] $entry{$type}\n\n"; X} X X X# X# doaction ( ) X# X# does all the work. X# X Xsub doaction { X X local($file) = @_; X local($donestat) = 0; X X while(1) { X X $donestat = 0; X X ($parsestat, %entry) = &enparse($file); X X # next if nothing was read X X next if $parsestat == $NOK; X X # return if only thing read was EOF X X return if $parsestat == $EOF; X X $somethingfound = 1; X X # object parsing generated an error, output object with X # errors and return. If we are deleting an object, then X # forget about it, we do not want to return with syntax X # errors X X local($type) = &entype(*entry); X X # now if we are running in -H mode, just next when we have X # not found a person. X X if ($opt_H) { X if ($type ne "pn") { X print "No person object found\n"; X next; X } else { X if ($entry{"nh"} !~ /^[aA][sS][sS][iI][gG][nN]$/) { X &adderror(*entry, "nichandle \"assign\" expected"); X print "\n" if &enwrite(*entry,1,1); X next; X } X } X } X X if (($parsestat == $O_ERROR) && (!&hasdelete(*entry))) { X if ($opt_v) { &printstat(0); } X# &adderror(*entry, "$MESSAGE[$parsestat]"); X $haserror = 1; X print "\n" if &enwrite(*entry,1,1); X next; X } X X X # If we have to delete, remove all parse errors and warnings X # and set status to OK: we do not want deletes to be checked X X if (&hasdelete(*entry)) { X &rmwarnings(*entry); X &rmerrors(*entry); X $parsestat= $O_OK; X } X X # object parsed OK or has only warnings X X if ($parsestat == $O_OK || $parsestat == $O_WARNING) { X X # open database file associated with "so" for writing X X local(*db) = 'currentdb'; X if (&dbopen(db, $DBFILE{$entry{"so"}}, 1)) { X X # do we delete or not ? X X if (&hasdelete(*entry)) { X X $dbstat = &dbdel(*db, *entry); X X # We do handle generation, so after a delete, we X # have to delete the handle from that database X # as well. X X if ($DOHANDLE && $HANDLEATTR{$type}) { X if ($dbstat == $OK) { X &DeleteHandle(*entry); X } X } X X } else { X X # We do handle generation, check whether we have X # to assign a nic handle (if nh value is "assign") X # Can be a request handle of form: assign handle X # Line has already been syntax checked, so no worries X # there. Errors are added by AssignHandle, so all we X # need is an extra check. X X if ($DOHANDLE && $HANDLEATTR{$type}) { X if ($entry{$HANDLEATTR{$type}} =~ /^[Aa][Ss][Ss][Ii][Gg][Nn]\s*(.*)$/) { X local($handle) = &AssignHandle(*entry, $1); X } else { X # new object, we may have to put the handle X # in the database. AddHandle will return if X # if the handle is already in handle database X X &AddHandle(*entry); X } X } X X if (!&haserror(*entry)) { X X # NEW assignments && !person X X if ($opt_A && ($type ne "pn")) { X $dbstat = &dbadd(*db, *entry); X } else { X $dbstat = &dbadd_or_modify(*db, *entry); X } X } else { X # Fake dbstat, has error due to handle X # generation ... X X $dbstat = $OK; X } X } X X # Totally yucky, but I do not know how to X # do this better right now. The thing is that X # every exit code but E_NOOP and OK are X # errors, so catch NOOP first, and print X # verbose warning if needed, then OK, and X # then handle all the others as errors. X X # noop, just print stat if verbose X X if ($dbstat == $E_NOOP && $opt_v) { X &printstat(2); X $donestat = 1; X } X elsif (($dbstat != $OK) && ($dbstat != $E_NOOP)){ X &adderror(*entry, "$MESSAGE[$dbstat]"); X } X X X # Object has errors, so print, and next X X if (&haserror(*entry)) { X $haserror = 1; X if ($opt_v) { &printstat(0); } X print "\n" if &enwrite(*entry,1,1); X next; X } X X # object has only warnings, so it must have X # been processed. print and next. X X elsif (&haswarning(*entry)) { X $haserror = 1; X if (!$donestat && $opt_v) { X &printstat(1); X } X print "\n" if &enwrite(*entry,1,1); X next; X } X X # all was OK, so only print stat if verbose X X if ($opt_v && !$donestat) { &printstat(1); } X X # all was OK, print object if nichandle assign mode X X if ($opt_H) { X &enwrite(*entry,1,1); X } X } X X else { X X # Not too good, probably permission problem X # if this is given as output ... X X print "Failed to open DB file: $!\n"; X } X } X } X close(TMP); X} X X# X# Main program X# X X# We want to make a local copy of the input, because we need to do mutliple X# things with it ... X Xopen(COPY, ">$TMPDIR/dbupdcopy.$$") || die "Cannot open copy file: $!"; Xselect(COPY); $| = 1; select(STDOUT); X Xwhile (<>) { X print COPY; X} X Xclose(COPY); X X# Now we open the copy to actually process X Xopen(COPY, "$TMPDIR/dbupdcopy.$$") || die "Cannot open copy: $!"; X X# We have a mail, so let's first parse the headers ... X Xif ($opt_M) { X X local($stat) = &parserfc822(COPY); X X # If we have at least a return address, compose the header of X # the ack mail X X if ($stat) { X X if ($TESTMODE) { X print "To: $DEFMAIL\n"; X } else { X print "To: $FROM\n"; X } X eval "print \"$MHEADER\";"; X eval "print \"$MAILTXT\";"; X X # If not we are in trouble once more ... X X } else { X print "Header could not be parsed ...\n"; X } X} X X# Take all the stuff from file COPY in doaction. It will process the X# whole stuff. X X&doaction(COPY); X Xif (!$somethingfound) { X print "** No objects were found in your message **\n"; X} Xelsif ($haserror) { X print "$ACKERR" unless $opt_H; X} else { X print "$ACKOK" unless $opt_H; X} X Xprint $ACKSIG unless $opt_H; X Xclose(COPY); Xclose(STDOUT); Xopen(STDOUT, ">&SAVEOUT"); X X# Output the ack, if -M specified then no logfile or stdout will be given. X Xif ($opt_M) { X system("$MAILCMD < $TMPDIR/dbupdack.$$"); X} else { X open(TMP, "$TMPDIR/dbupdack.$$"); X while () { X if ($opt_l) { X print LOGFILE; X } else { X print; X } X } X close(TMP); X} X X# We sent out the ack, now send out the notifications if needed X Xif (%notify) { X &SendNotifications(); X} X X# log all stuff to the right places X X# todays YYMMDD X Xlocal($s,$m,$h,$md,$mo,$y,$wd,$yd,$is) = localtime(time); X X$mo+=1; X X$mo = "0".$mo unless $mo > 9; X$md = "0".$md unless $md > 9; X$y = "0".$y unless $y > 9; X X$YYMMDD = "$y$mo$md"; X X# This may seem yucky, but is needed to untaint the filename ... X X$filename = $LOGFILE{"UPDLOG"}."/".$YYMMDD; X$filename =~ /(.*)/; X$realfile = $1; X X# first let's log the updates send in or via stdin X Xif (open(LOG, ">>$realfile")) { X &lock(LOG); X if ($opt_M) { X print LOG "\n>>> MAIL UPDATE <<<\n\n"; X } else { X print LOG "\n>>> STDIN UPDATE <<<\n\n"; X } X X open(TMP, "$TMPDIR/dbupdcopy.$$"); X X while () { X print LOG; X } X close(TMP); X close(LOG); X &unlock(LOG); X} else { X &syslog("ERRLOG", "dbupdate cannot open $LOGFILE{\"UPDLOG\"}/$YYMMDD"); X} X X X# then we log the acknowledgement X X$filename = $LOGFILE{"ACKLOG"}."/".$YYMMDD; X$filename =~ /(.*)/; X$realfile = $1; X Xif (open(LOG, ">>$realfile")) { X &lock(LOG); X if ($opt_M) { X print LOG "\n>>> MAIL ACK <<<\n\n"; X } else { X print LOG "\n>>> STDIN ACK <<<\n\n"; X } X open(TMP, "$TMPDIR/dbupdack.$$"); X while () { X print LOG; X } X close(TMP); X close(LOG); X &unlock(LOG); X} else { X &syslog("ERRLOG", "dbupdate cannot open $LOGFILE{\"ACKLOG\"}/$YYMMDD"); X} X X X# remove the temp stuff we made X Xunlink("$TMPDIR/dbtmp.$$"); Xunlink("$TMPDIR/dbupdcopy.$$"); Xunlink("$TMPDIR/dbupdack.$$"); X X X X X X X END_OF_dbupdate.pl if test 9951 -ne `wc -c rconf.pl <<'END_OF_rconf.pl' X# rconf - read RIPE database configuration file X# X# $RCSfile: rconf.pl,v $ X# $Revision: 0.26 $ X# $Author: marten $ X# $Date: 1994/02/17 10:58:14 $ X# X# This routine reads all parameters from the configuration file X# into scalars or associative arrays of the same name (uppercase). X# Multi line texts are stored as scalar strings with embdded "\n"s. X# Note the special variable names for the OBJ configuration. X# X# Arguments: X# X# $confname name of the configuration file X Xrequire "defaults.pl"; # file containing some default configuration X # definitions. X Xsub rconf { X X local($confname) = @_; X local ($i); X X open(CONF, $confname) || die "rconf: cannot open config \"$confname\", $!"; X X while () { X next if (/^\#/); X next if (/^\s*$/); X last if (/^ENDCONF\w*$/); X X if (/^ALIAS\s+(\S+)\s+(\S+)/) { X $ALIAS{$2} = $1; X } X if (/^ATTA\s+(..)\s+(\S*)/) { $ATTR{$2}=$1; next;} X if (/^ATTR\s+(..)\s+(\S*)/) { X $ATTR{$1}=$1; $ATTR{$2}=$1; $ATTL{$1}=$2; X next; X } X if (/^CONGRAT\s+(.*)/) { $CONGRAT=$CONGRAT.$1."\n"; next;} X if (/^CONNECT\s+(\S+)/) { $CONNECT{$1}=$1; next;} X if (/^COUNTRY\s+(..)\s+(..)/) { X $COUNTRY{$1}=$1; $COUNTRY{$2}=$1; X next; X } X if (/^DOHANDLE\s+(\d+)/) {$DOHANDLE=$1+0; next;} X if (/^HANDLEPOSTFIX\s+(\S+)/) {$HANDLEPOSTFIX=$1; next;} X if (/^MAXHANDLE\s+(\d+)/) {$MAXHANDLE=$1; next;} X if (/^HANDLEATTR\s+(\S+)\s+(\S+)\s+(\S+)/) { X $HANDLEATTR{$1} = $2; X $HANDLEDB{$1} = $3; X next; X } X if (/^TESTMODE\s+(\d+)/) {$TESTMODE=$1; next;} X if (/^DEFMAIL\s+(\S+)/) { $DEFMAIL=$1; next;} X if (/^TMPDIR\s+(\S+)/) { $TMPDIR=$1; next;} X if (/^CURDB\s+(\S+)/) { $CURDB=$1; next;} X if (/^DEFSRC\s+(\S+)/) { $DEFSRC=$1; next;} X if (/^ACKERR\s+(.*)/) { $ACKERR=$ACKERR.$1."\n"; next;} X if (/^ACKOK\s+(.*)/) { $ACKOK=$ACKOK.$1."\n"; next;} X if (/^ACKSIG\s+(.*)/) { $ACKSIG=$ACKSIG.$1."\n"; next;} X if (/^INMAILS\s+(\S+)/) { $INMAILS=$1; next;} X if (/^MAILCMD\s+(.*)/) { $MAILCMD=$1; next;} X if (/^MAILTXT\s+(.*)/) { $MAILTXT=$MAILTXT.$1."\n"; next;} X if (/^MHEADER\s+(.*)/) { $MHEADER=$MHEADER.$1."\n"; next;} X if (/^NAMNORM\s+(.)\s+(.)/) { $NAMNORM{$1}=$2; next;} X if (/^NEWDB\s+(\S+)/) { $NEWDB=$1; next;} X X if (/^NHEADER\s+(.*)/) { $NHEADER.=$1."\n";next;} X if (/^NOTITXT\s+(.*)/) { $NOTITXT.=$1."\n";next;} X if (/^GRDCONFLICT\s+(.*)/) { $GRDCONFLICT.=$1."\n";next;} X if (/^SPLITMSG\s+(.*)/) { $SPLITMSG.=$1."\n";next;} X X if (/^OBJ\s+(\S\S)\s+ATSQ\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $OBJATSQ{$i} = $OBJATSQ{$i}.$1." "; X } X next; X } X if (/^OBJ\s+(\S\S)\s+MAND\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $OBJ{$i, $1} = "M"; X $OBJMAND{$i} = $OBJMAND{$i}.$1." "; X } X next; X } X if (/^OBJ\s+(\S\S)\s+MULT\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $OBJMULT{$i} = $OBJMULT{$i}.$1." "; X } X next; X } X if (/^OBJ\s+(\S\S)\s+OPT\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $OBJ{$i, $1} = "O"; X } X next; X } X if (/^OBJ\s+(\S\S)\s+KEYS\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $KEYS{$i} .= $1." "; X } X next; X } X if (/^OBJ\s+(\S\S)\s+GRD\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $GRD{$i} .= $1." "; X } X next; X } X if (/^OBJ\s+(\S\S)\s+REC\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $RECUR{$i} .= $1." "; X } X next; X } X if (/^OBJ\s+(\S\S)\s+UNIQ\s+/) { X $i = $1; X while ($' =~ /(\S\S)\s*/) { X $UNIQ{$i} .= $1." "; X } X next; X } X X if (/^CANUPD\s+(.+)/) { X $_ = $1; X while (s/(\S+)\s*//) { X $CANUPD{$1} = 1; X } X next; X } X X if (/^DEFLOOK\s+(\S+)/) { $DEFLOOK=$1; next; } X if (/^ALLLOOK\s+(.*)/) { $ALLLOOK=$1; next; } X X if (/^DBFILE\s+(\S+)\s+(\S+)/) { $DBFILE{$1} = $2; next; } X if (/^AUTHFILE\s+(\S+)/) { $AUTHFILE = $1; next; } X if (/^PIDFILE\s+(\S+)/) { $PIDFILE = $1; next; } X if (/^GUARD\s+(\S+)\s+(\S+)\s+(\S+)/) { X $GUARD{$1} = $2; X $GUARDTYPE{$1} = $3; X next; X } X X if (/^OBJ\s+(\S\S)\s+SORT\s+(\S+)/) { $OBJSORT{$1} = $2; next;} X if (/^RIGHTS\s+(.*)/) { $RIGHTS=$RIGHTS.$1."\n"; next; } X if (/^NOMATCH\s+(.*)/) { $NOMATCH=$NOMATCH.$1."\n"; next; } X if (/^TOOMANY\s+(.*)/) { $TOOMANY=$TOOMANY.$1."\n"; next; } X if (/^SOURCE\s+(\S+)/) { $SOURCE{$1}=$1; next; } X if (/^STATS\s+(\S+)/) { $STATS=$1; next; } X if (/^HELP\s+(\S+)/) { $HELP=$1; next; } X if (/^QRYLOG\s+(\S+)/) { $LOGFILE{"QRYLOG"}=$1; next; } X if (/^ERRLOG\s+(\S+)/) { $LOGFILE{"ERRLOG"}=$1; next; } X if (/^AUTHLOG\s+(\S+)/) { $LOGFILE{"AUTHLOG"}=$1; next; } X if (/^UPDLOG\s+(\S+)/) { $LOGFILE{"UPDLOG"}=$1; next; } X if (/^ACKLOG\s+(\S+)/) { $LOGFILE{"ACKLOG"}=$1; next; } X if (/^CLEANLOCK\s+(\S+)/) {$CLEANLOCK = $1; next; } X } X foreach $i (keys %OBJATSQ) { chop($OBJATSQ{$i}); } X foreach $i (keys %OBJMAND) { chop($OBJMAND{$i}); } X foreach $i (keys %OBJMULT) { chop($OBJMULT{$i}); } X X return 1; X} X X1; # PC version of perl seems to require this for X # require () X END_OF_rconf.pl echo shar: 1 control character may be missing from \"rconf.pl\" if test 4945 -ne `wc -c cleandb.pl <<'END_OF_cleandb.pl' X#!PERL X# cleandb.pl - clean up the database, ie remove all the entries X# that have been deleted on the fly (*XX:) and X# rebuild the index. X# X# $RCSfile: cleandb.pl,v $ X# $Revision: 0.39 $ X# $Author: marten $ X# $Date: 1994/02/17 10:58:04 $ X X# $opt_v = 1; X X at INC = ("LIBDIR", @INC); X Xrequire "rconf.pl"; Xrequire "dblock.pl"; Xrequire "dbopen.pl"; Xrequire "dbclose.pl"; Xrequire "donetdbm.pl"; Xrequire "enread.pl"; Xrequire "enwrite.pl"; Xrequire "encmp.pl"; Xrequire "syslog.pl"; X X$CLASSA = &quad2int("128.0.0.0"); X$CLASSB = &quad2int("192.0.0.0"); X X# cleandbadd X# X# special version of dbadd. Basically the same, but some checks are X# taken out for the sake of speed. One can assume that there are no X# two entries with the same key, and the seek has been removed, since X# this file can only be used by one process at the same time, so it X# keep the current file position properly. X Xsub cleandbadd { X local(*db, *en) = @_; X X local($unikey) = &enukey(*en); X X select(db); X print "\n"; X local($offset) = tell(db); X &enwrite(*en); X &addkey(*db, $unikey, $offset); X X foreach $i (&enkeys(*en)) { X &addkey(*db, $i, $offset); X } X X return $OK; X} X X X# parsech X# X# Parse the changed field, and return the e-mail from associated with the X# last changed date. Used to notify the last changer of a block that his X# block has been split because of guarded field additions. X Xsub parsech { X X local($line) = @_; X local($em, $chdate) = ""; X local($rtem, $rtch) = ""; X X foreach $i (split(/\n/, $line)) { X ($em, $chdate) = split(/\s+/, $i); X if ($chdate gt $rtch) { X $rtch = $chdate; X $rtem = $em; X } X } X X $rtem = "$DEFMAIL" if $rtem eq ""; X $rtem = "$DEFMAIL" if $TESTMODE; X return $rtem; X} X X# AddConflict X# X# Builds a structure with all conflicts that can be walked and turned into X# mails later in MailConflicts. X Xsub AddConflict { X X local($attr, $key, $curvalue, $newvalue) = @_; X X if ($conflict{$key}) { X if ($curvalue ne "CONFLICT") { X if (!($conflict{$key} =~ s/(@$attr%)/$1$curvalue,/)) { X $conflict{$key} .= "@$attr%$curvalue"; X } X } X if (!($conflict{$key} =~ s/(@$attr%)/$1$newvalue,/)) { X $conflict{$key} .= "@$attr%$newvalue"; X } X } else { X $conflict{$key} = "@$attr%$curvalue,$newvalue"; X } X if ($opt_v) { X print STDERR "cleandb - \$conflict{$key} = $conflict{$key}\n"; X } X} X X# MailConflicts X# X# mail the conflicts out as built in AddConflict X# Mind you, this routine makes the assumption that the filename, which is X# the guarded value is also the e-mail address to mail the conflicts to !!! X# you'd better make sure these mailboxes exist. A nicer solution will be X# found later ... X Xsub MailConflicts { X X local($i, $j, $k, $n); X local($attr, $vals); X local(%guardianfile) = (); X local($nonexist) = 0; X X if ($opt_v) { X print STDERR "cleandb - mailing conflicts\n"; X } X X foreach $i (sort keys %conflict) { X foreach $j (split(/\@/, $conflict{$i})) { X next if $j eq ""; X ($attr, $vals) = split(/%/, $j); X foreach $k (split(/,/, $vals)) { X next if $k eq "NONEXIST"; X if (!$guardianfile{$k}) { X $guardianfile{$k} = &ConflictTmpFile($k); X &ConflictMailHeaders($guardianfile{$k}, $k); X } X local($newval) = $vals; X $nonexist = 0; X if ($newval =~ /NONEXIST/) { X $newval =~ s/^NONEXIST,|,NONEXIST$|^NONEXIST$//; X $newval =~ s/,NONEXIST,/,/; X $nonexist = 1; X } X $newval =~ s/^$k,|,$k$//; X $newval =~ s/,$k,/,/; X $newval =~ s/(.*),([^,]+)$/$1 and $2/; X $newval =~ s/,/, /g; X open(TMP, ">>$guardianfile{$k}"); X X print TMP "\"$i\" also appears in guardian files: $newval\n" if $newval && ($newval ne $k); X if ($nonexist) { X print TMP "\"$i\" not found in database !!\n"; X } X close(TMP); X } X } X } X foreach $i (keys %guardianfile) { X if ($opt_v) { X print STDERR "cleandb - send mail to $i\n"; X } X system("$MAILCMD < $guardianfile{$i}"); X# system("cat $guardianfile{$i}"); X unlink($guardianfile{$i}); X } X} X Xsub ConflictTmpFile { X X local($seed) = @_; X return "/tmp/dbconfl.$seed.$$"; X} X Xsub ConflictMailHeaders { X X local($filename, $guardedvalue) = @_; X $guardedvalue =~ tr/A-Z/a-z/; X X open(TMP, ">$filename") || X &syslog("ERRLOG", "cleandb cannot create conflict file $filename"); X select(TMP); X if ($TESTMODE) { X print TMP "To: \"$guardedvalue Guardian\" <$DEFMAIL>\n"; X } else { X print TMP "To: \"$guardedvalue Guardian\" <$guardedvalue>\n"; X } X eval "print \"$GRDCONFLICT\n\";"; X close(TMP); X select(STDOUT); X return; X} X X X# readguard X# X# read all the guarded values for a certain object type X# the values are stored in an associative array "guarded" with the X# index being the composition of "guarded attribute (short form)", "%" X# and the key mentioned in the guarded file. The value will be X# the file name, which is the guarded value. X# X# So, $guarded{"as%192.87.45.0"}="AS1104" would mean that the guarded X# attribute "as" for object with key "192.87.45.0" should be "AS1104"; X# X# There are two types of guarded attributes, SINGLE and MULTIPLE. SINGLE X# guarded attributes can only have one single value, and if a certain key X# appears in more than one guardian file, a special CONFLICT value is X# created, and the current value in the database is kept. CONFLICTS will X# then be mailed to the guardians of these values to resolve. X# MULTIPLE guarded attributes are not checked on conflicts, multiple values X# are allowed, and all these values are concatenated. X X Xsub readguard { X X local($type) = @_; X local($i); X local(%done) = (); X X foreach $i (split(/\s+/, $GRD{$type})) { X $curfield = $i; X opendir(A, "$GUARD{$i}") || X &syslog("ERRLOG", "cleandb cannot opendir $GUARD{$i}"); X local(@allfiles) = sort grep(!/^\./,readdir(A)); X closedir(A); X foreach $curfile (@allfiles) { X open (TMP2, "$GUARD{$i}/$curfile") || X &syslog("ERRLOG","cleandb cannot open $GUARD{$i}/$curfile"); X while () { X chop; X X next if /^;/; X next if /^#/; X X s/^inetnum:\s*//; X X next if /^\s*$/; X X s/\s*$//; X X # This is hardwired a bit again, ranges of IP network numbers X # in guardian files ... X local($IPNUM) = "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+"; X X if (/^($IPNUM)\s+\-\s+($IPNUM)/) { X local($bot) = &quad2int($1); X local($top) = &quad2int($2); X if ($bot > $CLASSB) { X $inc = 256; X } elsif ($bot > $CLASSA) { X $inc = 256 ** 2; X } else { X $inc = 256 ** 3; X } X local($loop); X for ($loop=$bot; $loop<=$top; $loop+=$inc) { X local($value) = &int2quad($loop); X next if $done{$value}; X if ($GUARDTYPE{$curfield} eq "MULTIPLE") { X if ($guarded{"$curfield%$value"}) { X $guarded{"$curfield%$value"} .= " ".$curfile; X } else { X $guarded{"$curfield%$value"} = $curfile; X } X } else { X if ($guarded{"$curfield%$value"}) { X &AddConflict($curfield, X $value, X $guarded{"$curfield%$value"}, X $curfile); X $guarded{"$curfield%$value"} = "CONFLICT"; X } else { X $guarded{"$curfield%$value"} = $curfile; X } X } X $done{$value} = 1; X } X X } else { X X next if $done{$_}; X X if ($GUARDTYPE{$curfield} eq "MULTIPLE") { X if ($guarded{"$curfield%$_"}) { X $guarded{"$curfield%$_"} .= " ".$curfile; X } else { X $guarded{"$curfield%$_"} = $curfile; X } X } X else { X if ($guarded{"$curfield%$_"}) { X &AddConflict($curfield, X $_, X $guarded{"$curfield%$_"}, X $curfile); X $guarded{"$curfield%$_"} = "CONFLICT"; X } else { X $guarded{"$curfield%$_"} = $curfile; X } X } X $done{$_} = 1; X } X } X %done = (); X } X } X $guarddone{$type} = 1; X} X X# dosplit X# X# Kind of yucky routine needed for block splits. This is called when X# a block split is needed. It will make a block from $from to $to, and X# will reset all guarded attributes according to the guardian files. X Xsub dosplit { X X local(*en, $from, $to) = @_; X X local($begin) = &int2quad($from); X local($end) = &int2quad($to); X X if ($from eq $to) { X $en{"in"} = "$begin"; X } X else { X $en{"in"} = "$begin - $end"; X } X X foreach $j (split(/\s+/, $GRD{$type})) { X $en{"$j"} = $guarded{"$j%$begin"}; X if ($from >= $CLASSB) {$inc = 256;} X elsif ($from >= $CLASSA) {$inc = 256**2;} X else {$inc = 256**3;} X for ($p=$from;$p<=$to;$p+=$inc) { X local($num) = &int2quad($p); X delete $guarded{"$j%$num"}; X } X } X X &cleandbadd(*newdb, *en); X X if ($domail && $firstmail) { X $firstmail = 0; X $BEGINADDRESS = $beginaddr; X $ENDADDRESS = $endaddr; X open(MAIL, ">/tmp/domail.$$"); X $to = &parsech($en{"ch"}); X print MAIL "To: $to\n"; X select(MAIL); X eval "print \"$SPLITMSG\n\";"; X select(STDOUT); X } X if ($domail) { X select(MAIL); X print "\n" if &enwrite(*en, 1); X select(STDOUT); X } X} X X X X# This is the routine where guarded fields are checked and deleted or added X# if necessary. All changes are logged. X# Now, there is a special case for IP network numbers, hardcoded I am X# afraid to deal with splitting of blocks .... X Xsub checkguardandprint { X X local(*en) = @_; X X local($type) = &entype(*en); X X if (!$type) { X return 0; X } X X &readguard($type) unless ($guarddone{$type} || !$GRD{$type}); X X X# No guarded fields, just print and leave X X if (!$GRD{$type}) { X &cleandbadd(*newdb, *en); X return 1; X } X X# this is the hardcoded part ... X X X if ($type eq "in") { X X X# We have a range, if all guarded values are NOT the same for all nets X# in this block, then do an aggresive split, ie split into ALL different X# nets ... (I don't know a better way for now). X# Implementation is kind of disgusting, but it works. The block split X# certainly makes things slower than it is supposed to be .... X X if ($en{"in"} =~ /(\S+) - (\S+)/) { X X $firstmail = 1; X $domail = 0; X local($inc) = 0; X $beginaddr = $1; X $endaddr = $2; X $lo = &quad2int($1); X $hi = &quad2int($2); X if ($lo > $CLASSB) { X $inc=256; X } X elsif ($lo > $CLASSA) { X $inc=256**2; X } X else { X $inc = 256**3; X } X X $start = $lo; X $end = $lo; X X %grd = (); X for ($i=$lo;$i<=$hi;$i+=$inc) { X foreach $j (split(/\s+/, $GRD{$type})) { X $net = &int2quad($i); X if ($guarded{"$j%$net"} eq "CONFLICT") { X $grd{"$i"} .= " $j".$en{"$j"}; X $guarded{"$j%$net"} = $en{"$j"}; X } else { X $grd{"$i"} .= " $j".$guarded{"$j%$net"}; X } X } X next if $start eq $i; X if ($grd{$i} eq $grd{$start}) { X $end = $i; X if ($end == $hi) { X $domail = 1 if $start != $lo; X &dosplit(*en, $start, $end); X $hasbeendone{$end} = 1; X } X } else { X if (($start != $lo) || ($end != $hi)) { X $domail = 1; X } X &dosplit(*en, $start, $end); X $hasbeendone{$end} = 1; X $start = $i; X $end = $i; X } X } X if (!$hasbeendone{$hi}) { X if (($start != $lo) || ($end != $hi)) { X $domail = 1; X } X &dosplit(*en, $start, $hi); X } X X if ($domail) { X close(MAIL); X system("/usr/lib/sendmail -t < /tmp/domail.$$"); X unlink("/tmp/domail.$$"); X } X return 0; X } X } X X# We have no block, just an ordinary single entry X X $key = $en{$type}; X $key =~ s/\n*$//; X foreach $j (split(/\s+/, $GRD{$type})) { X # Conflict handling, set value to guarded X # value is there is no conflict. X # conflicts are reported in readguard() X if ($guarded{"$j%$key"} ne "CONFLICT") { X $en{"$j"} = $guarded{"$j%$key"}; X } X delete $guarded{"$j%$key"}; X } X &cleandbadd(*newdb, *en); X return 1; X} X X# Main program X Xif (!$ARGV[0]) { X print STDERR "Usage: $0 database\n"; X exit; X} X X# Read config file from RIPEDBCNF, or set to default. X Xif ($opt_v) { X print STDERR "cleandb - reading config\n"; X} X$conffile=$ENV{"RIPEDBCNF"}; X$conffile= "DEFCONFIG" unless $conffile; X&rconf($conffile); X X# Now we open the database file defined in $ARGV[0] X# Maybe later it is nice to open based on the SOURCE in stead of hard X# file names X Xif ($opt_v) { X print STDERR "cleandb - opening previous database\n"; X} X Xlocal(*i) = 'curdb'; X&dbopen(i, $ARGV[0]) || die "Cannot open $ARGV[0]"; X X# We are going to output the cleaned up database to "$ARGV[0].new" for now. X Xif ($opt_v) { X print STDERR "cleandb - opening new database\n"; X} X Xopen(TMP, ">$ARGV[0].new"); Xprint TMP "\n"; Xclose(TMP); Xlocal(*newdb) = 'new'; X&dbopen(newdb, "$ARGV[0].new", 1) || die "Cannot open $ARGV[0].new"; X X# Create the lock file, so that dbupdates are put on hold X# Put the process ID in the lockfile. This lockfile is created to X# avoid "rename" and "open" race conditions between cleandb and dbupdate X# or basically anything that wishes to write to the database file. X# dbopen in write mode checks to see if this file is there, and then X# holds the open. X Xif ($opt_v) { X print STDERR "cleandb - checking for lockfile\n"; X} X X$ARGV[0] =~ /([^\/]+)$/; X$fileext = $1; X Xif (-e "$CLEANLOCK.$fileext") { X &syslog("ERRLOG", "$CLEANLOCK.$fileext already exists"); X die "lockfile $CLEANLOCK.$fileext already exists"; X} X Xif ($opt_v) { X print STDERR "- Creating lock file $CLEANLOCK.$fileext\n"; X} Xopen(LOCKFILE, ">$CLEANLOCK.$fileext") || X die "cannot create $CLEANLOCK.$fileext"; Xprint LOCKFILE "$$\n"; Xclose(LOCKFILE); X X# Print generation date to database X Xlocal($s,$m,$h,$md,$mo,$y,$wd,$yd,$is) = localtime(time); X X$mo+=1; X X$mo = "0".$mo unless $mo > 9; X$md = "0".$md unless $md > 9; X$s = "0".$s unless $s > 9; X$m = "0".$m unless $m > 9; X$h = "0".$h unless $h > 9; X Xif ($opt_v) { X print STDERR "cleandb - printing date\n"; X} X Xprint newdb "#\n# $y$mo$md $h:$m:$s\n#\n"; X X# Print the copyright notice to the new file X Xif ($opt_v) { X print STDERR "cleandb - printing rights\n"; X} X Xlocal(@rights) = split(/\n/, $RIGHTS); Xforeach $m (@rights) { X print newdb "# ".$m."\n"; X} X X# Now we can simply read the database using enread() since it will skip X# objects that are not defined (like *XX:) so that is the basic cleanup X# operation. X X# Make sure the enwrite() output goes to the new file X Xselect(newdb); X X# Now, since we are going to clean up the database, we would not want X# some daemons to alter the database when we are working on it, so X# we lock it. X Xif ($opt_v) { X print STDERR "cleandb - locking files\n"; X} X X&dblock(*i); X&dblock(*newdb); X Xif ($opt_v) { X print STDERR "cleandb - main loop\n"; X} X Xwhile (%en = &enread(i)) { X X &checkguardandprint(*en); X} X X# Then we move the newly generated database to the original X# NOTE - this is DBM implementation specific .... X X&dbunlock(*newdb); X&dbclose(*newdb); X Xrename("$ARGV[0].new", $ARGV[0]); Xrename("$ARGV[0].new.dir", "$ARGV[0].dir"); Xrename("$ARGV[0].new.pag", "$ARGV[0].pag"); X X# That's it, we can safely unlock now and close both databases X X&dbunlock(*i); X&dbclose(*i); X X# now we can remove the lock file X Xunlink("$CLEANLOCK.$fileext"); X Xforeach $i (keys %guarded) { X local($attr, $key) = split(/%/, $i); X &AddConflict($attr, $key, "NONEXIST", $guarded{$i}); X} X X&MailConflicts; END_OF_cleandb.pl if test 14983 -ne `wc -c notify.pl <<'END_OF_notify.pl' X# $RCSfile: notify.pl,v $ X# $Revision: 1.5 $ X# $Author: marten $ X# $Date: 1994/02/17 09:36:56 $ X X# notify.pl - implements the notify function. X Xrequire "encmp.pl"; Xrequire "enwrite.pl"; Xrequire "entype.pl"; X X# It consists of two parts. One is the part that writes out the objects X# to temp files, one temp file per notifier, and this is called from X# updatecheck, the second part should be called at the end of an update X# from dbupdate, and will actually mail out the notify messages. X Xsub AddNotify { X X local(*new, *old) = @_; X local($i, $j); X X local($delete) = 1 if (!&entype(*new)); X local($type) = &entype(*old); X X if ($old{"ny"} && !&encmp(*new, *old)) { X local(@notifiers) = split(/\n/, $old{"ny"}); X X # If there is a delete, add all guardians as notifiers. X X if ($delete) { X foreach $i (split(/\s+/, $GRD{$type})) { X foreach $j (split(/\s+/, $old{$i})) { X @notifiers = (@notifiers, $j); X } X } X } X X foreach $i (@notifiers) { X if (!$notify{$i}) { X $notify{$i} = &NotifyTmpFile($i); X open(NOTIFY, ">$notify{$i}") || X &syslog("ERRLOG", "Cannot create notify file $notify{$i}"); X &WriteNotifyHeader(NOTIFY, $i); X } else { X open(NOTIFY, ">>$notify{$i}") || X &syslog("ERRLOG", "Cannot open notify file $notify{$i}"); X } X select(NOTIFY); X if ($delete) { # Deletion, gets dummy *new X print "** object below DELETED **\n\n"; X print "\n" if &enwrite(*old,1); X } else { X print "\n" if &enwrite(*new,1); X } X close(NOTIFY); X } X select(STDOUT); X } X} X X Xsub NotifyTmpFile { X X local($notifier) = @_; X X return "$TMPDIR/$notifier.$$"; X} X Xsub WriteNotifyHeader { X X local($filehandle, $notifier) = @_; X X select($filehandle); X X print $NHEADER; X $notifier = $DEFMAIL if $TESTMODE; X print "To: $notifier\n"; X print "\n"; X X eval "print \"$NOTITXT\n\";"; X X select(STDOUT); X} X X Xsub SendNotifications { X X local($i); X X foreach $i (keys %notify) { X system("$MAILCMD < $notify{$i}"); X unlink($notify{$i}); X } X} END_OF_notify.pl if test 2012 -ne `wc -c Message-ID: <9402171233.AA02806@ncc.ripe.net> doc/hardcoded.doc Hardcoded attributes Although the database software has been written to be as generic as possible, there are a certain number of attributes in the database software that are treated special in some way. The database software has build in knowledge about these attributes, and performs specific actions based on the values of these attributes. These attributes should therefore not be used in a different context. The software will always use the two letter code for all hardcoded attributes. Below is a description of all attributes that the database software has built in knowledge off. A short description of what the database software does with them is added to each atribute. so (source): The source attribute in the database software is used to provide a mapping between a database source, and a UNIX file. The database software will open a database file based on the DBFILE mapping between source value and UNIX file the configuration file. modules affected: dbupdate.pl ch (changed): The changed attribute has the following build in syntax: ch: YYMMDD The date portion of this attribute is used at update time, to make sure that a to be updated object is newer than the object currently in the database. Objects will only be updated when the date portion is equal or higher than the current changed attribute in the database. The email portion of the changed field is used when due to the addition of guarded attributes, a network block has to be split to accomodate a true picture of guarded attribute to network mapping. Whenever s block is split for this reason, the software will determine the email address of the person who last changed this object, and send this person a notification of the split. modules affected: cleandb.pl updatecheck.pl in (inetnum): The inetnum attribute is handled special in many cases, and it should represent an IP network number or range. This attribute is handled special to cope with expanding ranges, and indexing. modules affected: cleandb.pl enkeys.pl ny (notify): The value of the notify attribute is always an email address. The usage of this attribute is described in ripe-96. modules affected: notify.pl ma (maintainer): not yet implemented -------- Logged at Wed Feb 23 14:57:24 MET 1994 --------- From epg at merit.edu Wed Feb 23 14:57:16 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 23 Feb 94 08:57:16 EST Subject: how to proceed Message-ID: <9402231357.AA02833@pepper.merit.edu> Hi Daniel, Marten, and Tony, In parallel with the work Dale, Andy and Rick have been doing to get the routing registry database and tools in place, we have also been following up with the extensions that we all discussed in San Diego. So, what we were considering doing is rolling out the minimum set (which is cast in concrete and assures compatibility) and introducing some of the new attributes. We thought that if we could do both things (minimum set and some extensions) in one step, we could get some valuable feedback and begin making iterations to improve the syntax based on the response of the US providers. The function of some of the extensions that we would like to rollout are: a. community syntax b. expansion of the default syntax c. introduce exclusion and transit syntax d. syntax for AS_in and AS_out with network granularity e. syntax to describe peer gateway interactions/preferences We have almost completed documenting these ideas and want to share them with you. Guess we'd really like to hear your reaction to this approach. What we are proposing will not delay our rollout of the routing registry announcement, and we are very interested in making this a joint announcment - as well as working with you to refine the extensions. Thanks. --Elise -------- Logged at Fri Feb 25 09:31:50 MET 1994 --------- From Daniel.Karrenberg at ripe.net Fri Feb 25 09:31:41 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 25 Feb 1994 09:31:41 +0100 Subject: how to proceed In-Reply-To: Your message of Wed, 23 Feb 1994 08:57:16 EST. <9402231357.AA02833@pepper.merit.edu> Message-ID: <9402250831.AA03749@reif.ripe.net> > epg at merit.edu writes: > > We thought that if we could do both things (minimum set and some > extensions) in one step, we could get some valuable feedback and > begin making iterations to improve the syntax based on the response > of the US providers. Wow! You lot are really ambitious now. Charge! :-) :-) :-) :-) > The function of some of the extensions that we would like to rollout > are: > a. community syntax > b. expansion of the default syntax > c. introduce exclusion and transit syntax > d. syntax for AS_in and AS_out with network granularity > e. syntax to describe peer gateway interactions/preferences > > We have almost completed documenting these ideas and want to share them > with you. We are eagerly awaiting the docs! > Guess we'd really like to hear your reaction to this approach. What we > are proposing will not delay our rollout of the routing registry > announcement, and we are very interested in making this a joint > announcment - as well as working with you to refine the extensions. Fine if you are chaging ahead with those. We are currently busy with the PRIDE guide and not doing much implementation work besides code cleanup here and there. We would probably leave you to work at the leading edge of these extensions in the next few weeks. One concern we will have with all extensions is how the PRIDE tools can make use of them. We will need to consider this for each extension. Before implemnting them here we will also have to run them by the RIPE routing and DB groups. Of course this will be easy if there is operational experience with them on your side of the pond. Daniel -------- Logged at Fri Feb 25 22:47:18 MET 1994 --------- From ala at merit.edu Fri Feb 25 22:47:14 1994 From: ala at merit.edu (Andrew Adams) Date: Fri, 25 Feb 1994 16:47:14 -0500 Subject: Status Update Message-ID: <199402252147.QAA23984@merit.edu> Hi all. This is just a quick note to let you all know what we've been doing the past couple of days. We've been spending quite a bit of time becoming familiar with your software - Things like trying to understand what messages get generated (and don't get generated) which operations are legal and which aren't, what the various parameters in the conf file do what file permissions work and don't, etc, etc. It's been fun :-) testing our understanding and playing with your software. We've also been drafting a "New User" document and are beginning to play with adding extensions - that is to say, new objects and attributes. All in all, things are going great. As Elise said earlier, the week of March 7 is looking good for some sort of announcement. -Andy -------- Logged at Fri Feb 25 22:53:21 MET 1994 --------- From dsj at merit.edu Fri Feb 25 22:53:11 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 25 Feb 1994 16:53:11 -0500 Subject: Status at end of Week #2 Message-ID: <199402252153.QAA24586@merit.edu> Hi! Here at the end of Week #2 of the RR Pilot project, we're trying to nail down details for going into production Marcy 7 (or so). Andy has been doing the most work with database this week; he will send a separate message about what he's been learning. One high-level issue is the Joint Announcement. Elise will work with Daniel on this when she returns from vacation on Tuesday. Andy has been working on a New Users' Guide ("How to Register Information in Merit's Routing Registry"). [You guys don't all ready have a document like this, right??] We've tried to predict the positioning we should be taking; here's an example, for your suggestions: > Our first version of the Routing Registry is a direct port of the RIPE > database software designed and implemented Tony Bates, Marten Terpstra > and Danial Karrenberg of RIPE. RIPE and Merit exchange data nightly, > so that the RIPE "PRIDE" tools work seamlessly over the combined data > in both of these Routing Registry databases. > > Merit's initial offering supports nearly all RIPE objects and syntax, > plus some new Merit extensions. Merit and RIPE anticipate that we will > do both joint development and independent development on the global > Routing Registry system. Independent development will facilitate rapid > deployment of new facilities. To the extent possible, however, Merit > and RIPE will attempt to develop tools that work with both registries, > leveraging the strengths of each, and where possible to provide the > user with a seamless, integrated view of routing information. We should have a draft for your review by Wednesday or so next week. There are similar issues about code distribution, etc. For example, to conserve trans-Atlantic bandwidth, Merit could host an ftp repositry for the PRIDE tools. We'd set up the WashingtonU FTP server (which we haven't actually done yet), and support a RIPE/PRIDE subtree. The banners on that subtree would welcome the user to the RIPE PRIDE tools. Optimally, you guys would have logins and would maintain that subtree directly, so it always had whatever you wanted to release. When we get into "branch" development, that might appear on a Merit subtree. We might want to have very minor modifications even within the PRIDE directory, though. For instance, the "TOP.config" file might have a line uncommented which pointed to the RIPE whois server for people who got their copies from RIPE, or to Merit for those who got their copies from Merit. (Or this might all be moot with more sophisticated schemes: the code might dynamically decide whether the user's host was 193* or 194* and choose a whois server dynamically or something--which leads into Daniel's list of whois server issues). Jessica and Laurent are closing in on a version of the extended syntax that we are willing to go into production with; Laurent is hoping to have a syntax parser and translator ready early next week, and the rest of us are working to support the rest of their new attributes and their new "Router" object (initially without much input validation). Again, the spec should settle down this coming week for your review. We will talk to Bill Manning and Andrew Partan this week, to see if they are willing to beta-test the pilot db. (This "testing" will be more of our installation, documentation, operation, and administration than of the db itself). Onward!! -Dale -------- Logged at Sat Feb 26 16:36:37 MET 1994 --------- From rlr at merit.edu Sat Feb 26 16:36:39 1994 From: rlr at merit.edu (rlr at merit.edu) Date: Sat, 26 Feb 94 10:36:39 EST Subject: adding new attributes (and objects) Message-ID: <9402261536.AA08643@mole.merit.edu> hi, I don't know if anyone is listening this weekend, but just in case, I'm trying to work on this so if you have a minute... I would like to add some new attributes to one of our dbs. I have added to the conf file the line: ATTR dr db-reference for the new attribute, and to the object I added dr to: OBJ in OPT as bl co ch gw ii ni no rl rm rz ny ma dr (I of course checked to be sure dr was not used already.) Then I just tried to update a net giving a value to dr. (an arbitrary string...no changes to syntax.pl yet.) It gives me the message: *ERROR*: attribute "db-reference" unknown in inetnum object So...it knows enough to expand the the abbreviation (since the line in the update file is 'dr: rlr'), but it doesn't recognize the attribute in the net object. So...what am I missing/not doing here? ---- A more general question: We are planning to add some additional attributes, some mandatory to our db file. To do that, we will of course have to change the conf file here. I am assuming that won't make a problem for us importing (by ftp of diff's or whatever) your ripe.db, since we won't be trying to update the objects in that db. That is, as I undestand things, these additions to the conf file will only effect things on input of objects, which will be into our db file. Thus, it won't affect lookups that expect to search both our and your db files here, so your db file will work just fine. Am I understanding things correctly? thanks! - r ps of course for export of our files to you, we also will have to write out objects without attributes you don't have. -------- Logged at Sat Feb 26 16:52:09 MET 1994 --------- From Tony.Bates at ripe.net Sat Feb 26 16:48:00 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Sat, 26 Feb 1994 16:48:00 +0100 Subject: adding new attributes (and objects) In-Reply-To: Your message of Sat, 26 Feb 1994 10:36:39 EST. <9402261536.AA08643@mole.merit.edu> Message-ID: <9402261548.AA02759@ncc.ripe.net> rlr at merit.edu writes: * hi, * I don't know if anyone is listening this weekend, but just in case, * I'm trying to work on this so if you have a minute... * Hi - I'm listening ;-) * I would like to add some new attributes to one of our dbs. * I have added to the conf file the line: * * ATTR dr db-reference * * for the new attribute, and to the object I added dr to: * * OBJ in OPT as bl co ch gw ii ni no rl rm rz ny ma dr * * (I of course checked to be sure dr was not used already.) * * Then I just tried to update a net giving a value to dr. * (an arbitrary string...no changes to syntax.pl yet.) * It gives me the message: * * *ERROR*: attribute "db-reference" unknown in inetnum object * * So...it knows enough to expand the the abbreviation * (since the line in the update file is 'dr: rlr'), * but it doesn't recognize the attribute in the net object. * * So...what am I missing/not doing here? * I think you missed the ATSQ line. OBJ in ATSQ .. .. dr Remember that gives the ordering as well for the whois output. * ---- * A more general question: * * We are planning to add some additional attributes, some mandatory to our db * file. * To do that, we will of course have to change the conf file here. * I am assuming that won't make a problem for us importing (by ftp of diff's * or whatever) * your ripe.db, since we won't be trying to update the objects in that db. Right. * That is, as I undestand things, these additions to the conf file * will only effect things on input of objects, which will be into our db file * . * Thus, it won't affect lookups that expect to search * both our and your db files here, so your db file will work just fine. Right. * * Am I understanding things correctly? * Yep * thanks! * You're welcome. * - r * -T * ps of course for export of our files to you, we also will have to * write out objects without attributes you don't have. Well - the smae principle applies so you dont have to I believe. Marten can say better on this one but I don't it is a problem. -------- Logged at Mon Feb 28 09:00:28 MET 1994 --------- From Marten.Terpstra at ripe.net Mon Feb 28 09:00:13 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 28 Feb 1994 09:00:13 +0100 Subject: adding new attributes (and objects) In-Reply-To: Your message of Sat, 26 Feb 1994 10:36:39 EST. <9402261536.AA08643@mole.merit.edu> Message-ID: <9402280800.AA04743@ncc.ripe.net> rlr at merit.edu writes * hi, * *ERROR*: attribute "db-reference" unknown in inetnum object * * So...it knows enough to expand the the abbreviation * (since the line in the update file is 'dr: rlr'), * but it doesn't recognize the attribute in the net object. * * So...what am I missing/not doing here? As Tony said, the ATSQ lines defines the object and print order. * A more general question: * * We are planning to add some additional attributes, some mandatory to our db * file. * To do that, we will of course have to change the conf file here. * I am assuming that won't make a problem for us importing (by ftp of diff's o * r whatever) * your ripe.db, since we won't be trying to update the objects in that db. * That is, as I undestand things, these additions to the conf file * will only effect things on input of objects, which will be into our db file. * * Thus, it won't affect lookups that expect to search * both our and your db files here, so your db file will work just fine. * * Am I understanding things correctly? No problem. If the ripe format is a subset of yours, everything will work. Of course the best would be to try and keep all objects aligned. * ps of course for export of our files to you, we also will have to * write out objects without attributes you don't have. Yes, if the objects have different attributes, these will have to be filtered out (not really possible, a config that does not understand some attributes will simply skip them, ie if we read your db with extra attributes with our config, the extra attributes are skipped in printing). -Marten -------- Logged at Tue Mar 1 21:18:02 MET 1994 --------- From ala at merit.edu Thu Feb 17 22:53:12 1994 From: ala at merit.edu (Andrew Adams) Date: Thu, 17 Feb 1994 16:53:12 -0500 Subject: questions Message-ID: <199402172153.QAA20501@merit.edu> Hi. We seem to be having some problems figuring out exactly how the guarded stuff works. Let me begin by asking a specific question. I want to add the following AS for the first time. aut-num: AS1126 descr: SARA Amsterdam AS guardian: ala at fox.merit.edu admin-c: Dale Johnson tech-c: Dale Johnson changed: ala at merit.edu 940217 source: RRPILOT I put this object instance definition into a file called "as_stuff" and do a "dbupdate -v as_stuff." Everything goes great and the info ends up in our rrpilot.db database file. Now, I want to change the "tech-c" attribute so I edit my "as_stuff" file so that it reads as follows. aut-num: AS1126 descr: SARA Amsterdam AS guardian: ala at fox.merit.edu admin-c: Dale Johnson tech-c: Andy Adams changed: ala at merit.edu 940217 source: RRPILOT Now, when I run "dbupdate -v as_stuff" I get the folllowing errored output. fox.merit.edu: dbupdate -v as_stuff Update FAILED: [aut-num] AS1126 aut-num: AS1126 descr: SARA Amsterdam AS guardian: ala at fox.merit.edu admin-c: Dale Johnson tech-c: Andy Adams changed: ala at merit.edu 940217 source: RRPILOT *ERROR*: guarded objects cannot be updated via automatic procedure Objects that just generated a WARNING have been updated as shown. Objects that generated an *ERROR* have NOT been updated as requested. Sincerely Yours, Merit RR-Pilot Database Maintenance Department What am I doing wrong? How are AS objects modified after they are entered the first time. Also, what is the definition of a "guarded object." Is it any object type referenced by a guarded attribute? So, my understanding of guarded attributes is as follows. Say I have the following network and AS object instances already in my database. inetnum: 35.0.0.0 netname: MERIT descr: Merit Network, Inc. country: US admin-c: Dale Johnson tech-c: Andy Adams connect: NSF changed: ala at merit.edu 940217 source: RRPILOT aut-num: AS237 descr: NSFNETTEST14-AS guardian: ala at fox.merit.edu admin-c: Dale Johnson tech-c: Andy Adams changed: ala at merit.edu 940217 source: RRPILOT As the owner of net 35 I would like to specify that my AS is 237. However, the aut-sys attribute in the Net object is guarded. My understanding is that is that there must be an account on the database machine (in this case fox.merit.edu) called "AS237". In the home directory of of AS237 there must exist a file called "AS237" which contains in it somewhere the line 35.0.0.0 About here in the process I begin to get confused. How do I, the owner of net 35, get my aut-sys attribute updated? In ripe-108 it states on page 3 "These lists (also called 'guarded files') will be maintained and be served as the 'only' source of membership information used in the database." Does this imply that a 'guarded file' contains __only__ a list of network numbers? I suspect not because of text that appears later but it's not entirely clear what these 'guarded files' are allowed to contain and what the legal syntax is. Later on ripe-108 says on page 4 "For each of the guarded files found on 'guardian.ripe.net' the database software will load any guarded attribute value(s) for the network object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected." So only the "guardian" of the AS 237 is allowed to make the aut-sys change to the net 35 object. That make sense. But the 2 questions are (1) How does the guardian of AS 237 specify that this should happen? Some lines in a files in the ~AS237/AS237 files perhaps? (2) What is the garbage collection program that must be run to effect the changes in rrpilot.db? Is it "cleandb"? Finally, ripe-108 mentions a guardian syntax checker called "checkguard." Is this available? Thanks a lot for any info! -Andy -------- Logged at Fri Feb 18 10:29:17 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Feb 18 10:29:07 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 18 Feb 1994 10:29:07 +0100 Subject: questions In-Reply-To: Your message of Thu, 17 Feb 1994 16:53:12 EST. <199402172153.QAA20501@merit.edu> Message-ID: <9402180929.AA01202@ncc.ripe.net> Andrew Adams writes * * Hi. We seem to be having some problems figuring out exactly how the * guarded stuff works. Let me begin by asking a specific question. * * I want to add the following AS for the first time. [...] * aut-num: AS1126 * descr: SARA Amsterdam AS * guardian: ala at fox.merit.edu * admin-c: Dale Johnson * tech-c: Andy Adams * changed: ala at merit.edu 940217 * source: RRPILOT * *ERROR*: guarded objects cannot be updated via automatic procedure * * * Objects that just generated a WARNING have been updated as shown. * Objects that generated an *ERROR* have NOT been updated as requested. * * Sincerely Yours, Merit RR-Pilot Database Maintenance Department * * What am I doing wrong? How are AS objects modified after they are entered * the first time. Also, what is the definition of a "guarded object." Is * it any object type referenced by a guarded attribute? Andy, there is two things that cause this. First is the notion of guarded objects, which are objects that need something special to be updated. We have this for objects that contain vital information, like AS numbers that contain routing information. It had happened to often that people mistyped their number and overwrote someone else's AS number. Therefore, we have to do something special to allow such an object in the database. The magic is an unknown attribute called "authorise". So, if you add: authorise: The object will be accepted. The fact that you can initially send in such a guarded object without authorisation could actually be considered a bug (I know why, but am not quite sure if I want to fix it ;-) As you can see, we are now getting into the more tricky (or disgusting, whatever you want to call it) of the software. Another thing with the guarded objects (as opposed to guarded attributes) is that the guarded objects are currently hardcoded (planned to take that out yesterday, but forgot). AS numbers, communities, bdry-gw and rout-pr are currently guarded in the RIPE database. This is hardcoded in updatecheck.pl. * So, my understanding of guarded attributes is as follows. Now, guarded attributes are different things, but following a similar principle, ie they can only be changed with some sort of authorisation. * Say I have the following network and AS object instances already in my datab * ase. * * inetnum: 35.0.0.0 * netname: MERIT * descr: Merit Network, Inc. * country: US * admin-c: Dale Johnson * tech-c: Andy Adams * connect: NSF * changed: ala at merit.edu 940217 * source: RRPILOT * * aut-num: AS237 * descr: NSFNETTEST14-AS * guardian: ala at fox.merit.edu * admin-c: Dale Johnson * tech-c: Andy Adams * changed: ala at merit.edu 940217 * source: RRPILOT * * As the owner of net 35 I would like to specify that my AS is 237. However, * the aut-sys attribute in the Net object is guarded. My understanding is tha * t * is that there must be an account on the database machine (in this case * fox.merit.edu) called "AS237". In the home directory of of AS237 there must * exist a file called "AS237" which contains in it somewhere the line * * 35.0.0.0 * * * About here in the process I begin to get confused. How do I, the owner * of net 35, get my aut-sys attribute updated? In ripe-108 it states on page * 3 You don't. It is the administrator (or guardian) of AS237 that determines whether you (35.0.0.0) are in AS237 or not. It is always the AS guardian that determines what nets belong to his AS, not the other way round (make sense, no ?) * "These lists (also called 'guarded files') will be maintained and be served * as * the 'only' source of membership information used in the database." * * Does this imply that a 'guarded file' contains __only__ a list of network * numbers? I suspect not because of text that appears later but it's not enti * rely * clear what these 'guarded files' are allowed to contain and what the legal * syntax is. Later on ripe-108 says on page 4 OK, for now the only useful syntax we have for the guardian files are network numbers and network blocks. I tried yesterday, and you can even add guarded attributes to persons, that all works nicely. The guardian files should contain the first line of an object (ie network number, person name, etc) for that value to be added to that object. In the case of network numbers, ranges may be given in the guardian files, and blocks in the database will be split if the guardian files require the block to split. * "For each of the guarded files found on 'guardian.ripe.net' the database * software will load any guarded attribute value(s) for the network object(s) * listed in the guarded file. This will take place at the same time as the * database is garbage collected." * * So only the "guardian" of the AS 237 is allowed to make the aut-sys change * to the net 35 object. That make sense. But the 2 questions are * * (1) How does the guardian of AS 237 specify that this should happen? * Some lines in a files in the ~AS237/AS237 files perhaps? Yep. The guardian of AS237 maintains his file, and as soon as he puts in a line with "35.0.0.0" at the next garbage collection, that object will get AS237 tagged to it. * (2) What is the garbage collection program that must be run to effect the * changes in rrpilot.db? Is it "cleandb"? Yes. Usage: "cleandb rrpilot.db" * Finally, ripe-108 mentions a guardian syntax checker called "checkguard." * Is this available? Yes, this is a simple perl script to check the guardian files, but only for network numbers and blocks (since that is the only use we currently have for guardian files) I have included that below. A bit on the definition of guarded attributes in the config. There is two types, SINGLE and MULTIPLE value guarded attributes. The difference between the two is that SINGLE value guarded attributes can only contain a SINGLE value, in cases where a certain object is mentioned in more that one guardian file, a conflict mail for all involved guardians is generated, and the value remains unchanged. In case of MULTIPLE guarded attributes, no conflicts are checked, simply all occurences in guardian files are appended to the value of this guarded attribute. The definition bit is as follows: # OBJ in ATSQ in na de cy ac tc co rl bl as ii ni no gw rz rm ny ma ch so OBJ in MAND ac ch cy de in na so tc OBJ in OPT as bl co ch gw ii ni no rl rm rz ny ma OBJ in MULT ac ch de ii rm rz tc ny OBJ in SORT 5 OBJ in UNIQ in OBJ in KEYS in na OBJ in REC ac tc OBJ in GRD bl rl as GUARD bl /nccfs3/dbase/guarded/bdrygw MULTIPLE GUARD rl /nccfs3/dbase/guarded/routpr MULTIPLE GUARD as /nccfs3/dbase/guarded/as SINGLE The line OBJ in GRD bl rl as says that in the "in" (inetnum) object the attributes bl, rl and as are guarded. The lines GUARD bl /nccfs3/dbase/guarded/bdrygw MULTIPLE GUARD rl /nccfs3/dbase/guarded/routpr MULTIPLE GUARD as /nccfs3/dbase/guarded/as SINGLE says that for the bl attribute, there is a directory /nccfs3/dbase/guarded/bdrygw that contains all the guardian files, filenames indicate the values, and that it is a multiple value guarded attribute, so that conflicts are not checked. The same for the others, except that "as" is a single value guarded attribute. Pfeewww ;-) -Marten -------- Logged at Fri Feb 18 10:47:05 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Feb 18 10:47:00 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 18 Feb 1994 10:47:00 +0100 Subject: questions In-Reply-To: Your message of Thu, 17 Feb 1994 16:53:12 EST. <199402172153.QAA20501@merit.edu> Message-ID: <9402180947.AA01271@ncc.ripe.net> Andrew Adams writes * Finally, ripe-108 mentions a guardian syntax checker called "checkguard." * Is this available? Of course I forgot. You might have to change the #! and @INC lines. -Marten #!/bin/perl # # This is a simple program to check the syntax of a guarded file # to make help the guardians out a little bit. # # $RCSfile: checkguard.pl,v $ # $Revision: 0.11 $ # $Author: tony $ # $Date: 1994/01/14 16:09:12 $ @INC = ("/lib", at INC); require "getopts.pl"; &Getopts('v'); if ( $opt_v ) { $verbose = 1; } if ( $#ARGV) { print STDERR "No configfile given, assuming stdin\n"; } $lineno = 0; $B = &quad2int("128.0.0.0"); $C = &quad2int("192.0.0.0"); while () { chop; $lineno++; if (/^\#/ || /^\;/) { $comment++; next; } s/^inetnum:\s*//; if (/^\s*$/) { $empty++; next; } if (/ \- /) { # Assume a range @range = split(/\s+/, $_, 3); if ($range[1] ne "-") { &ps; next; } elsif (!&isnetnum($range[0])) { &ps(" = $range[0] is not a valid IP network"); next; } elsif (!&isnetnum($range[2])) { &ps(" = $range[0] is not a valid IP network"); next; } else { $bot = &quad2int($range[0]); $top = &quad2int($range[2]); if ($top <= $bot) { &ps(" = invalid range given"); next; } # Now break out the range and add to the $seen array if($bot >= $C) { $inc = 256; $class = "c"; } elsif ($bot >= $B) { $inc = 256**2; $class = "b"; } else { $inc = 256**3; $class = "a"; } for ($i = $bot ; $i <= $top ; $i += $inc) { $val = &int2quad($i); if ($seen{"$val"}) { &pw("= $val already seen on line $seen{$val}"); } eval "\$class$class ++;"; # This is yuck !! $seen{"$val"} = $lineno; } next; } } else { if (!&isnetnum($_)) { &ps(" = $_ is not a valid IP network"); next; } } if ($seen{"$_"}) { &pw(" = $_ already seen on line $seen{$_}"); } $netval = &quad2int($_); if($netval >= $C) { $class = "c"; } elsif ($netval >= $B) { $class = "b"; } else { $class = "a"; } eval "\$class$class ++;"; # This is yuck !! $seen{"$_"} = $lineno; next; } if($opt_v) { printf "The file contains:\n%s%s%s%s%s%s", $lineno ? "\t$lineno lines\n" : "", $comment ? "\t$comment comment lines\n" : "", $empty ? "\t$empty emtpy lines\n" : "", $classa ? "\t$classa Class A networks\n" : "", $classb ? "\t$classb Class B networks\n" : "", $classc ? "\t$classc Class C networks\n" : ""; } sub pw { local($str) = @_; printf "warning at line $lineno $str\n"; } sub ps { local($str) = @_; printf "syntax error at line $lineno $str\n"; } sub isnetnum { local($str) = @_; local($ind) = 0; local(@add) = split(/\./, $str); if ($#add != 3) { return 0; } foreach $ind (0..$#add) { if (($add[$ind] !~ /^[0-9][0-9]*/) || ($add[$ind] > 255)) { return 0; } } if (($add[0] < 128) && (($add[1] != 0 ) || ($add[2] != 0 ) || ($add[3] != 0 ))) { return 0; } elsif (($add[0] < 192) && (($add[2] != 0 ) || ($add[3] != 0 ))) { return 0; } elsif (($add[0] < 224) && ($add[3] != 0 )) { return 0; } return 1; } sub quad2int { local($quad) = @_; local(@quads); local($i, $j, $result); # @quads = split(/\./, $quad); $result = 0; for ($i=0; $i<4; $i++) { $j = $quads[$i]; ($j>=0&&$j<256) || die "quad2int: illegal ip number '$quad'\n"; $result += ($j<<(8*(3-$i))); } return $result; } sub int2quad { local($int) = @_; local($i, $j, $result); $result = ""; for ($i=3; $i>=0; $i--) { $j = ($int>>($i*8))&0xff; $result = $result . "$j."; } chop($result); return $result; } -------- Logged at Fri Feb 18 10:54:59 MET 1994 --------- From Tony.Bates at ripe.net Fri Feb 18 10:54:32 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Fri, 18 Feb 1994 10:54:32 +0100 Subject: questions In-Reply-To: Your message of Fri, 18 Feb 1994 10:47:00 MET. <9402180947.AA01271@ncc.ripe.net> Message-ID: <9402180954.AA01351@ncc.ripe.net> Marten Terpstra writes: * * Andrew Adams writes * * * Finally, ripe-108 mentions a guardian syntax checker called "checkguard. * " * * Is this available? * * Of course I forgot. You might have to change the #! and @INC lines. * * * -Marten Andy, Actually - the version of checkguard Marten sent who is a little out of date. Here's a later version. Again you may have to change the #! and @INC lines but I made this a little the generic version for you. Cheers, --Tony. #!/local/bin/perl # # This is a simple program to check the syntax of a guarded file # to make help the guardians out a little bit. # # $RCSfile: checkguard.pl,v $ # $Revision: 0.14 $ # $Author: tony $ # $Date: 1994/02/18 09:51:07 $ @INC = (@INC, "/lib"); # The "/lib" is for the guarded environ require "getopts.pl"; &Getopts('v'); if ( $opt_v ) { $verbose = 1; } if ( $#ARGV) { print STDERR "No configfile given, assuming stdin\n"; } $lineno = 0; $B = &quad2int("128.0.0.0"); $C = &quad2int("192.0.0.0"); while () { chop; $lineno++; if (/^\#/ || /^\;/) { $comment++; next; } s/^inetnum:\s*//; # Allow the database formats s/^\*in:\s*//; # Both of them if (/^\s*$/) { $empty++; # Count empty lines next; } if (/ \- /) { # Assume a range @range = split(/\s+/, $_, 3); if ($range[1] ne "-") { &ps; next; } elsif (!&isnetnum($range[0])) { &ps(" = $range[0] is not a valid IP network"); next; } elsif (!&isnetnum($range[2])) { &ps(" = $range[0] is not a valid IP network"); next; } else { $bot = &quad2int($range[0]); $top = &quad2int($range[2]); if ($top <= $bot) { &ps(" = invalid range given"); next; } # Now break out the range and add to the $seen array if($bot >= $C) { $inc = 256; $class = "c"; } elsif ($bot >= $B) { $inc = 256**2; $class = "b"; } else { $inc = 256**3; $class = "a"; } for ($i = $bot ; $i <= $top ; $i += $inc) { $val = &int2quad($i); if ($seen{"$val"}) { &pw("= $val already seen on line $seen{$val}"); } else { eval "\$class$class ++;"; # This is yuck !! } $seen{"$val"} = $lineno; } next; } } else { if (!&isnetnum($_)) { &ps(" = $_ is not a valid IP network"); next; } } if ($seen{"$_"}) { &pw(" = $_ already seen on line $seen{$_}"); } $netval = &quad2int($_); if($netval >= $C) { $class = "c"; } elsif ($netval >= $B) { $class = "b"; } else { $class = "a"; } eval "\$class$class ++;"; # This is yuck !! $seen{"$_"} = $lineno; next; } # If they want verbose they get verbose ;-) if($opt_v) { printf "The file contains:\n%s%s%s%s%s%s", $lineno ? "\t$lineno lines\n" : "", $comment ? "\t$comment comment lines\n" : "", $empty ? "\t$empty emtpy lines\n" : "", $classa ? "\t$classa Class A networks\n" : "", $classb ? "\t$classb Class B networks\n" : "", $classc ? "\t$classc Class C networks\n" : ""; } sub pw { local($str) = @_; printf "warning at line $lineno $str\n"; } sub ps { local($str) = @_; printf "syntax error at line $lineno $str\n"; } sub isnetnum { local($str) = @_; local($ind) = 0; local(@add) = split(/\./, $str); if ($#add != 3) { return 0; } foreach $ind (0..$#add) { if (($add[$ind] !~ /^[0-9][0-9]*$/) || ($add[$ind] > 255)) { return 0; } } if (($add[0] < 128) && (($add[1] != 0 ) || ($add[2] != 0 ) || ($add[3] != 0 ))) { return 0; } elsif (($add[0] < 192) && (($add[2] != 0 ) || ($add[3] != 0 ))) { return 0; } elsif (($add[0] < 224) && ($add[3] != 0 )) { return 0; } return 1; } sub quad2int { local($quad) = @_; local(@quads); local($i, $j, $result); # @quads = split(/\./, $quad); $result = 0; for ($i=0; $i<4; $i++) { $j = $quads[$i]; ($j>=0&&$j<256) || die "quad2int: illegal ip number '$quad'\n"; $result += ($j<<(8*(3-$i))); } return $result; } sub int2quad { local($int) = @_; local($i, $j, $result); $result = ""; for ($i=3; $i>=0; $i--) { $j = ($int>>($i*8))&0xff; $result = $result . "$j."; } chop($result); return $result; } -------- Logged at Fri Feb 18 23:28:34 MET 1994 --------- From ala at merit.edu Fri Feb 18 23:28:24 1994 From: ala at merit.edu (Andrew Adams) Date: Fri, 18 Feb 1994 17:28:24 -0500 Subject: Friday Status Report Message-ID: <199402182228.RAA07759@merit.edu> Hi Guys. We made some more progress today but things went a little slower. We seem to have figured out/understand the guarded attribute and guarded object stuff now. We made a test AS1126 account and created an AS1126 file with the single line 35.0.0.0 After answering out some directory structure questions, we got "dbupdate" to make the change in out pilot db. (We actually pried open dbupdate and rconf.pl to figure out the directory structure for guardian files and along the way, discovered some syntax errors in our conf file! The accounts you have up on whois.ripe.net helped a lot in this effort too!) We also spent time exploring how the system reacts to various "misguided" update attempts, etc. It seems the main problem we have now is getting sendmail straightened out locally in order to enable mailing to auto-dbm. This should happen soon. (sendmail had been disabled on the machine that we're using.) After this is cleared up, I suspect that we'll spend a bit more time playing with things to gain familiarity and then we'll start registering. Thanks for the good info to help us along. -Andy -------- Logged at Fri Feb 18 23:58:09 MET 1994 --------- From dsj at merit.edu Fri Feb 18 23:58:05 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 18 Feb 1994 17:58:05 -0500 Subject: Week 1 Status Report Message-ID: <199402182258.RAA10020@merit.edu> Hi-- What a great week! Andy and Rick have got the db up and mostly running on a Sun, and partially on an RS-6000. The first round went *extremely* smoothly (as you suggested, Daniel). It got a bit rockier after we got past the pre-packaged code and into guardians, but that is progressing, too. We've got prtraceroute working off our whois, and showing the local data we've entered. The accounts you set up for us on whois.ripe.net proved useful in trying to figure the connections between the AS* accounts and the locations of the guardian files, and in letting us confirm to ourselves that the parts of the code we were looking at in our distribution weren't back-level. We are running (mostly) your ftp-able beta release, plus the individual files you've mailed us. We may be getting close to where someone needs to evaluate that: how up-to-date with your production system should we try to be. (For instance, the syntax for GUARD lines in the beta conf file is wrong though it's commented out and though you gave us the correct syntax in the message this morning (blush); it took a bit of perl diving to notice that). We're a few years behind you in PERL expertise here-- we've written some little things, but nothing in a managed environment like you're using (/bin, /lib, etc), so we could use some pointers on how you actually go about developing on this code. I found references to $opt_v, but no &Getopts. Do you edit "$opt_v=1;" into the code to debug? Or use the debugger? Do you have a separate development library directory for each developer? With what directory structure? You seem to share checked-in version with RCS. If we do get into serious joint development, you may want to let us know more about your development procedures so we can stay parallel with you. For early next week, we'll probably try to become expert users (at least) of the external interfaces: interpreting prtraceroute and prcheck, entering good and bad data, etc. I think we are very close to the time that we could ask some North American friends if they'd supply us with filled-in RIPE templates for us to test with; and possibly not very many days away from where we can just ask them to use RIPE procedures directly on our copy of RIPE. We still need to resolve the "exchanging databases" problem, though from what we've seen in the code it looks like you may have this all solved in advance all ready. (?) If we exchange ftps of the database.db files once per night and put them in the correct place, is that totally sufficient to make prtraceroute work on a combined image? Are there similar issues that you can think of that we need to resolve before announce availability of the conbined service? The help you've given us getting this up has been really wonderful. We're looking forward to working closely as things progress. Thanks enormously. --Dale -------- Logged at Mon Feb 21 09:01:32 MET 1994 --------- From Marten.Terpstra at ripe.net Mon Feb 21 09:01:20 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 21 Feb 1994 09:01:20 +0100 Subject: Week 1 Status Report In-Reply-To: Your message of Fri, 18 Feb 1994 17:58:05 EST. <199402182258.RAA10020@merit.edu> Message-ID: <9402210801.AA05915@ncc.ripe.net> Hi Dale (and others), Glad things went allright to start with. Now, I'll try and answer the many questions you asked below ... "Dale S. Johnson" writes * Hi-- * * What a great week! Andy and Rick have got the db up and mostly * running on a Sun, and partially on an RS-6000. The first round went * *extremely* smoothly (as you suggested, Daniel). It got a bit rockier * after we got past the pre-packaged code and into guardians, but that is * progressing, too. We've got prtraceroute working off our whois, and * showing the local data we've entered. Good. * We are running (mostly) your ftp-able beta release, plus the * individual files you've mailed us. We may be getting close to where * someone needs to evaluate that: how up-to-date with your production * system should we try to be. (For instance, the syntax for GUARD lines * in the beta conf file is wrong though it's commented out and though you * gave us the correct syntax in the message this morning (blush); it * took a bit of perl diving to notice that). We're a few years behind Well yes. I advice in the beta stuff to stay away from guarded attributes. It is only now that we started to use it heavily that I feel like it is properly working. I'll change the beta conf. * you in PERL expertise here-- we've written some little things, but * nothing in a managed environment like you're using (/bin, /lib, etc), * so we could use some pointers on how you actually go about developing * on this code. I found references to $opt_v, but no &Getopts. Do you * edit "$opt_v=1;" into the code to debug? Or use the debugger? Do you Well, we are supposed to have proper debugging in each runnable module, but every here and there I never put Getopts in. That is the places where you would find hardcoded $opt_v or $opt_d. All this is on the list to go. * have a separate development library directory for each developer? With * what directory structure? You seem to share checked-in version with * RCS. If we do get into serious joint development, you may want to let * us know more about your development procedures so we can stay parallel * with you. Ok, let me try and explain what we have here. We have 3 different database trees on ns.ripe.net. You can have a look if you wish. The 3 trees are: /nccfs3/dbase (production version), /nccfs3/testdb (test version) and /nccfs3/newdb (development version). The distribution is built from the development version. We all (well mostly Tony and me) work on the same sources, and use rcs for locking and version control. * For early next week, we'll probably try to become expert users (at * least) of the external interfaces: interpreting prtraceroute and * prcheck, entering good and bad data, etc. I think we are very close to * the time that we could ask some North American friends if they'd supply * us with filled-in RIPE templates for us to test with; and possibly not * very many days away from where we can just ask them to use RIPE * procedures directly on our copy of RIPE. Sounds great. * We still need to resolve the "exchanging databases" problem, though * from what we've seen in the code it looks like you may have this all * solved in advance all ready. (?) If we exchange ftps of the * database.db files once per night and put them in the correct place, is * that totally sufficient to make prtraceroute work on a combined image? prtraceroute basically works on the combined data. We provide Alternet data as a test in our server, and prtraceroute knows what to do with it. Mirroring the database is by far the easiest for now. * Are there similar issues that you can think of that we need to resolve * before announce availability of the conbined service? Not sure. Maybe Daniel knows some things. I'd make sure you test the whole stuff thoroughly before announcing anything. * The help you've given us getting this up has been really wonderful. * We're looking forward to working closely as things progress. Thanks * enormously. You are welcome. You owe us some bugs (and a beer perhaps ;-) -Marten -------- Logged at Mon Feb 21 09:58:04 MET 1994 --------- From Daniel.Karrenberg at ripe.net Mon Feb 21 09:56:53 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 21 Feb 1994 09:56:53 +0100 Subject: Week 1 Status Report In-Reply-To: Your message of Mon, 21 Feb 1994 09:01:20 MET. <9402210801.AA05915@ncc.ripe.net> Message-ID: <9402210856.AA00939@reif.ripe.net> > Marten Terpstra writes: > > ... > * For early next week, we'll probably try to become expert users (at > * least) of the external interfaces: interpreting prtraceroute and > * prcheck, entering good and bad data, etc. I think we are very close to > * the time that we could ask some North American friends if they'd supply > * us with filled-in RIPE templates for us to test with; and possibly not > * very many days away from where we can just ask them to use RIPE > * procedures directly on our copy of RIPE. > > Sounds great. Progress indeed! > * We still need to resolve the "exchanging databases" problem, though > * from what we've seen in the code it looks like you may have this all > * solved in advance all ready. (?) If we exchange ftps of the > * database.db files once per night and put them in the correct place, is > * that totally sufficient to make prtraceroute work on a combined image? > > prtraceroute basically works on the combined data. We provide Alternet > data as a test in our server, and prtraceroute knows what to do with > it. Mirroring the database is by far the easiest for now. Given the transatlantic bottlenecks these days we really should look into making context diffs, shipping these and patching them in. This has also been a long standing request from some db shadow sites here. Any showstoppers there? > * Are there similar issues that you can think of that we need to resolve > * before announce availability of the conbined service? > > Not sure. Maybe Daniel knows some things. I'd make sure you test the > whole stuff thoroughly before announcing anything. We need to establish "source:" names and exact descriptions of what they mean. I suggest something like MERIT-RR for your routing data. We need to make the tools just a little more configurable in the sense of how they use different whois servers on "source:"s. I would like to make a *joint* announcement about this if this is politically acceptable to you. > * The help you've given us getting this up has been really wonderful. > * We're looking forward to working closely as things progress. Thanks > * enormously. > > You are welcome. You owe us some bugs (and a beer perhaps ;-) Mainly some suggestions I'd say. How can we make this stuff better? You can also help us documentation wise. If you have notes about experiences when installing the stuff we would surely like to include them in some form in the distribution. We are also doing a complete re-write of the user documentation of the database. Your input on that would be highly appreaciated. Daniel -------- Logged at Mon Feb 21 23:46:53 MET 1994 --------- From dsj at merit.edu Mon Feb 21 23:46:46 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 21 Feb 1994 17:46:46 -0500 Subject: Week 1 Status Report Message-ID: <199402212246.RAA06166@merit.edu> Hi! -------- From Marten: > * We are running (mostly) your ftp-able beta release, plus the > * individual files you've mailed us. We may be getting close to where > * someone needs to evaluate that: how up-to-date with your production > * system should we try to be. (For instance, the syntax for GUARD lines > * in the beta conf file is wrong though it's commented out and though you > * gave us the correct syntax in the message this morning (blush); it > * took a bit of perl diving to notice that). We're a few years behind > > Well yes. I advice in the beta stuff to stay away from guarded > attributes. It is only now that we started to use it heavily that I > feel like it is properly working. I'll change the beta conf. Ok; but this becomes a timing issue. I'd understood Elise and Daniel wanted to have this running here very soon. What do we do to run without guarded ASs? Simply start the AS file, and use the same email security mechanism for them that's used for nets? (We've had a sendmail problem and haven't checked out the email-specific code yet...) > You are welcome. You owe us some bugs (and a beer perhaps ;-) In person, in Amsterdam? :-) -------- From Daniel: > Given the transatlantic bottlenecks these days we really should look into > making context diffs, shipping these and patching them in. This has also been > a long standing request from some db shadow sites here. Any showstoppers > there? Fine here. Any mechanism you'd like would be ok. Perhaps "patch", with full releases the last day of every month, and a patch distribution numbered the day of the month for the 1st, 2nd, ... ? Since there is nothing sensitive about this info (and since you have other sites who would like it), anonymous ftp might be fine. How about an "rsh ftp get " equivalent to cause the transfers to happen? (Or "ftp put", if you don't mind passwords coded into cron jobs, but the exec gives the power to start processing of the data as well. We've occasionally done this with a tiny special-purpose server, to avoid the rsh/rcp security problems). > > > * Are there similar issues that you can think of that we need to resolve > > * before announce availability of the conbined service? > > > > Not sure. Maybe Daniel knows some things. I'd make sure you test the > > whole stuff thoroughly before announcing anything. > > We need to establish "source:" names and exact descriptions of what they > mean. I suggest something like MERIT-RR for your routing data. Fine. > We need to make the tools just a little more configurable in the sense > of how they use different whois servers on "source:"s. Ok; should this be on your queue, or should we help? The "-h " parameter seems to work, and Andy says it is easy to modify the destination in your setup file. An environmental variable *might* be useful. (?) If these are being changed anyway, how about a "port" flag for use with debug whois servers. Other ideas? > I would like to make a *joint* announcement about this if this is politically > acceptable to you. Wonderful! Elise? --Dale -------- Logged at Tue Feb 22 04:15:29 MET 1994 --------- From ala at merit.edu Tue Feb 22 04:15:26 1994 From: ala at merit.edu (Andrew Adams) Date: Mon, 21 Feb 1994 22:15:26 -0500 Subject: prefered AS update method Message-ID: <199402220315.WAA24780@merit.edu> Hi guys. I was wondering... given that once an AS is added it can't be updated my sending mail to auto-dbm (unless you have the "authorise" attribute), what is your preferred method of having people update AS info? Do you indeed want people to use the "authoise" attribute or is there some other way - say sending mail to "ncc." Thanks! Andy -------- Logged at Tue Feb 22 09:08:54 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Feb 22 09:07:34 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 22 Feb 1994 09:07:34 +0100 Subject: prefered AS update method In-Reply-To: Your message of Mon, 21 Feb 1994 22:15:26 EST. <199402220315.WAA24780@merit.edu> Message-ID: <9402220807.AA09766@ncc.ripe.net> Andrew Adams writes * * Hi guys. I was wondering... given that once an AS is added it can't be updat * ed * my sending mail to auto-dbm (unless you have the "authorise" attribute), * what is your preferred method of having people update AS info? Do you * indeed want people to use the "authoise" attribute or is there some other * way - say sending mail to "ncc." We have them send the info to ripe-dbm at ripe.net (which must be manually handled by one of us here) and we check, authorise and forward to the automatic bits. -Marten -------- Logged at Tue Feb 22 09:14:04 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Feb 22 09:14:04 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 22 Feb 1994 09:14:04 +0100 Subject: prefered AS update method In-Reply-To: Your message of Mon, 21 Feb 1994 22:15:26 EST. <199402220315.WAA24780@merit.edu> Message-ID: <9402220814.AA01598@reif.ripe.net> We have a second mailbox called ripe-ddb at ripe.net for malual updates. This actually is the original update mailbox from the time before automatic updates. People send to there, we add the authorise attribute and "dist" the message to auto-dbm, auto-dbm acks to them. We keep the authorise: trick confidential. Please do likewise. Daniel > Andrew Adams writes: > > Hi guys. I was wondering... given that once an AS is added it can't be upda > ted > my sending mail to auto-dbm (unless you have the "authorise" attribute), > what is your preferred method of having people update AS info? Do you > indeed want people to use the "authoise" attribute or is there some other > way - say sending mail to "ncc." > > Thanks! > > Andy -------- Logged at Tue Feb 22 09:18:19 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Feb 22 09:17:34 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 22 Feb 1994 09:17:34 +0100 Subject: prefered AS update method In-Reply-To: Your message of Tue, 22 Feb 1994 09:14:04 MET. <9402220814.AA01598@reif.ripe.net> Message-ID: <9402220817.AA09819@ncc.ripe.net> I forgot, if you want to do without the autorise bit for some reason, delete the following 3 lines from updatecheck.pl: if (($new{"an"}||$new{"cm"}||$new{"bg"}||$new{"rp"}) && ! $new{"ua"}) { return $E_GUARDED; } Then, you do not need the authorisation bits. I know, I have to get this out of the code and into the config ... -Marten Daniel Karrenberg writes * * We have a second mailbox called ripe-ddb at ripe.net for malual updates. * This actually is the original update mailbox from the time before * automatic updates. * People send to there, we add the authorise attribute and "dist" the * message to auto-dbm, auto-dbm acks to them. * * We keep the authorise: trick confidential. Please do likewise. * * Daniel * * > Andrew Adams writes: * > * > Hi guys. I was wondering... given that once an AS is added it can't be u * pda * > ted * > my sending mail to auto-dbm (unless you have the "authorise" attribute), * > what is your preferred method of having people update AS info? Do you * > indeed want people to use the "authoise" attribute or is there some othe * r * > way - say sending mail to "ncc." * > * > Thanks! * > * > Andy -------- Logged at Tue Feb 22 10:01:05 MET 1994 --------- From Tony.Bates at ripe.net Tue Feb 22 10:00:33 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 22 Feb 1994 10:00:33 +0100 Subject: Week 1 Status Report In-Reply-To: Your message of Mon, 21 Feb 1994 17:46:46 EST. <199402212246.RAA06166@merit.edu> Message-ID: <9402220900.AA09880@ncc.ripe.net> Just picking up on a little in this mail. "Dale S. Johnson" writes: * * Fine here. Any mechanism you'd like would be ok. Perhaps "patch", with * full releases the last day of every month, and a patch distribution numbere * d * the day of the month for the 1st, 2nd, ... ? * This is fine for the DB. For pride tools (which I'm not sure you mean) I don't want anything too restrictive. Currently it is still quite early days for the tools so we need flexibility to release as we need rather than by date or anything else. * Since there is nothing sensitive about this info (and since you have * other sites who would like it), anonymous ftp might be fine. How about * an "rsh ftp get " equivalent to cause the transfers to * happen? (Or "ftp put", if you don't mind passwords coded into cron * jobs, but the exec gives the power to start processing of the data as * well. We've occasionally done this with a tiny special-purpose server, * to avoid the rsh/rcp security problems). * * > * > > * Are there similar issues that you can think of that we need to res * olve * > > * before announce availability of the conbined service? * > > * > > Not sure. Maybe Daniel knows some things. I'd make sure you test the * > > whole stuff thoroughly before announcing anything. * > * > We need to establish "source:" names and exact descriptions of what they * > mean. I suggest something like MERIT-RR for your routing data. * * Fine. * * > We need to make the tools just a little more configurable in the sense * > of how they use different whois servers on "source:"s. * * Ok; should this be on your queue, or should we help? * It is on our queue. The whole built-in whois side will allow more configurable options. * The "-h " parameter seems to work, and Andy says it is easy to * modify the destination in your setup file. An environmental variable *migh * t* Agreed - This will be in the next release. * be useful. (?) If these are being changed anyway, how about a "port" flag * for * use with debug whois servers. Other ideas? Yep this can also be added. * * > I would like to make a *joint* announcement about this if this is politic * ally * > acceptable to you. * * Wonderful! Elise? * * * --Dale I'd like to bring up one other thing which is important in the tools which may have been overlooked. That of nets which are DMZs. Network entries have an attribute known as ias-int. This allows the network owner to register interfaces on his net belonging to other ASes. This is a special case and away from the one net / one AS idea we have. This is not guarded but should be used wherever possible. I enclose a documnet which details this attribute. This will also be in the revised ripe-81 documnet (still in draft). --Tony. Description of Inter-AS Networks in the RIPE Routing Registry Tony Bates Daniel Karrenberg Document-ID: ripe-103 Addendum to Representation of IP Routing Policies in the RIPE Database (ripe-81) What is an Inter-AS Network ? Inter-AS IP networks are those networks which connect multiple auto- nomous systems (1). An inter-AS network exists for the purpose of passing traffic and routing information between different autonomous systems. The most simple example of an inter-AS network is a point-to-point link, connecting exactly two ASes. Each end of such a link is connected to an interface of router living in each of the autonomous systems. More complex examples are broadcast type net- works with multiple interfaces connecting multiple ASes with the possibility of more than one connection per AS. _________________________ (1) Inter-AS networks are currently called FIXes, IXFs, DMZs, NAPs, GIX and other names. ripe-103.txt December 3, 1993 - 2 - Which additional information is needed? Consider the following example of three routers 1, 2 and 3 with interfaces a through f connected by two inter-AS networks X and Y: X Y a1b --- c2d --- e3f Suppose that network X is registered in the routing registry as part of AS1 and net Y as part of AS3. If traffic passes from left to right prtraceroute will report the following sequence of interfaces and ASes: a in AS1 c in AS1 e in AS3 The traceroute algorithm enumerates only the receiving interfaces on the way to the destination. In the example this leads to the pas- sage of AS2 going unnoticed. This is confusing to the user and will also generate exceptions when the path found is checked against the routing registry. For operational monitoring tools such as prtraceroute it is neces- sary to know which interface on an inter-AS network belongs to which AS. If AS information is not known about interfaces on an inter-AS network, tools like prtraceroute cannot determine correctly which ASes are being traversed. Routing Registry Format All interfaces on inter-AS networks will be described in a new ias- int attribute of the corresponding network object in the RIPE data- base. The ias-int attribute has the following syntax: ias-int: The must be an address within the corresponding intenum and must be of the form AS referring to an aut-num object in the database. ripe-103.txt December 3, 1993 - 3 - For example: inetnum: 193.193.193.0 netname: INTER-AS-EXAMPLE descr: This is a hypothetical inter-as network. descr: It might be called a NAP, FIX, GIX, IXF, DMZ, descr: Mehrfachdienstanbieterkommunikationseinrichtung or ... country: DE admin-c: Werner Mueller tech-c: Paul Schmitz tech-c: Hans Meier changed: ripe-dbm at ripe.net 920714 aut-sys: AS4711 ias-int: 193.193.193.1 AS123 ias-int: 193.193.193.3 AS4711 ias-int: 193.193.193.9 AS789 source: RIPE Note that the interface 193.193.193.3 is described although it is in the same AS as the network. This is recommended practice. The update procedure for the ias-int attribute will be the normal update procedure for network objects. The attribute does not need to be guarded because it does not influence routing policy of opera- tional traffic. In which AS does an Inter-AS Network belong? Only one AS announces an inter-AS network externally. The other ASes connected to the inter-AS network will probably carry this net- work in their internal routing for redundancy but will not announce it to other ASes. In exceptional cases more than one AS may need to originate external routing information about the inter-AS network, This kind of routing setup cannot be described within the framework of ripe-81 and is generally discouraged. Tools using a ripe-81 type registry could take heuristic hints from the ias-int attributes when they encounter such situations. ripe-103.txt December 3, 1993 -------- Logged at Tue Feb 22 15:56:09 MET 1994 --------- From dsj at merit.edu Tue Feb 22 15:55:59 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 22 Feb 1994 09:55:59 -0500 Subject: Week 1 Status Report Message-ID: <199402221455.JAA11841@merit.edu> Tony, > * > * Fine here. Any mechanism you'd like would be ok. Perhaps "patch", with > * full releases the last day of every month, and a patch distribution numbere > * d > * the day of the month for the 1st, 2nd, ... ? > * > This is fine for the DB. For pride tools (which I'm not sure you mean) I > don't want anything too restrictive. Currently it is still quite early days > for the tools so we need flexibility to release as we need rather than > by date or anything else. Yep; this was only for nightly transfers of our respective parts of the DB each way. For tools, I presume you'd release or patch as required. ... > I'd like to bring up one other thing which is important in the tools which > may have been overlooked. That of nets which are DMZs. Network entries > have an attribute known as ias-int. This allows the network owner to register > interfaces on his net belonging to other ASes. This is a special case > and away from the one net / one AS idea we have. This is not guarded > but should be used wherever possible. Yes, we've looked at this here. Is there a particular action item for Merit, other than encouraging anyone who uses our copy of the database to fill them in? (Since we're using your software almost unmodified, we automatically get this stuff for free, right? Or do we need to add in some code not yet in the beta release that we've picked up?) Thanks for the documentation! (If you need reviewers of early drafts, we're hungry for new docs...) -Dale -------- Logged at Wed Feb 23 00:02:57 MET 1994 --------- From Tony.Bates at ripe.net Wed Feb 23 00:01:42 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 23 Feb 1994 00:01:42 +0100 Subject: Week 1 Status Report In-Reply-To: Your message of Mon, 21 Feb 1994 17:46:46 EST. <199402212246.RAA06166@merit.edu> Message-ID: <9402222301.AA12678@ncc.ripe.net> * * The "-h " parameter seems to work, and Andy says it is easy to * modify the destination in your setup file. An environmental variable *migh * t* * be useful. (?) If these are being changed anyway, how about a "port" flag * for * use with debug whois servers. Other ideas? Okay for a quick help - I made a version of prtraceroute which has a [ -p alternate-whois-port ] option and also looks for the environemt variables WHOIS-PORT and WHOIS-HOST. The command line swiches override the variables. I made a drop-in shar for you. You can get this from mature.ripe.net:tony/prtraceroute.shar You cant 'dir' in there but the file exists. I will make this more permanant and fix man pages, etc for the pride distribution when in the office ;-) Cheers, --Tony. Usage: ./prtraceroute [-v] [-l] host Other: [-d] [-m maxhops] [-q nqueries] [-w waittime] [-h whoishost] [-p alternate-whois-port] -------- Logged at Wed Feb 23 10:11:39 MET 1994 --------- From Marten.Terpstra at ripe.net Wed Feb 23 10:10:38 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 23 Feb 1994 10:10:38 +0100 Subject: Week 1 Status Report In-Reply-To: Your message of Tue, 22 Feb 1994 09:55:59 EST. <199402221455.JAA11841@merit.edu> Message-ID: <9402230910.AA00366@ncc.ripe.net> "Dale S. Johnson" writes * ter * > interfaces on his net belonging to other ASes. This is a special case * > and away from the one net / one AS idea we have. This is not guarded > but should be used wherever possible. * * Yes, we've looked at this here. Is there a particular action item for * Merit, other than encouraging anyone who uses our copy of the database to * fill them in? (Since we're using your software almost unmodified, we * automatically get this stuff for free, right? Or do we need to add in * some code not yet in the beta release that we've picked up?) No it is in the standard code for the db and the tools. Just to make sure, below is the production configuration we are using, it has community and some other things in there (clns object). -Marten ############################################################################# # # This is the RIPE database software main configuration file. # Almost all tools that manage the databases use some parts of this # config file, most of them do not use everything. # ############################################################################# # # Alter the pathnames below for your local environment # ############################################################################# # Run database sw in test mode? Testmode will cause ALL mail acks and other # mail messages to be send to DEFMAIL defined further below. TESTMODE 0 # file to keep people that can make entries using the update daemon # not in distribution yet. # AUTHFILE /nccfs3/dbase-beta/conf.auth # help file for "whois help" HELP /nccfs3/dbase/etc/db-help # default database to do lookups in DEFLOOK RIPE # if all databases are selected ALLLOOK RIPE NIC MERIT NCC-AS-LIST ALTERNET # Filenames associated with sources, more than one source can point to a file # Make sure that all the databases you define below are available ... DBFILE RIPE /nccfs3/dbase/data/ripe.db DBFILE MERIT /nccfs3/dbase/data/nsf.db DBFILE NIC /nccfs3/dbase/data/nic.db DBFILE NCC-AS-LIST /nccfs3/dbase/data/asn.db DBFILE ALTERNET /nccfs3/dbase/data/alter.db # What sources can be updated ? Others will generate an error. CANUPD RIPE # whoisd query log file QRYLOG /nccfs3/dbase/etc/qrylog/qrylog # Error log file (if something really goes wrong ...) ERRLOG /nccfs3/dbase/etc/errlog # authorization log (not yet used) # AUTHLOG /nccfs3/dbase-beta/etc/authlog # this is where all update requests will be logged, this SHOULD be a # directory, logged will be in file YYMMDD with EOF markers between # messages UPDLOG /nccfs3/dbase/etc/updlog # this is where all acknowledgements will be logged, this SHOULD be a # directory, logged will be in file YYMMDD with EOF markers between # messages ACKLOG /nccfs3/dbase/etc/acklog # This is where the whoisd pid goes once started # (default: /tmp/whoisd.pid) PIDFILE /nccfs3/dbase/etc/whoisd.pid # This is the lock file basename for cleandb, to avoid rename/open race # condition. The database name is appended to this basename, to create # sperate lock files for all databases. # (default: /tmp/CLEANDB.LOCK) CLEANLOCK /nccfs3/dbase/CLEANDB.LOCK # TMPDIR is the tmp directory where various tools keep tmp files. # (default: /tmp) TMPDIR /nccfs3/dbase/tmp # DEFMAIL is the mailbox used when no mail notifications or acknowledgements # both as to and from address in various places. DEFMAIL ripe-dbm at ripe.net # What to display if no match was found NOMATCH No entries found for the selected source(s). NOMATCH NOMATCH If you would like to search on arbitrary strings, NOMATCH please use the WAIS server on wais.ripe.net or NOMATCH telnet to info.ripe.net for a WAIS client interface. NOMATCH The WAIS database name is ripe-database. NOMATCH This will only work for RIPE data. # What to display if we got TOOMANY hits back TOOMANY The index search returned too many hits. TOOMANY Please refine your search key. # The list of valid attribute names themselves in short and long version # ATTR ac admin-c ATTR ad address ATTR ai as-in ATTR al as-list ATTR an aut-num ATTR am as-macro ATTR ao as-out ATTR as aut-sys ATTR au authority ATTR bg bdry-gw ATTR bi bis ATTR bl bdrygw-l ATTR ch changed ATTR cl comm-list ATTR cm community ATTR co connect ATTR cy country ATTR da dom-name ATTR de descr ATTR df default ATTR di dom-net ATTR dm dom-in ATTR dn domain ATTR do dom-out ATTR dp dom-prefix ATTR em e-mail ATTR fx fax-no ATTR gd guardian ATTR gw gateway ATTR ii ias-int ATTR in inetnum ATTR lo location ATTR ma maintainer ATTR na netname ATTR nh nic-hdl ATTR ni nsf-in ATTR no nsf-out ATTR ns nserver ATTR ny notify ATTR op op-phone ATTR of op-fax ATTR om op-mail ATTR ph phone ATTR pn person ATTR rl routpr-l ATTR rm remarks ATTR rp rout-pr ATTR rz rev-srv ATTR sd sub-dom ATTR so source ATTR tc tech-c # Attributes with u* short names are special! ATTR ua authorise # very special ATTR ud delete # update operation ATTR ue *ERROR* # internal to update procedures ATTR uf u-from # internal to update procedures ATTR ui u-msgid # internal to update procedures ATTR uw WARNING # internal to update procedures # ATTR zc zone-c # attribute aliases (because they appear so often!) # ATTA ch change ATTA fx fax ATTA rm remark ATTA ua authorised ATTA ud deleted # object alias for template mode # ALIAS in network ALIAS in netnum # The database objects in terms of their attributes # # ATSQ - all defined attributes in this object, also defines print order # MAND - these attributes are mandatory # OPT - these attributes are optional # MULT - these attributes can appear more than once per object # SORT - sort order, single digit, lowest sorted first # UNIQ - these attributes define the unique key # KEYS - these attributes define all possible keys # REC - these attributes must be looked up if referenced # GRD - these attributes are guarded # # autonomous systems # OBJ an ATSQ an de ai ao df gd ac tc rm ny ma ch so OBJ an MAND an de ac tc ch so OBJ an OPT ai ao df gd rm ny ma OBJ an MULT de ai ao df ac tc rm ch ny OBJ an SORT 0 OBJ an UNIQ an OBJ an KEYS an OBJ an REC ac tc # as macros # OBJ am ATSQ am de al gd tc ac rm ny ma ch so OBJ am MAND am de al gd tc ac ch so OBJ am OPT rm ny ma OBJ am MULT de al tc ac rm ch ny OBJ am SORT 8 OBJ am UNIQ am OBJ am KEYS am OBJ am REC tc ac # boundary gateways # OBJ bg ATSQ bg de lo au gd ac tc rm ny ma ch so OBJ bg MAND ac au bg ch de gd lo so tc OBJ bg OPT ny ma rm OBJ bg MULT ac de lo tc ch ny OBJ bg SORT 1 OBJ bg UNIQ bg OBJ bg KEYS bg OBJ bg REC ac tc # community # OBJ cm ATSQ cm de au gd tc ac rm ny ma ch so OBJ cm MAND cm de au gd tc ac ch so OBJ cm OPT ny ma rm OBJ cm MULT de tc ac rm ch ny OBJ cm SORT 6 OBJ cm UNIQ cm OBJ cm KEYS cm OBJ cm REC ac tc # domains # OBJ dn ATSQ dn de ac tc zc ns sd di rm ny ma ch so OBJ dn MAND ac ch de dn so tc zc OBJ dn OPT di ns rm sd ny ma OBJ dn MULT ac ch de di ns rm sd tc zc ny OBJ dn SORT 4 OBJ dn UNIQ dn OBJ dn KEYS dn OBJ dn REC ac tc zc # networks # OBJ in ATSQ in na de cy ac tc co rl bl as cl ii ni no gw rz rm ny ma ch so OBJ in MAND ac ch cy de in na so tc OBJ in OPT as bl cl co ch gw ii ni no rl rm rz ny ma OBJ in MULT ac ch de ii rm rz tc ny OBJ in SORT 5 OBJ in UNIQ in OBJ in KEYS in na OBJ in REC ac tc OBJ in GRD bl rl as cl GUARD bl /nccfs3/dbase/guarded/bdrygw MULTIPLE GUARD rl /nccfs3/dbase/guarded/routpr MULTIPLE GUARD cl /nccfs3/dbase/guarded/community MULTIPLE GUARD as /nccfs3/dbase/guarded/as SINGLE # persons # OBJ pn ATSQ pn ad ph fx em nh rm ny ma ch so OBJ pn MAND ad ch ph pn so OBJ pn OPT em fx nh rm ny ma OBJ pn MULT ad ch em fx ph rm ny OBJ pn SORT 3 OBJ pn UNIQ pn nh OBJ pn KEYS pn nh # routing privileges # OBJ rp ATSQ rp de au gd ac tc rm ny ma ch so OBJ rp MAND ac au ch de gd rp so OBJ rp OPT tc ny ma OBJ rp MULT ac de tc ch ny OBJ rp SORT 2 OBJ rp UNIQ rp OBJ rp KEYS rp OBJ rp REC ac tc # clns object # OBJ dp ATSQ dp da de bi dm do df ac tc gd ny ma ch so OBJ dp MAND dp da ac tc ch so OBJ dp OPT bi de dm do df gd ny ma OBJ dp MULT de bi dm do df ac tc ch ny OBJ dp SORT 7 OBJ dp UNIQ dp OBJ dp KEYS dp da OBJ dp REC ac tc # MAILCMD is the command into which a composed e-mail is given as standard # input, to be send as mail. The message piped into this command has ALL # the necessary mail header to process the mail: # From: # To: # Subject: # The mail command should take the recipients from the actual message. # Using sendmail it will be executed as: /usr/lib/sendmail -t < "messagefile" # (default: /usr/lib/sendmail -t) MAILCMD /usr/lib/sendmail -t # The MAILTXT is the text that comes right after the headers in an email ack # send by "dbupdate" when processing an email update (-M flag). # In this text you can use 4 variables that will be expanded to the real # values in the ack: # # $FROM = "Reply-To:" or "From:" address in mail being processed # $SUBJECT = "Subject:" field ,, ,, # $MDATE = "Date:" field ,, ,, # $MSGID = "Msg-Id:" field ,, ,, MAILTXT MAILTXT Your e-mail: MAILTXT MAILTXT > From: $FROM MAILTXT > Subject: $SUBJECT MAILTXT > Date: $MDATE MAILTXT > Msg-Id: $MSGID MAILTXT MAILTXT has been processed by the automatic update procedure at the RIPE NCC. MAILTXT Diagnostic output follows: MAILTXT MAILTXT ------------------------------------------------------------------------ # MHEADER The complete mailheader for the ack mail, you can include any # mail header field, EXCEPT for the "To:" field which is added inside the # ack sending program. Again you can use the 4 variables as specified in # MAILTXT MHEADER From: RIPE Database Management MHEADER Subject: Re: $SUBJECT MHEADER Reply-To: ripe-dbm at ripe.net # ACKERR is the message that will be displayed when errors or warnings were # found in an update. ACKERR ACKERR Objects that just generated a WARNING have been updated as shown. ACKERR ACKERR Objects that generated an *ERROR* have NOT been updated as requested. ACKERR Please re-submit corrected objects. # ACKOK is message displayed when no error/warnings were found in an update ACKOK ACKOK No error/warnings were found in your database update. Congratulations. # Signature on the acknowledgement ACKSIG ------------------------------------------------------------------------ ACKSIG ACKSIG This acknowledgement was sent to you by the new RIPE database software. ACKSIG ACKSIG Please use ACKSIG ACKSIG instead of and ACKSIG instead of ACKSIG ACKSIG for fast turnaround times on all but guarded objects. ACKSIG ACKSIG If you have any question about an error or warning message, please ACKSIG contact . ACKSIG ACKSIG Sincerely Yours, ACKSIG ACKSIG RIPE Database Maintenance Department (Automatic Section) # NOTITXT Notification text used in notification messages. # Same variables as in MAILTXT can be used here. NOTITXT Dear Colleague, NOTITXT NOTITXT This is to notify you that some objects in which you are mentioned as NOTITXT a notifier or guardian of one of the guarded attributes in this object NOTITXT have been modified. The objects below are the NEW entries for these NOTITXT objects in the database. In case of DELETIONS, the deleted object is NOTITXT displayed. NOOPs will not be reported. NOTITXT NOTITXT The update causing these changes had the following mail headers: NOTITXT NOTITXT - From: $FROM NOTITXT - Subject: $SUBJECT NOTITXT - Date: $MDATE NOTITXT - Msg-Id: $MSGID NOTITXT NOTITXT RIPE Database Notification Department # NHEADER The Header used for notification messages NHEADER From: RIPE Database Notifications NHEADER Subject: Notification of RIPE Database changes NHEADER Reply-To: ripe-dbm at ripe.net # GRDCONFLICT - Text including header to be used in case of guardian # conflicts. To field simply defaults to "guardian". It must be a # local account/alias to mail to. GRDCONFLICT From: RIPE Database Conflict Handler GRDCONFLICT Subject: Guarded attributes conflicts found GRDCONFLICT GRDCONFLICT Dear Guardian, GRDCONFLICT GRDCONFLICT One or more conflicts have been found regarding guarded GRDCONFLICT attributes in the RIPE database. Some of the conflicts GRDCONFLICT concern the guarded values you are a guardian for. GRDCONFLICT GRDCONFLICT Please verify and correct the conflicts below. GRDCONFLICT The guarded values for objects below have been set to GRDCONFLICT the value they had in the database before this guarded GRDCONFLICT attributes run. GRDCONFLICT GRDCONFLICT Kind Regards, GRDCONFLICT RIPE Database Conflict Department GRDCONFLICT ------ # SPLITMSG - Message (including header) to be send when a block of # network numbers has been split due to guarded attribute addition. # The To field is always the email address that last changed the # network block. Some variables to be used here as well: # $BEGINADDRESS - first address of the block that was split # $ENDADDRESS - last address of the block that was split SPLITMSG From: RIPE Database Management SPLITMSG Subject: $BEGINADDRESS - $ENDADDRESS has been split SPLITMSG SPLITMSG SPLITMSG Dear last changer of the RIPE database entry SPLITMSG $BEGINADDRESS - $ENDADDRESS, SPLITMSG SPLITMSG This is to notify that network block $BEGINADDRESS - $ENDADDRESS SPLITMSG has been split due to the addition of guarded attributes. It has SPLITMSG been split into the objects displayed below in the RIPE database. SPLITMSG SPLITMSG Please update your local information accordingly, SPLITMSG SPLITMSG RIPE Database Maintenance Department # COPYRIGHT message that goes on top of every newly generated, or cleaned # database, will be output with "#" before each line. RIGHTS Copyright (c)1992/1993 by Daniel Karrenberg and the RARE Association RIGHTS RIGHTS Restricted rights. RIGHTS RIGHTS Except for agreed Internet operational purposes, no part of this RIGHTS publication may be reproduced, stored in a retrieval system, or RIGHTS transmitted, in any form or by any means, electronic, mechanical, RIGHTS recording, or otherwise, without prior permission of the RIPE NCC RIGHTS on behalf of the copyright holders. Any use of this material to RIGHTS target advertising or similar activities are explicitly forbidden RIGHTS and will be prosecuted. The RIPE NCC requests to be notified of RIGHTS any such activities or suspicions thereof. # the list of valid country names RIPE database specific, used # for syntax checking. May move into different config at later stage. COUNTRY AE ae COUNTRY AL al COUNTRY AT at COUNTRY AZ az COUNTRY BE be COUNTRY BG bg COUNTRY BY by COUNTRY CH ch COUNTRY CM cm COUNTRY CS cs COUNTRY CZ cz COUNTRY CY cy COUNTRY DE de COUNTRY DK dk COUNTRY DZ dz COUNTRY EE ee COUNTRY EG eg COUNTRY ES es COUNTRY FI fi COUNTRY FR fr COUNTRY GB gb COUNTRY GR gr COUNTRY HR hr COUNTRY HU hu COUNTRY IE ie COUNTRY IL il COUNTRY IN in COUNTRY IR ir COUNTRY IS is COUNTRY IT it COUNTRY KE ke COUNTRY KW kw COUNTRY LA la COUNTRY LB lb COUNTRY LI li COUNTRY LU lu COUNTRY LV lv COUNTRY LT lt COUNTRY MA ma COUNTRY MC mc COUNTRY MT mt COUNTRY NL nl COUNTRY NO no COUNTRY OM om COUNTRY PL pl COUNTRY PT pt COUNTRY RO ro COUNTRY RU ru COUNTRY SA sa COUNTRY SE se COUNTRY SG sg COUNTRY SI si COUNTRY SK sk COUNTRY SU su COUNTRY TN tn COUNTRY TR tr COUNTRY UA ua COUNTRY YU yu COUNTRY ZA za # And some funny translations for the yobbos COUNTRY GB UK COUNTRY GB uk # legal connect attribute values in alphabetic order # also RIPE database specific used for syntax checking, may move to # different config file later .... # CONNECT ACONET CONNECT ALT CONNECT CIX CONNECT CNR CONNECT DATANET CONNECT EASI CONNECT EBONE CONNECT EMPB CONNECT EU CONNECT EU-FI CONNECT FICIX CONNECT FUNET CONNECT GARR CONNECT HEPNET CONNECT ICS CONNECT INFN CONNECT IRIS CONNECT IUNET CONNECT JANET CONNECT LANLINK CONNECT LOCAL CONNECT NIKHEF CONNECT NLNET CONNECT NORDU CONNECT NSF CONNECT PIPEX CONNECT POWERWAN CONNECT RCCN CONNECT REDIRIS CONNECT RENATER CONNECT RIPE CONNECT SARA CONNECT SURF CONNECT SWIP CONNECT SWITCH CONNECT TIP CONNECT WCW CONNECT WIN CONNECT XLINK ENDCONF # do not remove! -------- Logged at Wed Feb 23 10:20:20 MET 1994 --------- From dsj at merit.edu Wed Feb 23 10:20:09 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 23 Feb 1994 04:20:09 -0500 Subject: Tuesday's questions Message-ID: <199402230920.EAA07376@merit.edu> Hi! Some assorted questions today: Can you confirm a couple of impressions? 1) That if we are running without guarded attributes, then there is no code to prevent anyone from changing anything. However, whenever someone does change something that they probably aren't supposed to, a mail message gets sent to the people responsible for that object so the damage can probably be quickly repaired. 2) That when we run with guarded ASs, this really doesn't matter much for nets since the only information about nets that is used in routing is their ASs (and those *are* guarded). I gather Marten would like us to hold off on using the guarded attribute stuff until it is a bit more stable. This would mean that we'd put the first version into production unguarded. Do we have concensus that this is the right way to go for an initial deployment? What is the status of communities? Laurent thought that they had been announced as operational for Feb 7 (or some such). Is "rash" something you'd recommend we use? Is the code available? We'd like to look at what would be required to add new attributes for Merit purposes to our copy of the db. Presumably we'd need to strip these out of the db file that we transfer to you. (Or would your code just ignore new attributes in the .db file that it didn't know about?) Could you suggest just a few sentences of issues we're likely to encounter, code that you know offhand will require changing, things to think about, etc? And a really vague one: How much staff time do you spend "operating" this? (Or, more to the point, any estimates of what we need to budget for operations?) Even though this is a direct-user-input system, there seems to be at least a minimal ongoing load to human process "auth:" requests, set up new accounts, etc. Are there routine issues that come up with the nightly cleandb that end up requiring human involvement? When two ASs claim the same net, do they tend to work that out themselves (based on your automatic "conflict" email), or do you end up participating in the discussion? How much time does the RIPE NCC spend helping new ASs or new net administrators learn the system and get through problems? How often do you have to go in as the administrators and overwrite somebody's data? Do you recommend that Merit time be allocated for searching out incomplete or incorrect information, and contacting people to encourage them to do better at their registrations? (e.g. how much time do you spend doing that? Should that be an operational responsibility of a "remote RIPE" site?) (And all of those activities, I presume, are in addition to figuring out what next months' features ought to be, building concensus with the community, actually coding and testing, answering long-winded questions for friends across the pond, etc. :-) ) Thanks! -Dale -------- Logged at Wed Feb 23 10:20:43 MET 1994 --------- From Daniel.Karrenberg at ripe.net Wed Feb 23 10:12:58 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 23 Feb 1994 10:12:58 +0100 Subject: Week 1 Status Report In-Reply-To: Your message of Mon, 21 Feb 1994 17:46:46 EST. <199402212246.RAA06166@merit.edu> Message-ID: <9402230912.AA02131@reif.ripe.net> > "Dale S. Johnson" writes: > > We need to make the tools just a little more configurable in the sense > > of how they use different whois servers on "source:"s. Multiple design issues here: 1) Which source:s comprise the routing registry? 2) In which precedence if multiple source:s have the same info? This is really a RR consistency problem. But it exists and even if we do consistency checking will continue to exist. 2a) is it OK to combine info from different sources? 3) Which servers to use? 4) In which order? Current answers: 1) all 2) the server lookup precedence 2a) yes 3) only one selected by -h option, environment, configured 4) not applicable My future answers: 1) should be limited (preferably in server) 2) server lookup precedence seems ok, but see 4) 2a) I don't really know. Until we see it break badly we can combine. 3) Everything should allow for an ordered list of servers. If TCP connecting to the first one times out, use the next one. ... We should look at automagic heuristics to choose a good one ... later. 4) see above, but then we might have to warn the user that a secondary is being used because of possible different precedences for information. > Ok; should this be on your queue, or should we help? Think about those. Daniel -------- Logged at Wed Feb 23 12:12:40 MET 1994 --------- From Tony.Bates at ripe.net Wed Feb 23 12:12:24 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 23 Feb 1994 12:12:24 +0100 Subject: Tuesday's questions In-Reply-To: Your message of Wed, 23 Feb 1994 04:20:09 EST. <199402230920.EAA07376@merit.edu> Message-ID: <9402231112.AA00878@ncc.ripe.net> "Dale S. Johnson" writes: * Hi! * * Some assorted questions today: * * Can you confirm a couple of impressions? 1) That if we are running * without guarded attributes, then there is no code to prevent anyone * from changing anything. However, whenever someone does change * something that they probably aren't supposed to, a mail message gets * sent to the people responsible for that object so the damage can * probably be quickly repaired. 2) That when we run with guarded ASs, * this really doesn't matter much for nets since the only information * about nets that is used in routing is their ASs (and those *are* * guarded). * Both right yes. * I gather Marten would like us to hold off on using the guarded * attribute stuff until it is a bit more stable. This would mean that * we'd put the first version into production unguarded. Do we have * concensus that this is the right way to go for an initial deployment? * We talked about here and there seems no porblem so please try it. * What is the status of communities? Laurent thought that they had * been announced as operational for Feb 7 (or some such). * Communities are allowed and guarded in the same way. The only difference in the software is the link for the database software for cleandb. * Is "rash" something you'd recommend we use? Is the code available? * Well, not really sure if I'd recommend it. It is just a chrooted thing I got and changed a little. I'll enclose it but if you already have ways of doing you chrooting then no problems. Of course, it is entirely up to you if you want a secure login or not. We really need it more for the fact that we ourselves may have things we don't really want the guardians to see rather than for any malicious type worries. /* * This is the initial "shell" for external users. * Its function is to chroot to ROOT and exec SHELL. * It also sets up the environment (HOME, SHELL, PATH, * TERM and USER). * It should be suid root for chroot to work. * JA 17-Oct-86 * * * Thanks to John Andrews for this. What are freinds for ?? * * */ /* * This is now known as rash * The restricted access shell ;-) * * TB - 171193 */ #include #define ROOT "/home/guarded" #define SHELL "/bin/sh" /* relative to new root */ #define PATH ".:/bin" #define MAXENV 100 #define EOS '\0' #define NIL (char *) 0 char minus[20] = "-"; char en_shell[MAXENV] = "SHELL="; char en_home[MAXENV] = "HOME="; char en_path[MAXENV] = "PATH="; char en_user[MAXENV] = "USER="; char en_term[MAXENV] = "TERM="; char *envp[MAXENV]; main() { char *name, *rindex(); char *getenv(), *strcat(); if( chroot(ROOT) == 0 ){ setuid( getuid() ); /* become user */ (void) chdir( getenv("HOME") ); envp[0] = strcat(en_shell, SHELL); envp[1] = strcat(en_home, getenv("HOME")); envp[2] = strcat(en_path, PATH); envp[3] = strcat(en_user, getenv("USER")); envp[4] = strcat(en_term, getenv("TERM")); envp[5] = NIL; if(( name = rindex(SHELL, '/')) == NULL ) name = SHELL; else name++; execle( SHELL, strcat(minus,name), 0, envp); } printf("Cannot login - please contact ncc at ripe.net\n"); exit(0); } * We'd like to look at what would be required to add new attributes for * Merit purposes to our copy of the db. Presumably we'd need to strip * these out of the db file that we transfer to you. (Or would your code * just ignore new attributes in the .db file that it didn't know about?) * Could you suggest just a few sentences of issues we're likely to * encounter, code that you know offhand will require changing, things to * think about, etc? * Well - the db software will just ignore them so it should be okay. The interesting bit to remmeber is the extensions you need to add to syntax.pl (blame me for that awful code) (if you want to syntax check that it ?) and I would sugguest creating your own syntax module that can be looked at. It is on the agenda to make this a configurable type of syntax meta language but that wont be for a while. * And a really vague one: How much staff time do you spend "operating" * this? (Or, more to the point, any estimates of what we need to budget * for operations?) Even though this is a direct-user-input system, there * seems to be at least a minimal ongoing load to human process "auth:" * requests, set up new accounts, etc. Are there routine issues that come * up with the nightly cleandb that end up requiring human involvement? * When two ASs claim the same net, do they tend to work that out * themselves (based on your automatic "conflict" email), or do you end up * participating in the discussion? How much time does the RIPE NCC spend * helping new ASs or new net administrators learn the system and get * through problems? How often do you have to go in as the administrators * and overwrite somebody's data? This is a tricky one. Currently, we probably spend too much time on it I would say as this is all still in the learning curve. The idea behind all this is to eventually make the whole thing part of the `core' service. Also, part of PRIDE is to educate the SPs to we will always spend time with them if they need. On resolving problems - it is not too bad at the moment. The real plus will be when we get the PRIDE guide out as this should take some of the general misunderstandings off us. As to resources it is hard to say but this is certainly at least two FTE's to start with reducing to one I would say as the community settles down to RRs and all things routing policy. * * Do you recommend that Merit time be allocated for searching out * incomplete or incorrect information, and contacting people to * encourage them to do better at their registrations? (e.g. how much * time do you spend doing that? Should that be an operational responsibility * of a "remote RIPE" site?) * Well - I spend the most time on this. At RIPE meetings I put up names of who hasn't registered. I even brought one SP a bottle of wine (out of my own pcket) for his excellent additions. But seriously, it would be great for you to push in this area. It is something we need as much effort as possible. * (And all of those activities, I presume, are in addition to figuring * out what next months' features ought to be, building concensus with the * community, actually coding and testing, answering long-winded questions * for friends across the pond, etc. :-) ) * Sure. * Thanks! * * -Dale -Tony -------- Logged at Fri Mar 11 14:47:47 MET 1994 ---------