Who can perform the Edge 4.16.01 install and configuration

[sgilson]

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 including install, uninstall, update.
  • apigee-all commands including install, uninstall, update.
• setup.sh script to install Edge components
• migrate.sh script to migrate Edge components

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

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: 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.

[#2]

@sgilson Does this mean that all post install commands require root access and are no longer able to be run as the apigee account its self?

If that is the case I have a bit of a design problem to overcome .. yikes.

Also - in our original installs (back in 13 something and again in 14.07) we outright modified the installation scripts to run as the Apigee user account. I am very likely going to need to do that again as our ... infra group... will probably never give us root the way it seems like we need here.

Thoughts? After we discuss maybe we can move to a new question?

[#3]

This came up in the security review, best practice is, “apigee” (and similar non-human user ids) users should not have bash or any other login shells. The reason is, such common accounts are shared by many system administrators so it's difficult to audit who did what.

The design is, all the post install/setup commands should "run as" apigee user but "run by" a non-apigee/non-root user. This is the reason we create the apigee user we create it with "/sbin/nologin" shell.

Note that we are not asking everyone to have "root" privilege through sudo. We want the user to have sudo permission to execute command "on behalf" of the "apigee" user.

Hope that helps.

[#4]

yeah - i totally understand the whole idea of having non shell accessible users. But there is another problem here that is a remnant of big it: in many shops nobody has root. Nobody has sudo to root. This is many times by 'law'.

im seeing 2 very conflicting statements in this thread: "For full sudo access, that means the user has sudo access to perform the same operations as root."

and

"Note that we are not asking everyone to have "root" privilege through sudo. We want the user to have sudo permission to execute command "on behalf" of the "apigee" user."

And i need to get this clarified. Note: I cannot install anything in my world as root. Never have been able to.

Also note: I cannot "create" accounts - so we have them created a head of time by those that can.

This whole shift - w/o any real notice or the benefit of being able to participate in a beta program - is KILLING me.

[#5]

i seriously doubt that you mean we dont have to run as root.

[#6]

Clearly as is even the bootstrap requires root access to function.

apigee@40-gb-updated:~> bash ./bootstrap.sh apigeeuser=<username> apigeepassword=<password>

=== Obtaining creds for software.apigee.com:

=== Begin work ...

=== Checking for presence of misc commands:

=== Checking distro:

=== Checking architecture:

=== Checking OS:

=== Checking SELinux status

bootstrap.sh: Error: this script must be run as root

apigee@40-gb-updated:~>

[#7]

And honestly - with the move to using YUM to install - this kind of makes sense.