如何在 CentOS 7 解決 glibc 的 yum 套件相依性問題
這週凍仁接到一個需要幫 CentOS 7 部署 OpenLDAP client 的任務。過程中，總是有一兩台 server 會遇到 glibc 相依性問題，並為此煩惱。如果是所有的 server 都有同樣的問題還好解決，最麻煩的就是遇上這種時好時壞的情形。
上網查了一下資料，發現前人在 2016 年就遇上同樣的問題，其解法也很簡單，只需先降級 glibc 即可。
1. 降級 glibc 的相關套件。
2. 接著重新安裝 nss-pam-ldapd 就不會遇到相依性問題了。
現在回過頭來看，其實在錯誤訊息的第 3 行的 glibc-common = 2.17-157.el7_3.1 就提到需安裝 2.17-157.el7_3.1 版本的 glibc-common，可出問題的 server 上雖已裝了 2.17-157.el7_3.2 但在降級的過程中失敗。
這問題會發生在已安裝某些服務後，才改用內部 Yum mirror repo 的 server 上。而這個結論是在嘗試升級已降級 glibc 和切換內部 Yum mirror repo 的 server，卻無任何變更後得知。
題外話，現在的凍仁很幸運地得到前人分享的知識，並擁有 Ansible 和 Vagrant 兩大利器，才能在不到一週內解決環境不一的問題。甚至還在最後發現 Ansible Playbooks 漏掉了要安裝 authconfig 這個必要套件呢！
[ jonny@centos7 ~ ]
$ sudo yum install nss-pam-ldapd [Enter]
... 1 --> Finished Dependency Resolution 2 Error: Package: glibc-2.17-157.el7_3.1.i686 (internel-upadte) 3 Requires: glibc-common = 2.17-157.el7_3.1 4 Installed: glibc-common-2.17-157.el7_3.2.x86_64 (@updates) 5 glibc-common = 2.17-157.el7_3.2 5 Available: glibc-common-2.17-105.el7.x86_64 (internel-base) 6 glibc-common = 2.17-105.el7 7 Available: glibc-common-2.17-106.el7_2.1.x86_64 (internel-upadte) 8 glibc-common = 2.17-106.el7_2.1 9 Available: glibc-common-2.17-106.el7_2.4.x86_64 (internel-upadte) 10 glibc-common = 2.17-106.el7_2.4 11 Available: glibc-common-2.17-106.el7_2.6.x86_64 (internel-upadte) 12 glibc-common = 2.17-106.el7_2.6 13 Available: glibc-common-2.17-106.el7_2.8.x86_64 (internel-upadte) 14 glibc-common = 2.17-106.el7_2.8 15 Available: glibc-common-2.17-157.el7.x86_64 (internel-base) 16 glibc-common = 2.17-157.el7 17 Available: glibc-common-2.17-157.el7_3.1.x86_64 (internel-upadte) 18 glibc-common = 2.17-157.el7_3.1 19 You could try using --skip-broken to work around the problem 20 You could try running: rpm -Va --nofiles --nodigest
▲ 安裝 nss-pam-ldapd 出現了 glibc 的套件相依性問題。
上網查了一下資料，發現前人在 2016 年就遇上同樣的問題，其解法也很簡單，只需先降級 glibc 即可。
1. 降級 glibc 的相關套件。
[ jonny@centos7 ~ ]
$ sudo yum downgrade glibc glibc-common glibc-devel glibc-headers [Enter]
2. 接著重新安裝 nss-pam-ldapd 就不會遇到相依性問題了。
$ sudo yum install nss-pam-ldapd [Enter]
現在回過頭來看，其實在錯誤訊息的第 3 行的 glibc-common = 2.17-157.el7_3.1 就提到需安裝 2.17-157.el7_3.1 版本的 glibc-common，可出問題的 server 上雖已裝了 2.17-157.el7_3.2 但在降級的過程中失敗。
這問題會發生在已安裝某些服務後，才改用內部 Yum mirror repo 的 server 上。而這個結論是在嘗試升級已降級 glibc 和切換內部 Yum mirror repo 的 server，卻無任何變更後得知。
題外話，現在的凍仁很幸運地得到前人分享的知識，並擁有 Ansible 和 Vagrant 兩大利器，才能在不到一週內解決環境不一的問題。甚至還在最後發現 Ansible Playbooks 漏掉了要安裝 authconfig 這個必要套件呢！
相關連結：
★ 2.2. Using authconfig | redhat customer portal
資料來源：
★ [SOLVED] Yum Dependencies resolution fail (glibc-common) | LinuxQuestions.org
I have got same problem via `sudo yum install bind-utils`, and I fixed this case with `yum downgrade` too.
回覆刪除1. Downgrade the "bind-libs" and "bind-license".
```
$ sudo yum downgrade bind-libs-lite.x86_64 bind-license.noarch
```
2. Install the "bind-utils".
```
$ sudo yum install bind-utils
```
3. DONE.
Same problem again.
回覆刪除> https://unix.stackexchange.com/a/551488/62890
```
$ sudo yum install -y bind-utils
...
Error: Package: 32:bind-libs-9.9.4-38.el7_3.2.x86_64 (ltzwk-upadte)
Requires: bind-license = 32:9.9.4-38.el7_3.2
Installed: 32:bind-license-9.9.4-50.el7_3.1.noarch (@updates)
bind-license = 32:9.9.4-50.el7_3.1
Available: 32:bind-license-9.9.4-29.el7.noarch (ltzwk-base)
bind-license = 32:9.9.4-29.el7
Available: 32:bind-license-9.9.4-29.el7_2.1.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-29.el7_2.1
Available: 32:bind-license-9.9.4-29.el7_2.2.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-29.el7_2.2
Available: 32:bind-license-9.9.4-29.el7_2.3.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-29.el7_2.3
Available: 32:bind-license-9.9.4-29.el7_2.4.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-29.el7_2.4
Available: 32:bind-license-9.9.4-37.el7.noarch (ltzwk-base)
bind-license = 32:9.9.4-37.el7
Available: 32:bind-license-9.9.4-38.el7_3.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-38.el7_3
Available: 32:bind-license-9.9.4-38.el7_3.1.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-38.el7_3.1
Available: 32:bind-license-9.9.4-38.el7_3.2.noarch (ltzwk-upadte)
bind-license = 32:9.9.4-38.el7_3.2
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
```