株式会社アイオーアーキテクトは、オープンソースなどを活用してシステム運用を最適にご提供します。

手持ちの雑プロ等の野良gitレポジトリを整理したくて、gogsを導入してみました。レポジトリ管理であれば言わずとしれたGitHubやAWSのCode commitあたりが有名どころでしょう。が、人様にお見せできないような雑なコードをGitHubで晒すのもアレですし、gitlabあたりはさすがに大げさすぎます(メモリ4GBきっちり持ってくのはきついというか、別のサーバに割り当てたい)。そういう観点でいくとgogsはお手軽でサーバのメモリ的にも優しくていい感じです。

で、手持ちのレポジトリを放りこんでいくのですが、ブランチやタグをちまちま指定していくのはやりたくないところです。漏れも怖いですし一括でやって欲しい。

ということで軽く調べたらちゃんとありました。cloneのときに–mirrorオプションをつけて引っ張ってきます。

git clone --mirror git@XXproject.git

このときcloneしたものはbare形式になります。で、移動先にレポジトリを作っておいて、pushするときも–mirrorをつけます。

cd XXproject.git ; git push --mirror git@dst:project.git

git remote add originとかせずにそのままレポジトリを指定します。これで全部のブランチ・タグもまとめて新しいレポジトリに追加されます。

さすがgit、よくありそうなことはちゃんとあるところが素敵です。

ちなみにgogsの場合、これをGUIからやってくれる移行機能がありましたので今回はそっちで移行してしまいましたが、–mirrorつけるやり方多分どのサービスでも共通で行けると思いますのでメモ兼ねて記事にしておきます。

ここのところホットなLog4jで見つかった脆弱性ですが、Log4j バージョン2.10より前のときの対策で、「JndiLookupクラスをクラスパスから削除する」というのを見て、ぱっと直感的に「抜いて大丈夫なのかな？なんか変な挙動起こさないかな？」と疑問に思ったので軽くソースを覗いてみました。

ちなみにOTRS, OTOBOはperlとJavascriptで書かれたアプリですのでLog4J(というかJava)の脆弱性の影響は受けません。ただ、OTOBOでは検索の高速化の機能のためにElasticsearchと連携できるようになっています。ElasticsearchはJavaでLog4jも使用していますので影響を受けることになります。また、OTRSでも弊社独自で用意したElasticsearch連携のアドオンが存在しており、その関連で気になった次第です。

お断り: 軽くソースを覗いた内容ですので、その真正性はあくまでご自身でご判断ください。本記事を信じて行ったこと/行わなかったことに対するいかなる責任も負いませせん。テストは大事です。

ソースは諸々の事情から、Log4j 2.8.2を使っています。

展開してgrepすると、問題のJndiLookupはlog4j-core.jarの、org/apache/logging/log4j/core/lookup/JndiLookup.javaが該当します。同列のlookupディレクトリを見ると、AbstractLookupを筆頭にDateLookupとか、EnvironmentLookup, JavaLookup等と並んでいますので、おそらくAbstractLookupを基底クラスにしたプラグインっぽい実装になっていそうです。

JndiLookup.javaを見てみると、クラスの出だしが次の通り。

@Plugin(name = "jndi", category = StrLookup.CATEGORY)
public class JndiLookup extends AbstractLookup {

やっぱりAbstractLookupを基底にして、まんまPluginというアノテーションついていますので、扱い的にはプラグイン、と。

そうするとどこからロードしているかが気になりますのでソースに対してgrepかけてみると、テストコードやドキュメント類を除くとorg/apache/logging/log4j/core/lookup/Interpolator.javaがクラスを呼んでいます。

public Interpolator(final Map<String, String> properties) {
　　this.defaultLookup = new MapLookup(properties == null ? new HashMap<String, String>() : properties);
　　// TODO: this ought to use the PluginManager
　　lookups.put("log4j", new Log4jLookup());
　　lookups.put("sys", new SystemPropertiesLookup());
　　lookups.put("env", new EnvironmentLookup());
　　lookups.put("main", MainMapLookup.MAIN_SINGLETON);
　　lookups.put("marker", new MarkerLookup());
　　lookups.put("java", new JavaLookup());
　　// JNDI
　　try {
　　　　// [LOG4J2-703] We might be on Android
　　　　lookups.put(LOOKUP_KEY_JNDI,
　　　　Loader.newCheckedInstanceOf("org.apache.logging.log4j.core.lookup.JndiLookup", StrLookup.class));
　　} catch (final LinkageError | Exception e) {
　　　　handleError(LOOKUP_KEY_JNDI, e);
　　}
　　// JMX input args

他のLookupプラグインはともかく、JndiLookupについてはエラーハンドリングされていて、クラスが読めなかったらhandleErrorで処理しているみたいです。JavaLooupクラス等を抜いてしまうとロード時にエラーで落ちますが、このコードの書き方はない場合にはないなりに動かそうという書き方です。

handleErrorはというと、特に落ちたりせずに警告ログだけ出して終わっています。

private void handleError(final String lookupKey, final Throwable t) {
　　switch (lookupKey) {
　　case LOOKUP_KEY_JNDI:
　　　　// java.lang.VerifyError: org/apache/logging/log4j/core/lookup/JndiLookup
　　　　LOGGER.warn( // LOG4J2-1582 don't print the whole stack trace (it is just a warning...)
　　　　　　"JNDI lookup class is not available because this JRE does not support JNDI." +
　　　　　　" JNDI string lookups will not be available, continuing configuration. Ignoring " + t);
　　　　break;

ちなみに、大本のInterpolatorについてはどこから呼ばれてるかというと、何か所かありますが、org/apache/logging/log4j/core/config/AbstractConfiguration.java あたりでクラスのメンバ変数の初期化でばっちり呼ばれています。

private final StrLookup tempLookup = new Interpolator(properties);

AbstractConfigurationの名の通り、Log4Jの設定の基底クラスですから、ライブラリの初期化さえ通ってしまえばまずまず問題はなさそうです。

まとめると

• 問題を起こしているJndiLookupクラスについてはプラグインの1種として扱われている(=必須機能として扱われていない)
• もともと存在しない場合でも大丈夫なようなコードになっている
• ライブラリの初期化さえ通ってしまえば後で問題になる可能性は低い

ということで、提示されている対処通り、「JndiLookupクラスをクラスパスから削除する」という対処で問題なさそうということで個人的には納得です。

ちなみに、クラスパスを削除するといってもJndiLookup.classはlog4j-core.jarの中に入っていますので、実質jarから該当クラスを抜くという操作になります。

いくつか思いついたり探したりした中ではjarは実質zipファイルですので、

誰もがリモートで家電を操作したり、音声で動作させたりする夢の環境にしたいと思ったりすると思うので、現実の技術でどこまで出来るかを書いてみようと思う。(OTRSネタではなくて、すみません。）スマートフォンやGoogle Homeなどから家電製品を操作するためには、スマート家電コントローラが必要になる。Clova WAVEのようにスマート家電コントローラが内蔵されているものもあるが、Google HomeやAmazon Echoなどは、スマート家電コントローラを購入する必要だ。簡単にいうと、エアコン、TV、ビデオ、照明などの赤外線リモコンをこのスマート家電コントローラに記憶させて、このコントローラが代替して、命令するのだ。この設定は、どの機器もスマートフォンで実施する。お持ちのAIスピーカーと連携可否や簡単な特徴を纏めてみたので、ご参考に。(2017年12月25日現在)

Nature Remoについて

私は、スマート家電コントローラの中で反応速度が一番早いと言われる「Nature Remo」を購入してみた。発売日に予約したので、11月初旬ぐらいに納品されてきた。使ってみると、iPhoneのボタンを押して命令したり、Google Homeで命令してから、スイッチが入るまでの時間がかかることが気になる。大体2〜5秒ぐらいかかるのだろうか。リモコンだと瞬時に切り変わるので、数秒でも遅いと気になるかもしれない。あと、Nature Remoは家電から赤外線が届く範囲に置く必要があるので、私はプリンターに貼ってしまった。(ちなみに、近日中にIFTTTを介さずにGoogle Homeに直接接続出来るようになるらしいです。）

リモコンの操作登録(Nature Remo)

①iPhoneで「Remo」アプリをダウンロード

②WiFiに接続

③リモコンボタンを登録

以下の記事の通り、１つずつリモコンのボタンごとに赤外線をかざして登録します。以下のURLを参考にすると良いです。

http://www.itmedia.co.jp/pcuser/articles/1711/30/news058.html

ここまでの設定で、iPhoneで登録したリモコンの操作が出来ます。Google Homeから実行したいときは、IFTTTの設定が必要です。

IFTTTの設定

IFTTTの設定方法は、このURLを参考にすると良いです。先にNature Remoでリモコン操作の登録をしないと設定できません。IF文でGUIで動作条件を設定していく。”that”で”Nature Remo”の登録をすれば、家電を操作出来るようになります。

http://nature.global/jp/ifttt-setup/

まとめ

「電気をつけて」と音声で命令を出してから、照明が点灯するまで3〜4秒ほどかかる。リモコンで操作する方が明らかに早いけど、リモコンを探す手間を考えるとすごく便利です。スマートコントローラによって、レスポンス時間が違うようなので、最新の機器を使った方が良さそうだ。また、近日中にNature RemoからIFTTTを介さずにGoogle Assistantに命令できるようになるみたいで、今後対応済みのファームウェアにアップグレードすれば、もう少しレスポンスが早くなることが予想される。

AIスピーカーについて

本年秋ぐらいからAIスピーカーと言われる機器が注目されている。ほぼ各社の製品が出揃い、何ができるか、違いについて纏めてみた。以下の表をご覧下さい。(2017年12月18日現在)

音楽を楽しみたいならONKYOのG3 VC-GX30、風呂や台所で利用したいならソニーのLF-S50G、LINEを簡単にメッセージ送信した位ならLINEのClova wave、IoTとして家電を操作したいならGoogle HomeやAmazon Echoというように用途により選択すると良いのかもしれない。

Google Homeについて

まずは、色々と開発すれば実現出来そうなGoogle Homeについて、触ってみた。Google Homeの設定は、Google AssistantというサービスでGmailのアカウントでログインして設定する。従って、Webで設定が可能で、iPhoneやAndroidでもアプリがあるので、設定が可能です。発売日に私が購入した某量販店で「Androidがないと設定出来ません！」と言われたがそんなことはない。

音楽を再生したい時はPlay Musicと連携する設定をGoogle Assistantの設定をすることで、流行りの曲などを流すことが出来る。このGoogle Assistantの機能のみだけでは、家電操作やメール送信、Line送信などが出来ない。それを可能にするのがIFTTT（イフト）というWebサービスで、Google Homeはサポートしている。IFTTTは、各種外部サービスやIoTデバイスを連携させるプラットフォームで、「if～then」という簡易なプログラミング（レシピ）により、動作条件、アクションを定義することで、インターネット経由で動作させることが出来る。IFTTTで連携出来るWebサービスは、一部ですが次のようなものがある。

Google HomeからOTRSへメール送信

Google HomeとOTRSを連携出来ないかなと思い、簡単に出来そうなGoogle Homeへ言った内容をOTRSでチケット生成する仕組みを作ってみたので、簡単に実現方法を紹介する。

①IFTTTにログインする。

②上記の「My Applets」タブを選択し、「New Applet」を押下します。

③「this」を押下します。

④「Choose a service」で「Google Assistant」と入力して、「Google Assistant」のアイコンを押下します。

⑤「Say a simple phrase」のアイコンを押下します。

⑥次の項目を入力して「Create trigger」を押下します。

⑦「that」を押下します。

⑧「Choose a service」で「Gmail」と入力して、「Gmail」のアイコンを押下します。

⑨「Send an email」を押下します。続いて、「Finish」を押下すると設定完了です。

以上で、OTRSにメール送信されて、チケットを生成することができました。もう少し細かい設定をすれば、システム管理者が障害内容を口頭で簡単にチケットを作成したりできそうです。

次回以降で家電製品をNature Remoに登録して、Google Homeから家電製品を操作する方法をやってみようと思う。

通常の運用では、セキュリティ強化のため、公開鍵認証を利用していることが
多いかと思います。しかし、どうしても特定のアカウントのみパスワード認証
を使用したい時があったりしたことはないでしょうか？
そのような時にパスワード認証と公開鍵認証の併用する設定例を紹介します。

testuserはパスワード認証、それ以外のユーザーは公開鍵認証の設定です。

# cd /etc/ssh/
# cp -ip sshd_config sshd_config.20160513
# vi sshd_config
以下のように設定値を変更する。
---
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
PasswordAuthentication no
パスワード認証したいユーザー(testuser)の設定をする。
Match User testuser
  PasswordAuthentication yes
---

設定を反映させます。
# service sshd restart
sshd を停止中:                                             [  OK  ]
sshd を起動中:                                             [  OK  ]

これで、testuserのアカウントのみパスワード認証でssh接続が可能になります。

とある案件でWindowsでポートフォワーディングを行う必要がありましたのでやり方含めてご紹介しておきます。

OS: Windows 2008R2
やりたいこと: Windowsサーバにポート中継をさせて、特定セグメントからのアクセスを別セグメントの特定マシンへの通信に振り替えさせる

Linuxですとiptablesあたりを駆使すればそれなりに簡単にできてしまいますし、SSHポートフォワードなんて手もあります。ですが今回は相手はWindows。制約上SSHポートフォワードもNGということでなんかアプリをいれないと駄目かなぁと思って調べていたのですが、実はWindowsのみでポートフォワードすることができます。

ポートフォワードを行うにはnetshコマンドを使用します。
Windowsサーバ(192.168.50.50)の8080ポートを外部サーバ(ここでは192.168.100.100とします)のポート80に転送したい場合、コマンドプロンプトを管理者権限で起動して、以下のように入力します。(画面では2行になっていますが実際には1行で入れます)

> netsh interface portproxy add v4tov4 listenport=8080 listenaddr=192.168.50.50
connectport=80 connectaddress=192.168.100.100

これで、他のマシンからWindowsサーバ(192.168.50.50:8080)へアクセスすると、Windowsサーバ経由で外部サーバ(192.168.100.100:80)に接続できるようになります。

また、netshからはshow allで現在の状態を確認することが出来ます。

> netsh interface portproxy show all

ちなみに削除する場合にはdelete v4tov4コマンドを使用します。

> netsh interface portproxy delete v4tov4 listenport=8080

まあポート転送が必要な状況自体がネットワーク設計的にどうなのよという話があったりなかったりもしますが、既存の制約や限られた時間の中でなんとかしないといけないケースもままあります。知っておくとひょっとすると役にたつかもしれないTipsのご紹介でした。

サポートなんてやっていると、いくつも環境持つことになります。

データがろくに入っていない純粋な検証用なら鍵やアカウント共通でもいいのでしょうが、多少でもデータが入っているとさすがにそうは行きません。SSH鍵やポート、アカウント等はそれぞれ別のものとして管理することになります。

これらのパラメータを楽に管理するために簡単なスクリプトをネタに、bash補完で楽をする方法を紹介します。

まずsshのパラメータを簡単に指定できるスクリプトから。パスの通ったところにsshxという名前で配置し、実行権限をつけておきます。

#! /usr/bin/ruby

require 'json'
require 'optparse'

keydir="~/ssh-keys/"
confFile="~/ssh-keys/sshx.conf"

# confファイル読み込み
confData = ""
IO.foreach(confFile) do |line|
    confData += line
end

conf = JSON.parse(confData)

# コマンドライン解析
opt = OptionParser.new
opt.on('-L') do |v|
    conf.each_key do |k|
        desc = conf[k]["description"]
        if desc != nil then
            print "#{k}: #{desc}\n"
        else
            print "#{k}\n"
        end
    end
    exit 1
end

opt.on('-ll') do |v|
    conf.each_key do |k|
      print "#{k} "
    end
    print "\n"
    exit 0
end

opt.parse!(ARGV)

setting = conf[ARGV[0]]

if setting == nil then
    print "Invalid confname #{ARGV[0]}. Check sshx -l.\n"
    exit 1
end

cmdline = []

if setting["port"] != nil then
    cmdline << "-p" << setting["port"]
end

if setting['option'] != nil then
    cmdline << "#{setting['option']}"
end

if setting["pem"] != nil then
    cmdline << "-i" << keydir + setting["pem"]end

cmdline << "#{setting['user']}@#{setting['host']}"

exec('ssh',*cmdline)

次に設定ファイルとして、接続先一覧を記述したファイルを~/ssh-keys/sshx.confとして作成します。JSON形式です。

必要ならsshx側のパスを好みの場所に変更してください。sshの鍵(*.pem)も同じディレクトリに配置します。お約束ですがパーミッションに注意して下さい。

{
    "dev1": {
        "host" : "192.168.100.1",
        "port" : "10022",
        "user" : "user1",
        "pem"  : "dev1.pem",
        "description" : "開発環境1"
    },
    "dev2" : {
        "host" : "192.168.100.2",
        "port" : "10122",
        "user" : "user2",
        "pem"  : "dev3.pem",
        "description" : "開発環境2"
    },
    "fumidai-pf" : {
        "host" : "192.168.100.3",
        "port" : "10522",
        "user" : "dev3",
        "pem"  : "dev3.pem",
        "option" : "-L8080:localhost:80",
        "description" : "踏み台(w/PF)"
    },
    "fumidai" : {
        "host" : "192.168.100.3",
        "port" : "10522",
        "user" : "dev3",
        "pem"  : "dev3.pem",
        "description" : "踏み台"
    }
}

上記の例ですと、dev1, dev2, fumidai-pf, fumidaiをパラメータで指定するとIPやポート、鍵等を適切に選んで接続してくれます。

$ sshx dev1
dev1$

とかやっていると、今度はパラメータを一々手で入れるのが面倒くさくなってきます(苦笑)。

シェルならパラメータは補完して欲しいもの。というわけで、bashの補完機能で補完させることにします。

~/.bashrcあたりに以下を追加します。

_sshx()
{
  CAND=`sshx -ll`
  COMPREPLY=(`compgen -W"$CAND" $2`)
}
complete -F _sshx sshx

sshx -llで候補となるパラメータの一覧を表示するようにしているのがミソです。bash提供のcompgenコマンドとの組み合わせで一覧から候補を絞り込んで選択できるようになります。

上記の例ですと、sshx fで、ファイル名の補完と同様にfumidaiまで補完され、さらにを押すとそこから選択可能な一覧(例ではfumidaiとfumidai-pf)が表示されます。

今回は接続先リストを補完させましたが、一覧表示できれば色々と補完させることができます。よく使うコマンド系のパラメータを色々補完させてみるのも一興かもしれません。