私がPC,スマホが好きなため、手元に多数の機器があります。 すべての端末で電話が取れるように出来たら、どの端末でも同じ環境で作業できると考えて050番号を運用していました。が、以下の理由でやめました。 SMSがとれない 現時点でSMSによる認証を完全に避けることは難しい。また、結局、通常の090,080,070の番号は必要。 SaaSで永続性に疑問がないのはTwillioくらいだが、こちらではSMS認証の目的で利用することは規約違反になる。 https://zenn.dev/kawabatas/articles/e996a7d59eeadf 最近の各種MVNOによる料金値下げで、電話番号付きとデータ専用での料金差がとても小さくなった LINEやFacebook Messenger等、ほとんどのメッセンジャーアプリには通話機能があり、それで用が足りることがほとんど。 もし電話番号出ないとダメなタイミングが発生したら、SIMを差し替えればよい。面倒だが、機会はほとんどないのでそれで充分 スマホの購入の際、SIMフリーであることは前提条件となる。現状、すべてSIMフリーではあるが。 NTTcomの050plusを利用していて、毎月わずかですが使わない機能にお金を払うことがなくなり、少し気が軽くなりました。

Ubuntu 20.04の2台構成で、サーバ固有のIPアドレスとは別にクラスタ用IPアドレスを割り振ることでクラスタを組もうとした際のメモ。 通信の送信元はクラスタIPで行いたい。Ubuntuで複数IPを割り当てると一方がSecondaryとなり、通信の送信元にはSecondaryでない方が使用される。これはsshサーバに接続してログに表示される接続元IPで確認。 サーバ固有のIPが192.168.1.191,クラスタIPが192.168.1.11の場合に、クラスタのマスタからメンバに降格してサーバ固有のIPのみ割り振られた状態で再度クラスタIPを追加すると、クラスタIPがSecondaryとなってしまう。/etc/netplan/99_config.yamlにて以下のように指定しているのだが。 network: version: 2 renderer: networkd ethernets: eth0: dhcp4: false dhcp6: false addresses: - 192.168.1.11/24 - 192.168.1.191/24 gateway4: 192.168.1.254 nameservers: addresses: [192.168.1.254] IPアドレスの順番を変えてもダメ。どうも、追加したIPアドレスが必ずSecondaryになるという仕様らしい。対応として一旦クラスタIPアドレスのみ割り当て、サーバ固有のIPアドレスを追加するという手順を踏んだところ、クラスタIPアドレスがSecondaryでない設定をすることができた。 …と思っていたが、それでもうまくいかないケースが発生。 インストール時にサーバ固有IPを初期設定すると、/etc/netplan/00-installer-config.yamlに設定が書き込まれ、そちらも含めて設定しようとするらしく、/etc/netplan/99_config.yamlを書き換えてもサーバ固有IPが解放されない状態となった。これは/etc/netplan/00-installer-config.yamlを/etc/netplan/00-installer-config.yaml.disabledのようにリネームすることで解消した。 /etc/netplan/00-installer-config.yamlを作成しろという記事はあるが、/etc/netplan/00-installer-config.yamlを無効化しろという記載がない記事が多いので、落とし穴かもしれない。

bashで戻り値とexit statusがごっちゃになっていたのでメモ。 [参考] https://www.shell-tips.com/bash/functions/ https://eng-entrance.com/linux-shellscript-function 戻り値 function func1(){ echo "2" echo "err" >&2 return 1 } return_value=`func1` rc=$? 上記コードでreturn_valueに格納される値「2」。function内で標準出力に出力した内容がすべて格納される。標準エラー出力に出力した内容は含まれない。 exit status 上記コードでrcに含まれる値「1」。8bitの範囲である0-255の範囲しか指定できない。

Windowsバックアップの結果通知は、タスクスケジューラにて成功/失敗のイベントログをトリガーにしたタスクを作るよう説明しているサイトが多い。 が、自社の環境ではちょいちょい通知が来ないことがある。イベントログを確認してみると記録はされている。イベントログのトリガは不安定と感じている。 そこで、直接成功/失敗のイベントログを見に行って、その結果をもとに通知するほうが確実と判断。現在テスト中。 以下がとても参考になった。 https://stackoverflow.com/questions/51769582/powershell-script-not-pulling-event-from-event-log 実際には以下のようなコードで運用している # 何時間前までのログを対象にするか $PastHours=12 $StartAt = (Get-Date).AddHours(-$PastHours) # バックアップ成功時に記録されるイベントログ $FilterHashTable = @{ logname = "Microsoft-Windows-Backup" id = 4 StartTime = $StartAt } try{ $actions = (Get-WinEvent -FilterHashtable $FilterHashTable -ErrorAction Stop) if ($actions){ ForEach($action in $actions){ Write-Host "OK: Windows Backup Completed Successfully at $(($action.Task)),$(($action.TimeCreated))" Exit 0 } }else{ Write-Host "CRITICAL: Windows Backup has not run in past $PastHours hours" exit 1 } }catch [Exception] { Write-Host "CRITICAL: Windows Backup has not run in past $PastHours hours" Exit 1 }

Windows 10では半年に1回、「機能更新プログラム」という大型アップデートが配布されます。つい先日、2021年の1回目となる「21H1」が公開されました。 機能更新プログラムは18か月間サポートされるため、過去2回分はスキップできるということになります。 https://docs.microsoft.com/ja-jp/lifecycle/announcements/windows-10-servicing-support-updates 18か月ぎりぎりまで引き延ばすと問題が出た際の対応が大変となるので避けたいところですが、ある程度は様子を見たいところです。WSUSの場合、以下の運用で対応できます。 WSUS管理コンソールの[オプション]-[自動承認]-[更新規則]にて、Windows 10PCが対象となるすべてのルールで「Upgrades」への承認ルールが設定されている場合は解除します これで機能更新プログラムがWSUSに配布されても、PCには適用されない状態となります。 WSUS管理コンソールにて[オプション]-[製品と分類]-[分類]にて「Upgrades」のチェックをつける これで機能更新プログラムがWSUSサーバにダウンロードされるようになります。前述の承認ルールの設定によりPCへの適用はされません 機能更新プログラムの様子見が完了して適用するタイミングで、以下の手順で適用します。 先行して適用するPCと、様子見のPCで別のコンピューターグループを作成してPCを移動します。 WSUS管理コンソールの[更新プログラム]-[すべての更新プログラム] にて承認状態が[未承認]のものを検索すると機能更新プログラムが表示されるので、先行して適用するグループに対してのみ承認処理を行います 先行適用のPCに問題がなければ、様子見のPCを先行適用のコンピューターグループに移動して随時適用します。