What's New Qiita

20200927のLinuxに関する記事は11件です。

  • 投稿日：2020-09-27T23:58:02+09:00

WindowsとLinuxのディレクトリの違い

パスの区切り文字

  • Windowsでは ￥ が使われるが、Linuxでは / を用いる。

ディレクトリ構造

  • システム全体で2台の物理ディスクがある場合、Windowsでは2つのディレクトリツリーができるが、Linuxでは何台のディスクがあろうが、システム全体で1つのディレクトリツリーしか持たないのが大きな違いである。このため複数ディスクがある場合、Linuxではルートディレクトリ配下のどこかに、ディスクをディレクトリとしてくっつける手法（この操作を「マウント」と呼ぶ）を取っている。
※ ディストリビューションによってディレクトリ構造に若干の違いはある。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T23:21:34+09:00

LPIC202に合格した勉強法

＠Qiita初投稿記事

LPIC202に合格したので、備忘録として勉強法を投稿します。Ping-tに投稿しようと思いましたが、今回Ping-tを一切使用しなかったため、こちらに投稿します。※自身の主観も含まれた記事ではありますが、何卒ご容赦下さい。

取得しようとした目的

サーバー構築などが必要となる場面に必要な知識は、レベル2の取得が必須になると考えたためです。特にLPIC202ではApache,BIND,Nginx,NFS,Sambaなど、Linuxサーバーの幅広い知識が習得できると考え受験しました。

学習時間

約２週間

使用したテキスト

・白本 (似たような問題が出題されます)
・小豆本 （辞書代わりに使いました）

主な学習方法

・小豆本を1周読み、サラッと雰囲気を理解します

・白本を解きます(私の場合、全3回解きました。3回目でようやく全単元(模試含む)90％から80％に近い解答率となりました)

※1周目は間違いだらけで苦痛でしょうが、気にせず解いていきましょう

※2周目からは解説を全て精読し、重要・理解できない箇所には蛍光ペンでマーキングをしましょう

(不明点はググり、小豆本を辞書代わりに確認し、理解できない項目に内容を転記していきましょう)

※白本内の[参考][合わせてチェック]などに付箋を張り、その箇所を何回か読みこみましょう

※白本内の記述問題に出題される設定ファイルは全て押さましょう

(解説内の細かい設定内容までは覚える必要はありません(覚えるのは時間の無駄))

・LPIC202の出題範囲をスマホのメモ帳に貼り、不明点をググって意味を書き、通勤時間や休み時間などのスキマ時間に読みましょう

・小豆本の暗記項目はスマホのメモ帳に貼り、不明点をググって、メモ帳に転記し、スキマ時間に読みましょう

・LPIC202合格体験記を読み、出題しそうなポイントを押さえておきましょう

・蛍光ペンでマーキングした重要項目、何回も間違えてる箇所を重点的に読み返しましょう

・不明点は小豆本を読み返し、意味を咀嚼してテキストに転記しましょう

ポイント1-理解までに時間がかかる

・最初はサーバーの利用用途から不明なため、出題単元の大枠を理解する上でも、「Sambaは何のために使うのか、NFSは何のために使うのか」などを理解しておきましょう。

・細かい設定内容に関してもググって「何のために使うのか」を重視し、用語の意味を調べた上で、自分で理解できる言葉に置き換えて理解するようにしましょう

・図を書いて全体像を理解しましょう

　-DNSの一連の問い合わせの仕組み
　-netfilterのルーティング仕組み
　-メールの配送方法(MTA/MDA/MUA)

ポイント2-出題範囲からズレた勉強はしない

・出題範囲を何回も読み返し、理解不明な点はググって調べましょう

ポイント3-合格体験記はよく読みましょう

・重箱を突く問題が出る、合格体験記で噂になっているような知識は出ます
　
-fail2ban
-グルーレコードなど

最後に

LPIC202はLPIC資格の中でも暗記項目が多く、最難関と言われることが多いですが、
多少なりともこの記事が役に立ち、皆様が合格されることを祈ります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T23:05:46+09:00

ロックファイル /var/lib/dpkg/lock-frontend をオープンできません　の対処方法

さてこれがQiita初投稿。大目に見てくださいな。

なんらかのアプリをインストールする際、コマンドで実行しようと

apt install ●●●

だけだと

**:~$ apt install ●●●
E: ロックファイル /var/lib/dpkg/lock-frontend をオープンできません - open (13: 許可がありません)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
**:~$

こういう文言が出てしまう。そのため

sudo apt install ●●●

のようにaptの前にsudoが必要。なんかのインストールは管理者権限がないと実行できないからね。このコマンドは管理者のコマンドですよぉと認識させるためのものって考えればヨシ

以上、では

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

Visual Studio Code と Azure で Linux System Programing をやってみよう！（helloworld から nginx の開発とリモートデバッグまで）

今回は、Visual Studio Code の Remote Development 機能を使って、Azure Virtual Machine の Ubuntu で Linux System Programing (C言語)をやってみたいと思います。

とりあえず動かしてみるために helloworld を用意しました。また、実際の開発に近い形として nginx を題材にリモートデバッグしてみようと思います。

  • helloworld の開発とリモートデバッグ
  • nginx の開発とリモートデバッグ

1. Microsoft Azure に Ubuntu の Virtual Machine を準備する

Ubuntu の Virtual Machine を作成します。ポイントとしては以下になります。

  • Linux の Virtual Machine として今回は、 Ubuntu Server 18.04 LTS -Gen1 を使用
  • Authentication Type は SSH Public Key を使用
  • Inbound ports は、22(SSH)と、8080(後半のnginxで使用)を設定

Virtual Machine の作成に関しては、みなさんご存じだと思いますので読み飛ばしても構いませんが、上記にあわせて作成してください。

1.1. Ubuntu の Virtual Machineを作成する

Microsoft Azure のポータル画面から、Create a resource を選び、Virtual Machineを作成します。以下のように Ubuntu Server 18.04 LTS -Gen1 を選択します。選択したら、Review + Createを押します。

image.png

確認画面で Create を押すと、Private Key のダウンロードとVirtual Machineの作成ボタンが表示されますので続けて押します。Private Key は、作成された Ubuntu に SSHで使用する際に必要となりますので、無くさないように保存しておいてください。

image.png

Virtual Machine が作成されたら、Virtual Machine の画面から接続先のIPアドレスを確認しておいてください。

2. Visual Studio Code を準備する

Windows 10 に Visual Studio Code をインストールした後に、リモート開発の設定をします。(macOS も一緒ですが、今回は、あの Windows で 実機の Linux System Programing できることが凄いので、Windows 10 で進めます）

2.1. Visual Studio Code をインストールする

まずは、Visual Studio Code は以下のサイトからダウンロードしてください。
https://code.visualstudio.com/

image.png

ダウンロードしたインストーラーを実行してインストールします。インストール中に追加するタスクの選択が出てきますが、今回は以下のように設定しました。デスクトップに Visual Studio Code のショートカットが作成されますので、本記事で実行する際はこちらをご利用ください。

image.png

2.2. リモート開発に必要なエクステンションを Visual Studio Code にインストールする

Visual Studio Code を起動した後に、左のExtentionsアイコン（下図の①）からエクステンションをインストールします。検索ボックス（下図の②）に、以下のエクステンション名を入力して検索します。エクステンションが表示されたらインストール（下図の③）を押してインストールを完了します。

エクステンション名：Remote Development
ms-vscode-remote.vscode-remote-extensionpack
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack

image.png

Remote Development がインストールされると、左下に緑色のボタンが表示されるので、そこをクリックします。

image.png

2.3. Azure の Virtual Machine に SSH で接続する

左下の緑色のボタンから、「Remote-SSH:Open Configuration File...」を選択して、sshの接続先を登録します。HostName には Virtual Machine のパブリックIPアドレス、IdentityFile には、Virtual Machine 作成時にダウンロードした Private Key を設定します。

.ssh/config
Host linuxsystemprograming-vm
  HostName xxx.xxx.xxx.xxx
  IdentityFile C:\Users\kentaro\Downloads\linuxsystemprograming-vm_key.pem
  User azureuser

続いて、左下の緑色のボタンから、「Remote-SSH:Connect to Host...」を選択して、先ほど登録した接続先を選択して、プラットフォームとしてLinuxを選択して接続します。これで、Azure の Virtual Machine にログインされましたので、Ubuntu側に、開発に必要なパッケージをインストールします。Terminal メニューから New Terminal を選択することで、Azure Virtual Machine の Ubuntu のTerminal が表示されます。

image.png

3. Azure Virtual Machine の Ubuntu 開発環境を整える

Terminalで、以下のコマンドを入力して、Azure Virtual Machine の Ubuntu に gcc と gdb をインストールします。

sudo apt update
sudo apt install -y build-essential gdb

4. Hello World を作ってみる

Terminal から、Azure Virtual Machine の Ubuntu にディレクトリを作成して Hello World のC言語ファイルを作成します。

cd /home/azureuser/
mkdir helloworld
cd helloworld
touch helloworld.c

右上のExploreアイコンから、先ほど作成したディレクトリ /home/azureuser/helloworld を開きます。

image.png

Explore に表示されている helloworld.c を選択すると、右下にC/C++のエクステンションをインストールするメッセージが表示されるので、インストールを選択します。（表示されない場合は、左側の Extentions から C/C++ のエクステンションをインストールしてください）

image.png

リロードが必要になりますので、画面中央上のリロードボタンからリロードを行って下しさい。

image.png

4.1. IntelliSense で helloworld.c を書く

helloworld.c の ソースコードは以下になります。

helloworld.c
#include <stdio.h>

int main(int argc, char *argv[])
{
    int i;
    for (i = 3; i > 0; i--)
    {
        printf("%d...\n", i);
    }
    printf("Hello World!\n");
    return 0;
}

Visual Studio Code では、IntelliSenseが使えるようになっていることを確認してください。

image.png

入力したら、Ctl-sで保存しておいてください。

4.2. helloworld.c のビルド方法を設定する

Terminalメニューの「Configure Default Build Task...」を選択した後に、「C/C++:gcc build active file」を選択します。

image.png

taks.json の編集になりますので、以下のように設定します。（自動的に作られたものを変更していません）

task.json
{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "C/C++: gcc build active file",
            "command": "/usr/bin/gcc",
            "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/${fileBasenameNoExtension}"
            ],
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

Terminalメニューの「Run Build Task...」からビルドできることを確認してください。helloworld実行ファイルが作成されますので、実行することができます。

image.png

4.3. helloworld.c のデバッグ方法を設定する

Terminalメニューから「Add Configuration...」を選択し、「C++(GDB/LLDB)」を選択し、「gcc - Build and debug active file」を選択してデバッグ方法を設定します。

image.png

launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "gcc - Build and debug active file",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: gcc build active file",
            "miDebuggerPath": "/usr/bin/gdb"
        }
    ]
}

4.4. helloworld.c をリモートデバッグする

設定が完了したら、Helloworld.cを選択した状態で、F5を押すか、Runメニューから「Start Start Debugging」を選択して、helloworldをデバッグ実行します。行数が表示されている左側をクリックすることにより、ブレイクポイントを設定することもできますし、ステップ実行や、変数の値を確認することができるようになります。

image.png

次は、Azure Virtual Machine の Ubuntu 上で動いている nginxを題材にデバッグ実行してみます。

5. nginx を Visual Studio Code で ビルド、デバッグしてみる

Hello World だと実践的ではないので、nginx を題材に Visual Studio Code で開発とデバッグを行ってみたいと思います。

5.1. nginx のダウンロードと必要なパッケージのインストール

nginx のソースコードをダウンロードして nginx の開発環境を整えます。あと、nginx のビルドに必要なパッケージもインストールしておきます。

sudo apt install -y libpcre3-dev libz-dev
cd ~/
wget https://nginx.org/download/nginx-1.19.2.tar.gz
tar xvfz nginx-1.19.2.tar.gz
cd nginx-1.19.2/

試しに nginx をデバッグ用にビルドしてみます。エラー無くビルドできることを確認します。

cd ~/nginx-1.19.2/
./configure --with-cc-opt="-O0" --prefix=`pwd`/nginx
make

5.2. Visual Studio Code で nginx のコードを確認する

Visual Studio Code の Fileメニューから「Open Folder...」を選択して、nginxのディレクトリ(/home/azureuser/nginx-1.19.2)を開きます。IntelliSense が使えるようになっていると思います。

あと、今回の開発は azureuser で実施するため、nginxのリッスンポートを8080などに変更しておきます。conf/nginx.conf の 36行目あたりのポート設定を 8080 に変更します。（もし、make installしている場合は、nginx/conf/nginx.conf も変更しておいてください）

image.png

5.3. nginx のビルド方法を設定する

Terminalメニューの「Configure Default Build Task...」を選択した後に、「C/C++:gcc build active file」を選択します。

task.json
{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "C/C++: gcc build active file",
            "command": "/usr/bin/make",
            "args": [           
                "install"
            ],
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

Terminalメニューの「Run Build Task...」からビルドできることを確認してください。ビルド後、nginx が /home/azureuser/nginx-1.19.2/nginx にインストールされます。

5.4. nginx のデバッグ方法を設定する

/home/azureuser/nginx-1.19.2/src/core/nginx.c を選択した後に、Terminalメニューから「Add Configuration...」を選択し、「C++(GDB/LLDB)」を選択し、「gcc - Build and debug active file」を選択してデバッグ方法を設定します。nginx はデーモンで動かさないようにオプションを設定しています。あと、stopAtEntry を true にして、実行時にステップ実行できるように設定しています。

launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "gcc - Build and debug active file",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/nginx/sbin/nginx",
            "args": ["-g", "daemon off;"],
            "stopAtEntry": true,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: gcc build active file",
            "miDebuggerPath": "/usr/bin/gdb"
        }
    ]
}

5.5. nginx の動作を確認する

デバッグ実行する前に、Azure Virtual Machine の Inbound security rule で 8080ポートが許可されていることを確認してください。
image.png

Terminalから、nginx をインストールして実行してみます。

cd ~/nginx-1.19.2/
make install
./nginx/sbin/nginx -g "daemon off;"

Webブラウザで、Azure Virtual Machine の パブリックIPアドレス 8080ポートにアクセスして nginx が動いていることを確認します。確認したら Ctl-c で終了してください。

image.png

5.6. nginx をリモートデバッグする

/home/azureuser/nginx-1.19.2/src/core/nginx.c を選択した状態で、F5を押すか、Runメニューから「Start Debugging」を選択して、nginx をデバッグ実行します。

image.png

デバッグできますね！

試しに、Webブラウザからリクエストを待っている直後の箇所にブレイクポイントを設定してみます。/home/azureuser/nginx-1.19.2/src/event/modules/ngx_epoll_module.c の 802行目あたりです。

800:    events = epoll_wait(ep, event_list, (int) nevents, timer);
801:
802:    err = (events == -1) ? ngx_errno : 0;

image.png

ここは nginx 起動後にworkerプロセス（子プロセス）として動く箇所なので、forkされる前にgdbで子プロセスにアタッチするように設定します。Visual Studio Code デバッグ実行中の DEBUG CONSOLEの一番下に gdb のコマンドを入力します。

-exec set follow-fork-mode child

image.png

あと、現在の状態を確認する場合は以下のようになります。

-exec show follow-fork-mode

gdbに設定したら、「Continue」（再生のような三角形のアイコン）で実行を続けます。
再度、Azure Virtual Machine の パブリックIPアドレス 8080ポートにアクセスすると、Webブラウザは待機状態になります。これは、Visual Studio Code(gdb) で設定したブレイクポイントで止まっているからです。

image.png

Visual Studio Codeで、epoll_wait から戻ってきた値を確認すると、1が入ってますね。ステップ実行もできます。素晴らしい！
(man epoll_wait : https://linuxjm.osdn.jp/html/LDP_man-pages/man2/epoll_wait.2.html)

image.png

あと、デバック開始時から follow-fork-mode を child にしたい場合は、以下のように setupCommands を設定しておいてください。

launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "gcc - Build and debug active file",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/nginx/sbin/nginx",
            "args": ["-g", "daemon off;"],
            "stopAtEntry": true,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set follow-fork-mode to child",
                    "text": "set follow-fork-mode child",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: gcc build active file",
            "miDebuggerPath": "/usr/bin/gdb"
        }
    ]
}

6. さいごに

Visual Studio Code と Azure Virtual Machine で Linux System Programing がより身近になりましたね。クラウドで動いている Linux をリモートデバッグできるなんて夢のようです。

サーバを書いてみたい人は是非チャレンジしてみてください。

ところで、TCP/UDP のサーバプログラム開発に関する書籍はたくさん出ておりますがエラー処理が足りなかったりする書籍が多いので、今から勉強する方のために、お勧めの書籍を紹介しておきます。

  • UNIXネットワークプログラミング〈Vol.1〉 W.Richard Stevens　（UNIXの教科書的な本ですが、中古しかないですね…。） https://amzn.to/335xUel

UNIXの基本的なコードを知った上で、Linuxでサーバで大量のクライアントを相手にする場合は、以下の書籍がお勧めです。

今回の記事のために nginx のコードを少し読みましたが、奇麗なのですごく勉強になりますね。

ではー。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T17:54:21+09:00

LPIC-1 取得までの道

初めに

以前に LPIC-1 を取得したので、その備忘録的なものを書いていこうと思います。

LPIC-1 取得以前の知識

期間的には、一か月ぐらいです。（101 に2週間, 102 に2週間という感じです）
Linux の基本的なコマンドは知っている状態でした。(cd, find, for, if, awk, sed など)
しかし、Linux のシステムやストレージ関連、セキュリティなどはほとんど知らない状態で、そうなんだと思うことが多々ありました。

例）ssh で接続はできるけど、ssh-agent とかの仕組みなんて知らなかった。(ファイルの存在とかも)
　　dig コマンドの名前は知ってるけど、実際に打つようなことはしていなかった。（nslookup 使ってた）

勉強に使ったもの

LPICレベル１　スピードマスター問題集 versiono 5.0 --> 基本的にはこれで勉強
Ping-t(webサイト) --> 仕上げに利用
※　Ping-t の102の過去問は有料なので、お金を支払ってもいいと思う人は使用してください。

実際の勉強の流れ

1週間　問題集
その後、1週間 ping-t と スピードマスターの模擬試験をひたすらやる

上記の流れでひたすら、解きまくっていました。
Ping-t とかは全部金にしてから受験したほうがいいと思いますが、自分は時間がなかったため、模擬試験の部分で80% ぐらいを連発できるようになった時点で受験しました。

落ちるリスクを回避するには、金にするのがいいと思います。

まとめ

すごく簡単になってしまい、すみません。
資格を取るという意味では、これで十分だと思います。（実務で使えるようにはならないですが、言葉を知っていると困ったときに調べやすかったりするので、資格取得はそういう意味ではいいかもしれないです。）

上位資格については、また書きたいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T17:24:29+09:00

docker run --help 日本語訳

docker run --help 実行時に表示されるドキュメントの日本語訳。

使用法:

docker run [OPTIONS] IMAGE [COMMAND] [ARG ...]

新しいコンテナでコマンドを実行する

オプション:

  • --add-host list カスタムのホストから IP へのマッピングを追加します( host:ip )
  • -a, -attach list STDIN, STDOUT, または STDERR に接続
  • --blkio-weight uint16 ブロック IO(相対重み)、10 から 1000、または無効にする場合は 0(デフォルトは 0)
  • --blkio-weight-device list ブロック IO の重み(デバイスの相対的な重み)(デフォルトは [] )
  • --cap-add list Linux 機能を追加する
  • --cap-drop list Linux 機能の削除
  • --cgroup-parent string コンテナーのオプションの親 cgroup
  • --cidfile string コンテナ ID をファイルに書き込みます
  • --cpu-period int CPU CFS(Completely Fair Scheduler)期間の制限
  • --cpu-quota int CPU CFS(Completely Fair Scheduler)の割り当てを制限する
  • --cpu-rt-period int CPU のリアルタイム期間をマイクロ秒で制限する
  • --cpu-rt-runtime int CPU リアルタイムランタイムをマイクロ秒単位で制限する
  • -c, -cpu-shares int CPU シェア(相対ウェイト)
  • --cpus decimal CPU の数
  • --cpuset-cpus string 実行を許可するCPU(0-3, 0, 1)
  • --cpuset-mems string 実行を許可する MEM(0-3, 0, 1)
  • -d, -detach コンテナーをバックグラウンドで実行し、コンテナー ID を表示する
  • --detach-keys string コンテナーを切り離すためのキーシーケンスをオーバーライドする
  • --device list コンテナにホストデバイスを追加する
  • --device-cgroup-rule list ルールを cgroup 許可デバイスリストに追加します
  • --device-read-bps list デバイスからの読み取り速度(1 秒あたりのバイト数)を制限します(デフォルトは [] )
  • --device-read-iops list デバイスからの読み取り速度(1 秒あたりの IO)を制限する(デフォルトは [] )
  • --device-write-bps list デバイスへの書き込み速度(1 秒あたりのバイト数)を制限します(デフォルトは [] )
  • --device-write-iops list デバイスへの書き込み速度(1 秒あたりの IO)を制限します(デフォルトは [] )
  • --disable-content-trust 画像検証をスキップ(デフォルトは true)
  • --dns list カスタム DNS サーバーを設定する
  • --dns-option list DNS オプションを設定する
  • --dns-search list カスタム DNS 検索ドメインを設定する
  • --domainname string コンテナ NIS メイン名
  • --entrypoint string イメージのデフォルト ENTRYPOINT を上書きする
  • -e, -env list 環境変数を設定する
  • --env-file list 環境変数のファイルを読み込む
  • --expose list ポートまたはポートの範囲を公開する
  • --gpus gpu-request コンテナーに追加する GPU デバイス(すべての GPU を渡すには all )
  • --group-add list 参加するグループをさらに追加
  • --health-cmd string コンテナの健常性をチェックするために実行するコマンド
  • --health-interval duration チェックの実行間隔( ms | s | m | h )(デフォルトは 0s )
  • --health-retries int 異常を報告するために必要な連続失敗数を指定する
  • --health-start-period duration health-retries のカウントダウン( ms | s | m | h )を開始する前にコンテナを初期化する開始期間(デフォルトは 0s )
  • --health-timeout duration 1 つのチェックの実行を許可する最大時間( ms | s | m | h )(デフォルトは 0s )
  • --help 使用法を表示する。
  • -h, --hostname string コンテナのホスト名
  • --init シグナルを転送し、プロセスを取得するコンテナ内で初期化を実行します
  • -i, -interactive 接続されていなくても STDIN を開いたままにします
  • --ip string IPv4 アドレス(172.30.100.104 など)
  • --ip6 string IPv6 アドレス(例: 2001:db8::33)
  • --ipc string 使用する IPC モード
  • --isolation string コンテナ隔離技術
  • --kernel-memory bytes カーネルメモリ制限
  • -l, --label list コンテナにメタデータを設定する
  • --label-file list ファイルからラベルの一覧を読み取る。 ラベルの一覧は行区切りで記述する。
  • --link list 別のコンテナへのリンクを追加
  • --link-local-ip list コンテナ IPv4 / IPv6 リンクローカルアドレス
  • --log-driver string コンテナーのロギングドライバー
  • --log-opt list ログドライバーオプション
  • --mac-address string コンテナの MAC アドレス(例: 92:d0:c6:0a:29:33)
  • -m, --memory bytes メモリ制限
  • --memory-reservation bytes メモリのソフト制限
  • --memory-swap bytes スワップ制限はメモリ + スワップに等しい: -1 は無制限のスワップを有効にします
  • --memory-swappiness int コンテナメモリの swappiness を調整する(0 から 100)(デフォルトは -1)
  • --mount mount コンテナーにファイルシステムのマウントを追加します
  • --name string コンテナーに名前を割り当てる
  • --network network コンテナーをネットワークに接続する
  • --network-alias list コンテナーのネットワークスコープのエイリアスを追加する
  • --no-healthcheck コンテナ指定のヘルスチェックを無効にする
  • --oom-kill-disable OOM キラーを無効にする
  • --oom-score-adj int ホストの OOM 設定を調整する(-1000 から 1000)
  • --pid string 使用する PID 名前空間
  • --pids-limit int コンテナー PID の制限を調整する(無制限の場合は -1 に設定)
  • --platform string サーバーがマルチプラットフォーム対応の場合はプラットフォームを設定する
  • --privileged コンテナに拡張特権を与える
  • -p, --publish list コンテナのポートをホストに公開する
  • -P, --publish-all 公開されているすべてのポートをランダムなポートに公開する
  • --read-only コンテナーのルートファイルシステムを読み取り専用としてマウントする
  • --restart string コンテナの終了時に適用する再起動ポリシー(デフォルトは no )
  • --rm 終了時にコンテナを自動的に削除します
  • --runtime string コンテナに使用するランタイム
  • --security-opt list セキュリティオプション
  • --shm-size bytes /dev/shm のサイズ
  • --sig-proxy プロセスへのプロキシ受信シグナル(デフォルトは true)
  • --stop-signal string コンテナーを停止する信号(デフォルトは 15 )
  • --stop-timeout int コンテナーを停止するタイムアウト期間(秒単位)
  • --storage-opt list コンテナーのストレージドライバーオプション
  • --sysctlマップ Sysctl オプション(デフォルトのマップ [])
  • --tmpfs list tmpfs ディレクトリをマウントする
  • -t, --tty 疑似 TTY を割り当てる
  • --ulimit ulimit Ulimit オプション(デフォルト [])
  • -u, -user string ユーザー名または UID(形式: : <name|uid>[:<group|gid>] )
  • --userns string 使用するユーザー名前空間
  • --uts string 使用する UTS 名前空間
  • -v, --volume list ボリュームをバインドマウントする
  • --volume-driver string コンテナーのオプションのボリュームドライバー
  • --volumes-from list 指定されたコンテナからボリュームをマウントします
  • -w, --workdir string コンテナ内の作業ディレクトリ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T16:35:14+09:00

Ubuntu のターミナルをかっこよく

つい最近、以下のような記事を見つけました。
Bashのプロンプトを超絶おしゃれにする Starship を紹介

ターミナルのカスタマイズは一度は誰でもやることでしょう。
僕は普段Ubuntuを使っているのですが、上の記事ではMacで環境構築を行っているようでした。
Ubuntuに導入する記事が見当たらなかったので書こうと思います。

目次

  • Rustのインストール
  • Starshipの導入

Rustのインストール

Ubuntu環境へのRustのインストールはここを参考にしました。
インストール、パスの設定を行ったあと、実行確認を行いました。
パスの設定にある以下のコマンドは.bashrcに追記しておくといいでしょう

$ source $HOME/.cargo/env

Starshipの導入

Rustの環境導入が出来たらあとは簡単です。
まず公式ページに従い、Starshipをインストール。

$ cargo install starship

次にinit scriptをshellのconfig fileに追記。
僕は普段bashを使っているので、.bashrcに以下を追記。

eval "$(starship init bash)"

これで環境構築は終了です。
あとはここを参考にしながら自分好みにカスタマイズしましょう！

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

yumで、Cannot retrieve metalink for repository エラーが出た時の対処

エラー内容

yum コマンドが、metalink エラーで動作しなくなった時の対処

yum repolist all などと入力すると、下記のエラーが出るようになった。

Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and try again

対処方法

epelリポジトリへのmetalinkでの接続ができないのが原因なので
以下のファイルのbaseurlのコメントを外して、
metalink設定をコメントアウトする

/etc/yum.repos.d/epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch

[epel-debuginfo]、[epel-source]にも同様の設定があるので同様に修正する。

サーバーを初期化後にこのエラーが出たので、証明書関連の設定が影響した
可能性があるがこれでyumが動作するようになった。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T09:27:22+09:00

Linuxを初めてみよう

Linuxはどこでも使える技術だし、エンジニアの基礎力上がるって聞いて、Linux初めてみました。
はじめた流れ、最初にやったこと紹介します。
何からしたらいいか分からない人の参考になればいいなと思います。

仮想マシンにLinuxを入れてみた

以下の記事を参考に、仮想マシンにLinuxを入れてみました。
https://qiita.com/miyase256/items/b44a89eb636d16de010c
VirtualBoxにUbuntuで行っています。

やり直せるので、仮想マシンやLinuxディストリビューションの種類選びに時間かけなくて大丈夫です。
（僕はかけてしまったのですが、結局よくわからずこの記事参考にしました）
この記事だけでLinux扱う準備ができます。
(isoのダウンロードはリンククリックしてoption2 -> option3 って進むとダウンロードあります)

インストールバトルのところは出てくる項目とか順番とかが記事と違って、適当にやってしまったところもあります。
仮想マシンなので、Windows本体へ影響ないですし、失敗したらやり直せるので気楽にやるといいと思います。

仮想マシンは、ザックリ言うと
他の普通のアプリみたいに起動して使えて、起動したらそこでLinuxとか使えます。
作った仮想環境の削除もできるみたいなので
とにかく一回いろいろ触ってみるつもりで、初めは進めていきましょう！！

環境構築できたら、次にこんなことしてみました。

ファイルサーバー構築してみた

https://qiita.com/toki_k/items/f805421f809c67d0c92b

Webサーバー構築してみた

https://qiita.com/toki_k/items/19ec98080ae6081e4fa8

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T00:13:54+09:00

Instance Metadata Service Version 2 (IMDSv2)：インスタンスメタデータサービスv2の設定と挙動確認

Instance Metadata Service Version 2 (IMDSv2)：インスタンスメタデータサービスv2の設定と挙動確認の作業メモ

本記事の内容

  1. Instance Metadataとは
  2. Instance Metadata Service Version 2 を使う理由
  3. AWS-CLI実行環境準備
  4. 既存インスタンスのIMDSv2強制設定
  5. IMDSv2強制設定時の挙動確認

1. Instance Metadataとは

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

インスタンスメタデータは、インスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用します。インスタンスメタデータは、ホスト名、イベント、およびセキュリティグループなどのカテゴリに分けられます。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

次のいずれかのメソッドを使って、実行中のインスタンスからインスタンスメタデータにアクセスできます。

  • インスタンスメタデータサービスバージョン 1 (IMDSv1) – リクエスト/レスポンスメソッド
  • インスタンスメタデータサービスバージョン 2 (IMDSv2) – セッション志向メソッド

インスタンスメタデータサービスバージョン 2 の仕組み

IMDSv2は、セッション志向リクエストを使用します。セッション志向リクエストを使用して、セッション期間 (1 秒～6 時間) を定義するセッショントークンを作成します。指定した期間中、それ以降のリクエストに同じセッショントークンを使用できます。指定した期間が期限切れになった後、将来のリクエストに使用する新しいセッショントークンを作成する必要があります。

2. Instance Metadata Service Version 2 を使う理由

2019年7月29、米金融大手のCapital Oneにて不正アクセスにより、1億人以上の個人情報が漏洩。

Information on the Capital One Cyber Incident
https://www.capitalone.com/facts2019/

情報漏洩の原因は以下の通り

  • 攻撃者がWAFを経由してEC2のインスタンスメタデータにアクセスし、IAM Roleの認証情報(S3へのアクセス)を取得。
  • IMDSv1は、メタデータへの接続に認証は行われない。
  • 取得したIAM Roleの認証情報を利用し、Capital OneのS3にアクセスし、情報を取得。

一方、IMDSv2は、メタデータへのアクセスに、事前に取得したTokenを必須とする。
IMDSv2の使い方と、セキュリティ面でのメリットは以下の通り。

使い方
  • PUTリクエストを使って、6 時間 (21,600 秒) のセッショントークンを作成する
  • セッショントークンヘッダーをTOKENという名前の変数に保管する
  • トークンを使って最上位メタデータアイテムをリクエストする
メリット
  • ほとんどのWAFはPUTリクエストを許容していない為、WAFを経由した外部からのアクセスが成功する可能性が低い。
  • メタデータレスポンスのホップリミットを短くし複数ホストを経由した取得を防止できる。(1に設定すれば、CapitalOneで発生したような、WAFを経由したメタデータ取得を阻止できる)
  • PUTリクエストは、X-Forwarded-Forヘッダーが含まれている場合、拒否する。(プロキシサーバでは、通常X-Forwarded-Forヘッダーを付与する)

3. AWS-CLI実行環境準備

インスタンス構築/設定変更のコマンドを発行するためのAWS-CLI実行用インスタンス(cli_instance)を準備

cli_instance環境(AWS-CLI発行元環境情報)
[root@ip-10-0-0-74 ~]# cat /etc/system-release
Amazon Linux release 2 (Karoo)
[root@ip-10-0-0-74 ~]# 
[root@ip-10-0-0-74 ~]# uname -a
Linux ip-10-0-0-74.ap-northeast-1.compute.internal 4.14.193-149.317.amzn2.x86_64 #1 SMP Thu Sep 3 19:04:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@ip-10-0-0-74 ~]# 
[root@ip-10-0-0-74 ~]# aws --version 
aws-cli/1.18.107 Python/2.7.18 Linux/4.14.193-149.317.amzn2.x86_64 botocore/1.17.31
[root@ip-10-0-0-74 ~]# 
[root@ip-10-0-0-74 ~]# curl http://169.254.169.254/latest/meta-data/instance-type/
t3.small
[root@ip-10-0-0-74 ~]#

IMDSv2稼働確認用インスタンス「test_instance」構築

cli_instance環境(run-instances実行)
[root@ip-10-0-0-74 ~]# aws ec2 run-instances \
> --image-id ami-0ce107ae7af2e92b5 \
> --instance-type t2.nano \
> --key-name key_file \
> --monitoring Enabled=false \
> --placement AvailabilityZone=ap-northeast-1a \
> --subnet-id subnet-03d74b8d6ab6c39f2 \
> --associate-public-ip-address \
> --security-group-ids sg-0a00ecb871bb15fb3 \
> --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=test_instance}]'

構築したインスタンス(test_instance)デフォルトのインスタンスメタデータ設定の確認

cli_instance環境(describe-instances実行)
[root@ip-10-0-0-74 ~]# aws ec2 describe-instances \
> --filters "Name=tag:Name,Values=test_instance" \
> --query Reservations[*].Instances[*].[MetadataOptions]
[
    [
        [
            {
                "State": "applied", 
                "HttpEndpoint": "enabled", 
                "HttpTokens": "optional", 
                "HttpPutResponseHopLimit": 1
            }
        ]
    ]
]
[root@ip-10-0-0-74 ~]#

"HttpTokens": "optional" -> IMDSv1/IMDSv2が両方利用可能
"HttpTokens": "required" -> IMDSv2のみ利用可能(IMDSv2の強制化)

"HttpTokens": "optional"状態での挙動確認(IMDSv1/IMDSv2が両方利用可能)

以下は新規に構築した「test_instance」環境上で実行

test_instance環境（IMDSv1実行）
[root@ip-10-0-0-68 ~]# curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
[root@ip-10-0-0-68 ~]#
test_instance環境（IMDSv2実行）
[root@ip-10-0-0-68 ~]# TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    56  100    56    0     0   9333      0 --:--:-- --:--:-- --:--:-- 11200
*   Trying 169.254.169.254...
* TCP_NODELAY set
* Connected to 169.254.169.254 (169.254.169.254) port 80 (#0)
> GET /latest/meta-data/ HTTP/1.1
> Host: 169.254.169.254
> User-Agent: curl/7.61.1
> Accept: */*
> X-aws-ec2-metadata-token: AQAAAO6n081baEIWdrfpILhc9Egt4kTm0HSpUftcYqvJSR-NKewL6A==
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Accept-Ranges: bytes
< Content-Length: 313
< Content-Type: text/plain
< Date: Sat, 26 Sep 2020 14:45:29 GMT
< Last-Modified: Sat, 26 Sep 2020 14:28:58 GMT
< X-Aws-Ec2-Metadata-Token-Ttl-Seconds: 21600
< Connection: close
< Server: EC2ws
< 
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
* Closing connection 0
services/
[root@ip-10-0-0-68 ~]#

4. 既存インスタンスのIMDSv2強制設定

以下はAWS-CLI実行環境「cli_instance」環境上で実行

cli_instance環境
[root@ip-10-0-0-74 ~]# # test_instanceのインスタンスID取得
[root@ip-10-0-0-74 ~]# aws ec2 describe-instances \
> --filters "Name=tag:Name,Values=test_instance" \
> --query Reservations[*].Instances[*].[InstanceId]
[
    [
        [
            "i-034109c70aaa4b055"
        ]
    ]
]
[root@ip-10-0-0-74 ~]# 
[root@ip-10-0-0-74 ~]# # IMDSv2強制設定の実行("HttpTokens": "required")
[root@ip-10-0-0-74 ~]# aws ec2 modify-instance-metadata-options \
> --instance-id i-034109c70aaa4b055 \
> --http-tokens required \
> --http-put-response-hop-limit 1 \
> --http-endpoint enabled
{
    "InstanceId": "i-034109c70aaa4b055", 
    "InstanceMetadataOptions": {
        "State": "pending", 
        "HttpEndpoint": "enabled", 
        "HttpTokens": "required", 
        "HttpPutResponseHopLimit": 1
    }
}
[root@ip-10-0-0-74 ~]#

5. IMDSv2強制設定時の挙動確認

"HttpTokens": "required"状態での挙動確認(IMDSv2のみ利用可能(IMDSv2の強制化))

以下は新規に構築した「test_instance」環境上で実行

test_instance環境（IMDSv1実行）
[root@ip-10-0-0-68 ~]# curl http://169.254.169.254/latest/meta-data/
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>401 - Unauthorized</title>
 </head>
 <body>
  <h1>401 - Unauthorized</h1>
 </body>
</html>
[root@ip-10-0-0-68 ~]#

IMDSv2強制化されているため、IMDSv1の方法では取得できない

test_instance環境（IMDSv2実行）
[root@ip-10-0-0-68 ~]# TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    56  100    56    0     0   9333      0 --:--:-- --:--:-- --:--:-- 11200
*   Trying 169.254.169.254...
* TCP_NODELAY set
* Connected to 169.254.169.254 (169.254.169.254) port 80 (#0)
> GET /latest/meta-data/ HTTP/1.1
> Host: 169.254.169.254
> User-Agent: curl/7.61.1
> Accept: */*
> X-aws-ec2-metadata-token: AQAAAO6n081aj7u-yzdFHoD8zll2ZKiNfVS79OXp1qJDwgzw7-96gA==
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Accept-Ranges: bytes
< Content-Length: 313
< Content-Type: text/plain
< Date: Sat, 26 Sep 2020 15:01:45 GMT
< Last-Modified: Sat, 26 Sep 2020 14:28:58 GMT
< X-Aws-Ec2-Metadata-Token-Ttl-Seconds: 21600
< Connection: close
< Server: EC2ws
< 
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
* Closing connection 0
services/
[root@ip-10-0-0-68 ~]#
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T00:06:06+09:00

LinuxWebサーバー構築（Ubuntu & Apache）

Windowsにvirtualboxを使ってLinux(Ubuntu20.04.1)を入れて、ファイルサーバ構築をしてみたので、次はWebサーバー構築をしてみました。のメモです。

ファイルサーバー構築↓
https://qiita.com/toki_k/items/f805421f809c67d0c92b

ファイアウォールのインストール

$ sudo apt install ufw

まずは、インストールします。

ファイアウォールの設定

次に、ファイアウォールの設定をします。

$ sudo ufw allow 22
$ sudo ufw allow 80

ポート+22 、 ポート+80 の全ての接続が許可されます。
22 はsshを許可します
80 はhttpの許可のためです。apacheが使用します

※前回のファイルサーバの接続もできなくなったので、以下のようにすることで再びファイルにアクセスできます

$ sudo ufw allow samba

許可しているもの等、状態の確認はこちら↓
一覧で見れます。

$ sudo ufw status

Apacheのインストール

Apatchをインストールします。

$ sudo apt install apache2

ページにアクセスしてみる

インストールまで成功していれば、ブラウザからアクセスできるはずです。

$ hostname

サーバー名を確認します。

ブラウザを開き、「http://（ホストネーム）」で初期設定されているページにアクセスできます。
（サーバー名）にはhostnameで確認した値を入れてください。

Apacheが表示してくれるページは「 /var/www/html/」の様です。ドキュメントルートと呼ぶみたいです

自分でファイルを追加してアクセスする

$ cd /var/www/html
$ vim hello.html

cd でまず、ドキュメントルートに移動します。
vim を開いて、新規ファイルを作成します。

ブラウザで、「http://（ホストネーム）/hello.html」と入力します。
これで作成したページにアクセスすることができました！！

参考記事

https://qiita.com/sakkuntyo/items/03742bad0f57a4f46b07
https://qiita.com/moennig1997/items/65da2650583d3667342f

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

日付別

タグ一覧