Google Meetの標準機能として、映像の露出（明るさ）を自動調整する機能が加わった。いろいろと試してみたので、その話。
バーチャル背景を常に使っているのであれば、便利な機能なので使わないという選択はないと思う。これをブラウザ上でやるのだから、すごい。
Googleカレンダーで有効になった勤務場所のメインオフィスの設定は、Google Workspaceの管理者が設定する必要がある。その設定方法。
1. Google Workspaceの管理画面を開く
2. 「ディレクトリ」→「ビルディングとリソース」→「リソースの管理」を開く
3. 「ビルディングを管理」をクリックする
4. 「新しいビルディングの追加」もしくは、既存のビルディングを編集する
5. ビルディングの追加や編集が終わったら、「ディレクトリ」の「ユーザー」を開く。
6. メインオフィスを設定するユーザを開く。
7. 「ユーザー情報」のパネルを展開する。
8. 「従業員情報」を編集する。
9. 「ビルディングID」に上で追加したID（ビル名）を入力する（選択はできないので、コピペなどで間違えないように入れる）。ここのビルディングIDがビルディングの管理のIDと一致しないとユーザに表示されない。
10. 入力が終わったら、保存する。
11. ユーザサイドで確認してもらう。ただし、反映されるまでに時間がかかる。
そのまんまだが、CiscoルータでのDHCPアドレスの払いだし期間は、デフォルトで1日。ユーザ側で、払い出し期間を変更しなければ、デフォルトの1日のまま。
コンフィグに明示的に設定されていない場合は、「show ip dhcp binding」をCiscoの機器で実行することにより、払い出し期間が何日であるかを調べることができる。
払いだしたDHCPアドレスを確認するコマンドは、Catalystと同じ。
CiscoのルータにTelnetかSSHでログインして、Enableモードにする。Enableモードで、` show ip dhcp binding ` を入力し、確認する。
実行例）
CISCORT#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.99.13 01cc.4463.9e92.c9 Sep 01 2021 02:28 AM Automatic
192.168.99.44 0124.29fe.5d70.62 Sep 01 2021 12:08 PM AutomaticGitlab CE 13.10.3 がインストールされたUbuntuで、apt upgradeしたときに、Gitlabだけバージョンアップできずにエラーになった。古いままにもできないので、ステップを踏んでバージョンアップされたときのメモ。
エラー
(データベースを読み込んでいます ... 現在 327380 個のファイルとディレクトリがインストールされています。)
.../gitlab-ce_14.2.3-ce.0_amd64.deb を展開する準備をしています ...
gitlab preinstall: It seems you are upgrading from major version 13 to major version 14.
gitlab preinstall: It is required to upgrade to the latest 14.0.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: アーカイブ /var/cache/apt/archives/gitlab-ce_14.2.3-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
/var/cache/apt/archives/gitlab-ce_14.2.3-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)下記のコマンドを順番に実行して、ステップを踏んでGitLabをバージョンさせた。 ”13.10.3”→”13.12.11”→”14.2.3”の順にバージョンアップさせた。”14.2.3”はバージョンアップをしたときの最新バージョン。
sudo apt-get update
sudo apt-cache madison gitlab-ce
（各マイナーバージョンの最後のバージョンを調べて、次のインストールから指定した）
sudo apt-get install gitlab-ce=13.12.11-ce.0
sudo apt-get install gitlab-ce=14.0.10-ce.0
sudo gitlab-ctl reconfigure
sudo apt-get install gitlab-ce=14.2.3-ce.0Gitlab CE 14.2.3のインストールをしたときにエラーが表示されたが、実際には成功していたようだ。
参考 https://docs.gitlab.com/ee/update/index.html#checking-for-background-migrations-before-upgrading
ウェブの入力で、数値入力のみをさせるタグ。html5以降で、inputタグのタイプをnumberにすることで、数値入力専用になる。オプションの”step”で指定することにより、入力できる最小単位を決められるので、stepで少数を指定することで、入力を少数でできる。
<input type="number" step="0.5" max="24" min="0" value="0" class="chara4">解説
入力の枠の幅を”size”では指定できないので、CSSで指定した。下記では、4文字分の幅にしている。
input[type="number"].chara4 {
width: 4em;
}Windows10 21H1で、WSLをインストールすると、最初から規定のバージョンが2になっている（デフォルトでWSL2になっている）。
設定を変えなくても、WSL2の機能を使えるので楽。
SQL Serverへの接続に使用するポートは、通常、TCPの1433番ポート。デフォルトでインストールしたSQL Server（既定のインスタンス）しかなければ、これで接続できる。名前付きで、SQL Serverをインストールした場合は、SQL Server Browerサービスを使用することにより、1434番ポートで、UDPを使用する。
SQL Serverでポート番号を調べると、1433と1434が出てくるのだが、これをTCPだけで設定してしまうと、SQL Server Browerサービスを介した名前解決でエラーになる。エラー時には、エラー番号の26なので、SQL Server Browerサービスの起動を確認するのだが、これが起動されている場合には、UDPの1434番ポートが通信可能になっているかを通信経路上（SQL Serverのサーバと、経路のネットワークと、クライアント）で確認する。
Provider: SQL Network Interface, error: 26さらに注意事項として、名前付きインスタンスが動的ポートで構成されるようになっている場合（デフォルトだと動的ポート）、1433番ポートを使用して、SQL Serverが起動していない。名前付きインスタンスの１つしかインストールされていない場合には、起動ポートを1433に固定することで、他のポートは空けなくてもよい。
参考： https://docs.microsoft.com/ja-jp/troubleshoot/sql/connect/resolving-connectivity-errors
vROpsのサイジングのガイドライン。ガイドラインでの大きな指針は、CPU数とメモリサイズ。これが監視対象となるホストの数とゲストの数から、サイジングされる。データを保管するHDDサイズについては載っていない。HDDというかVMDKは追加できるから、ということだろう。
vRealize Operations 8.5 Sizing Guidelines (85062) (vmware.com)
https://kb.vmware.com/s/article/85062
NginxにPHPを動作させるための設定をいれたのだが、アクセスすると、「File not found.」と表示されて、PHPの処理がされない。Nginxのエラーログを見てみると、下記の表示があった。
FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream,Nginxの「/etc/nginx/sites-available/default」のPHPに関連する設定は、下記のように設定していた。
# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}上記を、次のように修正したところ、正常にPHPの処理が行われた。
# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
root /var/www/html;
include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}そもそものエラーが、ファイルの場所がわからないということなので、「root path」でドキュメントルートを指定したことにより、正常に処理ができるようになった。Nginxの設定は、何回やっても難解でどこからしらで躓く。