PC設定覚書と雑記
Nextcloudのヴァージョンアップについてです。
以前は、Nextcloudサイトに管理者がログインすると、アップデートが可能かどうかがすぐに分かり、続けてアップデート操作に進めるようになっていたと思います。
しばらくこのアップデート作業をやってなかったので、先日、ログインしてアップデート可能か調べようとしました。
すると、すぐにはアップデートの有無の確認が出来なかったので、検索で調べてみました。
結果、管理者ログイン → 右上のユーザアイコンから、「管理者設定」→「概要」
と進むと、アップデートの有無が調べられ、そこからアップデート作業に入れることが分かりました。
で、かなり溜まっていたアップデート作業を始めてみました。
これまでやってきたWebアクセスによるアップデート作業です。
すると、しばらく順調に作業が行われていましたが、急に途中で止まってしまい、動かなくなってしまいました・・・
そこで再度検索してみると、サーバー上でのコマンド操作によるupadate、upgradeについての方法が見つかりました。
ログイン後、まずNextcloudインストールディレクトリに移動します。
# cd /・・・/nextcloud/
# sudo -u apache php occ update:check
ここでつまづきました・・・
# sudo って?
sudoは一時的に管理者権限等を得るためのコマンドです。
# sudo ということは、「管理者(root)が管理者権限を得て実行」ということ??
しばらく悩みました。
そして、# sudo -u apache php ・・・ とは、phpコマンドの実行文で、
apacheユーザ(つまりapache使用時のwebサーバーユーザ)がphpコマンドを実行する、ということではないか? と推測しました。
phpコマンドを実行するための権限ユーザを指定するためにsudoコマンドが必要なのではないか?
ですから、単に、# php ・・・ という操作では、phpコマンドが実行されないんですね!
このことは実際に試してみて分かりました。
それでは、まず自鯖に sudo をインストールします。
また、debianのapachewebサーバユーザは、apache ではなく www-data です。
準備が出来たので、再度コマンドを実行してみます。
・・・/nextcloud/# sudo -u www-data php occ update:check
オッケーです!! これでアップデートの確認が出来ました! また、
・・・/nextcloud/# sudo -u www-data php occ upgrade
で、アップグレード作業も最後まで滞りなく進みました!
勉強になりました!
ヒントを下さったweb上の方々に感謝します!!
Intelの新型プロセッサーN100を搭載した省電力マザーボードが、ようやく発売されるようです!
ここで、Intel Celeron、Pentiumブランドは廃止され、
その代わりに「Intel Processor」ブランドのエントリー向けCPU、Nシリーズが発表されていました。
製品の開発コード名 Alder LakeーN
システムの種類 Mobile
プロセッサーナンバー N100
コアの数 4
スレッド数 4
ターボ・ブースト利用時の最大周波数 3.4 GHz
キャッシュ 6 MB Intel® Smart Cache
TDP 6 W
メモリーの仕様
最大メモリーサイズ (メモリーの種類に依存) 16 GB
メモリーの種類
DDR4 3200
DDR5 4800
LPDDR5 4800
最大メモリーチャネル数 1
メモリーはデュアルチャンネルではありませんが、メモリー周りは充分高速らしいです。
また、上限16GBとありますが、32GBまで動作するようなことが書かれていました。
マザーボードが発売されたら、このWebサーバーのハードウェアを全て一新する予定です。
仕事で使っているモバイルPCのマウスですが、
Bluetoothマウスの接続切れが、設定変更等どうやっても直せませんでした。
代わりにUSBポートに無線レシーバーを刺してワイヤレスマウスを使っていました。
Bluetooth機能がPCに内蔵されているのに、仕方なくこの手を使っていたんです。
で、つい最近、OSやドライバも頻繁にアップデートしているんだから、もしかしてと思い、
Bluetoothマウスを繋いでみました。
そうしたら、接続切れがうそのように無くなっていて快適にマウスが使えるんですね!
今は安定してBluetoothマウスが使えています。
OS、ドライバーが最新のものになったからだろうと、その時あまり深くは考えませんでした。
今日、何気なくBluetooth関連の検索をしてみて初めて分かったんですが、
Bluetooth規格もどんどんヴァージョンアップされていて、現在はv5.2なんだそうです。
そしてこのBluetoothのヴァージョンアップは、ファームウェアをアップデートしないとダメなんです。
ファームウェアということは、Bluetoothデバイスのハードウェアを直接制御するプログラムなので、PC本体のメーカーの提供がないとダメな訳です。
OSやドライバーのアップデートではダメなんですね。
幸い、自分の使っているDELL社は、ファームウェア(BIOSも)、ドライバー等のアップデートを頻繁に出してくれています。
他のメーカーも、おそらくこのようなサポートをしているんじゃないでしょうか?
Bluetoothマウスの接続が改善されたのは、ファームウェアアップデートのおかげだったかもしれないのです。
また、他のデバイスのファームウェアアップデートでも、基本的機能の追加や改善が期待できると思います。
これからも、特にIT機器の進化の度合いは加速していくと思われます。
そんな中で、デバイスに新機能が必要になったとします。
どうすればいいか?
昔ならハードウェアを交換するしかなかったと思います。
現在では、ファームウェア、BIOSのアップデートにより、
ある程度のハードウェア更新が可能になっているという概念なんだと思います。(間違っていたらご指摘願います・・・)
最新版 NetCommons3.3.6 が、ほぼ1年ぶりにリリースされました!
「重大なセキュリティバグの修正」が含まれるとのことでしたので、
先ほどupdateを済ませました。
関係の方々に感謝申し上げます!
家庭用AC電源の極性について、最も一般的な注意事項は、
「電気工事その他配線の際、接地極を必ず指定された側に接続する」というのがあります。
接地極と大地は常に同電位ですから、通常、人が接地極に触れたとしても感電はしません。
電極に直に人が触れることはほとんど無いはずですが、
例えば電球のネジ側の極には触れてしまう危険性があります。
ですから、電球のネジ側の極には、接地側の線を配線しなくてはならない規則になっています。
また、電気製品の金属部分を触った時に、
感電まではしなくてもピリピリする感覚を経験したことはないでしょうか?
このピリピリする感覚は、電源プラグを逆に刺し直すと低減することがあります。
感電を避けるという観点だけから見ても、電気製品の電源プラグの刺し方で差が生じるのです。
自分は今まで、AC電源の極性については、
感電を避ける理由で「大地に対して電位差が生じないように」意識していました。
ところが、今日初めて、
電源プラグの刺し方によってはWifiルーターが不安定になる(!)
という記事を見つけました!
Wifi系の機器は電源ノイズが大敵だと。
そして、「Wifiを含めたネットワーク機器の電源は、極性を合わせてAC電源に繋ぐべきだ」
とも書かれていました!
Wifiを使うスマートプラグに接続の極性があるのも、そういう理由だったのか!
と初めて納得出来ました。
また、自宅のWebサーバー、ルーター、ハブ等、
全て電源の極性を合わせて、正しく接続してみようと考えているところです。
<参考資料>
自分の自宅サーバー内のサイトのメンテナンス(バックアップ等)についてです。
低TDPの安価な新型マザーボードが出るタイミングで、
マザーボードとストレージ(SSDとHDD)を交換し、OS(Debian)もヴァージョンアップしてきました。
ところが、今回はまだ新型マザーボードが発表されていません。
そこで、ハードウェアの交換を待たずに、Webサイトのバックアップのみ昨夜行いました。
現サイトは個人運用ですから、
サーバーの故障や破壊があった時は、
状況によってはサイトも復旧できず、全て内容が失われることになります。
例えば地震や火災などで、サーバーマシンごと完全に壊れてしまうリスクはゼロではありません。
そんな時は、さすがに仕方ないとあきらめようとは思っています。
しかし、このサイトに備忘録として書き留めてある内容などは、自分にとってかなり貴重なものですし、
昔の想いや考えを過去に遡って読めるようにしておくことも、やっぱり自分には貴重なことです。
そこで、やはり、バックアップといった自分で出来ることは、定期的にやっておこうということになります。
<Netcommonsサイトのバックアップ>
①データベースのバックアップと、バックアップファイルの保管
②インストールディレクトリをそのままコピーして保管
<Wordpressサイトのバックアップ>
①Wordpressに実装されているバックアップ機能を使い、バックアップファイルを保管
現状では、この方法が最も手っ取り早いのではないかと思います。
素人的な方法だと思いますが、サイトのuploadディレクトリが肥大化していたりしても、
ローカルサーバーですし、ハードディスクを追加してそこにSSD内のファイルをコピーしたりも簡単に出来ます!
さらに、自宅内であっても、別の部屋のバックアップサーバーにファイルコピーをする等すれば、
多少であっても安全性は高まるでしょう。
アップルは、スマートフォンなどの基本ソフト(OS)について
「ハッカーが端末に侵入する恐れのある安全上の脆弱性が見つかった」と発表しました。
アップルによると、
OSの脆弱性によって影響を受けるのは
「iPhone」の「6S」以降のモデル、
第5世代以降の「iPad」
「iPadプロ」のすべてのモデルなどです。
アップルは、
ハッカーがこの脆弱性を利用して端末を乗っ取ったり、
悪意を持って作成されたWEBコンテンツを通じて端末に侵入することができる、
といった恐れがあるとしています。
アメリカ政府のサイバーセキュリティ当局は
「ハッカーはこれらの脆弱性を悪用する可能性がある」
と警告していて、
できるだけ早く必要なアップデートを行うようユーザーに呼び掛けています。
8/20(土) 4:49配信
旧URLのアクセスがあった時への対応はどうしようか迷ったんですが、
対応しないというのも不誠実だと思い、調べてみました。
「Redirect」を使うというのは何となく分かっていたんですが、
旧URLを使ったサイトを用意する必要があるのではないかと思い込んでいました。
今回、時間がたっぷりとあったので、色々と調べたり考えたりしているうちに、
apacheの、旧URLに対応したヴァーチャルホストの設定ファイルに、Redirect設定を書き込めば?
と思いあたりました。
旧URL用httpアクセス設定ファイル 〇〇〇.confの中身は
<VirtualHost *:80>
ServerName 〇〇〇.pgw.jp
Redirect / https://△△△.mydns.jp/
</VirtualHost>
だけです!
このあと、LetsEncrypt自動設定を行います。
#certbot --apache
旧URL用の処理を選ぶと、旧URL用httpsアクセス設定ファイルを自動で作ってくれます!
さて、以上の設定を済ませて運用した結果ですが、
現状、これで旧URLアクセスを新URLサイトに導けているようです。
旧URLサイトの特定のページも、新URLサイトの同じページに誘導出来ています!
補足ですが、旧URL、新URL共に利用できるよう、
DDNSサービスサイト(MyDNS)に定期的に通知を送信し、DNS情報を更新し続けていただいています。
自分は、旧サイトで初めて Netcommons の運用を始めました。
その時のアクセスURLは、お世話になっている Mydns サイトで取得できるドメイン名を使うことになります。
その時、〇〇〇.mydns.jp より、〇〇〇.pgw.jp の方がかっこいい感じだと思い、ドメインはこれに決めました。
そして、ホスト名 www を付けて http://www.9monotaira.pgw.jp をアクセスURLとしたんです。
ずっとこれで運用していたんですが、ある時TREND.MICRO社の「サイト安全性チェック」で確認したところ、
この「安全」判定にはホッとしたんですが、
何と、サイトのカテゴリ評価は・・・
ん?
出会い?!
出会い系サイト?!!
ヒドイでしょう?
汚名だー!
「評価内容変更のリクエスト」は当然しました!
これで一度は改善されたんですが、
サイトをSSL化したところ、またも「出会い」カテゴリに分類されてしまったんです!
しばらく考えてみたんですが、これは、ドメイン名 pgw.jp を使うことに問題があるのではないかと思いあたりました。
例えばこのドメインが悪用された例があるとか。
試しに、存在しないサイト名 https://kakuu.pgw.jp を「サイト安全性チェック」で同様にチェックしてもらうと、
予想通り「出会い」カテゴリと診断されました!
これで状況が掴めました!
こんな訳で、旧サイトのアクセスURLをドメインも含めて変更できないか考えることにしたんです。
①Netcommons3サイト内のアクセスURLが書いてあるファイルですが、
インストールディレクトリ¥app¥Config¥application.yml です。
この中のアクセスURL(1か所)を書き換えます。
②DynamicDNS等の設定は前もって済ませておく。
(certbot --apacheによるLetsEncrypt設定で、外部DNSに新URLを行き渡らせておかないとダメ)
③次は、WebサーバーApache2の設定ファイルです。
まず、
#a2dissite 〇〇〇.conf
で、該当サイトへのアクセスを無効にしておきます。
また、
#a2dissite 〇〇〇-le-ssl.conf
も実行しておきます。
#systemctl reload apache2
④新しいURL用の △△△.conf を作成
⑤新URLアクセスを有効にする。
#a2ensite △△△.conf
#systemctl reload apache2
⑥LetsEncrypt自動設定
#certbot --apache
あとは対話形式で操作を選んでいけばサイトssl化が完了!