screenコマンドとは tmuxに似ていて、以下の用途で使える。 ・ セッションの保存（sshで長時間のジョブを実行するときに助かる） ・ 画面の分割 MacでもLinuxでも大抵デフォルトで入っているらしい。 逆にtmuxは追加で入れないといけないので、できればscreenに慣れておきたい。 一連の流れ 以下は全てUbuntuで実行。 セッション管理 セッション一覧を確認 $ screen -ls No Sockets found in /run/screen/S-user1. セッションを作成（＋自動的にセッションに入る） $ screen -S hoge 今セッションの中にいるのかどうかチェック $ echo $TERM # "screen*"だったら内部にいる screen.xterm-256color $ echo $STY # セッション内部のときだけ存在する環境変数 3023174.hoge セッション内部ではctrl-a <cmd> でscreenコマンドを実行することになる。 もともとのctrl-a（カーソルを先頭に移動）はctrl-a aで実行できる。 セッションを抜ける ctrl-a d 一覧を確認してみる $ screen -ls There is a screen on: 3023174.hoge (08/09/2021 05:25:41 PM) (Detached) 1 Socket in /run/screen/S-user1. セッションに入る（以下のどれでもオッケー） $ screen -r 3023174.hoge $ screen -r hoge $ screen -r 3023174 セッションの削除 $ screen -X quit # 今いるセッションを削除して元のターミナルに戻る $ screen -S hoge -X quit # セッション外部にいて、セッション"hoge"を削除する 画面分割 画面分割 ctrl-a S # 水平 ctrl-a | # 垂直 画面移動 ctrl-a tab 虚無の画面に新規ウィンドウ作成（分割でできた新規画面に移動したらまずこれ） ctrl-a c 分割された画面の削除 ctrl-a X # 小文字のxだと画面ロックになるので注意 Tips マウスでスクロールするなら。 $ cat ~/.screenrc termcapinfo xterm* ti@:te@ defscrollback 100000 ctrl-aからctrl-jに変更。 $ cat ~/.screenrc escape ^Jj
0 はじめに ・Webアプリでは、調査のためアプリが動いている本番サーバーに アクセスしたときのログやエラーになったときのログを作成し、 ログがたまったらgzファイルにして格納していることがあります。 そんなgzファイルを展開して、エラーの種類やそのエラーの 出現回数を調べるやり方の例です ・今回は、アプリのサーバーのOSがLinux(CentOS)だった時の例です。 1 ログのディレクトリ構成 ログのディレクトリ構成 /apuri |-log |-apuri_20210730.log.gz # 1日経ったらgzに変更するように設定されているとします |-apuri_20210730.log.gz |-apuri_20210731.log.gz |-apuri_20210801.log.gz |-apuri_20210802.log.gz |-apuri_20210803.log.gz |-apuri_20210804.log.gz |-apuri_20210805.log.gz |-apuri_20210806.log.gz |-apuri_20210807.log.gz |-apuri_20210808.log.gz |-apuri_20210809.log 2 ログの中身 ・ログは項目ごとにタブ区切りで出力されているとします ・項目は以下の通り 1項目目:ログ出力日付 2項目目:ログ出力時刻 3項目目:アクセスURL 4項目目:IPアドレス 5項目目:HTTPステータスコード 6項目目:エラー種類 7項目目:エラーの内容 8項目目:アクセスしたユーザー ※下記、項目間は半角スペースですが、実際はタブで区切りになっていることにします apuri_yyyymmdd.log 2021/08/09 01:11:12 apuri/login.php 192.168.100.131 500 loginError ログインに失敗しました rinchome 2021/08/09 01:15:12 apuri/selectUser.php 192.168.100.130 500 selectError ユーザー情報取得に失敗しました rinchome 2021/08/09 01:15:13 apuri/selectUser.php 192.168.100.133 500 selectError ユーザー情報取得に失敗しました rinchome2 2021/08/09 01:15:16 apuri/selectUser.php 192.168.100.133 500 selectError ユーザー情報取得に失敗しました rinchome3 3 エラーの種類やそのエラーの出現回数を調べるコマンド ・今回は2021年07月と08月のエラーの種類とその出現回数を取得 ・コマンド上で出力する項目は、6項目(エラー種類)と7項目(エラーの内容)とする $ zcat /apuri/log/apuri_202107*.log.gz /apuri/log/apuri_202107*.log.gz | awk 'BEGIN {FS="\t"} {print $6 "\t" $7}' |sort |uniq -c # 上記、sortコマンドはオプション指定しない場合は、行単位で並び替えてくれる # 上記、uniq -c で重複している内容の出現回数をカウントし、表示する 4 実行結果イメージ loginErrorのエラーが1回出現 selectErrorのエラーが3回出現 した場合 $ zcat zcat /apuri/log/apuri_202107*.log.gz /apuri/log/apuri_202107*.log.gz | awk 'BEGIN {FS="\t"} {print $6 "\t" $7}' |sort |uniq -c 1 1 loginError ログインに失敗しました 3 selectError ユーザー情報取得に失敗しました
概要 いつもログインに使ってるPCが故障した，誤ってクライアント側の鍵ファイルを削除してしまったなどして，サーバーから締め出されてしまった．．．といった際に使用できる対処法を紹介します． 公開鍵認証でしかログインできなくする方法はこちら 環境 サーバー(ホスト) : Ubuntu 20.04 LTS (ConoHa VPS) 留意事項 これからお読みいただくと分かる通り，ConoHa VPSではSSHを使用しなくてもブラウザ上でコンソールが使えます．つまり，ConoHaのパスワードとサーバーのsudoを持ったユーザーのIDとパスワードが割れると乗っ取られます．ConoHaアカウントには二段階認証を設定しておくことをお勧めします． 【事前準備】の作業は，サーバーから締め出された後でも，ConoHaのコントロールパネルからVPS管理画面に進み，ブラウザコンソールを使うことで実施することができます． 事前準備: 非常用ユーザーの作成とパスワード認証の例外的許可 公開鍵認証でログインできなくなった際に使うための非常用のユーザーを作成します． sudo権限は持たせない このユーザーのみ例外的にパスワード認証を許可 SFTP専用で，自分のホームディレクトリにのみ接続できるようにする． 通常時はこのユーザーを使ったSSH接続を拒否するようにする． sudo権限を持ったユーザーでサーバーにログインし，非常用のユーザーを作成します．<username>は使いたいユーザー名に置き換えてください． sudo adduser <username> パスワードを二回聞かれますので，使いたいパスワードを入力し次へ進んでください． その後，ユーザーのプロフィールに関する質問(フルネームや電話番号など)を聞いてくる場合がありますが，空欄のまま全部スキップしてください．最後に Is the information correct? と聞かれたら，Yesと入力して完了です． 次に，サーバー側のSSH設定を変更します．ターミナル上で使えるテキストエディタを，サーバーに用意しておいてください．(ここではVimを使っています) sudo vim /etc/ssh/sshd_config configファイルの末尾に以下を追加してください．DenyUsersは既に指定している場合は，既存の行に,<username>を付け加えてください．DenyUsersを設定することで通常時はログインができないようにします．そうしないと，パスワードが破られた際に，SFTPで大量のファイルをアップロードされサーバーを破壊される可能性があるためです．また，SFTP限定にしているのもsudoを与えてないとはいえ何かしらのコマンドを実行されるのを防ぐためです． Match User <username> PasswordAuthentication yes ForceCommand internal-sftp DenyUsers <username> サービスを再起動すると設定が反映されます． sudo systemctl restart sshd [1] クライアント側で鍵ペアを生成 こちらは省略します． [2] 非常用ユーザーのログインを許可 ConoHa コントロールパネルからVPSの管理画面に進み，「コンソール」をクリックしてください． コンソールに入ると以下のような表示になると思います． ※ブラウザコンソールは，ブラウザのウインドウを最大化するか全画面表示にして利用することをおすすめします． <VPSのIPアドレス> Login: ここで，sudo権限を持ったユーザー名(いつもログインに使用してるユーザー名)を入力し改行します．パスワードを聞かれるのでログインします． テキストエディタ(Vim等)で /etc/ssh/sshd_config を開き，DenyUsersをコメントアウトします．(もしくはDenyUsersから非常用ユーザーを除外します) #DenyUsers <username> サービスを再起動すると設定が反映されます． sudo systemctl restart sshd ConoHaのコンソールはいったん切断します．exitでログアウトしたらウインドウを閉じてください． [3] 公開鍵ファイルをアップロード SFTPに対応したFTPクライアントで，先ほどの非常用ユーザーでログインし，/home/<username> に公開鍵ファイルをアップロードします． [4] 公開鍵を既存のユーザーに追加 再びConoHaのブラウザコンソールを開き，普段サーバー管理に使っているユーザーでログインします．次に，以下のようなコマンドを実行してください． sudo mv /home/<username>/<公開鍵ファイル> ~/. cat <公開鍵ファイル> >> .ssh/authorized_keys rm <公開鍵ファイル> sudo systemctl restart sshd SSHクライアントから，公開鍵認証でログインできることを確認してください． 後始末: 非常用ユーザーのログインを拒否 全ての作業が終了したら，sshd_configファイルを開き，DenyUsersを再度有効化してください．
今回の目標 ・MacからMicrosoft Remote Desktopを使用してラズパイにアクセスできるようになる 他の記事はこちら スマートホーム目指してラズパイ触ってみた(1) 〜ラズパイ４+SenseHatセットアップ編〜(Qiita) スマートホーム目指してラズパイ触ってみた(3) 〜LINE連携＆温度通知編〜（Qiita） スマートホーム目指してラズパイ触ってみた(4) 〜Amazon S3 (AWS CLI)連携編〜（Qiita） スマートホーム目指してラズパイ触ってみた(5) 〜Amazon S3 + QuickSight連携編〜 （Qiita） Step１ ラズパイをさわるのに毎回HDMIケーブルやら有線キーボードを接続するのは面倒・・・ということで、MacからRemoteDesktopでアクセスできるようにします。 ラズパイ側でソフトウェアのインストールが必要になるので、ターミナルを起動し、以下のコマンドを実行します。 sudo apt-get install xrdp sudo service xrdp restart インストールが完了したら、 ラズパイのターミナルでifconfigを実行し、ラズパイのIPアドレスを確認する リモートデスクトップのアプリから、ラズパイのIPアドレスを指定してリモートデスクトップ接続します。 私はMacから接続したかったので、こちら(Mac版のMicrosoft Remote Desktop)を使いました。 ※ラズパイと自分のPCが同じWifiに接続してないと（所属するネットワークが異なるため）、リモートデスクトップ出来ないので注意です。 PC name: ラズパイのIPアドレス（Wifi接続用） User Account: pi (ラズパイのデフォルトrootユーザー) Password: ラズパイのパスワード 私の設定画面はこんな感じです。 参照記事
(夏休み企画 6/20) キッズも参加する、ワークショップ用のマウス。 小さな手でも扱える小型マウス 有線接続 安価 丈夫 しかしながらさすがにキッズの荒行下ではマウスは消耗品。 特にあるのが、ケーブルの断線。 今回は、ケーブルが断線した場合の修理をしてみます。 環境 マウス Fujitsu M520 msi M1232 aigo Q805 リールマウス Ubuntu 20.04 LTS Linux (トラブルシューティングに使います) 準備するもの 壊れたマウス Linux マシン USB A プラグ ないし USB A ケーブル はんだごて トラブルシューティング Linux マシンでターミナルを開き、以下のようにしてカーネル出力をモニターします。 $ dmesg -w マウスをUSBにつなげます。正常な場合、以下のように出てきます。 [407606.892466] usb 1-1.2: new low-speed USB device number 24 using ehci-pci [407607.006939] usb 1-1.2: New USB device found, idVendor=1bcf, idProduct=0007, bcdDevice= 0.14 [407607.006944] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [407607.006947] usb 1-1.2: Product: USB Optical Mouse [407607.014486] input: USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1BCF:0007.000D/input/input22 [407607.014755] input: USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1BCF:0007.000D/input/input23 [407607.014980] hid-generic 0003:1BCF:0007.000D: input,hiddev0,hidraw0: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:1a.0-1.2/input0 何も出なかったら、断線しているか、内部の回路が壊れています。 そして、大体は断線が原因です。 断線を直す 有線マウスが断線するところは大体2箇所です。 ここと ここ。 どっちが断線しているのでしょうか？ 簡単に調べる方法としてケーブルを少し引っ張ってみます。本来であればしっかりと引っ張る力に抵抗がありますが、 断線している場合は抵抗が小さい箇所があり、少し力を入れるとちぎれてしまいます。 この例では、USB A プラグの根元で断線していたようです。 この場合、ケーブルを剥いて新しいコネクタに繋ぎ直します。 根元が断線していた場合は、ケーブルを交換します。 ケーブルを剥く 内部の信号線を出してみます。 USB 内部の色は本来は以下のようになっていますが 信号 USB規定色 5V 赤 D- 白 D+ 緑 GND 黒 今回例にした3つのマウスでは、マウスによってバラバラでした。 信号 Fujitsu M520 msi M1232 aigo Q805 リールマウス 5V 赤 赤 白 D- 白 緑 赤 D+ 緑 青 青 GND 黒 白 緑 Fujitsu M520だけ規格どおり、あとはデタラメですね！ このように、どれがどれかというのは都度都度テスターなどで確認する必要があります。 コネクタをつける このようなコネクタを用意しました。 Fujitsu M520の場合は標準の色配置なので、シールドと共に以下のように結線します。 コネクタの配置は写真では下から 5V,D-,D+,GND の順番です。 PWE線だった場合 PWE線というのは細い銅線1本1本にポリウレタン塗装がなされているものです。マウス用途の場合はPWEを使ったストランド線になっていて芯線に樹脂繊維、側線に8本(aigo Q805)ないし 10本(msi M1232) のPWE線の構成になっています。 樹脂繊維を丁寧に分けて 繊維を切り去ってからPWE部分のみにはんだづけします。 コネクタにはんだづけします。 ケーブルを交換する場合 マウス本体側近くで断線していた場合などはケーブルを交換します。 携帯用 USB ケーブルはよく携帯接続側コネクタが破損しますが、その場合 USB A コネクタとケーブルは正常なのでそういったケーブルを流用します。 内部を開けて、基板にケーブルを接続します。 ※注意！ ホイールを壊さないように！ 今回の作例では、内部を開けた時にホイール軸を折ってしまいました。折ったことに気づかずに、ケーブル断線の修理完了後気がついて、結局マウスは使えなくなってしまいました。 aigo Q805 リールマウスの基板の場合、 V 5V G GND C D- D D+ でした。 今回の USB ケーブルは標準色に近かったので以下のように配線し、組み直しました。 テストと仕上げ dmesg でちゃんと認識しているかな？ 確認。 うまくいったら、コネクタのカバーを付けて、完成です。
はじめに 本記事ではVagrantで作成した環境(Box)を複製する手順を記載します。 複製手順は下記です。 パッケージ化 パッケージ化したBoxを登録 Vagrantfile作成 Vgrantfile編集 起動 1. パッケージ化 複製したいVagrantfileがあるディレクトリに移動します。 下記コマンドでboxのパッケージ化を実施します。 実行が完了すると現在ディレクトリに XXX.boxファイルが生成されます。 パッケージ化 $ vagrant package --output [任意のbox名].box 2. パッケージ化したBoxを登録 複製後のVagrantfileを配置するディレクトリに移動し、XXX.boxファイルを配置します。 下記コマンドでBoxを登録します。 Box登録 $ vagrant box add [任意のbox名] [パッケージ化したbox名].box Box登録確認 $ vagrant box list [パッケージ化したbox名] (virtualbox, 0) # 表示されていればOK 3. Vagrantfile作成 下記コマンドで登録したBoxのVagrantfileを作成します。 現在ディレクトリにVagrantfileが作成されていることを確認してください。 Vagrantfile作成 $ vagrant init [登録したBox名] 4. Vgrantfile編集 複製元のVagrantfileと比較し、変更が必要であれば変更してください。 不要の場合は次へ進む。 ※複製元と複製した仮想マシンを同時に起動した場合、private_networkのIPアドレスやポートフォワーディングのポートなどが同じだとエラーになり起動に失敗します。 5. 起動 下記コマンドでvagrantを起動します 起動 $ vagrant up
