Working Apache configuration for NOID resolver?

[Karl Holten]

Hello,

The University of Wisconsin-Milwaukee is looking at issuing ARK identifiers using NOID. We have successfully issued IDs over apache but we are having problems getting them to resolve using the directions available on CPANM. I know there is probably some overlap between those using ARK and NOID, so I'm hoping someone can point out what is wrong with the apache configuration, or provide a working one of their own. If not, does someone know of a community for NOID that might be able to help? Thanks.

APACHE CONFIG

<VirtualHost *:80>
  ServerName noid-dev.uwm.edu
  DocumentRoot /var/www/noid/public
  ErrorLog /var/log/noid/error_log
  CustomLog /var/log/noid/access_log common
  Alias /noid/ /var/www/noid/public

  ScriptAliasMatch ^/ic/noidu(.*) "/var/www/noid/public/noidu$1"
  ScriptAliasMatch ^/public/noidr(.*) "/var/www/noid/public/noidr$1"

  <Location /var/www/noid/public>
    AllowOverride All
      SetHandler perl-script
      PerlResponseHandler ModPerl::Registry
      PerlOptions +ParseHeaders
      Options +ExecCGI
      Order allow,deny
      Allow from all

  </Location>

RewriteEngine on
# External resolution; start program once on server start
RewriteMap  rslv           prg:/var/www/noid/public/noidr_kt5

# Main lookup; add artificial prefix for subsequent testing
RewriteRule ^/ark:/(99999/.*)$ "_rslv_${rslv:get $1 myGoto}"

# Test: redirect [R] if it looks like a redirect
RewriteRule ^_rslv_([^:]*://.*)$    $1 [R]
# Test: strip prefix; pass through [PT] if intended for us
RewriteRule ^_rslv_(/.*)$           $1 [PT]
# Test: restore value if lookup failed; let come what may
RewriteRule ^_rslv_$                %{REQUEST_URI}
# Alternative: redirect failed lookup to a global resolver


#RewriteLock /var/log/noid/redirect_lock
#RewriteLog /var/log/noid/redirect_log
#RewriteLock   /var/log/rewrite/lock
#RewriteLog    /var/log/rewrite/log
## RewriteLogLevel 9


</VirtualHost>

URL: http://noid-dev.uwm.edu/public/noidu_kt5?mint+1

Response: kt3x841

URL: http://noid-dev.uwm.edu/public/noidu_kt5?bind+set+kt3x841+myGoto+http://foo.ucsd.edu/

Id: kt3x841 Element: myGoto Bind: set Status: ok, 20 bytes written, replacing 20 bytes

URL: http://noid-dev.uwm.edu/ark:/99999/kt3x841

Response: 404 Error

[John Kunze]

There's a problem in that key that you are binding needs to have the NAAN prepended to it. What you probably want to do is make sure the minter is set up to output things like

    99999/kt3x841

instead of just

    kt3x841

It's that first longer string that you want to bind to, since the NAAN is stored with the random string that the minter generated.

The reason to store the NAAN as well as the random string is so that you can store test ARKs (NAAN=99999) along with your real ARKs (under your own NAAN). Also, some organizations support more than one NAAN. 

The example doc excerpt  below shows the longer string in use, in this case with the 13030 NAAN.

http://foo.ucop.edu/nd/noidu_kt5?
    bind+set+13030/kt639k9+myGoto+http://foo.ucsd.edu/

In this case we stored a URL in "myGoto". This kind of convention can underly a redirection mechanism that is part of an organization's overall identifier resolution strategy. To retrieve that stored data,

http://foo.ucop.edu/nd/noidu_kt5?get+13030/kt639k9+myGoto

--
You received this message because you are subscribed to the Google Groups ARKs group. To post to this group, send email to arks-...@googlegroups.com. To unsubscribe from this group, send email to arks-forum+...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/arks-forum?hl=en
---
You received this message because you are subscribed to the Google Groups "ARKs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arks-forum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/882085e6-8d46-494b-9484-1d7339ce8bacn%40googlegroups.com.

[John Kunze]

Thinking about this more, the noid documentation could be a little more complete and ready-to-go.

For the resolver to work with those rewrite rules, you'll want a minter that prepends the NAAN in front of the generated strings. Here's an example of a minter that will prepend a NAAN and a "shoulder" (kt5).

naan=99999

shdr=kt5

noid -f $d dbcreate $shdr.reedeedk long $naan example.org demo

[Karl Holten]

That worked! I misinterpreted the Rewrite rule and thought it was just matching on the end part.

I created a directory called kt5 and set kt5 as the $d variable and wound up with the following:

noid -f kt5 dbcreate kt5.reedeedk long 99999 example.org demo

Now that I've included the NAAN as part of the ID generator it is resolving just fine. Thank you so much!

[John Kunze]

Very glad to hear that it's working.

We'd love for you to share your implementation story in a short blog post (eg, 2 paragraphs) at some point. Let me know if that's interesting to you!

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/7bf1420c-ab2e-4386-93ec-c787f4aa80d6n%40googlegroups.com.