[Wien] parallel ssh error

[Gavin Abo]

The "sudo service sshd restart" step, which I forgot to copy and paste, 
that is missing is corrected below.

On 9/28/2019 12:18 PM, Gavin Abo wrote:
>
> After you set both "SendEnv *" and "AcceptEnv *", did you restart the 
> sshd service [1]?  The following illustrates steps that might help you 
> verify that WIENROOT appears on a remote vlsi node:
>
> username at computername:~$ echo $WIENROOT
>
> username at computername:~$ export WIENROOT=/servernode1
> username at computername:~$ echo $WIENROOT
> /servernode1
> username at computername:~$ ssh vlsi
> Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-64-generic x86_64)
> ...
> Last login: Sat Sep 28 12:04:07 2019 from xxx.x.x.x
> username at computername:~$ echo $WIENROOT
>
> username at computername:~$ exit
> logout
> Connection to vlsi closed.
> username at computername:~$ sudo gedit /etc/ssh/ssh_config
> [sudo] password for username:
>
> username at computername:~$ sudo gedit /etc/ssh/sshd_config
>
> username at computername:~$ grep SendEnv /etc/ssh/ssh_config
>     SendEnv LANG LC_* WIENROOT
> username at computername:~$ grep AcceptEnv /etc/ssh/sshd_config
> AcceptEnv LANG LC_* WIENROOT
>
    username at computername:~$ sudo service sshd restart
>
> username at computername:~$ ssh vlsi
> ...
> username at computername:~$ echo $WIENROOT
> /servernode1
> username at computername:~$ exit
>
> [1] 
> https://askubuntu.com/questions/462968/take-changes-in-file-sshd-config-file-without-server-reboot
>
> On 9/28/2019 11:22 AM, Indranil mal wrote:
>> Sir I have tried with " SetEnv * " Still nothing is coming with echo 
>>  commad and user name by mistake I posted wrong Otherwise no issue 
>> with user name and I have set the parallel options file taksset "no" 
>> and remote options are 1 1 in server and client machines.
>>
>>
>> On Sat, 28 Sep 2019 11:36 Gavin Abo, <gsabo at crimson.ua.edu 
>> <mailto:gsabo at crimson.ua.edu>> wrote:
>>
>>>     Respected Sir, In my linux(Ubuntu 18.04 LTS) in ssh_config, and
>>>     in sshd_config there are two line already "SendEnv LANG LC_*"
>>>     "AcceptEnv LANG LC_*" respectively.
>>
>>     The "LANG LC_*" probably only puts just the local language
>>     variables in the remote environment.  Did you follow the previous
>>     advice [1] of trying to use "*" to put all variables from the
>>     local environment?
>>
>>     [1]
>>     https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19049.html
>>
>>>     However, ssh vsli1 'echo $WIENROOT' gives nothing (blank).
>>
>>     That seems to be the main cause of the problem as it should not
>>     return (blank) but needs to return "/servernode1" as you
>>     previously mentioned [2].
>>
>>     [2]
>>     https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19036.html
>>
>>     Perhaps the message below is a clue.  It you had set the WIENROOT
>>     variable in .bashrc of your /home/vlsi accounts on each system,
>>     you likely have to login and use that same /home/vlsi account on
>>     the head node as the output below seems to indicate login to a
>>     different /home/niel account.  Alternatively, setting the
>>     WIENROOT variable in .bashrc of all /home/niel accounts on each
>>     node might work too.
>>
>>>        The command ssh vsli1 'pwd $WIENROOT' print "/home/vlsi" the
>>>     common home directory and
>>>     ssh vlsi1 "env"
>>>     ...
>>>     USER=niel
>>>     PWD=/home/niel
>>>     HOME=/home/niel
>>>     ...
>>>     this is similar as server, and other nodes.
>>>
>>>     Sir After changing the parallel option file in $WIENROOT in
>>>     server to
>>>
>>>     setenv TASKSET *"yes" from "no"*
>>>     if ( ! $?USE_REMOTE ) setenv USE_REMOTE 1
>>>     if ( ! $?MPI_REMOTE ) setenv MPI_REMOTE 1
>>>     setenv WIEN_GRANULARITY 1
>>>     setenv DELAY 0.1
>>>     setenv SLEEPY 1
>>>     setenv WIEN_MPIRUN "mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_"
>>>     setenv CORES_PER_NODE 1
>>>
>>>     the error is not coming but the program is not increasing steps
>>>     after lapw0 it stuck in lapw1
>>
>>     Since it seemed to be throwing an appropriate error message with
>>     TASKSET previously unlike when set to "yes", probably you should
>>     change it back to "no".
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20190928/64702008/attachment.html>