2019年1月30日水曜日

今更ながらStackEditを使って、Bloggerの記事をMarkdown記法で書いてみた

今更ながらMarkdown記法というものを知る機会があり、本ブログもMarkdown記法で書いていきたいと思うようになった。本ブログはBloggerで作成しており、そのままでは直接Markdown記法による記事投稿はできないので、一度Markdown記法に対応したエディターでHTMLを作成し、それを貼りつけることで対応するようにした。

StackEditを使う

 Markdown記法に対応したエディターとして、StackEditを使うことにした。StackEditはWeb上でMarkdown記法を書きつつ、プレビューも同時に表示できる。


データはGoogleドライブ上に保存されるので、メモツールとして利用する場合でも非常に有用だ。

Bloggerのテーマを編集して見出しタグ修正する

Bloggerの見出し設定は以下になっていることがわかった。
見出しタグ 適用箇所
h1 ブログタイトル
h2 日付・ウィジェットタイトル・記事内の見出し1
h3 記事タイトル・記事内の見出し2
h4 コメント
h5 未使用
h6 未使用
h1タグはページのタイトルとなるので、ブログタイトルとなっていることは問題ないが、h2タグ、h3タグには以下問題がある。
  • 記事タイトルがh2タグではなく、なぜかh3タグ
  • h2タグが日付・ウィジェットタイトル・記事見出し1など複数で設定されており、特に「日付」といったタイトルにすべきではない項目がh2タグで設定されている
理想は見出しタグを以下のように変更したい。
見出しタグ 適用箇所
h1 ブログタイトル
h2 記事タイトル
h3 記事見出し1
h4 記事見出し2
h5 未使用
h6 未使用
上記が理想ではあるが、変更箇所が多岐にわたるため、まずは以下のようにBloggerのテーマを編集することにした。最低限、「日付」を見出しとして扱わないよう変更する。
見出しタグ 適用箇所
h1 ブログタイトル
h2 ウィジェットタイトル・記事見出し1
h3 記事タイトル・記事見出し2
h4 コメント
h5 未使用
h6 未使用
CSSの修正箇所は以下の通り。
# 353行付近
h2.date-header {
  font: $(date.header.font);
}
   .date-header {
  font: $(date.header.font);
}
HTMLの修正箇所は以下の通り。
# 996行付近
<h2 class='date-header'><span><data:post.dateHeader/></span></h2>
# 1350行付近
<h2 class='date-header'><span><data:post.dateHeader/></span></h2>
   ↓
<div class='date-header'><span><data:post.dateHeader/></span></div>

BloggerのCSSを追加して見やすくする

今まであまりこだわってはいなかったのだが、記事の見やすさを向上させるため、見出しタグや、コード表示のためのpreタグのCSSを修正することにすることにした。

見出しのデザインはCSSのコピペだけ!おしゃれな見出しのデザイン例まとめ68選が非常に参考になった。

上記URLのデザインを参考にしつつ、本ブログでは以下の通りCSSを追加した。
h2 {
font-size: medium;
margin-top: 1.5em;
margin-bottom: 0.5em;
padding: 0.3em;
color: #494949;
background: #f4f4f4;
border-left: solid 5px #249fa3;
border-bottom: solid 3px #d7d7d7;
}

h3 {
margin-top: 1.5em;
margin-bottom: 0.5em;
padding: 0.3em 0em;
border-bottom: solid 3px #249fa3;
}

pre {
background: #e2f1ea;
border: dashed 1px #249fa3;
margin: 1em 0em;
}

table, td, th {
border: solid 1px #249fa3;
border-collapse: collapse;
margin: 1em 0em;
}

th {
background: #e2f1ea;
}
Bloggerのテーマの編集からCSSの追加はできるが、CSSが二重で設定されたりするので、「HTMLの編集」にて追加した。

StackEditで作成したHTMLをBloggerに貼る

StackEditの「Export to disk」→「Export as HTML」を選択し、「Plain HTML」を選んだ後、「Copy」ボタンを押すと、HTMLがクリップボードにコピーされる。これをBloggerの記事のHTMLとして貼りつけてやればよい。


画像はStackEditではなくBlogger側で管理させたいため、HTMLを貼りつけた後、必要な個所に画像を挿入する手法をとっている。

また、Bloggerの仕様により段落を表すpタグが消えるようなので、<br />を適宜挿入し、文章の整形をしている。
2019年1月23日水曜日

VyOSでステートフルフェイルオーバー(conntrack-sync)をできるようにした話

以前、VyOSを冗長化するために、VRRPによる冗長化を記事にした。
VRRPだけでも障害時は数秒で切り替わることが確認できており、特に動作に不満はないのだが、VyOSではTCPやUDPのコネクション情報をフェイルオーバー時に引き継ぐ「ステートフルフェイルオーバー」という機能が実装できることを知った。これはVyOSでは「conntrack-sync」と呼ばれる機能となる。本記事では、VyOSでのconntrack-syncの設定を行い、動作確認をしてみた。

環境

環境は以下の通りとなる。利用しているVyOSのバージョンは1.1.8となる。


VRRPの設定

VyOSでVRRPを実装する方法は、以下の過去記事に記載しており、本記事ではVyOS2台でVRRPの構成が組まれていることが前提となる。

conntrack-syncを設定する

設定は2台のVyOS両方に対し、同じコマンドで設定する。

VyOS#1設定

まずはVyOS#1の設定をコメント付きで記載する。
vyos@t3033vyos# set service conntrack-sync accept-protocol 'tcp,udp,icmp'
→★conntrack-syncで同期するプロトコルとしてTCP/UDP/ICMPを設定
vyos@t3033vyos# set service conntrack-sync failover-mechanism vrrp sync-group syncgrp01
→★フェイルオーバーのタイプをVRRPに設定
vyos@t3033vyos# set service conntrack-sync interface eth1
→★情報同期に利用するインタフェースを指定

vyos@t3033vyos# compare
[edit service]
+conntrack-sync {
+    accept-protocol tcp,udp,icmp
+    event-listen-queue-size 8
+    failover-mechanism {
+        vrrp {
+            sync-group syncgrp01
+        }
+    }
+    interface eth1
+    mcast-group 225.0.0.50
+    sync-queue-size 1
+}
vyos@t3033vyos# commit
vyos@t3033vyos# save

VyOS#2設定

続いてVyOS#2の設定となるが、コマンドは完全に同一となる。
vyos@t3032vyos# set service conntrack-sync accept-protocol 'tcp,udp,icmp'
vyos@t3032vyos# set service conntrack-sync failover-mechanism vrrp sync-group syncgrp01
vyos@t3032vyos# set service conntrack-sync interface eth1
vyos@t3032vyos# compare
[edit service]
+conntrack-sync {
+    accept-protocol tcp,udp,icmp
+    event-listen-queue-size 8
+    failover-mechanism {
+        vrrp {
+            sync-group syncgrp01
+        }
+    }
+    interface eth1
+    mcast-group 225.0.0.50
+    sync-queue-size 1
+}
vyos@t3032vyos# commit
vyos@t3032vyos# save

動作確認

conntrack-syncのステータスを確認

設定が完了したら、conntrack-syncのステータスを確認する。VyOS#1がMaster、VyOS#2がStandbyになっている。
  • VyOS#1
vyos@t3033vyos:~$ show conntrack-sync status
sync-interface        : eth1
failover-mechanism    : vrrp [sync-group syncgrp01]
last state transition : MASTER at Sun Jan 20 06:11:04 JST 2019
ExpectationSync       : disabled
  • VyOS#2
vyos@t3032vyos:~$ show conntrack-sync status
sync-interface        : eth1
failover-mechanism    : vrrp [sync-group syncgrp01]
last state transition : BACKUP at Sun Jan 20 06:13:05 JST 2019
ExpectationSync       : disabled

保持しているコネクション情報を確認

conntrack-syncでは、2つのコネクション情報を管理している。
  1. 自身のもつコネクション情報(Internal Cache)
  2. 対向ルーターが持つコネクション情報(External Cache)
簡単に図に書くと以下の通りとなる。各ルーターはExternal Cacheとして対向ルーターのコネクション情報を同期しており、対向ルーター障害時に、即座に引き継げる。
VyOS#1VyOS#2マルチキャスト(225.0.0.50)でInternal Cacheを送信受信したCacheをExternal Cacheとして保持マルチキャスト(225.0.0.50)でInternal Cacheを送信受信したCacheをExternal Cacheとして保持VyOS#1VyOS#2
実際にコマンドで確認してみよう。実行タイミングで随時変更が入るため完全に同一とならないが、2台のルーター間で「cache internal」と「cache external」がほぼ同数となっていることがわかる。
  • VyOS#1
vyos@t3033vyos:~$ show conntrack-sync statistics
Main Table Statistics:

cache internal:
current active connections:              128
connections created:                  138830    failed:            0
connections updated:                  431529    failed:            0
connections destroyed:                138702    failed:            0

cache external:
current active connections:               19
connections created:                   77975    failed:            0
connections updated:                    4198    failed:            0
connections destroyed:                 77956    failed:            0

traffic processed:
                   0 Bytes                         0 Pckts

multicast traffic (active device=eth1):
            39144744 Bytes sent              7447944 Bytes recv
              546040 Pckts sent               116175 Pckts recv
                   0 Error send                    0 Error recv

message tracking:
                   0 Malformed msgs                  537 Lost msgs

  • VyOS#2
yos@t3032vyos:~$ show conntrack-sync statistics
Main Table Statistics:

cache internal:
current active connections:               12
connections created:                   83300    failed:            0
connections updated:                    6895    failed:            0
connections destroyed:                 83288    failed:            0

cache external:
current active connections:              128
connections created:                  167162    failed:            0
connections updated:                  349591    failed:            0
connections destroyed:                167034    failed:            0

traffic processed:
                   0 Bytes                         0 Pckts

multicast traffic (active device=eth1):
             7474996 Bytes sent             38942708 Bytes recv
              116529 Pckts sent               543314 Pckts recv
                   0 Error send                    0 Error recv

message tracking:
                   0 Malformed msgs                 2418 Lost msgs

フェイルオーバー時の動作を確認する

VyOS#1を停止させ、VRRPがフェイルオーバーした際のconntrack-syncの動作確認を行う。
まずは、VyOS#2にて、VRRPの状態確認を行う。MASTERになっている。
vyos@t3032vyos:~$ show vrrp
                                 RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
---------         -----  -----   ---------  -----  ----------  -----
eth0              10     MASTER  no         no     4s          syncgrp01
eth1              10     MASTER  no         no     4s          syncgrp01
次にconntrack-syncのステータス確認を行うと、こちらもMASTERになっている。
vyos@t3032vyos:~$ show conntrack-sync status
sync-interface        : eth1
failover-mechanism    : vrrp [sync-group syncgrp01]
last state transition : MASTER at Mon Jan 21 06:47:09 JST 2019
ExpectationSync       : disabled
コネクション情報を確認すると、VyOS#1のコネクション情報がVyOS#2に引き継がれており、Internal Cacheが増加していることがわかる。
vyos@t3032vyos:~$ show conntrack-sync statistics
Main Table Statistics:

cache internal:
current active connections:              157
connections created:                   84647    failed:            0
connections updated:                    7251    failed:            0
connections destroyed:                 84490    failed:            0

cache external:
current active connections:                0
connections created:                  173852    failed:            0
connections updated:                  370742    failed:            0
connections destroyed:                173852    failed:            0

traffic processed:
                   0 Bytes                         0 Pckts

multicast traffic (active device=eth1):
             7660420 Bytes sent             41014156 Bytes recv
              121520 Pckts sent               572546 Pckts recv
                   0 Error send                    0 Error recv

message tracking:
                   0 Malformed msgs                 2418 Lost msgs

参考

2019年1月16日水曜日

ZabbixをActive Directoryのユーザーで認証させる方法

Zabbixは、初期設定ではZabbixのデータベースでユーザー管理が実装されている。これをActive Directoryのユーザーで認証できるよう設定してみることにした。

実施環境

本検証を実施した環境は以下の通り。
  • OS : CentOS 7.5
  • Zabbix : Zabbix 4.0

Active Directory認証設定手順

1. Active Directory認証用のユーザー作成

ZabbixからActive Directory認証を行うにあたり、Bind DNと呼ばれるユーザー検索用のユーザーを1つ作成する必要があるので、事前に作成しておくこと。今回は、ユーザー名「ldapuser」で権限を「Domain Guests」で作成した。

2. Active Directory認証を設定

Zabbixの「管理」→「認証」→「LDAP認証のの設定」にて、以下の通りLDAPサーバー(今回の場合はActive Directoryドメインコントローラー)を設定する。
  • LDAPホスト:<ドメインコントローラーIPアドレス>
  • ポート:389 ※固定
  • Base DN:ユーザーを検索するOUを指定 (例:ou=My OU,dc=intrat,dc=local)
  • 検索の属性:sAMAccountName ※固定
  • Bind DN:ユーザーを検索するユーザーを指定 (例:ldapuser@intrat.local)
  • ログイン時に大文字小文字を区別:チェック ※固定
  • Bind password:<上記のパスワード>
  • ログイン:Base DN配下に存在する任意のユーザー
  • ユーザーのパスワード:<上記のパスワード>
設定後、「テスト」ボタンを押し「LDAPによるログインが成功しました」と表示されれば、設定に問題がないことを確認できる。



テスト後、必ず「更新」ボタンを押して設定反映をしておくこと。


3. Active Directory認証用グループを作成

「管理」→「ユーザーグループ」より、LDAP認証用のグループを「Active Directory Users」という名前で作成しておく。作成画面で「Webインターフェースへのアクセス」を「LDAP」にすること。


4. Active Directory認証用ユーザを作成

Active Directoryに存在するユーザー名を「エイリアス」に記載し、グループを先ほど作成した「Active Directory Users」に設定して、ユーザーを作成する。なお、パスワードは空白のままで問題ない


5. ログイン確認

先ほど作成したユーザーで、ログインができることを確認しよう。パスワードは、当然Active Directoryに登録されたものを入力する。



以下の通り正常にログインすることができた。


2019年1月13日日曜日

RSHで使用するポート番号を調べてみた

現在ではあまり利用されることもないRSHコマンドというものがある。Remote Shellの略称となるが、近年ではほとんどの場合SSHがリモートログインに利用されることから、OSに標準でインストールすらされなくなっているようだ。

このように現在ではあまり利用機会の少ないRSHとなるが、ISA社の監視警報装置「警子ちゃん」に鳴動命令を送る際には、いまだにRSHがよく利用されている。

今回、警子ちゃんを鳴動させるためにRSHコマンドで各種テストをする機会があったのだが、その際にRSHの通信が少し変な挙動をすることがわかったため、その調査結果について記載する。

RSH通信の挙動

RSHで接続する側をクライアント、接続される側をサーバーと呼ぶことにする。結論から言うと、RSHはクライアント→サーバーの通信だけでなく、サーバー→クライアントの通信も発生する。この動作が特殊であるため、特にクライアント~サーバー間にファイアウォールが存在する環境では注意が必要となる。

もう少しRSHの接続プロセスを詳細にみていこう。

RSHでは最初にクライアントからサーバーに接続するために、サーバー側で514番ポートにて待ち受けを行う。その際に、サーバーがクライアントに接続するためのポート番号を通知する。この折り返し用のポート番号は1023番から順番に設定されるが、1023番が既に利用されている場合は、1022、1021…とポート番号を下げていく仕様となっている。なお、一番最初にクライアントがサーバーへ接続する際に、1023番ポートが使用されるので、通常は1022番ポートが利用される。


上記動作をふまえると、接続先と接続元間でファイアウォールが存在する場合は、戻り通信は許可される前提とした場合はであっても、双方向で通信許可ルールを設定する必要がある

------------------------------
接続元IP   接続先IP   512-1023 514      許可
接続先IP   接続元IP   512-1023 512-1023 許可
------------------------------

このあたりはRed Hat社のKBにも記載がある(要アカウント)。

rsh 接続が使用するポート数を確認する
https://access.redhat.com/ja/solutions/2886641

RSH通信を実際にキャプチャして確かめてみる

上記動作をTCP dumpでキャプチャして確かめてみることにする。見やすくするために、一部記載を省略している。

# tcpdump -i 9 -nn host 192.168.11.114 and host 192.168.11.117
------------------------------
192.168.11.114.1023 > 192.168.11.117.514: Flags [S], seq 3849560126, win 29200, options [mss 1460,sackOK,TS val 1636109665 ecr 0,nop,wscale 7], length 0
192.168.11.117.514 > 192.168.11.114.1023: Flags [S.], seq 3310990677, ack 3849560127, win 28960, options [mss 1460,sackOK,TS val 1383182199 ecr 1636109665,nop,wscale 7], length
192.168.11.114.1023 > 192.168.11.117.514: Flags [.], ack 1, win 229, options [nop,nop,TS val 1636109665 ecr 1383182199], length 0

↑★クライアント→サーバーへの3-WAYハンドシェイク

192.168.11.114.1023 > 192.168.11.117.514: Flags [P.], seq 1:6, ack 1, win 229, options [nop,nop,TS val 1636109665 ecr 1383182199], length 5
192.168.11.117.514 > 192.168.11.114.1023: Flags [.], ack 6, win 227, options [nop,nop,TS val 1383182199 ecr 1636109665], length 0

↑★サーバーへクライアントが待ち受けるポート番号を通知(今回は1022番)

192.168.11.117.1023 > 192.168.11.114.1022: Flags [S], seq 1011651134, win 29200, options [mss 1460,sackOK,TS val 1383182206 ecr 0,nop,wscale 7], length 0
192.168.11.114.1022 > 192.168.11.117.1023: Flags [S.], seq 923859153, ack 1011651135, win 28960, options [mss 1460,sackOK,TS val 1636109671 ecr 1383182206,nop,wscale 7], length
192.168.11.117.1023 > 192.168.11.114.1022: Flags [.], ack 1, win 229, options [nop,nop,TS val 1383182206 ecr 1636109671], length 0

↑★サーバー→クライアントへの3-WAYハンドシェイク

192.168.11.114.1023 > 192.168.11.117.514: Flags [P.], seq 6:19, ack 1, win 229, options [nop,nop,TS val 1636109672 ecr 1383182199], length 13
192.168.11.117.514 > 192.168.11.114.1023: Flags [.], ack 19, win 227, options [nop,nop,TS val 1383182206 ecr 1636109672], length 0
192.168.11.117.514 > 192.168.11.114.1023: Flags [P.], seq 1:2, ack 19, win 227, options [nop,nop,TS val 1383182213 ecr 1636109672], length 1
192.168.11.114.1023 > 192.168.11.117.514: Flags [.], ack 2, win 229, options [nop,nop,TS val 1636109679 ecr 1383182213], length 0
192.168.11.117.514 > 192.168.11.114.1023: Flags [P.], seq 2:172, ack 19, win 227, options [nop,nop,TS val 1383182222 ecr 1636109679], length 170
192.168.11.114.1023 > 192.168.11.117.514: Flags [.], ack 172, win 237, options [nop,nop,TS val 1636109687 ecr 1383182222], length 0

↑★各種通信

192.168.11.117.1023 > 192.168.11.114.1022: Flags [F.], seq 1, ack 1, win 229, options [nop,nop,TS val 1383182222 ecr 1636109671], length 0
192.168.11.114.1022 > 192.168.11.117.1023: Flags [.], ack 2, win 227, options [nop,nop,TS val 1636109688 ecr 1383182222], length 0
192.168.11.114.1022 > 192.168.11.117.1023: Flags [F.], seq 1, ack 2, win 227, options [nop,nop,TS val 1636109693 ecr 1383182222], length 0
192.168.11.117.1023 > 192.168.11.114.1022: Flags [.], ack 2, win 229, options [nop,nop,TS val 1383182228 ecr 1636109693], length 0

↑★TCP通信終了(サーバー→クライアント)

192.168.11.117.514 > 192.168.11.114.1023: Flags [F.], seq 172, ack 19, win 227, options [nop,nop,TS val 1383182227 ecr 1636109687], length 0
192.168.11.114.1023 > 192.168.11.117.514: Flags [F.], seq 19, ack 173, win 237, options [nop,nop,TS val 1636109694 ecr 1383182227], length 0
192.168.11.117.514 > 192.168.11.114.1023: Flags [.], ack 20, win 227, options [nop,nop,TS val 1383182229 ecr 1636109694], length 0

↑★TCP通信終了(クライアント→サーバー)
------------------------------

通信開始の前に、サーバー→クライアントへの3-WAYハンドシェイクが実施されていることがわかる。

2019年1月5日土曜日

Xubuntu 18.04にxrdpを使ってRDPでリモートデスクトップ接続をする

おおよそ1年前に、Xubuntu 16.04にxrdpをインストールして、リモートデスクトップをするという記事を書いた。

★以前の記事はこちら↓

Xubuntu 16.04にxrdpを使ってRDPでリモートデスクトップ接続をする
https://tech-mmmm.blogspot.com/2017/08/xubuntu-1604xrdprdp.html

ふと、Xubuntu公式サイトを見ると、18.04が2018年4月にリリースされたようなので、16.04をやめて18.04に入れ替えることにした。

結論から言うと、xrdpのバージョンが上がっており、前回必要だった細かな設定変更はすべて不要となっており、使い勝手が向上していた。

xrdpインストール手順

インストールは非常に簡単で、apr-getでインストールするだけである。

# apt-get install xrdp
------------------------------
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  xorgxrdp
提案パッケージ:
  guacamole xrdp-pulseaudio-installer
以下のパッケージが新たにインストールされます:
  xorgxrdp xrdp
アップグレード: 0 個、新規インストール: 2 個、削除: 0 個、保留: 0 個。
498 kB のアーカイブを取得する必要があります。
この操作後に追加で 3,303 kB のディスク容量が消費されます。
続行しますか? [Y/n] y   ←★"y"を入力
取得:1 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 xorgxrdp amd64 0.9.5-2 [78.7 kB]
取得:2 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 xrdp amd64 0.9.5-2 [419 kB]
498 kB を 1秒 で取得しました (336 kB/s)

~(中略)~

systemd (237-3ubuntu10.3) のトリガを処理しています ...
man-db (2.8.3-2) のトリガを処理しています ...
xorgxrdp (0.9.5-2) を設定しています ...
libc-bin (2.27-3ubuntu1) のトリガを処理しています ...
ureadahead (0.100.0-20) のトリガを処理しています ...
------------------------------

インストールが完了したら、バージョンを確認してみよう。

# xrdp --version
------------------------------
xrdp: A Remote Desktop Protocol server.
Copyright (C) Jay Sorg 2004-2014
See http://www.xrdp.org for more information.
Version 0.9.5
------------------------------

Xubuntu 16.04のxrdpのバージョンは0.6系だったが、今回は0.9系となっている。以下URLで2019年1月現在のxrdpの最新バージョンを確認すると、0.9.9のようなので、そこそこ新しいものが導入されているようだ。

GitHub - neutrinolabs/xrdp
https://github.com/neutrinolabs/xrdp/releases

使ってみる

早速リモートデスクトップ接続をしてみると、ログイン画面は表示されユーザー名とパスワード入力はできるのだが、ログイン以降の画面が表示されないという事象が発生した。詳細な原因は不明だが、これはxrdpインストール以降一度も再起動をしていないと発生するようだ。一度OSを再起動するとうまく接続できた。


デフォルトで、キーボードのキー配置は英語配列ではなく日本語配列になっている。ターミナルのTAB保管も問題なく利用できる。さらに、クリップボードを利用したコピー&ペーストによるファイル転送もできるようになっており、WindowsでRDPを利用している場合と比較しても遜色がない。

というわけで、xubuntu 16.04の頃よりもxrdpのバージョンが上がっており、簡単にRDPできるようになっていることから、xubuntu 18.04の利用はかなりお勧めとなる。

人気の投稿