Understanding Apache Ranger’s Installation Structure: Two install.properties Files and the Role of the EWS Directory

When deploying Apache Ranger manually, especially on production-grade Hadoop ecosystems, administrators often notice something unusual: Ranger ships two different install.properties files located in different paths.

/opt/ranger/install.properties
/opt/ranger/bin/install.properties

At first glance, they look identical. Both contain similar configuration keys, both appear important, and both seem to influence installation. But they do not serve the same purpose.

Additionally, administrators frequently wonder about another directory created during installation:

/opt/ranger/ews/

What exactly is it, and why does Ranger create it?

In this blog post, we break down these components so you can clearly understand the Ranger installation structure and confidently manage, troubleshoot, and automate your Ranger deployment.

1. Why Apache Ranger Has Two install.properties Files

Apache Ranger keeps its configuration intentionally separated into:

✔ A template file

✔ An active installation configuration file

This design ensures clarity, safety, and upgradeability.

Let’s explore each one.

2. /opt/ranger/bin/install.properties — The TEMPLATE File

This file is the built-in configuration template bundled inside every Ranger release package.

🔹 Purpose

• Acts as a reference configuration
• Shows all available configuration parameters
• Provides default values and examples for admins
• Ensures you always have a clean template to compare during upgrades

🔹 Important characteristics

• It does not change during installation
• Ranger does not read values from this file while installing
• Not intended for editing
• Useful only as a sample config

✔ Think of it as:

The blueprint, not the actual house.

3. /opt/ranger/install.properties — The ACTIVE Configuration File

This is the file you must edit when installing Ranger.

🔹 Purpose

• Ranger’s installation script (setup.sh) reads this file
• Stores your actual configuration:
• Database settings (PostgreSQL / MySQL)
• JDBC connector paths
• Solr audit store URLs & credentials
• Ranger Admin & UserSync passwords
• Unix service user information
• Hadoop configuration path
• Keystore settings

🔹 How Ranger uses it

When you execute:

./setup.sh

Ranger:

1. Loads /opt/ranger/install.properties
2. Validates DB connections
3. Creates databases/tables
4. Generates keystores & stores credentials
5. Writes configuration into the web application
6. Prepares runtime directories
7. Deploys Ranger Admin under /opt/ranger/ews/

✔ Think of it as:

The actual construction plan used to build your Ranger server.

4. Summary: Which File Does What?

Path Role Editable? Used During Installation? /opt/ranger/bin/install.properties Template / reference copy Not recommended ❌ No /opt/ranger/install.properties The actual configuration ✔ Yes ✔ Yes

This distinction prevents accidental overwrites and simplifies upgrades.

5. What Is /opt/ranger/ews/ and Why Is It Important?

After Ranger processes your install.properties, it creates a directory called:

/opt/ranger/ews/

EWS = Embedded Web Server — this is where the actual Ranger Admin application lives.

What does /opt/ranger/ews/ contain?

✔ 1. webapp/

This holds the fully built Ranger Admin web application, including:

• JSP pages
• REST APIs
• Configuration files
• UI components
• Libraries

This is what runs when you access:

http://<host>:6080

✔ 2. logs/

The Ranger Admin server writes all its logs here.

Examples:

ranger-admin-<hostname>.log
xa_portal.log
audit.log

These logs are essential for troubleshooting Ranger startup failures, Solr audit issues, or login problems.

✔ 3. ranger-admin-services.sh

This script manages the Ranger Admin process:

start
stop
restart
status

It is the core service management tool before you convert Ranger into a systemd service.

✔ 4. ranger-admin-initd

Legacy init.d script (for non-systemd systems). Modern deployments typically use systemd units you create manually.

✔ 5. lib/

JAR files required for Ranger Admin runtime.

✔ 6. work/

Temporary directory used by the embedded Tomcat server.

Why does Ranger create the EWS directory?

Because Ranger Admin runs as a standalone web application (with embedded web server). All of its runtime configuration, logs, libraries, and web resources need to be isolated.

So /opt/ranger/ews/ becomes the runtime home of the Ranger Admin server.

✔ Install-time config lives in:

/opt/ranger/install.properties

✔ Runtime files live in:

/opt/ranger/ews/

Clear separation makes Ranger easier to manage and upgrade.

6. Visual Representation of the Directory Structure

Here’s a simple overview:

/opt/ranger/
│
├── install.properties       ← Active install config (YOU EDIT THIS)
├── bin/
│   └── install.properties   ← Template file (reference only)
│
└── ews/                     ← Ranger Admin runtime directory
    ├── webapp/             ← UI + REST application
    ├── logs/               ← Log files
    ├── lib/                ← Java library JARs
    ├── work/               ← Tomcat temp files
    ├── ranger-admin-services.sh ← Start/stop script
    ├── ranger-admin-initd

7. Why This Matters in Production

Understanding these directories helps with:

✔ Upgrades

Modify /opt/ranger/install.properties to re-run setup correctly.

✔ Troubleshooting

Check logs under /opt/ranger/ews/logs/.

✔ Automation

Use systemd to control /opt/ranger/ews/ranger-admin-services.sh.

✔ Security

Know where keystores and sensitive credentials are stored.

Conclusion

Apache Ranger’s installation directory is structured for safety, clarity, and maintainability.

Two install.properties files exist for a reason:

• One is a template
• One is the real configuration

The /opt/ranger/ews/ directory is the heart of the Ranger Admin runtime, containing:

• The web application
• Logs
• Service scripts
• Runtime libraries

If you’re deploying Ranger in a production Hadoop ecosystem, understanding these directories is not optional — it’s essential for smooth operation, troubleshooting, and automation.