Ownership, Permissions, Authentication, Authorization, User ID, Password?

What are ProTop's security requirements?

NOTE: ProTop Does not require access to your application data.

ProTop only reads system data about your application data. It does not need to touch your application data in any manner. If that is a concern, you can safely create an ID that does not have access to application data and use that ID to manage your ProTop installation and configuration.

Installation and configuration

Use a "dba" type ID to install, configure and run ProTop. A likely candidate for this ID is the one you use to start your OpenEdge databases.

If it so happens that root is used to start the databases (not a recommended practice), we suggest creating a non-root "dba" type ID and using that ID to install and configure ProTop.

ProTop file ownership and permissions

NOTE: for *nix, the ProTop scripts set the umask to 0 (results in 777 permissions) specifically so that people who insist on using root do not create tmp files owned by root that get in everyone else’s way.

If someone downloaded and installed ProTop as root make sure to:

0) chown -R yourDBAID $PROTOP # ProTop should be owned by the DBA, not root
2) chmod -R 755 $PROTOP/* # Everyone needs to be able to read and execute everything in the $PROTOP tree

3) chmod 777 tmp log # the tmp and log directories have to be writeable
4) chmod 777 tmp/* log/* # same with the contents thereof - although you could argue that owner & group are “enough”, world might be going too far in some cases

Exception to “root”: some scripts, such as those that might disconnect users may need to be run with sudo or from a root crontab. These are *exceptions* and are not a good reason to run everything as root.

-U and -P

If your business has restricted access to the database meta schema and or Virtual System Tables (VSTs), ProTop will require a user id (-U) and password (-P) to connect to and read the required system data from the database. These credentials should be stored in a pf file as discussed here.

Scheduling access

On *nix, the dbmonitor service, which restarts ProTop after any outage, is typically scheduled to run from cron, so the ID that manages ProTop typically requires access to cron.

On Windows, ProTop is installed with a command shell requiring administrative privileges. ProTop creates a service (using nssm64.exe) called "ProTop3 DB Monitor" as part of that installation process. This service runs periodically to restart ProTop after any outage.