Installation failure - cannot install both postfix-2:3.5.8-2.el8.x86_64 and postfix-3:3.5.15-1.apnscp.x86_64\

I get the following failure on Alma Linux:

2022-03-13 15:22:51,799 p=1671 u=root n=dnf.[fork.4618] | appstream: using metadata from Fri 11 Mar 2022 04:00:43 PM UTC.
2022-03-13 15:22:51,799 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: extras
2022-03-13 15:22:51,800 p=1671 u=root n=dnf.[fork.4618] | extras: using metadata from Thu 11 Nov 2021 04:40:51 PM UTC.
2022-03-13 15:22:51,800 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: powertools
2022-03-13 15:22:51,818 p=1671 u=root n=dnf.[fork.4618] | powertools: using metadata from Fri 11 Mar 2022 04:04:51 PM UTC.
2022-03-13 15:22:51,818 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: epel
2022-03-13 15:22:51,966 p=1671 u=root n=dnf.[fork.4618] | epel: using metadata from Fri 11 Mar 2022 01:28:12 PM UTC.
2022-03-13 15:22:51,966 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: epel-modular
2022-03-13 15:22:51,969 p=1671 u=root n=dnf.[fork.4618] | epel-modular: using metadata from Fri 11 Mar 2022 02:17:21 PM UTC.
2022-03-13 15:22:51,969 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: mariadb
2022-03-13 15:22:52,024 p=1671 u=root n=dnf.[fork.4618] | mariadb: using metadata from Sat 12 Feb 2022 03:58:35 AM UTC.
2022-03-13 15:22:52,025 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: pgdg-common
2022-03-13 15:22:52,047 p=1671 u=root n=dnf.[fork.4618] | pgdg-common: using metadata from Thu 10 Mar 2022 03:21:04 PM UTC.
2022-03-13 15:22:52,051 p=1671 u=root n=dnf.[fork.4618] | repo: using cache for: pgdg14
2022-03-13 15:22:52,058 p=1671 u=root n=dnf.[fork.4618] | pgdg14: using metadata from Thu 10 Mar 2022 03:21:10 PM UTC.
2022-03-13 15:22:52,063 p=1671 u=root n=dnf.[fork.4618] | Last metadata expiration check: 0:00:13 ago on Sun 13 Mar 2022 03:22:39 PM UTC.
2022-03-13 15:22:52,545 p=1671 u=root n=dnf.[fork.4618] | timer: sack setup: 1033 ms
2022-03-13 15:22:52,597 p=1671 u=root n=dnf.[fork.4618] | timer: depsolve: 12 ms
2022-03-13 15:22:52,607 p=1648 u=root n=ansible | fatal: [localhost]: FAILED! => {“attempts”: 2, “changed”: false, “failures”: [], “msg”: “Depsolve Error occured: \n Problem: problem with installed package postfix-mysql-2:3.5.8-2.el8.x86_64\n - package postfix-mysql-2:3.5.8-2.el8.x86_64 requires postfix = 2:3.5.8-2.el8, but none of the providers can be installed\n - cannot install both postfix-3:3.5.15-1.apnscp.x86_64 and postfix-2:3.5.8-2.el8.x86_64\n - cannot install both postfix-2:3.5.8-2.el8.x86_64 and postfix-3:3.5.15-1.apnscp.x86_64\n - cannot install the best update candidate for package postfix-2:3.5.8-2.el8.x86_64”, “rc”: 1, “results”: []}
2022-03-13 15:22:52,612 p=1648 u=root n=ansible | PLAY RECAP *********************************************************************
2022-03-13 15:22:52,612 p=1648 u=root n=ansible | localhost : ok=112 changed=17 unreachable=0 failed=1 skipped=60 rescued=0 ignored=0

rpm -qa | grep postfix | xargs rpm --nodeps -e 

Looks like your instance came with postfix + postfix-mysql pre-installed.

Run installation again after removing these packages,

cd /usr/local/apnscp/resources/playbooks
ansible-playbook bootstrap.yml

Thanks; it was from the OS7 > Alma upgrade.

Yup that’ll reapply installation, correcting any drifts. If anything isn’t reconciled after this, let me know and we’ll go from there.

OK, from a n00b perspective I am lost.

I am now getting:

TASK [system/pam : Edit /home/virtual/FILESYSTEMTEMPLATE system-auth] ******************************************************************************************************************************
fatal: [localhost]: FAILED! => changed=false
msg: Destination /home/virtual/FILESYSTEMTEMPLATE/siteinfo/etc/pam.d/system-auth does not exist !
rc: 257

PLAY RECAP *****************************************************************************************************************************************************************************************
localhost : ok=1012 changed=3 unreachable=0 failed=1 skipped=527 rescued=0 ignored=0

but when I run grep -m1 failed=1 -B20 /root/apnscp-bootstrapper.log

I get the same output from my first post.

I think you have a borked install overall. Perhaps reinstalling pam package would fix the issue (should relink dirs and whatsoever), but I’d rather fully reinstall the OS itself if it’s not too late…

OK, did a fresh Cent OS8 > Alma install and I seen to be caught in a loop. grep -m1 failed=1 -B20 /root/apnscp-bootstrapper.log returns several hundred lines, last few are:

ons.lo Zend/zend_ini.lo Zend/zend_sort.lo Zend/zend_multibyte.lo Zend/zend_ts_hash.lo Zend/zend_stream.lo Zend/zend_iterators.lo Zend/zend_interfaces.lo Zend/zend_exceptions.lo Zend/zend_strtod.lo Zend/zend_gc.lo Zend/zend_closures.lo Zend/zend_weakrefs.lo Zend/zend_float.lo Zend/zend_string.lo Zend/zend_signal.lo Zend/zend_generators.lo Zend/zend_virtual_cwd.lo Zend/zend_ast.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_default_classes.lo Zend/zend_inheritance.lo Zend/zend_smart_str.lo Zend/zend_cpuinfo.lo Zend/zend_execute.lo sapi/apache2handler/mod_php7.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo main/internal_functions.lo -lcrypt -lc-client -ltidy -lresolv -lcrypt -laspell -lpspell -lpq -lpq -lrt -lldap -llber -lstdc++ -lcrypt -lpam -lgmp -ldb-5.3 -lgdbm -lbz2 -lrt -lm -ldl -lsystemd -lpthread -lxml2 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -lsqlite3 -lz -lcurl -lxml2 -lssl -lcrypto -lz -lpng16 -lz -lwebp -ljpeg -lfreetype -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -licuio -licui18n -licuuc -licudata -lonig -lsqlite3 -lxml2 -lxml2 -lsodium -lcrypt -lxml2 -lxml2 -lxml2 -lxml2 -lxslt -lm -lxml2 -lexslt -lxslt -lm -lgcrypt -ldl -lgpg-error -lxml2 -lzip -lz -lssl -lcrypto -lcrypt -o libphp7.la"]}
2022-03-14 02:53:40,559 p=5005 u=root n=ansible | PLAY RECAP *********************************************************************
2022-03-14 02:53:40,560 p=5005 u=root n=ansible | localhost : ok=228 changed=2 unreachable=0 failed=1 skipped=140 rescued=0 ignored=0

Obviously the log is totally garbage, doesn’t really help identifying the issue. Could you provide a more meaningful extract?

Also, it would be nice knowing what provider or what VM specs you have…

Would need to see the full line (or preceding lines). Based on similar situations you’re most likely OOM on a 1 GB server or / partition is filled, verify with df.

Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1992148 0 1992148 0% /dev
tmpfs 2011176 0 2011176 0% /dev/shm
tmpfs 2011176 17000 1994176 1% /run
tmpfs 2011176 0 2011176 0% /sys/fs/cgroup
/dev/mapper/cl_uniquerobust-root 206972928 7972508 199000420 4% /
tmpfs 956416 0 956416 0% /tmp
/dev/sda1 1038336 318020 720316 31% /boot
tmpfs 402232 0 402232 0% /run/user/990
tmpfs 402232 0 402232 0% /run/user/0

the results scroll off of the window and too big to post, suggested command?

This should work. First filter out the last 1500 lines from the most recent failure, then send it as an attachment to my email.

grep -b1499 failed=1 /root/apnscp-bootstrapper.log  | tail -n 1500 > /tmp/log.txt
mail -s "Log" -a /tmp/log.txt matt@apisnetworks.com < /dev/null

Confirm the email was dispatched in /var/log/maillog.

tail /var/log/maillog
Mar 14 23:44:45 localhost postfix/postdrop[3262619]: warning: unable to look up public/pickup: No such file or directory

cd /usr/local/apnscp/resources/playbooks
ansible-playbook bootstrap.yml --tags=mail/configure-postfix

Give that a go first otherwise rsync the log somewhere else and PM me the URL.

https://file.io/J7nybiLhV7fD

4753128-2022-03-14 03:30:41,968 p=420979 u=root n=ansible | fatal: [localhost]: FAILED! => {“changed”: false, “cmd”: “/bin/gmake --jobs=1”, “msg”: “libtool: link: `ext/exif/exif.lo’ is not a valid libtool object\ngmake: *** [Makefile:170: libphp7.la] Error 1”, “rc”: 2, “stderr”: "libtool: link: …

cd /usr/local/apnscp/build/php/php-7.4.28
make clean
make 2>&1 | tee /tmp/log.txt

If it fails to compile successfully send me log.txt. I’m unable to reproduce this on a fresh install with PHP 7.4/Alma. It may have to do with your image if postfix-mysql was present at provisioning.

There is no php-7.4.28 directory, only php.config

Also, just to clarify; the postfix-mysql issue was from the first install attempt (cent OS7 upgrade to Alma), at the suggestion of anatoli I scrapped the install when a pam error came up and started again.

This is now a second install from Cent OS8 upgrade to Alma, no postfix-mysql error.

Directory would be /var/cache/httpd/php-7.4.28 then. Looked like from the build log it was building panel PHP, not the server PHP. Same process with make clean + tee.