20210124のLinuxに関する記事は10件です。

LinuxからAndroid(その逆も)へバックアップ

Alpineでも日本語入力Mozcが利用可能であることは確認できました。
現在は、Arch LinuxベースのManjaro Linux(xfce)に落ち着いています。
グラフィカルなインストーラー)(Calamares?)でインストール先のパーティションも手動で選べます。
日本語環境も整えやすいです。

個人的にはブラウザのfirefoxがあれば、Webは一通り見れるし、動画も再生できる。Webメールのgmailも見れる。
Yahooのニュースのライブ動画もUser Agent Switcherのアドオン入れて、Windowsと同じですよ宣言しておけば、再生できます。

バックアップに使うアプリ(ソフトウェア)は、
syncthing
を選択しました。P2Pらしい。

無料のクラウドストレージには限度がある。クラウドまでは必要ない。アクセスするのは重たいし。
バックアップも無意識にLinuxとAndroidで同期(Sync)してくれたら、助かる。そういったニーズのアプリです。
私の場合には、スマホに取り付けたSDカードにバックアップできればなぁというケース。
Windowsもあるようです。

バックアップで同期元(送信のみ)、同期先(受信のみ)も設定できて、ファイルのバージョンもとれるらしい。
そこまではチェックしてないけれど。
スマホでとった写真を、Wifiにつながったときに、自宅のPCと同期して、バックアップとる、という、私のケースの逆パターンでも、有効活用できると思います。
大きなストレージが不要なら、BOX,Dropbox,Google Driveで十分ではありますね。

ポイント!
外部SDカードで、受信も可能にする場合。
アプリに付与されるパーミッションの関係か、共有フォルダを
Android/data/com.nutomic.syncthingandroid/files
フォルダ以下に指定する必要がある。

パスが深くなるので、
ファイラーでホームディレクトリに設定できるものや、ホーム画面にショートカットを作れるタイプがあると便利でしょう。

ファイラーで、無料で広告無しで、良かったのは
DVファイルエクスプローラー(Dovi Tools)
ホーム画面にショートカットを作成でき、タップすると、DVファイルエクスプローラーがそのパスで立ち上がる。
ただ、レビューによるとAndroid10でSDへのアクセス権限付与でうまく動作しない場合があるらしい。

他には、最新バージョンはProが99円だが、
シンプルファイル管理(Simple Mobile Tools)は、ファイラーを立ち上げたときの初期パスを設定できるので、これでも良いかもしれない。
環境によって、エラーがあるようなので、Proを使うのが安心かもしれない。動作確認できるまでは、バックアップをとっときましょう。

Androidのファイルシステムではsymlinkはないので、同期元にシムリンクが含まれている場合、Androido側のsyncthingは未同期になります。
同期元でtarballを展開して、シムリンクが生成されたりすると、その部分で同期ができないので、未同期と表示されます。
イレギュラーなケースなので、まずないでしょうが、バックアップができてない、と焦らないようにしましょう。
最初に一通り動作チェックを行っていれば、多分、問題なく動いてくれるでしょう。
設定すれば、ファイルのバージョンまでとってくれるらしい。(履歴?)
初期設定でAndroidではオフになってましたので、設定して、テストしてみてください。
最初のチェックは特に大切(笑)

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

3週間くらい勉強してLPIC101合格した振り返り

はじめに

LPIC101を受けて合格したので振り返り書きます。102は来週受けます。

数名LPICについて記述している人が何人かいるのですが、自分とは難易度の感覚や対策方法が違うなと思いました。

正解は一つではないので、また別の1ケースとして参考にしてもらえればと思います。

LPIC101試験概要

  • 点数は200-800点
  • 合格点500点

試験結果

  • 570点 合格

私のスペック

文系からフルスタックエンジニア。キャリア4年。インフラは弱い。サーバーはKubernetesとかFirebaseとかCloud runとかつかって動かすのでよくわからんけど勝手にいい感じに動くものと認識している。

私の学習目的

  1. インフラ含めたアプリケーション全体の設計判断の不安をなくすため。
  2. 全く知らない分野を作らないようにしておくため

学習期間

3週間程度仕事の後とか土日に勉強してました。

最初はもっとコツコツ勉強する気でいたので3ヶ月後に試験を申し込んだのですが、101と102を合わせて2週間弱勉強した段階で、長い期間かけるよりも細かいオプションなどが記憶に残っているうちに短期で決着をつけるべきと判断しました。

101をその1週間後(2021/1/24日現在)に変更し、102はさらその1週間後に申し込みました。

学習方法

利用書籍

いわゆる小豆本とping-tを利用しました。

  • 小豆本: 王道の一冊。模擬試験つきの参考書。
  • ping-t: web問題集、豊富な解説付き。101は無料で102は有料。101のみ利用。

学習戦略

1.試験の概要を確認

まずは試験の合格基準を確認。

  • 200-800点
  • 60問
  • 1問の配点は不明
  • 噂では6割取ればいいらしい(試験終わってから50%の500点取ればいいと知る)
  • 90分
  • 試験場でWeb受験
  • 検索不可
  • 持ち物は全て会場のロッカーにあずけて受験
  • 顔写真つきの身分証と直筆つきの身分証の合計2枚必要
  • 101,102それぞれ15,000円

2.試験の傾向を確認

まず小豆本の模擬試験でのをさらっと眺めて以下の内容を確認

  • コマンドを記述する問題が出る
  • コマンドのオプションを選択する問題が出る
  • 設定ファイルの場所を選択する問題が出る
  • BIOSの説明などの理解を問う問題がでる
  • 重箱の隅を突くような問題もあるが基本的な問題が多数
  • 試験時間はすごく余る

3.方針立てる

  • 4割間(実際は5割だった)違えても多数を占める基本的な問題を解ければ受かるので重箱の隅を突くような問題はそこまで気にしないことに
  • 問題集を解いたところで理解は深まらないので小豆本を読みこむ方針に
  • ping-tは到達度の確認にたまに利用

4. 具体的な学習方法

  • 設定ファイル・オプション・正確なコマンドを覚えるように意識して小豆本を読み込んだ
  • オプションは何の英語の省略形なのかを確認して一発で覚えるようにした
  • コマンドは勘違いを防ぐために実際に打って結果をたしかめた
  • 設定ファイルは単に場所を知るだけでなく実際にその中身を読んで理解するなどすることで記憶に残した
  • BIOS, BUS, PCI, GRUBなど知らなかった単語が出たら必ず調べて理解した
  • 忘れそうなところは全てメモにとって、直前の見直しノートを作成した
  • 関連する用語・似たような概念・別の概念をカテゴライズしたり関連づけたり区別したり類似点を見つけたり連想したりして記憶に定着させた
  • 十分に理解したと思った段階で小豆本の模擬試験を利用し、勘違いや理解不足の部分を補強した

試験受ける直前

試験の3日前くらいには、どうやったら落ちるんだろうって思うくらい自信ありました。そのせいでちょっとだれたのですが、本番は想定とかなり違いました。本番の本当の難易度を知るのはとても重要ですね。

事後振り返り

出題された問題

出題範囲のテーマの隅々から出たように思います。覚えているものを羅列します。

  • GRUB2のインストールコマンド
  • GRUBの設定ファイル一式
  • GRUBの説明
  • mkfs
  • BIOS
  • XFS (問題多かった)
  • tarのtzvオプション
  • vimのコマンド(問題多かった)
  • ファイルストリーム: cat, cut, tr, wc etc
  • dmesg --clean
  • リダイレクトの構文(問題多かった)
  • yum, rpm, agt-get, rpkg (問題多かった)
  • /etc/ld.so.conf
  • mount関連(問題多かった) などなど。

知らない問題が沢山出た

大きな誤算として、小豆本に載ってない問題がが沢山でました。マニアックな問題が出たというよりは、書籍に載っていないけれどちゃんと利用しそうなオプションが沢山出たという印象です。

しかし、試験後LPICの試験のホームページを見たら、学習教材がありそちらに解説が書いてあるようでした。(https://learning.lpi.org/en/learning-materials/102-500/108/108.2/)

こちらを読んでいたら素直に点数が取れそうです。

重要度が低いところからも複数問題が出た

試験の項目ごとに重要度が公式に出ているのですが、重要度5段階中の2の分野や1の分野から3問以上問題がでるなどします。(GRUB関係など)。またvimのコマンドから多数の問題が出ました。山を貼るより穴がないように網羅的にやるのが良いと思います。

受けている時は落ちたと思った

あっているか確信がもてない問題が28問(40%以上)ありました。合格ボーダーが60%程度だと勘違いしていたのでやらかしたと思ったのですが、570点(61%)で合格でした。

合格基準がゆるいので大丈夫

90%以上とって合格とかは相当対策しないと難しいと思いますが、30問近く自信のない問題があっても合格できるので合格自体は簡単かと思います。あくまで完璧を目ざすのでなく合格基準をゴールに見据えることが重要だと思います。

ちなみに小豆本の模擬試験では90%以上軽くとれていたので、小豆本の模擬試験で60%を目指すだと思っていると死ぬと思います。その点はご注意を。

LPIC-102に向けて

小豆本を完璧に理解していたとしてもどうしようもないような問題を取りこぼさなければもっと安定するので、公式の学習教材を追加で利用して勉強してみます。

やり直すなら

  • 101と102は完全に分けて学習する。
  • 学習期間は片方最大2週間にし、試験直前に記憶とモチベがピークになるように調整する。
  • 公式の教材をちゃんとみる
  • 他は同じことを繰り返す

結果よかった?

受けてよかったです。

まず設定ファイルやオプションの暗記など無駄も多いのですが、理解して覚えたおかげでどこの何のファイルを見れば、何が設定されていてどういうログが見れるのかがわかったのが非常によいです。

またハードウェア関連の用語がしれたのもとてもよかったです。BIOS, カーネルモジュール, BUS, PCIデバイス, マザーボード, ATA などなど。

LEVEL2は受ける?

受けないと思います。Linuxを沢山触るエンジニアではないので、LEVEL2以降の内容は軽く概要を理解しておく程度で十分かなと思っています。

最後に

102も取りこぼさ無いようにがんばります。結果がでたら追記します。

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

3週間でLPIC101合格した振り返り

はじめに

LPIC101を受けて合格したので振り返り書きます。102は来週受けます。

数名LPICについて記述している人が何人かいるのですが、自分とは難易度の感覚や対策方法が違うなと思いました。

正解は一つではないので、また別の1ケースとして参考にしてもらえればと思います。

LPIC101試験概要

  • 点数は200-800点
  • 合格点500点

試験結果

  • 570点 合格

私のスペック

文系からフルスタックエンジニア。キャリア4年。インフラは弱い。サーバーはKubernetesとかFirebaseとかCloud runとかつかって動かすのでよくわからんけど勝手にいい感じに動くものと認識している。

私の学習目的

  1. インフラ含めたアプリケーション全体の設計判断の不安をなくすため。
  2. 全く知らない分野を作らないようにしておくため

学習期間

3週間程度仕事の後とか土日に勉強してました。

最初はもっとコツコツ勉強する気でいたので3ヶ月後に試験を申し込んだのですが、101と102を合わせて2週間弱勉強した段階で、長い期間かけるよりも細かいオプションなどが記憶に残っているうちに短期で決着をつけるべきと判断しました。

101をその1週間後(2021/1/24日現在)に変更し、102はさらその1週間後に申し込みました。

学習方法

利用書籍

いわゆる小豆本とping-tを利用しました。

  • 小豆本: 王道の一冊。模擬試験つきの参考書。
  • ping-t: web問題集、豊富な解説付き。101は無料で102は有料。101のみ利用。

学習戦略

1.試験の概要を確認

まずは試験の合格基準を確認。

  • 200-800点
  • 60問
  • 1問の配点は不明
  • 噂では6割取ればいいらしい(試験終わってから50%の500点取ればいいと知る)
  • 90分
  • 試験場でWeb受験
  • 検索不可
  • 持ち物は全て会場のロッカーにあずけて受験
  • 顔写真つきの身分証と直筆つきの身分証の合計2枚必要
  • 101,102それぞれ15,000円

2.試験の傾向を確認

まず小豆本の模擬試験でのをさらっと眺めて以下の内容を確認

  • コマンドを記述する問題が出る
  • コマンドのオプションを選択する問題が出る
  • 設定ファイルの場所を選択する問題が出る
  • BIOSの説明などの理解を問う問題がでる
  • 重箱の隅を突くような問題もあるが基本的な問題が多数
  • 試験時間はすごく余る

3.方針立てる

  • 4割間(実際は5割だった)違えても多数を占める基本的な問題を解ければ受かるので重箱の隅を突くような問題はそこまで気にしないことに
  • 問題集を解いたところで理解は深まらないので小豆本を読みこむ方針に
  • ping-tは到達度の確認にたまに利用

4. 具体的な学習方法

  • 設定ファイル・オプション・正確なコマンドを覚えるように意識して小豆本を読み込んだ
  • オプションは何の英語の省略形なのかを確認して一発で覚えるようにした
  • コマンドは勘違いを防ぐために実際に打って結果をたしかめた
  • 設定ファイルは単に場所を知るだけでなく実際にその中身を読んで理解するなどすることで記憶に残した
  • BIOS, BUS, PCI, GRUBなど知らなかった単語が出たら必ず調べて理解した
  • 忘れそうなところは全てメモにとって、直前の見直しノートを作成した
  • 関連する用語・似たような概念・別の概念をカテゴライズしたり関連づけたり区別したり類似点を見つけたり連想したりして記憶に定着させた
  • 十分に理解したと思った段階で小豆本の模擬試験を利用し、勘違いや理解不足の部分を補強した

試験受ける直前

試験の3日前くらいには、どうやったら落ちるんだろうって思うくらい自信ありました。そのせいでちょっとだれたのですが、本番は想定とかなり違いました。本番の本当の難易度を知るのはとても重要ですね。

事後振り返り

出題された問題

出題範囲のテーマの隅々から出たように思います。覚えているものを羅列します。

  • GRUB2のインストールコマンド
  • GRUBの設定ファイル一式
  • GRUBの説明
  • mkfs
  • BIOS
  • XFS (問題多かった)
  • tarのtzvオプション
  • vimのコマンド(問題多かった)
  • ファイルストリーム: cat, cut, tr, wc etc
  • dmesg --clean
  • リダイレクトの構文(問題多かった)
  • yum, rpm, agt-get, rpkg (問題多かった)
  • /etc/ld.so.conf
  • mount関連(問題多かった)
  • 複数選択は2個の選択のみで、3個以上はなかった
  • 記述問題はオプション無しのものみであった
  • 複数行にまたがる記述はなかった
  • 設定ファイルに書くべき文を記述する問題はなかった などなど。

知らない問題が沢山出た

大きな誤算として、小豆本に載ってない問題がが沢山でました。マニアックな問題が出たというよりは、書籍に載っていないけれどちゃんと利用しそうなオプションが沢山出たという印象です。

しかし、試験後LPICの試験のホームページを見たら、学習教材がありそちらに解説が書いてあるようでした。(https://learning.lpi.org/en/learning-materials/102-500/108/108.2/)

こちらを読んでいたら素直に点数が取れそうです。

重要度が低いところからも複数問題が出た

試験の項目ごとに重要度が公式に出ているのですが、重要度5段階中の2の分野や1の分野から3問以上問題がでるなどします。(GRUB関係など)。またvimのコマンドから多数の問題が出ました。山を貼るより穴がないように網羅的にやるのが良いと思います。

受けている時は落ちたと思った

あっているか確信がもてない問題が28問(40%以上)ありました。合格ボーダーが60%程度だと勘違いしていたのでやらかしたと思ったのですが、570点(61%)で合格でした。

合格基準がゆるいので大丈夫

90%以上とって合格とかは相当対策しないと難しいと思いますが、30問近く自信のない問題があっても合格できるので合格自体は簡単かと思います。あくまで完璧を目ざすのでなく合格基準をゴールに見据えることが重要だと思います。

ちなみに小豆本の模擬試験では90%以上軽くとれていたので、小豆本の模擬試験で60%を目指すだと思っていると死ぬと思います。その点はご注意を。

LPIC-102に向けて

小豆本を完璧に理解していたとしてもどうしようもないような問題を取りこぼさなければもっと安定するので、公式の学習教材を追加で利用して勉強してみます。

やり直すなら

  • 101と102は完全に分けて学習する。
  • 学習期間は片方最大2週間にし、試験直前に記憶とモチベがピークになるように調整する。
  • 公式の教材をちゃんとみる
  • 他は同じことを繰り返す

結果よかった?

受けてよかったです。

まず設定ファイルやオプションの暗記など無駄も多いのですが、理解して覚えたおかげでどこの何のファイルを見れば、何が設定されていてどういうログが見れるのかがわかったのが非常によいです。

またハードウェア関連の用語がしれたのもとてもよかったです。BIOS, カーネルモジュール, BUS, PCIデバイス, マザーボード, ATA などなど。

LEVEL2は受ける?

受けないと思います。Linuxを沢山触るエンジニアではないので、LEVEL2以降の内容は軽く概要を理解しておく程度で十分かなと思っています。

最後に

102も取りこぼさ無いようにがんばります。結果がでたら追記します。

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

~/.ssh/config を使わずに複数の踏み台を経由して SSH 接続する

1. 概要

踏み台経由で SSH 接続する必要がある場合、~/.ssh/config に ProxyCommand を書くことがあると思います。
事情があって ~/.ssh/config を編集出来ない場合に ~/.ssh/config を使わずに ssh コマンドのオプションで直接 ProxyCommand を指定する方法を記載します。

2. 踏み台が1台のパターン

ホスト 秘密鍵 ユーザー hostname or ip
踏み台 ~/.ssh/humidai.key humidai_user humidai.xxxxx.jp
SSH接続したいサーバー ~/.ssh/dest.key dest_user 192.168.0.1
$ ssh -o ProxyCommand="ssh -i ~/.ssh/humidai.key -W %h:%p humidai_user@humidai.xxxxx.jp" -i ~/.ssh/dest.key dest_user@192.168.0.1

3. 踏み台が2台のパターン

ホスト 秘密鍵 ユーザー hostname or ip
踏み台の踏み台 ~/.ssh/humidai_2.key humidai_2_user humidai_2.xxxxx.jp
踏み台 ~/.ssh/humidai.key humidai_user humidai.xxxxx.jp
SSH接続したいサーバー ~/.ssh/dest.key dest_user 192.168.0.1
$ ssh -o ProxyCommand='ssh -o ProxyCommand="ssh -i ~/.ssh/humidai_2.key -W humidai.xxxxx.jp:22 humidai_2.xxxxx.jp" -i ~/.ssh/humidai.key -W %h:%p humidai.xxxxx.jp' -i ~/.ssh/dest.key dest_user@192.168.0.1
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[linux]duコマンドで「xxxにアクセスできません: そのようなファイルやディレクトリはありません」メッセージを出力しない方法

やりたいこと

du実行したときのこんなメッセージを消したい.(cronのエラー通知が届いてしまうので)

$ du /
du: `/proc/14537/task/14537/fd/3' にアクセスできません: そのようなファイルやディレクトリはありません
du: `/proc/14537/task/14537/fdinfo/3' にアクセスできません: そのようなファイルやディレクトリはありません
du: `/proc/14537/fd/4' にアクセスできません: そのようなファイルやディレクトリはありません
du: `/proc/14537/fdinfo/4' にアクセスできません: そのようなファイルやディレクトリはありません

ソリューション

grepでフィルタリングする。

du <option> <path> 2> >(grep -v '^du:.*アクセスできません' >&2)

英語メッセージ版

du 2> >(grep -v '^du: cannot \(access\|read\)' >&2)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ryzen CPUとWestern Digital製SSDの組み合わせでSSDが読み込めなくなる不具合を回避する

Ryzen CPUとWestern Digital製SSDの組み合わせでSSDが読み込めなくなることがある不具合があります。
ThinkPad T14 Gen1 (AMD) + WD SN550 1TBでの発生を確認しました。

下記のようなログが出力されます。

EXT4-fs error (device nvme0n1p1): ext4_find_entry:1463: inode #123456: comm Foobar: reading directory iblock 0

NVMeデバイスの省電力を制御するAPST(Autonomous Power State Transition)に起因する不具合のようです。

APSTを無効にする

管理者権限で /etc/default/grub をテキストエディタで開きます。

sudo nano /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=5500"
に書き換え、保存します。

管理者権限で update-grub コマンドを実行します。

sudo update-grub

Ubuntuを再起動します。
再起動後はSSDが読み込めなくなることがなくなります。

References

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

サーバーとクライアント

勉強の記録

サーバーとクライアント 1/24

勉強した内容

  • tmux コマンド サーバーとクライアントの両方を操作できるようになる
  • nc コマンド TCP UDPの読み書きを行う。(よくわからない!)
  • telnet コマンド リモートコンピューターにアクセスする。

何をベースに勉強してるか

内容の詳細

  • サーバーとクライアントの通信について。

わかったことについて

  • これってもしかしてHPやアプリにアクセスしたら、毎回同じ反応が返ってくるのと同じことなのだろうか?って思ってます

むずかしかったよ

  • しいて言うなら nc

次回やる予定のこと

  • 次回はHTTP通信についての授業だそうです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ProxyJumpで踏み台サーバーをジャンプ!任意のファイルを使ったsshコマンドしよう

なにこれ

最近こんな案件に当たりました

  • サーバーの種類がかなりの台数ある上に、踏み台経由じゃないとアクセスできない
  • 認証鍵もポートもユーザー名も全部バラバラ
  • 踏み台サーバーは定期的に再生成されIPがたまに変わる

・・・お堅い仕事は結構ですが、とにかくサーバーあたりの情報指定が多くssh/confignが汚染されるのが嫌なので、別ファイルを使ってsshを叩けるようにしたい!と思ったのですが、適当にProxyCommand書いてもssh: Could not resolve hostnameが出て詰まったので調査がてら勉強しなおしました。
sshの基本についてもついでに書くので、本題にしか興味がない人は本題まで飛ばしてください。

最近忙しすぎて年単位で記事書けてなかった&保守もできてなかったので、記事を書くリハビリを兼ねます

sshでサーバーにアクセス

単純にsshコマンドでアクセスする

まずは基本に立ち返って地道にsshします(本題以前の話です。興味ない人は飛ばしてください)
Portが2222が空いているIP192.168.0.1のサーバーにmochisunaという名前でアクセスしたい場合、

  1. 公開鍵/秘密鍵を生成(クソ雑ネームssh_my_key
    例:ssh-keygen -t ed25519 -C "hirokazu.maruta@gmail.com" -f ssh_my_key
  2. 接続先サーバー(192.168.0.1)の~/.ssh/authorized_keysに公開鍵を追記

を設定して以下のようなコマンドを打つことで、そのサーバーにアクセスすることができるようになります。

ssh -i ~/.ssh/ssh_my_key mochisuna@192.168.0.1 -p 2222

-iオプションはどの認証情報を使うか(≒どの鍵の情報を使うか)というもので、事前に提供した公開鍵に合致する秘密鍵を指定する必要があります。
ただ、ssh-add ~/.ssh/ssh_my_keyとかしてあげれば毎回 -i オプションを入れなくともアクセスできるようになります。
ここまでは基本。

では192.168.0.1はただの踏み台で、ここを経由して他のサーバーにアクセスしたい場合はどうしましょうか?

多くの場合は次のように ProxyComannd をかけてアクセスするでしょう(192.168.0.3にアクセスすることを仮定)

ssh -i ~/.ssh/ssh_my_key -o ProxyCommand='ssh -i ~/.ssh/ssh_my_key mochisuna@192.168.0.1 -p 2222 -W %h:%p' mochisuna@192.168.0.3

内容的には-oオプションで踏み台サーバーにsshするコマンドを実行してから改めて目的のサーバーを叩くというようなことをやっているというもので、記法に慣れれば難しくないし便利です。

ただこのケース「ちょっと目的のサーバーにアクセスする」くらいならいいんですが、アクセス先のサーバーが増えてくると、管理・タイピング共にとても大変になってきます。
そこで .ssh/config を活用してアクセスします。

~/.ssh/configをカスタマイズしてアクセスする

~/.ssh/configにサーバーの情報を記載することでアクセス先の管理を大幅に簡略化できます。

~/.ssh/config
Host step
  User         mochisuna
  HostName     192.168.0.1
  IdentityFile ~/.ssh/ssh_my_key
  Port         2222

Host web1
  User         mochisuna
  HostName     192.168.0.3
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh mochisuna@192.168.0.1 -p 2222 -W %h:%p

Host web2
  User         mochisuna
  HostName     192.168.0.5
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh mochisuna@192.168.0.1 -p 2222 -W %h:%p

このようにsshコマンドで記述するパラメータを構造体のような形で書いてあげることで、ssh web2のような簡単なコマンドだけでアクセスできるようになります。
自動的に定義したパラメータで置換してアクセスしてくれるわけですね。便利ー。

ただ、この書き方はあまり良くありません

例えば毎週stepサーバーのIPが変わるような仕組みが取られていると、毎回書き直すのに絶望することになります。・・・まぁそんな設定入れることはないだろうけど、要は起点のIPが変わると保守が大変ということです。

なので以下のように書き換えます。

~/.ssh/config
Host step
  User         mochisuna
  HostName     192.168.0.1
  IdentityFile ~/.ssh/ssh_my_key
  Port         2222

Host web1
  User         mochisuna
  HostName     192.168.0.3
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh step -W %h:%p

Host web2
  User         mochisuna
  HostName     192.168.0.5
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh step -p 2222 -W %h:%p

こうすればstepサーバーの内容をいい感じに補填してくれるようになるので、stepサーバーのIP設定を変えるだけでssh web2のでアクセスできるようになります。
超便利。

ただ、僕は複数のプロジェクトに関わっているため、全てのプロジェクト設定を~/.ssh/configに盲目的に入れていくと大変なことになります。
stepだけだと、どのプロジェクトのどこのサーバーに行くかわかったもんじゃないのです。
そこでssh_configというようなファイルをプロジェクト毎に定義します。
そしてssh -F sugoi-project/ssh_config web1のように指定してあげれば、任意の定義ファイルでアクセスができるようになる・・・ハズですが、実はそのままではやろうとすると ssh: Could not resolve hostname が出てアクセスできません。
ファイルの記載をさらに改造しましょう。

ProxyJumpを使って踏み台サーバー経由でアクセスする

本題です
~/.ssh/configの汚染を避けるためsugoi-projectプロジェクト配下のssh_configのというファイル(~/.ssh/configと同じ記法)を利用することを前提にします。
この時、HOSTの記載がProxyCommand ssh step -p 2222 -W %h:%p のように記載されていた場合ssh -F sugoi-project/ssh_config web1 のようにしても以下のようなエラーが出てアクセスできないかと思います。

$ ssh -F sugoi-project/ssh_config
ssh: Could not resolve hostname step: nodename nor servname provided, or not known
kex_exchange_identification: Connection closed by remote host

これはProxyCommandが実行される際にsshのプロセスには「sugoi-project/ssh_configファイルからサーバー設定を読み取った」という情報が渡されることがないため ~/.ssh/configの中からstepサーバー情報を探してしまうことが原因です。
そこでProxyJumpを利用した形に書き換えます(OpenSSH 7.3以降に限り)

Host step
  User         mochisuna
  HostName     192.168.0.1
  IdentityFile ~/.ssh/ssh_my_key
  Port         2222

Host web1
  User         mochisuna
  HostName     192.168.0.3
  IdentityFile ~/.ssh/ssh_my_key
  ProxyJump    step

Host web2
  User         mochisuna
  HostName     192.168.0.5
  IdentityFile ~/.ssh/ssh_my_key
  ProxyJump    step

このように定義してあげることでssh -F sugoi-project/ssh_config web2というような形でアクセスできるようになります。
僕はさらに手を抜いてsshcとかいう適当なコマンドでアクセスできる仕組みを作ってます
sshc ssh_configって打つだけでほぼ脳死でアクセスできるのでオススメです。

まとめ

  1. ssh-add 使うとsshコマンドの-iオプションを省略できるけど、それやるくらいなら.ssh/configを利用したほうが楽
  2. ProxyCommandを使うなら外部ファイルではなく~/.ssh/configで使う
  3. ProxyCommandProxyJumpは定義済のHost情報を利用できるのでIPとかはベタ書きしない
  4. ProxyJumpを使えば sshコマンドの-Fオプションでも定義済Host情報を使えるので便利

stackoverflowでもちょくちょく上がる内容ぽいので、知っておくと便利かもしれません。

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

ProxyJumpでhostnameを解決しながら踏み台サーバーをジャンプ

なにこれ

最近こんな案件に当たりました

  • サーバーの種類がかなりの台数ある上に、踏み台経由じゃないとアクセスできない
  • 認証鍵もポートもユーザー名も全部バラバラ
  • 踏み台サーバーは定期的に再生成されIPがたまに変わる

・・・お堅い仕事は結構ですが、とにかくサーバーあたりの情報指定が多くssh/confignが汚染されるのが嫌なので、別ファイルを使ってsshを叩けるようにしたい!と思ったのですが、適当にProxyCommand書いてもssh: Could not resolve hostnameが出て詰まったので調査がてら勉強しなおしました。
sshの基本についてもついでに書くので、本題にしか興味がない人は本題まで飛ばしてください。

最近忙しすぎて年単位で記事書けてなかった&保守もできてなかったので、記事を書くリハビリを兼ねます

sshでサーバーにアクセス

単純にsshコマンドでアクセスする

まずは基本に立ち返って地道にsshします(本題以前の話です。興味ない人は飛ばしてください)
Portが2222が空いているIP192.168.0.1のサーバーにmochisunaという名前でアクセスしたい場合、

  1. 公開鍵/秘密鍵を生成(クソ雑ネームssh_my_key
    例:ssh-keygen -t ed25519 -C "hirokazu.maruta@gmail.com" -f ssh_my_key
  2. 接続先サーバー(192.168.0.1)の~/.ssh/authorized_keysに公開鍵を追記

を設定して以下のようなコマンドを打つことで、そのサーバーにアクセスすることができるようになります。

ssh -i ~/.ssh/ssh_my_key mochisuna@192.168.0.1 -p 2222

-iオプションはどの認証情報を使うか(≒どの鍵の情報を使うか)というもので、事前に提供した公開鍵に合致する秘密鍵を指定する必要があります。
ただ、ssh-add ~/.ssh/ssh_my_keyとかしてあげれば毎回 -i オプションを入れなくともアクセスできるようになります。
ここまでは基本。

では192.168.0.1はただの踏み台で、ここを経由して他のサーバーにアクセスしたい場合はどうしましょうか?

多くの場合は次のように ProxyComannd をかけてアクセスするでしょう(192.168.0.3にアクセスすることを仮定)

ssh -i ~/.ssh/ssh_my_key -o ProxyCommand='ssh -i ~/.ssh/ssh_my_key mochisuna@192.168.0.1 -p 2222 -W %h:%p' mochisuna@192.168.0.3

内容的には-oオプションで踏み台サーバーにsshするコマンドを実行してから改めて目的のサーバーを叩くというようなことをやっているというもので、記法に慣れれば難しくないし便利です。

ただこのケース「ちょっと目的のサーバーにアクセスする」くらいならいいんですが、アクセス先のサーバーが増えてくると、管理・タイピング共にとても大変になってきます。
そこで .ssh/config を活用してアクセスします。

~/.ssh/configをカスタマイズしてアクセスする

~/.ssh/configにサーバーの情報を記載することでアクセス先の管理を大幅に簡略化できます。

~/.ssh/config
Host step
  User         mochisuna
  HostName     192.168.0.1
  IdentityFile ~/.ssh/ssh_my_key
  Port         2222

Host web1
  User         mochisuna
  HostName     192.168.0.3
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh mochisuna@192.168.0.1 -p 2222 -W %h:%p

Host web2
  User         mochisuna
  HostName     192.168.0.5
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh mochisuna@192.168.0.1 -p 2222 -W %h:%p

このようにsshコマンドで記述するパラメータを構造体のような形で書いてあげることで、ssh web2のような簡単なコマンドだけでアクセスできるようになります。
自動的に定義したパラメータで置換してアクセスしてくれるわけですね。便利ー。

ただ、この書き方はあまり良くありません

例えば毎週stepサーバーのIPが変わるような仕組みが取られていると、毎回書き直すのに絶望することになります。・・・まぁそんな設定入れることはないだろうけど、要は起点のIPが変わると保守が大変ということです。

なので以下のように書き換えます。

~/.ssh/config
Host step
  User         mochisuna
  HostName     192.168.0.1
  IdentityFile ~/.ssh/ssh_my_key
  Port         2222

Host web1
  User         mochisuna
  HostName     192.168.0.3
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh step -W %h:%p

Host web2
  User         mochisuna
  HostName     192.168.0.5
  IdentityFile ~/.ssh/ssh_my_key
  ProxyCommand ssh step -p 2222 -W %h:%p

こうすればstepサーバーの内容をいい感じに補填してくれるようになるので、stepサーバーのIP設定を変えるだけでssh web2のでアクセスできるようになります。
超便利。

ただ、僕は複数のプロジェクトに関わっているため、全てのプロジェクト設定を~/.ssh/configに盲目的に入れていくと大変なことになります。
stepだけだと、どのプロジェクトのどこのサーバーに行くかわかったもんじゃないのです。
そこでssh_configというようなファイルをプロジェクト毎に定義します。
そしてssh -F sugoi-project/ssh_config web1のように指定してあげれば、任意の定義ファイルでアクセスができるようになる・・・ハズですが、実はそのままではやろうとすると ssh: Could not resolve hostname が出てアクセスできません。
ファイルの記載をさらに改造しましょう。

ProxyJumpを使って踏み台サーバー経由でアクセスする

本題です
~/.ssh/configの汚染を避けるためsugoi-projectプロジェクト配下のssh_configのというファイル(~/.ssh/configと同じ記法)を利用することを前提にします。
この時、HOSTの記載がProxyCommand ssh step -p 2222 -W %h:%p のように記載されていた場合ssh -F sugoi-project/ssh_config web1 のようにしても以下のようなエラーが出てアクセスできないかと思います。

$ ssh -F sugoi-project/ssh_config
ssh: Could not resolve hostname step: nodename nor servname provided, or not known
kex_exchange_identification: Connection closed by remote host

これはProxyCommandが実行される際にsshのプロセスには「sugoi-project/ssh_configファイルからサーバー設定を読み取った」という情報が渡されることがないため ~/.ssh/configの中からstepサーバー情報を探してしまうことが原因です。
そこでProxyJumpを利用した形に書き換えます(OpenSSH 7.3以降に限り)

Host step
  User         mochisuna
  HostName     192.168.0.1
  IdentityFile ~/.ssh/ssh_my_key
  Port         2222

Host web1
  User         mochisuna
  HostName     192.168.0.3
  IdentityFile ~/.ssh/ssh_my_key
  ProxyJump    step

Host web2
  User         mochisuna
  HostName     192.168.0.5
  IdentityFile ~/.ssh/ssh_my_key
  ProxyJump    step

このように定義してあげることでssh -F sugoi-project/ssh_config web2というような形でアクセスできるようになります。
僕はさらに手を抜いてsshcとかいう適当なコマンドでアクセスできる仕組みを作ってます
sshc ssh_configって打つだけでほぼ脳死でアクセスできるのでオススメです。

まとめ

  1. ssh-add 使うとsshコマンドの-iオプションを省略できるけど、それやるくらいなら.ssh/configを利用したほうが楽
  2. ProxyCommandを使うなら外部ファイルではなく~/.ssh/configで使う
  3. ProxyCommandProxyJumpは定義済のHost情報を利用できるのでIPとかはベタ書きしない
  4. ProxyJumpを使えば sshコマンドの-Fオプションでも定義済Host情報を使えるので便利

stackoverflowでもちょくちょく上がる内容ぽいので、知っておくと便利かもしれません。

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

How to check log of specific service in Linux

List units and see log of units.

When you have some trouble in http, you want to see httpd log. Then, you can see httpd log by journalctl -u httpd. You can check which service is running by systemctl list-units.

systemctl list-units # you can see list of running services. 
journalctl -u httpd
journalctl -u mysqld 
# ...etc

Make log persistent

When you want to keep log after server shutdown, you should edit /etc/systemd/journald.conf and add line Storage=persistent .

/etc/systemd/journald.conf
[Journal]
#Storage=auto
Storage=persistent
#Compress=yes
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む