Logon with a long session timeout?

[Stephen Crawley]

My use-case is that I'm running a TCL script from the Unix command prompt using the "mfcommand" script.  If the script takes too long, I suspect that the steps at the end will fail because the authentication token that is being used has expired.

  - Is it possible to get mfcommand (i.e. aterm.jar) to logon to the mediaflux server with a long session expiry; i.e. longer than the configured default session expiry?

  - Or ... are my suspicions unfounded?

[Brian O'Connor]

Hi Stephen

As I understand it the session should not time out if you are doing something... i.e its 30mins of inactivity.

So you may not have a problem.

There is a new security token infrastucture that may help.....

What is the context?

--
You received this message because you are subscribed to the Google Groups "mediaflux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mediaflux+...@googlegroups.com.
To post to this group, send email to medi...@googlegroups.com.
Visit this group at http://groups.google.com/group/mediaflux.
For more options, visit https://groups.google.com/d/optout.

-- 
Brian O'Connor

[Jason Lohrey]

Also, if your script is doing something — i.e. calling a service, then your session will not time out.

--
You received this message because you are subscribed to the Google Groups "mediaflux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mediaflux+...@googlegroups.com.
To post to this group, send email to medi...@googlegroups.com.
Visit this group at http://groups.google.com/group/mediaflux.
For more options, visit https://groups.google.com/d/optout.

JASON LOHREY

Chief Technical Officer

ARCITECTA

5/26-36 High Street, Northcote

Victoria, Australia 3070

T:+61 3 9029 3437

M:+61 418 364 941

F:+61 3 9005 2876

http://www.arcitecta.com

Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to email or messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Arcitecta shall be understood as neither given nor endorsed by it.

[Stephen Crawley]

This is what the TCL script is doing:

server.database.backup :url file:///$dir/database
server.database.lock :action abort \
    :msg "The Mediaflux database and stores are being backed up"
exec /opt/mflux/bin/tar_gz_wrapper $dir pssd
exec /opt/mflux/bin/tar_gz_wrapper $dir dicom
server.database.unlock

There is no other output to tell me which step in the script is hitting the timeout.  But based on what Jason said, I'm guessing that it is the final "unlock" ... and that the "exec" steps don't count as activity for the purposes of keeping the session alive.

Here is the exception:

arc.shell.Shell$ExScriptExecute: executing script: /opt/mflux/config/backup.tcl
[line: 6]: arc.mf.client.ServerClient$ExSessionInvalid: Session is invalid or ti
med out.
        at arc.fd.b(SourceFile:1850)
        at arc.fd.a(SourceFile:1786)
        at arc.dW.a(SourceFile:69)
        at arc.dV.a(SourceFile:59)
        at arc.shell.Shell$TclCmdHandler.a(SourceFile:1158)
        at arc.FU.a(SourceFile:865)
        at arc.FU.a(SourceFile:1278)
        at arc.FE.b(SourceFile:2247)
        at arc.FE.c(SourceFile:2301)
        at arc.shell.Shell.a(SourceFile:499)
        at arc.shell.Shell.a(SourceFile:481)
        at arc.hR.a(SourceFile:148)
        at arc.hR.a(SourceFile:98)
        at arc.mf.command.Execute.a(SourceFile:606)
        at arc.mf.command.Execute.a(SourceFile:68)
        at arc.mf.command.Execute.main(SourceFile:62)

        at arc.shell.Shell.a(SourceFile:534)
        at arc.shell.Shell.a(SourceFile:481)
        at arc.hR.a(SourceFile:148)
        at arc.hR.a(SourceFile:98)
        at arc.mf.command.Execute.a(SourceFile:606)
        at arc.mf.command.Execute.a(SourceFile:68)
        at arc.mf.command.Execute.main(SourceFile:62)

[Jason Lohrey]

Hi Stephen,

It will be the “server.database.unlock” — the behaviour is as expected.  As far as the server is concerned the process interacted to server.database.lock… (indicating the session is in use) then went off somewhere for more than the session timeout time (30 minutes), and then came back.. after the session was reaped.

The right way to do this is to use mfcommand or aterm with a configuration file:

E.g.:

java -Dmf.cfg=/path/to/config -jar aterm.jar server.database.backup ..

You can wrap the aterm.jar in an aterm script (shipped with Mediaflux) — see below:

and then:

aterm server.database.backup

aterm server.database.lock

do long running stuff

aterm server.database.unlock

The difference it that, each aterm request establishes a new connection and session.

Jason

#!/bin/sh
#
# Aterm shell commands - enables the aterm command line terminal.
#
# Usage:
#
#   ./aterm
#   ./aterm <service> 
#   ./aterm <script>
#

# See if the location of aterm has been set.
if [ -z $MFLUX_ATERM ]
then {

     # If not, then assume relative to the location of this binary
     # which is distributed one level below the aterm.jar
     MFLUX_ATERM=`dirname "$0"`/../aterm.jar

}
fi

# Have we been supplied with the location of a configuration file
# that specifies the host, etc. If so, use that.
#
# This file has the form:
#
#  host=<host>
#  port=<port>
#  transport=[http|https]
#
#  domain=<domain>
#  user=<user>
#  password=<password>
#
#  All are optional - if not specified, then aterm will as for them.
#

if [ -z $MFLUX_CFG ]
then {

# Execute without configuration. Will be prompted for connection and 
# credential details
java -jar $MFLUX_ATERM nogui $*

     } else {

        # Use the supplied configuration
        java -jar -Dmf.cfg=$MFLUX_CFG $MFLUX_ATERM nogui $*

     }
fi

[Stephen Crawley]

On Wednesday, August 20, 2014 12:41:56 PM UTC+10, Jason Lohrey wrote:

Hi Stephen,

It will be the “server.database.unlock” — the behaviour is as expected.  As far as the server is concerned the process interacted to server.database.lock… (indicating the session is in use) then went off somewhere for more than the session timeout time (30 minutes), and then came back.. after the session was reaped.

The right way to do this is to use mfcommand or aterm with a configuration file:

Well I'm already using mfcommand to run that TCL script.

So really, the best solution is to call mfcommand / aterm multiple times.

IIRC, the reason I was doing it with TCL calling `exec` was that I thought I'd be able to get exclusive access AND a database lock that released automatically.  The latter turned out not to be the case.  So my `exec` callback approach is doing more harm than good.

Sigh

[Jason Lohrey]

Yes, that’s right — call multiple times. 

I can see why you have done it that way — it’s quite reasonable, but that mode does not keep the session alive if you are executing client-side external operations. A long lived operation in the server would however, keep the session alive.

Alternatively, you could actually execute your script in the server context with:

script.execute

or

asset.script.execute

The destination paths would need to be accessible to the server.

Jason

--
You received this message because you are subscribed to the Google Groups "mediaflux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mediaflux+...@googlegroups.com.
To post to this group, send email to medi...@googlegroups.com.
Visit this group at http://groups.google.com/group/mediaflux.
For more options, visit https://groups.google.com/d/optout.