So-net無料ブログ作成

Ubuntu16.04デスクトップDVDが立ち上がらなくなった。 [Linux]

14.04LTSから16.04LTSへのアップグレードが見事に失敗し、DebianでUbuntu16.04のISOを取って来て焼いた。そこからブートしたのだが、なぜか途中で電源が落ちる。意味がわからない。ずっと立ち上がったままとかならまだしも、諦めて電源切るなよw。

何が悪いのかなぁと思って、CPUが16bitじゃないよな、いくら古いとはいえと危惧したが、問題なくx86_64の表示があった。そのOSが動いているから問題ない。DVDの焼け具合が悪いのかなと思い、Macでブートしたら問題なくデスクトップ画面まで行った。何だよそれ。今までXPやらDebianやらUbuntuやらを散々入れて来たマシンで動かないとか意味わからないんだが。

何が悪いのかわからないので、他のISOディスクでブートしてみる。他の昔焼いたCDとかDVDとかでは問題なくブートしている。何だろう。Ubuntu16.04.2のディスクがおかしいのか? どちらにしても相性は良くないようである。というか最近デスクトップのUbuntuはずっと入れていないので、状況がよくわからない。そういやいつ頃か64bitに変わってやっと当然の対応がされるとか思っていたのは覚えている。でも、その時もインストールしなかった気がする。

たくさんあるHDDを取ったり、マザーボードとは別に付けてあるイーサネットカードを外してみたりして動くかなぁと思っていたのですが、結果は変わらず。ただ単にDesktop用のDVDの素養が悪いだけじゃないかと思いだしてきた。ハードウェアが悪いとか古いとかいう問題じゃない気がするよ。ほんとこういうデグレードは頭にくるなぁ。GUIっぽい画面になっているからどこで止まっているかも見当がつかないし。

そういや日本語Remixという邪道なものがあった気がするなぁ。それでブートできれば問題ないのだが、いちいち落として来るの面倒だなぁ。正直、前入れた時に変なメッセージがブートの度に出て来てウザかったから、二度と使うものかと思ったのですが、デスクトップ用途なら日本語入力とかすんなりできた方がいいし、入れてみるのも悪いことじゃないのかもしれない。でも、同じようにブートしない確率高いなぁ。だって基本的なところはみんなおんなじでしょ。ブートしてからが勝負なディストロだろうから、ブートする前はやっぱりダメなんじゃないかな。

結局日本語版を落とした。DebianでもTorrentデフォルトで使えるんだね。Transmissionっていうアプリがあってちょっと驚き。なんかDVD-RWこんなに焼くのも久しぶり。以前はLinuxを物理サーバに入れるために、CD-Rとかはブートディスク用によく焼いてましたが、仮想環境が整ってきたためにISOファイルをそのまま使って終わりということがほとんどでした。今となってはISOファイル自体も使わず、コンテナを使ったりしていて時代の流れを感じさせます。

それにしてもDVD-RWは2倍速しか出ないのって遅いなぁ。RW系のメディアって焼くの遅いんだよなぁ。CD-RWとか高速規格が出てすごく嬉しかった思い出がある。何回もかけるだけじゃなくて、耐久性も色素よりかはいいらしいのは良いことだ。と書いているうちに終わると思っていたが、まだ終わらない。時間が過ぎてディスプレイの電源も落ちる始末。Torrentでネットワークから落としてくるよりか遅いんじゃない? というか、ネットワークも無駄に動画とか扱うようになって余裕が出てきたというか、世界のどこかの途中で引っかかるということが少なくなってきた。

さて焼けたら日本語RemixDVDでブートしてみる。あぁそうだ、DVDにはファイナライズという処理が必要だったんだったっけ。あぁ感じが同じだからまたすっこけそうだなぁ。なんか前より長いことDVDが動いている気がする。を!大丈夫そう。デスクトップ画面まで行った。音まで出たw。やっぱ同じ16.04でもデグレしてるんだな。友好的なコミュニティーなら英語で報告しに行くけど、Ubuntuは使わせてもらってるだけなんで無視。というか自分たちで気付け馬鹿者。Debianからかすめ取っているのを最大限に感謝する意向を示さない限りはそういう献身的な行為はしない。使えるから使ってやっている。大体の人間はそんなもんだろう。

さて、たくさんあるパーティションの中から選んで、インストールした。日本語のローカライズはそこそこきちんとしている。アホな外国人が翻訳機をかけたような日本語ではない。さてUbuntuのデスクトップはどう変わっているのだろう。正直そんなに期待していないが、とりあえずFirefoxが使えれば問題ない。DebianもIceなんとかじゃなくて、Firefoxになっていたし権利関係というかライセンス関係の問題はクリアしているのね。FirefoxだけどFirefoxにあらずってのはどうにも使いにくいし、バージョンとしても無駄な手間がかかっているぶん古くなってしまう傾向にあったしねぇ。とりあえず、Chromeなんてネトゲーにしか使ってないですよ。あんな寄せ集めのブラウザなんてできれば使いたくないし、Googleにはすでに極度に依存しすぎている気がするし、これ以上べったりは嫌だ。

サードパーティのソフトをインストールを付けたので途中でハングした。インストールの時に選ぶのをやめたらインストールが最後まで終了した。問題なくインストールできたみたいだけど、放っておいて画面が消えた後にレジュームしなくなっていた。元々そんなことがあった気もしたが、マウス動かしても、キーボード叩いても、電源ボタン押しても、画面が戻らず消えたまんま。なんでかよく分からんけど、そういう状態になっている。やっぱりUbuntuはサーバとして使うのが一番だな。Desktopは気を遣うところがたくさんありすぎて、OSS的なサポートでは限界があるのではないだろうか。しかも、どういうところで動くかハードがバリエーションありすぎるし、それをサポートするベンダも多いわけではないだろう。GPUなどはプロプライエタリなドライバとかでGPL的には問題になっていたと思う。

入れたはいいが使わないかもなぁ。デスクトップの使い勝手が上がってUbuntuは名を上げたけど、正直ある時から進歩を止めてしまったような気がする。そして我が道を行って散々叩かれたUnityとかあったけど、次のLTS18.04ではGNOMEに戻るらしい。

http://archlinux-blogger.blogspot.jp/2017/04/ubuntuunitygnome.html

何でもいいから使いやすくて今後も発展できるような状態になってほしいものである。ともあれ、LinuxはコマンドラインなOSとしては一部GUI商用OSよりも安定しているぐらいだけど、GUIを加えるとその安定感が逆転する。やっぱり資本がかかっているかどうかは、集約的な作業が必要かどうかという面にかかっている。散開的な開発モデルでは何ともならない部分もあろうかと思う。基本的にGUIなOSは何が何でもGUIで解決できるようにしないといけないという縛りが強いので、できなければCUIで的な逃げは作りにくいからユーザーフレンドリーにならざるを得ない。というか、昔のようにオタクだけが触っていた時代に戻ることは許されないし、そもそもGUIのパソコンだって既に使いにくい人間も多くなってきているのだ。

そういう意味からLinuxはAndroid並みにラッピングしてあげないと使い物にならないのかもしれない。使いこなすのにベンダー試験が必要なくらいではダメなのは当然の話だ。昔はコンピュータとプログラミングが近い関係にあったのだけれど、圧倒的にアプリを使うだけの人間が増えた今、デスクトップOSというのはLinuxとしてはどうなのかと思ってしまう。Chrome OSも事実上は失敗したと言えるだろうし、実際Androidに吸収されるみたいな話を読んだ気がした。そういう意味ではパソコンをOSSでやる意味というのは、スマホが主戦場になった今、それほど重要じゃない気もする。スマホにサービスを与えているのも、GUIが必要じゃないサーバが大半なのだろうし、実際コンテナでGUI環境も確保しようという話にはなってはいないと思う。

タダのデスクトップなOSとしては面倒が多すぎるので、今まで普及することはなかったし、これからもないだろう。タブレットOSが端末として発展することはあるのだろうが、それはLinuxがカーネルですよというだけで、ユーザーランドが云々という話でもディストロがどうとかいう話でもない。こう見るとGUIなOSが割と大変な思いをして作られていることが感じられる。正直、ハイスペックなプログラマがGUIに苦心し続けるという事は考えずらい話でもある。そんな手先の事を考えるくらいだったら、自分のEmacs環境を充実させるという人の方が玄人の方には多いでしょうしね。

しかし、最近Emacsを使っている人というのをとんと見かけなくなった。そういう仕事場ではないのは確かなのだが、それにしても使っている人ってそんなに多いのかなぁと勘ぐってしまう。やっぱりカスタマイズをかけてなんぼの商品ってのは、個人的に先鋭化され過ぎてしまって、周りに広がりを見せないというのが問題なのだろう。それに他の環境行ったら一気にできなくなることが多くなってしまうし、どこにでも入っているviを使おうという気になるのが普通なのかなと思う。だからviかemacsかという宗教戦争があったのは過去の話で、結局emacs使える人はつぶしが利くようにviもある程度使えるんでしょ、という事になっちゃってると思う。どっちがいいとかそういう話もできなくはないだろうけど、そもそもプロダクトとして比べるものなのかどうかという時点から怪しい。だってスクリーンエディタという切り分けでしか合っていないわけでしょ。

ただ黙々とEmacsを使える環境にいられる事自体が恵まれているのかもしれないなと思う。大体、常駐先企業に入るとおいそれと自分の環境を持ち込める状態にあるところは少ないんだろうし。vi以前にWinSCPみたいなツールを使って、Windowsのエディタを使っているよという人の方が多いんだろうね。最初に仕事に入った時も秀丸エディタが活躍していたし、今でもWindowsやMacのエディタで編集している人も多いんだろうと思われる。viにしてもEmacsにしても、操作が直感的ではないし、習得するのに幾分時間を取る。GUIなエディタだったら酔っぱらっていても操作できそうなものだ。UNIX的なエディタでは酔っぱらって作業はできないw。

何にしてもつぶしが利く方法で不都合なく操作できればいいんじゃないというのが結論なのだろう。だから何使っても迷惑をかけないレベルで作業できていれば誰も文句を言う必要はない。ただ、無駄な縛りを効かせられる人間や環境はどこにでもあるもので、その場所によって常識は変わってくる。自分が良くできると思っている人間ほど、自分の持っている常識は間違いないと思っているが、そんなものは不確かなもので庇護の下にしか存在しえないものだと自覚した方がいい。ふんぞり返っている人間ほど、できない時オロオロして環境のせいにしがちだし。

まぁGUIだろうとCUIだろうと、面白いものが作れればいいなと思うわけで。それをタイピングで生み出すことのできるプログラマという職業を面白く思う。一時期、GUIでみんなプログラミングできるみたいな妄想をしていたことがあったが、そこまで作り上げるのに誰がコーディングするのという話になってくる。ある程度は作ってやらないといけないし、個別的な話になると手で書いちゃった方が速い場合だって多いだろう。


どうでもいいが今入れたUbuntu16.04LTSは18.04LTSまでの命だろうな。すぐには代えないだろうけど、GNOMEに戻るんならそっちの方がいいだろうし。CanonicalもスマホのOSを新規に開拓すればよかったのかもしれない。無駄にパソコンから移行させようとしたから失敗したに違いない。まぁ僕としてはAPTのリポジトリをきちんと維持運営してくれれば問題ない。Bash on Windowsもあることだし。

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

Ubuntu14.04LTSから16.04LTSにアップグレードで少し泣いた。 [Linux]

デスクトップ環境でLTSからLTSへのアップグレードをしたのだけれど、案の定問題が発生。そう上手くはいかないのが世の常。というか、大した理由もないのでクリーンインストールすればいいのだが、なんとなく試してみたくなった。

do-release-upgradeすればいいのね〜ふんふん〜とやっていたら途中でエラーが出て止まる。あ〜事前にapt update&&apt upgradeするの忘れてた〜。再起動してみるとデスクトップが起動しなくなっていた。んも〜面倒臭いなぁ。というかただ単にデスクトップ環境があった方がいいなと思っていただけなのに〜。そこは以前GPGPUをやろうとしてかなり環境をいじくった後なので、まともにアップグレードできる環境じゃないことは重々承知だったんだけど、はじめのお作法を忘れては何にもならない。

ん〜かなり待っているのだけれどうんともすんとも言わず、最後にはHDDへのアクセスも途切れてしまった。これはクリーンインストールが妥当かなぁ。クリーンインストールするにもISOをDVDに焼かないとダメだろう。それにしてもWindowsXPが死蔵されているマシンって、どうでもいいけど使えない感じ満々である。でも、何か必要かもしれないと思って置いておいたパソコン感がひしひしと伝わってくる。XPの他にもいつのバージョンだかわからないDebianも入っている。どうしようかな。使えないで放っておくのもなんだしなぁ。

Debianもそうなんだけど、Ubuntu14.04を取って置く意味は全然ない。もうGPGPUはやめてしまったし、GPU自体も他のパソコンへ移動させてしまった。しかし、Desktop Ubuntuはしばらく入れてないなぁ。Unityやめたんだったっけ。GNOMEがいいよ、普通がいいんだよ。まぁ面倒が一番少なくて汎用性があるのが一番なんだけどね。jessieって何だ? DebianはToy Storyのキャラクター名をコードネームにしているんだよね。あ〜カウガールのあの子ね。現行のディストリビューションってのはどうなっているんだろう。一応入っているものでもメンテされているみたいなんだけど、それもできたら新しくしちゃいたい。何気に現行のバージョンであった。LTSだと2020年まで行けるらしい。Ubuntuとかとそんなに変わらないじゃないか。

Debianもapt update && apt upgradeしたら、GUI画面から入れなくなってしまった。何だろね〜。ハードディスクは動いたまんまなので何事かやっているんだろうけど、何しているんだかはCUIよりもわからない。だって何の断りもないんだもん。こういうところは商用のOSとは違うところで、無口で無駄にユーザーを不安にさせるんだよなぁ。まぁ商用でもタイムアウトもせずにずっと立ち往生の時もあるけれども。一時間くらい放っておきます。というか、DebianもUbuntuの生みの親とはいえ、色々とユルいところは否めないな。

UbuntuがDebianの融通の利かないところをいいとこ取りして成功したわけだけど、はじめはDebianのことに触れていなくてむかついた。Debian側でもむかついている人はいたみたいだけれども、実際DebianのGPLなどの縛りは使いにくかったし、妙なところに力を入れるからそういうリソースの力点的な意味でも正直使いやすいとはいえなかった。そのところを解決したのはUbuntuは上手かったし、Debianに敬意を表していないところ以外は特に問題なかった。

その後はデスクトップの政策が迷走してしまい、モバイルのほうに出て行こうとして完全に失敗した。まだFirefox OSの方がましだったかもしれない。結局iOSとAndroidの二強になってしまっているわけだが、Androidも改めて低スペック版を出してきて磐石な感じだ。Androidのアキレス腱になっているのは、マルウェア対策と偽Javaのライセンスとメモリ使用量だろう。第三のモバイルOSが叫ばれたわけだが、結局みんなポシャっちゃった感じはある。何だかんだでLinuxを使わなくてはいけないのは、Androidと一緒でARMで動くOSってのも後はWindows10ぐらいしかないのかもしれない。

OSSのOSはCUIがメインなこともあって、それほどGUIのスマホに向いているとは言えないのではないかと思う。要するにGUIラップするのが面倒なのである。やっぱりそこいらの開発はお金もスキルも集約的な体制を持っていないとどうにもならないんじゃなかろうか。ある程度の高いGUIを実装できるレベルの高い人間と、それを実証するための多くのテスト人員を揃えなければならないというところではなかろうか。それを実現できるリソースがAppleとGoogleにはあったということだろう。まぁGoogleはほぼパクリなわけだが、今のスマホはAppleとMSの功績によるところが大きい。

何でMSと言われるかもしれないが、昔からスマホを使っている人にとっては、案外MSがハンドヘルド機の古参であることはよく知っているだろう。それこそPalmとかのPDAの時代からやっているので、そこそこ実践を積み重ねてきていることは確かだろう。AppleのiPhoneがいきなり出てきたと思われがちだが、感圧式のタッチパネルから考えるとスマホの一番最初ではないはずだ。静電式のタッチパネルを全面に採用して、指で操るスタイルはほぼ完全にAppleが発明したも同じようなものだろうが、それらをみんなパクッたのでエポックメイキングだと感じられがちだけども、その他の機能は既存のものをブラッシュアップしたものも多い。

何にしてもARMはわが世の春だなと思わざるを得ない。スマホのほとんどがARMのライセンスがかかったSoCを使っているのだから、ソフトバンクは滅びることはあってもARMはしぶとく生き残っていくであろう。ARMが設計図を売るスタンスだから、どの会社も何がしかの形で作ったり使ったりしているわけで、低消費電力がここまで重く響くとは誰も思っていなかっただろう。だってPowerPCだって電力性能比は高かっただろうし、MIPSだってあったわけだ。一人勝ちになる理由は自分では物を作らないというファブレスにあるのだろうが、それにしたって設計だけで何とかできると思った人はすごいなと思うわけで。

クラウドにしたって逆の立場ではあるものの似たようなもので、ハードウェアとソフトウェアを管理してくれて、安易にユーザーが使えるようにしている点においては分業という文脈としては間違っていないだろう。ファブレスのファブ部分だって設計をせずに製造を請け負うだけの会社だってあるわけで、世の中は垂直統合じゃなくてサービスの切り分けなんだと感じている。良かれ悪しかれ全部自分でやる時代は終わっていて、それに付随するサービスをハードとかに一緒に売るとかじゃなくて、サービスそのものを売るようになってきているんだろう。切り分けとパッケージングということだろうか。目的のための手段を売らずに、楽な方法で目的に直結させる。まぁ切り分ける場所によって住み分けができてくるってことで、それをユーザー側が選べるようになってきているということなんだろう。

そういうわけでコンピューターは最終的には、スマホとか今流行りの音声認識のインターフェイスに変わってしまい、パソコンなんて仕事をするときぐらいにしか使わなくなるんだろうなと思っている。少なくともサーバレスな世界は来てしまっているのだから、少なくとも家にサーバを持つなんて趣味的にしか存在し得なくなるだろう。と言いつつ、サーバを立てて運用していたりして。今はNASやハードディスクレコーダを動かしておいて、外から視聴するとかあるみたいだが、そういう特殊な使い方以外は家に高性能で高機能なコンピュータは必要なくなるんだろうなぁ。

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

すでにバイナリが用意されているものの.debファイルの作成。で立往生 [Linux]

AppleのSwiftではUbuntuバイナリが用意されているのですが、システムのディレクトリにインストールされず、解凍してそこにパスを張るだけの仕様になっています。それはそれで問題ないのですが、なんか気持ち悪いので/usr/local/あたりぐらいには入れておきたいと思いました。出来れば.debファイルが作れればいいと思ったのですが、そこそこ時間がかかってしまいました。やることはそんなに難しくはないのですが、いちからやろうとすると結構手間で、checkinstallを使わずにやろうとしたらつまりました。

まぁ普通にMakefileがあって./configure&&make&&make installできるものだったら良かったのですが、元からコンパイルしてあるものだったので多少はまりました。どっちにしてもMakefileがまともに書けていないと動かない代物だったので、久しぶりにMakefileをかじりました。いや~書き方が独自でシェルスクリプトより面倒な感じ。出来ることが直感的じゃないんだよなぁ。前に複雑なMakefileの質問をしたところ、何でこんなものも分からないんだみたいな事を書かれたのですが、事前にかかれたものを簡単に改造できるレベルじゃないですよ。


ともあれ、オレオレdebファイルはでっち上げることが出来たので、はまった点を書いておきます。まず、makefileで
install ./usr/bin/*
みたいにアスタリスクで処理できません。インストールは出来るけど、アンインストールでファイルを覚えておいてくれないのは、Makefileの中身と同じなんですね。そこまで気にしてくれるシステムではないと。なので複数ファイルをインストールするのは一つ一つだとしんどいわけで。

だけど、面倒だけど一つ一つ実行バイナリをinstallで置いていくしかないのかもしれない。

あとcheckinstallのインタラクティブ部分で、いくつか設定が変えられるんですが、大体はそのままで動きます。ただ下のように

*****************************************
**** Debian package creation selected ***
*****************************************

This package will be built according to these values:

0 -  Maintainer: [ hoge@swift ]
1 -  Summary: [ Package created with checkinstall 1.6.2 ]
2 -  Name:    [ swift-3.1.1-release ]
3 -  Version: [ ubuntu ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ swift-3.1.1-release-ubuntu ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ swift-3.1.1-release ]
12 - Conflicts: [  ]
13 - Replaces: [  ]

Versionに数字を入れないといけないのにUbuntuとか勝手に入ってるので、そのまま通そうとするとエラーが出ます。私は適当に1を入れました。バージョン管理するつもりもないので。ただSwiftはGPLじゃないと思うので変えた方がいいかなと思ったけど、オレオレ.debファイルなのでどうでもいいかもしれない。配布するときになったら考えますわ。

あとswift-3.1.1-release-ubuntuというところは、ディレクトリから取っていて大文字だとあかんと言われていたので、元のディレクトリのswift-3.1.1-RELEASE-ubuntu16.04をlowerな感じに変えてみました。そういえばバージョンはディレクトリの最後のハイフンより後から取っていた気がした。まぁバージョンは数を何かしら入れておけばいいみたい。

あとMakefileでmake uninstallできるようにしないといけないのか、インストールしたファイルを見ていてくれてdpkg -rすれば消えるんだろうかといろいろ気になってはいた。面倒なのでmake uninstallをrmコマンドをしこしこ書いたのだけれど、dpkgを使う限りは必要ないみたい。まぁあっても問題ない。

それと/usr/local/bin/にインストールしているのだけれど、dpkg -rをするとbinディレクトリが消えてしまう。特にmake uninstallで消えるようには書いていないのだけれども、checkinstallを使ってdebファイルを作って-rオプションで消そうとするとディレクトリごと消えてしまう。他のファイルがあれば消えないのかもしれないが、それしか入れない場合は後で面倒なことになりかねない。実際、再度インストールするときに、binディレクトリがあるものとして動くのでエラーが出てしまう。

checkinstallが作るテンポラリのファイルを出力しようと思ったけど、正直良く分からず。出来たdebファイルの解凍を試みてみた。

ar -x swift-3.1.1-release-ubuntu_16.04-1_amd64.deb

みたいにすると中身が出てくる。
control.tar.gz data.tar.xz debian-binary

control.tar.gzにインストールの細かい設定は入っているのだが、ディレクトリの設定とかはなく、ディレクトリの設定に関してはdata.tar.xzに相対的に絶対パスが置かれている状態(わかりにくいな~)で、それを参照してインストールしているみたい。tarの展開を具体的に書くと

./
./usr/
./usr/local/
./usr/local/bin/
./usr/local/bin/swift-build-tool
./usr/local/bin/lldb-server-4.0.0
./usr/local/bin/repl_swift
./usr/local/bin/swift-demangle
./usr/local/bin/swift

みたいに出てくるわけです。それを元にアンインストールしているから、他のファイルと一緒に/usr/local/binディレクトリが消えていたみたいです。その下の/usr/local/は他にディレクトリを含んでいるため消されることはないようで、binにその他のインストールされたバイナリがなかったら削除されてしまうということらしい。

システムから提供されたディレクトリを消すというのはよろしくないので、どうにかして消さない状況に持っていきたいところ。dpkgが悪いのか、checkinstallの仕様が悪いのかわからないんだけど、debパッケージを地道に作らないといけないっぽいな。

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

Ubuntu16.04とかでLXCコンテナ内でtmuxを使う方法。 [Linux]

how to use tmux in LXC Container.
って書いとくと外人さんも来るかな?

やろうとした人はわかると思うけど、LXCコンテナ内でtmuxは使えなかったりした。回避方法はあったみたいだけど、根本的に解決できた。17.04になれば解決するんだが、いかんせんLTSじゃなかったりする。

https://www.ubuntuupdates.org/package/core/zesty/main/base/tmux

ここのdebファイルを使う。64bitだよね普通は。ってUbuntuの正式リポジトリじゃねぇかw。

wget http://security.ubuntu.com/ubuntu/pool/main/t/tmux/tmux_2.3-4ubuntu1_amd64.deb
sudo dpkg -i tmux_2.3-4ubuntu1_amd64.deb

ですぐに使えるようになる。別に無理やり17.04に上げる必要はない。まぁそのうちLTSに導入されるだろうから、すぐ使いたい人以外は気にしないw。今のLTSにバックポートはされるのかどうかは知らない。まぁそのまま使えるので、該当バージョンのaptで設定されれば入るというわけで。

なんか色が違うような気がしなくもないが気にしない。

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

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) 
共通テーマ:パソコン・インターネット