CentOS6.0上で動いているファイルサーバーにWindows10からアクセスしたところ突然エラーが出て接続できない。
「安全ではない[ため、ファイル共有に接続できません。 この共有には古いの smb1 プロトコルが必要です。このバージョンのプロトコルは安全ではなく、システムが攻撃される可能性があります。」
どうもWindows10 18.04で勝手に下位プロトコルを禁止したもよう。
幸いにしてCentOS6のsambaでもSMB2には対応可能だった。
以下の記述を/etc/samba/smb.confに入れた
[global] max protocol = SMB2
Let’s noteに限らずノートPCが画面を閉じたかどうかの判定は磁石を使っていることが多いらしく、
ノートPCの上に置くとなぜかスリープ状態になったり、タブレットモード(CF-RZ5の場合)になることが多発。
通常の用途だと重ねることはないのだが、机が狭いときはついつい重ねて使ってしまうのでこの現象に遭遇する。
Ansibleで変更があった時のみ再起動したいときに使うのがhandlerである。
設定ファイルの反映などによく使われるのだが、自分でsambaとhttpdをセットアップしてhandlerを呼んでいた時になぜかhttpの設定が反映されない現象が発生した。
よくよく見るとroleを単独で実行する時は問題ないのだが、連続してやるとsambaのhandlerのみが有効となっていた。
firewalldの設定変更なのでfirewalld_restartという名称をつけていたのだが、この名称で実行したかを判断するので、同じ名前を別のroleでつけているとroleをまたいで実行された時に片方（先に記載したhandler)のみが実行されるようだ。
というわけできちんとhandlerの名前を分けたら無事httpのhandlerが動くようになった。
Ansibleはエラーにならないけど、実行時にはまるというのが多いように感じるな。
何回やっても忘れてしまうのだが、時折ディスクがいっぱいになるたびに
容量が多いディレクトリを探すコマンドを実施している。
てなわけで以前にも投稿したが、階層を指定する方法
# /varの一階層下までのディレクトリ単位で表示 du -h --max-depth 1 /var
「ご対応が必要です」とくるので、まるで詐欺メールのようなタイトルかと思ったが、
以下のように無料のクレジット枠でもクレジットカードの登録は必要である。
２０１６年ぐらいに登録してそのまま放置だったため、利用再開時に以下のメールで警告が２回も来た。
以下引用
Google をご利用のお客様
このメールは、Google Cloud Platform、Firebase、API をご利用のお客様にお送りしています。
Google で記録を確認いたしましたところ、お客様の請求先アカウント XXXXXX-XXXXXX-XXXXXX はお支払い期限が過ぎているか、関連付けられているお支払い情報が無効となっています。原因としては、クレジット カードの有効期限が切れているかクレジット カードがキャンセルされており、お客様から有効なお支払い情報をまだご提示いただいていないことが考えられます。
以下の設定を入れるだけ！
mybatis:
configuration:
map-underscore-to-camel-case: true
課金ができる常態かをチェックするメソッドcanMakePayments
できない状態とはどういうときかというと
ペアレンタルコントロールで課金ができない状況のときである。
存在することは知っていたが、意図せぬ状態で設定してしまうこともあるのだろう。
なぜか課金できないとの問い合わせがあったときはこの設定を見てもらうのが良い。
設定→一般→機能制限の順にタップする
https://support.apple.com/ja-jp/ht201304
クレジットカード決済時に入力するセキュリティーコード(CVV2ともいうらしい)であるが、
実はこれ全てのクレジットカードが対応しているわけではない
（いい加減な値を入れても決済時にチェックされないケースもある）
決済時のサイトの注意書きでは
「日本国内の全てのクレジットカード発行会社が、クレジットカード・セキュリティコード（CVV2/CVC2）対策を施しているわけではありません。」
とか
「クレジットカード会社によっては、セキュリティコードによる認証に対応していない場合があります。」
とか記載があるということは、カード発行元ごとに対応が違うのだろう。
手元で試す限りJCBは大丈夫そうだが、VISA発行元の二枚はいい加減なセキュリティーコードをいれても通ってしまった！
セキュリティーコード自体は単にカードに記載があるので、カード盗まれたらどっちにしようが不正利用される可能性がある。
上記の意味では気休め程度と思っておいた方が良い。
セキュリティを高めるのであれば3Dセキュアを導入するべきだろう。
MySQLでバックアップを取っていても、オペレーションミスは防げない。
間違って今朝あるテーブルを全件DELETEしてしまって真っ青に！
幸いにして早朝４時にバックアップが走り、mysqldumpしているファイルがあったのでそこから復旧させることに。
最初は簡単にテーブルのみを指定するオプションがあると思ったのだがそんなものはなかった。
しょうがないので巨大なMySQLファイルから目的のテーブルを探して、リカバリーすることに！
GRATINA2を使っていた時はこのようなトラブルは皆無だったのだが、
SH-M05にしてからちょくちょくトラブルに遭遇する。
（スマホだから半分諦めているが）
まずは電源OFFであればSuicaは使えるのだが、中途半端に電源ONして起動中の状態（パスワード入力でブート待ちのとき）は使えないようだ。
改札にかざしても反応無しであった。
完全に起動すれば使えるはずだが、さすがに朝の改札で待っている余裕はなかったので物理Suicaで切り抜けた。
次は、地方のお土産やでSuica対応端末があったのだが、これまた読み取りエラー！
二度連発したので、さすがに他に切り替えようと思ったけど三度目の正直で成功。
お店ではあまり失敗したことがないので、IC共通端末の設定ミス（店員側の選択ミス）の可能性もあるかも？？