Service management of Sage - D

[YU_Xinjie]

(09-15-2016 12:34 AM)lingu Wrote:  

(09-08-2016 04:48 PM)YU_Xinjie Wrote:  For the private key, I encounter an issue:

SSH command would check the premission of private key. If the key can readable by others, SSH would just ignore the key. One method to skip the check is to set the owner of key to be a user that would never use the key. For example:

Code:

[0][15:40:42] xinjie@devmac0e0:/thinker/dstore/gene/glad/conf
$ ll sage_key
-rw-r--r--. 1 dstore dstore 1679 Sep  8 14:57 sage_key

I set the owner to be dstore. Then user gene, sage, xinjie can use the key to access sage_portal. Only user dstore can not do that.

If the user is not the owner but can read the file and other users can read the key file, too, why does SSH allow the user to use the key? This seems to be a bug in SSH.

Is the behavior dependable? If the current behavior is not well defined, we may not want to rely on it although it works now. In the future, if the behavior changes, our programs will break.

Can we use multiple key files of the same content, i.e., key-sage, key-xinjie, ..., so that the key file's access can be restricted to that particular user?

In general, avoid hacks unless there is no other way out. Keep things simple stupid. Hacks are fun, but it's not dependable. It's like sleeping a drunk girl -- if anything lasted after the fun through the next sunrise it would be some mess of drying sperm mixed with vomits. That's not beauty of life.

Looks good to me. I replied in http://rar.shufangkeji.com:60380/showthr...2#pid12582

(09-15-2016 12:49 AM)lingu Wrote:  

(09-07-2016 05:35 PM)lingu Wrote:  

Quote:1.
require sage_user can password-less login sage_user@sage_portal

This is fine if all are sage_user.

Quote:copy private key of sage_user@sage_portal into $gb/conf/sage_key

$gb is owned by glad_user and all operative users can access it. So this is a security vulnerability. OK now. But make a TODO to fix it later.

I think I may not have really understood what we are doing here. Are we trying to let glad_user ssh to sage_user@sage_portal? Or are we trying to let sage_user ssh back to sage_user@sage_portal?

For the latter, we can perhaps let all sage_user have the same key on all nodes? But the keys may not be stored in $gb.

For the former, we should perhaps add glad_user's pub key to sage_user@portal's authorized_keys during the installation of glad?

Neither.

The glad operative users & sage_user need to ssh to sage_user@portal, in "sage" script.

[lingu]

(09-18-2016 03:59 PM)YU_Xinjie Wrote:  Neither.

The glad operative users & sage_user need to ssh to sage_user@portal, in "sage" script.

What function needs this? Where is the designer's info? We should review it.

sage_user is an advanced user with quite some high access rights.

[YU_Xinjie]

(09-23-2016 10:41 PM)lingu Wrote:  What function needs this? Where is the designer's info? We should review it.

It is the original design in the headpost, which you already endorse it.

(07-12-2016 05:54 PM)YU_Xinjie Wrote:  Then glad operative user & sage_user can use sage_key to execute remote command to sage_user@sage_portal.

It is needed by the goal:

Quote:1. the script can be used in both sage_portal & glad_portal to start/stop/status sage.
2. user can start sage before glad, and stop sage after glad.

[lingu]

(09-27-2016 11:33 AM)YU_Xinjie Wrote:  

(09-23-2016 10:41 PM)lingu Wrote:  What function needs this? Where is the designer's info? We should review it.

It is the original design in the headpost, which you already endorse it.

(07-12-2016 05:54 PM)YU_Xinjie Wrote:  Then glad operative user & sage_user can use sage_key to execute remote command to sage_user@sage_portal.

It is needed by the goal:

Quote:1. the script can be used in both sage_portal & glad_portal to start/stop/status sage.
2. user can start sage before glad, and stop sage after glad.

The headpost does not say that the operative user (opuser) needs keys to impersonate sage_user@sage_portal to start/stop Sage. There is a logical glitch that prevents me from linking them together in a hurry reading.

Typically I tend to endorse matters if I see no obvious issues :-) Sometimes I miss some points.

Here it is okay to let opuser or glad_user impersonate sage_user as a temporary solution.

[YU_Xinjie]

(07-12-2016 05:54 PM)YU_Xinjie Wrote:  goal

1. the script can be used in both sage_portal & glad_portal to start/stop/status sage.
2. user can start sage before glad, and stop sage after glad.

The script would replace the current start.sh/stop.sh/status.sh in the future.
The script may inspire us about how to set up regression tests for sage.

For shbio's project, I have already written a script /thinker/dstore/run/sage to support a part of the goal. I would try to generalize it.

config design

The brief idea is to use auntie to send a file to glad_portal. Then check the file content.

1.
require sage_user can password-less login sage_user@sage_portal
copy private key of sage_user@sage_portal into $gb/conf/sage_key

But SSH command would check the premission of private key. If the key can readable by others, SSH would just ignore the key. One method to skip the check is to set the owner of key to be a user that would never use the key. For example:

Code:

[0][15:40:42] xinjie@devmac0e0:/thinker/dstore/gene/glad/conf
$ ll sage_key
-rw-r--r--. 1 dstore dstore 1679 Sep  8 14:57 sage_key

I set the owner to be dstore. Then user gene, sage, xinjie can use the key to access sage_portal. Only user dstore can not do that.

Then glad operative user & sage_user can use sage_key to execute remote command to sage_user@sage_portal.

2. The glad_portal IP can be get from $gb/conf/config.sh

3.
create a config file $gb/conf/sage_portal_ip to record the IP of sage_portal. Or we can also write it into $gb/conf/config.sh.

4. let sage_user@sage_portal can password-less login glad_user@glad_portal.

start sage

Code:

wait_sage_start () {
content="This is test content."
echo $content > $curdir/${USER}_sage_testfile
test_file=/thinker/bin/ephemeral/667.sagetest

# 30 seconds timeout
try_cnt=10
while [[ ("$try_cnt" -gt "0") && ((! -f "$test_file") || ("$(cat $test_file)" != "$content")) ]]; do
  timeout -s SIGINT 1 bash -c "sage_user=$sage_user $curdir/auntie ^$curdir/${USER}_sage_testfile $glad_portal 667 sagetest" || echo -n ''
  echo "Trying to start Sage..."
  sleep 2
  try_cnt=$((try_cnt-1))
done
rm -f $test_file

if [[ "$try_cnt" == "0" ]];then
  # timeout
  return 1
else
  return 0
fi
}

start_sage () {
# check whether sage is really stopped.
local tmp="$(status_sage)"
if [[ "$tmp" != "Sage is stopped." ]]; then
  echo "Sage is already started."
  echo ""
  echo "Status: "
  echo "$tmp"
  return 0
fi

remote_cmd "screen -dmS sage_service bash -c 'cd ~/sage; ./start.sh'"

local rt="succ"
wait_sage_start || rt="fail"
if [[ "$rt" == "succ" ]]; then
  echo "Sage is started."
else
  echo "Sage fails to start."
fi
}

stop sage

Code:

stop_sage () {
# stop sage
remote_cmd "cd ~/sage; ./stop.sh" > /dev/null

# kill all sage_service screens
remote_cmd "
for session in \$(screen -ls | grep 'sage_service' | grep -o '[0-9]\+\.' | grep -o '[0-9]\+')
do
    screen -S \${session} -p 0 -X quit
done
"

# check whether sage is really stopped.
local tmp="$(status_sage)"
if [[ "$tmp" == "Sage is stopped." ]]; then
  echo "Sage is stopped."
else
  echo "Sage failed to stop."
  echo ""
  echo "Status: "
  echo "$tmp"
fi
}

status sage

Code:

status_sage () {
local output="$(remote_cmd "cd ~/sage; ./status.sh")"
if [[ "$output" == "Sage is stopped." ]]; then
  echo "Sage is stopped."
else
  echo "$output"
fi
}

Save a copy before changing.

[YU_Xinjie]

Updated sage service script, so that it is decoupled with glad.

[YU_Xinjie]

Updated the design of "sage status". Added the design of "sage ps".

[lingu]

(10-19-2016 06:37 PM)YU_Xinjie Wrote:  Updated the design of "sage status". Added the design of "sage ps".

What is the semantics of 'sage status' or auntie? Please specify. For example, it can be 'exit status 0 meaning success and otherwise failure'. Although simple, it needs to be specified for this info to be professionally engineered.

[YU_Xinjie]

I suggest we add a "sage config VAR_NAME" command, so that app of Sage (such as GLAD) can query the config value easily.

It is needed for many situations:
1. We need to use "atp_cnt" to set up glad_size of GLAD.
2. GLAD needs the config.node info.

@lingu

Please endorse.

[lingu]

(12-06-2016 12:32 PM)YU_Xinjie Wrote:  I suggest we add a "sage config VAR_NAME" command, so that app of Sage (such as GLAD) can query the config value easily.

We already have a way to let Sage store and report k/vs. Why can't we use the existing way?

Quote:It is needed for many situations:
1. We need to use "atp_cnt" to set up glad_size of GLAD.

Where do we need to use glad_size? I am curious to know.

Quote:2. GLAD needs the config.node info.

In which case?

We should discuss over a concrete example.