So-net無料ブログ作成
検索選択

LXCコンテナの中からファイルを取り出したり、Wetty文字化けを検証したり。 [Linux]

Wettyで日本語がうまく扱えないことが判明。コンテナ内で実行していたのは関係ないと思うが、Windowsから取ってくるのに一苦労した。


外からファイルを取りに行こうとしたら、コンテナの中ってWinSCPでアクセスできないんだよな。外に晒していればいいろうけど、内部でしか使っていない。だから、外部サーバにアクセスしてFTPあたりで上げてから、Windowsからアクセスするとか面倒なことをすることになる。

FTPなんて最近使ってない、CUIならなおさらなので強引にrootでアクセス。Ubuntuだとsu rootできないのでsudo suで。

コンテナの中は
/var/lib/lxd/containers/
にあった。ゴリゴリとディレクトリを進んでいくとファイルがあったので、面倒なので/にコピーして、そこからWindowsからWinSCPでコピー。


あ~wettyからviにコピーしたのはどう文字化けしてるんだかわからないや。UTF-8でもShift-JISでもない感じ。それとgoからGoogleのトップページを保存してみたんだけどShift-JISなんだね。世界企業はみなUTF-8とかで統一しているものかと思っていた。とりあえず、Golangで保存したものについては、文字化けしていないことが分かった。wettyからじゃ上手く確認できないんだよなぁ。そもそも、日本語のエンコーディングをどこまで実現できるんだかよく分からん。

うむ、外から与えられたパスに関しては日本語表示はできる。ただ日本語入力はできないのでファイルが一つの時とかしか選べないだろう。入力ができればいいのになぁ。そもそも日本語は使わないんだけど、SSHで使えるから使えた方がいいなぁと思ってしまう。Wettyを改修するか。でも、日本語でShift-JISで送っちゃってるんじゃないかな、と思っているので、世界的に汎用的な対応じゃなくなっちゃうよなぁ。世界的どころかWindowsとMac限定になっちゃう。あ、それでいいのかw。

どうせLinuxはUTF-8で入力することになるんだろうし。とはいえ、Linuxはマイナーだから気にしてないんだけどね。というか、プログラムの内部的にUNICODEの利用は進んでいるのに、OS全体の利用状況としては相変わらずShift-JISのコードだっていうのもどうかと思うよなぁ。過去のShift-JISのテキスト資産を気にしている人って多いのかな。MS自体がUTF-8にするのが面倒なのかな。メモ帳UTF-8対応とか?

コメント(0) 
共通テーマ:パソコン・インターネット

SSHダメなプロキシを越えて、Linuxの端末操作してみる。4 番外編 [Linux]

会社の外にアクセスするプロキシでSSHが通らない場合、HTTPSでどうにかしてしまおうという事をしてきました。実際にやったこととしては、WettyというWebで端末を実行するソフトを、Dynamic DNSでDNSを付けて、let's encryptでHTTPSにして立ち上げてみたってだけです。一つ一つは大したことやっていません。でも組み合わせて実際にやってみると少ししんどい。でも誰でもできないレベルじゃない。

http://miff.blog.so-net.ne.jp/2017-03-15-2
http://miff.blog.so-net.ne.jp/2017-03-21
http://miff.blog.so-net.ne.jp/2017-03-25-2

以上がいきさつです。Wettyさえ立ち上げられれば、あとはググって解決できるレベルですね。wetty自体を動かすのがちょっとしんどかった。案外、前に作られていたので手を入れないと動かないと思っていたけれど、とりあえずは今は問題がないことを確認できている。

Wettyですごいのが、Ctrl+C, Ctrl+Vでコピペができるってことですね。コピペが面倒くさい端末もあるのですが、マウスでコピペができないもののキーボードオペレーションでできるので問題なし。むしろマウスを使わない方がいいのかもしれない。端末ソフトとして特に問題を感じていません。tmuxは使えるし。日本語表示はどうなんだろうな。日本語ディレクトリとか日本語のドキュメントを見てないので何とも言えません。UTF-8ぐらいは対応できていると思うんだけど、試してみてないのでわかりません。

開発環境とかいちいち日本語環境にするの面倒くさくて最近ローカライズされたものを使っていない。英語環境でもUTF-8であればフォントがある環境であれば文字化けしにくいし。MacのXcodeとかもメニューが日本語になったことあったかなぁ。開発者はメニューの英語くらいの英語は読めるようになっておこう。というか、外国のツールとかやたら日本語化したものを使いたがる人がいるけど、そこまでして日本語でやりたいかという感じはするんだよね。やれることは同じなんだし、手間がかかるだけで応用が利かないし。


いろいろ調べている時に、自作をしている人を見てちょっと惹かれた。
http://blog.tmyt.jp/entry/2017/01/07/175533
使っているパッケージ(npmでは何というのか分からんが)も少なくて、自分でも作ってみたい気がした。アスカを苦しめるギフハブとかで晒してくれればいいのにw。まぁソースはあるので足らんかったら自分で足せばいいわけで。

というか、wetty自体が結構色々なものを使っているんですよね。そこの機能をxterm.jsが吸収しているのかな。よくわからんけど。まぁWettyが何らかの理由で使えなくなったらいじってみようかな。しばらくNode.js使っていないので、JavaScriptを何も見ずに間違いなく書ける気がしない。フロントエンドもあんまりやっていないんだよなぁ。HTML5をFlash並みにグリグリ動かせるようにしようと思っていたんだけどな。

HTML5はパソコンでも実行環境を使えるけど、せっかくLinuxを動かせるんだから何かPCでできないことをしたい。今ならWindows10でBash on Ubuntu on Windowsがあるからいいけど、それ以前だとVirtualBox入れないとダメだし。会社のPCだとVirtualBoxを動かすリソースが足りないんだよね。そのためのWettyでの端末操作だったりします。まぁクラウドな世の中、どこからでもアクセスできるようになったのはいいことだ。

タグ:Node.js
コメント(0) 
共通テーマ:パソコン・インターネット

SSHダメなプロキシを越えて、Linuxの端末操作してみる。3 Wettyを少しいじる [Linux]

職場からSSHをつなげなくて自宅マシンにつないで遊びたいLinuxの検証などをしたい人のために、Wettyを使おうシリーズ第三弾。まぁWettyを探して立ち上げたってだけの話なんだけど、SSHをフィルタリングされて通れないというパターンはたくさんあると思うので、それをHTTPSで通れるよということが分かるだけでも、困難が緩和されるってのものです。さすがにHTTPSを通さないプロキシはないと思うし、特定のURLをフィルタリングしているものだって、Dynamic DNSを通さないってのはなかなかないと思うし。

とにかく、前回まではオレオレ証明書で運用して外から見えたところまでやったのでした。せっかくletsencryptで証明書を取ってきたのに使ってないのでした。今回は使います。使ってはみたのですが、そして動いてはいたのですが、いまいち操作に確証が持てなかったので書きませんでした。でも、同じことをやっていた人がいたので、一応晒すことにしました。と言ってもリンク先と大して変わらないんですけど。

http://www.utali.io/entry/2016/11/21/025555

privkey.pemとcert.pemを使うだけなんだけど、それまでの経緯は以下。

http://miff.blog.so-net.ne.jp/2017-03-15-2
http://miff.blog.so-net.ne.jp/2017-03-21

sudo node app.js --sslkey /etc/letsencrypt/live/foo.bar.jp/privkey.pem --sslcert /etc/letsencrypt/live/foo.bar.jp/cert.pem -p 443


sudoにするのは443ポートで動かさないといけないのと、。.pemファイルがルート権限じゃないとアクセスできないからなので、sudoで動作させる。基本、80番ポートでもWellKnownポートだから、Webサーバは管理者権限で動かさないといけないのは、知らない時は覚えておいた方がいいです。まぁ作り付けのWebサーバを使っているとか、1024番以上のどうでもいいポートを使っているのであれば問題ないですが。


これがprivkey.pemを晒すことにならなければいいなと思うが、動作的に問題ないようなのでたぶん大丈夫。他のサイトでも同じような事をやっておったわけだし、それほど疑いがあるものでもないのかもね。というか、プライベートキーが流出しても、元々タダで得られたものだし、ダメな時はもう一回得ればいいだけかもしれんし。最悪、Dynamic DNSのURLを取り直せばいいような気もするし、そこまで気にしない。

変えたんだけど、自宅のサーバにLANからhttps://192.168.0.200みたいにアクセスしても、証明書が正しくないとされる。これはURLじゃなくてプライベートIPでアクセスしているからで、同じLAN内からではDynamic DNSのURLが使えないので仕方がない。





これでオレオレ証明書じゃなくて問題なくHTTPSにアクセスできるようになりました。あとはルートアクセスしてきた時に入られちゃう問題を解決しないといけない。というか、webrootがアクセスできないとか画像アップサイトじゃないんだからねぇ。でも、IPで適当にアクセスしてくるボットやハッキングに対しては、ルートを適切に処理しておくことが大事かと思う。これはExpressを使ってソースに手を入れないといけない。

https://github.com/krishnasrinivas/wetty/blob/master/app.js

ここにしか手を入れない。

app.use('/', express.static(path.join(__dirname, 'public')));


の前に

app.get('/',function(req, res, next) { res.send('hello');});


を置いておくだけで、Webルートからアクセスできなくなる。それだけでいくらかセキュリティは上がる。

更に「/wetty/ssh/ユーザー名」でアクセスできるんだけど、気になるならwettyのところを別のパスに切り替えてみれば万全。まずアクセスされることはないかもしれない。まぁ途中で盗聴できたらURLを取ること自体はHTTPSでもできるのかな? アクセスするURL自体は暗号化できそうな感じはしないけど、それでも安全性は普通の第三者から考えれば非常に高くなる。少なくともsshでアクセスできるポートを変える以上の効果はある。

ただ、これをやると/wetty/ssh/ユーザー名でしか、たぶん入ることができなくなるので、ルートからとか/publicから入るのはつぶされる。使い慣れてきてからやった方がいいのかもね。そんなこんなで、全三回でお送りしたWETTY動かして安全端末アクセスができたのでした。

タグ:Node.js
コメント(0) 
共通テーマ:パソコン・インターネット

SSHダメなプロキシを越えて、Linuxの端末操作してみる。2 WettyをHTTPSで使ってみる。 [Linux]

前に職場のプロキシでSSHが越えられずに困ったという話をして、それならばHTTPで端末操作ができればいいのではないかと思っていた。コマンドを渡して実行するってのは簡単だしやったことがある。まぁ色々セキュリティに問題があるのだが、そこはHTTPSを使うしかないのかなというところです。

そんなわけで、SSL/TLS用の証明書を無料で取ってこようという話になります。今はタダで配布しているという事なので、それをもらってきて使ってみる段階です。最終的にはnode.jsのアプリであるWETTYに適用する予定。

もはや定番になっているっぽいLet's Encrypt

https://letsencrypt.org/

でUbuntu用の証明書をアップデートするシェルスクリプトがあるらしく、aptで入れられるらしい。

https://certbot.eff.org/#ubuntuxenial-other

これかな?
sudo apt install letsencrypt

やたらPythonの依存パッケージが入れられて気持ち悪い。Pythonはバージョン問題などあんまり好きじゃない。コマンドの例を見てみると

$ letsencrypt certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is

そもそもDNSでURLがないとダメだよね。どこかのDynamic DNSでURLをもらってこないとな。ルーターとかNASによっては半自動的に付与されるのもあった気がする。というか、Dynamic DNSとか久しぶりなんだけど。前に探したのはずいぶん前だから改めて探し直さないとダメだろうね。

それと-dオプションのthing.is, m.thing.isってなんだろう。前の-dはexample.comで容易にURLドメインであることが分かるんだけど、後のは何だろう。同じ-w, -dの組み合わせなのはわかるんだけど…

https://blog.apar.jp/linux/3619/

バーチャルホストがうんぬんと書かれているのであんまり気にしないでいいかもしれない。


とりあえず、Dynamic DNSを登録してくる。なんかあれってプロトコルがあるようでない感じだったような気がするんだよね。RFCで決められているんだっけ? まぁURLと動的なIPを結びつけているだけだしねぇ。とりあえずお気楽な方法で。

DynamicDNSに登録してきた。
http://www.ieserver.net/
ってところで、IPを設定するのがシェルスクリプトを叩くだけで簡単そうだったので決めました。
ググったらもっと上に

http://www.mydns.jp/

があったんだけど、Ban4IPとか面倒くさそうだったのでやめました。でも、後から読んだら二行くらいのスクリプトで対応可能だったので、そっちを使えばよかったかもなぁと思ったり。まぁ気になったらそのうち移るとして。


登録したURLがhoge.foo.jpとして書きますが(実際にあるかもだけど…)、以下のコマンドでエラーが出ました。

letsencrypt certonly --webroot -w /home/hoge -d hoge.foo.jp

エラーでいろいろ出たけど

Detail: DNS problem: NXDOMAIN looking up A for

うんちゃらかんちゃら、と出ていて、よく意味が分からない。Webサーバを立ち上げないといけないのかなと思ったら、立ち上げたら立ち上げたで別のエラーが出て立ち上げるのやめろと出る。その前にルーターの設定で自分のサーバの80番ポートと443番ポートをつなげておいた。一応やっていることは外にはつながっているっぽい。


DNSサーバが悪いのかな、まだ登録されていないのかな、と思って一晩放置したのだが、一応スマホのLTE回線から見られるようにはなっていた。

結局、コマンドが違っていた。

letsencrypt certonly --standalone -d hoge.foo.jp

これで

/etc/letsencrypt/live/hoge.foo.jp/fullchain.pem

あたりに出てくる。でも、期限が短いって話なんだよなぁ。どうするんだろ。


同じディレクトリにはいくつかあるが、どれ使うんかな。

cert.pem chain.pem fullchain.pem privkey.pem

cert.pemあたりを使う気がするんだけど、メッセージにはfullchain.pemが出てくるので気になる。あとで調べよう。でも後でって言ったのって大体はやらないことが多いんだよなw。まぁオレオレ証明書でも動くことは動くからいいのだけれど…。


openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30000 -nodes

で出力して

node app.js --sslkey key.pem --sslcert cert.pem -p 3000

で動かせと書いてあるのでやってみると、やはりワーニングが出る。まぁ個人利用ならこれでもいいんじゃないでしょうか。やってないけど、cert.pemは同じとして、key.pemにあたるのがprivkey.pemでいいのかなぁ。privkeyってprivateなキーなんだろうから外に晒すようではだめなんだろうけど、これもletsencryptの仕様を調べてから使おうと思う。

現状では80番ポートで晒すとすぐにアクセスが来ていたから、最低443ポートでHTTPSで晒さないといけないな。そしてWebルートなURLでアクセスできちゃっているので、それをアクセス禁止にしてユニークなURLでアクセスするようにしないといけないだろうね。そうすれば、途中で盗聴してでもしなければ、アクセス方法はわからないし、URLが分かったところで基本的にユーザーとキーワードの認証はそれほど楽に突破できるものでもないでしょう。

普通の端末接続は、あんまり間違うとしばらく受け付けなくなるんだが、wettyではそこまでやってくれるかどうかはわからない。とりあえずDynamic DNSでURLを取らないと使えないのはまともなHTTPSを使おうとしたときには必要なので事前に取っておきましょう。以下次回。ソースに手を入れないといけないのでここまでにしておきます。

タグ:Node.js
コメント(0) 
共通テーマ:パソコン・インターネット

SSHダメなプロキシを越えて、Linuxの端末操作してみる。1 [Linux]

So-net blog自体のアクセスランキングは悪くないけど、パソコン・インターネットのカテゴリのランクが下がり気味。あんまり相関はない感じなんだよね。まぁ普通は今の時期は年度末なので忙しいのだけれど、カテゴリ的に仕事中にやってるやつとかが多いみたいで、お気楽でいいねぇと思わざるを得ないのだけれど。


と愚痴っぽいのはそれくらいにして、仕事でのLinux利用。職場はファイヤーウォールだかプロキシサーバだとかで、SSHが通らない。ポートを色々設定したのだが、そもそも受け付けてないっぽいのだ。どこかにHTTPでつなげる端末とかないかなと思ったら、Webサーバ経由でターミナル操作できるものがあるみたい。

これとか
https://www.npmjs.com/package/web-terminal
これとか
https://github.com/krishnasrinivas/wetty

後者の方がターミナルとしては優れているっぽいので、wettyにしてみる。なんか名前が湿ってる感じがするけど、もともとwettyという単語はないらしい。wetで形容詞だし。

HTTPSも使えそうなので、あとあとそのためにソースに手を入れなくていいっぽいね。オレオレ証明書でしかSSLを使ったことがないので、今回はLet's encryptを使ってみたい気はしている。というか、暗号化しないでユーザー名とパスワードを送るのなんて無理。

http://knowledge.sakura.ad.jp/knowledge/5573/

node.jsでWebサーバをいじったことがあるので、Webルートで動作するところを変えないとクラッカーの餌食になりそうな予感。というか、アクセスログを見たことがあるのだけれど、適当にIPアドレスで来ているのってたくさんあるんだよね。んで、ありそうなURLのパスでアクセスしようとして来ていたりしている。まぁそういうのはほとんどボットなんだろうけど、踏み台にされるのはまっぴらなのでなんとか考えたいところである。


まずLXCでサーバ作ろうか。Ubuntuでいいか、面倒だし。と思ったけど、外につなぐ時にポート開けたりしないといけないだろうからやめて物理サーバに。まぁ物理サーバにつないでからLXCコンテナ作ってもいいや。

というわけで、物理サーバのUbuntuにnode.js、npm、wettyという手順で入れる。

めんどうなのでnode.jsはUbuntuリポジトリで
sudo apt install nodejs

あ、入ってた。バージョンはv4.2.6で対応しているかどうかは怪しい。
sudo apt install npm

んでwettyインストールはサイト通りに。
git clone https://github.com/krishnasrinivas/wetty
cd wetty
npm install


deprecatedが4つ出て、そのあとにエラーが出た。ん〜なんだろう。二年前のソースだからそんなに問題になりそうな感じはないだろうなぁ。

node-gypあたりでエラーが出ていて
node-gyp rebuild
としても解決せず。WindowsだとPythonの環境の問題で必ずと言っていいほど出まくっているみたいですが、Ubuntuだしなぁ。

sudo npm install -g node-gyp

入れ直してもpty.jsがnode-gyp rebuildしろというのは変わらない。




挫折してちょっとweb-terminalの方にちょっかいを出してみる。
sudo npm install web-terminal -g
ですんなり入る。本当はsudoしたくないんだけど、ダメらしいので。
web-terminal --port 8088
で起動。どこに入っているのかさえも分からないけど、あっさり。

それでクライアントPCからhttp://192.168.0.123:8088とかでアクセスすると少し間をおいてプロンプトが出る。
~/.npm/web-terminal/0.7.0/package
からなぜか入るのだが、ここにはバイナリとかの実態がない。node.jsだからテキストか。

$ which web-terminal
/usr/local/bin/web-terminal

みたいな感じでコマンドは打てる。でもviとかはダメだって書いてあったな。単純なコマンドラインのみっぽいけど、viを立ち上げてみる。わーw
web-terminal-vi.png
なんかぐちゃぐちゃ出てきてテキストの編集どころではありませんでした。やっぱり、wetty立ち上げ頑張らな。




色々やってみたので決定打となるコマンドが分からないんだけど、大体こんな感じで直った。

npm update -g npm
npm update -g
node-gyp clean
node-gyp install
node app.js -p 3000

npmとその中のパッケージを新しくする。
node-gypコマンドでコンパイルした内容をきれいにしてから、新しく入れ直す。
そんな感じなのかな。

正直npm周りが分からないので、新しくしてみたら何とかなった次第です。たぶん結構前に入れたので、使うときには新しくしましょうというのが鉄則なのでしょう。それから対応するバージョンに合わせていくのが無難なのかと。基本、安定板の一番新しいのを入れるのがいいんでしょうが、色々問題はありますしね。

とりあえずviが動く環境を手に入れられた。次はSSLというかTLSでHTTPSにしたい。オレオレ証明書でもいいけど、タダでもらえる時代なのでガチで入れてみる。あとWebのルートディレクトリで動作させるのは危なすぎるのでこれも次にやろうと思う。プロキシの設定の問題で、80と443番ポートのアクセスしか受け付けないみたいなんだよね。怪しいポート番号は怪しいサイト、とみなしているのでしょう。どっちにしてもルートで動かさないといけないよなぁ。面倒だがやるしかないなぁ。

タグ:Node.js
コメント(1) 
共通テーマ:パソコン・インターネット

LXC on Ubuntu on MacOSで再度挑戦 [Linux]

LXC on Ubuntu on Windows7でネットワークに苦労したという話を書きました。まぁそもそもがVirtualBoxのブリッジ接続ができないLAN環境に加え、ホストマシンが32bit Windowsで、プロキシさえあるという三重苦の状態だったので、繋がらなくても当然なのかもしれません。

結局、LANの中のDHCPでIPを割り振ってもらわないと外が見れないですから、LANに接続できないと話にならないわけでした。プロキシ設定はLXCにもあるものの、NATを設定してもそもそもLANもその外側も見れないという状態でした。

疑問に思ったのはVirtualBoxで本当にLXCはできないのか、ということです。それがDHCPサーバに割り振ってもらえてないのが原因なのか、その前のLANにそもそもアクセスすらできないのかもわかっていません。なわけで、MacのVirtualBoxがお家でWebにアクセスできるのかを見てみたいと思います。正直ハマりそうな予感がするけど、プロキシもないしブリッジ接続できたはずだし。

うぉぉっ。Core i7+SSDで爆速だ。Core i7の世代は古いけどねw。やっぱインストール速いわ。というか、HDD自体が遅いんだよね。SSDだとSATAの能力もギリギリまで発揮できそうだし。OSインストール後のやたら多いアップデートも半分以下の時間で終わりました。

そういやUbuntuのカーネルはver4になっていますが、あいかわらず再起動なしのOSアップグレードができてないみたいです。これは32bitの時のものですが、やっぱりできてない。
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-53-generic i686)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.


*** System restart required ***

システム再起動しろと書いてあるので、Ver.4の利点を活かせてないのかな。それともやっぱり完全な再起動をしないとダメな部分が残っているのだろうか。たぶん、Ver.4にしてもセキュリティを上げるだけのために使っているのかもしれない。ずっとVer.3でいられるわけもないし。

おぉ書いてるうちに最初のアップデート終わってた。会社の事務マシンとは比べものにならんな。起動も嫌になる程速い。というか、もうHDDを使う理由って容量しかないんじゃないかと思うね。値段もこなれて来たし。sudo lxd initで適当にセッティングをして(ってそこが一番大事じゃないの?w)、下記のコマンドでLTSを入れた。

lxc launch ubuntu:16.04 my-ubuntu


このコマンドはネットワーク先に依存するのでそれほど速くはない。SSDが速くてもどうしても相手側のサーバの速さがボトルネックになってしまったりする。LXC自体に最新のLTSぐらい入れてくれても良さそうなもんだけどねぇ。どうせUbuntuで作ってるんだし。

あ。普通にapt通っちゃった。lxd initをほぼデフォルトで設定したんだけど、変えたのはブリッジに設定したところぐらい。LXCを実行しているVirtualBox上のホストOSすらネットワーク関連をいじってない。というわけで、特に細かい設定なしにLXCからインターネットが見えたのでした。あっけなさすぎたな。

ということは、会社でやっているところの問題は、いくつか見えて来たわけです。少なくともLXCのコンテナから見えない構造にはなってない。設定の問題、LXCというよりもLAN側の設定が大きそう。そこは手を入れられないので、諦めるか迂回する方法を考えないといけない。それと32bitだからこそ残っているバックポートし忘れなどのバグとかも怪しい。どっちにしてもLXCコンテナでWebが見れないという事態にはなっていない。まぁもしそうだったら誰もLXCなんぞ使っていないんだろうが。

う〜んこれは会社のLXCの希望の兆しか、諦めろとのネットワークのゴリ押しで終わりか。できればネットワークが見られるといいなぁ。いちいちインストール済みのHDDイメージを入れ替えるのも面倒な気がするので。

コメント(0) 
共通テーマ:パソコン・インターネット

わけあってLXC on VirtualBox [Linux]

はじめに述べておきますが、ここでホストOSと言っているのは特に断りがなければ、VirtualBoxに素で入れたUbuntuのことで、LXCホストという意味でホストOSと言っています。普通はVirtualBoxがインストールされているOSのことを言うんだけど、LXCでコンテナを使っているので紛らわしいですが念のため。

VirtualBoxの中のUbuntuでLXCを使っているのだけれど、VirtualBoxの中ではネットワークの部分がなかなかうまくいかない。そもそも、LXCコンテナだと一般的なインストール作業がないため、ネットワークがなくてもコンテナを作れてしまう。そのため、作ったそばからaptとかでネットワークを使ってアップデートをかけようとすると、アクセスできなくてはじかれてしまう。

その時点で諦めるべきなんだろうなぁと思ったりもするが、32bitOS上ではDockerが使えないし、LXCを使ってコンテナを作るしかなかったりする。LXCで32bitだからといって問題があるとは思えないのだが、VirtualBox単体でも問題が出てくるのに、さらにその上にLXCのネットワークが来てしまうと何が悪くて使えないのかさえもわからないことも多い。

何ができていないといけないか整理すると、

・コンテナ内からWebが見える状態にする
・ホストOSかホストOSと同じネットワークから、任意のポートにアクセスできる。

この二つが実現できていれば大体良い。方法はいくつかあるけど、わりとことごとくやられてしまった感じ。そもそもPROXYサーバ経由で実現しないといけなかったので、面倒な設定が多かったりする。

その時の様子。
http://miff.blog.so-net.ne.jp/2016-11-13

設定すればVirtualBoxの中のホストOSからもインターネットが見える。一般的なソフトウェアリポジトリなどは見られると思う。上のリンクでLXCにもプロキシの設定をしないといけないのだが、それをやってもインターネットは見えない。そもそもLXCのホストOSから出られる設定になっていないようなのだ。先に言ったようにはじめからaptでファイルを取ってこれない状態は変わっていない。


今のネットワークへの参加の状態を書くと、

VirtualBox上のホストOSはNATで参加。LAN上のコンピュータからはアクセスできない(はず)。
ホストOSで使ったLXCはブリッジ接続が基本みたいだけど、それでは外が見えない。

そんな感じ。NATでつないでいるのは、LANの設定でブリッジ接続ができなかったからで、そこでブリッジ接続ができていれば、ブリッジブリッジで使えたのかもしれない。あと、LXCの設定をするとデフォルトで8443のポートが、LXCのホストOSに開きます。それはホストOS上でnmap localhostしたから問題ないはずです。ただホストOS自体がLAN方向には閉じているので(インターネットにはつながる)、そのポートから云々ということはあまりできないと思われます。

ん〜どうしたものか。ホストOSがブリッジ接続できたとしても、外につなげられる設定があるとは限らないんだけどね。結局、LXCのネットワーク設定がブリッジ前提だから、LXC同士のネットワークにはいいんだろうけど、外に対してのアクセスという面はあまり自由度がないのかなと。

ググっているとiptableとかいじっているのがあるんだけれども、ポートフォワーディングとかも嫌だし、なんかiptableってコアすぎてあまり触りたくない気がするんだよね、なんでかわからんけども。とにかく、今のところLXC on Ubuntu on VirtualBox on Windowsのネットワークアクセスは外にできてないということで。

コメント(0) 
共通テーマ:パソコン・インターネット

WindowsにUbuntuが乗るならwgetもWindowsでやればいいじゃないか。 [Linux]

Windows10で唯一いいと思ったのが、Bash on Windowsの存在。Bashというよりもaptのソフトウェアリポジトリを使えるところが超いい。上手く動かなくてもbuild-essentialを入れればどうにでもなろうというもの。それまでもBash on Ubuntu on Windowsについては何回か書いてきた。

それまではフィジカルなハードの上に普通にサーバを置くか、WindowsやMacの上にVirtualBoxかなんかの仮想化ソフトを使ったりして、いづれの場合にもSSHでつないでいたわけだ。でもBash on Windowsを使えば直でLinuxのソフトが使える。それもバイナリリポジトリを使えるとなると手間はほとんどない。

前までUbuntu上でwgetで画像を取りに行って、zipで固めて、WinSCPみたいなソフトでUbuntu上のファイルを取りに行って、Windowsのグラフィックローダーを使ってみていたりしていた。でもWindows上でできれば面倒(zipの日本語ディレクトリの扱いとか)が少なくて済むし、Linuxのノウハウがそのまま使える。こんな素晴らしいことってある?

開発ではGUIなんて重くなるだけだから、たくさんメリットがなければコマンドラインでいいんじゃねぇか、と思ってしまうとともに、普段の使い道でGUIじゃないコマンドラインなんか使っていられっかと思う人です。どっちにも理由があって選んでいるわけですが、MacとWindowsを選んでいる時よりもシビアに見比べるわけです。

そんなわけでwgetで画像収集の旅に行ってきます。wgetの使い方はこのブログの検索窓で結構見られると思います。まぁSurface3の限られたストレージの上でやるのですから、そんなにガンガン取りに行けるわけじゃないですが。

コメント(0) 
共通テーマ:パソコン・インターネット

libglib2.0-0でエラーが出たんだけど [Linux]

Ubuntuでapt upgradeをかけたらlibglib2を入れるときにエラーが出た。昔はAptでも依存性の問題を解決する自体に問題があったものだが、最近はそういうのにあたらなかった。でも、デスクトップ版でアップグレードをかけようとしたら出てきた。

ググると似たような事態を見つけた。
 http://askubuntu.com/questions/240147/libglib2-0-0-broken

sudo apt-get install -f libglib2.0-0=2.30.0-0ubuntu4

をすればいいと書いてあったのだが、そんなパッケージ無いとかエラーが出たので
sudo apt-get install -f libglib2.0-0

とやってみたらエラーが出ず色々ドカドカ入れられた。

そんでsudo apt upgradeは上手くいったみたい。どっちにしろ、GUIが必要ではないサーバ的には面倒が増えただけの気がする。lxcのイメージにはデスクトップに必要なパッケージは入らないことを願う。だってディスク領域無駄に消費するだけじゃん。

コメント(0) 
共通テーマ:パソコン・インターネット

やっぱり会社のプロキシはSSHどころか、aptぐらいしか使えない。けど何とかした。 [Linux]

http_proxy、https_proxyを設定しても、LXDとかでイメージをダウンロードできなかったりで、まともに使えない。前のところはプロキシを設定すればいろいろできたのだが、ガチで技術者の会社に来ると詰めて設定されているので隙がない。相手は自分よりも上の技術者だろうから困るなw。


まずはじめから行こう。作りたい環境はWindows7上にUbuntuなLXCコンテナだ。要するにVirtualBoxにUbuntu16.04を入れて、その中でLXCを動かすという算段。Ubuntu16.04のISO拾ってきて、それでブートして、インストーラで会社のプロキシを設定してあげれば入れることができた。ネットワーク的には問題なさそうだ。ホストOSは入れられた。

ただインストーラで使ったプロキシは、入ったUbuntuには反映されないから、環境変数のhttp_proxy、https_proxyを入れる。いくつかのコマンドはこれを読んでくれるみたいだけど、基本aptぐらいしか使わないみたいだ。wgetとかも独自に設定してあげないといけなかったんだよな、たしか。

aptを使えるのでソフトは簡単に入れられるようになった。話が前後してしまうけど、VirtualBoxのネットワーク設定はいくつかある。

 http://changineer.info/server/virtualization/virtualbox.html#i-7

はじめはブリッジ接続でやろうと思ったんだけど、なぜかDHCPからIPがもらえなかった。そんなわけで外に出られないどころか、自分のホストからもネットワーク経由では見られなかった。まぁネットワークを設定しているのは自分じゃないのであきらめるしかないんだろう。

とりあえず、ゲストマシンが外とやり取りができて、自分のホストから別マシンとして見えればいい。はじめから外が見える設定になっていて、OSのインストールの時にネットワーク経由でファイルを取りに行っているから、そこのところは問題ない。自分のフィジカルなOSから、中の仮想化OSを見るためには、上のリンクのようにNATの状態にポートフォワーディングすればいいらしい。

ここは間違えたところも書いていて、分からなかったことが分かった。

 http://blog.pg1x.com/entry/2014/06/20/234518

自分も上で書いている人もポートフォワーディングが何なのかをはっきりとわかってなかったということで。そういやルーターでもポートフォワーディングってあるけど、本質的に同じものではない(同じハードに同居しているわけではない)ので、状況的に違うしね。確かにポートを別のものに変換するというのは変わっていないわけだけれども。まぁ同じマシン上でバッティングしないで使えればいいってだけだと思うんだけど。

とにかくポートフォワーディングの設定をVirtualBox側でやってあげれば、ホストOS側からもアクセスできる。基本SSHの22番ポートと、Webアプリ用などに80番が使えればいいわけで。他に必要なら同じように設定すればいいんだろうけど、そんなに必要になることはないと思う。

んでゲストOSからプロキシを経由してLANの外側を見れてLXCが使えればいいわけだが、lxcのコマンドが通らない。始めに書いたように、lxc関係はhttp_proxyを使っていないみたいなのだ。というか、http_proxyを使っている方が少数派なのかもしれない。日本語でググっても全然出てこないので、検索語を英語にしたらすぐに出てきた。もちろん検索先も英語サイト。まぁ実際に使うコマンドを確認できればいいだけなんだけどね。

https://www.stgraber.org/2016/03/15/lxd-2-0-installing-and-configuring-lxd-212/
lxc config set core.proxy_http http://hogehoge:3128
lxc config set core.proxy_https http://hogehoge:3128
lxc config set core.proxy_ignore_hosts image-server.local


設定はファイルに記述とかじゃなくて、コマンドで注入する。他のアプリから設定することが多い場合は、やたらバリエーションが多くなってもコマンドだと、ファイルに書き込むよりか簡単にあとくされなく設定できる。UNIXは設定をファイルにテキストで持っているというのが一般的であったが、こういう設定は自動化を徹底するなら増えてくる可能性が高い。まぁYAMLやJSONやXMLでストアすれば、人間にも機械にも読みやすい設定ファイルが作れるかもね。

とにかくLXCの設定は上のhttp://の後を該当のURLに変えればよい。日本のサイトって本当に欲しいところが出てくるのって簡単な設定だけなんだよね。それはそれで役に立っているのだけれど、ググったら自分のブログが上位に出てきてしまうと悲しくなってくるんだよね。そんなにマイナーなことをしているつもりはないのだけれど、日本人は英語のドキュメントを前にするとあきらめちゃう奴が多いので、それを簡易に翻訳するとかかみ砕いて紹介するとかしてくれる人が少ない。

Dockerの日本語ドキュメントは結構あるのにLXCってそれほど多くない。使っている人が少ないのかなぁ。やれることって大して違わない気はするし、ちょっと前までDockerがLXCの機能を間接的に使っていたりしたし。それとLXDになってできるようになったことがわからない。それはおいおいやっていくことにしましょう。

コメント(0) 
共通テーマ:パソコン・インターネット