software


(netbeans 6.1, external ant 1.7)

There are some great tools out there to generate a visual overview of the dependencies between the tasks within an ant file. Here is an example for Netbeans build-impl.xml file using Grand:

build-impl ant task dependencies

build-impl ant task dependencies

Here is the snippet from the task in my build.xml (following descriptions in Visual Documentation of Ant Dependencies in 3 Simple Steps):

    <target name="visual-ant-task-dependencies">
        <typedef resource="net/ggtools/grand/antlib.xml" /><!-- if its in your ants lib dir, otherwise use classpath="" -->
        <grand output="build.dot" buildfile="${basedir}/nbproject/build-impl.xml">
             <filter name="fromnode" node="jar"/>
             <!-- filter name="tonode" node="xxxx"/ -->
        </grand>
	<exec executable="dot">
            <!-- arg line="-Tpng -Gsize=11.69,8.27 -Grotate=90 -o build.png ${basedir}/build.dot" / -->
            <arg line="-Tpng -Gsize=23.39,16.54 -o build.png ${basedir}/build.dot" />
        </exec>
    </target>

I uploaded the grand.jar to my ant home /lib directory. Of course you will need graphviz to be installed for the dot command. Have fun!

Automation for the people

In Jira there is a fixed role “project lead” for each single project which is assigned in the projects configuration. The only default use of this role is as the default assigne of created issues. The problem here is that you can’t change this behaviour (see http://jira.atlassian.com/browse/JRA-3523).

So if you assign “project lead” to the administrative project lead, the mailbox of this person will be filled up with messages on issue creation. This might not be exactly what you wanted.

What possibilities are there to avoid such a problem? (Some only for Jira Enterprise).

  1. Using the role “project lead” as a proxy between customers and project team members. In this case don’t use the role “project lead” in your permission scheme, define your own role like “project manager” or similiar and use this instead. And:
    1. Assign “project lead” to a moderator or support team member.
    2. Assign “project lead” to a dummy user with a catch-all IMAP mailbox.
  2. Allow unassigned issues: Check admin -> global-settings for “allow unassigned issues” and set this in the project configuration as default
  3. You can configure a different default assignee for each component of a project. See http://www.atlassian.com/software/jira/docs/latest/component_management.html
  4. Edit you current Notification Scheme and remove Current Assignee from Notification on Issue Created.

Netbeans’ help browser doesn’t react on font size settings (User Startup Settings ). This is an old issue which you can study here . Actually all to do is to override the default CSS settings in:
netbeans-6.0/ide8/docs/org/netbeans/modules/usersguide/ide.css
Download a workaround version ide.css.

I had to edit this file to fit my needs (on KDE, ubuntu):

body {
font-size: 15pt;
font-family:  Arial, Helvetica, SansSerif, sans-serif;
...

To see the changes you do not need to restart the IDE or something like that. Just go to another help page.

Netbeans 6.5

Here you the appropriate .css file is ide10/docs/org/netbeans/modules/usersguide/ide.css .

An example for a possible adaptation:

body  {font-size: 15pt;
	font-family: SansSerif, Arial, Helvetica, sans-serif;
	margin-left: 5;
	margin-right: 5;
	color: Black;
	background-color: White}
 
p  {font-size: 15pt;
     margin-top: 5;
     margin-bottom: 5}
 
....

It seems to me that there are basically two ways to get started with the examples of the Jersey distribution (see also Java Webservices – Relationship between JAX-WS, JAX-RS, Metro and Jersey) in Glassfish.

First you can use the Glassfish’s update center executing:
$path/updatecenter/bin$ ./updatetool
like described for example in Japod’s blog.
But currently only version 0.4 is available here.

The other way is : download and unzip the newest version of Jersey. In the root directory of the unzipped archive you will find an
ant script, execute it like this:
$path/jersey-0.5-ea$ ant -f jersey-on-glassfish.xml -Dgf.home=$HOME/bin/glassfish install
with appropriate gf.home property supplied.

If you get an error message similiar to this one:
BUILD FAILED
/home/kostja/Development/jersey/jersey-0.5-ea/jersey-on-glassfish.xml:103: The following error occurred while executing this line:
/home/kostja/Development/jersey/jersey-0.5-ea/jersey-on-glassfish.xml:43: /home/kostja/Development/jersey/jersey-0.5-ea/examples/GlassfishDB not found.

which means some example is missing in the distribution, edit the jersey-on-glassfish.xml file, comment out the matching lines:

     <!-- copy-example example.name="GlassfishDB"/>
     <update-nb-prop nb.prop.file="${gf.home}/jersey/examples/GlassfishDB/nbproject/project.properties"/ -->

Be aware! This procedures will only install the examples and won’t add auto-magically the jersey jars to Glassfish’s runtime classpath. So
you have to take care by yourself to include the jars to the build target, see the provided examples for the jars needed:

glassfish/jersey/examples/SimpleServlet/nbproject/build-impl.xml:

    <target depends="init" name="library-inclusion-in-archive" unless="dist.ear.dir">
        <copy file="${file.reference.activation.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jsr250-api.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.persistence-api-1.0.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.asm-3.1.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jsr311-api.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jersey.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
    </target>

glassfish/jersey/examples/SimpleServlet/nbproject/project.properties:

# some of this properties are set by jersey-on-glassfish.xml
# during installation
ashome.jersey.lib.dir=../../lib
ashome.lib.dir=../../../lib
...
file.reference.jsr250-api.jar=${ashome.jersey.lib.dir}/jsr250-api.jar
...
file.reference.jersey.jar=${ashome.jersey.lib.dir}/jersey.jar
...
javac.classpath=${file.reference.servlet.jar}\:${file.reference.activation.jar}\:${file.reference.jsr250-api.jar}\:
${file.reference.persistence-api-1.0.jar}\:${file.reference.asm-3.1.jar}\:${file.reference.jsr311-api.jar}\:
${file.reference.jersey.jar}

Command line utilities are great for one-pointed tasks or for batch processing, but sometimes you just want to browse around and quickly play with the options. For that purpose I prefer to use GUI-tools.

In ubuntu you can use the svn-workbench as an GUI-Client written in python to subversion repositories. I am using KDE, so installing kdesvn (also see kde-apps.org) gives me a repository access and management functions right in my Konqueror file browser by using addresses like: ksvn+https://rcs.somehost.de/rep1. In this way you can work in repositories without explicit checkout. The only draw back appears in case you want to copy directories. Due to Konquerors way of copying/moving with KIO you will be asked for log messages for each single subdir or file recursively. To avoid being asked for log messages every time start kdesvn, go to Main Menu Settings – Configure Kdesvn – KIO/Commandline – check KIO operations use standard logmessage .

Kdesvn adds extra functions in Konqueror’s context menu : RightClick – Actions – Subversion . Kate and QuantaPlus Integration is also provided by kdesvn.

BTW: Subclipse is a good svn GUI client implementation as well, but requires an Eclipse installation.

To control background child processes from a shell script you want to know the PID or job-id of the child. Here are some ways to do this:

First starting a background process echoes the job-id and pid of the process:
$ emacs &
[1] 15393

The PID of the last command set to run in the background by the current shell or script is stored in $! variable:
$ echo $!
15393

This you could find out by using the jobs command:
$ PID=`jobs -l | sed -n 's/^\[[0-9]*\] *+ *\([0-9]*\) .*$/\1/p'`; echo $PID
using the fact that the last current (last started) job will be marked by a + in
jobs -l output.
To terminate the current job you don’t need the explicit job-id:
$ kill %+
The exit status will be stored in the $? variable.
Read more in the Advanced Bash-Scripting Guide:Job Control Commands

To see your currently used user directory go to Help – About – Details.

To override the default settings in the file netbeans-install-dir/etc/netbeans.conf you can create a directory etc/ in /home/myhome/.netbeans/6.0 ( with 6.0 being the version number of your NetBeans installation). Then use the default netbeans.conf file from netbeans-install-dir/etc/netbeans.conf as a template to create a user specific settings in /home/myhome/.netbeans/6.0/etc/netbeans.conf (see How do I make my custom startup parameters permanent? ).

For instance you could change you user name (used in templates):
# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-XX:PermSize=64m -J-XX:MaxPermSize=200m -J-Xverify:none -J-Duser.name='My Name' -J-Dapple.laf.useScreenMenuBar=true -J-Dswing.aatext=true --fontsize 14"

(… or use Tools -> Template Manager -> User configuration properties .)

Read more about startup parameter for Netbeans IDE in FaqStartupParameters .

The Problem: There are a bunch of servers I need to login almost daily using ssh, all with different login names and passwords. I also want to secure copy data between them and access one server from another.

The Wish: One password for a group of servers to type in only once when I login into the local X-session.

A Solution: Set up passphrase protected private and public keys. Make ssh-agent run your window manager und type the keys passphrases into a pass-phrase dialog triggered by ssh-add on window managers startup. Use the ssh-agents forwarding features to forward local ssh-identities between remote hosts. Of course you
also need to configure your public key on the remote hosts.

So it goes:

  1. Install x11-ssh-askpass (ubuntu package ssh-askpass).
  2. Create key pairs and protect them by a (hopefully) strong passphrase:
    ~/.ssh$ mkdir mykeys
    ~/.ssh$ cd mykeys
    ~/.ssh/mykeys$ ssh-keygen -t dsa
    Generating public/private dsa key pair.
    Enter file in which to save the key (/home/me/.ssh/id_dsa): /home/me/.ssh/mykeys/gebewau_dsa
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/me/.ssh/mykeys/gebewau_dsa.
    Your public key has been saved in /home/me/.ssh/mykeys/gebewau_dsa.pub.
    The key fingerprint is:
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    ~/.ssh/mykeys$ chmod 600 *

    To use the keys it is necessary to set strict permission on the files, otherwise ssh won’t accept them.
  3. Edit your .xinitrc (on ubuntu ssh-agent is running by default, see post SSH on Ubuntu , SHH-Agent Is Running per Default), add this line:
    #!/bin/bash
    exec ssh-agent sh -c '{ for f in /home/kostja/.ssh/mykeys/*_dsa ; do ssh-add $f </dev/null ; done ; } && exec startkde'

    This will start ssh-agent once to use in all sessions. ssh-agent will start a shell (bash in my case) which in turn executes the command enclosed within ‘ ‘. Foreach private key in mykeys directory there will appear a passphrase dialog triggered by ssh-add . The passphrase dialog is provided by x11-ssh-askpass. For this ssh-add reads the SSH_ASKPASS environment variable (in ubuntu it seems not to be neseccary) which you can set in your ~/.bashrc file :

    # Set the location of the x11-ssh-askpass binary
    export SSH_ASKPASS=/usr/local/libexec/x11-ssh-askpass

    On success – startkde will be executed. To see how to run the session independently from the success of the passphrase dialog read the description in Simplifying SSH access using an agent

  4. Configure your ssh client to use agent forwarding by creating and editing the configuration file .ssh/config. An example:
    # selfmade OpenSSH ssh client configuration file will
    # override the system config file in /etc/ssh/ssh_config
    #
    # Config options are unioned over all matching host
    # entries, first config option wins

    Host xxx.gebewau.de
    # with this user setting you only have to type
    # ssh xxx.gebewau.de to connect
    User me

    Host *.gebewau.de
    # don't need this if identity is added by ssh-add
    # IdentityFile ~/.ssh/mykeys/gebewau_dsa
    # next two settings have security issues, see man:ssh_config
    ForwardAgent yes
    ForwardX11 yes

    Host *
    CheckHostIP yes
    Compression yes
    StrictHostKeyChecking ask
    SetupTimeOut 300
    ServerAliveInterval 300

  5. Install your identity.pub in a remote machine’s authorized_keys. You can use scp to copy your public key file to the remote server followed by:
    cat gebewau_dsa.pub >> .ssh/authorized_keys
    Or you use
    ssh-copy-id -i ~/.ssh/mykeys/gebewau_dsa.pub user@xxx.gebewau.de
    this will also set the right permissions in the servers ~/.ssh directory.

To use AgentForwarding you have to use ssh -A or enable forwarding in .ssh/config for the local client and for the client on the bridge server. The bridge servers client will try to use your username you used to log into it. So the set appropriate user names in .ssh/config or use : ssh forwardeduser@over-the-bridge.gebewau.de .

Note about adding several matching identities with ssh-add:
If you have several identities which can access the same host then ssh will only use the first matching one added by ssh-add. Even using command line option -i won’t override it.
So if you have two SSH identities valid on an SSH server, you better don’t load either identity into an agent. Otherwise, one of those identities will be unable to access that server. You may also try to set the config option IdentitiesOnly in your clients config file.

Security remark regarding forwarding found in man:ssh_config:
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

Links:

The eSciDoc Infrastructure is published now under the CDDL-Licence .

eSciDoc uses the Fedora Repository as backend to store the digital objects and runs within a JBoss Application Server. Although it is still beta the main features are implemented and the install works without bigger problems now.

Next Page »