NFS Storage

The CloudShark OVA includes a dedicated data disk mounted at /storage by default. For enterprise deployments, especially High Availability configurations, we recommend using NFS or S3 storage instead of the included data disk to store capture files and the CloudShark configuration. This article describes how to setup a new OVA or migrate an existing one to use NFS storage.

Database Storage Limitation: MariaDB database files should not be stored on NFS. NFS filesystems don’t support the SELinux extended attributes and file locking mechanisms that MariaDB requires for reliable operation. Store only /storage/data and /storage/etc on NFS, and keep /storage/db on the external data disk or configure CloudShark to use an external database.

Best Practices

For High Availability deployments CloudShark should be configured with the following:

  • NFS Storage: /storage/data (capture files) and /storage/etc (configuration)
  • External Database Server: For best performance and reliability in HA environments, run MariaDB on a separate dedicated server

Instructions

The following is an example configuration where /storage/data and /storage/etc are stored on an NFS share using example-server as the NFS server and /cloudshark-storage as the folder.

  1. Stop CloudShark and back up the existing /storage/data and /storage/etc directories:

    systemctl reset-failed && systemctl stop cloudshark-full cloudshark-threat-assessment
    mv /storage/data /storage/data.orig
    mv /storage/etc /storage/etc.orig
    
  2. Create mount points for NFS storage:

    mkdir -p /mnt/nfs/data /mnt/nfs/etc
    
  3. Add your NFS mount entry to /etc/fstab for capture files and configuration. Replace example-server and /cloudshark-storage with your NFS server details:

    # Mount NFS storage for data and etc
    example-server:/cloudshark-storage/data /mnt/nfs/data nfs defaults 0 0
    example-server:/cloudshark-storage/etc /mnt/nfs/etc nfs defaults 0 0
    
  4. Mount all configured storage:

    systemctl daemon-reload
    mount -a
    
  5. Create symlinks to point /storage/data and /storage/etc to the NFS mount:

    ln -s /mnt/nfs/data /storage/data
    ln -s /mnt/nfs/etc /storage/etc
    
  6. Set the correct ownership on all storage directories:

    chown -R cloudshark:cloudshark /mnt/nfs/ /storage/data /storage/etc
    

Config Files

The files under /storage/etc are used to configure CloudShark and the underlying applications it uses including Wireshark, Suricata, and Zeek.

To initially populate the /storage/etc directory with the default configuration, and any changes made to the OVA, copy the files backed up in step 1 above to the NFS share:

cp -r --preserve /storage/etc.orig/* /storage/etc/

Once the configuration files are stored on the NFS share, new instances of CloudShark can use the existing configuration and skip this step.

Existing Data

If you have an existing CloudShark OVA deployment and want to migrate to external storage:

cp -r --preserve /storage/data.orig/* /storage/data/

SELinux

When using NFS storage, SELinux requires additional configuration to allow access to network-mounted files.To enable SELinux to allow CloudShark to use NFS:

semanage fcontext -a -t usr_t "/storage/etc(/.*)?"
restorecon -Rv /storage/etc/
setsebool -P httpd_use_nfs on

Restart

After configuring storage and copying the initial config files and any existing capture file data, restart nginx and CloudShark:

systemctl reset-failed
systemctl restart nginx cloudshark-full cloudshark-threat-assessment

After restarting and verifying that CloudShark is running, make sure that any existing capture files can be opened and that the correct configuration is applied. Once you have confirmed this the backups created above can be removed from the data disk:

rm -rf /storage/etc.orig
rm -rf /storage/data.orig