pSeven Enterprise deployment¶

This guide covers the initial deployment and setup of pSeven Enterprise.

Related guides

Version upgrade: installing updates.
Administration: maintenance, advanced configuration, backups.

pSeven Enterprise deployment requires a Kubernetes cluster and depends on several infrastructure services, some of them optional.

flowchart TB
  classDef dashed stroke:#777,stroke-dasharray: 5 5;

  subgraph da [DATADVANCE]
    dockerreg-da[(Docker<br>Registry)]:::dashed
  end

  subgraph hostinfra2 [Infrastructure services]
    postgres[(PostgreSQL<br>database)]
    nfs[(Dedicated<br>NFSv3<br>file storage)]
    smtp[SMTP<br>server]:::dashed
    ldap[AD/LDAP<br>provider]:::dashed
    dockerreg[(Local<br>Docker<br>Registry)]:::dashed
  end

  subgraph kubernetes [Kubernetes cluster]
      pseven[[<b><br>pSeven Enterprise<br><br></b>]]
  end

  subgraph extnodes [Windows nodes]
      extnode[[pSeven Enterprise<br>Windows extension]]:::dashed
  end

  subgraph hostinfra1 [Infrastructure services]
    rproxy[Reverse proxy<br>Load balancer]:::dashed
  end

  rproxy -.-> pseven

  pseven -.- extnode

  pseven --> postgres
  pseven --> nfs
  pseven -.-> smtp
  pseven -.-> ldap
  pseven -.-> dockerreg

  pseven -.-> dockerreg-da

Hardware resources summary¶

TrialProduction

Resource	Qty	Requirements
Kubernetes control plane node	1	4 CPU, 8 GB RAM, 80 GB storage (1500 IOPS), 1 Gb⁠/⁠s network
Kubernetes worker node	5	8 CPU, 16 GB RAM, 80 GB storage, 1 Gb⁠/⁠s network
PostgreSQL server	1	2 CPU, 4 GB RAM, 50 GB storage, 1 Gb⁠/⁠s network
NFS server	1	2 CPU, 4 GB RAM, 500 GB storage, 1 Gb⁠/⁠s network
(optional) Docker Registry	1	4 CPU, 8 GB RAM, 200 GB storage, 1 Gb⁠/⁠s network
(optional) Reverse proxy	1	2 CPU, 4 GB RAM, 10 GB storage, 1 Gb⁠/⁠s network
(optional) Windows node¹	1	4 CPU, 16 GB RAM, 500 GB storage, 1 Gb⁠/⁠s network

Windows nodes are required only if users need to run tasks on Windows. Their hardware requirements are determined by the software, which they will run.

Resource	Qty	Requirements
Kubernetes control plane node	3	4 CPU, 8 GB RAM, 80 GB storage (7000/4000 IOPS read/write), 1 Gb⁠/⁠s network
Kubernetes worker node¹	5+	8 CPU, 16 GB RAM, 80 GB storage, 1 Gb⁠/⁠s network
PostgreSQL server	1	4 CPU, 8 GB RAM, 100 GB storage, 1 Gb⁠/⁠s network
NFS server	1	4 CPU, 8 GB RAM, 1+ TB storage, 10 Gb⁠/⁠s network
Docker Registry	1	4 CPU, 8 GB RAM, 200 GB storage (2400/800 IOPS read/write), 1 Gb⁠/⁠s network
Reverse proxy	1	2 CPU, 4 GB RAM, 10 GB storage, 1 Gb⁠/⁠s network
(optional) Windows node²	1+	8 CPU, 32 GB RAM, 1 TB storage, 1 Gb⁠/⁠s network

The required number of Kubernetes worker nodes depends strongly on the number of users and expected load. Discuss this requirement with your corresponding DATADVANCE or VAR account manager.
Windows nodes are required only if users need to run tasks on Windows. Their hardware requirements are determined by the software, which they will run.

Requirements¶

Helm 3.10.0 or newer.

Kubernetes 1.15.5-1.25.2.
Using managed Kubernetes is recommended. If this is not an option, you can set up your own cluster.

Minimum cluster requirements

TrialProduction

1 dedicated control plane node: 4 CPU, 8 GB RAM, 80 GB storage (1500 IOPS), 1 Gb/s network.
5 worker nodes: 8 CPU, 16 GB RAM, 80 GB storage, 1 Gb/s network.
Clock synchronization (NTP) on all nodes required.

Warning

This deployment becomes unserviceable, if the control plane node is down.

3 dedicated control plane nodes: 4 CPU, 8 GB RAM, 80 GB storage (7000/4000 IOPS read/write), 1 Gb/s network.
5 worker nodes: 8 CPU, 16 GB RAM, 80 GB storage, 1 Gb/s network.
Clock synchronization (NTP) on all nodes required.

PostgreSQL 12 or newer.

Database requirements

TrialProduction

Database server: 2 CPU, 4 GB RAM, 50 GB storage, 1 Gb/s network.
Connection pooling - for example, PgBouncer.
Clock synchronization (NTP) required.

Database server: 4 CPU, 8 GB RAM, 100 GB storage, 1 Gb/s network.
Connection pooling - for example, PgBouncer.
Clock synchronization (NTP) required.

NFS storage.

NFS requirements

TrialProduction

NFS server: 2 CPU, 4 GB RAM, 500 GB storage, 1 Gb/s network (10 Gb/s recommended).
Storage features: ACL, file locks, NFSv3 (recommended) or NFSv4; disk quota support recommended.
Clock synchronization (NTP) required.

Warning

Overall performance of pSeven Enterprise is strongly dependent on the NFS server network connection and storage performance. Slow connections and storages bring poor user experience.
Many user operations will be slow, if the same server provides storage to other applications (non-dedicated storage).
You will not be able to set user storage quotas, if the server does not support disk quotas.
NFSv4 support is experimental.

Dedicated NFS server: 4 CPU, 8 GB RAM, 1+ TB storage (10000/5000 IOPS read/write), 10 Gb/s network.
Storage features: ACL, file locks, disk quota, NFSv3 (recommended) or NFSv4.
NFSv4 should be disabled when possible. NFSv4 support is experimental.
Must serve a single pSeven Enterprise deployment exclusively (dedicated storage).
Clock synchronization (NTP) required.
Overall performance of pSeven Enterprise is strongly dependent on the NFS server network connection and storage performance. Faster networks and storages provide better user experience.

(optional) Docker Registry 2.7.1 or newer.

Registry requirements

TrialProduction

You can use the DATADVANCE Registry at registry.pseven.io.

Warning

User tasks will show delays on launch, and will often stop by timeout because loading their required images over the Internet is too slow.

Local Registry: 4 CPU, 8 GB RAM, 200 GB storage (2400/800 IOPS read/write), 1 Gb/s network.
Images copied from registry.pseven.io.
Clock synchronization (NTP) required.

(optional) SMTP server.

Deployment options

TrialProduction

You can deploy without an SMTP server.

Warning

pSeven Enterprise will be unable to send password reset links and mail notifications to users.

The server must support basic password authentication.
Clock synchronization (NTP) required.

(optional) Reverse proxy (NGINX, Traefik).

Reverse proxy requirements

TrialProduction

You can deploy without a reverse proxy.

Warning

User traffic will go unencrypted over HTTP.
Higher denial of service probability: connections to pSeven Enterprise may fail, if any of the Kubernetes nodes is down.

2 CPU, 4 GB RAM, 10 GB storage, 1 Gb/s network; depends on the reverse proxy you run.
WebSocket support.
SSL/TLS termination set up.
Load balancing to Kubernetes worker nodes, with health check enabled.
Clock synchronization (NTP) required.

(optional) Windows extension nodes.

Deployment options

TrialProduction

You can deploy without extension nodes.

Warning

Users will be unable to run Windows software in their tasks.

A physical Windows 10 workstation or a standalone server. The server must not be an Active Directory domain controller.
Windows 10 Pro 64-bit, version 1909 or newer; Windows Server 2019 or newer.
Hardware requirements are determined by the software, which the nodes will run. Commonly: 8 CPU, 32 GB RAM, 1 TB storage.
Clock synchronization (NTP) required.

It is also possible to deploy without extension nodes and add them later on demand.

Installation package¶

To get the pSeven Enterprise package, send a request to your corresponding DATADVANCE or VAR account manager. You shall receive the following:

The pSeven Enterprise Helm chart, which is a small file named pseven⁠-⁠{YYYY.MM.DD}.tgz, where {YYYY.MM.DD} is the release date. For example: pseven⁠-⁠2023.09.25.tgz.
Access credentials for the DATADVANCE Registry, which provides the pSeven Enterprise Docker images to deploy.

The installation package does not include a license key, because each pSeven Enterprise license is bound to a specific Installation ID, which you can only get after the installation.

Deployment overview¶

This section lists the general stages of a pSeven Enterprise deployment. Details and instructions are provided in the sections that follow.

Prepare the Kubernetes cluster - see Kubernetes cluster.
- If you are building a new cluster for pSeven Enterprise, check Configuration requirements first.
- Set up clock synchronization (NTP) on all cluster nodes.
- Create the pSeven Enterprise installation namespace (pseven⁠-⁠ns).
Install a recent Helm version - see Helm.
Set up the PostgreSQL database server - see PostgreSQL server.
- Enable connection pooling (PgBouncer).
- Create the pSeven Enterprise database and user. The user must have full access to that database, including permissions to add and remove tables and schemas.
- Set up password authentication for the pSeven Enterprise user.
Set up the NFS file storage server - see NFS server.
- Disable NFSv4.
- Enable storage quotas.
- Create and export 3 data storage directories: user data, app data, and shared data. The directories must be exported with the no_root_squash flag, and the user with UID 11111 must be set as the owner with full access.
If you plan to set up secure LDAP integration (use LDAPS), add the LDAP server public key certificate to the shared data directory on the NFS server. See LDAPS setup.
Set up the reverse proxy (load balancer, ingress controller) - see Reverse proxy.
- Check that the proxy properly sets the X-Forwarded-* headers.
- Enable WebSocket support.
- Configure SSL/TLS termination.
- Configure load balancing to Kubernetes worker nodes, enable health checks.
(optional) Set up the SMTP server - see SMTP server.
- Create the mail account for pSeven Enterprise, set up password authentication.
Set up the local Docker Registry - see Registry setup.
- Get the full version number from the pSeven Enterprise Helm chart.
- Copy the pSeven Enterprise images from the DATADVANCE Registry.
- Create the pSeven Enterprise user and set up password authentication for this user.
Check that your network satisfies the pSeven Enterprise requirements and allows all connections established by pSeven Enterprise. See Network parameters.
Generate the pSeven Enterprise secrets - see Secrets.
- Get the full version number from the pSeven Enterprise Helm chart.
- Run the pseven⁠-⁠secretgen image to get the secrets file pseven⁠-⁠secrets.yaml.
- Backup the secrets file.
Prepare your deployment configuration - see Deployment configuration.
- Generate the deployment configuration file values.yaml from the pSeven Enterprise Helm chart.
- Set parameters in values.yaml.
Install the pSeven Enterprise Helm chart - see Installation.
- Use the prepared values.yaml and pseven⁠-⁠secrets.yaml files.
- Install to the pSeven Enterprise namespace (pseven⁠-⁠ns) as a named release (pseven⁠-⁠rl), save the installation log.
- Monitor the installation progress for errors and warnings.
- Run the post-install commands output by Helm to the log.
Secure the built-in admin account - see Admin access.
Set up the license - see License.
- Get your Installation ID (generated during deployment).
- Request a license for your Installation ID.
- Add the license to your deployment.
Check user sign-in - see User access.
Check the storage quotas - see User storage quotas.
- Check that the user storage quota management is enabled.
- Set the default user storage quota.
Perform basic tests on your deployment - see Verify installation.
Set up the Windows extension nodes (optional) - see Extension nodes and the Extension node deployment guide.
- Get the extension node setup package from pSeven Enterprise and install.
- Enable clock synchronization (Internet Time) on every extension node.
- Test each node.
Continue with accounts setup.
- Remove the end-user permissions from the default admin account - see Admin account configuration. This is required to exclude the admin from the licensed users count.
- To integrate with AD DS or LDAP, see Users from Active Directory or LDAP server.
- For LDAPS setup, see Using secure LDAP.
- To set up SSO, see Setting up single sign-on (SSO).
- If you are not going to use an existing authentication service, create pSeven Enterprise accounts - see Adding accounts.

Kubernetes cluster¶

A production deployment of pSeven Enterprise requires a fault tolerant production grade Kubernetes cluster with high availability. You can use one of the many managed Kubernetes solutions (see Turnkey Cloud Solutions and Kubernetes Partners), or build your own production Kubernetes cluster.

Compatible versions¶

pSeven Enterprise is compatible with Kubernetes versions 1.15.5 through 1.25.2. Newer versions are compatible but were never tested. Older versions are not supported.

Configuration requirements¶

If you decide to use a new managed Kubernetes cluster, opt for the regional master configuration with load balancer enabled for the control plane nodes.

If you decide to deploy your own cluster, on premises or in the cloud, observe the following recommendations:

Set up your cluster following the guidelines found in the Kubernetes documentation, sections Production environment and Best practices.
If you install Kubernetes version 1.26 or later, note that you must use a container runtime interface that supports CRI API v1 - see CRI version support.
Configure the node filesystem to keep the /var directory on the system root filesystem, as described in Local ephemeral storage.
Make sure that the node disk partition mounted to / (root) has at least 50 GB of free disk space.

Clock synchronization¶

pSeven Enterprise requires clock synchronization for all Kubernetes nodes. Whichever cluster solution you use, make sure that an NTP client is installed and enabled on every cluster node.

Installation namespace¶

pSeven Enterprise should be deployed in a dedicated namespace (see Namespaces). Provide a new namespace to use for the pSeven Enterprise deployment. This guide and other pSeven Enterprise administration guides assume that the pSeven Enterprise installation namespace is called pseven⁠-⁠ns. If you choose another namespace, replace pseven⁠-⁠ns in example commands in the guides with the namespace you actually use.

Helm¶

Helm is the package manager for Kubernetes.

It is recommended use a recent release of Helm - see Installing Helm.

The least version of Helm compatible with pSeven Enterprise is Helm 3.10.0. Older versions are not compatible and must be updated.

PostgreSQL server¶

pSeven Enterprise requires PostgreSQL version 12 or greater. Earlier versions are not compatible. You can use a managed PostgreSQL instance from your cloud service provider or a PostgreSQL server that exists in your organization.

Set up the database connection pooling (PgBouncer).
Create a new database and a new database user for pSeven Enterprise.
Set up password authentication for the pSeven Enterprise database user - see Client Authentication.
Verify that the server allows connecting to the database with the above username and password.
Verify that the user you have created for pSeven Enterprise has full access to the pSeven Enterprise database, including permissions to add and remove tables and schemas.

Connection pooling¶

pSeven Enterprise requires connection pooling on the PostgreSQL server in order to avoid issues caused by the PostgreSQL connection limits.

The recommended connection pooling tool for pSeven Enterprise is PgBouncer, which serves as a proxy between the PostgreSQL server and database clients. PgBouncer can be installed on the PostgreSQL server host or on a separate server.

In Ubuntu, Debian distributions: apt-get install pgbouncer.
In RedHat, CentOS distributions: yum install pgbouncer.
Also available from the Postgres package repositories (APT, YUM), which may provide a more recent version than your distribution repository.

For setup instructions, see Usage in the PgBouncer documentation.

NFS server¶

pSeven Enterprise requires an NFS server to store user files and application data.

This server must be used exclusively by a single pSeven Enterprise deployment. It must not serve any other applications or serve multiple pSeven Enterprise instances.
The server storage must support Access Control Lists (ACL).
The server storage must support file locking (the flock() syscall).
NFSv3 must be enabled on the server. Older NFS versions are not compatible with pSeven Enterprise.
NFSv4 support is experimental, and should be disabled on the server, unless using NFSv4 is required by your organization. See Disabling NFSv4 for an example.
Disk quota support is required to enable user storage quotas in pSeven Enterprise. See Enabling user storage quota for an example.
The server should designate 3 data storage directories to be used by pSeven Enterprise: user data, app data, and shared data. The data storage directories must be exported with the no_root_squash flag and must be owned by the user with UID 11111 who has full access. See Data storage directories.

Data segregation

The data storage directories are independent. If required, you can create them on different servers and connect those servers to pSeven Enterprise.

Further sections consider nfs-kernel-server in Ubuntu Server to provide an example of configuring an NFS server for pSeven Enterprise. You can enable nfs-kernel-server as follows:

sudo apt install nfs-kernel-server
sudo systemctl enable rpc-statd
sudo systemctl start rpc-statd
sudo systemctl enable --now nfs-server

Note that nfs-server requires rpc-statd but does not enable it automatically. Check that rpc-statd is running and check the NFS server status:

sudo systemctl status rpc-statd
ps -e | grep rpc.statd
sudo systemctl status nfs-kernel-server

Disabling NFSv4¶

NFS servers normally enable NFSv3 and NFSv4 protocol versions by default. Both are compatible with pSeven Enterprise, however NFSv4 support is experimental.

If your organization's NFS usage policy does not require NFSv4, it is recommended that you disable NFSv4 and check that the server allows NFSv3 only. For example, if using Ubuntu Server with nfs-kernel-server, you can disable NFSv4 as follows.

22.04 or later20.04 or earlier

On Ubuntu Server 22.04 or later, you can use nfsconf:

Run the following sequence of commands to change the server configuration:

sudo nfsconf --set nfsd vers2 n
sudo nfsconf --set nfsd vers3 y
sudo nfsconf --set nfsd vers4 n
sudo nfsconf --set nfsd vers4.0 n
sudo nfsconf --set nfsd vers4.1 n
sudo nfsconf --set nfsd vers4.2 n

Use sudo nfsconf --dump to check the resulting settings.
Reboot the server to apply the new configuration.

If a full reboot is unwanted, you can restart the nfs-kernel-server and rpc-statd services:
```
sudo systemctl restart nfs-kernel-server rpc-statd
```
Note that restarting the services sometimes does not bring the configuration changes to effect.
Check the server configuration as described below.

On Ubuntu Server 20.04 and earlier releases, you need to edit the nfs-kernel-server configuration file:

Open /etc/default/nfs-kernel-server.
Add the --no-nfs-version 4 option to RPCNFSDCOUNT:
```
# Number of servers to start up
#RPCNFSDCOUNT=8
RPCNFSDCOUNT="8 --no-nfs-version 4"
```
Adding the --no-nfs-version 4 option to RPCMOUNTDOPTS as described in /etc/default/nfs-kernel-server does not work due to a bug in nfs-kernel-server. Modifying RPCNFSDCOUNT is a workaround.
Save the changes to /etc/default/nfs-kernel-server, then reboot the server.

If a full reboot is unwanted, you can restart the nfs-kernel-server and rpc-statd services:
```
sudo systemctl restart nfs-kernel-server rpc-statd
```
Note that restarting the services sometimes does not bring the configuration changes to effect.
Check the server configuration as described below.

To check the server configuration, create a temporary test directory accessible over NFS and a test mount point. Try mounting the test directory using NFSv4 to verify that it is disabled. Then, try using NFSv3 to verify that it works.

Create a test directory to be mounted, and another to be used as the mount point. For example:

sudo mkdir -p /tmp/p7-nfs-test/storage  # The test directory.
sudo mkdir -p /tmp/p7-nfs-test/mountpoint  # The test mount point.

Allow NFS access to the test directory:

echo -e "\n/tmp/p7-nfs-test/storage *(rw,sync,no_subtree_check)" | sudo tee -a /etc/exports > /dev/null
sudo exportfs -av

The exportfs -av command should output a message similar to:

exporting *:/tmp/p7-nfs-test/storage

Try mounting the test directory using NFSv4. You should see a "Protocol not supported" error:

sudo mount -t nfs -o vers=4 localhost:/tmp/p7-nfs-test/storage /tmp/p7-nfs-test/mountpoint

mount.nfs: Protocol not supported

Now mount the test directory using NFSv3. This must work without errors:
```
sudo mount -t nfs -o vers=3 localhost:/tmp/p7-nfs-test/storage /tmp/p7-nfs-test/mountpoint
```
Additionally check that the test directory is mounted using NFSv3. Use the following command, which outputs the test directory mount options:
```
mount | grep p7-nfs-test
```
Look for the mountvers option in the output: it should read mountvers=3.

The server configuration test has passed if mounting the test directory fails when you use NFSv4 and works when you use NFSv3, and mount shows the mountvers=3 option.

Remove the /tmp/p7-nfs-test directory used for testing.
Remove the /tmp/p7-nfs-test/storage *(rw,sync,no_subtree_check) line from /etc/exports.

If the server configuration test fails, contact the DATADVANCE support team for further advice (see Technical support).

Enabling user storage quota¶

pSeven Enterprise supports user storage quotas and enables them automatically, if you configure the user data storage server filesystem as described in this section.

Install the disk quota management tools package, for example:
```
sudo apt-get install quota
```
Disk quotas are configured per partition. Identify the partition where the user data storage is located and its mount point. In the examples below, the mount point of the user data storage partition is denoted {usermnt}.
Open /etc/fstab and add the usrquota,grpquota flags to the {usermnt} mount point options. Save your edits, then re-mount the filesystem:
```
sudo mount -o remount {usermnt}
```
Enable disk quotas:
```
sudo quotacheck -ugm {usermnt}
sudo quotaon -v {usermnt}
```
If the sudo quotaon command returns an error message indicating that the system kernel does not support storage quotas, you should check and install the required kernel modules if necessary (see Checking for the kernel modules).
pSeven Enterprise requires a remote quota server (rpc-rquotad) running on the file storage. The quota server must allow the remote setting of quotas (run with the --setquota or -S option).
- Add rpc-rquotad to startup, allow the remote setting of quotas. Refer to your Linux distribution documentation for details on configuring system startup. You can find an example for Ubuntu Server in Enabling the remote quota service.
- Reboot the file storage server and verify that the remote quota server has started automatically.
For testing purposes, you can also start the remote quota server manually with sudo rpc.rquotad -S.

Checking for the kernel modules¶

To enable disk quotas, the appropriate operating system kernel modules must be installed and loaded. You can check for them using the following command:

lsmod | grep -i quota

This command should output the following list, indicating that the required modules are in place:

quota_v1               16384  0
quota_v2               16384  2

Otherwise, you must install these modules using the following command:

apt install linux-image-extra-virtual

If you use Amazon Web Services (AWS), you must additionally install the linux-modules-extra-aws package using the following command:

apt install linux-modules-extra-aws

Use the following commands to load and check for the required modules:

modprobe quota_v1
modprobe quota_v2
lsmod | grep -i quota

If the quota_v1 and quota_v2 modules are still missing from the lsmod output, contact the DATADVANCE support team for further guidance (see Technical support). If these modules are in the list, run the following commands to ensure they are autoloaded:

echo quota_v1 >> /etc/modules
echo quota_v2 >> /etc/modules

Finally, enable disk quotas ({usermnt} is the user data storage partition mount point):

sudo quotaon -v {usermnt}

Enabling the remote quota service¶

The rpc-rquotad service must be configured so that it starts automatically and allows the setting of quotas. For example, on Ubuntu Server you can configure this service as follows:

Create /etc/systemd/system/rpc-rquotad.service and add the following settings there:

rpc-rquotad.service

[Unit]
Description=Quota remote RPC service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=root
ExecStart=/usr/sbin/rpc.rquotad -S -F

[Install]
WantedBy=multi-user.target

Start the rpc-rquotad service:

systemctl start rpc-rquotad
systemctl daemon-reload

Enable automatic start of the rpc-rquotad service:
```
systemctl enable rpc-rquotad
```
Finally, reboot the file storage server and verify that the remote quota server has started automatically.

Data storage directories¶

pSeven Enterprise uses 3 data storages:

User data storage ({user data}) - contains user home directories.
AppsHub data storage ({app data}) - contains published apps.
Shared data storage ({shared data}) - contains system data.

Each storage must be a separate NFS share. For simplicity, the examples below assume that you create all those shares on the same NFS server, though this is not required.

Create directories and configure access. pSeven Enterprise connects to NFS shares as a system user with UID 11111. This user must be the shared directory owner with full access.

sudo mkdir -p /var/pSeven  # Create the parent directory for file storages.
cd /var/pSeven
sudo mkdir UserData AppsHubData SharedData  # Create file storage directories.
sudo chown 11111 UserData AppsHubData SharedData  # Set the pSeven Enterprise system user as the owner.
sudo chmod u+rwx UserData AppsHubData SharedData  # Set full access rights for that user.

Export directories:

echo -e "\n/var/pSeven/UserData *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)" | sudo tee -a /etc/exports > /dev/null
echo -e "\n/var/pSeven/AppsHubData *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)" | sudo tee -a /etc/exports > /dev/null
echo -e "\n/var/pSeven/SharedData *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)" | sudo tee -a /etc/exports > /dev/null
sudo exportfs -av

The exportfs -av command should output a list of exported directories similar to the following:

exporting *:/var/pSeven/SharedData
exporting *:/var/pSeven/AppsHubData
exporting *:/var/pSeven/UserData

Apply NFS configuration:

sudo systemctl restart nfs-kernel-server

Check the NFS server status:

sudo systemctl status nfs-kernel-server

LDAPS setup¶

pSeven Enterprise supports AD DS and LDAP integration and the secure LDAPS protocol (LDAP over SSL/TLS). The use of LDAPS requires adding the LDAP server public key to the pSeven Enterprise shared data storage before installation.

Get the LDAPS public key certificate that is used in your organization. The certificate must be exported to a DER or Base-64 encoded X.509 file. Request the certificate file from your LDAP services admin, or get it with a command like the following:
```
openssl s_client -connect {LDAP server address}:{port number} < /dev/null > ldaps.cert
```
On the NFS server, in the directory you have designated for the pSeven Enterprise shared data storage, create the subdirectory named certs.
Copy the certificate file to certs. The file must be named ldaps.cert as in the example above. The resulting path to the certificate must be {shared data}/certs/ldaps.cert, where {shared data} is the pSeven Enterprise shared data storage directory path.

pSeven Enterprise will import the LDAP server public key from {shared data}/certs/ldaps.cert during installation. The rest of the LDAPS setup is done after the installation.

Reverse proxy¶

pSeven Enterprise should be placed behind a reverse proxy to secure the deployment and enable load balancing - for example, NGINX or Traefik.

Before you deploy pSeven Enterprise, ensure that:

Your reverse proxy properly sets the X-Forwarded-* headers for the forwarded requests.
The proxy supports the WebSocket protocol.
SSL/TLS termination is enabled (see examples: NGINX, Traefik).
The proxy is configured to load balance the user traffic to Kubernetes nodes.
The proxy sends health check requests to Kubernetes nodes (see examples: NGINX, Traefik).

SMTP server¶

pSeven Enterprise can use an SMTP server to send emails to users - for example, notifications and password reset links. You can also deploy without an SMTP server; those features will then be unavailable.

Create a new mail account for pSeven Enterprise.
Set up password authentication for that account.

Registry setup¶

Running pSeven Enterprise requires a Docker Registry, which stores the pSeven Enterprise Docker images. The Registry is also required during the installation.

It is recommended to set up a local Registry in the same network with pSeven Enterprise and copy images from the DATADVANCE Registry (registry.pseven.io) before the installation. You can use a managed Registry instance from your cloud service provider or a Registry that exists in your organization.

If you are deploying a new Registry, see Deploy a registry server for instructions.
pSeven Enterprise requires a username and a password to connect to the Registry. Create the pSeven Enterprise user and set up password authentication - see Restricting access.

To prepare for the pSeven Enterprise installation, copy its images from the DATADVANCE Registry to your local Registry:

Log in to the DATADVANCE Registry and the local Registry.

docker login registry.pseven.io  # Log in to DATADVANCE Registry
docker login {registry address}  # Log in to your local Registry

Get the list of image names from the pSeven Enterprise Helm chart:

helm show values pseven-{YYYY.MM.DD}.tgz | grep -oE "registry\.pseven\.io\/[^:]+"

Get the full version number from the pSeven Enterprise Helm chart:

helm show chart pseven-{YYYY.MM.DD}.tgz | grep appVersion | cut -d" " -f2

Copy each image to your local Registry, specifying the full version number. For example (replace {registry} with your Registry address, {version} with the full version number):

docker pull registry.pseven.io/pseven-app:{version}
docker tag registry.pseven.io/pseven-app:{version} {registry}/pseven/pseven-app:{version}
docker push {registry}/pseven/pseven-app:{version}

Remove images from the local cache, for example:

docker image rm registry.pseven.io/pseven-app:{version}
docker image rm {registry}/pseven/pseven-app:{version}

Network parameters¶

All nodes used by pSeven Enterprise and all infrastructure service hosts must support 1 Gb/s connection speed, and the NFS server specifically must support 10 Gb/s. Network connections with high latency or less bandwidth often cause performance loss and system failures.

Your network configuration must allow all connections established by pSeven Enterprise. See the diagram below for an overview and the full details in the table that follows.

flowchart TB
  classDef dashed stroke:#777,stroke-dasharray: 5 5;

  subgraph da [DATADVANCE]
    dockerreg-da[(Docker<br>Registry)]:::dashed
  end

  subgraph hostinfra2 [Infrastructure services]
    dockerreg[(Local<br>Docker<br>Registry)]:::dashed
    ldap[AD/LDAP<br>provider]:::dashed
    smtp[SMTP<br>server]:::dashed
    nfs[(Dedicated<br>NFSv3<br>file storage)]
    postgres[(PostgreSQL<br>database)]
  end

  subgraph extnodes [Windows nodes]
      extnode[[pSeven Enterprise<br>Windows extension]]:::dashed
  end

  subgraph kubernetes [Kubernetes cluster]
      kubenodes[[<br><b>pSeven Enterprise</b><br>worker nodes<br><br>]]
  end

  subgraph hostinfra1 [Infrastructure services]
    rproxy[Reverse proxy<br>Load balancer]
  end

  subgraph clients [Clients]
    webui((Web UI<br>user))
    restapi((REST API<br>client))
    admin((Deployment<br>admin))
  end

  kubenodes --"25*/tcp:SMTP<br>465*/tcp:SMTPS<br>587*/tcp:SMTPS"---> smtp
  kubenodes --"389/tcp:LDAP<br>636/tcp:LDAPS"---> ldap
  kubenodes --"5432*/tcp+udp:PostgreSQL"---> postgres
  kubenodes --"111/tcp+udp:NFS<br>1110/tcp+udp:NFS<br>2049/tcp+udp:NFS<br>4045/tcp+udp:NFS"---> nfs
  kubenodes --"443/tcp:HTTPS"---> dockerreg
  kubenodes -."443/tcp:HTTPS"...-> dockerreg-da

  webui --"443/tcp:HTTPS"--> rproxy
  restapi --"443/tcp:HTTPS"--> rproxy
  rproxy --"30080*/tcp:HTTP<br>30001*/tcp:HTTP"--> kubenodes

  admin --"6443/tcp:Kubernetes API"--> kubernetes
  admin --"3389/tcp:RDP"--> extnode

  extnode --"31194*/tcp+udp:OpenVPN"--> kubenodes

  admin --"5432/tcp+udp:PostgreSQL"--> postgres
  admin --"111/tcp+udp:NFS<br>1110/tcp+udp:NFS<br>2049/tcp+udp:NFS<br>4045/tcp+udp:NFS"--> nfs

Notes

The AD/LDAP provider is optional. pSeven Enterprise supports the AD DS and LDAP integration but does not require it.
The SMTP server is optional. You can skip the related installation steps. If you deploy without an SMTP server, pSeven Enterprise will be unable to send emails to users - for example, notifications or password reset links.
Windows extension nodes are optional. You can disable the support for Windows extension nodes before the pSeven Enterprise installation. You can also keep it enabled but do not deploy any Windows nodes, and add them later on demand.
Also before the installation, you can change the following ports used by pSeven Enterprise (marked * in the diagram):
- The ports for inbound connections (defaults are 30080 and 30001).
- The OpenVPN connection port (default is 31194). This port is used only if there are Windows extension nodes connected to pSeven Enterprise.
- The PostgreSQL database connection port. There is no default, 5432 is the commonly used port.
- The SMTP server connection port. There is no default, port number depends on your SMTP server type.

The table below contains full details about the pSeven Enterprise network parameters. Note that certain ports are configurable, and certain components run conditionally - see the notes next to the table.

Component	Listen ports/protocols	Outbound connections
`appserver`	10080/tcp:HTTP	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP `keycloak`: 10080/tcp:HTTP `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL Mail server: 25/tcp:SMTP Mail server: 465,587/tcp:SMTPS File storage: 111,1110,2049,4045/tcp+udp:NFS
`appshubui`	10080/tcp:HTTP	none
`appworkerappjobs`	none	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`appworkerblockjobs`	10000-65535/tcp:HTTP	To pSeven Enterprise components: `appserver`: 10080/tcp:HTTP `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`appworkerfilesystemjobs`	none	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`appworkerworkflowjobs`	none	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`blockfilesgate`	139/tcp:NetBIOS 445/tcp:SMB	To infrastructure components: File storage: 111,1110,2049,4045/tcp+udp:NFS
`blocknetworkgate`	31194/tcp+udp:OpenVPN	To pSeven Enterprise components: `appserver`: 10080/tcp:HTTP `blockfilesgate`: 139/tcp:NetBIOS `blockfilesgate`: 445/tcp:SMB `blocksshgate`: 11122/tcp:SSH `blocksshgate`: 10000-65535/tcp:HTTP `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP
`blockrouter`	10080/tcp:HTTP	To pSeven Enterprise components: `appworkerblockjobs`: 10000-65535/tcp:HTTP `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP `blocksshgate`: 11122/tcp:SSH `blocksshgate`: 10000-65535/tcp:HTTP `redis`: 16379/tcp:Redis
`blocksshgate`	11122/tcp:SSH 10000-65535/tcp:HTTP	none
`dataeditorui`	10080/tcp:HTTP	none
`edgerouter`	30080/tcp:HTTP 30001/tcp:HTTP	To pSeven Enterprise components: `appserver`: 10080/tcp:HTTP `blockrouter`: 10080/tcp:HTTP `keycloak`: 10080/tcp:HTTP `files`: 10080/tcp:HTTP `psevenui`: 10080/tcp:HTTP `appshubui`: 10080/tcp:HTTP `dataeditorui`: 10080/tcp:HTTP `valueeditorui`: 10080/tcp:HTTP
`files`	10080/tcp:HTTP	To infrastructure components: File storage: 111,1110,2049,4045/tcp+udp:NFS
`htcondorexecute`	19618/tcp:Condor 10000-65535/tcp:HTTP	To pSeven Enterprise components: `appserver`: 10080/tcp:HTTP `blocksshgate`: 10000-65535/tcp:HTTP `blocksshgate`: 11122/tcp:SSH `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `redis`: 16379/tcp:Redis To infrastructure components: File storage: 111,1110,2049,4045/tcp+udp:NFS
`htcondormanager`	19618/tcp:Condor	To pSeven Enterprise components: `htcondorsubmit`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP
`htcondorsubmit`	19618/tcp:Condor	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorexecute`: 19618/tcp:Condor `htcondorexecute`: 10000-65535/tcp:HTTP To infrastructure components: File storage: 111,1110,2049,4045/tcp+udp:NFS
`keycloak`	10080/tcp:HTTP	To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL AD/LDAP provider: 389/tcp:LDAP AD/LDAP provider: 636/tcp:LDAPS
`launcher`	10080/tcp:HTTP	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`memcached`	11211/tcp:Memcached	none
`post1_makeextnodepkgs`	none	File storage: 111,1110,2049,4045/tcp+udp:NFS
`post1_migratedb`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL
`post2_cleanupruns`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`post2_fixstorages`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`post2_scanapps`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`post3_moveuserstokeycloak`	none	To pSeven Enterprise components: `keycloak`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`post3_tweakkeycloakconfig`	none	To pSeven Enterprise components: `keycloak`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`post3_upgradeapps`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`psevenui`	10080/tcp:HTTP	none
`redis`	16379/tcp:Redis	none
`upkeepkblockeditsessions`	none	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`upkeeplogs`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`upkeepquotas`	none	To pSeven Enterprise components: `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`upkeepruns`	none	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`upkeepwaitingruns`	none	To pSeven Enterprise components: `htcondormanager`: 19618/tcp:Condor `htcondorsubmit`: 19618/tcp:Condor `launcher`: 10080/tcp:HTTP `memcached`: 11211/tcp:Memcached `redis`: 16379/tcp:Redis To infrastructure components: PostgreSQL database: 5432/tcp+udp:PostgreSQL File storage: 111,1110,2049,4045/tcp+udp:NFS
`valueeditorui`	10080/tcp:HTTP	none

Notes

The PostgreSQL database connection port can be configured while you prepare for the installation. 5432 is the commonly used port.
The actually used SMTP server connection port depends on your SMTP server type and can be configured while you prepare for the installation.
The blocknetworkgate listen port for OpenVPN connections can be configured while you prepare for the installation (31194 is the default). If you disable the support for Windows extension nodes, this port is not used.
The edgerouter listen ports 30080 (user client connections) and 30001 (health check requests) can be configured while you prepare for the installation.
blockfilesgate, blocknetworkgate, and blocksshgate do not run if you disable the support for Windows extension nodes.
htcondorexecute runs only if you disable running the pSeven Enterprise user tasks (blocks) on Kubernetes natively.
htcondormanager and htcondorsubmit do not run if you:
- disable the support for Windows extension nodes, and
- enable running the pSeven Enterprise user tasks (blocks) on Kubernetes natively.
The post* components are Jobs, which run once during the installation.
The post1_makeextnodepkgs Job does not run if you disable the support for Windows extension nodes.
The post2_fixstorages Job runs only if you enable the file storage check when upgrading pSeven Enterprise (install with the -⁠-⁠set fixStorages=true option) - see Upgrading pSeven Enterprise.
The upkeep* components are CronJobs, which run on schedule.

Secrets¶

The initial deployment of pSeven Enterprise requires a set of secrets - encryption keys and certificates. To generate these secrets:

Log in to the Docker Registry.

docker login {registry address}  # registry.pseven.io or your local Registry address

Get the full version number from the pSeven Enterprise Helm chart:

helm show chart pseven-{YYYY.MM.DD}.tgz | grep appVersion | cut -d" " -f2

Generate the secrets file (replace {registry} with the Registry address, {version} with the full version number):
```
docker run --rm {registry}/pseven-secretgen:{version} > pseven-secrets.yaml
```

The secrets file pseven⁠-⁠secrets.yaml will be required to start the installation. Also keep a backup copy of the secrets file after completing with the deployment.

Deployment configuration¶

To install pSeven Enterprise, you have to prepare the deployment configuration file values.yaml. Generate this file from the pSeven Enterprise Helm chart:

helm show values pseven-{YYYY.MM.DD}.tgz > values.yaml

Open values.yaml and specify the parameters listed below. See the comments in values.yaml for detailed parameter descriptions and examples.

Replace "*" in entrypoint.allowedHosts with your reverse proxy address.
Set entrypoint.usingTrustedReverseProxy:
- true to trust the X-Forwarded-* request headers. This setting requires that all connections to pSeven Enterprise come through a trusted reverse proxy.
- false for all other cases.
Replace the DATADVANCE Registry address in registry.url with your local Registry address.
Set registry.username and registry.password.
Set all storage.* parameters according to your NFS file storage configuration.
Set all postgres.* parameters according to your PostgreSQL database server configuration.
If you are providing an SMTP server, set all smtp.* parameters according to its configuration.
The sizing.htcondorexecuteReplicas and sizing.htcondorexecuteResources.requests.memory parameters should be set to provide maximum performance but avoid running two or more task executor containers on the same worker node. This is commonly achieved with the following:
- Set the number of executors - sizing.htcondorexecuteReplicas equal to the number of the worker nodes in your cluster.
- Set sizing.htcondorexecuteResources.requests.memory equal to half the amount of worker node RAM. For example, if the worker nodes have 16 GB RAM, set "8192Mi" (8 GB).
- Set sizing.htcondorexecuteResources.requests.cpu equal to half the performance of worker node CPUs. For example, if the worker nodes have 8 CPU cores, set "4000m" (4 cores; the value is in millicores).
In the image.* parameters, replace the DATADVANCE Registry address (registry.pseven.io) with your local Registry address.

Other parameters in values.yaml, which are not mentioned above, are set to sensible defaults. You can change them according to your requirements.

Installation¶

Before you begin with the installation, check you have the following files in the current directory:

pseven⁠-⁠{YYYY.MM.DD}.tgz - the Helm chart.
values.yaml - the deployment configuration file with your settings (see Deployment configuration).
pseven⁠-⁠secrets.yaml - the secrets file for this deployment (see Secrets).

In the examples below, pseven⁠-⁠rl is the Helm release name, which identifies your pSeven Enterprise deployment, and pseven⁠-⁠ns is the dedicated installation namespace. These are conventional names, which are not required. If you choose other names, replace pseven⁠-⁠rl and pseven⁠-⁠ns in example commands.

Make sure you are installing to a clean environment:
```
helm uninstall pseven-rl -n pseven-ns
```
This command, for example, will remove the leftovers of the previous installation, if you are reinstalling pSeven Enterprise after an unsuccessful installation attempt.
Install with values.yaml and pseven⁠-⁠secrets.yaml you have prepared:
```
helm install pseven-rl pseven-{YYYY.MM.DD}.tgz -f values.yaml -f pseven-secrets.yaml -n pseven-ns --timeout 60m --wait --debug | tee pseven-{YYYY.MM.DD}.log
```
Note the -⁠-⁠timeout option in the example installation command. That option is required because Helm will need to load several GB of images from the Registry, so the Helm's default operation timeout (5 minutes) is usually too low.

Keep the installation log file (pseven⁠-⁠{YYYY.MM.DD}.log) - it is required for troubleshooting installation errors.
While helm install runs, watch the console log for errors and monitor state of Kubernetes resources - for example, using the kubectl get all command. If you see any errors or find that Kubernetes resource states do not change over an extended time period, refer to the Technical support section.
When installation enters the final stage, Helm shows a finalization message with a few commands to get the network addresses of your deployment. Run those commands and save the following from their output (note that all URLs include a port number):
- pSeven Enterprise sign-in URL ({sign-in URL})
- pSeven Enterprise admin URL ({admin URL})
- pSeven Enterprise health check endpoint
- The list of worker node addresses
Important

Do not give out the pSeven Enterprise sign-in URL to end users. The users should connect to a reverse proxy, which forwards the user requests to this URL.
Wait while Kubernetes launches the pSeven Enterprise services. After a few minutes, go to the pSeven Enterprise sign-in URL. The user sign-in page should load. Sign-in will be blocked at the moment, because you have not added a license yet.

If the sign-in page does not load, refer to the Technical support section.

Before you proceed, back up the following files:
- pseven⁠-⁠{YYYY.MM.DD}.log - the installation log
- values.yaml with your settings
- pseven⁠-⁠secrets.yaml

Admin access¶

pSeven Enterprise provides a built-in admin account for performing the initial administrative tasks, with the following default credentials:

Username: admin
Password: admin
Email: admin@admin.admin

Secure the built-in admin account immediately after installation:

Open the pSeven Enterprise admin URL with a web browser and sign in with the default admin credentials. You will be prompted to set a new password for the built-in admin account. After you set the password, the Site administration page will open.
In the Site administration page header on the right, click Manage users. You will be redirected to the Users page of the pSeven Enterprise Admin Console.
Select the Manage account command from the user menu in the upper right corner of the Users page. The Edit Account page will open.
In the Email field on the Edit Account page, enter a valid email address, then save your changes on that page.

Important

Never disable the built-in admin account unless you have another admin account active, and never revoke admin rights from all accounts or disable all admin accounts. Otherwise, admin access to pSeven Enterprise will be entirely blocked.

License¶

Each pSeven Enterprise license is bound to a specific Installation ID. The Installation ID is unique for every deployment and is generated during installation.

Open the pSeven Enterprise admin URL and sign in.
Copy the ID string from the page header. Example header:

pSeven Enterprise Admin Site (Installation ID: 20f0dc441f73404fb70ee963806c272e)
Send the Installation ID to your corresponding DATADVANCE or VAR account manager. You shall receive the pSeven Enterprise license file for your Installation ID.
Having received your license file, sign in as admin and open the license settings page (URL: {admin URL}/app_auth/license/add/).
Open the license file, copy its contents into the License source field, and click the Save button at the bottom of the page.

User access¶

If you have set up a reverse proxy, then the end users should connect only to the reverse proxy server and must not be able to access pSeven Enterprise directly (by the sign-in URL).

Test your reverse proxy configuration:

Connect to the reverse proxy with a web browser. You should get redirected to the pSeven Enterprise user sign-in page.
Sign in using the admin credentials. The pSeven Enterprise Studio user interface should open. This step requires a license - without it, the user sign-in is blocked by pSeven Enterprise.

User storage quotas¶

If you have enabled disk quotas on the file storage NFS server, pSeven Enterprise should detect this and enable the user storage quota management (see Enabling user storage quota).

Sign in as admin and go to pSeven Enterprise settings (URL: {admin URL}/app_pseven/settings/).
On the Settings page, check that the value in the "Quota management available" column is "True".
Set the default user storage quota:
Input quota in the "Default user storage quota" field. The value is in megabytes.
Click the Update users quota button to apply quota settings.

After you create the user accounts, you can also set personal quotas for specific users, which take priority over the default quota setting. For details, see Applying user storage quotas.

Verify installation¶

To verify your installation, you need to sign in to the user interface.

Connect to the reverse proxy with a web browser and sign in using the admin credentials.
Perform the tests described in this section. All tests are required. Your deployment cannot be considered successful unless all these tests pass.
If your deployment does not pass any of the tests, contact the DATADVANCE support team for advice (see Technical support).
If all tests have passed, remove the end-user permissions from the default admin account - see Admin account configuration. This is required to exclude the admin from the licensed users count.

File upload test¶

To test general operation, try uploading a file to user Home. The file size should be a few MB.

Drag a file to the Explorer pane on the left, or use the Upload files... command from the pane's menu.
Wait for the upload to complete.
Delete the uploaded file.

The test is considered passed if the file upload was successful.

If you get error 413 or other while uploading a file, there may be an issue with the reverse proxy, load balancer or ingress controller in your environment (see Reverse proxy configuration notes).
If the file upload never finishes, there may be an issue with your NFS server. Check to see if your NFS server meets the requirements and is configured as described in the NFS server section.

AppsHub test¶

To test user workflow execution, try running an example from AppsHub.

Switch to AppsHub: click Studio in the top navigation bar, then select AppsHub.
In AppsHub, open the Disk optimization example: hover over its thumbnail and click the icon.
In the example, scroll down and click the Calculate button at the bottom. The button title should change to Deploying workflow..., then Setting parameters..., then Running workflow...
Wait a few minutes for the workflow to complete.

Warning

Do not refresh or close the browser tab with the example as this cancels the calculation.
After the calculation finishes, the example shows results at the bottom, and the button title changes back to Calculate. Scroll down to see the results.

The test is considered passed if you see the Results section with diagrams and result values.

If you get an error while running the example, or calculation never finishes, your deployment does not function properly.

Extension nodes¶

pSeven Enterprise supports extension nodes, meaning that Windows hosts, which are not Kubernetes nodes, can be set up to connect with the cluster and receive pSeven tasks. These nodes can be used to run platform-dependent or node-locked software from pSeven workflows.

During deployment, pSeven Enterprise generates an extension node setup package and saves it to the pSeven Enterprise file storage. See the Extension node deployment guide for the download and installation instructions. This step is optional.

Creating user accounts¶

pSeven Enterprise supports integration with external authentication services to work with existing user accounts. Alternatively, you can set up basic authentication in pSeven Enterprise.

Check that you have removed the end-user permissions from the default admin account - see Admin account configuration.
To integrate with AD DS or LDAP, see Users from Active Directory or LDAP server.
For LDAPS setup, see Using secure LDAP.
To set up SSO, see Setting up single sign-on (SSO).
If you are not going to use an existing authentication service, create pSeven Enterprise accounts - see Adding accounts.

Notes¶

This section discusses some important considerations to be aware of when deploying pSeven Enterprise.

Reverse proxy configuration notes¶

The pSeven Enterprise entry point for incoming traffic is the edgerouter service (see Network parameters). The deployment publishes the edgerouter service with the NodePort service type (see Publishing Services (ServiceTypes) in the Kubernetes documentation), which exposes the service on each cluster node at a static port. By default, this is port 30080; a different port can be specified by changing the entrypoint.webHttp parameter value in values.yaml.

This configuration gives you the opportunity to set up user access to pSeven Enterprise by routing all incoming traffic from users directly to the node port on any one of the cluster nodes. However the common practice is to use a reverse proxy (load balancer, ingress controller) to handle the incoming traffic. The reverse proxy must be properly configured to handle all traffic between clients and pSeven Enterprise. For instance, an inappropriate configuration of a NGINX-based ingress controller can cause the following issues:

The WebSocket protocol is disabled. As a result, users will be unable to work with pSeven Enterprise because a persistent loading screen will appear after signing in, followed by a timeout error.

To address this issue, enable WebSocket (see WebSocket support in the NGINX Ingress Controller documentation).
The default client request body size limit is too tight. As a result, pSeven Enterprise users may encounter a 413 Request Entity Too Large error when uploading files.

To address this issue, increase the maximum size of the request body (see Custom max body size in the Ingress NGINX Controller documentation).
The default proxy buffer size is insufficient to handle responses from pSeven Enterprise. As a result, a 502 Bad Gateway error may occur when opening the Users page of the pSeven Enterprise authentication service interface.

To address this issue, increase the buffer size (see Proxy buffer size in the Ingress NGINX Controller documentation). The recommended buffer size is 128 KB (128k).

In addition to those described above, you may also need to change other settings depending on the kind of reverse proxy you are using.