Monday, June 20, 2016

Sunday, June 12, 2016

Thursday, May 19, 2016

Invoking Jenkins Job using Jersey Client in Java with Username / Password authentication

General

The following post is document how to invoke a job using Jersery client in Java on Jenkins

Assumptions

  • You are familiar with Jenkins and have permissions to create a new job
  • I've used Jenkins version is 1.651.1 ( I'm guessing it will work on previous versions but I did not check)
  • You are familiar with Maven
  • You have IntelliJ ( I used Community Edition 2016.1)

Setup

Jenkins

Creating the job

  • Connect your Jenknis
  • Click on New Item
  • In Item name type 'hello_world'
  • Select 'Freestyle project'
  • Press ok

Configuring the job

  • Click on the job
  • Press on the configure link from the left
  • Check the 'This build is parameterized'
  • Click on 'Add Parameter'
  • Choose String Parameter
  • In the name type 'firstname' (Leave the Default value and description empty)
  • Scroll down to the Build section
  • Click on  'Add build step' and choose Execute shell
  • type 'echo ${firstname}'

Test the job

  • Click on the 'Build with Parameters'
  • Fill in a name click on the build number (should be #1) in case this job is new
  • Click on Console Output
  • You should see something like this
+ echo checking
checking

Java

Creating the project

  • Open IntelliJ
  • Click on 'Create New Project'
  • Choose maven and click next
  • GroupId: com.tzach.jenkins
  • ArtifactId: jerseyclient
  • Project name: jersey_client_jenkins
  • Open the pom.xml file
  • Add the following
    <dependencies>
        <dependency>
            <groupId>org.glassfish.jersey.core</groupId>
            <artifactId>jersey-client</artifactId>
            <version>2.22.2</version>
        </dependency>
    </dependencies>

  • Click on Enable auto import
  • Click on Maven from the right and choose compile
  • On the bottom you should see 'Process finished with exit code 0'

Now let's write some code

  • Create a new class named JenkinsJerseyClient
  • Create the following method: Response invoke(String username, String password, String firstname)
  • Paste the following
String target = "http://myjenkins:8080/job/hello_world/buildWithParameters";

HttpAuthenticationFeature httpAuthenticationFeature = HttpAuthenticationFeature.basicBuilder()
                .credentials(username, password)
                .build();

ClientConfig clientConfig = new ClientConfig();
clientConfig.register(httpAuthenticationFeature);

Client client = ClientBuilder.newClient(clientConfig);

WebTarget webTarget = client.target(target);
// Parameters needed for the job
Form form = new Form();
form.param("firstname", firstname);

// Sending invoke as POST
return webTarget.request(MediaType.APPLICATION_JSON_TYPE)
.post(Entity.entity(form, MediaType.APPLICATION_FORM_URLENCODED_TYPE));

  • Replace the URL of jenkins to your jenkins
  • Create a main method, and paste the following:
 System.out.println(new JenkinsJerseyClient().invoke("tzachs","tzachs_password","tzach").getStatus());

  • Replace 'tzachs' with your username
  • Replace 'tzachs_password' with your password
  • Replace 'tzach' with the parameters you need
  • Full code looks like this:

import org.glassfish.jersey.client.ClientConfig;
import org.glassfish.jersey.client.authentication.HttpAuthenticationFeature;

import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.Entity;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.Form;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

/**
 * Created by tzachs on 5/19/2016.
 */
public class JenkinsJerseyClient {

    public Response invoke(String username, String password, String firstname){
        String target = "http://myjenkins:8080/job/hello_world/buildWithParameters";

        HttpAuthenticationFeature httpAuthenticationFeature = HttpAuthenticationFeature.basicBuilder()
                .credentials(username, password)
                .build();

        ClientConfig clientConfig = new ClientConfig();
        clientConfig.register(httpAuthenticationFeature);

        Client client = ClientBuilder.newClient(clientConfig);

        WebTarget webTarget = client.target(target);
        Form form = new Form();
        form.param("firstname", firstname);

        return webTarget.request(MediaType.APPLICATION_JSON_TYPE)
                .post(Entity.entity(form, MediaType.APPLICATION_FORM_URLENCODED_TYPE));
    }

    public static void main(String[] args) {
        System.out.println(new JenkinsJerseyClient().invoke("tzachs","tzachs_password","tzach").getStatus());
    }
}

Run

  • Run the main, you should see in the console log 201. If you see it, it's working. Go to jeknins see you have a new build number

Thursday, April 28, 2016

Connecting IntelliJ and JIRA with SSL (java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty)

Connecting IntelliJ and JIRA with SSL (java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty)

My work place change the JIRA connection from HTTP to HTTPS meaning now JIRA was working with SSL. 
Everything was working fine with Chrome but when trying to work with IntelliJ and JIRA using the Atlassian plugin (https://confluence.atlassian.com/display/IDEPLUGIN/Installing+the+IntelliJ+Connector) I've encountered the following error: 


Clicking on Show Details was not that helpful and displayed the following stack trace:

com.atlassian.theplugin.commons.remoteapi.RemoteApiException: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at com.atlassian.connector.commons.jira.soap.JIRASoapSessionImpl.login(JIRASoapSessionImpl.java:193)
at com.atlassian.connector.commons.jira.JIRASoapAndXmlServerFacade2Impl.testServerConnection(JIRASoapAndXmlServerFacade2Impl.java:154)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.atlassian.connector.commons.jira.JIRAServerFacade2Impl$1.invoke(JIRAServerFacade2Impl.java:93)
at com.sun.proxy.$Proxy41.testServerConnection(Unknown Source)
at com.atlassian.connector.commons.jira.JIRAServerFacade2Impl.testServerConnection(JIRAServerFacade2Impl.java:268)
at com.atlassian.theplugin.commons.jira.IntelliJJiraServerFacade.testServerConnection(IntelliJJiraServerFacade.java:473)
at com.atlassian.theplugin.idea.config.serverconfig.ProductConnector.connect(ProductConnector.java:35)
at com.atlassian.theplugin.ConnectionWrapper.run(ConnectionWrapper.java:63)

The problem

Intellij now needed the Certificate JIRA was using in order to establish a connection

How to solve?

Thanks to the IT guy at my work, I understood I needed to fetch the certificate and tell IntelliJ to use the key store in which I loaded the certificate to.

Here is how to do it.
  • You have JRE / JDK installed
  • Make sure you have openssl.exe (I'm assuming you are on windows). If you don't have you can get it by installing openvpn (get it from here https://openvpn.net/)
  • Open command line
  • Execute: openssl s_client -connect <JIRA_DNS_NAME>:443 where <JIRA_DNS_NAME> should be replaced with the your JIRA dns name / IP (for example openssl s_client -connect jira:443)
  • Copy the output the last command generated from ---BEGIN CERTIFICATE--- to ---END CERTIFICATE-- including those lines to a file named public.cert
  • Execute: keytool -import-alias <NAME_OF_ALIAS> -file public.cert. For example, keytool -import -alias jira -file public.cert
  • It will ask for a password. The default password is 'changeit'
  • Answer yes to 'Trust this certificate'
  • You should receive 'Certificate was added to keystore'
  • Verify the certificate was really added using the following command: keytool -list | findstr <NAME_OF_ALIAS>, for exampe keytool -list | findstr jira
  • You should see something like this: jira, Apr 28, 2016, trustedCertEntry,
  • Go to the installation of IntelliJ. Default installation in windows is at 'C:\Program Files (x86)\JetBrains\<INTELLIJ_PRODUCT>\bin'
  • If you have multiple installation, notice which one you choose, in my case it was 'C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 2016.1.1\bin'
  • Edit the file idea.exe.vmoptions (or idea64.exe.vmoptions, depends which one you are running)
  • Add the following: -Djavax.net.ssl.trustStore=c:\Users\<YOUR USERNAME>\.keystore, for example, in my case it was '-Djavax.net.ssl.trustStore=c:\Users\tzachs\.keystore'
  • Restart IntelliJ

Troubleshoot

In case something does not work, check the idea.log. 

For more reading


Sunday, April 3, 2016

Java script not working in Jenkins due new Content security policy, chrome console log 'displays allow-scripts' permission is not set.

Problem

We run tests using our Jenkins CI and our report contains java script. From version 1.625 LTS we saw that our report is corrupted, meaning most of it is gone.

Displaying the console (F12 in chrome) revealed the problem:
Blocked script execution in 'http://10.10.10.10:8080/job/test/ws/run/report/index.html' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Temporary solution:

  • Go to Jenkins main page
  • Click on Manage Jenkins
  • Click on Script Console
  • Paste the following and press run: System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")
Go again to the page the was "corrupted" and refresh it

NOTICE: This fix does not survive restart of Jenkins

Fixed Solution:

Ubuntu

  • SSH the jenkins machine
  • Edit the jenkins default file located at /etc/default/jenkins
  • Search for JAVA_ARGS parameter
  • Add the following: -Dhudson.model.DirectoryBrowserSupport.CSP=\"\""
  • Restart jenkins

CentOS


  • SSH the jenkins machine
  • Edit the jenkins default file located at /etc/sysconfig/jenkins
  • Search for JENKINS_JAVA_OPTIONS parameter
  • Add the following: -Dhudson.model.DirectoryBrowserSupport.CSP=\"\""
  • Restart jenkins

See this for more information



Checkout with SVNKIT on UNIX - Solving SVN authentication error E170001

Prefix

I'm writing this post since I've seen many encountered this error without an answer including myself and SVNKIT documentation is not at best, for example:


Problem

The following code will run okay in case you in the windows and working in the domain same as the SVN but will not work on UNIX platforms


SvnOperationFactory svnOperationFactory = new SvnOperationFactory();
SvnCheckout svnCheckout = svnOperationFactory.createCheckout();
svnCheckout.setSingleTarget(SvnTarget.fromFile(checkoutFolder));
svnCheckout.setSource(SvnTarget.fromURL(url));
svnCheckout.run();

Solution:

Add the following line after creating the SvnOperationFactory


svnOperationFactory.setAuthenticationManager(SVNWCUtil.createDefaultAuthenticationManager(username, password.toCharArray()));

Complete code should look like this:

SvnOperationFactory svnOperationFactory = new SvnOperationFactory();
svnOperationFactory.setAuthenticationManager(SVNWCUtil.createDefaultAuthenticationManager(username, password.toCharArray()));
SvnCheckout svnCheckout = svnOperationFactory.createCheckout();
svnCheckout.setSingleTarget(SvnTarget.fromFile(checkoutFolder));
svnCheckout.setSource(SvnTarget.fromURL(url));
svnCheckout.run();

Saturday, September 5, 2015

Connecting to Oracle Database using SQL Developer and Wallet authentication method

The story behind this post

A friend encountered a trouble opening a connection using SQL Developer to oracle database using Wallet authentication method.

The ORA error code we got was ORA-12578 TNS: wallet open failed.
After an hour of trying to troubleshoot we were able to make it work.

This post documents how to use the Oracle Sql developer while using the wallet authentication

Assumptions

  • Your Wallet already setup at the database, if you need any help see http://www.dba-resources.com/oracle/a-guide-to-oracle-wallet/
    • You should have the files cwallet.sso and ewallet.p12 files at the end of the process
  • Your Wallet storage is setup on your Client (where the SQL developer is installed)
  • Your TNS is setup with the connection to the database, example set is:
TEST_WALLET_ALIAS = 
    ( DESCRIPTION  =  
       ( ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.17.2)(PORT = 5138))
       ( CONNECT_DATA = 
          (SERVICE_DATA = demo_srv)
       )
    )

  • Your sqlnet.ora have the needed configuration. Our at the client side sqlnet.ora looked like this:
WALLET_LOCATION =
    ( SOURCE =
      ( METHOD = FILE)
      ( METHOD_DATA = 
        ( DIRECTORY = c:\app\product\11.2.0\client_2\network\admin)
      )
    )

Preparing

Verifying Wallet connection is working locally

Before trying to work remotely using the SQL developer, verify the wallet is working by doing the following (NOTICE: This requires access to the database machine itself. Not always you have that access rights. If you do not, try):
  1. Connect to the machine (using SSH or Remote Desktop)
  2. Connect locally using the wallet authentication method using the following syntax:
    1. sqlplus /@<your wallet name> (For example  sqlplus /@TEST_WALLET_ALIAS
  3. If you are able to connect on the database itself continue.

Verifying Wallet connection works remotely using sqlplus

If you have installed the oracle client correctly you probably have the sqlplus client (Oracle's proprietary client).

We'll use it to verify the Wallet is working remotly
  1. Open terminal or command line
  2. Go to your oracle client installation directory. Our's was at c:\app\product\11.2.0\client_2)
  3. Go to the network admin directory.
  4. Copy the sqlnet.ora, tnsnames.ora and wallet files from the database. The tnsnames.ora should have the alias, in our case it was TEST_WALLET_ALIAS
  5. Connect using the syntax of the wallet authentication
    1. sqlplus /@<your wallet name> (For example  sqlplus /@TEST_WALLET_ALIAS

Connecting using SQL Developer

If you've reached this point, I'm assuming sqlplus worked for you at least remotely.
So, in order to make the SQL Developer use the wallet authentication we'll do the following

  1. Verify that you have environment variable named TNS_ADMIN in the system environment variables pointing to the directory where the sqlnet.ora directory resides,
    1. To configure environment variables on windows, go to Control Panel --> System Properties --> Environment Variables
  2. In the sqlnet.ora you need to direct to wallet directory.
  3. Create a wallet using the wallet manager
  4. Copy the wallet files from the Oracle database to the wallet directory
  5. Create a new advanced connection using the following format
    1. Connection Name: TestWaller (the name does not really matter)
    2. Connection Type: Advanced
    3. Custom JDBC URL: jdbc:oracle:oci /@<your wallet alias> (In our case it was jdbc:oracle:oci /@TEST_WALLET_ALIAS)

Further reading

http://www.dba-resources.com/oracle/a-guide-to-oracle-wallet/