yum update を途中で終了してしまい、エラーになった後の対処

【環境】
CentOS Linux release 7.6.1810 (Core)


発端は、、、
yum update している途中で、うっかりターミナルを閉じてしまった(´・ω・`)


再びログインして、 yum update するとエラーが発生した。

# yum update
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.yz.yamagata-u.ac.jp
 * epel: ftp.yz.yamagata-u.ac.jp
 * extras: ftp.yz.yamagata-u.ac.jp
 * updates: ftp.yz.yamagata-u.ac.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.4 を 更新
--> 依存性の処理をしています: glibc = 2.17-260.el7_6.4 のパッケージ: glibc-common-2.17-260.el7_6.4.x86_64
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.5 を アップデート
--> トランザクションの確認を実行しています。
---> パッケージ glibc.i686 0:2.17-260.el7_6.4 を インストール
--> 依存性の処理をしています: libfreebl3.so(NSSRAWHASH_3.12.3) のパッケージ: glibc-2.17-260.el7_6.4.i686
--> 依存性の処理をしています: libfreebl3.so のパッケージ: glibc-2.17-260.el7_6.4.i686
---> パッケージ glibc.x86_64 0:2.17-260.el7_6.4 を 更新
--> トランザクションの確認を実行しています。
---> パッケージ nss-softokn-freebl.i686 0:3.36.0-5.el7_5 を インストール
--> 依存性解決を終了しました。
エラー:  Multilib version problems found. This often means that the root
        cause is something else and multilib version checking is just
        pointing out that there is a problem. Eg.:

          1. You have an upgrade for glibc which is missing some
             dependency that another package requires. Yum is trying to
             solve this by installing an older version of glibc of the
             different architecture. If you exclude the bad architecture
             yum will tell you what the root cause is (which package
             requires what). You can try redoing the upgrade with
             --exclude glibc.otherarch ... this should give you an error
             message showing the root cause of the problem.

          2. You have multiple architectures of glibc installed, but
             yum can only see an upgrade for one of those architectures.
             If you don't want/need both architectures anymore then you
             can remove the one with the missing update and everything
             will work.

          3. You have duplicate versions of glibc installed already.
             You can use "yum check" to get yum show these errors.

        ...you can also use --setopt=protected_multilib=false to remove
        this checking, however this is almost never the correct thing to
        do as something else is very likely to go wrong (often causing
        much more problems).

        Protected multilib versions: glibc-2.17-260.el7_6.5.x86_64 != glibc-2.17-260.el7_6.4.i686

/var/log/yum.log を確認しても、更新がインストールされたログは記録されていない。

パッケージを確認してみると、

# rpm -qa | grep glibc-common
glibc-common-2.17-260.el7_6.4.x86_64
glibc-common-2.17-260.el7_6.5.x86_64

のように、glibc-common が2つ入った(?)状態になっている。

よりによって glibc とは・・・。


重複したパッケージの整理を試みる。
(package-cleanup コマンドは、yum-utils パッケージに入っている)

# package-cleanup --cleandupes
読み込んだプラグイン:fastestmirror
Not removing glibc-common-2.17-260.el7_6.4.x86_64 because it is required by 1 installed package
No duplicates to remove
Warning: Some duplicates were not removed because they are required by installed packages.
You can try --cleandupes with --removenewestdupes, or review them with --dupes and remove manually.

オプションが足りないらしいので、追加してもう一度。
新しいバージョンのほうだけ削除されそうに見えるので、y を押して続行。

# package-cleanup --cleandupes --removenewestdupes
読み込んだプラグイン:fastestmirror
読み込んだプラグイン:fastestmirror
--> トランザクションの確認を実行しています。
---> パッケージ glibc-common.x86_64 0:2.17-260.el7_6.5 を 削除
--> 依存性解決を終了しました。

依存性を解決しました

=========================================================================================================
 Package                  アーキテクチャー        バージョン              リポジトリー        容量
=========================================================================================================
削除中:
 glibc-common             x86_64                  2.17-260.el7_6.5        installed           115 M

トランザクションの要約
=========================================================================================================
削除  1 パッケージ

インストール容量: 115 M
上記の処理を行います。よろしいでしょうか? [y/N]y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
警告: RPMDB は yum 以外で変更されました。
  削除中                  : glibc-common-2.17-260.el7_6.5.x86_64          
                                                                          
                                                             1/1
  検証中                  : glibc-common-2.17-260.el7_6.5.x86_64          
                                                                          
                                                             1/1

削除しました:
  glibc-common.x86_64 0:2.17-260.el7_6.5

完了しました!

パッケージの確認

# rpm -qa | grep glibc-common
glibc-common-2.17-260.el7_6.4.x86_64

1つになっていて良さげ。

yum update で再び更新すると問題なくアップデートされた。

yum.log を見てみると、

# tail /var/log/yum.log
・・・
 511 08:58:42 Erased: glibc-common-2.17-260.el7_6.5.x86_64
May 11 08:59:52 Updated: glibc-common-2.17-260.el7_6.5.x86_64
May 11 08:59:54 Updated: glibc-2.17-260.el7_6.5.x86_64

という感じで大丈夫そうに見える。

date コマンドで令和から紀元前まで

Windows元号関連で色々と話題なっているなか、Linuxではどうなっているか?

glibc をupdateすると、新元号にも対応するとの事で、前後の結果をメモしておく。

元号に対応前

$ LC_ALL=ja_JP.utf8 date +%EY -d 20190501
平成31

yum updateした後

# grep glibc /var/log/yum.log
Apr 13 08:08:41 Updated: glibc-common-2.17-260.el7_6.4.x86_64
Apr 13 08:08:43 Updated: glibc-2.17-260.el7_6.4.x86_64
Apr 13 08:09:21 Updated: glibc-headers-2.17-260.el7_6.4.x86_64
Apr 13 08:09:21 Updated: glibc-devel-2.17-260.el7_6.4.x86_64
Apr 13 08:09:30 Updated: glibc-2.17-260.el7_6.4.i686

元号に対応後

$ date +%EY -d 20190501
令和元年

おぉ、令和になった!


%EY オプションを使う事があまりないので、他の引数も試してみる。

$ date +%EY -d 00010101
西暦1

うっかり桁数を間違えたら、、、紀元前(´・ω・`)?

$ date +%EY -d 0001101
紀元前1

少し変えてみたら平成に。

$ date +%EY -d 000110
平成12

WordPress で PHPのバージョンに関する警告が出る、そしてデータベース接続確立エラー

WordPress 5.1 に更新したせいか、管理画面のダッシュボードでPHPのバージョンに関する警告が出るようになった。

f:id:savakan:20190316132118p:plain

!PHPの更新が必要です
サイトが安全ではいバージョンのPHPを実行していることを検出しました。

PHPとは何ですか?サイトにどう影響しますか?

PHPはWordPressの構築およびメンテナンスに使用されるプログラミング言語です。
新しいバージョンのPHPはより高速かつ安全であるため、更新することでサイトのパフォーマンスに良い影響を与えます。

PHPの更新についてさらに詳しく

公式としては、現行の動作要件は以下のようになっている。

wordpress.org


古いPHP(5.2.4)でも動作するが、前述のような警告が出た上に、WordPressが最低限の動作要件を引き上げるとなると、困るケースがありそう。

例えば、
 CentOS 6:PHP 5.3+MySQL 5.1
 CentOS 7:PHP 5.4+MariaDB 5.5
など、RHEL系で標準リポジトリを使っている場合。

Remiリポジトリへ切り替えたり、ソースからビルドしたPHPの環境が必要になる。


WordPress の動作要件の遷移については、調べた方がいるのでリンク。

blog.hinaloe.net



なお、PHP 7系となると、PHPの古いMySQL関数(mysql)が廃止されている。

従って、古いMySQL関数を使ったプラグインがあれば、動作しなくなる。

php.net



PHP Compatibility Checker」というプラグインで、各PHPバージョンにおけるプラグインの互換性を検証できるので、事前にチェックしておくと良い。



ソースからビルドしたPHP 7.x へ切り替えた際、環境によってはデータベース接続確立エラーが発生する。

f:id:savakan:20190316132415p:plain

データベース接続確立エラー

これは、wp-config.php ファイルのユーザー名とパスワードが正しくないか、あるいはlocalhostのデータベースサーバーに接続できないかのどちらかを意味します。
ホスティングサービスのデータベースサーバーがダウンしているかもしれません。
 ・ユーザー名とパスワードに間違いはありませんか?
 ・正しいホスト名を入力しましたか?
 ・データベースサーバーは稼働していますか?

こうした用途が何を意味しているのか分からない場合は、ホスティングサービスに連絡するべきでしょう。
助けが必要であれば、いつでもWordPressサポートフォーラムを訪れることができます。

wp-config.php にて、ユーザ名とパスワードを変更していないなら、データベースへの接続方法の指定に問題がある。

WordPressをDEBUGモード有効で動作させると、画面に次のようなメッセージが表示される。

Warning: mysqli_real_connect(): (HY000/2002): No such file or directory 
in /wordpress-path/wp-includes/wp-db.php on line 1612

No such file or directory

該当ファイルを見ると、、、

1611  if ( WP_DEBUG ) {
1612      mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
1613  } else {
1614      @mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
1615  }


「No such file or directory」というメッセージからは判断するに、ソケットファイルが見つからないものかもしれない。


回避方法として、2つ挙げておく。

回避方法1

接続ホスト名を localhost127.0.0.1 に変更する。

/** MySQL のホスト名 */
define( 'DB_HOST', 'localhost' );
 ↓
/** MySQL のホスト名 */
define( 'DB_HOST', '127.0.0.1' );

レンタルサーバでは、こちらの方法になると思われる。

回避方法2

php.ini の mysqli.default_socket にソケットのパスを設定する。

パスを調べるには、

# ps aux | grep mariadb
mysql     4984  0.0  0.7 1178220 31860 ?       Sl    204  33:13 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock

など。

この場合、/var/lib/mysql/mysql.sock がソケットのパス。

php.ini へ設定を記載する。

mysqli.default_socket =
 ↓
mysqli.default_socket = /var/lib/mysql/mysql.sock

リモートデスクトップの「ローカル セキュリティ機関にアクセスできません」が2月の月例パッチで修正された

先月書いた以下の件の続き。

shobon.hatenablog.com

2月の月例パッチを適用したら、解決しました。

パッチ適用後は、再起動が必要。

CentOS 7 で PHP 7.2 を OpenLDAP 付きで configure/make するとエラーになる

【環境】

$ cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

$ rpm -qa | grep openldap
openldap-clients-2.4.44-20.el7.x86_64
openldap-devel-2.4.44-20.el7.x86_64
openldap-2.4.44-20.el7.x86_64

以下のようなオプションで、PHP 7.2 をconfigureすると、LDAPのところでエラーになる。

# ./configure \
--prefix=/usr/local/lib/php-7.2 \
--with-ldap \
・
・省略
・
checking size of long int... (cached) 8
configure: error: Cannot find ldap libraries in /usr/lib.


OpenLDAPのライブラリが入っているはずだが、状況を確認。

# ls -l /usr/lib64/libldap*
lrwxrwxrwx 1 root root     21 124 08:31 /usr/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.10.7
-rwxr-xr-x 1 root root 352624 1031 08:15 /usr/lib64/libldap-2.4.so.2.10.7
lrwxrwxrwx 1 root root     21 1216 14:43 /usr/lib64/libldap.so -> libldap-2.4.so.2.10.7
lrwxrwxrwx 1 root root     23 124 08:31 /usr/lib64/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.7
-rwxr-xr-x 1 root root 381440 1031 08:15 /usr/lib64/libldap_r-2.4.so.2.10.7
lrwxrwxrwx 1 root root     23 1216 14:43 /usr/lib64/libldap_r.so -> libldap_r-2.4.so.2.10.7


64bit用パッケージしか入っていないので、/usr/lib/ 以下には、libldap* のファイルは無い。
configure で /usr/lib 以下にライブラリを探しに行っているところを見ると、32bit用のパッケージがあれば良いのかもしれない。

# yum install openldap-devel.i686

でインストールしようとすると、他にも依存関係のあるパッケージが大量にリストアップされる。
この方法は危険な匂いがするので中止。



/usr/lib/libldap.so と /usr/lib/libldap_r.so を探しに行っていると思われるので、次のように /usr/lib 以下から /usr/lib64 のファイルへシンボリックリンクを作成。

# ln -s /usr/lib64/libldap.so /usr/lib/libldap.so
# ln -s /usr/lib64/libldap_r.so /usr/lib/libldap_r.so


確認

# ls -l /usr/lib/libldap*
lrwxrwxrwx 1 root root 21 1216 14:53 /usr/lib/libldap.so -> /usr/lib64/libldap.so
lrwxrwxrwx 1 root root 23 1216 14:53 /usr/lib/libldap_r.so -> /usr/lib64/libldap_r.so


再びconfigureしてみると、問題は回避される。

# ./configure \
--prefix=/usr/local/lib/php-7.2 \
--with-ldap \
・
・省略
・
Thank you for using PHP.

次に、make でも別なエラーに遭遇する。

# make
・
・省略
・
/usr/bin/ld: ext/ldap/.libs/ldap.o: undefined reference to symbol 
'ber_scanf'
/usr/lib64/liblber-2.4.so.2: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
make: *** [sapi/cli/php] エラー 1


ber_scanf というシンボルが見えない事が原因というメッセージなので、これをネットで検索すると、man page が出る。
https://linux.die.net/man/3/ber_scanf

これによると、このシンボルは、
 OpenLDAP LBER (liblber, -llber)
に含まれるらしい。
liblber.so のこと。

configure 前に LDFLAGS で liblber.so を参照するように指定して、やり直し。

# export LDFLAGS=-llber
# configure 
・
・省略
・
# make

これで make できるようになった。

wkhtmltoimage/wkhtmltopdf コマンドで UserAgent を指定する

タイトルの通り、wkhtmltoimage/wkhtmltopdf コマンドで UserAgent を指定したくなったでのメモ。


【環境】
CentOS 6.x
wkhtmltoimage 0.12.5


デフォルトでは、wkhtmlto* コマンドでアクセスしたWebサーバのログに、以下のようなUserAgentが残った。

"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltoimage Safari/534.34"

wkhtmltoimage と表示されるのが嫌なら、任意のUserAgentを指定できる。

コマンドのオプションに、

 --custom-header 
 --custom-header-propagation

の両方を指定する。

両方指定しないと、適用されない。

    • custom-header の書式で、HTTPヘッダを追加できる。


例)

wkhtmltoimage \
  --custom-header "User-Agent" "${USER_AGENT}" \
  --custom-header-propagation \
  ${URL} \
  ${OURPUT_FILE}

${...} は、シェルの変数。

なお、wkhtmltopdf コマンドでも同様。


wkhtmltoimage/wkhtmltopdf コマンドの基本的な使い方は、2014年に書いてた。

shobon.hatenablog.com

2019年1月のWindowsUpdate後、Windows7へのリモートデスクトップに失敗する

【環境】
リモートホスト側:Windows 7 Pro SP1
クライアント側:Windows 10 Pro 1809


リモートホスト側とクライアント側の両方に対して、2019年1月のロールパッチを適用したら、Windows7リモートデスクトップに失敗する(繋がらない)ようになった。

エラーメッセージは以下の通り。

f:id:savakan:20190110202122p:plain

認証エラーが発生しました
ローカル セキュリティ機関にアクセスできません


リモートホスト側のリモートデスクトップ接続のオプションを見直して、セキュリティレベルを低くすると、接続できるようになった。(根本的な解決法ではない)

f:id:savakan:20190110202146p:plain

再びセキュリティレベルを高い設定に直すと、やはり接続に失敗する。

リモートホスト側とクライアント側の片方だけWindowsUpdate未更新の状態で検証できないので、どちらに原因があるかは不明。

これは困った(´・ω・`)


【2019.1.11 追記】

ニュースにもあったので貼っておく。
forest.watch.impress.co.jp

MSのBlog
2019 年 1 月 8 日の更新プログラムを適用すると、ファイル サーバーへの通信やリモート デスクトップ接続が不可能となる – Ask the Network & AD Support Team


【2019.2.14 追記】
2月の月例パッチで修正されました。
shobon.hatenablog.com