Creating An Oracle Solaris DevOps Like Environment, Update ZoneTypes, Roles, Reporting – Version-08

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Finally had the time to updated the latest version of the Solaris DevOps Manager script. Just published Version 0.8 of the Solaris DevOps Manager, full details plus code are available on my Github repository

This version adds many new features, including creating different zone types, security like user/password/roles to create zones, better zone reporting. make sure to read the release notes for all changes.

Below is a copy of the release notes.

I also included below – an example of how to secure the configuration manager system.

Version 0.8 – Whats new

Added: Added a new db zone type. the db zone type will not rely on zfs snapshots. to snap a new db zone, it will use snapshots for the zone, and rsync to copy the db content, the full process is outlined below.

The DB zone type is initially created like any other zone, cloned from z-source (or whatever name you specify in devops_config.ini).
You create a file called db_version.ini with a db version number (for example 1), or the system will automatically created it with the first version number.

By installing the zone you specify the type as DB with option -t db for the zone type.

The clone process will work as follows.

  1. The system create a new DB zone when you run the script with option -t db.
  2. At install time the system will try to find the latest DB version, and create the new DB zone with the next available version. for example if the current version is 5, it will created the new zone with version 6.
  3. At time of the zone install a new DB file system will get initialized.
  4. At first boot of the new DB zone, the zone will mount the current db version (for example version 5), and also mount the new version (for example version 6).
  5. Automatically copy all data from current version for example version 5 => to new version for example 6.
  6. When completed, umount version 5 and version 6. re-mount version 6 as the normal db mount and start the db.

Example installing a new db zone.

Output of the updated devops_manager help script for the new option is below.

By default, all new zones with type app, will get created with the current db version. the current/active db is the one specified in db_version.ini.
The version can be updated with the new -n option.

For example to update the current active db version you can run the below:

Note: You need admin access to do so, otherwise you will get something like the message below(for more info check out the new user role section).

In addition. you can specify a DB version at zone creation or when rotating/updating the db with the -r db -v 5 options, otherwise the current db version will be used.

Added: The user creating a zone will now be stored as part of an SMF property. at time of login you will get the below message (if you are not the developer created the zone).

Added: Two new required options ware added, -u user and -p password.
In addition. the -U was also added, more information is available below.
Note: for the -p option if you only specify -p without the password the system will prompt you for the password.

Note: The devops JSON database now includes the user created the zone, the database file is stored in ports.db, and might need to be manually updated.

Updated: The zone live status view got updated with the zones db real mount, an example is below.

New: Rotating a VM/Zone DB file system will rotate using the db image initially used for creation.

An example rotate db is below.
Note: not much has changed in usage, however this was updated under the hood to accommodate the db changes (more about the at the end).

Added/updated: The zone status was totally re-done, to include most information required(as requested by our developers), a few examples are below.

Default results for only the current authenticated user, without any options.

Getting results for another user by adding -U userb

Showing results for all zones by adding -a.

Getting the most information…(adding -l det and -a)
Note: -a for all zones, and -l det for full details.

Enhanced: If you don’t specify an argument for the -i option, the script will prompt you for one.

Added: Added a -v option at zone creation or at zone rotate, the -v will set which db version to install/use.

Added: The system now checks for user and application roles.

There are a few roles defined out of the box feel free to change them around as needed.

Below is explained how it works.

Now, you have to create a file called access.db, the file defines what access the user gets, the higher the number the more access(based on whats defined in the devops_config.ini APP_ROLES section.

If the user is not in the access.db. access will be denied.

Enhancement: The script will now check and make sure the devops zone/ports db is not in-use while trying to update.

Securing the configuration manager system

Below is an example how to configure/secure a system were the devops_manager application is running on.

The application will only run as user confmgr.

Create a user confmgr in /etc/passwd, etc.., then add the below lines to /etc/user_attr

Note: Non of our developers can login as user confmgr, they login by using their own login to the devops configuration manager system.

When they login they get a menu which will look something like the below.
In the below example we have two groups of users, an admin, and a regular user(developer) (you can setup many types of users – as many as you needed).

The admin menu looks like so.

The regular user menu looks like so.

In /etc/profile we append the below lines.

if [ “${LOGNAME}” != “root” \
-a “${LOGNAME}” != “confmgr” ] ; then
exec /export/home/confmgr/multi_choice 0

Below is how the multi_choice application looks like looks like, you place that in the confmgr home, typically in /export/home/confmgr.

As you can see the menu_access variable will get set to the users access in access.db. i.e. it will call /export/home/confmgr/menu_list_[10|5] (based on how defined in access.db).

Next, you will have to create the menu_list_10 and menu_list_5 (or whatever your user/admin is mapped to).
An example of an admin menu_list is below.

An example of a regular user menu

The menu list is what options the user / developer will get when logging in to the system.

Of course the application has many more options, but this simplifies usage for most users / developers / used cases using the application.

One last configuration is sudo. we need to configure sudo for all developers logging in to this system.

In our case we ware using LDAP, but you can use your local /etc/suders, will work as well.
The below example is what was appended to LDAP.

Note: Make sure the devops_config.ini is owned by confmgr user and only confmgr user can read it(as it contains passwords).

An example of file permissions

For additional details please check out the git repository here.

For a batter explanation you can check out Part 1 and Part 2 on how Creating A DevOps Like Environment In Oracle Solaris.

You might also like – Articles related to Oracle Solaris 11.4/Solaris 12.

Like what you’re reading? please provide feedback, any feedback is appreciated.

Leave a Reply

Notify of