I installed Jenkins 2.46.2 on Windows Server 2012 and integrated it with GitBucket.
I am trying the trigger the build when a change is pushed to GitBucket.
I tried to add a webhook but I get this error:
Error 403 No valid crumb was included in the request
HTTP ERROR 403 Problem accessing
/jenkins/gitbucket-webhook/. Reason: No valid crumb was included
in the requestPowered by
Jetty://
This worked for me:
obtain crumb
$ wget -q --auth-no-challenge --user yourUserName --password yourPassword--output-document - 'http://myJenkins:8080/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'
Now Run Jenkins Job
$ curl -I -X POST http://yourUserName:yourPassword#myJenkins:8080/job/JOBName/build -H "Jenkins-Crumb:44e7038af70da95a47403c3bed5q10f8"
HTTP/1.1 201 Created Date: Fri, 28 July 2017 09:15:45 GMT X-Content-Type-Options: nosniff Location: http://myJenkins:8080/queue/item/17/ Content-Length: 0
For me the problem was that I left the jenkins window unattended for some time. Once I navigated to the jenkins root I was prompted to sign in again and was able to configure the job with git. I also enabled AUTO REFRESH in jenkins which will likely prevent this in the future.
Related
I'm trying to use WebUpd8 team's oracle-java8-installer to install Java 8 on my Ubuntu 14.04 computers. Some of them could succeed but others failed. After some debugging, I realized it was caused by the HTTP proxy setting. I'll provide more details below, but basically my questions are: Why does the use of http_proxy cause the problem? I believe it's must be related to how an HTTP proxy works, but since I have little experience in that, could someone tell me what knowledge I should learn to understand this issue?
Here are more details.
Under the hood, the oracle-java8-installer uses wget to download the jdk-8u181 package. So I can reproduce the issue with the steps below:
Install apt-cacher-ng: sudo apt-get install apt-cacher-ng
You don't have to configure anything in the APT configuration to reproduce this problem. apt-cacher-ng uses localhost:3142 by default to cache the packages.
Run http_proxy="http://localhost:3142" wget --continue --no-check-certificate -O jdk-8u181-linux-x64.tar.gz --header "Cookie: oraclelicense=a" http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
Here are some notes:
The http://localhost:3142 is configured for apt-cacher-ng. Those machines that failed had apt-cacher-ng installed before I tried to install jdk-8u181.
The Cookie: oraclelicense=a is to indicate the user has accepted the license.
If you run the last command, the download of the jdk-8u181-linux-x64.tar.gz is finished instantly. There is a line saying "Proxy request sent, awaiting response... 200 OK". But if you open the received ".tar.gz", you'll see it's merely an HTML page that contains error information.
If you remove the http_proxy environment variable and run:
wget --continue --no-check-certificate -O jdk-8u181-linux-x64.tar.gz --header "Cookie: oraclelicense=a" http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
You will have the full package downloaded correctly.
My best guess is that an HTTP proxy works with wget if the target URL is the final URL, so the proxy would cache it in its storage. Conceptually, it's like a key-value store:
proxy['URL'] = result
However, in this case, the target URL (http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz) actually returns a "302" code and a "Location" header field for the new URL. This can be seen from the output:
ywen#ubuntu:~$ wget --continue --no-check-certificate -O
jdk-8u181-linux-x64.tar.gz --header "Cookie: oraclelicense=a"
http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
--2018-08-01 11:10:04-- http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
Resolving download.oracle.com (download.oracle.com)... 23.32.72.143
Connecting to download.oracle.com
(download.oracle.com)|23.32.72.143|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location:
https://edelivery.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
[following]
--2018-08-01 11:10:04-- https://edelivery.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
Resolving edelivery.oracle.com (edelivery.oracle.com)...
23.216.148.161, 2001:559:19:3081::2d3e, 2001:559:19:3086::2d3e
Connecting to edelivery.oracle.com
(edelivery.oracle.com)|23.216.148.161|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location:
http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz?AuthParam=1533136324_72efc4e6208a5a7fc1cbba0527c741b6
[following]
--2018-08-01 11:10:04-- http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz?AuthParam=1533136324_72efc4e6208a5a7fc1cbba0527c741b6
Connecting to download.oracle.com
(download.oracle.com)|23.32.72.143|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 185646832 (177M) [application/x-gzip]
Saving to: ‘jdk-8u181-linux-x64.tar.gz’
Handling the redirection is out of the capability of a proxy (Am I right??), therefore those machines set with the HTTP proxies failed.
Using Team City 2017.1
I am unable to use Agent Side checkout with my Ubuntu 14.04 build agent due to the following error:
[2017-06-22 13:41:12,779] INFO - jetbrains.buildServer.VCS.P4 - Running p4 login for user myUserId in [P4Port: redacted-server-address:1666; P4User: myUserId; perforce client mapping with 1 rules, VCSRoot: "ETG" {internal id=170}]
[2017-06-22 14:07:38,029] INFO - jetbrains.buildServer.VCS.P4 - Creating P4 workspace TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a
[2017-06-22 14:07:38,225] INFO - jetbrains.buildServer.VCS.P4 - Creating/updating Perforce client specification:
Client: TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a
Owner: myUserId
Description:
Created by TeamCity for user myUserId.
Root: /home/someuser/BuildAgent/work/964e0a7b4154cd8c
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
Host: ubuntu
SubmitOptions: revertunchanged
LineEnd: local
View:
//ETS/GE_DEV/Build/... //TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a/...
[2017-06-22 14:07:38,436] INFO - jetbrains.buildServer.VCS.P4 - Running p4 login for user myUserId in [P4Port: redacted-server-address:1666; P4User: myUserId; perforce client mapping with 1 rules, VCSRoot: "ETG" {internal id=170}]
[2017-06-22 14:07:39,016] WARN - l.patch.AbstractSourcesUpdater - Error while checkout on agent: Perforce password (P4PASSWD) invalid or unset. - while running 'p4 -c TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a -u myUserId -p
redacted-server-address:1666 -H ubuntu client -i'
jetbrains.buildServer.vcs.VcsException: Perforce password (P4PASSWD) invalid or unset. - while running 'p4 -c TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a -u myUserId -p redacted-server-address:1666 -H ubuntu client -i'
at jetbrains.buildServer.vcs.perforce.PerforceConnection.runCommand(PerforceConnection.java:271)
at jetbrains.buildServer.vcs.perforce.PerforceConnection.runCommand(PerforceConnection.java:257)
at jetbrains.buildServer.vcs.perforce.PerforceWorkspacesImpl.createOrUpdateWorkspace(PerforceWorkspacesImpl.java:80)
at jetbrains.buildServer.vcs.perforce.PerforceAgentSourceUpdater.createOrUpdateLocalWorkspace(PerforceAgentSourceUpdater.java:99)
at jetbrains.buildServer.vcs.perforce.PerforceAgentSourceUpdater.updateSources(PerforceAgentSourceUpdater.java:68)
at jetbrains.buildServer.vcs.perforce.PerforceAgentSourceUpdater.updatePerforceSources(PerforceAgentSourceUpdater.java:55)
at jetbrains.buildServer.vcs.perforce.PerforceSourceUpdatePolicy.updateSources(PerforceSourceUpdatePolicy.java:66)
at jetbrains.buildServer.agent.impl.vcs.AgentVcsManagerExImpl$CheckoutSupportImpl.updateSources(AgentVcsManagerExImpl.java:108)
at jetbrains.buildServer.agent.impl.patch.ProjectSourcesOnAgent$1.run(ProjectSourcesOnAgent.java:186)
at java.lang.Thread.run(Thread.java:745)
I am fairly certain our Perforce server uses ticket based auth. At the build machine, I can run p4 login (which prompts for password). This is successful and allows me to run p4 client which returns a User specification that includes an "AuthMethod: perforce" (the user specification does not include a "Password:" line).
I have tried a couple of different workarounds including:
Creating a .p4enviro file which includes the P4PASSWD
Setting an environment variable for P4PASSWD (in /etc/environment)
However, these have no effect...
The logs seems strange to me because the login appears to succeed (at least, no errors are logged). But, the checkout fails with the P4PASSWD error.
Also, the VCS root is using a Client mapping (but I have tried it with Client as well - same error is present).
Any help would be very appreciated!
This is resolved thanks to those who added comments above.
This issue was self-inflicted and caused by an entry in rc.local that was issuing the start command to agent.sh (thus causing the build agent to run as root).
If I would have just RTFM, I wouldn't have encountered this issue :)
I have to conduct a PT on a mobile application.
The recording was done from personal laptop where we didn't face any problem.
However, when we transfer the PT scripts to the testing network, we are facing the following error every time we run it:-
Error in Sample Result:-
Response code: 307
Response message: Authentication Required
Response headers:
HTTP/1.1 307 Authentication Required
Date: Mon, 19 Oct 2015 09:53:21 GMT
Proxy-Connection: close
Via: 1.1 localhost.localdomain
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Error in Response Data:-
Authentication Required
Kindly help us as we have very less time to provide the results.
After several round of brainstorming, I have found out the solution.
Just ensure that the HTTP Request Implementation is set to "JAVA" and the "Redirect Automatically" is set checked-in.
The Scripts will run only for this combination.
If you're running JMeter behind the proxy you can pass credentials via command-line arguments like:
-H, --proxyHost <argument>
Set a proxy server for JMeter to use
-P, --proxyPort <argument>
Set proxy server port for JMeter to use
-N, --nonProxyHosts <argument>
Set nonproxy host list (e.g. *.apache.org|localhost)
-u, --username <argument>
Set username for proxy server that JMeter is to use
-a, --password <argument>
see Full list of command-line options for other keys which might be useful
It may be internal application under test authentication challenge, for instance it expects certain HTTP Header or Cookie. The easiest way to check it is recording the same actions one more time and inspect 2 JMX files for any differences. If they are - they need to be correlated.
I have 2 Linux Servers (with LAMP):
Web Server with SSL (https://www.example.com)
Admin Server (needs to connect to Web Server, via https)
When i connect from Admin Server (to Web Server) via curl command. It is refusing. Then when i use curl with --caeert option, its going through. Like this:
# curl --cacert CAchain.crt -I https://www.example.com
HTTP/1.1 200 OK
..
I'm getting 200 OK only because of --cacert CAchain.crt.
Then obviously i need the pure/basic curl command without defining the --cacert, to be working. Like:
# curl -I https://www.example.com
HTTP/1.1 200 OK
..
So that my Admin Application will for sure be able to connect to it (via https).
But now, when i connect to https://www.example.com from Admin Server (via its Application), it is bouncing back. Not able to reach, with SSL.
How do i make my Linux (RHEL) to install the client's CA-CERT inside, in order automatically AVOID defining the cert file. So that any communications to "https://www.example.com" via CURL or Web Browser (from Admin), can just then successfully go through. (Is it something like, we make "SSH without Keys" logic? But how, please?)
You need to add the CA cert to somewhere that curl can use it - it looks like you're just keeping it in your local directory (which isn't where curl looks for it - typically in some /etc/pki/ssl/ca-bundle.crt-type location). There's a handful of ways to do this. I don't have much experience doing it in RHEL (or CentOS), but have done it for Debian.
This ServerFault Post might help.
Likewise, This Post might help you install/import the CA cert properly.
This has got me the whole day digging for answers. The bottom line is that when I run svn as system user it seems to use the system-name to authenticate against the SVN server regardless of what credentials are passed. Following is the long explanation that made arrive at that conclusion.
When running from a Windows 7 Professional, if I run svn from the console under any normal user, the application works as expected: if credentials have been cached in %AppData%/Roaming/Subversion it will use them, if not it will prompt for username and password unless I use the options --username and --password. If I enter credentials using the options then the commit works with no problem. All good so far.
But when I try to run svn as the system user (nt authority\system) in the same computer, it behaves differently. To begin with, %AppData%/Roaming/Subversion points to C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion, and I make sure there is no auth folder there, so no credentials cached. Then I run svn without any parameters and it doesn't prompt for username/password, instead it executes the action and receives an error from subversion:
svn: E175013: Commit failed (details follow):
svn: E175013: MKACTIVITY of '/svn/Development/!svn/act/f20db493-48f1-9c43-a957-541584be555e': 403 Forbidden (http://<ip-address>)
If I run it indicating --username and --password, it gets the same error. But then I check the error logs from subversion and find this:
[Fri Aug 08 17:32:18 2014] [error] [client <client IP>] Access denied: '<clienthostname>$' MKACTIVITY Development:
[Fri Aug 08 17:32:18 2014] [error] [client <client IP>] Access denied: '<clienthostname>$' DELETE Development:
Where <clienthostname> is the hostname of the computer where I'm trying to commit from (note the '$' at the end of the subversion log, that's not part of the hostname but it does appear in the log as part of the username).
So that's the question: why is svn behaving differently when running as system user? Why does it use the hostname as username when authenticating against the SVN server? And why do other users work correctly?
Note: I believe my problem is different from the following questions in stackoverflow:
Subversion ignoring “--password” and “--username” options: I don't get any prompts to enter username and password, regardless of whether I indicate the options --username and --password or I don't
SVN Error when commiting Access denied: 'foobar' MKACTIVITY MYREPO: I saw this question and I tried double checking the case of all the items in the URL, no luck.
svn: MKACTIVITY 403 Forbidden: I have checked that no credentials are cached in %AppData%/Roaming/Subversion
For those who are wondering why I'm trying to run svn as system user, the answer is that I am trying to make a commit from TeamCity, which means it is the Build Agent the one executing the svn command. The Build Agent is a Windows Service and runs as system user, and the svn command fails in the way explained above.
Use the "--no-auth-cache" in your svn commands and you won't see this issues. You might however run into other set of issues.
If you do not use the no-auth-cache it tries to figure out default username and password anyways
A better way would be to create a .subversion folder and store the authentication in that folder. So for the system account, you can specify a differrent userid and password for the login.