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から直接立ち上げてみると...
/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分くらいまでば起動します。
参考記事
感服です。
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 いれているのでアクセスが一定数を超えた場合、記事を具体化していこうと思います。
急ぎの場合はコメントをお願いいたします。
環境
- Ubuntu 18.04 on Virtualbox
- Docker 19.03.2 on Ubuntu
- docker-compose version 1.24.1 on ubuntu
- Mysql 8.0 in docker-compose
Azure Portalでアプリの登録
リダイレクトURLの設定
Laravelへアプリキーの登録
参考
2分でできる?GitHub PagesでサクッとWebサイトページ公開
おもっていた以上に簡単だったので記事にします。
手順
- いつも通りにレポジトリを作成(privateではなくpublicで作成してください)
- 公開したい静的頁をそのレポジトリにpush
- レポジトリ頁のSetting をクリック。
- 下にスクロールして Github Pages 項目のSourceを none → master branch に切り替える
- Done!
アクセス方法
上記手順4の項目でルートアドレスが表示されます。(画像を参照)
そのルートアドレス + 自分のpushした静的頁のファイル名をURLにすればOK。
参考
Vue.jsのAjax(axios)をサクっと試すサンプル
jQueryやってたけどフロントも少しはできるけどVueのajaxってどうすんだっけ。 ここで言うさくっとは、インストール不要!・1ファイルで完結します! ほいっ、これだけ。 このコードをhtmlファイルで保存して、ダブルクリックでブラウザで開くだけ。 1 . 画面が読み込まれると同時にgetが発動 はい、次。 先人たちに託す 私も最初はGoogleで検索して上記記事を参考にサクッとためしたかったんですが、なんかうまくいかなかった。 かつ、動くサンプルがないのでイメージしにくかった。 概要
Webpack ?やらなんかnpmやら、コンポーネントファイルやら準備がいるんでしょ?
そんなことを思っている人のためにさくっと試せて改良できるコードを載せます。とりあえず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>
動作としては、
2 . infoに結果を挿入サンプル頁
ボタン押したら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>
サンプル頁
POSTどうすんの?
余談
やっぱ1ファイルでコピペしたら動くし、動作がみれるものがいい感じのサンプルだと私は思っています。
そんなサンプルを用意したかったという思いが背景です。
Ubuntuで構築したDocker Laravel のファイル権限 (www-data User access denied) 問題の即席対応
- 環境
- 概要
- 最初の問題点
- 1. 対応:即席レベル1(Not Foundやaccess deniedの解消)
- 2. 対応:即席レベル1(ローカルからのコード修正)
- 次の問題点
- 3. 対応:即席レベル2(グループを作成する)
- 余談
環境
- Ubuntu 18.04
- Docker 19.03.2 on Ubuntu
- docker-compose version 1.24.1 on ubuntu
- Mysql 8.0 in docker-compose
概要
みんなどうしているんですかね。
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のグループのノウハウを蓄積して少し進化させました。
方法としては、
というやり方です。
これだといちいち権限の変更作業がないです。
残る問題としては、新規でコンテナ上のユーザーでファイルを作成したとき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なのでサインインで入力したユーザー名とかパスワードがもろに見れます。画像ではパスワードの箇所はカットしてキャプチャしてます。
* 修正後
Application Dataとして暗号化されURLさえ不明に。TLS v1.2みたいですね。
余談
証明書とか考慮してないのでGoogle Chromeには真っ赤になって怒られます。 でも、関係ないよね。要件は満たした。