以前、cron と rtcwake を使って通常の Linux PC で決まった時間に自動起動させる方法についてまとめました。
cronとrtcwakeでLinux PCが決まった時間帯だけ起動するようにする | 為せばnull
自宅の Raspberry Pi 5 サーバでもこれができないかなと思ったんですが、ラズパイは設定先が異なっていたのでメモしておきます。
自宅の Raspberry Pi サーバで samba で NAS を運用しているんですが、iPad からだけなぜか「読み取り専用」となってしまって書き込めない問題が起きていました。Windows からでも macOS からでも普通に書き込めるのに、iPad だけ書き込めません。
というわけで、今回はこれをサクッと解決しましょう。
先日、うっかり 350GB ほどの大規模圧縮ファイル(tar.bz2 形式)を Google Drive にアップロードしてしまいました。目的は NAS を dm-crypt 化する際(下記の記事)のファイル一次退避のため。
NAS用の外付けHDDをLVM化してついでに暗号化もする | 為せばnull
しかし困ったことに、アップロードはうまくいったのに対し、ダウンロードがうまくいきません。
ダウンロードエラーとなり、途中で中断されてしまいます。
これではファイルが Google Drive に閉じ込められてしまってローカルに戻すことができません。
今回はその解決策として、Google Drive 上の大規模単一ファイルを数個に分割し、ダウンロードして再結合するまでの手順をメモしていきたいと思います。
最近は GitHub Actions を使って、GitHub に commit するたびにビルドからテストまで自動で行うようにしています。
しかし、外部 API の API キーを扱うようなテストの場合、ログやテストコードから API キーが流出することは避けたいですよね。あるいは、パスワードがコードやログから流出することも避けたいです。今回は、GitHub Environments を使って、これらの機密情報が外部に漏れないようにしていきます。
新しい勤め先ではパソコンカタカタのお仕事でして、一日中職場にある Ubuntu のデスクトップ PC を使います。また、コロナ禍以降は職場はハイブリット制になっていまして、週何回出社という目標さえ守っていれば、週何日かはリモートワークできます。
それ自体はいいんですが、そうなると毎日出社するわけではないので、家から SSH 接続で仕事する日もあります。そのたびに誰かに毎日電源スイッチを押すよう頼むのも面倒ですし、毎日つけっぱなしにしておくのも電気がもったいない…
というわけで、平日の始業時間になったら PC を自動で起動し、終業時間になったら自動でシャットダウンするよう Ubuntu デスクトップにて設定しました。
Webブラウザからコンテナ内のターミナルにアクセスできるようにしたい!という欲が出てきたので作りました。
普通は SSH でシェルに繋げば済む話ですが、最終的には自分の Web サイト上で自作 OS を試用できるようにしたいという願望があります。v86 のように WASM で動く仮想マシンを使うアプローチもありますが、まずは実装が簡単そうなサーバサイドでコンテナを動かすアプローチで実装してみたいと思います。
現在、Raspberry Pi 5 で運用している NAS サーバはサーバアプリケーションに samba を利用しており、記憶媒体は USB 接続の外付け HDD で運用しています。この HDD は論理パーティションで区切っているのですが、今回は NAS サーバに Linux の LVM2 を導入し、柔軟にサイズ変更などが可能な論理ボリュームに移行したいと思います。
また、現在の HDD では USB を挿すだけで誰の PC からもデータが見える状態ですので、ついでに論理ボリュームの暗号化もしていきます。
Docker で一度確保された領域は、イメージ内で空き領域を増やしても、どうやらホストマシン上では自動的には開放されないらしい。ということで、今回は無駄に拡大されて開放されなくなってしまった Docker イメージ(正確には仮想マシンの VHDX)を縮小していきます。
自作の DeepL API 向け CLI ツールである「dptran」で、先日のアップデートより任意・自作の翻訳 API を利用できるようになったので、実験としてローカル LLM を利用した翻訳 API を作成し、dptran から LLM 翻訳を実行してみました。
今回は作成方法からプロンプト、そして実行結果までを共有したいと思います。
普段より Yapps という Web アプリサイトを GitHub Pages 上で運営しており、主に JavaScript でアプリを実装しているのですが、これまでは自分で書いた js ファイルはミニファイをしておらず、改行・コメント等が残されたままでした。
ご存知の通り、JavaScript はブラウザで実行させるためにバイナリにコンパイルして配布するわけではなく、ソースファイルを配布するのが一般的です。ブラウザでファイルを読み込み、ブラウザ実装の js エンジンで構文解析、バイトコード変換、インタプリタ実行、JIT compile、…といった手順が踏まれます。
js ファイルは単なるテキストファイルですので、単なる改行であろうと単なるコメントであろうとブラウザはそれも含めて読み込みます。が、実行の上では無駄なデータでしかなく、それを回避することは有意義と言えます。
この無駄な改行やコメントを削除する工程を「minify(ミニファイ)」「minimize」あるいは「圧縮」などといいます。世の中のイケてるサービスはだいたいミニファイをきちんと実施している印象です。というわけで、世の中で一般的に行われているミニファイを適用しようと意気込んだのですが、毎回自分でやるのは面倒です。せっかく GitHub Pages を使っていることですし、毎回のデプロイごとに GitHub Actions にやらせることにしました。