How to Setup Sandstorm Personal Cloud Server in Linux

Sandstorm is an Open Source self-hostable web productivity suite implemented as a security-hardened web app package manager. It is a radically easier way to run personal instances of your web application at one place. It allows you to have your own personal server to install multiple application on it through an app store interface as easily as you would install apps on a phone. Sandstorm keeps a list so you can find everything you create and its unified access control system covers data from every app, and everything is private to you by default. Find any app you want on the App Market and start using it with a few clicks. Every app comes with automatic updates. More than all it protects you, each document, chat room, mail box, notebook, blog, or anything else you create is a “grain” in Sandstorm. It containerizes each one in its own secure sandbox from which it cannot talk to the world without express permission. All your grains are private until you share them. The result is that 95% of security vulnerabilities are automatically mitigated.


To make Sandstorm run on CentOS 7, we will be required to have systems with following competencies.

  • Linux Kernel 3.10+
  • User namespaces disabled

According to its basic software requirements, you can easily install it on RHEL-7 or CentOS 7 as both have the kernel versions greater than 3.10. Like the same way if you have to install it on Arch Linux, you can do so because of its kernels compiles with ‘CONFIG_USER_NS=n’.

Other than software requirements, you can use 1GB+ of RAM but 2GB+ is recommended. Here in this article we will be using a CentOS 7.2 VM with 2GB RAM , 2 CPUs and 20 GB disk space.

How to update your system

Once you have access to the VM, create a non-root user with sudo privileges to perform all system level tasks. In CentOS 7 you create a new user with sudo rights using below commands.

$ ssh root@server_ip

# adduser new_user

Set your password for the new user, and then Use the ‘usermod’ command to add the user to the ‘wheel’ group.

# usermod -aG wheel new_user

Now using the ‘su’ command, switch to the new user account and run the command with sudo to update your system.

# su – new_user

# sudo yum update -y

After system update with latest updates and security patches, move to the next step to download and install the Sandstorm on CentOS 7.

How to install Sandstorm

This comes with its own installer that provides its automatic installation setup. To install on your own Linux machine, you just need to run below ‘curl’ command.

$ curl | bash

Then You can have two options, and you need to choose the appropriate one, either you like to go for 1 or 2 .

1. A typical install, to use Sandstorm (press enter to accept this default)
2. A development server, for working on Sandstorm itself or localhost-based app development

Let’s choose the option ‘1’ and press Enter key to go for its default typical installation.

This complete installation setup with go through the following process.:

* Install Sandstorm in /opt/sandstorm
* Automatically keep Sandstorm up-to-date
* Configure auto-renewing HTTPS if you use a subdomain of
* Create a service user (sandstorm) that owns Sandstorm’s files
* Configure Sandstorm to start on system boot (with systemd)
* Listen for inbound email on port 25.

To set up Sandstorm, we have to provide the sudo privileges, type ‘yes’ to allow sudo access to continue after its password.

Note that Sandstorm’s storage will only be accessible to the group ‘sandstorm’. As a Sandstorm user, you are invited to use a free Internet hostname as a subdomain of, a service operated by the Sandstorm development team. You can choose your desired Sandcats subdomain (alphanumeric, max 20 characters). Type the word ‘none; to skip this step, or ‘help’ for help.

What * subdomain would you like? [] linox

Next you need to mention your email on file so it help you recover your domain if you lose access.

Enter your email address: []

This register your domain, and you will be provided with a URL that users will enter in browser.


Next Sandstorm requires you to set up a wildcard DNS entry pointing at the server. This allows Sandstorm to allocate new hosts on-the-fly for sandboxing purposes. Please enter a DNS hostname containing a ‘*’ which maps to your server. For example, if you have mapped * to your server, you could enter “*”. You can also specify that hosts should have a special prefix, like “ss-*”. Note that if your server’s main page is served over SSL, the wildcard address must support SSL as well, which implies that you must have a wildcard certificate. For local-machine servers, we have mapped * to for your convenience, so you can use “*” here. If you are serving off a non-standard port, you must include it here as well.

Wildcard host: [*] *

Server installation is complete now, Visit the link mentioned in the end of the setup to start using it.


As mentioned the URL expires in 15 minutes. You can generate a new setup URL by running below command.

$ sudo sandstorm admin-token

session token

How to configure Sandstorm Web setup

Once you open the URL, you will see a welcome page to begin the admin settings and to configure your login system.

welcome sandstorm

1) Identity providers

To use Sandstorm, you need to create a user account. Every user account on Sandstorm is backed by an identity provider. You’ll use this identity provider to authenticate as the first administrator of this Sandstorm install.

Configure the identity provider or providers you wish to enable by a click on the ‘configure’ button.

identity provider

Let’s see if you want to enable Github on your Sandstorm, click on the configure button, a new window will be opened where you need to provide github login configurations. Once you got your Client ID and Client secret from your github account, click on the ‘Enable’ button to proceed.

github configuration

2) Organization settings

Sandstorm allows you to define an organization. You can automatically apply some settings to all members of your organization. Users within the organization will automatically be able to log in, install apps, and create grains.

Organization settings

3) Email delivery

Sandstorm needs a way to send email. You can skip this step (unless you’re using email login), but email-related features will be unavailable until you configure email in the future. Mention your SMTP host with Port and credentials.

email delivery

4) Pre-installed apps

Here Sandstorm installs the following Productivity Suite apps that are useful for most users shown below. You will be able to configure all pre-installed apps in the Admin Settings panel after setup.

pre install app

5) Create Admin account

Log with your google or Github account that you created in previous step to create your admin account.

admin account

That’s it, now add more users, edit other settings or start user your awesome personal cloud platform.

start using


In the end of this article, you are now able to install, configure and use your own personal cloud platform on CentOS 7. It aims to tackle the authentication and security problems that software-As-A-Service poses for many companies through the use of fine-grained containerization. Using Sandstorm now it’s much easier than setting up yourself because you just to point and click, your click install and you have the app running. It takes like 5 seconds to spin up a container that help’s you build your own applications within seconds.

Compatibility with Older Systems RHEL 7

If an ACL has been set on any file on a given file system, that file system has the ext_attr attribute. This attribute can be seen using the following command:
# tune2fs -l filesystem-device
A file system that has acquired the ext_attr attribute can be mounted with older kernels, but those kernels do not enforce any ACLs which have been set.
Versions of the e2fsck utility included in version 1.22 and higher of the e2fsprogs package (including the versions in Red Hat Enterprise Linux 2.1 and 4) can check a file system with the ext_attr attribute. Older versions refuse to check it.

Archiving File Systems with Acls RHEL 7

By default, the dump command now preserves ACLs during a backup operation. When archiving a file or file system with tar, use the --acls option to preserve ACLs. Similarly, when using cp to copy files with ACLs, include the --preserve=mode option to ensure that ACLs are copied across too. In addition, the -a option (equivalent to -dR --preserve=all) of cp also preserves ACLs during a backup along with other information such as timestamps, SELinux contexts, and the like. For more information about dump, tar, or cp, refer to their respective man pages.
The star utility is similar to the tar utility in that it can be used to generate archives of files; however, some of its options are different. Refer to Table 4.1, “Command Line Options for star” for a listing of more commonly used options. For all available options, refer to man star. The star package is required to use this utility.

Table 4.1. Command Line Options for star

Option Description
-c Creates an archive file.
-n Do not extract the files; use in conjunction with -x to show what extracting the files does.
-r Replaces files in the archive. The files are written to the end of the archive file, replacing any files with the same path and file name.
-t Displays the contents of the archive file.
-u Updates the archive file. The files are written to the end of the archive if they do not exist in the archive, or if the files are newer than the files of the same name in the archive. This option only works if the archive is a file or an unblocked tape that may backspace.
-x Extracts the files from the archive. If used with -U and a file in the archive is older than the corresponding file on the file system, the file is not extracted.
-help Displays the most important options.
-xhelp Displays the least important options.
-/ Do not strip leading slashes from file names when extracting the files from an archive. By default, they are stripped when files are extracted.
-acl When creating or extracting, archives or restores any ACLs associated with the files and directories.

Setting Default Acls RHEL 7

To set a default ACL, add d: before the rule and specify a directory instead of a file name.

Example 4.3. Setting default ACLs

For example, to set the default ACL for the /share/ directory to read and execute for users not in the user group (an access ACL for an individual file can override it):
# setfacl -m d:o:rx /share

Overview of File System Hierarchy Standard (FHS)

Red Hat Enterprise Linux uses the Filesystem Hierarchy Standard (FHS) file system structure, which defines the names, locations, and permissions for many file types and directories.
The FHS document is the authoritative reference to any FHS-compliant file system, but the standard leaves many areas undefined or extensible. This section is an overview of the standard and a description of the parts of the file system not covered by the standard.
Compliance with the standard means many things, but the two most important are compatibility with other compliant systems and the ability to mount a /usr/ partition as read-only. This second point is important because the directory contains common executables and should not be changed by users. Also, since the /usr/ directory is mounted as read-only, it can be mounted from the CD-ROM or from another machine via a read-only NFS mount.

⁠1.2.1. FHS Organization

The directories and files noted here are a small subset of those specified by the FHS document. Refer to the latest FHS document for the most complete information.
The complete standard is available online at

⁠ The /boot/ Directory

The /boot/ directory contains static files required to boot the system, such as the Linux kernel. These files are essential for the system to boot properly.


Do not remove the /boot/ directory. Doing so renders the system unbootable.

⁠ The /dev/ Directory

The /dev/ directory contains device nodes that either represent devices that are attached to the system or virtual devices that are provided by the kernel. These device nodes are essential for the system to function properly. The udev daemon takes care of creating and removing all these device nodes in /dev/.
Devices in the /dev directory and subdirectories are either character (providing only a serial stream of input/output) or block (accessible randomly). Character devices include mouse, keyboard, modem while block devices include hard disk, floppy drive etc. If you have GNOME or KDE installed in your system, devices such as external drives or cds are automatically detected when connected (e.g via usb) or inserted (e.g via CD or DVD drive) and a popup window displaying the contents is automatically displayed. Files in the /dev directory are essential for the system to function properly.

Table 1.1. Examples of common files in the /dev

File Description
/dev/hda The master device on primary IDE channel.
/dev/hdb The slave device on primary IDE channel.
/dev/tty0 The first virtual console.
/dev/tty1 The second virtual console.
/dev/sda The first device on primary SCSI or SATA channel.
/dev/lp0 The first parallel port.

⁠ The /etc/ Directory

The /etc/ directory is reserved for configuration files that are local to the machine. No binaries are to be placed in /etc/. Any binaries that were once located in /etc/ should be placed into /sbin/ or /bin/.
Examples of directories in /etc are the X11/ and skel/:
   |- X11/
   |- skel/
The /etc/X11/ directory is for X Window System configuration files, such as xorg.conf. The /etc/skel/ directory is for “skeleton” user files, which are used to populate a home directory when a user is first created. Applications also store their configuration files in this directory and may reference them when they are executed.

⁠ The /lib/ Directory

The /lib/ directory should contain only those libraries needed to execute the binaries in /bin/ and /sbin/. These shared library images are particularly important for booting the system and executing commands within the root file system.

⁠ The /media/ Directory

The /media/ directory contains subdirectories used as mount points for removable media such as usb storage media, DVDs, CD-ROMs, and Zip disks.

⁠ The /mnt/ Directory

The /mnt/ directory is reserved for temporarily mounted file systems, such as NFS file system mounts. For all removable media, please use the /media/ directory. Automatically detected removable media will be mounted in the /media directory.


The /mnt directory must not be used by installation programs.

⁠ The /opt/ Directory

The /opt/ directory provides storage for most application software packages.
A package placing files in the /opt/ directory creates a directory bearing the same name as the package. This directory, in turn, holds files that otherwise would be scattered throughout the file system, giving the system administrator an easy way to determine the role of each file within a particular package.
For example, if sample is the name of a particular software package located within the /opt/ directory, then all of its files are placed in directories inside the /opt/sample/ directory, such as /opt/sample/bin/ for binaries and /opt/sample/man/ for manual pages.
Packages that encompass many different sub-packages, data files, extra fonts, clipart etc are also located in the /opt/ directory, giving that large package a way to organize itself. In this way, our sample package may have different tools that each go in their own sub-directories, such as /opt/sample/tool1/ and /opt/sample/tool2/, each of which can have their own bin/, man/, and other similar directories.

⁠ The /proc/ Directory

The /proc/ directory contains special files that either extract information from or send information to the kernel. Examples include system memory, cpu information, hardware configuration etc.
Due to the great variety of data available within /proc/ and the many ways this directory can be used to communicate with the kernel, an entire chapter has been devoted to the subject.

⁠ The /sbin/ Directory

The /sbin/ directory stores executables used by the root user. The executables in /sbin/ are used at boot time, for system administration and to perform system recovery operations. Of this directory, the FHS says:

/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. Programs executed after /usr/ is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin.
At a minimum, the following programs should be in /sbin/:
arp, clock,
halt, init,
fsck.*, grub,
ifconfig, mingetty,
mkfs.*, mkswap,
reboot, route,
shutdown, swapoff,

⁠ The /srv/ Directory

The /srv/ directory contains site-specific data served by your system running Red Hat Enterprise Linux. This directory gives users the location of data files for a particular service, such as FTP, WWW, or CVS. Data that only pertains to a specific user should go in the /home/ directory.

⁠ The /sys/ Directory

The /sys/ directory utilizes the new sysfs virtual file system specific to the 2.6 kernel. With the increased support for hot plug hardware devices in the 2.6 kernel, the /sys/ directory contains information similarly held in /proc/, but displays a hierarchical view of specific device information in regards to hot plug devices.

⁠ The /usr/ Directory

The /usr/ directory is for files that can be shared across multiple machines. The /usr/ directory is often on its own partition and is mounted read-only. At a minimum, the following directories should be subdirectories of /usr/:
   |- bin/
   |- etc/
   |- games/
   |- include/
   |- kerberos/
   |- lib/
   |- libexec/
   |- local/
   |- sbin/
   |- share/
   |- src/
   |- tmp -> ../var/tmp/
Under the /usr/ directory, the bin/ subdirectory contains executables, etc/ contains system-wide configuration files, games is for games, include/ contains C header files, kerberos/ contains binaries and other Kerberos-related files, and lib/ contains object files and libraries that are not designed to be directly utilized by users or shell scripts. The libexec/ directory contains small helper programs called by other programs, sbin/ is for system administration binaries (those that do not belong in the /sbin/ directory), share/ contains files that are not architecture-specific, src/ is for source code.

⁠ The /usr/local/ Directory

The FHS says:

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable among a group of hosts, but not found in /usr.
The /usr/local/ directory is similar in structure to the /usr/ directory. It has the following subdirectories, which are similar in purpose to those in the /usr/ directory:
	|- bin/
	|- etc/
	|- games/
	|- include/
	|- lib/
	|- libexec/
	|- sbin/
	|- share/
	|- src/
In Red Hat Enterprise Linux, the intended use for the /usr/local/ directory is slightly different from that specified by the FHS. The FHS says that /usr/local/ should be where software that is to remain safe from system software upgrades is stored. Since software upgrades can be performed safely with RPM Package Manager (RPM), it is not necessary to protect files by putting them in /usr/local/. Instead, the /usr/local/directory is used for software that is local to the machine.
For instance, if the /usr/ directory is mounted as a read-only NFS share from a remote host, it is still possible to install a package or program under the /usr/local/ directory.

⁠ The /var/ Directory

Since the FHS requires Linux to mount /usr/ as read-only, any programs that write log files or need spool/ or lock/ directories should write them to the /var/ directory. The FHS states /var/ is for:

…variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.
Below are some of the directories found within the /var/ directory:
   |- account/
   |- arpwatch/
   |- cache/
   |- crash/
   |- db/
   |- empty/
   |- ftp/
   |- gdm/
   |- kerberos/
   |- lib/
   |- local/
   |- lock/
   |- log/
   |- mail -> spool/mail/
   |- mailman/
   |- named/
   |- nis/
   |- opt/
   |- preserve/
   |- run/
   +- spool/
       |- at/
       |- clientmqueue/
       |- cron/
       |- cups/
       |- exim/
       |- lpd/
       |- mail/
       |- mailman/
       |- mqueue/
       |- news/
       |- postfix/
       |- repackage/
       |- rwho/
       |- samba/
       |- squid/
       |- squirrelmail/
       |- up2date/
       |- uucp
       |- uucppublic/
       |- vbox/
|- tmp/
|- tux/
|- www/
|- yp/
System log files, such as messages and lastlog, go in the /var/log/ directory. The /var/lib/rpm/ directory contains RPM system databases. Lock files go in the /var/lock/ directory, usually in directories for the program using the file. The /var/spool/ directory has subdirectories for programs in which data files are stored.

Configuring the date and time RHEL 7 (1)

Modern operating systems distinguish between the following two types of clocks:
  • A real-time clock (RTC), commonly referred to as a hardware clock, (typically an integrated circuit on the system board) that is completely independent of the current state of the operating system and runs even when the computer is shut down.
  • A system clock, also known as a software clock, that is maintained by the kernel and its initial value is based on the real-time clock. Once the system is booted and the system clock is initialized, the system clock is completely independent of the real-time clock.
The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST). The real-time clock can use either UTC or local time. UTC is recommended.
Red Hat Enterprise Linux 7 offers three command line tools that can be used to configure and display information about the system date and time: the timedatectl utility, which is new in Red Hat Enterprise Linux 7 and is part of systemd; the traditional date command; and the hwclock utility for accessing the hardware clock.


The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock. You can use this tool to change the current date and time, set the time zone, or enable automatic synchronization of the system clock with a remote server.

2.1.1. Displaying the Current Date and Time

To display the current date and time along with detailed information about the configuration of the system and hardware clock, run the timedatectl command with no additional command line options:
This displays the local and universal time, the currently used time zone, the status of the Network Time Protocol (NTP) configuration, and additional information related to DST.

Example 2.1. Displaying the Current Date and Time

The following is an example output of the timedatectl command on a system that does not use NTPto synchronize the system clock with a remote server:
~]$ timedatectl
      Local time: Mon 2013-09-16 19:30:24 CEST
  Universal time: Mon 2013-09-16 17:30:24 UTC
        Timezone: Europe/Prague (CEST, +0200)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET


Changes to the status of chrony or ntpd will not be immediately noticed by timedatectl. If changes to the configuration or status of these tools is made, enter the following command:

~]# systemctl restart

2.1.2. Changing the Current Time

To change the current time, type the following at a shell prompt as root:
timedatectl set-time HH:MM:SS
Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form.
This command updates both the system time and the hardware clock. The result it is similar to using both the date --set and hwclock --systohc commands.
The command will fail if an NTP service is enabled.

Example 2.2. Changing the Current Time

To change the current time to 11:26 p.m., run the following command as root:
~]# timedatectl set-time 23:26:00
By default, the system is configured to use UTC. To configure your system to maintain the clock in the local time, run the timedatectl command with the set-local-rtc option as root:
timedatectl set-local-rtc boolean
To configure your system to maintain the clock in the local time, replace boolean with yes (or, alternatively, y, true, t, or 1). To configure the system to use UTC, replace boolean with no (or, alternatively, n, false, f, or 0). The default option is no.

2.1.3. Changing the Current Date

To change the current date, type the following at a shell prompt as root:
timedatectl set-time YYYY-MM-DD
Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month.
Note that changing the date without specifying the current time results in setting the time to 00:00:00.

Example 2.3. Changing the Current Date

To change the current date to 2 June 2013 and keep the current time (11:26 p.m.), run the following command as root:
~]# timedatectl set-time '2013-06-02 23:26:00'

2.1.4. Changing the Time Zone

To list all available time zones, type the following at a shell prompt:
timedatectl list-timezones
To change the currently used time zone, type as root:
timedatectl set-timezone time_zone
Replace time_zone with any of the values listed by the timedatectl list-timezones command.

Example 2.4. Changing the Time Zone

To identify which time zone is closest to your present location, use the timedatectl command with the list-timezones command line option. For example, to list all available time zones in Europe, type:
~]# timedatectl list-timezones | grep Europe
To change the time zone to Europe/Prague, type as root:
~]# timedatectl set-timezone Europe/Prague

2.1.5. Synchronizing the System Clock with a Remote Server

As opposed to the manual adjustments described in the previous sections, the timedatectl command also allows you to enable automatic synchronization of your system clock with a group of remote servers using the NTP protocol. Enabling NTP enables the chronyd or ntpd service, depending on which of them is installed.
The NTP service can be enabled and disabled using a command as follows:
timedatectl set-ntp boolean
To enable your system to synchronize the system clock with a remote NTP server, replace boolean with yes (the default option). To disable this feature, replace boolean with no.

Example 2.5. Synchronizing the System Clock with a Remote Server

To enable automatic synchronization of the system clock with a remote server, type:
~]# timedatectl set-ntp yes
The command will fail if an NTP service is not installed.

Changing the keyboard layout RHEL 7

The keyboard layout settings enable the user to control the layout used on the text console and graphical user interfaces.

1.2.1. Displaying the Current Settings

As mentioned before, you can check your current keyboard layout configuration with the following command:
localectl status
In the following output, you can see the keyboard layout configured for the virtual console and for the X11 window system.
~]$ localectl status
   System Locale: LANG=en_US.utf8
       VC Keymap: us
      X11 Layout: us

1.2.2. Listing Available Keymaps

To list all available keyboard layouts that can be configured on your system, type:
localectl list-keymaps

Example 1.5. Searching for a Particular Keymap

You can use grep to search the output of the previous command for a specific keymap name. There are often multiple keymaps compatible with your currently set locale. For example, to find available Czech keyboard layouts, type:
~]$ localectl list-keymaps | grep cz

1.2.3. Setting the Keymap

To set the default keyboard layout for your system, use the following command as root:
localectl set-keymap map
Replace map with the name of the keymap taken from the output of the localectl list-keymaps command. Unless the --no-convert option is passed, the selected setting is also applied to the default keyboard mapping of the X11 window system, after converting it to the closest matching X11 keyboard mapping. This also applies in reverse, you can specify both keymaps with the following command as root:
localectl set-x11-keymap map
If you want your X11 layout to differ from the console layout, use the --no-convert option.
localectl --no-convert set-x11-keymap map
With this option, the X11 keymap is specified without changing the previous console layout setting.

Example 1.6. Setting the X11 Keymap Separately

Imagine you want to use German keyboard layout in the graphical interface, but for console operations you want to retain the US keymap. To do so, type as root:
~]# localectl --no-convert set-x11-keymap de
Then you can verify if your setting was successful by checking the current status:
~]$ localectl status
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: us
      X11 Layout: de
Apart from keyboard layout (map), three other options can be specified:
localectl set-x11-keymap map model variant options
Replace model with the keyboard model name, variant and options with keyboard variant and option components, which can be used to enhance the keyboard behavior. These options are not set by default.