Managing file systems

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create an XFS file system on a block device
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_volumes:
             - name: barefs
               type: disk
               disks:
                 - sdb
               fs_type: xfs

   Copy to Clipboard Toggle word wrap

   The setting specified in the example playbook include the following:

   name: barefs

   The volume name (barefs in the example) is currently arbitrary. The storage role identifies the volume by the disk device listed under the disks attribute.

   fs_type: <file_system>

   You can omit the fs_type parameter if you want to use the default file system XFS.

   disks: <list_of_disks_and_volumes>

   A YAML list of disk and LV names.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Persistently mount a file system
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_safe_mode: false
   
           storage_volumes:
             - name: barefs
               type: disk
               disks:
                 - sdb
               fs_type: xfs
               mount_point: /mnt/data
               mount_user: somebody
               mount_group: somegroup
               mount_mode: "0755"

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create logical volume
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_safe_mode: false
   
           storage_pools:
             - name: myvg
               disks:
                 - sda
                 - sdb
                 - sdc
               volumes:
                 - name: mylv
                   size: 2G
                   fs_type: ext4
                   mount_point: /mnt/data

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   size: <size>

   You must specify the size by using units (for example, GiB) or percentage (for example, 60%).

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Enable online block discard
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_volumes:
             - name: barefs
               type: disk
               disks:
                 - /dev/sdb
               fs_type: xfs
               mount_point: /mnt/data
               mount_options: discard

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       -name: Create and mount a file system
       ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
       vars:
         storage_safe_mode: false
   
         storage_volumes:
           - name: barefs
             type: disk
             disks:
               - sdb
             fs_type: ext4
             fs_label: label-name
             mount_point: /mnt/data

   Copy to Clipboard Toggle word wrap

   The setting specified in the example playbook include the following:

   disks: <list_of_devices>

   A YAML list of device names that the role uses when it creates the volume.

   fs_type: <file_system>

   Specifies the file system the role should set on the volume. You can select xfs, ext3, ext4, swap, or unformatted.

   label-name: <file_system_label>

   Optional: sets the label of the file system.

   mount_point: <directory>

   Optional: if the volume should be automatically mounted, set the mount_point variable to the directory to which the volume should be mounted.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a RAID on sdd, sde, sdf, and sdg
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_safe_mode: false
           storage_volumes:
             - name: data
               type: raid
               disks: [sdd, sde, sdf, sdg]
               raid_level: raid0
               raid_chunk_size: 32 KiB
               mount_point: /mnt/data
               state: present

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure LVM pool with RAID
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_safe_mode: false
           storage_pools:
             - name: my_pool
               type: lvm
               disks: [sdh, sdi]
               raid_level: raid1
               volumes:
                 - name: my_volume
                   size: "1 GiB"
                   mount_point: "/mnt/app/shared"
                   fs_type: xfs
                   state: present

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

   Note

   Setting raid_level at the storage_pool level creates an MD RAID array first, and then builds an LVM volume group on top of it.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure stripe size for RAID LVM volumes
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_safe_mode: false
           storage_pools:
             - name: my_pool
               type: lvm
               disks: [sdh, sdi]
               volumes:
                 - name: my_volume
                   size: "1 GiB"
                   mount_point: "/mnt/app/shared"
                   fs_type: xfs
                   raid_level: raid0
                   raid_stripe_size: "256 KiB"
                   state: present

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

   Note

   Setting raid_level at the volumes level creates LVM RAID logical volumes.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create LVM-VDO volume under volume group 'myvg'
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_pools:
             - name: myvg
               disks:
                 - /dev/sdb
               volumes:
                 - name: mylv1
                   compression: true
                   deduplication: true
                   vdo_pool_size: 10 GiB
                   size: 30 GiB
                   mount_point: /mnt/app/shared

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   vdo_pool_size: <size>

   The actual size that the volume takes on the device. You can specify the size in human-readable format, such as 10 GiB. If you do not specify a unit, it defaults to bytes.

   size: <size>

   The virtual size of VDO volume.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create ~/vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

      Copy to Clipboard Toggle word wrap

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      luks_password: <password>

      Copy to Clipboard Toggle word wrap
   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     vars_files:
       - ~/vault.yml
     tasks:
       - name: Create and configure a volume encrypted with LUKS
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_volumes:
             - name: barefs
               type: disk
               disks:
                 - sdb
               fs_type: xfs
               fs_label: <label>
               mount_point: /mnt/data
               encryption: true
               encryption_password: "{{ luks_password }}"
               encryption_cipher: <cipher>
               encryption_key_size: <key_size>
               encryption_luks_version: luks2

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   encryption_cipher: <cipher>

   Specifies the LUKS cipher. Possible values are: twofish-xts-plain64, serpent-xts-plain64, and aes-xts-plain64 (default).

   encryption_key_size: <key_size>

   Specifies the LUKS key size. The default is 512 bit.

   encryption_luks_version: luks2

   Specifies the LUKS version. The default is luks2.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     become: true
     tasks:
       - name: Create shared LVM device
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_pools:
             - name: vg1
               disks: /dev/vdb
               type: lvm
               shared: true
               state: present
               volumes:
                 - name: lv1
                   size: 4g
                   mount_point: /opt/test1
                   fs_type: gfs2
           storage_safe_mode: false
           storage_use_partitions: true

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Resize LVM PV size
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.storage
         vars:
           storage_pools:
              - name: myvg
                disks: ["sdf"]
                type: lvm
                grow_to_fill: true

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   grow_to_fill

   true The role automatically expands the storage volume to use any new capacity on the disk.

   false The role leaves the storage volume at its current size, even if the underlying disk has grown.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Verification

1. Verify the grow_to_fill setting works as expected. Prepare a test PV and VG:

   # pvcreate /dev/sdf
   # vgcreate myvg /dev/sdf

   Copy to Clipboard Toggle word wrap

2. Check and record the initial physical volume size:

   # pvs

   Copy to Clipboard Toggle word wrap
3. Edit the playbook to set grow_to_fill: false and run the playbook.
4. Check the volume size and verify that it remained unchanged.
5. Edit the playbook to set grow_to_fill: true and re-run the playbook.
6. Check the volume size and verify that it has expanded.

Procedure

1. Log in to the RHEL 10 web console.

2. Click the Storage tab.

   In the Storage table, you can see all available partitions formatted with file systems, their ID, types, locations, sizes, and how much space is available on each partition.

   

   You can also use the drop-down menu in the top-right corner to create new local or networked storage.

   

Procedure

1. Log in to the RHEL 10 web console.
2. Click the Storage tab.
3. In the Storage table, click the device which you want to partition to open the page and options for that device.
4. On the device page, click the menu button, ⋮, and select Create partition table.

5. In the Initialize disk dialog box, select the following:

   1. Partitioning:

      • Compatible with all systems and devices (MBR)
      • Compatible with modern system and hard disks > 2TB (GPT)
      • No partitioning

   2. Overwrite:

      • Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you need to overwrite it.

        If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

6. Click Initialize.
7. Click the menu button, ⋮, next to the partition table you created. It is named Free space by default.
8. Click Create partition.
9. In the Create partition dialog box, enter a Name for the file system.
10. Add a Mount point.

11. In the Type drop-down menu, select a file system:

    • XFS file system supports large logical volumes, switching physical drives online without outage, and growing an existing file system. Leave this file system selected if you do not have a different strong preference.

    • ext4 file system supports:

      • Logical volumes
      • Switching physical drives online without outage
      • Growing a file system
      • Shrinking a file system

    Additional option is to enable encryption of partition done by LUKS (Linux Unified Key Setup), which allows you to encrypt the volume with a passphrase.

12. Enter the Size of the volume you want to create.

13. Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you need to overwrite it.

    If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

14. If you want to encrypt the volume, select the type of encryption in the Encryption drop-down menu.

    If you do not want to encrypt the volume, select No encryption.

15. In the At boot drop-down menu, select when you want to mount the volume.

16. In Mount options section:

    1. Select the Mount read only checkbox if you want the to mount the volume as a read-only logical volume.
    2. Select the Custom mount options checkbox and add the mount options if you want to change the default mount option.

17. Create the partition:

    • If you want to create and mount the partition, click the Create and mount button.

    • If you want to only create the partition, click the Create only button.

      Formatting can take several minutes depending on the volume size and which formatting options are selected.

Procedure

1. Log in to the RHEL 10 web console.
2. Click the Storage tab.
3. Click the device from which you want to delete a partition.
4. On the device page and in the GPT partitions section, click the menu button, ⋮ next to the partition you want to delete.

5. From the drop-down menu, select Delete.

   The RHEL web console terminates all processes that are currently using the partition and unmount the partition before deleting it.

Procedure

1. By default, NFSv3 RPC services use random ports. To enable a firewall configuration, configure fixed port numbers in the /etc/nfs.conf file:

   1. In the [lockd] section, set a fixed port number for the nlockmgr RPC service, for example:

      port=5555

      Copy to Clipboard Toggle word wrap

      With this setting, the service automatically uses this port number for both the UDP and TCP protocol.

   2. In the [statd] section, set a fixed port number for the rpc.statd service, for example:

      port=6666

      Copy to Clipboard Toggle word wrap

      With this setting, the service automatically uses this port number for both the UDP and TCP protocol.

2. Open the relevant ports in firewalld:

   # firewall-cmd --permanent --add-service=rpc-bind
   # firewall-cmd --permanent --add-port={5555/tcp,5555/udp,6666/tcp,6666/udp}
   # firewall-cmd --reload

   Copy to Clipboard Toggle word wrap

3. Restart the rpc-statd service:

   # systemctl restart rpc-statd nfs-server

   Copy to Clipboard Toggle word wrap

Procedure

1. Edit the /etc/fstab file and add a line for the share that you want to mount:

   <nfs_server_ip_or_hostname>:/<exported_share>     <mount point>    nfs    default   0 0

   Copy to Clipboard Toggle word wrap

   For example, to mount the /nfs/projects share from the server.example.com NFS server to /home, enter:

   server.example.com:/nfs/projects    	/home        nfs 	defaults    	0 0

   Copy to Clipboard Toggle word wrap

2. Mount the share:

   # mount /home

   Copy to Clipboard Toggle word wrap

Procedure

1. Log in to the RHEL 10 web console.
2. Click Storage.
3. In the Storage table, click the menu button.

4. From the drop-down menu, select New NFS mount.

   

5. In the New NFS Mount dialog box, enter the server or IP address of the remote server.
6. In the Path on Server field, enter the path to the directory that you want to mount.
7. In the Local Mount Point field, enter the path to the directory on your local system where you want to mount the NFS.

8. In the Mount options check box list, select how you want to mount the NFS. You can select multiple options depending on your requirements.

   • Check the Mount at boot box if you want the directory to be reachable even after you restart the local system.
   • Check the Mount read only box if you do not want to change the content of the NFS.

   • Check the Custom mount options box and add the mount options if you want to change the default mount option.

     

9. Click Add.

Procedure

1. Log in to the RHEL 10 web console.
2. Click Storage.
3. In the Storage table, click the NFS mount you want to adjust.

4. If the remote directory is mounted, click Unmount.

   You must unmount the directory during the custom mount options configuration. Otherwise, the web console does not save the configuration and this causes an error.

5. Click Edit.
6. In the NFS Mount dialog box, select Custom mount option.

7. Enter mount options separated by a comma. For example:

   • nfsvers=4: The NFS protocol version number
   • soft: The type of recovery after an NFS request times out
   • sec=krb5: The files on the NFS server can be secured by Kerberos authentication. Both the NFS client and server have to support Kerberos authentication.

   For a complete list of the NFS mount options, enter man nfs in the command line.

8. Click Apply.
9. Click Mount.

Procedure

1. Obtain a kerberos ticket as an IdM administrator:

   # kinit admin

   Copy to Clipboard Toggle word wrap

2. Retrieve the host principal, and store it in the /etc/krb5.keytab file:

   # ipa-getkeytab -s idm_server.idm.example.com -p host/nfs_client.idm.example.com -k /etc/krb5.keytab

   Copy to Clipboard Toggle word wrap

   IdM automatically created the host principal when you joined the host to the IdM domain.

3. Optional: Display the principals in the /etc/krb5.keytab file:

   # klist -k /etc/krb5.keytab
   Keytab name: FILE:/etc/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM

   Copy to Clipboard Toggle word wrap

4. Use the ipa-client-automount utility to configure mapping of IdM IDs:

   # ipa-client-automount
   Searching for IPA server...
   IPA server: DNS discovery
   Location: default
   Continue to configure the system with these values? [no]: yes
   Configured /etc/idmapd.conf
   Restarting sssd, waiting for it to become available.
   Started autofs

   Copy to Clipboard Toggle word wrap

5. Mount an exported NFS share, for example:

   # mount -o sec=krb5i server.idm.example.com:/nfs/projects/ /mnt/

   Copy to Clipboard Toggle word wrap

   The -o sec option specifies the Kerberos security method.

Verification

1. Log in as an IdM user who has permissions to write on the mounted share.

2. Obtain a Kerberos ticket:

   $ kinit

   Copy to Clipboard Toggle word wrap

3. Create a file on the share, for example:

   $ touch /mnt/test.txt

   Copy to Clipboard Toggle word wrap

4. List the directory to verify that the file was created:

   $ ls -l /mnt/test.txt
   -rw-r--r--. 1 admin users 0 Feb 15 11:54 /mnt/test.txt

   Copy to Clipboard Toggle word wrap

Procedure

1. Add the following line to the beginning of the /etc/dconf/profile/user file. If the file does not exist, create it.

   service-db:keyfile/user

   Copy to Clipboard Toggle word wrap

   With this setting, dconf polls the keyfile back end to determine whether updates have been made, so settings might not be updated immediately.

2. The changes take effect when the users logs out and in.

Procedure

1. Create a private key and a certificate signing request (CSR):

   # openssl req -new -newkey rsa:4096 -noenc \
   -keyout /etc/pki/tls/private/server.example.com.key \
   -out /etc/pki/tls/private/server.example.com.csr \
   -subj "/C=US/ST=State/L=City/O=Organization/CN=server.example.com" \
   -addext "subjectAltName=DNS:server.example.com,IP:192.0.2.1"

   Copy to Clipboard Toggle word wrap
   Important

   Common Name (CN) and DNS must match the hostname. IP must match IP of the host.

2. Send the /etc/pki/tls/private/server.example.com.csr file to a CA and request a server certificate. Store the received CA certificate and the server certificate on the host.

3. Import the CA certificate to the systems’s truststore:

   # cp ca.crt /etc/pki/ca-trust/source/anchors
   # update-ca-trust

   Copy to Clipboard Toggle word wrap

4. Move the server certificate to the /etc/pki/tls/certs/ directory:

   # mv server.example.com.crt /etc/pki/tls/certs/

   Copy to Clipboard Toggle word wrap

5. Ensure the SELinux context is correct on the private key and certificates:

   # restorecon -Rv /etc/pki/tls/certs/

   Copy to Clipboard Toggle word wrap

6. Add the server certificate and private key to the [authenticate.server] section in the /etc/tlshd.conf file:

   x509.certificate= /etc/pki/tls/certs/server.example.com.crt
   x509.private_key= /etc/pki/tls/private/server.example.com.key

   Copy to Clipboard Toggle word wrap

   Leave the x509.truststore parameter unset.

7. Enable and start the tlshd service:

   # systemctl enable --now tlshd.service

   Copy to Clipboard Toggle word wrap

Procedure

1. Import the Certificate Authority (CA) certificate to the systems’s truststore:

   # cp ca.crt /etc/pki/ca-trust/source/anchors
   # update-ca-trust

   Copy to Clipboard Toggle word wrap

2. Enable and start the tlshd service:

   # systemctl enable --now tlshd.service

   Copy to Clipboard Toggle word wrap

3. Mount an NFS share by using TLS encryption:

   # mount -o xprtsec=tls server.example.com:/nfs/projects/ /mnt/

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a private key and a certificate signing request (CSR):

   # openssl req -new -newkey rsa:4096 -noenc \
   -keyout /etc/pki/tls/private/client.example.com.key \
   -out /etc/pki/tls/private/client.example.com.csr \
   -subj "/C=US/ST=State/L=City/O=Organization/CN=client.example.com" \
   -addext "subjectAltName=DNS:client.example.com,IP:192.0.2.2"

   Copy to Clipboard Toggle word wrap
   Important

   Common Name (CN) and DNS must match the hostname. IP must match IP of the host.

2. Send the /etc/pki/tls/private/client.example.com.csr file to a Certificate Authority (CA) and request a client certificate. Store the received CA certificate and the client certificate on the host.

3. Import the CA certificate to the systems’s truststore:

   # cp ca.crt /etc/pki/ca-trust/source/anchors
   # update-ca-trust

   Copy to Clipboard Toggle word wrap

4. Move the client certificate to the /etc/pki/tls/certs/ directory:

   # mv client.example.com.crt /etc/pki/tls/certs/

   Copy to Clipboard Toggle word wrap

5. Ensure the SELinux context is correct on the private key and certificates:

   # restorecon -Rv /etc/pki/tls/certs/

   Copy to Clipboard Toggle word wrap

6. Add the client certificate and private key to the [authenticate.client] section in the /etc/tlshd.conf file:

   x509.certificate= /etc/pki/tls/certs/client.example.com.crt
   x509.private_key= /etc/pki/tls/private/client.example.com.key

   Copy to Clipboard Toggle word wrap

   Leave the x509.truststore parameter unset.

7. Enable and start the tlshd service:

   # systemctl enable --now tlshd.service

   Copy to Clipboard Toggle word wrap

8. Mount an NFS share by using TLS encryption:

   # mount -o xprtsec=mtls server.example.com:/nfs/projects/ /mnt/

   Copy to Clipboard Toggle word wrap

Procedure

1. Set the server min protocol parameter in the [global] section in the /etc/samba/smb.conf file to NT1.

2. Mount the share using the SMB 1 protocol by providing the -o vers=1.0 option to the mount command. For example:

   # mount -t cifs -o vers=1.0,username=<user_name> //<server_name>/<share_name> /mnt/

   Copy to Clipboard Toggle word wrap

   By default, the kernel module uses SMB 2 or the highest later protocol version supported by the server. Passing the -o vers=1.0 option to the mount command forces that the kernel module uses the SMB 1 protocol that is required for using UNIX extensions.

Procedure

1. Add an entry for the share to the /etc/fstab file. For example:

   //<server_name>/<share_name>  /mnt  cifs  credentials=/root/smb.cred  0 0

   Copy to Clipboard Toggle word wrap
   Important

   To enable the system to mount a share automatically, you must store the user name, password, and domain name in a credentials file. For details, see Creating a credentials file to authenticate to an smb share.

   In the fourth field of the row in the /etc/fstab, specify mount options, such as the path to the credentials file. For details, see the OPTIONS section in the mount.cifs(8) man page and Frequently used SMB mount options.

Procedure

1. Create a file, such as /root/smb.cred, and specify the user name, password, and domain name in that file:

   username=user_name
   password=password
   domain=domain_name

   Copy to Clipboard Toggle word wrap

2. Set the permissions to only allow the owner to access the file:

   # chown user_name /root/smb.cred
   # chmod 600 /root/smb.cred

   Copy to Clipboard Toggle word wrap

   You can now pass the credentials=file_name mount option to the mount utility or use it in the /etc/fstab file to mount the share without being prompted for the user name and password.

Procedure

1. Start the parted utility. For example, the following output lists the device /dev/sda:

   # parted /dev/sda

   Copy to Clipboard Toggle word wrap

2. View the partition table:

   (parted) print
   
   Model: ATA SAMSUNG MZNLN256 (scsi)
   Disk /dev/sda: 256GB
   Sector size (logical/physical): 512B/512B
   Partition Table: msdos
   Disk Flags:
   
   Number  Start   End     Size    Type      File system  Flags
    1      1049kB  269MB   268MB   primary   xfs          boot
    2      269MB   34.6GB  34.4GB  primary
    3      34.6GB  45.4GB  10.7GB  primary
    4      45.4GB  256GB   211GB   extended
    5      45.4GB  256GB   211GB   logical

   Copy to Clipboard Toggle word wrap

3. Optional: Switch to the device you want to examine next:

   (parted) select block-device

   Copy to Clipboard Toggle word wrap

   For a detailed description of the print command output, see the following:

   Model: ATA SAMSUNG MZNLN256 (scsi)

   The disk type, manufacturer, model number, and interface.

   Disk /dev/sda: 256GB

   The file path to the block device and the storage capacity.

   Partition Table: msdos

   The disk label type.

   Number

   The partition number. For example, the partition with minor number 1 corresponds to /dev/sda1.

   Start and End

   The location on the device where the partition starts and ends.

   Type

   Valid types are metadata, free, primary, extended, or logical.

   File system

   The file system type. If the File system field of a device shows no value, this means that its file system type is unknown. The parted utility cannot recognize the file system on encrypted devices.

   Flags

   Lists the flags set for the partition. The most commonly used flags are boot, root, swap, hidden, raid, lvm, or lba. For a complete list of flags, see parted(8) man page on your system.

Procedure

1. Start the interactive parted shell:

   # parted block-device

   Copy to Clipboard Toggle word wrap

2. Determine if there already is a partition table on the device:

   (parted) print

   Copy to Clipboard Toggle word wrap

   If the device already contains partitions, they will be deleted in the following steps.

3. Create the new partition table:

   (parted) mklabel table-type

   Copy to Clipboard Toggle word wrap

   • Replace table-type with with the intended partition table type:

     • msdos for MBR

     • gpt for GPT

       For example to create a GPT table on the disk, use:

       (parted) mklabel gpt

       Copy to Clipboard Toggle word wrap

       The changes start applying after you enter this command.

4. View the partition table to confirm that it is created:

   (parted) print

   Copy to Clipboard Toggle word wrap

5. Exit the parted shell:

   (parted) quit

   Copy to Clipboard Toggle word wrap

Procedure

1. Start the parted utility:

   # parted block-device

   Copy to Clipboard Toggle word wrap

2. View the current partition table to determine if there is enough free space:

   (parted) print

   Copy to Clipboard Toggle word wrap
   • Resize the partition in case there is not enough free space.

   • From the partition table, determine:

     • The start and end points of the new partition.
     • On MBR, what partition type it should be.

3. Create the new partition:

   For MS-DOS:

   (parted) mkpart part-type fs-type start end

   Copy to Clipboard Toggle word wrap

   For GPT:

   (parted) mkpart part-name fs-type start end

   Copy to Clipboard Toggle word wrap
   • Replace part-type with primary, logical, or extended. This applies only to the MBR partition table.
   • Replace name with an arbitrary partition name. This is required for GPT partition tables.
   • Replace fs-type with xfs, ext2, ext3, ext4, fat16, fat32, hfs, hfs+, linux-swap, ntfs, or reiserfs. The fs-type parameter is optional. Note that the parted utility does not create the file system on the partition.

   • Replace start and end with the sizes that determine the starting and ending points of the partition, counting from the beginning of the disk. You can use size suffixes, such as 512MiB, 20GiB, or 1.5TiB. The default size is in megabytes.

     For example, to create a primary partition from 1024 MiB until 2048 MiB on an MBR table, use:

     (parted) mkpart primary 1024MiB 2048MiB

     Copy to Clipboard Toggle word wrap

     The changes start applying after you enter the command.

4. View the partition table to confirm that the created partition is in the partition table with the correct partition type, file system type, and size:

   (parted) print

   Copy to Clipboard Toggle word wrap

5. Exit the parted shell:

   (parted) quit

   Copy to Clipboard Toggle word wrap

6. Verify that the kernel recognizes the new partition:

   # cat /proc/partitions

   Copy to Clipboard Toggle word wrap