sudo apt install tk-dev python-tk python3-tk pyenv install 3.8.6 pyenv global 3.8.6 python3 -m tkinter

User (Desktop): Settings > Network > Network Proxy Settings > Network > Network Proxy > Manualに設定する。 自動的に環境変数HTTP_PROXY, HTTPS_PROXYにスキームが追加された状態で設定される。 HTTP Proxy: proxy port HTTPS Proxy: proxy port Ignore Hosts: localhost, 127.0.0.0/8, ::1（プライベートネットワーク・組織内ネットワークのIPアドレス範囲またはドメインも追加する） curlやwget、pipなど主要コマンドは 注意点として、別ユーザとしてコマンドを実行すると環境変数が引き継がれない。 例えばsudo curlしたときにプロキシに接続しにいかない。 /etc/sudoers sudoでコマンドを実行したとき、実行時シェルに設定されている環境変数を引き継ぐようにする。 sudoersは書き込み禁止になっているためvisudoで編集する。 # run as root visudo -f /etc/sudoers Defaults env_keep+="HTTP_PROXY" Defaults env_keep+="HTTPS_PROXY" Defaults env_keep+="NO_PROXY" Defaults env_keep+="EDITOR" /etc/environment システム全体の環境変数として設定される。影響範囲が大きいので注意。 デスクトップユーザではSettings側の設定（Disabledなら設定されない）が優先されるようだった。 HTTP_PROXY=http://proxy:port HTTPS_PROXY=http://proxy:port NO_PROXY=localhost, 127.0.0.0/8, ::1 apt: /etc/apt/apt.conf Acquire::http::proxy "http://proxy:port"; Acquire::https::proxy "http://proxy:port"; Snap: systemctl edit snapd.service /etc/systemd/system/snapd.service.d/override.confにsystemdの設定ファイルを作成する。 ...

ses = requests.Session() Headers ses.headers.update({ }) Copy cookies from Selenium ses.cookies.clear() for cookie in driver.get_cookies(): rc = requests.cookies.create_cookie(domain=cookie['domain'], name=cookie['name'], value=cookie['value']) ses.cookies.set_cookie(rc) Download a file file_url: str dest_path: str with tempfile.NamedTemporaryFile() as fp: with ses.get(file_url, stream=True) as r: r.raise_for_status() for chunk in r.iter_content(chunk_size=8192): fp.write(chunk) fp.flush() shutil.copy(fp.name, dest_path)

2022-08-06 追記 Seleniumのバージョンが上がって一部非推奨化したりしたので、そちらに対応した版を作成しました。 リポジトリ: https://github.com/aoirint/compose-selenium-python-template 2020-09-28 docker-compose.yml version: '3.8' services: app: build: ./app/ entrypoint: [ "wait-for-it", "selenium:4444", "--", "python3", "/code/main.py" ] volumes: - ./work:/work environment: SELENIUM_URL: http://selenium:4444/wd/hub depends_on: - selenium selenium: image: selenium/standalone-chrome volumes: - /dev/shm:/dev/shm app/Dockerfile FROM python:3 WORKDIR /work RUN apt update && apt install -y \ wait-for-it ADD requirements.txt /tmp/ RUN pip3 install -r /tmp/requirements.txt ADD code/ /code app/requirements.txt requests >= 2.24.0 selenium app/code/main.py from selenium import webdriver from selenium.common.exceptions import NoSuchElementException from selenium.webdriver.common.desired_capabilities import DesiredCapabilities selenium_url = os.environ['SELENIUM_URL'] website_url: str = None driver = webdriver.Remote( command_executor=selenium_url, desired_capabilities=DesiredCapabilities.CHROME, ) driver.get(website_url)

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のところをコピーして増やせばコマンドを増やすことができる。 ...