apt 的 invalid signatures / public key is not available (NO_PUBKEY/EXPKEYSIG/KEYEXPIRED) 問題處理方式

症狀 – apt / apt-get 操作時出現以下錯誤:

Err:4 https://dl.winehq.org/wine-builds/ubuntu xenial InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 76F1A20FF987672F
Reading package lists... Done
W: GPG error: https://dl.winehq.org/wine-builds/ubuntu xenial InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 76F1A20FF987672F
E: The repository 'https://dl.winehq.org/wine-builds/ubuntu xenial InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://deb.torproject.org/torproject.org bionic InRelease: The following signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive signing key
W: Failed to fetch https://deb.torproject.org/torproject.org/dists/bionic/InRelease  The following signatures were invalid: EXPKEYSIG 74A941BA219EC810 deb.torproject.org archive signing key
W: Some index files failed to download. They have been ignored, or old ones used instead.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://apt.puppetlabs.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7F438280EF8D349F
W: Failed to fetch http://apt.puppetlabs.com/dists/trusty/Release
W: Some index files failed to download. They have been ignored, or old ones used instead.

可以看到上面缺的 key 分別是 76F1A20FF987672F74A941BA219EC8107F438280EF8D349F ,這種情況有可能是新增了新的 apt repository 但沒有對應的 key,或是舊有的 apt repository 所使用的 key已經過期了

通常可以到對應軟體提供者的網站上找到正確的 key ,並放到 /etc/apt/trusted.gpg 這個檔案、或 /etc/apt/trusted.gpg.d 目錄下,或是透過 apt-key 的指令從 keyserver 進行下載匯入,像是這樣(以 Yarn 和 Google Cloud 的套件庫為例):

  • curl -sS https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add –
  • curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -

我們也可以透過將有問題/闕漏的 key 直接拿去問 OpenPGP keyserver ,透過 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys XXXXXXXX 的指令,像這樣:

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7F438280EF8D349F
Executing: /tmp/apt-key-gpghome.VyE6MFMrnc/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 7F438280EF8D349F
gpg: key 7F438280EF8D349F: public key "Puppet, Inc. Release Key (Puppet, Inc. Release Key) <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 74A941BA219EC810
Executing: /tmp/apt-key-gpghome.lRWvuhWnPw/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 74A941BA219EC810
gpg: key EE8CBC9E886DDD89: public key "deb.torproject.org archive signing key" imported
gpg: Total number processed: 1
gpg:               imported: 1
閱讀全文

清理 systemd 的 journal 檔案

使用 systemd 的 Linux 作業系統通常會在目錄 /var/log/journal/ 下存放 systemd-journald 這個服務所蒐集到的系統的 log 檔案,時間久了如果沒清理就可能會佔用一定大小的磁碟空間,對日常使用不會有什麼明顯影響,但是當磁碟空間不夠用、或是想要封裝、轉移系統的時候,清理這個目錄就會很有幫助 (可以少處理一些檔案),當然有這種情況時 /var/log 底下的其他 log 檔案可能也要清理,不過瞥除跑對外服務可能產生的大量 log 外,systemd 的 journal 也許會相對佔用比較多空間,可以考慮優先處理。

對於刪除不認識的檔案難免會擔心是否造成不良的影響,一般來說清除 systemd 的 journal 檔案並不會對系統造成危害,可以放心操作,但要不要清理這種事就見仁見智,保留太久的日誌有時候不見得有什麼價值 (當然還是看主機性質而定),有些人可能永遠用不到這些 log 、有些人可能經常會需要靠 log 來 debug 問題,清理後系統的 log 變少了省下空間,但如果剛好在追問題的話可能就暫時先避免類似的操作,或是清理時還是要保留一些 log 下來,以免相關資訊被清掉了增加追查問題的難度

Systemd-journald 預設使用的空間是磁碟大小的一成空間、上限是 4GB,要了解目前的上限以及使用狀況可以透過 journalctl -u systemd-journald 來得知:

$ sudo journalctl -u systemd-journald | tail -n 5
-- Reboot --
Jan 04 16:48:07 x systemd-journald[489]: Journal started
Jan 04 16:48:07 x systemd-journald[489]: Runtime journal (/run/log/journal/ef635a010d284bc38d762d2b9f0e65ac) is 8.0M, max 158.0M, 150.0M free.
Jan 04 16:48:07 x systemd-journald[489]: Time spent on flushing to /var is 177.349ms for 1008 entries.
Jan 04 16:48:07 x systemd-journald[489]: System journal (/var/log/journal/ef635a010d284bc38d762d2b9f0e65ac) is 4.0G, max 4.0G, 0B free.

也可以透過 dujournal --disk-usage 指令看目前使用的空間,像我這台主機就被佔用了 4GB :

$ du -d 0 -h /var/log/journal/
4.1G	/var/log/journal/

$ sudo journalctl --disk-usage
Archived and active journals take up 4.0G in the file system.

如果這時候找不到 /var/log/journal/ ,那有可能是因為這個目錄曾經被刪除過 (刪除後不一定會自動重建、要看設定)、或是 systemd 的設定是不會把 log 直接保存在磁碟上,這時後 log 可能就只有放在 /run/log/journal/ ,那就不是佔用磁碟空間、而是使用記憶體空間,清理的時機或動機就不太一樣。

最簡單的清理方式就是直接砍檔案,要小心的是除非之後不打算讓 journal 繼續往磁碟上寫,否則別把整個 /var/log/journal/ 資料夾都砍了,砍底下的內容就好

使用 rm 指令清理 /var/log/journal/ 目錄

這邊搭配 -rf 參數

$ sudo rm -rf /var/log/journal/*

砍完之後記得重啟 systemd-journald 服務:

閱讀全文

A rapid way to erase multiple partition tables on Ubuntu/Debian Linux

When doing labs / playing with ZFS on Linux, ZFS pool may creates a few partitions on each drive, we may want to erase all the playground partition table to start from scratch again(though it may not be required), if we have many drives like more than 10, and we want to erase them all, it’ll take a while to finish the job.

Here is a rapid method to do it, using the non-interactive command sgdisk from package gdisk – the GPT fdisk text-mode partitioning tool, with parameter -Z or -o (both work in my case):

$ sudo sgdisk -Z /dev/sda
GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.
$ sudo sgdisk -o /dev/sdb
The operation has completed successfully.

According to the help message, by specifing parameters -Z, it’ll zap (destroy) the GPT and MBR data structures and exit, and by specifing parameters -o, it’ll clear out all partition data. This includes GPT header data, all partition definitions, and the protective MBR.

Because the command sgdisk is non-interactive, so we can simply integrate the whole massive partition clean up job with shell scripts, for example:

#!/bin/bash
sudo sgdisk -Z /dev/sda &
sudo sgdisk -Z /dev/sdb &
sudo sgdisk -Z /dev/sdc &
sudo sgdisk -Z /dev/sdd &
sudo sgdisk -Z /dev/sde &
sudo sgdisk -Z /dev/sdf &
sudo sgdisk -Z /dev/sdg &

That’s it! Happy hacking!

ZFS on Ubuntu 18.04 基本設定/初始化

Ubuntu 在 15.10 開始測試 ZFS16.04 LTS 的時候正式加入了 ZFS 的支援,背後用的是 ZFS On Linux 的實做,這邊筆記一下已經使用在 Ubuntu 18.04 上了好一陣子的 ZFS 初始化過程

先安裝所需要的套件:

$ sudo apt install zfsutils-linux -y

接著建立 ZFS Pool

接著會使用到 zpool 這個指令,相關的操作都需要要有 root 權限,我這邊是要直接拿完整的整顆硬碟來用,不另外做分割,測試的時候方便起見可以直接用 /dev/sda /dev/sdb 這樣的路徑,所以一路從 sda 用到 sdz,名稱取叫 pool-ftp ,做 raidz3 讓這組 pool 一次最多可以掉三顆硬碟不掉資料,不怕掉資料可以不加這個設定、效果會等同 RAID0 ,硬碟數量如果沒這麼多但想要有個保險也可以用 raidz 或 raidz2 就好,分別為容許一顆和兩顆的硬碟失效,要 RAID1 的效果可以用 mirror 這個選項:

$ sudo zpool create pool-ftp raidz3 /dev/sda /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt /dev/sdu /dev/sdv /dev/sdw /dev/sdx /dev/sdy /dev/sdz

不過正式環境還是建議不要使用 sda / sdb 而是使用 Disk ID / Label / UUID 的方式來認硬碟,就不用擔心未來順序可能改變或亂掉的問題,如果是整批相同型號的硬碟要做處理,透過 Disk ID 其實也很方便,例如:

$ command ls /dev/disk/by-id/ata-ST8000NM0055* | xargs sudo zpool create ftp-pool

如果過程中出現了這樣的訊息,在確認硬碟上沒有其他資料的情況下可以加 -f 的參數:

/dev/sdz does not contain an EFI label but it may contain partition information in the MBR.
閱讀全文