Changes to the default storage directory should be made before any captures are uploaded to your CloudShark system. Existing capture files will need to be imported into CloudShark again following any storage path changes. This procedure should only be done during your initial configuration.
Updating the Storage Directory
We’ll call ours /data. Grant ownership to the cloudshark user and group:
mkdir /data chown cloudshark.cloudshark /data
Do not adjust the directory location by manually editing the cloudshark.conf file. This is not supported.
You must create a symbolic link inside the /usr/cloudshark/data directory to your new storage directory.
mv /usr/cloudshark/data /usr/cloudshark/data.original ln -s /data /usr/cloudshark/data
This replaces the CloudShark uploads directory immediately. No restart is required.
To make sure that this storage location is available before the
CloudShark service starts you can add this as a requirement to the
service. First run
systemctl edit cloudshark.service and add a line
similar to the one below:
Replace /data in the line above with the directory your CloudShark
instance is storing it’s captures. Then run
systemctl daemon-reload to
apply the change and
systemctl cat cloudshark.service to verify. The
output of the cat command should look similar to:
# /usr/lib/systemd/system/cloudshark.service [Unit] Description=Top level CloudShark process monitor After=syslog.target network.target mariadb.service memcached.service cloudshark-redis.service [Service] Type=forking User=root Group=root ExecStartPre=/usr/bin/rm -rf /run/blkid/blkid.tab ExecStartPre=/bin/sh -c "/usr/sbin/blkid $(cat /usr/cloudshark/etc/blkid_dev)" ExecStart=/usr/cloudshark/ruby/bin/ruby /usr/cloudshark/ruby/bin/god -c /var/www/cloudshark/shared/config/cloudshark.god PIDFile=/run/god.pid [Install] WantedBy=multi-user.target # /etc/systemd/system/cloudshark.service.d/override.conf [Unit] RequiresMountsFor=/data
A common scenario is to mount a remote file system on a CloudShark host, to improve the size, speed, and robustness of the system storage. The section above details how to change the default storage directory for the system’s capture files.
NFS does not support the inotify system call, which allows a system to be alerted of file system changes. Because the CloudShark Autoimporter relies on this system call to operate, it is not possible to mount a remote NFS share as an AutoImport target. Files that end up published to the remote NFS share do not trigger the event and thus, no files are imported.
An NFS file system which is exported from CloudShark does not have this limitation because the file events are still processed by the same system.