 |
Basic Enterprise Application Realm Documentation |
|
- 1 About BEAR
- 2 Release Notes
- 3 Developer Toolkit
- 4 Installation & Upgrades
- 4.1 Installation Steps
- 4.2 Network Requirements
- 4.3 Application Server Initialization (First Run)
- 4.4 Uninstallation
- 5 Backend Adminitration
- 5.1 Introduction
- 5.2 Common Commands
- 5.3 Application Server Commands
- 5.4 Resource Monitor Commands
- 5.5 Sharepoint Commands
- 5.6 Database Commands
- 6 Frontend Adminitration
- 6.1 User Management
- 6.2 Package Management
- 6.3 Installing Documentation Packages
- 6.4 Application Storage
- 6.5 Resource Monitoring
- 6.6 Resource Scaling
- 6.7 Starting & Stopping BEAR
- 6.8 Security
- 6.9 Physical Storage
- 6.9.1 RAID
- 6.9.2 File Systems
- 6.9.3 Viewing the Storage Summary
- 6.9.4 Decommissioning (wiping) Disks
- 6.9.5 Storage Management
- 6.10 Event Distribution
- 6.11 Hostnames & Ports
|
6.11 Hostnames & Ports
January 28th, 2026 RBAC required: bear: HTTP controls
BEAR makes three interfaces available independently for the purpose of accessing the following services:
- Public facing applications
- The BEAR Admin application
- The API
BEAR specifically exposes these as different services listening on different ports. In total there are actually four because the public facing applications comprise of both standard non secure HTTP and secure HTTPS.
6.11.1 Defining Custom Hostnames & Ports
- Select HTTP Control from the Admin Tools list and then the Hostnames & Ports tab if not already active.

- Set the desired hostnames (we recommend setting FQDNs) for each of the services and the ports that BEAR should listen on.

- For the API, indicate whether TLS is required.
- If required, restrict the range of IP addresses that BEAR will accept API requests on. By default, this is set to 0.0.0.0 which accepts API requests from anywhere. To restrict call to specific class A, B, or C networks, you can replace this with a prefix such as 192.168.1.

- Click Apply to commit the changes to the BEAR configuration.
Changes can be made during operational hours without impacting users. The changes only take affect after the next restart of the application server. So the changes could be made and reviewed during the week and then activated with a restart during a weekend downtime window.
|