2021/05,江端さんの技術メモ

Ubuntu Desktop 18.04でClamAVによるウィルスチェックを実行する！

を参考にして、ClamAVを、Amazon Lightsailにインストールしたら、(それが原因かどうかは、今一つはっきりしないんだけど)以下のような問題が発生した。

Amazon lightsailにsshログインできなくなった件 (ClamAV のアンインストールと AWS inspectorのアンインストール)

けど、お勧めされたので、AWS EC2(Ubuntu Desktop 18.04)の方には、週明けにインストールする予定。

(T.B.D.)

2021/05,江端さんの技術メモ

私は小心者なので、サーバにログインできなくなるだけで、青ざめてしまいます。

今日も、Amazon lightsailにsshログインできなくなって、パニックになっていました。

原因は、ウイルスチェックツールのClamAVのインストールと、AWS inspectorのインストール(Amazon lightsailでは動かない)が原因と考えられました。

『こういう場合、あわてて動くとロクなことがない』は経験則ですので、まずは、Amazonlightsailの内部情報をコンソールから見る方法をググってみました。

から「メトリクス」を選ぶと

CPUが100%のまま動いているグラフが出てきます。

間違いなく、ウイルススキャンがCPUを喰い捲っている、と思いましたので、いつかは下がるはず、と1時間くらい待ってみたところ、落ちてきました(ケースによっては、3時間、6時間コースもあるようなので、しばらく放っておく勇気が大切です)。

で、この間に、「使用率」と記載されているところをクリックして、「＋アラームの追加」をクリックして、こういう状態になったらアラートが飛んでくるように設定しておきました。私の場合、以下のように設定しておきました。」

で、CPUも落ちついてきて、sshログインができるようになったので、早速パッケージのアンインストールを実施しました。

ubuntu@ip-123-45-67-89:~$ sudo apt-get remove --purge clamav clamav-daemon
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
clamav-base clamav-freshclam clamdscan libclamav9 libtfm1
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
clamav* clamav-daemon*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 1881 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 196083 files and directories currently installed.)
Removing clamav (0.103.2+dfsg-0ubuntu0.20.04.2) ...
Removing clamav-daemon (0.103.2+dfsg-0ubuntu0.20.04.2) ...
Processing triggers for man-db (2.9.1-1) ...
(Reading database ... 196045 files and directories currently installed.)
Purging configuration files for clamav-daemon (0.103.2+dfsg-0ubuntu0.20.04.2) . ..
Processing triggers for systemd (245.4-4ubuntu3.6) ...

で、サービス状態を確認したら、まだ生き残っていたので、これも力付くで停止

ubuntu@ip-123-45-67-89:~$ systemctl list-unit-files | grep clamav
clamav-freshclam.service enabled enabled
ubuntu@ip-123-45-67-89:~$ sudo systemctl stop clamav-freshclam

さらに、AWS inspectorも強制アンインストールを実施

ubuntu@ip-172-26-7-19:~$ systemctl list-unit-files | grep aws
awsagent.service generated enabled

ubuntu@ip-172-26-7-19:~$ sudo apt-get remove --purge awsagent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
clamav-base clamav-freshclam clamdscan libclamav9 libtfm1
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
awsagent*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 196040 files and directories currently installed.)
Removing awsagent (1.1.1677.0-102677) ...
Stopping awsagent-agent service:
Stopping awsagent (via systemctl): awsagent.service.
Removing awsagent-agent service:
Killing existing AwsAgent Updater Cron Jobs:
Found existing awsagent updater cron job PID: 1462
Processing triggers for systemd (245.4-4ubuntu3.6) ...
(Reading database ... 196024 files and directories currently installed.)
Purging configuration files for awsagent (1.1.1677.0-102677) ...
dpkg: warning: while removing awsagent, directory '/opt/aws/awsagent/etc' not empty so not removed

最期に、sudo reboot をして、起動を確認しました。

 

教訓: メモリ1G程度の Amazon lightsailに、あまり凝った仕組みを組込むな

 

 

2021/05,江端さんの技術メモ

「どんなものでも計算します」 社会システム科学の一方法論 ―― 「ゆるシミュ」へのお誘い ――

 

2021/04,江端さんの技術メモ

Amazon Inspectorを使う必要にせまられて、Amazon Lightsail でできるか試してみた。

Teratermで入った、Amazon Lightsailのシェルから、

wget https://inspector-agent.amazonaws.com/linux/latest/install

sudo bash install

# o.o.o.o などの表示が出てきて失敗する場合は、/etc/init.d/awsagent.envの設定をする

# awsagent.envの内容は他のページに記載があるから探すこと

は、さくっと成功したけど、

その後、AWS マネジメントコンソール から、inspector を選んで、

[Amazon Inspector]-[評価ターゲット]→[作成]

Assessment-Target-All-Instances-All-Rules

を選んで、(全部のEC2をターゲットとする、てなことが記載されていたので)編集で何も操作せずに、「保存」を押下。

が出てくる。

[評価テンプレート]-[作成]で

Assessment-Target-All-Instances-All-Rules

を選んで、(全部のEC2をターゲットとする、てなことが記載されていたので)「編集」→「保存」を押下

そのまま「実行」を押すと

と失敗するみたいです。

====

調べてみると「Amazon Lightsail は AWSのEC2と同じ扱いはできない」てな記載があったので、ここは大人しく引き下がることにしました。

私が間違っていることを知っている方は、御一報頂ければ幸いです。

E-mailはこちら(スパム対策)

2021/01,江端さんの技術メモ

助けて頂いた資料: 

 Proxy環境でdockerを外に繋ぐ方法 

今、困っていること

Goが動かん。下記(1)～(4)をやっても、

package main

import "fmt"

func main(){
     fmt.Printf("Hello world\n")
}

以下のエラーが出てきて取れない。（なんだこれ？）

$ go run hello.go
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
このメージを読んで頂いたプログラミングの師匠のSさんに、"go mod vendor" を試すようにアドバイスさました。以下、その挑戦の経緯を記載します。
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go run hello.go
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
やっぱりダメかなぁ(ちなみに、~/hello.go なら、サクっと動く)
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod vendor
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
これもダメかぁ
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod download
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
(手あたり次第モードになってきた・・・)
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod init
go: cannot determine module path for source directory /home/ubuntu/codes/hailing_go/docker/app (outside GOPATH, module path must be specified)
Example usage:
'go mod init example.com/m' to initialize a v0 or v1 module
'go mod init example.com/m/v2' to initialize a v2 module
Run 'go help mod init' for more information.
(手あたり次第モードが進む)
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go run hello.go
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
やっぱりダメかぁ
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod github.com/go-chi/jwtauth/go.mod
go mod github.com/go-chi/jwtauth/go.mod: unknown command
そりゃ、だめだよなぁ
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod verify
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod why
go: github.com/go-chi/jwtauth@v4.0.2+incompatible: reading github.com/go-chi/jwtauth/go.mod at revision v4.0.2: unknown revision v4.0.2
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod init m
go: creating new go.mod: module m
あれ、ググったコマンドを適当に入力したら、"m"というモジュールができてしまったらしい。変なモジュール作ってしまって、やばくないか？
ubuntu@ip-57:~/codes/hailing_go/docker/app$ go run hello.go
go: finding github.com/go-chi/jwtauth v4.0.4+incompatible
go: downloading github.com/go-chi/jwtauth v4.0.4+incompatible
go: extracting github.com/go-chi/jwtauth v4.0.4+incompatible
go: finding github.com/dgrijalva/jwt-go v3.2.0+incompatible
go: downloading github.com/dgrijalva/jwt-go v3.2.0+incompatible
go: extracting github.com/dgrijalva/jwt-go v3.2.0+incompatible
Hello world
あれ、モジュールが自動的にインストールされて,"hello.go"が動いてしまった・・・
この話、実は続続きがある・・・
https://wp.kobore.net/%e6%9c%aa%e5%88%86%e9%a1%9e/post-2156/

(とりあえず、ここまで)

試行錯誤で分った事項

(1)/etc/apt/apt.conf を作る

Acquire::http::Proxy "http://12.34.56.789:8080";
Acquire::https::Proxy "http://12.34.56.789:8080"; // (×https://)
Acquire::ftp::Proxy "ftp://12.34.56.789:8080";

(2)/etc/systemd/system/docker.service.d/http-proxy.confを作る

/etc/systemd/system/docker.service.d/http-proxy.conf を力づくで作った(最初はなかった(みたい))。

修正前:

[Service]
Environment="HTTP_PROXY=http://12.34.56.789:8080/" "HTTPS_PROXY=https://12.34.56.789:8080" "NO_PROXY=localhost,127.0.0.1,.12.34.56.789"

修正後:

[Service]
Environment="HTTP_PROXY=http://12.34.56.789:8080/" "HTTPS_PROXY=http://12.34.56.789:8080" "NO_PROXY=localhost,127.0.0.1,.12.34.56.789"

(なんのことはない、HTTPS_PROXY の "https:"→"http:" としただけ。ただし、これは、個々の環境に依存する問題だと思う)

(3)関係のありそうな"Dockerfile"に片っ端から、以下を書き込む(関係ありそうなファイルは2つ。hitachi_ride_hailing_go/docker/postgis-pgrouting/Dockerfile
hitachi_ride_hailing_go/docker/app/Dockerfile)

ENV http_proxy http://12.34.56.789:8080
ENV https_proxy http://12.34.56.789:8080

（一番最初の”RUN”の前に書き込んでおくとよい）

(4)シェルに以下を書き込んでおく(設定方法は後で調べる)

export http="http://12.34.56.789:8080"
export https="http://12.34.56.789:8080"

 

2021/05,江端さんの技術メモ

本日、嫁さんから「トイレで水が溢れている」と言われて、急遽、トイレの水を止める(止水)作業を行いました。

一応、写真にも残しておきました。

トイレの脇に潜り込むと、止水栓が見えます。

止水栓を押し込むと、水が止まりますが、我が家のケースでは、手前のノズルを前に引き出さないと、止水栓を押し込めないので、以下の写真のようにします。

これで、止水できる状態になります。

以上

 

2021/03,江端さんの技術メモ

これが出ると、流石にパニックになる。

なんどリスタートしても状況が改善されないことがある。

コンピュータの再起動もやったし、

を繰り返したりした。

しかし状況が改善されない。

そして、世界には、「これ」に関する情報がほとんどない。

現状、Dockerなしでの仕事は考えられないので、かなり青ざめた。

ところが、これが意味不明に「突然直る」ことがある

ということで、私から私への提案であるが、

何か別の仕事をしながら、時々、"Restart Docker" を試してみる

を、提案する(エンジニアとしては、かなり腹立たしい対応であることは分かっているが)

焦って再インストールしたり、

https://github.com/docker/for-win/issues/7677 に記載されているような

I have made the following steps and was able to start docker successfully:
1)run "cmd" with administrator rights
2) type Regedit and enter
3)In registry editor find this folder Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE
4)inside this folder you can find "FDVDenyWriteAccess" this rule click on it choose modify and replace value data 1 with 0 , then restart docker and wait for it.

のような方法は、少なくとも1日待って、駄目だったら、試すくらいの気持ちでいよう。

合言葉は、

Docker Desktop for Windows は馬鹿

で、行こう。

========

続編

Docker Desktop for Windowsのメモリ管理やら、面倒なことを弄って、そして、論文やら報告書やらで、1月近く放っておいたら、全く動かなくなった。こいつは、構ってやらないと動かなくなるらしいです。

このアイコンの帆の部分が出なくなって、「docker desktop is runnning」の状態のまま続いて、もうウンともスンとも言わないらしいです。

ここのところ、Windows10を軽量化する為に、色々カルトな設定をしていたので、その中の一つが、Dockerのご機嫌を損ねた可能性があります

Hyper-V 周りがあやしい、と思って、管理者モードで立ち上げた、PowerShellから、

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

なんぞを打ち来んで、待つこと10分。

無事終って再起動したのだけど、全く改善がありません。

ずっとこんな感じ。

『再インストールするしかないのかな』と暗い気持ちになっているところに、この記事を見付けました。

macでdocker desktopが起動しないときのシンプルな対処方法

要するに、

対処方法「Reset to factory defaults」の実行

というのをやればいいらしいようです。色々失うものがありそうですが、(間違いなく、Dockerのイメージは消えるだろうが)、この際『かまわん』と腹をくくって、Windows10でのやり方を試みました。

からSetttingで、てんとうむしみたいなアイコンをクリックします。

すると、「Reset to factory defaults」というのがあるので、これを押下します。

まあ、結果的に、これでdocker for Windowsは動き出すようです(前述のHyper-Vとかも関係あるかもしれません)。

ただ、

ディスクスペースを開けるのに"docker system prune"は便利だが、濫用しないこと。docker-compose buildが再び上手く動くという保障はないぞ

みたいに、何もかも「真っ白」になるので、その覚悟はして下さい。

まあ、「Dockerを再インストールするよりはいいよね」というくらいに追い込まれた時の最後の手段として使って下さい。

========

パソコンを立ち上げ直すたびに、"Reset to factory defaults"をしないと動かないので、Dockerを再インストールしましたが、状況が改善されません。

ほとほと困っていますが、Docker  Imageを毎回作り直している訳にもいきません。

で、この問題を解決する手段として、経験的に分かったことを書き下します。

(1)Docker Desktopはまともに起動するのに、PC起動後10分程度かかる(ような)気がします。

(2)もし「エントツの出てこないクジラ」のアイコンが出てきて手が打てないような状況になっていれば、[タスクマネージャ]→[詳細]→Docker Desktop.exe、その他 Dockerと名前のついているのを全部殺す。

(3)メニューから、手動で、"Docker Desktop"を起動する。

これで動き出すことがあるようです。もう、「良い悪い」といっている場合ではないので、私は、Docker desktopの自動起動のオプションを外して、手動で立ち上げることにしました。なお、手動で立ち上げても、上記の対応が必要となることがあります。

まあ、何かの拍子に直ることを期待しましょう。

 

 

 

 

2021/01,江端さんの技術メモ

"docker system prune"は濫用しないこと。docker-compose buildが再びビルドできるという保障はないぞ！
怖い思いをしたので、戒めの為に記載。
---> Using cache
---> 62e20b49fae8
Step 5/7 : COPY . .
ERROR: Service 'app' failed to build: Error processing tar file(exit status 1): write /go/XXXXX_ride_hailing_go/static/fonts/Noto Sans Bold/64256-64511.pbf: no space left on device  
てなものがでてきて、ディスクが足りないと言われました。
「そんなはずがない」と思いました。
動いているシステムと比較して、その倍の容量のEC2を選んだから。
で、調べてみると、どうもDockerの残骸たちが悪さをしているようでした。
"df" で調べてみると、ルートが93%ほどの使用率となっていたのですが、

を、参考にして、"docker system prune"を実行してみたところ60%以下になり、上記の問題は解決しました。

別のAWSでも試してみました。

現在、64%です。

"docker system prune"を実行

実行後は39%になっていました。

で、その後、悲劇が発生した・・・ docker-compose buildが正常終了しなくなる、という悲劇が。

2021/04,江端さんの技術メモ

AWS inspectorからのセキュリティ対応で苦慮しています。

■AWS Inspectror - Assement Report  Finding Report の一部

詰まる所、セキュリティパッチを当てろということのようですが、どうも当っていないようです。

結構頻繁に、

>sudo apt-get install

>sudo apt-get update

> sudo apt-get upgrade

を精髄反射的に投入してきたのですが、どうも改善されていないらしくて、有識者の方のアドバイスを受けながら作業をしていました。

■ まずは、ターゲットOSの確認
ログイン画面を見る限り、ターゲットOSは、"20.04.2 LTS " で間違いありませんでした。

■"20.04.2 LTS"のセキュリティパッケージを管理しているサイトにいってみた

■https://ubuntu.com/download/desktop/thank-you?version=20.04.2.0&architecture=amd64 からパッケージを確認

ダウンロードを指示されましたが、まさか、isoをインストールして、今のEC2を消滅(リセット)させる、というとありえないので・・・

とりあえず、これはキャンセルしました。

■ https://news.mynavi.jp/itsearch/article/hardware/2040 に記載のあった方法

これを見て、赤線のところを実施していなかったことに気がつきました。

■ >sudo apt-get dist-upgrade の実行結果

 "1029-aws"なる表示がでています。これでパッケージがインストールされたのかもしれません。

■ 結果

本件で、再度、Amazon Inspectror - Assement Report を確認して貰ったら、セキュリティパッチが当っていることが分かりました。

以上

2021/04,江端さんの技術メモ

  1. 前提
    AWS Lightsail に、Visual Studio Code からリモートから入って開発したい。
    Windowsには、SSHが入っているとする。
  2. ~/.ssh/config に以下を書き込む 
    Host sea-anemone.tech
     HostName sea-anemone.tech
     IdentityFile ~/.ssh/DefaultKey-ap-northeast-1.pem
     User ubuntu

    (pemは、AWSから貰ったものを使うだけ)

  3. "ssh sea-anemone.tech"でログインできる(はず)