別にMacユーザーさようならという記事ではありません。メインターゲットがWindowsユーザーなだけです。

Linuxとは

Unixという古式ゆかしい文化の流れを汲むOSの1つです。仲間にFree/Open/Net-BSDとかSolarisとかいます。そうそう、冒頭で触れたMacが使ってるOSもFreeBSDの流れを汲むOSの1つです。商用のUnixもいくつかあり、MacOS/Solarisとかは商用ですね。詳細は https://ja.wikipedia.org/wiki/Linux参照。

Unix系OSの特徴は…ターミナルだけで何でも出来るように設計されていることです(本当の意味ではPOSIX準拠くらいが妥当だと思う)。我々Windowsユーザーには信じられないですね。簡単に言えばコマンドプロンプト1つだけで何でも出来るというわけですから。当然マウスはオプションです。もちろんWindowsも極めると大抵の人はほとんどマウス使わなくなりますけど…。

ターミナルだけで何でも出来るということは、ネットワーク的に離れたところからでも、sshなどで接続すれば手元のPCと同じように何でも出来るということです。つまりネットワーク越しの作業がしやすい＝サーバー向けということになります。サーバーは普通ディスプレイも繋がっておらず、データセンターでラックに積まれるようなPCなのです。これにsshなどで繋いでコマンドラインから操作できるのがUnix系OSです。Windows系のサーバでは、通常そういう操作は行われず、リモートデスクトップのGUI画面を使ってサーバを操作します。一見初心者でも楽に操作できますが、サーバ単体のコストが高いのと、負荷が高いときに(自動で)サーバを増やして対応する(スケールアウト)ようなことが出来ないので、サーバーの主流はUnix系になります。

Windowsから使うLinux

WindowsもLinuxも括りはOSです。OSとは基本電源入れてから(ブートローダ除けば)最初に起動するものなので、普通は何かのOSを使っていたら、他のOSは同時に起動しません。アプリとは違うのですよアプリとは。つまりWindowsを使っていたら、普通は同時にLinuxを使えないのです。

しかし、ゲームをするためにWindowsを使っていたいけど、裏でスクレイピングさせてるからLinuxも同時に使いたいなぁとかいうことはあるわけです。昔はこれを実現するためにはPCが2台必要で、1台にWindowsを入れてゲーム、1台にLinuxを入れてスクレイピングといった使い方をしないといけませんでした。そんなゲーマーのために(？)最近は「仮想化」という単語とともに、1台で複数のOSを同時に動かす技術が生まれています。

仮想化の時代

現代はあらゆる仮想化の技術によって、いろいろな恩恵を受けることができます。OSも例外ではなく、CPU仮想化支援とハイパーバイザーの力を借りて、複数のOSを同時に動かすことが出来ます。

Windows上でLinuxを動かす場合、2020年2月2日現在、以下の方式が一般的です。

1. Hyper-V(ハイパーバイザ)を無効にしてVirtualBox/VMwareなどを使って好きなディストリビューションのLinuxを動かす
2. Hyper-V(ハイパーバイザ)を無効にしてWSLを使って対応ディストリビューションのLinuxを動かす(WSL1のまま使う)
3. Hyper-V(ハイパーバイザ)を有効にしてWindowsもLinuxも使う(WSL2はこの方式)

2.は動かないソフトがあったり、安定性が問題になる場合があります。3.は1.の使い方が出来なくなる問題があります(最近のVirtualBoxは機能的にHyper-V有効でも動くようになったらしいが、ハード依存しており安定していない)。そこで今回は1.のケースを選択します。

なお、1～3いずれにしてもCPU仮想化支援を前提としています。今使われてるCPUは大半がこの機能を持っていると思いますが、BIOSの設定次第の場合があるので、BIOSで有効化しておきましょう。

なお、最近巷でよく聞くDockerなどのコンテナ系の仮想化もありますが、これらはOSそのものを仮想化してるわけではないので、ここでは扱いません。OSそのものの機能はホストのものを使い、アプリの実行環境をコンテナという箱で管理する方式に近いです。ようは1.～3.でLinuxをインストールしないと使えないということです。

VirtualBoxのインストール

現在主流のVMソフトはVirtualBox/VMwareの2つですが、ここでは無料で登録せずに使えるVirtualBoxを選択します。

vagrantで良くない？

いいえ。某学習サイトなどで紹介される、vagrantもローカルインストール用に中で使ってるのはVirtualBoxです。なので、VirtualBoxを意識せずにvagrantで簡単インストールすることも可能です。ただ、vagrantは元々いろいろなPCに同じLinux環境をインストールしたい人が楽に出来るよう開発されたツールです。初心者が何が何だか分からないけど使うような、親切設計の便利ツールではありません。悪いことは言わないので、最初はVirtualBoxを直に使って環境に対する理解を深めることをオススメします。そうでないと問題が起きたときの対応が全く取れなくなります。慣れてからvagrantの恩恵に預かってください。便利さに心打たれます。

ダウンロード

Downloads – Oracle VM VirtualBox

ここから最新をダウンロードします。

インストール

ダウンロードしたインストーラをポチポチするだけでOKです(途中ドライバのインストールで署名関連の警告が出るが気にせずOKでいい)。難しいことはありません。

→PC内に仮想PCをもう一台起動することが出来るようになった

Linuxのインストール

VirtualBoxのおかげで、PC内に仮想PCをもう一台起動することが出来るようになりました。しかし、この仮想PCにも設定とOSのインストールという作業が必要になります。普通PCを買うとOSはプリインストールされた状態で納品されますが、元々素のPCにはOSなど入っていないのです。そこで、まずは仮想PCの作成とLinuxのインストールをします。

ディストリビューションの選定

Linuxのインストールをする前にディストリビューションを決めます。Linuxと一口に言っても、実はその種類であるディストリビューションが星の数ほどあるからです。しかし主要なディストリビューションを2つ挙げるとすると、Redhat(CentOS)とUbuntuです。日本で業務用に使う場合はRedhat(CentOS)が多いですが、個人用で使いやすいディストリビューションはUbuntuになります。オススメは個人用に扱いやすいUbuntuでLinuxに慣れるです。Redhatは仕事で必要になったらCentOSで勉強する、くらいでいいと思います。なので、ここでの選択もUbuntuです。

ダウンロード

Ubuntuを入手する | Ubuntu | Ubuntu

デスクトップ版かつサポート期間の長いLTS版をダウンロードします。本当はサーバー版の方が適切なのですが、GUIが全く使えないので、慣れてる人以外はデスクトップの方が扱いやすいです。サーバー版の方がGUIがない分軽くなります。

2020年2月2日現在、最新のLTSは18.04.3です。2020年4月には新しいLTSが出てくる予定ですが、出始めは不具合も多いので、初心者はリリース後2~3ヶ月経つまでは古いLTSで様子を見た方がいいかもしれません。

インストール

説明サイトが他にあるのでそちらに譲ります

VirtualBox6にLinux(Ubuntu18.04LTS)をインストールする方法

必要十分な情報があり、クライアントとして使う分には申し分ない環境が整います。が、1件だけ追加の設定が…GUIの日本語設定が足りません。

[左下のアプリケーションを表示する]の点々を左クリックします。すると、以下のような画面が出るので…

ちょっとスクロールして下の方にある「言語サポート」を押してください。アプリが起動して、以下のダイアログが出ます。

ここで、インストールを選択します。パスワードを聞かれるので入力すると日本語サポートがインストールされます。

閉じれば完了です。

Tips.1. Terminal起動ショートカット

デフォルトショートカット、左Ctrl+Alt+TでTerminalを起動出来ます。結構便利。

Tips.2. Windowsアプリの切り替えをしたい

Alt+TABでアプリの切り替えを出来ますが、これはUbuntu内の切り替えになります。
Windows側の切り替えをキーボードからしたい場合は、右Ctrlキーを一度押してからAlt＋TABでWindowsアプリを切り替えられます。

Tips.3. GUIが固まった。コマンドだけでも使えないか？

右Ctrl＋F1～F7でUbuntu内の仮想端末を切り替えられます。
GUI画面はそのうち1つなので、仮想PC自体が固まってなければ、別の仮想端末からログインすることでコマンドが使えます。
sshなどでリモートから操作できるようにするのも手です。

Tips.4. ターミナルでのコピー＆ペースト

WindowsだとCtrl+CとCtrl+Vでコピペですが、Linux GUIのターミナルだと基本はShift+Ctrl+CとShift+Ctrl+Vでコピペになります。
ようはShiftも押す必要があるということです。ターミナルだけですけどね。

まとめ

Windows上でUbuntuを同時に使えるようになりました。インストールしたUbuntuで動画を見ることも出来ますし、OpenGLも簡単なものならそれなりに動かすことが出来るはずです。サーバーとしての機能、ネットワーク系の設定は今回端折っていますが、次回sshとpostgresをインストールする際に説明予定です。

↓次回

sshサーバーのインストール

序

実際このサイトどうせほとんど人来ないんだし、大事なものは何1つ置いてないので、セキュリティとかあまり考える必要もないのですが、放置して踏み台とかになるんだとちょっと困ります。

検討

適当にセキュリティ関連のプラグインでも入れればいいのかなぁとも思うのですが、それも速度面とか気になるし、いうてそんなセキュリティが欲しいわけでもないのです。すごい人が集まっていて、個人情報などを溜め込んでるとか、何か他人様の認証用パスワードなど漏れては困るものがあるとか、そういう事情がないので、何か特別に強化する必要のあるセキュリティがない…Windowsで例えて言えば、 標準的なセキュリティであるWindows Updateがちゃんと当たっていて、乗っ取られさえしなければいいってことです。

方法

というわけで、当サイトでは、

Geekflare WP Security Scanner – Powered by WPScan

を使うことにしました。これはプラグインとかではなく、外部サイトです。セキュリティチェックしたいWordPressサイトのURLを貼って実行するだけで以下のような判定をしてくれます。

結果を信用するなら、少なくとも自分で調べるよりかなり楽できます。

Google Search Console

このサイトはGoogle Analyticsは入れてないのですが、サイトに何も入れずに済むGoogle Search Consoleで、Google検索からの流入は見ていました。

これがその画面です。なんと合計クリック数4。Google検索からは最大でも4人しか訪れてないってことです。検索で表示はしてくれてるみたいですし、コンテンツの問題だと一目で分かりますね。

ちなみにどんなページがクリックされてるのか？とか、検索キーワードが何だったのか？とか分かっちゃいます。このサイトであえてキーワードを選ぶとしたら、djangoとherokuだそうです。djangoはCGIでダメ出ししてるし、herokuも一度しか書いてないんですけどね。力入れてないのに出てくるってことは、恐らくその情報を欲してる人に対して供給してる人が少ないってことなんでしょうね。heroku+djangoの記事ならありかなぁとは思うので、そのうち書くかもしれません。

Google AdSense

そして僅かに2020年２月１日現在最大4人しか見てないであろうこのサイトに、広告であるGoogle AdSenseを導入しちゃいました。現在審査中です。せめて自分は審査結果に関係なく、たまにポチってあげようと思います。

目次を右側に付けたかったので付けてみたら、トップページに空白の目次がついてしまったので、これを誤魔化すのにも有効だったりします。

追記

審査通りました！

見積もり時点で0円。どんな広告が出るのか楽しみです。

概要

前回gitリポジトリを公開したけど、gitコマンドでclone/pull/push出来るだけで、httpsなのにブラウザから直接見ることが出来なかった。

今回はリポジトリに格納されてるソースをWebで直に見れるようにしてみる。

Web UIの選択

最大手は

• Gitea
• GitLab

の2つ。この辺になるともう見た目GitHubと遜色がないし、とても多機能。しかし、VALUE-SERVERのCGIでは動かない。そこで今回はVALUE-SERVERで最も力を入れてそうな「PHP」でgitのWeb UIを選んでみた。その結果…

GitList

を入れてみることにしました。

https://gitlist.org/

インストール

先のリンクからダウンロードは出来るものの、インストール方法はこちらの方が詳しい

https://github.com/klaussilveira/gitlist#installation

ダウンロード

最初のリンク先からダウンロード

展開

$ cd $HOME/public_html/(ドメイン)/
$ tar xvfz ダウンロードしたファイルのフルパス

キャッシュディレクトリの作成

$ cd gitlist
$ mkdir cache

設定ファイルの編集

$ cp -p config.ini-example config.ini

config.iniを以下のように編集

--- config.ini-example  2019-04-26 02:51:27.000000000 +0900
+++ config.ini  2020-01-31 10:15:55.815297245 +0900
@@ -1,7 +1,7 @@
 [git]
 client = '/usr/bin/git' ; Your git executable path
 default_branch = 'master' ; Default branch when HEAD is detached
-repositories[] = '/home/git/repositories/' ; Path to your repositories
+repositories[] = '(ホーム)/(リポジトリの場所)/' ; Path to your repositories
                                            ; If you wish to add more repositories, just add a new line
 
 ; WINDOWS USERS
@@ -28,10 +28,10 @@
 ssh_user_dynamic = false ; when enabled, ssh_user is set to $_SERVER['PHP_AUTH_USER']
 
 ; http remote
-show_http_remote = false ; display remote URL for HTTP
+show_http_remote = true ; display remote URL for HTTP
 http_host = '' ; host to use for cloning via HTTP (default: none => uses gitlist web host)
 use_https = true ; generate URL with https://
-http_url_subdir = 'git/' ; if cloning via HTTP is triggered using virtual dir (e.g. https://example.com/git/repo.git)
+http_url_subdir = 'gitrepos/git-http-backend.cgi/' ; if cloning via HTTP is triggered using virtual dir (e.g. https://example.com/git/repo.git)
                     ; has to end with trailing slash
 http_user = '' ; user to use for cloning via HTTP (default: none)
 http_user_dynamic = false ; when enabled, http_user is set to $_SERVER['PHP_AUTH_USER']

確認

以下に設置されたことになる。

https://elephantcat.work/gitlist/

動いてるみたい。

VALUE SERVERでは動いてましたが、今はConoHa VPSに移行し、Giteaを導入したので消しています。

https://git.elephantcat.work/

概要

apache2.2で.htaccessしか使えない状況での設定で手間取りましたが、VALUE-SERVERでgitリポジトリを公開することが出来たので、その方法を記事にしました。本来こういう用向きはGitHubでいいのですが、やっぱりやってみたいでしょ？

なお、今回はgitコマンドで扱えるhttpsのリポジトリを作成するところまでで、WebUIの設定は次回予定です。

設定の検討

今回はGitのマニュアルをベースに設定を検討していきます。

Smart HTTPで公開

Git – Smart HTTP

Gitのリポジトリ公開方法は、2020年1月31日現在、gitプロトコル、ssh、httpの3種類で、httpはさらにdum/smartの2種類に分かれます。gitプロトコルはVALUE-SERVERでは使えないし、sshだと公開してもVALUE-SERVER上ではアカウント作れないので自分しか使えません。 今回はhttpのより洗練されたsmartで公開する、ということです。

Apache自体のインストール

マニュアルではここからやっているのですが、これはVALUE-SERVERでは出来ません。

$ sudo apt-get install apache2 apache2-utils
$ a2enmod cgi alias env rewrite

https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-Smart-HTTP

最初に行っているのはdebian系Linuxでのapache2とapache2-utilのインストールです。apache2相当は絶対にインストールされてます。apache2-utilは、恐らくhtpasswdコマンドをインストールするためだと思うので、これはVALUE-SERVERにも入っており、問題ありません。

次に行っているのは、mod_cgi、mod_alias、mod_env、mod_rewriteなどのモジュールの有効化です。これらもVALUE-SERVERで有効になってます。apachectl -Mで確認できるので、気になる人はやってみてください。

つまりApache自体のインストールについては、すでにやってあるので問題ないということです。

gitリポジトリの所有グループ変更

次にやってるのはリポジトリ内のファイル・ディレクトリの所有グループ変更です。

$ chgrp -R www-data /opt/git

https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-Smart-HTTP

これはapacheからリポジトリを読み書きするために必要なことなのですが、VALUE-SERVERの設定では、ユーザーが扱える$HOME/public_html/*のファイルを実行するときにユーザーのアカウントで実行されるため設定の必要がありません。逆に言うとWebから自分のアカウントで出来ることは何でも出来るということなのですが…そういうセキュリティのプランなのです。

Apache の設定

いよいよ本題に近付いてきました。マニュアルで次に記載があるのは、httpd.confとかapache2.confやその分散された設定ファイルの内容です。これはディストリビューションごとにファイル名やディレクトリ構成が違いますが、そもそも管理者権限のないレンタルサーバでは変更できない部分です。

SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-Smart-HTTP

これらは、ユーザーが唯一編集可能な設定ファイルである、.htaccessで記述する必要があります。内容とともに解説すると…

SetEnvは環境変数を設定するもの(ディレクティブ)です。ここではGIT_PROJECT_ROOT(リポジトリの場所)とGIT_HTTP_EXPORT_ALL( GIT_PROJECT_ROOT以下のリポジトリを全て公開する意思表示)を設定しています。これらは.htaccessに記載が可能であり、またVALUE-SERVERではOverrideが許可されている(つまり普通に使える)ので問題ありません。

ScriptAliasは、スクリプトの位置とURLの紐付けを行うもの(ディレクティブ)です。これは.htaccessには記載できないので、代替手段が必要になります。

ScriptAliasの代替

今回の設定は、URLパスとして/git/以下でアクセスされた場合に、/usr/lib/git-core/git-http-backendが処理をし、環境変数PATH_INFOに/git/をルートとしたパスが入るということを意味します。git-http-backendはgitパッケージに付属するコマンドで、VALUE-SERVERにも /usr/libexec/git-core/git-http-backend に入っています。ユーザーがWebから直接 git-http-backend を処理させる手段はありませんが、CGIスクリプトから呼び出すことは可能です。ということはつまり、$HOME/public_html/ドメイン/git ディレクトリの.htaccessに以下の記述を入れて、

AddHandler cgi-script .cgi

git-http-backend.cgiという名前で

#!/bin/sh
/usr/libexec/git-core/git-http-backend

とすれば、 URLパスとして/git/git-http-backend.cgi/以下でアクセスされた場合に、/usr/libexec/git-core/git-http-backendが処理をし、環境変数PATH_INFOに/git/git-http-backend.cgi/ をルートとしたパスが入る、を実現できます。

BASIC認証の設定

マニュアルで次に行っているのはBASIC認証の設定です。

RewriteEngine On
RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED]

<Files "git-http-backend">
    AuthType Basic
    AuthName "Git Access"
    AuthUserFile /opt/git/.htpasswd
    Require valid-user
    Order deny,allow
    Deny from env=AUTHREQUIRED
    Satisfy any
</Files>

解説

1. Rewriteを有効にします
2. URLのクエリ文字列(?以降の部分)が"service=git-receive-pack"である場合、もしくは
3. URLのパス文字列が"/git-receive-pack"で終わっている場合
4. URLのパス文字列が"/git/"で始まっているなら環境変数AUTHREQUIREDを設定する
5. ファイルシステム内のファイル名がgit-http-backendである場合
   1. 認証方式をBASIC認証とする
   2. realmを"Git Access"とする
   3. BASIC認証のパスワードを/opt/git/.htpasswdから読むものとする
   4. ユーザーの認証を「必要」とする
   5. 全てを許可した上で、Deny処理→Allow処理の順で処理する
   6. 環境変数 AUTHREQUIRED が設定されていたらDenyする
   7. Allowされているか、「必要」を満たせばアクセスを許可する

つまり git-http-backendで処理するケースでは、「URLのクエリ文字列(?以降の部分)が"service=git-receive-pack"である」か「URLのパス文字列が"/git-receive-pack"で終わっている」場合はBASIC認証を要求し、それ以外の場合は無条件にアクセスを許可するという設定。ようはgit cloneやpullなど読み取りは無条件アクセスで、git pushなど書き込みはBASIC認証を付けたいということ。

VALUE-SERVERでの対応検討

この部分は全て.htaccessに記述可能です。しかし、VALUE-SERVERのapache2.2では期待したとおりに機能しません。理由は以下の記事のとおりです。

Apache設定ファイルのRewriteRuleとDenyの適用順番

ようは、適用順番のせいで「環境変数 AUTHREQUIRED が設定されていたらDenyする」が機能しないということなので、常に「無条件にアクセスを許可するという設定」になってしまいます。さすがに認証なしで無制限に書き込みが出来てしまったら何が起きるか分かりません(デフォルトでは無条件にアクセスしても書き込みはエラー(403)になりますが)。

RewriteでダメならSetEnvIfではどうか？

Rewriteは主にリダイレクトや、読み替え、つまりURLの書き換えに似た機能です。しかし、今回はURLの書き換えは行っておらず、HTTPリクエストのパラメータを解析してBASIC認証の必要判定を環境変数に入れたいだけです。であれば、SetEnvIfでも出来そうな気がしますが…しかしSetEnvIfではQUERY_STRINGパラメータを扱えません。今回の用件では使用できないということです。

じゃあQUERY_STRINGを使わない方法はないの？

ありました。

If you do not have mod_rewrite available to match against the query string, it is sufficient to just protect git-receive-pack itself, like:

https://git-scm.com/docs/git-http-backend

<LocationMatch "^/git/.*/git-receive-pack$">
 AuthType Basic
 AuthName "Git Access"
 Require group committers
 ...
</LocationMatch>

BASIC認証をするタイミングは遅れますが、これでもpushなど書き込みに制限付けられます。ただし、

In this mode, the server will not request authentication until the client actually starts the object negotiation phase of the push, rather than during the initial contact. For this reason, you must also enable the http.receivepack config option in any repositories that should accept a push. The default behavior, if http.receivepack is not set, is to reject any pushes by unauthenticated users; the initial request will therefore report 403 Forbidden to the client, without even giving an opportunity for authentication.

https://git-scm.com/docs/git-http-backend

遅れた分のアクセスはデフォルトだとエラーになるので、 git-http-backendには「認証してなくてもエラーにしない設定」(http.receivepack)にする必要があります。apacheが許可したらOKということです。

ただURLとのマッチングを行うLocationMatchセクションは.htaccessでは使用できません。

解: LocationMatchをSetEnvIfで置き換える

こうしてしまえばいいのです。

SetEnvIf Request_URI "/git-receive-pack$" AUTHREQUIRED=yes
AuthType Basic
AuthName "Git Access"
Require group committers
...
Order deny,allow
Deny from env=AUTHREQUIRED
Satisfy any

これが今回使用した方法の骨子になります。

パスワードの設定

マニュアルの続きです。htpasswd -c パスワードファイル ユーザー名 して、パスワードファイルを作成して認証可能なユーザーを1人作ってるだけです。 htpasswdの使い方はそこら中にあるので各自で調べてください。

実際の設置方法

URIのベースとなるディレクトリを決めて作成

マニュアルだと/git/になっていた部分ですね。そのまま使うと悪戯されそうなので、ちょっと変えました。

$ cd $HOME/public_html/(ドメイン名)/
$ mkdir gitrepos

.htaccessの設置

$HOME/public_html/(ドメイン名)/gitrepos/に以下の.htaccessを置きました。

SetEnv GIT_PROJECT_ROOT (ホーム)/(リポジトリの設置場所)
SetEnv GIT_HTTP_EXPORT_ALL
AddHandler cgi-script .cgi

SetEnvIf Request_URI "/git-receive-pack$" AUTHREQUIRED=yes

Order Deny,Allow
Deny from env=AUTHREQUIRED
AuthType Basic
AuthName "Git Access"
AuthUserFile (ホーム)/(リポジトリの設置場所)/.htpasswd
AuthGroupFile /dev/null
Require valid-user
Satisfy Any

CGIスクリプトの設置

$HOME/public_html/(ドメイン名)/gitrepos/に以下のgit-http-backend.cgiを置きました。

#!/bin/sh
/usr/libexec/git-core/git-http-backend

実行可能属性を付けておきます。

$ cd $HOME/public_html/(ドメイン名)/gitrepos/
$ chmod u+x git-http-backend.cgi

gitリポジトリの作成

このディレクトリはセキュリティ上の理由から、$HOME/public_html/(ドメイン名)/ 配下には置きません。ここでは $HOME/(リポジトリの設置場所)/に複数のリポジトリを置くものとし、今回はsample1という名前のリポジトリを作成します。

$ mkdir -p $HOME/(リポジトリの設置場所)
$ cd $HOME/(リポジトリの設置場所)
$ mkdir sample1
$ cd sample1
$ git init --bare
$ git config http.receivepack true

最後のコマンドが、「認証してなくてもエラーにしない設定」をしています。今回の認証方式を使う場合は、公開リポジトリを作成する度に必要な操作になります。

パスワード認証ファイルの作成

$ cd $HOME/(リポジトリの設置場所)
$ htpasswd -c .htpasswd ユーザー名
$ chmod og-rwx .htpasswd

ユーザーは必要な数だけ作成してください。VALUE-SERVERでは、パスワード認証ファイルは自分以外読めない設定で十分です。

最後に

BASIC認証はパスワードが暗号化されません。必ずhttpsでアクセスするようにしてください。

公開リポジトリへの接続確認

早速リポジトリにアクセスしてみます。

$ git clone https://(ドメイン名)/gitrepos/git-http-backend.cgi/sample1
Cloning into 'sample1'...
warning: You appear to have cloned an empty repository.
$ 

取得成功したようです。それでは適当に何かcommitしてpushしてみます。

$ cd sample1
$ touch hoge
$ git add .
$ git commit -m "initial commit."
[master (root-commit) 23b1fde] initial commit.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 hoge
$ git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 205 bytes | 205.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
Username for 'https://(ドメイン名)': (htpasswdで設定したユーザー名)
Password for 'https://(ユーザー名)@(ドメイン名)': (htpasswdで設定したパスワード)
To https://(ドメイン名)/gitrepos/git-http-backend.cgi/sample1
 * [new branch]      master -> master
$

pushの途中でちゃんとBASIC認証が入り、pushできました。

→成功

2021/6/15 追記

現在はVALUE SERVERからConoHa VPSに移行し、SmartGitによるhttpsでのリポジトリ公開はしておりません。代わりにGiteaで公開しています。

前回の Apache設定ファイルのSetEnv/SetEnvIf適用順番 と似たような記事です。

確認したいこと

VALUE-SERVERの現行Apache 2.2の.htaccessで、RewriteRuleとDenyの適用順番を確認したい

実験

まずはやってみる

.htaccess

RewriteCond REMOTE_ADDR .*
RewriteRule .* - [E=HOGE:deny]
Order Deny,Allow
Deny from env=HOGE

解説

1. クライアントのIPアドレスが正規表現で.*であるかどうか？＝全てに一致するので、常に条件を満たす
2. .htaccessの置いてあるディレクトリ部分を除いたURLのパス指定部分が正規表現で.*である部分(つまり全て)を無変更とし、環境変数HOGEに値denyを設定する
3. Orderはまず全てをAllowとした上で、Deny処理を適用後に、Allow処理を入れるという宣言
4. 環境変数HOGEが設定されていたら全てDenyとする

つまり、記述された順番どおりに適用されるなら、全て403 Forbiddenにするという設定

結果

こちら(VALUE SERVER上なのでConoHaに移行した現在はない)に上記.htaccessを置いたが、200 OKで見えてしまっていた。RewriteRuleの適用順序がDenyよりも遅い可能性が高まった。

RewriteRuleで環境変数を設定できていることの確認

.htaccess

RewriteCond REMOTE_ADDR .*
RewriteRule .* - [E=HOGE:deny]
Header set X-Frame-Options %{HOGE}e env=HOGE

解説

前回記事とあわせて全て説明されているので詳細は省略。環境変数経由でHTTPレスポンスヘッダX-Frame-Optionsにdenyを設定している。

結果

こちら(VALUE SERVER上なのでConoHaに移行した現在はない)に上記.htaccessを置いたが、Chromeの開発者ツールのネットワークで、以下のレスポンスが確認できた。

HTTP/1.1 200 OK
...
X-Frame-Options: deny
...

つまり、RewriteRuleの記述に問題はない→最初の実験の設定では、RewriteRuleより先にDenyが評価されている。

DenyをFilesMatchセクションに置いたら、評価が遅くならないか確認

.htaccessで置けるセクションとしてはFileかFilesMatchだと思うので、その条件で最初の実験を再確認する。

.htaccess

RewriteCond REMOTE_ADDR .*
RewriteRule .* - [E=HOGE:deny]
<FilesMatch ".*">
Order Deny,Allow
Deny from env=HOGE
</FilesMatch>

解説

FilesMatchは、ファイルシステムベースでのファイル名でマッチングをかけるセクション。このケースではどんなファイル名でも該当する。なので最初の実験と内容は同じ。

結果

こちら(VALUE SERVER上なのでConoHaに移行した現在はない)に上記.htaccessを置いたが、最初の実験同様見えてしまっている。こう書いてもRewriteRuleの適用順序がDenyよりも遅い 。

結論

VALUE-SERVERの現行Apache 2.2の.htaccessでは、Deny→RewriteRuleの順で適用される。

※Apacheが2.4だったり、server configに記載された場合などは確認していない

2020年1月30日現在、ココVALUE-SERVERで使用されているapache2.2(古い)で.htaccessを使っていろいろな設定が出来る。出来るけど、その設定には適用順番があるって話(2.4でも同様)。

事の発端

SetEnv HOGE "deny"
Order Deny,Allow
Deny from env=HOGE

この.htaccessが置かれたディレクトリが見えてしまう。論より証拠がこちら(VALUE SERVER上なのでConoHaに移行した現在はない)。

参考リンクに置いたapacheのドキュメントに従って解説を入れると、

1. SetEnvは環境変数HOGEに値denyを設定している
2. Orderはまず全てをAllowとした上で、Deny処理を適用後に、Allow処理を入れるという宣言
3. Denyは環境変数HOGEが設定されていたら、全部Denyとするという意味

つまり、「書かれた順番どおりに処理されたなら、この.htaccessが置かれたディレクトリでは全て403 Forbiddenになるはず」ということ。しかし200 OKで見えてしまっているわけです。

いろいろ疑い調べましたが、日本語の2.2のマニュアルには記載がありませんが、英語の2.2以降のマニュアルと、日本語の2.4以降のマニュアルに、

SetEnv はリクエスト処理の 段階の中でも遅くに実行されます。つまり SetEnvIf や RewriteCond などからは、変数がそこで設定されていることがわかりません。

https://httpd.apache.org/docs/2.4/ja/env.html#setting

という、よ～く読み漁らないと見つからない記述を見つけました。2.2の日本語版ではどれだけ読み漁っても見つかりませんけど…。

で、「それ本当なの？」「本当ならどう書けばいいの？」というのを読み解くのが今回のミッションです。

実験

そもそもSetEnv出来てるの？

SetEnvの成功例が必要です。確認できたのが、こちらの.htaccessになります。

SetEnv HOGE "deny"
Header set X-Frame-Options %{HOGE}e env=HOGE

解説

1. 環境変数HOGEに値denyを設定する
2. 環境変数HOGEが設定されていたら、HTTPレスポンスヘッダのX-Frame-Optionsに環境変数HOGEの内容を設定する

結果

こちらのリンク先(VALUE SERVER上なのでConoHaに移行した現在はない)のディレクトリに当該.htaccessを置いています。Chromeなどの開発者ツールでNetworkモニタリングしつつ、リンク先を読み込めば、HTTPプロトコルのレスポンスヘッダを見ることで分かります。

HTTP/1.1 200 OK
...
X-Frame-Options: deny
...

SetEnv自体は出来てますね。成功です。つまり処理順序の問題であるという可能性が高まりました。

じゃあDeny fromは出来てるの？

次はDeny fromの成功例が必要です。環境変数パターンは試せてませんが、.htaccessでAllow/Deny設定を上書き可能かどうかはApacheの設定次第なので、確認が必要ということです。確認用の.htaccessが以下です。

Order Deny,Allow
Deny from All

解説

1. Orderはまず全てをAllowとした上で、Deny処理を適用後に、Allow処理を入れるという宣言
2. 全てをDenyする

つまり、「この.htaccessを含むディレクトリ以下は全て403 Forbiddenになる」という設定です。

結果

こちらのリンク先(VALUE SERVER上なのでConoHaに移行した現在はない)のディレクトリに当該.htaccessを置いています。 辿れば分かりますが、403になります。置かれてるファイルはいつものsample.htmlです。

SetEnvIfとSetEnvの処理順序確認

記述内容の確認になります。SetEnvIfからSetEnvの結果を参照して本当にうまく動作しないかどうかを見ます。確認用.htaccessが以下になります。

SetEnv HOGE "deny"
SetEnvIf HOGE "deny" HOGECHILD=deny
Header set X-Frame-Options %{HOGECHILD}e env=HOGECHILD

解説

1. 環境変数HOGEに値denyを設定する
2. 環境変数HOGEの値がdenyだったら、環境変数HOGECHILDに値denyを設定する
3. 環境変数HOGECHILDが設定されていたら、HTTPレスポンスヘッダX-Frame-Optionsに環境変数HOGECHILDの値を設定する

結果

こちらのリンク先(VALUE SERVER上なのでConoHaに移行した現在はない)のディレクトリに当該.htaccessを置いています。Chromeなどの開発者ツールでNetworkモニタリングしつつ、リンク先を読み込めば、HTTPプロトコルのレスポンスヘッダを見ることで分かります。

HTTP/1.1 200 OK
Date: Wed, 29 Jan 2020 23:38:37 GMT
Server: Apache
Last-Modified: Wed, 29 Jan 2020 21:28:41 GMT
ETag: "1581901-31-59d4e063ccc5b"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 61
Connection: close
Content-Type: text/html

X-Frame-Optionsヘッダの出力がありません。確かにうまく動作しておらず、SetEnvIfがSetEnvより処理が早い可能性が高まります。

SetEnvIfは単体なら動くの？

単体で機能するなら、処理順序で確定します。確認用.htaccessが以下になります。

SetEnvIf Remote_Addr ".*" HOGE=deny
Header set X-Frame-Options %{HOGE}e env=HOGE

解説

1. クライアントIPアドレスRemote_Addrの値が正規表現で".*"にマッチしたら、環境変数HOGEに値denyを設定する(何でもマッチするので、必ず設定される)
2. 環境変数HOGEが設定されていたら、HTTPレスポンスヘッダX-Frame-Optionsに環境変数HOGEの値を設定する

結果

こちらのリンク先(VALUE SERVER上なのでConoHaに移行した現在はない)のディレクトリに当該.htaccessを置いています。Chromeなどの開発者ツールでNetworkモニタリングしつつ、リンク先を読み込めば、HTTPプロトコルのレスポンスヘッダを見ることで分かります。

HTTP/1.1 200 OK
...
X-Frame-Options: deny
...

X-Frame-Optionsヘッダの出力されています。単体なら確かにうまく動作しており、SetEnvIfがSetEnvより処理が早いことが確定しました。

SetEnvの代わりにSetEnvIfにしてみる

最後にどうすればいいの？の回答です。.htaccessが以下になります。

SetEnvIf Remote_Addr .* HOGE=deny
Order Deny,Allow
Deny from env=HOGE

新しい要素がないので解説は省略

結果

こちらのリンク先(VALUE SERVER上なのでConoHaに移行した現在はない)のディレクトリに当該.htaccessを置いています。 辿れば分かりますが、403になります。置かれてるファイルはいつものsample.htmlです。

参考リンク

• https://httpd.apache.org/docs/2.2/ja/
• https://httpd.apache.org/docs/2.2/en/
• https://httpd.apache.org/docs/2.4/ja/

前回HTML内でJavaScriptを書いてみたらハイライトされなくて、おかしいな〜と調べてたら3件不具合を見つけた。

不具合

HTML内のJavaScriptなどをハイライトできない場合がある

現象

記事内にシンタックスハイライターを単独で置き、HTML内にJavaScriptを記述した上で言語をHTML/XHTMLにしておくと、JavaScriptがハイライトされない。

原因

HTMLのハイライトを行う(prism-)markup.jsとJavaScriptのハイライトを行う(prism-)javascript.jsの読み込み順序が逆であるため。依存されているjsが後に読み込まれる必要がある。

JavaScriptなのにJava用のハイライタまで読み込まれる

現象

読み込みがごくごく僅かに遅くなるだけだが、わざわざ言語別に必要ハイライタだけ読み込んでるからもったいない

原因

言語指定の先頭4文字がjavaかで判断しているため、javascriptまでjavaと勘違いされた

JavaScriptのハイライタが2回読み込まれる場合がある

現象

読み込みがごくごく僅かに遅くなるだけだが、わざわざ言語別に必要ハイライタだけ読み込んでるからもったいない

原因

JavaScript単体で言語指定された場合と、依存言語として他の言語指定から読み込まれる場合に、別の言語指定文字列が使われているため(highlight-javascriptとjavascript)、重複して読み込まれる

対策

パッチを作成した。

diff --git a/inc/load-inline.php b/inc/load-inline.php
index cc707c5..3374c70 100644
--- a/inc/load-inline.php
+++ b/inc/load-inline.php
@@ -51,10 +51,14 @@ function thk_highlighter_load( $loads, $list, $active ) {
 
 		// Javascript
 		foreach( $list as $key => $val ) {
-			if( strpos( $post->post_content, '<code class="language-' . str_replace( 'highlight_', '', $key ) ) !== false ) {
+			if( strpos( $post->post_content, '<code class="language-' . str_replace( 'highlight_', '', $key ) . '"' ) !== false ) {
 				$lang = str_replace( 'highlight_', '', $key );
 
-				if( !isset( $loads[1][$key] ) ) {
+				if( !isset( $loads[1][$lang] ) ) {
+					// 言語ごとの読み込み
+					$loads[0] .= thk_fgc( $jsdir . $lang . '.js' );
+					$loads[1][$lang] = true;
+
 					/*
 					 * 他言語の依存チェック
 					*/
@@ -114,10 +118,6 @@ function thk_highlighter_load( $loads, $list, $active ) {
 						$loads[0] .= thk_fgc( $jsdir . 'sql.js' );
 						$loads[1]['sql'] = true;
 					}
-
-					// 言語ごとの読み込み
-					$loads[0] .= thk_fgc( $jsdir . $lang . '.js' );
-					$loads[1][$key] = true;
 				}
 			}
 		}

保管場所は以下。

Luxeritasパッチ置き場

Luxeritas作者様に報告させて頂きました。次バージョンで対応して頂けるとのお話なので、個々にパッチを当てる必要はないと思います。

2020年2月2日にリリースされたLuxeritas3.7.8本体で、対応されたことを確認しました。なので以降本件のパッチリリースはありません。

2020年2月3日本パッチには、ほとんどの言語でハイライトできなくなるという重大な不具合が発見されました?。
同日にリリースされたLuxeritas3.7.8.2で作者様が対応してくれております。詳細は↓で。

?祝！Luxeritas 3.7.8リリース?

UI系JavaScriptの記事なら動かせてもいいなぁと思って実験してみました。

カスタムHTMLブロックを使う

以下のVueのサンプルコードを動かしてみる。

<script src="https://cdn.jsdelivr.net/npm/vue"></script>
<div id="app-5">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">Reverse Message</button>
</div>
<script type="text/javascript">
var app5 = new Vue({
  el: '#app-5',
  data: {
    message: 'Hello Vue.js!'
  },
  methods: {
    reverseMessage: function () {
      this.message = this.message.split('').reverse().join('')
    }
  }
})
</script>

これをカスタムHTMLブロックに貼り付けた結果が以下。

結果

動いてるみたい。

ここでは、本サイトで実施しているDBのみの手作業移行について解説します。簡単で、用途もデバッグ用なので、方法も適当です。

目的

DBのデータを運用しているサイトからlocalデバッグ環境に移行する

方針

ファイルはgitで管理されているので、DB内のデータのみ移行したいということです。プラグインを使うと、ファイルまで一緒についてきたり、サーバに余計なプラグインを設置しないといけなくなります。ローカルでサーバと同じデータを使ってデバッグ/テストしたいという目的であれば、DBの内容だけ適当にコピーできれば良く、できればコマンド一発で簡単にやりたいというわけです。

mysqlのデータをVALUE SERVER上でファイルに落とす

VALUE SERVER上で以下のスクリプト($HOME/bin/hoge.sh)を使うと、標準出力に、圧縮したWordPress関連のテーブルデータを全て出力できます。

#!/bin/sh
TABLES="wp_commentmeta wp_comments wp_links wp_options wp_postmeta wp_posts wp_term_relationships wp_term_taxonomy wp_termmeta wp_terms wp_usermeta wp_users"
mysqldump --user=$USER -p $USER $TABLES | gzip

実行すると、MySQLのパスワードが聞かれます。このファイルには実行可能属性を付けておきます。

$ chmod u+x $HOME/bin/hoge.sh

なお、使用しているコマンドのmysqldumpはあまり早くない汎用性の高いコマンドです。大量のデータがあって、いつまで経っても終わらない場合は別の方法にすべきです。このサイトは2020年1月23日現在圧縮して1MBに満たないサイズです。

ローカル環境から直接ファイルに落とす

上のスクリプトと、前回整えたsshの公開鍵認証を使って、ローカル環境から直にVALUE SERVER上のMySQLデータをファイルに落とすことができます。以下がそのコマンドです。

$ echo (MySQLパスワード) | ssh xxxxxxxx@xx.valueserver.jp ./bin/hoge.sh > mysqldat.gz

リダイレクトを使うことで、暗号化された経路でコマンドに履歴を残したり、一時ファイルを作成することなく、綺麗にデータを落とすことができています。さらに、VALUE SERVER上のhoge.shすら使用しないローカルスクリプト(export_db.sh)も書いてみました。

#!/bin/sh
SSH_USER="xxxxxxxx"
SSH_SERVER="xx.valueserver.jp"
MYSQL_PASSWD="yyyyyyyyy"
TABLES="wp_commentmeta wp_comments wp_links wp_options wp_postmeta wp_posts wp_term_relationships wp_term_taxonomy wp_termmeta wp_terms wp_usermeta wp_users"
OUTFILE=mysql.dat.gz
echo $MYSQL_PASSWD \
    | ssh $SSH_USER@$SSH_SERVER "mysqldump --user=$SSH_USER -p $SSH_USER $TABLES | gzip" > $OUTFILE

完成したタイミングでVALUE SERVER上のhoge.shは削除しました。sshは痕跡をあまり残さず何でも出来て便利だけど、ここが乗っ取られたら大変なことになることがよく分かります。

落としたファイルをローカルDBに流し込む

今回流し込むローカルDBは以前書いた記事のものを使います。

Docker WordPressのローカルデバッグ環境構築

まずはdockerを起動して

$ docker-compose up

その後、以下のスクリプト(import_db.sh)で取り込みます。

#!/bin/sh
MYSQL_DB="exampledb"
MYSQL_USER="exampleuser"
MYSQL_PASSWD="examplepass"
CONTAINER="docker_db_1"
OUTFILE="mysql.dat.gz"
gzip -dc $OUTFILE | docker exec -i $CONTAINER mysql --default-character-set=utf8 -D $MYSQL_DB -u $MYSQL_USER --password=$MYSQL_PASSWD
docker exec -i $CONTAINER mysql --default-character-set=utf8 -D $MYSQL_DB -u $MYSQL_USER --password=$MYSQL_PASSWD <<EOF
update wp_options set option_value='http://localhost' where option_name in ('siteurl', 'home');
commit;
EOF

実行時にパスワードが引数で渡されることに警告が出ますが、デバッグ用の環境で固有名詞は適当なので、気にしないことにします。

また、取り込んだ後にSQLのUpdate文でWP_OPTIONテーブルを修正していたりもします。しかしその部分も最低限で、リンクなどの修正やその他の細かい変更もしていません。これらは運用サイトの状態をなるべく変えないことを意図しています。

まとめ

dockerが起動していれば、ローカルでexport_db.shとimport_db.shを実行するだけでVALUE SERVERのデータを取り込むことが出来た。