Service management of Sage - D
|
09-07-2016, 05:53 PM
Post: #11
|
|||
|
|||
RE: Service management of Sage
(09-07-2016 05:35 PM)lingu Wrote: This is too heavyweight -- it may even disrupt Sage if it is busy. I ever tested to send a small file from s188 to s188. It only costs 0m0.009s. I think it is good enough. Quote:Quote:Then glad operative user & sage_user can use sage_key to execute remote command to sage_user@sage_portal. We already have a $glad_portal that can be used directly. It is set by util/install.sh during installing. Quote:What if the wait_sage_start fails? This is a bug. I will fix it. |
|||
09-07-2016, 06:18 PM
(This post was last modified: 09-07-2016 06:18 PM by lingu.)
Post: #12
|
|||
|
|||
RE: Service management of Sage
(09-07-2016 05:53 PM)YU_Xinjie Wrote:(09-07-2016 05:35 PM)lingu Wrote: This is too heavyweight -- it may even disrupt Sage if it is busy. The auntie command may complete in 0.009s, but the transfer should take longer because I added a 1s wait somewhere. Maybe it is not in the critical path... Anyway, it is okay to keep it this way for a while. Quote:We already have a $glad_portal that can be used directly. It is set by util/install.sh during installing. OK. Then it's fine. Quote:Quote:What if the wait_sage_start fails? Please revise the design of this part first as a reply then I can reply to endorse the overall design. The real "fix" should be after the design is endorsed. |
|||
09-07-2016, 06:37 PM
Post: #13
|
|||
|
|||
RE: Service management of Sage | |||
09-07-2016, 06:52 PM
Post: #14
|
|||
|
|||
RE: Service management of Sage
(07-12-2016 05:54 PM)YU_Xinjie Wrote: goal OK. |
|||
09-07-2016, 06:53 PM
Post: #15
|
|||
|
|||
RE: Service management of Sage
(09-07-2016 06:37 PM)YU_Xinjie Wrote:(09-07-2016 06:18 PM)lingu Wrote: Please revise the design of this part first as a reply then I can reply to endorse the overall design. Okayed the design. But you ignored my word "as a reply". Pls make sure to execute precisely. |
|||
09-08-2016, 04:28 PM
Post: #16
|
|||
|
|||
RE: Service management of Sage
(09-07-2016 05:35 PM)lingu Wrote:Quote:wait_sage_start () { 1. While implementing, I find "sage start" cost 21 seconds on average in my dev cluster. The perf of my dev cluster is not well since they are VMs. Sometimes it would cost more than 30 seconds. Then the sage is actually started but my script reports failed. Therefore I suggest we still use 2 minutes timeout here. 2. The sleep time is 2 seconds after each trial fails. But I find even though auntie command is finish quickly if it succeeds, the received file content will exist after 2~3 seconds. So even though auntie sends file successfully, another auntie trial would be triggered. If it is triggered, script would print a ERROR info to confuse user but finally the Sage & service scripts would still succeed. Therefore I suggest we use "sleep 4" after each trial fails. Then the confusing ERROR info would not appear frequently. I will implement above change before your review, since I think they are minor change. |
|||
09-08-2016, 04:48 PM
Post: #17
|
|||
|
|||
RE: Service management of Sage
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 |
|||
09-08-2016, 06:41 PM
Post: #18
|
|||
|
|||
RE: Service management of Sage
Committed in df99edcb4f9ae617c098714f8036393fbdf8e413 .
|
|||
09-15-2016, 12:34 AM
(This post was last modified: 09-15-2016 12:42 AM by lingu.)
Post: #19
|
|||
|
|||
RE: Service management of Sage
(09-08-2016 04:48 PM)YU_Xinjie Wrote: For the private key, I encounter an issue: 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. |
|||
09-15-2016, 12:49 AM
Post: #20
|
|||
|
|||
RE: Service management of Sage
(09-07-2016 05:35 PM)lingu Wrote:Quote:1. 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? |
|||
« Next Oldest | Next Newest »
|
- View a Printable Version
- Send this Thread to a Friend
- Subscribe to this thread
- Show the subscribers of this thread:
- Add subscribers to this thread: