れんとう

まいにち なにか ひとつ

秋葉原回顧録 第1回 Flip-Flap

21世紀もあともう少しで四半世紀が経とうとしている。
2000年になったのはついこの前のことと思っていたのに、時の流れは早いものだ。
そんな四半世紀を秋葉原PCショップの栄枯盛衰と共に思い出語りをしてみる。

その1回目で取り上げるのは、「Flip-Flap」だ。

小さい頃から、NECのパーソナルコンピュータを見て育った。
父親が新しい物好きだったからだ。
完全な「趣味」として、PC6001、PC8001、PC8801、PC9801と歴代のNEC製品を買い替えながら使っていた。

「パソコンなら自分でプログラムを打ち込めば、ゲームしたい放題なんだぞ?」と父親にそそのかされて、ベーマガのプログラムリストを打ち込まされたりしたものである。

そんな幼少時代を過ごしたから、「パソコンとはNECの製品であり、メーカー製品を買うもの」という刷り込みがされていた。しかし、大人になって、自分のパソコンを欲しくなって知るのである。

「AT互換機」というものがあり、それは、自由に組み立てることができる、ということを。

「AT互換機はPCパーツが規格化されていて、自分の好みでパーツを組み合わせることができる!」

AT互換機の存在を知ってから、もう、寝ても覚めても頭の中のことはパソコンでいっぱいだ。
まだ、ネット接続は、アナログモデムに28.8kbps、AkibaPCHotlineのサイトも立ち上がったばかりだったろうか?
Google2ちゃんねるもまだ存在していない、それが、1990年代後半。
地方在住者としては、昼間はせっせと雑誌を読み込み、パーツの構成をメモ用紙に書き出して、テレホタイムになったら、せっせとネットにつなぎ、秋葉原のPCショップのサイトを見ながら、値段を調べる、そんな日々を過ごしていた。
少しずつ貯めたバイト代を握りしめて、秋葉原に降り立つ日を夢見て。

秋葉原の電気街に初上陸したのは、1996年だったろうか?
実家への帰省のついでに寄ったと記憶している。
目的は、PCに内蔵するHDDを買うためだった。
今のように、スマホで店舗を現地で調べるなんてできない時代。
プリントアウトした秋葉原MAPを握りしめて、店舗を周った。

そこでふらっと立ち寄ったのが、Flip-Flapだった。

場所は、牛丼のサンボとファミマの間、にある、雑居ビルの階段を登った先のドアを開けた先に、Flip-Flapは存在した。

店舗の広さは12畳くらい。
所狭しと並べられた、PCパーツ。
品揃えはバルク品が多く、当時の有名店である、TWOTOPT-ZONEDOSパラと比べて1〜2割くらい安かった。
その魅力にすっかり魅せられて、盆暮れ帰省の際には、必ず立ち寄る店舗の一つになった。

IDEのHDD(3GB)
・チューリップのLANボード(当時で始めた100BASE)
・MN128SOHO(当時めっちゃ流行った、ISDNルーター)
・NE2000互換のLANボード(当時のPC-UNIXで動作する定番)

などを訪れるたびに一つずつ買ったものである。

そんなこんなで年に2回の訪問を楽しみにしていたのだが…。

1999年の年末のこと。
今年もFlip-Flapに立ち寄ろうか…と思った時にネットで見かけたのが、この記事だった。

https://akiba-pc.watch.impress.co.jp/hotline/991218/etc.html#flipflap

え!そうなの!なんで!ととても驚いたことを覚えている。
なぜならば、Flip-Flapは俺にとっての良店であり、それが儲かってないはずなどないと思い込んでいたからだ。
今にして思えば、PCパーツショップの氷河期、終わりの始まりだったのだろうな。

そして、年明けに、「通販サイトできたかな?」と思ったら、それどころか、こんな感じだった。

https://akiba-pc.watch.impress.co.jp/hotline/991218/etc.html#flipflap

えええええ!なんで!と言葉もなかった。

俺の中で、秋葉原が、楽しい現実から思い出に変わっていく、歴史の始まり、それがFlip-Flapの閉店だったんだなぁ。

YAMAHAのルーターにシリアル接続するのがかっこいい

YAMAHAルーター、それは憧れの機器

2000年になったばかりの頃。
まだ、ブロードバンドもフレッツ接続も地方には来ていない。インターネット接続はアナログモデムからテレホタイムにせっせと接続したものである。
光ファイバー専用線接続サービスINS1500もあったけど、まだまだ高価だった。
128kbpsのメタル専用線サービスがお手頃値段で主流、そんな時代。
YAMAHAのRT100iをせっせと設定して接続したものである。
当時、先輩に教えられながら、TeraTermでシリアル接続して、せっせとコマンドラインからconfigを叩いていた頃も懐かしい。
そんな風に育ったためか、未だに、Webで楽々設定というのには慣れない。あんなものでお気軽設定に慣れてしまったら、ダメになる!そんな風に思っていたこともありました。
ま、今は、「Web設定って楽チンでいいね!」と思ってるけどね。
そんなわけで、YAMAHAルーターは、未だに自分の中では、基準であり憧れの機器でもある。

 

久々にいじろう!RT107e

そんなわけで、うちでもYAMAHAルーターを愛用している。

製品ページはこちら。

https://network.yamaha.com/products/routers/rt107e/index

 

今となっては古い機体で、製造終了してるし、ギガビットにも対応はしていない。けど、お家で使う分には十分でかれこれ6年くらい使っている。

これを、プロバイダーから貸与されているルーターの下に置いて使っている。
で、だ。購入後、忙しかったこともあって、必要最小限の設定をして、それからずっとそのままだったりする。
6年もたってしまったけど、ちゃんと設定したいなぁと思う。
しかも、メインとは別に、「予備」という名目で、中古品のRT107eも持っていたりする。
せっかく、VPN対応のルーターが2台もあるのだから、VPNをはってみたいと思うのは人情ですよね?

と思いったった休日の午後、意外なハマり道の始まりだった。

シリアルポート?え?今って付いてないの?

シリアルポートとかCOMポートとか、今となっては化石ですか?
手持ちのPCはWindowsノートとMac miniなんだが、どちらもシリアル9PINなんぞ付いていない。
どうすんの?という話だが、そこで出てくるのが、USBシリアル変換コネクタなるものでこんな感じ。

 

f:id:dawon2015:20180826024535j:plain

 

いろんなメーカーから出ているようだけど、手持ちのは、秋月電子さんで売ってる、Prolific社のPL2303というチップセットを使っている代物。ググってみると、ちょっと設定は面倒そうだったが、やってみたらそうでもなかった。先人の知恵に感謝!

 

Windowsでの使い方

ドライバは公式ではWindows8までの対応らしい。
Windows10では使えない!という報告もあったようだが、調べてみると、古いドライバであれば動くらしい。
秋月電子さんのサイトでv1210をダウンロードしてきて、インストールしてみた。

 

http://akizukidenshi.com/catalog/faq/goodsfaq.aspx?goods=M-02746

 

インストールしてみると、デバイスマネージャーにCOM3ポートが追加される。

 

f:id:dawon2015:20180826024817j:plain

 

ということで、早速、PuTTYを使って接続してみる。

f:id:dawon2015:20180826024836j:plain

シリアルポート:COM3
スピード:9600

この辺はお約束。

そのほかの設定も。

f:id:dawon2015:20180826024906j:plain

データ長:8
ストップビット:1

この辺もお約束。

パリティ:None
フロー制御:XON/XOFF

は自動で設定されるようだ。

で、接続してみる。

f:id:dawon2015:20180826024937j:plain

 

うん、あっさり繋がった。

 

Macでの使い方

macOSについては、ちゃんとドライバが用意されているし、HighSierraにも対応している。

http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41

ダウンロードしてインストールして、再起動。
インストールの途中で、実行許可を求められるので、そこだけ注意かな?
「システム環境設定」ー「セキュリティとプライバシー」ー「一般」で許可すればO.K.

再起動したら、USBシリアル変換コネクタを差し込むと、ttyデバイスができていることが確認できる。

 

$ ls -l /dev/tty.*

crw-rw-rw-  1 root  wheel   21,   0  8 26 00:46 /dev/tty.Bluetooth-Incoming-Port

$ ls -l /dev/tty.*

crw-rw-rw-  1 root  wheel   21,   0  8 26 00:46 /dev/tty.Bluetooth-Incoming-Port

crw-rw-rw-  1 root  wheel   21,   6  8 26 01:01 /dev/tty.usbserial

 

macOSの接続は、ターミナルから。
screenコマンドで接続してみる。

$ screen /dev/tty.usbserial 

 

RT107e Rev.8.03.46 (Mon Aug 28 13:20:54 2006)

  Copyright (c) 1994-2006 Yamaha Corporation.

  Copyright (c) 1995-2004 Jean-loup Gailly and Mark Adler.

  Copyright (c) 1998-2000 Tokyo Institute of Technology.

  Copyright (c) 2000 Japan Advanced Institute of Science and Technology, HOKURIKU.

  Copyright (c) 2002 RSA Security Inc. All rights reserved.

  Copyright (c) 1997-2004 University of Cambridge. All rights reserved.

  Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura, All rights reserved.

  Copyright (c) 1995 Tatu Ylonen , Espoo, Finland All rights reserved.

  Copyright (c) 1998-2004 The OpenSSL Project.  All rights reserved.

  Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) All rights reserved.

00:a0:de:77:6b:ca, 00:a0:de:77:6b:cb, 

Memory 32Mbytes, 2LAN

> show config 

# RT107e Rev.8.03.46 (Mon Aug 28 13:20:54 2006)

# MAC Address : 00:a0:de:77:6b:ca, 00:a0:de:77:6b:cb, 

# Memory 32Mbytes, 2LAN

# main:  RT107e ver=e0 serial=N1D120976 MAC-Address=00:a0:de:77:6b:ca MAC-Addre

ss=00:a0:de:77:6b:cb

ip lan1 address 192.168.100.1/24

dhcp service server

dhcp server rfc2131 compliant except remain-silent

dhcp scope 1 192.168.100.2-192.168.100.191/24

> 

 

よしよし、繋がった。

終了は

ctrl + K
A
y

でターミナルに戻ってくる。

よし!コンフィグだ!

こんな感じで、無事に、シリアル接続は完了!

レガシイテクノロジ感、満載だけど、これがいいんだよね!

今更シリアル?とも思うけど、マイコンとの接続とか、使い道はそれなりにあるし、いいお勉強になりました。

さて、忘れちゃったコマンドラインを思い出して、バキバキ設定していくぞっと。

 

オレオレリポジトリとlftpコマンド

オレだよオレオレ!

実家にオレオレ詐欺の電話があったらしい。

  1. 風邪ひいてるから声がいつもと違う
  2. 電話は友達のを借りた
  3. 上司と喧嘩して会社辞めることになった
  4. とにかく至急お金が欲しい

とのたまわったとか。

ちなみに、両親は、3で本気にしたようだ!

俺のことどんなキャラだと思ってんだよ!

ローカルに作ったリポジトリ、名付けて、「オレオレリポジトリ

VM、PMを合わせると、ScientificLinuxで3台、OpenBSDは2台、Windowsは…4台。

さらに、RaspberryPiについても4枚転がっているわけで。

これらが一気にアップデートでネット接続すると、ネット回線が混雑するんだよね。

時間帯をずらしたりもしたんだけど、同じデータをDLするのにトラフィック発生ももったいないな、と思ったもので、ローカルにリポジトリを作ることにした。

というか、作った。

それを「オレオレリポジトリ」と名付けている。

かれこれ3年くらい、快適に使ってる。

「オレオレリポジトリの作り方」

WindowsのWSUSもローカルに作りたいのだが、今はフリーではないようだ。

なので、まずは、Linuxなどのリポジトリをローカルに作った。

yumコマンドやaptコマンドはネット上に公開されているリポジトリのhttpやftpサイトを見に行ってるわけだから、ローカルに同じ構造のものを作ってしまえばよい。

その後、各クライアントの参照先をローカルに向ける。

サーバの構築手順はこんな感じ。

なので、とても簡単。大きなサイズのディスクがあればよい。

クライアントについては、/etc/yum.repos.d 以下の$baseと$URLをローカルに構築した先に向けて、書き換えればO.K.。

 

lftpコマンドのスクリプトもこんな感じ。

下記は、ScientificLinux7.3をとある公開ミラーから丸ごとDLする場合の例。

 

!/bin/bash
lftp -e 'mirror --delete --only-newer /pub/Linux/scientific/7.3/ /var/www/html/local/scientificlinux/7.3/ && exit' http://www.hogehoge.jp

 

www.hogehoge.jp/pub/Linux/scientific/7.3をローカルの/var/www/html/local/scientificlinux7.3にダウンロードしてる。

lftpコマンドは、ローカルとサーバーのミラーに用いられる。

--only-newerの指定で、ローカルとサーバーの比較をして、更新されたものだけ落としてくれるので、トラフィックにも負荷をかけない。

--deleteの指定で、サーバーで削除されているファイルはローカルでも削除される。

 

で、だ、快適にすごいていたのに、ある日気がついた。

あれ?7.3のDLなんか止まってない?

ゾンビってる

cronでDLスクリプト実行の開始前と開始後に

date >> ~/cron-update.log

を挟んで、実行時間がどのくらいかかるか参考にしているのだが、ログファイルを見て、気がついた。あれ?アップデートスクリプト、完了してなくない?

psコマンドで確認すると、ゾンビってる。

あれ、なんでだろ?夜間に自動実行してるから、気がつかなかった。なんでだろ?

ということで、手動実行してみた。

 

# lftp -e 'mirror --delete --only-newer /pub/Linux/scientific/7.3/ /var/www/html/local/scientificlinux/7.3/ && exit' http://www.hogehoge.jp

cd 成功、cwd=/                                                

x86_64/release-notes: Getting files information (100%) [応答を待っています...

 

x86_64/release-notes というディレクトリのDLでどうやら引っかかっているようだ。

ブラウザで確認するとただのhtmlファイルなのでが、なぜか引っかかる。

逆に、ここはアップデートとはあまり関係ないところだ。

ちなみに、wgetコマンドで落とせたので、ここはwgetで対応すればいいや。

よし、x86_64/relese-notesを除けばいいのだな。でもどうやるんだろ?

 

-xオプションで解決だ!

man lftpしたら、マニュアル入ってなかったので、公式サイトを見に行ってみた。

LFTP - sophisticated file transfer program

PDF版のマニュアルゲット!

それを見ると、-xオプションについて書かれていた。

 

−x RX, −−exclude=RX exclude matching files

 

-xオプションでマッチングするファイルやディレクトリを除外できるようだ。

release-notesというフォルダは、他にないようなので、除外するようにスクリプトを直してみた。

 

#!/bin/bash
lftp -e 'mirror -x release-notes --delete --only-newer /pub/Linux/scientific/7.3/ /var/www/html/local/scientificlinux/7.3/ && exit' http://www.hogehoge.jp

 

実際に実行してみたら、うまくいった!

やったぜ!

 

rsyncとの違いは?

ローカルにオレオレリポジトリを作るときにrsyncコマンドも用いられることがあるようだ。どう違うのだろうとちょっとググってみた。

rsyncは、常時、サーバー間のファイルを比較して同期をとる用途のときにもちいるとよさそうだ。というかそういう用途向けらしい。

俺のオレオレリポジトリは、そこまで細かく同期をとるつもりもないので、週1くらいでDLすればいい。そういう時はlftpの方がいいみたい。

 

ということで、無事、オレオレリポジトリ、定期的に最新版に更新されるようになったよ!

WSUSも作っておきたいな。

 

乗り換えるならVisual Stdio Code

エディタなに使う?

WindowsOS XLinuxと複数の環境を使う身としては、環境ごとに違うエディタを使うのは、めんどくさい。できれば、統一したいな?と思うわけ。

で、だ。

ならなに使う?

viとかemacsならどの環境でも存在するけどさ、それもちょっとな、と思うわけ。

で、今時なら、AtomかVisual Stdio Codeかなと思うわけ。

 

Atom

Visual Studio Code - Visual Studio

 

悩んだ末、Visual Studio Codeにした。

まだ使い込んでないからわからないけど、さ。

最近のMicosoft製品って好きだしね。

それに、VisualStdioの他のエディタと共通点多いんじゃないかと思ったのでね。

ということで、あちこちの環境にインストールしているのです。

Linuxで使うには?

いろんなインストール方法があるみたいだけど、リポジトリを使って簡単にインストールすることにした。

ちなみに、openSUSEへのインストールはこんな感じ。

$ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
$ sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ntype=rpm-md\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/zypp/repos.d/vscode.repo'
$ sudo zypper refresh
$ sudo zypper install code

インストールが終わったら、コンソールから

code
と入力したら簡単に使える。
 
使ってみるとこんな感じ。
 

f:id:dawon2015:20180112000351j:plain

複数バッファの編集、デバッグコンソールやターミナルが一体化した環境。

うん、昔(ちょっとだけ)使ってたemacsに似てるね。

収斂進化ってこういうことだろうなぁ。

 

おまけ

ちなみに、サンプルプログラムはここから。

f:id:dawon2015:20180112001456j:plain

 

ブックオフで300円で購入。

え?古すぎるって?

いやいや、いいんですよ、これが。

昔の本って、アーキテクチャからちゃんと書かれていて、ほんと勉強になる。

最近の本って、盛り込むことが多いから、基礎のアーキテクチャの部分って省略されちゃうんだよね。

まずは、その、省略されている部分の記憶を呼び戻して、復習するところから始めるぞ!

 

openSUSE Leap42.3の解像度ってどうやって変えるの?

せまい

f:id:dawon2015:20180111005043j:plain

 

VMWareFusionにopenSUSE Leap 42.3を突っ込んでみた。

openSUSEのデフォルトのこの壁紙は、とても素敵だといつも思う。

が、画面がせまい!これ、解像度800x600かな?

で、設定を直そうと思ったんだけど…。

恥ずかしながら、最近のLinuxのXの設定ってよく知らない。

 

結局どこに?

f:id:dawon2015:20180111003448j:plain

 

「アプリケーションメニュー」ー「設定」ー「KDEシステム設定」

を選択。

 

f:id:dawon2015:20180111003510j:plain

 

「ディスプレイとモニタ」を選択。

ここ、画面のした〜の方にあるので、見つけるまでが大変でほげった。

 

f:id:dawon2015:20180111003908j:plain

 

あとは、解像度直すだけ。

 

かっこよくなりたい

Xの設定とかゴリゴリと書けるようならかっこいいのですけどね。

今回はGUIに頼りました。

openSUSEはデスクトップ環境としていろいろ使ってみたいところ。

 

俺の夢!WindowsからUNIXへのシームレスな接続なるか!? 〜WSLのインストール〜

かつて、仕事柄、UNIXを扱う方が多かった。
TeraTermはお友達。SSHになってからはPuTTYに乗り換え。
なので、シームレスにUNIXに接続できる環境をクライアントに作ることになる。
Cygnus(Cygwinになる前)とMIXをWindowsNTに突っ込んで、rxvtからサーバーにつないでX Windows転送をローカルへなんて、あーでもないこーでもないとやっていたのは、もう、ずいぶん昔のことになるな。
VMWarePlayerが実用的になってからは、そこにLinux突っ込んでクライアントにしてたけど、そのため「だけ」にわざわざVMを用意するのもなぁと思ってたんだよね。

もっと、シームレスにUNIXに接続できる環境を!Windowsで!とずっと思っていた。
うん、ついに、真打登場したらしい。

Windows Subsystem for Linux(WSL) 登場

そんな中で登場したのが、Windows Sybsystem for Linux、略してWSL。
前からβ版で提供されていたけれど、「Windows 10 Fall Creators Update」から正式版になった。
Linux互換のカーネルインターフェースの上でLinuxのソフトウェアを動かすという形LのLinux環境で、ストアアプリとして提供される。
この互換カーネルは、Linuxカーネルのコードは含んでいないらしく、あくまでも「互換」。なので、互換カーネルが提供していないサービスコールを呼び出すソフトウェアは動かないらしい。だが、そんな特殊なソフトウェアは、パッと思いつかない。うん、つまり、自分で使う分には十分に実用的だろうな、と思った。

ということで、導入してみることにした。

 

Windows10のアップデートから


WSLを使用するためには、「Windows 10 Fall Creators Update」の適用が必要になるので、WindowsUpdateを忘れずに。

「開発者モード」の設定と「Windowsの機能の有効化または無効化」
あちこちの記事を読むと「Fall Creators Updateの適用後は、開発者モードでなくてもWSLが使える」というようなこと見かけるけど、うちの環境では、開発者モードをオンにしないとインストールできなかった。どっちにせよ、開発者モードで使って問題ないので深く考えずにオンにする←謎理論一歩前のダメ発言。
この章は飛ばし読みして、うまく起動しなかったら、戻ってくるといいと思うよ?

 

まずは、「開発者モード」の設定から。

 

f:id:dawon2015:20180107210954j:plain

「設定」ー「更新とセキュリティ」を選択。

 

f:id:dawon2015:20180107211049j:plain

①最新状態=Fall Creators Upate」であることはチラ見する。
②「開発者向け」をクリック。

 

f:id:dawon2015:20180107211129j:plain

「開発者モード」にチェックがついてなかったら、チェックしよう。

 

f:id:dawon2015:20180107211155j:plain

なんか脅迫されるが、黙って、「はい」。

 

f:id:dawon2015:20180107211221j:plain

有効になると、「開発者モード」にチェックがつく。

 

次は、「Windowsの機能の有効化または無効化」でWSLを有効にする。

 

f:id:dawon2015:20180107211404j:plain

「設定」ー「アプリ」を選択。

 

f:id:dawon2015:20180107211430j:plain

下の方にスクロールしていくと、「関連設定 プログラムと機能」があるので、クリックする。

 

f:id:dawon2015:20180107211502j:plain

Windowsの機能の有効化または無効化」をクリックする。

 

f:id:dawon2015:20180107211521j:plain

Windows Subsystem for Linux」にチェックを入れる。

 

f:id:dawon2015:20180107211554j:plain

これで作業完了!再起動したら、いよいよ、WSLをイストールするよ!

 

アプリストアからダウンロード

 

インストールは、「ストア」からダウンロードするだけ。

 

f:id:dawon2015:20180107211637j:plain

まずは、ストアを起動する。検索ボックスに「Linux」と入力すると、「WindowsLinux を実行する」という文字が見えるね。
そこをダブルクリックしてみる。

 

f:id:dawon2015:20180107211716j:plain

インストールできるディストリビューションが出てくる。
このインストール作業をしたのは、2017.12.09、今確認した(2018.01.07)けど、変わらないね。
UbuntuopenSUSE Leap42、SUSE Linux Enterprise Serverの3つ。
Fedoraは謳い文句に名前はあるものの、リストにはのって来ないね。
今回は、openSUSE Leapを選択してみる。なぜかって?openSUSE LeapはVM切って普段使いしてるから親しみがあるの。RedHat系だから馴染みがあるしね(YaSTとかちょっと特殊ではあるけど)。
ディストリビューションごとのウンチクは、また後ほど。

 

f:id:dawon2015:20180107211810j:plain

「入手」をクリックでインストールは簡単に始まる。
あとは、待つだけ。

待ってる間に、せっかくだから、説明文でも訳してみますかね。

 

f:id:dawon2015:20180107211832j:plain

openSUSEは、安定していて、簡単に使えて、全ての用途に適したLinuxディストリビューションである。

openSUSE 42を起動するには、コマンドラインから"opensuse-42"と入力するか、Windows10のスタートメニューからopenSUSE42のタイルをクリックする。

ユーザーと開発者がデスクトップまたはサーバーで使用すること意図している。それは、ビギナー、経験のあるユーザー、スーパーハカーにとって素晴らしいことだ!一言でまとめると、完璧!だ!最新リリースであるopenSUSE Leap 42.2の特徴は、大量の便利なサーバーアプリケーションとユーザーアプリケーションが改良されて、新しくなったことだ。1,000以上のオープンソースアプリケーションが含まれている。

openSUSEもまた、SUSE Linux Enterprise製品をベースにしている。openSUSE Leap 42.1はSLE(SUSE Linux Enterprise)をベースにしており、Leap 42.2のソースコードの多くは、SLE 12のサービスパック2をベースにしている。NVIDIMM、OmniPATH、OpenVSwitch(Data Plane Development Kit)のような新しいテクノロジーはバックポートされている。XENはもはや専用のカーネルを必要とし、デフォルトカーネルでサポートされている。SLEのコードベースであるため、openSUSE Leap 42.2はパッケージ、メンテナンス、バグフィックスも、openSUSEコミュニティとSUSEのエンジニアが協力している。
leap42シリーズは、42.1のリリースから、少なくとも36ヶ月のメンテナンスとセキュリティアップデートを提供を達成している。

より多くのことを学びたければ

https://www.opensuse.org/

コミュニティのサポートは

https://forums.opensuse.org/forumdisplay.php/667-Get-Technical-Help-Here

ちなみに、和訳の正確度については保証しません!(雰囲気はなんとなく掴めてるはず)

さて、インストールが終わったら起動するよ!

WSLの起動と設定

さてさて。
和訳した通り、コマンドラインかタイルから、WSLは簡単に起動できる。
ので、やってみた。

f:id:dawon2015:20180107212240j:plain

初回起動時には、
①使用するユーザー名とパスワード
②rootのパスワード
の入力が求められる。
それが終われば、あとは、Linuxコマンドプロンプトだ。

ユーザーに関しては、Windowsのユーザーをそのまま使うのでなく、WLSの内部で別管理になるようだ。

ちなみに、サンプル画面では、ユーザー名をnagaにしてパスワードも同じnagaにしたら、「違う文字にしろ!」と怒られてる。

画面が小さいなと思ったら、タイトルバーを右クリックして、プロパティから、フォントサイズやウィンドウサイズを直せるので、適宜設定すると見やすくなるね。

さてなにをしよう

Microsoftの公式サイトをいくつか眺めてみた。

blogs.msdn.microsoft.com

channel9.msdn.com

 

Windowsしか知らない人にUNIXの裾野を広げる」という意図がはっきりみてとれる。
かつて、MicrosoftUNIXを目の敵にしていた時代を思うと、変わったな、と思うね。

さて、インストールしただけじゃなくて、何かしてみたい。
なにをしようかな?

ssh-keygenについて調べてみた 〜鍵束の話の続き〜

フォーマットの違いはわかったけれど

ちょっと前のエントリにも書いた、鍵束の違いについて。

dawon2015.hatenablog.jp

なんか、自分のログを調べたら、こんなメモ書きが出たきた。

ーーーーーーーーーーーーーー
puttygenとssh-keygen -i -f key.pub >> authorized_keys

OS Xならば普通にssh-keygenコマンドで公開鍵と秘密鍵を作ればいい。

中身がBSDだから、当たり前と言えば、当たり前。

Windowsではどうする?

puttygenで秘密鍵と公開鍵を作って、公開鍵をホストへ転送。

その後、ホストで、

ssh-keygen -i -f key.pub >> authorized_keys

して、鍵束に突っ込んでやる。

cat kye.pub >> authorized_keys

だと、うまくいかない。ファイルフォーマットが違うようだ。

ーーーーーーーーーーーーーー

どうやら、3年くらい前に、同じことをやって悩んでいたようだ。

なるほどねぇ。だから、サーバーAには、OpenSSH形式とSECSH形式の両方の公開鍵が登録されていたわけだ。

たまには、真面目に、manを読む

ssh-keygenコマンドは、鍵の発行だけでなくフォーマットの変換もしてくれる、ということはメモ書きを読んでわかった。

しかし、なんも注釈がないメモ書きであるところを見ると、多分、Google大先生に、「Windows ssh-keygen」でお伺いを立てたのだろうなと、思われる。

うん、ここは、ひとつ、いい機会だから、勉強してみよう、と思った。

UNIXのよいところは、「質の良い豊富なドキュメントがコミュニティによって整備されている」ことでもあるのだけど、意外と活用できてないよね。

ということで、やってみた。

$ man ssh-keygen

 

SSH-KEYGEN(1)             BSD General Commands Manual            SSH-KEYGEN(1)

 

NAME

     ssh-keygen — authentication key generation, management and conversion

 

SYNOPSIS

     ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa | rsa1]

                [-N new_passphrase] [-C comment] [-f output_keyfile]

     ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

     ssh-keygen -i [-m key_format] [-f input_keyfile]

     ssh-keygen -e [-m key_format] [-f input_keyfile]

     ssh-keygen -y [-f input_keyfile]

     ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]

     ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]

     ssh-keygen -B [-f input_keyfile]

     ssh-keygen -D pkcs11

     ssh-keygen -F hostname [-f known_hosts_file] [-l]

     ssh-keygen -H [-f known_hosts_file]

     ssh-keygen -R hostname [-f known_hosts_file]

     ssh-keygen -r hostname [-f input_keyfile] [-g]

     ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]

     ssh-keygen -T output_file -f input_file [-v] [-a rounds] [-J num_lines]

                [-j start_line] [-K checkpt] [-W generator]

     ssh-keygen -s ca_key -I certificate_identity [-h] [-n principals]

                [-O option] [-V validity_interval] [-z serial_number] file ...

     ssh-keygen -L [-f input_keyfile]

     ssh-keygen -A

     ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]

                file ...

     ssh-keygen -Q -f krl_file file ...

書き出しが、「ssh-keygen 認証鍵の作成、管理、変換」。

ここから察するに、-i -m -f あたりオプションをみていくと良さそうだ。

-i オプションにはなんと書いてあるのだろうか?

     -i      This option will read an unencrypted private (or public) key file

             in the format specified by the -m option and print an OpenSSH

             compatible private (or public) key to stdout.  This option allows

             importing keys from other software, including several commercial

             SSH implementations.  The default import format is “RFC4716”.

このオプションは、-mオプションで明記されたフォーマットの暗号化されていない秘密(または公開)鍵ファイルを読み込み、OpenSSHと互換性のある秘密(または公開)鍵として標準出力に書き出す。このオプションは、いくつかの商用SSHを含む他のソフトウェアから鍵をインポートすることを許可している。デフォルトのインポートフォーマットは"RFC4716"である。

と書いてあるので、超訳すると「商用SSHからOpenSSHに変換するよ!-mオプションつけないならRFC4716フォーマットとして読み込むよ」ということだな。

-m オプションはなんて書いてあるのだろうか?

     -m key_format

             Specify a key format for the -i (import) or -e (export) conver‐

             sion options.  The supported key formats are: “RFC4716” (RFC

             4716/SSH2 public or private key), “PKCS8” (PEM PKCS8 public key)

             or “PEM” (PEM public key).  The default conversion format is

             “RFC4716”.

-i または -e の変換オプションのために鍵のフォーマットを明示する。サポートしているフォーマットは、RFC4716(RFC4716/SSH2 公開または秘密鍵),PKCS8(PEM PKCS8 公開鍵),PEM(PEM公開鍵)。デフォルトの変換フォーマットはRFC4716。

つまり、おいらのメモ書きでは、-m オプションを指定してないってことは、puttykeygenが生成する鍵のフォーマットは、RFC4716ということなのだろうか?

http://www.ietf.org/rfc/rfc4716.txt

うん、どうやらそうらしい。むしろ、「読み込めない!」と思っていた

---- BEGIN SSH2 PUBLIC KEY ----

---- END SSH PUBLIC KEY ----

という書式の方が、準拠なようだ。

 

-f オプションは、キーになるファイルを指定するだけ、らしい。

     -f filename

             Specifies the filename of the key file.

鍵ファイルのファイル名を明記する。

 

ちゃんと調べてみたら、意外と面白かったね。

むしろ鬼子なのは?

Windowsは鬼子、という表現をしてしまったけど、ごめんよ!puttykeygen。

むしろ、puttykeygenで出力された形式の方がRFCに準拠してる形式なんだな。

正直にいうと、「またWindows界隈だけ独自の実装しやがって」とか誤解していました。でも、違うんだね、ちゃんとしてた。

 

こういう、ことがちゃんとわかるから、ちゃんと文書を読んでみる、ということは大切なんだな、ということで。

これからも、適当な思い込みはしないで、ちゃんと文書を読んでみることにする。