ZAPAブログ2.0

さくらのVPSの CentOS 8 サーバーに、 Amazon AWS Cloud9 をインストールしたときのメモです。


開発に利用するマシンが複数台ある場合、一般的にはマシンごとに開発環境の設定値が異なり、それだけでストレスがたまります。ローカルファイルやオンラインファイルの同期も必要です。今の時代、開発環境もすべてクラウド上で構築できるなら、そちらの方が楽です。

Cloud9は、WebからアクセスできるオンラインIDE（統合開発環境）です。Webブラウザさえあれば、どのマシンからでもコードを記述、実行、デバッグできます。エディタの操作については、コード補完、コードヒント候補、エラー表示、ドラッグ＆ドロップ操作、Ctrl＋Sで保存など、まるでPCネイティブのアプリケーションを操作しているような感覚でブラウザから開発できます。ターミナル、プレビュー表示、テーマ、キーボードショートカットなどの機能も備えています。クラウドベースのため、オフィス、自宅、移動中、布団の中…どこでも同じ環境でプログラミングすることができます。Cloud9の初期設定さえ済ませれば、「プログラミングに必要なものはブラウザだけ」という夢の環境を構築できることになります。開発マシンの種類や性能は問われません。

また、Cloud9 IDEは、C 、 C ++ 、PHP、Ruby、Perl、Python 、Node.jsを伴うJavaScript 、Goなどの複数のプログラミング言語をサポートしています。Cloud9自体は、JavaScriptでほぼ完全に記述され、バックエンドでNode.jsが使われています。Cloud9は2016年7月にAmazonが買収しました。AWSユーザーには有名な開発環境となっています。

Cloud9は、実はAWS以外のサーバーでも利用できます。ということで、さくらのVPSの CentOS 8.1 サーバーに、 Amazon AWS Cloud9 をインストールしてみたというわけです。Amazon公式で解説されている「AWS Cloud9 インストーラ」を使えば簡単にインストールできそうですが、実際には難しかったので、手順を追ってログとして残しておきます。

Node.jsのインストール確認

まずは、Cloud9のバックエンドとして動いているNode.jsのインストールから。ターミナルから「node -v」と打って、サーバーにnodejsがインストール済みか確認。

Node.jsのインストール

バージョン確認で何か表示が出てきたらインストール済み。インストールされていなかったら、以下の方法でCentOS8.1にnodejsをインストールできる。
インストールしたnodeとnpmのバージョン確認。

Node.jsのアンインストール

上記の方法でnodejsはインストールできるが、npmのパッケージが古いとかいろいろ問題が出てきて、今後のバージョン管理にも不具合が出てきそうだったので、上記方法でのnodejs管理方法はやめ。

いきなりnodejsをアンインストール。

nodebrewのインストール

nodejsを直接インストールする代わりに、nodebrewをインストール。

以下のように表示されれば、nodebrewのインストールに成功。

環境変数を追加。

パスが通っているか確認。「nodebrew 1.0.1」等と表示されればOK。

Node.js公式ページを見て、node.js最新推奨版（LTS）をバイナリでインストールする（バイナリだと、インストールが速い！）。「Installed successfully」と表示されればOK。

使用するnodejsのバージョンを指定。以下のuseコマンドを打って、「use v12.18.1」等と表示されればOK。インストールするnode.jsと使用するバージョンの切り替えが簡単なので、nodebrewは圧倒的に楽。

続いて、npmのバージョンを確認。「6.14.5」等と表示されればOK。
これでNode.jsとnpmの利用準備は完了。

Python 2.7 をインストール。

Cloud9にはPython3系ではなく、Python2.7を使う。Python 2.7 をインストール。

gitのインストール確認

次はgitのインストール（すでにインストールされていれば必要なし）。

ここが超難関のglibc-staticのインストール。

上記コマンドを打っても、以下のエラーが返ってきてインストールできない。

実は、glibc-staticは、Red Hat系OSからは削除されている。インストールは推奨されていない。

それでも無理やりglibc-staticをインストールするなら、以下のコマンドで（自己責任で）。

GitHubとの連携設定

GitHubと連携するため、SSH認証用の鍵を作る。事前にGitHubのアカウントが必要。アカウントがない場合は、アカウントを作っておく。

作った公開鍵を開く。中身の文字列を全てコピーする。

GitHubの方で、「SSH and GPG keys」を選択し、コピーした文字列をGitHubに登録


コンフィグファイルの作成。

configファイルに以下のように記述して保存。

動作確認。下記コマンドで、「Hi ユーザー名! You've successfully authenticated,」と表示されればOK。

Cloud9のインストール

ようやく、Cloud9のインストールに取りかかる。まずは、Cloud9の作業スペースとインストール場所の作成（場所は各自自由）。

インストール。

成功すれば、以下のように表示される（もしうまく行かなかった場合は、エラー内容をよく読んで修正し、install-sdk.shをやり直す）。

ポート、ユーザー名、パスワード、IPアドレスを指定するには、以下のようにする。
firewalldのポートを開けたいときは、以下のようなコマンドを使って解放する。さくらのVPSなど、パケットフィルタでポートが塞がれている場合はそちらも確認する。

ポートが開放できたら、node ./server.js コマンドを打ったときに出てきたアドレスにアクセスする（8080番ポートを指定したのなら、http://IPアドレス:8080など）。このような画面が出てきたら成功。エラーが表示されたら、それをがんばって直す。



hello.phpを作り、Hello,World!を表示するPHPファイル作ってみる（適当に打ったらタイプミスした）。


hello.phpを保存してみる。Windows PCと同じように、Ctrl＋Sで保存できる。ブラウザ上で保存すると、サーバーのターミナル側には、以下のようにリアルタイムで処理が表示される。


作成したPHPファイルを外部のWebブラウザから直接表示できるようにする。nginxの場合、nginx.confを編集。

Cloud9で8080ポートを使っているので、Nginxでも8080を使おうとすると…（下記設定は各自の環境に合わせて）

nginxを再読込し…

もう一度Cloud9を立ち上げようとすると、怒られる。

8080はCloud9で使うので、nginxでは使うなということ。Webからページを表示させたいときは、他のポートを使用する。例えば、httpの80やhttpsの443（SSL）。テスト用に自分だけ表示できれば良いのなら、8081ポートとかを適当に使う（公開せず、自分専用の開発環境の表示確認なら、Basic認証を設定しておくとなお良い）。

この場合も、ポート開放を忘れないようにしなくてはいけない。firewalldを設定し、nginxを再起動し、Cloud9の起ち上げまで、一連の動作。

サーバーのCPU使用率やメモリ消費量を確認する上でお世話になっていた「top」コマンド。「top」コマンドはそのままでは複数コアのCPU使用率が見えないので、今までは数字の「1」を押してコアごとの使用率を見たりしていました。

そんなときに、齊藤貴義＠サイバーメガネさんのツイートを見かけました。

• 齊藤貴義＠サイバーメガネさんはTwitterを使っています 「タイトルが逆だ。htop便利だよね。自分も使ってる。 / “Linuxコマンド「ncdu」「htop」「tldr」「jq」「fd」の代替コマンドとは？ | マイナビニュース” https://t.co/jBEEk6dMsd」 / Twitter

「htop」コマンド…そういうのもあるのか、ということでマイナビニュースをチェック。

• Linuxコマンド「ncdu」「htop」「tldr」「jq」「fd」の代替コマンドとは？ | マイナビニュース

取り上げられているコマンドは多くのLinuxディストリビューションで利用できるほか、macOSやFreeBSDといった他のオペレーティングシステムでも使用できる。

早速、CentOS8.1のサーバー上で「htop」コマンドを打ち込んでみると…
そんなコマンドは使えませんでした。

ということで、「htop」をインストール（CentOS7までの場合は、dnfではなくyumでインストールします）。


EPELリポジトリに「htop」のパッケージが見つかりました（リポジトリを追加していない場合は、EPELリポジトリを追加する必要があります）。

前記事「PHPでセキュアなクッキーとセッション」からの続きです。

サーバー内でPHPのセッションファイルがどこに保存されているか知りたいとき、ありますよね。サーバー、OS、Webサーバー、PHPを入れ替えたときなどは特に（なかなか変える機会はないですが）。

そんなときは、PHP関数のphpinfo()関数を実行すれば、セッションファイルの格納場所がわかります。以下のようにphpinfo.phpというファイルを作り（ファイル名は適当です）、実行します。 アクセスすると、サーバーのPHP情報一覧が表示されます。その中にsessionセクションがあり、session.save_pathの項目に、セッションファイルのパスが以下のような感じで書かれています。

これでPHPのセッションファイルがどこに保存されているかわかりました。

続いて、このセッション保存場所をどこでどのように設定しているのか、サーバーからコマンドを入力して調べてみます。 今利用しているサーバーの場合、session.save_pathはno valueでした。「設定されていないのに、設定されている？」と不思議な気持ちになります。詳しくは、php.iniを開いて確認してみます。CentOS8の場合、以下の場所にphp.iniファイルはあります（もしphp.iniの場所がわからない場合は、上記phpinfo.phpを実行して、「Loaded Configuration File」の項目を確認してみて下さい）。 php.iniの中を確認しても、session.save_pathの行はコメントアウトされていて、何も書かれていません。代わりにこんなものがありました。

; RPM note : session directory must be owned by process owner
; for mod_php, see /etc/httpd/conf.d/php.conf
; for php-fpm, see /etc/php-fpm.d/*conf
;session.save_path = "/tmp"

サーバーをさくらのVPSに移転後、Google ChromeでPHPページを確認したら、警告が出ていました。

A cookie associated with a cross-site resource…SameSite=None` and `Secure`

安全なWebのために、Googleでは2020年2月のChrome 80から、セキュアなクッキーの利用と接続が推奨されるようになっています。

• Google Developers Japan: 2020 年 2 月の SameSite Cookie の変更: 知っておくべきこと

SameSite 値を宣言していない Cookie は SameSite=Lax の Cookie として扱われます。サードパーティ コンテキストで利用できるのは SameSite=None; Secure が設定されている Cookie のみになり、それも安全な接続が使われている場合に限られます。

session.cookie_samesite を設定

Chromeのデベロッパーツールで警告が出ている以上、警告が出ないように修正する必要があります。幸い、PHP7.3からは、php.iniで簡単に設定できるようになっています。昔のPHPには存在しなかった「session.cookie_samesite」のオプションが追加されています。

設定値は、Lax、Strict、Noneなどを設定します。例えばNoneにするなら、以下のように書き換えて設定します。
最初、「session.cookie_samesite = None」としたら、samesiteの値が空でした。「session.cookie_samesite = None」ではなく、「session.cookie_samesite = "None"」です。文字列での設定です。あまりネットに情報が出回っていませんので、ご注意ください。

先日の「ブログのデザインとシステムをリニューアルしました」の時に、「iPhone(iOS6以上)対応画像アップロードプログラム」も自分用に改良したことを書きました。スマホから複数枚の画像をアップロードできるように改良し、画像を削除できる機能も付けました。その後、画像ファイルの名前をリネームできる機能も付けました。この「リネーム」の処理が少し危なかったので、メモとして残しておきます。


PHPの関数では、アップロードされたファイルを移動するときは「move_uploaded_file」関数を使います。一方、既存のファイルを移動するときは「rename」関数を使います。move_uploaded_file()とrename()、この統一感のない関数名がPHPの面白いところだななどと思っていたら、ちょっとした罠が。

rename ( string $oldname , string $newname [, resource $context ] ) : bool

oldname を newname にリネームし、必要ならディレクトリを移動しようと試みます。 ファイル名の変更かつ newname が存在する場合、上書きされます。 ディレクトリ名の変更かつ newname が存在する場合、 この関数は警告を発します。

「ファイル名の変更かつ newname が存在する場合、上書きされます」という仕様です。特に警告もなく、いきなり上書きしちゃうんですね。以下のページでも話題になっていました。

• PHPは上書きしないrenameができない - Qiita

自分でファイルのリネーム処理を実装したとき、当初は「自分で名前を変更するわけだから、同じ名前を付けてしまうことはないだろう」などと考えていました。実際に画像ファイルのリネームをやってみたところ、変更後の名前をコピペで貼り付け、そのあと連番を付けようとしていたのに、コピペの段階でリターンキーを押してしまいそうになりました。そのままリターンキーを押していたら、画像を上書きして、元の画像ファイルが上書きされて消失していたというわけです。実際に上書きしてしまったわけではありませんが、このままでは危ないので、確認処理を追加しました。以下のような感じです。

フォームの入力途中に画面遷移しようとした場合に、警告を出すJavaScriptはないかなぁと考えました。誤った操作で、フォームへの入力内容が全て消えてしまうのは悲しすぎますから。jQueryか何かで簡単に実装できるだろうと思って探してみました。

• jQueryでフォームの入力途中で画面遷移しようとするとアラートを出して注意する｜プログラムメモ

試しに上記サイトの通り実装してみたところ、Windows PCのWebブラウザからは警告が出ました。ところが、iPhoneのWebブラウザSafariからはアラートが出ません。

「あれ、なんでだろう？」と思っていろいろ調べてみました。

formのinput入力欄でEnterキー（リターンキー、実行キー、決定キー）を押されてページ遷移させたくないとき、ありますよね。インクリメンタルサーチを実装したときなどは、わざわざエンターキーを押して画面遷移される必要性がありません。また、ページ内ですべて完結する処理も、POSTして画面遷移される必要がありません。例えば、以下のようなページです。

• DQ9錬金レシピリアルタイム検索：ドラゴンクエスト9攻略Wiki
• ホビロン パスワード強化メーカー

Submitのボタンを消せば、ページ遷移を防げそうですが、input[type=text]のフォームが一つだけで、そのフォーム内でEnterキーを押されると実行されてしまいます。これを防ぐには、javascriptで別途処理を書いたり、「 onSubmit="return false;"」などとする方法があります。

ただ、最近のブラウザはもっと賢くて、もっと簡単に送信を防ぐことができるようになりました。ダミーフィールドの使用です。

iPhoneで入力欄にカーソルを合わせたとき、自動的に画面がズームアップする機能があります。ユーザー側としては、勝手に拡大表示されて面白いなぁと思っていました。ところが、Webページ提供側から見ると、「勝手に拡大するな」と言いたくなるときもあります。このiPhoneでの「勝手に拡大する」「拡大しない」の違いは一体何なのか、調べてみました。

まず、Google Chromeのエミュレータから、スマホ向けのレスポンシブデザインのページを動作確認してみました。Chromeのエミュレータからだと、入力欄にカーソルを合わせても拡大しません。これだと、iPhoneの自動ズーム問題に気付かないことがあります。実機での動作確認は絶対に必要です。「スマホ表示だから拡大する」のではなく、「iOSだから拡大する」というApple側の仕様です。

調べてみたところ原因は、「フォーム入力欄のフォントサイズが16px未満だと、iOS側で勝手にズームする」という仕様になっていました。

原因がわかれば、対処方法は簡単です。一番簡単に解決する方法は、textareaやinputなどのフォントサイズを16px以上にすることです。単純明快です。

例えば、inputのテキストフォームにフォーカスを合わせたときに自動拡大させたくないなら、CSSでこのようにします。

httpのwwwアクセスをhttpsのwwwなしドメインにリダイレクトすることはできるのに、httpsのwwwアクセスをhttpsのwwwなしドメインにリダイレクトできなかったときのメモです。

あらかじめWebサーバーのNginxで、サブドメインwww付きのアクセスはすべてwwwなしにリダイレクトするように設定していました。例えば、「http://www.zapanet.info/blog/」にアクセスすると、SSL対応の「https://zapanet.info/blog/」に転送できるようにしていました。

ところが、「https://www.zapanet.info/blog」にアクセスしても、「https://zapanet.info/blog/」には転送されなくて失敗しました。httpからhttpsには転送できるのに、httpsからhttpsには転送できませんでした。なんででしょう？

Webサーバー側の設定はできているはずなのに、なぜかエラーが起きて転送されません。「この接続ではプライバシーが保護されません」と表示されてしまいます。常時SSL化はしてあるはずなのに。


なんでかなぁとよく考えたら、取得したSSL証明書がサブドメインに対応していないからでした。「zapanet.info」はSSL化していましたが、「www.zapanet.info」はSSL化していなかったということです。

では、どうするか。

取得したSSL証明書は、「Let's Encrypt - フリーな SSL/TLS 証明書」です。


Let's Encryptで、サブドメインも含めたSSL証明書に更新すれば良かったというわけです。最初にCentOS8のサーバー上でcertbot-autoコマンドで取得した証明書は以下でした。

dnf install tree

tree -f -i  ./ -P '*.html' > html_list.txt

^(?!.*文字列).+$

^(?!.*html).+$\n

<url>
  <loc></loc>
  <priority></priority>
  <changefreq></changefreq>
  <lastmod></lastmod>
</url>