本家のお世話-#113。(Apache2.4.12へアップデート)

 Apache HTTP Server 2.4.12 が出た。 CVE-2014-3583, CVE-2014-3581, CVE-2014-8109, CVE-2013-5704 のパッチが入ってる模様。 httpd-ssl.conf に下記の行が追加されている。 2.4.11 はリリースされず,欠番になった。

  • # OCSP Stapling (requires OpenSSL 0.9.8h or later)
    #
    # This feature is disabled by default and requires at least
    # the two directives SSLUseStapling and SSLStaplingCache.
    # Refer to the documentation on OCSP Stapling in the SSL/TLS
    # How-To for more information.
    #
    # Enable stapling for all SSL-enabled servers:
    #SSLUseStapling On

    # Define a relatively small cache for OCSP Stapling using
    # the same mechanism that is used for the SSL session cache
    # above. If stapling is used with more than a few certificates,
    # the size may need to be increased. (AH01929 will be logged.)
    #SSLStaplingCache “shmcb:c:/Apache24/logs/ssl_stapling(32768)”

    # Seconds before valid OCSP responses are expired from the cache
    #SSLStaplingStandardCacheTimeout 3600

    # Seconds before invalid OCSP responses are expired from the cache
    #SSLStaplingErrorCacheTimeout 600

 このバージョンは, openssl-1.0.1l とともにビルドされているので, OpenSSL Security Advisory [08 Jan 2015] 関連の問題も対処済みになった。

 VC11 用の httpd-2.4.12-win32-VC11.zip を我が家用 ( Windows7 x86 ) にダウンロード。 Apache 2.4.x conf 情報が必要な方は,「Windows7上にWamp系WebServerを建てる-#1。」を見てください。

Adobe Flash Player の新バージョンが出るまで, Google AdSense は停止。

投稿アップデート情報  追記(2/5) 追記2(2/7)

 皆さま, Adobe Flash Player の新バージョンが出るまで, Google AdSense を停止することにしました。 Google AdSense に罪はないのですが,ご存知の通り, AdSense は時としてよくないサイトを表示してしまうことがあります。そんなわけで,現時点では― CVE-2015-0313 がゼロデイ攻撃に利用されている今という意味ですが― hxxp://www.retilio.com/skillt.swf の危険を回避するには止めたほうがいいだろうと判断したわけです。Adobe Flashの新たなゼロデイ脆弱性を確認、不正広告に利用。この悪しき swf は Dailymotion などを通して広がっているみたいですね。

 Adobe Flash Player の新バージョンでゼロデイが解消されたら, Google AdSense を復帰させるつもりです m(_”_)m。

追記(2/5):
 Adobe Flash Player の新バージョンが出ましたね。今 (16 時), うちの IE, FireFox, Google Chrome 上で version 16.0.0.305 になっているのを確認しました。速やかに,新バージョンに更新しましょう。

 2 ・ 3 日うちには, Google AdSense を復帰させるつもりです。今後は, CVE-2015-0313 狙いの悪性 swf に感染したら,それは,皆さん各自の責任ですよぉ(爆)。

追記2(2/7):
 Google AdSense を復帰させました。

初めての VPS-#7 (自分用のリポジトリの使い方)。

 前回作ったリポジトリの使い方を書こうと思う。

 リポジトリを利用しようと思う CentOS7 にログインする。例えば, VPS とか,開発用の VM とか。

  1. ‘yum-plugin-priorities’ をインストールする。
    Base, Updates, Extras リポジトリの優先度が高いので,この 3 つが有効で,なおかつ同じパッケージがこれらの中にあると,デフォルトのままでは自前リポのパッケージは使ってもらえない。この件は,その都度マニュアルで対処することもできるのだが,よく使うリポについては, ‘yum-plugin-priorities’ を利用するほうが,面倒がなくていい。
    $ sudo yum install yum-plugin-priorities
     
    よく使うリポについては,プライオリティをセットしておくべきだが,どのリポジトリを有効にしているかという情報が必要になる。忘れちゃっていることも多いもんネ。そんなときは,下記で調べる。
    $ yum repolist
     
    ‘yum repolist all’ とやれば,有効・無効にかかわらずすべてのリポジトリが,列挙されまっさ。
  2. /etc/yum.repos.d に myrepo.repo を作成する。
    $ sudo vi /etc/yum.repos.d/myrepo.repo
    中に書くのは,下記のようなこと。
    [myrepo]
    name=o6asan’s original RPM packages
    baseurl=http://www17130ue.sakura.ne.jp/~myrepo/x86_64/
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-o6asan
    priority=1
  3. /etc/yum.repos.d/CentOS-Base.repo の[base], [updates], [extras] の各エリアの最終行に ‘priority=2‘ を追記する。
  4. $ wget http://www17130ue.sakura.ne.jp/~myrepo/x86_64/RPM-GPG-KEY-o6asan
    $ sudo mv RPM-GPG-KEY-o6asan /etc/pki/rpm-gpg/

 準備完了。自前リポジトリの 1 回目の使用時に, CentOS7 が RPM-GPG-KEY-o6asan をインポートしていいか聞いてくるので, ‘y’ を入力する。

注) クライアント PC から公開鍵を削除する方法。
 クライアント PC には秘密鍵はないので, ‘gpg --delete-key <email@address>’ をやっても, ‘Unknown system error’ が戻ってくるだけで,削除はしてくれなかった。下記を使うとうまくいった。
  $ sudo rpm -e [package]

 当然ながら,正確なパッケージ名がいるが,それは下記で調べることができる。
  $ rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'

 例えば, CentOS-7 Key については,下記が戻ってくる。
  gpg-pubkey-f4a80eb5-53a7ff4b –> gpg(CentOS-7 Key (CentOS 7 Official Signing Key) )
なので,
  $ sudo rpm -e gpg-pubkey-f4a80eb5-53a7ff4b
とやると,削除することができる。

追記:
 あとで気付いたが, Apache の rpm を作ったときの記述だと,秘密鍵なしの状況でも gpg --delete-key RSA鍵ID で公開鍵を消せたと書いてある。今回はできなかったんだが,なんでだろ。バグだったりして。

初めての VPS-#6 (自分用のリポジトリを作る)。

 現在,さくらの VPS に event + suEXEC + FPM で WEB サーバを構築しようとしている。そのために,前回, ‘--enable-fpm’ 付きの php.rpm を作ったわけだが, ‘rpm -ivh’ でインストールするときの依存関係でうんざりしたので,自分用にリポジトリを作ることにした(爆)。

    VPS 上。

  1. $ sudo adduser --gid xxxx myrepo
    ‘myrepo’ はリポジトリ用のユーザで, ‘xxxx’ は httpd ユーザグループの gid である。
    $ sudo passwd myrepo
  2. $ sudo chmod 710 /home/myrepo
  3. $ sudo su - myrepo
  4. $ mkdir public_html
  5. $ cd public_html
  6. $ mkdir x86_64
  7. $ exit

 まだ,記事にしていないのだが,実はすでに Apache httpd で suEXEC サポート用の構築をしている。そんなわけで, User と Group はそれ用のものがあるわけだ。この記事に出てくる設定で,ご自分用のリポジトリを作る場合は,各自のシステムに合わせて,用語を読み替えていただきたい。
 
 httpd conf から ‘Options Indexes’ を削除してあるのだが,リポジトリのディレクトリについては,インデックスを表示したい。そのためには, .htaccess において, ‘Options Indexes’ が使えないといけないので,以下のところを変えた。

    VPS の httpd conf において。

  1. userdir.conf (/etc/httpd/conf.d/userdir.conf) の次のところを変えた。
    UserDir enabled normuser1 —>> UserDir enabled normuser1 myrepo
        ↑ これは .htaccess のためではなく, ‘myrepo’ を使えるようにするためである。
    AllowOverride FileInfo AuthConfig Limit Indexes
    —>> AllowOverride FileInfo AuthConfig Limit Indexes Options
  2. $ sudo systemctl restart httpd.service
  3. $ sudo su - myrepo
  4. $ cd public_html/x86_64
  5. $ vi .htaccess
    中身は ‘Options Indexes’ の一行。
  6. $ chmod 640 .htaccess
  7. $ exit
    開発用 VM 上。

  1. ‘rpmbuilder’ としてログオンし, rpm ファイルをリビルドする。
     
    注 1) 「初めての VPS-#5」において php.rpm のリビルドについて書いたわけだが,あのままで yum をやると,「パッケージ PACKAGE_NAME.rpm は署名されていません」と言われる。 yum を使うためには, rpm に署名がいるらしい。署名なしの rpm をインストールするには, ‘--nogpgcheck’ オプションを使う。 filezilla.rpm については,その方法でインストールした。
  2. リビルドした rpm ファイルに署名する。
    $ rpm --addsign rpmbuild/RPMS/x86_64/*
     
    当たり前だが,この作業前に GPG キーを作っておかないといけないので,作り方。
    • root 特権のユーザで VM にログオンする。
      $ sudo gpg --gen-key
      $ sudo gpg --export -a 'o6asan' > RPM-GPG-KEY-o6asan
      RPM-GPG-KEY-o6asan は公開鍵のファイルである。これを VPS の myrepo のドキュメントルート内の /x86_64 に Filezilla クライアントでアップロードする。
      $ sudo gpg -o file.secret --export-secret-key o6asan
      file.secret が秘密鍵である。これは, rpmbuilder の ホームディレクトリに移動する。
      $ sudo mv /home/vmowner/file.secret /home/rpmbuilder/file.secret
    • ‘rpmbuilder’ として VM にログオンする。
      $ gpg --import file.secret
      このコマンドは,秘密鍵,公開鍵ともにインポートしてくれる。
       
      $ vi .rpmmacros
      以下の 2 行を追記する。
      %_signature gpg
      %_gpg_name <Owner name>
       
      注 2) 実のところ,リビルドは ‘rpmbuilder’ でやるので,鍵も ‘rpmbuilder’ として作ろうとしたのだが,蹴られた。鍵の作成作業には, root 特権が必要なようである。
  3. すべての rpm ファイルを VPS の myrepo のドキュメントルート内の /x86_64 にアップロードする。
  4. VPS 上。
    $ sudo yum install createrepo
    $ sudo createrepo /path to/x86_64

 やっと,リポができたワイ。 URL は http://www17130ue.sakura.ne.jp/~myrepo/x86_64/
 次回は,使い方を書くつもり。

本家のお世話-#112。(PHP5.6.5へアップデート)

 Windows 版の PHP5.6.5 が Jan-22 03:24:41UTC に出た。結構な数のバグフィックスと CVE-2015-0231 (bug #68710), CVE-2014-9427 (bug #68618), CVE-2015-0232 (bug #68799) へのパッチが含まれているようだ。
 PHP5.6.5 ChangeLog には “Fixed bug #68799″ が見つからなかったんだが,書き忘れかな。 5.5.21 のにはあったんだが……。まっ,とにかく,アップデートした。(サーバ OS : Windows7HP+SP1(x86)).

 インストールについて詳しい情報が必要な場合は,「PHP 5.5.16 から PHP 5.6.0 への移行」をご覧ください。

初めての VPS-#5 (php.rpm のリビルド)。

 当初の予定では, suEXEC サポートの話を書くはずだったのだが,ちょっと困ったことが。今回,さくらの VPS には, event + suEXEC + FPM のシステムを構築しようとしているのだが, CentOS7 標準の php.rpm はビルド時に ‘--enable-fpm‘ オプションが付与されていないみたいなのだ。 Apache httpd 上での event + suEXEC については,標準で動きそうなんだけどね。 php.rpm のビルドオプションは, ‘php-devel’ パッケージをインストールすると,下記のコマンドで参照できる。 CentOS の rpm においては ‘php -i’ では,ビルドオプションは見えないようだ。
$ php-config --configure-options
 
 そんなわけで, ‘--enable-fpm’ オプション付きの php.rpm をリビルドすることにした。本当に必要なんかね,これ?まっ,いいけど!!
 VPS に開発系のパッケージは入れたくないので,そこでは rpm を作れない。で, NJ2100 上に開発用仮想環境を作ることにした。仮想マシンには, VMware(R) Player 6.0.4 build-2249910 と CentOS7 (「開発およびクリエイティブワークステーション」を選択し,「開発ツール」にチェックを入れた)を使用。やり方は,「CentOS6の練習-#13(仮想マシンとして使う)」と大体一緒。
 
 大体一緒だったんだけどね,今回の仮想マシンは,イーサネットデバイスを認識してくれなかった。これ,困るじゃん。 NJ2100 には SiS Ethernet Controller がついてる。「どうすりゃいいんじゃ」と思ったが,ネット上にたくさん解決方法のページがあった。私としては,その中のこちらのページをおすすめする。
 
 みーんな,同じこと書いてある。曰く「vmnetcfg.exe と vmnetcfglib.dll をお使いなさい。 VMware-workstation-full-10.0.x-xxxxxxx.exe のような VMware Workstation の無償評価版を展開すれば,手に入るよ。」と。ところがさ,ベンダーさんから,評価版を落として調べてみたけど,入ってなかった。評価版は,すでに ‘VMware-workstation-full-11.0.0-2305329.exe’ になっていて, 64 ビット版に変わっており,どうも仕様が違うようだ。ウェーン。
 
 どっかに, VMware Workstation 10 がないかって探した探した。だって,今,公式からバージョン 10 を落とすとなると,製品版を買うしかないわけだが,それは「なんじゃそれっ?」状態しょっ。結局, filehorse.com で見つけて,ダウンロードした。みんなも問題の 2 ファイルほしいかしらん?一応, zip にしてみたよ。これって,グレーゾーンかな?何はともあれ,ネットにつながる開発用仮想マシンが手に入った。
 
 さて,実際のリビルド作業。当然ながら,すべて仮想マシン上で行う。参考ページとしては,公式のここを見た。

  1. リビルド用の非特権ユーザー (rpmbuilder) を作る。 mockbuild という no logon ユーザも作る。 mockbuild って, ‘rpm’ コマンドがつかうようで,どうも IUS に起因してるようだ。
    $ sudo useradd rpmbuilder
    $ sudo passwd rpmbuilder
     
    $ sudo useradd -s /sbin/nologin mockbuild
  2. rpmbuilder のホームディレクトリに, RPM ビルド用のディレクトリを作る。
    $ sudo su - rpmbuilder
    $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
    $ echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros
  3. vault.centos.org から src.rpm をダウンロードする。
    $ wget http://vault.centos.org/7.0.1406/updates/Source/SPackages/ \
    php-5.4.16-23.el7_0.3.src.rpm
  4. インストール。
    $ rpm -ivh php-5.4.16-23.el7_0.3.src.rpm
  5. php.spec の編集
    $ $ cd ~/rpmbuild/SPECS/
    $ vi php.spec
    869 行に ‘--enable-fpm \’ を追加。
  6. $ rpmbuild -ba php.spec
     
    依存関係で,いろいろ足りないよと言われるので,素直に全部インストールののち,再挑戦。
    $ rpmbuild -ba php.spec
     
    ‘--enable-fpm’ オプション付きの php.rpm 入手完了。

 ところで,仮想マシンは, GUI で使っている。ここで, FileZilla を FTP クライアントとして使いたかったんだが,標準のリポジトリにはなかったので, filezilla.rpm も作った。このビルドのときに, wxGTK3-devel を要求されて, epel リポを有効にした。

  1. $ sudo yum install epel-release
  2. $ wget ftp://fr2.rpmfind.net/linux/fedora/linux/development/rawhide/source/ \
    SRPMS/f/filezilla-3.10.0-1.fc22.src.rpm

    $ rpm -ivh filezilla-3.10.0-1.fc22.src.rpm
    $ cd ~/rpmbuild/SPECS/
    $ rpmbuild -ba filezilla.spec

 こんなとこかな。

あけましておめでとうございます。

おめでとう! あけましておめでとうございます。
 皆様,本年もよろしくお願いいたします。

 新しい年が皆様にとって素晴らしい年でありますように!

 おかげさまで、昨年も1月のトンデモ風邪を除いては,元気に過ごせました。今年も,生きているわが身を素直に喜べる年であることを祈っております。

初めての VPS-#4 (CentOS7 上に WordPress のインストール)。

 さくらの VPS のお試し期間は, 12/2 までだったのだが,まだやりたいことを残しているので,続けて使っている。月払いで,しばらく続けてみるつもりである。

 今回は,「WordPress のインストール」について書く。試される場合は,当然ながら,前もって,初めての VPS #1初めての VPS #2初めての VPS #3 は完了していないといけないです。まずは Wheel Group User (うちの場合は centos )として―言い換えると root 権限のユーザということ―インストールする。

注)||SELinux と WordPress||httpd_selinux(8) 参照)

  1. ダッシュボードからプラグインをインストールしようとしたら,「FTP サーバー VPS_DomainName への接続に失敗しました」が出た。 Http デーモンがネットワークにアクセスできないせいらしい。解決策は, “httpd_can_network_connect –> on”。
    $ sudo setsebool -P httpd_can_network_connect on
  2. ダッシュボードからメディアファイルをアップロードしようとしたら,「ディレクトリ wp-content/uploads/year/date を作成できませんでした。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか?」が出た。親ディレクトリのパーミッションは 707 だったんだけとさ。 Httpd デーモンが context のせいで,ディレクトリの読み書きができないらしい。 context を ‘httpd_user_content_t’ から ‘httpd_sys_rw_content_t’ に変えたら,できるようになった。しかし,別の問題が発生。 FTP クライアントから見えない。メディアファイルに関しても FTP クライアント経由でバックアップすることが多い私には,これは問題である。
     
    解決策を探してみた。
    context を ‘httpd_sys_rw_content_t’ ではなく, ‘public_content_rw_t’ にする。メディアをアップロードするためには, ‘httpd_anon_write –> on’ も必要だった。
    $ sudo setsebool -P httpd_anon_write on
    $ sudo semanage fcontext -a -t public_content_rw_t \
    "/path/to/wp-content/uploads(/.*)?"

    $ sudo /sbin/restorecon -RF /path/to/wp-content/uploads
     
    参考 URL: 5.7.2. 永続的な変更: semanage fcontext
    上記には ‘restorecon -R’ で変更可能にと書いてあるのだが,なんでだか ‘restorecon -RF’ と F(force)を付けないとうまくいかなかった。

||Wheel Group User として WordPress をインストール||

  1. phpMyAdmin に root としてログイン。
  2. WordPress 用の database (wordpressdb とか) を照合順序 ‘utf8_general_ci’ で作成する。
  3. WordPress 用の user (wordpressuser とか) を localhost かつ passphrase ありで作成する。
    GRANT USAGE ON *.* TO wordpressuser@localhost IDENTIFIED BY PASSWORD ‘passphrase';
     
    特権を編集する。データベース ‘wordpressdb’ について GRANT 以外のすべての特権を与える。グローバル特権は一切付与しないことに注意!!
    GRANT ALL PRIVILEGES ON wordpressdb.* TO wordpressuser@localhost;
  4. ログアウト

——————–

  1. VPS に SSH 経由で centos としてログオン。直後は, /home/centos にいるはず。
  2. $ mkdir tmp
    $ chmod 707 tmp

    tmp はダウンロードファイル用である。

  3. $ cd tmp
     
    ‘wget’ が入っていない場合は,下記でインストール。
    $ sudo yum install wget
     
    WordPress をダウンロードし,解凍後当該個所にコピーする。
    $ wget https://ja.wordpress.org/wordpress-4.0-ja.tar.gz
    $ tar xzvf wordpress-4.0-ja.tar.gz
    $ rsync -avP ~/tmp/wordpress/ ~/www/html/wp/
  4. uploads フォルダを作成。
    $ mkdir ~/www/html/wp/wp-content/uploads
    $ chmod 707 uploads
     
    context type を変更する。
    $ sudo semanage fcontext -a -t public_content_rw_t \
    "/home/centos/www/html/wp/wp-content/uploads(/.*)?"

    $ sudo /sbin/restorecon -RF /home/centos/www/html/wp/wp-content/uploads

——————–

  1. ブラウザから, http://VPS_DomainName/wp/ にアクセスする。
  2. ブラウザからのインストール時, wp-config.php が自動生成されないので,表示される情報をもとに,テキストエディタで作成し, FTP クライアントでアップロードして,パーミッションを 404 にする。
    それ以外は,順当に進む。
     
    注)WordPress が FTP account 情報を自動取得できないようで,アップテートやプラグインインストール時に,一々入れてやらないといけないので, wp-config.php の /* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */ より前に下記の 3 行を追加した。
    参考 URL: WordPress Upgrade Constants
     
    define('FTP_USER', 'username');
    define('FTP_PASS', 'password');
    define('FTP_HOST', 'VPS_DomainName');

 
 この時点で, PHP は DSO (Apache 2.0 Handler) で動いている。で,上の手順後,大部分の WordPress のファイルのオーナー/グループは ‘centos:centos’ になっているが,ダッシュボードからアップロードしたメディアファイルだけは, ‘apache:apache’ である。このせいで, FTP クライアントから,メディアファイルの編集ができない。バックアップはできるんだが。まあ, ‘centos‘ としてなら, SSH 経由で ‘chown’ が使えるけどね。
 
 このことは,一般ユーザの場合に,より問題となると思う。続いて,一般ユーザとして,インストールする話を書く。
 
||一般ユーザとして WordPress をインストール||
 当然ながら,サーバサイドの作業は,一般ユーザではできない。 centos として行う。

    [サーバサイド]——

  1. centos として, SSH 経由で VPS にログインし,一般ユーザを作成。
    $ sudo adduser normuser1
    $ sudo passwd normuser1
    Changing password for user normuser1.
    New password:
    Retype new password:
    $ sudo chmod 701 /home/normuser1
  2. /etc/httpd/conf.d/userdir.conf を編集する。
    $ sudo vi /etc/httpd/conf.d/userdir.conf 参考 URL: UserDir ディレクティブ
    • UserDir disabled の次行に UserDir enabled normuser1 を追加。
    • #UserDir public_html の次行に UserDir www/html を追加。
    • <Directory "/home/*/public_html">
      —>> <Directory "/home/*/www/html">
    • Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
      —>> Options MultiViews SymLinksIfOwnerMatch IncludesNoExec
  3. $ su - normuser1
    $ mkdir www
    $ cd www
    $ mkdir html
     
    normuser1 id の属性をチェック。
    $ id -a normuser1
    uid=1001(normuser1) gid=1001(normuser1) groups=1001(normuser1)
    $ exit
    $ sudo systemctl restart httpd.service
  4. $ sudo gpasswd -a sennari apache
    normuser1 id の属性をチェック。
    $ id -a normuser1
    uid=1001(normuser1) gid=1001(normuser1) groups=1001(normuser1),48(apache)
  5. ブラウザから root として phpMyAdmin にログイン。
     
    WordPress 用の database (normuser1db とか) を照合順序 ‘utf8_general_ci’ で作成する。
    WordPress 用の user (normuser1wp とか) を localhost かつ passphrase ありで作成する。
    GRANT USAGE ON *.* TO normuser1wp@localhost IDENTIFIED BY PASSWORD ‘passphrase';
     
    特権を編集する。データベース ‘normuser1db’ について GRANT 以外のすべての特権を与える。グローバル特権は一切付与しないことに注意!!
    GRANT ALL PRIVILEGES ON normuser1db.* TO normuser1wp@localhost;
     
    ログアウト。
    [クライアントサイド]——

  1. FTP クライアントで, normuser1 の DocumentRoot にアクセスする。
    テストとして, index.html をアップロードしてみる。ブラウザから http://VPS_DomainName/~normuser1/ にアクセスして確認。
     
    余談だが,この index.html に base64 encoded in-line image scheme を使ってみた (^^)。
  2. FTP クライアントで, DocumentRoot に wp フォルダを作成。
    解凍した WordPress のファイルを wp に FTP 経由でアップロード。
  3. ブラウザで, http://VPS_DomainName/~normuser1/wp/ にアクセスし, WordPress のインストールを続ける。
     
    ブラウザからのインストール時, wp-config.php が自動生成されないので,表示される情報をもとに,テキストエディタで作成し, FTP クライアントでアップロードして,パーミッションを 404 にする。それ以外は,順当に進んだ。
     
    注)WordPress が FTP account 情報を自動取得できないようで,アップデートやプラグインインストール時に,一々入れてやらないといけないので, wp-config.php の /* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */ より前に下記の 3 行を追加した。
    参考 URL: WordPress Upgrade Constants
     
    define('FTP_USER', 'username');
    define('FTP_PASS', 'password');
    define('FTP_HOST', 'VPS_DomainName');

 上記終了後, WordPress 4.0 を 4.1 にアップグレードした。問題なし。ところが, uploads フォルダは作成済みでパーミッションを 707 にしてあったにも関わらず,メディアのアップロードができなかった。そんなわけで,下記のような手直しをした。

  1. FTP クライアントで, uploads フォルダのパーミッションを 775 に変更。どうやら, Http デーモンがここにフルアクセスできないといけないようなので。
  2. 以下の 3 つは centos として SSH 経由でやった。これらは,一般ユーザの権限ではやれない。そんなわけで,複数ユーザのサイトを運営する場合,この件はとても不便ではないかと思った。何しろ, ‘fcontext -a -t’ 以外は uploads フォルダ作成後でないとできなかったから。
    • $ sudo chown -R normuser1:apache \
      /home/normuser1/www/html/wp/wp-content/uploads
    • $ sudo semanage fcontext -a -t public_content_rw_t \
      "/home/normuser1/www/html/wp/wp-content/uploads(/.*)?"
    • $ sudo restorecon -RF /home/sennari/www/html/wp/wp-content/uploads

 さて,いまひとつの疑問がある。どうして WordPress は upgrades と メディアアップロードで違う方法をとっているのだろうか。メディアについても upgrades と同じ方法でやってくれれば,こんなことは起こらないと思うのに。 PHP に詳しくないのでよくわからないが,おんなじ方法を使うとなんかまずいことがあるんかいな?
 
 そんなこんなで, suEXEC サポートに取り組んでみようかという気になっている。

覚え書-#22。

群雀

群雀

 昨日,珍しくスズメの群れを見た。子供のころには田んぼにいやというほどいたスズメ,近頃では本当に珍しい。昨日のような群れとなるとめったとお目にかかれない。寂しいことだ。雀のお宿(舌切り雀ですな)などという話も,本当のスズメをあまり見たことのない子供たちに,話して聞かせる日が来てしまうのだろうか。
シロハラかな?

シロハラかな?

 
 でもって,今日は左図の鳥を見た。シロハラに似ている気がするが,どうだろうか。ちょっと,細身の気もするが,あってますかね?
 
 話は変わって,アップデートメモ。昨日,下記のソフトをアップデートした。サーバの OS は Win7 HP SP1 x86 である。
 

本家のお世話-#111。(phpMyAdmin 4.3.1へアップデート)

 12/5 に phpMyAdmin 4.3.0 が 12/8 に 4.3.1 が出た。で,昨日, 4.2.13.1 から 4.3.1 にアップデートした。 ChangeLog はこんな感じ。 4.3.0 はいろいろと改良されているみたいだが, 4.3.1 は単なる bugfix バージョン。

 いつも通り, phpMyAdmin-4.3.1-english.zip をダウンロードして解凍。古い config.inc.php を新しくできた phpmyadmin フォルダにコピーし,すべてをサーバにアップロードする。(「Windows7上にWamp系WebServerを建てる-#3。」参照。)

 古い config.sample.inc.php (=Ver.4.2.x) と新しいのを比べたら, 1 行減って, 1 行増えていた。

/* Storage database and tables */ のところ
 減った行
     // $cfg[‘Servers’][$i][‘designer_coords’] = ‘pma__designer_coords';

 増えた行
     // $cfg[‘Servers’][$i][‘central_columns’] = ‘pma__central_columns';

4.3.1 の警告

4.3.1 の警告

 しょっぱなにログインすると,「The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated. Find out why. Or alternately go to ‘Operations’ tab of any database to set up it there」が出た。前半は,いつもの環境保管領域に関しての注意書きだが,後半が増えている。要するに,手作業でセットアップをやってもいいよってことダネ。

 「Find out why」をクリックすると,右図のように問題点が表示される。また,対処法も書いてある。表題の日本語のみ,ちょっと,変だね。

     高度な機能の設定する簡単な方法:

     Create the needed tables with the ./examples/create_tables.sql.
     作ったテーブルにアクセスできる pma ユーザを作成します。
     設定ファイル (config.inc.php) で高度な機能を有効にします。 config.sample.inc.php に
     ある設定例をコピーするといいでしょう。
     更新した設定ファイルを読み込むために phpMyAdmin にログインし直します。

 下記のことをやった。

  1. 古い config.inc.php のままで,新バージョンに root として,ログオンする。
  2. phpmyadmin データベース上での, controluser(Default : pma) の特権に ALTER を追加する。
  3. 新しい, create_tables.sql をインポートする。データベース名 (Default : phpmyadmin) や controluser 名 (Default : pma) をいじっている場合は,インポート前に, create_tables.sql を編集しておく。(「phpMyAdmin 環境保管領域」参照。)
  4. ログアウト。
  5. 前の config.inc.php を編集する。
    • 削除する行
           $cfg[‘Servers’][$i][‘designer_coords’] = ‘pma__designer_coords';
    • 追加する行
           $cfg[‘Servers’][$i][‘central_columns’] = ‘pma__central_columns';
  6. 再度, root としてログオン。
  7. テーブル pma__designer_coords を削除する。

 以上。

 ところで, central columns についての説明が central_columns にあるが,読んでも使い方がよくわからない。どうやったら,記録できるのか???