2013.12.17

ドコモメール(WEB版)試してみた。

12月17日0時より、WEB版のドコモメールが利用可能になりましたので早速ログインして試してみました。

docomo-mail1

 

ドコモ公式サイトより、「ドコモメールのマルチデバイス利用」よりたどって行きます。

マルチデバイスご利用方法のところで、docomo-IDの利用設定をONに設定する注意書きが記載されています。

この設定必ず必要です。

スマホ版ドコモメールを利用する上でこの設定は参照していないようで、標準状態では設定は「利用しない」になっています。

ここの設定を「利用する」(オプションのログイン通知を行うの設定は任意で)にしないとWEB版ドコモメールのログインでエラーとなります。(最初この設定をしていなくて焦りました。)

 

ログイン画面(https://mail.smt.docomo.ne.jp/)にたどり着いたら、利用しているdocomo-IDとパスワードを入力します。

docomo-mail2

 

利用設定が適切ならば、無事ログインされます。

画面は割りとすっきりしていて見やすいのではないしょうか??

WEB版のドコモメールはWEB上ではシンプルな動作をしているのか、gmailよりも動作は軽い感じがしました。

docomo-mail3

 

このサービス・・・あと2年早くサービスINしていれば Lineなどのチャット系サービスに脅かされずにすんだだろうなぁと思える位に今回のメールサービスは良くできていると思います。

今度は折を見てIMAP4対応メールクライアントで接続してみることにします。

 

ではでは。

WordPress3.6.1ja → 3.8jaにアップグレード

WordPressを3.6.1jaから3.8jaアップグレードしました。

基本1つ飛ばしでアップグレードするポリシーだったので、3.7シリーズは見送って、3.8ja公開を待ってからのアップグレード。

アップグレード作業はセオリー通りにデータベースのバックアップ、サイトディレクトリを丸ごとアーカイブしてからアップグレードを実施。 アップグレード後、インストールしているプラグインの動作確認。特に問題なし。

 

管理画面のUIが変更されているので、見た目や使用感はかなり違いますね。

これから更新された機能について確認していこうと思います。

 

Wordpress3.8

CentOS6.5⇒6.4ダウングレード無事成功

12月15日早朝から行っていた、親(Host)サーバーのCentOS6.5から6.4へのダウングレードは無事完了しました。

結果的には力技でのダウングレードですが、今のところ問題なく動作。

また同じようなことがあったときの備忘録として記載します。

 

ダウングレードの選択肢。

CentOSの場合、ダウングレードの方法は

1.インストーラディスクで完全にシステムをクリーンインストールしなおす

2.yumのリポジトリ情報を強制的に過去のバージョンにして、過去のパッケージを強制上書きする

という方法が考えられます。

 

一番確実なのは1.のクリーンインストールしてしまうという方法。

しかし、今までセットアップした設定をもう一度しなければならないというおまけ付き。

非常に面倒です。

出来れば避けたいところ。

 

なので、2.のyumで強制的にシステムをCentOS6.4のパッケージで上書きしてシステムの再構築を実施します。

今回の場合システムのクリーンインストールを実行を考えていたところにyumでの強制上書きを実施しましたのでところどころ若干乱暴とも言えるコマンド操作も含まれています・・・が、そこは結果オーライということで。

 

yumで強制オーバーライトを実施する工程は下記の様になります。

1.yumのリポジトリを6.4に固定する。

2.yumのキャッシュエントリをすべて削除

3.yumリポジトリの内容で同期させる。(ダウングレード)

4.インストール前のチェックで弾かれたパッケージは手動で削除するので、yum同期後に手作業で削除したパッケージを再インストール。

 

1.yumのリポジトリを6.4に固定する

今回のアップグレードでわかったことは、CentOSがインストールするyumのリポジトリは常に最新パッケージを指し示すようになっていて、OSのバージョンという概念はないということ。

常に最新をリポジトリエントリに登録されていくので、結果として今回アップデートした内容がCentOS6.5になって更新されたということになります。

セキュリティという観点で考えるとこれは正解ではありますが、6.4は6.4の各モジュールのバージョンというものもあるわけで、場合によっては今回のように突然動かないアプリケーションも出てきますので、システムデフォルト設定のままでアップデート機能を使用するというのはちょっと危険…今回はそこが勉強になりました。

 

話を元に戻して、yumのリポジトリをバージョン固定化するのはわりと簡単です。

編集するファイルは /etc/yum.repo.d/CentOS-Base.repo

このファイルにリポジトリのurl情報が格納されています。

実際に編集する前に念のため、/etc/yum.repo.d/CentOS-Base.repoのバックアップを取っておきます。

 

次に、/etc/yum.repo.d/CentOS-Base.repoをvimなどで開いて、リポジトリのバージョンを示している「$releasever」の文字列を「6.4」に書き換えます。(vimでは、”:%s/$releasever/6.4/g“と入力すれば一括置換してくれます。)

 

これで6.4パッケージのバージョンアップはそのままに、6.5以上のパッケージはダウンロードされないようになります。ただし、既に古いバージョンとなっているわけですから、おそらくパッケージの更新はないと思います。

KDD-Labのftpサイトに入って6.4のパッケージを確認しても、2013/11/30以降パッケージは更新されていないようで、そこは想定内ということでダウングレードします。

 

2.yumのキャッシュエントリをすべて削除

親(Host)サーバーでは何度かパッケージの更新を行っていますので、ダウンロード済のパッケージ情報がキッシュされています。 これをそのまま残しておくとリポジトリは6.4のポインタをさして、キャッシュは直近アップデートした内容を保持するという不整合が発生します。

今回は何が記録されていようとも、リポジトリの内容に置き換えるわけですからyumのキャッシュデータは初期化 (削除)して しまいます。

 

コマンド # yum clean all

 

3.yumリポジトリの内容で同期させる。(ダウングレード)

準備が整えば、ダウングレード作業の開始です。

コマンド #yum distribution-synchronization

を実行して、yumリポジトリの内容と同期するように指定します。

リポジトリは6.4の最終リリースを指し示していますので、これで同期するということは6.5から6.4Finalにダウングレードするということになります。

 

[root@server_host yum.repos.d]# yum distribution-synchronization
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * base: mirror.fairway.ne.jp
 * extras: mirror.fairway.ne.jp
 * updates: mirror.fairway.ne.jp
Setting up Distribution Synchronization Process
Resolving Dependencies
--> Running transaction check
---> Package ModemManager.x86_64 0:0.4.0-3.git20100628.el6 will be a downgrade
---> Package ModemManager.x86_64 0:0.4.0-5.git20100628.el6 will be erased
---> Package NetworkManager.x86_64 1:0.8.1-61.el6_4 will be a downgrade
---> Package NetworkManager.x86_64 1:0.8.1-66.el6 will be erased

・・・・・・・・・・中略・・・・・・・・・・・

---> Package xorg-x11-server-common.x86_64 0:1.13.0-11.1.el6.centos.2 will be a downgrade
---> Package xorg-x11-server-common.x86_64 0:1.13.0-23.el6.centos will be erased
---> Package xorg-x11-xinit.x86_64 0:1.0.9-13.el6 will be a downgrade
---> Package xorg-x11-xinit.x86_64 0:1.0.9-14.el6 will be erased
--> Processing Conflict: p11-kit-trust-0.18.5-2.el6.x86_64 conflicts nss < 3.14.3-33
--> Finished Dependency Resolution
Error: p11-kit-trust conflicts with nss-3.14.3-4.el6_4.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

[root@server_host yum.repos.d]#

 

依存性確認のところで、いくつかコンフリクトが発生してErrorで停止しています。この段階では依存チェックなので書き込み動作は何もしていません。 ダウングレードを実行するのですから過去のパッケージに戻るために依存チェックで引っかかるのは致し方ないところ。

 

yumのメッセージとしては、“yum distribution-synchronization –skip-broken”を試してみてはどうか、“rpm -Va –nofiles –nodigest”を試してみてはどうか…とヒントを表示してくれますが、これらはおそらく役に立たないと思います。

私の環境で –skip-brokenオプションを実行して、細かく依存性確認を実施しましたが6時間かけてチェックして成果なしの結果となりました。 rpmにしても同様。

依存性確認のチェックを通らないとパッケージのダウンロード/インストールが開始されませんので、ここは強制的にチェックが通るようにします。 つまり、依存性エラーのパッケージは削除する…です。

 

コマンド #yum remove パッケージ名

で、コンフリクトを発生したパッケージをすべて記載して削除します。

(削除したパッケージはメモしておいてあとで手作業で再インストールします。)

今回のダウングレードでは“p11-kit-trust”パッケージのみコンフリクトを発生していましたので、このパッケージを指定します。

・・・しかしこのパッケージは他のパッケージとの依存関係あり上手く行きません。

依存関係があるものが多い場合、手間も膨大。

 

ここで熟考…同期チェックではこれら依存関係にあるものはErrorで弾かれていないようなので、ならば問題のものだけを強制的に削除してしまえ…と、強制削除を実施。(ちょっと乱暴ですが、「ダメなら再インストール」という気持ちで挑んでいるので許してください)

 

コマンド #yum remove –nodeps パッケージ名

–nodepsオプションを指定すると依存関係無視して当該パッケージを削除してくれます。

 

ここまで実施したたら再度 #yum distribution-synchronization を実施します。

 

今度は整合性チェックはOK…そのままパッケージダウンロード/インストールに進みました。

個々の環境に依存すると思いますが、今回ダウングレードに必要になったパッケーでは270個/233MBです。

20分もあればダウンロード/インストール/検証は完了しました。

 

4.手作業で削除したパッケージを再インストール。

3.の同期化のところでコンフリクトしたパッケージをインストールします。

 

コマンド #yum install パッケージ名

実行結果は…“既にイントールされているよ”というもの。

うーむ、削除したパッケージが同期化の途中で依存性解消のためインストールされていたようです。

それはそれで良いことなのですが、ちょっと気持ち悪いですね。

でもインストール時の検証工程で依存性に破綻はでていなかったようなので、これで様子を見てみることにします。

 

なお、この同期化処理ではパッケージのみが同期化されていますので、例えばLinuxカーネルなどは通常アップデート時には上書きではなく複数のバージョンが/bootに保存されています。

当然、CentOS6.4(Final)のカーネルがインストールされますが、grubのkernel起動設定は要確認です。

もしかしたら正しい値が書き込まれていない可能性があるので、起動するLinuxバージョンが、kernel-2.6.32-358.23.2.el6~となっているかdefault=xの値を確認します。

その後システムを再起動して、CentOSが6.4に戻っているか確認します。

 

ダウングレード前

20131214CentOS6.5

 

ダウングレード後

20131215CentOS6.4

 

問題なくダウングレードは実施できました。

CentOS6.5の時は起動できなかったVMwareWorkstation9も無事起動します。

VMware社がCentOS6.5対応の更新が実施されれば、また改めてOSのアップグレードを実施しようかと思いますが、Workstation9はすでに一つ前の世代。 微妙。

駄目なら駄目でそのとき考えるようにします。

公開サーバーはすべて仮想サーバーで行っていて、今回ダウングレードしたこのサーバーはファイヤーウォールでほとんど外部からのアクセスを遮断しているので無理にOSをアップグレードする必要はないかも知れないからです。

 

2013.12.15

CentOS6.5にハマってしまった。

今朝、親(Host)サーバーのソフトウェア更新をしておこう…と更新すると、CentOS6.4から6.5にアップグレードされてしまいました。

えっ…ちょっ…アップデータがOSアップグレードするなんてちょっとびっくり…

 

OSリビジョンがあがると大抵はセキュリティパッチが最新になる、機能がアップするなどのポジティブな要素が多いですが、相性問題が発生するなど少なからずともネガティブな要素も含んでいます。

このあたりはオープンソースソフトウェアの怖いところです。

大勢でパッチを当てているのでバグが改善されるのも早いですが植えつけられるのも早い。

コアソフトウェアが独自進化していて統一仕様でソフトが作られていない弊害ともいえます。

 

で、不具合は発生していないかまずはネットで探ってみると、Intelネットワークカードがらみでカーネルにバグが発生しているとか?

得にVPN関係で致命的な症状が出でいるようで関係するサーバーではカーネルのダウングレードで対応している模様。

うちのサーバーではVPNは使用していないのでこのあたりは特に問題なさそう…と、CentOS純正ではない後からインストールしているソフトウェアを一通り動作させてみると、やばい問題が発生していました。

 

VMwareWorkstation と VMwarePlayerの管理コンソールを起動すると、

問答無用でOSが落ちます。

 

Logを見てもなにが原因で落ちたのか記録されないので、これはKernelごと落ちている感じ。

 

おいおい・・・致命傷やん。

vmrunコマンドを使用してバックグラウンドで起動している仮想サーバーは問題なく動いているのでVMware Workstation & Playerの表示系の問題のようです。 ググッてみたものの同様の症状の報告はまだ出ていないか、Googleにまだ登録されていないのか…とにかくCentOS6.5ではVMwareの管理コンソールが使用不可となってしまいました。

 

一応仮想サーバーは動作しているので、このまま管理コンソールは使用せず運用続けて、VMware社が対応版を出してくるのを待つというのもありですが、如何せんこのサーバーに搭載しているのはWorkstation9.0.3…最新版の10.0系ではないので、アップデートされる保障はない。

 

仕方ないので、このblogを書いている裏で、親(Host)サーバーのOSダウングレード(6.5→6.4)を実行中。

1.yumのリポジトリエントリを一旦削除し

2.リポジトリがリリースデフォルト(6.5)ではなく、6.4固定のURLを指定

3.パッケージの再同期を実行(yum distribution-synchronization)

 

コマンド実行後は依存関係のエラーになったので、–skip-broken オプションを指定して再同期実施。

そしてコマンド実行からすでに2時間経過…いまだパッケージの依存関係をチェック中。

これ朝までに終わるのかな??

2013.12.09

ポケモンICOCA

ICOCA10周年記念の限定デザイン、ポケモンICOCAをゲットしてきました。

20131208011052A

 

記念デザインICOCAはこれまでもいくつか発売されていますが、カモノハシのイコちゃんがデザインされていないものって、過去にはルミナリエ限定絵柄くらいではないでしょうか?

それくらいまでにイコちゃんは限定絵柄に登場しているのですが、今回10周年記念での限定絵柄はポケモンセンター大阪とのコラボでピカチュウの絵柄を採用しています。

ゲットしてきたのは西明石駅のひとつ西側の大久保駅にて。 長男・次男をお供に、夜明け前06:30頃から並んできました。

6月に交通系ICカード相互乗り入れ記念デザイン入手の際にもこの駅で購入しましたが、西明石駅の隣というのが非常に絶妙。 大阪方面からの乗り入れでは西明石までと以西とでは乗車する列車の都合が大きく変わり。 逆に姫路エリアでは西明石を姫路エリアの最東とするならば新快速が停車しない大久保駅はちょっと不便。

 

この絶妙な位置関係のおかげで、大阪や三宮といったターミナル駅が100人単位の行列が出来ている状況で、大久保駅では10人ちょっと並んでいるか…という感じ。

割り当て枚数はそれほど多くないようなので、30人も並べば売切れてしまう状況だと思いますが、8時発売時にはまだ在庫があったものと思います。

 

来年3月で長男が小学校卒業、こどもICOCAもあと4ヶ月で返却し大人用ICOCAに切り替えなので長男はこのICOCAを使う気満々。 まぁそのつもりで複数枚購入したので、大事に使って欲しいものです。