Merge pull request #463 from ritza-co/19.06.12

Docs 19.06.12 release (Week 30, 2025)

Author: sixhobbits

docs/administration/appliance-manager/setting-up-backup-device42-appliance-manager.mdx

@@ -41,6 +41,16 @@ Configure the backup options for the Main Appliance and Remote Collectors (RCs).
 
 ![Run the backup](/assets/images/setting-up-backup-device42-appliance-manager/backup-now-form.png)
 
+### For Standby Instances
+
+Select the **Backup Meta Data** option when creating a Device42 instance for recovery or failover purposes. Selecting the metadata option copies all system identifiers, passphrases, certificates, and configuration settings – preparing the standby instance to fully replace your production instance when needed.
+
+The standby instance will have the same system identifiers as the production instance, which means it will connect as the primary instance. For this reason, keep one instance with the identifier data active at a time. See the [Warm HA Setup documentation](administration/appliance-manager/warm-ha-setup-failover-and-automated-backups.mdx) for failover procedures.
+
+### For Test Instances
+
+Do not select the **Backup Meta Data** option when creating test or development environments. Backing up and restoring this way is useful when you just want to recover your data, rather than replacing your production instance. The GUIDs will not be copied without the metadata option selected, and without these GUIDs, the machine cannot connect to external services or be used to replace the production instance.
+
 ### Remote Collector Options
 
 The following table summarizes the backup settings for the selected RC(s):
@@ -69,7 +79,7 @@ The following table summarizes the backup settings for the selected RC(s):
     </tr>
     <tr>
       <td>**Backup TLS Key Pair**</td>
-      <td>Backs up the TLS certificate and key</td>
+      <td>Backs up the TLS certificate and key.</td>
       <td> 
         <ul>
           <li>`/etc/nginx/ssl.crt/server.crt`</li>
@@ -99,19 +109,19 @@ The following table summarizes the backup settings for the selected RC(s):
 </table>
 
 
-## Back up to an SFTP Server
+## Back Up to an SFTP Server
 
-The backup file can be scheduled to be sent to a SFTP server. All fields are required.
+The backup file can be scheduled to be sent to an SFTP server. All fields are required.
 
 ![Backup to an SFTP server](/assets/images/setting-up-backup-device42-appliance-manager/sftp-server-settings.png)
 
-## Back up to an NFS server
+## Back Up to an NFS Server
 
-The backup file can be scheduled to be sent to an NFS server. All fields are required. The IP address should be the address of the target NFS server, and the folder path should be the path to the directory where the backups will be stored. This folder should be writeable by a user with `uid=1000`.
+The backup file can be scheduled to be sent to an NFS server. All fields are required. The IP address should be the address of the target NFS server, and the folder path should be the path to the directory where the backups will be stored. This folder should be writable by a user with `uid=1000`.
 
 ![Backup to an NFS server](/assets/images/setting-up-backup-device42-appliance-manager/nfs-server-settings.png)
 
-## Back up Using Amazon S3
+## Back Up Using Amazon S3
 
 The backup file can be scheduled to be sent to Amazon S3 as well. All fields are required.
 
@@ -141,15 +151,15 @@ If your **Current System Time** is incorrect, change it in your VM system config
   }}
 />
 
-## Important Note for Scheduled Backups
+### Important Note for Scheduled Backups
 
 If you intend to use a backup schedule for an auto-restore configuration to a stand-by appliance, as described in the Device42 [Warm HA Configuration](administration/appliance-manager/warm-ha-setup-failover-and-automated-backups.mdx) documentation, it's critical that you select the **Backup Meta Data** option for the backup schedule.
 
 Without the metadata for scheduled backups, the restore and passphrase settings will not be in the backup archive, and the appliance will have no reference for how to use the data when attempting to restore it.
 
 A backup file without metadata can still be used for an on-demand restore.
 
-### Limit Backup Retention
+## Limit Backup Retention
 
 You may want to limit the duration for which backups will be retained. 
 

docs/auto-discovery/database-discovery/index.mdx

@@ -266,7 +266,7 @@ Device42 supports autodiscovery on Windows and \*nix platforms for the following
 
 Device42 database autodiscovery for Windows and \*nix targets supports discovery for Oracle RAC clustered database environments, which helps users better assess their cluster databases and understand all the IT assets tied to critical business applications. Discovery returns data about the RAC configuration, the RAC database, and the nodes (physical servers) running the RAC software. You can run the autodiscovery against one or more nodes in the Oracle RAC and return information about all connected nodes. Device42 requires the use of sudo for Oracle discoveries to mitigate the risk of lockout.
 
-### Minimum Permissions Requirements for Oracle Discovery
+### Minimum Database-Level Permissions
 
 For discovery to return detailed info about your database instance, you will require read or view permissions for the following system views and tables:
 
@@ -284,6 +284,53 @@ To get information about pluggable databases (PDBs) within an Oracle container d
     CONTAINER = CURRENT;
     ```
 
+### System-Level Permissions
+
+In addition to the minimum DB-level permissions above, discovery also needs shell access to the target system to run OS-level commands to get information about the Oracle environment. 
+
+For example, shell access is needed to read the `tnsames.ora` file, which contains network connection details:
+
+```bash
+/usr/bin/cat: /dbprog/oracle/product/19.3.0.0.26/network/admin/tnsnames.ora
+```
+
+Another example is the `lsnrctl status` command, which checks the status of the Oracle listener:
+
+```bash
+oracle -c 'lsnrctl status'
+```
+
+To allow Device42 to run these commands securely, you can grant limited `sudo` access by adding the following to the `/etc/sudoers` file or by creating a separate `sudoers` file for Device42 Oracle discovery:
+
+<details>
+  <summary>Click to expand the code block</summary>
+
+```bash
+# Basic Oracle Discovery Commands
+Cmnd_Alias DEVICE42_ORACLE = \
+    /usr/bin/ps -ef, \
+    /usr/bin/pwdx *, \
+    /usr/bin/su - oracle -c lsnrctl status, \
+    /usr/bin/su - oracle -c echo "select * from product_component_version;" | sqlplus -L -S -M "HTML ON" / as sysdba, \
+    /usr/bin/cat /etc/oratab, \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/lsnrctl status, \
+    /usr/bin/su - oracle -c echo "select * from product_component_version;" | /u01/app/19.1.0.0/grid/bin/sqlplus -L -S -M "HTML ON" / as sysdba
+
+# Oracle RAC Additional Commands  
+Cmnd_Alias DEVICE42_ORACLE_RAC = \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/olsnodes -c, \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/olsnodes -n -i -s, \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/olsnodes -l -n -i -s, \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/srvctl config scan_listener, \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/srvctl config scan, \
+    /usr/bin/su - oracle -c /u01/app/19.1.0.0/grid/bin/crsctl stat res -t | grep *, \
+    /usr/bin/su - oracle -c srvctl config database -d *
+
+# Grant these permissions to your Device42 discovery user:
+# username ALL=(ALL) NOPASSWD: DEVICE42_ORACLE, DEVICE42_ORACLE_RAC
+```
+</details>
+
 ### Set Up Your Oracle Discovery Job
 
 To begin discovering your Oracle databases, navigate to **Discovery > HyperVisors /\*nix /Windows**. Create a new discovery job for Windows or \*nix (or both) targets, and be sure to check the **Collect database server information** checkbox.