# Debian Testingを普段使いしてみた --- ## 皆さんこんにちは！ :wave: --- <!-- 初めましての方も多いと思いますので自己紹介させて いただきます。 フリーランスのバックエンドエンジニアをやっております 音川といいます。 --> My Profile Otogawa Katsutoshi go, python freelance backend enginner twitter account[https://twitter.com/k_otogawa] --- <!-- Setting 舞台 --> ## 突然ですがみなさん！Debianは好きですか！ :sunglasses: --- ## 私は大好きです！ :laughing: <!-- --> --- <!-- 今回私が何しに来たか?というと --> ## 今回何しに来たか?というと Debian は非常に安定性が高いけれども、 カーネルがやや古かったり、パッケージのバージョンが古かったりします。 これを理由にDebianをOSとして選択しないのは勿体無いと私は思っています。 使っているものが古いという問題はテスト版のDebianであるDebian Testingを使うと、解消できます。 ## 要するに --- ## Debian Testingの布教にきました  Test版でも安定してるし、実用性高いよ --- <!-- ではその前に、Debian Testingとは？ Stableとどう違うのか？を説明していきます。 --> ## Debian Testingとは？  <!-- という事でDebianのリリースについて説明します。 --> --- ## Debianは安定度に合わせて４種類のリリースがある 星の数は安定度 - stable(普通使うやつ) 　　:star: :star: :star: :star: - testing(テスト用)　　　　:star: :star: :star: - unstable(開発者用) 　　　:star: :star: - experimental(~~ドM~~用)　　 :star: <!-- このStableというやつがみなさん使っている安定版で 一般ユーザーが使うことを想定しているものです。 今回説明させていただくTestingっていうのが、テスト版で、 公開テストみたいなものです。本番サーバーでは使わないほうが 良いけど、クライアントPCで使うのはありかな？というレベルの安定度です。 unstableっていうのがDebian自体の開発者向けのリリースで一言でいうと、Debian版のArchLinuxみたいな安定性です。これを普段使いするのは割と疲れるので、開発者以外は向かいないかなと。 最後はexperimentalです。これはめちゃくちゃ不安定で、Biosを壊すこともある機能が含まれているので、Debian開発者でもインストールするのはやめたほうが良いと言われています。このリリースでは主に次のDebianのカーネルの開発を行っています。 --> --- <!-- これを聞いて、あれ？ --> ## debian strechとかbusterとかそういう名前じゃなかったっけ？  <!-- って思われる方いると思うんですけど、 --> --- <!-- それはコードネームと呼ばれるものです。 --> ## Debianにはコードネームがある <!-- Debianには --> 各バージョンに対応したコードネームがある いわゆる愛称みたいなもの <!-- です。 --> --- <!-- で --> ## リリースとバージョンとコードネームのまとめ <!-- は次のようになります。 --> | リリース |　　　バージョン番号 | コードネーム | | -------- | -------- | -------- | | oldoldstable　| 9 | strech | | oldstable | 10 | buster | | stable | 11 | bullseye | | testing | 12 | bookworm | | unstable | 番号無し | sid | | experimental | 番号無し | 無し | <!-- 新しいstable、安定板が出たら、今までstableだったバージョンが oldstable,oldstableだったものがoldoldstableになって、 将来新しいstableになるtesting、test版がリリースされるという リリースサイクルになっています。 --> <!-- で最初に戻るのですが、 --> --- ## debian Testingのメリットは？ <!-- メリットについて説明していきたいと思います。 --> --- ## debian Testingの特徴 1. ほぼ最新のカーネルが使える。 <!-- Fedoraと同じかfedoraよりちょっと新し目ぐらいです。 今だったら、linuxカーネルの5.19使っています。 --> 2. ubuntu並みに新しいバージョンのパッケージが使える。 <!-- 今のdebianの stableだったら、nodejsならバージョン12がデフォルトで結構古いんですが、testingなら最新のLTSの18が使えます。 golangもdebianのstableだったら、バージョンの1.15使うことになるんですが、testingなら1.19使えます。 --> <!-- つまり、 --> --- ## debian Testingのメリット 常に開発で困らない程度の新しいものが使える  <!-- という事で、これを聞いて皆さんdebian testingに興味を持ちました！ 試してみたいですよね！？ という事で --> --- <!-- インストール方法を説明していきたいと思います。 --> ## debian testingをインストールしてみる  --- <!-- まずは普段使いの --> ## クライアントPCにインストールする場合 <!-- について説明します。 --> --- <!-- まず --> ## Debian Testing のインストーラー <!-- をダウンロードしましょう！ --> 公式ダウンロードサイトのweekly-build <!-- のところにあります。 -->  <!-- で実際にインストールして見てください。 ただ、残念な事に、 --> --- ## testingのインストーラー testingのインストーラーは壊れていることがある。  <!-- つまり上手くインストールできるかどうかは --> <!-- 運です。よって --> --- ## 祈祷力が試される! weekly-buildが使えなかったら、新しめのdaily-buildを使おう。  <!-- ちなみに私はgrubでlinux imageをインストール するところで失敗していたので、手動で復旧させました。 Testingで一番バグありそうなのが、インストーラで、 これが結構インストールできないとかがよくあるので、 途中で失敗したらちょっと古いインストーラーを使いましょう。 --> <!-- インストールできてしまったら特に --> --- ## インストール後 特にStableと違う設定をする必要などは無い。 <!-- クライアントPCじゃなくて、 仮想環境で試したいという人は、 --> --- ## インストーラー使いたくない人 vagrant cloudやdocker hubにtestingのイメージがある <!-- のでそれを使いましょう。 で、自分はTesting使ってみたのですが、 --> --- ## 使った感想 test版と思えないぐらい安定している。  <!-- 今プレゼンに使っているこのパソコンも Debian Testingなんですが、ちゃんと問題なく使えています。 testingでこれだけ安定しているから、 LinuxOSの開発者も安心してdebianの子孫という形で OSを作ることができる。その結果Debian系がシェアダントツになっているという図式になっているんでしょうね。 使ってて楽しいです！ --> --- <!-- それでも --> ## 言ってもバグあるんでしょ？ あくまでtest版だからバグあるんでしょ？  <!-- って思われる方もいると思うので、 なので --> --- <!-- できるだけ --> ## バグを避ける方法 <!-- も紹介していきます。 -->  --- ## testingのおすすめ運用方 1. OSを勝手にアップデートしないように設定 2. 定期的にsnapshotを作成して簡単に復元できるようにする <!-- について 解説していきたいと思います。 --> <!-- OSを勝手にアップデートしないように設定ですけれども、 一応ブート時にgrubで新しいカーネルを選択しなかったら 良いという方法もあります。 しかし、念には念を押すなら、OS自体のアップデートを少し時間をおくというのが良いと思います。 特に手元にサーバーが無いか、仮想環境ならssh自体が立ち上がらなくなるので、待つというのは割と重要かなと。 ということで、 --> --- ## OSを勝手にアップデートしないように設定 何人か尊い犠牲になってもらってからインストールしましょう。  <!-- 具体的にどうやるかというと --> --- ## パッケージの更新の止め方 ```bash apt-mark hold ``` <!-- っていうコマンドを使います。 これはパッケージの更新を止めるコマンドで、 引数に下のようは具体的なパッケージ名を与えてください。 --> ```txt linux-headers-amd64 linux-image-amd64 util-linux util-linux-extra ``` <!-- これでパッケージの更新を止める事ができます。 具体的にはここにあるようにlinux imageとヘッダーの更新を止めておきましょう。 util-linuxはカーネルでないですが、カーネルの機能使っている コマンドたちなので、とりあえず止めておくのが無難かなと。 --> カーネルの更新を止めておく。 <!-- で、大丈夫そうだったら、 --> ```bash apt-mark unhold ``` で解除 <!-- できます --> --- <!-- 次は --> ## snapshotのとり方 <!-- なんですけれども、snapshotは --> ファイルシステムに依存してたり、LVMでなかったらだめだったり基本的に設定が面倒臭い... --- ## 楽にやる方法無いの？ <!-- と思われると思います。 --> timeshiftを使うなら簡単 <!-- にsnapshotを作成できます。 --> --- ## timeshiftとは rsyncでsnapshotを作成するツール。 ファイルシステムに依存せず簡単にsnapshotを作成できる <!-- まだ本番サーバーでは使われている事例をあまり聞かないけど、 snapshot作れるツールとしてはlinux界隈で注目されいているので、 クライアントPCや壊れても困らない環境だったら導入するのはアリだと思います。 -->  <!-- という事で、実際のtimeshiftの使い方も説明します。 簡単ですよ！ --> --- ## timeshiftでsnapshotを取ろう cuiなら下記のコマンド一発でsnapshotを取れる。 <!-- れます --> ```bash sudo timeshift --create ``` 復元も下記のコマンド後再起動で元通り <!-- になります --> ```bash sudo timeshift --restore snapshotの番号 ``` GUIのツールもあって、その場合はもっとスケジューリングなど細かく指定できる --- <!-- ということで --> ## testingのバグにぶつかったら 簡単にsnapshotで元に戻せる  <!-- ここまで聞いてtesting使うのも大丈夫そう。 トラブル時の解決策もあるしってなりました！ --> --- <!-- という事で帰ったらみなさんぜひ Debian Testingを使ってみてください。 これ以外のなんらかのトラブルがあったにせよ、Debianの知識は 今後必要なくなるって言うことはなかなか無いと思うので、 時間かけてチャレンジしてみる価値はあると思います。 --> <!-- という事で -->  --- <!-- ここまで聞いてて、 docer --> ## recommendインストールしなかったら良いのでは --- ## recommendは？ <!-- recommentってなんなんだ？っていうとdebianがなんらかのパッケージをインストールしたときに一緒に他のパッケージもインストールする機能です。 dockerでコンテナ作る時にnorecommendとする事多いと 思うんですが、実サーバーやクライアントPCで --> recommendをインストールしないようにするのはやめたほうが良い。  --- ## recommendはインストールしたほうが良い。 公式では堅牢性的に**recommendをインストールすることが推奨**されている  ---