20200325のLinuxに関する記事は15件です。

RaspberryPiのUSBポートの電源On/Offを制御する

はじめに

RaspberryPiのUSBポートの電源On/Offを操作してみました。

前回の記事でBlynkサーバー経由でRaspberryPiとスマートフォンを接続したので、スマートフォン側から操作して電源操作をしています。

使用した物

使用機器の全体像

上記の使用機器の全体像はこのような感じです。
全体像.jpg
スマートフォンとRaspberryPiは同じローカルエリア内で接続をしており、それとBlynkサーバーが繋がっているイメージです。
RaspberryPiと今回制御するUSB-HUB/USB-FANを繋いでいます。

事前準備

1.Blynkの導入と接続

以降のやり方はBlynkを使用したやり方なので、スマートフォン/RaspberryPiの双方でBlynkのインストールと接続が必要になります。

やり方はこちらを参照ください。
↓↓↓
Blynkを使ってRaspberryPiとスマートフォンを接続する

2.Blynk のプログラム修正

初期設定ではスクリプトが扱いづらいので下記サイトを参考にして変更しています。

http://blog.livedoor.jp/victory7com/archives/48432885.html

その結果、ウィジェットの設定とRaspberryPi側のスクリプトの関係性は以下の図のようになっています(※同サイトから画像を引用)

image.png

実装

スマートフォン側の作業

スマートフォン側ではBlynkのプロジェクトにウィジェットとスクリプトに紐づくピンを選択します。
blynk.jpg

【左】ウィジェットをタップしウィジェット設定を開く
【中】今回はボタンなので、ボタンを押したときに紐づくピンを選ぶためタップ
【右】ピンの種類とピンの番号を選択する

※ピンの種類はDigital(GPIOポート)/Virtual(スクリプト)から選べますが、今回はスクリプトと紐づけたいため、後者を選択
※ピンの番号はスクリプトの名称と紐づける番号なので、何でもいいですがV10にしました。

RaspberryPi側の作業

1.USBポートを制御するためのツール(hub-ctrl)を導入

pi@raspberrypi:~ $ sudo apt-get install libusb-dev
pi@raspberrypi:~ $ git clone https://github.com/codazoda/hub-ctrl.c
pi@raspberrypi:~ $ cd hub-ctrl.c
pi@raspberrypi:~/hub-ctrl.c $ gcc -O2 hub-ctrl.c -o hub-ctrl-armhf-static -lusb –static
pi@raspberrypi:~/hub-ctrl.c $ sudo cp hub-ctrl-armhf-static /usr/local/bin/hub-ctrl

※補足
1行目:libusbをインストール
2行目:Githubから「hub-ctrl.c」をダウンロード
4行目:hub-ctrl.cのインストール

2.USBポートの接続状況を確認する

「lsusb」コマンドを実行するとUSBポートに接続しているデバイスとそのBus番号とDevice番号が返されます。
今回USB-HUBが操作対象なので、デバイス名が「Genesys Logic」であることを確認します。

pi@raspberrypi:~ $ lsusb

Bus 001 Device 005: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 006: ID 0424:7800 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

3.USB-HUBの電源ON/OFFのシェルスクリプトを作成する

ウィジェット設定でピンの番号を「V10」にしたため、スクリプトのファイル名に「V10」としています。

pi@raspberrypi:~ $ sudo vi /home/pi/blynk/BLYNK_WRITE_V10.sh

スクリプトの中身はこのような内容にしています。

/home/pi/blynk/BLYNK_WRITE_V10.sh
#!/bin/sh

HUB=`/usr/bin/lsusb -v 2>/dev/null | grep ^Bus | grep "Genesys Logic, Inc. Hub" | head -1`
BUS=`echo $HUB | awk '{print $2}'`
DEV=`echo $HUB | awk '{print $4}' | sed -e "s/\(.*\)\:/\1/p;d"`

for i in 1 2 3 4
do
     /usr/local/bin/hub-ctrl -b $BUS -d $DEV -P $i -p 0
done
スクリプトの補足
デバイス情報の設定(3行目)
lsusbの命令の結果を、デバイスの名称で抽出し変数HUBにセットする。
Bus番号の設定(4行目)
HUBに設定された2番目のフィールドを変数BUSにセットする。
Device番号の設定(5行目)
HUBに設定された4番目のフィールドを文字の置き換えをして変数DEVにセットする。
for文(7行目)
USB-HUBのポートが4つあるので、4回ループさせている。
hub-ctrlコマンド(9行目)
「-b」は対象のBus番号、「-d」は対象のDevice番号、「-P」はポート番号を指定する。
最後の「-p」は電源供給On/Offの指定で、「0」(Off)/「1」(On)のいずれかを指定する。

これでウィジェットで指定したピンの番号に相対するスクリプトができたため、スマートフォン側でボタンを押せばこのスクリプトが起動します。
その結果、USB扇風機の電源のOn/Offを切り替えができます。

USBポートの電源操作の補足

RaspberryPiの昔のバージョンだと本体のUSBポートを個別に電源制御できるようでしたが、バージョンが上がったため不可能になりました。

「Per-port power switching」仕様のUSB-HUBであれば制御可能ということでしたが、それに対応したHUBが現在販売されてません。
今回使用したBUFFALOのBSH4AE12BKであればUSB-HUB単位に電源制御可能ということで、これを利用することにしました。

まとめ

ウィジェットで指定したピンとそれに紐づくスクリプトを作成すれば、スマートフォン側からスクリプトを実行させることができました。
まずは動かし方の基本を理解できたので、次は違うウィジェットを使って動かしてみたいです。

参考リンク

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

util-linuxのマニュアルの日本語訳

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

iproute2のマニュアルの日本語訳

iproute2のマニュアルの日本語訳

iproute2-5.1.0

ifcfg(8)
ifstat(8)
ip(8)
lnstat(8)
ss(8)
rtacct(8)

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

sysstatのマニュアルの日本語訳

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

Blynkを使ってRaspberryPiとスマートフォンを接続する

はじめに

RaspberryPiを使ってIoT機器を作りたく、またスマートフォンで操作ができないかと模索してみたらBlynkというアプリを使えば簡単に接続と操作ができるとわかったので試してみました。

Blynkとは

Blynkサーバー経由でRaspberryPiとスマートフォンを接続でき、Blynkのアプリを使ってRaspberryPiにあるスクリプトの操作ができるようになるものです。

全体像はこのような感じです。
blynk.jpg
(引用元:http://docs.blynk.cc/)

使用したもの

  • Androidスマートフォン
  • Raspberry Pi3 B+

接続するために準備すること

スマートフォン側とRaspberryPi側でそれぞれで準備が必要です。

スマートフォン側の準備

  1. Blynkのアプリをダウンロードする
  2. Blynkのアプリでプロジェクトを作成する
  3. 指定したメールアドレスにBlynkよりRaspberryPiと接続するためのToken(接続キー)が届くので控えておく

RaspberryPi側の準備

1.BlynkのライブラリをGithubから取得する

pi@raspberrypi:~ $ git clone https://github.com/blynkkk/blynk-library.git

2.ビルドし、Blynkの実行ファイルを作成

pi@raspberrypi:~ $ cd blynk-library/linux
pi@raspberrypi:~/blynk-library/linux $ make clean all target=raspberry

3.Blynkを起動し、Blynkサーバーと接続する

pi@raspberrypi:~/blynk-library/linux $ sudo ./blynk --token="メールに届いたToken"

[0] 
    ___  __          __
   / _ )/ /_ _____  / /__
  / _  / / // / _ \/  '_/
 /____/_/\_, /_//_/_/\_\
        /___/ v0.6.1 on Linux

[1] Connecting to blynk-cloud.com:80
[583] Ready (ping: 192ms).
---

これでBlynkが起動し、サーバー経由でスマートフォンとRaspberryPiの接続が完了しました。

まとめ

Blynkを使えば短時間でスマートフォンとRaspberryPiの接続が可能でした。
あとはやりたいことをプロジェクト内で作り、それに相対する実行プログラムを作成すればBlynkサーバー経由で実行可能です。

参考サイト

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

MacBook Air 11' Early 2015にArchLinuxをインストールする際にハマった事メモ(2020年3月)

走り書きのメモです。
久々にArchLinux環境をリフレッシュしようとしたら、かなり手間取りました。

新しめのカーネルが内臓ストレージ(nvme0n1)を認識しない

この症状はいつぞやから起動しないなと認識はしていたので、途中からltsカーネルをインストールして使っていました。
技術的背景等は調べていませんが、こちらのスレッドによると、nvmeをLinux Kernel 5.1.5からサポートしなくなったとされています。
ただ自分が確かめた範囲では、少なくとも自分の機体に関してはもっと前の4.19でも認識しませんでした。
色々な世代のインストールイメージを入手して試した限りでは、2019.05.02(Kernelは4.16.12-1)で認識できました。
ただしこのUSBでは別の問題があります。詳細は次の見出しで。

archlinux-keyringが更新できない

こちらに関してはpacmanで用いられるパッケージの圧縮形式の変更が影響しています。
https://www.archlinux.jp/news/required-update-to-recent-libarchive/
要約すると、

  • 新しいpacman5.2は.zst圧縮に対応する
  • 今後はこちらの圧縮方式に変更していく
  • libarchiveを3.3.3-1以降に更新するように

という話です。

これが何故問題化するかというと、前述の2019.05.02のインストールイメージでは

  • libarchiveのバージョンは問題ない
  • pacmanはこの5.2より前のバージョン(5.2のリリースは2019.10.22)で、.zstパッケージを取り扱えない
  • archlinux-keyringパッケージは既に.zst圧縮になっている

archlinux-keyringはパッケージ署名の情報等が含まれているので、インストール時にここに無い署名が含まれているとエラーが出て更新しろと言われるのですが、アップデートができません。
その他のパッケージにも.zst圧縮の物が既に含まれており、ストレージを認識していてもpacstrapを完了できません。

解決について

問題を整理すると

  • インストールUSBと本体にインストールするKernelが4.16以下である必要がある(確認した限り)
  • pacmanが5.2以上である必要があり、libarchiveも3.3.3-1以上にする必要がある

上記の問題を同時に解決できるインストールUSBは存在しないので、archisoを使用するか、isoをリマスタリングしてカスタムインストールUSBを作成して解決する事になると思います。
その為、別にArchLinuxが動作している環境(VMでも可)が必須になります。

使用するカーネルは、linux-lts414がお勧めです。このMacBookでも問題なく動作する上に、サポートがとても長い(~2024年1月)ので当分安泰です。
ただしこのカーネルはAURのものなので、こちらについても別のArchLinux環境でビルドした上で、プライベートリポジトリを設定してarchisoの構築時に使用させるようなどしてください。
もしくはビルド済みパッケージを提供しているリポジトリを追加してください。(未発見)
AURパッケージの為、カーネルのセキュリティアップデートにもビルドが必要になります。

またオプションですが、ついでにbroadcom-wl-dkmsパッケージを含めておくと、インストール時にも無線LANを使用できるようになります。
インストール手順に関しては、基本的にArchWikiのMacBookの記事の内容に従ってください。ブートローダーは、筆者はsystemd-bootを採用しています。

おわりに

もう5年前の機種ですし、あまりこういった使い方をする方はいないかもしれませんが、役立てば幸いです。

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

CentOS で/lib64 のシンボリックリンク先を/usr/lib64 から/my-lib64 に変更したい

いったい何の役に立つねんシリーズ。技術の無駄遣い担当の平野です。
今回は、CentOS の/lib64 のシンボリックリンクをどう書き換えるかをご紹介します。

はじめに

とあることから、システムの標準ライブラリ(.so)をすべて置き換えたくなりました。
/usr/lib64 にあるようなライブラリを全部一括で、です。
CentOS7 や 8 の場合、システムのライブラリは/lib64 から実体/usr/lib64 へのシンボリックリンクになっています。
新しいライブラリを置いたディレクトリへ/lib64 のシンボリックリンクを付け替えるのが楽そうです。

やってみる

まず思いつくのは、以下のような方法です。
最初は気にせず、これを実行しました。

# ln -sf /my-lib64 /lib64

しかし、あれれ。書き換わっていないようです。

# ls -ld /lib64
lrwxrwxrwx 1 root root 9 May 11  2019 /lib64 -> usr/lib64

システムの部分なので、変更途中でエラーになって変えられないのかなぁ、とか考えながら、とりあえず、別の方法を試してみます。

※お急ぎの方は解決方法 ④ へどうぞ。

削除して作成 (失敗)

上書きができないのなら、簡単に思いつくのは、削除して、新たに作成するという方法です。
やってみましょう。

CentOS7
# rm /lib64
# ln -s /my-lib64 /lib64
sh: /usr/bin/ln: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

半分予想してはいましたが、システムのライブラリを削除してしまったので、ln コマンドが実行できなくなってしまいました。

では、LD_LIBRARY_PATH で指定してみたらどうでしょうか。

CentOS7
# LD_LIBRARY_PATH=/usr/lib64 ln -s /my-lib64 /lib64
sh: /usr/bin/ln: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

効かないですね。

もはや、ls コマンドさえ、もう実行できません。

CentOS7
# ls
sh: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

さようなら。。。

/lib64 がない状態でコマンドを実行する

システムのライブラリが使えない状態でコマンドが実行できるようにするには、static link でコンパイルしたコマンドを利用することを、まず思いつきます。
しかし、残念ながら CentOS7 の ln コマンドは static link にはなっておらず、いくつかの外部ライブラリを必要としていました。

CentOS7
# ldd /usr/bin/ln
        linux-vdso.so.1 =>  (0x00007ffeaa98e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f48229de000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4822dac000)

自分で static link されたコマンドをコンパイルするのは負けた気分がするので、これは、最後の手段とすることで、少し調査してみることにしました。

まずは、他力本願で、全世界の人々に頼ろうと、自分の Facebook で軽くつぶやいてみました。すると、すぐに会社の同僚から反応が来ました。

LiveCD でやってみたら?

いやいやいやいやいやいや、それはダメです。最後です。負けです。ていうか、環境は Docker コンテナです。却下。

しばらくすると、予想もしていなかった、自転車仲間方面から反応がありました。

ld-linux でライブラリ指定すれば?

ほぉぉぉ。なんですかね、それは。さっそく試してみましょう。

解決方法 ① ld-linux を使う

ld-linux はさっきから No such file or directory と怒られている張本人です。
それで、ライブラリを指定するとは、どういうことだろう、と少し調べてみると、なんと、そのまま実行できるようです。

# /usr/lib64/ld-linux-x86-64.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
  ... 長い説明 ...
  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache       Do not use /etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST          use objects named in LIST as auditors

おーーー。どうやら、--library-path というのでライブラリの場所を指定しつつ、コマンドを実行できるようです。
LD_LIBRARY_PATH はだめでしたが、こちらはどうでしょうか。

CentOS7
# /usr/lib64/ld-linux-x86-64.so.2 --library-path /usr/lib64 /usr/bin/ln -s /my-lib64 /lib64
# ls -ld /lib64
lrwxrwxrwx 1 root root 9 Mar 25 02:42 /lib64 -> /my-lib64

すばらしい!!!
できました!!

解決方法 ② static link されたコマンドを作る

さて、もう、今なら負けた気分はしません。
勝ち誇った気持ちで、自作 static link コマンドバージョンも試しておきます。

こんなコードです。
ld-linux なんちゃらを調べるより速く書けます。

my-ln.c
#include <unistd.h>

int main() {
    symlink("/my-lib64", "/lib64");
    return 0;
}

コンパイルします。

# yum install -y gcc glibc-static
# gcc -Wall -static -o my-ln my-ln.c

試します。

# rm /lib64
# ls -ld /lib64
sh: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
# ./my-ln
# ls -ld /lib64
lrwxrwxrwx 1 root root 9 Mar 25 02:58 /lib64 -> /my-lib64

できました!!!

解決方法 ③ 用意された static link されたコマンドを使う

実は、悔しいので隠していたのですが、調べてる途中で OS に static link された ln コマンドが付属していることがわかりました。

90 年代頃は、sh やメンテに必要なコマンドが、/bin や/sbin の下に同名で static link された状態で置かれてしました。
最近は/usr/bin や/usr/sbin へのシンボリックリンクなので気づかなかったのですが、/sbin/sln というのがありました。

# rm /lib64
# ls -ld /lib64
sh: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
# sln /my-lib64 /lib64
# ls -ld /lib64
lrwxrwxrwx 1 root root 9 Mar 25 03:05 /lib64 -> /my-lib64

素晴らしい!

解決方法 ④ そもそも ln だけでできたのだ

そもそも、ことの発端は

# ln -sf /my-lib64 /lib64

がなぜか効かなかったことでした。
問題があるのならエラーが出るはずで、エラーもなく静かに終わるのが少し気になります。

ということで、詳細を strace で追いかけてみることにしました。
何かエラーが出てるかもしれません。

# strace ln -s /my-lib64 /lib64
execve("/usr/bin/ln", ["ln", "-s", "/my-lib64", "/lib64"], [/* 8 vars */]) = 0
... snip ...
symlink("/my-lib64", "/lib64/my-lib64") = 0
... snip ...
+++ exited with 0 +++

え゛っ???

/lib64 の下に my-lib64 のリンクを作ってるじゃないですか!!

# ls -ld /usr/lib64/my-lib64
lrwxrwxrwx 1 root root 9 Mar 25 03:11 /usr/lib64/my-lib64 -> /my-lib64

確かにあります。。。

よく考えたら、cp も mv もこの動きですね。
対象がディレクトリへのシンボリックリンクだったので、置き換えではなく、そのディレクトリ配下にリンクを作ってしまっていた、と。

こういうとき、cp や mv コマンドには、対象がディレクトリの場合にもファイルのように扱うオプション「-T」があります。
ln コマンドもにもあるでしょうか。

# ln --help
... snip ...
  -T, --no-target-directory   treat LINK_NAME as a normal file always
... snip ...

ありますねぇ。

試してみます。

# ls -ld /lib64
lrwxrwxrwx 1 root root 9 Oct  1 01:15 /lib64 -> usr/lib64
# ln -sfT /my-lib64 /lib64
# ls -ld /lib64
lrwxrwxrwx 1 root root 9 Mar 25 03:18 /lib64 -> /my-lib64

なんと、簡単にできてしまいました。

終わりに

わかってみれば、簡単な話でした。。。
だいぶ、遠回りをしました。。。

こうして、技術の無駄遣い、いったい何の役に立つねんシリーズができあがっていくのです。

*本記事は @qualitia_cdevの中の一人、@hirachanさんに作成して頂きました。

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

【Webサーバ】nginxにアクセスできなくて調査したときの話

GCEにnginxをインストールしたが、接続できなかったので調査したときの話です。

以下のエラーがでた
curl: (7) Failed connect to ...:**; 接続を拒否されました

・ping確認

PING ...:** (...:) 56(84) bytes of data.
64 bytes from ***.
..:: icmp_seq=1 ttl=55 time=127 ms
--- *
...: ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 13017ms

https://eng-entrance.com/linux-command-ping
上記のサイトにあるとおり、正常に疎通はとれてる

apacheを入れなおして、apacheを起動したら正常にアクセスできた。

curl -I ...
HTTP/1.1 403 Forbidden
Date: Tue, 24 Mar 2020 22:39:08 GMT
Server: Apache/2.4.6 (CentOS)
Last-Modified: Thu, 16 Oct 2014 13:20:58 GMT
ETag: "1321-5058a1e728280"
Accept-Ranges: bytes
Content-Length: 4897
Content-Type: text/html; charset=UTF-8

Curlの表示も変わった。

nginxが起動できてなかったという恥ずかしい話でした。

【思ったこと】
・GCPのファイアウォールの設定を理解は必要
https://dev.classmethod.jp/articles/gce-firewall/

【参考サイト】
http://yebisupress.dac.co.jp/2018/08/23/publish_website_with_google-cloud-platform/

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

【linux】検索コマンド

find / -name Debug -print

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

【SSH】公開鍵認証とEC2について

はじめに

SSHについての記事はたくさんありますが、どうしてもイメージとして捉えられませんでした。
先日AWSのデプロイを行った際に、RUNTEQの講師の方に説明をしていただいて自分なりに解釈したので書き記しておきます。
なお、これは覚書であって手順書ではないのでご注意ください。実際に行う手順は一部省略しています。

こんな人が読んだら腑に落ちるかもしれない

  • SSHはコピペでなんとかするもの。
  • どうして公開鍵をいろんなところに登録するんだろう。
  • 鍵とか錠とか言うけど、なんか納得できない。

SSH鍵事始め

ローカル
$ cd ~/.ssh
$ ssh-keygen

このコマンドによって、~/.sshディレクトリに(特に指定をしなければ)id_rsaid_rsa.pubが作成される。前者が秘密鍵、後者が公開鍵となる。
公開鍵を外部に登録することはあるが、秘密鍵を登録することはない。というか、秘密鍵が漏れるとやばい。

よく言う鍵と錠の関係

よく、公開鍵は南京錠で秘密鍵はその鍵だと言う。確かに、錠は見せてもいいが鍵は見せてはならないと言うイメージではしっくりくるが、この鍵と錠は一対一の関係ではない。
実際はその南京錠を複製することがよくある。例えば、私はid_rsa.pubをGitHubとEC2インスタンス内に登録している。どちらもid_rsaで開けることができる。
また、一つのドアに複数の南京錠が付いていることもある。例えば、私のGitHubには複数の公開鍵が登録されている。この場合、いずれかの対応する秘密鍵があれば開けることができる。
Untitled Diagram.jpg

EC2に接続するときの手順

EC2インスタンスを作成するときに、新規にキーペアを作成する。(すでに鍵がある場合はそれを使うこともできる)
スクリーンショット 2020-03-23 21.26.02.png
このときにダウンロードしたプライベートキー(pemファイル)を~/.ssh配下に保存しておく。
作成したインスタンスを選択して「接続」ボタンを押すと、手順が表示されるので、基本的にはそれに従えばいい。ありがたいね。
スクリーンショット 2020-03-23 21.40.49.png

SSH認証のエラーいろいろ

せっかくなので手順に従わずいろいろやってみたら、見事に怒られたので紹介する。

"aws-key.pem"を指定しない場合

ローカル
$ cd ~/.ssh
$ ssh ec2-user@18.176.56.238

ec2-user@18.176.56.238: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

特に鍵の指定がない場合は、id_rsaを用いて認証を行う。
id_rsaの公開鍵は登録されていないぞ。アクセスさせるわけにはいかない」

ディレクトリに"aws-key.pem"がない場合

ローカル
$ ssh -i "aws-key.pem" ec2-user@18.176.56.238

Warning: Identity file aws-key.pem not accessible: No such file or directory.
ec2-user@18.176.56.238: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

「そんな名前のファイルもディレクトリも無いぞ。鍵がないから駄目だ」

chmod 400 aws-key.pemしていない場合

ローカル
$ ssh -i "aws-key.pem" ec2-user@18.176.56.238

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'aws-key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "aws-key.pem": bad permissions
ec2-user@18.176.56.238: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

「ばっかやろう!その秘密鍵は誰でも見れることになってるじゃないか!そんな鍵は認めないぞ!!」
パーミッションについて

手順に沿った場合

ローカル
$ ssh -i "aws-key.pem" ec2-user@18.176.56.238

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
No packages needed for security; 6 packages available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-0-11-209 ~]$ sudo yum update

SSH認証に成功した場合、EC2インスタンス内に入ることができ、このように表示される。
Run "sudo yum update" to apply all updates.と言われたので、yumをアップデートしておく。

公開鍵の場所

起動時に、パブリックキーコンテンツは、~/.ssh/authorized_keys内のエントリに配置されます。
Amazon EC2 のキーペア - Amazon Elastic Compute Cloud

ということなので、実際に確認してみる。

インスタンス
[ec2-user@ip-10-0-11-209 ~]$ cd ~/.ssh
[ec2-user@ip-10-0-11-209 .ssh]$ ls
authorized_keys
[ec2-user@ip-10-0-11-209 .ssh]$ cat authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCyZDViLAZcA7F8N8ebO9KlYoKOFC9hlG1y7BB6/R8grwcvKRGVhVCBRrCvLIoijkDfv+NYJnCyPxPb7QWdjQ/apD6FPfdmk9fdunyFRC5IRuFwXW17TUeVnBQwnHmatW/S36ZsDJxiK3O4s+L+WuK8XEriyddEHS1xLZi8+vNaTiSmqhNdPhhP/ocdAE/yWvSQqmdmTL4/HFVqp+Hy4C3v8+sgztj+F2+vpbHMmlb8aArdTMTDKcqPryNtLEN/ib1opqJLv4zhrv7EteqtCeFR6OnQttiAO+32UD0XP2mtj9lzsskCZ1wnNwG38WJbRdgD2mM/Ap8kNx0k/4Tkg7W3 aws-key

authorized_keysaws-key.pemのペアとなるパブリッシュキーが登録されていることがわかる。

EC2インスタンスの中で行う推奨設定

編集用ユーザーを追加する

ec2-userはルートユーザーなので、編集用ユーザーを作成する。

インスタンス
[ec2-user@ip-10-0-11-209 ~]$ sudo useradd username  # usernameは任意の名前
[ec2-user@ip-10-0-11-209 ~]$ sudo passwd username
ユーザー username のパスワードを変更。
新しいパスワード:  # 表示されないが問題ない
新しいパスワードを再入力してください:
passwd: すべての認証トークンが正しく更新できました。
[ec2-user@ip-10-0-11-209 ~]$ sudo visudo  # vimエディタが開くので、usernameの行を追加する。

  ## Allow root to run any commands anywhere
  root      ALL=(ALL)       ALL
  username  ALL=(ALL)       NOPASSWD: ALL

[ec2-user@ip-10-0-11-209 ~]$ su - username  # usernameに切り替える
パスワード:  # 先ほど設定したパスワードを入力
[username@ip-10-0-11-209 ec2-user]$ cd ~/ 

これで、usernameを作成することができた。

自分の公開鍵を登録する

単一のインスタンスにアクセスする複数のユーザーがいる場合、インスタンスにユーザーアカウントを追加できます。(省略)各ユーザー用にキーペアを作成し、インスタンスの各ユーザー用の.ssh/authorized_keysファイルに各キーペアからのパブリックキー情報を追加できます。その後、ユーザーに対してプライベートキーファイルを配布できます。この方法では、AWS アカウントルートユーザー用に使用しているプライベートキーファイル(補足:aws-key.pemのこと)と同一のファイルを複数のユーザーに配布する必要はありません。
Amazon EC2 のキーペア - Amazon Elastic Compute Cloud

インスタンス
[username@ip-10-0-11-209 ~]$ mkdir .ssh
[username@ip-10-0-11-209 ~]$ chmod 700 .ssh
[username@ip-10-0-11-209 ~]$ cd ~/.ssh
[username@ip-10-0-11-209 .ssh]$ touch authorized_keys
[username@ip-10-0-11-209 .ssh]$ chmod 600 authorized_keys

authorized_keyを作成し、このファイルにローカルのid_rsa.pubを記述することで公開鍵情報を登録する。
これで、次回からは$ ssh username@18.176.56.238でインスタンスにアクセスできる。

おわりに

これはSSHについて教えてもらったことを私なりにデフォルメして解釈したものです。
間違っている点や書き落としなどございましたら、是非ご指摘いただければと思います。
また、この記事で作成したEC2インスタンスとキーペアは現在削除済みです。

参考リンク

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

Linuxマニュアルの翻訳

Linuxマニュアルの翻訳

iproute2のマニュアルの翻訳

ifcfg(8) ifstat(8) ip(8) lnstat(8) ss(8) rtacct(8)

sysstatのマニュアルの翻訳

cifsiostat(1) iostat(1) mpstat(1) pidstat(1) sadf(1) sar(1) tapestat(1)

sysstat(5)

sa1(8) sa2(8) sadc(8)

util-linuxのマニュアルの翻訳

cal(1) chfn(1) chsh(1) col(1) colcrt(1) colrm(1) column(1) flock(1) getopt(1) hexdump(1) kill(1) last(1) line(1) logger(1) look(1) mcookie(1) mesg(1) more(1) namei(1) newgrp(1) pg(1) rename(1) rev(1) script(1) scriptreplay(1) setterm(1) ul(1) wall(1) whereis(1)

fstab(5)

agetty(8) blockdev(8) cfdisk(8) ctrlaltdel(8) fdformat(8) fdisk(8) fsck.minix(8) hwclock(8) isosize(8) losetup(8) mkfs(8) mkfs.bfs(8) mkfs.minix(8) mkswap(8) pivot_root(8)

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

Linuxマニュアルの日本語訳

Linuxマニュアルの日本語訳

iproute2のマニュアルの日本語訳

ifcfg(8) ifstat(8) ip(8) lnstat(8) ss(8) rtacct(8)

sysstatのマニュアルの日本語訳

cifsiostat(1) iostat(1) mpstat(1) pidstat(1) sadf(1) sar(1) tapestat(1)

sysstat(5)

sa1(8) sa2(8) sadc(8)

util-linuxのマニュアルの日本語訳

cal(1) chfn(1) chsh(1) col(1) colcrt(1) colrm(1) column(1) flock(1) getopt(1) hexdump(1) kill(1) last(1) line(1) logger(1) look(1) mcookie(1) mesg(1) more(1) namei(1) newgrp(1) pg(1) rename(1) rev(1) script(1) scriptreplay(1) setterm(1) ul(1) wall(1) whereis(1)

fstab(5)

agetty(8) blockdev(8) cfdisk(8) ctrlaltdel(8) fdformat(8) fdisk(8) fsck.minix(8) hwclock(8) isosize(8) losetup(8) mkfs(8) mkfs.bfs(8) mkfs.minix(8) mkswap(8) pivot_root(8) raw(8)

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

【Linux】同じアプリなのにDockにアイコンが2個表示されてしまう!

自分でdesktopファイルを書いて登録したアプリなどがこうなることがあります↓
Screenshot from 2020-03-25 00-53-29.png

対処法

やることとしては、このアプリのクラス名を取得し、そのクラス名をdesktopファイルに明記します。

クラス名の取得

  1. 調べたいアプリケーションを起動しておいてください。

  2. このコマンドを叩きます

$ xprop WM_CLASS
  1. するとコマンドが完了せずに待ちの状態に入りますので、この状態で該当のアプリケーションのウィンドウをクリックします

うまくいくと、↓のようにクラス名を出力します。

WM_CLASS(STRING) = "gravitdesigner", "GravitDesigner"

desktopファイルに登録

対象アプリのdesktopファイルを開き、

$ sudo vi /usr/share/applications/gravit-designer.desktop

↓の行を追加します

StartupWMClass=GravitDesigner

GravitDesigner がさっき調べたクラス名になります。


以上で改善するはずです!

ちなみに、このGravitDesignerというデザインソフトは、Adobe Illustratorからの乗り換え先として使っています。おすすめです。

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

【Linux】定義されていないmime typeを登録してアプリケーションに関連付ける

例:

Qiita というアプリケーションは、 xxx.qiita というプロジェクトファイルを保存します。

しかし、*.qiita という拡張子は登録されておらず、Qiitaにも関連付けられていません。
*.qiita というファイルを Qiita で開けるように設定します。
Screenshot from 2020-03-25 00-35-09.png

拡張子の確認

まずは mimetype コマンドで拡張子が登録されていないことを確認します。

$ mimetype article.qiita 
article.qiita: application/gzip

登録されていない場合、 text/plainapplication/gzip などと認識されます。

拡張子を定義

$ sudo vi /usr/share/mime/packages/freedesktop.org.xml

周りの項目を見ながらxmlを書きます。コメントとかは多分適当で大丈夫です。

  <mime-type type="application/qiita">
    <comment>Qiita file</comment>
    <comment xml:lang="ja">Qiita ファイル</comment>
    <acronym>Qiita</acronym>
    <expanded-acronym>Qiita file</expanded-acronym>
    <glob pattern="*.qiita"/>
  </mime-type>

mime databaseを更新します。

$ sudo update-mime-database /usr/share/mime

確認

$ mimetype article.qiita 
article.qiita: application/qiita

アプリケーションに拡張子を関連付け

「Qiita」というアプリは「application/qiita」に対応してますよー、的な設定をします。

該当のdesktopファイルのMimeTypeに加筆します。なければ行を足してください。

$ sudo vi /usr/share/applications/qiita.desktop
...
MimeType=xxx/xxx;xxx/xxx;application/qiita;
...

再読込

$ update-desktop-database

*.qiita ファイルを Qiita で開けるようになっているはずです。

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

WSL2でカスタムカーネルを使う

WSL2にてカスタムカーネルを使う方法を書きますた。

カーネルのコンパイル (例)

github - microsoft/WSL2-Linux-Kernel

依存関係

Ubuntu

build-essential flex bison libssl-dev libelf-dev

ArchLinux

base-devel flex bison openssl libelf

ソース

ビルド

shell
 make KCONFIG_CONFIG=Microsoft/config-wsl
# or. AutoEnter
 yes '' | make KCONFIG_CONFIG=Microsoft/config-wsl

Windowsでの設定

~/.wslconfigを弄ります。
の前に!uname -aをしておきましょう。

ホームパスに次のファイルを作ります。
[USERNAME]を置き換えてください。

.wslconfig
[WSL2]
kernel=C:\\Users\\[USERNAME]\\vmlinux

インスタンスを起動している場合はwsl --shutdownをします。
vmlinuxの場所はもちろん自由です。各自好きなところに。
ビルド済みのやつ

WSL2でぜんぶできるね

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