Re: The svn command failed ... Server certificate verification failed: issuer is not trusted
Greetings: here is a clip from the logs: 85479675 [defaultScheduler_Worker-13] INFO org.apache.maven.continuum.build.set tings.SchedulesActivator:default - > Executing build job (D EFAULT_SCHEDULE)... 85479720 [defaultScheduler_Worker-13] INFO org.apache.maven.continuum.Continuum :default - Enqueuing 'emap' (Build definition id=7). 85479726 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Initializing build 85479742 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Starting build of emap 85479807 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Updating working dir 85479808 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Performing action check-working-directory 85479814 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Performing action checkout-project 85479820 [pool-1-thread-1] INFO org.apache.maven.continuum.scm.ContinuumScm:def ault - Checking out project: 'emap', id: '7' to '/opt/continuum-1.1-beta-3/apps /continuum/webapp/WEB-INF/working-directory/7'. 85479896 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Executing: /bin/sh -c "cd /opt/continuum-1.1-beta-3/apps/continuum/webapp/WE B-INF/working-directory && svn --username continuum --non-interactive checkout h ttps://localhost/repo/emap/trunk 7" 85479898 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Working directory: /opt/continuum-1.1-beta-3/apps/continuum/webapp/WEB-INF/w orking-directory 85480114 [pool-1-thread-1] WARN org.apache.maven.continuum.scm.ContinuumScm:def ault - Error while checking out the code for project: 'emap', id: '7' to '/opt/ continuum-1.1-beta-3/apps/continuum/webapp/WEB-INF/working-directory/7'. 85480114 [pool-1-thread-1] WARN org.apache.maven.continuum.scm.ContinuumScm:def ault - Command output: svn: PROPFIND request failed on '/repo/emap/trunk' svn: PROPFIND of '/repo/emap/trunk': Server certificate verification failed: iss uer is not trusted (https://localhost) 85480114 [pool-1-thread-1] WARN org.apache.maven.continuum.scm.ContinuumScm:def ault - Provider message: The svn command failed. 85480184 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Merging SCM results 85480232 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.Buil dController:default - Error updating from SCM, not building I can tell I am running as the continuum user by invoking: [EMAIL PROTECTED]:~$ ps -u continuum PID TTY TIME CMD 12119 ?00:00:35 wrapper 12121 ?00:08:57 java Let me know if I can send along anything else. Thanks for your help. Bill. Emmanuel Venisse wrote: > > can you paste your continuum logs too? > > Are you sure you run continuum with the continuum user because this svn > output is generally printed when the certificate isn't registered in the > svn registry. > > Emmanuel > > Bill Brown a écrit : >> Greetings: >> >> I am trying to use continuum-1.1-beta-3 with jdk java-6-sun-1.6.0.03 on >> Ubuntu Linux. >> >> After adding a maven2 pom, I get the following error when trying to >> build: >> >> Provider message: The svn command failed. >> Command output: >> --- >> svn: PROPFIND request failed on '/repo/project/trunk' >> svn: PROPFIND of '/repo/project/trunk': Server certificate verification >> failed: issuer is not trusted (https://localhost) >> >> I run the continuum server with a user named continuum. >> >> I can manually run (as the continuum user) from the command line: 'svn >> list >> https://localhost/repo/project/trunk' and get a listing of the contents >> of >> the project/trunk. The first time I ran this I was prompted to >> permenantly >> accept the certificate which I did. >> >> I have a copy of the cert in the continuum users home directory .keystore >> file. >> >> Am I missing some other command to run to get continuum to recognize the >> https://localhost certificate? >> >> Thanks for your help. >> Bill. >> > > > -- View this message in context: http://www.nabble.com/The-svn-command-failed-...-Server-certificate-verification-failed%3A-issuer-is-not-trusted-tf4611163.html#a13185702 Sent from the Continuum - Users mailing list archive at Nabble.com.
Re: 1.1-beta-3 LDAP
that is some great feedback, I was looking for something to wedge things into a real environment and get some information. thanks! jesse On 10/12/07, ossi petz <[EMAIL PROTECTED]> wrote: > > hallo > > hopefully this does not end up in thread-stealing... > i'd like to provide some ldap feedback on beta-3 too. > > i've managed to configred authentication against our active directory. > users can login to continuum. thats already something! > > so lets switch quickly to the problems part :) > > documentation. if this should be tested give people more than a dead > link in applicaiton.xml: > > http://svn.codehaus.org/plexus/plexus-redback/trunk/redback-site/src/site/apt/integration/ldap.apt > > as mentiond by bryan madsen there is a requirement for a guest account. > please remove that one. a guest is a guest. so no authentication against > any other system should be required. there a billions of guest auth > requests against the ldap server that serve no purpose. > > the security.properties contains the name of an admin. this user can see > all project groups in continuum. any other user seems to be equal to a > guest. when i try to edit a user only the users admin and guest exist. > both from continuum, none of these are ldap accounts. > so i cant reconfigure project access rights for ldap users at the moment? > also the created admin account in continuum does no longer work. i would > like some fallback authentication: if a user is not found in ldap try in > local database. we often have external users we dont create in our > active directory as they only need access to certain tools (bugzilla, > continuum, etc). in bugzilla this can be configured (ldap only, local > only, ldap->local, local->ldap). i did like that feature very much. > > notifications cannot be assigned to ldap users (well those may never > where assigned to continuum accounts anyway? not sure). > > usernames with special characters (mmüller, tkühn) cause a server error > (stacktrace see below). the user mmüller can login with 'mmuller', after > that the username 'mmüller' appears in the logged in bar :) > > usernames that are not found in ldap cause a 500 server error too. > > > thats about my report. if you require any mor information please tell :) > > thanks for doing ldap integration! > > > regards > > ossi > > > > > Stacktrace for special usernames: > Oct 12, 2007 4:20:36 PM org.mortbay.jetty.servlet.ServletHandler handle > WARNING: /continuum/security/login.action: > java.lang.NullPointerException > at > > org.codehaus.plexus.redback.authentication.users.UserManagerAuthenticator.authenticate > (UserManagerAuthenticator.java:85) > at > > org.codehaus.plexus.redback.authentication.DefaultAuthenticationManager.authenticate > (DefaultAuthenticationManager.java:74) > at > org.codehaus.plexus.redback.system.DefaultSecuritySystem.authenticate( > DefaultSecuritySystem.java:98) > at > org.codehaus.plexus.redback.xwork.action.LoginAction.webLogin( > LoginAction.java:317) > at > org.codehaus.plexus.redback.xwork.action.LoginAction.login( > LoginAction.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java > :39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction( > DefaultActionInvocation.java:358) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly( > DefaultActionInvocation.java:218) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke( > DefaultActionInvocation.java:192) > at > > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept > (SecureActionInterceptor.java:114) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke( > DefaultActionInvocation.java:190) > at > > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept > (PolicyEnforcementInterceptor.java:100) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke( > DefaultActionInvocation.java:190) > at > > org.codehaus.plexus.redback.xwork.interceptor.AutoLoginInterceptor.intercept > (AutoLoginInterceptor.java:156) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke( > DefaultActionInvocation.java:190) > at > > org.codehaus.plexus.redback.xwork.interceptor.ForceAdminUserInterceptor.intercept > (ForceAdminUserInterceptor.java:76) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke( > DefaultActionInvocation.java:190) > at > > org.codehaus.plexus.redback.xwork.interceptor.EnvironmentCheckInterceptor.intercept > (EnvironmentCheckInterceptor.java:122) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke( > Defa
Re: 1.1-beta-3 LDAP
hallo hopefully this does not end up in thread-stealing... i'd like to provide some ldap feedback on beta-3 too. i've managed to configred authentication against our active directory. users can login to continuum. thats already something! so lets switch quickly to the problems part :) documentation. if this should be tested give people more than a dead link in applicaiton.xml: http://svn.codehaus.org/plexus/plexus-redback/trunk/redback-site/src/site/apt/integration/ldap.apt as mentiond by bryan madsen there is a requirement for a guest account. please remove that one. a guest is a guest. so no authentication against any other system should be required. there a billions of guest auth requests against the ldap server that serve no purpose. the security.properties contains the name of an admin. this user can see all project groups in continuum. any other user seems to be equal to a guest. when i try to edit a user only the users admin and guest exist. both from continuum, none of these are ldap accounts. so i cant reconfigure project access rights for ldap users at the moment? also the created admin account in continuum does no longer work. i would like some fallback authentication: if a user is not found in ldap try in local database. we often have external users we dont create in our active directory as they only need access to certain tools (bugzilla, continuum, etc). in bugzilla this can be configured (ldap only, local only, ldap->local, local->ldap). i did like that feature very much. notifications cannot be assigned to ldap users (well those may never where assigned to continuum accounts anyway? not sure). usernames with special characters (mmüller, tkühn) cause a server error (stacktrace see below). the user mmüller can login with 'mmuller', after that the username 'mmüller' appears in the logged in bar :) usernames that are not found in ldap cause a 500 server error too. thats about my report. if you require any mor information please tell :) thanks for doing ldap integration! regards ossi Stacktrace for special usernames: Oct 12, 2007 4:20:36 PM org.mortbay.jetty.servlet.ServletHandler handle WARNING: /continuum/security/login.action: java.lang.NullPointerException at org.codehaus.plexus.redback.authentication.users.UserManagerAuthenticator.authenticate(UserManagerAuthenticator.java:85) at org.codehaus.plexus.redback.authentication.DefaultAuthenticationManager.authenticate(DefaultAuthenticationManager.java:74) at org.codehaus.plexus.redback.system.DefaultSecuritySystem.authenticate(DefaultSecuritySystem.java:98) at org.codehaus.plexus.redback.xwork.action.LoginAction.webLogin(LoginAction.java:317) at org.codehaus.plexus.redback.xwork.action.LoginAction.login(LoginAction.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:114) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:100) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.AutoLoginInterceptor.intercept(AutoLoginInterceptor.java:156) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.ForceAdminUserInterceptor.intercept(ForceAdminUserInterceptor.java:76) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.EnvironmentCheckInterceptor.intercept(EnvironmentCheckInterceptor.java:122) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.validator.ValidationI
Re: 1.1-beta-3 LDAP
redback requires a guest to exist for authorization purposes.. however the guest doesn't need to have any roles assigned to it. I would recommend just pointing the guest as some utility user in ldap and not give it any additional privileges.. we are looking at removing this guest user requirement in later version of redback, but that will be a while. jesse On 10/1/07, Madsen,Bryan <[EMAIL PROTECTED]> wrote: > > We do not allow guest accounts on our LDAP server. If I remove the ' > redback.default.guest' configuration I see this exception below. Is there > a way to bypass that? > > I would like all users with an LDAP sign-on to be considered a registered > user once signed in and then administer their access rights at that point. > > 69711 [SocketListener0-1] ERROR > com.opensymphony.webwork.dispatcher.DispatcherUtils - Could not find > action > Caught Exception while registering Interceptor class > redbackEnvironmentCheckInterceptor - Class: > org.codehaus.plexus.redback.xwork.checks.security.GuestUserEnvironmentCheck > File: GuestUserEnvironmentCheck.java > Method: validateEnvironment > Line: 100 - > org/codehaus/plexus/redback/xwork/checks/security/GuestUserEnvironmentCheck.java:100:-1 > at org.codehaus.plexus.xwork.PlexusObjectFactory.buildInterceptor( > PlexusObjectFactory.java:152) > at > com.opensymphony.xwork.config.providers.InterceptorBuilder.constructInterceptorReference > (InterceptorBuilder.java:56) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.lookupInterceptorReference > (XmlConfigurationProvider.java:701) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.loadInterceptorStack > (XmlConfigurationProvider.java:568) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.loadInterceptorStacks > (XmlConfigurationProvider.java:581) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.loadInterceptors > (XmlConfigurationProvider.java:602) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.addPackage > (XmlConfigurationProvider.java:204) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.loadConfigurationFile > (XmlConfigurationProvider.java:675) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.loadConfigurationFile > (XmlConfigurationProvider.java:678) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.init( > XmlConfigurationProvider.java:91) > at com.opensymphony.xwork.config.impl.DefaultConfiguration.reload( > DefaultConfiguration.java:86) > at > com.opensymphony.xwork.config.ConfigurationManager.getConfiguration( > ConfigurationManager.java:55) > at com.opensymphony.xwork.DefaultActionProxy.( > DefaultActionProxy.java:60) > at > com.opensymphony.xwork.DefaultActionProxyFactory.createActionProxy( > DefaultActionProxyFactory.java:46) > at > com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction( > DispatcherUtils.java:264) > at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter( > FilterDispatcher.java:202) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage( > PageFilter.java:118) > at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter( > PageFilter.java:52) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter( > ActionContextCleanUp.java:88) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( > WebApplicationHandler.java:821) > at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch( > WebApplicationHandler.java:471) > at org.mortbay.jetty.servlet.ServletHandler.handle( > ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) > at org.mortbay.jetty.servlet.WebApplicationContext.handle( > WebApplicationContext.java:633) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) > at org.mortbay.http.HttpServer.service(HttpServer.java:909) > at org.mortbay.http.HttpConnection.service(HttpConnection.java > :816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java > :982) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at org.mortbay.http.SocketListener.handleConnection( > SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: java.lang.NullPointerException > at > org.codehaus.plexus.redback.xwork.checks.security.GuestUserEnvironmentCheck.validate
