macOS Catalina から CentOS7.7 へ ssh 接続した際のメモ。

クライアント（macOS）側作業

mkdir -m 0700 ~/.ssh
ssh-keygen

パスフレーズはエンターキーだけ。
すると秘密鍵(id_rsa)と公開鍵(id_rsa.pub)がホームディレクトリ配下の .ssh ディレクトリへ生成される。

~/.ssh
┣ id_rsa
┗ id_rsa.pub

公開鍵をサーバへコピーする。

cd ~/.ssh
scp id_rsa.pub (サーバでのユーザ名)@サーバIP:.

一旦サーバへsshログインする。

ssh (サーバでのユーザ名)@サーバIP

サーバ側作業

公開鍵を登録する。

mkdir -m 0700 ~/.ssh
cd ~/.ssh
cat ~/id_rsa.pub >> authorized_keys
chmod 0600 authorized_keys

サーバに公開鍵認証を設定する。

vi /etc/ssh/sshd_config

次のように修正する。
#PubkeyAuthentication yes
　▼
PubkeyAuthentication yes

sshdを再起動する。

service sshd restart

これでクライアント側からサーバへパスワード認証なしでsshログインできる。

以上。

sqlldrについて

Oracleのsqlldrユーティリティはファイルをテーブルにロードするときに使用します
sqlldrは標準出力に以下のような途中経過を出力するので、実行状況を確認することができます
しかし、ロード件数が多い場合は、あとどのくらいの時間でロードが完了するのか把握できません

SQL*Loader: Release 12.1.0.2.0 - Production on 木 1月 23 14:36:14 2020

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

使用パス:      従来型
コミット・ポイントに達しました。 - 論理レコード件数64
コミット・ポイントに達しました。 - 論理レコード件数128
コミット・ポイントに達しました。 - 論理レコード件数192
コミット・ポイントに達しました。 - 論理レコード件数256
コミット・ポイントに達しました。 - 論理レコード件数320
コミット・ポイントに達しました。 - 論理レコード件数384
コミット・ポイントに達しました。 - 論理レコード件数448
コミット・ポイントに達しました。 - 論理レコード件数512
コミット・ポイントに達しました。 - 論理レコード件数576

そこで、Linuxのpvコマンドを利用して実行状況を監視できないかと考えました

pv コマンドについて

Linuxではpvコマンドが利用できます
pvコマンドはパイプでつながれたコマンドにはさんで実行し、全体のデータ量とパイプを通過したデータ量から現在の状況と完了までの予想時間を表示してくれる便利なツールです

たとえば、大きなファイルをgzipコマンドで圧縮する場合、

$ gzip bigfile

を実行すると、圧縮されたbigfile.gzができます
しかし、実行中は何のメッセージも出力しないので、いつ終わるのかがわかりません

そこで、pvコマンドを利用して、

$ pv bigfile | gzip -c > bigfile.gz

を実行すると、

$ pv bigfile | gzip -c > bigfile.gz
129MB 0:00:15 [92.8MB/s] [===========>                       ] 36% ETA 0:00:31

のように、全体量、経過時間、秒あたりの通過量、現在実行状況（ゲージと％）、残り時間が表示されます

このようにpvは非常に便利ですが、パイプを通過するデータ量を監視するので、パイプでつながれたコマンド形式にしか対応できません

sqlldrとpvをつなげる

前述のとおり、sqlldrは現在、何件ロードしたかを標準出力に書き出しています
この件数の部分だけをとりだして、pvにパイプで渡すことができれば、何とかなりそうです

実行状況がわかればいいので、ロードするバイト数ではなく、レコード件数で十分です
そこで、簡単なawkを実行するシェルスクリプト作成し、sqlldrの標準出力を読み取り、件数に相当する文字数を出力するようにしてみます

loadcount

#!/bin/bash
awk -F'件数' '
BEGIN { SV = 0; }
NF==2{
    for (i = 0; i < $2 - SV; i++) {
        printf("1");
    }
    SV = $2;
}'

このスクリプトは実行可能にする必要があるので、エディタで保存後に実行権を与えます

$ chmod +x loadcount

処理内容は以下の通りです
・「件数」という文字列を区切りとして、フィールド数（NF）が２のとき（＝ｘｘｘ件数ｙｙｙとなっているとき）の「件数」の
後ろの文字列を取り出します（$2）
・前回取り出した件数との差分の数だけ「1」という１バイトの文字を出力しています
つまり、sqlldrが1000レコードロードすると、「1」が1000個出力されます

pvコマンドは入力がパイプの場合、全体量がわからないので、その場合は-sオプションで全体量を指定することができます
この場合の全体量はロード対象ファイルのレコード件数になります
レコード件数（行数）はwcコマンドを使って得ることができます

$ wc -l ファイル名

最終形は以下のようになります

$ sqlldr USER/PASS@SID control=t1.ctl | ./loadcount | pv -p -t -e -s `cat t1.csv|wc -l` > /dev/null
0:00:20 [========>                                            ] 17% ETA 0:01:33

・USER/PASS＠SIDはOracleに接続するための記述子です
・t1.ctlはsqlldrの入力制御ファイルです
・t1.csvはロード対象のデータファイルです

うまくsqlldrの実行状況監視をすることができました

PATHとは？

Linuxに限らず、コマンドを実行する際にフルパスを書く必要がないのはPATHにそのパスの情報が保存されているからです。例えば、Linuxをシャットダウンする際に/usr/sbin/shutdown -h nowではなくshutdown -h nowと書いて実行できるのは、/usr/sbin/がPATHに登録されているからです。

PATHの確認方法

以下を実行。

echo $PATH

実行結果：

自分の場合、いじったのでこうなっています。PATHは何個でも登録してもよく、:で各パスに区切られています。

バージョンが違う同じソフトウェアを入れた時の対処

例えばCentOS7だとディフォルトでpython 2.7が入っています。python --versionを実行すると、そのバージョン情報が出てきます。
ここで、新たに以下のコマンドを叩きRed Hut Enterprise Linuxを使用してpython 3.6を落としてくるとします。

sudo yum -y install centos-release-scl;
sudo yum -y install rh-python36;
sudo scl enable rh-python36 bash;

この後にpython --versionを実行すると、python 3.6を見ていますが、Vagrantの操作等でパスを再度読み込んだ際に元に戻ってしまいます。これはRed Hut Enterprise Linuxで落としたpython 3.6が/usr/binには行かずに/opt/rh/rh-python36/root/bin/へ落ちるためです。この/opt/rh/rh-python36/root/bin/をPATHへ登録し、/usr/binにあるpython2.7を取り除かない限りは綺麗にpythonのバージョンアップができません。ちなみにLinuxが参照しているpythonのパスは以下のコマンドでわかります。

which python

pythonに限らず、なんでもこのwhichでLinuxが参照しているコマンドの実際のパスがわかります。

python2.7など、古いバージョンのプログラムを取りのぞくときは、rmコマンドで削除するより、mvコマンドで名前を変えて取り置いといた方がいいです。以下Pythonの例をとった時のコマンドです。

sudo mv /usr/bin/python2.7 /usr/bin/python2.7_old

これでLinuxがPython2.7を退避することができます。

PATHの変更方法

いくつかあると思いますが、自分が好きなのはsourceコマンドで~/.bash_profileというファイルを取り込む方法です。~/.bash_profileにはPATHの情報があり、source　~/.bash_profileを実行することでPATH登録が行われます。シェルスクリプトでこれを実行する人に注意して欲しいんですが、この~がどこなのかスクリプト内に明記しておくべきです。というのもルートユーザーと一般ユーザーでは~の部分が違います（動画参照）。

Vagrantfileにシェルを仕込ませて実行した場合、~がどちらを向いてるか自分はわからなかった（vagrant provisionを行うと実行ユーザーはvagrantなのに~は/root/側を見ているようだった）ので、明記しました。

結果、以下のコマンドでPATHを読み込ませました。

#/home/vagrant/.bash_profileにPATH情報を設定
echo "export PATH="/opt/rh/rh-python36/root/bin:/usr/bin:/usr/sbin"" >> /home/vagrant/.bash_profile;
#PATH情報を登録
source /home/vagrant/.bash_profile;

最後に

上記のステップを押さえておけば、どんなソフトウェアでも問題なくバージョンアップが可能です。
自分はsqlite 3.2をsqlite 3.29へ同じアプローチでバージョンアップできました。

参考

https://teratail.com/questions/50308
https://qiita.com/nito128/items/e91e8510c882a7f24768

はじめに

tmuxのstatuslineのホスト名を変更しようとしたときに少し嵌ったのでメモ。

やり方

現在のhostnameを確認する

hostnamectl

hostnameを変更する

hostnamectl set-hostname 'new_hostname'

ディレクトリとファイルサイズの下限(ex. 500M)を指定する。

find {ディレクトリ} -size +{ファイルサイズ} | xargs ls -lh | sort -rn

ファイルを見つける

ディレクトリとファイルサイズの下限(ex. 500M)を指定する。

find {ディレクトリ} -size +{ファイルサイズ} | xargs ls -lh | sort -rn

ディレクトリを見つける

du {ディレクトリ} -h -d 1 | sort -h

chromeDevoolのコンソール
エラーメッセージ

GET ~image_name~.jpeg 403 (Forbidden)

• このリンクから情報収集

私はあなたが経験しているこの403の問題が共有ホスティングに置かれていると推測しています。

シンボリックリンクを作成するphp artisan storage:link、にはstorage/app/public`フォルダーへの完全な絶対パスが含まれます。これがおそらくサーバーによる403応答の原因です。

解決策は、プロジェクトルートからの相対パスでシンボリックリンクを作成することです

シンボリックリンクに関する操作（linux）の参考

解決　

• `php artisan storage:link でつくったシンボリックリンクを削除

• ln -s ../storage/app/public public/storage
  

上記で貼り直し
実行する階層に注意

理由

• 上に書いてある通りの原因だった
• 一番上のリンクに一通り原因が書かれてるっぽい
• autloaderがよみに行かないくらい上から書かれてたから403エラーだったってことでいいのかな

https://github.com/chriskempson/base16-xfce4-terminal

$ git clone https://github.com/chriskempson/base16-xfce4-terminal
$ cd base16-xfce4-terminal
$ ./convert2themes
$ sudo cp themes/*.theme /usr/share/xfce4/terminal/colorschemes/

トラブルの内容はタイトルの通り

状況

2020年1月22日に出たRHEL8.2 Betaをインストールしようとして問題に遭遇

8.2 Release Notes Red Hat Enterprise Linux 8-beta | Red Hat Customer Portal

インストーラーを起動して実行すると下記のようなエラーが表示されて進まない

環境

• ESXi: 6.7.0 U2
• 仮想マシン設定
  • 起動モード: EFI
  • Secure Boot: 有効
• RHEL8.2 Beta
  • ISO: rhel-8.2-beta-1-x86_64-dvd.iso

その後確認すると、RHEL8.0 Betaでも同様の問題が発生。以前から既知の問題の模様。

原因

RHEL8のベータリリースでは、UEFIセキュアブート用の公開キーを追加する必要があるため

第7章 UEFI セキュアブートを使用したベータシステムの起動 Red Hat Enterprise Linux 8 | Red Hat Customer Portal

UEFI セキュアブートでは、オペレーティングシステムカーネルが、認識された秘密キーで署名されている必要があります。Red Hat Enterprise Linux 8 のベータリリースの場合、カーネルは Red Hat ベータ固有の秘密キーで署名されます。UEFI セキュアブートは、対応する公開キーを使用して署名を検証します。

Red Hat Enterprise Linux 8 のベータリリースは、ハードウェアがベータの秘密鍵を認識しないと起動できません。ベータリリースで UEFI セキュアブートを使用するには、MOK (Machine Owner Key) 機能を使用して Red Hat ベータ公開キーをシステムに追加します。

対処

セキュアブートを無効にしてインストールする。

7.2. UEFI セキュアブート用のカスタム公開キーの追加 Red Hat Enterprise Linux 8 | Red Hat Customer Portal

前提条件

• システムで UEFI セキュアブートを無効にします。
• ベータ版の Red Hat Enterprise Linux 8 リリースをインストールします。インストールプロセスが完了すると、システムが再起動します。セキュアブートは引き続き無効にする必要があります。システムを再起動してログインし、該当する場合は 初期セットアップ ウィンドウでタスクを完了します。

インストール後、無効にしたセキュアブートを有効化したい場合は、上記のリンクの手順に則ってセキュアブート用の公開キーを追加する必要がある。

まとめ

セキュアブートが有効な環境でRHEL8.2をインストールする場合は、無効にしてインストールする必要が分かった。以前、RHEL8.0 Betaをインストールしていたがその時はあまり深く考えずに対処していた可能性があるので、今回あらためて内容を整理してみた。
ベータリリースなので長期運用する必要がない場合は無効のままでもよいと思うが、セキュリティ面でのテストなどを行う場合は有効化することが望ましい。

参考リンク

• Installation of RHEL8 on UEFI system with Secure Boot enabled fails with error 'invalid signature' on vmlinuz. - Red Hat Customer Portal
  ベータリリースとは書いていないが、エラー内容はほぼ同じ

• 5.9. UEFI セキュアブートによるベータリリースの使用 Red Hat Enterprise Linux 7 | Red Hat Customer Portal
  セキュアブートに対応したRHEL7ベータリリースから同様の内容がドキュメントに記載有り

• 25.11. Unified Extensible Firmware Interface (UEFI) セキュアブート Red Hat Enterprise Linux 7 | Red Hat Customer Portal
  セキュアブートの説明（RHEL7）

• UEFI セキュアブートによる制約 - Red Hat Customer Portal
  セキュアブートに関するナレッジベース（RHEL7）

macOS から Windows に戻ってきて、「コマンドプロンプトかー、せめて PowerShell だよな」ということで PowerShell Core を使っていたのですが、そういえば WSL(Windows Subsystem for Linux) があったな、と思い出して、開発環境は全面的に WSL を使っていくことにしましたので、その手順をメモしておきます。

なおここで言う開発環境とは、Webアプリのフロントエンドを Angular で、バックエンドを node.js で開発することを指します（また、実際のところ Linux にはあまり詳しくないので、WSL とディストリとシェルを混同して表記している自信があります）。

1. WSL の導入

• 【WSL入門】第1回　Windows 10標準Linux環境WSLを始めよう：ITの教室 - ＠IT

を参考に、WSL を導入します。

2. Windows Terminal の導入

Windows Terminal は Windows 向けのターミナルクライアントで、現在はまだ Preview 版ですが、なかなか使いやすくカスタマイズ性も高いので愛用しています。

• Windows Terminal (Preview) を入手 - Microsoft Store ja-JP
• Windows Terminal (Preview) メモ - Qiita

WSL をインストールすると、Windows Terminal にも「Ubuntu」という Profile が増えます。
Windows Terminal を起動したときに、Ubuntu の Terminal がデフォルトで開かれるようにするには、「ctrl + ,」を押して profiles.json を開き、defaultProfile を変更します。

他にも、

• colorScheme を設定して見やすい色に変更
• startingDirectory で初期のディレクトリを設定
• keybindings を追加して ctrl+c と ctrl+v でコピペできるように(既定では ctrl+shift+c/v)

を変更しています。Windows Terminal はこの profiles.json を編集することでいろいろカスタマイズできるので楽しいですね。参考までに私の設定を載せます。

profiles.json

{
    "$schema": "https://aka.ms/terminal-profiles-schema",

    "defaultProfile": "{2c4de342-38b7-51cf-b940-2309a097f518}",

    "profiles":
    [
        ＜中略＞
        {
            "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
            "hidden": false,
            "name": "Ubuntu",
            "colorScheme": "Campbell",
            "cursorShape": "emptyBox",
            "acrylicOpacity": 0.85,
            "useAcrylic": true,
            "cursorColor": "#FFFFFF",
            "fontFace": "Cascadia",
            "fontSize": 12,
            "startingDirectory": "C:\\dev",
            "source": "Windows.Terminal.Wsl"
        }
    ],
    "schemes": [
        {
            "name": "Campbell",
            "foreground": "#F2F2F2",
            "background": "#0C0C0C",
            "colors": [
                "#0C0C0C",
                "#C50F1F",
                "#13A10E",
                "#C19C00",
                "#0037DA",
                "#881798",
                "#3A96DD",
                "#CCCCCC",
                "#767676",
                "#E74856",
                "#16C60C",
                "#F9F1A5",
                "#3B78FF",
                "#B4009E",
                "#61D6D6",
                "#F2F2F2"
            ]
        }
＜中略＞
    ],

    // Add any keybinding overrides to this array.
    // To unbind a default keybinding, set the command to "unbound"
    "keybindings": [
        { "command": "copy", "keys": [ "ctrl+c" ] },
        { "command": "paste", "keys": [ "ctrl+v" ] }
    ]
}

3. VScode の Default Terminal を WSL に

WSL を導入すると Visual Studio Code の Terminal にも "wsl" が増えているので、ctrl + shift + p → Terminal:Select default shell で、"wsl" に変更します。

なお、.code-workspace に Terminal を指定することでワークスペース毎に Terminal を切り替えることもできるようですが、wsl が入っていない環境もあるので、私はあまりオススメしません。

4. VSCode のタスク実行を WSL で

VScode の Default Terminal を WSL に変更しても、VScode のタスクの実行は、Windows 側で行われてしまうようで、これも WSL 上で実行させたいです。残念ながらこれを解決するには「WSL に依存したタスク」の記述が必要になります。

./vscode/tasks.json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "ng-serve",
      "type": "shell",
      "isBackground": true,
      "command": "ng serve",
      "problemMatcher": {
        "owner": "custom",
        "pattern": {
            "regexp": "^$"
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": ".*Angular Live Development Server.*",
          "endsPattern": ".*Compiled successfully.*"
        }
      }
    },
    {
      "label": "ng-serve-wsl",
      "type": "shell",
      "isBackground": true,
      "command": "\"ng serve\"",
      "options": {
        "shell": {
          "executable": "C:\\Windows\\System32\\wsl.exe",
          "args": [ "bash -ic" ]
        }
      },
      "problemMatcher": {
        "owner": "custom",
        "pattern": {
            "regexp": "^$"
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": ".*Angular Live Development Server.*",
          "endsPattern": ".*Compiled successfully.*"
        }
      }
    }
  ]
}

例えば、上記の tasks.json の例では、Angular のデバッグを行うための ng-serve というタスクを定義していますが、これは Windows 上で動作してしまうので、それに加えて WSL 上で動作させる設定を加えた ng-serve-wsl というタスクも用意しています。

WSL版の違いは、options: { } で設定した wsl.exe の情報で、これはコマンドプロンプトで、

wsl.exe bash -ic "ng serve"

を実行することに相当します。
重要なのは bash の実行引数 -i で、これを指定しないと .bashrc が読み込まれない(= PATH が設定されない)ため、ng が command not found エラーになってしまいます。

5. WSL 側に開発環境を構築する

git, node, npm, angular, python, aws-cli, firebase-cli などの開発に必要なツールは、WSL の方に入れていきます。
Ubuntu であれば大抵は apt-get でインストールします。

まとめとちょっと面倒(冗長)なところ

WSL2 まで待っていようかなと思っていたのですが、WSL1 でも使ってみたらとても便利でした。

開発時によく使う Terminal, VSCode については、ほとんど Windows である事を意識せずに過ごす事ができるようになりました。
スクリプトなどは macOS と同じものがほぼ動きますし、Linux で動作する CI のリハーサルも容易になりました。

Windows との相互運用性が思っていたよりも高く、コマンドに .exe をつければ WSL 上からでも Windows コマンドが実行できるので、かゆいところに手が届いてるなと感じました(WSL から msbuild.exe を叩けば Windows でしか動作しない .NET アプリもビルドできるはずだし、そもそも WSL 側に .NET Core を入れてクロスプラットフォームで動作する .NET プログラムの動作確認をする事ももちろん可能です)。

ちょっと冗長なところとしては、

git の認証情報を Win/WSL どちらにも記憶させる必要がある

bash で git コマンドを叩くこともあれば、Gitクライアントアプリ(GitKraken や VSCode など)を使うこともあり、認証情報ストアを共通にする方法は知らないので、今のところ両方に記憶させています。

Windows パスから UNIX パスへの変換

「Windows のエクスプローラでパス名をコピーして、bash で cd する」ために、次のようなコマンドが必要です。

cd $(wslpath -u "C:\dev\hoge")

Windows のパス文字列を wslpath 関数で UNIX パスに変換できるので、これを咬ませてディレクトリ移動しています。

チームの他のメンバは Windows の人が多い

ため、彼らの環境でも動作する事を前提にスクリプトを記述する必要がある場合、その動作確認のために PowerShell も併用し、結局 Windows 側にも node をインストールせざるを得なかったりします。
まあ、これはチームの事情です。
それでも、Windows Terminal は、タブで WSL と PowerShell どちらも管理できるので使いやすいです。

別解というか本命

VSCode 前提ですが、Remote - WSL Extension を利用することで、プロジェクトの開発をすべて WSL上 で行えるようになります。上記で説明した Terminal も、タスクの実行もすべてです。

• Get Started with C++ and Windows Subsystem for Linux in Visual Studio Code
• Developing in the Windows Subsystem for Linux with Visual Studio Code

現在はまだ Preivew 版のため安定性が不安であること、リモート前提なため WSL でもなんか遅そう(主観です)な事、VSCodeの拡張機能がモノによってはリモート用をさらにインストールする必要があるなど、やや気になる点があるために少し試しただけで保留としました。

Route::get('/', function () {
    return view('welcome');
});

Route::get('/diary','DiaryController@index')->name('dialy.list');
Route::get('/diary/{id}','DiaryController@show')->name('diary.show');

こんな感じで色変えれるんですね！
なんかすごい。
プログラマーの道を一歩一歩進んでる感じ。