<!-- keep this as a security measure: * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup,Main.LCGAdminGroup * Set ALLOWTOPICRENAME = Main.TWikiAdminGroup,Main.LCGAdminGroup #uncomment this if you want the page only be viewable by the internal people #* Set ALLOWTOPICVIEW = Main.TWikiAdminGroup,Main.LCGAdminGroup --> KeyWords: SysAdmin ---+ Issues of our 1.9.3-3 dcache installation ---++ gPlazma problems Note: Filed as dcache support request #5119 on 2009-09-24. I am trying to debug an issue of failing phedex CMS exports. They all fail with authentication problems as indicated by the errors from SRM/FTS. My first suspicion is that the users who fail do not use real VOMS proxies. Therefore I also generated myself a naked grid proxy and started to test: To have a deeper look into the problem, I am executing srm requests against our dcache while following the gPlazma log, and stracing the gPlazma process: From the UI <pre> srmls -l srm://storage01.lcg.cscs.ch:8443/srm/managerv2?SFN=/pnfs/lcg.cscs.ch/cms </pre> Every such event leaves in the =/var/log/d-cache/gPlazma-storage02Domain.log=: <pre %FILESTYLE%> Exception thrown by gplazma.authz.plugins.vorolemap.VORoleMapAuthzPlugin: java.lang.NullPointerException 22 Sep 2009 16:47:42 (gPlazma) [v2:srmLs:71788691 SRM-storage01] caught exception: </pre> Following the cell and its siblings for some sys calls with strace <pre> strace -e trace=open,stat64 -fp 4749 Process 4749 attached with 84 threads - interrupt to quit </pre> *every invocation of srmls with the non-VOMS-proxy resulted in the following outputs from strace* (sometimes there were additional files read, but always there was a SIGSEGV): <pre> [pid 6925] stat64("/opt/d-cache/etc/dcachesrm-gplazma.policy", {st_mode=S_IFREG|0444, st_size=3859, ...}) = 0 [pid 6925] stat64("/etc/grid-security/grid-vorolemap", {st_mode=S_IFREG|0444, st_size=42556, ...}) = 0 [pid 6925] --- SIGSEGV (Segmentation fault) @ 0 (0) --- </pre> Note that the files are not really read - probably because dcache only tests whether they have changed (when I touch a file, I can see an open on the next run). *I am surprised... Segmentation Errors in Java VM. That should not be possible, right?* (but I'm just a C/C++ guy). I see log lines like the above ones quite often in the gPlazma log, and therefore at least this is a hint as to a number of non-VOMS proxies trying to access our site. However, I would like to get a log line about which DN is responsible, instead of a SIGSEGV. ---+++ dCache gPlazma config Excerpt from our =dcachesrm-gplazma.policy= file: <pre %FILESTYLE%> # Switches xacml-vo-mapping="OFF" saml-vo-mapping="OFF" # we want no more kpwd mapping at CSCS. Note that this may cause problems with # users relying on non-voms proxies kpwd="OFF" grid-mapfile="OFF" gplazmalite-vorole-mapping="ON" # Priorities xacml-vo-mapping-priority="5" saml-vo-mapping-priority="1" kpwd-priority="3" grid-mapfile-priority="4" gplazmalite-vorole-mapping-priority="2" </pre> - Main.DerekFeichtinger - 2009-09-22
This topic: LCGTier2
>
WebHome
>
PhoenixClusterBlog
>
PhoenixBlog20090922x1649
Topic revision: r2 - 2009-09-24 - DerekFeichtinger
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback