Re: controlling upstream/downstream relationships

[Maven User]

Anyone else?

There should be someway to reset this

Re: controlling upstream/downstream relationships

[Sami Tikka]

AFAIK that information has never been written down anywhere. Instead
it has always been inferred from the "Trigger other projects..." and
"Build after other projects" settings of jobs.

-- Sami

2012/5/2 Maven User :
> Hi all -
>
> I could have sworn somewhere that a jenkins job stores what it thinks is an
> upstream or downstream job.
>
> I have two jobs that at one point, were misconfigured.  Now one always
> triggers the other.
>
> Is there a way to clip this configuration?  I could have sworn that in one
> of the files on the jenkins server it stored that kind of information, but I
> can't see it anymore.
>
>

Re: CLI Authentication using Unix Users

[Sami Tikka]

I have often found the ssh access to be useful when other kind of
authentication has been problematic. Have you seen
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH ?

-- Sami

2012/5/2 Anshul :
> Hi,
> One of my Jenkins job actually creates a new job using the cli
> interface. The creator job (and all other jobs by default) require
> authentication to build.
>
> The creator job calls the jenkins cli to create the new job but it
> doesn't make use of the information that a logged in user is actually
> running the job and the build fails citing authentication issue for
> user anonymous. How can I make sure the cli gets the required
> credentials?
>
> Jenkins Version: 1.446
>
> I am using Project Matrix Based Authentication for all the activities
> on my Jenkins installation and ideally want to keep any build/create/
> delete actions restricted to the logged in users. The users are the
> unix users.
>
> Thanks,
> Anshul

Re: Static Analysis of Unix Shell Scripts

[Sami Tikka]

What kind of static analysis are you looking for?

You can do a syntax check for a script by running "bash -n script.sh",
but that's all the static analysis I have ever done for shell scripts.

-- Sami

2012/5/2 Nig :
> Hi,
> Does anyone know if there are any static analysis tools for Unix shell
> scripts (e.g. sh, ksh) ?
> Thanks !

Re: authenticating with certificates & username/password

[Dustin Parker]

I did it!

I looked at the files hudson.scm.SubversionSCM.xml and 
jobs//subversion.credentials. Both of them had, from a previous 
repository, an entry that looked like:


  ;
  
username
YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=
  


and an entry that looked like:


  ; Subversion 
Repositories
  
username
YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=
  


so I gathered the former was for the *server* and the latter was for the *basic 
realm*. Even that wasn't true, this got me to realize that SVNKit would be *
forced* to distinguish between the two: the realm isn't available until 
after the security has been negotiated, so if SVNKit is going to supply a 
password, it can only use the hostname. Then once the secure connection has 
been established, it will try to look up credentials in this map using the 
host and realm name. So I ginned up two entries: one with the certificate 
authentication and *only* the hostname, and another with password 
authentication and the host *and *realm names, just like above (only using 
certificate authentication for the first example). So far, crossing my 
fingers and toes, this seems to work!

On Wednesday, May 2, 2012 10:41:14 AM UTC-7, Dustin Parker wrote:
>
> This issue (JENKINS-3912) is currently stalling our development effort, 
> too. I'm trying a variety of things to work around the issue. The 
> frustrating thing is that jsvn from the command line *works*, so the SVN 
> plugin is taking this functioning library and *breaking* it somehow.
>
> On Wednesday, July 13, 2011 5:40:50 AM UTC-7, michaelw wrote:
>>
>> Has this been resolved? Sorry to bring up such an old post but I have the
>> same problem.
>>
>> The scenario is as follows:
>>
>> 1. SSL is configured on our apache server to require a client certificate 
>> -
>> right at the front so you can't access any of the content if you don't 
>> have
>> the client certificate.
>> 2. The svn server is thus sitting behind the apache server - we thus use
>> https to reach our svn server.
>> 3. The svn server then has its own username/password resolution 
>> facilities,
>> this is to do thing like permissions on svn folders etc.
>>
>> I can't get Jenkins to checkout my code.
>>
>> When I select the username/password option I get the following exception
>>
>> 
>>
>> Caused by: java.lang.NullPointerException
>> at 
>> org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:129)
>> at 
>> org.apache.commons.io.FileUtils.readFileToByteArray(FileUtils.java:1135)
>> at
>>
>> hudson.scm.SubversionSCM$DescriptorImpl$SslClientCertificateCredential.(SubversionSCM.java:1494)
>> at
>>
>> hudson.scm.UserProvidedCredential$AuthenticationManagerImpl.getFirstAuthentication(UserProvidedCredential.java:205)
>> at
>>
>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:319)
>> at
>>
>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:301)
>> at
>>
>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:196)
>> at
>>
>> sun.security.ssl.AbstractWrapper.chooseClientAlias(SSLContextImpl.java:282)
>> at
>>
>> sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:629)
>> at
>>
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228)
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610)
>> at sun.security.ssl.Handshaker.process_record(Handshaker.java:546)
>> at 
>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913)
>> at
>>
>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158)
>> at 
>> sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:652)
>> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:78)
>> at 
>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>> at 
>> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>> at
>>
>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.sendData(HTTPConnection.java:229)
>> at
>>
>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:166)
>> at
>>
>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364)
>> ... 59 more
>>
>> Almost as if it is looking for a client certificate file but as one isn't
>> set, it cannot find one.
>>
>> Then if I try the other option - client certificate I get:
>>
>> Attempting an SSL client certificate authentcation
>> Passing user name null and password you entered
>> Failed to authenticate: org.tmatesoft.svn.core.SVNErrorMessage: svn: 
>> OPTIONS
>> of /OldMutual/sandbox/trunk/maven/parent: 401 Authorization Requi

controlling upstream/downstream relationships

[Maven User]

Hi all - 

I could have sworn somewhere that a jenkins job stores what it thinks is an 
upstream or downstream job.

I have two jobs that at one point, were misconfigured.  Now one always 
triggers the other.

Is there a way to clip this configuration?  I could have sworn that in one 
of the files on the jenkins server it stored that kind of information, but 
I can't see it anymore.

Re: authenticating with certificates & username/password

[Dustin Parker]

This issue (JENKINS-3912) is currently stalling our development effort, 
too. I'm trying a variety of things to work around the issue. The 
frustrating thing is that jsvn from the command line *works*, so the SVN 
plugin is taking this functioning library and *breaking* it somehow.

On Wednesday, July 13, 2011 5:40:50 AM UTC-7, michaelw wrote:
>
> Has this been resolved? Sorry to bring up such an old post but I have the
> same problem.
>
> The scenario is as follows:
>
> 1. SSL is configured on our apache server to require a client certificate -
> right at the front so you can't access any of the content if you don't have
> the client certificate.
> 2. The svn server is thus sitting behind the apache server - we thus use
> https to reach our svn server.
> 3. The svn server then has its own username/password resolution facilities,
> this is to do thing like permissions on svn folders etc.
>
> I can't get Jenkins to checkout my code.
>
> When I select the username/password option I get the following exception
>
> 
>
> Caused by: java.lang.NullPointerException
> at 
> org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:129)
> at 
> org.apache.commons.io.FileUtils.readFileToByteArray(FileUtils.java:1135)
> at
>
> hudson.scm.SubversionSCM$DescriptorImpl$SslClientCertificateCredential.(SubversionSCM.java:1494)
> at
>
> hudson.scm.UserProvidedCredential$AuthenticationManagerImpl.getFirstAuthentication(UserProvidedCredential.java:205)
> at
>
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:319)
> at
>
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:301)
> at
>
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:196)
> at
> sun.security.ssl.AbstractWrapper.chooseClientAlias(SSLContextImpl.java:282)
> at
>
> sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:629)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:546)
> at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913)
> at
>
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158)
> at 
> sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:652)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:78)
> at 
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at 
> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at
>
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.sendData(HTTPConnection.java:229)
> at
>
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:166)
> at
>
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364)
> ... 59 more
>
> Almost as if it is looking for a client certificate file but as one isn't
> set, it cannot find one.
>
> Then if I try the other option - client certificate I get:
>
> Attempting an SSL client certificate authentcation
> Passing user name null and password you entered
> Failed to authenticate: org.tmatesoft.svn.core.SVNErrorMessage: svn: 
> OPTIONS
> of /OldMutual/sandbox/trunk/maven/parent: 401 Authorization Required
> (https://svn.afrozaar.com)
>
> So it looks like it is getting passed the https level but being locked out
> by the svn authentication.
>
> The interesting thing about this scenario is that the log says "Passing
> username null and password you entered" - almost as if if the password was
> set, it would work.
>
> The .subversion config is configured correctly - so I'm not sure if it is
> reading this.
>
> --
> View this message in context: 
> http://jenkins.361315.n4.nabble.com/authenticating-with-certificates-username-password-tp373150p3664923.html
> Sent from the Jenkins users mailing list archive at Nabble.com.
>
>

Re: LDAP authentication fails

[Roberto Nunnari]

2012/5/2 Roberto Nunnari 

> 2012/5/2 Roberto Nunnari 
>
>> 2012/5/2 Maven User 
>>
>>> What version of the AD plugin are you using?  If you have 1.27
>>> installed, try rolling back to 1.26 (which may be a manual thing at this
>>> point).
>>>
>>
>> I'm using the LDAP thing.. I have also tried the AD plugin (1.26), but it
>> didn't work neither..
>>
>> Is there a way to make it more verbose, so that I can pin out what's
>> wrong?
>>
>
> Maybe I found what's wrong.. it seams that jenkins/acegisecurity searches
> for  uid=username, while in our AD, the username is mapped to cn
> Is there a way to configure jenkins/acegisecurity so that it searches for
> cn=username instead?
> Thanks.
>

YES! That was it! Solved. It was the 'User search filter'.
 Thank you all.

Re: LDAP authentication fails

[Roberto Nunnari]

2012/5/2 Roberto Nunnari 

> 2012/5/2 Maven User 
>
>> What version of the AD plugin are you using?  If you have 1.27 installed,
>> try rolling back to 1.26 (which may be a manual thing at this point).
>>
>
> I'm using the LDAP thing.. I have also tried the AD plugin (1.26), but it
> didn't work neither..
>
> Is there a way to make it more verbose, so that I can pin out what's wrong?
>

Maybe I found what's wrong.. it seams that jenkins/acegisecurity searches
for  uid=username, while in our AD, the username is mapped to cn
Is there a way to configure jenkins/acegisecurity so that it searches for
cn=username instead?
Thanks.

Re: LDAP authentication fails

[Roberto Nunnari]

2012/5/2 Maven User 

> What version of the AD plugin are you using?  If you have 1.27 installed,
> try rolling back to 1.26 (which may be a manual thing at this point).
>

I'm using the LDAP thing.. I have also tried the AD plugin (1.26), but it
didn't work neither..

Is there a way to make it more verbose, so that I can pin out what's wrong?

Dependency Graph View plugin issues

[Dan Stine]

Thank you for this plugin.  I installed it, and have installed
graphviz.  But I am only seeing some of the expected features.  I am
using Jenkins 1.448 and Dependency Graph View version 0.2.

I have one set of related jobs in View A.  These jobs each have a
Dependency Graph link on the left-hand nav bar, and the link renders a
nice graph.  (Each job has upstream and downstream jobs listed in the
landing page as appropriate.)

I have other sets of related jobs in Views B and C.  These jobs do NOT
have a Dependency Graph link on the left-hand nav bar.  (Each job does
have upstream and downstream jobs listed in the landing page as
appropriate.)  If I force browse to 
http://[jenkins]/view/B/job/Foo/depgraph-view/?
I get a 404 Error page with no exception or stack trace information,
and I can find no information in the Jenkins log.

I also do not see a Dependency Graph link at the top-level, as
depicted in the screenshot on the plugin wiki page.

Any thoughts?

Thanks,
Dan

Re: Error running groovysh via jenkins-cli due to anonymous missing the Administrator permission

[Carlton Brown]

Thanks for the explanation, I will try that.

On Wed, May 2, 2012 at 3:44 AM, Daniel PETISME wrote:

> The groovysh command seems broken with the jenkins-cli.jar.
> if you use a "recent" version of Jenkins you should use the Jenkins SSH
> server to invoke the groovysh command.
>
> https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH
> http://kohsuke.org/2011/12/27/jenkins-now-acts-as-an-ssh-daemon/
>
> Cheers
> Daniel
>
> Le jeudi 26 avril 2012 17:23:50 UTC+2, Carlton Brown a écrit :
>
>> I wish to use groovysh to interact directly with Jenkins.   Does it work?
>>
>> On Wed, Apr 25, 2012 at 4:58 PM, Daniel PETISME > > wrote:
>>
>>> Hi Carlton,
>>>
>>> Jenkins-cli seems to have some issues concerning authentication.
>>> Groovysh allows you to interact directly with the Jenkins JVM using the
>>> goovy language.
>>>
>>> If you don't need this "interaction" prefer the groovy command as a
>>> possible workaround
>>>
>>>
>>> For instance.
>>>
>>> $ java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ -i
>>>  groovy test_script.gsh
>>> Enter passphrase for :
>>> ant - 1.1
>>> javadoc - 1.0
>>> Jenkins CVS Plug-in - 1.6
>>> Maven Integration plugin - 1.460
>>> Jenkins SSH Slaves plugin - 0.21
>>> Jenkins Subversion Plug-in - 1.34
>>> Jenkins Translation Assistance plugin - 1.8
>>>
>>> and the test_script.gsh is reusing your command "jenkins.model.Jenkins.*
>>> *instance.pluginManager.**plugins.each { println("${it.longName} -
>>> ${it.version}") }"
>>>
>>> I try to add more details concerning jenkins-cli.jar tool: Jenkins CLI
>>> in Dev 
>>> ML
>>>
>>> To skip the step of the creation of a groovy script file for each
>>> command, the usage talks about a pramater "=" to write the command in stdin.
>>>
>>> Cheers
>>>
>>> Daniel
>>>
>>>
>>> On Wednesday, April 25, 2012 4:27:14 PM UTC+2, Carlton Brown wrote:

 Steps to reproduce:
 1:  set up an SSH key under my username
 2:  verified that I am authenticated:  java -jar jenkins-cli.jar -s
 http://myserver/jenkins  **wh**o-am-i
  Authenticated as: myuser
 Authorities:
 authenticated
 3:  tried to run a trivial script via groovysh and got an error
   java -jar jenkins-cli.jar -s 
 http://myserver/jenkins
  **gro**ovysh 
 'jenkins.model.Jenkins.**instanc**e.pluginManager.**plugins.each
 { println("${it.longName} - ${it.version}") };'
 Exception in thread "main" java.lang.reflect.**UndeclaredTh**
 rowableException
 at $Proxy2.main(Unknown Source)
 at hudson.cli.CLI.execute(CLI.**jav**a:271)
  at hudson.cli.CLI._main(CLI.java:417)
 at hudson.cli.CLI.main(CLI.java:**3**22)
 Caused by: hudson.remoting.**ProxyException**: hudson.security.**
 AccessDeniedEx**ception2: anonymous is missing the Administer
 permission
  at hudson.security.ACL.**checkPermi**ssion(ACL.java:53)
 at hudson.model.Node.**checkPermiss**ion(Node.java:381)
  at hudson.cli.GroovyshCommand.**mai**n(GroovyshCommand.java:61)
  at hudson.cli.CliManagerImpl.**main**(CliManagerImpl.java:92)
 at sun.reflect.**GeneratedMethodAcc**essor5352.**invoke(Unknown Source)
  at sun.reflect.**DelegatingMethodAc**cessorImpl.**invoke(**
 DelegatingMe**thodAccessorImpl.**java:43)
 at java.lang.reflect.Method.**invok**e(Method.java:601)
  at hudson.remoting.**RemoteInvocati**onHandler$**RPCRequest.perform(**
 R**emoteInvocationHandler.java:**27**4)
 at hudson.remoting.**RemoteInvocati**onHandler$**RPCRequest.call(**Remo
 **teInvocationHandler.java:**255)
  at hudson.remoting.**RemoteInvocati**onHandler$**RPCRequest.call(**
 Remo**teInvocationHandler.java:**215)
 at hudson.remoting.UserRequest.**pe**rform(UserRequest.java:118)
  at hudson.remoting.UserRequest.**pe**rform(UserRequest.java:48)
 at hudson.remoting.Request$2.run(Request.java:287)
  at hudson.remoting.**InterceptingEx**ecutorService$1.**call(**
 Intercept**ingExecutorService.**java:72)
 at hudson.cli.CliManagerImpl$1.**ca**ll(CliManagerImpl.java:63)
  at hudson.remoting.**InterceptingEx**ecutorService$2.**call(**
 Intercept**ingExecutorService.**java:95)
 at java.util.concurrent.**FutureTas**k$Sync.innerRun(**FutureTask.**
 java:334)
  at java.util.concurrent.**FutureTas**k.run(FutureTask.**java:166)
 at java.util.concurrent.**ThreadPoo**lExecutor.runWorker(**ThreadPool**
 Executor.java:1110)
  at java.util.concurrent.**ThreadPoo**lExecutor$Worker.run(**ThreadPoo*
 *lExecutor.java:603)

>>>
>>

Static Analysis of Unix Shell Scripts

[Nig]

Hi,
Does anyone know if there are any static analysis tools for Unix shell
scripts (e.g. sh, ksh) ?
Thanks !

Re: LDAP authentication fails

[Maven User]

What version of the AD plugin are you using?  If you have 1.27 installed, 
try rolling back to 1.26 (which may be a manual thing at this point).

Re: LDAP authentication fails

[Roberto Nunnari]

humm.. I deleted identity.key and secret.key, restarted jenkins, and tried
again: the two files have been recreated, but got the same error!

Any more hints, please?



2012/5/2 Jan Seidel 

> Hi Nunni,
>
> *uhm* only thing that crosses my mind is a buggy identity.key file or
> secret.key file. The secret.key is more likely to fail.
> You can rebuild it somewhat easy. simply delete the secret.key files. They
> are located in the jenkins root folder and in the job folders.
> They contain the encryption key to garble/ungarble the credentials you
> have saved in Jenkins. Only garbage will be send as response if this key
> file is out of sync with Jenkins.
>
> You will have to re-enter passwords in your configuration as the will
> definitely become unvalid when the key file is missing.
> So lucky you if the credentials for your repository and the like are
> stored globally in "Manage Jenkins" and not individually by job. Good time
> to change it if the later case just comes back on you ;)
>
>
> Am Mittwoch, 2. Mai 2012 11:11:04 UTC+2 schrieb Nunni:
>
>> Hi Jan.
>> Sorry for not replying earlier.. I was on holiday and got back to work
>> only this morning.
>>
>> No.. no special characters that need to be escaped, nor wrong password..
>> I even tried copy/paste of the password, but it doesn't help..
>>
>> Any more hints, please?
>>
>>
>> 2012/4/30 Jan Seidel 
>>
>>>
>>> Hi Nunni,
>>>
>>> org.acegisecurity.**BadCredentialsException: Bad credentials  tells you
>>> at least that something is happening and then fails. This looks more like a
>>> matter of human engineering rather the technical engineering ;)
>>> Do you use some funny special character which may interfere with your
>>> system/shell/CLI. You will then have to escape the characters in question
>>> or evene better select a passwort less prone to error.
>>>
>>> @David: "By the way, what are you doing with the command line? Jenkins
>>> is a purely web-based application, and the configuration is carried out via
>>> the webpage." ???
>>> How did tell you that? The web based part is just a convenience thingy.
>>>
>>> You can run it from command line without webfront. I do more and more
>>> rarely use the webfront and run the administrative task straight from the
>>> operating systems CLI
>>> Further does Jenkins also provide it's own CLI (see:
>>> http://jenkins_server/cli)
>>>
>>> Take care
>>> Jan
>>>
>>>
>>

Re: CVS and extssh

[Tim Pizey]

There seem to be some relevant instructions here:

http://www-d0.fnal.gov/software/cmgt/cvs_ssh.html

you need to have an environment variable
CVS_RSH set to your ssh executable.

my guess.
Tim


On 2 May 2012 14:04, Xavier NOPRE  wrote:
> Hi Vincent,
>
> Thank you for your quick answer.
>
> So, I have tried with "ext", just replacing "extssh" with "ext" in my CVS
> URL, and I have another error. Sorry, it's in french, but the error seems to
> be with a RSH command. In the console, I can see like the help of RSH
> command and the this error : cvs [checkout aborted]: end of file from server
> (consult above messages if any)
>
> Thanks,
>
> Xavier
>
>
>
>
> 2012/5/2 HARDION Vincent 
>>
>> Hi Xavier,
>>
>> The "extssh" tag exists only for eclipse.
>> The real type of connection for cvs is "ext".
>>
>> Best regards,
>>
>> Vincent
>> 
>> From: jenkinsci-users@googlegroups.com [jenkinsci-users@googlegroups.com]
>> on behalf of Xavier NOPRE [xno...@gmail.com]
>> Sent: Wednesday, May 02, 2012 2:41 PM
>> To: jenkinsci-users@googlegroups.com
>> Subject: CVS and extssh
>>
>> Hi,
>>
>> I've just installed the last version of Jenkins. I have created a first
>> job for a Maven project. But my problem is with CVS. In Eclipse, my CVS URL
>> is with ":extssh:" prefix. But with Jenkins, I have this error : "cvs
>> checkout: Unknown method (`extssh') in CVSROOT.".
>>
>> My server OS is Windows. I have installed cvs.exe in c:\windows.
>>
>> How can I solve this problem ? Do I have to install some CVS extension for
>> the extssh support ?
>>
>> Thanks,
>>
>> Xavier
>>
>



-- 
Tim Pizey - http://pizey.net/~timp

Re: CVS and extssh

[Xavier NOPRE]

Hi Vincent,

Thank you for your quick answer.

So, I have tried with "ext", just replacing "extssh" with "ext" in my CVS
URL, and I have another error. Sorry, it's in french, but the error seems
to be with a RSH command. In the console, I can see like the help of RSH
command and the this error : cvs [checkout aborted]: end of file from
server (consult above messages if any)

Thanks,

Xavier



2012/5/2 HARDION Vincent 

> Hi Xavier,
>
> The "extssh" tag exists only for eclipse.
> The real type of connection for cvs is "ext".
>
> Best regards,
>
> Vincent
> 
> From: jenkinsci-users@googlegroups.com [jenkinsci-users@googlegroups.com]
> on behalf of Xavier NOPRE [xno...@gmail.com]
> Sent: Wednesday, May 02, 2012 2:41 PM
> To: jenkinsci-users@googlegroups.com
> Subject: CVS and extssh
>
> Hi,
>
> I've just installed the last version of Jenkins. I have created a first
> job for a Maven project. But my problem is with CVS. In Eclipse, my CVS URL
> is with ":extssh:" prefix. But with Jenkins, I have this error : "cvs
> checkout: Unknown method (`extssh') in CVSROOT.".
>
> My server OS is Windows. I have installed cvs.exe in c:\windows.
>
> How can I solve this problem ? Do I have to install some CVS extension for
> the extssh support ?
>
> Thanks,
>
> Xavier
>
>

RE: CVS and extssh

[HARDION Vincent]

Hi Xavier,

The "extssh" tag exists only for eclipse.
The real type of connection for cvs is "ext".

Best regards,

Vincent

From: jenkinsci-users@googlegroups.com [jenkinsci-users@googlegroups.com] on 
behalf of Xavier NOPRE [xno...@gmail.com]
Sent: Wednesday, May 02, 2012 2:41 PM
To: jenkinsci-users@googlegroups.com
Subject: CVS and extssh

Hi,

I've just installed the last version of Jenkins. I have created a first job for 
a Maven project. But my problem is with CVS. In Eclipse, my CVS URL is with 
":extssh:" prefix. But with Jenkins, I have this error : "cvs checkout: Unknown 
method (`extssh') in CVSROOT.".

My server OS is Windows. I have installed cvs.exe in c:\windows.

How can I solve this problem ? Do I have to install some CVS extension for the 
extssh support ?

Thanks,

Xavier

CVS and extssh

[Xavier NOPRE]

Hi,

I've just installed the last version of Jenkins. I have created a first job
for a Maven project. But my problem is with CVS. In Eclipse, my CVS URL is
with ":extssh:" prefix. But with Jenkins, I have this error : "cvs
checkout: Unknown method (`extssh') in CVSROOT.".

My server OS is Windows. I have installed cvs.exe in c:\windows.

How can I solve this problem ? Do I have to install some CVS extension for
the extssh support ?

Thanks,

Xavier

CLI Authentication using Unix Users

[Anshul]

Hi,
One of my Jenkins job actually creates a new job using the cli
interface. The creator job (and all other jobs by default) require
authentication to build.

The creator job calls the jenkins cli to create the new job but it
doesn't make use of the information that a logged in user is actually
running the job and the build fails citing authentication issue for
user anonymous. How can I make sure the cli gets the required
credentials?

Jenkins Version: 1.446

I am using Project Matrix Based Authentication for all the activities
on my Jenkins installation and ideally want to keep any build/create/
delete actions restricted to the logged in users. The users are the
unix users.

Thanks,
Anshul

Re: Gzipped build log

[Jan Seidel]

Hi David,

opening an issue seems to be a good idea.
I have this issue always when the log file is chunked. As soon as I say 
view all is everything fine.
I wouldn't mind if it just are a few garbled signs as is often is but is 
pretty annoying when the log becomes 4-8 times as broad only with an white 
area.

The mentioned issues do not fit in here imho.

take care
Jan

Am Montag, 30. April 2012 14:37:03 UTC+2 schrieb David Mata:
>
> Hello. 
>
> I've seen the ability of inspecting compressed by gzip logs. Lines are 
> not well displayed in the console 
>
> Shows 
> ha:kh+LCABb85aBtbiIQSajNKU4P08vOT+vOD8nVc 
> +jsiC1KCczL9svvyT1dMUiOWdZ/mImBiZPBrac1Lz0kgwfBubSopwSBiGfrMSyRP2cxLx0/ 
> eCSosy8dOuKIgYpNOOcITTIMAYIYGRiYKgoADJ4gGbolxanFuknJyelpJal5pTk5+cAAKxNYUeXccbdeveltool
>  
>
> Building on master in workspace 
>
> instead of 
> Started by user ccbdeveltool 
> Building on master in workspace 
>
> I mean, the html is not well uncoded when log is gz. 
>
> Do you know the reason? Maybe I must open an issue. 
>
>

Maven installs and SNAPSHOT deploys

[Tim Pizey]

Hi,

for my  Maven projects I have been running a single job to install and deploy.
I run this job both upon scm change and periodically (as the OS is
updated in step with Ubuntu).

This works very nicely, but fills a 15G partition pretty quickly.

I would really prefer to run two jobs:
- a maven install periodically
- a maven deploy on SCM change

what is the best way of doing this?

cheers
Tim


-- 
Tim Pizey - http://pizey.net/~timp

Re: Pre-Checkout actions?

[Jan Seidel]

pre-scm-buildstep plugin? YAY!
Never heard of that nor seen it before but you have just made my life 
pretty much easier :)

Thanks Chris!

Take care
Jan

Am Montag, 30. April 2012 14:55:16 UTC+2 schrieb cjo:
>
>
> If you just want to remove the junction points between triggering a build 
> and the checkout from SCM, 
> You can use the pre-scm-buildstep plugin[1] which allows you to run most 
> build steps at this point, including windows batch scripts.
>
>
> You could also use the post-build step, which should always run regardless 
> of the result of the build,
> for more freedom at this point consider using the flexible publish plugin 
> (use the always condition) and anybuildstep plugins to allow buildsteps to 
> be run at this point.
>
> [1] https://wiki.jenkins-ci.org/display/JENKINS/pre-scm-buildstep
> [2] https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task
> [3] https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin
> [4] https://wiki.jenkins-ci.org/display/JENKINS/Any+Build+Step+Plugin
>
> Chris
>
>

Re: LDAP authentication fails

[Jan Seidel]

Hi Nunni,

*uhm* only thing that crosses my mind is a buggy identity.key file or 
secret.key file. The secret.key is more likely to fail.
You can rebuild it somewhat easy. simply delete the secret.key files. They 
are located in the jenkins root folder and in the job folders. 
They contain the encryption key to garble/ungarble the credentials you have 
saved in Jenkins. Only garbage will be send as response if this key file is 
out of sync with Jenkins.

You will have to re-enter passwords in your configuration as the will 
definitely become unvalid when the key file is missing.
So lucky you if the credentials for your repository and the like are stored 
globally in "Manage Jenkins" and not individually by job. Good time to 
change it if the later case just comes back on you ;)


Am Mittwoch, 2. Mai 2012 11:11:04 UTC+2 schrieb Nunni:
>
> Hi Jan.
> Sorry for not replying earlier.. I was on holiday and got back to work 
> only this morning.
>
> No.. no special characters that need to be escaped, nor wrong password.. I 
> even tried copy/paste of the password, but it doesn't help..
>
> Any more hints, please?
>
>
> 2012/4/30 Jan Seidel 
>
>>
>> Hi Nunni,
>>
>> org.acegisecurity.BadCredentialsException: Bad credentials  tells you at 
>> least that something is happening and then fails. This looks more like a 
>> matter of human engineering rather the technical engineering ;)
>> Do you use some funny special character which may interfere with your 
>> system/shell/CLI. You will then have to escape the characters in question 
>> or evene better select a passwort less prone to error. 
>>
>> @David: "By the way, what are you doing with the command line? Jenkins is 
>> a purely web-based application, and the configuration is carried out via 
>> the webpage." ???
>> How did tell you that? The web based part is just a convenience thingy. 
>>
>> You can run it from command line without webfront. I do more and more 
>> rarely use the webfront and run the administrative task straight from the 
>> operating systems CLI
>> Further does Jenkins also provide it's own CLI (see: 
>> http://jenkins_server/cli)
>>
>> Take care
>> Jan
>>
>>
>

Re: LDAP authentication fails

[Roberto Nunnari]

Hi Jan.
Sorry for not replying earlier.. I was on holiday and got back to work only
this morning.

No.. no special characters that need to be escaped, nor wrong password.. I
even tried copy/paste of the password, but it doesn't help..

Any more hints, please?


2012/4/30 Jan Seidel 

>
> Hi Nunni,
>
> org.acegisecurity.BadCredentialsException: Bad credentials  tells you at
> least that something is happening and then fails. This looks more like a
> matter of human engineering rather the technical engineering ;)
> Do you use some funny special character which may interfere with your
> system/shell/CLI. You will then have to escape the characters in question
> or evene better select a passwort less prone to error.
>
> @David: "By the way, what are you doing with the command line? Jenkins is
> a purely web-based application, and the configuration is carried out via
> the webpage." ???
> How did tell you that? The web based part is just a convenience thingy.
>
> You can run it from command line without webfront. I do more and more
> rarely use the webfront and run the administrative task straight from the
> operating systems CLI
> Further does Jenkins also provide it's own CLI (see:
> http://jenkins_server/cli)
>
> Take care
> Jan
>
>

Re: Error running groovysh via jenkins-cli due to anonymous missing the Administrator permission

[Daniel PETISME]

The groovysh command seems broken with the jenkins-cli.jar.
if you use a "recent" version of Jenkins you should use the Jenkins SSH 
server to invoke the groovysh command. 

https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+SSH
http://kohsuke.org/2011/12/27/jenkins-now-acts-as-an-ssh-daemon/

Cheers
Daniel

Le jeudi 26 avril 2012 17:23:50 UTC+2, Carlton Brown a écrit :
>
> I wish to use groovysh to interact directly with Jenkins.   Does it work?
>
> On Wed, Apr 25, 2012 at 4:58 PM, Daniel PETISME 
> wrote:
>
>> Hi Carlton, 
>>
>> Jenkins-cli seems to have some issues concerning authentication. Groovysh 
>> allows you to interact directly with the Jenkins JVM using the goovy 
>> language.
>>
>> If you don't need this "interaction" prefer the groovy command as a 
>> possible workaround
>>
>>
>> For instance.
>>
>> $ java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ -i 
>>  groovy test_script.gsh
>> Enter passphrase for :
>> ant - 1.1
>> javadoc - 1.0
>> Jenkins CVS Plug-in - 1.6
>> Maven Integration plugin - 1.460
>> Jenkins SSH Slaves plugin - 0.21
>> Jenkins Subversion Plug-in - 1.34
>> Jenkins Translation Assistance plugin - 1.8
>>
>> and the test_script.gsh is reusing your command 
>> "jenkins.model.Jenkins.instance.pluginManager.plugins.each { 
>> println("${it.longName} - ${it.version}") }"
>>
>> I try to add more details concerning jenkins-cli.jar tool: Jenkins CLI 
>> in Dev 
>> ML
>>
>> To skip the step of the creation of a groovy script file for each 
>> command, the usage talks about a pramater "=" to write the command in stdin.
>>
>> Cheers
>>
>> Daniel
>>
>>
>> On Wednesday, April 25, 2012 4:27:14 PM UTC+2, Carlton Brown wrote:
>>>
>>> Steps to reproduce:
>>> 1:  set up an SSH key under my username 
>>> 2:  verified that I am authenticated:  java -jar jenkins-cli.jar -s 
>>> http://myserver/jenkins  **who-am-i
>>>  Authenticated as: myuser
>>> Authorities:
>>> authenticated
>>> 3:  tried to run a trivial script via groovysh and got an error
>>>   java -jar jenkins-cli.jar -s 
>>> http://myserver/jenkins
>>>  **groovysh 'jenkins.model.Jenkins.**instance.pluginManager.**plugins.each 
>>> { println("${it.longName} - ${it.version}") };'
>>> Exception in thread "main" java.lang.reflect.**
>>> UndeclaredThrowableException
>>> at $Proxy2.main(Unknown Source)
>>> at hudson.cli.CLI.execute(CLI.**java:271)
>>>  at hudson.cli.CLI._main(CLI.java:**417)
>>> at hudson.cli.CLI.main(CLI.java:**322)
>>> Caused by: hudson.remoting.**ProxyException: 
>>> hudson.security.**AccessDeniedException2: 
>>> anonymous is missing the Administer permission
>>>  at hudson.security.ACL.**checkPermission(ACL.java:53)
>>> at hudson.model.Node.**checkPermission(Node.java:381)
>>>  at hudson.cli.GroovyshCommand.**main(GroovyshCommand.java:61)
>>>  at hudson.cli.CliManagerImpl.**main(CliManagerImpl.java:92)
>>> at sun.reflect.**GeneratedMethodAccessor5352.**invoke(Unknown Source)
>>>  at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
>>> DelegatingMethodAccessorImpl.**java:43)
>>> at java.lang.reflect.Method.**invoke(Method.java:601)
>>>  at hudson.remoting.**RemoteInvocationHandler$**RPCRequest.perform(**
>>> RemoteInvocationHandler.java:**274)
>>> at hudson.remoting.**RemoteInvocationHandler$**RPCRequest.call(**
>>> RemoteInvocationHandler.java:**255)
>>>  at hudson.remoting.**RemoteInvocationHandler$**RPCRequest.call(**
>>> RemoteInvocationHandler.java:**215)
>>> at hudson.remoting.UserRequest.**perform(UserRequest.java:118)
>>>  at hudson.remoting.UserRequest.**perform(UserRequest.java:48)
>>> at hudson.remoting.Request$2.run(**Request.java:287)
>>>  at hudson.remoting.**InterceptingExecutorService$1.**call(**
>>> InterceptingExecutorService.**java:72)
>>> at hudson.cli.CliManagerImpl$1.**call(CliManagerImpl.java:63)
>>>  at hudson.remoting.**InterceptingExecutorService$2.**call(**
>>> InterceptingExecutorService.**java:95)
>>> at java.util.concurrent.**FutureTask$Sync.innerRun(**
>>> FutureTask.java:334)
>>>  at java.util.concurrent.**FutureTask.run(FutureTask.**java:166)
>>> at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>>> ThreadPoolExecutor.java:1110)
>>>  at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>>> ThreadPoolExecutor.java:603)
>>>
>>
>