Wrong user directory matching rule when copying to server

[sunxiyuan]

Describe the bug A clear and concise description of what the bug is.  To Reproduce Steps to reproduce the behavior:

1. Go to '复制到服务器'
2. Click on '开始复制'  Expected behavior The replication should be executed correctly, but the target server prompts: SSH key not available in the origin server!  Additional context  This issue is caused by the use of imprecise matching rules in the 81 origin site sync. sh file during the extraction of user directories. Specific code: homedir=grep $localuser /etc/passwd|cut -d':' -f6 The correct one should be: homedir=$(grep '^root:' /etc/passwd | cut -d':' -f6) Otherwise, it will match: snapd-range-524288-root:x:524288:524288::/nonexistent:/usr/bin/false

[cmhello]

没想到哥们也在用 WPCloudDeploy，不过貌似开发者上个月去世了，目前官方网站和相关的几个网站都无法访问了，不知道后续有没有人接手，郁闷……

[sunxiyuan]

没想到哥们也在用 WPCloudDeploy，不过貌似开发者上个月去世了，目前官方网站和相关的几个网站都无法访问了，不知道后续有没有人接手，郁闷……

啊……我们在基于 WPCloudDeploy 做政务SaaS，第一个切入点是红十字会，现在已经进入到地市一级推广的阶段了，我没有想过会出现这种情况，哎

[SuperHondo]

@cmhello request, if you could pls post in ENGLISH. It will be easy for us to understand and follow.

[eslam-dev]

@sunxiyuan @cmhello If you can write the issue in English, we will be able to resolve it and release a new version of the plugin.

[sunxiyuan]

@eslam-dev What I want to describe is the abnormality in the ability to replicate a site to other servers.

This issue is caused by the use of imprecise matching rules in the 81-origin-site-sync.sh file during the extraction of user directories. Specific code: homedir=grep $localuser /etc/passwd|cut -d':' -f6 The correct one should be: homedir=$(grep '^root:' /etc/passwd | cut -d':' -f6) Otherwise, it will match: snapd-range-524288-root:x:524288:524288::/nonexistent:/usr/bin/false

[eslam-dev]

@sunxiyuan I believe there is no issue in the following line: homedir=$(grep $localuser /etc/passwd | cut -d':' -f6) Because there is code before it that fetches the user directly:

localuser=$(sh -c 'echo ${SUDO_USER:-$USER}') And the rest of the file also relies on using the variable localuser.

The code was tested on AWS and works correctly. Could you please provide me with the name of the server provider?

[sunxiyuan]

@eslam-dev Sorry for the misunderstanding in my reply. I guess the reason is that I replaced the $localuser variable with root for my own debugging. I will describe the bug in detail below.

My /etc/passwd file contains the following two lines (note that the username in the second line contains the string root):

root:x:0:0:root:/root:/bin/bash
snapd-range-524288-root:x:524288:524288::/nonexistent:/usr/bin/false

In this case, the original match specification will match both /root and /nonexistent. The root cause is that there is no strict match on the username, because grep $localuser only checks whether a line contains the username string, regardless of where the string appears.

[eslam-dev]

@sunxiyuan I understand the issue you are facing now. You can try the following solution on your server. Simply change the username newuser to the name you need in the following code.

sudo useradd -m -s /bin/bash newuser

// Set the password for the user:

sudo passwd newuser