技術ノート

docker-compose run --rm appを実行するとサービスappが起動してコンテナが作られ、実行が終わり次第コンテナは削除される。 このとき削除されるコンテナはforegroundで実行されたもののみで、 depends_onなどの設定からリンクを通じて起動した他サービスのdetachedコンテナは削除されず残り続ける。 docker-compose run <container> –rm does not rm links · Issue #2791 · docker/compose このissueでlinked containersを同時に削除する機能について議論されているが、 runコマンドにオプションを増やしたくない、ということで却下されている。 As mentioned in this thread, docker-compose rm -f –all and docker-compose down already allow cleaning up a project’s containers / resources. We won’t overload run with more options at that point. ひとまずdocker-compose run終了後にdocker-compose downを実行するシェルスクリプトで対応する。 compose_run.sh ...

GitHub Actions実行中に生成したbuildディレクトリの内容を別ブランチにpushする。 github:s0/git-publish-subdir-action name: Build on: push: branches: - master jobs: deploy: name: Build runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Build run: python3 app/main.py # run: | # python3 app/cmd1.py # python3 app/cmd2.py # https://github.com/s0/git-publish-subdir-action - name: Push to build branch uses: s0/git-publish-subdir-action@master env: REPO: self BRANCH: build FOLDER: build GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

環境の整理を兼ねて、UbuntuのKernelのアップデートをしたので、そのときのメモ。 メイン Ubuntu 18.04のKernelをアップデートした（HWE Kernel） カーネルバージョンについて /lib/modulesを見る限りインストール時のバージョンは4.10.0-28で、 /usr/srcを見る限り4.15.0-115をしばらく使ったあと、 4.16.18に更新していた。 バージョン4.10.xはおそらくUbuntu 16.04をクリーンインストールしたときのもので、 バージョン4.15.xはdist-upgradeでUbuntu 18.04にアップデートしたときに変更されたと思われる。 その後ソフトウェア導入のためのバージョン合わせかなにかで4.16.xにして、そのまま使っていた。 4.15.xから4.16.xにアップデートするときにはUKUU（Ubuntu Kernel Update Utility）を使っていた。 このとき参考にしたサイト： Upgrade Kernel on Ubuntu 18.04 – Linux Hint ところで、カーネルバージョンの後ろに付いているハイフン以降の数字はUbuntu Release ABIというらしいのだが、 UKUUを使ってカーネルをインストールするとこの部分がバージョン番号（ハイフンの前）を6ケタの数字に直したようなものになるので、 これはABIとは違いそうだ（ABIは0から255までの範囲のように思われる）。 ABIのドキュメントらしきものがあったので、機会があれば読みたい：KernelTeam/BuildSystem/ABI - Ubuntu Wiki UKUUとセキュリティアップデートについて Ubuntu 20.04 その164 - Linux kernelにDoSや任意コード実行の脆弱性・アップデートを - kledgeb USN-4489-1: Linux kernel vulnerability | Ubuntu security notices | Ubuntu 通常の方法でインストールされるカーネルを使っている場合、 Linux Kernelに脆弱性が発見されてもこのようにUbuntu側からセキュリティアップデートが提供される。 ...

Ubuntu 18.04.5 LTS (Bionic Beaver) Ubuntu 18.04、Windows 10のデュアルブート環境を構築する。 プロキシ下を想定しているので、不要な場合は適宜調整。 時刻ずれの解消 Linux環境設定/デュアルブートのWindows時刻をUTCにする - Linuxと過ごす デュアルブート環境では、BIOSの時刻を介してWindows側の時刻管理（ローカル時間）とUbuntu側の時刻管理（UTC時間）が衝突して、タイムゾーンの時差分、時計がずれてしまう。ここでは、Windows側の時刻管理をUTC時間にするようにレジストリを変更して対処する。 Windows上で管理者権限でコマンドプロンプトを起動し、以下のコマンドを実行する。 reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f NTPサーバの設定（プロキシ環境） Ubuntu 18.04 / 16.04 で時刻合わせの設定を変更する - Sickly Life Blog systemdのSNTPクライアント機能を使ってみる | Keep the Light Alive 【Windows】「ハードウェアクロック」と「システムクロック」と「NTP 時刻同期」の関係 | 100%レンタルサーバーを使いこなすサイト 時刻同期のためプロキシ内のNTPサーバを設定する。 Settings > Details > Date & Timeで使われるNTPサービスはsystemd-timesyncd。 ...

概要 LaTeXをホストにインストールせず、Docker内で動かしつつ、 Atomからこれを利用できるようにする。 Requirements Ubuntu 18.04 Docker Atom Atom Packages latex Atom Packages latexを入れれば最低限ビルドコマンドは叩けるようになる。 latex シンタックスハイライト language-latex アウトライン表示 document-outline PDFプレビュー pdf-view（メモリリーク? Atomを一度閉じれば解消する） または pdf-view-plus（メモリリーク対策版らしい。latexとの連携はないので注意） Dockerイメージ paperist/alpine-texlive-jaを使う。 sudo docker pull paperist/alpine-texlive-ja Docker sudoなしでDockerを実行できるようにする。AtomからDockerコンテナを作るのに必要。 注意として、この方法で一般ユーザがDockerを使えるようにすると特権昇格できてしまうため、 共有サーバにおいてはDocker 20.10以降のDocker rootlessを設定する。 https://docs.docker.com/engine/security/rootless/ ユーザをdockerグループに追加したあと再ログインする。新しくdockerグループが作られた直後はnewgrp dockerしなければならないことがあり、シェルごとにこれを実行する必要があるようなのでAtomに反映されず、この場合OSの再起動が必要。 sudo groupadd docker sudo adduser $USER docker latexmkスクリプトを作る /usr/texbin/latexmk（手動でlatexのTeX Pathを設定するか、デフォルトでPATHの通っている場所ならどこでもいい）に以下のシェルスクリプトを作成し、chmod +x /usr/texbin/latexmkしておく。 ${HOME}/.atom/packages/latex/resourcesのマウントはlatexのExtended Build Modeが有効のときに${HOME}/.atom/packages/latex/resources/latexmkrcが読み出されるため設定している（このパスはホストのAtomから渡されるのでマウント先パスもホストと同じ）。この機能を無効にしていれば不要。 #!/bin/sh docker run --rm \ -v "${PWD}:/workdir" \ -v "${HOME}/.atom/packages/latex/resources:${HOME}/.atom/packages/latex/resources" \ paperist/alpine-texlive-ja \ latexmk "$@" サンプルTeXファイル \documentclass[10pt,a4paper]{jsarticle} \title{My Title} \author{Author} \date{2020-09-17} \begin{document} \maketitle \section{サンプル} \end{document} 注意点 カレントディレクトリ以下をマウントするため、外部においた.styなどは読み込めないので注意（デフォルトでロードされるディレクトリがあれば追加のマウントをすればOKと思われる）。 ...

概要 新しく静的サイトジェネレータでブログ環境を整備した。 細かい使い方には触れないが、構成を書いておく。 静的サイトジェネレータとCI/CD 静的サイトジェネレータ 静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。 Sphinx Jekyll Hugo Miyadaiku MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。 テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント（とサンプルテンプレート、ソースコード）を見ていくしかないかも。 github:miyadaiku/miyadaiku pypi:miyadaiku GitHub Actions GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、 つまりCI（Continuos Integration、テストやビルドの自動化）/CD（Continuous Delivery、デプロイの自動化）を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。 この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。 バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで（手元にリポジトリがあっても）GitHub ActionsによるCI/CDができないのが難点な気がする。 GitHub Status 考えていること レンダリング後のHTMLファイルの分離 Markdownを書いている時に見えるところに（レンダリング後の）HTMLファイルを置きたくない。 できれば何も考えずに（Markdownで書いた）メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して（オプションで指定したテーマなどで）いい感じにレンダリングしてくれるようなものがいい （HTMLファイル自体にファイルシステムからアクセスできる必要はない）と思っていた。 このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、 レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性（再レンダリングしても差分がない状態）が崩れてしまうことがない。 それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、（見える）commitに含めたくない気持ちがある。 この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。 今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ（gh-pages）に自動でcommitされるように設定する。 GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ（gh-pagesブランチの更新）にはgithub:peaceiris/actions-gh-pagesを使っている。 # deploy.yml name: Deploy # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the master branch on: push: branches: [ master ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Run miyadaiku-build run: miyadaiku-build --output public . - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public name、runのところをコピーして増やせばコマンドを増やすことができる。 ...

VisualBoyAdvance - MをDocker上で動かすDockerfile（とrunコマンドのオプションセット）を作った。 要X Window System、Pulseaudio。Ubuntu Desktop 18.04（with NVIDIA Driver）で動作確認。 https://github.com/aoirint/vbam-docker Dockerfile # for general machine FROM ubuntu:bionic # for nvidia-driver machine # FROM nvidia/opengl:base-ubuntu18.04 ENV VERSION 2.1.4 ENV SHA1HASH bf6e452b53f47e2fbc4e6e41c92f567aa285cdbe WORKDIR /vbam RUN apt update \ && apt -qq -y --no-install-recommends install \ ca-certificates \ tar \ wget \ # -- from builddeps script build-essential \ g++ \ nasm \ cmake \ ccache \ gettext \ zlib1g-dev \ libgl1-mesa-dev \ libavcodec-dev \ libavformat-dev \ libswscale-dev \ libavutil-dev \ libswresample-dev \ libgettextpo-dev \ libpng-dev \ libsdl2-dev \ libsdl2-2.0 \ libglu1-mesa-dev \ libglu1-mesa \ libgles2-mesa-dev \ libsfml-dev \ libsfml-graphics2.4 \ libsfml-network2.4 \ libsfml-window2.4 \ libglew2.0 \ libopenal-dev \ libwxgtk3.0-dev \ libwxgtk3.0 \ libgtk2.0-dev \ libgtk-3-dev \ zip \ # sound driver to play sound on host pulseaudio \ # build && mkdir /vbam-build && cd /vbam-build \ && wget -O vbam.tar.gz https://github.com/visualboyadvance-m/visualboyadvance-m/archive/v${VERSION}.tar.gz \ && echo "${SHA1HASH} vbam.tar.gz" | sha1sum -c - \ && mkdir src \ && tar xf vbam.tar.gz -C src --strip-components 1 \ && mkdir build && cd build \ && cmake ../src \ && make \ # copy to /usr/local/bin/ && mv visualboyadvance-m /usr/local/bin/ \ # remove build environment && rm -r /vbam-build/ ベースイメージは（とりあえず）基本はubuntu:bionicで、NVIDIAのGPUで動いてるマシンでビルドするときはnvidia/openglにする。これをやらないと描画時にlibGL error: No matching fbConfigs or visuals foundを吐く（逆にubuntu:bionicでの動作確認はしていないが.. 設定で描画をOpenGL以外にすればどちらでも動きそう）。 ...

https://jekyllrb.com/ Ruby製の静的ウェブサイト生成ツール（Static Site Generator）。なんかMarkdownとかで書いたサイトをいい感じにHTMLにしてくれるやつ。 Dockerイメージの準備 Ruby, RubyGems, gcc, makeが入っていれば動くらしい。公式Dockerイメージもあるみたいだけど、あえてスルーしてrubyイメージからやってみる。 ふだんRubyは使わないので試行錯誤。 https://hub.docker.com/_/ruby まずはイメージをビルド。 FROM ruby:2 WORKDIR /code RUN gem install jekyll bundler ここでgem installしてもいいのか、という問題がありそうだけどよくわからない..（キャッシュについてはいいとして） sudo docker build . -t myjekyll ひとまずこれでイメージの準備はできた。 sudo docker run --rm -v `pwd`/myblog:/code -e BUNDLE_PATH=vendor/bundle myjekyll jekyll new ./ これで./myblog（/code）に新しいJekyllプロジェクトが生成される（合わせて依存ライブラリがmyblog/vendor/bundleにインストールされる）。 vendorを除いたフォルダ構成はこんな感じ。 myblog/ ├── 404.html ├── about.markdown ├── _config.yml ├── Gemfile ├── Gemfile.lock ├── index.markdown └── _posts └── 2020-05-31-welcome-to-jekyll.markdown もし既存のプロジェクトを使う場合、bundle installでライブラリを取得する（Gemfileに書かれた依存ライブラリがmyblog/vendor/bundleにインストールされる）。 sudo docker run --rm -v `pwd`/myblog:/code -e BUNDLE_PATH=vendor/bundle myjekyll bundle install bundler、bundle execについて　※自分用メモ - Qiita 環境変数 BUNDLE_PATH の怪 - Qiita 最後に開発用サーバを立てる。 ...

Firefox 76 https://diary.palm84.com/entry/20190527/1558967870 Firefox 69以降デフォルトで無効化されたらしいので、about:configからstylesheetsで検索、toolkit.legacyUserProfileCustomizations.stylesheetsをtrueにする。 ブラウザ右上の三本線メニューからHelp、Troubleshooting InformationのProfile Directoryという項目から現在のプロファイルのディレクトリがわかる。 PROFILE_DIR/chromeディレクトリを作成、PROFILE_DIR/chrome/userContent.cssファイルを作成。あとはこのCSSがすべてのWebサイトに適用されるのでCSSを書いていくだけ。Firefoxを再起動すると変更が適用される。 body { background: black !important; } https://developer.mozilla.org/ja/docs/Web/CSS/@document http://puppet.asablo.jp/blog/2008/11/25/3974444 @-moz-documentで特定のドメインのWebサイトにだけスタイルを適用できる（@documentでは動かなかった）。ドキュメントは@documentのものを見ればいいのかな（Firefoxにしかこのクエリは実装されてないらしい、CSS 4で検討中？）。ID/クラスが被ってる場合に使えるか。 @-moz-document domain(twitter.com) { body { background: black !important; } } https://qiita.com/uzumushi/items/f95f9e89fde2a507d7e8

Environment Ubuntu 18.04 PulseAudio スピーカー出力を仮想マイク入力にする pavucontrolを実行し、Input Devicesのタブを開く。Show:をAll Input Devicesに設定すると、Monitor of YOUR_SPEAKERという項目があり、このデバイスからの読み取りはスピーカーへの出力がループバックされたものになっている（YOUR_SPEAKERへの出力＝Monitor of YOUR_SPEAKERからの入力。 しかしここで音声を入力するアプリケーションとして仮にZoomを開いても、Microphoneの選択肢にMonitor of YOUR_SPEAKERは現れない。回避策として、MicrophoneをSame as System（デフォルトの音声入力デバイス）にし、Input DevicesでMonitor of YOUR_SPEAKERのSet as Fallback（緑のチェックマーク、デフォルトの音声入力デバイス）を有効にすることでZoomのマイクとしてスピーカー出力を渡すことができた。 このままでは他の人から送られてきた音声が自分のコンピュータの中でループ（Zoom Output→YOUR_SPEAKER→Monitor of YOUR_SPEAKER→Zoom Input）してしまうんじゃないかと思うが、少なくともZoom上ではそうはならなさそう（PC1のマイク→Zoom→PC2の音声出力→Monitor of PC2 Speaker→Zoom→PC1の音声出力 とはならなかった？）？　これはハウリング防止フィルタが効いてるのかどうなのか.. Zoomの音域系フィルタが効いているのか音楽は若干変になる（もともと声を送るためのチャンネルだし。きれいな音声を送るにはShare Screenを使う必要ありか）。 Zoomの入力デバイスをpavucontrolから直接変えられないのはZoom側でなにか固定してるのか、チャンネル数とかフォーマット対応してないみたいなことなのか.. 前回のデスクトップ映像の出力と組み合わせた場合、映像と音声の同期がとれないと思われるので、お気持ちでなんとかするか、あるいはffmpegで同時に送り出すことまでを保証する、くらいはできるのだろうか.. https://aoirint.hatenablog.com/entry/2020/05/15/185853 挿入音声の再生デバイス分離 Zoomの音声を出力するデバイスと挿入音声を出力するデバイスを分離して、目的の音声だけ送り出せるようにしてみる。つまり、Zoomの音声出力はYOUR_SPEAKERのままにして、挿入音声を仮想音声出力デバイスに出力するようにする。 pacmd load-module module-null-sink sink_name=DummyOutput0 sink_properties=device.description=DummyOutput0 # Or pacmd load-module module-null-sink sink_name=DummyOutput0 pacmd update-sink-proplist DummyOutput0 device.description=DummyOutput0 # --- pacmd unload-module module-null-sink これでデフォルトの音声入力デバイスをDummyOutput0に設定すればZoom上にDummyOutput0への出力が送り出される。あとは挿入音声を流しているアプリケーションからの音声出力をDummyOutput0に送り出せばOK。 この状態でDummyOutput0に出力されている挿入音声をYOUR_SPEAKERで聞くには、Monitor of DummyOutput0をループバックしてYOUR_SPEAKERに出力する。 pacmd load-module module-loopback source=DummyOutput0.monitor pacmd unload-module module-loopback 物理マイクの入力をミックスする ここでZoomの入力デバイスに送り出されるのは自分のコンピュータ上で出力された音声だけになっているので、物理マイクを接続していてもこれに入力された音声をZoomに送り出すことはできていない。物理マイクへの入力もZoom上に送り出せるようにする。 ...