「Linux/OSS」カテゴリーアーカイブ

Windows Subsystem for Linuxでの複数ディストリビューションの管理

Reference listing and configuring multiple Linux distributions running on the Windows Subsystem for Linux.

情報源: Manage Linux Distributions

上に書いてあるとおりです。

Windows 10 Fall Creators Update(RS3)よりWindows Subsystem for Linuxで複数ディストリビューションを同時実行できるようになり、それに伴いディストリビューション管理用のコマンドが追加されているほか、コマンドが新しくなっています。

機能的には上にあるようにインストールされているディストリビューションの一覧、既定のディストリビューションの設定、登録されているディストリビューションの解除が行えます。

このようにディストリビューション名と既定(Default)であるかどうかが表示されます。

既定とそうでは無いものとの違いは、既定となっているディストリビューションはwsl.exe(従来のbash.exeに変わる物)もしくはbash.exe(将来的になくなる可能性有り)コマンドで呼び出されるディストリビューションとなります。また、既定でないディストリビューションを呼び出す場合には、ストタートメニューから該当するディストリビューションのアイコンをクリックするか、上のwslconfig /lコマンドで表示されるディストリビューション名をコマンドプロンプトもしくはPowerShellから起動します。

また、wsl.exeとディストリビューション名で呼び出したときの細かな違いとしては、wsl.exeの場合ログイン時のフォルダがWindows側のユーザーフォルダ(/mnt/(systemdrive)/users/(username))であるのに対して、ディストリビューション名で呼び出した場合には、Unixファイルシステム側のHOMEディレクトリ(~)になります。ただこのあたりの動作も今後RS4に向けて仕様が変わらないとも限りません。ユーザーフィードバック次第だと思います。

ということで、RS3以降追加されたコマンドや挙動もそれなりに変わっているので、上情報源等MSDNのドキュメントを今一度ご確認ください。また、リリースノート、開発陣のBlogを追いかけておくことも大事です。

リリースノート https://msdn.microsoft.com/ja-jp/commandline/wsl/release-notes

Windows Command Line Tools For DevelopersのBlog https://blogs.msdn.microsoft.com/commandline/

Windows Subsystem for LinuxチームのBlog https://blogs.msdn.microsoft.com/wsl/

混ぜるな危険 (msys2とCygwinとGit For Windowsを一緒に使ってはいけません)

まぁ上に書いたとおりです。今まで機会があるたびにお話しさせていただいていたりするのですが、いまだに1つの環境にGit for WindowsとMsys2/MnGW、もしくはGit for WindowsとCygwin、もしくはそれらの全部をインストールして環境が動かなくなった発言をtwitter他で見掛けますが、これらの環境を混在させない方が無難ですというか、混ぜるな危険です。

Msys2はCygwinからForkされた環境なので、ランタイムの内容がCygwinとは違います。Git For Windowsのツール類はMsys2のランタイム上で動いていますが、このGit For Windowsに付属しているMysy2ランタイムはGit For Windows用のMsys2ランタイムなので、本家のMsys2のランタイムとはソースレベルで異なります。つまりこれらの環境にはそれぞれ互換性が無いので同居させない方が良いし、ましてや全部の環境に対してPATHを通すようなことは絶対にしてはいけません。動かなくなります。

基本的に、Windows上で何らかのUnix互換環境が欲しい場合にはCygwinもしくはMsys2を選択し、GitもGit For Windowsではなく、それぞれの環境で用意されたGitの実行ファイルを使用してください。

どうしても混在させたい場合には、それぞれの環境を全部PATHに追加するようなことはしないで、個別の環境用の起動BATファイルなど用意し、PATHの中に複数の環境が混在しないような形で使用しましょう。

同様の理由でGit For Windows SDKの環境を直接PATHに追加することもおすすめしません。

また、Ruby On Railsの開発環境構築などで、RubyのToolkitをインストールすると、古いmsysのツールがインストールされ、PATHが追加されてしまう場合があるので、この場合にもGit For WindowsとRails開発環境のToolkitのPATHが混在しないように起動BATファイルで工夫するなどの処理が必要です。

以上で「お前は何を言っているんだ?」という感じで内容がわからない人は、Windows上にUnix互換環境を作るのは諦めていただいて、素直に仮想マシンにお気に入りのLinuxディストリビューションをインストールしていただくか、Windows Subsystem For Linuxをお使いください。

もう一度大事なことで書きますが、混ぜるな危険 (msys2とCygwinとGit For Windowsを一緒に使ってはいけません)

TOKAIケーブルネットワーク ひかりdeネット10G  に関するすったもんだ

情報源: ひかりdeネット10G | ケーブルテレビ (TOKAIケーブルネットワーク) 本日契約しました。工…

情報源: ひかりdeネット10G  | OPC Diary

上に書いたようにTOKAIケーブルネットワークのひかりdeネット10Gを契約したのですが、契約後以下のことがわかりました。

  • 営業さんがルーターと言っていたのは、営業さんが混乱していただけで、ただのD-ONUでルーター等の貸し出しは無い。
  • D-ONUにはEthernetポートが2ポートあるが1ポートは電話アダプタ専用なので、インターネット接続に使用できるのは1ポートのみ。
  • 配布されるグローバルIP(IPV4)は1つのみ、有料でも複数配布するサービスは今のところない。

つまり、ひかりdeネット10Gというインターネット接続サービスは、下り10Gb、上り1Gbの回線を提供しながら、その先はすべてお客にぶん投げるという、まさに「投げっぱなしジャーマンサービス」というべきものでした。


三沢さんの懐かしい映像をどうぞ

全く素人にはお勧めしないというか、本当にどうしろとw

普通の一般人ではこの段階で絶望して終わりです。

この段階で契約を白紙に戻すことも考えたのですが、フレッツNext隼1Gが最近特に夕方から夜中にかけてはフレッツNext隼10Mぐらいの通信速度しか出ず、もういい加減どこかに乗り換えたいので、そこは思いとどまりどうするか考えることにしました。

まず、10Gb対応のNAT/IPマスカレード環境を構築しないと行けませんが、10Gb対応の安いブローバンドルーターとか当然無く、10Gb対応のヤマハルーターもない(お願いヤマハ様RTX810クラスで出してください!)ので、棒C社とかのエッジルーターとか見てみるわけですが、当然のように金額的にも技術的なハードルも個人でどうこうできる感じでも無いなぁって感じになるわけです。

いろいろ考えて見ましたが、せっかくの10Gbの回線にMAX 1Gbのルーター繋ぐのももったいないので、いっぱんじんである私は、PCでブロードバンドルーターを作る事にしました。ルータ用PCの構成は以下のようになります。

  • CPU : Intel Core i5 6600K
  • RAM : 16GB
  • SSD : 128GB
  • マザー: ASROCK H110M-ITX (miniITX)
  • 電源: 玄人志向 KRPW-SX400W/90+ (SFX 400W)
  • ケース: Silver Stone SST-SG06S-Lite/B(miniITX Case)
  • NIC : Intel X540-T2(10G BASE-T * 2)
  • OS : Fedora 26 Workstation

CPU, RAM, SSDはどこのご家庭にもある余り物です。オンボードのNICはUEFIで殺しています。NICはお値段がこなれてきた2ポートのIntelのX540を使用し、これで速度低下無しでルーティングできますね。

OSがFedora 26なのは、わたしがyum野郎で、「そう言えばまだFedora 26使ってなかった」からで、Workstationなのは私がWindows野郎なのでGUIがないと怖いから。

動作しているサービスは今のところfirewalld、upnpd、dhcpdのみで最低限のブロードバンドルーター機能を実現しました。とりあえずupnpdが起動時に一度こけるのが困りものですが、サービスを再起動すれば問題無くUPnPも動作しています。個々のインストールセットアップについては書きませんので、興味のある方は各位お調べください。いやーでも今本当に簡単ですね。

ゆくゆくはVPN環境等も整えていきたい所存。

また、ルーターとPC他を接続するためにバッファローのBS-XP2008という8ポートの10Gbのスイッチを購入しました。特に何も期待していなかったのですが、専用ユーティリティを使えばVLANとQOSの設定ぐらいは出来るようです。

ま、あと使ったお金のことは考えたくない。

最後になりますが、ネットワーク構成案を添付いたしますのでご査収ください。

さて、実際の工事はどうなりますことやら。次回は工事完了後にレポートいたします。

WSLにSUSEが追加されました

情報源: SUSE’s Linux distros for WSL now available in the Windows Store – Windows Command Line Tools For Developers

WSLのディストリビューションにUbuntuに続き、SUSEが追加されました。しかもSUSEはOpen SUSE Leap 42とSUSE Enterprise 12両方です。

Windows Storeよりインストールします。インストールにはWindows 10 Insider Preview #16215以上が必要で、且つそれらでWindows Subsystem for Linux(WSL)をインストールしておく必要があります。

Ubuntuとの共存も可能です。残りはFedoraという事になります。

追記(2017/07/23 19:43)

openSUSE Leap 42をGUIアイコンでなく、コマンドラインより起動する場合にはコマンドラインより、「openSUSE-42」とタイプします。

また、ディストリビューション毎の起動コマンドは以下のようにFall Creator Updateより追加される「wslconfig」コマンドで確認することが出来ます。

LegacyはFall Creators Update(RS3)前までのubuntuのディストリビューションなので、「lxrun /uninstall」コマンドにて削除してしまった方が良いです。(私の環境で残してしまっていた)

また、(規程)となっているディストリビューションが、「bash」コマンドで起動されるディストリビューションとなり、変更は「wslconfig /setdefault」コマンドにより行います。

Windows Subsystem for Linuxの仕様にあたり、開発者モードの設定が不要に

情報源: Developer Mode no longer required for Windows Subsystem for Linux – Windows Command Line Tools For Developers

Windows 10 Insider Preview Build 16215よりWSLの仕様に当たって開発者モードの設定をする必要がなくなります。

これは、開発中の不安定な機能を使用するものだったため、非技術ユーザーを保護する目的で設置されていましたが、昨年からの二つの大きな更新でMSとして自信が持てたので、このツールセットを多くのユーザーが利用できるよう、開発者モードの設定無しで使えるようにするということのようです。

このため、今後WSL自体の機能をWindowsに追加するには、Windowsの機能にて「Windows Subsystem for Linux(Beta)」を選択するだけです。

Windows 10 SでWSLは動くのか?

情報源: Will Linux distros run on Windows 10 S? – Windows Command Line Tools For Developers

教育分野用のWindows 10のエディションとして、Windows Sが先頃発表されました。このWindows SはWindowsストア経由でのアプリケーションのインストールが行えませんし、ストア経由でインストールしかアプリケーションを実行できません。また、先のBuild 2017ではWSLのユーザーランドがUbuntuだけでなくSUSE, Fedoraが追加され、それがストア経由で選択してインストール出来るようになることが発表されました。

そこで、誰もが疑問に思うのがそれだったらWindows SでWSLが動くんじゃ無いかって事です。

答えはNO

理由はWSLが前提としているデスクトップブリッジが広範な権限を必要とするため、Windows Sでは動かないから。記事では同様な理由でWindows Sは開発者向けではないとしています。

Surface LaptopのようなWindows SがプリインストールされたPCを入手した場合には、Pro等へのアップグレードが必要となります。

File System Improvements to the Windows Subsystem for Linux

This is part of a series of blog posts on the Windows Subsystem for Linux (WSL). For background information you may want to read the architectural overview , introduction to pico processes , WSL system calls , and WSL file system blog posts.

情報源: File System Improvements to the Windows Subsystem for Linux

WSLでWindowsのファイルシステムをマウントし、差分を吸収する仕組みがDrvFsだが、mountコマンドでDrvFsを使用するための解説。SMBなシェアフォルダもマウントできるようです。

Windows Subsystem for Linuxでのシリアルポートサポート

情報源: Serial Support on the Windows Subsystem for Linux – Windows Subsystem for Linux

Windows 10 Insider Previewの最新ビルドで、WSL上からのCOMポート使用がサポートされたようです。これでTTYが必要なアプリケーションも動作させれるようになったほか、VT-100とかつなげられますね:P

仕組み的には以下の図のようになっているようです。

Lxcore.sys内部に持つttyS.libがWindowsのCOMポートを中継する黒魔術です。

WSLではWindowsのCOM1がLinuxの/dev/ttyS1にCOM2が/dev/ttyS2と言うようにマップされます。WSLから使用する際のCOMポートのボーレート、ストップビット、フロー制御などについてはデバイスマネージャもしくはレジストリにより設定するようです。

MSではWSL上からラズベリーPiのシリアルポートに対して、以下のシナリオで動作のテストをしているようです。

  • Hyper-V virtual COM port
  • FTDI USB to serial converter
  • Prolific USB to serial converter
  • Physical COM port

まぁターミナル繋ぐのは今となってはネタですが、シリアル接続が必要なデバイスはそれなりに今もあるので、そのようなデバイスのプログラミングやデバッグをするのには良いかもしれませんね。

Windows 10 Creators Update: Bash/WSL & Windows Consoleの新しい点

雑に要約しました。

情報源: Windows 10 Creators Update: What’s new in Bash/WSL & Windows Console – Windows Command Line Tools For Developers

Windowsクリエーターズアップデートでは、WSL, コンソールアプリケーションがアップデートされています。

WSLの新機能

互換性の向上

クリエーターズアップデートではLinuxシステムコールインターフェイス(CSI)との互換性が改善されました。

これにより、各種開発ツール、言語処理系、テキストエディタ、RDBMS等が期待通りに動作します。

詳細については情報源の記事を確認ください。

Linuxとの互換テストについては、以下の記事になっています。

Testing the Windows Subsystem for Linux – Windows Subsystem for Linux

Ubuntu 16.04のサポート

Ubuntuが16.04へアップデートされました。

Win10 AUからWin 10 CUへアップデートした場合、自動的にUbuntu 14.04から16.04へのアップデートは行われないので、管理者権限のあるコマンドプロンプトで、以下の要領でWSLのアンインストールとインストールを行います。

既存の環境を余り壊したくない場合には以下の要領でインプレースアップデートが可能です。

Ubuntuのバージョン確認は以下の要領で行います。

ifconfig, ネットワーク接続列挙のサポート

Win10 AUではネットワーク接続列挙の機能が不足していたため、ifconfig、gulp、npmのようなツールが正しく動作しませんでしたが、Win10 CUではこの部分が改善されました。

pingとICMPのサポート

Win10 AUでは管理者権限がないとpingが出来ませんでしたが改善されました。

ファイル変更通知のサポート(INOTIFY)

Win10 AUでの不満点にINOTIFYの非サポートがありましたが、これも改善されました。

Windows, Linuxの相互運用

WSLのコンソールからWindowsアプリケーションの呼び出し、WindowsのコンソールからWSL上のLinuxアプリケーションを呼び出しができ、それだけで無く、パイプ、リダイレクトで接続することができます。

WindowsからLinuxコマンドを呼び出す場合、…\System32\Bash.exe経由で呼び出すので、Git for WindowsやCygwinでその他のbashにpathを通している場合には注意してください。

UNIXとNetlinkソケットの改善

Win10 AUではUnixソケットとNetlinkソケットの一部機能がサポートされていませんでしたが、改善され、多くのツールが動作するようになりました。詳しくは以下のリリースノートを確認ください。

https://msdn.microsoft.com/en-us/commandline/wsl/release_notes

TCPソケットとIPV6の改善

TCPソケットとネットワーク周りが改善され、様々なネットワークソケット機能、IPV6の使用が可能になりました。詳しくは以下のリリースノートを確認ください。

https://msdn.microsoft.com/en-us/commandline/wsl/release_notes

Windowsコンソールとコマンドラインの改善

Windowsコンソールは非常に長い歴史がありますが、長い間ほとんど顧みられること無く、機能改善はされないままで、それ故に多くのサードパーティが登場することになりましたが、長い間ユーザーの不満点として残っていました。

ところが、MSがOSSに配慮するようになって、要約その不満点を理解したのか、2年前よりWindowsコンソールチームがが出来、コンソールのオーバーホールが行われています。

多くのVTシーケンスの改善

以前のWindowsのコンソールは不十分なANSIシーケンスのサポートで有名でしたが、もはやそれは過去のものとなりました。

Win10 AUのコンソールではほとんど一般的なANSI, VTシーケンスがサポートされましたが、いくつかの高度な機能が欠落していました。Win10 CUではさらにVTシーケンスのサポートが改良され、いくつかの高度なVTシーケンスを正しく処理できるようになり、vim、emacs、Midnight Commander、tmux、htopなどの多くのリッチテキストUI機能をコンソールに表示できるようになりました。

24ビットカラーのサポート

コンソールで24ビットカラーがサポートされるようになりました。

マウスのサポート

コンソールでマウスがサポートされるようになりました。

Windowsのシンボリックリンクで管理者権限が不要に

Win10 CUで開発者モードをONにした場合、管理者権限無しでシンボリックリンクの作成が可能になりました。

これについては次の記事を参考にしてください。

https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#lHydFmMHvUPDUtk0.97

What’s Next?

Win10 CUにおいてもWSLはベータ版です。

Windows 10 Insider PreviewのFastリングに登録して、新しい追加機能を試すとともにフィードバックをして欲しいとのこと。