Confirmed also here, with complete re installation of the node. Fails
during yaim:
Caused by:
com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException:
Duplicate entry '/C=NL/O=NIKHEF/CN=NIKHEF medium-security certification
auth' for key 2
Στις 16/2/2011 10:38 πμ, ο/η Alessandro Paolini έγραψε:
> Hi all,
> just to confirm that with the temporary repository, the error is
> disappeared.
>
> On my test VOMS 3.2 I've done the following operations:
>
> 1) # yum remove ca_* ca-policy-egi-core ca-policy-lcg
>
> 2) # yum install lcg-CA
>
> 3) (maybe is necessary only a restart of the services) #
> /opt/glite/yaim/bin/yaim -c -s site-info.def -n VOMS
>
> 4) verify that "ca" table has been filled, and in particular:
> # mysql -u root -p -e "use voms_pacs_infn_it; select * from ca;" | grep
> cilo
> Enter password:
> 111 NULL /DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Silver CA 1 NULL
> 2011-02-16 09:21:22
>
> 5) check a voms-admin log:
>
> ==================================
> 09:20:52.873 [Resource Destroyer in BasicResourcePool.close()] - WARN
> c.m.v.resourcepool.BasicResourcePool - Failed to destroy resource:
> com.mchange.v2.c3p0.impl.NewPooledConnection@4e0a39de
> java.lang.NullPointerException: null
> at
> com.mchange.v2.log.log4j.Log4jMLog$Log4jMLogger.isLoggable(Log4jMLog.java:255)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:490)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:191)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:470)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.resourcepool.BasicResourcePool$1DestroyResourceTask.run(BasicResourcePool.java:964)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.resourcepool.BasicResourcePool.destroyResource(BasicResourcePool.java:989)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.resourcepool.BasicResourcePool.access$100(BasicResourcePool.java:32)
> [c3p0-0.9.1.jar:0.9.1]
> at
> com.mchange.v2.resourcepool.BasicResourcePool$5.run(BasicResourcePool.java:1174)
> [c3p0-0.9.1.jar:0.9.1]
> 09:21:05.595 [main] - INFO o.g.s.voms.admin.core.VOMSService -
> VOMS-Admin starting for VO: pacs.infn.it
> 09:21:11.980 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task UpdateCATask with period: 1800 seconds
> 09:21:11.992 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task TaskStatusUpdater with period: 30 seconds
> 09:21:11.995 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task ExpiredRequestsPurgerTask with period: 300 seconds
> 09:21:15.782 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task MembershipCheckerTask with period: 300 seconds
> 09:21:15.783 [main] - INFO o.g.s.voms.admin.core.VOMSService -
> VOMS-Admin started succesfully.
> 09:21:17.863 [main] - WARN c.o.x.c.p.XmlConfigurationProvider - no
> default parameter defined for result of type json
> 09:21:22.458 [pool-1-thread-1] - INFO
> o.g.s.v.a.persistence.dao.VOMSCADAO - Adding
> '/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Silver CA 1' to trusted CA
> database.
> 09:22:09.584 [main] - INFO o.g.s.voms.admin.core.VOMSService -
> VOMS-Admin starting for VO: pacs.infn.it
> 09:22:15.761 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task UpdateCATask with period: 1800 seconds
> 09:22:15.774 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task TaskStatusUpdater with period: 30 seconds
> 09:22:15.777 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task ExpiredRequestsPurgerTask with period: 300 seconds
> 09:22:19.482 [main] - INFO o.g.s.v.a.c.t.VOMSExecutorService -
> Scheduling task MembershipCheckerTask with period: 300 seconds
> 09:22:19.483 [main] - INFO o.g.s.voms.admin.core.VOMSService -
> VOMS-Admin started succesfully.
> 09:22:21.203 [main] - WARN c.o.x.c.p.XmlConfigurationProvider - no
> default parameter defined for result of type json
> 09:23:33.394 [TP-Processor20] - INFO o.g.s.v.a.s.InitSecurityContext -
> Connection from "131.154.3.49" by /C=IT/O=INFN/OU=Personal
> Certificate/L=CNAF/CN=Alessandro Paolini (issued by
> "/C=IT/O=INFN/CN=INFN CA", serial 19500)
> 09:23:33.702 [TP-Processor22] - INFO o.g.s.v.a.s.InitSecurityContext -
> Connection from "131.154.3.49" by /C=IT/O=INFN/OU=Personal
> Certificate/L=CNAF/CN=Alessandro Paolini (issued by
> "/C=IT/O=INFN/CN=INFN CA", serial 19500)
> =====================================================================================================
>
>
> for the production VOMS 3.1 I hope to apply the correction later today,
> because the operation have to be done almost at the same time on the
> master and on the replica servers, so I have to ask people who manage
> the replica ones
>
> cheers,
> Alessandro
>
>
> Il 15/02/2011 17:39, David Groep ha scritto:
>> Hi all,
>>
>> [sorry for being late]
>>
>> The CILogon CA was the only new one introduced in 1.38, so if the
>> VOMS is trying to be cleaver and insert only the new ones, only
>> CILogon would show up.
>>
>> Strangely, though, this issue was not found by OSG when they tested the
>> new format, not in SR of EGI-version 1.37, which was also the new format.
>> Could some-one with a test voms server try a completely
>> fresh install (or clean the CA database) and then re-populate it on
>> the basis of the new-format distribution?
>> It then should show errors for *all* CAs, since each and every CA
>> trust anchor file (*.pem) now has two symlinks (*.0) pointing to it, just
>> like what OpenSSL's c_rehash has done all along...
>> If even with a blank database only CILogon has troubles, it's a CILogon
>> problem ...
>> I would be really interested in the result...
>>
>> As for the legacy build: as long as there is a demand for it the
>> IGTF will keep producing it -- don't worry!
>>
>> Other option: directly use c_rehash from your favourite OpenSSL
>> version for
>> your platform, and use only one symlink.
>>
>> DavidG.
>>
>> On 2011-02-15 17:25, Maarten Litmaath wrote:
>>> Hi Dimitris, all,
>>>
>>>> It seems this tasks tries to add the same CA more than one time.
>>>> After a
>>>> talk with my colleague Christos Triantiafillidis, this new CA release
>>>> contains 2 symlinks for every ca file, plus the actual file. In
>>>> previous
>>>> CA releases, only one actual file per ca certicate was present. It
>>>> seems
>>>> VOMS cannot handle the current CAs rpm. You can downgrade to 1.37 to
>>>> "solve" this problem if your VOMS stoppped working.
>>> Or use the "legacy" build of the 1.38 rpms:
>>>
>>> https://dist.eugridpma.org/distribution/igtf/current-old/
>>>
>>> They want to stop providing that format, but maybe we have a good
>>> argument for continuing it for a while...
>
>
--
=============================================================================
Dimitris Zilaskos
GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece
Tel: +302310998988 Fax: +302310994309
http://www.grid.auth.gr
=============================================================================
|