Re: explicit shlib_directory in main.cf
Wietse Venema: > Maxim Nikulin: >> of shared libraries. If shlib_directory were absent in main.cf >> and all programs were getting the value from postconf instead of >> reading main.cf directly than package upgrades would be smooth. >> Such way is not viable since there are installations >> with explicit shlib_directory across the world. > > There is no such thing as 'getting the value from postconf instead > of reading main.cf', because the postconf command reads main.cf. The value could be missed in main.cf. From my point of view it looks like compiled-in defaults that could be *reliably* obtained from postconf but not from main.cf directly. From your words I suspect some things that I am not aware of. grep --count shlib_directory /etc/postfix/main.cf 0 postconf shlib_directory shlib_directory = /usr/lib64/postfix This case I intentionally removed shlib_directory line from main.cf. > If possible do not mix new installs and updates. In particular, > with updates one would not expect to change the location of queue, > config, and data files. I see, but some cases could be more complicated. Upgrade could be performed from a version installed from different repository so having significantly different settings. In ultimate cases post install script could move files to another location so preferences should be changed accordingly. I am just trying to find balance between reliable upgrade and degree of allowed customization. E.g. if shlib_directory is responsibility of server administrator or of maintainers of packages. It appeared that setting this particular parameter during first install only could cause problems. That is why my question if it could be omitted emerged. I feel that I have consumed too much of your time already. Thank you for your answers, some things become more clear.
Re: explicit shlib_directory in main.cf
On 07.05.2020 20:38, Wietse Venema wrote:
> Maxim Nikulin:
>>
>> Just to avoid any ambiguity, you suggest that package post install
>> script should have something like the following, don't you?
>>
>> postfix upgrade-configuration \
>
> In which script file or documentation file?
>
>> shlib_directory=/usr/lib...
>> ...
>
> Why would one want to hard-code /usr/lib?
In real life some kind parametrization is expected here
(I realized I am unsure concerning postfix, generally /usr/local
is used by default.) I put "/usr/lib..." just avoid diving into
details with e.g. RPM macro expansion or parameters of alternative
build and packaging scripts. Is it OK to discuss Fedora packaging
rules? (RedHat EL .spec file is similar)
https://src.fedoraproject.org/rpms/postfix/raw/master/f/postfix.spec
Post-install RPM script
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_447
%post -e
contains in particular
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_451
%{_sbindir}/postfix set-permissions upgrade-configuration \
daemon_directory=%{postfix_daemon_dir} \
# More parameters...
>From your words I decided that the following line should be added here
shlib_directory=%{postfix_shlib_dir} \
I took it from install step
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_309
%install
namely from "make non-interactive-package" command
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_322
It uses definition of the internal postfix_shlib_dir parameter
%define postfix_shlib_dir%{_libdir}/postfix
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_32
> Why not also override queue_directory, data_directory, etc? Of
> course many of these are meaningful only for first-time installs.
Sorry, I narrowed down context too much, My question was on
shlib_directory, so I assumed that "..." is a proper substitution
for all other variables. By the way, I noticed that queue_directory
and data_directory are passed to "make non-interactive-package"
but not to "postfix upgrade-configuration" (and shlib_directory too).
>>> As for shlib_dir in main.cf:
>>>
>>> shlib_dir not only specifies at BUILD time the location for
>>> libpostfix-*, information that the runtime linker needs to use to
>>> start a Postfix program, before any Postfix program can look up
>>> settings in main.cf.
>
> You missed the paragraph that immediately follows this. It explains
> how the main.cf setting is used during RUN time.
Maybe I stick too strong to workflow with installing of prepared
rpm or deb packages as opposite to compiling and installing
from sources. I realized the following might be a reason
to *avoid* default value in the config file inside a package:
>>> and therefore this location may be changed after Postfix is built.
If administrator of particular server installed a package
and later decided to move .so files to other directory
then it is time to add explicit shlib_directory to main.cf.
This case invoking "postfix upgrade-configuration" with
shlib_directory parameter in package post-install script
will break postfix. The script is executed during package
upgrade and such scenario includes the cases of transitions
from one package vendor to another perhaps with change
of package layout. I suspect that in general it should
be quite fragile solution to alternate shlib_directory
while using packages.
So the source of problems is upgrade of package between
versions with different layouts or with/without support
of shared libraries. If shlib_directory were absent in main.cf
and all programs were getting the value from postconf instead of
reading main.cf directly than package upgrades would be smooth.
Such way is not viable since there are installations
with explicit shlib_directory across the world.
So the only way is to force updating the setting to built-in
value from new package version (and no possibility to customize
shlib_directory on particular server if postfix is installed
from a package). Commenting out the line in the post install script
could be an alternative.
To summarize, I am considering adapting of the following to
particular packaging system
# post-install stage (clean install or upgrade)
%{_sbindir}/postfix set-permissions upgrade-configuration \
shlib_directory=%{postfix_shlib_dir} \
daemon_directory=%{postfix_daemon_dir} \
# More parameters...
Re: explicit shlib_directory in main.cf
Wietse Venema: > Maxim Nikulin: >> >> I have noticed than postfix-install script explicitly adds >> shlib_directory to the main.cf file e.g. during non-interactive install. > > Postfix records all installation settings in main.cf even if they > are at their built-in defaults. That is because defaults change > over time, and I don't want things to break when people upgrade to > a newer release. Thank you for not blowing away existing config > files. You're expected to run "postfix upgrade-configuration" > instead. Just to avoid any ambiguity, you suggest that package post install script should have something like the following, don't you? postfix upgrade-configuration \ ... shlib_directory=/usr/lib... ... That sounds reasonable. RedHat package contains a call to upgrade-configuration however without shlib_directory, in Debian package I have not noticed it at all. Concerning changed defaults, I expect that package manager should ensure through dependencies and conflicts that consistent set of files is present in the system and actual location files is the same as built-in values. Vice versa I faced an upgrade problem with diverged explicit value in config and real paths in new packages. But you are right, it happened due to absence of proper upgrade-configuration call. > As for shlib_dir in main.cf: > > shlib_dir not only specifies at BUILD time the location for > libpostfix-*, information that the runtime linker needs to use to > start a Postfix program, before any Postfix program can look up > settings in main.cf. I feel come confusion here. postconf -d shlib_directory reports expected build-time value. Do you mean components that reads main.cf directly instead of query to postconf? Presence or absence of explicit shlib_directory in main.cf does not help in the case of problem with library load paths. > You mention the PORTING document. It likely needs updating, as it > was last updated in 2004, about 10 years before I adopted support > for dynamic linking in Postfix 3.0. Are you using "PORTING" as a nickname for "Guidelines for Package Builders"? PACKAGE_README file has modification time in 2015, do not know if it was a significant update. Thank you for the valuable hint, "postfix upgrade-configuration" is almost certainly what I am looking for.
explicit shlib_directory in main.cf
Hi, I have noticed than postfix-install script explicitly adds shlib_directory to the main.cf file e.g. during non-interactive install. Is there any reason why such approach is better than relying on compiled-in default value? PACKAGE_README.html suggests to provide small main.cf file. My concern is that main.cf is marked as config files e.g. in RPM packages, so if administrator touched it than file content is preserved during package upgrade. If an alternative package is built without support of shared libraries or with different value, it requires a dedicated action to configure proper directory in post-install scripts. Am I wrong that everything should just work if shlib_directory is mentioned neither in original package nor in its update? I expected something like if [ "$shlib_directory" = "`bin/postconf -c conf -d -hx shlib_directory`" ]; then bin/postconf -c $CONFIG_DIRECTORY -# "shlib_directory" || exit 1 else bin/postconf -c $CONFIG_DIRECTORY -e "shlib_directory = $shlib_directory" || exit 1 fi Sorry, if I missed discussion of this point. Thanks
