しばたテックブログ

気分で書いている技術ブログです。

VisualSVN Server上のApacheでTracを動かしてみる

非常にレガシーなはなしです。

Trac Lightningからの移行をどうしようか悩んだ末に検証した内容なのですが、おそらくこれを本番環境で採用する事はないと思います。*1

一応最低限の動作を確認したので備忘録としてエントリを残しておきます。

0. はじめに

本エントリの前提としては、

  • Windows Server上のSubversionでソース管理をする
  • 小規模なオンプレ環境

となります。
Trac Lightningからの移行だけを考えるのであれば、Windowsを捨てる、Subversionを捨てる、Tracを捨てるというのが割と現実解になりますが、本エントリではその点は考えないことにします。

検証環境

検証環境は以下となります。

  • Windows Server 2012 R2
    • インストール直後の状態に最新のWindows Updateを適用した状態
  • Windows PowerShell 4.0
    • デフォルトでインストールされているPowerShellをそのまま使います

試していませんが、Windows Server 2016でも問題はないかと思います。
試しました。Windows Server 2016+PowerShell 5.1でも本手順は動作します。

1. VisualSVN Serverのインストール

SubversionサーバーとしてVisualSVN Serverを採用します。
バージョンは現時点で最新のVer.3.6.3にします。

こちらはGUIのインストーラーからインストールしても構わないのですが、面倒なのでPowerShellから以下の様にしてサイレントインストールします。

# Install VisualSVN Server
$VISUALSVN_VER = '3.6.3'
$VISUALSVN_INSTALL_PATH = 'C:\Program Files\VisualSVN Server'
Invoke-WebRequest -Uri "https://www.visualsvn.com/files/VisualSVN-Server-$($VISUALSVN_VER)-x64.msi" -OutFile "$(Get-Location -PSProvider Filesystem)\VisualSVN-Server-$($VISUALSVN_VER)-x64.msi"
Start-Process -FilePath "msiexec.exe" -ArgumentList @('/i', "$(Get-Location -PSProvider Filesystem)\VisualSVN-Server-$($VISUALSVN_VER)-x64.msi", '/qb', "INSTALLDIR=""$VISUALSVN_INSTALL_PATH""", 'USE_SSL=1', 'ADDLOCAL=Server,Manager,AddSvnToPath') -Wait -PassThru

このインストールでは、

  • インストール先 : C:\Program Files\VisualSVN Server
  • インストール対象 :
    • VisualSVN Server - Standard Edition
    • Administration Tools
    • コマンドラインのPATHを追加

のインストールを行います。

インストール後の設定として、今回は認証方式をWindows認証とし、ローカルAdministratorをなんでもできるユーザーにしておきます。

# PowerShellを再起動していれば、Import-Module VisualSVNとしても良い
Import-Module (Join-Path $VISUALSVN_INSTALL_PATH "PowerShellModules\VisualSVN")
# 認証方式をWindowsn認証に
Set-SvnServerConfiguration -AuthenticationMode Windows
# ローカルAdministratorの権限設定
Add-SvnAccessRule -Global -AccountName "$(hostname)\Administrator" -Access ReadWrite

また、必要があれば以下の様にしてサンプルのリポジトリを作成することも可能です。

# 必要があればリポジトリを作成
New-SvnRepository -Name SampleProject
New-SvnRepositoryItem -Repository SampleProject -Path ('/branches', '/tags', '/trunk') -Type Folder

これでVisualSVN Serverのインストールと設定は完了です。
この時点でふつうにVisualSVN Serverに対してWebアクセスできます。

f:id:stknohg:20170803185941p:plain

2. Pythonのインストール

www.python.org

Tracを動作させために、先ずはPythonをインストールします。

Tracは未だにPython3系に対応していないため、Python 2.7.13をインストールします。
こちらもPowerShellから以下の様にサイレントインストールします。

# Install Python
$PYTHON_VER = '2.7.13'
$PYTHON_INSTALL_PATH = 'C:\Python27'
Invoke-WebRequest -Uri "https://www.python.org/ftp/python/$($PYTHON_VER)/python-$($PYTHON_VER).amd64.msi" -OutFile "$(Get-Location -PSProvider Filesystem)\python-$($PYTHON_VER).amd64.msi"
Start-Process -FilePath "msiexec.exe" -ArgumentList @('/i', "$(Get-Location -PSProvider Filesystem)\python-$($PYTHON_VER).amd64.msi", '/qb', "TARGETDIR=""$PYTHON_INSTALL_PATH""", 'ALLUSERS=1', 'ADDLOCAL=ALL') -Wait -PassThru
# PowerShellを再起動しない場合はPATHを追加しておく
$env:PATH = $env:PATH + ";$PYTHON_INSTALL_PATH;$(Join-Path $PYTHON_INSTALL_PATH "Scripts")"

このインストールでは、

  • インストール先 : C:\Python27
  • インストール対象 : すべてのオプション

のインストールを行います。

3. Tracのインストール

The Trac Project

ここからTracをインストールし、VisualSVN Server上のApacheで動作させます。

3-1. Tracのインストール

pipからTrac(+Genshi)、Babelをインストールします。
Tracのバージョンは現時点の安定板であるVer.1.2.2とします。

# 一応Tracのバージョンを指定してインストール。同時にGenshiもインストールされる。
pip install Trac==1.2.2
pip install Babel

ここで理由は不明なのですが、util\__init__.pyファイル内で、ctypes.windll.kernel32.MoveFileTransactedWを呼び出すとエラーとなってしまったのでMoveFileTransactedに置換するパッチを当てておきます。
環境によってはこのパッチは不要かもしれません。

$PYTHON_INSTALL_PATH = 'C:\Python27'

# Trac 1.2.2用パッチ
# ※Windows Server 2016だとこのパッチ無しでもエラー無く動作しました。  
& {
    $SitePackagesDir = Join-Path $PYTHON_INSTALL_PATH "Lib\site-packages\"
    $InitFilePath = Join-Path $SitePackagesDir "trac\util\__init__.py"
    Copy-Item $InitFilePath "$($InitFilePath).orig"
    (Get-Content -LiteralPath $InitFilePath -Raw) -replace 'MoveFileTransactedW','MoveFileTransacted' | Set-Content -LiteralPath $InitFilePath
}

3-2. デフォルトプロジェクトの作成

続けてデフォルトのサンプルプロジェクトを作成し、VisualSVN Server上のApacheにデプロイします。
プロジェクト名はSampleProject、作成先はC:\Projcets\Tracとしています。

$VISUALSVN_INSTALL_PATH = 'C:\Program Files\VisualSVN Server'

# デフォルトのプロジェクトを作成
$TRAC_PROJECT_ROOT_PATH = 'C:\Projcets\Trac'
$TRAC_DEFAULT_PROJECT_NAME = 'SampleProject'
$TRAC_DEFAULT_PROJECT_PATH = Join-Path $TRAC_PROJECT_ROOT_PATH $TRAC_DEFAULT_PROJECT_NAME
mkdir $TRAC_PROJECT_ROOT_PATH -Force
trac-admin $TRAC_DEFAULT_PROJECT_PATH initenv $TRAC_DEFAULT_PROJECT_NAME sqlite:db/trac.db
# ローカルAdministratorを管理者に
# ※ここの Administrator、TRAC_ADMIN は大文字小文字を区別するので注意
trac-admin $TRAC_DEFAULT_PROJECT_PATH permission add Administrator TRAC_ADMIN

# Apacheの実行ユーザー(NETWORK SERVICE)にアクセス権を与える
& {
    $Acl = Get-Acl -LiteralPath $TRAC_PROJECT_ROOT_PATH
    $Rule = New-Object System.Security.AccessControl.FileSystemAccessRule("NETWORK SERVICE","FullControl","ContainerInherit,ObjectInherit","None","Allow")
    $Acl.SetAccessRule($Rule)
    $Acl | Set-Acl -LiteralPath $TRAC_PROJECT_ROOT_PATH
}

# プロジェクトのデプロイ
trac-admin $TRAC_DEFAULT_PROJECT_PATH deploy $VISUALSVN_INSTALL_PATH

3-3. pthファイルの追加

次に、先程インストールしたPythonからVisualSVNにインストールされているパッケージを読み込むために、独自のpthファイルを追加しておきます。

$VISUALSVN_INSTALL_PATH = 'C:\Program Files\VisualSVN Server'
$PYTHON_INSTALL_PATH = 'C:\Python27'

# 独自のpthファイル、trac_custom.pth を追加し、SVN関連パッケージのPATHを記載。
@"
$((Join-Path $VISUALSVN_INSTALL_PATH "bin") -replace '\\','\\')
$((Join-Path $VISUALSVN_INSTALL_PATH "PythonPackages") -replace '\\','\\')
"@ -replace "`n","`r`n" | Set-Content (Join-Path $PYTHON_INSTALL_PATH "trac_custom.pth") -Encoding Default

3-4. Apacheの設定

VisualSVN SeverのApacheには、カスタマイズ用に\conf\httpd-custom.confという空ファイルがデフォルトで用意されています。

以下のコマンドを実行して、このファイルの内容をカスタマイズします。
今回はWSGIを使う最低限の設定のみ入れていますが、必要に応じて変更しても良いでしょう。

$VISUALSVN_INSTALL_PATH = 'C:\Program Files\VisualSVN Server'

# httpd-custom.conf ファイルのカスタマイズ
@"
# Customize for Trac
LoadModule wsgi_module bin/mod_wsgi.so
WSGIScriptAlias /trac "$(Join-Path $VISUALSVN_INSTALL_PATH "cgi-bin\trac.wsgi")"

<Location "/trac/">
  WSGIApplicationGroup %{GLOBAL}
</Location>
"@ -replace "`n","`r`n" | Set-Content (Join-Path $VISUALSVN_INSTALL_PATH "conf\httpd-custom.conf") -Encoding Default

続けて、\cgi-bin\trac.wsgiの内容をカスタマイズします。
このファイルは前項のプロジェクトのデプロイ時に作成されているのですが、内容は変更する必要があります。

$VISUALSVN_INSTALL_PATH = 'C:\Program Files\VisualSVN Server'
$PYTHON_INSTALL_PATH = 'C:\Python27'
$TRAC_PROJECT_ROOT_PATH = 'C:\Projcets\Trac'

# trac.wsgi ファイルのカスタマイズ
@"
#!$(Join-Path $PYTHON_INSTALL_PATH "python.exe")
import os
os.environ['TRAC_ENV_PARENT_DIR'] = '$($TRAC_PROJECT_ROOT_PATH -replace '\\','\\')'
import trac.web.main
application = trac.web.main.dispatch_request
"@ -replace "`n","`r`n" | Set-Content (Join-Path $VISUALSVN_INSTALL_PATH "cgi-bin\trac.wsgi") -Encoding Default

3.5 VisalSVN Serverの再起動

これで一通りの設定は完了です。
最後にVisalSVN Serverを再起動します。

Stop-Service VisualSVNServer
Start-Service VisualSVNServer

4. プロジェクトのカスタマイズ

この時点でhttps://localhost/tracにアクセスすればTracを利用できるはずです。
ユーザー認証はVisualSVNの認証を引き継いでいます。

f:id:stknohg:20170803185332p:plain

ただ、プロジェクトの初期状態ではバナーが非表示であったり、ソース管理の設定がなされていないので、必要に応じてtrac.iniを修正してやる必要があります。

f:id:stknohg:20170803185354p:plain

今回は以下の内容を修正しました。

# ソース管理にSubversionを使用する
[components]
tracopt.versioncontrol.svn.* = enabled

# ロゴをデフォルトのものに設定
[header_logo]
src = common/trac_banner.png

f:id:stknohg:20170803185433p:plain

f:id:stknohg:20170803185459p:plain

f:id:stknohg:20170803185511p:plain

これで最低限動作する状態になります。

f:id:stknohg:20170803185525p:plain

後は必要に応じてカスタマイズしてください。

*1:Redmineに移行しようと思っているので...

WindowsのVisual Studio CodeでGo言語の開発環境を作る(2017年7月版)

以前、

blog.shibata.tech

で書いた手順が最新バージョンでさらに変わっていたので新たにエントリを起こしました。

各ツールのバージョンは、

  • Visual Studio Code 1.14.1
  • Go for Visual Studio Code 0.6.62
  • Git for Windows 2.13.3
  • Go 1.8.3

で実施しています。

1. Visual Studio Codeのインストール

こちらはこれまで通りです。

code.visualstudio.com

公式サイトからインストーラーをダウンロードして適当にインストールします。
今回Stableの64bit版がリリースされていたのでこれまでインストールしていた32bit版から新たにインストールしなおしました。

そしてGo for Visual Studio Codeの拡張機能を追加します。

Goで拡張機能を検索して出てくる、キモいかわいいGopher君のヤツを追加してください。

f:id:stknohg:20170720202049p:plain

2. Gitのインストール

go getコマンドなどでGitが必要になるのでインストールします。

git-for-windows.github.io

からインストーラーをダウンロードして適当にインストールします。

通常であればPATHが通っているのでgitコマンドが普通に使える様になるはずですが、通っていなければPATHを通しておいてください。

3. Goのインストール

The Go Programming Language

からWindows用のインストーラーをダウンロードしてインストールします。
今回はgo1.8.3.windows-amd64 (Ver.1.8.3)C:\Go\にインストールしました。

インストール後、必要があればGOROOTを設定し%GOROOT%\binに対してPATHを通します。
GOROOTの設定は任意ですが、PATHを通すのは必ず行ってください。

PowerShellからだと以下の様な感じで設定できます。

# GOROOTの設定 (要管理者権限)
# ※ GOROOTは必要がある場合のみ設定
$GOROOT = 'C:\Go'
$GOROOTBIN = (Join-Path $GOROOT "bin")
[Environment]::SetEnvironmentVariable('GOROOT', $GOROOT, 'Machine')
[Environment]::SetEnvironmentVariable('PATH', [Environment]::GetEnvironmentVariable('PATH', 'Machine') + ";$GOROOTBIN", 'Machine')

続けてGOPATHを設定します。
今回GOPATH%USERPROFILE%\Goにし、%GOPATH%\binに対してPATHも通しておきます。

# GOPATHの設定
$GOPATH = (Join-Path $env:USERPROFILE "Go")
$GOPATHBIN = (Join-Path $GOPATH "bin")
mkdir -p $GOPATHBIN
[Environment]::SetEnvironmentVariable('GOPATH', "$GOPATH", 'User')
[Environment]::SetEnvironmentVariable('PATH', [Environment]::GetEnvironmentVariable('PATH', 'User') + ";$GOPATHBIN", 'User')

ちなみに

今回はGOPATHを環境変数で設定しましたが、代わりにsettigns.jsongo.inferGopathおよびgo.gopathパラメーターを使って設定することもできる様です。
詳細については、GOPATH in the VS Code Go extension · Microsoft/vscode-go Wiki · GitHubを参照してください。

ここまでで必要なソフトウェアのインストールは完了です。

4. Go for Visual Studio Codeための環境設定

ここからGo for Visual Studio Codeための環境設定を行います。

必要パッケージのインストール

過去の手順では自前で必要なパッケージをgo getしていましたが、最新のGo for Visual Studio Codeでは内部コマンドで必要なパッケージのセットアップを行ってくれます。
コマンドパレットを開き、

> Go: Install/Update Tools

を選択すると現在のsettings.jsonの設定に応じて自動で必要なパッケージをgo get -u -vしてくれます。

f:id:stknohg:20170720203704p:plain

f:id:stknohg:20170720204141p:plain

上図を見ればわかりますが、Delveも一緒にインストールしてくれます。
インストールの細かい挙動についてはソース(goInstallTools.ts)を見て確かめてください。

エラーがなければ%GOPATH%\bin配下に各パッケージの実行ファイルができているはずです。

f:id:stknohg:20170720204626p:plain

最後に

これでGoの開発環境が出来上がります。
あとは適当にコードを書いてデバッグしてやればOKです。

f:id:stknohg:20170720204940p:plain

必要なパッケージのインストールがほぼ自動化されたので環境構築が非常に楽になりました。

PowerShell 6.0のロードマップに関して

2018/1/10(PST)にPowerShell Core 6.0が正式リリースされました。
詳しくはこちらのエントリをご覧ください。

blog.shibata.tech


先日PowerShell BlogでPowerShell 6.0のロードマップに関するエントリが公開されました。

blogs.msdn.microsoft.com

日本語情報も出ており、例えば窓の杜による情報はこちらになります。

forest.watch.impress.co.jp

このアナウンスはかなりセンシティブな内容を含みますので本ブログでも補足する形でエントリを書いておきます。

はじめに

できる限り正確な情報を書く様に努めていますが、私も英語が完璧にわかるわけではないので不正確なことを記載してしまっている可能性があります。

完璧な正しさを求めるならPowerShell Blogに書かれていることが全てです。
PowerShell Blogの内容を文意通りに解釈してください。

間違いをご指摘いただければ随時訂正します。

PowerShellのエディションに関して

GitHubの情報を追うとわかるのですが、PowerShell TeamはPowerShell 6.0 Alpha 18からPowerShell Coreという表現を使う様になりました。

そして先のPowerShell Blogにある様にWindows PowerShellPowerShell Coreという2つのPowerShellを定義しこれを正式に呼称する様です。
(ただし、ブログ以外での正式なアナウンスおよびドキュメント化はされていません)

Windows PowerShell

  • PowerShell 1.0~5.0、およびDesktop EdtionのPowerShell 5.1
  • Windowsの.NET Framework上で動作するバージョン
  • PowerShell 5.1では $PSVersionTable.PSEdition = 'Desktop'となる

PowerShell Core

  • Nano Server向けのPowerShell 5.1、および現在開発中のPowerShell 6.0
  • (Windowsを含め)プラットフォームを問わず.NET Core上で動作するバージョン
  • $PSVersionTable.PSEdition = 'Core'となる

ざっと図にすると以下の様になります。

(図は https://speakerdeck.com/stknohg/learn-open-source-powershell?slide=14 より)

PowerShell 6.0のリリースに関して

PowerShell Core 6.0のリリース

まず、PowerShell Coreに関しては

That being said, it is our strong desire to ship a high-quality PowerShell Core 6.0 by the end of the year that you can feel confident about deploying in production.

とある様に今年の年末までにはリリースしたい考えを持ち、フィードバックを強く募集しています。

ただし、Beta 1リリース時にアナウンスされた様に、

  1. 6.0.0-betaのマイルストーンに紐づけられたIssueを解決する

  2. 最低80%のコードカバレッジを達成する

  3. バージョン6.0.0に向けたすべてのシナリオを実現する

  4. テレメトリに基づいた利用目標を達成する

の目標がありますので、これらを年内にクリアできるかも課題となっています。

Windows PowerShell 6.0のリリース

こちらについてはコメント欄の質問に対して、

The goal with PowerShell Core 6.0 and all the compatibility shims is to supplant the need for Windows PowerShell 6.0 while converging the ecosystem on PowerShell Core. So no, we currently don’t have any plans to do a Windows PowerShell 6.0.

との回答がなされ、PowerShell Core 6.0と(Windows PowerShellに対する)互換SHIMでWindows PowerShellを置き換えよう*1としており、いまのところWindows PowerShell 6.0をリリースする計画はない様です。

また、

Windows PowerShell 5.1, much like .NET Framework 4.x, will continue to be a built-in, supported component of Windows 10 and Windows Server 2016. However, it will likely not receive major feature updates or lower-priority bug fixes.

とある様にWindows PowerShell 5.1は今後もサポートされますが、大きな機能追加や優先度の低い不具合の修正は行われない可能性があります。

正直現時点のPowerShell Blogの内容だけでWindows PowerShellがどうなっていくのかなんとも言えず、決定的なところに全然触れてくれない感があるのですが、PowerShell Coreに注力していくという事だけは伝わります。

PowerShell Coreの互換性に関して

現時点でPowerShell Coreは.NET Standard 2.0、.NET Core 2.0(Preview 3向けビルド 2.0.0-preview3-25426-01)のアプリケーションになります。

.NET Standard 2.0では.NET Coreと.NET Frameworkの互換性が大幅に強化されており、これを踏まえて、Windows版のPowerShell Coreでは既存のPowerShellモジュールをPowerShell Coreから利用可能にすることを目指し、最終的には前項で触れた様にWindows PowerShellを置き換えていきたい様です。

互換性を確かめてみる


【2018/01/12追記】

先日正式リリースされたPowerShell 6.0ではこのPSModulePathの自動読み込みは撤回され、WindowsPSModulePathモジュールとして別機能に分離されました。(#4056)

以下の様にモジュールをインストールして、Add-WindowsPSModulePathを呼ぶことで従来のPowerShellモジュールが読み込まれます。

Install-Module WindowsPSModulePath -Scope CurrentUser -Force
Add-WindowsPSModulePath

実際にPowerShell Core 6.0 Beta 4では起動時に読み込むPSModulePathが変更され(#4132)、従来のPowerShellモジュールが読み込まれる様になっています。

ここでPowerShell Coreから、

Get-Module -ListAvailable | ? Path -like "C:\WINDOWS\*"

の様Get-Moduleすると、これまでとは異なり従来のPowerShellモジュールが表示されます。

この中から、例としてHyper-Vモジュール(当然Hyper-Vに関する機能は.NET Coreの対象外です)を利用してみると下図の様に普通に動作します。

Import-Module Hyper-V
Get-VM

この場合は単純にGet-VMしただけなので動作しましたが、細かいことをすれば非互換のエラーが出る可能性はあります。
ただPowerShell Coreの目指す方向性を示すには十分かと思います。

補足

.NET Standard 2.0の詳細についてはこちらのブログが詳しいので参考にしてください。

yfakariya.blogspot.jp

その他

補足としてコメント欄のやり取りから気になるものをピックアップしておきます。

  • Q.PowerShell Workflowはどうなるのか?
    → PowerShell WorkflowはWindows PowerShell専用でPowerShell Coreに導入する予定は今のところない。
    ただ、WorkflowではないがPowerShellに並列実行に関して新しいRFCが提案されている。

  • Q.PowerShell CoreがWindowsにプリインストールされて従来のPowerShellを置き換えるのか?
    → まだ何ともいえない。

  • Q.PowerShell CoreでPowershell Web Accessは動作するのか?
    → PowerShell Web AccessはPowerShell Coreのスコープ外。 (#3004)

  • Q.WindowsのPowerShell CoreでDSCはサポートされる様になるのか?
    回答付かず。 コメント欄の回答では無いですが、DSC Coreが発表されました。

*1:実際にはPowerShell Core 6.0 + Windows PowerShell 5.1という構成になるでしょうが...