fortifyclient uploadFPR An internal error has occurred

When you try to upload a .fpr file to Fortify 360 server and you get the below mentioned error. Then, this blog provides one of the route cause info and fix.

fortifyclient -url http://some-fortify-server:8282/f360 -authtoken xxxxxxx-xxxx-xxxx-xxxx-xx1231324 uploadFPR -file myproject.fpr -project myproject -version 3.1


An internal error has occurred.
(org.springframework.oxm.jaxb.JaxbUnmarshallingFailureException: JAXB unmarshalling exception: null; nested exception is javax.xml.bind.UnmarshalException
 - with linked exception:

One of the reason this error occurs is "If the date/time on the machine where you run fortifyclient is ahead or too behind"

Solution: Set current date/time on the client machine.

Read More

Upgrading Virtual Machine hardware versions using Kiwi

In this blog, I'm providing information on upgrading the VMWare Virtual machine hardware version. Also this VM is generated using the SuSe appliance build utility - KIWI.

What hardware versions in VM's mean?

Refer the links 

   http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746

and

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014006

How to determine the current hardware version of a virtual machine ?

In the vSphere Client

  1) Click the virtual machine.

  2) Click the Summary tab.

  3) Find the hardware version in the VM Version field.

Upgrading hardware versions using VMWare utilities

 Refer the above mentioned links for this info.

Ugrading hardware versions in automated builds generated using kiwi (Suse Studio)

KIWI is an application for making a wide variety of image sets for Linux supported hardware platforms as well as virtualisation systems. 

We use Kiwi to build our virtual appliances. Kiwi builds appliances by referring a configuration file config.xml . To upgrade the VM machine HW version, you just need to make an entry to this config.xml file (source/config.xml  not bootsource/config.xml).

Your config.xml file may have a "vmwareconfig" section as shown below (in our case) and that describes the properties of a VM it is going to generate. Add desired HWversion field to this line as shown below (we upgraded from 4 to 7).

<vmwareconfig memory='4096' usb='true' arch='ix86' HWversion='7' guestOS='sles'>

    <vmwaredisk id='0' controller='scsi'/>

    <vmwarecdrom id='0' controller='ide'/>

    <vmwarenic mode='bridged' interface='0' driver='e1000'/>

 </vmwareconfig>

By default it was generating HW version 4 images. After adding HWversion='7', now it generated version 7 images for us. This is the working in our case.

If you don't find "vmwareconfig" section in your config.xml, then you need to deal it under "preferences" section as described in Kiwi cookbook. 

<machine arch="arch" memory="MB" HWversion="number" guestOS="suse|sles" domain="dom0|domU"/>

   <vmconfig-entry>Entry_for_VM_config_file<\vmconfig-entry>

   <vmconfig-entry .../>

   <vmnic driver="name" interface="number" mode="mode"/>

   <vmnic ...>

   <vmdisk controller="ide|scsi" id="number"/>

   <vmdvd controller="ide|scsi" id="number"/>

</machine>

Refer Kiwi cookbook for details.

Read More

Solution to Project Euler Problem 10 - Find the sum of all the primes below two million

http://projecteuler.net/problem=10

Problem
The sum of the primes below 10 is 2 + 3 + 5 + 7 = 17.
Find the sum of all the primes below two million.

Answer:   457143142877

Solution:

#!/usr/bin/perl -w

use strict;

use Math::Complex;

my (@primes,$ulimit,$stop);

$ulimit=2000000;

$stop=10001;

generate_prime();

sub generate_prime {

        my ($i,$j,$prime,$squareroot,$count);

        @primes=(2,3,5,7); #initial prime numbers

        my $sum=17;  #initial sum = 2+3+5+7

        #We know only 2 is the even prime numbers, hence skip all even numbers

        for ($i=9;$i<=$ulimit; $i+=2) {

                $prime=0;

                #Divide the number by all the prime numbers less than the square root

                $squareroot=sqrt($i);

                foreach $j (@primes) {

                        if ( $j > $squareroot ) {

                                last;

                        }

                        if (($i%$j) == 0) {

                                $prime=1;

                                last;

                        }

                }

                if ($prime == 0 ) {

                        print "The current prime number is: $i\n";

                        $sum+=$i;

                        print "sum till now: $sum \n";

                }
        }
}

Read More

Building SuSe appliances locally using Kiwi (command line)

SuSe Studio is a online/standalone software appliance build tool. We typically use it to generate appliances based on SLES O.S. We can use the online utility for free but the standalone utility is licensed.
But SuSe Studio is just a web interface. The core of the appliance building is done by a command line utility - Kiwi. Kiwi is part of OpenSuse and it is maintained by Open Source community (I guess it's funded by Novell).

Generating appliances through online is good for initial exploration, but if need to generate appliances frequently, can we do this manual task everyday? No. We need to automate. This blog explains how to automate appliance building process using Kiwi tool.

Step 1: Configure your appliance on SuSe Studio Standalone (preferably), build, deploy and validate your appliance.
Step 2: Export your appliance's Kiwi configuration, for building your appliance locally.
          In the build tab of Suse Studio, in the bottom you can find the link to download Kiwi config files.
Step 3: Copy the Kiwi config files to a SLES build machine, where kiwi is installed. Try to use the same kiwi version, the Suse studio have used to build it. Refer README file for details.
Step 4: Compile it using the script create_appliance.sh which comes along with kiwi config files when you export. It has 2 phases
             1) Boot build   - 2 sub process
                                     a) Prepare (generates boot-prepare.log)
                                     b) Create ( generates boot-create.log)
             2) Actual image build - 2 sub process
                                      a) Prepare (generates prepare.log)
                                      b) Create ( generates create.log)

             You can generate the appliance in ISO format or Virtual appliance ( .vmdk , OVF) or some other format.
Step 5: Deploy it either on physical machine or on virtual machine like (VMWare ESX server).
 If it gets deployed without any error, then you are lucky. Otherwise you may get error like
    VFS: Cannot open root device "<NULL>" or unknown-block
    Or some Kernel Panic message.

Actually when we download Kiwi configuration files from Suse Studio, it is not exporting the same config files it used to build. It is providing some modified set of files. Is it fooling us?

Here are the steps to overcome it.
Step 6: Login to the machine where you installed Standalone suse studio. If you don't have stand alone installation and got config files from online suse studio, then you may need to contact Suse Studio for help.
Step 7: Go to /studio/runner/ directory (cd /studio/runner/). You will notice 2 directories of interest bootsource & source.
Step 8: When you start the build on Suse studio, in the build log file you can notice which config files it used for that build. Like
   Running Step 3: Setting up build environment
  '/studio/runner/bootsource/a24-0.0.3-vmx-x86_64/' 'bootsource'
  '/studio/runner/source/a24-0.0.3-vmx-x86_64/' 'source'

   From the above output you can locate where on the Studio machines the actual config files for 'boorsource' and 'source' are getting stored
  Copy these 2 folders to your build machine mentioned in Step 3
Step 9: You may not be able to directly use the config files obtained in Step 8. Instead replace few selected files obtained from config files in step 8, with the existing config files on build machine ( Obtained in Step 2)
   Some of the files which we replaced/added to make it work are
        bootsource/config.xml
        bootsource/root/config.oempartition
        bootsource/root/dump
        bootsource/root/include
        bootsource/root/linuxrc
        bootsource/root/preinit
        bootsource/root/repart
        source/config.xml

 All the files mentioned above may not be needed to replace/add, but this is what worked for us.
Step 10: If you have local repository, don't forget to mention it in config.xml files ( source & bootsource)
Step 11: Build & deploy it again (Step 4 & 5).

Hopefully now your appliance should get deployed without any issues.

Read More

How to find source changelist number used to create a perforce branch?

All perforce admins will mostly get this query "Hey from what changelist number branch //branch/B is created from branch //branch/A?"
There is no simple single command from Perforce to answer this question. But still  you can figure it out with below method. Though it is not 100% perfect answer, I can bet it will give 99.99% right one.

Scenario:
 Branch //release/dpm-3.1/KMS/... is created from //dev/rkm/KMS/... a year ago and we didn't preserve the source branch (i.e. //dev/rkm/KMS/...) changelist number used to create new //release branch.
 Usually the standard practice is to record this changelist number in the description of new branch changelist while creating it.
 Anyways, if you have missed it, no worries, still you can figure it out.

Solution:
Step 1: Find the first changelist number which got created when the new branch //release/dpm-3.1/KMS/... took birth. You can use below command to find it.
   $ p4 changes //release/dpm-3.1/KMS/...|tail -1
  Change 1270598 on 2011/11/22 by guruss1@sguru_VWINRSA2-46 'Creating //release/dpm-3.1/KMS '

  Note down this number 1270598

Step 2: Find the ancestral history of new branch //release/dpm-3.1/KMS/... using 'p4 changes -i' command and find out what was the changelist number before the birth of branch (i.e changelist before 1270598). Note that -i option will traverse behind and tell what all parent branch changelists are integrated to this new branch.
You can use below command to find ancestral history. Here I'm limiting history to 3 changelist numbers before this branch took birth.
  $  p4 changes -i //release/dpm-3.1/KMS/...|grep -A3 '1270598'
Change 1270598 on 2011/11/22 by guruss1@sguru_VWINRSA2-46 'Creating //release/dpm-3.1/KMS '
Change 1254271 on 2011/09/20 by sguru@sguru_VWINRSA2-46 'Adding thirdpartylicenses.pdf f'
Change 1254094 on 2011/09/19 by pasuns@Sreeekanth_RKM 'coverage reduced to 70% to make'
Change 1253772 on 2011/09/19 by pasuns@Sreeekanth_RKM 'Fix for KMSRV-1798: Addressing '

From this output, I got to know that, changelist number 1254271, which is from the parent branch  //dev/rkm/KMS/... is the last changelist number integrated and hence this is the changelist used to create this branch. 

Read More

Firewall configuration. How to open a port on Linux?

When we install CentOS, the default configuration will be hardened and hence most of the unneeded ports will be blocked.
I configured Perforce proxy server in a centOS, which needed port 1666 to be opened. Since it is blocked, none of the other machines were able to contact perforce proxy server.  It used to give below error
$ p4 info

Perforce client error:
        Connect to server failed; check $P4PORT.
        TCP connect to xxx.xxx.com:1666 failed.
        connect: xxx.xxx..com:1666: WSAETIMEDOUT


To configure Firewall, we can use ipconfig command in Linux.
Here is the iptables command to open it
  iptables -t filter -A INPUT -p tcp --dport 1666 -j ACCEPT
where
   --table       -t table        table to manipulate (default: `filter')
   --append  -A chain            Append to chain
   --proto     -p proto        protocol: by number or name, eg. `tcp'
   --jump      -j target         target for rule (may load target extension)

Then save the configuration

   service iptables save

Next reload the configuration

  service iptables reload

Check the status

  service iptables status

O/P:

   Table: filter

   Chain INPUT (policy ACCEPT)

    num  target     prot opt source               destination

   1    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:1666

As shown above, now the port 1666 is opened.

Other options 

  iptables -L    

      where 

        --list    -L [chain [rulenum]]         List the rules in a chain or all chains

        --flush   -F [chain]          Delete all rules in  chain or all chains

Read More

Running perforce p4d as service on RHEL

Perforce is not providing standard script to run the perforce server p4d as service on Linux systems. Different people configured it in different way. Here is my way of running it as service on RHEL machines.

• Create an account 'perforce' in your machine
• Download p4d and place it in designated directory as defined P4ROOT. Provide exec permission for it. And also change the owner to 'perforce' account.

         In my case P4ROOT=/home/perforce/server

• Create a start-up script 'p4d' at /etc/init.d

cat /etc/init.d/p4d
#!/bin/sh
# description: This is a daemon which starts perforce server on reboot
PATH=/sbin:/bin

test -f /home/perforce/server/p4d || exit 0
export P4ROOT=/home/perforce/server
export P4PORT=1818
RUN_AS_USER=perforce

case "$1" in
start)
  su -m $RUN_AS_USER -c "/home/perforce/server/p4d -r $P4ROOT -J /home/perforce/logs/journal -L /home/perforce/logs/p4err -p tcp:$P4PORT &"
  ;;
stop)
  /usr/local/bin/p4 admin stop
  ;;
*)
  echo "Usage: /etc/init.d/p4proxy {start|stop}"
  exit 1
esac

exit 0

Here note that we are not running p4d as root, instead using the account 'perforce'

• Add a new service for management through chkconfig

          chkconfig --add p4d

• Configure the run levels on which it needs to be on

          chkconfig --levels 345 p4d on

        It creates soft-links like

           ls -ltr /etc/rc3.d/S29p4d

        lrwxrwxrwx 1 root root 13 Sep  4 16:36 /etc/rc3.d/S29p4d -> ../init.d/p4d

• Verify it by running commands

            service p4d start

            service p4d stop

Read More