2020年1月30日木曜日

SUPER BOWL LIV プレビュー

毎年のことながらあっという間に終わったNFLのレギュラーシーズン。
2019年シーズンも最後のSUPER BOWL LIVを残すのみ。
開催は目前に迫っています。
日本時間で言うと2月3日(月)の朝となります。

さて、今回の対戦カードはサンフランシスコ・49ers対カンザスシティ・チーフス。
ちなみにカンザスシティはカンザス州とミズーリ州にありますが、
チーフスはミズーリ州の方です。

閑話休題。
49ersは攻守にハイレベルではありますが特筆すべきはD#。
前戦ではパッカーズO#に何もさせませんでした。
O#もRBやWRによるランがバリエーション多く面白い。
QBはエリートというほどでもないですが要所は押さえて
試合を壊さないタイプに見えるジミー・ガロポロ。
前戦でのパスの少なさから色々言われているみたいですが、
パス偏重では結局勝てないのがNFLですから。
むしろパスに偏らざるを得ない展開、
つまりD#が崩壊してキャッチアップというのはまずいですね。
できればD#がしっかり機能してロースコアゲームに持ち込み、
ランで時間を消費するのが理想的でしょう。

一方のチーフスはQBパトリック・マホームズを中心としたO#が特徴。
QBはモバイルタイプですが典型的ではなくパスもうまい。
しかもスクランブルからのパスが。
ただしQBのワンマンチームというきらいがあり、
良くも悪くもQBのでき次第。
個人的にはあまり好きなタイプのチームではありません。
調子が良ければ得点力がものすごいので
点の取り合いは望むところでしょう。

ということで私の応援チームですが、
前述の文章から察せるとも思いますが49ersです。
49ersが勝つためにはD#が相手QBマホームズを抑えねばなりません。
パスラッシュとQBへのスパイがキーでしょうか。
チーフスの前戦の対戦相手タイタンズのような
走るQBへのタックルの失敗は大問題なので、
QBにある程度走られつつも、ロングランや
そこからのパスを封じる方向を戦略とすべきでしょう。
Q#はランを主体にして時間を使うのがいいかと。
前戦で怪我をしたRBコールマンが復帰してくれれば、
ラッキーボーイになりそうなRBモスタートと相まって
いい感じにラン展開できそうです。
あとはスペシャルプレー。
後々語り継がれそうなやつを見せてほしい。

なおSUPER BOWL LIVの試合後の感想等については、
ここで書くのはゲームから1週間後とします。
なぜって、ネタバレにならないようにするため。
結果を知ってから試合を観るのは興ざめですから。
ライブではなく録画して観る方は、
結果がネットニュースに唐突に出ていたりするので、
観るまではインターネット断ちすることをおすすめします。
普段一般ニュース系サイトでアメリカン・フットボール関連の
記事なんか見ることがない日本でも、
SUPER BOWLとなればニュースタイトルで
結果がわかってしまう悲劇も起こりがちです。
まさに余計なお世話。

2020年1月29日水曜日

052-559-2295に注意

昨日私の携帯電話にSMSが届きました。
その内容は
お支払期限を過ぎましたが、ご利用料金のご入金が確認できておりません。本日中にご連絡ください。052-559-2295
"052"は名古屋。って、みるからにあやしい。
きっと架空請求ってやつですね。
私が持っているメールアドレスは大体ドメインが特殊ですし、
携帯メールも数年前に契約を切っているので
もう十数年この手の迷惑メールを受け取ったことはないのですが、
まさかSMSにくるとは。
送信元電話番号は"01015807814265"。
"010"は国際電話のプレフィックスと思われ、
となると"1"が国番号でアメリカ、
"580"がエリアコードでオクラホマとなります。
詐欺犯はオクラホマにいるわけではなく、
Twilioみたいなサービスを
利用しているんだと推測していますが、
国際SMSの送信料金ってそんなに安くないんですけどねぇ。
詐欺犯もよくやります。

2020年1月28日火曜日

楽天ひかりのIPv6対応

先日ディスった楽天ひかり
IPv6対応については2020年6月のサービス提供開始を予定しているとの
ニュースリリースを見つけました。
これでIPv6の口を大々的に展開しているGoogle等とは
快適に通信できるようになるでしょう。
またIPoE/IPv4 over IPv6にも対応する予定とのこと。
これでIPv6対応に二の足を踏んでいるようなサービスにも、
ボトルネックとなるPPPoE終端装置を経由せず
高速にアクセスできるようになるでしょう。
ただし、IPoE/IPv4 over IPv6についてはいくつかの方式が存在し、
各サービス事業者で選択が別れていますが、
楽天ひかりがどれを採用するのかは不明です。
とはいえ、この方式になっても多くの場合
IPv4にはキャリアグレードNATが挟まり、
完全に双方向で自由なインターネット環境ではなくなるので、
自宅内サーバーの公開が難しくなります。
私としてはIPv4は現状通りPPPoEが使いたいですね。
多分大丈夫だと思いますが、強制的にPPPoEから
移行させられるようなことがないことを願います。
SANNETサービス停止に伴い、SANNET用に設置された
PPPoE終端装置が楽天ひかりに流用されることで
結果的に増強されたり、他の方がPPPoEを使わなくなることで
処理量が低下したりすると嬉しいんですけどね。

2020年1月27日月曜日

バリアフリーは遠し

先日昼間の人通りがそれほどない繁華街を
犬の散歩していたときのこと。
車椅子に乗った妙齢のご婦人が一人、
何やら歩道を行ったり来たり。
最後には横断歩道手前で後ろを向いてしまいました。
何か困っているのかと声をかけてみると、
歩道と車道の僅かな段差を乗り越えるために
大きな後輪を前にしているようでした。
おせっかいかと思いつつも車椅子を押して
横断歩道を渡ったのですが、
私には車椅子を押した経験がほとんどなく、
取扱がかなり下手くそで、
かえって迷惑をかけてしまったような気がして…

バリアフリーが叫ばれる昨今、
歩道と車道の境界に部分的に段差を減らしたようなところを
ちょくちょく目にするようになってはきましたが、
超高齢化社会を目の前にして
まだまだぜんぜんバリアフリーじゃないなと実感するのでした。
明日は我が身、体を動かし辛くなっても、
生活しやすい環境になってくれると嬉しいのですが。
まあ将来的には地方は切り捨てられざるを
得なくなるんでしょうけど。

2020年1月23日木曜日

石油給湯器の警報290

数年前から長府製作所の石油給湯器
EHKF-4560SAGHを使用しておりますが、
昨冬から頻繁に[警報290]が出ていました。
操作パネルには同時に
お買い求めの販売店に
連絡してください
と表示され給湯器の火が消えてしまいます。
電源を一旦落としてから再度入れると
何事もなかったかのように使えるのでした。

昨春になって暖かくなると警報が出なくなっていたものの
今冬寒くなるとまた頻発。
そのままにしていると発生頻度が増してきて、
風呂を沸かしている10分程の間に
何度か起こることも珍しくなくなってきました。
さらにバスルームで温水シャワーを使っているときにも
症状が発生する事態に悪化。
ただし、キッチンや洗面所でお湯を使う分には発生しません。

まあこれ、給湯器を設置した時点で予想していたことです。
最近の給湯器(石油・ガスとも)お湯を温めるのに
火だけではなく排熱も利用するようになっており、
効率は良くなるものの副作用として酸性水ができあがります。
これを中和器で中性にして排出されるのがドレン水。
給湯中、本体からドレン水がポタポタ落ちているのが確認でき、
本体外部でのドレン水の排水不良は排除できていたので、
故障しているのは中和器と推測。
そもそも中和器は消耗品です。

で、最寄りの給湯器の取扱店から中和器を購入し、
家族の者が自力で取り替えたのですが、
本体のカバーを開けて中和器にアクセスするまでに、
いろいろな物を取り外さないと行けなかったらしく、
大変だったということでした。
腕に覚えがなければ取り替え作業は
業者に依頼することをお勧めします。

ともあれ、我が家の給湯器は只今絶好調です。

2020年1月22日水曜日

最悪な楽天ひかり

私は個人的には楽天のサービスを
なるべく避けて生きているのですが、
それでも使っていたサービスが断りもなく
楽天傘下になるパターンは経験しています。
自宅からのインターネット接続において、
忖度してADSL時代から使っていたSANNETもその一つです。

そのSANNET、今年度でのサービスが全面終了されるに伴い、
本家の楽天ひかりへの強制移転を余儀なくされました。
ところがこの楽天ひかりがまさにクソ。
回線速度を測ってみたところ上りは100Mbps以上なのに
下りは1Mbps以下って…orz
数十Mbps出ていた天国から地獄に突き落とされました。
それでもAmazon Prime Videoがまともに使えているのが
よくわからないのですが、
Androidスマートフォンのアプリケーションの
アップデートなどしていると遅さが身にしみます。
ちなみに早朝などだと下りも100Mbps以上出ているので、
混雑時にPPPoE終端装置の能力が
大幅に足りていないのが明らかです。
そして仕様的に最悪なのがIPv6が使えないこと。
いやNGN網内についてはIPv6で通信可能
(ひかり電話のSIPサーバへのpingで確認)なものの、
これは外部から隔絶されており
Googleのサーバーなどにはつながりません。
それより問題なのはIPv6での自宅サーバーの公開ができません。
まさに前時代的ネットワークです。

いろいろと事情があるので簡単ではないですが、
マジでISP変更を検討したいところです。

2020年1月21日火曜日

buff/cacheの開放

先日古いPCのメモリが少なくて四苦八苦している話をしましたが、
微妙な解決手段を見つけました。
定期的に
# sync
# echo 3 > /proc/sys/vm/drop_caches
を実行することです。

Linuxでメモリの使用状況を見たいときの定番は
"free"コマンドですが、
私が注目するのはusedとfreeの項目ばかりでした。
しかしよく見るとbuff/cacheが馬鹿でかい。
これはHDDへのディスクキャッシュや
I/Oのバッファリングに使用されていると認識していますが、
そこにそんなに使うなよと。
これを減らすのが前述のコマンドです。
これでbuff/cacheがガツンと減ります。少しはマシになります。
面倒ですが今思いつく最良の手なんですよね、これが。

2020年1月20日月曜日

W62Sの日時が0月0日0時0分

年が明けてからすでに3週間ほど経ちますが、
用がなければ鞄に入れっぱなしの
通話用のガラケーau W62Sを開き、
久々にマジマジと見てびっくり!!!
日付が0月0日0時0分になって微動だにしません。
慌てて調べてみると2020年になれなかったガラケーは
少なからず存在するようです。
とりあえず音声通話・SMSの発着信はできるので
(データ通信未契約のためezwebや電子メールについては確認できず)
個人的には大した影響はありませんが、
まさかの2020年問題。
まあW62Sは2008年発売の機種なので、
10年以上も使うなんてのは想定外なんでしょうね。
私もここまで長く使うつもりはありませんでしたし。
2022年3月末のau 3G停波まであと約2年。
ぎりぎりまでこれを使うつもりです。

ところで謎なのことが一点。
発着信履歴のタイムスタンプは0月0日0時0分なのに、
SMSの方は正しい日時になっていること。
SMSは網側から日時付きで降ってくるのか?

2020年1月16日木曜日

binwalk

最近知った便利ツールbinwalk。
ファイルを解析してその中に埋め込まれたファイルを教えてくれます。
主な目的は組み込み機器のファームウェアファイルの解析みたい。
実際某社のネットワーク機器のファームウェアを取ってきて
binwalkにかけてみると…何やら色々情報が出てきます。
画像系ファイルはそのまま抜き出して何かに使えるかもしれませんが、
それがどうしたという気がしますし、
プログラム部分はそれなりのスキルがなければナンノコッチャです。
ただ専門家ならここから脆弱性を発見して
それを利用して…なんてことを考えるんでしょうね。
面倒なので私はそんなことしませんが。

ちなみにbinwalkはUbuntu 18.04なら
# apt install binwalk
でインストール可能です。

2020年1月15日水曜日

新〇〇川

同じ地域に〇〇川と新〇〇川、または旧〇〇川があると、
〇〇川(旧〇〇川)が頻繁に氾濫して困るので
治水対策で新〇〇川(〇〇川)を掘ったケースが多いですが、
私の自宅の最寄りの川にも「新」が付き、
離れたところを旧の方が蛇行しています。
調べてみると明治以降旧のほうが度々氾濫して被害をもたらしたため、
大正から昭和初期に新の方を作ったようです。
なお実は旧の方も江戸時代に掘られたもののようで、
城の守りにつかっていたそうな。だからわざと蛇行させたのかも。
とはいえ新旧ともにそれなりに現代的な護岸になっています。

さて、新の方の護岸はよく見るコンクリートブロックで
固めた斜めの護岸になっているのですが、
長年の川の作用によるのか、その上に土砂が堆積し、
そこに大きな木が生えています。
また勝手に中洲ができてそこにも大きな木が。
無機質なコンクリートより木が鬱蒼と生えいてる
現状は個人的にはより好ましいと思ってきたのですが、
ここ数年の大雨で川が増水すると、
それら木々によって流れが滞り治水にはよくありません。
またその水が引いた後には木の上に大量のゴミを残すので、
なんとかしないとまずいんじゃないかと考えてました。

って、そんなことは管理者(国土交通省)もわかっていたようで、
昨年末あたりから木の伐採と土砂の除去が始まりました。
現在は土手の内側に管理車両が通れる舗装道路のある
右岸を作業中ですが、左岸に道はありません。
工事の看板によると期間はこの年度末までみたいで、
まさか左岸はスルー?
まあ右岸だけでも随分マシにはなりますけど。

2020年1月14日火曜日

Chrome重し

最近古いPCを引っ張り出してUbuntu 18.04(64bit)を入れ、
ウェブブラウザのChromeを使ってみたのですがこれがクソ重い。
調べてみると凄まじくスワップが発生しており、
それはなぜかというとメモリが2GBしかないから。
しかもこれ以上増やせない。
とりあえず必要なさそうなデーモンを軒並み落としていって
マシにはできましたが、
そもそもOSが1GB以上使ってるみたいで、
その上Chromeもじゃぶじゃぶメモリを使ってる。

解決策として、Ubuntuを32bitにするとか、
より古いUbuntu 16.04にするとか、
あるいはLubuntuみたいな軽量なフレーバーを使うとか
あるといえばあるのですが、
都合があってできればOSは変更したくない。

ではChromeやFirefoxより軽いウェブブラウザはというと、
Slimboatは配布されているパッケージが 古いライブラリに依存していてインストール失敗。
そんな中見つけたのがsurfです。
# apt install surf
でインストールした後
# surf <URL>
でウェブサイトが開けます。
GmailやGoogle Mapも問題なく使えるので
いい選択肢ではあるのですが、
使用メモリもそれなりに多い。
Chromeが重いのはそれ自体ばかりではなく、
コンテンツの肥大化も一因なのかなと。

軽量ブラウザについてはこんな記事もあるので、
時間があるときにいろいろ試してみようかと。

2020年1月13日月曜日

VLANスイッチで疑似マルチNIC

通常1台のPC等を複数のネットワークに接続したければ、
その数だけNICを用意する必要があります。
数が多ければ複数ポート対応の拡張カードを挿したり、
USB接続のLANアダプタをタコ足にして対応することになります。
しかしNICは1つでもVLANスイッチでなんとかする方法もあります。
VLANスイッチはちょっと賢いスイッチングハブで、
タグVLANやポートVLANを利用できます。
例えばPC側でVLANを設定してそれぞれVLAN IDが異なる
7つのインターフェイスを生成しておき、
スイッチでは8ポートのうちの1つをタグVLAN設定にして
それをPCに接続し、その他のポートをポートVLAN にして、
それぞれ別のVLAN IDを振っておくと、
PCから7つのネットワークに同時接続することができます。
超便利。

VLANスイッチ側の設定は各機器の取説を見るとしても、
PCがLinuxであれば設定はほぼ共通なので
以下ではUbuntu 18.04での設定例を紹介します。
まずVLANを扱えるように以下を実行します。
# echo "8021q" >> /etc/modules
# reboot
netplan環境なら設定ファイル"/etc/netplan/net.yaml"
(ファイル名は拡張子がyamlであればなんでもいい)
を以下のようにします。
network:
  version: 2
  ethernets:
    eth0:
      addresses: ["172.16.0.1/24"]
      dhcp4: false
      dhcp6: false
  vlans:
    eth0.1:
      id: 1
      link: eth0
      dhcp4: true
      dhcp6: true
    eth0.2:
      id: 2
      link: eth0
      addresses: ["192.16.2.1/24"]
ここでは物理インターフェイス”eth0”に対し、
ID:1のインターネット回線向けと、
ID:2のローカル網向けのVLANを構築しています。
もっと複雑にする際にはルーティングテーブルも
整備する必要があるのでその点にはご注意を。

2020年1月9日木曜日

Linuxでスタティックルーティングの設定

先日の2ポートイーサネットカードとつながる話です。
2つ以上のネットワークにつながる機器で
肝になるのはルーティングの設定です。
荒っぽく設定していても直接繋がっている
ネットワークには普通につながることが多いですが、
その先のルーターを介する通信は
ちゃんとしてないとトラブることも。
通常は静的に設定することが必要になります。

せっかくなのでLinuxでの設定例を紹介します。
想定する環境は以下の通り。
  • 第1ネットワーク(インターフェイス名:eth0)はIPv4の回線(直接つながるのは"10.20.30.0/24"だがバックに"10.0.0.0/8"のイントラネットが存在)で、DHCPサーバが存在。ルータは"10.20.30.1"。
  • 第2ネットワーク(インターフェイス名:eth1)はIPv4/IPv6にてインターネットにつながる回線で、DHCPサーバが存在。ルータは"192.168.1.1"。
  • 第3ネットワーク(インターフェイス名:eth2)はIPv4の完全な単体の閉域網(172.16.0.*/24)で、DHCPサーバなし。

古き良き"/etc/network/interfaces"を設定ファイルとして使用する場合は
これの内容を以下のようにするのがいいでしょう。
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
  post-up route del -net 0.0.0.0/0 gw 10.20.30.1 eth0
  post-up route add -net 10.0.0.0/8 gw 10.20.30.1 eth0

auto eth1
iface eth1 inet dhcp
  post-up route add -net 0.0.0.0/0 gw 192.168.1.1 eth1

auto eth2
iface eth2 inet static
  address 172.16.0.1
  netmask 255.255.255.0

最近のnetplanを利用する場合には
設定ファイル"/etc/netplan/net.yaml"
(ファイル名は拡張子がyamlであればなんでもいい)
を以下のようにします。
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp6: true
    eth1:
      dhcp4: true
      dhcp6: false
      routes:
        - to: 10.0.0.0/8
          via: 10.20.30.1
    eth2:
      addresses: [172.16.0.1/24]
      dhcp4: false
      dhcp6: false
ただし、起動時にはちゃんとならなくて、あとで
# netplan apply
を実行してやらないとうまく設定できません。なんで?
あとエントリーの削除はできないようで。やはり
# route del -net 0.0.0.0/0 gw 10.20.30.1 eth1
をあとで実行する必要もあります。
融通の利かないnetplanは普及したらやだな。

2020年1月8日水曜日

Ubuntuの時刻がずれてる

つい先日からのこと。
Ubuntu(18.04) PCを起動すると時刻が実際より20分ほど遅れているのです。
NTPサーバから時刻を取ってきているはずなのに。
とりあえず論理的に近いNTPサーバを利用してみようと
ISPが運用しているものを調べ(例えばOCN)
"/etc/systemd/timesyncd.conf"ファイルで設定してみましたが
改善は見られません。

まあ[設定]アプリケーションの[詳細]-[日付と時刻]メニューで
[自動日時設定]を無効にしてから有効にすれば直るので、
面倒ですが毎回そうすることで対処していました。

その後、別件からあるタイミングでルーティングテーブルに
問題が存在する可能性があることを発見し、
それを修正すると時刻遅れも直りました。
どうも、NTPサーバと通信できないタイミングで
NTPによる時刻合わせをしようとしていた模様。
ルーティングテーブルの設定って刹那刹那で
正しくしてないとまずいんですね。

2020年1月7日火曜日

2ポートイーサネットカード

最近2ポートのイーサネットカードを購入しました。
訳あって複数の物理的なネットワークインターフェイスがほしいものの、
スリムタイプデスクトップで2枚挿すのは空きスロット的に厳しく、
とはいえUSBアダプタタイプはあまり使いたくない。
ということでやむなく新たに入手したのですが、
考えていたより安価にRTL8111Gの2個搭載ボードが入手できました。
Ubuntu 18.04に挿してみたところ、
なんの苦労もなくenp4s0とenp5s0として認識されました。
さすが安定の(?)Realtekチップです。

ところでこの拡張カード、LANポートの横あたりに
電話マークに☓が付いたマークが刻印されており
やけにモデムじゃないことを強調しています。
なるほど、RJ系ポートが2つ並んでいる様子は
いかにも古のアナログモデムっぽく、
しかも多分アナログ電話のモジュラージャックも挿せる。
そして間違えて挿してしまうと電圧的にまずい。
私の環境では多分ありえませんが、
一応頭の片隅においておくことにします。

2020年1月6日月曜日

NISA口座から特定口座へ

NISA制度が始まってから早数年。
NISAでは最長投資期間が5年に設定されているため、
売却せぬまま期限を迎えるとロールオーバーするか
通常の口座に移動させるかを選択することになります。
一昨年分は全てロールオーバーしましたが、
昨年分は一部のみロールオーバーし、
他は特定口座へと移しました。
この移した分がどう表現されているか
以前から興味があったので調べてみました。
なお対象はSBI証券の国内株式です。

ロールオーバーしていないと、
年末(大納会後)の時価で購入した体裁で
特定口座に移されると聞いていましたが、
[買付日]は2018年12月31日や2020年1月1日ではなく、
本当にそれを購入した日のままになっています。
実際の購入価格である[参考単価]もその当時のままですが、
[取得単価]は時価になっているようです。
ある銘柄を何回かに分けて購入していると
[取得単価]は通常[参考単価]の加重平均になりますが、
NISAから移した分があるとこれらは一致せず、
これら評価額の差額が隠れた(非課税対象分の)利益、
または損失となります。
ぱっと見て全含み益(損)がわからないのは
いいとは言えないものの、特定口座に非課税分の
数字が混じっている方が余計悪いので仕方ないですね。
ともかく、隠れ損益があることだけは覚えておかないと。

2020年1月2日木曜日

ハリポタGOを6ヶ月

プレーし始めてから6ヶ月になる[ハリー・ポッター:魔法同盟]。
現在レベル25。XPはレベルで表すと25.75ぐらいです。
この1ヶ月でちょうど1つ分上がった勘定です。
この年末年始にかけてイベントもありますが、
達成できそうもないタスクがあるのでガン無視してます。
まあ特にいいものがもらえる訳ではないので。

2020年1月1日水曜日

GoPro購入

消費税増税を翌月に控えた昨年9月、
写真のプリントのためにカメラ屋に行ったときのこと、
GoProが売られているのが目に止まりました。
テレビ番組のロケなんかでも大々的に使われている
アクションカメラです。一瞬買おうかと思ったものの、
冷静にその用途を考えた結果踏みとどまりました。

しかし昨年末に岡山国際サーキットを試走できるとなった時、
GoProで撮影したら面白いんじゃないかと思い立ち、
結局購入してしまいました。
どれを買おうか散々迷いはしましたが、
今後海外旅行したときにも使えるかなとか思いつつ、
また末永く利用できるようにとGoPro HERO7 Blackを選択。
実際にはデュアルバッテリーチャージャー付属の セット品を購入しました。
ビデオモードで大きく異なりますが、
バッテリーでの撮影時間は30分〜90分とそんなに長くないので
旅行時の撮影に使うなら予備バッテリーは必要ですし、
限られた時間で充電する際に2つ同時というのも心強い。
まあバッテリーは本体だけでも充電可能なので、
将来的に2個めの予備バッテリーを準備すると完璧かも。
その他にはmicroSDカード(128GB/Class10/UHS-I U3)も購入。
特に問題なくこれに録画できています。

このGoPro、とりあえず撮影するだけなら
タッチアンドトライでなんとかなりますが、
なかなかの高機能製品で操作も複雑ですし、
そもそもパッケージから出すのに手間取る、
あるいは最悪壊してしまう可能性もあるので、
実物を手に取る前にマニュアル
一通り目を通しておくことを強くお勧めします。

さて、今回私はネット通販内のGoPro公式ストアで購入したのですが、
後日公式ストアからメールが届きました。
それには以下のURLが紹介されていました。

撮影した動画等はスマートフォンやデジカメと同様に、
GoProとPCをUSBケーブルで接続して
ファイルのコピーなどすればいいのですが、
iPhoneに対するiTunesのような
管理ツール(Windows/Mac)が用意されています。
こちらを使うのがいいでしょう。

実際に使ってみてどうこうという話はまた改めて書くつもりです。
今回はここまで。