Hudson 2.1.2 + Subversion 1.6 + behind proxy: "build" doesnt pick credentials

[Javy]

Hi..

Posting here after going through similar questions and suggested
solutions ( which did not seem to work in my case ).

Summary of my problem:
- Running Hudson as Windows service ( Hudson 2.1.2, Windows 7
Professional )
- While creating Job, I specify Subversion as the code source
--- After specifying the URL, the red text "update credentials"
appear
--- clicking that takes me to the same URL as does
http://<host>/scm/SubversionScm/enterCredential page
--- I enter the username/password, and it says "successfully
authenicated...hudson will now store this information.."
----- Note that I had entered the http-proxy-host and http-proxy-port
details under the hudson\.subversion\servers file, and only then it
was successfully able to authenticate here.
- After filing in the rest of the details required for the Job to be
created, I click save and then trigger a "build now"
- Seems Hudson dint pick the stored ( successful ) configuration,
because it fails as below:
Mar 15, 2012 2:57:46 PM hudson.scm.SubversionSCM$DescriptorImpl
doCheckRemote
INFO: Failed to access subversion repository https://xxx.yyy.com/path1/path2/
org.tmatesoft.svn.core.SVNException: svn: connection refused by the
server
svn: OPTIONS request failed on '/rg0101/hpn-netmgmt/branches/cpe/
04.00.xx'
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:
106)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:
90)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
629)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
275)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
263)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:
516)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:
98)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:
1001)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:
97)
at hudson.scm.SubversionSCM
$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1948)
at hudson.scm.SubversionSCM
$DescriptorImpl.doCheckRemote(SubversionSCM.java:1879)
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 org.kohsuke.stapler.Function
$InstanceFunction.invoke(Function.java:282)


--- Solutions tried already:
------ Installed SVN client and did interaction with the repsository,
so that authetication data is saved locally
------ restart hudson after specifying the credentials and before
starting job
------ reload hudson configurations
------ downgrading hudson jar version.

Can somone help please : tried out various solutions already posted in
the forums but none seem to work
Would really appreciate and owe GREAT Thanks if someone can pull me
out of this mess...:|

Thanks
~Ja

[Jan Seidel]

Hiya,

looks like the SCM server does either not know your machine/user or
the authentication method is not supported.
have you tried to access the server via plink and stored the finger
print?
I assume you are using https.
So try this:
- install plink (e.g. from PuTTy)
- open a shell/DOS box
- enter plink -l [username] -i [path_to_private_key (optional)]

This should open a connection to the server and a dialog should pop up
that tells you about an unknown fingerprint and asks you to save it
(select permamently). The server on the other hand should then also
know by then that user/key is valid. Obstracle may be if the user is
new and the server is set up very restrictive. This would eventually
require that an admin manually adds the user/key pair.
If using windows: check for x:\Documents and Settings\[profile_name]
\Application Data\Subversion. Take a look at the files servers and
config.
It can be tricky to apply the credentials in case you are using a
service user. Easiest way would be to access svn with the svn client
and use the credentials of the service user. They should be stored in
the sub-folder auth and copy it to x:\Documents and Settings\
[service_user_name]\Application Data\Subversion.
The problem is that each SVN client uses a different location to store
the credentials. TortoiseSVN uses the registry, the Collabnet client
uses x:\Documents and Settings\[profile_name]\Application Data
\Subversion, Eclipse stores the credentials in [workspace_name]
\.metadata and so on.
You can have two identically installed machines. It works on one, on
the other not. The reason could then be that 2 or more svn clients/
connectors are installed but in different order. the working machine
looks for x:\Documents and Settings\[profile_name]\Application Data
\Subversion the non-working for the registry as Tortoise on the latter
machine was installed after Subversion. This can become a serious
hassle.

I would suggest that you download Systernals ProcMon and trace the
processes to see which location/tool is used to authenticate. this may
be the quickest way if the plink approach does not work.

Good luck
Jan

On 15 Mrz., 11:45, Javy <j...@hp.com> wrote:
> Hi..
>
> Posting here after going through similar questions and suggested
> solutions ( which did not seem to work in my case ).
>
> Summary of my problem:
> - Running Hudson as Windows service ( Hudson 2.1.2, Windows 7
> Professional )
> - While creating Job, I specify Subversion as the code source
> --- After specifying the URL, the red text "update credentials"
> appear
> --- clicking that takes me to the same URL as does
> http://<host>/scm/SubversionScm/enterCredential page
> --- I enter the username/password, and it says "successfully
> authenicated...hudson will now store this information.."
> ----- Note that I had entered the http-proxy-host and http-proxy-port
> details under the hudson\.subversion\servers file, and only then it
> was successfully able to authenticate here.
> - After filing in the rest of the details required for the Job to be
> created, I click save and then trigger a "build now"
> - Seems Hudson dint pick the stored ( successful ) configuration,
> because it fails as below:
> Mar 15, 2012 2:57:46 PM hudson.scm.SubversionSCM$DescriptorImpl
> doCheckRemote

> INFO: Failed to access subversion repositoryhttps://xxx.yyy.com/path1/path2/

[Javy]

Hi Jan Seidel

Thanks a TON.

Your suggestion helped - I used it with combination of other solutions
and finally got over this irritant troubling me from past 2 days.

This is what I did ( just in case someone else falls into same trap
and figuring out how to get out :)
Uninstalled Hudson and erased all registery entries ( through
cleanup )
1) Installed Tortoise SVN ( it also installs the command line tools )
2) Tried a simple checkout from the SVN repository using the command
line
svn checkout https://xxx.x.x.x./deepfolderpath/ .
( choose folder having like 1 or two files )
3) It prompted for accepting certificate permanently ( since
connecting first time ) and asked to provide the
logged-in windows account password, SVN account username/password
4) Once the checkout from commandline was successful, installed Hudson
2.1.2 afresh and installed it as service
5) Setup configuration and specified SVN repository -- and restarted
hudson

...and BINGO...hudson was successfully able to take the credentials as
part of build process.

SO PROBLEM SOLVED!.

Thanks again for your time on this - its amazing how you could make
impact on others by lending such helping hand!

Thanks jan again!

> > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.ja­va:
> > 106)
> >         at
> > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.ja­va:
> > 90)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn­ection.java:
> > 629)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn­ection.java:
> > 275)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn­ection.java:
> > 263)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(D­AVConnection.java:
> > 516)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.jav­a:
> > 98)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepo­sitory.java:
> > 1001)
> >         at
> > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepo­sitory.java:

> > 97)
> >         at hudson.scm.SubversionSCM
> > $DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1948)
> >         at hudson.scm.SubversionSCM
> > $DescriptorImpl.doCheckRemote(SubversionSCM.java:1879)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >         at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> > 39)
> >         at

> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp­l.java:

> > 25)
> >         at java.lang.reflect.Method.invoke(Method.java:597)
> >         at org.kohsuke.stapler.Function
> > $InstanceFunction.invoke(Function.java:282)
>
> >  --- Solutions tried already:
> >  ------ Installed SVN client and did interaction with the repsository,
> > so that authetication data is saved locally
> > ------ restart hudson after specifying the credentials and before
> > starting job
> > ------ reload hudson configurations
> > ------ downgrading hudson jar version.
>
> > Can somone help please : tried out various solutions already posted in
> > the forums but none seem to work
> > Would really appreciate and owe GREAT Thanks if someone can pull me
> > out of this mess...:|
>
> > Thanks

> > ~Ja- Hide quoted text -
>
> - Show quoted text -

[Jan Seidel]

You're welcome :)

I have been face-palming and whacking my head into the desk for
several hours to crack this issue.
Some few hours more went through the sandglass as I had an idea what
was going on, traced it with procmon and then fixed it.
That is a cookie nobody wants to eat ;)