What's New Qiita

20190607のLinuxに関する記事は5件です。

  • 投稿日：2019-06-07T22:51:08+09:00

Hyper-VでOSが起動しない時の対処法

はじめに

初めてHyper-Vを触った時に、作成した仮想マシンがなぜか起動しない...という謎の現象に陥りました。
同様の事象は色々なサイトでも紹介されていますが、ここでは備忘録として記録しています。

発生した現象

Windows10 Pro（64bit）の環境で、以下の手順で仮想マシンを構築しましたが、なぜか正常に起動しませんでした。

  1. ［コントロールパネル］>［プログラムと機能］>［Windowsの機能の有効化または無効化］へと進み、［Hyper-V］を有効化する。
  2. ［スタートメニュー］>［Windows管理ツール］>［Hyper-Vクイック作成］と進み、LinuxのISOファイルを指定して仮想マシンを作成する。
    • ここではCentOS 6.10を使用。
  3. 作成した仮想マシンで［起動］を押しても、仮想マシンが正常に起動しない。
    • 「PXE Network Boot using IPv4 (ESC to cancel) Performing DHCP Negotiation...」というメッセージが表示された所で処理が止まってしまい、しばらく待っていてもそこから先に進めず...
  4. ここで使用したISOファイルが壊れているのではと疑って、CentOS 7.6（1810）を使って上記1～3の手順を繰り返したものの、やはり正常に起動せず...

解決策

  • 仮想マシンの設定画面で、［セキュアブートを有効にする］のチェックを外すことで、仮想マシンを正常に起動することができました。
    • よく知られた事象のようですが、何事も初めてだと分からなくて焦りますね...

disabled_secure_boot.png

参考URL

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-06-07T22:51:08+09:00

Hyper-Vで仮想マシンが起動しない時の対処法

はじめに

初めてHyper-Vを触った時に、作成した仮想マシンがなぜか起動しない...という謎の現象に陥りました。
同様の事象は色々なサイトでも紹介されていますが、ここでは備忘録として記録しています。

発生した現象

Windows10 Pro（64bit）の環境で、以下の手順で仮想マシンを構築しましたが、なぜか正常に起動しませんでした。

  1. ［コントロールパネル］>［プログラムと機能］>［Windowsの機能の有効化または無効化］へと進み、［Hyper-V］を有効化する。
  2. ［スタートメニュー］>［Windows管理ツール］>［Hyper-Vクイック作成］と進み、LinuxのISOファイルを指定して仮想マシンを作成する。
    • ここではCentOS 6.10を使用。
  3. 作成した仮想マシンで［起動］を押しても、仮想マシンが正常に起動しない。
    • 「PXE Network Boot using IPv4 (ESC to cancel) Performing DHCP Negotiation...」というメッセージが表示された所で処理が止まってしまい、しばらく待っていてもそこから先に進めず...
  4. ここで使用したISOファイルが壊れているのではと疑って、CentOS 7.6（1810）を使って上記1～3の手順を繰り返したものの、やはり正常に起動せず...

解決策

  • 仮想マシンの設定画面で、［セキュアブートを有効にする］のチェックを外すことで、仮想マシンを正常に起動することができました。
    • よく知られた事象のようですが、何事も初めてだと分からなくて焦りますね...

disabled_secure_boot.png

参考URL

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-06-07T18:28:14+09:00

初心者がパスを通す(´･ω･`)

・対象：IT初心者「しょぼん君」image.png
しょぼん君：image.png『パスを通すってどういう事ですか』

パスを通すとは

「パスを通す」とは、環境変数のPATHに実行ファイルまでのパスを追記することです。
しょぼん君：image.png『パスにパスを追記するって言われても...なんのために』

普段シェルスクリプトなどを実行するときには、ターミナルで、「./hoge/foo/bar.sh」などパス（道のり）を指定して実行すると思います。これでもいいんですが、数や頻度が多くなると、cdしたりlsしたりしながら探したり...ちょっと面倒ですよね。

実は、環境変数PATHによく使う実行ファイルのパスを書くことで、どこからでも実行ファイル名だけで実行出来るようになります。ターミナルで実行されたコマンドは、環境変数PATHを元に検索され実行されます。そのため、環境変数のPATHのことをコマンドサーチパスなんて言ったりもします。

しょぼん君：image.png『環境変数PATHに、よく使う道（パス）を教えておけば、実行ファイル名だけで実行してくれるようになるんだね』

環境変数PATH

「環境変数」は、プロセスの中で宣言する「シェル変数」よりも有効範囲が広い変数で、ターミナルを終了(exit)するまでパソコンが覚えている変数のことです。
しょぼん君：image.png『環境変数なら共通の変数として色んなシェルスクリプトから使えたりするんだな』

さっそく、環境変数PATHの中身を確認してみましょう。

環境変数PATHの確認.
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

パスはコロン（：）で区切られていて、コマンド実行時には、左のパスから優先的に検索をして実行ファイルを実行します。
例えば、環境変数PATHに登録されている/bin配下を確認してみます。

$ ls /bin/
[       chmod       date        domainname  expr        ksh     ln      mv      pwd     sh      sync        unlink
bash        cp      dd      echo        hostname    launchctl   ls      pax     rm      sleep       tcsh        wait4path
cat     csh     df      ed      kill        link        mkdir       ps      rmdir       stty        test        zsh

しょぼん君：image.png『よく使う「ls」や「pwd」があるね。これらも実行ファイルで、PATHにパスが書いてるからコマンドとして使えるんだね』

環境変数のPATHに追記をするには、以下のexportコマンドを使います。

環境変数PATHへの追記.
#環境変数PATHの右側にパスを追記（優先度低）
$ export PATH=$PATH:/hoge/foo

#環境変数PATHの左側にパスを追記（優先度高）
$ export PATH=/hoge/foo:$PATH

しょぼん君：image.png『あれ、でもこれじゃあターミナルを閉じたら消えちゃうよね？』

環境変数PATHを永続的にする

上述では、ターミナル起動後に「閉じるまでは環境変数PATHはこうするよ」と教えていたのでexitすると消えてしまいました。そこで、ターミナル起動時に「閉じるまでは環境変数PATHはこうするよ」を毎回教えるように設定すればターミナルを閉じたり再起動しても環境変数を利用することが出来ます。

しょぼん君：image.png『毎回勉強してから起動してもらうんやね。』

ターミナルのデフォルトではbashというシェルが起動されます。シェルは私たちと機械の仲介役で通訳のような役割をします。

ターミナルを起動すると通訳：bashさんが呼ばれ、設定ファイルである「bash_profile」や「bashrc」が読み込まれます。

環境変数は起動時に一度読み込まれたら良いので起動時に読み込まれる「bash_profile」に記載するのがベターです。bash_profileはホームディレクトリ配下の隠しファイルとして存在します。なければ作りましょう。

bash_profileがあるか確認.
$ ls -al | grep .bash
bash_profileの編集・作成.
$  vi ~/.bash_profile

# 追記
export PATH=$PATH:/hoge/foo

ファイルに追記しただけでは変更が反映されないので、ターミナルを再起動してログインしなおすか、sourceコマンドで設定を読み込み直します。

設定の反映.
$ source .bash_profile

しょぼん君：image.png『パスを通したから、どこからでも実行出来るようになって楽チンだぜ。これで手順書も薄く...ククク』

TIPS

コマンドからパスを探したいときは、which コマンドを使います。

バージョン確認.
$ which ls
/bin/ls

END

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-06-07T16:01:15+09:00

全文検索サーバを構築した話 その2（docker構築詳細編）

その1ではざっくりと全文検索サーバ構築の経緯と構築環境について記載しました。
その2ではもう少し掘り下げて環境構築のメモを記載します。（ほぼWebエビデンス）

OS環境

OSバージョン

$ cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

カーネルバージョン

$ uname -a
Linux [ホスト名] 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

dockerインストール

dockerはCentOS標準のdockerをyumでインストールしました。

$ sudo yum -y install docker

インストール:
  docker.x86_64 2:1.13.1-96.gitb2f74b2.el7.centos

依存性関連をインストールしました:
  PyYAML.x86_64 0:3.10-11.el7
  atomic-registries.x86_64 1:1.22.1-26.gitb507039.el7.centos
  audit-libs-python.x86_64 0:2.8.4-4.el7
  checkpolicy.x86_64 0:2.5-8.el7
  container-selinux.noarch 2:2.95-2.el7_6
  container-storage-setup.noarch 0:0.11.0-2.git5eaf76c.el7
  containers-common.x86_64 1:0.1.35-2.git404c5bd.el7.centos
  device-mapper-event.x86_64 7:1.02.149-10.el7_6.7
  device-mapper-event-libs.x86_64 7:1.02.149-10.el7_6.7
  device-mapper-persistent-data.x86_64 0:0.7.3-3.el7
  docker-client.x86_64 2:1.13.1-96.gitb2f74b2.el7.centos
  docker-common.x86_64 2:1.13.1-96.gitb2f74b2.el7.centos
  libaio.x86_64 0:0.3.109-13.el7
  libcgroup.x86_64 0:0.41-20.el7
  libsemanage-python.x86_64 0:2.5-14.el7
  libyaml.x86_64 0:0.1.4-11.el7_0
  lvm2.x86_64 7:2.02.180-10.el7_6.7
  lvm2-libs.x86_64 7:2.02.180-10.el7_6.7
  oci-register-machine.x86_64 1:0-6.git2b44233.el7
  oci-systemd-hook.x86_64 1:0.1.18-3.git8787307.el7_6
  oci-umount.x86_64 2:2.3.4-2.git87f9237.el7
  policycoreutils-python.x86_64 0:2.5-29.el7_6.1
  python-IPy.noarch 0:0.75-6.el7
  python-backports.x86_64 0:1.0-8.el7
  python-backports-ssl_match_hostname.noarch 0:3.5.0.1-1.el7
  python-ipaddress.noarch 0:1.0.16-2.el7
  python-pytoml.noarch 0:0.1.14-1.git7dea353.el7
  python-setuptools.noarch 0:0.9.8-7.el7
  setools-libs.x86_64 0:3.3.8-4.el7
  subscription-manager-rhsm-certificates.x86_64 0:1.21.10-3.el7.centos
  yajl.x86_64 0:2.0.4-4.el7

完了しました!

dockerサービス自動起動設定

$ sudo systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.

dockerサービス起動と確認

$ sudo systemctl start docker
$ sudo systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since 金 2019-06-07 14:42:00 JST; 23s ago
     Docs: http://docs.docker.com
 Main PID: 20950 (dockerd-current)
   CGroup: /system.slice/docker.service
           tq20950 /usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --defau...
           mq20958 /usr/bin/docker-containerd-current -l unix:///var/run/docker/libcontainerd/docker-containerd.sock ...

Fessのイメージを取得する

$ sudo docker pull codelibs/fess:latest
Trying to pull repository docker.io/codelibs/fess ...
latest: Pulling from docker.io/codelibs/fess
e79bb959ec00: Pull complete
d4b7902036fe: Pull complete
1b2a72d4e030: Pull complete
de423484a946: Pull complete
9ce08128c662: Pull complete
53b0cf80b370: Pull complete
52bd533f444d: Pull complete
f39d9fa4825b: Pull complete
ffbf2fa304a8: Pull complete
560b4917ad19: Pull complete
b19453126120: Pull complete
3e02eca524a0: Pull complete
5145f1f6b740: Pull complete
9c0519ef74ee: Pull complete
Digest: sha256:f8c9818af2035b2b5489756c609bf973f8cc02c460874f4f9e5e8672f7c105c9
Status: Downloaded newer image for docker.io/codelibs/fess:latest

Fessのdockerコンテナを作成する

dockerのコンテナ名は、"全文検索"を英訳すると"Full text search"となるため、頭文字を取って"fts"にしました。
また、メインサービスがfessになるため、ポート指定してつながなくても良いようにホストの80番ポートをコンテナ内の
fessの8080ポートにマッピングしています。

$ sudo docker run -d -p 80:8080 --name fts codelibs/fess:latest
c266e8c6c14d2514a60d987d1beb4c6c5a187b2ba5142a6087a464fc3261b17b

コンテナのタイムゾーンを変更する

コンテナ内のOS環境の標準タイムゾーンがUTCのため、日本時間のJSTに変更します。

$ sudo docker exec -it fts rm /etc/localtime
$ sudo docker exec -it fts ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
# 時間確認
$ sudo docker exec -it fts date
Fri Jun  7 15:01:10 JST 2019
$ sudo docker exec -it fts ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Jun  7 15:00 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo

Fess動作確認

curlで80番ポートにHTTPしてヘッダが読めるか確認します。

$ curl --head http://localhost
HTTP/1.1 200
Set-Cookie: JSESSIONID=4937956A71BB0E6DE7D7B974BB39D7F0; Path=/; HttpOnly
Pragma: no-cache
Cache-Control: no-cache, no-store
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 07 Jun 2019 06:08:41 GMT

ブラウザ動作確認

fessスクリーンショット.PNG
ブラウザでアクセスしてFessのページが表示されればOK。

まとめ

こんな感じで非常に簡単にFessによる全文検索サーバの環境が構築できます。
実際やっていただければわかりますが、イメージのダウンロード時間を除けばものの数分でFessが
利用できる環境を構築することができます。

おまけ

割愛しておりますが、selinuxを無効、firewalldの停止をしております。
selinuxとfirewalldを有効にして利用する場合はもうひと手間手順が必要かもしれません…
その辺は別の詳しい方に聞いてください…（弱気）

次回こそ、PDF変換手順の説明を書きます！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-06-07T14:19:54+09:00

CentOS7 dump/restore を使用して空のHDDに復旧させるまで

はじめに

Qiita初投稿です。自分はSEになってまだ3年目のぺーぺーですが、新しい案件で環境構築を任されシステムバックアップの実装もするよう言われました。その際、CentOS7 での復旧手順で地獄を見たので備忘録として残しておきます。誰かの役に立ちますように。

環境

  • バックアップサーバ
    Western Digital製 HDD 3TB
    CentOS7.6
    レガシーBIOSのみ
    IP：192.168.56.10

  • バックアップ対象サーバ
    Western Digital製 HDD 3TB
    CentOS7.6
    UEFI対応
    IP：192.168.56.1

  • リストアサーバ
    Western Digital製 HDD 3TB
    IP：192.168.56.1

前提

  • HDD1枚のため、デバイス名は/dev/sdaとします。
  • CentOS7.6のイメージディスク使用。
  • バックアップ対象サーバとリストアサーバは同じ筐体を使用。

今回のバックアップ、リストアはレガシーBIOSでブートする場合になります。
UEFIでのリストアはまだ上手くいっていません。。。いつか上げられたら嬉しいです。

手順

  1. NFSサーバの設定
    まずはバックアップを取るためにNFSサーバ・クライアントの設定します。以下のサイトを参考に構築していきます。

    参考サイト

    CentOS7.1 NFSサーバ、クライアントの設定
    NFS サーバ／クライアント設定メモ（CentOS7.1.1503）

    NFSサービスのインストール

    # yum -y install nfs-utils

    エクスポートポイント(NFS用の共有)設定。
    今回は、 /backup というディレクトリを誰でも触れるようにしている
    アクセスできるIPアドレスを設定したい場合は、* のところにIPを設定する。

    # vi /etc/exports
/backup *(rw,async,no_root_squash)

    サービスを起動して有効化

    以下の２つはOS起動時に自動的に有効にするコマンド

    # systemctl start rpcbind
# systemctl start nfs-server
# systemctl enable rpcbind
# systemctl enable nfs-server

    ここからはNFSクライアントの設定

    マウントポイントを作成

    # mkdir /mnt/nfs

    サービスを起動して有効化

    # systemctl start rpcbind

    ポート 2049 の TCP/UDP を許可

    # firewall-cmd --add-port=2049/tcp --permanent
# firewall-cmd --add-port=2049/udp --permanent

    設定を読込み

    # firewall-cmd --reload

    設定を確認（以下の表示があればOK）

    # firewall-cmd --list-all
ports: 2049/tcp 2049/udp

    NFSv4でマウント

    # mount -t nfs [サーバ側のIPアドレス]:/backup /mnt/nfs

    ※NFSv3とNFSv4の違いは、IPの指定ができる点。その他諸々。
    以下、参考サイト
    知っておきたいNFSの基本と活用法

  2. バックアップ対象サーバのバックアップ実行

    参考サイト

    Linuxシステムバックアップの基本:dump と restore コマンドによるシステムリカバリの方法を今更ながら解説(Linux)
    Linux システムバックアップリストア(xfs dump restoreおよびUEFI)

    2-1. 必要なパッケージのインストール
    CentOSの場合、dumpコマンドが標準インストールされていないため、パッケージをインストール
    また、この後使うディスク情報を取るコマンドで、足りないものがあったのでそれもインストールする。

    # yum -y install dump
# yum -y install lvm2    (lvm系のコマンドのインストール)

    2-2. ディスク情報の出力
    バックアップ対象サーバーのディスク情報をファイルに出力。後でパーテーションの復旧等に使用。

    # LANG=C fdisk -l > /tmp/`hostname`_fdisk.txt
# LANG=C df -T > /tmp/`hostname`_df.txt
# LANG=C pvdisplay > /tmp/`hostname`_pv.txt
# LANG=C vgdisplay > /tmp/`hostname`_vg.txt
# LANG=C lvdisplay > /tmp/`hostname`_lv.txt

    2-3. ダンプの実行
    バックアップ対象サーバのマウントポイントごとに、ダンプする。
    今回は、/および、/bootをバックアップ対象とし、tmpfsは、バックアップ対象外とする。

    # dump -f /mnt/nfs/sda2_boot.dump /dev/sda2    (/boot のパーテーション)
# dump -f /mnt/nfs/sda5_root.dump /dev/sda5    (/ のパーテーション)

    ダンプが終了すると、NFSマウントしたマウント先にダンプファイルが出力されるので、NFSマウントを解除。

    # umount /mnt/nfs

  3. 先ほど取ったバックアップを空のHDDに復旧させる(リストアの実行)
    ダンプ終了後、CentOSのインストールCDのレスキューモードを使用してリストア対象サーバにリストアを行う。
    なお、リストア対象サーバは、OSがインストールされていない新規サーバとしている。

    3-1. レスキューモード起動
    CentOSのインストールCDを用いて、リストア対象サーバを起動。
    ブートメニューが表示されたら、Troubleshooting -> Rescue a CentOS system
    の順で選択する。
    しばらく待っていると、1～4番のメニューを選択する画面になるので、3を入力。

    レスキューモード.PNG

    3-2. 初期設定
    キーボードが変だったり、IPが設定されていなかったりするので設定する。

    # localectl set-keymap jp106
# ip a add [設定したいIP]/[ネットマスク] dev [ネットワークデバイス名]
例）
# ip a add 192.168.56.1/16 dev eno1

    3-3. パーティション作成
    新規のHDDに、パーティションを作成。
    自分の環境では、sda1からsda7までパーテーションを作成し、sda1にブートフラグを設定している。
    設定完了後、パーティションタイプも変更。
    設定の仕方は参考サイトにも書いてある。ちなみに今回は間違ってfdiskでやってしまいましたが特に問題はありませんでした。
    しかし、2TBを超える場合はgdiskコマンドで設定をしましょう。

    # fdisk /dev/sda
・
・
・

★パーティション作成後
# mkfs.ext4 /dev/sda2
# mkfs.ext4 /dev/sda3
# mkfs.ext4 /dev/sda4
# mkfs.ext4 /dev/sda5
# mkfs.ext4 /dev/sda7

    3-4. リストアの実行
    まず、リストアを実行する前に、バックアップイメージを置いたバックアップサーバのNFS領域をマウント。

    # mount -t nfs [バックアップサーバのIP]:[NFS領域] /mnt
例）
# mount -t nfs 192.168.56.10:/backup /mnt

    そのままリストアすることは出来ないので、ルートディレクトリをリストアするディレクトリを作成。
    次に、ルートディレクトリをマウントさせていたデバイスをマウント。
    この後、/bootも同様の操作を行う。

    # mkdir /restore
# mount -t ext4 /dev/sda5 /restore
# cd /restore
# restore -rf /mnt/sda5_root.dump
★ここからboot
# mount -t ext4 /dev/sda2 /restore/boot
# cd /restore/boot
# restore -rf /mnt/sda2_boot.dump

    3-5. chroot環境への移行
    リストアのマウントポイントを仮想ルートディレクトリに設定。

    ★chrootした先でboot配下等見れるようにする
# mount --bind /dev /restore/dev
# mount --bind /proc /restore/proc
# mount --bind /sys /restore/sys

# chroot /restore

  4. 現在のHDDの環境合わせる
    前のサーバの情報(主にUUID)がそのまま設定されているままなので修正していく。
    4-1. fstabの修正
    UUIDが設定されていると思うので、対応するデバイス名に変更。
    バックアップ対象サーバで、dfすればで見れる。
    ※UUIDは適当に変更しましたので気にしないでください。イメージです。

    # vi /etc/fstab
★変更前
UUID=11111111-2222-3333-4444-555555555555 /                       ext4    defaults        1 1
UUID=11111111-2222-3333-4444-555555555555 /backup                 ext4    defaults        1 2
UUID=11111111-2222-3333-4444-555555555555 /boot                   ext4    defaults        1 2
UUID=11111111-2222-3333-4444-555555555555 /home                   ext4    defaults        1 2
UUID=11111111-2222-3333-4444-555555555555 /home/tomatoma          ext4    defaults        1 2
UUID=11111111-2222-3333-4444-555555555555 swap                    swap    defaults        0 0

★変更後
/dev/sda5     /                       ext4    defaults        1 1
/dev/sda7     /backup                 ext4    defaults        1 2
/dev/sda2     /boot                   ext4    defaults        1 2
/dev/sda3     /home                   ext4    defaults        1 2
/dev/sda4     /home/tomatoma          ext4    defaults        1 2
/dev/sda6     swap                    swap    defaults        0 0

    4-2. ネットワークインターフェースの修正
    /etc/sysconfig/network-scripts/[ネットワークインターフェース名] にも古いUUIDが設定されているので、nmcli コマンドを使用して現在のUUIDを調べる。あとは頑張って修正。
    ※UUIDは適当に変更しましたので気にしないでください。イメージです。

    # nmcli connection show
NAME    UUID                                  TYPE      DEVICE 
eno1  123456768-1234-5678-1234-1234567890ab   ethernet  eno1

    4-2. grub.cfgの修正
    grub2ブート設定(/boot/grub2/grub.cfg)にも、古いパーティションへのUUIDが定義されているので再作成し直す。
    直接編集は推奨されていないため、専用のコマンドを使用。

    # grub2-mkconfig -o /boot/grub2/grub.cfg

    4-3. mbrにブートローダ(bootのシステム的な) のインストール 超重要
    これ忘れていたせいで数時間嵌ってしまいました。詳しいことは長くなるので調べてもらえたら幸いです。

    # grub2-install /dev/sda

    4-4. 再起動
    chrootを終了し、レスキューモードからも抜けます。

    ★chrootを終了
# exit
★レスキューモードを終了
# exit

まとめ

以上で手順は終わりです。手探りの中見つけた方法にはなるので、もしかしたら動かないよ！！！
みたいな人もいるかもしれません。また、この手順も必要じゃない？みたいなのもあるかもしれません。
もしそういった意見がありましたら是非教えて頂けたら幸いです。
ありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧