Wednesday, June 10, 2015

maven-scm-plugin pom.xml sample for svn checkout/checkin - and why the error "svn: [dir] is not a working copy"

Below is a snippet of my pom.xml that performs the following 3 steps when invoked by "mvn generate-sources" -
1. maven-scm-plugin to do a svn checkout into the target/checkout directory
2. exec-maven-plugin to use curl to download a jar file into the target/checkout directory
3. maven-scm-plugin to do a svn add & checkin from the target/checkout directory
 ------------------------------------------------------
  <scm>
    <connection>scm:svn:http://your_svn_url</connection>
    <developerConnection>scm:svn:http://your_svn_url</developerConnection>
    <url>scm:svn:http://your_svn_url</url>
  </scm>

  <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.9</version>
        <configuration>
          <username>...</username>
          <password>...</password>
          <basedir>target</basedir>
          <workingDirectory>target/checkout</workingDirectory>
        </configuration>
        <executions>
         <execution>
            <id>perform-checkout</id>
                <phase>initialize</phase>
            <goals>
                <goal>checkout</goal>
            </goals>
           <configuration>
          <workingDirectory>target/checkout</workingDirectory>
          <checkoutDirectory>target/checkout</checkoutDirectory>
           </configuration>
         </execution>
          <execution>
            <id>perform-checkin</id>
                <phase>generate-sources</phase>
            <goals>
                <goal>add</goal>
                <goal>checkin</goal>
            </goals>
            <configuration>
                <workingDirectory>target/checkout</workingDirectory>
                <basedir>target</basedir>
                <includes>*</includes>
                <message>test</message>
            </configuration>
         </execution>
        </executions>
      </plugin>

    <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.2.1</version>
    <executions>
        <execution>
           <id>id1</id>
           <phase>initialize</phase>
           <goals>
                <goal>exec</goal>
            </goals>
           <configuration>
                <executable>curl</executable>
                <workingDirectory>target/checkout</workingDirectory>
                <arguments>
                        <argument>-O</argument>
                        <argument>https://repo.abc.com/abc.jar</argument>
                </arguments>
           </configuration>
        </execution>
    </executions>
</plugin>
</plugins>
--------------------------------------------------
A few things to note here -
1. As you can see, the "initialize" phase will execute the scm:checkout and exec:exec, then the "generate-sources" phase will  execute the scm:add and scm:checkin. You can of course change the phases to whatever fit your need, but phases determines the sequence that your plugin executions will be executed.

2. You should always do a svn checkout first, so the directory you plan to use to checkin contains the svn working copy (in this case, your svn working directory is [your_current_dir]/target/checkout). Otherwise, the scm:checkin would fail with error "svn: [your_current_dir/target/checkout] is not a working copy". You can of course manually checkout the svn working directory first, then use maven to just do the checkin. But with the above executions, you can do both checkout/checkin with maven.

3. You should also check that the .svn directory inside your working directory is properly populated. One thing that could cause the .svn to be empty is that you've set the "includes" configuration to wrong value for scm:checkout - for examples, if you have an "includes=*" in your checkout execution configuration, your ".svn" directory will be empty, and your subsequent scm:checkin would fail.


Monday, March 23, 2015

How to access a siteminder SSO protected url using a java client

I needed a piece of code that can access a siteminder SSO protected url/resource (something like this, http://xyz.abc.net/userList) . And I've heard quite a few times from other people that they wanted the same thing, so I've decided to write a piece of java code. Here are the basic steps to do it -

1. create a cookie store
2. create a httpclient with the cookie store
 CloseableHttpClient httpclient = HttpClients.custom()
                    .setDefaultCookieStore(cookieStore)
                    .build();

3. send a http post to the siteminder protected url
    HttpPost httpPost = new HttpPost("http://xyz.abc.net/userList");
    HttpResponse response = httpclient.execute(httpPost);

4. check that the http response code is 302

5. grab the "Location" (response.getFirstHeader("Location").getValue())
    String location = response.getFirstHeader("Location").getValue();

6. create another httpPost using the Location url you get from step 5

7. set two form fields "USER" and "PASSWORD"
            HttpUriRequest httpPost2 = RequestBuilder
                    .post()
                    .setUri(new URI(location))
                    .addParameter("USER", uid)
                    .addParameter("PASSWORD", pwd).build();

8. response = httpclient.execute(httpPost2)

9. Check the cookie store, there should be a SMSESSION cookie now
   cookies = cookieStore.getCookies();
   for (int i = 0; i < cookies.size(); i++) {
                    System.out.println("- " + cookies.get(i).toString());
   }

10. new create a  httpget with the siteminder protected url and send the httpget with the httpclient, and aha, I could see the proper content in the response and http code 200.

That's it!  Hope this helps.

Wednesday, February 25, 2015

Rundeck "authentication failure...Make sure your resource definitions and credentials are up to date." issue

We have Rundeck connecting to many different application servers to help application teams to do their deployment. Two teams reported the below authentication failure error, one for a linux node, the other for a windows node.

Error:
Authentication failure connecting to node: "<node>". Make sure your resource definitions and credentials are up to date.

For the linux node issue, it's because user was using passwordless ssh to connect to their linux box, but the public key wasn't setup properly. The connection didn't even work from Rundeck server to their box. The problem was resolved after  having user changed the permission of their public key file.

For the windows node issue, it's because user was using a "script" (inline script) job step, instead of the simple "command" job step. It looks like this "script" job step is for unix only, and because user was using it, the netstat from user's windows box showed that Rundeck was trying to connect to the port 22 (default ssh port) in their windows box. Replacing the inline script with a simple command step fixed the issue.