セキュリティ脆弱性あれこれ
後で調べること
パッケージ管理システムの一種。Node Package Manage
npm installは、npmリポジトリからライブラリ(正確にはパッケージと呼びます)をダウンロードしてくるコマンドです。 ライブラリそのものは下記のサイトから取得されます。
#npm install
npm runでビルドが実施される。
#npm run buildProd
gyp ERR! stack Error: unable to get local issuer certificate のエラーが出た場合
proxy設定をする。
#export NODE_TLS_REJECT_UNAUTHORIZED=0
RUN npm -g config set http-proxy http://proxyname:8080 RUN npm -g config set https-proxy http://proxyname:8080 RUN npm -g config set strict-ssl false RUN npm -g config set proxy http://proxyname:8080 RUN npm -g config set registry http://registry.npmjs.org
npmでpermission deniedになった時の対処法
npmディレクトリのパスを確認する npm config get prefixを実行するとおそらく/usr/localが表示される npmディレクトリのオーナーを自分のアカウントに変更する
sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}
以下のようなエラーが出ており、npm installに失敗する。
npm ERR! Error while executing: npm ERR! /usr/bin/git ls-remote -h -t ssh://git@github.com/eligrey/FileSaver.js.git npm ERR! npm ERR! ssh: connect to host github.com port 22: No route to host npm ERR! fatal: Could not read from remote repository.
解決策 npmのpackage.jsonで、sshプロトコルで、gitにアクセスするように指定している可能性がある。
package-lock.json: "file-saver": "git+ssh://git@github.com/eligrey/FileSaver.js.git#e865e37af9f9947ddcced76b549e27dc45c1cb2e",
これを以下のようにhttpsプロトコルに修正すれば、アクセスできるようになる。
package-lock.json: "file-saver": "https://git@github.com/eligrey/FileSaver.js.git#e865e37af9f9947ddcced76b549e27dc45c1cb2e",
npmで管理しているパッケージをリスト形式で出力 パッケージの依存関係やバージョンを調べるのに便利です。
#npm list ├─┬ @agm/core@1.1.0 │ └── tslib@1.14.1 ├─┬ @angular-devkit/architect@0.1303.7 │ ├─┬ @angular-devkit/core@13.3.7 │ │ ├─┬ ajv@8.9.0 │ │ │ ├── fast-deep-equal@3.1.3 │ │ │ ├── json-schema-traverse@1.0.0 │ │ │ ├── require-from-string@2.0.2 │ │ │ └─┬ uri-js@4.4.1 │ │ │ └── punycode@2.1.1 deduped │ │ ├─┬ ajv-formats@2.1.1 │ │ │ └── ajv@8.9.0 deduped │ │ ├── fast-json-stable-stringify@2.1.0 │ │ ├─┬ magic-string@0.25.7 │ │ │ └── sourcemap-codec@1.4.8 deduped │ │ ├── UNMET PEER DEPENDENCY rxjs@6.6.7 deduped │ │ └── source-map@0.7.3 │ └── UNMET PEER DEPENDENCY rxjs@6.6.7 deduped ├─┬ @angular-devkit/build-angular@13.3.7 │ ├─┬ @ampproject/remapping@2.2.0 │ │ ├─┬ @jridgewell/gen-mapping@0.1.1 │ │ │ ├── @jridgewell/set-array@1.1.1
現在インストールされているパッケージが最新であるかを確認するコマンドです。
$ npm outdated Package Current Wanted Latest Location @agm/core 1.1.0 1.1.0 3.0.0-beta.0 nec-edge-ui @angular-devkit/architect 0.1303.7 0.1303.9 0.1401.0 nec-edge-ui @angular-devkit/build-angular 13.3.7 13.3.9 14.1.0 nec-edge-ui
現在確認されているパッケージの脆弱性を報告します。
$ npm audit ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ High │ Regular expression denial of service in scss-tokenizer │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ scss-tokenizer │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Patched in │ No patch available │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ node-sass [dev] │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ node-sass > sass-graph > scss-tokenizer │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://github.com/advisories/GHSA-7mwh-4pqv-wmr8 │ └───────────────┴──────────────────────────────────────────────────────────────┘
ESXIでシンプロビジョニングでVMを作成している場合、ゲストOSからデータを削除してもVMのサイズは 減少しない。以下が、対応方法
https://rin-ka.net/thin-provisioning-disk-difference/#toc6
シックプロビジョニング(Lazy zeroed) 仮想ディスク作成時に指定したサイズ分の領域を確保します。
シックプロビジョニング(Eager zeroed) 仮想ディスク作成時に指定したサイズ分の領域を確保し、ゼロで初期化します。
シンプロビジョニング 仮想ディスク作成時には最低限の領域のみ確保し、必要に応じて増加します。
Bios設定でAbove 4Mの設定をしても、GUIをアッタチしたOSが立ち上がらない場合、同時に以下の設定をする必要がある。
いったんsshでVMwareにログインし、各GestOSのファイルを設定する。 ファイルの場所は、以下の通り。 ./vmfs/volumes/[volumeのSerial]/[Volume名称]/[Volume名].vmx .vmxファイルを設定する。 ./vmfs/volumes/63d9ba3e-c2cf65dc-f5a7-d85ed3eaaa85/Ubuntu20.04__n1/Ubuntu20.04_n1.mvx
Here, you add the following two parameters, with the value of the second parameter, as shown, set to TRUE
pciPassthru.use64bitMMIO="TRUE"
The value of the first parameter seen in the dialog above is adjusted to suit your specific GPU requirements:
pciPassthru.64bitMMIOSizeGB=
We calculate the value of the “64bitMMIOSizeGB” parameter using a straightforward approach. Count the number of high-end PCI GPU devices that you intend to pass into this VM. This can be one or more GPUs. Multiply that number by 16 and round it up to the next power of two.
For example, to use passthrough mode with two GPU devices in one VM, the value would be:
2 * 16 = 32, rounded up to the next power of two to give 64.
The Linux Foundation より参照
最もシンプルな形式では、 Kubernetes はセントラルマネージャ( 別名:マスタ)と数個のワーカノード(以前はミニオンと呼ばれていました)で構成されています。(これ以降の章で、テストを目的のために 1 つのノードで全てを実行する方法を説明します)。マネージャは、 API サーバ、スケジューラ、さまざまなコントローラ、そしてクラスタの状態、コンテナの設定、ネットワークの設定を格納するストレージシステムを実行しています。
Kubernetes は(API サーバを通して)API を公開します: kubectl というローカルクライアントを用いて、もしくは自分のクライアントを作成し curl コマンドを使用して、API とやり取りができます。Kube-schduler はAPIに届いたコンテナ起動リクエストの転送を受け、コンテナを起動するのにふさわしいノードを見つけます。クラスタ内の各ノードでは kubelet と kube-proxy の 2 つのプロセスが動作します。 kubelet は、コンテナを起動させるリクエストを受け取り、必要なリソースを管理し、そのリソースをローカルノードで監視します。kubelet はローカルのコンテナエンジンと通信します。デフォルトのコンテナエンジンは Docker ですが、人気が高まっている rkt や cri-o を使うこともできます。
kube-proxy は、ネットワーク上でコンテナを公開するためのネットワークのルールを作成し、管理します。
API ベースの通信スキームを使うことで、Linux でないワーカノードとコンテナを使うことができます。Windows Server 2019 のサポートは 1.14 のリリースをもって Stable になりました。ただし、クラスタマスタになれるのは Linux ノードのみです。
全ての内外からの処理はこのコンポーネントを通して行われます。全ての処理はこのエージェントを通して、受け取り、検証される。
どのノードでPodをホストするかを決定するエージェント。スケジューラーが結びつけるリソースを確認し、成功するまで、Podのデプロイを行う。
クラスタの状態やネットワークなどの必要な情報をetcd databaseに格納される。データベースの更新は、エントリを見つけて更新するのではなく、末尾に値をつけることで更新されます。
コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。
コントローラーには以下が含まれます。
ノードコントローラー:ノードがダウンした場合の通知と対応を担当します。
レプリケーションコントローラー:システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。
エンドポイントコントローラー:エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。
サービスアカウントとトークンコントローラー:新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。
全てのWorker nodeはkubelet と kube-proxy、Dockerなどのコンテナエンジンを起動します。
クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。 Podはストレージ、Secret,ConfigMapにアクセスすることが必要になります。Kubeletはそれらのアクセスや制裁を行います。
Gitで利用するREDMINEの書式。
以下はテンプレート
# Name(リポジトリ/プロジェクト/OSSなどの名前) 分かりやすくてカッコイイ名前をつける(今回は"hoge"という名前をつける) "hoge"が何かを簡潔に紹介する # DEMO "hoge"の魅力が直感的に伝えわるデモ動画や図解を載せる # Features "hoge"のセールスポイントや差別化などを説明する # Requirement "hoge"を動かすのに必要なライブラリなどを列挙する * huga 3.5.2 * hogehuga 1.0.2 # Installation Requirementで列挙したライブラリなどのインストール方法を説明する # Usage DEMOの実行方法など、"hoge"の基本的な使い方を説明する # Note 注意点などがあれば書く # Author 作成情報を列挙する * 作成者 * 所属 * E-mail # License ライセンスを明示する "hoge" is under [MIT license](https://en.wikipedia.org/wiki/MIT_License). 社内向けなら社外秘であることを明示してる "hoge" is Confidential.