2023年12月
2023年12月28日
Hyper-Vで linux を運用しています。
あるとき、ホストOS側からディスクの消費量を見ると、とても大きなファイルサイズになっていることに気づきました。
たしか100Gとかを消費していたように思います。
linux のテストインストールぐらいしかしていないので、linux 自身が実際に消費している容量は10Gぐらいでした。
なぜこんなにも大きな消費サイズになってしまっているのでしょうか。
原因は不明ですが、以下のサイトが見つかりました。
【これ重要かも】CentOS 5.9 を試してたら VHDX と EXT3 の組み合わせ問題に遭遇?
私の場合には ext4 でした。
上記サイトにあるように、以下のコマンドを Powershell から実行し、vhdファイルを作成しました。
New-VHD -path ./linux.vhdx -Dynamic -SizeBytes 50GB -BlockSizeBytes 1MB
これで linux をインストールしたところ、実際の消費量とOSから見る消費量が概ね近くなりました。
あるとき、ホストOS側からディスクの消費量を見ると、とても大きなファイルサイズになっていることに気づきました。
たしか100Gとかを消費していたように思います。
linux のテストインストールぐらいしかしていないので、linux 自身が実際に消費している容量は10Gぐらいでした。
なぜこんなにも大きな消費サイズになってしまっているのでしょうか。
原因は不明ですが、以下のサイトが見つかりました。
【これ重要かも】CentOS 5.9 を試してたら VHDX と EXT3 の組み合わせ問題に遭遇?
私の場合には ext4 でした。
上記サイトにあるように、以下のコマンドを Powershell から実行し、vhdファイルを作成しました。
New-VHD -path ./linux.vhdx -Dynamic -SizeBytes 50GB -BlockSizeBytes 1MB
これで linux をインストールしたところ、実際の消費量とOSから見る消費量が概ね近くなりました。
2023年12月27日
■バックアップ先
# vi /etc/rsyncd.conf
# 最大接続数
max connections = 4
# 転送結果もログに残すか否か
transfer logging = yes
[BK-TEST]
path = /bk/TEST/
uid = root
gid = root
read only = false
log file = /var/log/rsync-bk-TEST.log
pid file = /var/run/rsync-bk-TEST.pid
# systemctl status rsyncd.service
起動時に enabled になっていることを確認
Activeになっていることを確認
■バックアップ元
rsync -azP --delete --exclude /var/cache /etc /var /home root@::BK-TEST
-a アーカイブモード
-z 転送データを圧縮する
-P 進捗の表示+転送中のファイルを保持する(大きなファイルの転送中に中断すると、元ファイルが破損するため)
# vi /etc/rsyncd.conf
# 最大接続数
max connections = 4
# 転送結果もログに残すか否か
transfer logging = yes
[BK-TEST]
path = /bk/TEST/
uid = root
gid = root
read only = false
log file = /var/log/rsync-bk-TEST.log
pid file = /var/run/rsync-bk-TEST.pid
# systemctl status rsyncd.service
起動時に enabled になっていることを確認
Activeになっていることを確認
■バックアップ元
rsync -azP --delete --exclude /var/cache /etc /var /home root@
-a アーカイブモード
-z 転送データを圧縮する
-P 進捗の表示+転送中のファイルを保持する(大きなファイルの転送中に中断すると、元ファイルが破損するため)
2023年12月20日
以前に記事を書いていました。
2018年11月15日: poderosa で screen を実行しているときにスクロールできない。※未解決
結論 teraterm.ini の TranslateWheelToCursor=off にする
teraterm を利用して screen コマンドを利用していました。
普段のクセでマウスホイールをクルクルすることで、過去の画面を確認したいのです。
しかし screen コマンド下では、マウスホイールの操作は、キーボードの上下キーを押したのと同じ結果になります。
過去のコマンド履歴が出てくるのです。
一応 CTRL+マウスホイール でスクロールはできましたが、不便。
そこで、以下の設定を行い解決しました。
Teratermのメニューから、 setup - Keyboard から、 Disable mode 内の Application Cursor にチェックを入れます。
ただし・・・・今度は less などでの動作が今までと異なるようになってしまいました。
今までは less でキーボードの上下は、ログが上下していました。
上記設定を変更すると、上下しなくなってしまいました・・。
以下の方法がいいようでした。
Teraterm.ini を編集し、TranslateWheelToCursor=on を off に変更です。
今までマウスクルクルで、less などの場合には、ファイル内で上下していたように思いますが、上記設定にしてからは、スクロールが上下するようでした。
しかしながらこの動作が、今までの様々な方法の中で最も今までの操作感に近いのでこれで利用してみたいと思います。
参考
screen + teraterm 環境でマウスホイールのバッファスクロール有効化
2018年11月15日: poderosa で screen を実行しているときにスクロールできない。※未解決
結論 teraterm.ini の TranslateWheelToCursor=off にする
teraterm を利用して screen コマンドを利用していました。
普段のクセでマウスホイールをクルクルすることで、過去の画面を確認したいのです。
しかし screen コマンド下では、マウスホイールの操作は、キーボードの上下キーを押したのと同じ結果になります。
過去のコマンド履歴が出てくるのです。
一応 CTRL+マウスホイール でスクロールはできましたが、不便。
そこで、以下の設定を行い解決しました。
Teratermのメニューから、 setup - Keyboard から、 Disable mode 内の Application Cursor にチェックを入れます。
ただし・・・・今度は less などでの動作が今までと異なるようになってしまいました。
今までは less でキーボードの上下は、ログが上下していました。
上記設定を変更すると、上下しなくなってしまいました・・。
以下の方法がいいようでした。
Teraterm.ini を編集し、TranslateWheelToCursor=on を off に変更です。
今までマウスクルクルで、less などの場合には、ファイル内で上下していたように思いますが、上記設定にしてからは、スクロールが上下するようでした。
しかしながらこの動作が、今までの様々な方法の中で最も今までの操作感に近いのでこれで利用してみたいと思います。
参考
screen + teraterm 環境でマウスホイールのバッファスクロール有効化
2023年12月19日
2023年12月16日
PCを利用していると、突然インターネットに接続できなくなってしまいました。
IPアドレスの競合や、UTMなどによるフィルターなどを確認しましたが、まったく問題ありませんでした。
IPアドレスを変えると、一時的には通信が復活します。
しかしそれでもまた数時間ぐらいでネットが切れてしまいました。
イベントログを確認したところ、タイトルのようなエラーがでていました。
すべてのポートが使用中だったため、グローバルudpポート範囲から短いポート番号を割り当てる要求に失敗しました。
ここでは udp となっていますが、 icmp もインターネット接続も、それ以外の処理も何もできませんでした。
そのため本当に udp だけなのか?というのは疑問が残ります。
まだ根本的な解決方法はわかっていません。
一応以下の対応方法があるようなのですが、ポートを大量消費しているプロセスは見つからないようでした。
ポートの枯渇に関する問題のトラブルシューティング
とりあえず以下のコマンドでプロセスとポートの利用状況を監視したいと思います。
netstat -anob
IPアドレスの競合や、UTMなどによるフィルターなどを確認しましたが、まったく問題ありませんでした。
IPアドレスを変えると、一時的には通信が復活します。
しかしそれでもまた数時間ぐらいでネットが切れてしまいました。
イベントログを確認したところ、タイトルのようなエラーがでていました。
すべてのポートが使用中だったため、グローバルudpポート範囲から短いポート番号を割り当てる要求に失敗しました。
ここでは udp となっていますが、 icmp もインターネット接続も、それ以外の処理も何もできませんでした。
そのため本当に udp だけなのか?というのは疑問が残ります。
まだ根本的な解決方法はわかっていません。
一応以下の対応方法があるようなのですが、ポートを大量消費しているプロセスは見つからないようでした。
ポートの枯渇に関する問題のトラブルシューティング
とりあえず以下のコマンドでプロセスとポートの利用状況を監視したいと思います。
netstat -anob
2023年12月15日
問合せをいただいたのでメモ。
QNAP を利用しており、 Microsoft 365 を利用中です。
Boxafe を利用することによって、 Outlook などのメールバックアップを取得することができるようです。
今まで 1.X のフリーだったようですが、最近になって、 2.0 にアップグレードしたようです。
このバージョンからはライセンスが必要になるようです。
ただしフリーライセンスもあり、少ないユーザー数であれば今まで通り無料で利用可能なようでした。
ただ、アップグレードしたあとは、ライセンスがデフォルトでは適用されないようで、手動で割当の設定をする必要があるようでした。
日本語ではまだ情報が無いようなのですが、英語では以下のマニュアルがありました。
Why am I not able to backup my Microsoft/Google domain account data after updating Boxafe 2.0?
ドメイン設定からユーザを選択し、ライセンスの割当を行います。
ドメインの設定画面では、右端に各種設定変更アイコンがあるのですが、解像度が低いと画面からはみ出てしまうためこれも注意が必要です。
QNAP を利用しており、 Microsoft 365 を利用中です。
Boxafe を利用することによって、 Outlook などのメールバックアップを取得することができるようです。
今まで 1.X のフリーだったようですが、最近になって、 2.0 にアップグレードしたようです。
このバージョンからはライセンスが必要になるようです。
ただしフリーライセンスもあり、少ないユーザー数であれば今まで通り無料で利用可能なようでした。
ただ、アップグレードしたあとは、ライセンスがデフォルトでは適用されないようで、手動で割当の設定をする必要があるようでした。
日本語ではまだ情報が無いようなのですが、英語では以下のマニュアルがありました。
Why am I not able to backup my Microsoft/Google domain account data after updating Boxafe 2.0?
ドメイン設定からユーザを選択し、ライセンスの割当を行います。
ドメインの設定画面では、右端に各種設定変更アイコンがあるのですが、解像度が低いと画面からはみ出てしまうためこれも注意が必要です。
2023年12月12日
以前の記事も関連します。
2022年03月25日: Postfix で特定のキューを削除する
ホームページに設置している問合せフォームを悪用されてしまい、大量のスパムメールを受け取ることとなりました。
かなり大量のメール(問合せ)が送られてきており、メールキューが圧迫されていました。
以下の内容で対応しました。
キューにたまっているメールをホールドします。
※ h がホールド、 H はキューに戻す
これでキューにたまっているメールは一端処理が中断されます。以後届く新しいメールは通常処理されるようでした。
# postsuper -h ALL
メールキューの状態と件数を確認します。
# ls -l /var/spool/postfix/hold/ | wc -l
# postqueue -p
これで大量のメールが出てくると思います。
-----
22E7C42DXX! 4075 XXX XXX 1 XX:XX:45 apache@example.com
宛先A
宛先B
-----
ここで grep 検索をするときに、宛先Aや宛先Bで引っかかることがあります。
メールキューIDが欲しいので、そうならないように注意します。
またホールドしている場合にはキューIDにはビックリマーク(感嘆符!)がつきます。
問合せフォームからの送信だったので、送信者は apache@ になっていました。
以下のコマンドでキューを削除します。
# postqueue -p | grep apache@example.com | awk '{print $1}'|cut -d '!' -f 1 |xargs -L 1 postsuper -d
awk '{print $1}' の部分に apache が入ってくることがありました。エラーメールの場合には、送信者 MAILER-DAEMON 、受信者 apache となるので、これを引っかけているように思われます。この場合には、grep -v apache を途中で入れて除外します。
ビックリマークありのままだとキューを削除できないので取り除きます。
同じように MAILER-DAEMON も検索し、キューを削除します。
すべてが完了したら
キューをホールドから元に戻します。
# postsuper -H ALL
これでメールを通常運転に戻すことができました。
2022年03月25日: Postfix で特定のキューを削除する
ホームページに設置している問合せフォームを悪用されてしまい、大量のスパムメールを受け取ることとなりました。
かなり大量のメール(問合せ)が送られてきており、メールキューが圧迫されていました。
以下の内容で対応しました。
キューにたまっているメールをホールドします。
※ h がホールド、 H はキューに戻す
これでキューにたまっているメールは一端処理が中断されます。以後届く新しいメールは通常処理されるようでした。
# postsuper -h ALL
メールキューの状態と件数を確認します。
# ls -l /var/spool/postfix/hold/ | wc -l
# postqueue -p
これで大量のメールが出てくると思います。
-----
22E7C42DXX! 4075 XXX XXX 1 XX:XX:45 apache@example.com
宛先A
宛先B
-----
ここで grep 検索をするときに、宛先Aや宛先Bで引っかかることがあります。
メールキューIDが欲しいので、そうならないように注意します。
またホールドしている場合にはキューIDにはビックリマーク(感嘆符!)がつきます。
問合せフォームからの送信だったので、送信者は apache@ になっていました。
以下のコマンドでキューを削除します。
# postqueue -p | grep apache@example.com | awk '{print $1}'|cut -d '!' -f 1 |xargs -L 1 postsuper -d
awk '{print $1}' の部分に apache が入ってくることがありました。エラーメールの場合には、送信者 MAILER-DAEMON 、受信者 apache となるので、これを引っかけているように思われます。この場合には、grep -v apache を途中で入れて除外します。
ビックリマークありのままだとキューを削除できないので取り除きます。
同じように MAILER-DAEMON も検索し、キューを削除します。
すべてが完了したら
キューをホールドから元に戻します。
# postsuper -H ALL
これでメールを通常運転に戻すことができました。