composer install でエラーになる

composer Laravel mbstring

$ composer install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Your lock file does not contain a compatible set of packages. Please run composer update.

Problem 1
- laravel/framework is locked to version v7.8.1 and an update of this package was not requested.
- laravel/framework v7.8.1 requires ext-mbstring * -> it is missing from your system. Install or enable PHP's mbstring extension.

 

$ composer update
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- laravel/framework[v7.0.0, ..., 7.x-dev] require ext-mbstring * -> it is missing from your system. Install or enable PHP's mbstring extension.
- Root composer.json requires laravel/framework ^7.0 -> satisfiable by laravel/framework[v7.0.0, ..., 7.x-dev].

 

 

原因としてはlaravelを動かすためにmbstringが要るけど、それが入ってないよ

入れてねってこと

 

$ yum list installed | grep string
libunistring.x86_64 0.9.3-9.amzn2.0.2 installed
$ sudo yum install php-mbstring

 

次からは既存と合わせるために、こっちの方がいいかも

$ sudo yum install php72-mbstring

 

これで composer install が実行できるようになる。

MySQLでダンプした大量データを、Cloud9でRDSに一括インポートする方法

MySQL Cloud9 RDS インポート INSERT 大量データ dump

mysqlのエクスポート ＲＤＳへインポート | idealive tech blog

【ターミナル（Linux,Mac）】scpコマンドでサーバとファイルのやり取りをする - Qiita

 

・mysqlテーブル単位のエクスポート

mysqldump -u ユーザー -p データベース名 -t テーブル名 > エクスポートファイル名.sql

 

・mysqlテーブルデータの一部をエクスポート

mysqldump -u ユーザー -p データベース名 -t テーブル名 --where="ＳＱＬの条件を記述（例udate < '2019-01-01 00:00:00'）" > エクスポートファイル名.sql

 

 

Cloud9の storage/logs 配下にでも一時的にファイルをアップロード

mysql -h RDSのエンドポイント -P 3306 -u ユーザー名 -p データベース名 < インポートファイル.sql

 

10万件が1秒ほどのINSERT時間だった

 

 

 

具体的な手順

1. 本番DBに接続可能なサーバに入る

cd ~

 

2. mysqldump -u usernonamae -p -h xxxx.xxxxxx.ap-northeast-1.rds.amazonaws.com dbnonamae tablenonamae -w "jyouken>255 and jyouken<50000" > dumpfilenonamae.sql

 

3. DBパスワードを入力

 

4. dumpを取得したサーバに接続可能な開発サーバに入る

cd ~

 

5. scp -i "~/key/kaginonamae.pem"  ec2-user@xx.xx.xx.xx:/home/ec2-user/dumpfilenonamae.sql /home/ec2-user/

 

6. vimで、DROP TABLE や CREATE TABLE など、LOCK TABLESより上を削除

 

7. Ctrl + G
　UNLOCK TABLES;より下も削除
　5dd

 

8. mysql -h test-xxxxx-xxxxx.xxxxxxx.ap-northeast-1.rds.amazonaws.com -P 3306 -u usernonamae -p dbnonamae < dumpfilenonamae.sql

 

9. DBパスワードを入力

 

10万件レベルであれば、1秒で終わる

1000万件レベルのインポートになると数分かかった。

 

 

 

Google Workspaceを使い、AWSにシングルサインオン（SSO）でログインする方法

Google Workspace AWS シングルサインオン

これで行けた。

G Suite アカウントを用いた AWS へのシングルサインオン | AWS Startup ブログ

 

一旦設定をすれば、ユーザの追加は以下のみ。

・Google Workspaceでユーザ作成

・ユーザー > ○○名○○前○○ > ユーザー情報 の「AWS」にて、Roleの設定

 

 

 

ある日突然、400エラーになったら証明書の有効期限切れの可能性あり。

400. That’s an error.

Error: malformed_certificate

Error while signing data with certificate

 

1. Googleコンソールの「アプリ」から「Amazon Web Services」を選択

https://admin.google.com/ac/apps/unified

 

2. 「サービスプロバイダの詳細」を選択

 

3. 「証明書を管理」を選択、「証明書の追加」、「メタデータをダウンロード」

 

4. 「サービスプロバイダの詳細」で新しい証明書を選択して「保存」

 

5. AWSコンソールでIDプロバイダを選択

https://us-east-1.console.aws.amazon.com/iamv2/home?region=ap-northeast-1#/identity_providers

 

6. メタデータ置換

 

以上で400エラーが解消する。

 

 

 

 

 

ページが無くなった時のために、引用しておく。

 

Step1: AWS で利用する SAML 属性を G Suite のユーザープロファイルに追加
1. 管理者アカウントで G Suite 管理コンソール にログインし、”ユーザー” をクリック、次の画面で右上の “カスタム属性を管理します” と表示されるアイコンをクリックします。

 

2. “カスタム属性を追加” をクリックします。

 

3. 次のようにカスタムフィールドを追加します。

追加せずに既存のフィールドを代用することも可能ですが、新規に作成されたほうがいいかと思います。（その場合、 “部署” フィールドに IAM Role の ARN を登録するなどのようになります。）Role 用のフィールドは必須ですが、 Session Duration は無くても動作するため任意になります。

 

 

Step 2: G Suite でサービスプロバイダの設定と、IdP メタデータの取得
1. G Suite 管理コンソール のトップん戻り、”アプリ” > “SAML アプリ” の順にクリックします。

 

2. 新規作成を選択し、”Amazon Web Services” をクリックします。。

 

3. “ダウンロード” ボタンから IdP メタデータをダウンロードして下さい。

 

4. “サービス プロバイダの詳細” は変更箇所はありません。

 

5. “属性のマッピング” 設定を行います。

どのような情報を引き渡せばいいかは 認証レスポンスの SAML アサーションを設定する に記載がありますが、”RoleSessionName” と “Role” は必須になります。”RoleSessionName” はユーザ毎にユニークであることが好ましいのでメールアドレスを利用します。

また、デフォルトの Session の有効期間は1時間であり、作業中に切れることも多いかと思います。パラメータで可変にするためには属性名に https://aws.amazon.com/SAML/Attributes/SessionDuration を設定し、値に “Session Duration” を設定します。

 

Step 3: AWS アカウントで IdP の作成
1. IAM の管理画面を開き、”ID プロバイダー” を選択し “プロバイダの作成” を行います。

 

2. 先ほどダウンロードしたメタデータをアップロードし、任意のプロバイダー名を設定して下さい。

 

Step 4: AWS アカウントで IAM Role の作成
1. IAM の管理画面を開き、”ロール” を選択し “ロールの作成” を行います。

 

2. “SAML 2.0 フェデレーション” を選択し、先ほど作成した ID プロバイダーを選択します。

 

3. SAML 経由で認証したユーザに割り当てる権限を設定します。今回は試しに ReadOnlyAccess を付与します。

 

4. 任意のロール名をつけて作成します。

 

Step5: AWS で利用する SAML 属性を G Suite のユーザープロファイルに追加
1. 属性を設定するユーザのプロファイルを開き、”ユーザー情報” をクリックします。

 

2. AWS の項目を入力します。

設定する内容は 認証レスポンスの SAML アサーションを設定する に記載がありますが、Role については Role ARN と ID プロバイダーの ARN をコンマ区切りで記載する必要があります。今回の例だと arn:aws:iam::123456789012:role/GsuiteReadOnly,arn:aws:iam::123456789012:saml-provider/GSuite のようになります。（アカウント ID はご自身のものを設定して下さい。）

また、今回は Session の有効期間を最大の12時間 (43200秒) に設定しておりますが、こちらは推奨値という訳でははないのでお客様の要件に合わせて設定頂く必要があります。

 

6. G Suite で SAML アプリの有効化
設定直後は無効化されているため、SAML アプリを有効化する必要があります。

今回はテストのためすべてのユーザーに対して有効化しますが、実際には部門ごとにロールアウトしていく方が好ましいかと思います。また、 SAML アプリが有効になっていても、前述の SAML 属性が設定されていない場合は認証に失敗します。

 

7. ログインできるかの確認
一通り設定が終わったら、アプリランチャーの最下部に “Amazon Web Services” のアイコンが表示されます。（アイコンは “SAML アプリ” の設定で変更可能ですが割愛します）

こちらをクリックすることで AWS のマネジメントコンソールへログインすることが出来るようになります。

 

ログイン後にコンソールに表示されるアカウント情報を確認すると、次のように表示されているはずです。

G Suite 側のメールアドレスで各個人はユニークに識別されつつ、権限的には IAM Role のものが適用されます。

 

※ Role を複数設定している場合は次のような画面が表示されます。

 

 

 

親からの躾

親 躾 精神 鬱

新年早々、また親からの躾の記憶が頭に蘇ってきたので、吐き出しておく。

 

躾というのはペットに対してするものだと思う。

人間には言論と愛情を持って諭すことが必要だと思う。

忙しさを言い訳に、説明をせず、何かを強制することは本当によくない。

 

自分の頭で「何故」と考えるタイプの人に、躾をする場合は、ちゃんと何故かを説明してあげないといけない。

というか、経営者が社員に何かを強制する時も、国家が国民に何かを強制する時も、必ず「説明」が必要。親というだけで「説明」を省き、さらにそれを繰り返すと、しっぺ返しを食うのは当然だと思う。

本質的に「強制」は良くない。ただ、やむを得ず「強制」をする場合は必ず説明をしないといけないと思う。

 

親と仲が良い親子が羨ましい。

贈与税のことを調べていて、この思いがまた蘇ってきた。

小さな頃から親子仲が特に良いわけではないので、実家に帰る（実家に定住する）という選択肢がない。

 

実家に定住するというのは、過去の忌々しい記憶を肯定することになってしまう。

 

自己分析をすると、否定されることが極端に嫌いなんだと思う。プライドが極端に高いともいえる。

だから極端な努力をするし、それなりの結果も残しやすいが、扱いが難しい性格だとも思う。ただ、親としてはそこを考慮して、子育てをして欲しかった。

 

 

躾をされた身としては、以下のことを思う。

・完璧主義に躾をすると、それを完璧に再現しようとするから良くない。

・完璧主義は放っておいても完璧に行こうとするので、大丈夫だよやらなくてもいいよ。というような緩い方向に持って行ってやる必要があると思う。躾で厳しい方向に持って行くと、それを完璧に再現しようとするから軋轢を生む。

・躾（強制）ではなく、提案を提示すれば良いだけなのに、なぜ強制をするのか。強制ではなく、提案が教育だと思う。

・躾をされると家庭が楽しくない。否定をした場合は、それ以上の肯定（褒め）が必要なのに、自分の場合は褒められた記憶はない。

肯定的なことを言う時は「客観的な感想のような言い方」をして、否定的なことを言う時は「主観的な絶対悪というような強い言い方」を常にしていた。これは他者に対する接し方として、反対にしないといけないと思う。

 

 

実家の躾を受けた心理的な感想を例えると以下になる。

 ・寒い中、冷たいバケツに入った水を何度も怒りながら、かけられ続ける。

・崖から何度も何度も下に落とされる。

 

 

小学生の頃から、精神的に一人で生きてきた。

小学校低学年くらいから悩み事や辛いことがあっても、精神的に頼ったことがない。

自分の中で論理的に自己解決して、そのソリューションを実行して、解決してきた。

 

仮に相談をしても、忙しさからまともな返答がないか、あるべき論でこちらの感情を封殺されていた。

結果的に、徐々に相談しなくなり、中学生くらいからは何も話さなくなった。

 

半面、その寂しさを紛らわすために、学校では人一倍明るい方だったと思う。

いま思えば、ただ単に家で満たされていないから、学校で発散してるだけだったと思う。だから、交友関係（友達や知り合い）は人一倍多かったが、正常な人間関係を築けていなかったと思う。

寂しさから、親の代わりになるような、安定した存在を探し続ける、心としては亡霊のような存在だったと思う。

 

 

親に相談しないことが、普通かどうかわからないが、心理的に頼っていないので、心理的な感謝が生まれにくい。

辛いときに助け合ってこそ、信頼関係が生まれる。親子の信頼関係が出来ていないというのが正しいと思う。

 

相談する経験がないから、大学を辞める時も、結婚をする時も、起業する時も、どこかに引っ越す時も、世界一周に行く時も、一度も相談したことがない。

相談しても、また冷や水を掛けられるだけだと分かっているから。

事実、決断した後に事後報告をしたときは、想定通り、冷や水を浴びせてきてくれた。

自身の「心配」という気持ちを、相手にぶつけているだけということに、気付いてほしい。

 

 

衣食住を提供して、躾をしっかりやったのだから、子育てをしっかりやった。と思っていると思う。

折に触れて、中学高校の頃から上記のことを話したり、アピールしたりしているが、向こうの心には届いていないと思う。

だから絶対に帰らない（実家に定住しない）という方法で、いまだに抵抗しているんだと思う。

過去を肯定したくないから。

 

何なんだろうか、この人生は。

 

普通に親子仲が良く、たまにケンカしたりしながらも過ごし、

友だちも出来、新しい家族もでき、地元で生まれて死んでいく、こういう人はとても幸せだと思う。

 

生まれてから、一番最初に育むべき親子の関係を正常に構築できていない（と思っている）自分としては、一生幸せがやってくることはないと思う。

 

幸せというのは、自分の心の在り方次第だと思うから、環境や状況が客観的にみて最高だったとしても、自身の心が最高に満たされることがない。

 

ピラミッドを組み上げる時の土台の部分がブレブレなのだから。

本当に罪深い。

 

どうすれば良いのだろうか。

 

たぶん「赦す」とか「足るを知る」という精神的な状況に、心の奥底から行き着くことだと思うのだが、まだ難しい。

火災保険

火災保険 借家人賠償責任補償 個人賠償責任補償 失火法

火災保険の更新をしようとしたところ、

類焼損害保障特約というものがあった。

 

借家人賠償責任特約は、大家に対する賠償の保障だから、

隣の家などに延焼した場合に備えてこれも必要かなと思ったが、

いや必要ない。という結論に至った。

 

 

そもそも過去に調べて忘れていたが、

失火法という法律で、重大な過失がない場合は失火責任が問われないことになっている。

日本損害保険協会 - 損害保険Q&A - すまいの保険 - 問52 火災保険

 

だから、大家に対する賠償だけ保障すればいいことになる。

あと自分の家財。

 

と考えると、この類焼損害保障特約というものはかなり要らない。

無知な人を対象にしてるあくどさを感じる。

 

 

その流れで調べていたら、新たな発見があったので、記しておく。

そもそも個人賠償で3億円の保障が付いているのだから、借家人賠償も要らないのではないかと思ったのだが、これは間違いで、借家人賠償は要る。

 

個人賠償責任補償だと「借りている物」に関しては補償対象外となる

ということらしい。

 

 

借りているものの賠償　=　借家人賠償責任補償

借りていないものの賠償　=　個人賠償責任補償

 

【ホームズ】借家人賠償責任補償と個人賠償責任補償の役割とその違い | 住まいのお役立ち情報

-----------------------------------------------------------

最大の違いは、「大家さんに対する補償」と「他人に対する補償」ということです。大家さんも他人じゃないの？と思われる方もいるかもしれませんが、前述したように個人賠償責任補償だと「借りている物」に関しては補償対象外となってしまいます。2つの賃貸補償について比較するために、借りている物件で損害を起こしてしまったケースについて考えてみましょう。

 

①賃貸物件で寝タバコによって火事を起こしてしまい、隣家に損害を与えた

失火責任法によると、寝タバコは過去の判例において「重大な過失」に該当され、隣家の損害を賠償しなければなりません。この場合は個人賠償責任補償が対象となります。また、賃貸物件の原状回復も難しいと思われるため、大家さんに対しては借家人賠償責任補償が対象となります。

 

②賃貸物件で洗濯機の排水ホースが外れてしまい、階下に水漏れが起こった

階下の方への損害賠償は、個人賠償責任補償が対象となります。また、この場合は自分が借りている物件の床も水浸しになるため、大家さんに対しての損害賠償は、借家人賠償責任補償が対象となります。

 

このようなケースでは借家人賠償責任補償と個人賠償責任補償の両方が対象となります。賃貸物件のさまざまなリスクに備えるためには、火災保険に両方付帯しておくのがおすすめです。

-----------------------------------------------------------