初めに

「社内用ディストロ」ならばおそらくこの程度で事足りる筈。

• GPLでは一つの組織あるいは会社で複数のコピーを作成して使うことは「配布」とみなさないとしている
• MPLでも同様の見解になっている
  • FAQのQ6を参照
• Ubuntuの知財ポリシーもほぼ同様
  • You can modify Ubuntu for personal or internal use
  • You can make changes to Ubuntu for your own personal use or for your organisation’s own internal use.

組織外に「配布」する場合にはGPLやMPL、Ubuntuの知財ポリシーに従い、少なくとも以下の措置をとるべきである。

• ソースコードを配布できるようにしておく
• 商標の差し替え

要件定義

コンセプト

COVID-19対策で注目されているテレワーク/リモートワークに全振りする

• ベースにしたのはxubuntu 20.04 (作成開始当時、lubuntu20.04が未リリース)
• Network ManagerのVPNプラグイン全部入り
• Remminaの追加プロトコルのプラグインも全部入り
• ブラウザは残す
• それ以外のパッケージは「消せるものは消す」

追加要件(途中で思いついた)

• 社内でディストロのコピーをUSBメモリに焼いて引き渡す時、各々の人でバラバラな「VPNとremminaの接続設定を施した状態」で引き渡せるようにする(未解決)
  • 筆者は「機材と現物がある所に出向かないとどうしようも無い部門」に所属しているが、間接部門の人も通常通り出勤してきている。(おそらく環境未整備？)

手順

1. 仮想マシンor実機に(x)buntuをインストールして、パッケージを差し替える。
   1. この時、外部に配布する予定なら商標の差し替えと、ソースコードがどこに有るか分からないパッケージを含め、再配布に制限のあるパッケージを削除する(snap版パッケージはソースコードを探すのが面倒くさそう・・・)
2. Distroshare Ubuntu ImagerでISOファイル化する

今回は外部配布向けの制作をしなかったが、パッケージのソースコードを取得するには

$echo '#!/bin/bash' >pkg.shebang
$dpkg -l |grep "ii "| sed -e 's/ amd64 //g' |sed -e 's/ all //g'|sed -e 's/ +/ /g' |cut -d " " -f 1-3 |sed -e 's/ /=/g'|sed -e 's/ii=/apt source --download-only /g' >pkg.tmp
$cat pkg.shebang pkg.tmp >> pkg.sh

これで吐き出したpkg.shを実行すれば取得できる筈。
ちなみに、apt source --download-onlyに全てのパッケージを食わせようとしたら

NOTICE: 'accountsservice' packaging is maintained in the 'Git' version control system at:
https://anonscm.debian.org/git/collab-maint/accountsservice.git
Please use:
git clone https://anonscm.debian.org/git/collab-maint/accountsservice.git
to retrieve the latest (possibly unreleased) updates to the package.

のように怒られてしまった。

未解決の課題

• apt等で、パッケージのソースコードの一括取得
• 個々の人毎に違う設定をした状態のISOイメージを作るのを自動化する良い方法が思い浮かばない
• 外部配布の場合、Snapパッケージのソースコードを落としてくるのに手間が掛かりそう(不要なら削除)

反省点

• ネタを思いついたのが遅くて機を逃した
• 要件定義が甘かった
  • そもそも自分専用なら(台数が少なくてそれぞれ用途も違うので)「全てのマシンに共通して入れたい物だけをインストールするメタパッケージ」で事足りた

はじめに

前回の続きです．
とりあえずやりたいことはこんなんです．

今回は「GCP上のApacheからローカルのラズパイApacheにリバースプロキシする」です．
ここでやりたいことは，GCPからVPN接続しているローカルのラズパイにぶん投げさせます．

• [1]GCPとMyDNSを使って，ドメインを取得する
• [2]GCPにSoftether Serverを立てる（iPhoneから接続）
• [3]GCP上のApacheからローカルのラズパイApacheにリバースプロキシする
• [4]ラズパイをルーター化する
• [5]Wake on LAN用のPythonスクリプトを作成する．

GCP側

Apacheインストール

必要なものをインストールします．Line BotはHTTPSに対応していないとダメなので，Certbotもインストールします．

sudo apt update
sudo apt-get install apache2
sudo apt install certbot # For HTTPS

インストールはこれだけです．
※これで，/var/www/htmlが作成され，Webページを入れていけば表示されます（デフォルトページのindex.htmlも入ってます．）．

TCP443,40Portの開放

前々回同様の方法でTCP443,40ポートを開放します．

確認

前々回取得したドメインかグローバルIPアドレスを入力してApacheが動いているか確認します．（このとき，forbittenなんかが出てきたら，たぶんポート開放が正しくできていないです．）
http://yourdomain_or_ip

正しくインストール／ポート開放できていると以下の画面になります．

設定

次にサーバー情報を最小限にするために，以下の設定を行います．

sudo vi /etc/apache2/conf-available/security.conf

/etc/apache2/conf-available/security.conf

ServerTokens Prod
ServerSignature Off

SSL化

証明書発行

certbotを使って，SSLの証明書を発行します．--dry-run引数はちょっと試してみるなコマンドです．いきなり--dry-runなしでやってもいいですが，念のためにやっておいた方がいいです．

$ sudo certbot certonly --webroot -w /var/www/html -d {domain} --email {mail address} --agree-tos -n --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for {domain}
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - The dry run was successful.

と成功したら，本番です．

sudo certbot certonly --webroot -w /var/www/html -d {domain} --email {mail address} --agree-tos -n

エラーなく成功したら，

sudo ls /etc/letsencrypt/live/{domain}/
# >> README  cert.pem  chain.pem  fullchain.pem  privkey.pem # -> OK

で証明書ができているか確認します．

証明書を有効化

証明書を有効化して，WebページをSSL化します．

cd /etc/apache2/sites-available/
sudo cp default-ssl.conf default-ssl.conf.bak # 念のため，バックアップ
sudo vi default-ssl.conf

メールアドレスや先ほど作成した証明書のパスを設定します．

/etc/apache2/sites-available/default-ssl.conf

# 3行目くらい
ServerAdimin {mail address(above address)}
# 25行目くらい
SSLEngine on
# 32, 33行目くらい
SSLCertificateFile /etc/letsencrypt/live/{domai}/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/{domai}/privkey.pem
# 42行目くらい
SSLCertificateChainFile /etc/letsencrypt/live/{domai}/chain.pem

Softether serverの443ポートを閉じる

前回でやっているかもしれませんが，一応．

サービスやシステムを有効化する

先ほど編集したSSLの設定や，Apacheのサーバーを再度設定しなおします．

sudo service apache2 start 
sudo systemctl reload apache2
sudo a2ensite default-ssl
sudo a2enmod ssl 
sudo apachectl -t # >> Syntax OK
sudo systemctl restart apache2
sudo reboot

これで，https://yourdomain_or_ip
（hhtp*s*に注意）を開いて，以下のようになっていればSSL化はできています．

certbotの更新

このままでは，時間が経つと（期間は忘れました．調べてください）証明書が無効になってしまうので，定期的に更新させます．
まずは，更新がうまくいくかを--dry-runで確認します．

$ sudo certbot renew --dry-run
- - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/{domain}/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

とか出ればOK．
毎月ごとに更新するように，crontabで設定します．

sudo crontab -e # or crontab -u root -e

# renew ssl certification
0 0 1 * * certbot renew

80ポートを閉じる　or リダイレクト

SSL化が完了し，80ポートは不要なので，どちらかを選びます．
ポートを閉じるのは割愛し，リダイレクトの方法を書きます．

/etc/apache2/sites-available/hogehoge.confファイルがあるので，（たぶん000-default.confファイル）以下を書き込みます．正規表現でhttpsを強制的につけるように設定させています．

sudo vi /etc/apache2/sites-available/hogehoge.conf 

/etc/apache2/sites-available/hogehoge.conf

<VirtualHost *:80>
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
        ...

編集後，リロードします．

sudo a2enmod rewrite
sudo systemctl restart apache2

ラズパイ側

インストール設定等は基本同じなので，割愛します．ただし，SSL化は不必要なので，certbotは要りません！

インストールが終わり，Apacheを起動し，確認まで行います．
※確認の際はポート開放等していないので，ラズパイのローカルIPで確認してください．(例：http://192.168.5.111など)

テストのため，/var/www/html/index.htmlをわかりやすいように変更します．

/var/www/html/index.html

This is vpn server for wake on lan!

リバースプロキシでぶん投げる

GCP→ラズパイにぶん投げます．
まず，リバースプロキシのために，もろもろ設定します．

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests
sudo systemctl restart apache2

そうして，先ほど編集したファイルに以下を記入します．

sudo vi /etc/apache2/sites-available/default-ssl.conf

/etc/apache2/sites-available/default-ssl.conf

ProxyPreserveHost On
ProxyPass / http://{raspi's local IP}:80/
ProxyPassReverse / http://{raspi's local IP}:80/

再起動します．

sudo systemctl restart apache2

確認します．https://{domain}
で以下のベージになっていればOKです．

おわりに

とりあえず，長いのでここで終了です．

はじめに

前回の続きです．
とりあえずやりたいことはこんなんです．

今回は「GCP上のApacheからローカルのラズパイApacheにリバースプロキシする」です．
ここでやりたいことは，GCPからVPN接続しているローカルのラズパイにぶん投げさせます．

• [1]GCPとMyDNSを使って，ドメインを取得する
• [2]GCPにSoftether Serverを立てる（iPhone／ラズパイから接続）
• [3]GCP上のApacheからローカルのラズパイApacheにリバースプロキシする
• [4]ラズパイをルーター化する
• [5]Wake on LAN用のPythonスクリプトを作成する．

GCP側

Apacheインストール

必要なものをインストールします．Line BotはHTTPSに対応していないとダメなので，Certbotもインストールします．

sudo apt update
sudo apt-get install apache2
sudo apt install certbot # For HTTPS

インストールはこれだけです．
※これで，/var/www/htmlが作成され，Webページを入れていけば表示されます（デフォルトページのindex.htmlも入ってます．）．

TCP443,40Portの開放

前々回同様の方法でTCP443,40ポートを開放します．

確認

前々回取得したドメインかグローバルIPアドレスを入力してApacheが動いているか確認します．（このとき，forbittenなんかが出てきたら，たぶんポート開放が正しくできていないです．）
http://yourdomain_or_ip

正しくインストール／ポート開放できていると以下の画面になります．

設定

次にサーバー情報を最小限にするために，以下の設定を行います．

sudo vi /etc/apache2/conf-available/security.conf

/etc/apache2/conf-available/security.conf

ServerTokens Prod
ServerSignature Off

SSL化

証明書発行

certbotを使って，SSLの証明書を発行します．--dry-run引数はちょっと試してみるなコマンドです．いきなり--dry-runなしでやってもいいですが，念のためにやっておいた方がいいです．

$ sudo certbot certonly --webroot -w /var/www/html -d {domain} --email {mail address} --agree-tos -n --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for {domain}
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - The dry run was successful.

と成功したら，本番です．

sudo certbot certonly --webroot -w /var/www/html -d {domain} --email {mail address} --agree-tos -n

エラーなく成功したら，

sudo ls /etc/letsencrypt/live/{domain}/
# >> README  cert.pem  chain.pem  fullchain.pem  privkey.pem # -> OK

で証明書ができているか確認します．

証明書を有効化

証明書を有効化して，WebページをSSL化します．

cd /etc/apache2/sites-available/
sudo cp default-ssl.conf default-ssl.conf.bak # 念のため，バックアップ
sudo vi default-ssl.conf

メールアドレスや先ほど作成した証明書のパスを設定します．

/etc/apache2/sites-available/default-ssl.conf

# 3行目くらい
ServerAdimin {mail address(above address)}
# 25行目くらい
SSLEngine on
# 32, 33行目くらい
SSLCertificateFile /etc/letsencrypt/live/{domai}/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/{domai}/privkey.pem
# 42行目くらい
SSLCertificateChainFile /etc/letsencrypt/live/{domai}/chain.pem

Softether serverの443ポートを閉じる

前回でやっているかもしれませんが，一応．

サービスやシステムを有効化する

先ほど編集したSSLの設定や，Apacheのサーバーを再度設定しなおします．

sudo service apache2 start 
sudo systemctl reload apache2
sudo a2ensite default-ssl
sudo a2enmod ssl 
sudo apachectl -t # >> Syntax OK
sudo systemctl restart apache2
sudo reboot

これで，https://yourdomain_or_ip
（hhtp*s*に注意）を開いて，以下のようになっていればSSL化はできています．

certbotの更新

このままでは，時間が経つと（期間は忘れました．調べてください）証明書が無効になってしまうので，定期的に更新させます．
まずは，更新がうまくいくかを--dry-runで確認します．

$ sudo certbot renew --dry-run
- - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/{domain}/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

とか出ればOK．
毎月ごとに更新するように，crontabで設定します．

sudo crontab -e # or crontab -u root -e

# renew ssl certification
0 0 1 * * certbot renew

80ポートを閉じる　or リダイレクト

SSL化が完了し，80ポートは不要なので，どちらかを選びます．
ポートを閉じるのは割愛し，リダイレクトの方法を書きます．

/etc/apache2/sites-available/hogehoge.confファイルがあるので，（たぶん000-default.confファイル）以下を書き込みます．正規表現でhttpsを強制的につけるように設定させています．

sudo vi /etc/apache2/sites-available/hogehoge.conf 

/etc/apache2/sites-available/hogehoge.conf

<VirtualHost *:80>
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
        ...

編集後，リロードします．

sudo a2enmod rewrite
sudo systemctl restart apache2

ラズパイ側

インストール設定等は基本同じなので，割愛します．ただし，SSL化は不必要なので，certbotは要りません！

インストールが終わり，Apacheを起動し，確認まで行います．
※確認の際はポート開放等していないので，ラズパイのローカルIPで確認してください．(例：http://192.168.5.111など)

テストのため，/var/www/html/index.htmlをわかりやすいように変更します．

/var/www/html/index.html

This is vpn server for wake on lan!

リバースプロキシでぶん投げる

GCP→ラズパイにぶん投げます．
GCPにSSHで接続します．まず，リバースプロキシのために，もろもろ設定します．

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests
sudo systemctl restart apache2

そうして，先ほど編集したファイルに以下を記入します．

sudo vi /etc/apache2/sites-available/default-ssl.conf

/etc/apache2/sites-available/default-ssl.conf

ProxyPreserveHost On
ProxyPass / http://{raspi's local IP}:80/
ProxyPassReverse / http://{raspi's local IP}:80/

再起動します．

sudo systemctl restart apache2

確認します．https://{domain}
で以下のベージになっていればOKです．

おわりに

とりあえず，長いのでここで終了です．

https://www.kernel.org/doc/html/latest/watchdog/watchdog-api.html

---

Docs » Linux Watchdog Support » The Linux Watchdog driver API

The Linux Watchdog driver API

Last reviewed: 10/05/2007

Copyright 2002 Christer Weingel wingel@nano-system.com

Some parts of this document are copied verbatim from the sbc60xxwdt driver which is (c) Copyright 2000 Jakob Oestergaard ＜jakob＠ostenfeld.dk＞

このドキュメントの一部は、(c) Copyright 2000 Jakob Oestergaard ＜jakob＠ostenfeld.dk＞の、sbc60xx wdt driverからそのままコピーしました。

This document describes the state of the Linux 2.4.18 kernel.

このドキュメントは、Linux 2.4.18 kernelの状態で記述されています。

Introduction

A Watchdog Timer (WDT) is a hardware circuit that can reset the computer system in case of a software fault. You probably knew that already.

Watchdog Timer (WDT)は、ソフトウェアトラブルが発生したケースでコンピュータシステムをリセットできるハードウェア回路です。このことは既に知っているかもしれません。

Usually a userspace daemon will notify the kernel watchdog driver via the /dev/watchdog special device file that userspace is still alive, at regular intervals. When such a notification occurs, the driver will usually tell the hardware watchdog that everything is in order, and that the watchdog should wait for yet another little while to reset the system. If userspace fails (RAM error, kernel bug, whatever), the notifications cease to occur, and the hardware watchdog will reset the system (causing a reboot) after the timeout occurs.

通常、ユーザー空間のdaemonは、ユーザー空間で生きている/dev/watchdog special device fileを介して、カーネルのwachdog driverにまだ生存していることを定期的に通知します。そのような通知が発生したら、driverは通常hardware watchdogへすべてが正常であることを通知し、watchdogはまだもう少しシステムをリセットするのを待つ必要があることを通知します。もし、ユーザー空間で問題（RAMのトラブル、カーネルのバグ、その他）があった場合、通史は発生しなくなり、hardware watchdogは、タイムアウトが発生した後、システムをリセットします（つまり再起動が発生します）。

The Linux watchdog API is a rather ad-hoc construction and different drivers implement different, and sometimes incompatible, parts of it. This file is an attempt to document the existing usage and allow future driver writers to use it as a reference.

Linux watchdog API はその場しのぎの構造です。異なるドライバーが異なる実装をし、互換性がなく、その一部を実装しています。このファイルでは、既存の使用方法をドキュメント化し、従来のドライバー作成者が参照できるようにする試みです。

The simplest API

All drivers support the basic mode of operation, where the watchdog activates as soon as /dev/watchdog is opened and will reboot unless the watchdog is pinged within a certain time, this time is called the timeout or margin. The simplest way to ping the watchdog is to write some data to the device. So a very simple watchdog daemon would look like this source file: see samples/watchdog/watchdog-simple.c

全てのドライバーは、処理に関する基本的なモードをサポートしています。watchdogは、/dev/watchdogが開かれると速やかに有効化されます。そして、watchdogへの一定時間の通知が亡くなったらリブートをします。この時間を、timeoutあるいはmarginと呼びます。もっとも単純な、watchdogへpingする方法は、deviceに何らかのデータを書き込む事です。したがって、非常に単純なwatchdog daemonは、次のソースファイルのようになります。 samples/watchdog/watchdog-simple.c を参照してください。、

A more advanced driver could for example check that a HTTP server is still responding before doing the write call to ping the watchdog.

より高度なドライバは、たとえば、ウォッチドッグにpingするための書き込み呼び出しを行う前に、HTTPサーバーがまだ応答していることを確認できます。

When the device is closed, the watchdog is disabled, unless the “Magic Close” feature is supported (see below). This is not always such a good idea, since if there is a bug in the watchdog daemon and it crashes the system will not reboot. Because of this, some of the drivers support the configuration option “Disable watchdog shutdown on close”, CONFIG_WATCHDOG_NOWAYOUT. If it is set to Y when compiling the kernel, there is no way of disabling the watchdog once it has been started. So, if the watchdog daemon crashes, the system will reboot after the timeout has passed. Watchdog devices also usually support the nowayout module parameter so that this option can be controlled at runtime.

デバイスがクローズされたとき、watchdogは無効化されます、"Magic Close"機能がサポートされていない場合には（下記を参照してください）。これは、常に良い考えではありません。もし、watchdog daemonにバグがあり、それがクラッシュしたとき、systemはrebootできないでしょう。そのため、ドライバーの中には、"Diasable watchdog shutdown on close", CONFIG_WATCHDOG_NOWAYOUTの設定オプションをサポートするものがあります。もしカーネルをコンパイルする際に、これがYに設定されている場合、watchdogが一度開始したら止める手段はありません。そのため、watchdog daemonがクラッシュしたら、systemはtimeoutが経過した後にリブートされます。Watchdog devicesはまた通常、実行時にこのオプションを制御するためのnowayout module parameterをサポートしています。

Magic Close feature

If a driver supports “Magic Close”, the driver will not disable the watchdog unless a specific magic character ‘V’ has been sent to /dev/watchdog just before closing the file. If the userspace daemon closes the file without sending this special character, the driver will assume that the daemon (and userspace in general) died, and will stop pinging the watchdog without disabling it first. This will then cause a reboot if the watchdog is not re-opened in sufficient time.

”Magic Close"をドライバーがサポートしている場合、driverはwatchdogspecific magic character "V"が/dev/watchdogに、ファイルをクローズする前に送信することなく無効化することはできません。ユーザー空間daemonは、特殊な文字列を送信することなく、ファイルをクローズすると、ドライバーはdaemon（そして、一般的にはユーザー空間）が死亡し、それを始めて停止する事なく、watchdogへの通知が停止したとみなします。watchdogが十分な時間内に再度開かれない場合、これにより再起動が発生します。

The ioctl API

All conforming drivers also support an ioctl API.

準拠する全てのドライバは、ioctl APIもまたサポートします。

Pinging the watchdog using an ioctl:

ioctlを用いたwatchdogへの通知。

All drivers that have an ioctl interface support at least one ioctl, KEEPALIVE. This ioctl does exactly the same thing as a write to the watchdog device, so the main loop in the above program could be replaced with:

ioctl interface を有するドライバーは、少なくともKEEPALIVEのインターフェイスをサポートします。このioctlは、watchdog deviceへの書き込みと同じことです、そのため、前期プログラムでのmain loopは以下のように書き直せます。

while (1) {
        ioctl(fd, WDIOC_KEEPALIVE, 0);
        sleep(10);
}

the argument to the ioctl is ignored.

ioctlの引数は無効です。

Setting and getting the timeout

For some drivers it is possible to modify the watchdog timeout on the fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT flag set in their option field. The argument is an integer representing the timeout in seconds. The driver returns the real timeout used in the same variable, and this timeout might differ from the requested one due to limitation of the hardware:

ドライバーの中には、watchdog timeoutをSETTIMEOUT ioctlによって実行中に変更する事ができる者もあります。これらのドライバは、option fieldに、WDIOF_SETTIMEOUT flagが設定されています引数は整数型で、timeoutの秒数を示します。ドライバーは同じ変数を使った実際のタイムアウトを返却します。このtimeoutは、ハードウェアの制限により、要求されたものと異なる場合がありまsう。

int timeout = 45;
ioctl(fd, WDIOC_SETTIMEOUT, &timeout);
printf("The timeout was set to %d seconds\n", timeout);

This example might actually print “The timeout was set to 60 seconds” if the device has a granularity of minutes for its timeout.

この例では、デバイスのタイムアウトが分単位の粒度であるならば、実際の出力が、“The timeout was set to 60 seconds”となります。

Starting with the Linux 2.4.18 kernel, it is possible to query the current timeout using the GETTIMEOUT ioctl:

Linux 2.4.18 kernelから、GETTIMEOUT ioctlによって現在のtimeoutを要求する事もできます。

ioctl(fd, WDIOC_GETTIMEOUT, &timeout);
printf("The timeout was is %d seconds\n", timeout);

Pretimeouts

Some watchdog timers can be set to have a trigger go off before the actual time they will reset the system. This can be done with an NMI, interrupt, or other mechanism. This allows Linux to record useful information (like panic information and kernel coredumps) before it resets:

Watcjdog timerの中には、システムを再起動する実際の時刻の前にトリガーを設定できるものがあります。これは、NMI、割り込みあるいはほかのメカニズムを利用できます。これにより、Linuxが有益な情報（例えば、panic informationやkernel coredumps)を、再起動する前に残すことができます。

pretimeout = 10;
ioctl(fd, WDIOC_SETPRETIMEOUT, &pretimeout);

Note that the pretimeout is the number of seconds before the time when the timeout will go off. It is not the number of seconds until the pretimeout. So, for instance, if you set the timeout to 60 seconds and the pretimeout to 10 seconds, the pretimeout will go off in 50 seconds. Setting a pretimeout to zero disables it.

pretimeoutは、timeoutが発動する前の秒単位の時間であることに注意してください。これは、pretimeoutまでの字亜kんではありません。そのため、例えば、timeoutを60秒に、pretimeoutを10秒にセットしたら、pretimeoutは50秒の段階で発動します。pretimeoutを0に設定する事で無効化できます。

There is also a get function for getting the pretimeout:

pretimeoutを取得する関数もまたあります。

ioctl(fd, WDIOC_GETPRETIMEOUT, &timeout);
printf("The pretimeout was is %d seconds\n", timeout);

Not all watchdog drivers will support a pretimeout.

Watchdog driverの全てが、pretimeoutをサポートしているわけではありません。

Get the number of seconds before reboot

Some watchdog drivers have the ability to report the remaining time before the system will reboot. The WDIOC_GETTIMELEFT is the ioctl that returns the number of seconds before reboot:

Watchdog driverの中には、systemが再起動する前の残り時間を通知する機能を有したものもあります。WDIOC_GETTIMELEFTは、再起動前の秒数を返却するioctlです。

ioctl(fd, WDIOC_GETTIMELEFT, &timeleft);
printf("The timeout was is %d seconds\n", timeleft);

Environmental monitoring

All watchdog drivers are required return more information about the system, some do temperature, fan and power level monitoring, some can tell you the reason for the last reboot of the system. The GETSUPPORT ioctl is available to ask what the device can do:

全てのwatchdog driverは、システムに関する多くの詳細情報を返却する必要があります。温度、ファン、電源レベルのモニターをするものもあります。最後にシステムをリブートした要因として通知するものもあります。GETSUPPORT ioctlは、デバイスが何ができるのを問い合わせることができます。

struct watchdog_info ident;
ioctl(fd, WDIOC_GETSUPPORT, &ident);

the fields returned in the ident struct are:

ident 構造体のfieldにはは以下の通りです。

identity a string identifying the watchdog driver
firmware_version the firmware version of the card if available
options a flags describing what the device supports

identity watchdog driverの識別子文字列
firmware_version 有効ならばcardのファームバージョン
options デバイスがサポートしているフラグ記述子。

the options field can have the following bits set, and describes what kind of information that the GET_STATUS and GET_BOOT_STATUS ioctls can return. [FIXME – Is this correct?]

option fieldには、下記のビットを競ってすることができ、GET_STATUSやGET_BOOT_STATUS ioctlにおって情報を返すことができます[FIXME - これは本当？]

WDIOF_OVERHEAT Reset due to CPU overheat
The machine was last rebooted by the watchdog because the thermal limit was exceeded:

WDIOF_OVERHEAT CPUのオーバーヒートで再起動する
このマシンは、温度限界に達したため、watchdogによって最後の再起動が行われました。

WDIOF_FANFAULT Fan failed
A system fan monitored by the watchdog card has failed

WDIOF_FANFAULT Fan failed
このシステムは、watchdog cardによって監視されているfanが故障しました。

WDIOF_EXTERN1 External relay 1
External monitoring relay/source 1 was triggered. Controllers intended for real world applications include external monitoring pins that will trigger a reset.

WDIOF_EXTERN1 外部要因１
外部監視要因/ソース１のトリガーが発生しました。現実世界のアプリケーションのためのコントローラーには、リセットをトリガーするためのpinが含まれます。

WDIOF_EXTERN2 External relay 2
External monitoring relay/source 2 was triggered

WDIOF_EXTERN2 External relay 2
外部監視要因/ソース１のトリガーが発生しました。

WDIOF_POWERUNDER Power bad/power fault
The machine is showing an undervoltage status

WDIOF_POWERUNDER 電源不正/電源故障
このマシンでは、低電圧状態が見られました。

WDIOF_CARDRESET Card previously reset the CPU
The last reboot was caused by the watchdog card

WDIOF_CARDRESET Card previously reset the CPU
watchdog cardによって最終リブートが引き起こされました。

WDIOF_POWEROVER Power over voltage
The machine is showing an overvoltage status. Note that if one level is under and one over both bits will be set - this may seem odd but makes sense.

WDIOF_POWEROVER 過電流電源

このマシンでは、過電流状態を検知しました。1つのレベルが下になり、1つのレベルが両方のビットに設定される場合、これは奇妙に見えるかもしれませんが、理にかなっていることに注意してください。

WDIOF_KEEPALIVEPING Keep alive ping reply
The watchdog saw a keepalive ping since it was last queried.

WDIOF_KEEPALIVEPING Keep alive ping reply
watchdogは最後の要求から、keepalive 通知を検知しました。

WDIOF_SETTIMEOUT Can set/get the timeout
The watchdog can do pretimeouts.

WDIOF_SETTIMEOUT Can set/get the timeout
Watchdogは、pretimeoutを実行できます。

WDIOF_PRETIMEOUT Pretimeout (in seconds), get/set
For those drivers that return any bits set in the option field, the GETSTATUS and GETBOOTSTATUS ioctls can be used to ask for the current status, and the status at the last reboot, respectively:

WDIOF_PRETIMEOUT Pretimeout (in seconds), get/set
option fieldにセットされたbitを返却するドライバでは、現在の状態や最後に再起動した時点での状態を確認するのに、GETSTATUSやGETBOOTSTATUS ioctlを利用できます。以下のように…

int flags;
ioctl(fd, WDIOC_GETSTATUS, &flags);

or

ioctl(fd, WDIOC_GETBOOTSTATUS, &flags);

Note that not all devices support these two calls, and some only support the GETBOOTSTATUS call.

全てのドライバがこれら２つの呼び出しをサポートしているわけではなく、GETBOOTSTATUS callだけをサポートしているものもあることに注意してください。

Some drivers can measure the temperature using the GETTEMP ioctl. The returned value is the temperature in degrees fahrenheit:

ドライバーの中には、GETTEMP icotlを用いて気温を計測できるものもあります。戻り値は、fahrenheit度の気温です。

int temperature;
ioctl(fd, WDIOC_GETTEMP, &temperature);

Finally the SETOPTIONS ioctl can be used to control some aspects of the cards operation:

最期に、SETOPTION ioctlはいくつかのcard operationの側面に対して、指示を出すことができます。

int options = 0;
ioctl(fd, WDIOC_SETOPTIONS, &options);

The following options are available:

下記オプションが有効です。

WDIOS_DISABLECARD Turn off the watchdog timer
WDIOS_ENABLECARD Turn on the watchdog timer
WDIOS_TEMPPANIC Kernel panic on temperature trip

WDIOS_DISABLECARD ウォッチドックタイマーを停止
WDIOS_ENABLECARD ウィッチドックタイマーを起動
WDIOS_TEMPPANIC 温度要因でkernel panicを発生

[FIXME – better explanations]

---

もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。

https://www.kernel.org/doc/html/latest/index.html

Licensing documentation

The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.

https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing

LPICの試験や実際の仕事でLINUXについて知りたい、知る必要があるというという方はいると思います。
でもいざ調べても「コマンドや単語とか調べてみたけど、結局複雑でわかんないぞ？」となる人もいるのではないでしょうか（私はなりました）。
これはそんな方に向けて、手軽にLINUXの仕組みを知るための記事です！

LINUXの仕組みについて知るためには、ズバリLINUXの起動プロセスについて理解を深めることが効果的だと考えられます。なぜかというと、起動プロセスで関係するシステムはすなわちLINUXを動かしているシステムであり、LINUXを動かしてるということはLINUXの全てということになります。
例えば車の仕組みを知るために車のキーを回してエンジンがどのように起動されるか知ることで、車の動く仕組みについて理解が深まるみたいに、
LINUXのエンジンについて知ることで、LINUXのできることがわかることができるでしょう！

LINUXの位置づけ

まず数あるOSの中でのLINUXの位置づけについて触れますと、LINUXはUNIX系OSと呼ばれる種類のOSになります。LINUXのバージョンはディストリビュートと呼ばれるかたちで分岐しているのですが、このLINUXのカーネル(OSの元になるもの)がオープンソースとして広く公開されて、いろいろな人によってOSの開発がされました。その結果、Debian系とかUbuntu系とか、ファッション系統みたいのようにいろいろな分岐が生まれました。（この系統を
ざっくり分けると無料版と有料版の二つにわけられて、無課金だとCentOS、有料版だとRedHatが有名です)

Linuxの起動プロセス

まずは電源ボタンをつけてからコマンド入力ができるようになるまでの、Linuxの起動プロセスの流れが次の表です。

1. 電源投入
2. ファームウェアの起動
3. ファームウェアがブートローダを読み込む
4. ブートローダがカーネルとファイルシステムイメージ(initramfs)を読み込む
5. ブートローダがカーネルを実行
6. カーネルがファイルシステムイメージ(initramfs)を実行
7. カーネルがinit(またはsystemd)を起動、ルートファイルシステムをマウント
8. カーネルがinit(またはsystemd)を実行

１. 電源投入

電源を入れると端末に刻みこまれたファームウェアが立ち上がってきます。
有名なファームウェアだとBIOS(BootInput/OutputSystem)とUEFI(UnifiedExtendableFarmwareInterface)があり、各ファームウェアによって扱うブートローダの種類が変わってきます。

2. ブートローダの起動

ファームウェアはまずハードディスクの先頭に収められているブートローダを読み込んで、LINUXを立ち上げる準備を始めます。
この時にBIOSだとイメージファイルを生成して展開して、UEFIだと格納されてるEFIファイルを読み込んで起動します。
この時に起動されるのがGRUB2(GRandUnifiedBootloader)と呼ばれるものです。(2とついてるのは、二世代目だからです)

3. カーネルとルートファイルシステムの起動

ブートローダはLINUXのカーネル(vmlinuz)とファイルシステムイメージ(initramfs)を読み込みます。vmlinuzって変わった名前ですけど、頭文字はVirtualMachineのVMで、末尾がzなのは圧縮ファイルとのことでlinuxのxをzに変えたものらしいです。
ブートローダからカーネルの実行とファイルシステムイメージの展開が完了すると、ルートファイルシステムが使用可能になったとみて、
カーネルはユーザープロセスを起動します。

4. ユーザープロセスの起動

諸々の準備が終わったらカーネルは最後にユーザー自身のプロセス(intiまたはsystemd)を呼び出します。この時にランレベルまたはTargetに合わせた起動モードでLinuxを立ち上げます。
立ち上げ終わったら再度にユーザーの元に制御が戻って、Linuxを操作することができます。

細かい語句の説明

ファームウェア：ハード側からLinuxを立ち上げるシステム
ブートローダ：Linuxをたたき起こすやつ
カーネル：Linuxの種
initramfs：ファイルシステムの頂点、トップオブファイルシステム
ユーザープロセス：initとかsystemdで、ユーザーの操作自体
ランレベル：GUIかCGIか緊急モードかがレベル別で分けられてます

関連するファイル

Linuxの起動に関係するブートローダやカーネルの設定値は特定の場所に配置されてます。

◇ブートローダ(GRUB2:GRandUnifiedBootloader2)

　本体ファイル
　　BIOS(Basic input/output system)の時はboot.imgとcore.img(※画像ファイルではない)
　　※起動時に生成されます
　　UEFI(Unified Extended Firmware Interface)の時は
　　/boot/efi/EFI/(端末のバージョン名:例centos等)/配下に
　　shim.efiとgrubx64.efiが格納されてます
　設定ファイル
　　/boot/grub/grub.cfg(※confではない)
　カーネルパラメータ
　　/proc/cmdline
　カーネルの出力するログ
　　/var/log/dmesg
　ランレベルの設定ファイル
　　/etc/inittab(initの時)
　　/etc/systemd/system/defalut.target(systemdの時)

InitとSystemdの違い

詳しくはこちらのサイトが参考になるのですが、大まかにいうとinitを成長させた上位互換のシステムがsystemdです。便利になって、責任感が増してます！
具体的な機能で言うと、init時代は単発でバラバラに管理されていたプロセスがユニット単位で管理されるようになります。
このプロセスがユニット単位で管理されるようになることで、各サービスを安定的に運用できるようになったのです。(起動や停止がしやすくなる)

参考

以下の本を参考に書いてます。プラスアルファで細かに見たい場合は手に取って辞書的な使い方をしてみてもいいと思います☺

・Linux教科書 LPIC レベル1 スピードマスター問題集 Version5.0対応

はじめに

Linuxのコマンドは、１つ１つはできるだけ小さく、シンプルな動作をするように設計されています。これは単純にした方がわかりやすく使いやすいためです。
Linuxで様々な処理を行う場合、これらの小さなコマンドを連携させる仕組みが必要です。今回紹介する「リダイレクト」と「パイプライン」は、コマンドを連携させるための仕組みです。

標準入力・標準出力・標準エラー出力

まずはコマンド間で情報をやりとりする仕組みを理解する必要があります。そのため、まずは標準入出力という言葉について紹介します。

Limuxでは、catなどのコマンドが実行されると、自動的に標準的な入出力チャネルが開かれます。ここではチャネルを「データの流れる道」という意味に捉えておいてください。

標準的な入出力チャネルとは、具体的には次の３つです。

標準的な入出力チャネル	内容
標準入力(stdin)	プログラムの標準的な入力です。通常はキーボードが使用されます
標準出力(stdout)	プログラムの標準的な出力です。通常は端末ディスプレイが使用されます
標準エラー出力(stderr)	プログラムのエラーメッセージを出力するための標準的な出力です。通常は端末ディスプレイが使用されます

この３つを合わせて標準入出力と呼びます。

各コマンドは「キーボードから入力されている」とかディスプレイに出力する」とは考えていません。シンプルに「標準入力から入力し、標準出力に出力する」だけです。

標準入力は通常はキーボードに割り当てられていますが、ファイルでも構いません。また、標準出力も同様に、通常はディスプレイですが、ファイルでもプリンターでも構いません。

標準入出力を実際にどこへ繋ぐかは、ユーザが自由に設定できます。このようにLinuxでは、コマンドの入出力先を「標準入出力」という形で抽象化しているため、コマンド内部の動作を変更せずに標準入出力先を柔軟に変更することができます。

リダイレクト

標準入出力先を変更する機能のことを、リダイレクトと呼びます。
ここで、引数を指定しないcatコマンドを考えてみましょう。

catコマンド

$ cat  #引数を指定せずcatコマンドを実行
Hello  #キーボードからHelloと入力  
Hello  #Helloと表示された
       #Ctrl+dを入力
$      #プロンプトが表示

catコマンドは、標準入力の内容を入力として読みこんで、それを標準出力にそのまま出力するという動きをするコマンドであるため、このような動作をします。
標準入力は通常キーボードなので、上記はキーボードの入力がそのまま表示されました。

次は、キーボードの代わりに、ファイルを標準入力に繋いでみます。これを入力リダイレクトと呼びます。入力リダイレクトは<を使います。動作の流れは、標準入力のつながっている先をファイルに変更したことにより、ファイルの内容がそのまま標準入力としてcatコマンドに渡されて、catコマンドはこれをそのまま標準出力に出力する、というものです。結果として、標準入力に繋いだファイルの内容が表示されます。

入力リダイレクトとファイル指定

catコマンドはコマンドライン引数にファイルを指定するとそのファイルの内容を表示するため、入力リダイレクトで書いてもファイル指定で書いても同じ動作となります。

catコマンド

$ cat < /etc/crontab #入力リダイレクト
$ cat /etc/crontab   #ファイル指定

しかし、この2つは結果こそ同じですが、コマンドの動きは以下のように異なります。

記法	内容
入力リダイレクト <	標準入力をそのまま標準出力に表示する
ファイル指定 /xxx	ファイル名が指定された場合には、その内容を対象にするというcatコマンドの機能を使用している

今後、Linuxでなにかしらのコマンドを作成する際は、ファイルを指定するのではなく、標準入力から受け取る仕組みでプログラムを書く方が、汎用性が高くおすすめです。

標準出力のリダイレクト

標準出力もリダイレクト機能により変更できます。頻繁に使われるのは、コマンドの実行結果をファイルに保存するです。標準出力をリダイレクトするには>を使用します。次の例ではlsコマンドの実行結果をlist.txtファイルに出力しています。

なお、リダイレクト先のファイルは自動で作成されるので、touchコマンドなどでファイルを作成しておく必要はありません。

標準エラー出力

標準エラー出力は、主にプログラムのエラーメッセージを出力するために使用されます。lsコマンドで存在しないファイルを指定した場合は以下のように表示されます。

通常、標準エラー出力は標準出力と同様に、端末ディスプレイに繋がっています。そのため、このままでは、表示されているメッセージが、標準出力のものなのか、標準エラー出力のものかを区別することができません。

しかし、標準出力をファイルにリダイレクトして、画面に表示させないようにするとその違いがはっきりします。
以下に、標準出力をlist.txtにリダイレクトしているものの、指定したファイルが存在しない場合を示します。

list.txtにリダイレクトしているため、画面には何も表示されないように思いますが、実際には画面にエラーメッセージが表示されいます。これは、標準出力と標準エラー出力が別々のチャネルになっているためです。

この仕組みのために、標準出力をファイルにリダイレクトした場合でもエラーを見逃さずにすみます。

なお、標準エラー出力もファイルにリダイレクトすることができます。標準出力のリダイレクトと区別するために、2>という記号を使います。

標準エラー出力のリダイレクト

$ ls /xxxx 2> error.txt

このように、コマンドの結果をエラーメッセージは分けておくと何かと便利なため、標準出力とは別に標準エラー出力が用意されているのです。
また、次のようにリダイレクトを同時に指定することで、標準出力と標準エラー出力をそれぞれ別のファイルにリダイレクトすることもできます。

リダイレクト先を別ファイルに指定

$ ls /xxxx > list.txt 2> error.txt #この場合画面には何も表示されない

標準出力と標準エラー出力をまとめる

標準出力と標準エラー出力の両方を、１つのファイルにまとめてリダイレクトしたい場合には、次のように、標準出力をリダイレクトした後ろに、2>&1と記述するとうまくいきます。

１つのファイルにまとめてリダイレクト

$ ls /xxxx >result.txt 2>&1

標準入出力には数値が設定されており、これを指定することで、リダイレクト指定することができます。標準入出力の数値は以下の通りです。

入出力チャネル	数値
標準入力	0
標準出力	1
標準エラー出力	2

リダイレクトによる上書き

>で標準出力をリダイレクトする際に、指定したファイル名と同一のファイルが存在する場合は上書きされて、下のファイルが失われてしまいます。これを防ぐには>の代わりに、>>と記述することです。これによって、上書きではなく、ファイルの末尾に追記する形で、リダイレクトすることができます。

新規ファイルに>>を使用しても問題ありませんので、基本的に>>を使用するのがいいかと思います。

また、上書きを防止する別の方法として、シェルのオプションでnoclobberという値をsetコマンドで設定すると、リダイレクトで上書きしてしまう際には、エラーとなるようbashの動作を変更することができます。

## リダイレクトについての記号まとめ

記号	内容
<file	標準入力をfileに変更する
>file	標準出力をfileに変更する
>>file	標準出力の出力をfileの末尾に追記する
2>file	標準エラー出力をfileに変更する
2>>file	標準エラー出力をfileの末尾に追記する
>file 2>&1	標準出力と標準エラー出力を、共にfileに変更する

/dev/null

Linuxではリダイレクト先として、/dev/nullファイルがよく使用されるので、紹介します。/dev/nullファイルはスペシャルファイルと呼ばれる特別なファイルで、次のような性質を持っています。

• 入力先として指定しても、何も内容を返さない
• 出力先として指定しても、書き込んだデータはどこにも保存されずに消えて無くなる

例えば次のように、標準入力をdev/nullにリダイレクトすると何も入力がない状態になります。

これはコマンドのテストなど、何かしらの理由で、入力を空っぽにしたい場合に使用されます。

一方、標準出力を/dev/nullにリダイレクトすると、本来はコマンドの実行結果が画面に表示されるが、何も表示されなくなります。この際は、標準エラー出力へのエラーメッセージだけが画面に表示されます。

また、標準エラー出力を/dev/nullへリダイレクトする場合には2> /dev/nullを指定することで実現できます。あまりにもエラーが多いときや、すでにわかっているエラーを非表示にするときなどに使用します。

さらに、次のように標準出力と標準エラー出力を両方とも/dev/nullにリダイレクトすることで画面には何も表示されなくなります。これは、コマンドの実行時間を測るときなんかに使います。

パイプライン

コマンドの標準出力を別コマンドの標準入力につなぐパイプラインという機能を用いることで、たくさんのコマンドを連結させることができます。パイプラインは|(パイプ)と呼ばれる記号を使って、次のように記述します。

パイプラインの記述

$ <コマンド1> | <コマンド2> | <コマンド3>....

$ ls -l / | less   #ls -lコマンドで取得した内容をlessコマンドで表示する

パイプラインは複数のコマンドを繋ぐことができます。以下の例は、ls -lで取得した結果にcat -nで行番号をつけて、lessで１ページずつ表示しています。

フィルタ

Linuxには、標準入力を入力として受け取り、標準出力に出力するコマンドが多くあります。このようなコマンドを、フィルタと呼びます。

フィルタの例 -headコマンド-

フィルタの例としてheadコマンドを紹介します。headコマンドは、ファイルの先頭から指定した行数を標準出力に出力するコマンドです。引数を指定しない場合は、最初の10行を表示します。

コマンドを組み合わせることで、先頭の10行を表示することができます。ここでは、コマンド履歴を表示するhistoryコマンドと組み合わせた例を紹介しします。

代表的なフィルタコマンド

Linuxにはフィルタとして利用できるコマンドがたくさん用意されています。ここでは使用頻度の高いコマンド紹介します。

コマンド	役割
cat	入力をそのまま表示する
head	先頭の部分を表示する
tail	末尾の部分を表示する
grep	指定した検索パターンに一致する行だけ取得する
sort	順番に並べ替える
uniq	重複した行を取り除く
tac	逆順に表示する
wc	行数やバイト数を出力する

コマンド組み合わせの例

フィルタはパイプラインを使って、他のコマンドと組み合わせると便利です。ここでは、/binディレクトリの中のファイルを、サイズの大きい順に並べたいという問題を考えてみましょう。ここではduコマンドを使うことにします。

duコマンド

$ du [オプション] [ファイル/ディレクトリ]

上記の問題に関して以下のような機能のコマンドを使用して、課題解決したいと思います。

• duコマンドは-bを指定すると、引数で指定されたファイルのサイズをバイト単位で表示します。
• sort -nコマンドは数値を対象に小さい順に並べ替えるコマンドです。
• tacコマンドは入力行の順序を逆にして出力するコマンドです。
• head -n 5はheadコマンドの-nオプションを使って、最初の5行を表示させています。

これで、/binディレクトリの中のファイルを、サイズの大きい順に並べることができました。

このようなパイプライン処理が行えること、様々なフィルタが用意されていることが、Linuxがテキスト処理に強いと言われている理由の１つとなります。

参考資料

新しいLinuxの教科書

lpic勉強中なのでping-tを参考にしてパッケージツールのオプションなどをまとめました。

RedHat系(Red Hat Enterprise Linux, CentOS, Fedoraなど)

●RPMツール (設定ファイル:/usr/lib/rpm/rpmrc)

• rpmコマンド : パッケージのインストール・アンインストールなど、基本的なパッケージ管理を行うコマンド
  参照・検査関連の主なオプション

インストール関連の主なオプション
  

• rpm2cpio : PRM系パッケージをcpio形式のアーカイブに変換するコマンド

  ●YUMツール　(設定ファイル:/etc/yum.conf, パッケージ取得元の設定:/etc/yum.repos.d下の.repoファイル)

  RPMツールを拡張したツール群。

• yumコマンド
  

  ●DNFツール

  YUMツールの後継となるツールで、Fedora22からデフォルトのパッケージ管理ツールになっている。
  リポジトリの設定もYUMツールと同様に/etc/yum.repos.d/下の.reposファイルで設定する。

  Debian系(Debian GNU/Linux, KNOPPIX:クノーピックス, Ubuntuなど)

  ●dpkgツール(設定ファイル:/etc/dpkg/dpkg.cfg)

• dpkgコマンド : パッケージのインストール・アンインストールなど、基本的なパッケージ管理を行うコマンド
  

• dpkg-reconfigureコマンド : インストール済みのパッケージをパッケージを再設定するコマンド

  ●APTツール(パッケージ取得元の設定:/etc/apt/sources.list)

  dpkgツールを拡張したツール群

• apt-getコマンド : パッケージのインストール・アンインストールを行うコマンド
  

• apt-cacheコマンド : パッケージ情報の検索・参照などを行うコマンド
  

• aptコマンド : apt-getとapt-cacheの機能を統合したコマンド

  openSUSE(SUSE Linuxから改名)

  ●ZYPPER(ジッパー)ツール

  

linux mintを入れるやり方

今回、古いPCの動作が遅く使い勝手が悪いので動作速度の向上と、
Linuxの学習、PCシステムの勉強がてら、Linuxディストリビューションの一つである
Linux mintを入れてみました。

スペック

• ASUS U32U
• CPU：AMD デュアルコア E-450 APU
• メモリ：4GB
• ストレージ：500GB
• OS：Windows 7

手順

ディストリビューションのインストール

まずはLinux Mintのインストールファイルのダウンロード

ダウンロードは

Linux Mint イメージファイル

から取得する

ダウンロードしたファイルをUSBメモリに書き込む

Linux Mintをダウンロードしたら、次にインストール用のUSBメモリを作成

専用のソフトウェアを使って書き込む必要があるので

「balenaEtcher」というソフトを使用

flash from fileでLinux Mintのファイルを選択し、USBを繋いでいる場合、select targetにはデフォルトでUSBが選択されているので、flashボタンを押して実行

数分後イメージファイルの書き込みが完了。

ノートパソコンにUSBメモリを挿してLinux Mintを起動する

PCにUSBメモリを挿し、BIOS設定画面起動。

BIOS設定画面はPC起動直後にF2またはF12を押せば起動できる。（PCによって違う）

BIOS設定画面起動後BIOSの起動順位を変更。

最初にHDを読み込む設定になっているのでUSBの優先順位をあげる。

保存してパソコンを再起動。

USBが読み込まれ、Linux Mintが起動する。

Linux Mintをインストール

Linux Mintが起動するとメニューが表示されるので「Start Linux Mint」を選択。

次に「Install Linux Mint」を選択。

インストーラが起動するので、指示通りに進める。

インストールが終了したらPCを再起動する。

画面に書いてある通りに、USBを抜いてエンターキーを押下。

これでLinux Mintインストールが完了。

インストール後にすること

# パッケージのアップデート
sudo apt update
sudo apt upgrade

インストール時に起きたエラー

GRUB を/dev/sda にインストールできません。
'grub-install /dev/sda' の実行に失敗しました。
これは致命的なエラーです。

のエラーが出て、再起動時にOSが起動されない現象が起こる

解決策

インストール時にインストールの種類選択時、
それ以外（自分でパーティションの作成・・・）
を選択し、

ブートローダーをインストールするデバイスを
/dev/sda

に変更し、インストールを実行するとエラーなく終了する

原因

そもそもGRUBとは

• GRUBとは、コンピュータの起動時に最初に読み込まれ、ストレージなどからオペレーティングシステム（OS）を読み込んで起動するブートローダの一つ。GNUプロジェクトが開発・公開しているオープンソースソフトウェアで、よくLinuxと組み合わせて用いられる。 要するに、OSを起動するために必要なプログラムの１つ

/dev/sdaは最初に見つかったハードディスクのこと

自分の場合はブートローダーのインストール先をハードディスクにできておらず、ブートUSBを抜いた状態で再起動時するためOSの起動が出来なかった。

さくっと環境が欲しくなったときのためにここに書き留めておきます。

Ubuntuを引っ張る

bash

$ docker run -it ubuntu bash

はい終わり。多分これが一番早いです。

無事root権限でログインできてます。

加えてsudoとかnanoとか任意です。

bash

root$ apt-get update
#gitのインストール
root$ sudo apt-get -y install git
#エディタ(nano)のインストール
root$ sudo apt-get install nano

ちなみにこれだと日本語入力に対応していないので, 以下を参考にしてみてください。
【Docker】ubuntuの環境で日本語入力を可能にする

あとはubuntuをいじくり倒し(てぶっ壊し)ましょう！