ネットで検索しても古い操作と新しい操作が混じっているので
基本的な内容だがここに書く。
だって忘れるたびに探すの面倒臭い
なるべく、デフォルトでインストールされているコマンドを
使って説明していきます。
portage
gentoo最大の売り。
複雑だがかなり強力なpackage管理ツール
N new (not yet installed)
S new SLOT installation (side-by-side versions)
U updating (to another version)
D downgrading (best version seems lower)
r reinstall (forced for some reason, possibly due to slot or sub-slot)
R replacing (remerging same version)
F fetch restricted (must be manually downloaded)
f fetch restricted (already downloaded)
I interactive (requires user input)
B blocked by another package (unresolved conflict)
b blocked by another package (automatically resolved conflict)
emerge
やれることが膨大で、運用者でも
かなりいろんなオプションを使い分けることが要求される。
実際手を動かして覚えよう。
ebuild + mergeツールで
emergeか。
# 毎日一回定時に上がるパッケージリストと同期を取る。
# emerge --syncに比べて、公式のレポジトリの負荷も、こちら側のマシンの負荷も少ないため
# 普段のパッケージリストの同期にはこれを使う。
emerge-webrsync
# 一番最後に更新されたパッケージリストと同期を取る。
# 公式としては負荷軽減のため一日に一回のみが推奨される。
# 使うパターン
# 1. emerge-webrsyncしてもパッケージの依存関係が壊れているいて、最新のパッケージを確認したいというときに使うと良い。
# 2. eselect repositoryで特定のrepositoryを有効、無効に切り替えたときのパッケージの同期。
# よって今は普段は使わない。
emerge --sync
# 特定のレポジトリだけ同期する場合
# 公式以外のレポジトリの同期に使われる。
emerge --sync repository名
# パッケージ検索
emerge -S <pacakge_name>
# パッケージインストール時の依存関係の表示
# gentooは割と依存関係を意識してインストールする必要があるのでよく使う。
emerge -pv <package_name>
# パッケージの依存関係の表示(ツリー)
# 依存関係親子関係で不具合がある場合によく使う。
emerge -pt <package_name>
# パッケージ詳細
emerge --info
# バージョンを指定してパッケージインストール
# ex) emerge "=app-editors/vim-8.2.4586"
emerge "=<package_name>-version"
# 指定のバージョン以上のパッケージをインストール
# ex) emerge ">=app-editors/vim-8.2.4586"
emerge ">=<package_name>-version"
# 指定のバージョン未満のパッケージをインストール
# ex) emerge "<app-editors/vim-8.2.4586"
# 下の~の記法で事足りるので普通は使わない。
emerge "<<package_name>-version"
# 指定のバージョン以下で最大のものをインストール
# ex) emerge "~app-editors/vim-8.2"
# vimの-8.2より下のマイナーバージョンで一番大きいものを取ってくる。
emerge "~<package_name>-version"
# パッケージインストール
emerge <package_name>
# パッケージインストール(インストールするかどうか聞かれる)
emerge -a <package_name>
# パッケージアップデート
emerge -u <package_name>
# すべてのパッケージをアップデートする。
emerge -u @world
# すべてのパッケージを深い依存関係含めてアップデートする
# NはUSEキーワードを追加、変更してないなら不要。
# osのカーネル含めてアップデート
# 久しぶりに更新するときに必要なことが多い。
# 久しぶりにやると依存関係を治すのに苦労するので、一ヶ月に一回はしたほうがいい。
# システムパッケージのみすべてアップデートなら emerge -uDN @systemでよい。
emerge -uDN @world
# build時依存関係含めてアップデートする。
# build時依存とはパッケージのコンパイルのときのみに使うツール。
# たまに更新が求められる。主にpython系のツールで依存関係が壊れているときに使う。
emerge -uDN --with-bdeps=y @world
# インストール済みのpackage検索
qlist -IRv <pacakge_name>
# パッケージを不要なリスト(depclean時の削除リスト)に入れる。これのみではパッケージは削除されない。
emerge --deselect <package_name>
# 不要なパッケージを削除する。
# かなりパッケージを削除するならemerge -NDu @worldしたあとにやると安全。
emerge --depclean
# パッケージを強制的に削除。依存関係が壊れたときに使う。普段は使わない。
emerge --unmerge <package_name>
# パッケージをインストールするが、@world, @selectedに書き込まないし、@world, @selectedを読んでインストール済みかどうか考えずとりあえずインストールする。次のいずれかの理由で使う。
# 1. 依存関係が壊れているなどの理由でパッケージを再インストールする場合
# 2. 試しに使ってみたいなどお試しですぐアンインストールする場合。(@worldに書き込まれてないパッケージは--depcleanの対象になるため、意識しなくても--depclean時に削除される。)
emerge --oneshot <package_name>
# 古いパッケージを残す。
# 戻す可能性がある場合に使う。
# kernelとか。dbとか。openrcからsystemdに移行時にopenrc削除したくないとか。
# 割とシステムに影響でかいやつに使う。
emerge --noreplace <package_name>
sets
どのような形でインストールされたか、どのような形でインストールするが記録される場所。
パッケージをまとめたやつ。
複数の場所に属しているときももちろんある。
emergeを行うときにここから選択する。
下記のコマンドでsetsの一覧を確認できる。
emerge --list-sets
- @world すべてのebuildパッケージはインストールされるとここに記録される。
- @system システム関連のパッケージだけここに入る。
- @selected 自分でemerge パッケージ名などの形で直接選んだものがここに記録される。
- @profile eselect profile で自分が自分が選択したパッケージが入る。
- @module-rebuild kernelを再構築したときに再ビルドが必要なパッケージがここに入る。vbovfとか仮想環境周り。
- @security セキュリティアップデート。脆弱性が見つかったりしたやつの修正がここに入る。
つまり@world = @system + @selectedになる。
各setsのパッケージ内をみたい場合は下のようにすると表示される。
# ゼロじゃなくてオー
emerge -pqeO @<set>
詳しくは公式のpackage setsのドキュメントを見よう。
masked packageの解除方法
パッケージリストはあってもインストール時にmaskされていると表示される事がある。
これはtest中のパッケージだったり、パッケージ自体に不具合がある、指定のパッケージのときにはマスクされる、ライセンスを受け入れていなかったりなどの理由である。
ライセンス以外の場合
たいていの場合はtest中のパッケージだが使いたい場合だろう。
仮想環境や、開発者ツールは割とtest中のパッケージだったりするので、
クライアントPCとして使うなら割といじることが多いと思います。
これを受け入れるには
/etc/portage/package.accept_keywords/ 配下に設定を書いたファイルを置くとよい。
下に例を記す。
# vscode exists testing branch only
# if official merge request and approve this package, remove these row.
app-editors/vscode
ライセンスの場合
gentooは他のLinuxに比べてユーザーが予期しないライセンスを受け入れない用に
するためか、設定ファイルに書いて初めてそのライセンスのパッケージをインストールできるようになる。
vscodeなど開発ツールをインストールするためにmicrosoftのパッケージのライセンスを書くことは多いだろう。
これは/etc/portage/package.licenseに書き込んでいく。
/ ライセンス名という表記で
すべてのパッケージに対してこのライセンスを受け入れるという意味になる。
個別に対応するならパッケージ名
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
の用に個別に書く必要がある。
*/* google-chrome
*/* free-noncomm
*/* Microsoft-vscode
*/* microsoft-edge
*/* Vivaldi
*/* Apache-2.0
*/* BSD
*/* BSD-2
*/* MPL-2.0
*/* MIT
*/* ISC
*/* JSON
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
package mask
上までのunmaskとは逆にマスクします。
運用上では勝手にバージョンを挙げられたら困るときなどに使うでしょう。
/etc/portage/package.maskというファイル名を作って、
マスクの設定を一つのファイルをまとめて書くか、
/etc/portage/package.maskというディレクトリを作って、下記のように
個別にファイル（ファイル名は自由に決めれる。）を書くかの２択です。
好きな方を選択すればよいでしょう。
例えば、下の設定で、
gentoo-sources-6.1.0より上のパッケージはマスクされ(使えなくなる)ます。
>sys-kernel/gentoo-sources-6.1.0
使うべきでないバージョンの指定の設定になるので、pipやnpmなどのパッケージのバージョン管理と逆の向きの＜＞になる。
慣れないと混乱しやすいので注意。
portage環境変数
/etc/portage/make.confに書いたり
設定をうまくみて、判断する環境変数。
portageで使われている環境変数を
下記のようにportageq を使えば調べられる。
# USE フラグ
portageq envvar USE
# COMMON_FLAGS
portageq envvar COMMON_FLAGS
COMMON_FLAGS
COMMON_FLAGS="-O2 -pipe -march=native"
が一番無難な設定。
下に引数について書いていく。
-O2
zero でない。オーである。
どの程度ビルドを最適化するかというフラグ。
Optimize 2と覚えよう。
ほぼ固定で一般ユーザーはほとんどの場合はこれを使う。
-march
指定しないとx86_64アーチテクトとしてビルドするので、
Gentooの実行時速度という強みの一つがかける。
marchを指定するデメリットとしては
Intel,amd内で世代を変更した場合でも再ビルドする必要が出る事、
cpuがマザーボードと一蓮托生であるノートパソコンなら、
デメリットがあまりないし、nativeとしてこう。
nativeとすると今現在PCに乗っているCPUを見て
適切な値で最適化してくれる。
逆にいろんなCPUを試したい人は-marchを指定しないこと。
amdとIntelどころか、CPUの世代ごとに最適化されているため、
動作しない可能性がある。
C言語をビルドするときのフラグ
Gentoo公式より、gccや、Intelのほうが詳しく乗ってる。参考にして欲しい。
Gentoo GCC説明
gcc march説明
Funtoo cpuと世代まとめ
intelの第2世代に最適化とかそういう感じで最適化する。
-pipe
ビルドのときに途中の処理をいちいちファイルに落とさず、
パイプで処理していく。
メモリ上で処理するため、メモリが潤沢なら、ビルド時間が改善されると思われる。
メモリが潤沢出ない場合は使わないほうが良いかもしれない。
ビルド時の速度が帰って落ちる可能性もある。
この環境変数はおそらく最初触ってからみんな忘れて放置している
GRUB_PLATFORMS
Grubで64bit環境を使っているか、biosかuefiかを決定する環境変数。
ビルドしたlinux kernelのイメージをgrubでインストールするときに
内部で使っているらしい。
この環境変数ももちろん最初触ってからみんな忘れて放置している
USE
これには2つの意味がある。
- emergeするときにパッケージにどの機能をインストールするかを決定する(local USEフラグ)
- OSシステム全体としてこの機能を使うかどうかを決定する(global USEフラグ)。
1.の使い方について
システム全体に使う気は無いが、特定のパッケーじだけに使う機能がある場合に使う。
例えば、remminaのrdpの機能とgtk3を有効にする必要があるが、他のパッケージで使うつもりが
無いなら、その機能をインストールしないだけで、ビルド時間も短縮されるし、その機能をインストール
したことによって発生しうる脆弱性が起きなくなる。
/etc/portage/package.use/ディレクトリ配下に書くのがルール
1は下記の例を参考にされたい。
ex) firefoxの依存ライブラリでmedia-libs/libpxがあり、
media-libs/libpxの機能(useフラグ) postprocを有効にしたい場合。
media-libs/libvpx postproc
2.の意味については今後どんどんeselectの方に食われていくが、すべては無くならないだろう。
環境変数のUSEに設定する場合は2の意味で使われている。
インストールするパッケージによってはGlobal USEを使う事を強要される事も多い。
(わかりやすい例としてはsystemd USEフラグ。localで使うとか仕様上ありえない。systemd USEフラグについては
後述のeselect profileでsystemd関連のプロファイルを選択すると自動的にセットされる。)
2の例はremminaとsystemdがわかりやすいだろう。
ex) remminaでrdp(windowsのリモートデスクと同じプロトコル)を使いたい。
USE="${USE} gtk3 rdp"
PATHの連結のように
USE="${USE} useフラグ"
という形で追加していく。
Global なUSEフラグは下のコマンドを実行するとリストで表示される。
portageq envvar USE | xargs -n 1
# パッケージリスト中でパッケージで指定のUSEフラグを持つもの(インストールされていないものも含む)。
quse <use_flag>
# 現在のsystemにインストールされているパッケージで指定のUSEフラグを持つもの。
quse -I <use_flag>
PYTHON_TARGETS
gentooは速度改善のためか、システムの至る所でpythonを使っている。
パッケージがpythonのバージョンに依存している事はよくある。
使い方はUSEフラグと全く同じで、
PYTHON＿TARGETS
グローバルのPYTHON_TARGETSを変えたら、
emerge -uDN @world
としてシステム全体を更新しよう。
eselect
portageのUSEフラグ管理をすることによりソフトウェアのバージョン管理してくれるやつ。
eselect をセットすることにより適切なUSEフラグが適切にセットされ、eselectをセットすることで
不要になったパッケージは--depcleanの対象に入り、依存関係を壊しうるパッケージはmaskされる。
試しに壊れても良い環境で、下のようにprofileを変更してみよう。
eselect profile set 13
# グローバルの環境変数USEが変更され、
# multilibが入ってくる事がわかる。
portageq envvar USE | xargs -n 1 | grep multilib
emergeの複雑な処理を勝手に判断してやってくれるスグレモノ。
このまま
emerge -uDN @world
としたら、ほしい状態が作れるという事。
pentoo archのblackarch, debianのkaliに相当するoffensive securityツールをまとめたやつ。
英語圏含めて業務で使われているの聞いた事ないので現在では割と趣味の領域。
blackarchの方はkaliよりツールが多いので採用されることはあるらしい。
代表的なeselect
- eselect profile systemd使うかとか、selinux使うかとかシステム全体に関わるもの。
- kernel 現在システムで使っているカーネルをソースを管理してくれている。
- java システムで使われているjavaのバージョン管理
プログラミング系のeselectは複数のバージョンをインストールしたら
勝手にeselectができる。
上を見てたらわかるが、プログラミング言語のenv系のツールはgentooでは今後、
eselect側ですべて管理される方針になるっぽい。それで足りなかった場合に使う感じで。
eselect repository
かつては公式以外のレポジトリやダウンストリームのレポジトリを使うときは
laymanを使っていたが、現在はeselect-repositoryを使うこと。
ただ、laymanで書かれている記事とeselect repositoryの記事と混在しているので注意。
下記のようにしてインストールする。
emerge app-eselect/eselect-repository
レポジトリ一覧
eselect repository list
レポジトリ有効化
eselect repository enable <you want to enable repository>
gentoo公式のレポジトリと混ざると、
問題の発生時の切り分けが面倒なのでできるだけ影響範囲が小さくしておく。
echo '*/*::guru' >> /etc/portage/package.mask/guru
使うレポジトリから個別に有効にしていくと良い。
echo 'app-backup/timeshift::guru' >> /etc/portage/package.unmask
メジャーなレポジトリを並べていく。
archと同様、全体的にダウンストリームはまだ若い。
debianやfedoraの用に強力なダウンストリームが無いのは辛い。
guru
gentooのコミュニティレポジトリ。
当然、gentoo公式より不安定
ここからgentoo公式にレポジトリが移動する事もままある。
archlinuxにおけるAURレポジトリ。
つまり、あまり信用しない事。
使うことになりそうなのはtimeshiftぐらいだろう。
nest
gentooの個人用レポジトリ
guruよりさらに不安定
オレオレレポジトリ。つまり全く信用するな。
pentoo
gentooのoffensive用レポジトリ群。
現在では割と趣味の領域。
セキュリティエンジニアでgentoo使いでもpentoo使うより、
仮想環境でkali動かしている人の方が多い。
Kaliどころか、black archのほうがずっとユーザーは多いだろう。
pentoo公式もまだBetaだと言っている。
githubにある野良レポジトリ
野良とはいえ、gentooのcommiterのものなら信頼できる放置されているのもあるけど。
Gentooはgolangと同じくgithubのレポジトリをパッケージレポジトリに使えるという
強力な個性を持っている。
debianやrhelと違ってパッケージファイルを予め作る必要がないのだ。
下のコマンドを実行するだけで、githubのレポジトリを使うことができる。
eselect repository add test git https://github.com/test/test.git
もしあなたが、企業に働いていてGentooでPCを統一する場合は
社員がアクセスできるgithubレポジトリを作るだけで、
社内独自の環境を構築できるということ。
運用について
更新の頻度
クライアントPCとして使うなら、ブラウザが脆弱性抱えるの怖いとか、
サーバーなら一週間に一回ぐらいは同期を取っておいた方がいいだろう。
ソースコード削除
ソースコードをダウンロードしてきてビルドするなで、windowsよりもずっと大きな容量を取る。
普段遣いのPCでも最低1TBはほしい。
また、自分でパッケージを作る事になるともっと多い。
半年ならないうちに自分も500GB以上容量を取っていた。
その場合はソースコードを削除しよう!
ecleanを使えば削除できる。
emerge app-portage/gentoolkit
ecleanについて下記のただし下記がある。
デフォルトでは、現在のリポジトリ内のebuild ファイルに関するあらゆるソースファイルもバイナリパッケージも、削除されることはありません。なぜならば、現在のリポジトリツリーにあるパッケージについては、ダウングレードされたり、以前にアンインストールしたものでも再インストールされたりする可能性があり、役に立つかもしれないからです。
例えば、 foo-1.0 および foo-1.1 というパッケージがリポジトリ内にあるとします。foo-1.0 から foo-1.1 にアップグレードした後に eclean distfiles を実行しても、どちらのソースファイルも削除されません。なぜなら、foo-1.1 に不具合が見つかる可能性もあり、ユーザーが foo-1.0 を再インストールするかもしれないので、その際に再ダウンロードすることを省けるからです。
と書かれているが、普段使いだとこれを使わないと容量を取りすぎて、使い辛いと思われる。
また、ガチガチにサーバーでやる場合以外はそこまで必要ではないし、
現在の物理サーバーなら何十かから何百Tバイトクラスなので、
gentooのソースコードのせいで容量が云々というレベルまで
圧迫されることは無いだろう。
組み込みでやる場合は、知識として要求されるかもしれない。
使い方
ソースコードの削除
# 何を消すかリストで見せる。
eclean-dist -p
# 削除
eclean-dist -d
バイナリの削除
# 何を消すかリストで見せる。
eclean-pkg -p
# 削除
eclean-pkg -d
kernelビルド
gentooの魅力と面倒臭さの一つであるのがこのカーネルビルドだ。
ビルド時にkernel configの変数を参照することにより、自分好みの設定を作ることができる。
linuxを今使っている人は下のコマンドを実行してみよう。
zcat /proc/config.gz
ざっと変数っぽいものが流れてきたと思う。これが現在動いているLinux kernel
に設定されている変数だ。
ほとんどのlinuxディストリビューションは使うか使わないかわからない変数も
雑にビルドされているため、使わないカーネルの機能も有効化されている。
このため、セキュリティに本当に気をつけるなら、使うことはない機能をビルド
していることはあまり良い設計、システムではないと言える。
しかし、gentooはそもそもほとんどのconfigを無効にしており、最低限の
ものしか有効化されていない。
そのため、
自分でkernelパラメータを設定してビルドすることにより、
sys-kernel/gentoo-sources
ビルドし直し
新しいkernelのソースがportageに入ったら、
ビルドし直そう。
sys-kernel/gentoo-sourcesにアップデートがあり、適用した場合は
/usr/src/linux-*-gentoo
という形式でカーネルのソースコードがダウンロードされている。
これをeselect kernelコマンドで新しいソースコードを適用させる。
# 現在ダウンロードしたkernel 一覧
eselect kernel list
# 新しく適用するカーネルを設定する。
eselect kernel set <num>
ここで重要なのは
eselect kernel setとは下記のコマンドを実行するコマンドである。
ln -s /usr/src/linux /usr/src/linux-選択したversion-gentoo
つまり/usr/src/linuxへのシンボリックリンクを貼っているということである。
ここから新しいカーネルのためにカーネルのconfigを行うわけだが、
最初からconfigを自分で考えるのは手間だ。
このため、基本的には現在動いているカーネルを下のようにして設定を使いまわす。
zcat /proc/config.gz > /usr/src/linux/.config
これで現在動いているカーネルの設定を新しいソースコードの.configに移すことができた。
この後は/usr/src/linuxに移動して下記のようにして新しいカーネルをビルドする。
genkernel --oldconfig --menuconfig all --utils-cflags="-march=native"
--oldconfigは/usr/src/linux配下にある.configを使ってビルドするという意味。
--utils-cflags="-march=native"は/etc/portage/make.confと同じように
nativeフラグをつけてビルドするという意味である。
-O2, -O3の最適化についてはMakefileを見る限り特に指定しなくても考えてくれる。
ビルドが終わったら、下記のコマンドで新しくビルドしたOSをブートメニューに追加します。
grub-mkconfig -o /boot/grub/grub.cfg
再起動後にシステムで動いているカーネルを確認すると新しい
ものが反映されているはずだ。
uname -r
カーネルに依存するパッケージの再ビルド
新しいカーネルを導入した場合は、カーネルに対応したパッケージにビルドし直す必要がある。
これは主に仮想環境などのカーネルの機能に依存しているパッケージのモジュールだ。
virtualboxの依存関係のパッケージなどでよく求められる。
新しいカーネルを導入したときにmodule-rebuildセットをアップデートしてみよう。
emerge -u @module-rebuild
古いkernelの削除
使っていない古いkernelをそのまま放置しておくと
/boot配下が大きくなってしまい、新しいカーネルをビルドできなくなる。
なので、ある程度の周期で削除しよう。
これはGentooに限らず、DebianやRhelなど他のOSでもよくやります。
しばらく使っているとバグに当たる可能性もあるので、
現在メインで使っているkernelとそれ以外に動くカーネルを2つは計３つは最低残しておいた方がいいです。
# ディレクトリ内確認
ls -1 /boot
ここにあるkernelバージョンに対応したinitramfs, system.map, vmlinuz
でいらないファイルを削除することで、カーネルを削除します。
# 削除されるファイル確認
ls -1 /boot/*-5.15.74-*
# 削除
rm /boot/*-5.15.74-*
削除した場合はbootメニューに反映させるため、bootメニューを作り直す。
grub-mkconfig -o /boot/grub/grub.cfg
古いカーネルモジュールの削除
gentooはカーネルと違ってそんなに容量取らないし、
bootパーティションに配置されているわけでないので、
そんなに切迫されることはない。
結構放置していても数GBぐらいしか容量取っていないので。
ただ、DeianやRhelだと結構容量取っていることはある(それでも2,30GB程度だろうが)。
気になる人は使わない古いカーネルに対応したモジュールを削除しておこう。
カーネルモジュールは/lib/moules/配下のカーネルバージョンに対応したディレクトリに配置される。
# 容量の合計確認
du -sh /lib/modules
# ファイル確認
ls -1 /lib/modules
rm -r /lib/modules/5.15.26-gentoo-x86_64
ブラウザのおすすめ
firefoxはおすすめできません。
これはランタイム依存にも、ビルド時依存にもNetworkManagerが使われているためです。
これからはsystemdの時代ですし、Gentooを使っていると、
システム周りも色々なパッケージを使ってみたい、試してみたいと思うと思います。
余計なトラブルを避けるためにもfirefox以外のブラウザをおすすめします。
また、firefoxはchromium一族と全然違うためにビルド時依存にfirefoxのためだけに必要なパッケージがシステムに
増えます。spidermonkyとか、アセンブリとか...
eclassを見る限り自分たちでビルドせずに、パッケージを撮ってきて、
runtime依存のライブラリを追加しているだけになりますが、
google-chromeやMicrosoft-Edge, Vivaldiをおすすめします。
gentoo向けにリリースしていないし、ビルドもしていないので、ちゃんと動くか不安な人も
多いと思いますがちゃんと動きます。
もし、自分でeclassという形でビルドしたいならブラウザをchromiumがおすすめです。
ただし、chromiumはawsやGCPのサポートブラウザに入っていないので動作不具合あっても、
サポートされているchrome使ってねと言われると思います。 (実際AWSのサポートに聞きました。)
chromiumと別にchromeやedgeを使うことになります。
まとめ
割と覚える事多いですね...
学習コストが高く、公式のwikiが情報散らかってるので、初心者にはかなりキツイOSだと思います。
依存関係の多くがpythonなのが辛い...
OSの依存関係はいつかgolangかrustに変わりそうな気がする。
また面倒臭がりにも向いていません。
面倒臭い人はDebianの方が向いています。