- 投稿日:2019-07-16T23:50:58+09:00
dockerでマイクラのポケモンサーバ簡単構築
はじめに
dockerでpixelmonサーバ立ち上げたことがあったので、備忘録として残します。
いやぁ、楽しいですよねマインクラフトあと、今回ネットワークと、サーバ設定周りは触れませんので、そこらへんはあしからず
(機会があったら家のサーバ環境とかも取り上げたいです!)構築環境
・centos7
うん、docker動けばどこでもいいよ
・minecraft version 1.12.2
・forge version 14.23.5.2768
(これwin側のバージョンは違うかもです)
・pixelmon version 2.4.2自分が構築した時期も少し前と言うこともあり
全体的に古いバージョンなのですが、そこは臨機応変におねです内容
ディレクトリ構造
centosのユーザで以下ディレクトリ作成してください。
また、mods直下にpixelmonのjarを配置してください。pokemon
|--docker-compose.yml
|--25565
| |--data
| |--mods
| |--PixelmonGenerations-1.12.2-2.4.2-universal.jardocker-compose
docker-composeversion: '3' services: minecraft-server: container_name: miutipokemon image: itzg/minecraft-server ports: - "25565:25565" tty: true stdin_open: true restart: always volumes: - ./25565/mods:/data/mods/ - ./25565/data:/data/ environment: EULA: "TRUE" VERSION: "1.12.2" TYPE: "FORGE" FORGEVERSION: "14.23.5.2768" SPAWN_MONSTERS: "false"(これどうやったら色つくようにできるんだろう・・・)
軽く中身を説明すると
volumesの/data/modsでjarファイルをコンテナ内に同期させ、/dataでデータを永続化してます。
なので、バックアップを取りたい場合は、ホスト側の25565/dataの中身
全部取っておけばおっけーです。environmentの中の設定詳細は以下URL
https://hub.docker.com/r/itzg/minecraft-server実行
docker-composeが配置されてるディレクトリにて
$ docker-compose up -dと実行するだけ!
あとは、ネットワーク環境によりますがサーバ指定して入ってもらえば
OKです!僕のサーバ公開しているので、遊びたいかたいたら一声かけてくださーい。
- 投稿日:2019-07-16T23:04:55+09:00
意外と簡単なVS Codeの環境移行
Visual Studio Codeの環境移行のやり方を紹介します.
最新のバージョンでは,環境移行がかなり簡単になっています.使用バージョンとOS
- Visual Studio Code 1.36.1
- Ubuntu 18.04 LTS(※Windows向けの情報もうろ覚えですが,記載してます.)
環境移行に必要なフォルダ
下の2つのフォルダを,古いPCから(USBメモリ等)に退避させ,新しいPCで同じ場所に置いてあげるだけ.
~/.vscode
( Windows :%USERPROFILE%\.vscode
) ディレクトリ
- このディレクトリの中にプラグインのファイルが入ってたりします.
~/.config/Code/User
( Windows :%APPDATA\Code\User
) ディレクトリ
- このディレクトリの中に基本設定やキーコンフィグが入ってたりします.
- 投稿日:2019-07-16T21:34:43+09:00
bash shell に関するtips 備忘録
実行時にデバッグ出力する場合のヘッダ
#!/bin/bash -xroot以外が実行すると処理せずに終了させる
if [ $(whoami) != "root" ]; then echo "This script must be run as root" exit 1 fiスペースの入ったファイル名を処理するために配列の分割子を改行コードに固定する
export IFS=$'\n'ので、上記設定以降はshell内での配列指定は以下の例のように記述する必要がある
EXTLIST=( "mov" "mkv" "..avi" "avi.mp4" "wmv.mp4" "flv.mp4" "mpeg" "mpg" "flv" "rmvb" "wmv" "M4A" "avi" "ts")rootから全てのユーザのjavaに対してgc実行リクエストする
for line in `ps aux | grep java | tr -s " " | grep -v grep | tr " " "," | cut -d ',' -f 1-2` do arr=( `echo $line | tr -s ',' ' '`) user=${arr[0]} pid=${arr[1]} sudo -u $user jmap -histo:live $pid donelockファイルを作らずに、shellの複数起動をしないようにする
参考 : https://qiita.com/hit/items/e95298f689a1ee70ae4a
_pcnt=`pgrep -fo ${CMDNAME} | wc -l` if [ ${_pcnt} -gt 1 ]; then echo "This script has been running now. proc : ${_pcnt}" exit 1 fi
- 投稿日:2019-07-16T21:19:15+09:00
障害時の情報取得
障害発生時の情報取得
私がこれまでにいた現場では、各ミドルウェア担当ごとに、障害情報取得スクリプトを自作していた。
問題点
- DRYできてない。
- Apacheで障害が起きたとしても、Apacheのログしか取得してない。
- 定義ファイルだけを取得するスクリプトと障害情報?を取得するものでスクリプトが別れている。もちろんメンテは片方ずつしかされてなかったりする。
こういうときって、APだったり、負荷分散だったり、のログもほしいもの。
ほしければ、自分で実装しなければいけない。解決策
sosreportの活用を!
sosreportのプラグインを自作してしまえばいいんだ!とりあえず定義ファイルとコマンドを抜くだけだったら以下のようにすればいい。
from sos.plugins import Plugin, RedHatPlugin class MyPlugin(Plugin, RedHatPlugin): """pluginの説明""" def setup(self): self.add_copy_spec([ "取得したいファイルのパス", "取得したいファイルのパス", "取得したいファイルのパス", self.add_cmd_output("実行したいコマンド") ])こんなプラグインを、
/usr/lib/python2.7/site-packages/sos/plugins
につっこんでおけばよい。
ファイルは普通にアーカイブされているし、コマンド結果も、
sos_commands/プラグイン名/コマンド名
で保存されている。
- 投稿日:2019-07-16T20:39:03+09:00
OCI Computeでブロックボリュームをマウントする LVM不使用編
1. はじめに
以前に書いた以下のエントリでは、追加したブロックボリュームをLVM(論理ボリュームマネージャー)で構成した。
LVMのメリットは多いが、クラウドや仮想サーバー環境では既存のボリュームを簡単に拡張できる(以下参照)。そこで今回はLVMを使わない方法を説明する。
既存のボリュームを拡張する方法
- オフラインにした既存のボリュームを拡張する
- ボリュームのバックアップを、より大きなサイズのボリュームにリストアする
- 既存のボリュームを、より大きなサイズのボリュームにクローンする
2. 前提条件
前回の補足的な位置づけなので、ブロックボリュームは作成&アタッチ済みで、「5-2. ディスクパーティションを作成する」以降の差分だけを書くことにする。
3. 追加したブロックボリュームを使えるように構成する
3-1. パーティション構成を確認する
追加したブロックボリュームを確認する。すると
/dev/sdb
として追加され、コンシステンス・デバイス・パス/dev/oracleoci/oraclevdb
として定義されていることがわかる。# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 512G 0 disk sda 8:0 0 46.6G 0 disk ├─sda2 8:2 0 8G 0 part [SWAP] ├─sda3 8:3 0 38.4G 0 part / └─sda1 8:1 0 200M 0 part /boot/efi# ll /dev/oracleoci/oraclevd* lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevda -> ../sda lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda1 -> ../sda1 lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda2 -> ../sda2 lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda3 -> ../sda3 lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevdb -> ../sdb3-2. ディスクパーティションを作成する
LVMは使用しないので、LVMフラグを付けずに作成する。ここではコンシステンス・デバイス・パスを指定しているが
/dev/sdb
でもよい。# parted -s -a optimal /dev/oracleoci/oraclevdb \ mklabel gpt \ mkpart primary 0% 100%パーティション情報を確認すると
sdb1
が定義されていることがわかる。# parted /dev/oracleoci/oraclevdb print Model: ORACLE BlockVolume (scsi) Disk /dev/sdb: 550GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 550GB 550GB primary# lsblk -o +UUID NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID sdb 8:16 0 512G 0 disk └─sdb1 8:17 0 512G 0 part c31941dc-9bae-4680-9c35-8f195b0db30d sda 8:0 0 46.6G 0 disk ├─sda2 8:2 0 8G 0 part [SWAP] d2f67c75-3f12-4abb-9c5a-ae8c23426d7c ├─sda3 8:3 0 38.4G 0 part / 666196a2-64e0-4535-a3f8-7d746a37d900 └─sda1 8:1 0 200M 0 part /boot/efi 6F4C-7CE83-3. 次の手順は
残るは以下の作業である。この部分は同じなので「5-6. ファイルシステムを作成する」以降を参照のこと。
- ファイルシステムの作成
- マウントポイントの作成
- /etc/fstabの作成
- ファイルシステムのマウント
- 投稿日:2019-07-16T20:39:03+09:00
OCI Computeでブロックボリュームをマウントする(LVM不使用編)
1. はじめに
以前に書いた以下のエントリでは、追加したブロックボリュームをLVM(論理ボリュームマネージャー)で構成した。
LVMのメリットは多いが、クラウドや仮想サーバー環境では既存のボリュームを簡単に拡張できる(以下参照)。そこで今回はLVMを使わない方法を説明する。
既存のボリュームを拡張する方法
- オフラインにした既存のボリュームを拡張する
- ボリュームのバックアップを、より大きなサイズのボリュームにリストアする
- 既存のボリュームを、より大きなサイズのボリュームにクローンする
2. 前提条件
前回の補足的な位置づけなので、ブロックボリュームは作成&アタッチ済みで、「5-2. ディスクパーティションを作成する」以降の差分だけを書くことにする。
3. 追加したブロックボリュームを使えるように構成する
3-1. パーティション構成を確認する
追加したブロックボリュームを確認する。すると
/dev/sdb
として追加され、コンシステンス・デバイス・パス/dev/oracleoci/oraclevdb
として定義されていることがわかる。# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 512G 0 disk sda 8:0 0 46.6G 0 disk ├─sda2 8:2 0 8G 0 part [SWAP] ├─sda3 8:3 0 38.4G 0 part / └─sda1 8:1 0 200M 0 part /boot/efi# ll /dev/oracleoci/oraclevd* lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevda -> ../sda lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda1 -> ../sda1 lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda2 -> ../sda2 lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda3 -> ../sda3 lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevdb -> ../sdb3-2. ディスクパーティションを作成する
LVMは使用しないので、LVMフラグを付けずに作成する。ここではコンシステンス・デバイス・パスを指定しているが
/dev/sdb
でもよい。# parted -s -a optimal /dev/oracleoci/oraclevdb \ mklabel gpt \ mkpart primary 0% 100%パーティション情報を確認すると
sdb1
が定義されていることがわかる。# parted /dev/oracleoci/oraclevdb print Model: ORACLE BlockVolume (scsi) Disk /dev/sdb: 550GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 550GB 550GB primary# lsblk -o +UUID NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID sdb 8:16 0 512G 0 disk └─sdb1 8:17 0 512G 0 part c31941dc-9bae-4680-9c35-8f195b0db30d sda 8:0 0 46.6G 0 disk ├─sda2 8:2 0 8G 0 part [SWAP] d2f67c75-3f12-4abb-9c5a-ae8c23426d7c ├─sda3 8:3 0 38.4G 0 part / 666196a2-64e0-4535-a3f8-7d746a37d900 └─sda1 8:1 0 200M 0 part /boot/efi 6F4C-7CE83-3. ファイルシステムを作成する
ファイルシステムをxfsでフォーマットする。ext4のときには、代わりに
mkfs.ext4
を指定する。# mkfs.xfs /dev/oracleoci/oraclevdb1 meta-data=/dev/oracleoci/oraclevdb1 isize=256 agcount=4, agsize=33554304 blks = sectsz=4096 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0, rmapbt=0, reflink=0 data = bsize=4096 blocks=134217216, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=65535, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=03-4. 次の手順は
残るは以下の作業である。この部分は同じなので「5-7. ブロックボリュームをマウントする」以降を参照のこと。
- マウントポイントの作成
- /etc/fstabの作成
- ファイルシステムのマウント
- 投稿日:2019-07-16T18:15:39+09:00
findコマンド
find
は様々な方法でファイル検索ができる。
xargs
との併用に関しては別スレッド$ find [directory] [検索方法] [検索正規表現]ディレクトリは適当なものを。(現階層ならば
.
や./*
など...)検索正規表現に関しては、
*
使用時のみエラー発生することがあるので""
で囲む。#簡単なファイル名検索であればこれらでOK $ find . -name "hoge*" $ find ./* -name "*.rtf" $ find /test -name "num"大小文字区別のオプションに関しては
grep
と同じくi
で対処だがiname
と記述する点に注意$ find /test -iname "HoGe*"
find
コマンドで得た結果の一通りの情報を得る場合は-ls
を末尾に追加$ find /test -iname "HO*" -lsこれでアクセス権限等を含めた結果が得られる
64363231536 4 -rw-r--r-- 1 sf213471118 admin 32 7 16 17:06 ./hoge.rtfファイル名検索以外で使いそうなものは以下
#ファイルサイズで検索( 50>=size , 50<size) $ find ./* -size +50 $ find ./* -size -50 #最新の変更日時で検索( 60<=min , 7>days) $ find ./* -mmin +60 $ find ./* -mtime -7
- 投稿日:2019-07-16T17:21:09+09:00
grep
grep
grep
は特定の文字列を含むファイルの検索ができる。$ grep [検索正規表現] [option] [directory][検索正規表現] [option]については順不同。
ディレクトリは、例えば現階層のファイル全てから検索であれば
./*
で検索。オプションは主に使うものだけ以下にメモ
#大文字と小文字を区別せず検索 $ grep [検索正規表現] -i [directory] #一致しないものを検索 $ grep [検索正規表現] -v [directory] #行番号と併せて表示 $ grep [検索正規表現] -n [directory] #ファイル名のみ表示 $ grep [検索正規表現] -l [directory] #ディレクトリ内も検索に含める $ grep [検索正規表現] -r [directory]
- 投稿日:2019-07-16T17:21:09+09:00
grepコマンド
grep
grep
は特定の文字列を含むファイルの検索ができる。
xargs
との併用に関しては別スレッド。$ grep [検索正規表現] [option] [directory][検索正規表現] [option]については順不同。
ディレクトリは、例えば現階層のファイル全てから検索であれば
./*
で検索。オプションは主に使うものだけ以下にメモ
#大文字と小文字を区別せず検索 $ grep [検索正規表現] -i [directory] #一致しないものを検索 $ grep [検索正規表現] -v [directory] #行番号と併せて表示 $ grep [検索正規表現] -n [directory] #ファイル名のみ表示 $ grep [検索正規表現] -l [directory] #ディレクトリ内も検索に含める $ grep [検索正規表現] -r [directory]
- 投稿日:2019-07-16T14:23:10+09:00
任意の EDID を Linux Kernel に読み込ませる方法
日本語の情報があまり見つからなかったので記載してみました。
以下のようなニッチなユースケースくらいしかないと思いますので、ほぼ自分用の備忘録になるかと。。。
- ディスプレイが部分的に壊れてEDIDが取得できない
- 強制的に任意の解像度を指定したい
- 仕事で開発中の評価ボード等で何か問題があって、ダミーのEDIDを読ませたい
ただし、Kernel v5.1.5 以前の環境では脆弱性が指摘されている(CVE-2019-12382)ので、
対策されていない環境での利用は推奨しません。なお、2019/6/27 時点で Upstream Kernel (Linus のTree) の master ブランチには
対策パッチが入っていませんでしたが、
DRM Subsystem の drm-next ブランチには対策パッチが入っていましたので、
じきにマージされるはずですし、シンプルな修正の為、容易に Cherry-pick できると思います。確認環境
- Linux Kernel v4.14.75 ltsi
手順
1. menuconfig で CONFIG_DRM_LOAD_EDID_FIRMWARE を有効化してKernel Imageをビルドする
(ビルド手順はこちら)
$ make menuconfig
Symbol: DRM_LOAD_EDID_FIRMWARE [=y] Type : boolean Prompt: Allow to specify an EDID data set instead of probing for it Location: -> Device Drivers -> Graphics support -> Allow to specify an EDID data set instead of probing for it2. Linux Kernel に読み込ませる EDID のバイナリを作成する
CONFIG_DRM_LOAD_EDID_FIRMWARE が有効になると、以下の解像度については
Kernel Image に bulit-in で組み込まれるため、それ以外の解像度を指定したいときに
自分で EDID のバイナリを指定することになります。
- 800x600
- 1024x768
- 1280x1024
- 1600x1200
- 1680x1050
- 1920x1080
作り方については Documentation/EDID/HOWTO.txt もご参照ください。
$ cd ${WORK}/${KERNEL_TREE}/Documentation/EDID/ $ cp 1024x768.S WIDTHxHEIGHT.S $ vi WIDTHxHEIGHT.S $ make作成したバイナリの中身については以下のコマンドで確認できます。
$ edid-decode WIDTHxHEIGHT.bin
例 (クリックすると展開されます)
$ edid-decode 1920x1080.bin 1罹2x袰$YJ% PT兩:q8-@X,E・inux #0 ・=BD 鑅inux FHD Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 31 d8 00 00 00 00 00 00 05 16 version: 01 03 basic params: 6d 32 1c 78 ea chroma info: 5e c0 a4 59 4a 98 25 20 50 54 established: 00 00 00 standard: d1 c0 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 f4 19 11 00 00 1e descriptor 2: 00 00 00 ff 00 4c 69 6e 75 78 20 23 30 0a 20 20 20 20 descriptor 3: 00 00 00 fd 00 3b 3d 42 44 0f 00 0a 20 20 20 20 20 20 descriptor 4: 00 00 00 fc 00 4c 69 6e 75 78 20 46 48 44 0a 20 20 20 extensions: 00 checksum: 05 Manufacturer: LNX Model 0 Serial Number 0 Made week 5 of 2012 EDID version: 1.3 Analog display, Input voltage level: 0.7/0.7 V Sync: Separate Composite Serration Maximum image size: 50 cm x 28 cm Gamma: 2.20 DPMS levels: Standby Suspend Off RGB color display First detailed timing is preferred timing Established timings supported: Standard timings supported: 1920x1080@60Hz Detailed mode: Clock 148.500 MHz, 500 mm x 281 mm 1920 2008 2052 2200 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync Serial number: Linux Monitor ranges (GTF): 59-61Hz V, 66-68kHz H, max dotclock 150MHz Monitor name: Linux Checksum: 0x5 (valid) EDID block does NOT conform to EDID 1.3! Detailed block string not properly terminated
また、PC や 評価ボード側に問題があって EDID が取得できない場合には
別の PC とディスプレイを取得して、 PC がディスプレイから取得した EDID を
そのままバイナリ化しても良いと思います。$ find /sys/devices/ -name edid /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-HDMI-A-2/edid /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-D-1/edid /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-I-1/edid /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-1/edid /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/edid /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1/edid $ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-1/edid > DISPLAY.bin3. 作成したバイナリを Rootfs にコピーする
$ sudo cp WIDTHxHEIGHT.bin ${ROOTFS}/lib/firmaware/edid/WIDTHxHEIGHT.bin4. Kernel の bootargs に "drm_kms_helper.edid_firmware" を追加する
例:
drm_kms_helper.edid_firmware=edid/WIDTHxHEIGHT.bin前述していますが、以下の指定をした場合には EDID が built-in されていますので、
Rootfs にバイナリが無くても動作します。
- drm_kms_helper.edid_firmware=800x600.bin
- drm_kms_helper.edid_firmware=1024x768.bin
- drm_kms_helper.edid_firmware=1280x1024.bin
- drm_kms_helper.edid_firmware=1600x1200.bin
- drm_kms_helper.edid_firmware=1680x1050.bin
- drm_kms_helper.edid_firmware=1920x1080.bin
built-in されるバイナリについては "drivers/gpu/drm/drm_edid_load.c" 内の
"static const char * const generic_edid_name[]" で列挙されています。制限事項 ?
シングルディスプレイの場合には問題ありませんが、
マルチディスプレイ環境で "drm_kms_helper.edid_firmware" を指定してしまうと
全てのディスプレイが指定した EDID を使用してしまうようで、
1つのディスプレイだけ設定したい、ということが出来ないようです。
(仕様なのか私の環境固有の問題なのかは未調査です)
- 投稿日:2019-07-16T14:19:54+09:00
fcitx + mozcで入力中の文字が表示されなくなったときには
TL;DR
Ctrl + Alt + P
でもとに戻るfcitx + mozcで入力中の文字が表示されない
LinuxでのIMEはFcitx + mozcがメジャーかなと思いますが、度々「入力中の文字がプレビューされない」という問題に直面します。
この問題が発生してる人はやっぱりそこそこいるみたいで、調べると「Fcitx XIM Frontendのチェックを外したりつけたりする」とか「
~/.confg/fcitx
を削除して再起動」とか、「fcitxを消して再インストール」とかがヒットします。確かにこれで治ることもあるのですが、治らないこともありなんだかよくわからないうちに治ってたりといまいち原因がわからず毎回トラブルシューティングに時間をかけてしまっていました。
原因
fcitxに「入力中の文字表示をオンオフするショートカット」がありました...
デフォルトでCtrl + Alt + P
に振られており、何かの拍子に押してしまってこの状態になっていたようです。設定の削除だとか再インストールだとかで治ったケースはこのオンオフ状態が初期状態に戻っているから治っていたようで、逆にその状態が維持されたままだと何しても解決しません。
うっかり発動しても困るので、このショートカットを無効化しておきましょう。
Fcitxの設定から
Global Config
タブを選択し、「Show Advance option」にチェックを入れると詳細設定画面になります。
Hotkey
タブに「Switch Embedded Preedit」という項目があるので、ここのショートカットを空にしてOKを押せば二度とこの現象は発生しなくなります。以上で完了です。
おわりに
この機能いる...?
- 投稿日:2019-07-16T09:24:06+09:00
CentOS関係過去記事
■Linuxホスト名変更
https://qiita.com/myabiot/items/4583baa472bd4a630c3c■ntpサーバ(CentOS)と自動同期しない場合の設定
https://qiita.com/myabiot/items/273feef3912666c709d3■CentOS6.7 virtualBOXでクローンを作成したOSがネットワークへ抜けない場合
https://qiita.com/myabiot/items/4aa8a87adae943469f33
- 投稿日:2019-07-16T05:59:08+09:00
【最新サービス試用⑧】リクエスト管理やJSON出力結果整形等に便利なcurl拡張コマンドツールの「curlx」を試用。
- 日々輩出される素晴らしき最新サービスを素早く試して、不鮮明な先見性を堂々と誇示する記事第八弾。
- 歴史的偉人の集中力の記事の、収集作業に精を出している生活。
- 今回は、curlでの出力の際に、Terminal上であらゆる高機能な作業が可能な「curlx」を試用することにしよう。
概要
- レスポンス確認やAPI通信の際の際に用いる「curl」のリクエストの管理が捗るコマンドツール。
- 「JSONでの出力結果の整形」や「リクエストのコレクション(グループ化)」等の機能を、GUIツール等を利用せずに、ターミナル内のみで可能。
- GUIツールの「Postman」やJSON整形コマンドツールの「jq」の両方の機能を備えたようなツール。
- 公式サイト
- 公式Github
特徴
出力結果の整形
- 可読が容易ではないcurlでのJSON出力結果を、cxでは整形して、見やすく表示してくれる。
- jqを利用することなく、標準で整形してくれる。
リクエスト履歴の視覚化
- リクエスト履歴の確認が容易に可能であることに加え、ステータスや通信形式、時間等の詳細情報が表として、わかりやすく確認できる。
リクエストのコレクション(グループ)化
- リクエストをカテゴリごとにグループ化できるため、「よく投げるコマンドのエイリアス登録」や「内容別でのリクエストのグループ管理」が可能。
- Postmanでのコレクション機能を、ターミナル内で利用が可能。
結果
※テストAPIとして、LivedoorさんのWeather Hackを利用。
下記のように、curlでは見づらいjson形式や文字化けが、簡単なコマンドで見やすくなる。
- 通信形式やステータス結果等も含んだ、わかりやすい履歴の表示も可能。
- よく使う出力等を、グループ化で整理して、簡単なコマンドでリクエストが可能。
作業環境
- Amazon Linux 2
- Node.js v10.16.0
- npm 6.9.0
- ※Node.js環境が利用できれば、MacやWindowsでも可能。
インストール
curlxのインストールは、Nodejsのnpmやyarnで可能なため、未導入の場合は、下記を参考にインストールする。
Node.jsのインストール後、下記のコマンドをうち、バージョン確認をする。
# Node.jsのバージョン確認 $ node -v # npmのバージョン確認 $ npm -v
- 確認後、下記のコマンドをうち、「curlx」のインストールを行う。
# curlxのインストール $ sudo npm install curlx -g # バージョン確認 $ cx version基本操作
- curlxの基本操作は、下記。
- ※基本的にcurlコマンドをcxに置き換えるだけで可能。
内容 コマンド 通常リクエスト cx 接続先URL
※オプション指定なしで、ヘッダー出力やjson整形が可能。リクエスト(オプション付き) cx -オプション URL
※オプションは、curlと同様なため、curlをcxに置き換えるだけ。
例 :cx -X GET URL
リクエスト履歴確認 cx history
リクエストのグループ(コレクション)化 cx new collections
実行後、いくつかの質問に回答していく形で、作成していく
詳細は、下記の操作例を確認。作成コレクションへのリクエストの追加 cx new request
コレクション作成同様、質問形式で追加していく
詳細は、下記の操作例を確認。コレクション一覧 cx collections
idやコレクションリクエストでの実行 cx run <id or collection_id>
詳細は、下記の操作例を確認。リクエストやコレクションの削除 cx delete <id or collectionname>
詳細は、下記の操作例を確認。ヘルプページ確認 cx help
バージョン確認 cx version
操作例
通常リクエスト
- 下記のコマンドをうち、URLでの通常リクエストを行う。
- ※オプションは、curlと同様に扱えるため、cxに置き換えるだけでよい。
# 通常リクエスト $ cx http://weather.livedoor.com/forecast/webservice/json/v1?city=471010 # オプション指定でのリクエスト $ cx -X GET http://weather.livedoor.com/forecast/webservice/json/v1?city=471010コレクションの作成〜実行
- 下記のコマンドをうち、cxコマンドをグループ化することで、任意の名前とidでリクエストが可能。
# コレクション(グループ)を作成 $ cx new collection ✔ Name of your new collection … コレクション名(例:getWeather)入力 This collection already exists ✔ Would you like to add a new request to getWeather … リクエスト追加確認(例:yes) ✔ Enter complete request eg: cx -X GET https://httpbin.org/get … 実行コマンド入力(例:cx -X GET URL) ✔ Give a name for your request … リクエスト名(例:getOkinawa) # コレクション一覧確認 $ cx collections ┌────────────┬────────────────────┬────────┬──────────────────────────────┐ │ id │ name │ method │ url │ ├────────────┼────────────────────┼────────┼──────────────────────────────┤ │ y2Q9JCOjL │ getOkinawa │ get │ http://weather.livedoor.com… │ └────────────┴────────────────────┴────────┴──────────────────────────────┘ # id名でのリクエスト実行 # まず、history(履歴)内のid名での実行 $ cx history ┌────────────┬────────┬──────────────────────────────┬────────┬────────────┐ │ id │ method │ url │ status │ timestamp │ ├────────────┼────────┼──────────────────────────────┼────────┼────────────┤ │ H0yIigcQv │ get │ http://weather.livedoor.com… │ 200 │ 2019-7-13 │ │ │ │ │ │ 12:51 PM │ ├────────────┼────────┼──────────────────────────────┼────────┼────────────┤ $ cx run H0yIigcQv { "pinpointLocations": [ { "link": "http://weather.livedoor.com/area/forecast/4720100", "name": "那覇市" }, { # コレクション内のリクエストidでの実行 # ※コレクション内のidは、コレクション名も同時に明記する必要がある。 $ cx run getWeather y2Q9JCOjL { "pinpointLocations": [ { "link": "http://weather.livedoor.com/area/forecast/4720100", "name": "那覇市" },コレクションへのリクエスト追加
- 下記のコマンドをうち、既存コレクションに新規リクエストを追加
# コレクション確認 $ cx collections ┌────────────┬────────────────────┬────────┬──────────────────────────────┐ │ id │ name │ method │ url │ ├────────────┼────────────────────┼────────┼──────────────────────────────┤ │ y2Q9JCOjL │ getOkinawa │ get │ http://weather.livedoor.com… │ └────────────┴────────────────────┴────────┴──────────────────────────────┘ # リクエストの新規追加 $ cx new request ✔ Name of your new collection … コレクション名(getWeather)入力 ✔ Enter complete request eg: cx -X GET https://httpbin.org/get … 実行コマンド(例:cx URL) ✔ Give a name for your request … リクエスト名(getOsaka) # コレクション一覧再確認 $ cx collections ┌────────────┬────────────────────┬────────┬──────────────────────────────┐ │ id │ name │ method │ url │ ├────────────┼────────────────────┼────────┼──────────────────────────────┤ │ y2Q9JCOjL │ getOkinawa │ get │ http://weather.livedoor.com… │ ├────────────┼────────────────────┼────────┼──────────────────────────────┤ │ nG3nzD53k │ getOsaka │ get │ http://weather.livedoor.com… │ └────────────┴────────────────────┴────────┴──────────────────────────────┘リクエストidやコレクションidの削除
- 下記のコマンドをうち、リクエストidやコレクションの削除を行う。
# id名でのリクエスト削除 $ cx delete H0yIigcQv # コレクション内のid名でのリクエスト削除 $ cx delete getWeather:y2Q9JCOjL操作履歴やコレクション確認
- curlxの操作履歴やコレクション一覧は、下記のファイルで確認できる。
- ※curlxの履歴やコレクションといった情報は、ルートフォルダの「cxdb」というフォルダに保存されている。
- ※簡単な履歴やコレクション確認の際は、上記の操作例での操作方法で可能。
# 操作履歴格納ファイルの中身確認 $ less ~/cxdb/history.json { "history": [ { "id": "UsVI7Oq9Y", "method": "get", "command": "curl -i \"http://weather.livedoor.com/forecast/webservice/json/v1?city=471010\"", "url": "http://weather.livedoor.com/forecast/webservice/json/v1?city=471010", "status": "200", "ts": "2019-7-12 11:58 PM" }, { "id": "So_ybzFn3", "method": "get", "command": "curl -i \"http://weather.livedoor.com/forecast/webservice/json/v1?city=471010\"", "url": "http://weather.livedoor.com/forecast/webservice/json/v1?city=471010", "status": "200", "ts": "2019-7-13 12:01 AM" },# コレクション一覧ファイルの中身確認 $ less ~/cxdb/collection.json { "collections": { "getWeather": [ { "id": "y2Q9JCOjL", "name": "getWeather", "method": "get", "command": "curl -i \"-X\" \"GET\" \"http://weather.livedoor.com/forecast/webservice/json/v1?city=471010\"", "url": "http://weather.livedoor.com/forecast/webservice/json/v1?city=471010" }まとめ
- 今回は、curlでのAPI結果整形ということで、「Terminalのみでの利用幅の拡大」による「パソコンの容量削減」を感慨深く染みながら、記事を書く。
- 「利用機能による、GUIツールとCUIツールの併用」の誓いは、すぐさま「日毎の気分利用」に変化することを確信。
- しばらく、この賢人ツールとの付き合いが続くと感じたため、より一層開発者礼拝を強化。
参考
- https://curlx.dev/
→公式サイトです。大変お世話になりました。- https://github.com/shivkanthb/curlx
→公式Githubです。大変お世話になりました。- https://entry.anypicks.jp/product-curlx/
→こちらの記事で知りました。大変お世話になりました。