2022-08-03

JDKアップデートしたらsecureValidationでテストがコケたので暫定対処をしました

JDK17へ移行しようとテストコードを流していたらRSA-SHA1を使用している部分で以下のエラー。

It is forbidden to use algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 when secure validation is enabled

どうもsecureValidationが有効な状態だと、特定のアルゴリズムの仕様が許可されないセキュリティエンハンスのせいらしい。

以下は、Sean Mullan氏の記事。

本来であれば、正しいアルゴリズムを採用するようにコード側を変更すべきですが、いかんせん影響範囲が大きい部分だったりするといったんはこのアルゴリズムを許可してテストを通るようにして、アルゴリズム変更はまた別で行うべきかなと考え、暫定で許可することとしました。

以下は許可の方法です。

secureValidationで禁止するアルゴリズムを変更する

securyValidationの際に禁止されるアルゴリズムは、java.security に列挙されています。

Eclipse-Terumin JDK17 のコンテナイメージでは、以下の場所にありました。

/opt/java/openjdk/conf/security/java.security

これを覗くと確かに jdk.xml.dsig.secureValidationPolicy というポリシーがあり、それを見るとSHA-1とかもあります。

直接編集してしまってもいいんですが、さすがにシステム全体のポリシーを変えてしまうのもアレなので、テストを流したり実行したりする場合にのみこの変更を適用するようにします。

まずは適当な場所に java.security ファイルを作成します。（今回、自分の場合はプロジェクト直下においてしまいました）

そして、テスト実行する際に以下のオプションを指定するようにします。VSCodeでテストする際のvmArgsに書いたり、pom.xmlのsurefireのargsに書いたりしてみました。

-Djava.security.properties=./java.security

java.securityを作成した位置に応じて適宜読み替えてください。そして、java.sourceの内容をもともとのjava.sourceからコピペし、必要なアルゴリズムをリストから削除して以下のようにしました。

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    disallowAlg http://www.w3.org/2007/05/xmldsig-more#sha1-rsa-MGF1,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    minKeySize RSA 1024,\
    minKeySize DSA 1024,\
    minKeySize EC 224,\
    noDuplicateIds,\
    noRetrievalMethodLoops

削除したのは以下の3行です。

disallowAlg http://www.w3.org/2000/09/xmldsig#sha1,\
disallowAlg http://www.w3.org/2000/09/xmldsig#dsa-sha1,\
disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1,\

（ここは必要なアルゴリズムに応じて読み換えてください。）

動作確認

ここまでできたら、テストを流してみます。流れればOK。

おわりに

unmarshalXMLSignature 実行する系テストの以上系でエラーが出て、JDKのバージョンアップで javax.xml.crypto.dsig.XMLSignatureException の内容が変わってしまったのか～～～？！なんて思ってたらもっと根深いところに原因があったみたいです。

どなたかのご参考になれば幸いです。

2022-07-20

Azure Functions の開発にはdevcontainerを使うと便利だった

Pythonを使用したAzure Functionsの開発に Visual Studio Codeのdevcontainerを使用しようというお話です。

はじめに

どうも、devcontainer大好きdevcontainerおじさんです。

最近Azure Functionsで普段は使用しないpythonを使って開発してみようと思い触ってみたんですが、いきなり npmでazure functions core toolsをインストール とか言われて、オイオイpython開発なのにnodeが要るなんて聞いてないぜとなったので、結構Azure Functions (Python)の開発環境整えるのって面倒くさそうだなと感じました。

そこでdevcontainerを使って開発環境を整えるとすごく便利ということがわかった（というかMicrosoftが便利なコンテナイメージを提供してくれている）ので、共有です。

Microsoftが提供してくれているAzure Functions用のコンテナ

github.com

提供されているコンテナイメージの一覧はAzure公式リポジトリから参照することができます。様々な種類があるうえに、Dockerfileも公開されているので参考にされてみてはいかがでしょうか。

今回は、core toolsが同梱されている 4-python3.9-core-tools を使用してみました。

docker run --rm -it mcr.microsoft.com/azure-functions/python:4-python3.9-core-tools bash

上記コマンドで bash で試しに入ってみましたが、もちろんPythonは使用できますし、これからデプロイしたりするのに使用する Azure functions core tools も導入されていることがわかります。

始め方

ではこのコンテナイメージを使って開発する流れをご紹介します。始め方はとても簡単で、vscodeのメニューをポチポチいじるだけでdevcontainerを使った開発を始めることができます。

以下の手順はRemote - SSHで接続したリモート開発環境でもOKです。詳しくは↓

yoh1496.hatenablog.com

開発用フォルダをオープン

まずはFunctionsのソースコードが入るリポジトリ（フォルダ）を開きます。Functionsを作るのはこれから、という人は空のフォルダで大丈夫です。（例では適当にfuncapp001というフォルダを掘ってみました。）

devcontainerを準備する

というわけで次にdevcontainerを導入するんですが、ここではvscodeのウィザードを使用していきます。

左下の緑色のボタンをクリックし、開いたリモート関連のメニューから「Add Development Container Configuration Files...」をクリックします。

Add Development Container Configuration Files... を選択

すると追加するdevcontainerの種類を選ぶメニューが出るので、「Show All Definitions...」をクリック。

新たに開いた画面でコンテナイメージ一覧がずらっと出るので、「Azure Python 3」などと入力します。

表示された「Azure Functions & Python 3」を選択します。

すると、.devcontainerフォルダが作成され、その中に devcontainer.json と Dockerfile が格納されていることが確認できると思います。 Dockerfile に FROM mcr.microsoft.com/azure-functions/python:4-python3.9-core-tools など、意図したコンテナイメージを使用する文言が含まれていることを確認します。

その状態で、左下の緑色のボタンをクリックし、「Reopen in Container」をクリックすると、立ち上がったdevcontainerに今のフォルダが開かれた状態でvscodeが再起動します。

あとはこれを使って通常通り開発していく、といった感じです。

終わりに

やはりdevcontainerは開発環境を整えるのにとても便利なツールですね。特に普段使用しないプログラミング言語を選択した場合など戸惑うことが多く、どうしても作っては壊しを繰り返すことになると思うので、コンテナでひとまとまりにして何度でもやり直せるのはとてもグッドだなと思いました。

2022-06-29

devcontainer × docker-compose で共有サーバーで複数人開発を行う

Visual Studio Code の devcontainer (Remote Containers拡張機能)を使用した共有サーバーでの開発について書きます。

課題感

プロジェクトで共通のサーバーを用意してみんなで使いまわそう！みたいになった時、ミドルやDBの管理はどのようにしていますか？

開発の中では以下のような要望がでてくると思います。

ミドルを複数バージョンで試したい
開発の途中でDBをいったんリセットしたい
同じ構成でも複数ブランチのソースコードを試したい

複数人で共通サーバーを使ってこれをやろうとした場合、ポートの割り当てを1つ1つ分けて設定するなど七面倒くさい管理が発生してしまいます。

開発に必要なサーバー一式を管理できるようにしたい
複数ユーザーでそれを使えるとなおよい

という課題感がありました。

課題解決への筋道

docker-compose で開発環境に必要なサーバー一式をそろえる

「課題感」にも書きましたが、複数構成のミドルウェアを1つのホストで動作させるのは骨が折れます。1つのミドルに対して複数のコンポーネントが依存関係にあったりすると地獄ですね。

それを解決するのがDockerに代表されるコンテナ技術であり、それらのコンテナをまとめて管理できるのが docker-compose です。「docker-compose.prod.yml」と「docker-compose.dev.yml」といった感じで複数 docker-compose を用意して、プロダクション環境に合わせた開発環境、新しいバージョンを取り入れたリリース前の開発環境みたいな感じで切り替えるのはよくあるケースだと思います。

docker-composeのプロジェクトファイルに記述されたサービスのポートをlocalhostにバインドして、localhost:9200に対してリクエストすることでelasticsearchコンテナのAPIを叩く、みたいなやつですね。

docker-compose のネットワーク構成を使用しよう

上記のやり方ではlocalhostのポートをバインドしてしまっているので、結局複数パターンの開発環境を立ち上げるためにはポート管理を手動で行う必要がでてきてしまいます。これではdocker-composeを使って環境を作ったり壊したりするのは楽になったものの、複数環境の比較が楽になったとは言えません。

そこで活用したいのが、dockerのネットワーク機能です。dockerのネットワークはコンテナ間の通信を分離する仮想的なネットワークで、同一ネットワークに属するコンテナ同士はそのコンテナのポートで通信をすることができます。つまり、開発者が操作する開発環境をdockerのネットワークにつなげられるようにしてしまえば、localhostのポートにバインドする必要なくコンテナと通信することができます。（実際にはランダムなポートがバインドされます）

docker-compose は、プロジェクトごとにコンテナ用のネットワーク（default）を構成し、各コンテナは自動的にそのネットワークに接続されます。つまり、docker-compose内に開発用のコンテナをサービスとして定義し、そこに乗り込んで開発することができれば、プロジェクトごとに一意のホスト（コンテナ）名・ポートで通信することができるのです。つまり、プロジェクトAとBで「elasticsearchホストの9200ポート」という見かけ上同じでありつつ別のコンテナと通信する、ということができます。

devcontainerを使用することで、docker-composeを使って構成されたサービスにアタッチして開発することができます。

共有サーバーでも使用できます

さらにうれしいのが、最近（2021年11月）、リモートのdockerホストに対してのdevcontainer使用が Remote SSH 拡張機能との組み合わせで行えるようになったことです。それについては以下に記事を書きました。

yoh1496.hatenablog.com

これができるようになったことで、共有サーバーに対して複数ユーザーでログイン、各々のユーザーがポートの管理無しに開発を行うみたいなことができるようになったのです。

基本的な設定方法

使い方については、vscodeのドキュメントが充実しているので、こちらを参照してください。

code.visualstudio.com

Tips&トラブルシューティング

EACCES: permission denied, mkdir '/tmp/vsch…

どうも複数ユーザーでの使用は想定されていないらしく（？）、各ユーザーの VSCode devcontainer の一時ファイルが /tmp 直下に作られてしまいます。それぞれオーナーは作成ユーザーとなるため、Aさんが試した後にBさんが使おうとしたりするとパーミッションの関係でエラーが出ます。

GitHub上でもエラーは報告されており、2022年6月現在解決されていませんが、回避策があります。

EACCES: permission denied, mkdir '/tmp/vsch · Issue #2347 · microsoft/vscode-remote-release · GitHub

mkdir -p /tmp/$USER
export TMPDIR=/tmp/$USER

上記コマンドを ~/.bashrc に書くことで、TMPDIRが /usr/$USER になるため、devcontainerの一時ファイルがユーザーごとに異なるフォルダに作成され、前に述べたような競合が起こらなくなります。

とりあえずは上記対応で問題は発生しなくなりますが、早いこと公式に対応してもらえると嬉しいなと思います。

他のコンテナを触りたい

基本的にdevcontainerで触れるのはアタッチされているコンテナのみです。つまり他のミドルやDBに対して何かしらAPIを叩きたいときはdevcontainerでいったん開発用コンテナに入って踏み台的にAPIを実行する必要があります。

ただ、それだとちょっと使いづらいので、開発用コンテナのlocalhostへの通信を特定のコンテナにリレーします。

通常のdevcontainerのセットアップでは、コンテナのcommandには /bin/sh -c "while sleep 1000; do :; done" として無限に待機するように設定しますが、そこを socat を実行します。ここでは私が開発に使ってるdevcontainerの設定を示します。

personium-core-dev/docker-compose.local.yml at main · yoh1496/personium-core-dev · GitHub

    command: >-
      bash -c '
      socat TCP-LISTEN:61616,reuseaddr,fork TCP:activemq:61616
      | socat TCP-LISTEN:9300,reuseaddr,fork TCP:elasticsearch:9300
      | socat TCP-LISTEN:9200,reuseaddr,fork TCP:elasticsearch:9200
      | socat TCP-LISTEN:11211,reuseaddr,fork TCP:memcached-lock:11211
      | socat TCP-LISTEN:11212,reuseaddr,fork TCP:memcached-cache:11211
      | socat TCP-LISTEN:18888,reuseaddr,fork TCP:personium-engine:8080
      '

リレーするものが多かったので冗長になってしまいましたが、このようにパイプでつないであげることで、localhost:61616に対してはactivemqコンテナの61616に転送したり、9200ポートをelasticsearchの9200ポートにリレーするといった設定を同時に行うことができます。

socatはコンテナを落とさない限り実行されますので前の設定のような無限ループは必要ありません。

終わりに

devcontainer × docker-compose で快適開発ライフを！

2022-06-17

いつの間にかVSCode の Remote - Containersが超絶パワーアップしていた件【docker client 不要】

プログラミング

以前、「Docker Desktop for Windows」無しで Visual Studio Codeで「Remote - Containers」を使用するために Docker client を手動ダウンロードするお話を書きましたが、それがもはや不要だそうです。

yoh1496.hatenablog.com

はじめに

なんとなく Remote - Containers のドキュメントを読んでいたら以下のような記述を発見しました。

If you are using a Linux or macOS SSH host, you can use the Remote - SSH and Remote - Containers extensions together. You do not even need to have a Docker client installed locally.

code.visualstudio.com

どういうことか

超絶ハイパワーなサーバー上でコンテナを立ち上げて開発したいと思ったこと、あると思うんですが、以前までの拡張機能では単体でそういったことが行えず、ローカルに導入したDockerクライアントを使ってリモートのDockerホストを使用するという方法を取る必要がありました。

それが今回（？）、アップデートによって Remote - SSH と組み合わせて使うと、リモートで「Reopen in Container」するとリモートでコンテナが立ち上がり開発できるようになったみたいです！すごい！！！

ちなみに、これもしかして実は昔からできて、自分の勘違いだったんじゃ？？？って思いましたが、Webアーカイブから見るに、以前のドキュメントにはこのような記載はなく、新規に追加された機能っぽい です。

と、テンション上がっていたんですが、この機能 2021年11月に追加されたみたいですね・・・

https://github.com/microsoft/vscode-docs/blob/main/remote-release-notes/v1_63.md#containers-version-0209x

もっと話題になればいいのに！！！というか自分のアンテナが低すぎか！！！！

メリット

ローカルマシンにdockerクライアント不要

これはうれしいですね。VSCode入れられればどこでもコンテナ使った開発ができると。

「devcontainer使うためにdocker導入してくださいね～～～～」っていうのが必要なくなります。

docker-compose.yml 不在問題がなくなる

ローカルマシン上のdocker-compose.ymlを使用してリモートのDockerホストにコンテナを立てるとどうなるか。

リモートからは見えない位置にdocker-compose.ymlがあるので、リモートから docker-compose down できなくなります。

それが今回、リモートホスト上のdocker-compose.ymlを使用してそのマシン上のDockerホストにコンテナを立てることになるので、そういった問題が発生しなくなります。

手元のファイルシステムをコンテナのボリュームにマウントできる

今までの方法ではdevcontainerがあるフォルダはローカルマシンで、実行環境はリモートという構成になっていたためファイルシステムをマウントすることができず、代わりにvolumeを作成してマウントし、その中にgit cloneする必要がありました。

やってみればそれの何が不便というわけでもないんですが、devcontainerとソースコードをひとまとめに管理できるというのが良いかなと思います。

終わりに

あんまりDockerクライアントのみをローカルマシンにインストールしてリモートのDockerホストを使用するという方法を取ってる人はいないのかもしれませんが、個人的にこれがビッグニュースだったので書いてみました。

2022-06-15

プロキシ環境下でのVisual Studio Code Remote SSH の導入

プログラミング

プロキシ環境下で改めて Visual Studio Code の Remote SSH を使おうと思ったらドハマリしたのでメモ。

はじめに

以前はそんなことなかったと思うんですが、VSCodeの便利な拡張機能「Remote SSH」を使用しようとしたらリモート側のサーバー .vscode-server のダウンロードが以下のエラーとともに失敗するようになりました。

Resolver error: Error: Server returned 404

今まではできたが・・・

私の認識では今までは、

~/.bashrc に http_proxy https_proxy 環境変数をセットするように記載する
~/.wgetrc にプロキシ設定を記載する

のどちらかでダウンロードできない問題を回避できた記憶があるんですが、もしかしてできなくなりましたかね？？

ssh -T が曲者っぽい？？

ログ見ると、環境変数にそもそもプロキシ設定が入っていないようでした。

さらによく見ると ssh -T -D $PORT $HOST bash となっていて、non-interactiveなシェル でログインしてるっぽいです。で、non-interactiveなせいかは不明ですが、手動で -T オプションをつけて接続してみると同様に環境変数にプロキシ設定が入っていません。

個人的にはここらへんが怪しいのかなと思いましたが、ただ、それだと ~/.wgetrc も効かないのはなぜ？という感じで、原因究明は無理そうだなと思い力技で解決しました。

対処方法（正しいかは不明）

/etc/environment に以下を書き込みました。

http_proxy=http://user:pass@host:port/
https_proxy=http://user:pass@host:port/

そしていったん前回までの試行で発生したごみを削除。

rm -r ~/.vscode-server

再度 Remote SSH による接続を試します。

終わりに

これにてとりあえずは解決としてしまったのですが、なんとも気持ち悪い感じになってしまったなと思います。

というのも、 /etc/environment にユーザーIDパスワード含む文字列が入ることになるためです。これだと複数ユーザーが使用するサーバーでは使用できなくなりますし考え物だなと思いました。

そもそも ssh の「-T オプション」で接続したときにユーザー固有の環境変数を設定する方法が分かれば苦労しないのですが…

あんまり苦労しない方法でこれを解決できる方法をご存知の方がいらっしゃったら教えてください。

2022-05-25

Webサーバーで公開していた資材(html, js)をTAURIで配布する

プログラミング

HTMLやJSで構成されたXHRを行うWebアプリをローカルで実行できるようにGitHub Actionsでtauriで固めて配布するという話です。

TAURI とは

Webのフロントエンド技術を使ってデスクトップアプリケーションを作れるフレームワークです。

今までであれば、Electronがその役を担っており、mattermostなどのクライアントアプリはElectron製でした。

Electronが動く仕組みとしては、配布ファイルにChromiumが同梱されており、それがフロントエンドの描画だったりバックエンドとの通信を行うものでしたが、それには ブラウザが同梱されるゆえの配布サイズの肥大 といった問題がありました。

一方TAURIでは、スマホOSではお馴染みの「WebView」を使って描画や通信を行います。つまり、ユーザーが準備したブラウザを使用するので、配布ファイルは小さくなる利点があります。

フロントエンドだけの配布にも使える

TAURIもElectronも、Webフロントエンドのノウハウを活用しつつ、バックエンドと組み合わせることでローカルのファイルを操作したりといったデスクトップアプリを作れるものですが、バックエンド実装はマストではないので、既存のサーバーに対して通信するフロントエンドのみを配布するのにも使用することができます。

今回はその方法をご紹介します。よってTAURIを使うとは言ってもRustの知識は不要です。

手順

今回は app-uc-unit-manager という、Personiumというサーバーのファイルマネージャアプリ（HTML + jQuery）をTAURIで配布できるようにしてみます。

github.com

GitHub Actionsでビルドする

TAURIを利用するにはRustの環境を準備する必要があって・・・と、二の足を踏んでいる人もいるかもしれませんが、 tauri-action は GitHub Actions を使って TAURI アプリケーションをビルドできるとっても便利なactionです。

しかも、TAURIアプリのビルド用のファイルが無ければ自動で生成してくれる便利機能付きです。

tauri-action の使い方

使い方はGitHubのリポジトリを見てください。

github.com

tauri-action を使ってハマったポイント

ハマったポイントを書いていきます。

identifier の設定エラー

2022年5月25日現在、以下のエラーが出ます

Error You must change the bundle identifier in tauri.conf.json > tauri > bundle > identifier. The default value com.tauri.dev is not allowed as it must be unique across applications.

コチラについては既に対処されていて（Commit ee5ed527812fe6037c0dd322649f1c9d93d4325e）、tauri-actionを実行するときに bundleIdentifier オプションを設定すればよいみたいです。公式のチュートリアルに加筆して以下のように設定しました。

      - uses: tauri-apps/tauri-action@ee5ed527812fe6037c0dd322649f1c9d93d4325e
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tagName: app-v__VERSION__
          releaseName: "App v__VERSION__"
          releaseBody: "See the assets to download this version and install."
          releaseDraft: true
          prerelease: false
          distPath: ../dist-tauri
          bundleIdentifier: 'io.personium.app-uc-unit-manager'

distPathがわかりづらい

Webフロントエンドの生成物が格納されているフォルダを指定するオプション distPath ですが、それの仕様がわかりづらかったです。

自分の例では、 dist-tauri というディレクトリをリポジトリの直下に掘っておいて、そこに同梱したいHTMLやJSの資材を配置してactionを実行することで同梱させていました。

なので distPath には安直に dist-tauri とか ./dist-tauri と書いていたのですが、以下のようなエラーが出てしまいました。

Error running CLI: Unable to find your web assets, did you forget to build your web app? Your distDir is set to ""./dist_tauri"".

actionで実行されているコマンドを手でたたいてみると、以下のようなことがわかりました。

actionの中で src-tauri というフォルダが作成される
distPath の値はどうも src-tauri フォルダの tauri.conf.json の distDir に該当するらしい
tauri.conf.json の distDIr には src-tauri からの相対パスで指定する

よって、distPath には ../dist-tauri と記載するのが正しかったようです。

完成！

終わりに

tauri-action を既存のWebサイトに対して適用することで、Webサーバーをローカルに立てなくても外部と通信可能な状態で配布できるようになりました。

ただ、スクリーンショットにもある通り、インストーラー（MSI）形式となってしまって利用のハードルはElectronでビルドしたものよりも高くなってしまった気がします。MSIではなくexeで配布する方法もあるとは思うんですが、そうなると依存関係を手動で構築してもらう必要があるのでちょっと大変かななどと思います。