投稿

1月, 2018の投稿を表示しています

php_modが非推奨になったのね

昔のバージョンのphp環境でphpバージョンを上げるという対応中。 apache + PHP8のインスタンスを構築してドキュメントルートまで到達を確認。 対応する人にドキュメントルートまで到達するからプロジェクトのファイルを置いてバージョンアップのエラーを確認してもらうため依頼しましたが HTTP 503 Service Unavailable のエラーが出ているとのこと。 HTMLファイルはアクセスできているからPHPの実行ができていないと思い調べると Apache HTTP サーバーで使用するために PHP に提供されている mod_php モジュールが非推奨になりました。 php-fpmをインストールして起動し、リクエストを流してphp-fmpでphpを実行するようにして解決。 しばらくPHPを触っていなかったのでモジュールが非推奨になったことに気づかずでした。

AWS S3 大きいファイルをWEBからダウンロードする

AWS S3 大きいファイルをWEBからダウンロードする S3にログファイルなどを保存して開発者ツールを作ったときのメモ S3に保存してAWSマネジメントコンソールにログインしてダウンロードするのはIAMでアカウントやら権限やら居なくなった人のアカウント管理やら面倒で・・・ そんなことが面倒なので会社からしかアクセスできない開発者ツールでダウンロードできるようにした。 しかし、ファイル自体が1G弱あるものもありAWS-SDK(ちなみにfor PHPです)のS3ClientでgetObjctしたものをechoするような手順だとメモリ使うんでタイムアウトやら負荷になるやらいいことがなく。。 ストリーミングダウンロードにしようかとしたけどうまくいかず・・・ そんなとき調べていたらいい方法がありました! AWSで期限付きのダウンロードURLを発行できるということ なのでその時のことを記録に残します。 ※ところどころ端折って書いたり自作クラスは日本語で書いています。 こんなツールになりました。 プロジェクトや環境、ログの種類を選択すると対象ログ種別の一覧を取得 $s3 = new 【自前S3クライアント生成クラス】(); $response = $s3->listObjects(                                 $bucket,                                 $s3->【自前プレフィックス生成メソッド】($service, $env) ); $num = count($response['Contents']); $ret = array(); for($i=1; $i< $num; $i++) {     $split = explode("/", $response['Contents'][$i]['Key']);     $ret[] = end($split); } こんな感じでファイル名を取得しテンプレートで一覧を表示 ファイルA ファイルB ファイル名をクリックするとダウンロードU

AWSのログインに端末認証を導入してみた

AWSのログインに端末認証(MFA)を導入してみた MFAを導入してもユーザーの意識やユーザー自体の管理をしていなければそもそも脆弱なんですがこのご時世ですから自分の好きなパスワードだけで管理させてもMFA(Multi-Factor Authentication)を導入している方がセキュアだと思い導入しました。 ※AWSマネジメントコンソールのログイン自体も好きなパスワードにさせませんが 今回は新規ユーザー作成する機会があったのでその手順です。 (既存でも手順は新規ユーザー作成の部分の次のステッップからです) AMIメニューをクリック サイドメニュー 【ユーザー】 → 【ユーザーを追加】 ボタンクリック 新規ユーザーを作成していきます ・ユーザー名の入力 説明の必要なし ・ユーザーの種類を選択 アプリケーションやバッチ、コンソールからの利用想定であればプログラムによるアクセスをチェックをいれて、AWSマネジメントコンソール(AWSのWEB管理画面)にログインするユーザーであればこちらをチェックすればいいと思います。 今回はAWSマネジメントコンソールのみなので 【AWS マネジメントコンソールへのアクセス】 こちらのみにチェック ・コンソールのパスワード 堅めのパスワードであれば自動生成で定期的なパスワードの変更がおすすめです。 お好きなパスワードでもいいですがセキュリティにはご注意を ・ パスワードのリセットが必要 私が管理者ならユーザーに好きなパスワードを設定させないです。。 次のアクセス制限ですがここはどんな権限のユーザーを作成したいかなんで用途により様々だと思います。 開発メンバーにはこの権限というポリシーがあるならグループを作成しておいてそのグループにすればいいと思いますし、 すでに作成されているユーザーと同じものを作りたかったら既存のユーザーからコピーすればいいと思います。 どれでもない場合は既存のポリシーを直接アタッチすることになります。 以上を選択してユーザーを作成しましょう。 作成したら一応ログインできるか確認します。 ではMFA設定に入ります。新規作らなくても既存ユーザーがいればここからでOK

dokcerでapache+phpのコンテナが立ち上がらなかった時のメモ

dokcerでapache+phpのコンテナが立ち上がらなかった時のメモ 正確にはdocker-composeでapache2.4+php5.5のコンテナとmysql5.5のコンテナを立ち上げる この時にはまったことを残します。 docker-composeのファイル内容はapache2.4+php5.5・mysql5.5ともにすでにある自分用のベースイメージから 今回の作業ディレクトリにマウントしてサービスを起動するコマンドを記述したものです。 その際にapache2.4+php5.5のコンテナが立ち上がりませんでした。 立ち上がらなかったコンテナを docker commit コンテナID 作成イメージ名(原因調査なので適当に) できたイメージから docker run --rm -it 作成イメージ名 sh するとこんなエラーが出てきました $ docker run --rm -it httpd_test sh docker: Error response from daemon: cannot mount volume over existing file, file exists /var/lib/docker/overlay2/d09afadcb33cb0250cff89422a537f1c8e7af0c413976ce96a2c8a249db74cb0/merged/etc/httpd/conf/httpd.conf. See 'docker run --help'. とりあえずマウントしているパスが間違っていないdocker-composeファイルのマウント記述部分を確認 →間違えていない。 すでにイメージの中にファイルがあるのかとベースイメージを作成する時にhttpd.confを削除して再実行 →変わらず。。 ローカルのパーミッション? →関係なかった 以前にも同様の環境を作成したことがあってdockerにキャッシュでも残っているのか? →そうではなかった 今日docker for mac のアップデートがあったからか? →一番怪しいと思っていてファイル単位でのマウントできなくな

【amazon linux 2】を使ってみた

イメージ
【amazon linux 2】を使ってみた 目的はオープンソースでアンケートサイトを構築する機会があったので新しいものを使ってみるというところで amazon linux2 でLimeServeyを動かして動作を確認するまでです。 LimeServeyの推奨セットアップ環境である nginx+php+mysql php with php-fpm, mbstring, gd2 with freetype, imap, ldap, zip, zlib and databse drivers こちらで構築したいと思いますが推奨がPHP5.6です。amazon linux2の利用できる新しいトピックがPHP7.2(デフォルトでyumリポジトリにamzn2-coreがありPHP5.4があるんですがこれは流石に利用しないです。。)だったのでnginxもmysqlもバージョンは推奨を考えないで構築したいと思います。 しかし【amazon linux2】の【Extras Library】にmysqlがなかったりPHP7.2のphp-xmlがなかったりと結局追加でmysqlとremiのリポジトリを追加して対応しました。 手法として正しいかは別としてとりあえず動作はしたのでそれをメモに残したいと思います。 とりあえず【amazon linux2】の特徴 AMIやDockerイメージで利用できる。Hyper-v、VirtualBox、VMware、KVMの仮装マシンイメージでも利用できる LTS(長期サポート。セキュリティ・バグ修正) Extras Library(パッケージが依存関係ない。従来のトレードオフを排除) など とりあえずインスタンス作成は省略 ※amazonlinuxと変わらない作成手順でした。 SSHでインスタンスにログイン 管理者作業が続くので sudo su yum list で出てくるPHPのバージョンが古い。。 パッケージ管理が変わっているらしいので調べてみる 【Amazon Linux Extras Library】 一般的なパッケージをより新しいバージョンで利用することができる となっています。とりあえず amazon-linux-extras コマンド経由で管理するらしいので構築を進めて

AWSでインスタンスを削除する

AWSでインスタンスを削除する 単純にインスタンスだけ削除すると不要なものが残ったり 残しておくだけで課金がされるものもあるので手順をメモ 多分ご存知の方が多いと思いますので自分メモです まず削除したいインスタンスの情報などをメモる 削除したいインスタンスを選択して説明より ・インスタンスID ・AMI ID ボリュームにて説明より ・ボリュームID ・アタッチ済み情報 ・スナップショットID AMIにて詳細より ・ブロックデバイス いらないものもありますが一応メモっときます ではインスタンスを削除していきます ①対象インスタンスの削除 インスタンス作成時にボリュームも一緒に削除されています ボリュームメニューで先ほど控えていたボリュームIDで検索しても見つからないことを確認します。 ※インスタンス作成時に一緒に削除していなければ削除する必要があると思います。 ②AMIを検索する 今回は出来立てホヤホヤなのでAWSのパブリックイメージのようで削除できません。 自分で所有のAMIでインスタンスを作成していて今後そのイメージからインスタンスを作ることがなければ削除してもいいと思います。 ③スナップショットの確認 こちらもAMIがパブリッックイメージなのでスナップショットもパブリック。 削除できませんでした。 ちなみにパブリック以外で削除できない理由もありまして、削除できない理由はAMIによって使用されるルートデバイスのスナップショットは削除できません。削除するにはAMIの登録を解除する必要があります。とのことです。 ということでさらに今回はパブリックなんで消せなくて当たり前ですよね。 そもそもパブリックイメージなのでこちらに課金が走ることはないだろうから気にしなくていいのか。3年くらい使っているけどパブリックイメージの存在に初めて気づきました。 既存インスタンスからイメージを作成した場合は自分で所有のAMIになるのでこの場合は自分所有のスナップショットができるはずなんで必要に応じて削除します。 ④その他の管理しているもので対象インスタンスしか使っていなかった場合に必要なければ削除しましょう

nginxで画像が表示されない。。

nginxで画像が表示されない。。 表題の通りなんですがnginxを試しに使いブラウザ表示したのですが画像が表示されませんでした。 原因は簡単で設定ファイルに画像系(というか静的)ファイルにアクセスした時にどのディレクトリに流すのかを明記していなかったからです。     location ~* .(html|css|js|jpe?g|png|gif|ico|swf|woff2|ttf)$ {       root /home/user/html;       expires 10d;       access_log off;     } 下のようにしか書いていなかったのでphp拡張子にアクセスした時だけ指定のディレクトリを参照するようになっていただけなんですね。先ほど書いた設定を追加して無事表示されました。     location ~ \.php$ {   ・・・・     } 今まではapacheしか使ったことがなかったので対象ホストのドキュメントルート指定すれば大体は動いていたんでよかったんですが今回初めてnginxを使ったのですが細かく指定するみたいですね。 ------------------2018/04/01 追記 今、単純な静的WEBサイトを構築しているのですが上の記述だと画像を表示するためには画像のlocation設定をしなければならないように捉えられるなと思ったので追記しました。上の記述はphpのlocation設定しかしていなかったので画像のlocation設定も加えないと参照されないといことです。 例えばデフォルトの記述があるのですが     location / {         root   /var/www/html;         index  index.html index.htm;     } こちらですと画像だろうがHTMLファイルだろうがアクセスできました。 ただし直接アクセスできてはよろしくないファイルなんかもあるので拡張子設定やドキュメントルート設定をしていくんでしょうね。

mysql5.7を試してみました

mysql5.7を試してみました と言っても遅いんですが。。 mysql5.7を入れてみようと思ったのでやったこと コマンドも含む きっかけは新しいもの好きとjson型を扱えるようになったということで試してみたかったためです さてmysql5.7のインストール自体はyumでインストールするとしてサービスを起動 ここまではいつもと変わらず 以前にドキュメントを読んでいて変更点で気になっていたのがパスワードの有効期限が設定されたようで360日で設定され期間が過ぎるとログインできなくなるということ 【mysql5.7.4】よりパスワードの有効期限が設定されたようでパスワードを変更しようと思いましたが 【mysql5.7.11】よりデフォルトが無期限で変更されていました 今回導入したのは5.7.11以上のもの でもrootのパスワードがログに書かれたままなのは嫌なので変更します rootのパスワードが設定されていますので確認 /var/log/mysqld.log の中に A temporary password is generated for root@localhost: *********** **の部分は実際はパスワードが書かれています ログインしてまずはrootのパスワードを変更します set password for `root`@`localhost`=password('新たなパスワード'); FLUSH PRIVILEGES; ちなみにですが本当にデフォルトで無期限になったのかちゃんと確認していきたいと思います パスワード関連の設定を確認 SHOW VARIABLES LIKE '%password%'; mysql> SHOW VARIABLES LIKE '%password%'; 結果(省略あり) +---------------------------------------+--------------+ | Variable_name                    | Value        | +-

イモトのWiFiをレンタルしてシンガポールで利用してみた

イモトのWiFiをレンタルしてシンガポールで利用してみた 先日にシンガポールに旅行に行きました そんなに海外に行くことはないのですが今回は初めてWiFiをレンタルしてみました エンジニアとしてネットワークは切っても切れない存在でありレビューを書くことにしました レンタルしたのは【イモトのWiFi】です プランは【4G/LTE WiFiプラン】で、500M/日制限、シンガポール利用限定で1260円/日 これをレンタル当日は飛行機なのですが一応3泊4日なので4日間レンタルすることにしました プラスでオプション 安心パックフル(盗難や紛失時の保証) 150/日 250V対応3口電源タップ 90円/日 そもそも今までも数回海外旅行に行ったことはあるんですが今回初めてレンタルしようと思ったのは 金額が安くなってきていることと、今までは人数が多めで人に頼っていたのですが今回は少ないので自分頼りになるからです そして海外に旅行しながら仕事ができないかなんて発想も思い浮かびのレンタルです 500M/日 これって少ないんじゃないか?って思うんですが正月に帰省時にテザリングで勉強がてらネット検索くらい+αしていたらそんなに容量使わなかったので大丈夫かなって思っていました さて実際にシンガポールで使ってみての感想です 宿泊したのはシンガポール中心地メインです そこから遠くはシンガポール動物園であとはセントーサ島やマーライオン公園など中心地メインが使用地域になります ポケットWiFiルーターを利用していたのは2名 ホテルではホテルのWiFiにつなぎポケットWiFiは電源OFF まずはの感想は【500M/日】って意外と足りない。。。 利用に関してですが利用時に言われることはキャリアの海外ローミングと重複したりしないように海外ローミングをOFFにしてねとかアプリの自動更新OFFにしてね、動画などはみないでねなんてこと 確かに動画観たら一発でアウトですよね 結構、容量見ながら大丈夫かちょくちょく確認していました 利用内容としては、私はLINEや観光地のWEB検索のみ、もう一人はLINEやWEB検索とインスタくらいだと言っていました 実質的

nginx + php TCPでアクセスできなかった時のメモ

nginx + php TCPでアクセスできなかった時のメモ 環境 nginx 1.13.8 php 7.0 表題の件ですが結論から言うと 初めてnginxを使ったので設定の仕方がわからず間違っていた。。。 (まぁ大体理由なんてこんなもんです・・・) 間違っていた箇所はTCPにしたいなら 例えばnginxの設定ファイル /etc/nginx/conf.d/default.conf location ~ \.php$ { ・・・省略・・・ } なんかでfastcgi_passをunixソケットではなく fastcgi_pass   127.0.0.1:9000; #fastcgi_pass   unix:/var/run/php/php-fpm.sock; みたいにするんですが、 (unixソケットの方はここでわかりやすいように残しています) php-fpm の設定で例えば /etc/php/fpm/pool.d/www.conf の中で listen = /run/php/php7.0-fpm.sock listenがphp-fpmになっているからダメだったと思います。 listen = 127.0.0.1:9000 ;listen = /run/php/php7.0-fpm.sock 結論的にこことfpmのwww.confのlisten.ownerとlisten.groupを以下のようにして listen.owner = nginx listen.group = nginx アクセスできるようになったので原因はここかと思います。 後にデフォルトの listen.owner = www-data listen.group = www-data これに戻してアクセスしましたが普通にできました。 逆にunixソケットの場合はコメントアウトしている箇所が入れ替わる感じです。 unixソケットの場合はlisten.owner listen.groupはnginxになるかもしれません。調べているときにunixソケットの場合はそんな記事を見かけたのでこの設定をTCPなんですけどいじってみたというオチ