Red HatのApacheのバージョンを上げて!と言われたときに確認すべきこと
業務で実際に調査したことなのですが、備忘録として残しておきます。
この記事は2019/7/15に書いた記事です
事件は、httpd -vと叩いたときに始まった。
本番環境をAWSのRed Hat7のAMIイメージでサーバー構築していた我々。
(現状最新Red Hatサーバーを建てようと思ったら普通にやるとRed Hat8になる)
各OSSのージョン整理する段でhttpd -v
と叩いたときに驚愕の事実が発覚する。
バージョン : v2.4.6
えっ、Apacheってv2.4.39
とか出てなかった? 古すぎじゃね???
となった訳、v2.4.6~2.4.39までの脆弱性対策とかどうなってるんやって話。
(ちなみにv2.4.6は2013/07/22にリリースされたバージョン)
新事実、オープンソースとRed HatのApacheのバージョンは中身が違った。
yum
でインストールできんやん! と悪戦苦闘していた最中。
なんでv2.4.6
なんだ?? という疑問が出ないでもなかった。
調べてみると、以下のような情報が出てくる。
2つ目のサイトをgoogle翻訳で訳してみると、
backporting
(バックポート)なる概念があるらしいことが分かる。
ざっくりいうと、
古いバージョンを元にしているが、Red Hat社でセキュリティの問題は修正してリリースしてますよ
と言っているのである。
つまりオープンソースのApachev2.4.6
とRed HatのApachev2.4.6
は違ったのだ。
というか、httpd -v
ではRed Hat内のApacheの正体は分からないのである。
yum list installed | grep httpd
して、v2.4.6の先の数字をみる必要があったのだ。
今回であればhttpd-2.4.6-89.el7_6
と続いていて、これこそが真のバージョン情報だった。(リリース日:2019/04/23)
説得しよう
Red Hat社でセキュリティを担保していることもあって、yum
では、オープンソース版のApacheはまっったくインストールできなかったのである。
ここで一点注意しなければならない点を説明しなければならない。
それは、Red Hat社でセキュリティを担保しているのは、Red Hat社がクリティカルだと思ったものだけ
というところだ。
脆弱性はCVEなるものでまとめられているが、CVEのレベルで「Low」となっているもの等など、Red Hat社は対応していないものも散見される。
個人的には、クリティカルな部分はおさえてあるのだから、運用上の利便性を蔑ろにしてまで、オープンソース版に変える必要はないように思っているが、プロジェクトリーダーやらなんやら説得するにはもうちょっと調査が必要かもしれない。
残念なことにRed Hat版のApacheはリリースノートのように、一覧でまとめられたものは見つけられなかったので、私はオープンソースのApacheリリースノートとRed Hatの公式サイトのRed Hat CVE Database
の検索で調査した。
(私の場合は、事前にクリティカルそうなCVEを抽出してもらっていたので楽だったが、全部みるのは大変だろうと思う。ここは若干仕方がない・・・)
あとは、Red Hat版じゃなくて、オープンソース版にすると、こういった問題があるよ!的なことが、(ありがたいことに、)以下のサイトにまとまっているので、参考になるはず(少し情報は古いが)
以上、調査の役に立ってもらえたら幸いである。
NginxをEC2でUDPロードバランサーとして起動する方法
はじめに
AWSでNTPサーバーを立てようとして調べたこと。
ロードバランサー→NTPサーバーの構成にしたかったが、
2019年6月24日までAWSのロードバランサー(NLB)がUDPに対応していなかったので、Nginxで自作しようとしていた。
(しかし、既の所でAWSが対応したという・・・)
細かい設定の調整はできていないが、Nginxでもロードバランサーとして起動できたのでここにまとめます。
前提
EC2のOSはRed Hatを想定
Nginxのインストール
あまり難しいことは考えず、yum
で入れてしまいます。
以下のコマンドは基本的に管理者権限で実行する必要があります。(実際実行したときはec2-user
だったのでsudo
つけてます)
yumのupdateとnginxのインストール
yum update yum install nginx
設定ファイルの編集
vi /etc/nginx/nginx.conf
編集時の追記内容
stream { upstream dns_upstream { server 192.168.136.130:123; server 192.168.136.131:123; server 192.168.136.132:123; } server { listen 123 udp; proxy_pass dns_upstream; proxy_timeout 1s; proxy_responses 1; # error_log logs/dns.log; } }
上記内容は、公式のUDPヘルスチェックのところを参考にしています。
html通信しないのであれば設定ファイルのhtml{}
の部分をコメントアウトしても動くはずです。
ちなみに123ポートはntpのポート。dns_upstream
は各自指定しているDNS名なので条件に応じて編集が必要です。
error_log
をコメントアウトしているのは、取り敢えず初回起動させるためです。
ログファイルは、後々必要であれば作成してください。
nginx起動!
/bin/systemctl start nginx.service # 以下のようなエラーが出る Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
お達しの通りsystemctl status nginx.service
を実行すると・・・
結果↓
# 省略箇所あり ..Starting The nginx HTTP and reverse proxy server... ..nginx: the configuration file /etc/nginx/nginx.conf syntax is ok ..nginx: [emerg] bind() to 0.0.0.0:123 failed (13: Permission denied) ..nginx: configuration file /etc/nginx/nginx.conf test failed ..nginx.service: Control process exited, code=exited status=1 ..nginx.service: Failed with result 'exit-code'. ..Failed to start The nginx HTTP and reverse proxy server.
bind() to 0.0.0.0:123 failed (13: Permission denied)
ってやつが一番重要な情報っぽい・・・
実際はsudo
で実行しているし、権限大丈夫なはずなんやけどなぁと思って迷走してめちゃめちゃ時間取られてはまりました。
今回の原因はSELinux
:Linuxのカーネルに強制アクセス制御 (MAC) 機能を付加するモジュール(Wiki情報)のせいでした。
対応方法はこちら↓
# 現在の状態確認 getenforce
ここで Enforcing
と出たらアウト
参考サイト通りに永続的に無効にします。
vi /etc/selinux/config
SELINUX=enforcing
をSELINUX=disabled
に編集。
再起動!
reboot
再起動後にgetenforce
やってDisabled
になっておけばOK
あとはnginxの起動コマンド実行したらすんなりいけます。
/bin/systemctl start nginx.service
おまけ
以下の情報を見ると、「え、--with-stream
等つけてビルドしなきゃ、ロードバランサーとして使えない??」ってなったのですが、上記の方法でも起動できたので気のせいのはずです。(途中でAWSのNLB使うことになったので、実用では使っていないのですが、一応一回疎通確認はしました)
ビルドはなかなかでした・・・
最後まで到達していない。GeoIP
関連はGeoIP2
になっていて入れられないし・・・
ちなみにyum
でnginx入れると今んとこバージョンは1.14.1
になるみたいです。
ではでは、また何かネタがたまったら書きますー
WordPressのテーマXeory Baseでstaticxx.facebook.comとの通信をさせない方法
ただただ原因箇所を探すのに時間が掛かった内容なので、
備忘録として残しておきます。(万一、同じ要件にぶつかった方はサクッと解決していただきたいb)
しょうもないっちゃしょうもない。
ちなみに書いている人はphp
はかなり疎いのであしからず。
やりたいこと
題名の通り。
WordPressに無料テーマ導入して商用利用しようと思ったとき、
外部サービス(今回はfacebook)と通信して欲しくないってことがある。
(分からなくはない)
まあ、facebookと連携させる気全くないなら、余計な処理でもあるわけだ。
Firefoxなんか使うと、左下に小さく、しかし露骨に表示されたりする。
解決方法
何時間も探索を行った結果header.php
を編集したら通信しなくなるという結論に行き着いた。
編集箇所は以下の通り
// 〜〜省略〜〜 <?php bzb_show_facebook_block();?> // 〜〜省略〜〜
↓
// 〜〜省略〜〜 <!-- <?php bzb_show_facebook_block();?> --> // 〜〜省略〜〜
結論<?php bzb_show_facebook_block();?>
コメントアウトしましょうって話である。
header.php
だったら、管理画面からも編集できるはずので、サクッといけるはず。
おまけ(探索方法)
WordPressサーバーのテーマが入っているディレクトリまで移動して、
grep 'facebook' -rl ./
とか叩いて、facebookと記載あるファイルの抽出→facebookの記載箇所のコメントアウトの繰り返しで行き着いた。
以上!!(しょうもないけど、しょうもないからこそ時間かけたくないところなのでは、と思う)
追記(2019/6/28)
facebookだけじゃなくて、他のSNSとも通信させないより良い方法を教えてもらった。
以下を
// 〜〜省略〜〜 <?php bzb_header_social_buttons();?> // 〜〜省略〜〜
こう ↓
// 〜〜省略〜〜 <!-- <?php bzb_header_social_buttons();?> --> // 〜〜省略〜〜
<?php bzb_show_facebook_block();?>
じゃなくて<?php bzb_header_social_buttons();?>
をコメントアウトさせるとより良いです。
こっちやったら<?php bzb_show_facebook_block();?>
は何もしなくてよかった。
これから毎週2000字は書く
これから毎週2000字は書く
注意)極めて自分のための決意表明(日記)の記事になります。
GW10日間のトライアル
2019年10日間あるGWでやってみたこと。
それは「毎日1000字は小説を書く」こと。
始まる前はもっとがっつり書くような気でいたが、
GW当初に決めたスモールステップを守った形になった。
少ない自覚はある。が、しかし学んだことも多い。
それは自分の文章を書くスピード感が分かったことだ。
具体的に1000字書くのに、おおよそ2時間
かかっている。
まずは今の自分を受け入れる。
まあ、GW期間はなんやかんや続けられたというのは、ちょっとした自信になったのでよかった。
で、GW期に今の自分が継続的に執筆できるベストなスピードを考えた結果、
「週に2000字は書く」となったのである。
GWに創作できたのは、どっちかというと当たり前なので、
当たり前だが、これからの方が大切だろう。
「書くことを習慣づける」ことに注力していきたい。
筆が止まる原因
漠然と「こういう表現あったよな……」と思うのだがすぐに出てこない(かなりここはサボっている部分)
→(対策)本読んでいる時に印象的な文章表現は書き留めておく
書いていて展開が思っていた方向に進んでいかない。
→(対策)常々プロットは練っているが、もうちょっと細部まで考えられるようにする。
なんか突如疲れる。外に出れなくなる。
→(対策)そういう体質だと割り切る(HSP?かなって最近思えてきた)週一くらいは家で過ごした方がいい。
GW他にやったこと
友達とカラオケ1回
映画1回
AWSソリューションアーキテクトの勉強
部屋の掃除少々
MIDIキーボードのセッティング
ゲーム:ペルソナ5二週目
ブログ記事2つ
髪切った。
カフェには半分以上行った。
やる気を持続するために……
「もし僕がいま25歳なら、こんな50のやりたいことがある。」
もし僕がいま25歳なら、こんな50のやりたいことがある。 (講談社+α文庫)
- 作者: 松浦弥太郎
- 出版社/メーカー: 講談社
- 発売日: 2016/03/18
- メディア: 文庫
- この商品を含むブログを見る
「絶対に成功したいあなたへ]
絶対に成功したいあなたへ 圧倒的な成果を上げる ビジネスパーソンの心得50
- 作者: 川下順也
- 出版社/メーカー: 幻冬舎
- 発売日: 2018/03/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
社会人になって、上記のような自己啓発本も何冊か読んだ訳であるが、総じて書いてあることは、
成功するには、方向性を間違えずに、地道に一つ一つやっていく
ということであるように思う。
令和にもなったことですし、
一年目にやってきたITの勉強とも折り合いをつけながら、創作のペースも地道に増やしていこうと思う。
(残り一日のGWも小説書きます)
今回は珍しく創作関連の個人的な話でしたが、以上です。
小説投稿サイトのまとめ
AWSのCodePipelineでデプロイ対象のGitブランチを変更する。
AWSのCodePipelineでデプロイ対象のGitのブランチを変更してみます。(2019年4月末版)
ちょっと背景的な話
私がこの業界に入ったころには始まっていたサーバーレスの時代。
構築や管理が簡単になった分、インフラ担当者は一通りの構築が終われば「バイニャラ」しても不思議じゃない風潮になっているように思います。
(実際4月からインフラ担当がいなくなった!!)
今回は「バイニャラ」したインフラ担当者が用意してくださったデプロイ環境を、ちょこっとだけいじる必要性に迫られたので、ここにも備忘録残しときます。
前提
デプロイ環境はAWS CodePipeline
であり、
すでに~pushしたらそのままデプロイ~という環境が整っている。
AWS CodePipelineとは
公式の説明によると、
ソフトウェアをリリースするために必要なステップのモデル化、視覚化、および自動化に使用できる継続的な配信サービス
です。
やりたいこと
THE 本仕様と暫定仕様の二重管理です。
master : デプロイ対象のブランチ : 本仕様
temp : 現状デプロイ対象じゃないブランチ : 暫定仕様
つまり、上のようなブランチだとして、
tempをmasterにマージせずにデプロイしたい
デプロイ対象のブランチをmasterからtempに切り替えたい
ということ。
やり方
私は、これを調べるためにAWS CodePipelineのチュートリアルやりましたが、実際はそこまでしなくても気づけたかなぁくらいの内容です。
(1)AWS CodePipelineのコンソール画面を開いて対象のパイプラインを選択。
(コンソール画面はゆくゆく変更されるかもしれませんが、気持ち載せときます)
どうでもいいですが、MyFirstPipelineはチュートリアルのPipelineのデフォルトネームです
(2)編集する
ボタンを選択。
(3)Sourceのステージを編集する
を選択。
(4)画面が変化するので、編集を示すアイコン
を選択。
(5)リポジトリ名
の選択欄を変更したいブランチ名に変更します。
よくよくみるとリポジトリ名
となっているのはややこしい感じがしますね・・・
アクションから見たらブランチの違いはリポジトリの違い、ということなのかもしれません。
保存ボタンを押しまくったら、ブランチの変更は完了です。
あとは変更したブランチの方でpushを行うか、変更をリリース
ボタンを選択すれば、違うブランチのソースをデプロイすることができます。
まとめ
この記事に書いてあるものは場当たり的な対応なので、ご注意ください。
(そもそも、私が言うまでもないですが二重管理はミスの元でしかないので、極力避けた方がいいでしょう)
ここまで書いていて、本格的に二重管理しなければならないならSorceにブランチが異なるアクション増やしたらいけるんじゃね?と思えてきました。
そっちは検証していないので、参考程度の情報として受け取ってください〜〜
HTMLタグの由来
以前の内定者時代に書いたブログを移行した内容です。
(前のブログを消したので供養)
もちろん、検索すればすぐ出てくるのですが、自分のメモも兼ねて、、
文章構造に関するタグ
<h></h>
・・・heading(見出し)
<p></p>
・・・paragraph(段落)
<pre></pre>
・・・preformatted text(整形済みテキスト)
<br>
・・・break(用途:改行)
<hr>
・・・horizontal rule(水平方向の罫線)
画像
<img>
・・・image(画像)
属性src→source(出典・引用元),alt→alternate(代替)
メモ:srcが他と略す方法が違い、個人的には調子が狂う。
リンク
<a></a>
・・・anchor(いかり)
メモ:「なぜいかり?」とならなくもない。ある地点と連結するイメージからきているらしい。
属性href→「hypermedia reference」 or 「hypertext reference」
メモ:後半のreferenceは共通しているが、どうやら諸説ある模様。
一覧表示
<ol></ol>
・・・ordered list(順序ありリスト)
<ul></ul>
・・・unordered list(順序なしリスト)
<li></li>
・・・list item(リスト項目)
表
<table></table>
・・・略されていない。そのまま
<tr></tr>
・・・table row(表の行)
<td></td>
・・・table data(表のデータ)
<th></th>
・・・table header(表の見出し)
メモ:thタグでなくtdタグでも書けないことはなさそう。ただブラウザによってはthタグだと文字が太字になる場合もあるとか。
属性colspan→column span(コラム<円柱、縦長の要素のイメージ>にわたって)=横方向の連結
rowspan→(行にわたって)=縦方向の連結
HTMLのタグ、属性は大量にある訳ですが、今回は初心者が最初に勉強するであろうタグについて簡単にまとめております。
FiddlerとEclipseのデベロッパーツールで挙動が違ったのでメモ
業務でちょっと引っかかったので軽くメモ。
(同じような事象の人の参考になれば)
事象:FiddlerでテストしていたときはException発生しならなかったのにEclipseのデベロッパーツール使うとException発生する。
何がしたかったかって言うと、値を変えて業務チェックを通したかった。
原因
値がInteger型(Object型)
だったのがみそだった。
結果を言うと
Eclipseのデベロッパーツール使ったときにInteger型ではなく、int型で値を変更してしまっていてObjectを壊していたのが原因
myPCでは注意が出て事象を再現できなかったが、
EclipseにおけるInteger型(Object型)の正しい変更の仕方は以下
変数のタブに移動して
変えたい値を選択して右クリック
「値の変更」を選択
(注意書きもあるが)
new Integer('変えたい値')
で変更完了
結合テスト環境の時期にEclipseのデベロッパーツール使ったら、サーバー落ちたので結構焦りました。(localなので、皆さんに迷惑をかけた訳ではありませんが)
結構盲点だったので、ここにメモ。