> [!CAUTION]
> **Caution:** This documentation covers Edge for Private Cloud 4.16.05, which is no longer supported. Google does not provide security patches, bug fixes, or technical support for this version. The current supported version is 4.54.00. See the [Edge for Private Cloud documentation](https://docs.apigee.com/private-cloud/latest/overview) for the current version, or [All versions](https://docs.apigee.com/private-cloud/versions) to compare releases.

*Edge for Private Cloud v. 4.16.05*

A typical Edge installation consists of Edge components distributed across multiple nodes.
After you install Edge on a node, you then install and configure one or more Edge components on
the node.

## Installation process

Installing Edge on a node is a multi-step process:

- Disable SELinux on the node or set it to permissive mode. See [Install the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.16.05/install-edge-apigee-setup-utility) for more.
- Select your Edge configuration from the list of recommended topologies. For example, you can install Edge on a single node for testing, or on 13 nodes for production. See [Installation Topologies](https://docs.apigee.com/private-cloud/v4.16.05/installation-topologies) for more.
- On each node in your selected topology, install the Edge apigee-setup utility:
  - Download the Edge bootstrap_4.16.05.sh file to /tmp/bootstrap_4.16.05.sh.
  - Install the Edge apigee-service utility and dependencies.
  - Install the Edge apigee-setup utility and dependencies.   

    See [Install the Edge apigee-setup
    utility](https://docs.apigee.com/private-cloud/v4.16.05/install-edge-apigee-setup-utility) for more.
- Use the apigee-setup utility to install one or more Edge components on each node based on your selected topology.  
  See [Install Edge components on a node](https://docs.apigee.com/private-cloud/v4.16.05/install-edge-components-node) on a node.
- On the Management Server node, use the apigee-setup utility to install apigee-provision, the utilities that you use to create and manage Edge organizations.   
  See [Onboard an organization](https://docs.apigee.com/private-cloud/v4.16.05/onboard-organization) for more.

## Handling an installation failure

In the case of a failure during the installation of an Edge component, you can try to correct
the issue, and then run the installer again. The installer is designed to be run repeatedly in
cases where it detects a failure, or if you later want to change or update a component after
installation.

## Configure Postgres master-standby
replication

By default, Edge installs all Postgres nodes in master mode. However, in production systems
with multiple Postgres nodes, you configure them to use master-standby replication so that if the
master node fails, the standby node can continue to server traffic. See [Set up Master-Standby Replication for Postgres](https://docs.apigee.com/private-cloud/v4.16.05/set-master-standby-replication-postgres)
for more.

## Who can perform the install

The Apigee Edge distribution files are installed as a set of RPMs and dependencies. To
install, uninstall, and update Edge, the Edge commands must be run by the root user or by a user
that has full sudo access. For full sudo access, that means the user has sudo access to perform
the same operations as root.

Any user who wants to run the following commands or scripts must either be root, or be a user
with full sudo access:

- **apigee-service** utility:
  - **apigee-service** commands: install, uninstall, update.
  - **apigee-all** commands: install, uninstall, update.
- **setup.sh** script to install Edge components (Unless you have already used "apigee-service install" to install the required RPMs. Then root or full sudo access if not required.)
- **update.sh** script to update Edge components

Also, the Edge installer creates a new user on your system, named "apigee". Many Edge commands
invoke sudo to run as the "apigee" user.

Any user who wants to run all other commands than the ones shown above must be a user with
full sudo access to the "apigee" user. These commands include:

- **apigee-service** utility commands, including:
  - **apigee-service** commands such as start, stop, restart, configure.
  - **apigee-all** commands such as start, stop, restart, configure.

To configure a user to have full sudo access to the "apigee" user, edit the sudoers file to
add:

```
installUser        ALL=(apigee)      NOPASSWD: ALL
```

where ***installUser*** is the username of the person working with
Edge.

Any files or resources used by the Edge commands must be accessible to the "apigee" user. This
includes the Edge license file and any config files.

> [!NOTE]
> **Note:** You can set the **RUN_USER** property for an Edge component to specify a different user than "apigee". If you do, then all of the Edge commands for that component invoke sudo to run as that user. Files or resources must then be accessible to that user.

When creating a configuration file, you can change its owner to "apigee:apigee" to ensure that
it is accessible to Edge commands:

1. Create the file in an editor as any user.
2. Chown the owner of the file to "apigee:apigee" or, if you changed the user running the Edge service from the "apigee" user, chown the file to the user who is running the Edge service.

## Silent installation of Edge components

You must pass a configuration file to the apigee-setup utility that contains the information
about the Edge installation. The only requirement on silent installations is that the
configuration file must be accessible or readable by the "apigee" user. For example, put the file
in the /tmp directory on the node and chown it to "apigee:apigee".

All information in the configuration file is required except for the Edge system
administrator's password. If you omit the password, the apigee-setup utility prompts you to enter
it on the command line.

See [Install Edge components on a node](https://docs.apigee.com/private-cloud/v4.16.05/install-edge-components-node) for
more.

## Internet or non-Internet installation

To install Edge on a node, the node must be able to access the Apigee repository:

- **Nodes with an external Internet connection**   

  Nodes with an external internet connection access the Apigee repository to install the Edge RPMs and dependencies.
- **Nodes without an external Internet connection**   

  Nodes without an external Internet connection can access a mirrored version of the Apigee repository that you set up internally. This repository contains all Edge RPMs, but you have to ensure that you have all other dependencies available from repos on the internal network.

## Resolving RPM installation dependencies

The Apigee Edge distribution files are installed as a set of RPM files, each of which can have
its own chain of installation dependencies. Many of these dependencies are defined by third-party
components that are outside the control of Apigee and can change at any time. Therefore, the
documentation does not list the explicit version number of each dependency.

If you are performing an installation on a machine with internet access, the node can download
the necessary RPMs and dependencies. However, if you are installing from a node without internet
access, you typically set up an internal repo containing all necessary dependencies. The
only way to guarantee that all dependencies are included in your local repo is to attempt an
installation, identify any missing dependencies, and copy them to the local repo until the
installation succeeds.

## Setting up a virtual host

A virtual host on Edge defines the domains and Edge Router ports on which an API proxy is
exposed, and, by extension, the URL that apps use to access an API proxy. A virtual host also
defines whether the API proxy is accessed by using the HTTP protocol, or by the encrypted HTTPS
protocol.

As part of the Edge onboarding process, you have to create an organization, environment, and
virtual host. Edge provides the setup-org command to make this process easier
for new users.

When you create the virtual host, you must specify the following information:

- **The name** of the virtual host that you use to reference it in your API proxies.
- **The port** on the Router for the virtual host. Typically these ports start at 9001 and increment by one for every new virtual host.
- **The host alias** of the virtual host. Typically the DNS name of the virtual host.

The Edge Router compares the Host header of the incoming request to the
list of available host aliases as part of determining the API proxy that handles the request.
When making a request through a virtual host, either specify a domain name that matches the host
alias of a virtual host, or specify the IP address of the Router and the Host header containing the host alias.

For example, if you created a virtual host with a host alias of myapis.apigee.net on port
9001, then a cURL request to an API through that virtual host could use one of the following
forms:

- If you have a DNS entry for **myapis.apigee.net** :  

  curl http://**myapis.apigee.net**:9001/{proxy-base-path}/{resource-path}
- If you do not have a DNS entry for **myapis.apigee.net** :  

  curl http://**\<routerIP\>:9001** /{proxy-base-path}/{resource-path} **-H
  'Host: myapis.apigee.net'**   

  In this form, you specify the IP address of the Router, and pass the host alias in the Host header.   

  **Note**: The curl command, most browsers, and many other utilities automatically append the Host header with the domain as part of the request, so you can actually use a curl command in the form:  

  curl http://\<routerIP\>:9001/{proxy-base-path}/{resource-path}

### Options when you
do not have a DNS entry for the virtual host

One option when you do not have a DNS entry is to set the host alias to the IP address of the
Router and port of the virtual host, as \<routerIP\>:port. For example:

```
192.168.1.31:9001
```

Then you make a curl command in the form below:

```
curl http://<routerIP>:9001/{proxy-base-path}/{resource-path} 
```

This option is preferred because it works well with the Edge UI.

If you have multiple Routers, add a host alias for each Router, specifying the IP address of
each Router and port of the virtual host.

Alternatively, you can set the host alias to a value, such as
**temp.hostalias.com** . Then, you have to pass the Host header on every request:

```
curl -v http://<routerIP>:9001/{proxy-base-path}/{resource-path}  -H 'host: temp.hostalias.com'
```

Or, add the host alias to your /etc/hosts file. For example, add this line to /etc/hosts:

```
192.168.1.31   temp.hostalias.com
```

Then you can make a request as if you had a DNS entry:

```
curl -v http://myapis.apigee.net:9001/{proxy-base-path}/{resource-path}
```

## Configuring Edge components post
installation

To configure Edge after installation, you use a combination of .properties files and Edge utilities. For
example, to configure TLS/SSL on the Edge UI, you edit .properties files to set the
necessary properties. Changes to .properties files require you to
restart the affected Edge component.

The .properties files are located in
the /opt/apigee/customer/application directory.
Each component has its own .properties file in that directory.
For example, router.properties
and management-server.properties.

> [!NOTE]
> **Note:** If you have not set any properties for a component, the /opt/apigee/customer/application directory might not contain a .properties file for the component. In that case, create one.

To set a property for a component, edit the corresponding .properties file, and then restart
the component:

```
> /opt/apigee/apigee-service/bin/apigee-service component restart
```

For example:

```
> /opt/apigee/apigee-service/bin/apigee-service edge-router restart
```

When you update Edge, the .properties files in the
/opt/apigee/customer/application
directory are read. That means the update retains any properties that you set on the component.

See [How to Configure Edge](https://docs.apigee.com/private-cloud/v4.16.05/how-configure-edge) for more information on
Edge configuration.

## Ensure Edge Router can
access /etc/rc.d/init.d/functions

The Edge Router a BaaS Portal both use the Nginx router and require read access to
/etc/rc.d/init.d/functions.

If your security process requires you to set permissions on /etc/rc.d/init.d/functions, do
not set them to 700 or else the router will fail to start. Permissions can be set to 744 to allow
read access to /etc/rc.d/init.d/functions.

## Invoking commands on Edge components

Edge installs management utilities under /opt/apigee/apigee-service/bin that you can
use to manage an Edge installation. For example, you can use the apigee-all utility to start, stop, restart,
or determine the status of all Edge components on the node:

```
/opt/apigee/apigee-service/bin/apigee-all stop|start|restart|status|version
```

Use the apigee-service utility
to control and configure individual components. The apigee-service utility has the form:

```
/opt/apigee/apigee-service/bin/apigee-service component action
```

For example, to restart the Edge Router:

```
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
```

You can determine the list of components installed on the node by examining the /opt/apigee directory. That directory
contains a subdirectory for every Edge component installed on the node. Each subdirectory is
prefixed by:

- apigee - a third-party component used by Edge. For example, apigee-cassandra.
- edge - an Edge component from Apigee. For example, edge-management-server.
- edge-mint - a Monetization component. For example edge-mint-management-server.
- baas - an API BaaS component. For example baas-usergrid.

The complete list of actions for a component depends on the component itself, but all
components support the following actions:

- start, stop, restart
- status, version
- backup, restore
- install, uninstall

## Accessing log files

The log file for apigee-setup
and the setup.sh script is
written to /tmp/setup-root.log.

The log files for each component are contained in the /opt/apigee/var/log directory. Each component
has its own subdirectory. For example, the logs for the Management Server are in the
directory:

```
/opt/apigee/var/log/edge-management-server
```

## Common Yum commands

The Edge installation tools for Linux rely on Yum to install and update components. You might
have to use several Yum commands to manage an installation on a node.

- Clean all Yum caches:  
  sudo yum clean all
- To update an Edge component:  
  sudo yum update ***componentName***  
  For example:  
  sudo yum update apigee-setup  
  sudo yum update edge-management-server

## File System Structure

Edge installs all files in the /opt/apigee directory.

> [!NOTE]
> **Note:** You cannot change this directory location. However, you can create a symlink to map it to a different location. See [Install the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.16.05/install-edge-apigee-setup-utility) for more.

In this guide and in the Edge Operations Guide, the root installation directory is noted
as:

```
<inst_root>/apigee
```

The installation uses the following file system structure to deploy Apigee Edge for Private
Cloud.

### Log Files

| **Components** | **Location** |
|---|---|
| Management Server | \<inst_root\>/apigee/var/log/edge-management-server |
| Router | \<inst_root\>/apigee/var/log/edge-router |
| Message Processor | \<inst_root\>/apigee/var/log/edge-message-processor |
| Apigee Qpid Server | \<inst_root\>/apigee/var/log/edge-qpid-server |
| Apigee Postgres Server | \<inst_root\>/apigee/var/log/edge-postgres-server |
| Edge UI | \<inst_root\>/apigee/var/log/edge-ui |
| ZooKeeper | \<inst_root\>/apigee/var/log/apigee-zookeeper |
| OpenLDAP | \<inst_root\>/apigee/var/log/apigee-openldap |
| Cassandra | \<inst_root\>/apigee/var/log/apigee-cassandra |
| Qpidd | \<inst_root\>/apigee/var/log/apigee-qpidd |
| PostgreSQL database | \<inst_root\>/apigee/var/log/apigee-postgresql |

### Data

| **Components** | **Location** |
|---|---|
| Management Server | \<data_root\>/apigee/data/edge-management-server |
| Router | \<data_root\>/apigee/data/edge-router |
| Message Processor | \<data_root\>/apigee/data/edge-message-processor |
| Apigee Qpid agent | \<data_root\>/apigee/data/edge-qpid-server |
| Apigee Postgres agent | \<data_root\>/apigee/data/edge-postgres-server |
| ZooKeeper | \<data_root\>/apigee/data/apigee-zookeeper |
| OpenLDAP | \<data_root\>/apigee/data/apigee-openldap |
| Cassandra | \<data_root\>/apigee/data/apigee-cassandra/data |
| Qpidd | \<data_root\>/apigee/data/apigee-qpid/data |
| PostgreSQL database | \<data_root\>/apigee/data/apigee-postgres/pgdata |