[JIRA] (JENKINS-22900) Access log doesn't contain user names
Title: Message Title
Sam Clippinger commented on JENKINS-22900
Re: Access log doesn't contain user names
I managed to hack together a way to get the username, if it will help anyone else. I created a servlet filter that sets a response header with the username; it can catch basic authentication failures if it runs before the authentication filters (very handy for failing REST API calls). I then created a customized logger for Winstone/Jetty to grab that header and add it to the log output. The header never makes it to the browser, but fortunately I don't need it to. Obviously this requires hacking the web.xml file and the bundled winstone.jar file, but it works. I agree this is a bug – finding the username should not be this difficult. Here's the doFilter() method from my new filter:
/**
* Finds the username for this request, if any.
*
* NOTE: In the case of failed basic authentication requests, the _attempted_
* username is returned. Be sure to check the status code to determine
* success/failure before logging!
*/
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
String username = null;
chain.doFilter(request, response);
NonSerializableSecurityContext securityContext = (NonSerializableSecurityContext)((HttpServletRequest)request).getSession().getAttribute("ACEGI_SECURITY_CONTEXT");
if (securityContext != null) {
Authentication authentication = securityContext.getAuthentication();
if (authentication != null) {
Object principal = authentication.getPrincipal();
if (principal instanceof String) {
// Anonymous/unauthenticated
username = (String)principal;
if (username.equals("anonymous"))
username = null;
}
else if (principal instanceof HudsonPrivateSecurityRealm.Details) {
// Jenkins internal database
username = ((HudsonPrivateSecurityRealm.Details)principal).getUsername();
}
else if (principal instanceof LdapUserDetailsImpl) {
// LDAP
username = ((LdapUserDetailsImpl)principal).getUsername();
}
else {
// Unknown! Uncomment this to find out what class is being returned.
//username = "unknown(" + principal.getClass().getName() + ")";
}
}
}
else {
String authorization = ((HttpServletRequest)request).getHeader("Authorization");
if ((authorization != null) &&
authorization.startsWith("Basic ")) {
String credentials = new String(Base64.getDecoder().decode(authorization.substring(6)));
int colon = credentials.indexOf(':');
if (colon >= 0) {
username = credentials.substring(0, colon);
}
}
}
if (username != null)
((HttpServletResponse)response).addHeader("X-Username", username);
}
[JIRA] [core] (JENKINS-32103) Expose workspace path in environment for "prepare environment" scripts
Title: Message Title Sam Clippinger created an issue Jenkins / JENKINS-32103 Expose workspace path in environment for "prepare environment" scripts Issue Type: Improvement Assignee: Unassigned Components: core Created: 16/Dec/15 6:23 PM Environment: LTS 1.625.3 Priority: Minor Reporter: Sam Clippinger We use the "Prepare an environment for the run" option to run scripts prior to SCM checkout. However, the WORKSPACE environment variable is not set when those scripts run and I cannot find any way to discover what the workspace will eventually be. For example, if the project is set to allow concurrent builds and the workspace will have "@3" appended to the path, that information is inaccessible. This means our scripts that sanitize the git folders on the slave have to make some dangerous assumptions about where to run. I'm not very familiar with the Jenkins code, but from what I can tell the workspace is "leased" in AbstractBuild$AbstractBuildExecution.run() just before the call to prepareWorkspace(). If the WORKSPACE variable were added to the environment at that point, I think it would be visible from any scripts running before SCM checkout. Would it be possible to add this?
[JIRA] [jclouds-plugin] (JENKINS-27471) jClouds deletes nodes that are running flyweight builds
Sam Clippinger
created JENKINS-27471
jClouds deletes nodes that are running flyweight builds
Issue Type:
Bug
Assignee:
abayer
Components:
jclouds-plugin
Created:
17/Mar/15 10:50 PM
Description:
When a matrix build begins, Jenkins creates a "flyweight" build that checks out the code and decides which (if any) of the project axes need to be rebuilt. The "flyweight" build starts the subordinate jobs and waits until they are complete before it finishes. However, Jenkins doesn't allocate an executor to the "flyweight" builds or consider them when reporting whether a node is "idle". Because JCloudsRetentionStrategy.check() only uses Computer.isIdle() to determine if the node is busy, it kills off nodes running "flyweight" builds.
Our cloud is set to create instances with one executor each. In the scenario where a matrix build starts two subordinate builds, the "flyweight" will run alongside one build while the other goes to a second node. If the job on the second node takes more than the retention time to complete, the first node will be considered "idle" and jClouds-plugin will terminate it, which stops the "flyweight" build with an error, which causes the entire build to fail.
"Flyweight" builds don't occupy executors, so the only way I've found to detect them one is by enumerating every job in the system, testing to see if it's building, then checking the name of the node it's building on. (If there's a better way, I would very much like to know about it!) Some Groovy code:
for (node in Jenkins.getInstance().getComputers()) {
num_jobs = 0;
for (job in Jenkins.getInstance().getAllItems()) {
if (job.isBuilding()) {
if (job.getLastBuild().getBuiltOnStr() == node.getName()) {
num_jobs++;
}
}
}
if (num_jobs 0) {
println("Node " + node.getName() + " is running " + num_jobs + " - don't kill it!");
}
}
(I know this is really a bug in upstream Jenkins, but the developers there seem determined to treat "flyweight" builds as undetectable non-entities, so I think fixing jCloud-plugin's behavior will be a much easier fix.)
Thanks for all your great work!
Environment:
Jenkins 1.599, jClouds-plugin 2.9-SNAPSHOT (private-3bd37c37-jenkins)
Project:
Jenkins
Labels:
matrix
flyweight
Priority:
Critical
Reporter:
Sam Clippinger
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
