Closed mjhgthb closed 1 year ago
@mjhgthb you are right.
Currently only works with and it is highly recommended to have the NOPASSWD in the sudoers of the user that is used to do the installation, otherwise it will ask you for the password for each action that the DRLM wants to perform in the client and it would produce an output similar to this:
root@drlmsrv:~# drlm -vD instclient -c drlmcli1 -u instuser
2023-01-27 13:36:22 50916 instclient: Using log file: /var/log/drlm/debug/drlm-drlmsrv-instclient.20230127.133622.3184.log
2023-01-27 13:36:22 drlm:instclient: Installing software with user instuser
2023-01-27 13:36:22 drlm:instclient: Sending Key for user: instuser
instuser@drlmcli1's password:
2023-01-27 13:36:24 drlm:instclient: Success to update DRLM hostname info to drlmcli1
2023-01-27 13:36:25 drlm:instclient: Updating OS version Debian 11.6 of client 100 in the database
[sudo] password for instuser:
uid=1003(drlm) gid=1003(drlm) groups=1003(drlm)
[sudo] password for instuser:
userdel: drlm mail spool (/var/mail/drlm) not found
[sudo] password for instuser:
2023-01-27 13:36:29 drlm:instclient: User drlm created on drlmcli1
2023-01-27 13:36:29 drlm:instclient: Sending ssh key for drlm user ...
[sudo] password for instuser:
cat: /home/drlm/.ssh/authorized_keys: No such file or directory
2023-01-27 13:36:30 drlm:instclient: key for drlm has been sent on drlmcli1
[sudo] password for instuser:
passwd: password expiry information changed.
2023-01-27 13:36:32 drlm:instclient: User drlm has been blocked using password
[sudo] password for instuser:
2023-01-27 13:36:33 drlm:instclient: Installing dependencies and ReaR
[sudo] password for instuser:
[sudo] password for instuser:
2023-01-27 13:36:40 drlm:instclient: Updating ReaR version 2.6/2020-06-17 of client 100 in the database
[sudo] password for instuser:
Synchronizing state of rpcbind.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable rpcbind
2023-01-27 13:36:42 drlm:instclient: Services have been started succesfully
environment: line 4: rear: command not found
[sudo] password for instuser:
2023-01-27 13:36:43 drlm:instclient: Tunning drlmcli1 ReaR installation successfully done
[sudo] password for instuser:
2023-01-27 13:36:44 drlm:instclient: drlmcli1 is now managed by DRLM
[sudo] password for instuser:
2023-01-27 13:36:46 drlm:instclient: drlmcli1 DRLM API token send
[sudo] password for instuser:
2023-01-27 13:36:47 drlm:instclient: SSL CApath successfully created in drlmcli1
[sudo] password for instuser:
2023-01-27 13:36:49 drlm:instclient: SSL certificate successfully sent to drlmcli1
[sudo] password for instuser:
2023-01-27 13:36:50 drlm:instclient: Creating /var/lib/drlm in drlmcli1
[sudo] password for instuser:
2023-01-27 13:36:54 drlm:instclient: Sudo has been configured for user drlm
2023-01-27 13:36:54 drlm:instclient: instuser authorized_keys removed from client drlmcli1
DRLM only uses the user passed to it with the -u parameter to install the client. During this process, create a user called "drlm" with the correct sudo permissions to perform backup tasks, such as:
Cmnd_Alias DRLM = /usr/sbin/rear , /usr/bin/mount , /usr/bin/umount , /usr/bin/rm , /usr/bin/mkdir , /usr/bin/stat , /usr/bin/cat /etc/rear/drlm.token , /var/lib/drlm/scripts/drlm_pre_runbackup_script.sh , /var/lib/drlm/scripts/drlm_post_runbackup_script.sh
drlm ALL=(root) NOPASSWD: DRLM
If, in any case, you want to perform the installation by entering the password manually when sudo asks for it, you must modify the file /usr/share/drlm/lib/install-functions.sh and remove "&> /dev/null" from the end of the lines: 50, 58, 66, 75, 85, 96, 118, 127, 148, 157, 165, 187, 200, 215, 223, 234, 305, 321, 331, 340, 348, 360, 387, 443, 466 and 551 and the one at the end of line 41 of /usr/share/drlm/client/inst/default/109_create_user_on_client.sh
WARNING! These changes to DRLM functions have not been tested and may cause something else to stop working properly. The ideal would be to make a custom development if it is really a necessity.
Best regards and thanks for testing and reporting!!!
Thanks for the quick and very detailed reply! Do I see correctly that this has been added to a future milestone..? (as in: planning to officially support it, without needing to edit the mentioned files..?)
Hello @mjhgthb,
Yes, we are going to discuss it for a future milestone, but in a proper way to avoid continuous password requests. This was a quick workaround that needs to be discussed to find a proper way to solve the "issue".
Thanks for your testing and reporting!
Kind regards, Didac
All clear. Thanks very much! Great piece of software so far.
Issue type (Bug / Question / Feature Request / Others?): Feature Request
Impact (Low / High / Critical / Urgent): Low
How often it happens (Always / Eventually): Always
Brief description of the issue:
Could you find a way to support a sudo admin user for "drlm instclient -u adminuser" where the adminuser has to provide a password to use sudo?
"drlm instclient -c rear-client -u adminuser" when adminuser has sudo rights but sudo requires a password does NOT seem to work.
Work-around, if any: support "drlm instclient -c rear-client" will use the default user 'root', and that works perfectly.
DRLM version (/usr/sbin/drlm -V): Disaster Recovery Linux Manager 2.4.9-git / 2022-12-05
OS version (cat /etc/drlm/os.conf or lsb_release -a): OS_VENDOR=RedHatEnterpriseServer OS_VERSION=9
Output of:
drlm listclient -c client_name [root@drlm-server ~]# drlm listclient -c rear-client Id Name MacAddres Ip Client OS ReaR Version Network Scheduled 100 rear-client 5254009d37e6 192.168.100.157 RedHat 9.1 2.6/2020-06-17 ens3 false
drlm listnetwork -A [root@drlm-server ~]# drlm listnetwork -A Id Name Status Server IP Mask Network Ip Broadcast Gateway Interface 1 ens3 disabled 192.168.100.161 255.255.255.0 192.168.100.0 192.168.100.255 ens3
DRLM Client information:
ReaR version (/usr/sbin/rear -V): Relax-and-Recover 2.6 / 2020-06-17
OS version (cat /etc/rear/os.conf or lsb_release -a): cat: /etc/rear/os.conf: No such file or directory But it is: REDHAT 9.1, same as the server
Hardware platform (uname -i): x86_64
Some logging:
And on the drlm server, this is logged:
But this works as expected: