AURヘルパー pikaur
Arch Linuxは基本的なパッケージは公式リポジトリで配布していますが、それとは別にユーザコミュニティが自主的に配布・配布しているものもあります。それがArch User Repository(AUR)です。
AURを手元のArch Linuxで使用するためには、本来ならばGitを使ってローカルにクローンをダウンロードし、パッケージを展開してPKGBUILDを編集し、makepkgでパッケージを作成する必要があります。しかし毎回これを手動でやるのは骨が折れます。これらの作業をある程度自動化し、AURパッケージのダウンロードからインストールまでを一手に面倒をみてくれるのがAURヘルパーと呼ばれるツールです。
AURヘルパーにはいくつか種類があり、それぞれの特徴は以下のリストによくまとまっています。
https://wiki.archlinux.org/index.php/AUR_helpers
その一部を抜粋したものが以下の表です。
「Pacman wrappers」はpacman互換という意味です。コマンド体系がほぼpacman準拠となっており、pacmanと同じように違和感なくパッケージ管理が可能になります。
どのAURヘルパーを使用するかは好みの問題ですが、筆者はこの中から pikaur を選択しました。それほどの根拠はありませんが、少なくともパッケージ評価としてはオールグリーンで問題が少なそうなところ、Pythonで書かれていることが理由になります。
また、備考欄に「dynamic users」と書かれていますが、これは pikaur のみに備わる特徴で、systemdの機能である動的ユーザーに対応しています。これは /etc/passwd に存在しないユーザを動的に生成するもので、この機能のおかげで本来ならばroot権限でパッケージの管理を行わなければならないところを、 pikaur は一般ユーザ権限のままほとんどのことができてしまいます。これは地味に便利な機能です。
pikaur のインストール
前置きが長くなりましたが、 pikaur のインストール方法です。
まず、システムにインストールされていなければ base-devel と git を先にインストールします。
$ sudo pacman -S --needed base-devel git
AURに存在するパッケージは pacman からはインストールできません。システムにAURヘルパーが存在しない場合、ひと手間が必要です。pikaur 自身もまたAURパッケージなので、初回は以下の手順でインストールします。
$ git clone https://aur.archlinux.org/pikaur.git $ cd pikaur $ makepkg -fsri
pikaur が無事にインストールされた後は、AURパッケージはすべて pikaur で管理できるようになります。 よく使用する代表的な使用方法を列挙します。
パッケージのアップグレード
$ pikaur -Syu
公式リポジトリあるいはAURリポジトリからパッケージの検索
$ pikaur -Ss [検索したいパッケージ名]
インストールされたパッケージの検索
$ pikaur -Qs [検索したいパッケージ名]
孤児パッケージの表示
検索するには以下のようにします。
$ pikaur -Qdt
同時に削除するには以下のように使います。
$ pikaur -Rs $(pikaur -Qdtq)
パッケージのインストール
pikaur を含むいずれかのAURヘルパーをインストールしてしまえば、その後は以下のコマンドでパッケージをインストールできます。
$ pikaur -S [パッケージ名]
パッケージの削除
指定したパッケージのみを削除するには以下のようにします。
$ pikaur -R [パッケージ名]
指定したパッケージと同時に依存するパッケージをも削除するには以下のようにします。
$ pikaur -Rs [パッケージ名]
おわりに
以上、pikaur の使用方法自体は pacman とほぼ同じことがおわかりいただけたと思います。違いがあるとすれば、pacman の場合は必ず sudo による権限の昇格が必要でしたが、pikaur は必要がないことです。このおかげで少しだけコマンド行が短くなるという恩恵があります。
pikaur はマイナーではありますがたいへん便利なAURヘルパーなのでぜひ試してみてください。
Macの「ネットワーク」で見えるLinuxコンピュータのアイコンを変更する
Linuxにavahiをすでに導入済みの方が対象です。
Mac同士なら問題ないのですが、相手がLinuxの場合、Finderの「ネットワーク」で表示されるアイコンがのっぺらぼうな味気ないものになり、何となく落ち着きません。そんなときのavahiの設定例です。
avahiのみの場合
/etc/avahi/services/device-info.service
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=RackMac</txt-record>
</service>
</service-group>
model=RackMacの部分は、適切なコンピュータの種類を記述します。このRackMacの部分は、Mac本体の以下のファイルを参照すれば使用できるものがわかります。 /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist
avahiとnetatalkが導入されている場合
もしavahiとnetatalkが同時に動作している場合は、以下の設定でうまくいくでしょう。
/etc/avahi/services/afpd.service
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=RackMac</txt-record>
</service>
</service-group>
Macでの表示例
Macではこのような表示になります。
ちゃんとラックマウント型コンピュータのアイコンに変更されています。
Arch Linuxでnetatalk
こちらのWikiがすべてですが、Arch Linuxでnetatalkを実際に導入するときの手順を記します。
インストール
$ pikaur -S netatalk
netatalkはAURパッケージです。AURを取り扱える適当なパッケージマネージャを先に導入し、netatalkをインストールします。自動的にソースからコンパイルしますが、途中で以下のような選択肢が出てきますので適切に処理します。
( サポートがないパッケージ: 潜在的に危険です ! )
==> PKGBUILD を編集しますか ? [Y/n] ("A" で中止)
==> ----------------------------------
==>
==> netatalk の依存パッケージ:
- avahi>=0.6 (既にインストールされています)
- libldap (既にインストールされています)
- libgcrypt>=1.2.3 (既にインストールされています)
- python2 (既にインストールされています)
- dbus-glib (既にインストールされています)
- pam (既にインストールされています)
- libevent (パッケージが見つかりました)
- python2-dbus (パッケージが見つかりました)
==> netatalk.install を編集しますか ? [Y/n] ("A" で中止)
==> ------------------------------------------
==>
==> netatalk のビルドを続行しますか ? [Y/n]
==> ----------------------------
==>
==> パッケージのビルドとインストール
==> netatalk に欠けている依存パッケージをインストールあるいはビルド:
依存パッケージでまだ導入されていないものがあれば、そちらから先にインストールされます。
設定例
インストール後、/etc/afp,conf を適切に設定します。
[Global] ; Global server settings mimic model = RackMac ※ネットワーク上に表示するアイコンの種類 log level = default:warn log file = /var/log/afpd.log hosts allow = 192.168.0.0/16 ※接続を許可するネットワーク範囲 uam list = uams_dhx2.so uams_guest.so guest account = guest ※ゲストアカウントを指定 vol preset = My Default Values [My Default Values] ※後述 ea = samba file perm = 0664 directory perm = 0775 [Homes] basedir regex = /home [Shared Volume] ※共有ボリューム path = /srv/share rwlist = guest file perm = 0660 directory perm = 0770 [My Time Machine Volume] ※MacからTime Machineとして利用するボリューム path = /path/to/backup time machine = yes
mimic modelはnetatalkが動作しているコンピュータの種類を指定します。例）RackMac, Xserve, PowerBook, PowerMac, Macmini, iMac, MacBook, MacBookPro, MacBookAir, MacPro, AppleTV1,1, AirPort
My Default Valuesにて ea = samba としていますが、これはsambaとの相互運用をするときの設定です。拡張属性をsambaの方式と合わせます。以下のブログが詳しいです。
起動と恒常化
systemdにサービスとして登録します
$ sudo systemctl start netatalk
問題なく起動できることを確認し、以下で恒常化します。
$ sudo systemctl enable netatalk
その後発生した問題（自環境）
ここからは自環境で発生したことなので他には当てはまらないと考えていますが、事象ととして記します。
設定でゲスト接続を有効にしたのですが、どうも上手く接続できません。原因を探るとgroupが異なるためにアクセス拒否されている状態でした。しかし、netatalkではgroupを設定する項目が見当たりません。そのため筆者の環境ではnetatalkの使用を諦め、sambaのみの運用となっています。
ASRock J4205-ITXでのlm_sensors
まずは公式リポジトリから lm_sensors パッケージをインストールします。
$ pacman -S lm_sensors
lm_sensorsの設定
自動検出
マザーボードに搭載されているセンサー類は多くの種類がありますが、 lm_sensors はそれを自動検出する以下のコマンドがあります。
# sensors-detect
以下は ASRock J4205-ITX での検出結果です。
# sensors-detect revision $Revision$
# Board: ASRock J4205-ITX
# Kernel: 4.17.5-1-ARCH x86_64
# Processor: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz (6/92/9)
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 16h thermal sensors... No
AMD Family 15h power sensors... No
AMD Family 16h power sensors... No
Intel digital thermal sensor... Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor... No
Intel 5500/5520/X58 thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes
Found unknown chip with ID 0xd121
(logical device B has address 0x290, could be sensors)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
# DMI data unavailable, please consider installing dmidecode 2.7
# or later for better results.
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Found unknown SMBus adapter 8086:5ad4 at 0000:00:1f.1.
Sorry, no supported PCI bus adapters found.
Module i2c-dev loaded successfully.
Next adapter: SMBus I801 adapter at f040 (i2c-0)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Next adapter: i915 gmbus dpb (i2c-1)
Do you want to scan it? (yes/NO/selectively):
Next adapter: i915 gmbus dpc (i2c-2)
Do you want to scan it? (yes/NO/selectively):
Next adapter: i915 gmbus misc (i2c-3)
Do you want to scan it? (yes/NO/selectively):
Next adapter: DPDDC-A (i2c-4)
Do you want to scan it? (yes/NO/selectively):
Next adapter: DPDDC-B (i2c-5)
Do you want to scan it? (yes/NO/selectively):
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `coretemp':
* Chip `Intel digital thermal sensor' (confidence: 9)
Do you want to generate /etc/conf.d/lm_sensors? (YES/no):
Created symlink /etc/systemd/system/multi-user.target.wants/lm_sensors.service → /usr/lib/systemd/system/lm_sensors.service.
Unloading i2c-dev... OK
Unloading cpuid... OK
現在値の表示
sensorsコマンドで現在の値が表示されます。
# sensors
ASRock J4205-ITXの場合、以下のように表示されるはずです。
acpitz-virtual-0 Adapter: Virtual device temp1: +40.0°C (crit = +100.0°C) coretemp-isa-0000 Adapter: ISA adapter Package id 0: +39.0°C (high = +105.0°C, crit = +105.0°C) Core 0: +39.0°C (high = +105.0°C, crit = +105.0°C) Core 1: +39.0°C (high = +105.0°C, crit = +105.0°C) Core 2: +39.0°C (high = +105.0°C, crit = +105.0°C) Core 3: +39.0°C (high = +105.0°C, crit = +105.0°C)
何やら acpitz-virtual-0 の温度が40度で、CPUコア温度が39度と言っていますね。ここでの acpitz-virtual-0 はマザーボード上のセンサーではないかと推測できます。
もう少し詳しく情報を見たい場合は以下のようにします。
# sensors -u
ASRock J4205-ITXの場合、このように表示されました。
acpitz-virtual-0 Adapter: Virtual device temp1: temp1_input: 40.000 temp1_crit: 100.000 coretemp-isa-0000 Adapter: ISA adapter Package id 0: temp1_input: 40.000 temp1_max: 105.000 temp1_crit: 105.000 temp1_crit_alarm: 0.000 Core 0: temp2_input: 39.000 temp2_max: 105.000 temp2_crit: 105.000 temp2_crit_alarm: 0.000 Core 1: temp3_input: 39.000 temp3_max: 105.000 temp3_crit: 105.000 temp3_crit_alarm: 0.000 Core 2: temp4_input: 39.000 temp4_max: 105.000 temp4_crit: 105.000 temp4_crit_alarm: 0.000 Core 3: temp5_input: 39.000 temp5_max: 105.000 temp5_crit: 105.000 temp5_crit_alarm: 0.000
lm_sensorsの自動起動
sensors-detect の中での設問で、Do you want to generate /etc/conf.d/lm_sensors? (YES/no): をそのまま空欄かYESとすれば、 systemdのサービスとして組み込まれ、システム起動時に自動的に起動します。
lm_sensors の systemdユニットの状態を確認するには以下のようにします。
$ systemctl status lm_sensors
Linuxでシステム丸ごと新HDDに引っ越し
すでに過去の記憶になりつつありますが、HDDを換装しLinuxのシステムを丸ごと引っ越ししたときの手順を記します。
Linuxシステムでストレージだけ変えたい場合、通常は一からインストールするものですが、中身に特に変更がなくただ単にHDDのみを入れ替えたい場合には使えます。新規インストールよりは省力化できます。
新旧2つのHDDを同時に接続する
/dev/hdaに新ディスクを装着、/dev/hdcは既存ディスクとする。
システム起動
/dev/hdc からLinuxを起動する。
パーティション切り分け
cfdiskコマンドを使用する。
# cfdisk /dev/hda
ここでは以下の構成にした。 hda1 Boot Primary Linux 32M hda2 Primary Linux swap 1024M hda3 Primary Linux 残り全て
フォーマット
# mkswap /dev/hda2 # mke2fs /dev/hda1 # mke2fs -t ext4 /dev/hda3
/boot をdumpで丸ごとコピー
# mount /dev/hdc1 /boot # mount /dev/hda1 /mnt/hda # cd /mnt/hda # dump 0uaf - /boot | restore xf -
set owner/mode for '.' [yn]と聞かれたらyとする。
# cd / # umount /mnt/hda # umount /boot
/ （root）を丸ごとコピー
# mount /dev/hda3 /mnt/hda # cd /mnt/hda # dump 0uaf - / | restore xf -
set owner/mode for '.' [yn]と聞かれたらyとする。
# cd / # umount /mnt/hda
grubのインストール
# grub --no-floppy
> root (hd0,0)
※ "root ("でタブを押し、インストールするべきHDを見極める
> setup (hd0)
> quit
grub以外のブートマネージャを使用している場合は適切にインストールする。
再起動
システムをシャットダウンし、 新HDDを /dev/hdc につなぎかえる。旧ディスクは取り外し、起動できることを確認する。
HDDリトラクト音対策
Linuxで静音サーバーを構築する際、あらゆる音を消したくなるのが情というものです。そんな中、構成上HDDを使用している場合、アクセスしていないときでも常に「コツ、コツ、コツ、コツ」という音が定期的に聞こえてくる。これがHDDのリトラクト音というものです。調べたところ、これは消せることがわかりました。以下設定方法です。
hdparm
HDDの様々なパラメータ調節を行えるツール。入っていない場合はインストールしましょう。
様々なオプションがありますが、今回使用するのは -B オプションです。これはAPM（Advanced Power Management）機能を制御するもので、値が低いほど積極的な電源管理をすることを意味し、255ならばAPMを無効にするというものです。リトラクト音を消すためにはAPMを無効にする必要がありました。
# hdparm -B255 /dev/sdX
sdXは該当するHDDのデバイス名を指定。 APMが無効になったかどうかは以下で確認。
# hdparm -I /dev/sdX
Capabilities:
Advanced power management level: disabled
恒常化
hdparmが成功することを確認したら、それを起動時に有効になるように設定します。
/etc/hdparm.conf の場合
apm = 255
/etc/conf.d/hdparm の場合
sata_all_args="-B255"
/etc/laptop-mode/laptop-mode.conf の場合
HDPARM_POWERMGMT=255
Windows 10のネットワーク探索周り
Windows 10をはじめ、最近のWindowsのネットワーク探索まわりはどうにも混沌としています。以前はNBT（NetBIOS over TCP/IP）だけを押さえていれば問題はなかったのですが、そのNBTもレガシーな技術となりだんだんと使用されなくなっていく方向性です。その代替として昨日の記事ではLLMNRとLLTDが登場したということを紹介しましたが・・。
alecriarstudio.hatenablog.com
改めて調査したところ一部誤りがありました。Windows Vista以降のすべてのWindowsでネットワーク探索を担うのはLLMNRとLLTDのみではなく、LLDP、WSDという機能もまた追加されました。
ネットワーク探索のプロバイダ
LLTD、LLDP、WSDのいずれも、ネットワーク探索におけるプロバイダと呼ばれるものです。かつてWindows XP以前はNBTという単一の機能で提供され「コンピューターブラウザー」と呼ばれていましたが、Windows Vista以降はコンピュータを検索するさまざまな方法が導入されネットワーク探索と呼ばれるようになり、そこで使用可能な検索サービスがプロバイダという形で集約されました。プロバイダは一つだけを有効にすることも複数を有効にすることもできます。以下にプロバイダの一覧を示します。
| プロバイダ名 | 機能 |
|---|---|
| コンピューターブラウザー | NBTを使った探索。Windows XP以前のレガシーな方法 |
| LLTD | 元々はWindows Vista、7にてネットワークマップを作成するために使われたLLTD（Link-Layer Toplogy Discovery）プロトコルを使った探索 |
| LLDP | |
| LLMNR | IPv6のローカルセグメント向けの名前解決LLMNR（Link-Local Multicast Name Resolution）を使用した探索 |
| WSD | WSD（Web Services on Devices）を利用した探索 |
| UPnPデバイス | UPnPプロトコルによる探索 |
| SSDP Discovery | SSDP（Simple Service Discovery Protocol）による探索。ルータ等に採用されている |
| レジストリ | レジストリに記録されたホストも列挙できる |
| WCN | 無線LANの設定用の機能WCN（Windows Connect Now）による探索 |
LLTD
Windows VistaやWindows 7を使ったことがある方にはお馴染みの「ネットワークマップ」。
このネットワークマップの作成を自動的に行っていたのがLLTDでした。このLLTDですが、現行のWindows 10でもネットワークアダプタの設定画面でその片鱗をうかがうことができます。
そして一番重要な点ですが、LLTDもネットワーク探索を提供する機能なので、これを有効にした場合エクスプローラで「ネットワーク」を開いたときネットワーク上のコンピュータとして表示されることを期待するのですが、結果として「ネットワーク」には表示されません。
LLDP
LLTDと非常にまぎらわしいですが、LLDP（Link-Layer Discovery Protocol）はIEEE 802.1abで標準化されたネットワーク探索プロトコルで、主にルータやスイッチで使用されているものです。Windows 10ではLLDPもサポートしており、ネットワークアダプタの設定画面では「Microsoft LLDP」という表示でデフォルトで有効になっています。
ただしこちらが有効になっていても、エクスプローラから「ネットワーク」を開いたとき、LLTDの場合と同じくやはりネットワーク上のコンピュータとして表示されず、現時点ではどのように役に立つのか不明です。LLDPに対応したルーターやスイッチとの通信に限定した機能なのかもしれません・・。
WSD
WSD（Web Services On Devices）はMicrosoftが開発し、Windows Vista以降に導入された新しいネットワーク探索の仕組みで、ネットワークプリンターやWebカメラでの導入例が多いものです。こちらを試したところ、エクスプローラの「ネットワーク」で意図通りの表示を行うことができましたので、以下にその手順を記します。
スタートメニューから「Windows管理ツール」を開き、「サービス」を起動します。
エクスプローラから「ネットワーク」を開くと、自身のコンピュータと、あればLAN上にあるコンピュータもリストに表示されていると思います。「探索方法」カラムでWSDと表示されていれば正常です。
まとめ
以上の試行錯誤から、Windows 10などの最新のWindowsでは、ブラウジングに関してはWSD、名前解決に関してはLLMNRを使用したネットワーク探索を有効にし、NBTについては無効にしてしまっても構わないというのが現時点での最適解という結論です。ただし一筋縄ではいかず、そんなのめんどくさいよ！という方も当然いらっしゃると思いますので、そのような方は今まで通りNBTを引き続き利用されるのも一手です。ただし、Microsoftとしては廃止していく方向性と思いますので、いつまで使用できるかは未知数ではあります。
