MetaPii 技術室

あなたの知恵と思いを検索するフラッシュメモアプリMetaPiiのエンジニアブログです。

vagrantが起動しない (file system with error)

いやぁ、もうだめかと思いました。 3−4時間かかりました、一時はPC買い替えも覚悟しました。

ここにたどり着いた皆様も、おそらくすでにいろんなパターンを試されてだめだったのでしょう。 私のケースは以下で解決しました

問題

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'bento/ubuntu-18.04' version '201912.03.0' is up to date...
==> default: A newer version of the box 'bento/ubuntu-18.04' for provider 'virtualbox' is
==> default: available! You currently have version '201912.03.0'. The latest is version
==> default: '202003.31.0'. Run `vagrant box update` to update.
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: You are trying to forward to privileged ports (ports <= 1024). Most
==> default: operating systems restrict this to only privileged process (typically
==> default: processes running as an administrative user). This is a warning in case
==> default: the port forwarding doesn't work. If any problems occur, please try a
==> default: port higher than 1024.
==> default: Forwarding ports...
    default: 80 (guest) => 80 (host) (adapter 1)
    default: 443 (guest) => 443 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

ssh keyのところで止まるため、鍵問題かと思ったですが、vboxから直接立ち上げてみると... f:id:continue1:20200411105736p:plain

f:id:continue1:20200411105944p:plain

/dev/mapper/vagrant--vg-root contains a file system with errors, check forced.
/dev/mapper/vagrant--vg-root: UNEXPECTED INCONSISTENCY; RUN fsck manually 

そもそもファイルシステムに問題あることが原因のようでした。

対処

上図vboxの黒い画面上(ash上)で

fsck /dev/mapper/vagrant--vg-root

と打ち込み手動でファイルシステムを修復させます。 途中、いろいろ質問されますが、とりあえず私は全部Yesにしときました。 復活すればなんだっていい、言いなりです。

あとは、

vagrant up

でOK。まずはファイルシステム問題解決です

注意点

ファイルシステム修復後、vagrant upするとssh keyのところで

==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...

というふうにかなり待たされますがご安心ください。 5分くらいまでば起動します。

参考記事

感服です。

github.com

Heroku Laravel のセキュリティリスクについて(AppDB間のSSL化)with MySQL

「 おいおいおいおい。」
判明したときはそんな感想でした、たぶん自分に向けてですが。
AppとDB間の通信がデフォルトだと平文じゃん!

状況確認(mysql)

例えばLaravelのコントローラーなりで以下のようなDBのSSL通信状態を出力してみてください。 herokuのAWS

        #SSL 通信確認
        $rows = DB::select("show status like'Ssl_cipher'");
        foreach ($rows as $row) { echo $row->Variable_name.":".$row->Value."<br>\n"; }
        exit;

通常は下記のSQLを実行すると、SSL化されている場合なんらかの暗号化方式の名称文字列が入ります。何も値が入らない場合は、平文で通信されています。

show status like'Ssl_cipher'

対応方法

忙しいので果たしてブログにまとめる価値はあるのか見定めることにしました。 GoogleAnalytics いれているのでアクセスが一定数を超えた場合、記事を具体化していこうと思います。
急ぎの場合はコメントをお願いいたします。

LaravelでMicrosoft Graph (O365)認証ログイン by MSチュートリアル

Socialiteは使わず、チュートリアルでやろうと思ったら、けっこうかかりました。
果たしてブログにまとめる価値はあるのか見定めることにしました。 GoogleAnalytics いれているのでアクセスが一定数を超えた場合、記事を具体化していこうと思います。
急ぎの場合はコメントをお願いいたします。

環境

Azure Portalでアプリの登録

リダイレクトURLの設定

Laravelへアプリキーの登録

参考

developer.microsoft.com

2分でできる?GitHub PagesでサクッとWebサイトページ公開

おもっていた以上に簡単だったので記事にします。

手順

  1. いつも通りにレポジトリを作成(privateではなくpublicで作成してください)
  2. 公開したい静的頁をそのレポジトリにpush
  3. レポジトリ頁のSetting をクリック。
    f:id:continue1:20200111000215p:plain
    Setting
  4. 下にスクロールして Github Pages 項目のSourceを none → master branch に切り替える
    f:id:continue1:20200111000333p:plain
    github pages
  5. Done!

アクセス方法

上記手順4の項目でルートアドレスが表示されます。(画像を参照)
そのルートアドレス + 自分のpushした静的頁のファイル名をURLにすればOK。

参考

www.tam-tam.co.jp

Vue.jsのAjax(axios)をサクっと試すサンプル

概要

jQueryやってたけどフロントも少しはできるけどVueのajaxってどうすんだっけ。
Webpack ?やらなんかnpmやら、コンポーネントファイルやら準備がいるんでしょ?
そんなことを思っている人のためにさくっと試せて改良できるコードを載せます。

ここで言うさくっとは、インストール不要!・1ファイルで完結します!

とりあえずGet

ほいっ、これだけ。
・vue_sample.html

<!DOCTYPE html>
<html>
  <head>
    <title>vue ajax</title>
  </head>
  <body>
    <div id="app">
        {{ info }}
    </div>
    <script src="https://unpkg.com/axios/dist/axios.min.js"></script>
    <script src="https://unpkg.com/vue"></script>
    <script src="https://unpkg.com/jquery"></script>  
  
    <script type="text/javascript"> 
      var app = new Vue({
        el: '#app',
        data () {
          return { info: null }
        },
        mounted () {
          axios.get('https://api.coindesk.com/v1/bpi/currentprice.json')
            .then(response => (this.info = response))
        }
      })
    </script>

  </body>
</html>

このコードをhtmlファイルで保存して、ダブルクリックでブラウザで開くだけ。
動作としては、

1 . 画面が読み込まれると同時にgetが発動
2 . infoに結果を挿入

サンプル頁

vue ajax

ボタン押したらGet

はい、次。
・ vue_sample2.html

<!DOCTYPE html>
<html>
  <head>
    <title>vue ajax</title>
  </head>
  <body>
    <div id="app">
        <button v-on:click="get">Get</button><br> <!-- この行追加したよ -->
        {{ info }}
    </div>
    <script src="https://unpkg.com/axios/dist/axios.min.js"></script>
    <script src="https://unpkg.com/vue"></script>
    <script src="https://unpkg.com/jquery"></script>  
  
    <script type="text/javascript"> 
      var app = new Vue({
        el: '#app',
        data () {
          return { info: null }
        },
        methods:{ //この修正したよ。v-on:click="xxxx"のイベントに紐づく関数 
          get: function(){ //この修正したよ。v-on:click="get"時の処理
              axios.get('https://api.coindesk.com/v1/bpi/currentprice.json')
                  .then(response => (this.info = response))
          } 
        } 
      })
    </script>

  </body>
</html>

サンプル頁

vue ajax

POSTどうすんの?

先人たちに託す

qiita.com

余談

私も最初はGoogleで検索して上記記事を参考にサクッとためしたかったんですが、なんかうまくいかなかった。 かつ、動くサンプルがないのでイメージしにくかった。
やっぱ1ファイルでコピペしたら動くし、動作がみれるものがいい感じのサンプルだと私は思っています。
そんなサンプルを用意したかったという思いが背景です。

Ubuntuで構築したDocker Laravel のファイル権限 (www-data User access denied) 問題の即席対応

環境

概要

みんなどうしているんですかね。
Ubuntu上のDocker Laravelでnginxを通してアクセスするとwww-dataユーザー(UID=82)ってやつの権限(所有権)じゃないとNot Foundやaccess deniedになる問題。
とりあえず、時間がない中で数ヶ月走りながら運用してみて、とりまこれでのりきっとけってレベルの短期的な対応方法を記載します。

最初の問題点

  • 立ち上げた初期時点はNot Foundやaccess denied

    1. 対応:即席レベル1(Not Foundやaccess deniedの解消)

    まず、速攻の対応としては単に権限変更すればアクセス問題は解決します。
    例えば、以下のvolume設定でアプリを立ち上げているとします。

# docker-compose.yml
  app:
    build:
      context: .
      args:
        - TZ=${TZ}
    restart: always
    ports:
      - ${APP_PORT}:8000
    depends_on:
      - db
    volumes:
      - .src:/work

であれば作業ルート(/work)に対して所有権を変更するだけです。
publicは別途、権限変更。

$ docker-compose exec app chown -R www-data:www-data /work
$ docker-compose exec app chmod +x /work/public

でもこれだとコードの修正がローカルからはできません。
なので、コードの修正するときは以下の対応2をします。

2. 対応:即席レベル1(ローカルからのコード修正)

ローカルのユーザー名はdevとします。
その場合以下のコマンドで一発解決。

$ sudo chown -R dev:dev ./src

私は事情もあって実際これで2ヶ月くらい運用しました。
アクセスするとき、コード編集するときはいちいち上記のコードを実行してました。
いやぁ辛かったぁ。

次の問題点

  • アクセスするときはwww-dataへ、コード修正するときはローカルのユーザーへいちいち権限変更するのがとてつもなく面倒

    3. 対応:即席レベル2(グループを作成する)

    さて、それでLinuxのグループのノウハウを蓄積して少し進化させました。
    方法としては、
    1. docker上のwww-dataユーザー(UID=82)とそのグループ(dockerグループ)をローカルのUbuntu上に作成
    2. ローカルのユーザーを上記のdockerグループに参加させる
    3. 作業ファイルの権限をdockerグループレベルで編集可能にする

というやり方です。
これだといちいち権限の変更作業がないです。
残る問題としては、新規でコンテナ上のユーザーでファイルを作成したときrootとか権限自体がグループレベルで変更できない初期設定だったり。 この問題は追々対応します。

3-1. www-dataユーザー作成

コンテナ上のwww-dataユーザーのUIDをまず調べます。

$ docker-compose exec app cat /etc/group | grep www
www-data:x:82:www-data

次に、ローカル(Ubuntu)上でそのユーザとグループを作成します。 調べたUIDを使います。
名前は別にwww-dataでなくもいいです。私はdockerの省略系でdocにしました。

$ sudo useradd --shell /bin/bash -u 82 -o -m doc
$ sudo groupmod -g 82 doc

3-2. ローカルのグループへ参加させる

上記で作成したdocグループにローカルユーザーであるdevを参加させます。

sudo gpasswd -a dev doc

3-3. グループ編集可能に権限変更

これでまずはwww-dataへ変更させ、今後はwww-dataの所有権でやっていきます。

$ docker-compose exec app chown -R www-data:www-data /work

最後に、編集したいディレクトリに対して以下のコマンドでグループ編集可にします。

$ sudo chmod -R 770 ./src

上記はすべてのファイルに対して再帰的にやっちゃってますが、個別のフォルダにかける場合でもおkです。
なぜなら所有はwww-dataになってるのでアクセスは常にできるようになってます。

余談

あとは新規作成時の問題どうするかなぁ。

自宅・社内の gitlabで最速SSL(HTTPS)対応 by docker

概要

gitlabのguiって便利ですよね、ユーザー作成したりレポジトリ作成したり。
でもデフォルトだとhttpなのでパケット見るとログインパスワードとかバレバレ。
怖い!
で、さくっと(1分以内に)SSL(TLS)対応したいけど、どうするの?ってところが本記事のミソです。

ポイントとして、証明書は作りません。 だって自分で立てたものに対して証明なんていらない、ただほしいのは通信の暗号化。
証明書なしで最速で通信暗号化の対応を紹介します。

1. デフォルトのdocker-compose.yml 確認

以下のような感じだと思います。

version: '3'
services:
  gitLab:
    image: gitlab/gitlab-ce:latest
    restart: always
    hostname: '192.168.0.200'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://192.168.0.200:6500'
        gitlab_rails['gitlab_shell_ssh_port'] = 6522
    ports:
     - "6500:6500"
     - "6522:22"
     - "65443:443"
    volumes:
     - 'gitlab-config:/etc/gitlab'
     - 'gitlab-logs:/var/log/gitlab'
     - 'gitlab-data:/var/opt/gitlab'
volumes:
  gitlab-data:
  gitlab-logs:
  gitlab-config:

2. 修正

では、修正していきます。
* 修正前箇所

      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://192.168.0.200:6500'
  • 修正後箇所
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://192.168.0.200:6500'

ふぅ。疲れた。

これだけです。httpのとこに[s]つけただけ。

3. 再起動そして対応終了

あとは起動

docker-compose up -d

4.通信の暗号化確認

パケットをキャプチャして確認します。
* 修正前
当然httpなのでサインインで入力したユーザー名とかパスワードがもろに見れます。画像ではパスワードの箇所はカットしてキャプチャしてます。

f:id:continue1:20191130142632p:plain
パケットキャプチャ修正前
* 修正後 Application Dataとして暗号化されURLさえ不明に。TLS v1.2みたいですね。
f:id:continue1:20191130143212p:plain
キャプチャ修正後

余談

証明書とか考慮してないのでGoogle Chromeには真っ赤になって怒られます。 でも、関係ないよね。要件は満たした。