Este conteúdo não está disponível no idioma selecionado.
Chapter 3. Advanced Topics
This chapter discusses advanced topics on packaging Software Collections.
3.1. Using Software Collections over NFS
In some environments, the requirement is often to have a centralized model for how applications and tools are distributed rather than allowing users to install the application or tool version they prefer. In this way, NFS is the common method of mounting centrally managed software.
You need to define a Software Collection macro
nfsmountable to use a Software Collection over NFS. If the macro is defined when building a Software Collection, the resulting Software Collection has its state files and configuration files located outside the Software Collection's /opt file system hierarchy. This enables you to mount the /opt file system hierarchy over NFS as read-only. It also makes state files and configuration files easier to manage.
If you do not need support for Software Collections over NFS, using
nfsmountable is optional but recommended.
To define the
nfsmountable macro, ensure that the Software Collection metapackage spec file contains the following lines:
%global nfsmountable 1 %scl_package %scl
As shown above, the
nfsmountable macro must be defined before defining the %scl_package macro. This is because the %scl_package macro redefines the _sysconfdir, _sharedstatedir, and _localstatedir macros depending on whether the nfsmountable macro has been defined or not. The values that nfsmountable changes for the redefined macros are detailed in the following table.
|
Macro
|
Original definition
|
Expanded value for the original definition
|
Changed definition
|
Expanded value for the changed definition
|
|---|---|---|---|---|
_sysconfdir
|
%{_scl_root}/etc
|
/opt/provider/%{scl}/root/etc
|
%{_root_sysconfdir}%{_scl_prefix}/%{scl}
|
/etc/opt/provider/%{scl}
|
_sharedstatedir
|
%{_scl_root}/var/lib
|
/opt/provider/%{scl}/root/var/lib
|
%{_root_localstatedir}%{_scl_prefix}/%{scl}/lib
|
/var/opt/provider/%{scl}/lib
|
_localstatedir
|
%{_scl_root}/var
|
/opt/provider/%{scl}/root/var
|
%{_root_localstatedir}%{_scl_prefix}/%{scl}
|
/var/opt/provider/%{scl}
|
3.1.1. Changed Directory Structure and File Ownership
The
nfsmountable macro also has an impact on how the scl_install and scl_files macros create a directory structure and set the file ownership when you run the rpmbuild command.
For example, a directory structure of a Software Collection named software_collection with the
nfsmountable macro defined looks as follows:
$rpmbuild -ba software_collection.spec --define 'scl software_collection'...$rpm -qlp software_collection-runtime-1-1.el6.x86_64/etc/opt/provider/software_collection /etc/opt/provider/software_collection/X11 /etc/opt/provider/software_collection/X11/applnk /etc/opt/provider/software_collection/X11/fontpath.d ... /opt/provider/software_collection/root/usr/src /opt/provider/software_collection/root/usr/src/debug /opt/provider/software_collection/root/usr/src/kernels /opt/provider/software_collection/root/usr/tmp /var/opt/provider/software_collection /var/opt/provider/software_collection/cache /var/opt/provider/software_collection/db /var/opt/provider/software_collection/empty ...
3.1.2. Registering and Deregistering Software Collections
In case a Software Collection is shared over NFS but not locally installed on your system, you need to make the scl tool aware of it by registering that Software Collection.
Registering a Software Collection is done by running the
scl register command:
$ scl register /opt/provider/software_collection
where /opt/provider/software_collection is the absolute path to the file system hierarchy of the Software Collection you want to register. The path's directory must contain the
enable scriptlet and the root/ directory to be considered a valid Software Collection file system hierarchy.
Deregistering a Software Collection is a reverse operation that you perform when you no longer want the scl tool to be aware of a registered Software Collection.
Deregistering a Software Collection is done by calling a
deregister scriptet when running the scl command:
$ scl deregister software_collection
where software_collection is the name of the Software Collection you want to deregister.
3.1.2.1. Using (de)register Scriptlets in a Software Collection Metapackage
You can specify (de)register scriptlets in a Software Collection metapackage similarly to how enable scriptlets are specified. When specifying the scriptets, remember to explicitly include them in the
%file section of the metapackage spec file.
See the following sample code for an example of specifying (de)register scriptets:
%install
%scl_install
cat >> %{buildroot}%{_scl_scripts}/enable << EOF
# Contents of the enable scriptlet goes here
...
EOF
cat >> %{buildroot}%{_scl_scripts}/register << EOF
# Contents of the register scriptlet goes here
...
EOF
cat >> %{buildroot}%{_scl_scripts}/deregister << EOF
# Contents of the deregister scriptlet goes here
...
EOF
...
%files runtime -f filelist
%scl_files
%{_scl_scripts}/register
%{_scl_scripts}/deregister
In the register scriptlet, you can optionally specify the commands you want to run when registering the Software Collection, for example, commands to create files in
/etc/opt/ or /var/opt/.
