apacheサーバーでホームページを公開しているサーバーで深刻な脆弱性が発見されています。
(参照:piyolog 「Apache HTTP Server の深刻な脆弱性CVE-2021-41773とCVE-2021-42013についてまとめてみた」)
ドキュメントルート外のファイルを読み出せたり,apacheユーザーでリモートコードを実行できるようなので,かなり注意が必要です。
apacheサーバーでホームページを公開しているサーバーで深刻な脆弱性が発見されています。
(参照:piyolog 「Apache HTTP Server の深刻な脆弱性CVE-2021-41773とCVE-2021-42013についてまとめてみた」)
ドキュメントルート外のファイルを読み出せたり,apacheユーザーでリモートコードを実行できるようなので,かなり注意が必要です。
サーバー類のアップデートを実施しました。
コマンド
dnf install dnf-plugin-system-upgrade
dnf system-upgrade download –releasever=34
dnf system-upgrade reboot
確認後
uname -a
特に問題点はありませんでした。
今日は、Linuxのライセンスのうち、コピーレフトの話をします。
コピーレフトとは、ソフトを利用や再頒布した場合、利用したソフトの著作権表示を義務づけていることをいいます。
ここでいう利用とは、ソフトを使用した場合ではなく、改造やシステムの一部として利用した場合をいいます。
ソフトを利用して形が変わったとしても、変わる前のソフトの著作権を保護することが目的です。
前回紹介した規約のうち、GPLは、コピーレフトを採用していますが、MITライセンスとBSDライセンスは、採用していません。
コピーレフトを採用していないライセンスは、利用前のソフトの著作権表示をしなくてもよいため、よりソフト開発をライセンス上を自由にできるといえます。
ソフトを利用するためには、コピーレフトの適用があるか否かを確認が必要です。
今日もLinuxのライセンスの話をします。
Linuxサーバーの設定をして商用で使用する場合(利用でなくて使用、著作権法30条)は、著作権者の免責(つまり、作った人は責任を負わない)はあるものの、基本利用は自由です。(OSS、コピーレフト等)
ソフトのライセンスの中には、CC(クリエイティブ・コモンズ ライセンス)というものがあり、このライセンスの場合で「非営利」の場合には、商用のよる使用はできないようです。
Linuxのソフトの多くは、GPLv2を採用しており、利用や改変は自由であり、改変の際はソースコードの公開が原則となっています。
Linuxのソフトを使用する際は、ドキュメントを参照して、どのライセンスに属するかの確認が必要になってきます。
Linuxサーバーを管理するためには、ライセンスについても確認しておかなければならないです。
今日は、Linuxで利用されるライセンスについて書きます。
Linuxのサーバーを使う場面として、各ソフトのライセンスを気にしなければいけません。気にすることとして、
1.ソフトの利用・使用は有償か無償か
2.ソフトの商用の利用または使用が可能か否か
3.ソースを改変して利用することができるか否か
4.ソフトを利用・使用したの各種サービス提供について、有償提供してよいか否か
(著作権法上の「利用」と「使用」は、意味が違います。著作権法第30条・その他)
以下に主要なライセンスを示しておきます。
・OSS
・GNU/GPL
・MIT
・Apache License
・BSD(2条項)
Linuxサーバーに入っているソフトたちは、ソフト毎にそれぞれのライセンスが適用されているため、利用前に確認をしておいたほうがいいです。
3連休でしたので、時間を使って、業務用パソコンを新たに購入し、同時にメインサーバーをFedora33に移行と更改をしました。
更改により、業務パソコンとサブマシン、メインサーバーのメモリーが増設になりました。
Fedora32から33の移行については、今のところ、特に問題は出ていません。
移行で大変だったのは、サーバーのipv6アドレスが変わってしまうことくらいでした。
業務サーバーと事務所のサーバーのメジャーアップデート更新を行いました。
コマンドは以下のとおりです。
dnf upgrade --refresh dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=31 dnf system-upgrade reboot
前回のアップデートのときは、お問い合わせフォームのトラブルの発生に気がつくまでに時間がかかりました。
今回は、試験してみましたが、特に何もありませんでした。
SSDの価格低下のおかげにより、
業務サーバーのストレージ容量が増加できました。
SSDはHDDに比べて高価なため、
大容量をそろえるのは容易ではありませんでした。
その中、業務データのみならず、バックアップデータやスマホのバックアップ、購入した音楽データ等を記録しておくには、大容量が必要となってきました。
今年になってようやくSSDの価格が低下したので購入を決めました。
方法としてはSystem Rescue CDを用いて、Fedoraサーバーの単純なコピーをかけます。
dd if=/dev/sdx of=/dev/sdy bs=4092
バッファサイズは4,092byteにしていますが、サイズは大きいほど早くコピーがかけられます。
4,092byteでは、SSD同士の転送は、100M/1秒程度でコピーできました。
その後、lvmとマウントポイントの容量増加をしました。
一番苦慮したのは、マウントポイントの容量増加でした。
実際ざっくりした方法は、
論理ボリュームの拡張
lvextend -l+100%FREE /dev/論理グループ名/rootとかhome
ファイルシステムの拡張
「マウント」してから、
xfs_growfs /マウントポイント
今後はWindows10クライアントのSSDを交換したいと思っています。
半年に1回くらいのメジャーアップデートがあり、
サーバーのアップデートをしました。
今回は特に問題なしでした。
やり方は、
dnf upgrade --refresh dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=31 dnf system-upgrade reboot
特に変更点も有りませんでした。
今回のFedoraのアップデートでcertbotを使用している場合は
SSL周りの再設定をしないといけないみたいです。
また、Fedoraがアップデートされました。
リリースは4/29のよう。
今回焦ったのは、SSLまわりの設定が初期化されたこと。
アップデートされてた際も聞かれたのですが、
python-certbot-apacheの移行ができなかった。
一旦、そのあたりをリムーブして、アップデートをかけました。
アップデート後、ホームページがhttpsで接続できなくなったから、
焦りました。電子証明書もletsencryptから発行された証明書でなくて、サーバーのデフォルトの証明書になってしまうし。
certbot-apacheをインストールして
SSL周りの設定をやり直し。
具体的には、ssl.confをアップデート前のサーバーのetcのバックアップから持ってきました。
Fedoraをアップデートされるかたは注意を。