server certificate verification failed
Hi, After a couple of weeks of successful builds, we are suddenly getting the following error in continuum 1.0.3: svn: PROPFIND of '/svn/ges-abfo/trunk': Server certificate verification failed: issuer is not trusted (https://ges-abfo.ibitdev.com) Has anyone seen anything like this before? One guess is that the ssl certificate has somehow changed and if so, is there some way to get continuum to auto-accept this? Thanks - Ashley --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: server certificate verification failed
Continuum can't accept it automatically because it's svn that must accept it. On your continuum server, run svn with the user that run continuum to accept permanently the certificate. Emmanuel Ashley Williams a écrit : Hi, After a couple of weeks of successful builds, we are suddenly getting the following error in continuum 1.0.3: svn: PROPFIND of '/svn/ges-abfo/trunk': Server certificate verification failed: issuer is not trusted (https://ges-abfo.ibitdev.com) Has anyone seen anything like this before? One guess is that the ssl certificate has somehow changed and if so, is there some way to get continuum to auto-accept this? Thanks - Ashley --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: Continuum getting slower over time (1.1-beta-3)
Hello, continuum 1.1-beta-3 DOES get slower with time unfortunately. The time needed to perform some sequence of operations was about 3 minutes initially and went up to about 15 minutes. Then, continuum started producing various OutOfMemory Errors (Java heap space). This looks like a memory leak but I do not know where to search. If there is some info I can give, tell me. -- Julien On Mon, Oct 08, 2007 at 01:29:23PM +0200, Emmanuel Venisse wrote: Julien Stern a écrit : Hi list, Continuum (1.1-beta-3) seem to be getting slower and slower over time. I have roughly measured the time needed to verify all projects when nothing has been updated. (e.g. full SCM check pass without any invokation of Maven). After a week or so, this time seems to get much larger. If I restart continuum, it is short again. Has anyone else experienced a similar slow down ? No, I have few instances that run since few weeks and they aren't slow. If this is the case, I can try to perform some more precise measurements. Yes, please. Emmanuel
Re: server certificate verification failed
On Mon, October 15, 2007 10:57 am, Ashley Williams wrote: Ok I can do this. I was hoping that since continuum is responsible for calling out to subversion, it could automatically accept on my behalf. After all I've already told continuum of my user name and password for the repository url so it should have everything it needs to do this. The trouble with this is that by doing this, you are removing most of the protection the SSL certificate is offering you. Subversion can be configured to trust a root CA certificate(s), which will mean in theory that subversion will always trust any new certs it finds, on condition those certs are signed by a trusted root CA. This should make your problem go away. Regards, Graham --
Multi module setup as in maven docu
Hi, in http://maven.apache.org/guides/introduction/introduction-to-the-pom.html #Example_4 there is an example for a multi module environment. Namely Example 4 I have a structure similar to . |-- my-module | `-- pom.xml `-- parent `-- pom.xml In the Maven docu they say I just need to add follwoing to the parent/pom.xml project parent groupIdcom.mycompany.app/groupId artifactIdmy-app/artifactId version1/version relativePath.../parent/pom.xml/relativePath /parent modelVersion4.0.0/modelVersion artifactIdmy-module/artifactId /project I'm not sure if this works with continuum. First: is it their aim that there are three dots? Second: Will this work, cause continuum has another directory structure with IDs in the path. For example: . |-- 12 |`-- my-module | `-- pom.xml |-- 9 `-- parent `-- pom.xml So I'm wondering if the relativePath notation works or if this only relates to the structure inside the SCM. Additionally, it's possible that the ids change, I simply do not want to hardcode the pathes. Nevertheless, I tried with the example 4 and I get a two-step continuum error: The first is an error --- org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perfor mAction(DefaultBuildController.java:443) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build( DefaultBuildController.java:148) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.exec uteTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter .call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask .java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error while mapping metadata:add.project.validation.error add.project.project.building.error add.project.unknown.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.upda teProjectFromCheckOut(MavenTwoBuildExecutor.java:168) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectory ContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction .java:75) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perfor mAction(DefaultBuildController.java:417) ... 8 more --- The second is a failure: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: lt; 1 second [INFO] Finished at: Mon Oct 15 11:52:36 CEST 2007 [INFO] Final Memory: 1M/4M [INFO] Greetings Manuel
Re: server certificate verification failed
I would expect that if I have taken the decision to connect to a repository for development then it would go without saying that I also trust that site. I'm not suggesting also that continuum auto-trusts out of the box, but rather as a configurable property and maybe against certain certificates. However I take your point that this is a subversion config issue - looks like I'll be browsing the redbook for the next half an hour ;) Thanks - Ashley Graham Leggett [EMAIL PROTECTED] wrote on 15/10/2007 10:37:38: On Mon, October 15, 2007 10:57 am, Ashley Williams wrote: Ok I can do this. I was hoping that since continuum is responsible for calling out to subversion, it could automatically accept on my behalf. After all I've already told continuum of my user name and password for the repository url so it should have everything it needs to do this. The trouble with this is that by doing this, you are removing most of the protection the SSL certificate is offering you. Subversion can be configured to trust a root CA certificate(s), which will mean in theory that subversion will always trust any new certs it finds, on condition those certs are signed by a trusted root CA. This should make your problem go away. Regards, Graham -- --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: Multi module setup as in maven docu
[EMAIL PROTECTED] a écrit : Hi, in http://maven.apache.org/guides/introduction/introduction-to-the-pom.html #Example_4 there is an example for a multi module environment. Namely Example 4 I have a structure similar to . |-- my-module | `-- pom.xml `-- parent `-- pom.xml In the Maven docu they say I just need to add follwoing to the parent/pom.xml project parent groupIdcom.mycompany.app/groupId artifactIdmy-app/artifactId version1/version relativePath.../parent/pom.xml/relativePath /parent modelVersion4.0.0/modelVersion artifactIdmy-module/artifactId /project I'm not sure if this works with continuum. First: is it their aim that there are three dots? You can't use ... in maven and/or Continuum. ... mean that is a relative path that can be .. or ../../dir1/dir2/ or something. Second: Will this work, cause continuum has another directory structure with IDs in the path. For example: . |-- 12 |`-- my-module | `-- pom.xml |-- 9 `-- parent `-- pom.xml So I'm wondering if the relativePath notation works or if this only relates to the structure inside the SCM. Additionally, it's possible that the ids change, I simply do not want to hardcode the pathes. Continuum use maven API to load projects so if you checkout your my-module project without other parent/modules, you'll have the same result. If maven don't find the parent pom with the relative path, it use the one it found in the local/remote repo. Nevertheless, I tried with the example 4 and I get a two-step continuum error: The first is an error --- org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perfor mAction(DefaultBuildController.java:443) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build( DefaultBuildController.java:148) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.exec uteTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter .call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask .java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error while mapping metadata:add.project.validation.error add.project.project.building.error add.project.unknown.error The error isn't well formatted but it's generally because Continuum/maven can load the project. The parent or a dependency can't be loaded from the local/remote repository. Emmanuel at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.upda teProjectFromCheckOut(MavenTwoBuildExecutor.java:168) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectory ContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction .java:75) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perfor mAction(DefaultBuildController.java:417) ... 8 more --- The second is a failure: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: lt; 1 second [INFO] Finished at: Mon Oct 15 11:52:36 CEST 2007 [INFO] Final Memory: 1M/4M [INFO] Greetings Manuel
Re: Project on SVN with a not versioned parent
I had a similar problem with continuum 1.1beta3, artifactory and maven 2.0.7, except I use CVS. Due to a bug in maven 2.0.7, you cannot use the mirror tag to redirect to artifactory, thus you must use a profile to achieve this redirection. Be careful to specify activationactiveByDefaulttrue/activeByDefault/activation for this profile otherwise continuum cannot find artifactory and then that leads to the message Missing artifact trying to build the POM. Check that its parent POM is available or add it first in Continuum. Hope this helps. Vincent -- View this message in context: http://www.nabble.com/Project-on-SVN-with-a-not-versioned-parent-tf4588826.html#a13211640 Sent from the Continuum - Users mailing list archive at Nabble.com.
Re: server certificate verification failed
See comments inline... Graham Leggett [EMAIL PROTECTED] wrote on 15/10/2007 13:40:36: On Mon, October 15, 2007 1:51 pm, Ashley Williams wrote: I would expect that if I have taken the decision to connect to a repository for development then it would go without saying that I also trust that site. You are missing the point behind SSL. Quite possibly! Although I would have thought the issue of whether or not I trust a particular site is different from whether my continuum installation is connecting me to the site I think it should be. So can you give guidance as to what my action should be? Each developer has just been hitting the 'accept permanently' button in subclipse in their own workspaces. So should we be thoroughly investigating the proposed certificate before doing this, since a glance at the certificate hostname field looks fine to me ( *.ibitdev.com). Continuum is in a dmz and has not been reconfigured since the last build, so I am fairly certain it is connecting to the correct url. Obviously you trust the site, you put it there, but how does your continuum know that the site it is connecting to is the site you trust? Diverting continuum to connect to something else is not very difficult to do at all by a third party device on the same LAN (even a switched LAN), it is not difficult to fool your subversion client to try and log into a fake repository using the correct credentials. Having done this, the attacker has a known working username and password for your repo, and depending on how you set it up, they could either steal code or alter code to their advantage. (Luckily as you run svn over https, you are not open to the risk of a disgruntled employee deleting the files behind your CVS repo, as happened at a friend's company a few weeks ago causing much angst and grief). Regards, Graham -- --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: Guest security in 1.1-beta-3
Thanks for the pointers to the source. After I looked a little closer, I realized the guest user only had access to add new modules to the existing project, not to add new project groups. This seems reasonable to me. (Or at least not a big enough deal for me to dig into the source code) I would be more concerned about letting guest users add new project groups. I've just finished migrating most of our existing projects over to 1.1-beta3, so overall I've been pretty happy with 1.1. OT: I did checkout hudson to see where they are at. With hudson, the big missing functionality for me was it doesn't pick up email notifiers from the pom for build notification. Thanks for your assistance, Tom Emmanuel Venisse wrote: Look at this file (http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-security/src/main/resources/META-INF/redback/redback.xml), it defines all roles and inheritence between each roles. If you write a patch, I don't think it will be in 1.1 but you'll have it for your instance. Emmanuel -- View this message in context: http://www.nabble.com/Guest-security-in-1.1-beta-3-tf4594648.html#a13224776 Sent from the Continuum - Users mailing list archive at Nabble.com.
running build targets even when repository code is unchanged?
Apologies if this has already been answered. I searched the forums (and the web in general) as well as reading through what Continuum documentation I could find, but I was unable to figure this out. Is it possible to have Continuum run scheduled build targets regardless of whether the project under which the build target resides has changed? As far as I can tell, Continuum will only run scheduled build targets when files in the repository for the project have been updated (e.g., by adding or committing code in CVS). This works fine for most of our stuff, specifically where the project specified in Continuum is also the project that we want to deploy. However, we have two instances where the code in the repository specified for the Continuum project may change infrequently, despite needing to have the associated build targets run on a nightly basis. In one case, we're trying to push some code on a nightly basis to development servers, but the project specified in Continuum is a package of shell scripts that doesn't change often (one of the scripts in question is what does the nightly push). In the other case, we want Continuum to trigger an Ant target to perform nightly test harness runs (the test harness code tends to change much less frequently than the application code that's being tested). I could just do this directly with cron jobs and another wrapper script for the nightly tests, but having the web interface of Continuum is nice, especially since it would allow the non-developers on our team to easily and safely push newly checked in code or run the test suite without having to worry about pulling up a terminal and running the scripts themselves. Any help would be much appreciated. Thanks very much... -john -- View this message in context: http://www.nabble.com/running-build-targets-even-when-repository-code-is-unchanged--tf4631473.html#a13225243 Sent from the Continuum - Users mailing list archive at Nabble.com.
