Linux
AMD CPUのPRIMERGY MX130 S2 にCentOS 7をいれてyum upgradeしたら microcode: failed to load file amd-ucode/microcode_amd.bin などと言う謎のエラーを吐いて起動しなくなっているお話(現在進行形) (解決したのでオチを追記)。
古の激安サーバー()であるPRIMERGY MX130 S2が職場に２台あるわけですが、うち1代のHDDがS.M.A.R.T.エラーを噴いて撃沈したのをいいことに、CentOS 7で再構築を始めたわけですよ。とりま、 yum upgrade でまるっと更新かけたわけですよ。 kernel が更新リストに入っていたから、何も考えずリブートしたわけですよ。
…カーネルパニックみたいな状態になって起動どころかCTRL+ALT+DELすら受け付けない状態になったわけですよ(汗)
電源断して起動時に1つ前のkernelを指定したところ無事起動したので、dmesg.oldを見たところ、最後のメッセージが冒頭の “microcode: failed to load file amd-ucode/microcode_amd.bin”。
で、このメッセージでGoogle検索してみると、以下のバグトラックが出てきた。どうも同じ現象っぽい。
0007331: Failed to load file microcode_amd.bin
実際、 /lib/firmware/ の中に amd-ucode/ というディレクトリ自体が存在しないのでそりゃファイルのロードもできないよね、という状態ではあるのだけど、今一つ分からないのが、今回の現象が意図的に行われたのか誰かのミスなのか、というところ。
英文なんで斜め読みで取り敢えず解決方法だけ探してる状況なのですが、解決方法自体はまあ、バグトラックに言及があるURLからmicrocode一式をダウンロードして入れてしまえば良さげです。
ただ仮に今回の現象が意図的なもので、今後kernelにはこのファイル群が入らないとなると、このサーバー機はCentOS 6止まりにしておくとか、運用終了も考えたほうが良い気がします。ただ、意図的な足きりならば、この手のバグトラックは割と早い段階で開発当事者の人が出てきて「そいつはもうサポート外だ」で 終わると思うんですよね。なにやら話題は継続している様子だし、足りないファイル入れておしまいなら早々にバグフィックス版が出てもよさそうなのに、1年以上もスレッドが続いている。
そして何より気にかかるのが、PRIMERGY MX130 S2を買った、CentOS入れたという日本語記事はわりとGoogle検索にひっかかるのに、このバグに遭遇したという日本語記事が出てこない。みなさんなんで大丈夫なの？？
ともあれ、明日(というか今日)出勤したら、問題のファイル群を押し込んで経過観察する予定。
[2015.12.29 追記]
いや本当は12/17に解決していたのだけど、記録する暇が無くて…。
結論。microcodeは関係なかった。つか然るべきファイルを置いてみても「ファイルが無い」というエラーは出ていないもののフリーズする現象は止まらず。再度ググったところ、以下と同じ現象だった模様。
Kernel 3.10.0-327 issue on AMD Neo processor
同じ方法で対策してみたところ、安定稼働するようになりました。その後本格的なシステム構築を始めて仕事納めの12/25まで24時間動作続けています。
しかしclocksource_done_bootingってなんだろう…。名前から察してタイマー割り込み系かしら。
ConoHaのownCloudとオブジェクトストレージでオンラインストレージを作る(前編)の続き。いよいよオブジェクトストレージと連結し、Windowsの同期バックアップストレージとして運用しますよ。
ownCloudのデータ保存領域をオブジェクトストレージにする
ownCloud のドキュメントに設定のサンプルがあります。ただ、一部項目の入れ替えが必要となりますので注意。
ConoHaオブジェクトストレージを契約する
- ConoHa管理画面の「オブジェクトストレージ設定」 を開く
- 「ディスク容量」バーの右端にある設定アイコンをクリック
- お好みでディスク容量をセット。最低100GBからなので、予め使う容量が分かっているのでなければ、とりま100GBでよろしいかと。容量セット後から課金スタートです。
ConoHaオブジェクトストレージのAPI情報を確認する
APIユーザーにパスワードを設定します。既にある場合はテナント名、パスワード、エンドポイントURLを確認。
- 左側グローバルメニューの上から7つめ「API」をクリック
- 「APIユーザー」の右側「＋ユーザー」ボタンをクリック
- 適宜パスワードをセット。ConoHaアカウント自体、ownCloud管理者、ownCloud運用VPSのroot(権限を持つ)アカウント等とはパスワードを変えておいたほうがより安全かと思われ。
- パスワードの他、画面上段の「テナント情報」内「テナントID」と「エンドポイント」内「Identity Service」の情報も確認。
ownCloudにオブジェクトストレージの情報をセットする
/var/www/htmi/owncloud/config/config.php に以下の内容を追加します。’dboassword’等と同じ階層になるよう注意。
'objectstore' => array(
'class' => 'OC\\Files\\ObjectStore\\Swift',
'arguments' => array(
'username' => ←APIユーザー名
'password' => ←APIパスワード
'container' => 'owncloud', ←任意のコンテナ名(別途作成が必要)
'region' => ← Identity Service URLの identity と conoha.io の間にあるサブドメインを指定。認証情報の endpoints.region としても得られます
'url' => ← Identity Service のURL
'tenantId' => ←テナントIDをセット
'serviceName' => 'Object Storage Service' ←ConoHa APIのエンドポイント名
),
),
ハマった点としては tenantIdがありました。ownCloudのサンプルコードでは tenantName を使用しており、ConoHaのAPI情報にも「テナント名」があるのでてっきりコレかと思ったのですが、「テナントID」のほうを渡してやらないとConoHaの認証エンドポイントから他のエンドポイント一覧が提供されないという罠。しかも tenantName があると tenantId を書いてあっても無視される。…というのを ownCloud のソースコードを追いかけまわしてようやく見つけましたよ…。
ConoHaオブジェクトストレージにコンテナを作成する
コンテナは自動では作成されない模様。 autocreate オプションは true にしてみても反応しないし、ソースコード中には「テスト用」的なコメントがあったのでどこかで無効化されているんだろうな。ともあれ、仕方ないので node.js でコンテナ生成だけ実行するスクリプトを書きました。gistにテンプレートがありますので宜しければどうぞ（以下)。こちらでの注意としては、認証URL(AuthURL)にバージョン番号が入らない点があります。node.jsは v5.2.0-linux-x64 を使用していますが、ほぼ同一の JavaScript を他のサーバーでかなり前に入れた v0.12.7 で動かしていたりしますので、概ね動くかと思われ。しかし node.js のバージョン番号はよく分からん。なんで1年も経たないうちにこんなに上がるんだ。
Windows 7 との同期
できれば WebDAV でスマートにいきたいのですが、HTTPS にしないといけないようです(レジストリをいじればいけるっぽい)。後々ちゃんとしたSSL証明書を取得する方向でいきたいので、今回はひとまず ownCloudの公式デスクトップアプリを使うことにします。
- owncloud.org の ダウンロード画面 から「Desktop Clients」をクリック、Windows用インストーラをダウンロード
- さくさくとインストール(これといった選択肢もありませぬ)
- さくさくと起動すると、サーバーアドレスを入力する画面が現れますので、http://
/owncloud/ を入力(結局ここでもHTTPS問題が発生…致し方なし) - ユーザ名とパスワードを入力
- サーバー側の同期対象フォルダ、ローカル側の同期対象フォルダを選択
あとはローカル側に作成された同期フォルダにがつがつとモノを入れていけば同期されるようデス。
ファイルの行先を確認など。
本当にちゃんとConoHaオブジェクトストレージに収まっているんでしょうか…？
- owncloud をインストールした VPS の
/var/www/html/owncloud/data/administraotr/files/にはファイルが作成されていません - ConoHaオブジェクトストレージのディスク使用量を確認すると、イイ感じに増加しております
ということで、まあオブジェクトストレージには収まったかな、と。次の疑問は、具体的にどういうオブジェクトになっているのか、とか、メタデータとかどうなんですかね？といった点ですが。
あと、HTTPSは早めに対応しないとなぁ…。
ConoHa VPSに標準で用意されているownCloudアプリケーションサーバーとConoHaオブジェクトストレージを組み合わせて、Windows PCから同期可能なオンラインストレージを作る試み。まずはowncloudを起動するまで。
[2015.12.10] 追記
後編 も書きました。
レシピ
- ConoHa VPS (ownCloudパッケージ)
- ConoHa オブジェクトストレージ
- ownCloudのリファレンス
- このはへの愛(ん？)
VPSとオブジェクトストレージを契約
- 清楚可愛いこのはちゃんと契約する
- 言語モードを「このは」にする(重要!)
- ConoHaチャージ(月額で最低金額1500円くらいかな)またはクレジットカードを登録する
- ConoHa VPSは次の仕様で組んでみた
- vCPU 1個
- メモリ1GB
- 東京リージョン
- イメージタイプは「アプリケーション」を選択(初期値)
- アプリケーションは「その他」から「ownCloud」を選択、バージョンは8-x64固定
- なお、ベースになっているOSは CentOS release 6.7 (Final) カーネルは 2.6.32-573.7.1.el6.x86_64 でした (2015.12.06現在)
- owncloud自体は 8.1.3 がinstalled、yumで 8.1.4 が来ていますね(後程アップデートしませぅ)
- rootパスワードをセット
- 自動バックアップはお好みで。今回はアプリケーションサーバーとしてのみ使用するので、変更した設定さえ別途保管しておけば全体バックアップは不要かも。
- ディスク容量は最低のSSD50GBで十分。これでも多いかも？
- インストール後の空き容量は / が 51GB割り当て、47GB空きなのでがら空き…
- 準備が整うまでは色々危ないので、取り敢えず接続許可ポートはすべてOff(コントロールパネルのブラウザコンソールで作業する)。なお、ここのポートはConoHa VPS外部のファイアウォールらしく、VPS側でSSHポートを22番以外にした場合は「すべて許可」一択となる。
- SSHキーはお好みで新規作成するなり、手持ちをセットするなり
- ネームタグもお好みで
あとは料金を確認して「追加」ボタンを押し、準備が整うまでこのはちゃんのお姿を堪能して待ちませぅ。
コンソールを開いてVPSの初期設定
- 左側「サーバー」から目的のサーバーを見つけ、ネームタグをクリック
- 「コンソール」アイコンをクリック(新しいWebブラウザ画面で仮想コンソールが開く)
- 画面が真っ暗ならEnterとか押してみる
- 作業アカウントを作る
- rootで作業すると失敗が致命的になるし、rootでのSSHログインは拒否しておきたいので、通常作業するための作業アカウントを作り、sudo権限を与える
- [注意！] ConoHaのコントロールパネルでセットした公開鍵は、rootアカウントに紐付けられています(/root/.ssh/authorized_keysに書き込まれる)。作業アカウントは別途キーを準備するなり、rootからキーを奪ってくるなりしましょう(rootのキーを移動した場合はパーミッションとオーナーに注意)。
- /etc/ssh/sshd_config を開いて編集
- 「Port 22」のコメントアウトを外し、22番以外の未使用ポートに変更 (ポート22狙いのアタッカーが回避できます)
- 「PermitRootLogin」を「no」に変更 (SSH経由でのrootログイン不可)
- /etc/sysconfig/iptables を開いて編集 (空だった)
-A INPUT -m state --state NEW -m tcp -p tcp --dport <SSH port> -j ACCEPTを追記- (owncloudのWeb画面を開くために)
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPTを追記 - あとはお好みで。基本的に全部 REJECT してホワイトリストのポートだけ ACCEPT すれば良いかと。
- この辺りのことは覚えたところで、どうせ CentOS 7になればfirewalldに代わって役に立たなくなりますよ… (今回firewalldを探して10分くらい彷徨った…)
- sshdとiptablesを(再)起動
$ sudo service sshd restart$ sudo service iptables restart
- ConoHaのコントロールパネルの「ネットワーク情報」をプルダウンさせ、「接続許可ポート」で「すべて許可」を選択(以後、ポートアクセス制御はVPS側のiptablesに委任)
- お好みのターミナルエミュレーターから接続できることを確認 (以降はターミナルエミュレーターから作業)
- 念のため、rootでログインできないことも確認しませぅ
- さらに念のため、ConoHaコントロールパネルのWebブラウザコンソールからはrootでログインできることを確認しませぅ
- 適当なタイミングで
sudo yum upgradeでも打って最新環境にするべし
ownCloudの設定
- コンソールにログインするとwelcomeメッセージとして URLやらMySQLのパスワードやらが表示されるので、URLにアクセスする。
- 管理者アカウントを作成する
- 試しに適当なファイルをアップロードしてみる
たぶん通常アカウントを作って、そっちで使ったほうが良い…いや所詮プライベートストレージだからこのままでもいいか…な？
なおアップロードしたファイルは /var/www/html/owncloud/data/<アカウント名>/files/ に収まる様子。 (/var/www/html/owncloud/data/ 以下はapacheユーザー/グループ管轄、otherにアクセス権無し)
残項目
- HTTPSアクセスにしたほうが良い気がするぞ
- ポートをガチガチに塞ぎ過ぎてメールアラートも出なくなってるので、必要なポートを開けたい
- ていうかちゃんとドメイン割り当ててメールサーバーも設定しておこう
- 本題であるWindowsとの同期とオブジェクトストレージの使用はどうした
[2015.12.08] 追記
yum upgrade したのち reboot してそのまま気持ちよく作業を終えたところ、数日経ってからアクセスしたら owncloud がメンテナンスモードに入ってしまっているという仕打ちが発生。モード解除自体は /var/www/html/owncloud/config/config.php 内の ’maintenance’ を false にすればOKだったのだけど、なんでメンテナンスになったんだ…。しかも画面には「owncloudを再起動すれば解除されます」とある割に、 httpd をリスタートしても何も変わらんかったし。
もしかして yum upgrade で owncloud 自体が 8.1.3 から 8.1.4 にアップデートされたので、このタイミングで自動的にメンテナンスモードになるんですかね…？
あと数日放置してたら、案の定 httpd にアタッカーの皆さんからご訪問を受けておりました。幸い突破された様子は無かったけど、一度アクセス範囲を見直したほうが良さげ。
[2015.12.10] 追記
後編 に続く…！
CentOSで他のマシンをリモート操作することに関するメモ。必要に応じて追記されていると思われ。
コマンドプロンプトから他のマシンを起動する (Wak on LAN)
ether-wake <MAC address>
実行にはroot権限が必要。
CentOS 7 だと標準で導入されているっぽい? うちでは主要マシン向けに以下のようなシェルスクリプト書いてあります。(sudoで実行して機動確認のためにpingを打ちつづける)
#!/bin/sh
sudo /usr/sbin/ether-wake <MAC address>
ping <IP address>
リモートデスクトップ接続
EPELの xrdp パッケージ ( http://xrdp.sourceforge.net/ ) を導入します。
xrdp.x86_64 : Open source remote desktop protocol (RDP) server
以下のようなシェルスクリプトを書いておくと便利。この例ではフルHDモニタいっぱいに表示します。また、起動後コンソールを占拠されるのが嫌なのでバックグラウンドに回しています。
ポート番号は標準のままならば指定不要。うちの場合ブロードバンドルーターを介してINTERNETから繋ぐので、アタック対策も兼ねてポート番号を適当に割り当てています。
#!/bin/sh
rdesktop -g 1920x1080 <IP address>:<port> &
開発作業スペース 兼 プライベートgitリポジトリを新規確保したいのだけど、有料プランでいくつか選択肢があるのでどれにするか検討した次第。
この手のものは定期的に再検討しないと状況が変わってきたりすることと、今後開発業務の副業を本格化していく見込みで、作業スタイルを見直す必要があるため。
目的・用途
- 開発作業スペース
- やりっぱなしにできると便利 = 常時稼働
- (常時稼働の場合)そこそこ安心感のある自動バックアップ体制
- とはいえきちんと作業してまめにリポジトリへcommitすれば、作業の区切りで初期化しても問題ないはず
- git リポジトリ
- 常時稼働
- そこそこ安心感のある自動バックアップ体制
- リリース前テスト環境
- 開発作業スペースから独立したクリーンな環境が望ましい
- VMで構築して都度初期化したほうが確実かも = VM稼働環境が必要
候補とその利点・欠点
| 候補 | 利点 | 欠点 |
|---|---|---|
| レンタルサーバー(VPS or クラウド or 物理) | 開発環境+gitリポジトリ | (初期費用合わせて)1000円くらい/月 |
| 自宅サーバー | 開発環境+gitリポジトリ+VM稼働環境 | 初期費用大きい、電気代かかる |
| githubの有料プラン | 比較的安価 | 開発環境は置けない |
| Amazon EC2 | 開発環境+リリース前テスト環境。使わないとき止めておけば安価? | EC2止めてもEBS料金は発生。連続稼働だとやはり高め。 |
試算
2コア、メモリ2GB、50GB ディスク程度を目安とする。1ドル=123円として計算。
| 候補 | 試算 | 備考 |
|---|---|---|
| さくらのVPS | 初期費用1500円+900円/月 | 2コア、メモリ1GB、HDD 100GB |
| ConoHa | 900円/月 | 2コア、メモリ1GB、SSD 50GB |
| GMO VPS クラウド | 初期費用4000円+934円/月 | 3コア、メモリ2GB、HDD 100GB |
| 自宅サーバー | 2,000円/月 | ハードウェアはあるので電気代 |
| github有料プラン(micro) | $7/月 ≒ 861円/月 | 開発環境は別に必要 |
| Amazon EC2 ( EC2常時稼働 ) | $23.04/月 ≒ 2,833円/月 | t2.micro + 50GB HDD EBS |
| Amazon EC2 ( EBSを永続 ) | $4/月 ≒ 492円/月 | 50GB HDD、別途開発環境使用時にはEC2の代金もかかる |
| Amazon EC2 ( S3にアーカイブ ) | $4.75/月 ≒ 585円/月 | 50GBで計算しているが実際にはもっと少なくなるはず |
まとめ (まとまらない)
やっぱりVPSを借りてしまった方が楽か、はたまたそれほど頻繁には使用しないと見越してEC2でやるか、といったところか。しかし頻繁に使用しないなら自宅サーバーで良い気もしてくる。電気代2000円/月は多めに見積もっているので、実際はもっと少ないはずだし。EC2で始めて結局連続稼働時間が長くなったりすると負け確定になる。
リリース前テスト環境は頻繁・長時間使用するものではないはずなので、EC2環境で良いと思う。
技術習得というところから考えると、敢えてEC2+github有料プランというところ。金額的な面で現実的なのはConoHa VPS + github有料プランあたりと結論づけたい。
結局
EC2で毎回初期化・運用環境を整えたほうが検証がやりやすいので、小規模な確認作業はEC2でやるようになってきた。後はいかに手早くかつ手をかけずに必要な環境を整えるか、というところだけど、なんかそういう技術は既にあった気がしている。今のところ手動でも数分で終わるセットアップなので、手を出すには大仰すぎるけど。
t/18-is_blocked.t とともにエラーになる MediaWiki-Bot-5.006002 の t/29-get_log.t についての調査結果。結果は脱力感全開。
元ソースは以下。
https://github.com/MediaWiki-Bot/MediaWiki-Bot/blob/master/t/29-get_log.t
- 実行結果として期待する内容(変更ログ)は2件を指定しているが、実行時に「limit=1」を指定しているため最新の1件しか得られない(limit=2とすると期待通りの内容が得られる)
- 実行結果として得られるログには params という項目があるが、テストとして期待する内容には無いので不一致になる
…paramsが無いというのは、まあ仕様の変更に追いついていないのだろう、とは思うのだけど、なんでlimit=1を指定しておきながら2件の結果を期待しているんだろう…？
依頼されて MediaWiki::Bot 5.006002 をインストール中なわけですが、t/18-is_blocked.tとt/29-get_log.tが自動テストに失敗する。で、まずはt/18-is_blocked.tの調査。
元ソースは以下。
https://github.com/MediaWiki-Bot/MediaWiki-Bot/blob/master/t/18-is_blocked.t
問題の箇所(line 38)は、先行する line 31で決定された$resultの評価をしており、どうやらブロックされたユーザーについてAPIで問い合わせ、「ブロックされているぞ！」という答えを期待しているらしい。
line 31; my $result = $bot->is_blocked('User:Hiwhispees');
しかし、問い合わせに行っている test.wikipedia.org には “Hiwhispees” というユーザーは見当たらず、代わりに “Hiwhispees~testwiki” がいらっしゃる。しかもブロックされて。
…こっちぢゃねぇの…？
MediaWiki::Botのソースを読んで本来呼び出していると思われるURLを特定し、APIをじかにひっぱたいて見ると、やっぱり “Hiwhispees” だと結果が空、"Hiwhispees~testwiki" だと中身がある。
で。
t/18-is_blocked.t のline 31を “Hiwhispees~testwiki” に変えて make test してみたところ、あっさり通りましたとさ。
ぐぬぬ。
問題が起きているのは、 perl v5.10.1 (*) built for x86_64-linux-thread-multi に同梱されている(たぶん。他の作業でインストールはしていない筈)無印の LWP::Protocol::https を、現時点最新の6.06にアップグレードする際。
自動テストの t/apache.t で、https://www.apache.org/ にアクセスしようとして失敗するらしく、以下のようなエラーとなる。
cpan[1]> upgrade LWP::Protocol::https (略) Running make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/apache.t ....... 1/5 # Failed test at t/apache.t line 15. # Failed test at t/apache.t line 18. # 'Can't connect to www.apache.org:443 (certificate verify failed) # # LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl5/LWP/Protocol/http.pm line 47. # ' # doesn't match '(?-xism:Apache Software Foundation)' t/apache.t ....... 4/5 # Looks like you failed 2 tests of 5. t/apache.t ....... Dubious, test returned 2 (wstat 512, 0x200) Failed 2/5 subtests (略)
同じOS上でwget “https://www.apache.org/”すると成功するので、OSレベルでブロックされているわけではなかった。
Google検索してみると他でもエラーが出ているようだし、何より CPAN Testers で結構エラーがでているんですが…。
CPAN Testersのレポート見るとどうやらperlバージョンにかなり依存している様子。他の記事も合わせて考えると、証明書関連のミスマッチかな、という印象も。となると実使用では環境が変わる可能性も高そう。
というか、このライブラリをインストールする主目的の作業では、HTTPS関係ないのじゃ…？とも思えてきた。
ということで、とりあえず t/apache.t のエラーになるテスト箇所をコメントアウトして逃げることにする。
まず cpanコンソールから look でコンパイル環境に入り、テストコードを編集。
cpan[2]> look LWP::Protocol::https
元のソース から
- line 13～18までをコメントアウト
- line 11 のテスト数を 5 から 3 に変更
- line 13で $res を宣言しつつ使用しているので、コメントアウトによってこの変数が初出となる line 24 で宣言するよう($res →my $res)に変更
以上3つの変更を実施(以下は変更後)。
#!perl -w
use strict;
use Test::More;
use LWP::UserAgent;
my $ua = LWP::UserAgent->new();
plan skip_all => "Not online" unless $ua->is_online;
plan tests => 2;
#plan tests => 5;
#
#my $res = $ua->simple_request(HTTP::Request->new(GET => "https://www.apache.org"));
#
#ok($res->is_success);
#my $h = $res->header( 'X-Died' );
#is($h, undef, "no X-Died header");
#like($res->content, qr/Apache Software Foundation/);
# test for RT #81948
my $warn = '';
$SIG{__WARN__} = sub { $warn = shift };
$ua = LWP::UserAgent->new( ssl_opts => {verify_hostname => 0} );
my $res = $ua->simple_request(HTTP::Request->new(GET => "https://www.apache.org"));
ok($res->is_success);
is($warn, '', "no warning seen");
$res->dump(prefix => "# ");
その場でmake testしてパスできることを確認。
# make test (略) All tests successful. Files=2, Tests=58, 2 wallclock secs ( 0.03 usr 0.01 sys + 0.44 cusr 0.04 csys = 0.52 CPU) Result: PASS
cpanに戻り、改めて upgrade を実行。
cpan[3]> upgrade LWP::Protocol::https Package namespace installed latest in CPAN file LWP::Protocol::https undef 6.06 MSCHILLI/LWP-Protocol-https-6.06.tar.gz 1 installed module has no parsable version number (use 'o conf show_unparsable_versions 1' to show them) Running install for module 'LWP::Protocol::https' Running make for M/MS/MSCHILLI/LWP-Protocol-https-6.06.tar.gz Has already been unwrapped into directory /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv Has already been made Running make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/apache.t ....... ok t/https_proxy.t .. 1/56 # creating cert for direct.ssl.access # creating cert for direct.ssl.access # creating cert for foo # creating cert for bar # creating cert for foo # creating cert for foo # creating cert for bar # creating cert for bar t/https_proxy.t .. ok All tests successful. Files=2, Tests=58, 2 wallclock secs ( 0.03 usr 0.01 sys + 0.53 cusr 0.04 csys = 0.61 CPU) Result: PASS MSCHILLI/LWP-Protocol-https-6.06.tar.gz /usr/bin/make test -- OK Running make install Prepending /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv/blib/arch /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv/blib/lib to PERL5LIB for 'install' Installing /usr/local/share/perl5/LWP/Protocol/https.pm Installing /usr/local/share/man/man3/LWP::Protocol::https.3pm Appending installation info to /usr/lib64/perl5/perllocal.pod MSCHILLI/LWP-Protocol-https-6.06.tar.gz /usr/bin/make install -- OK cpan[4]>
どっとはらい。
「openssl-develが無いよ」という事象に起因するエラー内容が
SSLeay.c:13975: error: expected ‘{’ at end of input
make: *** [SSLeay.o] Error 1
なのってなにか納得がいかないですね…。一体中で何が起こっているんだろうか…。
ヘッダファイルで定義されるプリプロセッサが仕事しなくてみょんなマクロが組みあがってしまっている、とか？
ともあれ yum install openssl-devel すれば解決はするわけですが。
エラーメッセージでググって出てきたのは stackoverflow のページ でした。
cpanプロンプトでうっかりカーソルキーを押してしまってコントロールコードが入るのが鬱陶しい…というかそのせいで妙な誤動作をしてしまうのが怖いので、readlineに対応できないのかとグーグルさんに伺った所以下の記事が見つかりました。
Term::ReadLine::Gnu をインストールすれば幸せになれるようです。
インストール要件
- ncurses, ncurses-devel, readline, readline-devel
(Term::ReadLine::Gnuをインストールする時点でncurses、readlineは導入済みだったため、必須か否かは未確認です。が、develを入れるなら実行モジュールも入れてしまえばいいと思う)
インストール時のエラーによると、ncursesのほか libtermcap.a でも良いようです。ncurses-develはrubyコンパイル時にも使用するので、こちらを選択しました。
cpan>プロンプトはreadline対応しますが、インストール時の依存性解決で
Shall I follow them and prepend them to the queue of modules we are processing right now? [yes]
と聞いてくるあたりはやっぱりダメみたい。割とここで余計なキー入力してしまうのですが…。
インストールログ
$ sudo yum install ncurses ncurses-devel $ sudo yum install readline readline-devel # cpan cpan[1]> install Term::ReadLine::Gnu (省略) CPAN: File::Temp loaded ok (v0.22) (省略) CPAN.pm: Going to build H/HA/HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz (省略) Checking if your kit is complete... Looks good (省略) HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz /usr/bin/make -- OK Running make test (省略) Result: PASS HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz /usr/bin/make test -- OK (省略) Running make install (省略) HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz /usr/bin/make install -- OK (省略) CPAN: Term::ReadLine::Gnu loaded ok (v1.26) ..................... 21 subroutines in Term::ReadLine redefined