痛いところは煙に巻く

製造業のしがない社内SEが日記代わりにいろいろ書く

Hello,World

Üben Sie es nur recht fleißig, so wird es schon gehen

プロキシ環境下でElasticsearchのプラグインがどうしてもインストールできない

おはこんばんにちわ、ビショップです。

あまりの忙しさとネタのなさに久々の更新。

また今度記事に書こうと思うのですが、Amazon Linux 2023にWikiツールのGROWIをインストールしています。公式ですとdocker-composeによるインストールを推奨していますが、どうしても弊社のプロキシ環境下において、Elasticsearchのプラグインがインストールできないという現象に当たりました。ES_JAVA_OPTSといった環境変数等の設定も試してみましたが、どうしてもうまくいかない。
ということで、やむを得ず、レガシーではありますがCentOSでのインストール方法を参考に各ツールを個別にインストールして構築しました。

環境

  • Amazon Linux 2023
  • Elasticsearch 8.x

とはいえ、個別のインストールを実行しても、結局Elasticsearchのelasticsearch-pluginコマンドを使用してのプラグインのインストールができず、結局オフラインインストールをすることになりました。残念。
今回インストールするプラグインは、次の２つです。

  • analysis-kuromoji
  • analysis-icu

とりあえず公式にあるダウンロード用のリンクを使ってダウンロードします。
今回は２つともtmpフォルダにダウンロードします。

wget -P /tmp https://artifacts.elastic.co/downloads/elasticsearch-plugins/analysis-kuromoji/analysis-kuromoji-8.12.0.zip 
wget -P /tmp https://artifacts.elastic.co/downloads/elasticsearch-plugins/analysis-icu/analysis-icu-8.12.0.zip

その後、ダウンロードしたzipファイルを指定して、elasticsearch-pluginコマンドを実行します。ファイルを指定する際には、file://で/tmpフォルダ内のzipファイルを指定します。elasticsearchのフォルダ構成は何も考えずにインストールした場合です。

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install file:///tmp/analysis-kuromoji-8.12.0.zip
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install file:///tmp/analysis-icu-8.12.0.zip

特にエラーが発生しなければ成功です。
elasticsearchを再起動して反映しましょう。

docker-composeでコンテナを起動した後に、コンテナに保存先をマウントしてオフラインインストールもできるような気がしますが、また今度試してみたいですね。

【AWS】 費用節約のためEC2を夜間停止する2023年4月版【備忘録】

AWS インフラ 備忘録

おはこんばんにちは、ビショップです。

AWS、高いですよね。毎月の費用に辟易しております。やべぇ、たっけぇってなる前に、昼間しか使わないものは夜間とか土日は停止しておきましょう。Webのサービスはなんでもそうですが、AWSもちょいちょい管理コンソールの画面とか表現が変わるので、直近、2023年4月現在の管理コンソールでの設定方法を備忘録にしておきます。

手順は下記のように進めます。

使用する画面はこの2つです。

  • IAM Management Console
  • Amazon EventBridge

以前はLambdaとか使ってましたが、今はEventBridgeだけでちゃちゃっとできます。
今回は、「平日（月曜～金曜）の朝8時に起動、夕方18時に停止」というスケジュールにして、土日と平日夜間は停止、昼間のみ利用するように組んで行きます。

設定開始

ロールを作る

自動停止と自動起動を行うためのロールを作成します。
IAM ManagementConsoleから、「アクセス管理」→「ロール」でロールの管理画面を開きます。画面右上の「ロールを作成」

IAM
カスタム信頼ポリシー

ロール作成の画面に移るので、まずは信頼されたエンティティタイプで、「カスタム信頼ポリシー」を選択します。

信頼されたエンティティタイプ

すると、すぐ下のポリシーがJSON形式で記述するものに変わります。

カスタム信頼ポリシー

ので、下記のように編集します。Seviceだけ追加すればいいと思います。その後、次へ。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "scheduler.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
許可ポリシー

続いて、「許可を追加」画面になります。

許可を追加

検索等を活用して、下記どちらかのポリシーを追加します。どっちでも大丈夫です。

  • AmazonEC2FullAccess
  • AmazonSSMAutomationRole

こんな感じでポリシー左側のチェックを入れて、「次へ」

ロールの作成完了

ロール名の設定と、諸々の確認画面になるので分かりやすい名前をつけて、画面下部の「ロールを作成」ボタンを押して作成を完了しましょう。今回の名前は適当に「Auto_stop_start_role」としました。

ロールの詳細

メッセージが表示され、ロールの一覧に表示されていれば成功です。

自動停止スケジュールを作る

続いて、スケジュールを作っていきます。停止と開始はそれぞれでスケジュールを作ります。まずは停止のスケジュールを作りましょう。別にどっちからでもいいんですけど。

EventBridgeの「スケジューラ」→「スケジュール」と遷移し、「スケジュールを作成」します。

EventBridge
スケジュールの設定

最初にスケジュールの名前を設定しますが、割愛します。適当にわかり易い名前をつけましょう。そのすぐに下にスケジュールを具体的に設定する部分があります。Linuxのcron式で記述します。こんな感じに設定しましょう。

停止スケジュール

これで月曜から金曜の間、毎日18時になったら処理が実行されます。ちなみに、ちゃんと日本時間なので、タイムゾーンを気にする必要はないです。たぶん最近そうなった。
すぐ下にトリガー日が表示されるので、それを見てスケジュールが問題ないか確認しましょう。「フレックスタイム」はとりあえずオフで。

他は特に設定する必要はないのでそのまま「次へ」

ターゲットの選択

次にスケジュールによって起動する処理とそのターゲットを指定します。先に停止したいEC2のインスタンスIDをコピーしておきましょう。「すべてのAPI」を選択して、検索を駆使してAmazonEC2の「StopInstances」を発見、クリックして選択します。

ターゲットの選択

すぐ下のウィンドウで、停止したいインスタンスをJSONで記述します。ダブルクォーテーションでくくって、カンマ区切りで複数記述できます。いい感じに書けたら「次へ」

ロールの設定

他の設定画面に移ります。画面下の方のアクセス許可で、最初に作成したロールを設定します。「既存のロールを使用」を選択して、プルダウンリストで先程作成したロールを探しましょう。

アクセス許可
スケジュールの作成完了

その後はスケジュールの確認と作成完了になります。表示されている内容を確認して問題なければ完了しましょう。

自動開始スケジュールを作る

停止と同じように作る

基本の作成方法は自動停止スケジュールと同じです。
開始スケジュールのcron式のサンプルを一応おいておきます。

ターゲットは、AmazonEC2の「StartInstances」を選択して、インスタンスIDをJSONに記述していきます。

動作確認

ここまでで一通りの設定は完了です。
あとは時間になって、指定したインスタンスが問題なく停止すること、次の日ちゃんと起動していることを確認します。

注意事項

インスタンスの「停止保護」が有効になっていると自動的に停止しません。一応確認しておきましょう。

まとめ

EC2インスタンスの費用は起動時間がほぼすべてみたいなもんです。本番環境のサービスであろうとも夜中は利用できなくていいサービスもいっぱいあると思います。起動と停止をうまく活用していい感じに節約しましょう。

【RHEL9】パスワード認証のrootでSSH接続できない

AWS Linux 備忘録

おはこんばんにちは、ビショップです。

最近は1か月ごとに備忘録ばっかり書いてる。

AWS EC2のインスタンス起動時に選択できるRHELがいつのまにか9になってた。今回は特に気にせずにそのままRHEL9で新しくインスタンスを起動しましたが、タイトル通り、rootでのSSH接続でハマりました。そもそも論は置いておきます。

最初はコマンドプロンプトから公開鍵を指定して接続、/etc/ssh/sshd_configで下記を変更しました。

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes            #コメントアウトを外す
#PermitEmptyPasswords no

# たぶん一番下の行
#PasswordAuthentication no          #コメントアウトする

PasswordAuthenticationを有効にした感じですね。RHEL8までならこれで

systemctl restart sshd.service

を実行すればパスワードを使ってrootでログインできました。（パスワードは設定してね）
が、どうにもうまくいかない。調べてみると、少し追加で設定が必要のようです。

RHEL9からは
  1. /etc/ssh/sshd_config.dの下に「01-permitrootlogin.conf」というファイルを作る。
  2. 01-permitrootlogin.confに「PermitRootLogin yes」を追記する。
  3. sshd.serviceを再起動する。


直接/etc/ssh/sshd_configのPermitRootLoginをyesにしても動くと思いますが、confファイル作った方がいいんじゃないですかね。RHEL9のインストール時に「パスワードによるroot SSHログインを許可」みたいな設定が出来るんですが、そちらでもconfファイルが追加され、sshdが起動する際にincludeされる形となってると思います。

普通の人はちゃんと公開鍵使いましょうね。そんな難しいものじゃないから。

AWSのRHELでdnfすると「このシステムは、エンタイトルメントサーバーに登録されていません」とエラーになる

AWS Linux 備忘録

おはこんばんにちは、ビショップです。

備忘録。

タイトルのように、AWS EC2で構築したRHELでdnfすると「このシステムは、エンタイトルメントサーバに登録されていません。」と表示され、エラーになります。EC2のRHEL AMIにはアップデート等を受けるサブスクリプションが含まれているはずなので、特に問題ないはずです。ということで、このエラーが表示されないように設定を変更します。
/etc/yum/pluginconf.d/subscription-manager.conf を編集します。

vim /etc/yum/pluginconf.d/subscription-manager.conf 

[main]
# 1になっているところを0にする
#enabled=1
 enabled=0

これでエラーが表示されなくなりました。

【DBeaver】プロキシ経由でのドライバダウンロード

Database ソフトウェア 備忘録

おはこんばんにちは、ビショップです。

備忘録。

DBeaverでは必要に応じて各DBエンジン用のドライバを自動でダウンロードしてくれます。ただ、弊社のようにプロキシ環境だとちゃんとダウンロードできません。ということでプロキシ設定をしましょう。いつも聞かれるたびに、どこだったっけ？ってなるのでメモ。

まずは設定を開きます。（ウィンドウ > 設定）

左側のドリルダウンメニューから「接続」→「ドライバ」と選択します。
ドライバの設定画面になるので、HTTPプロキシ（ダウンロード用）となっているところにプロキシサーバの情報を登録しましょう。

プロキシ設定

これでプロキシ環境でもドライバをダウンロードできるようになります。
分かりにくいところで、設定の「一般」に「ネットワーク接続」の設定がありますが、これはダウンロードとなんら関係がないので注意が必要ですね。

MySQLクライアントを選ぶ【3選】

おはこんばんにちは、ビショップです。
久々すぎて。ずっとブログを書こうと思ってたんですが、忙しくてねぇ。向いてないかも。

最近MySQLのクライアントを変えようかな～と思って色々探していました。
まぁ有名なものもあるんでなんですが、良い感じのものを3つ選びました。この中から一つに絞り込もうと思ってるんですが、まだ決めあぐねています。
これから比較していく人の参考になればいいかなと思います。まとまってるようでまとまってないので感覚としてみてほしい。DBエンジンについて少し言及していますが、基本はMySQLのクライアントとして選定しているので注意してください。
日本語で使えるもの、Windowsでも使えるものだけを対象にしてます。Macユーザはラーメンブログでも読んでろ。

PremiumSoftから提供されているNavicatのMySQL専用版です。

良いところ

・ 使いやすい。ほとんどの作業をGUIで完結できる。
・ サーバ間のマイグレーションもコピペ感覚で出来る。
・ 最新版の見た目が今時。
・ ER図の作成機能がある。
・ データ生成機能がある。
・ 日本語対応は当然完璧

良くないところ

・ 有償。

お金出してもらえるなら迷わずこちらを使えば良いでしょう。詳しい機能は製品サイトを確認してください。お金をたくさん出してもらえる人たちはNavicat Premiumを買いましょう。MySQL以外も使えるので全部賄える。Enterprise版とStandard版の違いはよく分かりません。Standardしか使ったことない。
今使ってるちょっと古いバージョンは時々謎のエラー吐くのが気になる。

HeidiSQL

「ハイジエスキューエル」が正しい読み方でしょうかね。

良いところ

・ MySQL以外にPostgreSQL、Microsoft SQL Serverも対応。
・ モダンな見た目で、丁寧な色使いでテーブルプロパティや表示されたデータなどが非常に分かりやすく表現されている。
・ ほとんどの作業をGUIで完結することが可能。
・ かなりいい感じに日本語対応。
・ SQLの履歴が表示されてる。
・ 圧倒的に軽い。

良くないところ

・ テーブルプロパティが複数タブで開けない？プロパティの比較とかやりづらい。

HeidiSQL

とってもバランスいいと思います。初心者とかこれからいっぱい触るよ～って人はHeidiSQLが良いかも？

DBeaver

なんて読むのが正解？特にD。「ディービーバー」「デービーバー」って呼んでます。今一番熱いDBクライアントですよね。

良いところ

・ MySQL以外のDBエンジンも豊富に対応。
・ JDBCドライバを自動的にダウンロードしてくれる。
・ 見た目も良き。
・ 日本語にもかなり対応。
・ ER図を勝手に作ってくれる。
・ ER図を使ってデータのリレーションを追える。
・ 重いSQLが終わったことを通知してくれる。

良くないところ

・ 一部英語のまま。

DBeaver

かなり機能も多く、いろいろ使い方をまとめてる方もたくさんいるので、困ることもなさそうです。使い方自体もそんなに癖を感じることもなく、使いづらさもそこまでないですね。データ表示時は件数が多いとハングアップするときがあります。DBのことをある程度理解してるならDBeaverが良さげです。

まとめ

どれを使っても良いところ悪いところがあります。後は好みなんでしょうね～。DBeaverがなんとなくもう一息って感じがします。もう少し軽くなったらDBeaver一択って感じになりそう。Googleトレンドで比較しても圧倒的にDBeaverが人気ですね。同じ土俵にはならないんで、比較するのは良くないかもしれんけど。データやテーブルプロパティの見やすさだけで言ったらHeidiSQLはマジで最強。直感的に分かりやすいのいい感じですね～。まぁお金出せるなら迷わずNavicat選んどけって感じです（2022年9月現在）

Aurora MySQLのデフォルトcharacter_setを変更する

AWS Database MySQL 備忘録

おはこんばんにちは、ビショップです。
ググれば出てきますが、備忘録のために自分のブログにも書いておきます。

Aurora MySQL 5.7 です。
何も考えずに立てたDBのcharacter_setがlatin1になってて、システムから登録したデータが文字化けして困りました。テスト環境だったんで良かった。こちらをちゃんとutf8に変更します。

DBクラスター用のパラメータグループを作ります。
「character_set」でパラメータを検索して出てきたパラメータを良しなに変更します。

出てくるパラメータは下記6つだと思います。
character_set_client
character_set_connection
character_set_database
character_set_filesystem
character_set_results
character_set_server

特に、普通にAurora MySQLでDBを作ると、character_set_databaseとcharacter_set_serverがlatin1とかになってたりします。うちのように普通はシステムの日本語文字コードにはutf8とか使ってるでしょうから文字化けします。この2つはちゃんと指定しましょう。

サーバ立ててMySQL立てるときってmy.cnfに何も考えずにdefault_character_set書いてたんで、なんか抜け落ちてました。

スポンサーリンク