Multiple Hudson instances on one machine

Hi,

We've installed multiple instances of Hudson on a single LINUX server with out problems. We

1) created a new user for each instance of Hudson we required
2) installed a new version of Tomcat and Hudson for each user.

Hudson's home directory is a sub directory of the users home directory, so there were no conflicts  :-)

I couldn't say how you'd do this on a Windows Server.

The only problem we had was when we needed to allocate ports when running unit tests. If two different Hudson instances wanted exclusive access to use the same port at the same time then we got false failures of some of our tests.

Perl System and `` and exec

system LIST
system PROGRAM LIST
Does exactly the same thing as exec LIST , except that a fork is done first and the parent process waits for the child process to exit.
-If there is more than one argument in LIST, or if LIST is an array with more than one value, starts the program given by the first element of the list with arguments given by the rest of the list.
-If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is /bin/sh -c on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to execvp , which is more efficient.

 `` use shell always

Process

http://www.win.tue.nl/~aeb/linux/lk/lk-10.html 

10.1 Processes

Creation

A new process is traditionally started using the fork() system call:

pid_t p;

p = fork();
if (p == (pid_t) -1)
        /* ERROR */
else if (p == 0)
        /* CHILD */
else
        /* PARENT */

This creates a child as a duplicate of its parent. Parent and child are identical in almost all respects. In the code they are distinguished by the fact that the parent learns the process ID of its child, while fork() returns 0 in the child. (It can find the process ID of its parent using the getppid() system call.)

Termination

Normal termination is when the process does

exit(n);

or

return n;

from its main() procedure. It returns the single byte n to its parent. Abnormal termination is usually caused by a signal.

Collecting the exit code of child process

The parent does

pid_t p;
int status;

p = wait(&status);

The parent will suspend till one of its child process terminates, and collects two bytes:

A process that has terminated but has not yet been waited for is a zombie. It need only store these two bytes: exit code and reason for termination.

On the other hand, if the parent dies first, init (process 1) inherits the child and becomes its parent.

Signals

Stopping

Some signals cause a process to stop: SIGSTOP (stop!), SIGTSTP (stop from tty: probably ^Z was typed), SIGTTIN (tty input asked by background process), SIGTTOU (tty output sent by background process, and this was disallowed by stty tostop).
Apart from ^Z there also is ^Y. The former stops the process when it is typed, the latter stops it when it is read.
Signals generated by typing the corresponding character on some tty are sent to all processes that are in the foreground process group of the session that has that tty as controlling tty. (Details below.)
If a process is being traced, every signal will stop it.

Continuing

SIGCONT: continue a stopped process.

Terminating

SIGKILL (die! now!), SIGTERM (please, go away), SIGHUP (modem hangup), SIGINT (^C), SIGQUIT (^\), etc. Many signals have as default action to kill the target. (Sometimes with an additional core dump, when such is allowed by rlimit.) The signals SIGCHLD and SIGWINCH are ignored by default. All except SIGKILL and SIGSTOP can be caught or ignored or blocked. For details, see signal(7).

10.2 Process groups

Every process is member of a unique process group, identified by its process group ID. (When the process is created, it becomes a member of the process group of its parent.) By convention, the process group ID of a process group equals the process ID of the first member of the process group, called the process group leader. A process finds the ID of its process group using the system call getpgrp(), or, equivalently, getpgid(0). One finds the process group ID of process p using getpgid(p).
One may use the command ps j to see PPID (parent process ID), PID (process ID), PGID (process group ID) and SID (session ID) of processes. With a shell that does not know about job control, like ash, each of its children will be in the same session and have the same process group as the shell. With a shell that knows about job control, like bash, the processes of one pipeline. like

% cat paper | ideal | pic | tbl | eqn | ditroff > out

form a single process group.

Creation

A process pid is put into the process group pgid by

setpgid(pid, pgid);

If pgid == pid or pgid == 0 then this creates a new process group with process group leader pid. Otherwise, this puts pid into the already existing process group pgid. A zero pid refers to the current process. The call setpgrp() is equivalent to setpgid(0,0).

Restrictions on setpgid()

The calling process must be pid itself, or its parent, and the parent can only do this before pid has done exec(), and only when both belong to the same session. It is an error if process pid is a session leader (and this call would change its pgid).

Typical sequence

p = fork();
if (p == (pid_t) -1) {
        /* ERROR */
} else if (p == 0) {    /* CHILD */
        setpgid(0, pgid);
        ...
} else {                /* PARENT */
        setpgid(p, pgid);
        ...
}

This ensures that regardless of whether parent or child is scheduled first, the process group setting is as expected by both.

Signalling and waiting

One can signal all members of a process group:

killpg(pgrp, sig);

One can wait for children in ones own process group:

waitpid(0, &status, ...);

or in a specified process group:

waitpid(-pgrp, &status, ...);

Foreground process group

Among the process groups in a session at most one can be the foreground process group of that session. The tty input and tty signals (signals generated by ^C, ^Z, etc.) go to processes in this foreground process group.
A process can determine the foreground process group in its session using tcgetpgrp(fd), where fd refers to its controlling tty. If there is none, this returns a random value larger than 1 that is not a process group ID.
A process can set the foreground process group in its session using tcsetpgrp(fd,pgrp), where fd refers to its controlling tty, and pgrp is a process group in the its session, and this session still is associated to the controlling tty of the calling process.
How does one get fd? By definition, /dev/tty refers to the controlling tty, entirely independent of redirects of standard input and output. (There is also the function ctermid() to get the name of the controlling terminal. On a POSIX standard system it will return /dev/tty.) Opening the name of the controlling tty gives a file descriptor fd.

Background process groups

All process groups in a session that are not foreground process group are background process groups. Since the user at the keyboard is interacting with foreground processes, background processes should stay away from it. When a background process reads from the terminal it gets a SIGTTIN signal. Normally, that will stop it, the job control shell notices and tells the user, who can say fg to continue this background process as a foreground process, and then this process can read from the terminal. But if the background process ignores or blocks the SIGTTIN signal, or if its process group is orphaned (see below), then the read() returns an EIO error, and no signal is sent. (Indeed, the idea is to tell the process that reading from the terminal is not allowed right now. If it wouldn't see the signal, then it will see the error return.)
When a background process writes to the terminal, it may get a SIGTTOU signal. May: namely, when the flag that this must happen is set (it is off by default). One can set the flag by

% stty tostop

and clear it again by

% stty -tostop

and inspect it by

% stty -a

Again, if TOSTOP is set but the background process ignores or blocks the SIGTTOU signal, or if its process group is orphaned (see below), then the write() returns an EIO error, and no signal is sent.

Orphaned process groups

The process group leader is the first member of the process group. It may terminate before the others, and then the process group is without leader.
A process group is called orphaned when the parent of every member is either in the process group or outside the session. In particular, the process group of the session leader is always orphaned.
If termination of a process causes a process group to become orphaned, and some member is stopped, then all are sent first SIGHUP and then SIGCONT.
The idea is that perhaps the parent of the process group leader is a job control shell. (In the same session but a different process group.) As long as this parent is alive, it can handle the stopping and starting of members in the process group. When it dies, there may be nobody to continue stopped processes. Therefore, these stopped processes are sent SIGHUP, so that they die unless they catch or ignore it, and then SIGCONT to continue them.
Note that the process group of the session leader is already orphaned, so no signals are sent when the session leader dies.
Note also that a process group can become orphaned in two ways by termination of a process: either it was a parent and not itself in the process group, or it was the last element of the process group with a parent outside but in the same session. Furthermore, that a process group can become orphaned other than by termination of a process, namely when some member is moved to a different process group.

10.3 Sessions

Every process group is in a unique session. (When the process is created, it becomes a member of the session of its parent.) By convention, the session ID of a session equals the process ID of the first member of the session, called the session leader. A process finds the ID of its session using the system call getsid().
Every session may have a controlling tty, that then also is called the controlling tty of each of its member processes. A file descriptor for the controlling tty is obtained by opening /dev/tty. (And when that fails, there was no controlling tty.) Given a file descriptor for the controlling tty, one may obtain the SID using tcgetsid(fd).
A session is often set up by a login process. The terminal on which one is logged in then becomes the controlling tty of the session. All processes that are descendants of the login process will in general be members of the session.

Creation

A new session is created by

pid = setsid();

This is allowed only when the current process is not a process group leader. In order to be sure of that we fork first:

p = fork();
if (p) exit(0);
pid = setsid();

The result is that the current process (with process ID pid) becomes session leader of a new session with session ID pid. Moreover, it becomes process group leader of a new process group. Both session and process group contain only the single process pid. Furthermore, this process has no controlling tty. The restriction that the current process must not be a process group leader is needed: otherwise its PID serves as PGID of some existing process group and cannot be used as the PGID of a new process group.

Getting a controlling tty

How does one get a controlling terminal? Nobody knows, this is a great mystery.
The System V approach is that the first tty opened by the process becomes its controlling tty.
The BSD approach is that one has to explicitly call

ioctl(fd, TIOCSCTTY, ...);

to get a controlling tty. Linux tries to be compatible with both, as always, and this results in a very obscure complex of conditions. Roughly:
The TIOCSCTTY ioctl will give us a controlling tty, provided that (i) the current process is a session leader, and (ii) it does not yet have a controlling tty, and (iii) maybe the tty should not already control some other session; if it does it is an error if we aren't root, or we steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that (i) the current process is a session leader, and (ii) it does not yet have a controlling tty, and (iii) the tty does not already control some other session, and (iv) the open did not have the O_NOCTTY flag, and (v) the tty is not the foreground VT, and (vi) the tty is not the console, and (vii) maybe the tty should not be master or slave pty.

Getting rid of a controlling tty

If a process wants to continue as a daemon, it must detach itself from its controlling tty. Above we saw that setsid() will remove the controlling tty. Also the ioctl TIOCNOTTY does this. Moreover, in order not to get a controlling tty again as soon as it opens a tty, the process has to fork once more, to assure that it is not a session leader. Typical code fragment:

        if ((fork()) != 0)
                exit(0);
        setsid();
        if ((fork()) != 0)
                exit(0);

See also daemon(3).

Disconnect

If the terminal goes away by modem hangup, and the line was not local, then a SIGHUP is sent to the session leader. Any further reads from the gone terminal return EOF. (Or possibly -1 with errno set to EIO.)
If the terminal is the slave side of a pseudotty, and the master side is closed (for the last time), then a SIGHUP is sent to the foreground process group of the slave side.
When the session leader dies, a SIGHUP is sent to all processes in the foreground process group. Moreover, the terminal stops being the controlling terminal of this session (so that it can become the controlling terminal of another session).
Thus, if the terminal goes away and the session leader is a job control shell, then it can handle things for its descendants, e.g. by sending them again a SIGHUP. If on the other hand the session leader is an innocent process that does not catch SIGHUP, it will die, and all foreground processes get a SIGHUP.

10.4 Threads

A process can have several threads. New threads (with the same PID as the parent thread) are started using the clone system call using the CLONE_THREAD flag. Threads are distinguished by a thread ID (TID). An ordinary process has a single thread with TID equal to PID. The system call gettid() returns the TID. The system call tkill() sends a signal to a single thread.
Example: a process with two threads. Both only print PID and TID and exit. (Linux 2.4.19 or later.)

% cat << EOF > gettid-demo.c
#include <unistd.h>
#include <sys/types.h>
#define CLONE_SIGHAND   0x00000800
#define CLONE_THREAD    0x00010000
#include <linux/unistd.h>
#include <errno.h>
_syscall0(pid_t,gettid)

int thread(void *p) {
        printf("thread: %d %d\n", gettid(), getpid());
}

main() {
        unsigned char stack[4096];
        int i;

        i = clone(thread, stack+2048, CLONE_THREAD | CLONE_SIGHAND, NULL);
        if (i == -1)
                perror("clone");
        else
                printf("clone returns %d\n", i);
        printf("parent: %d %d\n", gettid(), getpid());
}
EOF
% cc -o gettid-demo gettid-demo.c
% ./gettid-demo
clone returns 21826
parent: 21825 21825
thread: 21826 21825
%

Kill parent and child process

No, child processes are not necessarily killed when the parent is killed. On UNIX, there is no enforced relation between parent and child process's lifetimes. Process will only terminate when it calls exit() or receives unhandled signal for which default action is to terminate.

Exceptions:
1. If the child has a pipe open which it is writing to and the parent is reading from, it will get a SIGPIPE when it next tries to write to the pipe, for which the default action is to kill it. That is often what happens in practice.

2. Entire "foreground process group" in a "controlling terminal" can receive SIGINT, SIGQUIT, etc. signals when user hits ctrl-C, ctrl-\, etc. on that terminal. Specific behaviour is partly implemented by login shell (with help from tty driver), details may be quite complicated: look here and here

You don't say if the tree you want to kill is a single process group. (This is often the case if the tree is the result of forking from a server start or a shell command line.) You can discover process groups using GNU ps as follows:

 ps x -o  "%p %r %y %x %c "

If it is a process group you want to kill, just use the kill(1) command but instead of giving it a process number, give it the negation of the group number. For example to kill every process in group 5112, use kill -TERM -5112.

To kill a process tree recursively, use killtree.sh: #!/bin/bash killtree() { local _pid=$1 local _sig=${2-TERM} for _child in $(ps -o pid --no-headers --ppid ${_pid}); do killtree ${_child} ${_sig} done kill -${_sig} ${_pid} } if [ $# -eq 0 -o $# -gt 2 ]; then echo "Usage: $(basename $0) <pid> [signal]" exit 1 fi killtree $@

 

Perl Open File and Pipe

open(FH, "<", "input.txt")

1.FH="input.txt"

2.FH is <, which means FH is (file) source whose content provides input(similar as stdin) to current program

3.if >, which means FH is a file accepting the output of current program

open(FH, "-|", "input.sh") 

1.FH="input.txt"

2.FH is <, which means is a (command) source whose output provides input(similar to stdin) to current program

3.if |-, >, which means FH is a command whose stdin accepts the output of current program


 

Fedora 15 no scroll bar in user login screen

Use KDE's kdm as login greeter

To put kdm into effect, I put create and DISPLAYMANAGER into file /etc/sysconfig/desktop, and also set the default session manager by setting DESKTOP, as follows:

DISPLAYMANAGER="KDE"
DESKTOP="KDE"

Perl Timeout | 陈钢的博客

Timeout | 陈钢的博客

【 Perl 】给所有的shell程序全加上timeout参数

2011年3月15日

1 条评论

有些程序自带–timeout参数，比如rsync，这样很好。
但是有些程序就很不乖，比如ffmpeg，自己不会超时退出，这很不好。
让我们用Perl把所有的命令都加上超时退出的功能——

01	#! /usr/bin/env perl

02	use POSIX qw(strftime WNOHANG);

03

04	#check input

05	my $timeout = shift @ARGV;

06	my ($secs) = $timeout =~ /--timeout=(\d+)$/;

07	unless($secs)

08

{

09	print "Usage: ./timeout --timeout=[SECONDS] [COMMAND] \n";

10

exit -1;

11

}

12

13	#fork and exec

14	my $status = 0;

15	$SIG{CHLD} = sub { while(waitpid(-1,WNOHANG)>0){ $status = -1 unless $? == 0; exit $status;} };

16	$0 = 'timeout hacked ' . $ARGV[0];

17	defined (my $child = fork);

18	if($child == 0)

19

{

20	my $cmd = join ' ', @ARGV;

21	exec($cmd);

22

}

23	$SIG{TERM} = sub { kill TERM => $child };

24	$SIG{INT} = sub { kill INT => $child };

25

26	#kill when timeout

27	sleep $secs;

28	$status = -1;

29	kill TERM => $child;

30	sleep 1 and kill INT => $child if kill 0 => $child;

31	sleep 1 and kill KILL => $child if kill 0 => $child;

32	exit $status;

然后如下就可以让任意的命令超时退出了（这里执行的命令是“sleep 500”）——

./timeout.pl --timeout=3 sleep 500 

实践 perl, timeout

【 Perl 】如何简单控制perl脚本超时

2009年11月3日

没有评论

1

eval

2

{

3	local $SIG{ALRM} = sub { die "alarmn" };

4	alarm $config{'perl'}{'time_out'};

5	do $plugin;

6

alarm 0;

7

};

Web Based Software Vs Standalone Solution - Nairaland

ky!! Let me start by defending web-based application to standalone. We have what we called FAT-CLIENT and THIN-CLIENT. Basically, it is used to depict if a web application is going to off-load its load to the server (thin client) or if the web application is going to do all the heavy work i.e sql statements and managing data base connection (fat client)

Before the birth of Server side computing applications (Standalone) use to be fat client, because all the programming and processing power it built-in in the standalone. That is why it was called standalone, it stands on its own. It does NOT depend on any other infrastructure for processing.

But there was problems with this implementation:

1. Maintenance issue
2. Scalability
3. Deployment
4. Security

Maintenance

Imagine you have 500 staffs using PC with standalone apps installed in them and there was a little requirement change. You are in trouble, it will take you days to walk around the office uninstall the old one and install the new one, dreadful.

Scalability

When user grow it does not manage database access very well since all fat client have their data access routine. No single point of reference to database manager. If Microsoft changes its OS (Operating System) to new one, which he does every year, i.e. extending the 32bit operating system API to 64bits operating system. You have to rewrite all you standalone else your company would be stuck with windows 95 haha.

Deployment

Like I said how are you going to install a software to 500 PC's when there is a need for requirement changes often frequent.

Mind you web application can be fat client, well it use to be. With the advent of MVC (Model View Controller) and other n-tier architecture deployment infrastructure, it was evident that thin-client will live for a long time, not only it has:

1. One single point of deployment (url)
2. Single point of access (url)
3. Single point of maintenace (web server i.e apache, xmapp)
4. It Scales well when users increase (Buy more server)
5. If microsoft change it OS get the newer apache from apache website and take all your .jpg, .htm, html, .php, .php3 etc into the new apache

There are many reason why you should consider web application to standalone. Mind you standalone could be thin-client but the issue of deploying 500 PC or even more depending on the company is not a joke, especially when you have to do it every week because of requirements changes.

Security Also, remember that one of the most important issues with thin client is the application of security policy. Web apps has a single point to apply security policy.

Controlled central login, authentication, authorization and verification. These policies are kept under the web apps and furthermore you can apply web encryption algorithm by using a Cipher strength in excess of 128bits. You can control and map IP to specific web apps etc

These serious issues could not be achieved in standalone apps, where all the security is encoded on each apps. The only remote correlation for standalone is database access. Even then apps do not know what each one is doing. It could be difficult to achieve a real-time processing using standalone. The only way could be batch processing.

Linux 用Expect创建自动应答脚本

Linux 下的expect程序根据一个交互程序 的要求进行自动输入。比如自动登入另外一台机器，比如自动回答各种boring的问题等等。 下面就是一个自动登入的脚本

Step1： expect脚本
[]$ cat ~/autologin
#!/usr/bin/expect
set psword [exec pswsh VwFcef ]
set timeout 5
spawn your login program
expect "password" { send "$psword\r" } \
        timeout   { send "Wait Too Long, Bye\r" }
expect eof


注意：
pswsh 是解密脚本（show below）
VwFcef 是加密后的密码
your login program 是要你输入密码程序
expect oef 必须的

Step2:解密脚本
[linfa@babbage os]$ cat  ~/bin/pswsh
#!/bin/sh
dencrys()
{
  sin=$1
  sout=`echo $sin | tr 0-9a-zZ-A a-zA-Z0-9`
}
 senc=$1
 dencrys $senc
 echo $sout

Step3 运行expect脚本
[]$ autologin
spawn your login program
Enter password:
User logged in.

注意，一定要设置最小的权限给这两个脚本，不要给被人看

X-Forwarding - Gentoo Linux Wiki

X-Forwarding - Gentoo Linux Wiki



SSH Server Setup
Add the following line to /etc/ssh/sshd_config on sshd server

X11Forwarding yes ...

and reload sshd by /etc/init.d/sshd reload


Note: If you don't setup this, you may get receiving the error messages

xterm Xt error: Can't open display: your_client_name:0.0

Note: Another explanation for a Can't open display error is that the server is configured not to listen to tcp connections. Check the server is listening by doing

netstat -plant ¦ grep 6000.

Client Setup
The client does not need any extra configuration. In order to connect to the server and use port forwarding, issue one of the following commands:

ssh user@remotebox -X
ssh user@remotebox -Y

ssh -X is also known as secure X11-forwarding: it's secure, i.e., the server(running sshd) won't be able to spy on the client (key-logging etc...) ssh -Y is also known as insecure X11-forwarding: it's not secure but it can run more applications

Note: see also 'BadAtom? BadWindow?' below for other cases where -Y may be needed instead of -X.

Also, you may wish to use compression to speed things up by.

ssh user@remotebox -YC
ssh user@remotebox -XC


Forwarding Automatically
If you wish to use X-forwarding without the -X argument, edit your /etc/ssh/ssh_config or ~/.ssh/config on ssh client machine and add an entry.

Host *  (选项“Host”只对能够匹配后面字串的计算机有效。“*”表示所有的计算机。)
ForwardX11 yes

Common Errors
Error 1: No xauth data Warning: No xauth data; using fake authentication data for X11 forwarding.

This usually happens when sshing from old unix machine to new linux machine, and maybe caused by different version of SSH on server and client. Simply disable ssh forwarding

Error 2: 
BadAtom? BadWindow?

Try adding to ~/.ssh/config on your ssh client machine 

ForwardX11Trusted yes

java 的矩阵操作比 c++ 快？

测试环境
AMD Athlon(tm) 64 FX-53 Processor
Memory: 8GB
gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
javac 1.6.0_20

测试结果

[~]$javac jmatrix.java
[~]$/usr/bin/time -p java jmatrix
java allsum=1.8658666E16
real 27.90
user 26.82
sys 0.17

[~]$g++ cmatrix.cpp
[~]$/usr/bin/time -p ./a.out
c++ allsum=1.86587e+16
real 70.89
user 69.99
sys 0.32

【g++ 优化】
[~]$g++ -O3 cmatrix.cpp
[~]$/usr/bin/time -p ./a.out

c++ allsum=1.86587e+16
real 28.90
user 28.74
sys 0.11

测试代码

=====================jmatrix.java==========================

public class jmatrix {

    final static int size=2000;

public static void main(String argv[]){

    double x[];

    double y[];

    double m[][];

    int i,j,k;

    double sum;

    double allsum;

    try{

        m=new double[size][size];

        y=new double[size];

        x=new double[size];

        

        for(i=0;i<size;i++){

            for(j=0;j<size;j++){

                m[i][j]=i+j;

            }

            x[i]=i;

            y[i]=0.0;

        }

        allsum=0.0;

        for(k=0;k<size;k++){

            for(i=0;i<size;i++){

                sum = 0.0;

                for(j=0;j<size;j++){

                    sum+=m[i][j]*x[j]+k;

                }

                y[i]=sum;

                allsum+=sum;

            }

        }

    }finally{

        //delete[] m;

        m=null;

        x=null;

        y=null;

        System.gc();

    }

    System.out.println("java allsum="+allsum);

}

}

=====================cmatrix.cpp==========================

#include <iostream>

using namespace std;

#define size 2000

int main(int argc, char** argv){

    double *x,*y;

    double (*m)[size];

    int i,j,k;

    double sum,allsum;

    m=new double[size][size];

    y=new double[size];

    x=new double[size];

    

    for(i=0;i<size;i++){

        for(j=0;j<size;j++){

            m[i][j]=i+j;

        }

        x[i]=i;

        y[i]=0.0;

    }

    allsum=0.0;

    for(k=0;k<size;k++){

        for(i=0;i<size;i++){

            sum = 0.0;

            for(j=0;j<size;j++){

                sum+=m[i][j]*x[j]+k;

            }

            y[i]=sum;

            allsum+=sum;

        }

    }

    delete[] m;

    delete[] x;

    delete[] y;

    cout<<"c++ allsum="<<allsum<<endl;

}

How FLEXlm Works

0. Document Source

http://www.vcpc.univie.ac.at/information/software/pgi/flexuser/TOC.htm

1. Flexlm components

1. License manager daemon: lmgrd

2. Vender daemon:

3. License file

4. Application program

2. License Request Process

1. application find out the lmgrd server and port from license file

2. application establish connection to lmgrd and tells what vender daemon it needs talk to

3. lmgrd send back the master vendor daemon and port

4. application send license request to vendor daemon

5. vendor daemon send grant or deny back to application

3. Install License Server

1. select the license server and get their hostid

2. give the hostid to your software vendor and get a license file

3. determine if you want to combine it with the existing license file if any

4. install Flexlm utility programs such as lmgrd, lmstat and lmdown unless application vendor’s installation script does so for you

5. start lmgrd manually, and set it up to start automatically at boot time.

4. Specifying Location of License File at Application Hosts

1. Read license file directly by specifying LM_LICENSE_FILE to license file. -OR-

2. Read license file data from lmgrd, by specifying LM_LICENSE_FILE to ‘prot@host’

Note: you can only start lmgrd on the server node specified in the license file

5. Starting lmgrd with License File

Manual Start

C Shell: path_to_lmgrd –c license_file >& log_path &

BASH : path_to_lmgrd –c license_file > log_path 2>&1 &

Auto Start: Add the following to /etc/rc.boot or /etc/rc.local

su username –c ‘umask 022; path_to_lmgrd –c license_file >& log_path &’

su username –c ‘umask 022; path_to_lmgrd –c license_file > log_path 2>&1 &’

Note: the ‘-c’ option overrides the setting of LM_LICENSE_FILE environment variable for lmgrd and other FLeXlm utilites

6. License File Components

1. server name (verdor or lmgrd?) and hostid

2. vendor name and path to vendor daemon exec

3. feature information

1. Server Lines

SERVER hostname hostid [port-number]

Hostname: retuned by hostname

Hostid: returned by lmhostid command

Port-number: optional if FLEXLm TCP service in the network service database

2. Daemon Lines

DAEMON daemon-name daemon_path [options_file_path] [PORT=port_num]
	Daemon-name	Name of vendor daemon. Cannot be changed

3. Feature Lines

FEATURE|INCREMENT name daemon version exp_date #lic key \ [HOSTID=hostid][VENDOR_STRING='vendor-string'] \ [vendor_info='...'] [dist_info='...'] [user_info='...'] \ [asset_info='...'] [ISSUER='...'] [NOTICE='...'] [ck=nnn] \ [OVERDRAFT=nnn] [DUP_GROUP=NONE|SITE|[UHDV]]
	name	:	name given to the feature by the vendor
	daemon	:	name of the vendor daemon; also found in the DAEMON line
	version	:	version of this feature that is supported by this license
	exp_date	:	for example, 7-may-1996. Note: If the year is 0, then the license never expires
	#lic	:	number of concurrent licenses for this feature. If the number of users is set to 0, the licenses for this feature are uncounted and no lmgrd is required but a hostid on the FEATURE line is required.
	key	:	license key for this FEATURE line.

7. Combining License Files

Three ways to run multiple vendor daemon

1. Multiple lmgrd server, each running one lmgrd, each lmgrd runs one license file

2. Single lmgrd server, running multiple lmgrd, each lmgrd runs one license file.

3. Single lmgrd server, running one lmgrd and one combined license file

When you can combine license files

1. the number of SERVER line in each file are the same

2. The hostid of each SERVER are the same

When you can NOT combine license files

1. hostid are different because license files are needed to run on different servers

2. One vendor uses a custom hostid algorithm, so the hostid for the same server are different

3. One file is set up for single server ( one SERVER line), the other is set up for redundant server ( has multiple SERVER lines)

8. Common Administration Tools

lmstat - helps you monitor the status of all network licensing activities. (page 44)

lmgrd - the main daemon program for FLEXlm. (page 41)

lmdown - gracefully shuts down all license daemons (both lmgrd and all vendor daemons) on the license server node (or on all three nodes in the case of redundant servers). (page 41)

lmreread - causes the license daemon to reread the license file and start any new vendor daemons. (may cause issue on other lmgrd)

lmhostid - reports the hostid of a system. (page 42)

word 中怎样在左边显示目录._百度知道

word 中怎样在左边显示目录._百度知道

视图-〉文档结构图 

[solution] How to add menu and toolbar into gvim

==Add menu is easy. Add the following into your .vimrc on Linux or _vimrc on Windows
    amenu &Often.&Easy\ Mode :set im!<cr>
    amenu &Often.Line\ &Wrap :set wrap!<cr>
    amenu &Often.Line\ &Number :set nu!<cr>

This will create three menus Often->Easy Mode, Often->Line Wrap and Often->Line Number. The letter after & is for keyboard shortcuts

==Add Toolbar is two steps.

Step A: Creating 16x16 16 color bmp file

             1. Create a 16x16 icon in Visual Studio, and save to .ico file

             2. Rename .ico file into .bmp file and open in mspaint

             3. Save to 16 color .bmp file ( overwriting the original one ) -- must step

             4. Place the .bmp file in .vim/bitmaps on Linux or vimfiles\bitmaps\

Step B: Add the following into your .vimrc on Linux or _vimrc on Windows

    amenu ToolBar.easy :set im!<cr>

    amenu ToolBar.linewrap :set wrap!<cr>

    amenu ToolBar.linenum :set nu!<cr>

 Where easy, linewrap and linenum are the filename of .bmp file ( without extension )

get fileroot filename and dirname from full path

  fdir=${fullfile%/*}
  fname=${fullfile##*/}
  froot=${fname%.*}

[solution] Warning: No xauth data; using fake authentication data for X11 forwarding

Issues:
hosta you ~: ssh hostb
 Warning: No xauth data; using fake authentication data for X11 forwarding

Simple Solutions:
solution a) adding the following line into you@hosta:~.ssh/config
ForwardX11Trusted yes

solution b) adding the following line into you@hosta:~.ssh/config
ForwardX11 no

solution c) invoking ssh as "ssh -Y"

Explanation:
Solution a means that you trust the machine you are ssh-ing to ( hostb )
Solution b/c means that you disable X11 forwarding

Advanced solutions:
check "xauth list"