Table_of_Contents
1.3 Backup SecureOffice System
1.4 Restore SecureOffice System
1.5 Backup / Restore Additional Packages / Data
1.6 Backup / Restore Large Amounts of Data
2 Install an Additional Hard Disk
2.1 Determine Linux Name for New Disk
2.3 Partition and Format New Disk
2.4 Mount New Disk
4 Upgrade SecureOffice Version
5.1 Samba (Windows File Sharing)
5.1.1 Samba Server
5.1.2 Samba Client
Samba Credentials File (Linux)
5.2.1 NFS Server
5.2.2 NFS Client
5.3 SSHFS (Secure File Sharing)
5.3.1 SSHFS Server
5.3.2 Configure SSHFS Server Key Authentication
5.3.3 SSHFS Client
5.3.4 Configure SSHFS Client Key Authentication
5.4 Cloud Storage Using RClone
5.6 Install Rclone on SecureOffice
List of Figures
Figure 1: OpenWrt Backup
Figure 2: SecurePBX Backup / Restore Script
Figure 3: User Backup / Restore Script
Figure 4: Docker-Nextcloud Backup Task
Figure 5: Docker-Nextcloud GUI Backup / Restore Script
Figure 6: Add Mount Entry for Disk
Figure 7: Example Samba Configuration
Figure 8: Samba Firewall Configuration
Figure 9: Example Samba Credentials File
Figure 10: Hotplug Script For Remote Directories
Figure 11: Secure Dropbear Instance
Figure 12: Secure Dropbear Firewall Rule
Figure 13: DropbearKey Creation Result
Figure 14: RClone Configuration Page
Figure 15: RClone Main Page
Figure 16: RClone Explorer Page
Once you are satisfied with SecureOffice installed packages and configuration, have installed extra packages or re-configured, it is prudent to keep regular backups for disaster recovery and system upgrade purposes.
It is not yet possible to update SecureOffice (flash new firmware) using Backup / Restore. The current way to upgrade SecureOffice is to back up the existing system, re-install SecureOffice and restore from backup.
SecureOffice backup / restore saves / restores all settings, including databases from all installed (including SecurePBX, VmWare Workstation, ZoneMinder, NXserver, Nextcloud, Home Assistant) applications. If any of the packages in the previous list were installed at backup, and not installed at restore, they will be re-installed upon restore.
Virtual machine configuration is saved and restored. Virtual machines are not backed up or restored. To backup virtual machines, stop the virtual machine, tar the VM directory and save the archive to another location.
It is suggested to keep a list of additional packages to install after re-installing SecureOffice, before performing a restore.
SecureOffice backup / restore is (Luci GUI) accessed by the "System->Backup / Flash Firmware" menu, as shown below:
Figure 1: OpenWrt Backup
To perform a backup, select "Generate Archive". You will be prompted for a location (on your PC) to save the backup archive. Select a directory location. Backup is done.
Install any additional (previously installed) packages prior to performing a restore.
To perform a restore, select "Browse". Select the file (on your PC) containing a previous backup. Select "Upload Archive". During restore, SecureOffice will reboot, causing connection loss. You will need to reconnect to SecureOffice WiFi and start a new secure shell session. It also takes some time for restore to complete. Be patient. When restore is complete, SecureOffice WiFi will be up and will respond to ping.
If, after some time (may take a while for package installation), SecureOffice is not responding to ping, something has failed. Examine "/etc/backup.log" to fix any issues.
File "/etc/backup.log" always contains the results of the most recent backup / restore.
Backup / restore progress can be observed (SecureOffice console session using physical monitor, keyboard) by entering "tail -f /etc/backup.log" after backup / restore has started.
If, for disaster recovery purposes (such as a failed system disk), it is undesirable to download and re-install SecureOffice from the internet and a local copy is preferred, this can be done by downloading and saving a copy of SecureOffice for a subsequent offline install and then restoring current configuration from backup.
To determine current SecureOffice revision and architecture, at a command prompt, enter "set" to display environment variables. Resulting "OPENWRT_VERSION" will be referred to as "<openwrt version>" and architecture will be referred to as "<architecture>".
At a command prompt, enter "cd /tmp; wget --no-check-certificate https://www.rossco.org/Downloads/OpenWrt/<openwrt version>/SecureOffice-<architecture>.img.gz". Using WinSCP or another file transfer program, copy "SecureOffice-<architecture>.img.gz" to where your backups are stored.
Assuming you have a local copy of "SecureOffice-<architecture>.img.gz" saved from the previous section (or correct version and architecture downloaded from here) and want to restore by completely overwriting the target disk, use one of the SecureOffice installation options to write the disk image. After complete, install the disk on the target system and boot the target. Restore configuration from a recent backup.
Standard OpenWrt provides a way to specify extra files / directories to backup / restore (Menu: Backup / Flash Firmware -> Configuration). OpenWrt lacks a way to specify extra packages to install at restore and complex backup / restore tasks for data such as databases.
SecureOffice extends OpenWrt backup / restore to allow greater user control over what is backed up / restored using scripts in directory "/etc/backup/". These scripts are called by the main backup / restore task. Packages such as securepbx, vmplayer and docker containers install their own backup scripts. As an example, script "/etc/backup/securepbx" backups / restores securepbx, including installation and database:
#!/bin/sh
is_installed()
{
pkg=$(opkg list-installed | grep "^$1 " | cut -d " " -f1 | cat )
if [[ "$pkg" == "$1" ]]; then return 1; else return 0; fi
}
install_licensed_pkg()
{
# $1 is package name
is_installed $1
if [ $? -eq 0 ]; then
# Install package minus license files
opkg --force-checksum install $1 2>&1 >> $LOGFILE
# Restore license files
cp $RESTORE_DIR/packages/$1-*.ipk /packages
tar -zxf /packages/$1-*.ipk -C /
fi
# See if license OK - hardware may have changed
vtdaemon -S $(uci get vtlicense.$1.name) -V
if [ $? -ne 0 ]; then
PACKAGE=$(uci get vtlicense.$1.name)
# Update registration
vtdaemon -S $PACKAGE -R
# Update license
TIME=0;
until [ $TIME -eq 5 ] || vtdaemon -S $PACKAGE -G; do
sleep 30; $(( TIME++ ))
done
if [ $TIME -eq 5 ]; then echo "Failed to restore $PACKAGE license" >> $LOGFILE; fi
fi
}
if [ "$1" == "save" ]; then
is_installed securepbx
if [ $? -eq 0 ]; then exit 0; fi
find /etc/freeswitch >> $CONFIG_FILES 2>> $LOGFILE
sed -i '\#/etc/freeswitch/languages#d' $CONFIG_FILES
sed -i '/freeswitch.serial/d' $CONFIG_FILES
echo "/etc/fusionpbx/config.php" >> $CONFIG_FILES
# Remove database bloat
psql -Upostgres -d fusionpbx -c 'TRUNCATE TABLE v_xml_cdr RESTART IDENTITY;' >> $LOGFILE 2>&1
psql -Upostgres -d fusionpbx -c 'TRUNCATE TABLE v_voicemail_messages RESTART IDENTITY;' >> $LOGFILE 2>&1
psql -Upostgres -d fusionpbx -c 'TRUNCATE TABLE v_database_transactions RESTART IDENTITY;' >> $LOGFILE 2>&1
psql -Upostgres -d fusionpbx -c 'TRUNCATE TABLE v_fax_logs RESTART IDENTITY;' >> $LOGFILE 2>&1
# backup fusionpbx database
su - -c "/usr/bin/pg_dump -U postgres -f /tmp/fusionpbx_backup.sql fusionpbx" postgres >> $LOGFILE 2>&1
echo "/tmp/fusionpbx_backup.sql" >> $CONFIG_FILES
# Save license files
find /packages | grep securepbx- | grep ipk >> $CONFIG_FILES 2>> $LOGFILE
elif [ -d $RESTORE_DIR/etc/freeswitch ]; then
install_licensed_pkg securepbx
# Installation may have overwritten do_basics() restored files
cp -rf $RESTORE_DIR/etc/freeswitch/* /etc/freeswitch
# Drop old database, create new database, import configuration, create fusionpbx db user
chown -Rf postgres /usr/fusionpbx/fusionpbxDB
su - -c "/usr/bin/psql -c \"CREATE USER fusionpbx WITH PASSWORD 'fusionpbx';\"" postgres
su - -c "/usr/bin/psql -c \"DROP DATABASE fusionpbx\"" postgres
su - -c "/usr/bin/createdb fusionpbx" postgres
su - -c "/usr/bin/psql -U postgres -d fusionpbx -f $RESTORE_DIR/tmp/fusionpbx_backup.sql" postgres
# Freeswitch is started by hotplug script @ifup wan, don't enable
/etc/init.d/freeswitch disable;
fi
Figure 2: SecurePBX Backup / Restore Script
Scripts in "/etc/backup" are called with one parameter" "save" or restore" with environment variables $LOGFILE, $RESTORE_DIR (decompressed directory to restore from) and $CONFIG_FILES (file containing list of files to backup).
Script "/etc/backup/xtras" is intended for users to add extra packages / files to backup / restore, shown below:
#!/bin/sh
# Example package backup / restore script
# Called by /sbin/sysupgrade
# Very important, during save, all commands except tar (> stdout) should not generate output,
# else, downloaded backup file will be corrupted
# Environment variables
# $1 = save | restore (action)
# $RESTORE_DIR, base directory of backed up files to restore
# $LOGFILE output log
# $CONFIG_FILES, echo "full path of file to save" >> $CONFIG_FILES 2>> $LOGFILE
# $CONFIG_FILES, find full_path_of_directory_to_save >> $CONFIG_FILES 2>> $LOGFILE
# Extra packages to install at restore
#EXTRA_PACKAGES="luci-app-openvpn openvpn-openssl luci-app-nginx-certificates"
is_installed()
{
pkg=$(opkg list-installed | grep "^$1 " | cut -d " " -f1 | cat )
if [[ "$pkg" == "$1" ]]; then return 1; else return 0; fi
}
if [ "$1" == "save" ]; then
is_installed ppp-mod-pptp
if [ $? -eq 1 ]; then
echo "/etc/ppp/options.pptp" >> $CONFIG_FILES 2>> $LOGFILE
echo "/etc/hotplug.d/iface/30-ppp0" >> $CONFIG_FILES 2>> $LOGFILE
fi
else
if [ ! -z "$EXTRA_PACKAGES" ]; then
opkg install $EXTRA_PACKAGES 2>&1 >> $LOGFILE
fi
if [ -f $RESTORE_DIR/etc/ppp/options.pptp ]; then
opkg install ppp-mod-pptp 2>&1 >> $LOGFILE 2>> $LOGFILE
cp $RESTORE_DIR/etc/ppp/options.pptp /etc/ppp/options.pptp
cp $RESTORE_DIR/etc/hotplug.d/iface/30-ppp0 /etc/hotplug.d/iface/30-ppp0
fi
fi
Figure 3: User Backup / Restore Script
Some applications such as docker-nextcloud and virtual machines have a lot of data, too much for OpenWrt backup / restore to handle in a timely manner. SecureOffice provides an alternate backup / restore method to handle large backups. Essentially, backup uses a cron task for backup to a mounted directory and Luci GUI backs up configuration and restores from the archive created by the cron backup task.
SecureOffice defines a standard mount point (default: "/home/backup", configured in "/etc/config/dockerd") for mounting external storage (network / external disks) devices for storing bulk backup data. It is a requirement for docker-nextcloud backup / restore that this mount point exist and that a storage device of sufficient capacity (minimum 32GB) be mounted.
Options for external storage at "/home/backup" are:
The backup / restore methodology for docker-nextcloud can serve as an example for backing up / restoring large user application data such as virtual machines.
For docker-nextcloud, bulk data and database backup is performed by a weekly cron task (every Sunday at 11:30 PM), using script "/etc/nextcloud-backup.sh" shown below:
#!/bin/sh
is_installed()
{
pkg=$(opkg list-installed | grep "^$1 " | cut -d " " -f1 | cat )
if [[ "$pkg" == "$1" ]]; then return 1; else return 0; fi
}
data_root=$(uci get dockerd.globals.data_root)_data
backup=$(uci get dockerd.globals.backup)
if [ -z $data_root ] || [ -z $backup ]; then
logger "ERROR: /etc/config/dockerd is missing data_root and / or backup entries."
exit 0
fi
is_installed docker-nextcloud
if [ $? != 0 ]; then
nextcloud=$(docker ps | grep nextcloud | cut -d " " -f1)
if [ ! -z "$nextcloud" ]; then
docker exec -u www-data "$nextcloud" php /var/www/html/occ maintenance:mode --on
fi
# Save nextcloud database
su - -c "/usr/bin/pg_dump -U postgres -f /tmp/nextcloud_backup.sql nextcloud" postgres
mv /tmp/nextcloud_backup.sql $data_root/nextcloud/nextcloud_backup.sql
# Too big for openwrt backup
cd $data_root; tar -zcf $backup/nextcloud.tar.gz nextcloud; cd -
rm -f $data_root/nextcloud/nextcloud_backup.sql
if [ ! -z "$nextcloud" ]; then
docker exec -u www-data "$nextcloud" php /var/www/html/occ maintenance:mode --off
fi
fi
Figure 4: Docker-Nextcloud Backup Task
The most recent docker-nextcloud backup (within a week) is in file "/home/backup/ nextcloud.tar.gz". This backup is used during restore via Luci web GUI (next script, below).
During backup / restore using the SecureOffice / OpenWrt GUI, script "/etc/backup/docker-nextcloud" is called, shown below:
#!/bin/sh
# Nextcloud data is too big for OpenWrt backup
# due to XHR timeouts while compressing
# Instead, backup is done by a cron job: /etc/nextcloud-backup.sh
# Restore is done using /home/backup/nextcloud.tar.gz (created by cron)
is_installed()
{
pkg=$(opkg list-installed | grep "^$1 " | cut -d " " -f1 | cat )
if [[ "$pkg" == "$1" ]]; then return 1; else return 0; fi
}
data_root=$(uci get dockerd.globals.data_root)_data
backup=$(uci get dockerd.globals.backup)
if [ -z $data_root ] || [ -z $backup ]; then
echo "ERROR: /etc/config/dockerd is missing data_root and / or backup entries." >> $LOGFILE
exit 0
fi
if [ "$1" == "save" ]; then
is_installed coturn
if [ $? != 0 ]; then
echo "/etc/turnserver.conf" >> $CONFIG_FILES
fi
else
timeout=30
# Unmount detected disks at /mnt/sdxy
block umount
# And mount per /etc/config/fstab
block mount
until $(mount | grep $backup > /dev/null); do
mount >> $LOGFILE
sleep 5
timeout=$(($timeout-5))
if [ $timeout -lt 0 ]; then
echo "ERROR: Nothing mounted at $backup. Cannot restore nextcloud." >> $LOGFILE
exit 0
fi
done
if [ -f $backup/nextcloud.tar.gz ]; then
opkg install docker-nextcloud 2>&1 >> $LOGFILE
# Restore config overwritten by install
cp $RESTORE_DIR/etc/config/docker/nextcloud /etc/config/docker/nextcloud
# Nuke old data
rm -rf $data_root/nextcloud
mkdir -p $data_root/nextcloud
chmod 775 $data_root/nextcloud
cd $data_root; tar -zxf $backup/nextcloud.tar.gz; cd -
chown -R www-data:root $data_root/nextcloud
# Get db user and password
dbuser=$(cat $data_root/nextcloud/config/config.php | grep dbuser | cut -d "'" -f 4)
dbpass=$(cat $data_root/nextcloud/config/config.php | grep dbpassword | cut -d "'" -f 4)
# Restore nextcloud database
su - -c "/usr/bin/psql -c \"CREATE USER $dbuser WITH PASSWORD '$dbpass';\"" postgres
su - -c "/usr/bin/psql -c \"DROP DATABASE nextcloud\"" postgres
su - -c "/usr/bin/createdb nextcloud" postgres
su - -c "/usr/bin/psql -U postgres -d nextcloud -f $data_root/nextcloud/nextcloud_backup.sql" postgres
rm -f $data_root/nextcloud/nextcloud_backup.sql
# exit maintenance mode entered and saved during backup
sed -i "s/'maintenance' => .*,/'maintenance' => false,/g" $data_root/nextcloud/config/config.php
if [ -f $RESTORE_DIR/etc/turnserver.conf ]; then
opkg install coturn
cp $RESTORE_DIR/etc/turnserver.conf /etc/turnserver.conf
/etc/init.d/coturn enable
fi
fi
fi
Figure 5: Docker-Nextcloud GUI Backup / Restore Script
Another disk may be used to increase bulk storage for applications such as virtual machines, docker containers or as a RAID array member.
If the new disk is TF, SD, mSATA or SATA, power off SecureOffice, physically install the new disk and boot SecureOffice for the new disk to be detected.
If the new disk is connected via USB (Pendrive, SATA enclosure), it will be auto-detected when plugged in and re-boot is not necessary.
It is assumed you are at a Linux command prompt on SecureOffice, either directly or using PuTTY.
During boot, Linux enumerates block devices (disks) and assigns them names: "sda, sdb, sdc", etc. The Linux device name of the new disk needs to be identified.
Enter "dmesg". You are looking for a portion of output (from dmesg) of the following form, corresponding to the new disk, where XXX is the disk size in GB:
"sd 2:0:0:0: [sdb] 976773168 512-byte logical blocks: (XXX GB/YYY GiB)"
If the size of the new disk is unique (only one on system with XXX equal to the new disk size), this is likely the correct disk (sdb, sdc, etc). Note that "sda" cannot be the correct disk, since that contains the OS of SecureOffice.
As a sanity check, to confirm the new disk candidate is correct, the disk partitions can be inspected using the "fdisk" command.
Enter "fdisk /dev/disk" where "disk" is the candidate identified above (sdb, sdc, etc).
If still uncertain regarding correct disk choice (candidate disk has partitions you are unsure of), another sanity check is to inspect the disk contents.
The identified disk will be re-partitioned and formatted in the next step, wiping out all data on the chosen disk. Be absolutely certain the disk chosen is the correct disk. Otherwise, at best, you will lose all data on the disk, at worse, wipe out the SecureOffice operating system. Recovery from this disaster is left as an exercise for the reader.
This step is optional and should only be done to replace the swap partition on the system disk by a swap partition on a fast mSATA or SATA disk. Never use a TF, SD or USB connected disk for swap, it will degrade performance.
After standard installation, the SecureOffice swap partition is on "/dev/sda3" (system disk). It may be advantageous to create a swap partition on the new disk for the following reasons:
To create a swap partition:
The new swap partition will be activated in section Mount New Disk.
It is assumed that the new disk will contain bulk data such as virtual machines, docker images, documents or is intended to be a RAID array member. If multiple data partitions are desired, Google is your friend.
If a swap partition was created (above), using a SecureOffice command prompt:
If a swap partition was not created (above), using a SecureOffice command prompt:
The new disk needs a mount point (directory) on the SecureOffice filesystem, which must be created. It is assumed that the disk is to be mounted automatically at boot. These instructions assume you want to mount the new disk at "/home/data". This is the standard path for SecureOffice bulk data. Change the path according to preference.
Enter "mkdir -p /home/data" to create the mount point if it does not already exist.
Enter "blkid" to determine the UUID corresponding to your new disk. You will see a response similar to: '/dev/sdXY: UUID="5ec55ff2-6e79-46ea-9228-36e0dc11a88f" TYPE="ext4" PARTUUID="63ef2a2c-01"', where sdXY corresponds to the new disk. If a swap partition was created on the new disk, you will also see a UUID ending in "swap" for the new disk.
The UUID(s) will be used for automatic mounting (at boot) of your new disk by changing entries in the "/etc/config/fstab" file.
Enter "nano /etc/config/fstab" and change entries for your new disk, like the figure below.
config global automount
option from_fstab '1'
option anon_mount '1'
option delay_root '5'
option check_fs '1'
config global autoswap
option from_fstab '1'
option anon_swap '0'
config 'swap'
option uuid '<UUID of desired swap partition>'
option enabled '1'
config mount
option target '/home/data'
option options 'rw'
option uuid '<UUID of new data partition>'
Figure 6: Add Mount Entry for Disk
If you changed the swap partition, reboot to have the changes take effect.
Adding or replacing disks may result in changed disk enumeration order, requiring boot device reconfiguration.
After reboot, "/dev/sda4" (data partition of system disk) will be mounted at "/mnt/sda4" instead of (default) "/home/data" and the new disk will be mounted at "/home/data".
If the previous "/home/data" (/dev/sda4) directory contained important data, it can be copied to the new disk by entering "cp -rf /mnt/sda4/* /home/data". If desired, the files in "/mnt/sda4" can be deleted ("rm -rf /mnt/sda4/*") to reclaim storage space.
If the data at "/home/data" is used by applications, it may be necessary to reboot for applications to access their data.
If the swap and data partitions were moved to the new disk, storage space (on system disk) can be reclaimed by deleting the swap and data partitions, adding and formatting a new, larger data partition on the system disk:
It may be required to replace the primary (system and data) disk with another, perhaps larger disk for the following reasons:
Prerequisites:
The system disk can be replaced by:
Note: replacing the system disk constitutes a hardware change and premium package trial licensing (cannot change hardware) will fail. Full licenses can be refreshed by "System->Licensing->Manage Licenses", click "Register", "Install" for each licensed product.
SecureOffice can be upgraded using the Replace System Disk instructions, using the old system disk (rather than a new disk) as the target.
Note: Due to potential configuration file changes between versions, some application configuration may need to be manually updated if the application fails. Consult configuration file changes in release notes for new versions.
Network storage refers to:
Samba / cifs file sharing is the easiest way to share files with Windows PC's since it is built in to Windows. Other files sharing protocols (NFS, SSHFS) require Windows configuration or additional packages which is outside the scope of this document.
An overview of Samba is available on the Arch Wiki.
OpenWrt provides a Samba overview and Samba configuration overview.
Install Samba server: Enter "opkg install luci-app-samba4"
After reviewing the Samba configuration overview for options, Edit file "/etc/config/samba4". An example share for SecureOffice "/tmp" and "/home/data" directories is shown below:
config samba
option name 'OpenWrt'
option description 'OpenWrt'
option homes '1'
option workgroup '<Windows Workgroup>'
config sambashare
option name 'tmp'
option path '/tmp'
option read_only 'no'
option guest_ok 'yes'
option dir_mask '0777'
option create_mask '0777'
config sambashare
option read_only 'no'
option guest_ok 'yes'
option create_mask '0777'
option dir_mask '0777'
option name 'Data'
option path '/home/data'
Figure 7: Example Samba Configuration
Enter "/etc/init.d/samba4 restart" to apply updated configuration. At this point, configured Samba shares should be browsable in the Network Neighborhood of client PC's on the SecureOffice LAN.
If SecureOffice is configured for LAN topology (DHCP client of main router), firewall rules must be added to access Samba using the WAN interface.
Edit file "/etc/config/firewall" and add the following rules to allow Samba access via WAN:
config rule
option name 'Allow-Samba/NS/DS'
option src 'wan'
option proto 'udp'
option dest_port '137-138'
option target 'ACCEPT'
config rule
option name 'Allow-Samba/SS'
option src 'wan'
option proto 'tcp'
option dest_port '139'
option target 'ACCEPT'
config rule
option name 'Allow-Samba/SMB'
option src 'wan'
option proto 'tcp'
option dest_port '445'
option target 'ACCEPT'
Figure 8: Samba Firewall Configuration
Enter "/etc/init.d/firewall restart" to apply the configuration changes.
At this point, configured Samba shares should be browsable in the Network Neighborhood of client PC's on the main router and SecureOffice LAN's.
Assuming Windows sharing is enabled, to Samba share a Windows directory (Windows explorer), right click the directory, select "Give Access to", "specific people" and select valid users. To disable sharing a directory, right click it, select "Give access to" -> "Remove Access".
For SecureOffice / OpenWrt, Install Samba client packages: Enter "opkg install cifsmount samba4-client"
For other Linux distributions: Search internet to determine required packages / HowTo's.
All mounts, including Samba shares require a mount point (directory) for the mount. It is suggested that the last mount point subdirectory name be identical to the Server share directory name.
For example, if all mounted Samba shares are to be under directory "/mnt/cifs/" and the server share directory is "/something/media", name the mount point "/mnt/cifs/media" (<mount point>).
Create <mount point>: Enter "mkdir -p <mount point>". Example: "mkdir -p /mnt/cifs/media".
The format of the mount command is:
"mount.cifs //<Samba server name or IP address>/<Samba server share name> <mount point> -o username=<user name on server>,password=<password on server>,vers=2.1,sec=ntlmv2"
If desired, the mount command can be placed in a hotplug script (Figure 10) for automatic mount at boot.
Enter "ls <mount point>" to confirm the remote share is mounted.
To obtain a list of Samba shares for a server, enter:
"smbclient -L <server name or IP address> -U <user ID>". Enter password when prompted.
Samba client support is a standard Windows feature. All Samba shares should be visible in Network Neighborhood. If not, enter "\\<Server name or IP address> in the Windows explorer address bar. When prompted, enter the server user ID and password.
The user ID needs to be of the form "<Server name>\<user ID on server>.
To mount the share as a local drive on Windows, right click a directory to share, select "Map Network Drive" and select a drive letter when prompted. Select "Reconnect a sign-in" to permanently mount the network share. To unmount a network share, using Windows explorer, "This PC", right click on the network share and select "Disconnect".
Rather than placing mount command credentials in the command in "/etc/rc.local", "/etc/fstab" or hotplug script where they are visible to all users (security concern), the mount command can use a credentials file with restricted access permissions. A credentials file (one per Samba share) contains user ID, password and, optionally domain for a particular server. The mount command line parameters "-o username=<user name on server>,password=<password on server>" are replaced by "- o credentials=<full path to credentials file>".
username=<user ID on server>
password=<password on server>
domain=<Workgroup or server name>
Figure 9: Example Samba Credentials File
It is recommended that credentials files (one per server) be placed in directory "/etc/samba/" and be hidden files named ".<server_name>" (the leading "." marks the file hidden). The files should be owned by root with "600" (read/write) owner only permissions. For example, if the server is called "media_server", the credentials file is "/etc/samba/.media_server" and permissions are set by "chmod 600 /etc/samba/.media_server".
The mount command becomes:
"mount.cifs //<Samba server name or IP address>/<Samba server share name> <mount point> -o credentials=<full path to credentials file>,vers=2.1,sec=ntlmv2"
An overview of NFS is available on the Arch Wiki. The OpenWrt documentation for NFS is contradictory and obsolete because portmap has been replaced by rpcbind.
NFS server serves directories / files from the SecureOffice filesystem for clients on the SecureOffice LAN. Do not use this for clients on the WAN / internet. It is insecure, use SSHFS to securely serve files over the internet.
OpenWrt NFS server documentation. Ignore all references to portmap (replaced by rpcbind) and firewall.
Install NFS server: Enter "opkg install nfs-kernel-server kmod-fs-nfs kmod-fs-nfs-v3 kmod-fs-nfs-v4". Installation enables and starts all required services.
Alter file "/etc/exports " to configure directories to share. Consult /etc/exports documentation for further information. It is sufficient to add one line (format below) for each directory to share.
Export format (/etc/exports): "<directory to share> <SecureOffice LAN address>/24(rw,all_squash,insecure,sync)"
Example: "/home/backup 192.168.10.1/24(rw,all_squash,insecure,sync)" will share directory "/home/backup" to clients on the SecureOffice LAN.
Add one entry per line to "/etc/exports" for each directory to share.
After any change to "/etc/exports", enter "service nfsd reload" to apply current configuration values.
NFS client is used to mount remote directories from NFS servers on the SecureOffice LAN.
OpenWrt NFS client documentation. Ignore all references to portmap (replaced by rpcbind).
Install NFS client: "opkg install nfs-utils kmod-fs-nfs kmod-fs-nfs-v3 kmod-fs-nfs-v4".
Further NFS mount options are documented in nfs(5) and mount(8) Linux manual pages.
For each remote directory to mount (manual mount):
To mount at shares at boot (hotplug mount), create file "/etc/hotplug.d/iface/99-share-mount" with contents as below:
#!/bin/sh
. /lib/functions.sh
[ "$DEVICE" == "lo" ] && exit 0
case "$ACTION" in
ifup)
if [ "$DEVICE" == "br-lan" ]; then
# Allow network to stabalize
sleep 5
<Same command as used for manual mount 1>
<Other manual mount commands, cifs, nfs, sshfs>
fi
;;
ifdown)
if [ "$DEVICE" == "br-lan" ]; then
umount <mount point 1>
umount <Other mount points>
fi
;;
esac
Figure 10: Hotplug Script For Remote Directories
Note: This hotplug script is generic. It can be extended by adding manual mount and unmount commands for all network shares such as Samba (cifs), NFS and SSHFS. An alternative is to place the manual mount commands in file "/etc/rc.local".
Both Samba and NFS do not offer strong authentication or security though encryption and are thus only suited for use in a closed intranet (LAN). If you need to remotely access files over the internet (WAN) it is better to use an encrypted solution. The two common ways to do that are to use SSHFS or to use Samba or NFS over VPN.
SSHFS can be used to securely mount directories from servers on the local LAN or WAN (internet). Configuration for SSHFS can also be used for SSH access using the same ports and credentials.
An overview of SSHFS is available on the Arch Wiki.
Enter "opkg install openssh-sftp-server".
After default installation, sshfs connections can be established on default SSH port 22 from clients on SecureOffice LAN with a valid user ID and password.
To accept secure connections from the WAN / internet, a new dropbear instance with password authentication disabled needs to be started. For secure access using private / public key pairs, client public keys need to be added to the server's "/etc/dropbear/authorized_keys" file. For SSHFS access via WAN / internet, a firewall rule needs to be added for the dropbear instance port.
To create a dropbear instance running on an alternate port (example: 2223), listening for connections all interfaces, add the following at end of file "/etc/config/dropbear":
config dropbear
option Port '<port to listen to>'
option PasswordAuth 'off'
option RootPasswordAuth 'off'
# Uncomment to listen to WAN interface only.
#option Interface <WAN ethernet device>
Figure 11: Secure Dropbear Instance
If WAN access only is desired (LAN clients can still connect insecurely with user ID and password), uncomment the last line above, replacing <WAN ethernet device> with the WAN ethernet adapter (example "eth1").
To allow remote SSH connections from the WAN / internet, a firewall rule needs to be added to "/etc/config/firewall", as below:
config rule
option enabled '1'
option target 'ACCEPT'
option src 'wan'
option proto 'tcp udp'
option dest_port '<port of dropbear instance>'
option name 'support-secure-ssh'
Figure 12: Secure Dropbear Firewall Rule
Before clients can connect using key authentication, client public / private keys must be created and the client's public key added to server file "/etc/dropbear/authorized_keys". Instructions are in subsequent SSHFS Client Key Authentication section.
After creating the client keys, paste the contents of (client file) "/root/.ssh/public_rsa.pub" at end of (server file) "/etc/dropbear/authorized_keys".
After entering the above configuration, restart dropbear and firewall services. Enter "/etc/init.d/dropbear restart; /etc/init.d/firewall restart". The SSHFS server is now ready to accept clients using key authentication.
After default installation, clients on the SecureOffice LAN can connect via standard SSH port 22 with a valid user ID and password:
Enter "echo '<password>' | sshfs -o password_stdin <user ID>@<SSH server name or IP address>:<SSH server directory> <mount point> "
To create the client public / private keypair, enter "cd /root/.ssh; dropbearkey -t rsa -f private_rsa.key -s 4096". Command result will be as below:
Figure 13: DropbearKey Creation Result
The above command creates the private key file "/root/.ssh/private_rsa.key" and displays the public key. To create the public key file (required for SSH server), copy all lines starting with "ssh-rsa" up to but not including the "Fingerprint" line and paste into file "/root/.ssh/public_rsa.pub". Before clients can connect using keys, the contents of "/root/.ssh/public_rsa.pub" must be added to the server's authorized_keys file as explained above.
SSHFS clients can now connect to the server with the following command:
"sshfs -o reconnect,compression=yes,ssh_command="ssh -p <server port> -i /root/.ssh/private_rsa.key" root@<SSH server name or IP address>:<SSH server directory> <mount point>"
The above command can also be added to the generic mount hotplug script (Figure 10) to automatically mount the share at boot.
Despite warnings regarding information privacy and security of cloud storage, it may be useful for storing non-critical data for sharing with other users granted cloud access. Critical data can be protected by optionally encrypting the cloud storage filesystem.
RClone requires access to the SecureOffice custom repository.
RClone manages files on cloud storage. It is a feature rich alternative to cloud vendors' web storage interfaces. RClone supports over 40 cloud storage products including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.
RClone has powerful cloud equivalents to the Unix commands rsync, cp, mv, mount, ls, ncdu, tree, rm, and cat. RClone's familiar syntax includes shell pipeline support, and --dry-run protection. It can be controlled by command line, in scripts, via its API and / or by SecureOffice GUI.
RClone can mount any local, cloud or virtual filesystem as a disk on Windows, macOS, Linux and FreeBSD, and also serves files using SFTP, HTTP, WebDAV, FTP and DLNA.
Google Drive and Microsoft OneDrive are used as example cloud storage providers. Other supported providers can be used. Configuration instructions for supported providers are available here.
SecureOffice RClone allows mounting one or more remote cloud storage directories locally. The RClone web GUI is also accessible using the SecureOffice (Luci) menu system.
RClone configuration requires access tokens for cloud storage providers. It is easiest to generate RClone configuration using a Windows PC and then copy the configuration values to SecureOffice.
For all cloud storage providers, it is necessary to sign up for an account with chosen cloud storage providers.
A Google account is required to use Google Drive. If not already done, get a Google account and sign in.
A Microsoft account is required to use OneDrive. If not already done, get a Microsoft account and sign in.
For subsequent instructions, the name of the remote drive will be "remote_google", Choose your own name, which will be referred to as "<remote_name>".
Download and extract RClone to your PC.
Using a Windows command prompt, change to the directory that RClone was extracted to:
The OpenWrt RClone configuration page should be visible at "Admin->Services->RClone Config", as shown below:
Figure 14:RClone Configuration Page
You should see directory contents for all configured and enabled cloud providers by entering "ls -la <mount_point>" for each provider.
The OpenWrt RClone GUI page should be visible at "Admin->Services->RClone GUI", or at "https://rclone.<your_domain>" (without OpenWrt menu) as shown below:
The RClone file explorer page can be accessed by clicking on "Explorer" as shown below:
Figure 16:RClone Explorer Page
Cloud storage files and be viewed, uploaded and downloaded either by using the RClone GUI or using the RClone provider mount directory on the SecureOffice file system.
Any problems / issues can be diagnosed by enabling "Debug" (Figure3) and entering "tail -f /var/log/rclone.log" at a command prompt.
By default, access to RClone is private, restricted to clients on your local LAN or using secure remote access methods. RClone is available at "https://<Lan_Address>:5572" or "https://rclone.<Your_Domain>"
Cloud services already have authentication methods (service dependent) to allow public authenticated access to remote services for uploads and downloads. Using these methods for file sharing with others is recommended, since transfers do not use SecureOffice bandwidth.
If, for some reason it is desired to provide public access to cloud services using SecureOffice RClone, this can be done by altering the Nginx subdomain configuration in file "/etc/nginx/vhosts/rclone.conf". Be aware that any public access will use SecureOffice bandwidth.
|
|
Technologies Used:
