[SCOOP #DVS-863493]: SCOOP topology, in question is in-house relay

> Thanks.
> 
> On the relay server, sasquatch, when I set the request line as "request
> "^[DWS]" dc-ldm2...", and the allow line has "allow ".*" dc-ldm2..." I
> have seen some feedback
> 
> Doing this simulation (not LDM testing), requires that I turn on or off
> allowing the request of just "^WANAF...-UFL" pattern from dc-ldm2 to
> sasquatch. This is not an everyday thing, but I wondered, if there
> another way to turn on and then off, the allow for this instance for the
> duration of just this simulation.
> 
> Doing this:
> 
> request   EXP   "^W"    dc-ldm2.tamu.edu
> allow      ANY  ^dc-ldm2\.tamu\.edu        ".*"      "^W.*TAM"
> 
> would, at least, cut back on the "feedback" of regularly, locally
> generated files. Now that I think about it, that might be all we need.
> 
> Any other suggestions?


Simple is probably the best solution. The other possibility that will work with 
pqinsert 
(but not ldmsend) is to use the -p option to supply the name, if your aren't 
already,
and instead of just using a file name, add an additional string at the end such 
as
-p 'filename TEST'

Then, all your patters that root on the file file name would still work, unless 
you
are explicitly using the '$' terminator of a pattern. Then you could do the 
"not allow" of "TEST$" and not have to reconfigure your LDM when you want to
run a test, and still use the EXP feedtype and normal pattern processing.

Elsewise, you could test using SPARE as the feedtype.

Just throwing out possibilities, many solutions....

Steve Chiswell
Unidata User Support


> 
> Donna Cote
> 
> Unidata IDD SCOOP Support wrote:
> >> Dr Chiswell,
> >>
> >> You may remember that we have two (more, actually) SCOOP LDM servers.
> >> sasquatch.tamu.edu has a request line for each off-site SCOOP partner's
> >> LDM server; and it has a request line to our LDM server and file server:
> >> dc-ldm2.tamu.edu
> >>
> >> Well, I'm in the position of wanting to pqinsert data with the pattern
> >> ^WANAF on the EXP feedtype from dc-ldm2 but I don't think, with our
> >> current configuration, these files will be requested and received by
> >> sasquatch. You are welcome to call me if you have questions that I can't
> >> seem to answer by email.
> >>
> >
> >
> > Donna,
> >
> > I'm assuming that your new ^WANAF products will not matc the request line 
> > you
> > show below from sasquatch as "^W.......-FNM" .
> >
> > That is, you didn't mention what the full pattern of the new products will
> > be that or -TAM etc.
> >
> > Anyhow, you can modify the request line to be the "^[DSW]" pattern.
> >
> > You could use SPARE with ldmsend for testing as well.
> >
> > Since sasquatch allows dc-ldm2 to request ANY ".*", and
> > dc-ldm2 does request EXP ^[DSW]" from sasquatch, then you do have the 
> > pssibility
> > that they would come back to dc-ldm2, but this is not likely to be
> > a problem given that those machines are close so that you won't have long 
> > delays.
> > That is, you will get them offered back to you, but you will reject them as 
> > duplicates.
> > Over long distances however, that is what we wanted to avoid since hosts 
> > that have latency
> > and can get them offered back after they have already scoured them out of 
> > their queue.
> >
> > If you suspect that you will have a problem with getting them back to 
> > dc-ldm2 from
> > sasquatch, then I would suggest adding the "Not" pattern to sasquatch's 
> > allow line for dcldm2.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >
> >
> >> On sasquatch, the ~ldm/etc/ldmd.conf has (these lines mentioning dc-ldm2:
> >>
> >>> request         EXP     "^WNA.....-NCP.*ZTAMspec" dc-ldm2.tamu.edu
> >>> request         EXP     "^W.......-FNM"         dc-ldm2.tamu.edu
> >>> allow   ANY     ^dc-ldm2\.tamu\.edu$
> >>> accept ANY ".*" ^dc-ldm2\.tamu\.edu$
> >>>
> >> On dc-ldm2, the ~ldm/etc/ldmd.conf is simple, requesting only from
> >> sasquatch, with:
> >>
> >>> exec  "rtstats -f ANY -h sasquatch.tamu.edu"
> >>> request  FSL2|FSL3|NNEXRAD|IDS|DDPLUS      ".*" sasquatch.tamu.edu
> >>> request  EXP "^[DSW]" sasquatch.tamu.edu
> >>> request  SPARE "^[DSW]" sasquatch.tamu.edu
> >>> request  CRAFT        "K[A-Z]*"     sasquatch.tamu.edu
> >>> request  FNMOC ".*"  sasquatch.tamu.edu
> >>> allow ANY  ^sasquatch\.tamu\.edu$
> >>>
> >> I am thinking that what we really want is to have
> >> sasquatch:~ldm/etc/ldmd.conf say:
> >>
> >>> request         EXP     "^[DSW]" dc-ldm2.tamu.edu
> >>> allow   ANY     ^dc-ldm2\.tamu\.edu$      ".*"    "^W.*TAM"
> >>> accept ANY ".*" ^dc-ldm2\.tamu\.edu$
> >>>
> >> What I need to verify is, does this sound like it will work, so that
> >> 1) the ^WNAM.*-NCP.*ZTAM files and the ^W.......-TAM, which are created
> >> and pqinserted on dc-ldm2, correctly get into the LDM queue (feedtype
> >> used is EXP)
> >> 2) there will not be a "bounce-back" effect of having the files created
> >> in 1) come back into dc-ldm2's queue as new products
> >> 3) and allow me to (for experiments only, at this time) pqinsert files
> >> (which a third-party scp'd to our file server (dc-ldm2)) which are not
> >> normally created and pushed out by dc-ldm2
> >> ?
> >>
> >> Now I'm not even sure if I've asked the question correctly or well.
> >> Reference our SCOOP LDM Admins meeting of 20070305 in College Station,
> >> Texas.
> >>
> >> An inelegant solution to my dilemma in this experimental phase of our
> >> SCOOP project might be to
> >> * use ldmsend on dc-ldm2, and the SPARE feedtype, to get the files into
> >> the ldm queue on sasquatch,
> >> * then have a pqact entry which takes those files and pqinsert's them
> >> with the EXP feedtype?
> >> (what would such a pqact entry look like??? SPARE (^WANAF.*) PIPE
> >> -close /usr/local/ldm/bin/pqinsert -v -l logfile -f EXP \1
> >>
> >> Thanks,
> >> Donna
> >> --
> >> Donna Cote
> >> Senior Research Associate
> >> The Academy for Advanced Telecommunications and Learning Technologies
> >> Texas A&M University
> >> 3139 TAMU
> >> College Station, Texas 77843-3139
> >> Office: (979) 862-3982
> >> Cell: (979) 324-3549
> >> Fax: (979) 862-3983
> >>
> >>
> >>
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: DVS-863493
> > Department: Support IDD SCOOP
> > Priority: Normal
> > Status: Closed
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: DVS-863493
Department: Support IDD SCOOP
Priority: Normal
Status: Closed