Category Archives: tomcat

SvnKit E170001: Negotiate authentication failed: ‘No valid credentials provided’

In a new project, attempts to programmatically access our Subversion server using SvnKit fails with an E170001 error. But, only on one Windows 7 workstation.

After a lot of searching on web for answers finally found something that helped. I had to add system property: svnkit.http.methods=Basic,Digest,Negotiate,NTLM

So, using SvnCli, which I used to debug this, you add the property using the “-D” switch to the command line.

java -Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM -cp "SvnCli\*" org.tmatesoft.svn.cli.SVN --username *** --password *** list

I also had to add this property to the Tomcat app server.

Solution?
While this does fix the problem in this instance, since only one workstation is effected, it is probably hiding an underlying configuration setup issue.

I wonder what percentage of the nation’s GDP is spent on configuration and its issues.

Original stacktrace:

Mar 18, 2015 11:40:31 AM org.tmatesoft.svn.core.internal.util.DefaultSVNDebugLogger log
SEVERE: CLI: svn: E170001: Negotiate authentication failed: 'No valid credentials provided'
org.tmatesoft.svn.core.SVNException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided'
        at org.tmatesoft.svn.cli.AbstractSVNCommandEnvironment.handleWarning(AbstractSVNCommandEnvironment.java:401)
        at org.tmatesoft.svn.cli.svn.SVNListCommand.run(SVNListCommand.java:95)
        at org.tmatesoft.svn.cli.AbstractSVNCommandEnvironment.run(AbstractSVNCommandEnvironment.java:142)
        at org.tmatesoft.svn.cli.AbstractSVNLauncher.run(AbstractSVNLauncher.java:79)
        at org.tmatesoft.svn.cli.svn.SVN.main(SVN.java:26)
        at org.tmatesoft.svn.cli.SVN.main(SVN.java:22)
svn: E170001: Negotiate authentication failed: 'No valid credentials provided'

Environment

  • Java 1.7
  • SvnKit 1.8.8
  • Tomcat 7

Links

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Jenkins CI Server is great

Finally got a Jenkins server installed. Had a host of system issues, like communicating to our source code repo.

Jenkins is a joy to use. Well, it is not perfect, what is? Like, I need to pass the user’s name that invoked a build via Jenkins to the target DOS script (yea, Windows) that eventually invokes the legacy Ant scripts. A quick Google search shows that this is asked in various ways, but no answers. For example, here or here. Hmmmm.

Anyway, now comes a trial use, to see if it is what we really need and can we manage it to do what we will want. With 400 plugins, I don’t see how it could lack. Plus, I’m sure I can use the Groovy plugin to cobble something up. Jenkins even includes a Groovy Console. Finally, there is a road map for possible migration of legacy Ant scripts to Gradle using the Gradle Plugin.

I take back my past snarky comment. Jenkins is not just a pretty face on Cron.

Off Topic
Was watching the Easyb intro video. BDD is interesting. Definitely “should” is a better then “test”. With so many great tools why are products still bug ridden?

Enterprise Level CI Server?
I was told that QuickBuild is better for corporate use.

Wikis and the home link
BTW, is there some Wiki law that says a wiki shall never ever have a link to the parent project? If you get tossed into a wiki by following a link, invariably you will click in agony at links that should go to the real home. Instead, you have to edit the URL in the address bar. Since I never curse, I can’t write “wtf”.

More stuff

  1. Jenkins home page
  2. QuickBuild

  3. Continuous integration Not a very good Wikipedia article
  4. Continuous Integration Much better
  5. Continuous Integration in Agile Software Development
  6. Hooking into the Jenkins(Hudson) API
  7. Five Cool Things You Can Do With Groovy Scripts
  8. Parameterized Builds in Jenkins – choosing subversion folders
  9. Groovy Console
  10. Groovy plugin
  11. Switching to Jenkins–Download and Install Artifact Script for Tester
  12. Gradle Plugin
Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Tomcat 7 change ROOT application

The default application of a fresh install of Tomcat 7 is ROOT. You want to remove it and use your own?

I’m running a supported Tomcat instance and it’s trial period ended. I’ll just stick with plain old Tomcat. Perhaps for a business, the enhanced Tomcat (only change is a better management console?) would make more sense. For personal use I just installed version 7. Maybe they improved the setup experience. I gave up trying to change the default web app from ROOT to my own “home”.

Nope, still makes no sense. You’d think there would be a FAQ or something on this. The kludge way is to just put your app into ROOT. Yuck. Well, its possible and easy. I found the hint here, in one of the comments.. Thanks Joe!

The trick is that you have to add a context configuration for the default web app AND you CAN’T do this with an external context file, ROOT.xml. It won’t work. Instead, add this context to the Host node in the server.xml file.

Example snippet from my conf/server.xml:

      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">

        <!-- SingleSignOn valve, share authentication between web applications
             Documentation at: /docs/config/valve.html -->
        <!--
        <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
        -->

        <!-- Access log processes all example.
             Documentation at: /docs/config/valve.html
             Note: The pattern used is equivalent to using pattern="common" -->
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"  
               prefix="localhost_access_log." suffix=".txt"
  
             pattern="%h %l %u %t &amp;quot;%r&amp;quot; %s %b" resolveHosts="false"/>
			 
			 
			 
		<Context path="" docBase="home">

			<!-- Default set of monitored resources -->
			<WatchedResource>WEB-INF/web.xml</WatchedResource>

			<!-- Uncomment this to disable session persistence across Tomcat restarts -->
			<!--
			<Manager pathname="" />
			-->

			<!-- Uncomment this to enable Comet connection tacking (provides events
				 on session expiration as well as webapp lifecycle) -->
			<!--
			<Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
			-->

		</Context>	 

      </Host>

The diff is:

136a137,156
>               <Context path="" docBase="home">
>                       <!-- Default set of monitored resources -->
>                       <WatchedResource>WEB-INF/web.xml</WatchedResource>
>
>                       <!-- Uncomment this to disable session persistence across Tomcat restarts -->
>                       <!--
>                       <Manager pathname="" />
>                       -->
>                       <!-- Uncomment this to enable Comet connection tacking (provides events
>                                on session expiration as well as webapp lifecycle) -->
>                       <!--
>                       <Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
>                       -->
>
>               </Context>

I hope this helps.

Note, before doing the above, please verify that this information is correct. Perhaps everyone is reading the Tomcat docs incorrectly or there really is a configuration discrepancy.

Updates
12Feb2011: Funny, if you make the above change and still leave the ROOT application folder in the webapps folder, you can not open the original ROOT at http://host:port/ROOT, even if you add another context node in host. I guess I still don’t grok Tomcat config.

Links


Ralph Towner — Green and Golden

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.