■ヘッダ情報削減
・HTTPレスポンスヘッダのサーバ情報を減らす
/etc/apache2/conf-available/security.conf
ServerTokens OS → ServerTokens Prod
ヘッダにApacheやOSのバージョン情報を入れない
・ヘッダ識別子非表示
ServerSignature On → ServerSignature Off
■Apacheトップページの非表示
http://ドメイン名/ で表示されるApacheのサンプルページの非表示
/etc/apache2/conf-available/security.conf
<Directory />
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>
これがコメントアウトされていたらはずす。無ければ追記
2015年4月29日水曜日
[Ubuntu] Gitolite3 + Apache2 + SSLクライアント認証
■目的
自分で立てたgitサーバーに対してhttps プロトコルでクライアント認証アクセスする
■インストール
Apache2はインストール済みとする
・Gitolite3インストール
apt-get install gitolite3
インストール中に管理者の公開鍵パスを要求されるので適当にSSHログインできる公開鍵を指定する
→これは後で変更も可能なので適当でOK
インストールが完了するとGitolite3のファイル群は /usr/share/gitolite3
環境は /var/lib/gitolite3 に作成される。
■Apache2準備
まずはApache2の準備
・ apache-suexec-custom のインストール
apt-get install apache-suexec-custom
a2enmod suexec
・mod_cgid 有効化
a2enmod cgid
・gitolite ラッパースクリプト用意
DocumentRoot が /var/www だとしたら /var/www/git というフォルダを作成する。
ここにスクリプトを追加する。 gitolite-suexec-wrapper.sh とする。
→スクリプトを置くフォルダは/var/www/git でなくても良いが、DocumentRootで指定したフォルダのサブフォルダでないとsuexecがスクリプトを実行できないので注意
(gitolite-suexec-wrapper.sh)
===============================================================================
#!/bin/bash
export GIT_PROJECT_ROOT="/var/lib/gitolite3/repositories"
export GITOLITE_HTTP_HOME="var/lib/gitolite3"
exec /usr/share/gitolite3/gitolite-shell
===============================================================================
chown gitolite3:gitolite3 gitolite-suexec-wrapper.sh
chmod +x /var/gitolite/gitolite-suexec-wrapper.sh
として所有者、実行権限を変更する。
・SSLクライアント認証設定
VirtualHost の設定に以下を追加
===============================================================================
SSLEngine on
SSLCertificateFile <サーバー証明書のパス>
SSLCertificateKeyFile <サーバ秘密鍵のパス>
SSLCACertficateFile <CA証明書のパス>
SSLVerifyClient require
SSLUserName SSL_CLIENT_S_DN_CN
SuexecUserGroup gitolite3:gitolite3
ScriptAlias /git /var/www/git/gitolite-suexec-wrapper.sh
<Location /git>
Order allow,deny
Allow from all
</Location>
===============================================================================
CAはオレオレCAで良い。SSLUserName設定はクライアント証明書のCNをユーザー名として扱うことの宣言。
環境変数REMOTE_USERもこれによって証明書CNに置き換わる。
■Gitolite3準備
次にGitolite3側の準備
・リポジトリアクセス権設定
Gitolite3のインストールによってgitolite-admin リポジトリが自動で生成されているはず。
まずはこれをローカルでclone する。そして conf/gitolite.conf を編集する。
例えばtesting リポジトリの設定が以下のようになっていたら
repo testing
RW+ = @all
↓
repo testing
RW+ = @all
R = daemon
というようにdaemonユーザーに対してRead権限を付与する。こうしないとApacheからGitolite3管理のリポジトリが読み出せない。Apacheからアクセスしたい全てのリポジトリにR = daemonを付与する。
変更したらcommit, push して反映
また当然であるが、クライアント証明書のCNと同じ名前のアクセス権限がリポジトリに設定されている必要がある。例えば、developというメンバーがクライアント認証でアクセスする場合にはtesting リポジトリの例で言うと
repo testing
RW = develop
R = daemon
とする。このときtestingリポジトリにApacheからはクライアント証明書のCNがdevelopでないとリポジトリにアクセスできない。
■クライアント側設定
・git設定ファイルの変更
(Linux)
~/.gitconfig
(Windows)
C:/Users/<ユーザー名>/.gitconfig
以下の設定を追記する
===============================================================================
[http]
sslCert = <クライアント証明書ファイルパス>
sslKey = <クライアント秘密鍵ファイルパス>
sslCaInfo = <CA証明書ファイルパス>
sslVerify = false
===============================================================================
最後のsslVefiry = false はオレオレCAの場合に必要。ちゃんと認証機関からCA証明書を取得しているなら不要。
■実行
以上の設定が完了していれば以下のコマンドでリポジトリの取得が可能なはず。
git clone https://<ドメイン名>/git/<リポジトリ名>
自分で立てたgitサーバーに対してhttps プロトコルでクライアント認証アクセスする
■インストール
Apache2はインストール済みとする
・Gitolite3インストール
apt-get install gitolite3
インストール中に管理者の公開鍵パスを要求されるので適当にSSHログインできる公開鍵を指定する
→これは後で変更も可能なので適当でOK
インストールが完了するとGitolite3のファイル群は /usr/share/gitolite3
環境は /var/lib/gitolite3 に作成される。
■Apache2準備
まずはApache2の準備
・ apache-suexec-custom のインストール
apt-get install apache-suexec-custom
a2enmod suexec
・mod_cgid 有効化
a2enmod cgid
・gitolite ラッパースクリプト用意
DocumentRoot が /var/www だとしたら /var/www/git というフォルダを作成する。
ここにスクリプトを追加する。 gitolite-suexec-wrapper.sh とする。
→スクリプトを置くフォルダは/var/www/git でなくても良いが、DocumentRootで指定したフォルダのサブフォルダでないとsuexecがスクリプトを実行できないので注意
(gitolite-suexec-wrapper.sh)
===============================================================================
#!/bin/bash
export GIT_PROJECT_ROOT="/var/lib/gitolite3/repositories"
export GITOLITE_HTTP_HOME="var/lib/gitolite3"
exec /usr/share/gitolite3/gitolite-shell
===============================================================================
chown gitolite3:gitolite3 gitolite-suexec-wrapper.sh
chmod +x /var/gitolite/gitolite-suexec-wrapper.sh
として所有者、実行権限を変更する。
・SSLクライアント認証設定
VirtualHost の設定に以下を追加
===============================================================================
SSLEngine on
SSLCertificateFile <サーバー証明書のパス>
SSLCertificateKeyFile <サーバ秘密鍵のパス>
SSLCACertficateFile <CA証明書のパス>
SSLVerifyClient require
SSLUserName SSL_CLIENT_S_DN_CN
SuexecUserGroup gitolite3:gitolite3
ScriptAlias /git /var/www/git/gitolite-suexec-wrapper.sh
<Location /git>
Order allow,deny
Allow from all
</Location>
===============================================================================
CAはオレオレCAで良い。SSLUserName設定はクライアント証明書のCNをユーザー名として扱うことの宣言。
環境変数REMOTE_USERもこれによって証明書CNに置き換わる。
■Gitolite3準備
次にGitolite3側の準備
・リポジトリアクセス権設定
Gitolite3のインストールによってgitolite-admin リポジトリが自動で生成されているはず。
まずはこれをローカルでclone する。そして conf/gitolite.conf を編集する。
例えばtesting リポジトリの設定が以下のようになっていたら
repo testing
RW+ = @all
↓
repo testing
RW+ = @all
R = daemon
というようにdaemonユーザーに対してRead権限を付与する。こうしないとApacheからGitolite3管理のリポジトリが読み出せない。Apacheからアクセスしたい全てのリポジトリにR = daemonを付与する。
変更したらcommit, push して反映
また当然であるが、クライアント証明書のCNと同じ名前のアクセス権限がリポジトリに設定されている必要がある。例えば、developというメンバーがクライアント認証でアクセスする場合にはtesting リポジトリの例で言うと
repo testing
RW = develop
R = daemon
とする。このときtestingリポジトリにApacheからはクライアント証明書のCNがdevelopでないとリポジトリにアクセスできない。
■クライアント側設定
・git設定ファイルの変更
(Linux)
~/.gitconfig
(Windows)
C:/Users/<ユーザー名>/.gitconfig
以下の設定を追記する
===============================================================================
[http]
sslCert = <クライアント証明書ファイルパス>
sslKey = <クライアント秘密鍵ファイルパス>
sslCaInfo = <CA証明書ファイルパス>
sslVerify = false
===============================================================================
最後のsslVefiry = false はオレオレCAの場合に必要。ちゃんと認証機関からCA証明書を取得しているなら不要。
■実行
以上の設定が完了していれば以下のコマンドでリポジトリの取得が可能なはず。
git clone https://<ドメイン名>/git/<リポジトリ名>
2014年6月15日日曜日
Beagle Boneのデバッグ
■openocd 0.7.0
openocd -f scripts/board/ti_beaglebone.cfg -c "init" -c "reset init" -c "arm core_state arm"
上記コマンドでopenocdが接続できる。
最後のコマンドはThumbモードからARMモードにするだけなので無くてもいい。
接続できない場合はopenocd ドライバフォルダにあるftdi2232ドライバのインストールをまず行う。
ドライバは自動認識しないので手動インストールでopenocdドライバフォルダにあるinfファイルを選択し、texas instrument xds100v2を選択してインストールする。
上記の方法でgdbからデバッグできるが、それには前提がある。
それはBeagleBone付属のＳＤカードからブートした後である。
ただしLinuxは起動してはいけない。
U-Bootが起動してLinuxロードの前にキー操作をしてU-Bootコンソールの状態に止めておく。
■gdb
Eclipseでgdbを使ってHardware Debuggingを行う際の注意。
Window-Preference-Run/Debug-Launching-Default Launchers-GDB Hardware Debuggingの設定
Eclipseのバージョンによってはこの設定がGDB(DSF) Hardware Debugging Launcherになっている。
しかしOpenOCD-gdbでデバッグする場合はLegacy GDB Hardware Debugging Launcherの設定でないとうまく動作しない。
■おまけ
U-Bootコンソールの起動を待ってからデバッグする理由
最初はDDRの初期化が行われていない。
したがってデバッグするプログラムをメモリにロードできないからである。
それでもロードしようとすると jtag-dap sticky error が発生する。
ＳＤカードでのブートなしにロードしようとする場合はopenocd起動時にメモリの初期化コマンドを追加する必要がある。
その方法は調査中。
openocd -f scripts/board/ti_beaglebone.cfg -c "init" -c "reset init" -c "arm core_state arm"
上記コマンドでopenocdが接続できる。
最後のコマンドはThumbモードからARMモードにするだけなので無くてもいい。
接続できない場合はopenocd ドライバフォルダにあるftdi2232ドライバのインストールをまず行う。
ドライバは自動認識しないので手動インストールでopenocdドライバフォルダにあるinfファイルを選択し、texas instrument xds100v2を選択してインストールする。
上記の方法でgdbからデバッグできるが、それには前提がある。
それはBeagleBone付属のＳＤカードからブートした後である。
ただしLinuxは起動してはいけない。
U-Bootが起動してLinuxロードの前にキー操作をしてU-Bootコンソールの状態に止めておく。
■gdb
Eclipseでgdbを使ってHardware Debuggingを行う際の注意。
Window-Preference-Run/Debug-Launching-Default Launchers-GDB Hardware Debuggingの設定
Eclipseのバージョンによってはこの設定がGDB(DSF) Hardware Debugging Launcherになっている。
しかしOpenOCD-gdbでデバッグする場合はLegacy GDB Hardware Debugging Launcherの設定でないとうまく動作しない。
■おまけ
U-Bootコンソールの起動を待ってからデバッグする理由
最初はDDRの初期化が行われていない。
したがってデバッグするプログラムをメモリにロードできないからである。
それでもロードしようとすると jtag-dap sticky error が発生する。
ＳＤカードでのブートなしにロードしようとする場合はopenocd起動時にメモリの初期化コマンドを追加する必要がある。
その方法は調査中。
2013年5月14日火曜日
ビルド環境移行 - clang準備
CodeSourcery のgcc環境からclangへ乗り換えを検討する。
■Clangダウンロード
LLVMのClangサイトから最新版Ver. 3.2のダウンロード
Experimental Clang Binaries for Mingw32/x86が対象ファイル
■準備
まずClangを動作させるのに必要なMinGWをインストールする。
注意すべきは必ずC:/MinGWにインストールすること。
現状のMinGW版Clangは上記フォルダにMinGWがあることがハードコードされている。
次にClangが使うgccのライブラリの準備
現状Clang Ver. 3.2のWindowsビルドがサポートしているgccライブラリのバージョンは以下の通り
4.3.0, 4.4.0, 4.5.0, 4.5.2, 4.6.1, 4.6.2
これはclangのソースコード /clang/lib/Frontend/InitHeaderSearch.cpp L400あたりにハードコードされている。
そこでMsysプロンプトから以下のコマンドを実行して該当バージョンのgccインストール
mingw-get install gcc=4.6.2-1
mingw-get install g++=4.6.2-1
既に4.7.0とかがインストールされていてエラーになってしまった場合は下記
mingw-get upgrade gcc=4.6.2-1
mingw-get upgrade g++=4.6.2-1
■インストール
ダウンロードしたClangのファイル一式を適当な場所に展開するだけ。
/binフォルダにパスを通しておく
以下コマンドで動作確認
clang --version
clang version 3.2 (tags/RELEASE_32/final)
Target: i686-w64-mingw32
Thread model: posix
と出たらインストール成功
■Clangダウンロード
LLVMのClangサイトから最新版Ver. 3.2のダウンロード
Experimental Clang Binaries for Mingw32/x86が対象ファイル
■準備
まずClangを動作させるのに必要なMinGWをインストールする。
注意すべきは必ずC:/MinGWにインストールすること。
現状のMinGW版Clangは上記フォルダにMinGWがあることがハードコードされている。
次にClangが使うgccのライブラリの準備
現状Clang Ver. 3.2のWindowsビルドがサポートしているgccライブラリのバージョンは以下の通り
4.3.0, 4.4.0, 4.5.0, 4.5.2, 4.6.1, 4.6.2
これはclangのソースコード /clang/lib/Frontend/InitHeaderSearch.cpp L400あたりにハードコードされている。
そこでMsysプロンプトから以下のコマンドを実行して該当バージョンのgccインストール
mingw-get install gcc=4.6.2-1
mingw-get install g++=4.6.2-1
既に4.7.0とかがインストールされていてエラーになってしまった場合は下記
mingw-get upgrade gcc=4.6.2-1
mingw-get upgrade g++=4.6.2-1
■インストール
ダウンロードしたClangのファイル一式を適当な場所に展開するだけ。
/binフォルダにパスを通しておく
以下コマンドで動作確認
clang --version
clang version 3.2 (tags/RELEASE_32/final)
Target: i686-w64-mingw32
Thread model: posix
と出たらインストール成功
登録:
投稿 (Atom)