questions
Marten Terpstra
Fri Feb 18 10:29:07 CET 1994
Andrew Adams <ala at merit.edu> 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: <some text, we usually use initials> 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 ---------
[ rr-impl Archive ]