Windows上でWinSshFS使う代わりに 、VM上のUbuntuでSSHFSつかって、SMBでWindowsとファイル共有する

https://jtanx.github.io/2017/10/16/an-alternative-approach-to-sshfs-on-windows/
内容としては↑と同じです。しかしUbuntuではこの通りやってもできません。

あと日本語の情報だと次のURLにありますが、手順は解説されていません。
http://d.hatena.ne.jp/murase_syuka/20150530/1432992778

これの②をやります。
➀だと以下のような問題点がありました。

なぜWinSshFSを使わないか

SSHFSを使うのを一か所でまとめたい(がWindows上で動くLinuxとの共有が難しい)

前提として、仮想マシンと、ホストとなるWindowsの両方からSSHFSを使うことはなるべくしたくないという事情があります。
なのでSSHFS接続を一か所(=Windowsか、VM上のUbuntuか)で行い、それを共有する形をとりたいです。

WinSshFSを使ってこれをやるとなると上の図の➀になります。

VirtualBox上のLinuxとの共有では遅くて使えない

WinSshFSでWindows上にマウントをしたものをVirtualBoxのファイル共有機能を使い仮想マシンと共有したところ、lsコマンドに1秒、tabキーでファイル名補間に1~2秒、vimで開くと3秒かかるといった有様で快適に使えません。

WSLで動くUbuntではそもそもマウントできなかった(たぶん?)

WSLで動くUbuntuと共有したかったのですが、現在のところWSLで動くUbuntuはこのタイプのドライブのマウントができないようです。

WindowsのDドライブに、WinSshFSでリモートのファイルをマウントしたところ、

sudo mount -t drvfs D: /mnt/d
というコマンドでは
mount: /mnt/d: wrong fs type, bad option, bad superblock on D:, missing codepage or helper program, or other error. 
と怒られるので、
今度はファイルシステムタイプのところをautoにしたところ
unknown filesystem type “NFS”
みたいなエラーが出てしまいます。
マウントできたところでWSLは仮想マシンよりI/Oが遅いとかなんとか聞くので良い結果にはならなかったかもしれません。

それと現在のところ、WSLのUbuntuはFUSEには対応していないようです。よってsshfsコマンドもたぶん使えないです。
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl

再接続が怪しい

Docan Library 1.0.3、WinSshFS 1.6.1.13 で試したところ、スリープしたりWi-FI切断されたりしてVPNが切断されたときに再接続がうまくされません。
VPNなしではどうか知りませんが…ネット上では再接続が上手くいかないという情報も見るので、あまり期待はしてないです。

ちなみにmacOSでは

macOS側でSSHFSを使ってマウントしたものを、仮想マシンとVirtualBoxの機能で共有しても、少しラグはあるものの普通に使えました。
再接続も普通に行われます。
こんなクソ面倒な作業は要りません。

環境

Ubuntu 16.04 LTS 日本語ver
Windows10 1803  ビルド17134.228

手順

UbuntuでSSHFSの準備(fuseグループのあたりが元記事には無いです)

sshfsをインストールします。
# apt install sshfs

マウントポイントとしたいディレクトリのオーナーがfuseグループに追加されていることを確認してください。
(そうでない場合、read: Connection reset by peer とかいうエラーが出ます)

今回の説明の場合はuser1というユーザのホームディレクトリ以下に作成したので、user1をfuseグループに追加します。(fuseグループがない場合、groupaddコマンドでfuseグループを作成してください)

# usermod -a -G fuse user1

UbuntuでSambaの準備

VirtualBoxのネットワーク設定

ホストオンリーアダプターを追加しておきます

インストール(同じ)

# apt install samba

Sambaの設定変更(設定ファイルの場所が元記事と違います)

設定ファイルは/etc/samba/smb.confにあります。これの末尾に次の内容を追加します。
[remotesshfs]
   comment = sshfs remote
   # マウントしたディレクトリの位置にでもする
   path = /home/user1/mount/mountpoint1
   browseable = yes
   writeable = yes
   guest ok = yes
   acl allow execute always = True
   read only = no
   public = yes
   # user1の位置をVM上のLinuxで使用中のユーザ名に変える
   force user = user1

設定を再読み込みするためにデーモンを再起動します

# systemctl restart smbd nmbd

次に、ホストオンリーアダプターによってUbuntuに割り振られたIPアドレスを確認します。

$ ifconfig
enp0s3    Link encap:イーサネット  ハードウェアアドレス 08:00:27:c4:98:ce  
          inetアドレス:10.0.2.15  ブロードキャスト:10.0.2.255  マスク:255.255.255.0
          inet6アドレス: fe80::528a:18a6:99ef:d36a/64 範囲:リンク
          UP BROADCAST RUNNING MULTICAST  MTU:1500  メトリック:1
          RXパケット:20 エラー:0 損失:0 オーバラン:0 フレーム:0
          TXパケット:118 エラー:0 損失:0 オーバラン:0 キャリア:0
          衝突(Collisions):0 TXキュー長:1000 
          RXバイト:3940 (3.9 KB)  TXバイト:14540 (14.5 KB)

enp0s8    Link encap:イーサネット  ハードウェアアドレス 08:00:27:b8:3d:e0  
          inetアドレス:192.168.56.101  ブロードキャスト:192.168.56.255  マスク:255.255.255.0
          inet6アドレス: fe80::49b4:7979:6a11:39ec/64 範囲:リンク
          UP BROADCAST RUNNING MULTICAST  MTU:1500  メトリック:1
          RXパケット:16 エラー:0 損失:0 オーバラン:0 フレーム:0
          TXパケット:85 エラー:0 損失:0 オーバラン:0 キャリア:0
          衝突(Collisions):0 TXキュー長:1000 
          RXバイト:2670 (2.6 KB)  TXバイト:10390 (10.3 KB)

lo        Link encap:ローカルループバック  
          inetアドレス:127.0.0.1  マスク:255.0.0.0
          inet6アドレス: ::1/128 範囲:ホスト
          UP LOOPBACK RUNNING  MTU:65536  メトリック:1
          RXパケット:51 エラー:0 損失:0 オーバラン:0 フレーム:0
          TXパケット:51 エラー:0 損失:0 オーバラン:0 キャリア:0
          衝突(Collisions):0 TXキュー長:1 
          RXバイト:3939 (3.9 KB)  TXバイト:3939 (3.9 KB)

192.168.56.101です。

こうすることで、Windowsのエクスプローラのアドレスバーに192.168.56.101remotesshfs と入れれば、VM上のUbuntuの/home/user1/mount/mountpoint1にアクセスできるようになります。

いよいよ接続

UbuntuとリモートとでSSHFSでファイル共有

ファイルパスやremote-user-nameとremote-host-nameは自分のものに変えてください。idmap=userというのはそういうオプションなので自分のユーザ名に変える必要はないです。

$ sshfs -o auto_cache -o reconnect  -o allow_other -o idmap=user  remote-user-name@remote-host-name:/home/user1/ /home/user1/mount/mountpoint1/

WindowsとUbuntuとでSMBでファイル共有

Windowsのエクスプローラに192.168.56.102remotesshfsと入れます。ユーザ名とパスワードを聞かれるのでVM上のUbuntuのユーザ名とパスワードを入れると、ファイル共有ができます!

CentOS7でdigコマンドなどの実行時の「dig: error while loading shared libraries: /lib64/liblwres.so.160: file too short」エラーの解決

Cent OS 7でdigコマンドとかを実行すると次のエラーがなぜか出るようになってしまいました。

dig: error while loading shared libraries: /lib64/liblwres.so.160: file too short

(つまんない記事ですみませんが)

# yum remove bind-utils
# yum install bind-utils

で直ります。

Excel2016でのヒストグラムのビンの設定の方法のWindows版とMac版での違い

Excelは2016からヒストグラムが一発で書けるようになりました。

その機能で描いたヒストグラムのビン幅などが変更できるのですが、その変更の仕方がWindows版とMac版で違うので迷ったので書いておきます。

Windows版はExcel2016 Ver. 16.0.9126.2259、Mac版はExcel2016 Ver.16.16で現時点での最新版です。

ちょうど入れ替わってる感じなんですよね。「軸の書式設定」と「データ要素の書式設定」が。
WindowsやMacの文化に合わせたローカライズというわけでもないでしょうし、揃えてほしいですね…。

Windows版 Excel2016

グラフの横軸を右クリックし、「軸の書式設定」をクリック。右のペインでビンの設定ができます。

なおMac版のように、グラフ部分(青いとこ)を右クリックして「データ要素の書式設定」をクリックしても、ビンの設定はできません。

Mac版 Excel2016

グラフの部分(青の部分)を右クリックして、「データ要素の書式設定」をクリック。右のペインでビンの設定ができるようになります。
なおWindows版のように、横軸を右クリックして「軸の書式設定」をクリックしても、ビンの設定は出てきません。

Macbook Pro 2018と2017のキーボードを触ってきた

出先で偶然に寄ったお店で、2018と2017のキーボードを比べました。
左が2017、右が2018です。

大音量の音楽が流れる店内での聴き比べですが…。

2018は2017よりはっきりと静かになっています!
(海外レビューサイトではあんま変わらんという書き込みも見られ心配でしたが杞憂でした)

2018は2017に比べ、タカタカッターンッと強めに打った時の高音が無くなっているという違いが大きいです。
またバタフライキーボードにふさわしい、指をあまり動かさないで優しめに押すタッチでも音の違いはわかります。

とくに、スペーキスキーなど大きめのキーは、2017だと連打するとカチャカチャ音が鳴ることがあるのですが、2018だとほぼ全くなりません。

ただ、BGMがうるさい電気屋での比較なので、そこまで正確ではないはずです…。
同じ部屋で作業をしている人たちは2016や2017年モデルのMacbook Proを使っている人が多いのですが、キーボードがうるさいと感じたことはありません。(キーボードカバーつけてるのかも?)
なので、もしかしたら、静かな場所で比較するとよくわからない違いなのかもしれません。

キータッチ

2017は2018よりコク、コクとスイッチ感があります。
つまりキーを押す感触は2018より2017の方が良いと私は感じます。

2018がこうなったのはゴミ対策+静音化で薄いゴム膜を挟んだ代償だと思います…。

まぁでも気にならないレベルと言えばそうだと思います。

総括

2018のキータッチは悪化している気がするけどまぁ許容範囲なので、ゴミを噛んで故障しにくい2018年を買えばよいと思います。
iFixitのレポートによれば、キートップが変更されており、外しやすくなっている=自分でゴミ噛みを直しやすくなっているらしいですしね。
ゴミ噛んだ際の修理に掛かる時間と手間を許せるなら2017でも全然アリだと思います。
(2018はキーボード修理キャンペーンの対象になってませんが、2017は対象になっており4年間キーボードをタダで直してくれます!)

Alexa Top Sites APIの使い方

Alexaから、国別に人気のサイトのURLを取得できるAPIです。

総合案内:https://support.alexa.com/hc/en-us/articles/200461990-Can-I-get-a-list-of-top-sites-from-an-API-

なおこのAPIを使わなくても525位までならウェブサイトのスクレイピングで得られるらしいです。
https://qiita.com/saxsir/items/a85ee3c5fb9d3bd76dde

登録方法

Getting Started with Alexa Top Sitesを見てやります。

AWSのコンソールにアクセスし、AWSのアカウントをつくります。クレカと電話番号が必要!1年間はAWSの無料期間ですが、Alexa Top Sitesは対象ではないようなので注意です!
登録したらコンソールでIAMの設定を画面に行きます。下の画像のように検索すれば出てきます。
ユーザの管理をクリック します。
アクセスの種類は2つとも選択して次に進んでください。
「ポリシーを作成」ボタンを押します。

これをコピペします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "AlexaTopSites:GET"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

図のようにエラーが出ますが、これはバグらしいので気にしないでください。

このあと、さっきの画面(「ポリシーを作成」ボタンを押した画面)に戻り、「既存のポリシーを選択」から今回作成したポリシーを選ぶ必要があったかもしれません。忘れました。

そのあと次へとか押すと作成が終わったと思います。

できたらアカウントの詳細画面で、認証情報タブを見ます。

APIの使用に必要なアクセスキーIDとシークレットを得るには、この「アクセスキーの作成」ボタンを押します。
シークレットは作成時にしか見ることができません。
見忘れたら作成し直してください。

Pricing

0.0025perURLreturned(e.g..25 for 100 URLs)

とあります。この料金は安いのか高いのかわかりません。
私は9万個のURLをfetchしたため税込241ドル(=27,000円くらい)払う羽目になりました。

Rate Limit

レート制限はないらしいです。

Sample code

公式(Getting Started with Alexa Top Sites)のサンプルコードにはPythonがないっぽいです。
オープンソースだと
  1. https://github.com/davedash/Alexa-Top-Sites
  2. https://github.com/everping/aws-alexa-top-sites
というのがありました。2番目が使いやす気がします。
ダウンロードしてそのディレクトリに移動し、
$ ./ats.py -country US -count 10 -secret <アクセスシークレット> -key <アクセスキーID> -start 200

とやると、200番目から10個のURLをfetchできます。

Alexa Top Sites APIは一度のクエリで最大1000件まで取ってこれます。
よって、1万件とかをfetchする際は、1000件ずつクエリを投げます。

そのときにこのオープンソースのats.pyというスクリプトは一切の待ち時間を挟まないでクエリを投げ続けるので、ときどきコネクションが確立できません。
(詳しくは忘れたけどとりあえず問題が起こります)
ats.pyの197行目、クエリを投げ続けるfor文の中にtime.sleep() でも挟んで少し待たせると良いです。

Alexa Top Sites APIで27,000円使ってしまった

よく課金のされかたがわからずにAlexa Top Sites APIで9万件のURLを取得し、241ドル(=27,000円)使ってしまいました。

数十万円のミスをしなくてよかった。

ミス一覧:

  1. AWSは12ヶ月間無料キャンペーンの中にAlexa Top Sites APIは対象となっていないことをわかってなかった
  2. 課金状況を見るページの使い方がわかってなかった

1. Alexa Top Sites APIは無料キャンペーンの対象ではなかった

AWSは12ヶ月間無料!って書いてあって、その中にAlexa Top Sites のAPIも入ってるものだと思ってたくさん使ってしまいました。
リストアップされているナンチャラAPIとかいうのに含まれてるんだと解釈してしまったのが原因です。
Alexa Top Sites APIは無料の対象ではなかったようです。

(よくわからないけど、AWS上に構築したサービス(=Alexa Top Sites API)を利用させそれに課金するスタイルなのでAWSアカウントの作成が必要だったっぽい?)

2. 課金状況の見方がわかってなかった

間違ったページを見ていました。
コストエクスプローラーから見ることができます。
しかし、この「Launch Cost Explorer」を押しても、デフォルトでは次のように、何も課金されていないようなグラフが出たのでAlexa Top Sites APIはやっぱり無料対象なのかなと思ってしまっていました。

「Monthly EC2 running hours costs and usage」と書いてあるように、これはEC2の課金状況であり、Alexa Top Sites APIはEC2のサービスではないためこの画面には含まれないのです。
全体の課金状況を見るにはどうすれば良いかというと、 Saved Reportから左上の青い「New Report」をクリックします。
(この写真では既に作られていますが気にしないでください)
「Cost & Usage report」を選び、右の青い「Create Report」を押します。
するとこのようにグラフが見えます。
はぁ〜〜
1URLあたり0.0025ドルです。約9万件のURLを取得したので225ドル+税で241ドルになったというわけ。

気をつけなくてはなりません…。