Software Collections (SCL) give you the power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages. Therefore, the Software Collections packaging technique is used a lot for building stacks for Red Hat Enterprise Linux and CentOS, especially dynamic languages (Python, Ruby, NodeJS) or databases (PostgreSQL, MariaDB, MongoDB).
Avoiding Conflicts
The SCL technique is based on avoiding conflicts on three levels:
- Filesystem (files are put into an alternate directory under /opt/rh)
- RPM package name (all packages names are prefixed by the collection name)
- RPM metadata (especially provides should be unique, so SCL packages do not influence the packages from base system)
In order to use the Software Collections packages, users need to do "few things" differently than with normal RPMs. For example, they need to use 'scl enable' call, which changes environment variables like PATH or LD_LIBRARY_PATH, so that binaries under alternative path are found. Users also need to use different names for systemd services. Or, some scripts might use full paths for the binaries, like /usr/bin/mysql, so these scripts may not work with Software Collections. Although many things will work without users even notice they use SCL, there can be some issues like that.
Unfortunately, it's not easy to solve these issues, because we would lose the ability to not influence the base system underneath, the main feature of Software Collections technology.
When conflicts are no problem
However, in the latest Red Hat Software Collections release 3.0, the new database collections (PostgreSQL 9.6, MariaDB 10.2, and MongoDB 3.4) use a new concept called "syspaths". This concept allows users still to consume different versions of packages without influencing the other environment but optionally allows them to use the RPM packages as any other package. It feels like the Software Collections technology would not be used at all, which allows users to choose, whether they prefer isolation or usage simplicity.
The concept of syspaths is simply enabled by installing optional packages called *-syspaths, for example, rh-mariadb102-syspaths. These packages deliver shell wrappers in the first place, that is deliberately installed into a standard path (typically /usr/bin). That means that installation of these packages obviously breaks the feature of isolation SCL from the rest of the system. On the other hand, not everybody requires installing and especially run more versions of the same package on one system at the same time, which is especially the case for the database servers.
Wrapper shell script for binaries and variable files
So, what all changes we can see after installing the *-syspaths package? First obvious thing is having few binaries (executable shell scripts) in /usr/bin as mentioned above. Thanks to that, users can simply run mysql or mysqladmin without the need to use 'scl enable' before. The trick is not any magic, the wrapper in '/usr/bin' simply sets the correct environment and executes the original binary that still lives in /opt/rh.
The fact that we use shell wrappers does not allow us to do everything that we can do with original binary though. For example for debugging binaries using gdb, we need to use the full path in /opt/rh, because gdb would not be happy with the wrapper shell script.
Anyway, the binaries are not the only thing that we put outside of /opt, /etc/opt/, or /var/opt/ directories. For example, the path to the database files (originally in /var/opt/rh/rh-mariadb102/lib/mysql in case of MariaDB 10.2 SCL) will be discovered easier now, because the symlink lives in the path that users would usually look into -- under /var/lib. However, we can't simply create a symlink called /var/lib/mysql, because that directory may still include data from the system database, and we really do not want to play with any user's data. What's more, RPM wouldn't like the mixture of symlink and directory for the same path.
So, the symlink is rather called /var/lib/rh-mariadb102-mysql and similarly, for the log file location, the symlink is called /var/log/rh-mariadb102-mariadb (you see the pattern `//-`). Nevertheless, the name itself is not important; as said before, what is important here is that the files will be found easily when looking into /var/lib, or /var/log.
Configure files and services
Do you want more from the syspaths feature? Here it is -- the same concept as for the variable files is used for the configuration files as well; the symbolic links called rh-mariadb102-my.cnf and rh-mariadb102-my.cnf.d can be easily found in /etc. Again, that should help to locate the configuration files.
Systemd and SysV init services are another entry point to the database services that users interact. Users generally do not need to use 'scl enable' when starting the service, because services are by design started in a clean environment. Still, users need to use the correct name, which is usually prefixed by SCL name (rh-mariadb102-mariadb in case of MariaDB 10.2 when no syspaths package is installed). The syspaths feature allows users to use the normal names for the services, like mariadb, mongod, or postgresql, when the syspaths package is installed. And yes, it means that running `systemctl start mariadb` will just work.
As a result, all these enhancements should not only help users to use the new database collections easier in the terminal, but also any existing scripts should not need changes anymore. Just don't forget that the *-syspaths packages obviously conflict with the packages from the base system, so the system packages cannot be installed together with the syspaths packages. If that is a problem for you, but you still want to use the *-syspaths packages, you might also consider container technology (like Docker) to avoid the conflicts. In that case, you would install *-syspaths packages into the container, but no conflicting packages from the base system.
Feedback welcome
What else? Well, enjoy the new *-syspaths feature and provide us with your feedback either here or on sclorg@redhat.com mailing list.
Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.
Take advantage of your Red Hat Developers membership and download RHEL today at no cost.
Last updated: October 13, 2017