deploy hook synology_dsm fails when running on Synolgy SRM and SYNO_USE_TEMP_ADMIN=1

[Eddict]

if SYNO_USE_TEMP_ADMIN=1 is set the script checks for synogroup existence

     if ! _exists synogroup; then

however on SRM synogroup exists but it does not support parameter --memberadd.

synogroup: unrecognized option '--memberadd'

on SRM the parameter is --member.

SRM (1.3.1-9346 Update 8):

root@srm:~ # synogroup
Copyright (c) 2003-2014 Synology Inc. All rights reserved.

Usage: synogroup (Version 9346)
        --help
        --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})}
        --enum [{local|domain|ldap|all}]
        --enumpre {local|domain|all} prefix Caseless{0|1}
        --enumsub {local|domain|all} substr Caseless{0|1}
        --get groupname
        --getgid GID
        --descget groupname
        --descset groupname ["New Descritions"]
        --add groupname username1 username2 ...
        --rename old_groupname new_groupname
        --member groupname username1 username2 ...
        --del groupname1 groupname2 ...
        --dbopen2 groupname

DSM (7.2.1-69057 Update 4):

root@dsm:~# synogroup
Copyright (c) 2003-2023 Synology Inc. All rights reserved.

Usage: synogroup
        --help
        --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})}
        --enum [{local|domain|ldap|all}]
        --enumpre {local|domain|all} prefix Caseless{0|1}
        --enumsub {local|domain|all} substr Caseless{0|1}
        --get groupname
        --getgid GID
        --descget groupname
        --descset groupname ["New Descritions"]
        --add groupname username1 username2 ...
        --rename old_groupname new_groupname
        --member groupname username1 username2 ...
        --memberadd groupname username
        --del groupname1 groupname2 ...
        --dbopen2 groupname

but besides that, it is executing the synogroup command locally (the Synology device running acme.sh) instead of on the target (SYNO_Hostname). i assume this also won't work when running acme.sh on a different NAS/DSM than the one you want to deploy to, so it's not only a SRM issue..

[github-actions[bot]]

Please upgrade to the latest code and try again first. Maybe it's already fixed. acme.sh --upgrade If it's still not working, please provide the log with --debug 2, otherwise, nobody can help you.

[scruel]

Hi, your issue can be concluded as the following two points:

1. for machines that older than DSM7.x, synogroup won't have --memeberadd parameter.
2. want to use the new temp user admin method to deploy remotely

For point#1, I already got it fixed in the commit even before you opened this issue, and already opened a PR which is waiting to be merged.

For point#2, temp admin method is now designed to only support locally deployment, I will commit new code to add a special check for SYNO_HOSTNAME in the same PR and then update the document. BTW, it may not (or shouldn't) be supported for a long time in the future, even we do can utilize tools like SSH to do the implementation, because it will contain quite high-risky operations - requires executing several admin commands on the remote target machine, and I won't have more time for it. However, if you or anyone want to do so, you can still discuss it.

[Eddict]

1. correct. and so also on SRM (all versions up to 1.3.1)
2. indeed, that is more complicated and risky. i will comment the export SYNO_USE_TEMP_ADMIN=1 line for now (export SYNO_USE_TEMP_ADMIN=0 seems not working, it still checks and executes synogroup command)

maybe i can add the remote implementation via SSH commands, not sure if that's really worth it and if i have the time to do so. let me think about that.

thanks for your response and (upcoming) fixes though!

[scruel]

SYNO_USE_TEMP_ADMIN=0 is in the same PR, and already be replaced by CLEAR_SYNO_USE_TEMP_ADMIN=1 in it, will update documents later. What a bad design on GitHub which we can't have PRs for the wiki pages...

[nillebor]

SYNO_USE_TEMP_ADMIN=1 does not work on different Diskstation. Tested on DSM 7.1 and DSM 7.2. On all systems, I get the error message: Tools are missing for creating temp admin user, please set SYNO_USERNAME and SYNO_PASSWORD instead.

[Mon May  6 16:44:36 CEST 2024] Lets find script dir.
[Mon May  6 16:44:36 CEST 2024] _SCRIPT_='/usr/local/bin/acme.sh'
[Mon May  6 16:44:36 CEST 2024] _script='/root/.acme.sh/acme.sh'
[Mon May  6 16:44:36 CEST 2024] _script_home='/root/.acme.sh'
[Mon May  6 16:44:36 CEST 2024] Using default home:/root/.acme.sh
[Mon May  6 16:44:36 CEST 2024] Using config home:/acme.sh
[Mon May  6 16:44:36 CEST 2024] LE_WORKING_DIR='/root/.acme.sh'
[Mon May  6 16:44:36 CEST 2024] Running cmd: deploy
[Mon May  6 16:44:36 CEST 2024] Using config home:/acme.sh
[Mon May  6 16:44:36 CEST 2024] default_acme_server='https://acme-v02.api.letsencrypt.org/directory'
[Mon May  6 16:44:36 CEST 2024] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon May  6 16:44:36 CEST 2024] _ACME_SERVER_HOST='acme-v02.api.letsencrypt.org'
[Mon May  6 16:44:36 CEST 2024] _ACME_SERVER_PATH='directory'
[Mon May  6 16:44:36 CEST 2024] The domain 'acmetest.dynv6.net' seems to have a ECC cert already, lets use ecc cert.
[Mon May  6 16:44:36 CEST 2024] DOMAIN_PATH='/acme.sh/acmetest.dynv6.net_ecc'
[Mon May  6 16:44:36 CEST 2024] DOMAIN_CONF='/acme.sh/acmetest.dynv6.net_ecc/acmetest.dynv6.net.conf'
[Mon May  6 16:44:36 CEST 2024] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh'
[Mon May  6 16:44:36 CEST 2024] _cdomain='acmetest.dynv6.net'
[Mon May  6 16:44:36 CEST 2024] SYNO_USE_TEMP_ADMIN='1'
[Mon May  6 16:44:36 CEST 2024] SYNO_USE_TEMP_ADMIN='1'
[Mon May  6 16:44:36 CEST 2024] Tools are missing for creating temp admin user, please set SYNO_USERNAME and SYNO_PASSWORD instead.
[Mon May  6 16:44:36 CEST 2024] Error deploy for domain:acmetest.dynv6.net
[Mon May  6 16:44:36 CEST 2024] Deploy error.

[scruel]

@nillebor Temp admin creation requires CLI commands synouser and synogroup to work, and such commands are built-in on DSM 7.x, so it should work perfectly. IDK why your DSM is missing such tools, consider missing these commands should cause your system to crash, and I won't be able to help if built-in tools are missing on your DSM. BTW, in case there are something I missed, please provide more details:

• device info
• DSM system info (version).
• the results of executing synouser --help and synogroup --help via SSH terminal
• related screenshots

[chriscarpenter12]

I had the same error as @nillebor and it took me a while to figure out why because I was using an admin account. Until I realized that the wiki assumes you installed acme.sh and are running it as root.

[nillebor]

Thanks for your answers. I use Acme.sh in Docker on different Diskstation. I bet acme.sh for a very long time. I read about the option in the wiki and wanted to try it out. Unfortunately, there is nothing else in the wiki about this, except that you should activate the option. https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-certificate-to-synology-dsm

[scruel]

I had the same error as @nillebor and it took me a while to figure out why because I was using an admin account. Until I realized that the wiki assumes you installed acme.sh and are running it as root.

I've tried to reproduce this with admin user, and the log from my side will contain different errors, not like the @nillebor mentioned:

sh-4.4$ acme.sh --deploy -d *.scruel.com_ecc --deploy-hook synology_dsm
[Tue May  7 11:26:16 AM CST 2024] Logging into localhost:5000...
line 192: /usr/syno/sbin/synogroup: Permission denied
grep: warning: stray \ before -
line 195: /usr/syno/sbin/synogroup: Permission denied
grep: warning: stray \ before -
[Tue May  7 11:26:16 AM CST 2024] Unsupported synogroup tool detected, please set SYNO_USERNAME and SYNO_PASSWORD instead.
[Tue May  7 11:26:16 AM CST 2024] Error deploy for domain:*.scruel.com_ecc
[Tue May  7 11:26:16 AM CST 2024] Deploy error.

As you can see, the user will be able to see Permission denied error, which may let user know that they should switch to root to re-run, even though, I will update script/wiki with tips to guide users, and thank you for bringing it out @chriscarpenter12.

@nillebor I don't think your issue is same as the above, did you solve it after switching to your root account? If it's still not working, please provide the log with --debug 3 and the related info.

[nillebor]

Sorry if I do not understand this correctly. Does this only work with native installation in root, not in docker?

[scruel]

Sorry if I do not understand this correctly. Does this only work with native installation in root, not in docker?

Hmm... Yes, please read the doc (wiki) more carefully :)

[nillebor]

Sorry for my mistake. The manual says that Docker and Remote are excluded. "... can't be used to deploy in docker or deploy remotely." I somehow overlooked this, otherwise I would not have asked for it! This solved my problem.

With the last updates 2FA works again and I am happy. Thank you for your support!