Category: work

Lightsail（WordPress環境用として提供されている）環境へBasic認証をかける必要が有り、トライした。

AWSでの説明は
https://docs.bitnami.com/aws/infrastructure/lamp/administration/use-htpasswd/
に有り、基本はこれに従うが、どうも、手元の環境とファイル構成が微妙に異なる。ドキュメントが最新になっていない（か、私の環境が古い？）のではと思われる。

ドキュメントでは
/opt/bitnami/apache2/conf/vhosts/wordpress-vhost.conf
/opt/bitnami/apache2/conf/vhosts/wordpress-https-vhost.conf
の2ファイルへ設定を追記するようになっているが、conf　の下へ　”vhosts”は存在しない。

今回
/opt/bitnami/apps/wordpress/conf/httpd-app.conf
ファイルへ設定を追記する事で対応した。
通常のapacheの設定では、設定を有効にしようとする親ディレクトリへ”.htaccess”を記載するが、この設定は有効にならない。
もう少し調べる必要は有るが、取り敢えず、これで、設定が有効に機能している。

資料を整理していたら、信頼性確保の為の格言が有ったので健忘メモとして残す。

①どんなに忙しくても、基本動作を守れ。
②品質＝信頼性×性能×操作性。どれがゼロでも結果はゼロ。
③設計の初期段階で十分検討せよ。その苦労が高品質を生む。
④不安な箇所にはバグが潜む。解らぬ事は解らぬと言え。
⑤変更による影響は、その前後も丹念にチェックせよ。
⑥実績の有るロジックに手を加えたら、必ずデグレードが有ると思え。
⑦文章作成やコーディング後は、自己チェックを最低３回は行え。
⑧マニュアル※は製品の顔。マニュアルの良否が製品の良否を左右する。
　※：システムの運用で顧客が使うすべて
⑨仕様の値は最低５点法（異常－最小－境界－最大－異常）でチェックせよ。
⑩５分の確認の省略が、いつかは５日間の手戻り作業を生むと思え。
⑪組み合わせ条件は必ずマトリックスにして考え、チェックせよ。
⑫代用品による替え玉テストは、実機確認の代用にはならない。

後
システムは動いて初めて評価の対象になる。どんな素晴らしいシステムでも、稼働しないシステムは０点で有る。９９％完成していても、０％の完成も同じ。

追記

⑬作成（コーディング等）時は、自分は天才と思って作業せよ！
　テスト（デバッグ）時は、自分はバホ（バカでアホ）と思って作業せよ！

上記、最近の若い人には刺さるんだろうか？
言い方とかは別として、物事の本質は変わらないと思うんだけど、どうなんだろ？

以下の投稿は半分愚痴です。

最近、マイナンバーカード関連のデータ紐付け（口座番号とか、ポイントの付与とかｅｔｃ）の間違いが話題になっていますが、大臣とかの発言を聞いていると、非常に違和感が有ります。

そもそも、無理矢理感（本来の目的を隠して）が有る導入が歪みを生んでいるのでしょうが、それはさておき、データの移行で、電子化された（論理的に明確に紐付けが出来る場合）物以外を移行すると、数％とかのエラーが出るのは普通（と言うか、常識）です。紙で保管されているのを入力するとかだと、１０％とかを越える事も珍しく無いのが当然でした。
なので、データのスクリーニングとか突合が出来るようにシステムを考える（設計する）のです。
大規模のシステムでは、これが非常に難しいので、出来る人が限られていたように思います。頭の良い人が集まっている、大手の企業さんでも、本当に対応出来る人は、個人名が上がるぐらいの少なさだった記憶が有ります。
データの正規化が流行った（今もデータを追加する観点からは非常に有効な手法。定着していると言うべきかも）のも、その一つの流れだと思います。
大規模のシステムを新規に作る事は非常に大変ですが、今、そのような経験が有る人が非常に少なくなっている（エンジニアさんが、リプレース案件がほとんどなので、新規構築を経験出来ない）のではと思います。
政府主導なので、システム全体の絵を描く人が居ないのではと思いますが、後付けの改修では、中々収束しないのが普通なので、今後もポロポロ出るのでしょうね。そのツケは、結局、全員で負担する事になるかと思うと・・・（私は、先が長く無いでしょうから、子供たちとかが心配）。

と、ここまで書いて、電々ファミリーと呼ばれた３社（日立、富士通、ＮＥＣ（ＤＩＰＳの製造会社））の企業文化を思い出しました。野武士、公家、武家　とそれぞれ呼ばれていたような記憶が有りますが（定かでは無い）、結果に対する執着心とそこへ到達する為のプローチが随分異なっていたように感じた事が有ります。今回、システム提供側の某社（偉い方）の発言を見ていて、だからこんな事を・・・と思わされる所が有るように感じた方が多かったのでは無いでしょうか？
（誹謗中傷とかの意図は有りません。念の為）

システムって、文化が変わる（ＣＵＩ－＞ＧＵＩ－＞Ｗｅｂ－＞スマホアプリ　ｅｔｃ）時には、エンハンスですら敷居が高い（著名なＰＫＧとかでも、失敗している事例が結構有る）ので、もっと困難であろうと想像されますが、日本の底力を見たいものです。期待したい。

秘密情報の保護ハンドブックが２０２２／５／１７時点で更新されていた。ちょっとページ数が多いですが、一読の価値が有ります。

https://www.meti.go.jp/shingikai/sankoshin/chiteki_zaisan/fusei_kyoso/pdf/20220517_3.pdf

本HPで使用しているSSL証明書は、Let’s Encryptの発行する物を使用している。これの証明書Keyサイズは256Bit。何処かのドキュメントには2048Bit以上を推奨とかの記載が有るので、少し勉強してみた。

現在の証明書は以下。

　署名アルゴリズム　　　　 sha256RSA　　　　　＜－鍵交換とかの指定

　署名ハッシュアルゴリズム sha256　　　　　　　＜－証明書でのハッシュ関数

　公開キー ECC(256 Bits) 　　　＜－ECCは256Bits以上を推奨

　公開キーのパラメーター ECDH_P256　　　　 ＜－ECDHE 256Bits以上　RSA 2048Bits以上

朝日新聞社とかと一緒。Google社とかは、公開キーがRSA(2048Bits)で異なる。

現状の状況でセキュリティとかの問題は無い（推奨される状況をクリアしている）事が確認出来たので、このままとする事とした。

＜参考メモ＞

　CAの署名アルゴリズムと鍵長の推奨（必須としてクリアすべき）は以下。

　・ECDSAとSHA-256の組み合せで鍵長256Bits以上　　　　＜－本HPはこちら

　・RSA署名とSHA-256の組み合わせで鍵長2048Bits以上

　参考となるページのリンク

https://it-tech-note.com/ssl-tls/

<2023/1/20 追記　参考情報＞

暗号移行の記事が有った。３年以内とかには対応が必要となるみたい。多分、その頃までこのサイトは維持していないと思うが、知識としてはウオッチしておきたい。

https://qiita.com/lemiyachi/items/c20a18b172c6f192a262

２０年近く前に作成したメモ。現状でもほとんど変更が無いはずなので、健忘禄メモとして。

cronの設定
コマンドを自動実行してくれるcronの設定です。最近のディストリビューションでcronがインストールされないものはないと思います。ただ、ひょっとすると動いていないかもしれない（自分で止めていない限り動いていると思いますが）ので、ps -ax などでcronが動いているか確認してください。動いていない場合は

/etc/rc.d/init.d/crond start
で動かしてください。

/etc/crontab
cronのデフォルトの設定ファイルは/etc/crontabです。Vine2.5では以下のようになっています。

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

run-parts

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

最初の4行が環境設定になっています。

SHELL
/etc/passwordの記述に関係なく、強制的にここで定義されたシェルを使います。
PATH
PATHの設定です。
MAILTO
cronの実行結果をここで指定されたユーザー宛にメールで送ります。ユーザー名を空にするとメールを送信しません。ただし、MAILTOの記述自体をしないと、crontabファイルの所有者にメールを送ります（デフォルトではroot）。
HOME
cronを実行する際のホームディレクトリの設定です。

run-parts以下がcronが実行するタスクになります。

書式は、

分 時 日 月 曜日 (ユーザー) コマンド

です。（ユーザー）は通常必要ありません。

01 * * * * root run-parts /etc/cron.hourly
上記は、毎時1分にrootユーザー権限で「run-parts /etc/cron.hourly」を実行します。run-partsスクリプトは指定されたディレクトリ以下を全て実行するコマンドです。/etc/cron.～というディレクトリを見てみるといくつかのスクリプトがあると思います。

タスクの登録
自分で新たにタスクを登録するには、/etc/crontabに書いてもいいのですが、それだとrootでしか登録ができません（/etc/crontabの所有者がrootなので）。なので実際には別のファイルにタスクを書きます（何度も書きますが、/etc/crontabに直接書いてしまっても構いません）。

タスクを記述するファイルはVine2.5の場合、「/var/spool/cron/ユーザー名」です。rootの場合、「/var/spool/cron/root」になります。emacs等のエディタでファイルを新規作成しても構いませんが、専用のコマンド「crontab」を使った方が楽だと（私は）思います。

$ crontab -e
とすると実行したユーザー用のファイルを新規作成して、編集できるようになります。デフォルトではviが起動します。

記述する書式は、先ほども書きましたが、

分 時 日 月 曜日 コマンド
です。

分
0～59で指定します。(ワイルドカード）も使用可能です。 時 0～23で指定します。(ワイルドカード）も使用可能です。
日
1～31で指定します。(ワイルドカード）も使用可能です。 月 1～12で指定します。(ワイルドカード）も使用可能です。また、月の名前の最初の3文字で指定することもできます。jun、julなど。
曜日
0～7で指定します。(ワイルドカード）も使用可能です。0と7が日曜日で6が土曜日です。また、sun等の名前で指定することもできます。 コマンド cronが実行するコマンドです。当然実行可能なものでなければいけません。 日付、時間の部分は範囲指定が可能です。例えば1時、2時、3時なら、時間のフィールドに「1,2,3」と書く代わりに「1-3」と書けます。また、何分おき（あるいは何時間おき）という場合は「/」の後に書きます。2時間おきなら「*/2」です。「1,4,7,10」は「1-10/3」と書くこともできます。

10分おきに特定のコマンドを実行するには、

0,10,20,30,40,50 * * * * コマンド
とします。またこれは、

*/10 * * * * コマンド
と書くこともできます。

注意として、書くフィールドは必ず左側から指定するようにしましょう。例えば、毎日1時にコマンドを実行しようとして

• 1 * * * コマンド
  なんて書いてしまうと、毎日1時0分から1時59分まで1分おきにコマンドが実行されてしまいます。こういう場合は

0 1 * * * コマンド
などと「分」の部分も指定しましょう。これで毎日1時0分にコマンドが実行されます。

1時間おきなら、

0 */1 * * * コマンド
としたいところですが、単に

0 * * * * コマンド
でも結果は同じです。

cronは実行結果をメールで送ってきます。これが邪魔だと思ったら、「MAILTO=」を追加します。こうすると全ての実行結果が送られないようになります。特定の実行結果のみメールの送信を止めたい場合は、「コマンド > /dev/null 2>&1」としてください。

crontab -e でタスクを登録したら、

$ crontab -l
としてちゃんと登録されているか確認しましょう。ついでに

$ crontab -r
とすると全てのタスクが削除されます。

cronは1分おきに設定ファイルを監視しているのでタスクを登録してもcronの再起動をする必要はありません。ただし、監視は1分おきなので、「1時34分30秒」に「1時35分」に実行するタスクを登録してもcronは実行してくれません。これは「1時35分」に新たなタスクが登録されたとcronが認識するためです。

もし、タスクが実行されなかったら、ログファイルを眺めてください。ログは「/var/log/cron」に出力されています。

老化を意識せざるをえない年齢になっているけど、米スタンフォード大学の研究結果が何カ所かでニュース化されていた。これによると、老化は一定の速度で進む訳ではない。３４才、６０才、７８才の時、ピークを迎えるとの事（＝この年齢前後で急激に老化が進むとの事か？）。タンパク質の分析による研究結果では。

不惑（４０才）、還暦（６１才）、喜寿（７７才）　等、昔の人の区切りとした年齢は人間の生理的な老化とよくリンクしているのかも？。厄年（大厄が４２才（男性）３３才（女性）、小厄が６１才（男女とも））とも近い。

下記のリンク先は記事の一つ。

https://project.nikkeibp.co.jp/behealth/atcl/news/19/00106/?P=1

コーディング量を対象規模として扱う場合の考え方

テスト対象規模	不良評価規模	テスト対象規模	不良評価規模
新規UOC	新規UOC	新規UOC	新規UOC
新規自動生成×A	新規自動生成×A	新規自動生成×B	新規自動生成×B
改造UOC×C	改造UOC	改造UOC×E	改造UOC
改造自動生成×C	改造自動生成	改造自動生成×E	改造自動生成
改造母体×D		改造母体×F	改造母体×G
		母体×F	母体×G

パラメータ	標準値／目安値	設定値範囲	解説
A	０．１を目安	0.05～0.2　程度	自動生成はユーザコーディングに比べ、基本的に不良の作り込みは少ないとの前提。
B	0.3を目安	0.0＜0.3＜1.0	”A”と同様の考え方。但し、結合以降では、自動生成部分も含めて機能の確認を実施する事が必要。
C	2を目安	1.5＜2.0＜2.5	改造については、修正規模でみた場合、新規より不具合を作り込む可能性が高い事を考慮する。
D	0.06を目安	0.05＜0.06＜0.10	未修正の母体への改修箇所の影響を考慮する。
E	1or2	１～２	流用時　１　継続改造時　２　　継続改造時は、元のPGの改修で有る。
F	0.1～0.3　を目安	0.05～1.0　程度	流用時　0.3～1.0　継続改造時　0.06　を目安として、PRJごとで指定する。
G	0.0～0.3　を目安	0.0～1.0　程度	流用時　0.3～1.0　継続改造時　0.0　を目安として、PRJごとで指定する。

Xeon Bronze 3204 1.9GHz 1P6C 16GB メモリ　６００ＧＢＨＤＤ×３　ぐらいのスペックを前提として、クラウドとの環境を簡易的に比較した。

項目	オンプレ	プライベートクラウド	パブリッククラウド	備考
コスト形態	資産	資産＋経費	経費
初期費用	高額 機器やライセンスの購入等	←	安価 初期費用は無料か安価
月額費用	固定費	固定費＋変動費	変動費
調達期間	数週間～	←	即日～
カスタマイズ	柔軟に対応可	←	制限有り
拡張性	困難（機器の増設等）	←	容易
縮小性	困難（機器の増設等）	←	容易
既存システムとの連携	容易	←	困難
自社内接続	高速	回線等の条件による	←
拠点よりの接続	回線等の条件による	←	←
情報セキュリティ	自社内で閉じた運用が可能	論理的に自社内で閉じた運用が可能	物理的な切り離しは不可 論理的な切り離しとなる
障害対応	復旧に時間が掛かる 障害原因の明確化が可能	←	復旧が短時間で可能 障害原因の特定が困難
災害対応	対応にコストが掛かる	比較的容易	←
冗長化	対応にコストが掛かる	←	比較的容易
更新	５～７年程度で更新が必要	←	不要
環境の継続性	自社でコントロール可	←	クラウドサービスの環境に依存
＜費用＞
初期費用	約1,100k\　※１	←	－	・サーバの構築費等はすべて除く
月額費用（サーバ等）	－	約60k\～（ラック収容面積による）	約31k\～（構成による）
月額費用（電気代等）	約3k\　※２	－	－
月額費用（回線接続）	－	約4.4k\～（回線速度／トラフィックによる）	←	・事務所側（利用側）の回線費用等は含まない
５年総額	約1,280k\	約4,764k\～	約2,124k\～
	※１：ハードの保守は、５年保守モデル前提で試算　＜－　適当！
	※２：電気代等を想定