Thunderbird で、gmailを受信できなくなった

 メールソフトのThunderbirdで、gmailの受信ができなくなりました。

セキュリティで、はじかれるようです。

ブラウザで、gmailにアクセスすると、メールが届いていて、セキュリティではじかれた形跡がありました。

gmailのサーバー設定は、昔、設定した状態で使い続けていました。

おそらく、今年になって、古い設定でのアクセスを禁止したのでしょう。

サーバー設定を、新しい方法（OAuth2）に、変更しました。

（サーバー名も変更）

受信を行うと、ブラウザが開き、gmailのログインが促されました。

この後、3つの選択肢が表示され、これは、意味が分かりません。

とりあえず、真ん中の選択肢を選んだのが良くなかったのか、面倒なことになりました。

通常なら、パスワードを入力すれば、大丈夫だったのですが、スマートフォンのgmailアプリを使うように指示されました。

スマートフォンを持っていないと、設定できなくなったのでしょうか？

たぶん、アクセス記録に、iPhoneでのアクセスがあることから、こちらによる認証を優先したのだと思います。しかし、そうでなかったら、スマートフォンを持っていないと、今後は、Thunderbirdを利用できなくなります。

不安になったので、Supportページを見ました。

しかし、Gmailアカウントの設定方法は、youtube動画が、エラーを出していて、見ることができません。

これは、私と同じような状態になった人が、調べにきて、アクセスが集中しているのかもしれません。

仕方なく、もう一度、スマートフォンを用意して、設定をやり直しました。

Thunderbirdで受信を行うと、ブラウザが開きますから、ログインします。

次に、スマートフォンのgmailアプリを開きます。ブラウザのgmailを使ってはいけません。

すると、説明にあったように、数字の選択を指示されますから、正しい数字を選択しました。

これで、認証が行われ、無事に、設定を終えました。

Tunderbirdで、gmailを扱えるようになりました。

Windows11 マルチディスプレイで、ソフトを動かせない

 Windows11に移行できるパソコンは、全て、Windows10から移行しました。

残っているのは、ハードウェアの要件を満たさないものだけです。

Windows11にして、困ったこと。

ノートパソコンに外付けのモニタを繋ぎ、マルチディスプレイにしています。

外出先では、ノートパソコンのみとなります。

マルチディスプレイで、外付けのモニタ側に、ソフトを表示していると、ノートパソコンのみとなったとき、表示エリアから外れてしまい、ソフトが起動しているのに見えない状態になることがあります。

Windows10の時は、昔は、このような仕様でしたが、最近では、強制的にノートパソコン側のモニタに移動させるようになっていました。

それが、Windows11では、元に戻ってしまったようです。

Windows11では、マルチディスプレイ周りの設定が増えていますので、設定を変更すると良いのかもしれません。

このようなことになったとき、隠れてしまったソフトを、表示エリアに戻す方法は、

・下のタスクバーに表示されるソフトに、カーソルを合わせ、右クリックメニューから、「移動」を選択。カーソルで移動させる。

・下のタスクバーに表示されるソフトに、カーソルを合わせ、ソフトを選択。Shift+Win+カーソルキーの組み合わせで、動かす。

この2つの方法がありますが、これに対応していないソフトもあります。

こうなると、モニタを繋ぐ方法しか思いつきません。

OneDrive 接続に失敗 0x8004de40

 OneDriveでエラーが発生しました。

OneDriveに接続するときに問題が発生しました

インターネット接続を確認し、もう一度やり直してください。

エラーコード　0x8004de40

エラーコードは忘れましたが、こういったエラーは、しばしば発生しています。

経験的に、businessの方が、よく発生しているような気がします。

ノートパソコン（Windows10）と、デスクトップ（Windows11）で、同時発生。

今回は、デスクトップは、放置で解決。

ノートパソコンは、OSの更新で解決。

原因は謎です。

Windows10の更新 OneDriveで困った

 Windows10の更新がありました。

ダイアログで、OneDriveの項目があり、うっかり、設定を選択してしまいました。

私は、ノートパソコン、デスクトップ、仮想マシンと、複数のWindows10や、Windows11を持っています。

それぞれのデスクトップやドキュメントは、その環境に合わせた状態にしているのに、OneDriveをインストールすると、勝手に、共通にしようとしてきて困ります。

今回、Windows10の更新時に、メッセージが表示され、ブラウザの設定、Micorsoft365の購入などの画面が、次々に表示されました。

この中で、うっかり、OneDriveを持っているので、「利用する」という設定を選び、どうやら、OneDriveの設定が、初期化されてしまったようです。

デスクトップには、他の環境のアイコンが並び、OneDriveでは、競合が発生している様子。

だから、「こんな機能、デフォルトにするなよ」と、いつものように、怒りが。

OneDriveの設定変更と、競合の解決という、余計な手間が増えました。

それだけなら良かったのですが、大事なデータが消されてしまいました。

docker mysql用docker-compose.ymlの記述

 私なりのmysql用のdocker-compose.ymlの記述を決めました。

ここに至る経緯は、なかなか大変でした。

ファイル構成

docker-compose.yml

mysql/Dockerfile

mysql/mysql.env

mysql/conf/my.cnf

mysql/init/01_create_tables.sql

mysql.env

MYSQL_ROOT_HOST=%

MYSQL_ROOT_PASSWORD=パスワード

MYSQL_USER=ユーザー名

MYSQL_PASSWORD=パスワード

MYSQL_DATABASE=データベース名

docker-compose.yml

一部、抜粋

services:

  mysql:

    build:

      context: .

      dockerfile: ./mysql/Dockerfile

    container_name: コンテナ名

    env_file: ./mysql/mysql.env

    environment:

      - TZ=Asia/Tokyo

    expose: 

      - "3306"

    restart: always

    volumes:

      - mysqldata:/var/lib/mysql

Dockerfile

FROM mysql:8.0

COPY ./mysql/conf/* /etc/mysql/conf.d/

COPY ./mysql/init/* /docker-entrypoint-initdb.d/

ファイルの扱い

最初、Dockerfileを用意せず、docker-compose.ymlファイルのvolumesに、my.cnfファイルなどを記述していました。

例えば、

./mysql/conf:/etc/mysql/conf.d/:ro

この場合、コンテナ起動時に、my.cnfファイルが読まれず、エラーが発生しました。

ファイルのパーミッションを変更するか、コンテナ内のmysqlユーザーのUIDを、ファイル所有者と一致させるかすれば、エラーを回避できます。

しかし、この方法は、docker-compose buildを実行する前に、ファイルパーミッションの変更作業か、ファイル所有者のUIDを.envファイルに書き込む手間が必要になります。

後者は、工夫すれば、不要かもしれません。

windowsのWSLで開発し、linuxで実行することを考え、このあたりの処理を不要にするため、コンテナ内に、ファイルをコピーする方法で回避しました。

文字コードの設定

mysqlのコンテナでは、文字コードをutf8mb4に変更する必要があります。

mysql 8.0では、デフォルトの文字コードだと思っていましたが、コンテナでは、latain1になるので、設定変更が必要でした。

この変更は、my.cnfファイルを用意するか、docker-compose.ymlのcommand項目で設定できます。

my.cnfファイルの方が見やすくなるため、こちらの方法を採用しました。

他にも、ポートの公開方法、タイムゾーンの設定など、方法が複数ある中で、上記の記述を選びました。

Docker MySQL

 MySQLのDockerコンテナを動かせました。

これまでも、動かしてはいましたが、設定に誤りがあり、正常には動いていませんでした。

my.cnfファイルのファイル名の問題。

このファイル名を、my.confと、間違っていました。

これにより、このファイルの設定は、コンテナに影響を与えない意味のない設定になっていました。

後で、分かったことですが、このファイルの記述に誤りがありました。

この影響で、my.confというファイル名の時には、設定が無視されることで、コンテナを起動できたのに、my.cnfに変えて、設定が有効になることにより、設定のミスから、コンテナを起動できませんでした。

ファイル名を間違えていたことで、動いていたという、なんともな話でした。

my.cnfの設定ミスは、下記の1行でした。

lower_case_table_names=1

過去のデータベースは、Windowsで動かしていて、Linuxへの移行中です。

Windowsのプログラムでは、テーブル名などに、大文字を使っていて、そこから、小文字へ統一しつつある過渡期です。

データベースで、大文字、小文字の区別があると、Windowsでは動くのに、Linuxでは動かないことになりますから、この設定で、大文字、小文字を区別しないのは助かる機能だと思いました。

しかし、これを設定すると、コンテナが起動しません。

この設定は、諦めることにしました。

わずか、これだけのことですが、これに気づくのに、長い時間が掛かりました。

Docker Windowsでは難しい

VMwareの仮想マシンで、開発環境を構築してきましたが、 Dockerでの開発環境に取り組んでいます。

Windowsに、WSLを導入し、dockerを使っていますが、この環境で動く、docker-compose.ymlが、ubuntuに持っていくと動きません。

原因は、主に、ファイルのパーミッションです。

docker内のユーザーと、ホストのユーザーが異なるため、アクセスできるように、設定を気をつけないと、ubuntuでは動きません。

ユーザーは、

・ホスト？側のファイルを所有するユーザー

・dockerを起動するユーザー

・コンテナ内で、サービスを起動するユーザー

この３つが関わるため、面倒でした。

ファイルの所有ユーザーと、コンテナ内のユーザーの違いについては、情報を、よく見かけますが、dockerのコンテナを起動するユーザーは盲点でした。

*.envで、環境変数（コンテナ内のデータベースのユーザー名、パスワード）を管理しますが、このファイルが、コンテナ内に反映されず、悩みました。

面倒なので、関係のあるフォルダは、下記のコマンドで読み込み権限を与えて解決しました。

$ chmod +r -R フォルダ名

セキュリティを考えれば、UIDを一致させるなどした方が良さそうですが、妥協しました。

また、mysqlでは、my.confとmy.cnfの名前の違いも考慮する必要がありました。

おそらく、ubuntu側で、dockerファイルを作成し、windowsに持っていく流れであれば問題ないと思いますが、逆は、はまりました。