Error Note

[dnf/yum] downgrade가 막힐 때 (--allowerasing)

2025-10-19T17:04:30+09:00

dnf 또는 yum으로 한 단계씩 downgrade로 판을 낮추려다 보니 다음과 같은 오류를 만났다.

# sudo dnf downgrade openssl-libs
Last metadata expiration check: 0:04:36 ago on Sun 19 Oct 2025 11:46:26 AM KST.
Error:
Problem: problem with installed package openssl-fips-provider-1:3.5.1-2.el9.x86_64
- package openssl-fips-provider-1:3.5.1-2.el9.x86_64 from @System requires openssl-libs(x86-64) = 1:3.5.1-2.el9, but none of the providers can be installed
- package openssl-fips-provider-1:3.5.1-2.el9.x86_64 from baseos requires openssl-libs(x86-64) = 1:3.5.1-2.el9, but none of the providers can be installed
- package openssl-fips-provider-1:3.5.1-3.el9.x86_64 from baseos requires openssl-libs(x86-64) = 1:3.5.1-3.el9, but none of the providers can be installed
- package openssl-fips-provider-1:3.5.1-5.el9.x86_64 from baseos requires openssl-libs(x86-64) = 1:3.5.1-5.el9, but none of the providers can be installed
- cannot install both openssl-libs-1:3.5.1-1.el9.x86_64 from baseos and openssl-libs-1:3.5.1-2.el9.x86_64 from @System
- cannot install both openssl-libs-1:3.5.1-2.el9.x86_64 from baseos and openssl-libs-1:3.5.1-1.el9.x86_64 from baseos
- cannot install both openssl-libs-1:3.5.1-3.el9.x86_64 from baseos and openssl-libs-1:3.5.1-1.el9.x86_64 from baseos
- cannot install both openssl-libs-1:3.5.1-5.el9.x86_64 from baseos and openssl-libs-1:3.5.1-1.el9.x86_64 from baseos
- cannot install the best candidate for the job
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

--allowerasing을 붙이면 아래처럼 downgrade를 더 이어갈 수 있다.

# sudo dnf downgrade openssl-libs --allowerasing
Last metadata expiration check: 0:07:15 ago on Sun 19 Oct 2025 11:46:26 AM KST.
Dependencies resolved.
========================================================================================
Package Architecture Version Repository Size
========================================================================================
Downgrading:
openssl x86_64 1:3.5.0-4.el9 baseos 1.5 M
openssl-libs x86_64 1:3.5.0-4.el9 baseos 2.7 M

Transaction Summary
========================================================================================
Downgrade 2 Packages

Total download size: 4.1 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): openssl-3.5.0-4.el9.x86_64.rpm 1.4 MB/s | 1.5 MB 00:01
(2/2): openssl-libs-3.5.0-4.el9.x86_64.rpm 2.0 MB/s | 2.7 MB 00:01
----------------------------------------------------------------------------------------
Total 2.1 MB/s | 4.1 MB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Downgrading : openssl-libs-1:3.5.0-4.el9.x86_64 1/4
Downgrading : openssl-1:3.5.0-4.el9.x86_64 2/4
Cleanup : openssl-1:3.5.1-1.el9.x86_64 3/4
Cleanup : openssl-libs-1:3.5.1-1.el9.x86_64 4/4
Running scriptlet: openssl-libs-1:3.5.1-1.el9.x86_64 4/4
Verifying : openssl-1:3.5.0-4.el9.x86_64 1/4
Verifying : openssl-1:3.5.1-1.el9.x86_64 2/4
Verifying : openssl-libs-1:3.5.0-4.el9.x86_64 3/4
Verifying : openssl-libs-1:3.5.1-1.el9.x86_64 4/4

Downgraded:
openssl-1:3.5.0-4.el9.x86_64 openssl-libs-1:3.5.0-4.el9.x86_64

Complete!

[certbot/snapd] error: cannot list snaps: cannot communicate with server

2025-06-09T23:45:58+09:00

snapd.service가 멈추어 있을 때 이런 오류가 나올 수 있다.

# snap list
error: cannot list snaps: cannot communicate with server: Get "http://localhost/v2/snaps": dial unix /run/snapd.socket: connect: no such file or directory

snapd를 통하여 letsencrypt를 쓰고 있을 때에도 오류가 나올 수 있다.

# certbot
cannot snap-exec: cannot exec "/var/lib/snapd/snap/certbot/4482/bin/python3": no such file or directory

이런 때에는 snapd.service를 시작해 준다.

# systemctl start snapd.service
# snap list
Name                 Version   Rev    Tracking       Publisher     Notes
certbot              3.3.0     4482   latest/stable  certbot-eff✓  classic
certbot-dns-rfc2136  3.3.0     4066   latest/stable  certbot-eff✓  -
core20               20250213  2501   latest/stable  canonical✓    base
core24               20241217  739    latest/stable  canonical✓    base,disabled
snapd                2.67.1    23771  latest/stable  canonical✓    snapd

아래처럼 snapd.socket만 재시작하면 아래와 같은 오류가 나기도 하는데, 그런 때에는 위처럼 snapd.service를 띄우거나 "snap refresh"로 구성 요소를 판올림하면 문제가 풀리기도 한다.

# snap list
error: cannot list snaps: cannot communicate with server: Get "http://localhost/v2/snaps": dial unix /run/snapd.socket: connect: connection refused

# snap refresh
certbot-dns-rfc2136 4.0.0 from Certbot Project (certbot-eff✓) refreshed

[named] Failed to start Berkeley Internet Name Domain (DNS)

2025-05-02T18:21:18+09:00

# systemctl start named-chroot
Job for named-chroot.service failed because the control process exited with error code.
See "systemctl status named-chroot.service" and "journalctl -xeu named-chroot.service" for details.

named-chroot 서비스가 문제가 있어서 시작되지 못했음을 알리고 있다.

아래는 "systemctl status named-chroot.service" 또는 "journalctl -xeu named-chroot.service"로 본 로그 내용이다.

░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://wiki.almalinux.org/Help-and-Support
░░
░░ An ExecStartPre= process belonging to unit named-chroot.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
May 02 09:00:40 KR-D1 systemd[1]: named-chroot.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://wiki.almalinux.org/Help-and-Support
░░
░░ The unit named-chroot.service has entered the 'failed' state with result 'exit-code'.
May 02 09:00:40 KR-D1 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
░░ Subject: A start job for unit named-chroot.service has failed
░░ Defined-By: systemd
░░ Support: https://wiki.almalinux.org/Help-and-Support
░░
░░ A start job for unit named-chroot.service has finished with a failure.
░░
░░ The job identifier is 1116 and the job result is failed.

"Failed to start Berkeley Internet Name Domain (DNS)."는 /var/named의 zone 파일이 없거나 문제가 있으면 나타날 수 있다.

???.zone 파일을 ???.zone.a라고 이름을 바꾸어도 이 오류가 나올 수 있다.

[PHP] Deprecated: Creation of dynamic property...

2024-08-14T10:57:23+09:00

PHP 8.1까지는 아래처럼 미리 선언하지 않은 클래스의 동적 요소를 쓸 수 있었다.

class Class_name {
	public function __construct() {
		$this->id = null;
	}
}

하지만 PHP 8.2에서는 위와 같이 미리 선언하지 않은 동적 요소(dynamic property)로서 클래스의 메소드에 쓰인 변수가 있으면, 아래처럼 비권장 경고문이 나온다.

PHP Deprecated: Creation of dynamic property Class_name::$var is deprecated in .../???.php on line 3

PHP 8.2에서는 경고문만 나오고 있지만, 그 뒤에 나오는 판에서는 클래스의 멤버 변수로 미리 선언하지 않은 동적 요소로 들어간 변수가 있으면 작동하지 않을 수도 있다.

아래처럼 클래스 내부에 멤버 변수($id)를 미리 선언하면, PHP 8.2 이후에 나올 수 있는 경고문이나 오류를 피할 수 있다.

class Class_name {
	public $id;
	public function __construct() {
		$this->id = null;
	}
}

[phpMyAdmin] mismatch between HTTPS indicated on the server and client

2024-08-13T17:18:28+09:00

아래는 로그인 정보를 넣는 항목이 나오지 않고 제목만 나온 phpMyAdmin의 모습이다.

로그인 항목이 나오지 않은 phpMyAdmin

디버그 도구로 숨김 처리된 HTML 항목의 CSS 내용(display: none;)을 없애면 아래와 같은 화면을 볼 수 있다.

There is a mismatch between HTTPS indicated on the server and client. This can lead to a non working phpMyAdmin or a security risk. Please fix your server configuration to indicate HTTPS properly.

phpMyAdmin에는 이상이 없으나 서버와 클라이언트의 HTTPS 인증서 정보가 서로 맞지 않을 때에 위와 같은 화면이 나올 수 있다.

서로 다른 웹 서버에서 주 도메인과 서브 도메인을 이용할 때에 쿠키나 HTTPS 인증서의 정보가 서로 다르면 이런 문제가 생길 수도 있는 것 같은데, 모두 같은 HTTPS 인증서를 쓰는 것 말고는 확실한 해결책을 찾지 못했다. 이 문제가 있더라도 숨은 화면을 보이게 해서 사용자명과 암호를 넣으면 phpMyAdmin은 작동한다.

Inhibitor: Upgrade requires links in root directory to be relative

2024-08-07T13:03:12+09:00

아래는 CentOS 7에서 AlmaLinux 8, 9으로 판을 올리는 과정에서 "leapp preupgrade" 명령을 넣었을 때에 나타날 수 있는 내용이다. (ELevating CentOS 7 to AlmaLinux 9 | AlmaLinux Wiki)

============================================================
                     UPGRADE INHIBITED
============================================================

Upgrade has been inhibited due to the following problems:
    1. Inhibitor: Upgrade requires links in root directory to be relative
    2. Inhibitor: Missing required answers in the answer file
Consult the pre-upgrade report for details and possible remediation.

/var/log/leapp/leapp-report.txt 파일에서 자세한 내용을 볼 수 있다.

Risk Factor: high (inhibitor)
Title: Upgrade requires links in root directory to be relative
Summary: After rebooting, parts of the upgrade process can fail if symbolic links in / point to absolute paths.
Please change these links to relative ones.
Remediation: [command] sh -c ln -snf var/lib/snapd/snap /snap
Key: 3d895ad37ceaf4157864d439edb6bd75562061fa
----------------------------------------
Risk Factor: high (inhibitor)
Title: Missing required answers in the answer file
Summary: One or more sections in answerfile are missing user choices: remove_pam_pkcs11_module_check.confirm
For more information consult https://leapp.readthedocs.io/en/latest/dialogs.html
Remediation: [hint] Please register user choices with leapp answer cli command or by manually editing the answerfile.
[command] leapp answer --section remove_pam_pkcs11_module_check.confirm=True
Key: d35f6c6b1b1fa6924ef442e3670d90fa92f0d54b
----------------------------------------

루트 디렉토리(뿌리 자료방)의 심볼릭 링크 문제는 위의 경우에는 "ln -snf /var/lib/snapd/snap /snap"로 풀 수 있다.

두번째 문제는 "leapp answer --section remove_pam_pkcs11_module_check.confirm=True" 명령을 넣거나 /var/log/leapp/answerfile 파일을 고쳐서 풀 수 있다.

[nginx] nginx.conf의 if 문 안에 넣을 수 없는 명령들 - listen, http2, ssl_protocols, …

2024-08-10T02:53:42+09:00

아래는 "nginx -t"로 nginx 설정 파일(nginx.conf)을 검사한 내용이다.

# nginx -t
nginx: [emerg] "listen" directive is not allowed here in /etc/nginx/conf.d/???.conf:62
nginx: configuration file /etc/nginx/nginx.conf test failed

여기에서 listen 명령 때문에 오류가 난 까닭은 아래처럼 listen을 if 문 안에 넣었기 때문이다.

http {
	server {
		server_name www.domain-name.com domain-name.com
		if ($host != "www.domain-name.com") {
			listen 443 quic;
		}
	...
	}
}

listen을 if 문 밖으로 빼내면 이 오류를 없앨 수 있다.

listen 말고도 if 문 안에 넣을 수 없는 명령은 http2, ssl_protocols를 비롯하여 여러 가지가 있다.

# nginx -t
nginx: [emerg] "ssl_protocols" directive is not allowed here in /etc/nginx/conf.d/???.conf:33
nginx: configuration file /etc/nginx/nginx.conf test failed

[memcached] Cannot set item size limit higher than 1/2 of memory max.

2024-08-06T11:23:30+09:00

memcached의 메모리를 너무 적게 설정하면 아래처럼 "Cannot set item size limit higher than 1/2 of memory max."라고 나오며 memcached가 실행되지 않을 수 있다.

● memcached.service - memcached daemon
     Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sun 2024-08-04 17:53:12 KST; 24s ago
   Duration: 21ms
    Process: 4037 ExecStart=/usr/bin/memcached -p ${PORT} -u ${USER} -m ${CACHESIZE} -c ${MAXCONN} $OPTIONS (code=exited, status=64)
   Main PID: 4037 (code=exited, status=64)
        CPU: 13ms

Aug 04 17:53:12 server_name systemd[1]: Started memcached daemon.
Aug 04 17:53:12 server_name memcached[4037]: Cannot set item size limit higher than 1/2 of memory max.
Aug 04 17:53:12 server_name systemd[1]: memcached.service: Main process exited, code=exited, status=64/USAGE
Aug 04 17:53:12 server_name systemd[1]: memcached.service: Failed with result 'exit-code'.

memcached 설정 파일(/etc/sysconfig/memcached)의 내용은 대략 이러한 식이다.

PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="1"
OPTIONS="-l 127.0.0.1,::1"

CACHESIZE 값을 2 이상으로 늘려 준다. 아래처럼 하면 캐시 크기가 32MB가 된다.
(초기 설정 파일의 CACHESIZE 기본값은 64)

CACHESIZE="32"

아래처럼 OPTIONS 값으로 캐시 크기를 바꾸는 방법도 있다.

OPTIONS="-m 32 -l 127.0.0.1,::1"

[MariaDB] A manual upgrade is required

2024-07-28T11:59:55+09:00

아래는 CentOS 7에서 예전에 쓰던 MariaDB(10.11.8)를 깨끗이 지우지 않고 dnf로 11.4.2판으로 곧바로 판올림하려다가 막힌 모습이다.

[user@host ~]# sudo dnf update
MariaDB Tools                                          0.0  B/s |   0  B     00:00
MariaDB Server                                         251 kB/s | 384 kB     00:01
MariaDB MaxScale                                       0.0  B/s |   0  B     00:00
Dependencies resolved.
=======================================================================================
 Package                   Arch       Version                   Repository        Size
=======================================================================================
Upgrading:
 MariaDB-client            x86_64     11.4.2-1.el7.centos       mariadb-main      17 M
 MariaDB-common            x86_64     11.4.2-1.el7.centos       mariadb-main      82 k
 MariaDB-compat            x86_64     11.4.2-1.el7.centos       mariadb-main     2.2 M
 MariaDB-server            x86_64     11.4.2-1.el7.centos       mariadb-main      27 M
Installing dependencies:
 MariaDB-client-compat     noarch     11.4.2-1.el7.centos       mariadb-main     7.9 k
 MariaDB-server-compat     noarch     11.4.2-1.el7.centos       mariadb-main     5.5 k
Transaction Summary
=======================================================================================
Install  2 Packages
Upgrade  4 Packages
Total download size: 46 M
Is this ok [y/N]: y
Downloading Packages:
(1/6): MariaDB-client-compat-11.4.2-1.el7.centos.noarc 9.7 kB/s | 7.9 kB     00:00
(2/6): MariaDB-server-compat-11.4.2-1.el7.centos.noarc 5.0 kB/s | 5.5 kB     00:01
(3/6): MariaDB-common-11.4.2-1.el7.centos.x86_64.rpm    94 kB/s |  82 kB     00:00
(4/6): MariaDB-client-11.4.2-1.el7.centos.x86_64.rpm   7.3 MB/s |  17 MB     00:02
(5/6): MariaDB-compat-11.4.2-1.el7.centos.x86_64.rpm   1.4 MB/s | 2.2 MB     00:01
(6/6): MariaDB-server-11.4.2-1.el7.centos.x86_64.rpm   7.7 MB/s |  27 MB     00:03
---------------------------------------------------------------------------------------
Total                                                  8.8 MB/s |  46 MB     00:05
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                               1/1
  Running scriptlet: MariaDB-compat-11.4.2-1.el7.centos.x86_64                    1/10
  Upgrading        : MariaDB-compat-11.4.2-1.el7.centos.x86_64                    1/10
  Running scriptlet: MariaDB-compat-11.4.2-1.el7.centos.x86_64                    1/10
  Running scriptlet: MariaDB-common-11.4.2-1.el7.centos.x86_64                    2/10
  Upgrading        : MariaDB-common-11.4.2-1.el7.centos.x86_64                    2/10
  Running scriptlet: MariaDB-common-11.4.2-1.el7.centos.x86_64                    2/10
  Running scriptlet: MariaDB-client-11.4.2-1.el7.centos.x86_64                    3/10
  Upgrading        : MariaDB-client-11.4.2-1.el7.centos.x86_64                    3/10
  Running scriptlet: MariaDB-client-11.4.2-1.el7.centos.x86_64                    3/10
  Running scriptlet: MariaDB-client-compat-11.4.2-1.el7.centos.noarch             4/10
  Installing       : MariaDB-client-compat-11.4.2-1.el7.centos.noarch             4/10
  Running scriptlet: MariaDB-client-compat-11.4.2-1.el7.centos.noarch             4/10
  Running scriptlet: MariaDB-server-compat-11.4.2-1.el7.centos.noarch             5/10
  Installing       : MariaDB-server-compat-11.4.2-1.el7.centos.noarch             5/10
  Running scriptlet: MariaDB-server-compat-11.4.2-1.el7.centos.noarch             5/10
  Running scriptlet: MariaDB-server-11.4.2-1.el7.centos.x86_64                    6/10
******************************************************************
A MySQL or MariaDB server package (MariaDB-server-10.11.8-1.el7.centos.x86_64) is installed.
Upgrading directly from MySQL 10 to MariaDB 11 may not
be safe in all cases.  A manual dump and restore using mysqldump is
recommended.  It is important to review the MariaDB manual's Upgrading
section for version-specific incompatibilities.
A manual upgrade is required.
- Ensure that you have a complete, working backup of your data and my.cnf
  files
- Shut down the MySQL server cleanly
- Remove the existing MySQL packages.  Usually this command will
  list the packages you should remove:
  rpm -qa | grep -i '^mysql-'
  You may choose to use 'rpm --nodeps -ev ' to remove
  the package which contains the mysqlclient shared library.  The
  library will be reinstalled by the MariaDB-shared package.
- Install the new MariaDB packages supplied by MariaDB Foundation
- Ensure that the MariaDB server is started
- Run the 'mysql_upgrade' program
This is a brief description of the upgrade process.  Important details
can be found in the MariaDB manual, in the Upgrading section.
******************************************************************
error: %pre(MariaDB-server-11.4.2-1.el7.centos.x86_64) scriptlet failed, exit status 1
Error in PREIN scriptlet in rpm package MariaDB-server
  Running scriptlet: MariaDB-client-10.11.8-1.el7.centos.x86_64                   7/10
error: MariaDB-server-11.4.2-1.el7.centos.x86_64: install failed
error: MariaDB-server-10.11.8-1.el7.centos.x86_64: erase skipped
  Cleanup          : MariaDB-client-10.11.8-1.el7.centos.x86_64                   7/10
  Running scriptlet: MariaDB-client-10.11.8-1.el7.centos.x86_64                   7/10
  Running scriptlet: MariaDB-compat-10.11.8-1.el7.centos.x86_64                   8/10
  Cleanup          : MariaDB-compat-10.11.8-1.el7.centos.x86_64                   8/10
  Running scriptlet: MariaDB-compat-10.11.8-1.el7.centos.x86_64                   8/10
  Running scriptlet: MariaDB-common-10.11.8-1.el7.centos.x86_64                   9/10
  Cleanup          : MariaDB-common-10.11.8-1.el7.centos.x86_64                   9/10
  Running scriptlet: MariaDB-common-10.11.8-1.el7.centos.x86_64                   9/10
  Verifying        : MariaDB-client-compat-11.4.2-1.el7.centos.noarch             1/10
  Verifying        : MariaDB-server-compat-11.4.2-1.el7.centos.noarch             2/10
  Verifying        : MariaDB-client-11.4.2-1.el7.centos.x86_64                    3/10
  Verifying        : MariaDB-client-10.11.8-1.el7.centos.x86_64                   4/10
  Verifying        : MariaDB-common-11.4.2-1.el7.centos.x86_64                    5/10
  Verifying        : MariaDB-common-10.11.8-1.el7.centos.x86_64                   6/10
  Verifying        : MariaDB-compat-11.4.2-1.el7.centos.x86_64                    7/10
  Verifying        : MariaDB-compat-10.11.8-1.el7.centos.x86_64                   8/10
  Verifying        : MariaDB-server-11.4.2-1.el7.centos.x86_64                    9/10
  Verifying        : MariaDB-server-10.11.8-1.el7.centos.x86_64                  10/10
Upgraded:
  MariaDB-client-11.4.2-1.el7.centos.x86_64  MariaDB-common-11.4.2-1.el7.centos.x86_64
  MariaDB-compat-11.4.2-1.el7.centos.x86_64
Installed:
  MariaDB-client-compat-11.4.2-1.el7.centos.noarch
  MariaDB-server-compat-11.4.2-1.el7.centos.noarch
Failed:
  MariaDB-server-11.4.2-1.el7.centos.x86_64 MariaDB-server-10.11.8-1.el7.centos.x86_64
Error: Transaction failed

다른 요소들은 판올림하여 깔 수 있었지만, MariaDB-server-11.4.2-1는 깔지 못하고 실패했다.

mariadb가 제대로 깔리지 않은 상태였기 때문인지, 아래처럼 단순히 mysql_upgrade를 실행하는 것은 보람이 없었다.

[user@host ~]# sudo mysql_upgrade
Reading datadir from the MariaDB server failed. Got the following error when executing the 'mysql' command line client
ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it
FATAL ERROR: Upgrade failed

또한 아래처럼 dnf update를 실행하더라도 MariaDB-server-11.4.2-1이 깔리지 않는다.

[user@host ~]# sudo dnf update
Last metadata expiration check: 0:02:32 ago on Thu 20 Jun 2024 11:40:06 PM KST.
Dependencies resolved.
=======================================================================================
 Package              Arch         Version                    Repository          Size
=======================================================================================
Upgrading:
 MariaDB-server       x86_64       11.4.2-1.el7.centos        mariadb-main        27 M
Transaction Summary
=======================================================================================
Upgrade  1 Package
Total download size: 27 M
Is this ok [y/N]: y
Downloading Packages:
MariaDB-server-11.4.2-1.el7.centos.x86_64.rpm           11 MB/s |  27 MB     00:02
---------------------------------------------------------------------------------------
Total                                                   10 MB/s |  27 MB     00:02
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                               1/1
  Running scriptlet: MariaDB-server-11.4.2-1.el7.centos.x86_64                     1/2
******************************************************************
A MySQL or MariaDB server package (MariaDB-server-10.11.8-1.el7.centos.x86_64) is installed.
Upgrading directly from MySQL 10 to MariaDB 11 may not
be safe in all cases.  A manual dump and restore using mysqldump is
recommended.  It is important to review the MariaDB manual's Upgrading
section for version-specific incompatibilities.
A manual upgrade is required.
- Ensure that you have a complete, working backup of your data and my.cnf
  files
- Shut down the MySQL server cleanly
- Remove the existing MySQL packages.  Usually this command will
  list the packages you should remove:
  rpm -qa | grep -i '^mysql-'
  You may choose to use 'rpm --nodeps -ev ' to remove
  the package which contains the mysqlclient shared library.  The
  library will be reinstalled by the MariaDB-shared package.
- Install the new MariaDB packages supplied by MariaDB Foundation
- Ensure that the MariaDB server is started
- Run the 'mysql_upgrade' program
This is a brief description of the upgrade process.  Important details
can be found in the MariaDB manual, in the Upgrading section.
******************************************************************
error: %pre(MariaDB-server-11.4.2-1.el7.centos.x86_64) scriptlet failed, exit status 1
Error in PREIN scriptlet in rpm package MariaDB-server
  Verifying        : MariaDB-server-11.4.2-1.el7.centos.x86_64                     1/2
  Verifying        : MariaDB-server-10.11.8-1.el7.centos.x86_64                    2/2
Failed:
  MariaDB-server-11.4.2-1.el7.centos.x86_64 MariaDB-server-10.11.8-1.el7.centos.x86_64
Error: Transaction failed

dnf 로 MariaDB-server(10.11.8-1)를 지우는 것도 아래처럼 막히고 있다.

[user@host ~]# sudo dnf remove MariaDB-server
Dependencies resolved.
=======================================================================================
 Package             Arch        Version                      Repository          Size
=======================================================================================
Removing:
 MariaDB-server      x86_64      10.11.8-1.el7.centos         @mariadb-main      141 M
Transaction Summary
=======================================================================================
Remove  1 Package
Freed space: 141 M
Is this ok [y/N]: y
Running transaction check
Error: transaction check vs depsolve:
MariaDB-server >= 11.0.0 is needed by (installed) MariaDB-server-compat-11.4.2-1.el7.centos.noarch
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue.

rpm 명령으로 mariadb가 들어가는 깔린 꾸러미(패키지)들이 무엇인지 알아 본다.

[user@host ~]# sudo rpm -qa | grep -i "^mariadb"
MariaDB-compat-11.4.2-1.el7.centos.x86_64
MariaDB-client-compat-11.4.2-1.el7.centos.noarch
MariaDB-common-11.4.2-1.el7.centos.x86_64
MariaDB-server-compat-11.4.2-1.el7.centos.noarch
MariaDB-server-10.11.8-1.el7.centos.x86_64
MariaDB-client-11.4.2-1.el7.centos.x86_64

앞에서 dnf를 실행했을 때에 나온 설명을 참고하여, 아래처럼 rpm 명령으로 MariaDB-server-10.11.8-1.el7.centos.x86_64을 지운다.

[user@host ~]# sudo rpm --nodeps -ev MariaDB-server-10.11.8-1.el7.centos.x86_64
 Preparing packages...
 MariaDB-server-10.11.8-1.el7.centos.x86_64

이렇게 하면 MariaDB-server가 깔리지 않은 상태가 되므로, 아래처럼 MariaDB-server를 새로 깔 수 있다.

[user@host ~]# sudo dnf install MariaDB-server
Last metadata expiration check: 0:05:54 ago on Thu 20 Jun 2024 11:40:06 PM KST.
Dependencies resolved.
=======================================================================================
 Package              Arch         Version                    Repository          Size
=======================================================================================
Installing:
 MariaDB-server       x86_64       11.4.2-1.el7.centos        mariadb-main        27 M
Transaction Summary
=======================================================================================
Install  1 Package
Total download size: 27 M
Installed size: 137 M
Is this ok [y/N]: y
Downloading Packages:
MariaDB-server-11.4.2-1.el7.centos.x86_64.rpm          9.8 MB/s |  27 MB     00:02
---------------------------------------------------------------------------------------
Total                                                  9.8 MB/s |  27 MB     00:02
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                               1/1
  Running scriptlet: MariaDB-server-11.4.2-1.el7.centos.x86_64                     1/1
  Installing       : MariaDB-server-11.4.2-1.el7.centos.x86_64                     1/1
  Running scriptlet: MariaDB-server-11.4.2-1.el7.centos.x86_64                     1/1
  Verifying        : MariaDB-server-11.4.2-1.el7.centos.x86_64                     1/1
Installed:
  MariaDB-server-11.4.2-1.el7.centos.x86_64
Complete!

[memcached] Too many open files

2024-07-27T13:55:33+09:00

memcached의 설정 파일인 /etc/sysconfig/memcached에서 MAXCONN의 기본값은 아래와 같다.

MAXCONN="1024"

이 값을 너무 낮추면 아래처럼 오류가 뜰 수 있다.

# systemctl status memcached
× memcached.service - memcached daemon
     Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sat 2024-07-27 09:08:49 KST; 3s ago
   Duration: 32ms
    Process: 39005 ExecStart=/usr/bin/memcached -p ${PORT} -u ${USER} -m ${CACHESIZE} -c ${MAXCONN} $OPTIONS (code=exited, status=1/FAILURE)
   Main PID: 39005 (code=exited, status=1/FAILURE)
        CPU: 15ms

Jul 27 09:08:49 server_name systemd[1]: Started memcached daemon.
Jul 27 09:08:49 server_name memcached[39005]: [warn] evutil_make_internal_pipe_: pipe: Too many open files
Jul 27 09:08:49 server_name memcached[39005]: [err] evsig_init_: socketpair: Too many open files
Jul 27 09:08:49 server_name systemd[1]: memcached.service: Main process exited, code=exited, status=1/FAILURE
Jul 27 09:08:49 server_name systemd[1]: memcached.service: Failed with result 'exit-code'.

# systemctl status memcached
× memcached.service - memcached daemon
     Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sat 2024-07-27 09:09:33 KST; 1s ago
   Duration: 17ms
    Process: 39032 ExecStart=/usr/bin/memcached -p ${PORT} -u ${USER} -m ${CACHESIZE} -c ${MAXCONN} $OPTIONS (code=exited, status=71)
   Main PID: 39032 (code=exited, status=71)
        CPU: 16ms

Jul 27 09:09:33 server_name systemd[1]: Started memcached daemon.
Jul 27 09:09:33 server_name memcached[39032]: socket(): Too many open files
Jul 27 09:09:33 server_name memcached[39032]: failed to listen on UNIX socket: /.../memcached.sock: Too many open files
Jul 27 09:09:33 server_name systemd[1]: memcached.service: Main process exited, code=exited, status=71/OSERR
Jul 27 09:09:33 server_name systemd[1]: memcached.service: Failed with result 'exit-code'.

MAXCONN 값이 기본적으로 열어야 하는 파일의 수만큼은 되어야 하는 것 같다. 때에 따라 다르겠지만, 시험해 보았을 때는 MAXCONN 값이 27보다 작게 하면 위와 같은 오류가 떴다.

[PHP] Non-static method cannot be called statically

2024-07-11T23:47:03+09:00

class Class_Name {
    function Method_name($param1 = null, $param2 = null) {
       ...
    }
}

Class_name::Method_name($a, $b);

PHP 8 이상에서 위처럼 non-static 메소드를 static 메소드처럼 다루면 아래와 같은 오류가 날 수 있다.

PHP Fatal error: Uncaught Error: Non-static method Class_name::Method_name() cannot be called statically in /.../.../???.php:115

다음 두 가지 방법으로 이 오류를 없앨 수 있다.

(1) static 메소드로 바꾸기

클래스의 메소드를 non-static에서 static 메소드로 바꾸면 메소드를 이용하는 곳의 부호글은 고치지 않아도 된다.

static class Class_Name {
    static function Method_name($param1 = null, $param2 = null) {
       ...
    }
}

Class_name::Method_name($a, $b);

(2) non-static 메소드에 맞는 접근 방식으로 바꾸기

메소드를 이용하는 곳의 접근 방식을 non-static 메소드에 맞게 고친다.

static class Class_Name {
    static function Method_name($param1 = null, $param2 = null) {
       ...
    }
}

(new Class_name)->Method_name($a, $b);

클래스의 멤버 함수(메소드) 하나를 한 번만 쏙 뽑아 쓰는 때에는 (2)보다 (1)가 간결하기는 하다.

[nginx] Can't open PID file /var/run/nginx.pid (yet?) after start: No such file or directory

2024-07-10T01:53:53+09:00

-- Unit nginx.service has begun starting up.
Jan 15 01:40:19 test_server systemd[1]: Can't open PID file /var/run/nginx.pid (yet?) after start: No such file or directory
Jan 15 01:40:19 test_server systemd[1]: Started nginx - high performance web server.
-- Subject: Unit nginx.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nginx.service has finished starting up.
--
-- The start-up result is done.
Jan 15 01:40:19 test_server polkitd[588]: Unregistered Authentication Agent for unix-process:21917:95474130 (system bus name :1.15088, object path /org/freedesktop/
~

PID 파일이 만들어지는 찰나의 시간차 때문에 생긴 오류가 아닌가 싶다.

다음 글에서는 nginx.service 파일의 ExecStartPost 값에 sleep 명령을 넣는 방법이 소개되어 있다.

nginx.service: Can't open PID file /run/nginx.pid (yet?) after start: Operation not permitted 이슈 해결 방안 — 문제해결집 (https://god-logger.tistory.com/81)

[PHP] count(): Argument #1 ($value) must be of type Countable|array, null given ...

2024-07-09T18:42:04+09:00

PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /…/…

배열이나 객체의 원소 수를 셀 때 count 함수를 쓰곤 한다. PHP 8 이상에서 셀 수 있는 객체나 변수를 count 함수로 세려고 하면 위와 같은 오류가 나올 수 있다. PHP 7까지는 없던 제한이다.

$a = count($b);

$b가 null 값이거나 셀 수 없는 것이면 오류가 날 수 있다. 아래처럼 바꾸어 주면 PHP 7에서와 같은 결과를 얻을 수 있다.

$a = is_countable($b) ? count($b) : 0;

[PHP/SElinux] opcache JIT 기능을 켰을 때의 '502 Bad Gateway'

2024-07-08T14:44:20+09:00

PHP에 들어간 opcache의 JIT 기능을 켜면 '502 Bad Gateway' 오류가 떴는데, Selinux를 끄면 오류가 나지 않으므로 SELinux에 원인이 있었다.

Centos Stream 9로 돌리는 웹 서버에서는 Selinux를 끄고 php-fpm을 다시 실행하면 502 오류가 다시 뜨지 않았지만, 알마리눅스(AlmaLinux) 9.4로 돌리는 웹 서버는 Selinux를 끄면 502 오류가 다시 나왔다.

audit2why와 audit2allow로 audit 로그(audit.log)와 해결 정보를 살폈다.

# audit2why < /var/log/audit/audit.log
...
type=AVC msg=audit(1720401420.710:1162): avc:  denied  { execmem } for  pid=2633 comm="php-fpm" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process permissive=1

        Was caused by:
        The boolean httpd_execmem was set incorrectly.
        Description:
        Allow httpd to execmem

        Allow access by executing:
        # setsebool -P httpd_execmem 1
...

# audit2allow -a

#============= httpd_t ==============

#!!!! This avc can be allowed using the boolean 'httpd_unified'
allow httpd_t httpd_user_content_t:dir create;

#!!!! This avc can be allowed using the boolean 'httpd_execmem'
allow httpd_t self:process execmem;
allow httpd_t var_run_t:file { read write };
...

httpd_execmem에 관한 권한이 원인이었던 것 같다. [SELinux] recv() failed (104: Connection reset by peer) while reading response header from upstream...에서 이야기한 nginx-passenger.te 파일에 아래 내용을 더 넣어 주었다.

module nginx-passenger 1.0;
require {
...
#============= httpd_t ==============
...
allow httpd_t self:process execmem;
allow httpd_t var_run_t:file { read write };
...

그리고 보안 규칙을 다시 적용시킨다.

# checkmodule -M -m -o nginx-passenger.mod nginx-passenger.te
checkmodule:  loading policy configuration from nginx-passenger.te
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 19) to nginx-passenger.mod

# semodule_package -o nginx-passenger.pp -m nginx-passenger.mod
# semodule -i nginx-passenger.pp

보안 규칙을 다시 적용한 뒤에는 opcache의 JIT 기능을 켜도 502 bad gatewate가 뜨지 않았다.

보안 규칙을 적용하지 않고, 위에 나온 것처럼 'setsebool -P httpd_execmem 1'를 실행하는 방법을 쓸 수도 있을 것이다.

※ 참고

Nginx PHP-FPM SELinux 정책 추가 내역 | Hoing

[curl] SSL certificate problem: unable to get local issuer certificate

2024-07-11T23:45:33+09:00

신뢰할 수 있는 인증 기관으로 등록되지 않은 SSL/TLS 인증서를 쓰는 곳을 curl로 접근하먼 이런 오류를 겪을 수 있다. 구글(google) 인증서를 쓰는 곳에서 그럴 수 있다.

# curl https://www...
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

'-k'(또는 '--insecure')와 '-L google.com'을 붙여서 인증서 검증을 하지 않게 할 수 있다.

# curl -k -L google.com https://www..

# curl --insecure -L google.com https://www...

신뢰할 수 있는 인증서 목록에 넣으려면

# curl -v https://google.com
*   Trying 2607:f8b0:4009:81b::200e:443...
* Connected to google.com (2607:f8b0:4009:81b::200e) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.google.com
*  start date: Dec 11 08:03:31 2023 GMT
*  expire date: Mar  4 08:03:30 2024 GMT
*  subjectAltName: host "google.com" matched cert's "google.com"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* Using Stream ID: 1 (easy handle 0x55bacf75c540)
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET / HTTP/2
> Host: google.com
> user-agent: curl/7.76.1
> accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
< HTTP/2 301
< location: https://www.google.com/
< content-type: text/html; charset=UTF-8
< content-security-policy-report-only: object-src 'none';base-uri 'self';script-src 'nonce-A71EtqVLshhMqBU3l6geSg' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
< date: Sat, 13 Jan 2024 20:31:41 GMT
< expires: Mon, 12 Feb 2024 20:31:41 GMT
< cache-control: public, max-age=2592000
< server: gws
< content-length: 220
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
* TLSv1.2 (IN), TLS header, Unknown (23):
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
* TLSv1.2 (IN), TLS header, Unknown (23):
* Connection #0 to host google.com left intact

위에 보이는 /etc/pki/tls/certs/ca-bundle.crt 파일에 신뢰할 수 있는 인증서 목록이 들어가므로, 이 목록에 문제가 되는 인증서 정보를 끼워 넣으면 된다. (아래 글들에 자세한 방법이 나옴)

[curl] (60) server certificate verification failed. 문제 해결 방법
(https://frankler.tistory.com/43)
https 연결시 서버의 SSL 인증서 추출하기 (curl 또는 web browser 사용)
(https://www.lesstif.com/gitbook/https-ssl-curl-web-browser-16744456.html)

※ 참고한 글

curl 에 신뢰하는 인증기관 인증서(CA Cert) 추가하기
(https://www.lesstif.com/gitbook/curl-ca-cert-15892500.html)