sleevi

On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.

1. Support for keeping a long-lived (disk) cache of OCSP responses.

   This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server

Seldaek

03:54 -!- THEBEEFSTEAK has joined #composer
03:54 <THEBEEFSTEAK> hey guyys
03:54 <THEBEEFSTEAK> RobLoach
03:55 <THEBEEFSTEAK> sandvige
03:55 <THEBEEFSTEAK> scottrigby
03:55 <THEBEEFSTEAK> skoop
03:55 <THEBEEFSTEAK> Spea
03:55 <THEBEEFSTEAK> tonton
03:55 <THEBEEFSTEAK> tystr:
03:55 <THEBEEFSTEAK> s+e:

micw

#!/bin/bash

set -e

if [ $# -eq 0 ]; then
  echo "USAGE: $0 plugin1 plugin2 ..."
  exit 1
fi

plugin_dir=/var/lib/jenkins/plugins

joseraya

In order to configure the bitbucket hook we need two things: The user's API Token and the project token. In order to retrieve the first one whe should click on our username (on the top right corner of the page), click on configure and then click on "Show API Token". This API token will be used as password for our user.

For the project's token we need to go to the job configuration (/job/{job-name}/configure), "build triggers" and enable "trigger remote builds" and, there, input some random text as token.

Once we have these two tokens we can go to bitbucket, repo administration, hooks section, and add a new jenkins hook that we will configure like:

• Endpoint: http://{username}:{APIToken}@{hostname}/{prefix_if_you_have_one}
• Module name: Whatever (I usually leave this one blank)
• Project name: The job name
• Token: The project token