rotatelogsにパイプすればローテーションできる。
<IfModule log_config_module>
LogFormat "%h %l %u %t \"%r\" %>s %b" common
#24時間でローテート
CustomLog "|bin/rotatelogs logs/access_log 86400" common
</IfModule>
ただし、logrotateのような世代管理は出来ない。
rotatelogsにパイプすればローテーションできる。
<IfModule log_config_module>
LogFormat "%h %l %u %t \"%r\" %>s %b" common
#24時間でローテート
CustomLog "|bin/rotatelogs logs/access_log 86400" common
</IfModule>
ただし、logrotateのような世代管理は出来ない。
使えるは使えるんだけど、放っておくと知らない間に落ちてる。
レンタルサーバーの性質を考えると、ポート占有してサービスをホスティングするのは正直邪魔だろうから、殺されている可能性は高い。
ご利用上の注意の禁止事項には「daemonとしてサーバに常駐するプログラムの実行」とか書いてあるからこれかもしれない。
でも所詮解説ページだし、レンタルサーバサービス約款(134KB)にはどこにもそんな記述はない。。
一方、基本約款(193KB)には
前項各号のほか、当社は必要に応じ当社ホームページ(http://support.sakura.ad.jp/support/caution.html)において禁止事項および注意事項等を別途定めることがあるものとし、利用者はこれを遵守するものとします。
って書いてあるけど、レンタルサーバーの禁止事項とは別のページだし、誘導もない。
つまり約款上は何の問題もない…気がする…
まぁでもとりあえず運営の気持ちを汲んで使わない事にしておこう。。
※要参照:さくらのレンタルサーバーでのdaemon実行は禁止?
さくらのレンタルサーバーはJavaが入っていないが、自分で入れればJenkinsを動かす事が出来る。
※JENKINS_HOMEは~/.jenkinsとなる。
マシンが再起動されても立ち上がるよう設定する。
効果があるかは試してないので不明…
[shell]
crontab -e
[/shell]
@reboot ~/jenkins/start-jenkins.sh >/dev/null 2>&1
面倒だから試してないけど出来るかもしれない。
.htaccessでmod_rewiteが利用できるため、うまくルールを作ればリダイレクトできる可能性あり。
参考:
さくらレンタルサーバで java を利用する
configuring ProxyPass on .htaccess to show tomcat through apache http server – Stack Overflow
【さくら共用】RewriteRuleで静的URLにしようとしたら404エラー | Server Hosting Guide
システム起動時に特定のコマンドを実行するには - @IT
再起動時に一度だけ実行されるcron定義
Starting and Accessing Jenkins – 日本語 – Jenkins Wiki
webhtm.net日記: psをgrepした結果にgrep自身のプロセスを出力させない
プログラムを作ってます さくらのレンタルサーバでbashを使う
Firefoxをしばらく使っていると、タブ切り替えなどの動作が物凄くもっさりになる事がある。
具体的にはFirefoxの消費メモリが1GB位になると急激に重くなるようだ。
思い返すと、Ver.4の頃あたりからこういう現象に遭遇するようになった気がする。
あの頃実装された大きな機能というと、ハードウェアアクセラレーション。
もしかしたらと思って試しに無効化してみたら、全く重くならなくなった!不思議!
因みにRADEON HD4670とIntel HD2000の環境で確認。
HD4670の性能でアクセラレーション無しの方が軽いというのはどうも理不尽…
根本的な原因がどこにあるのかまでは調べてないので不明なまま。。
とりあえずテーマ編集でなんとかなる。
Suffusionの例
[css title=”変更前”]
blockquote{
background: url(images/blockquote-l.png) no-repeat left top;
padding: 10px 15px;
margin: 0 3em 1em;
font-size: 1em;
text-indent: 2em;
}
[/css]
[css title=”変更後”]
blockquote {
background: url(images/blockquote-l.png) no-repeat left top;
padding: 0px 10px 0px 40px;
margin: 0px 1em 1em;
font-size: 1em;
background-color: #F0F9FF;
border: 1px solid silver;
}
[/css]
値-1の場合、ページのチェックは行われません。この値は、本番環境でのデフォルト値。
値0の場合、ページは常にチェックされます。
値1の場合、ページは毎秒チェックされます。この値は、開発環境でのデフォルト値。
デフォルト値1となっているが、環境によっては-1であることもある模様。
まぁ触った環境がそうだったから書いてるんだけど。。
以下のようなweblogic.xmlを記述し、デプロイすればOK。
[xml title=”weblogic.xml” mark=”4″]
[/xml]
VisualStudioの「配置パッケージの作成」や、MSBuildのターゲットPackageで作成したデプロイパッケージは、同時に作成されるdeploy.cmdでデプロイすることが可能である。
方法: deploy.cmd ファイルを使用して配置パッケージをインストールする
これを用いる際、msdeployの追加フラグを指定することが可能だが、=を含むフラグ値を指定する場合は以下のように指定するようreadmeに注意書きがある。
注意: 次の例に示すように、等号 (=) を含む任意のフラグ値は二重引用符で囲む必要があります。これにより、パッケージに含まれるデータベースの配置がスキップされます:
“-skip:objectName=dbFullSql”
ところが、実際にこの通り指定するとエラーとなってしまう(少なくとも手元の環境では)。
エラー: 引数 ‘”-skip:objectName=dbFullSql”‘ を認識できません。引数はすべて “-” で始まります。
エラー数: 1。
上記リンクにある通り、フラグ値を_MsDeployAdditionalFlags環境変数に設定することで対応可能。
Web 配置 コマンドを、__MsDeployAdditionalFlags 環境変数を設定して指定することもできます。
SET _MsDeployAdditionalFlags=-skip:objectName=dbFullSql
example.deploy.cmd /T /M:hostname /U:UserName /P:Password
VisualStudio標準では、XML-Document-Transformで差分を記述し、元のファイルを変換するという方法となる。
Web アプリケーション プロジェクト配置の Web.config 変換構文
以下のようなファイルを用意し、Web.Debug.configやWeb.Release.configといったファイル名にすれば、Debugビルド時にはWeb.Debug.configファイルを、Releaseビルド時にはweb.Release.configファイルがWeb.configとマージされる。
Debug/Releaseだけでは2環境しか対応できないが、3環境以上対応したい場合もそれなりにある。
その場合はProjectConfigTransformFileNameプロパティを変更することで対応可能。
というようなtargetsファイルをImportしておけば、
msbuild /t:Package /p:DeploymentEnvironment=production
とかやった場合にWeb.production.configを用いてWeb.configが変換される。
これはMicrosoft.Web.Publishing.targetsの内部動作に依存している。
VisualStudioに含まれるtargetsであるため、VSをインストールしないと利用できない。
ここでDeploymentEnvironmentのみ変更してビルドしなおした場合、Web.configが最新状態であるとみなされて変換されないことがある。
PostTransformWebConfig: Web.production.config を使用して Web.config を obj\Release\TransformWebConfig\transformed\Web.config に変換しました。 PipelineTransformPhase: パイプラインの発行の変換フェーズ PreAutoParameterizationWebConfigConnectionStrings: obj\Release\CSAutoParameterize\original\Web.config への obj\Release\TransformWebConfig\transformed\Web.config のコピーをスキップします。ファイル obj\Release\CSAutoParameterize\original\Web.config は最新のものです AutoParameterizationWebConfigConnectionStringsCore: すべての出力ファイルが入力ファイルに対して最新なので、ターゲット "AutoParameterizationWebConfigConnectionStringsCore" を省略します。
この場合、Cleanターゲットも実行するようにすれば対処可能。
PostTransformWebConfig: Web.production.config を使用して Web.config を obj\Release\TransformWebConfig\transformed\Web.config に変換しました。 PipelineTransformPhase: パイプラインの発行の変換フェーズ PreAutoParameterizationWebConfigConnectionStrings: ディレクトリ "D:\Jenkins\workspace\example\obj\Release\CSAutoParameterize\transformed\" を作成しています。 obj\Release\TransformWebConfig\transformed\Web.config を obj\Release\CSAutoParameterize\original\Web.config にコピーしています。 AutoParameterizationWebConfigConnectionStringsCore: ソース ファイルを変換しています: D:\Jenkins\workspace\example\obj\Release\TransformWebConfig\transformed\Web.config 変換ファイルを適用しています:出力ファイル: obj\Release\CSAutoParameterize\transformed\Web.config 変換に成功しました
AppConfigプロパティでapp.configファイルを指定すれば良い。
[xml title=”sample.targets” mark=”3″]
app.$(DeploymentEnvironment).config
[/xml]
というようなtargetsファイルをImportすれば、ビルド時のDeploymentEnvironmentプロパティに応じてプロパティファイルが切り替わる。
msbuild /t:Build /p:DeploymentEnvironment=production
とかやった場合は、app.production.configが読み込まれる。
これは、.NET Frameworkの標準targetsであるMicrosoft.Common.targets内でAppConfigプロパティが読み込まれているのを利用している。
たぶん標準的な方法ではない。。
因みにXDTを用いることも可能な模様。
Vishal Joshi’s Tangent: Applying XDT magic to App.Config