TL;DR Docker HubにあるMariaDBの公式イメージのメジャーバージョンアップを行う場合、環境変数MARIADB_AUTO_UPGRADEにnon-emptyな値に設定したほうがよい 経緯 Redmineで利用しているMariaDBのバージョンアップを行った。10.4.25から10.6.8に一気に上げた。 途中10.5.15を経由したのだが、その際に以下のメッセージが出たのが気になった。 redmine_db | 2022-06-25 05:16:20+00:00 [Note] [Entrypoint]: MariaDB upgrade (mysql_upgrade) required, but skipped due to $MARIADB_AUTO_UPGRADE setting Docker HubのMariaDB公式サイトを見に行くと確かに以下の記述がある。 Set MARIADB_AUTO_UPGRADE to a non-empty value to have the entrypoint check whether mysql_upgrade/mariadb-upgrade needs to run, and if so, run the upgrade before starting the MariaDB server. Before the upgrade, a backup of the system database is created in the top of the datadir with the name system_mysql_backup_*....

TL;DR 一度Apple Business Manager(ABM)管理外で作成したアカウントと同じアカウントは作成できない。削除してしばらく立っていてもダメ。新規アカウントであることが前提。 Apple Business Manager(ABM)で管理をするなら、ABMに対応するMDM(Mobile Device Management)は必須 ABM管理下のアカウントはアプリを追加できないのが最大のネック。App Storeのアカウントのみ個人アカウントとすれば逃げられるが… ABMで管理するデバイスは、購入時に申請してABMに追加してもらうのがベスト あとで追加もできるが、結構大変 デバイスは初期化される 経緯 Apple Business Manager(ABM)のアカウントが取得できたため、これを利用していろいろ試してみた。現状は以下の通り iPhoneは全営業、iPadは一部営業に配布済み ABM配下でない、個別に作ったApple IDを利用 MDMは一部iPhoneのみ導入済み ABMの画面を見て、MDMがなくてもアプリの配布くらいはできて、Apple Configuratorで作成したプロファイルの配布くらいはできるだろうと思っていた。 なので、MDM配下でない既存のデバイスに対しても設定やアプリの配布もできると考えていた… まず、個別に作ったApple IDをABM管理下に移行できないかとためした。が、やってみた限り、できない。また、個別に作ったアカウントを削除し、2-3ヶ月立った状態で同じアカウントを作ってもNG。すでに他で利用されている旨のメッセージが表示される。 ABMでのアカウントは、これまでに作っていない新規アカウントが前提となることがわかった。 上記を踏まえ、新規という前提でApple IDの作成は簡単にできた。作ったIDでiPadにログインし、App Storeで何もできないことも確認できた。 また、App Storeのアカウントを個人アカウントにすることでAppStoreから自由にインストールできることも確認できた。おそらく、ABMでデバイス登録ができていないため、制限がゆるいのだと思われる。 既存のデバイスをABMに登録するには、MacにデバイスをUSBケーブルで接続し、Apple Configuratorで該当のデバイスを「準備」する必要がある。これが以下の点で大変だった。 https://support.apple.com/ja-jp/guide/apple-business-manager/axm200a54d59/web デバイスは初期化される。 対象のデバイスはWiFiに接続されていないとネットワークエラーとなる。初期化された状態のまま処理してもダメ。Wi-Fi接続までは済ませておく必要がある。 処理の途中で再起動が行われた場合、再起動後にWiFiの情報がクリアされていた場合は、すばやく登録する必要がある これが遅れるとやはりネットワークエラーとなる 上記をクリアしても、最終的にエラーで処理が完了しない が、ABM上ではデバイスが登録されている。 上記を経てわかったのは、デバイスをABM上で登録できたとしても、ABMでアプリをデバイスに割り当てることはできない。それはMDMの仕事ということらしい…ABMでできるのは必要なライセンスの確保(有料アプリの場合は支払)のみ。 今後は以下の方針で行こうと考えている。 デバイス新規購入時は、ABMにデバイス登録するよう代理店に申請し、MDMも合わせて登録する ABMのデバイス登録とMDM利用はセットで考える 協力をもらえる人に関しては、ABM管理外のIDをABM管理下に移行してもらう 一から設定が必要となるため、望み薄か… 新入社員等で新規にApple IDを作成する場合は、ABMで作成してデバイスをMDM管理にする 既存のデバイスの手動登録は大変だが、なんとかやってみる 上記ケース以外では何もしない、そのまま

ChromeOSでは、 [search + v] というショートカットで過去にclipboardにコピーされた内容を5件まで表示し、選択してペーストできる機能があります。が、これ、crostini環境のterminalやvscodeには貼り付けられません。一覧表示まではできるのですが、選択しても貼り付けられないのです。 通常の[ctrl + v]で直近の内容のペーストはできるので、同じ対応が上記コピー履歴からの貼り付けまでは対応していないようです。残念です。

TL;DR 公開されている手順通りには行かないなぁ 経緯 Google Cloud Identity Freeで作成したWorkspaceのアカウントに対し、Azure ADをIdPとしたSSO設定を行いました。故あって2回行いましたが、2回とも試行錯誤したので今後のためにメモ Azure ADにて[Enterprise Application]->[New Application]より「Google Cloud / G Suite Connector by Microsoft」を追加 [Manage]-[Single sign-on]より、[Basic configuration]-[Edit]をクリック 以下のとおり入力して保存する(ドメイン名を「example.com」とする) Identifier (Entity ID) google.com/a/example.com https://google.com/a/example.com https://google.com google.com Reply URL (Assertion Consumer Service URL) https://google.com/a/example.com https://www.google.com/ (Default) Sign on URL https://www.google.com/a/example.com/ServiceLogin?continue=https://console.cloud.google.com [Attributes & Claims]-[Edit]をクリック [Additional claims]を4つとも削除する [SAML Signing Certificate]より「Certificate (Base64)」(※1)をダウンロード [Set up Google Cloud / G Suite Connector by Microsoft]のLogin URLの内容をコピー [Manage]-[Users and groups]にてSSO対象とするユーザーアカウントを登録 Google Adminにログインし、[Security]-[Authentication]-[SSO with third party IdP]をクリック [Thirt-party SSO profile for your organization]の編集アイコンをクリックし、以下のように設定して保存する Set up SSO with third-party identity provider: ON Sign-in URL: (※2を貼り付け) Sign-out URL: https://login....

TL;DR クラウドの設定変更には時間がかかる場合があります。設定変更が反映されることを前提に後続の作業を行う場合は、最低でも2日待って後続の作業をしたほうが良いです。 経緯 Google Cloud Identity FreeでWorkspaceと最初の管理者アカウント(ここではuser@example.comとする)を作成しました。次にadmin@example.comアカウントを作成し、Super Admin権限を付与しました。さらに最初に作成したuser@example.comのSuper Admin権限を削除しました。user@example.comアカウントのSuper Admin権限をadmin@example.comに移動した形です。 次に、Azure ADをIdPとしたSSOを行いました。user@example.comアカウントでうまくログインできないため、Google側の設定を見ようと思い、admin.google.comにadmin@example.comでログインしようとすると、SSO先のAzureログイン画面に転送されてしまい、ログインできません。当然user@example.comも同様です。つみました… 最初、SSOの設定は既定で全アカウントに適用されるのかと思いました。が、だとしたらこのような事例が頻発するはずで、実際Googleのドキュメントを見ると、管理者アカウントはSSOから除外されるとありました。 となると、最初に行った管理者権限の移動が反映されていない可能性がありそう。権限を移動してから12時間程度だったため、クラウドの設定は1日¥見ておいたほうが良いとするとありうる話。念のためサポートから問い合わせを入れましたが無料での利用のため、期待薄。 設定から27時間たったあたりで再度admin.google.comにログインしようとすると、SSOに転送されずにろぐいんできました。 クラウドの設定変更は最大1日程度、とは聞いていましたがたいてい遅くとも1時間以内には反映されるため甘く見て失敗しました。設定の反映が遅延されることを考慮し、遅延するとうまく行かない後続の作業は2日は開けて作業したほうが良さそうです。