投稿者: manualmaton Page 2 of 239

Ubuntuで特定のディレクトリに移動した際にカスタムメッセージを表示する。

概要

Ubuntuで、特定のディレクトリに移動した際にカスタムメッセージを表示するTIPSです。

例えば、cd /etc/apache2/sites-availableとしたときに「.confファイルのバックアップを取ること」といった確認メッセージを表示させることができます。

環境a

  • Ubuntu 22.04 /24.04
  • BashまたはZshシェル

手順

1. スクリプトを作成

まず、/etc/profile.d/cd.shにカスタムcd関数を追加します。

sudo tee -a /etc/profile.d/cd.sh > /dev/null << 'EOF'
# カスタムcd関数を定義
cd() {
# ディレクトリに移動
builtin cd "$@"

# 特定のディレクトリに移動したときのメッセージ
case "$PWD" in
"/etc/apache2/sites-available")
echo "注意: .confファイルのバックアップを取ること"
;;
"/var/log")
echo "注意: ログファイルを定期的にチェックすること"
;;
*)
# 他のディレクトリの場合は何もしない
;;
esac
}
EOF

2. スクリプトに実行権限を付与します。

sudo chmod +x /etc/profile.d/cd.sh

3. スクリプトを反映

source /etc/profile.d/cd.sh

動作確認

設定が正しく反映されているか確認するために、特定のディレクトリに移動してみます。

cd /etc/apache2/sites-available

注意: .confファイルのバックアップを取ることと表示されることを確認します。

cd /var/log

注意: ログファイルを定期的にチェックすることと表示されることを確認します。

スクリプト修正ポイント

ディレクトリの追加:

新しいディレクトリに対してメッセージを表示させたい場合は、case文に新しい条件を追加します。

メッセージの変更:

各ディレクトリに対するメッセージを変更する場合は、echoコマンドの内容を編集します。

case "$PWD" in
"/new/directory/path")
echo "新しいディレクトリに移動しました"
;;
# 他のディレクトリの条件を追加
esac

これで、特定のディレクトリに移動したときにカスタムメッセージを表示する方法が設定できました。

Ubuntu24.04のauth.logから不正ログイン試行を確認するワンライナー。

Ubuntu 24.04でWebサーバを公開中。

/var/auth.logから、失敗したアクセス(認証に失敗したユーザー)を確認するためのワンライナーです。

  • コマンド
sudo awk '/Disconnected from invalid user/ {print $(NF-4)}' /var/log/auth.log | sort | uniq -c | sort -nr
  • 実行結果
43 root
36 ubuntu
24 user
20 test
13 admin
8 deploy
6 guest
6 ftpuser
5 oracle
5 hadoop
5 dev
5 debian
4 user1
4 sysadmin
4 samba
3 test1
3 mysql
3 max
3 kafka

と、アカウントごとに失敗したユーザーを表示してくれます。

成功したログインを日付時刻を付与した上で表示する

/var/auth.logから、ログインに成功したユーザーを調べます。

  • コマンド
sudo awk '/Accepted/ {split($1, date, "T"); split(date[2], time, "."); gsub("-", "/", date[1]); print date[1] " " substr(time[1], 1, 5) " " $7}' /var/log/auth.log | sort | uniq -c | sort -nr

日付は2024-11-25T16:21:14.772402+09:00のような形式から2024/11/25 14:38に修正しています。ログの形式が異なる場合は調整が必要です。

  • 実行結果
1 2024/11/25 14:38 hoge

これで、ログの視認性が高まりました。

体調復旧とボードゲーム。

今月の中旬、軽さと重さの中間のような病にかかり療養。

その間は症状がちょっと厳しく、家にいてもほぼ何もできない状態でした。

その症状が軽くなったため、勘を取り戻すかのようにボードゲームのソロプレイです。

例によってのアグリコラ。

アクションスペースのめくり運が悪かったものの、

  • 大鎌使い
  • 薪集め

により食料と木材¥の調達が楽になり、小進歩も材料調達の手間を軽減。

おかげで、60点とソロにしてはなかなかの得点です。

そして、ボドゲ棚の隙間に転がっていた『タッジー・マッジー』が見つかったのでルールを思い出しながらのソロプレイ。

1ラウンドごとにカードが増えていく強敵(見習い)に対して1点差の勝利。

運が強めですが、それだけに高得点がとれたのは耐えがたく。

体調復旧の兆しが見えました。

カメラケース、新調。

所用のついでに立ち寄ったワークマン。

手頃なスーツケース型のポシェットが売られていました。

見ての通り『ゆるキャン△』とのコラボ。取り敢えず何かに使えるだろうと思っていたら

今、メインで使っているカメラとよく使うレンズ二本がジャストフィット。

クロスも入りますし、マチが採られている上に開閉に制限があるので落とす心配もそれほどありません。

肩掛けストラップ付きなので持ち運びも大丈夫。

カメラの運搬問題が解決しました。

UbuntuサーバのSSHセキュリティ周りを強化。

SSHの不正アクセス対策としてfail2banを入れています。とはいえ、これがマシンリソースを喰うので根本的な設定を行いました。

環境

  • Ubuntu 24.04

作業の前に

SSHを前提としているサーバの場合は

  • 直接コンソールで切り戻しができるようにしておく
  • VPS等はスナップショットでリカバリができるようにする

ことが大前提です。

また、鍵交換での手順です。パスワード認証でこの設定を行うと接続ができなくなります。

さっくりとした手順

  1. SSHの設定ファイルのバックアップを取ります。
  2. 設定を変更します。
  3. 設定を反映し、確認を行います。

設定ファイルのバックアップ

sudo cp -pi /etc/ssh/sshd_config /path/to/backup/directory/sshd_config.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

ファイルのバックアップ確認

diff -u /path/to/backup/directory/sshd_config.$(date +%Y%m%d) /etc/ssh/sshd_config

エラーがなければ(差分がなければ)バックアップできています。

sedによるファイル書き換え

echo -e "\nPermitRootLogin no\nPasswordAuthentication no\nAllowUsers user1" | sudo tee -a /etc/ssh/sshd_config

user1の部分は「実際にSSH接続を行うアカウント」を指定します。

user1 user2

のように、スペースで区切って複数のアカウントを指定することが可能です。

ファイル書き換え確認

diff -u /path/to/backup/directory/sshd_config.$(date +%Y%m%d) /etc/ssh/sshd_config

以下のような差分を確認します。

+PermitRootLogin no
+PasswordAuthentication no
+AllowUsers user1
  • rootのログインを禁止する
  • パスワード認証を禁止して鍵交換方式のミニする
  • user1のみアクセス可能にする

設定反映

SSH接続で修正をしている場合、別にターミナルクライアントを立ち上げておきます。

sudo systemctl restart ssh.service

設定反映確認

  1. 新たにターミナルクライアントを立ち上げて、指定したユーザーでログインできること
  2. 指定していないユーザーではログインできない
  3. rootでのログインはできない
  4. パスワード認証ができない

ことを確認します。また、

sudo reboot

を行い、サーバ再起動でも同じ挙動を確認します。

接続できない場合の切り戻し

スナップショットからイメージを復元します。

または、直接コンソールを開き、

sudo cp -pi /path/to/backup/directory/sshd_config.$(date +%Y%m%d) /etc/ssh/sshd_config

として設定を切り戻し、

sudo systemctl restart ssh.service

を実施します。

スープジャー導入後のフィードバック。

こちらで、改めてスープジャーを導入して、どのように変わったかのメモです。

弁当の内容が同じでもバリエーションが発生。

冷蔵庫にある材料の関係上、

同じようなメインの食材が並びます。それでも、スープジャーの中身を変えることで(上はミネストローネ、下は麻婆豆腐)味に変化が生まれます。

惣菜の再利用

個人的にはこっちがありがたいです。

作り置きしていた惣菜をスープの具に転用することで、冷蔵庫の整理が楽になりました。

運用する上での問題

「洗うのが面倒」に尽きます。カレーや味噌など、どうしてもにおいがつきやすい調味料を使うので、食後と寝る前の二度洗いが必要。

ただ、それさえクリアすれば暖かい汁物が食べられるというアドバンテージが大きいです。

Ubuntu 24.04にredmine 6.0.1をインストール。

以下の環境でインストールを確認しています。

  • Ubuntu 24.04

Ruby 3.1 / 3.2 / 3.3 が要件であるため、Ubuntu 22.04 / 20.04へのインストールは避けた方が無難です。

※ また、テーマやプラグインの仕様も大きく異なっているため、本格的な以降は筆者は様子見にしています。

本記事で実施すること

  1. Redmineを動かすためのパッケージがインストールできるように準備をします。
  2. Redmineを動かすためのパッケージ(Ruby/データベース/Webサービスなど)をインストールします。
  3. データベースやWebサービスの基礎設定を行います。
  4. Redmineの動作確認を行います。

想定している読者

  • 「Redmine」をUbuntuにインストールしてみたい
  • まずは動くところまで確認できればいい

前提

  • Ubuntuサーバの初期設定が終わった直後の状態を想定します。
  • DNSでドメインの名前が解決できることを前提としています
  • 環境は以下の通りです。
  • Apache系
  • MySQL
  • Ruby
    • 3.2 (Ubuntu 24.04)
  • また、パッケージ管理としてaptitudeを用いています。aptが好みの方はこちらに読み替えてください。

特記事項

  • 本手順ではRedmine 6.0.1をインストールします。
  • 本記事のredmineの格納ディレクトリは/home/www-data/redmineです。一般的なディレクトリ(/var/lib/redmine)と異なることを最初に注記します。
  • ほぼコピペだけで済むような構成にしていますが、一部、テキストエディタを使用する箇所があります。
  • また、自身の環境に合わせたりパスワードを設定する項目がありますのでそこは注意してください。

手順

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

必要なパッケージをインストールします。

  • パッケージ全体のアップデート
sudo aptitude update
  • 必要なパッケージのインストール
sudo aptitude install build-essential zlib1g-dev libssl-dev libreadline-dev libyaml-dev libcurl4-openssl-dev libffi-dev mysql-server mysql-client apache2 apache2-dev libapr1-dev libaprutil1-dev imagemagick libmagick++-dev fonts-takao-pgothic subversion git ruby libruby ruby-dev libmysqlclient-dev

apacheの追加モジュールをインストールします。

sudo aptitude install libapache2-mod-passenger

apacheのバージョンを確認します。

apache2ctl -v

Apache/2.4.59以降(2024/11/21現在2.4.62)であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

rubyのパッケージ管理(gem)を用いて必要なライブラリをインストールします。

sudo gem install bundler racc mysql2

「3 gems installed」が表示されればインストール成功です。

必要に応じてmysqlの初期設定を行います。

mysql_secure_installationによる初期設定を行います。

うまくいかない場合は以下を参照してください。

https://barrel.reisalin.com/books/bbf94/page/mysql-secure-installation

mysqlでDBとユーザーを設定します。

sudo mysql -u root -p

上記で設定した「mysqlのrootパスワード」を入力し、mysqlにログインします

CREATE DATABASE redmine character set utf8mb4;

DB "redmine" を作成します

CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'password';

ユーザ "redmine"を作成し、パスワードを設定します。
この'password'は任意のパスワードに変更してください

GRANT ALL ON redmine.* TO 'redmine'@'localhost';
flush privileges;
exit

設定したDBでログインできることを確認します。

mysql -u redmine -p
SHOW DATABASES;
exit
  • 配置ディレクトリ作成
sudo mkdir -p /home/www-data/redmine

自分の環境に合わせます。

  • 所有者変更
sudo chown -R www-data:www-data /home/www-data
  • Redmine 6.0.1を入手
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/6.0-stable /home/www-data/redmine

Redmineのコンフィグを設定します。

  • サンプルファイルをコピーしてコンフィグを編集
sudo -u www-data cp -pi /home/www-data/redmine/config/database.yml.example /home/www-data/redmine/config/database.yml

/home/www-data/redmine/config/database.yml

このファイルを教義・信仰に従ったエディタで編集してください。

database.yml 編集内容

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  # rootからredmineに変更します
  password: "redmine用のパスワード"
  encoding: utf8mb4
# 本番環境(production)のみ設定を行います

Redmineのマイグレーションを行います。

  • Redmineのルートディレクトリに移動
cd /home/www-data/redmine/ && pwd

/home/www-data/redmine/ (Redmineを配置したディレクトリ)であることを確認します

  • bundle install
sudo -u www-data bundle install --without development test --path vendor/bundle
  • シークレットトークンの発行
sudo -u www-data bundle exec rake generate_secret_token
  • DBマイグレーション
sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate
  • 日本語化
sudo -u www-data RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data

Apacheの設定ファイルを作成します。

【】を自分の作成したRedmineのサーバ名/ドメイン名に変更します。

cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/redmine.conf
<VirtualHost *:80>
    ServerName 【hoge.example.com】
    # ServerNameは自身が設定したredmineに読み替えてください。
    DocumentRoot /home/www-data/redmine/public
    <Directory /home/www-data/redmine/public>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
__EOF__

設定を反映させます。

  • ファイル作成確認
ls -l /etc/apache2/sites-available/redmine.conf
  • 設定ファイル有効化
sudo a2ensite redmine.conf
  • 初期サイト設定を無効化
sudo a2dissite 000-default.conf
sudo a2dissite default-ssl.conf
  • コンフィグファイル整合性確認
sudo apache2ctl configtest

Syntax OK を確認します

  • 設定反映前のapacheステータス確認
systemctl status apache2.service

active(running)を確認します

  • apache再起動
sudo systemctl restart apache2.service
  • 設定反映後のapacheステータス確認
systemctl status apache2.service

active(running)を確認します

Webページの表示を確認します。

http://設定したRedmineドメイン

でRedmineのトップページが表示されれば成功です。

直ちにadmin/adminでログインし、強固なパスワードを設定し直します。

Redmine 5.1対応版のknowledgebaseプラグインを検索できるように修正。

Redmine 5.1でも動くようになったknowlegebaseプラグイン。

なぜかその記事が検索で引っかからなかったので対処を行います。

環境

  • Ubuntu 24.04
  • Redmine 5.1
  • Apache 2.4
  • Ruby 3.2
  • knowlegebase 5.0.0

手順

参考:Redmine v5.1系で knowledgebaseプラグインの記事を検索する

Redmineのknowlegebaseディレクトリに移動します。

  • knowlegebaseのlibディレクトリに移動
cd /redmine/root/directory/plugins/plugins/redmine_knowledgebase/lib/ && pwd

/redmine/root/directory/は自分の環境に合わせます。

rbファイルのバックアップを取得します。

  • ファイルバックアップ
sudo cp -pi redmine_knowledgebase.rb /path/to/backup/directory/redmine_knowledgebase.rb

任意のバックアップディレクトリを指定します。

  • バックアップ確認
diff -u /path/to/backup/directory/redmine_knowledgebase.rb redmine_knowledgebase.rb

エラー(差分)がないことを確認します。

ファイルの編集を行います。

redmine_knowledgebase.rb

の、

base_url = File.dirname(__FILE__)
REQUIRED_FILES.each { |file| require(base_url + '/' + file) }

module RedmineKnowledgebase
end

の箇所を、

module RedmineKnowledgebase

  Redmine::Activity.register :kb_articles
  Redmine::Search.available_search_types << 'kb_articles'
end

となるように編集します。

  • 差分確認
diff -u /path/to/backup/directory/redmine_knowledgebase.rb redmine_knowledgebase.rb
 module RedmineKnowledgebase
+
+  Redmine::Activity.register :kb_articles
+  Redmine::Search.available_search_types << 'kb_articles'
 end

設定の反映と修正確認を行います。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

active(running)を確認します。

  • 動作確認

修正を行ったRedmineにアクセスし、knowlegebaseへのアクセス権があるユーザーでログインします。

Redmineの検索機能で、knowledgebaseプラグインの記事が検索できていれば設定完了です。

『ライザのアトリエ3』序盤におけるスキルの伸ばし方TIPS。

はじめに

本作のシステム、『スキルツリー』。

前作『ライザのアトリエ2』と異なり、シナリオ進行によるスキルツリーの解放がなくフルオープンとなっています。

つまり、序盤からSPがあればカーク群島の探索を開始した時点で品質999のアイテムを調合できてしまいます。

ここでは、冒険を進めて「どのようにスキルツリーを伸ばしていくか」について私見を述べます。

最初:三方向に伸ばす

チュートリアルのオニキスブレードは飛ばすとして、

  • メディカパウダー
  • 通常採取:獲得量強化Lv.1
  • 獲得SP+10%

を伸ばしていきます。

次に:品質上限突破:300を目指す

先のエントリーで

採取道具は作っているので、素材獲得の機会はあります。なので、品質上限を上げていきます。

その次に:複製と投入回数追加を解放させる

スキルポイントは

  • 高品質のアイテムを調合する
  • その際に強力な特性を付与する

ことでより多くを獲得できます。序盤の属性値が少なく(0もあります)投入回数が少ない状態では効果・特性の発現は見込めません。

そのため、早いうちに投入回数を増やしていきます。

その前段に複製がありますので、「超純度」の超特性で無限ジェム稼ぎも視野に入れています。

それから:通常採取/杖採取のLvを上げる

通常採取のレベルが上がれば、属性値も上がり特性もいいものが揃っていきます。

Lv.3になれば

  • 全能力強化++
  • クリティカル++
  • 破壊力上昇++

といったクリアまで使う特性がクーケン島各地の光る採取ポイントから出てきます。属性値も高くなるので調合が一気に楽になると同時に獲得SPも増えていきます。

ここまで来れば中和剤ループなども併用して

カーク群島にたどり着くかというタイミングで、

  • 攻防強化 ++99
  • 攻速強化 ++99
  • 全能力強化 ++99

を付与した錬金術士の杖も現実的になっていきます。

そうして稼いだSPで杖採取Lv.3まで上げます。

最初の内に伸ばさなくていいもの

武器レシピです。

武器の強さは

  • パラメーター(ステータス)が上昇する素材をどれだけ入れたか?
  • どれだけ強力な特性があるか?

が鍵になっていきます。それ以前の問題として強力な武器・攻撃アイテムのレシピを解放したとしても

  • 必須材料がストーリーを進めないと出てこない
  • 素材の投入回数や属性値が足りないので効果を発現させられない

状況に陥ります。

最初の段階では(カーク群島の探索を終えるまでは)初期レシピの武器・防具で少しずつステータスを上げていく方が無難です。

Growi v7.1.xのアップグレード手順。

概要

V7.1.xからパッケージ管理がyarnではなくmnpmに変更されました。

その手順に合わせたメモです。

前提

  • 既にgrowiをインストールしていること。
  • systemdによってサービス化されていること。
  • 最新版や安定版がリリースされていることを以下のサイトで確認していること。
  • https://github.com/weseek/growi/releases

※備考

v7.0.x以前はyarnを用います。

手順

さっくりとした手順

  1. growiのサービスを停止します。
  2. gitコマンドで最新版を引っ張ります。
  3. アップグレードを行います。
  4. growiのサービスを再開します。
  5. アップグレードされたことを確認します。

growiサービスを停止します

  • growiのステータス確認(停止前)
systemctl status growi.service

※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します

  • growiのサービス停止
sudo systemctl stop growi.service
  • growiのステータス確認(停止後)
systemctl status growi.service

inactive (dead)を確認します

growiディレクトリに移動します

cd /opt/growi

自分の環境に合わせます。

リリースタグを確認します。

  • リリースタグ取得
sudo git fetch --tags
  • リリースタグ確認
sudo git tag -l

スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。

チェックアウトとインストールを行います。

  • 変更を一時的に退避
sudo git stash
  • チェックアウト
sudo git checkout 【バージョン】
  • pnpm install
sudo pnpm install
  • ビルド
sudo npm app:build

growiサービスを起動します。

  • 再開前のステータス確認
systemctl status growi.service

inactive (dead)を確認します

  • サービス再起動
sudo systemctl start growi.service

※ 完全に起動していないと、アクセスしても503エラーが発生します。

  • 再開後のステータス確認
systemctl status growi.service
サービススクリプトを[growi]にしている場合

active (running)を確認します

バージョンアップを確認します。

  1. ブラウザから設定したgrowiのドメイン/IPにアクセスします。
  2. 画面下部にあるバージョンがチェックアウトしたバージョンであることを確認します。

Page 2 of 239

Powered by WordPress & Theme by Anders Norén