随感録 2020年11月

2020-11-02 (Mon) Fedora 33 で Btrfs がデフォルトに

Fedora 33 がリリースされた。今回のトピックは、Workstationエディションでのデフォルト file system が Btrfs になった。

公式edition は次の5つ. Fedora 31-32 から変更なし。

  • Fedora Workstation
  • Fedora Server. このeditionは引き続き XFS がデフォルト。
  • Fedora IoT.
  • Fedora CoreOS (preview) -- CoreOS team (https://coreos.com/) が Red Hat にジョイン. この上で Docker を動かすための最小限の構成.
  • Fedora SilverBlue (preview)

Workstation のDVDを落とし, 何も考えずにデフォルト設定でインストールした。

インストーラは, ユーザ登録もなしにインストールが開始して、驚いた。再起動後にユーザ登録するようになっていた。rootパスワードを入れる場所がない。

インストールが完了し, 立ち上げると, 最初に作ったユーザからの sudo はできる。一般ユーザのパスワードが聞かれる。しかし su ができない。何ですと!!

単に, rootパスワードが設定されていないだけ。次のようにすればよい。

$ sudo passwd

本題。パーティションの切り方を見てみる。

$ df
ファイルシス   1K-ブロック    使用   使用可 使用% マウント位置
devtmpfs           1977260       0  1977260    0% /dev
tmpfs              1997072       0  1997072    0% /dev/shm
tmpfs               798832    1804   797028    1% /run
/dev/sda2         19921920 6616116 12632332   35% /
/dev/sda2         19921920 6616116 12632332   35% /home
/dev/sda1           999320  235224   695284   26% /boot
tmpfs              1997072      36  1997036    1% /tmp
tmpfs               399412      80   399332    1% /run/user/42
tmpfs               399412      56   399356    1% /run/user/1000

/home は分けているが, /var は分けていない。/tmp は tmpfs ファイルシステム。

/var/tmp は実体ディレクトリ。このディレクトリは再起動しても消えない一時ファイル用なので、これでよい。

何か, //home の表示がおかしい。同じ値だ。/etc/fstab はどうか。

# cat /etc/fstab

# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=3b75e79d-3bfa-49ce-a03d-d8f200539e80 /                       btrfs   subvol=root     0 0
UUID=545bd837-ccf2-4ebf-a23d-9898279f7028 /boot                   ext4    defaults        1 2
UUID=3b75e79d-3bfa-49ce-a03d-d8f200539e80 /home                   btrfs   subvol=home     0 0

何だこりゃ, UUID が同じになっている。ツリー表示も見てみよう。

# findmnt
TARGET                       SOURCE     FSTYPE  OPTIONS
/                            /dev/sda2[/root]
│                                       btrfs   rw,relatime,seclabel,space_cache,s
├─/sys                       sysfs      sysfs   rw,nosuid,nodev,noexec,relatime,se
│ ├─/sys/kernel/security     securityfs securit rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup           cgroup2    cgroup2 rw,nosuid,nodev,noexec,relatime,se
│ ├─/sys/fs/pstore           pstore     pstore  rw,nosuid,nodev,noexec,relatime,se
│ ├─/sys/fs/bpf              none       bpf     rw,nosuid,nodev,noexec,relatime,mo
│ ├─/sys/kernel/tracing      none       tracefs rw,relatime,seclabel
│ ├─/sys/fs/selinux          selinuxfs  selinux rw,nosuid,noexec,relatime
│ ├─/sys/kernel/debug        debugfs    debugfs rw,nosuid,nodev,noexec,relatime,se
│ ├─/sys/fs/fuse/connections fusectl    fusectl rw,nosuid,nodev,noexec,relatime
│ └─/sys/kernel/config       configfs   configf rw,nosuid,nodev,noexec,relatime
├─/proc                      proc       proc    rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc systemd-1  autofs  rw,relatime,fd=30,pgrp=1,timeout=0
├─/dev                       devtmpfs   devtmpf rw,nosuid,noexec,seclabel,size=197
│ ├─/dev/shm                 tmpfs      tmpfs   rw,nosuid,nodev,seclabel
│ ├─/dev/pts                 devpts     devpts  rw,nosuid,noexec,relatime,seclabel
│ ├─/dev/hugepages           hugetlbfs  hugetlb rw,relatime,seclabel,pagesize=2M
│ └─/dev/mqueue              mqueue     mqueue  rw,nosuid,nodev,noexec,relatime,se
├─/run                       tmpfs      tmpfs   rw,nosuid,nodev,seclabel,size=7988
│ └─/run/user/1000           tmpfs      tmpfs   rw,nosuid,nodev,relatime,seclabel,
│   └─/run/user/1000/gvfs    gvfsd-fuse fuse.gv rw,nosuid,nodev,relatime,user_id=1
├─/boot                      /dev/sda1  ext4    rw,relatime,seclabel
├─/home                      /dev/sda2[/home]
│                                       btrfs   rw,relatime,seclabel,space_cache,s
├─/tmp                       tmpfs      tmpfs   rw,nosuid,nodev,seclabel,nr_inodes
└─/var/lib/nfs/rpc_pipefs    sunrpc     rpc_pip rw,relatime

SOURCE に [/root] などが付いている。

Btrfs は、filesystem に対してサブヴォリューム subvolume を複数繋げることができる。サブヴォリュームを mount する. また, スナップショットも, サブヴォリュームに対して作成する。

Filesystemの使用実績の正しい値を表示するには, root になって, 次のようにする。こちらは /dev/ 以下のパスを指定。

# btrfs filesystem show /dev/sda2
Label: 'fedora_localhost-live'  uuid: 3b75e79d-3bfa-49ce-a03d-d8f200539e80
        Total devices 1 FS bytes used 6.14GiB
        devid    1 size 19.00GiB used 9.02GiB path /dev/sda2

19Gbytes のドライブで、使用されたのが 6Gbytes.

一般ユーザだと次のようにする. こちらはマウントポイント。

$ btrfs filesystem df /
Data, single: total=8.01GiB, used=5.96GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=512.00MiB, used=183.22MiB
GlobalReserve, single: total=16.84MiB, used=0.00B

Total の表示が正しくない。後で調べる。

2020-11-26 (Thu) Fedora 33 で gitlab.com との git pull/push が permission denied で失敗

Fedora 33 Linux で gitlab.com のリポジトリからの git pullgit push に失敗。

症状は次の様子。パーミションの問題に見えた。

$ git pull
git@gitlab.com: Permission denied (publickey,keyboard-interactive).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

ググると GitLab トラブルが多く出てくる。真に受けて GitLabの問題の線で調べていたら, 時間を浪費した。結論は、GitLab の問題ではなく, Fedora のポリシー変更の副作用だった。 ssh-agent コマンドや ssh-add (秘密鍵のagentへの追加) コマンドも関係なし。

ssh コマンドで試す。ユーザ名は git. -v オプションで詳しく出力。

$ ssh -v git@gitlab.com
OpenSSH_8.4p1, OpenSSL 1.1.1h FIPS 22 Sep 2020
debug1: Reading configuration data /home/hori/.ssh/config
debug1: /home/hori/.ssh/config line 6: Applying options for *
debug1: /home/hori/.ssh/config line 17: Applying options for gitlab.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/hori/.ssh/config
debug1: /home/hori/.ssh/config line 6: Applying options for *
debug1: /home/hori/.ssh/config line 17: Applying options for gitlab.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to gitlab.com [2606:4700:90:0:f22e:fbec:5bed:a9b9] port 22.
debug1: Connection established.
debug1: identity file /home/hori/.ssh/id_rsa_gitlab type 0
debug1: identity file /home/hori/.ssh/id_rsa_gitlab-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u7
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to gitlab.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw
debug1: Host 'gitlab.com' is known and matches the ECDSA host key.
debug1: Found key in /home/hori/.ssh/known_hosts:6
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/hori/.ssh/id_rsa_gitlab RSA SHA256:jG8P6K/hFLKLtwQ6V63ChSqaLvHVnyPwF9zemkyfTbg explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/hori/.ssh/id_rsa_gitlab RSA SHA256:jG8P6K/hFLKLtwQ6V63ChSqaLvHVnyPwF9zemkyfTbg explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: No more authentication methods to try.
git@gitlab.com: Permission denied (publickey,keyboard-interactive).

鍵の長さが短いのかなぁ? (ハズレ) 表示させるのにコマンド名が keygen というのが不細工だが、とにかく、fingerprint の表示。

$ ssh-keygen -l -v -f ~/.ssh/id_rsa_gitlab.pub 
4096 SHA256:jG8P6K/hFLKLtwQ6V63ChSqaLvHVnyPwF9zemkyfTbg hisashi.horikawa@gmail.com (RSA)
+---[RSA 4096]----+
|                 |
|                 |
|                 |
|   . . o         |
|  o +.+.S.       |
|.+ +o+.+o .  .   |
|=o+.+o+.++... .  |
|++.+.=oo==.o.=   |
|=...o.+=..=.E .  |
+----[SHA256]-----+

長さは最初の 4096. 十分な長さ。ところで、公開鍵のコメントにログインメールアドレスを入れればいいよ、みたいな解説がある。上の例はメールアドレスにしているが、違っていてもそれで弾かれることはない。普通は違うし。

公開鍵、秘密鍵を作り直して GitLab に再登録すればいいよ、みたいな解説もあるが、当然、それも関係ない。

分かれば何のことはない。すでにフォーラムで話題になっていた。

上のログで赤字にしたところがポイント。サーバ側のアルゴリズム server-sig-algs とのミスマッチ。

Workaround は, ~/.ssh/config を次のようにする。PubkeyAcceptedKeyTypes を追加。これだけで通るようになる。

Host gitlab.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_rsa_gitlab
  PubkeyAcceptedKeyTypes = +ssh-rsa

openssh-clients パッケージの設定ファイル /etc/ssh/ssh_config.d/50-redhat.conf から参照されている, /etc/crypto-policies/back-ends/openssh.config ファイルが厳しい。

このファイルは crypto-policies というパッケージで, DEFAULT, FIPS, FUTURE, LEGACY を切り替えるようになっている。"ssh-rsa" という値は, LEGACY には含まれるが, DEFAULT からは削除されている。