2018年06月
2018年06月30日
Compute Stick を何台か導入しています。
絶対的なメリットが一つあって、会議室にTVがある場合、そのTVを利用してPCの画面を表示させることが可能です。ちょっとしたことであれば、そこで会議をしたり、プレゼンを表示させたり。音楽をかけたり様々な利用が可能です。
あまり製品の種類がないのですが、インテルの Compute Stick を導入しています。
STK2m3W64CC という製品があり、現在での価格は5万円を切る。
CPUは Core m3 6Y30(Skylake)
CPU Benchmarks のスコアは3051です。
STK1AW32SC という製品は、2万円を切るぐらいの価格です。
CPUは Atom x5-Z8300
CPU Benchmarks のスコアは 1199 です。
このx5-Z8300ではWindows10の普通の状態でもCPUを10％ぐらい利用しており、結構カツカツな感じです。
そのためそれこそ会議室のような場所で一時的な利用という用途以外には使えないように思いました。
高い方の製品は、全く問題無く複数のアプリを立ち上げるような用途も全く問題ありません。
安い方の製品であっても、条件に合致している場合にはとても有用です。
絶対的なメリットが一つあって、会議室にTVがある場合、そのTVを利用してPCの画面を表示させることが可能です。ちょっとしたことであれば、そこで会議をしたり、プレゼンを表示させたり。音楽をかけたり様々な利用が可能です。
あまり製品の種類がないのですが、インテルの Compute Stick を導入しています。
STK2m3W64CC という製品があり、現在での価格は5万円を切る。
CPUは Core m3 6Y30(Skylake)
CPU Benchmarks のスコアは3051です。
STK1AW32SC という製品は、2万円を切るぐらいの価格です。
CPUは Atom x5-Z8300
CPU Benchmarks のスコアは 1199 です。
このx5-Z8300ではWindows10の普通の状態でもCPUを10％ぐらい利用しており、結構カツカツな感じです。
そのためそれこそ会議室のような場所で一時的な利用という用途以外には使えないように思いました。
高い方の製品は、全く問題無く複数のアプリを立ち上げるような用途も全く問題ありません。
安い方の製品であっても、条件に合致している場合にはとても有用です。
2018年06月29日
まだ解決していません。そのためメモです。
前日以下の記事を書いています。
2018年06月12日：DHCPサーバーのエラー。
症状としては、前回の通りで再リースできないというものです。
で、取得できた場合でもリース期間が1時間となっていることがありました。設定値は1日とかそういう十分に長い時間だったのに不思議に感じていました。
なお Windows DHCP サーバーでフェイルオーバーを構成しています。
日本語ではいまいち検索結果が期待したものにならなかったので、以下の方法で検索しました。
windows dhcp 1 hour lease : google検索
検索結果のいくつかのページを見ていると、フェイルオーバー構成の場合、デフォルトでは1時間だという記事がありました。
そして以下のページのときに MCLT( Maximum Client Lead Time ) というキーワードが出てきました
DHCP Lease Duration Issue
MCLTで検索するとは日本語の以下のページが。
フェイルオーバー機能を使いこなせ〜DHCPサーバー編(2)
だいぶ理解が進んできたように思います。
僕のところで起きている症状としては、多数の端末は正常にDHCPを受け取る。リース期間が経過し再リースになった場合、1時間で受け取ることがある。このとき、リースを受けられない端末もある。※もちろん正常にリースを受けられる端末もある。
以上のことから、フェイルオーバー構成の問題が生じているように思いました。
負荷分散モードで動作させているので、これをホットスタンバイにするか、50%ずつの構成を90％と10％のようにするのもありかもしれません。
前日以下の記事を書いています。
2018年06月12日：DHCPサーバーのエラー。
症状としては、前回の通りで再リースできないというものです。
で、取得できた場合でもリース期間が1時間となっていることがありました。設定値は1日とかそういう十分に長い時間だったのに不思議に感じていました。
なお Windows DHCP サーバーでフェイルオーバーを構成しています。
日本語ではいまいち検索結果が期待したものにならなかったので、以下の方法で検索しました。
windows dhcp 1 hour lease : google検索
検索結果のいくつかのページを見ていると、フェイルオーバー構成の場合、デフォルトでは1時間だという記事がありました。
そして以下のページのときに MCLT( Maximum Client Lead Time ) というキーワードが出てきました
DHCP Lease Duration Issue
MCLTで検索するとは日本語の以下のページが。
フェイルオーバー機能を使いこなせ〜DHCPサーバー編(2)
だいぶ理解が進んできたように思います。
僕のところで起きている症状としては、多数の端末は正常にDHCPを受け取る。リース期間が経過し再リースになった場合、1時間で受け取ることがある。このとき、リースを受けられない端末もある。※もちろん正常にリースを受けられる端末もある。
以上のことから、フェイルオーバー構成の問題が生じているように思いました。
負荷分散モードで動作させているので、これをホットスタンバイにするか、50%ずつの構成を90％と10％のようにするのもありかもしれません。
2018年06月28日
Yamahaで L2TP/IPsec をやっています。
複数名がアクセスしてくる場合に、事前共有鍵をたくさん設定する必要があります。
そして案外と、Tunnel1の設定はあっているけども、複数が同時接続すると、3番目の人が接続できない・・・というようなエラーになることがあります。この場合、Tunnel2の設定が間違っていたりとか・・。
事前共有鍵をそれぞれ異なるものにしていたら・・・。
適切な tunnel で接続してくれるのか・・そう思ったのですが、どうもだめっぽいですね。
ルーターの設定例:複数のL2TPクライアント(アドレス不定)の接続を受け付ける場合
上記サイトに以下のように記載があります。
> ※アドレス不定の複数のL2TPクライアントから接続を受け付ける場合には、
> IPsec事前共有鍵が統一されている必要があります。
ログをみたところ、PCで設定した事前共有鍵のTunnelを利用しているようでした。
※ただし接続までは試していないので、詳細は不明です。
複数名がアクセスしてくる場合に、事前共有鍵をたくさん設定する必要があります。
そして案外と、Tunnel1の設定はあっているけども、複数が同時接続すると、3番目の人が接続できない・・・というようなエラーになることがあります。この場合、Tunnel2の設定が間違っていたりとか・・。
事前共有鍵をそれぞれ異なるものにしていたら・・・。
適切な tunnel で接続してくれるのか・・そう思ったのですが、どうもだめっぽいですね。
ルーターの設定例:複数のL2TPクライアント(アドレス不定)の接続を受け付ける場合
上記サイトに以下のように記載があります。
> ※アドレス不定の複数のL2TPクライアントから接続を受け付ける場合には、
> IPsec事前共有鍵が統一されている必要があります。
ログをみたところ、PCで設定した事前共有鍵のTunnelを利用しているようでした。
※ただし接続までは試していないので、詳細は不明です。
2018年06月27日
以前に会社のPCを交換していました。
2018年05月18日: 新しいPC
便利に使っているのですが、たまにマルチモニターが認識されなくなってしまいます。
今回もだめだったので以下の方法で解決しました。
症状としては、BIOSの画面などは問題無く表示されます。
しかしWindowsが起動すると、1つのモニターにだけ映像が表示されます。そしてディスプレイ設定を開いても特に何も出てきません。Windowsからは1台しか認識していないようだったのです。
デバイスマネージャーを表示させても、特に問題なさそうでした。
気になった点では、モニターのところに汎用PnPモニターとなっていたことぐらいでしょうか。
ディスプレイのドライバーをインストールしてみましたが、状況はかわりません。
いったんディスプレイアダプターを削除しました。
AMD Radeon R5 200 Series という表示があったのですが、「デバイスのアンインストール」を選択しました。
再起動するとそのまま自動で同じドライバーがインストールされました。
タスクバーには AMD Catalyst Control Center という亀のようなアイコンがふえていました。
このコントローラーを起動し、共通ディスプレイタスクから「ディスプレイを検出」を選択すると、無事に両方のモニターに映像が出力されました。
特に何もしていないのに、利用中に突然そのようなことになってビックりしました。
2018年05月18日: 新しいPC
便利に使っているのですが、たまにマルチモニターが認識されなくなってしまいます。
今回もだめだったので以下の方法で解決しました。
症状としては、BIOSの画面などは問題無く表示されます。
しかしWindowsが起動すると、1つのモニターにだけ映像が表示されます。そしてディスプレイ設定を開いても特に何も出てきません。Windowsからは1台しか認識していないようだったのです。
デバイスマネージャーを表示させても、特に問題なさそうでした。
気になった点では、モニターのところに汎用PnPモニターとなっていたことぐらいでしょうか。
ディスプレイのドライバーをインストールしてみましたが、状況はかわりません。
いったんディスプレイアダプターを削除しました。
AMD Radeon R5 200 Series という表示があったのですが、「デバイスのアンインストール」を選択しました。
再起動するとそのまま自動で同じドライバーがインストールされました。
タスクバーには AMD Catalyst Control Center という亀のようなアイコンがふえていました。
このコントローラーを起動し、共通ディスプレイタスクから「ディスプレイを検出」を選択すると、無事に両方のモニターに映像が出力されました。
特に何もしていないのに、利用中に突然そのようなことになってビックりしました。
2018年06月26日
※以前にも記事を書いていました。
2011年07月19日:mod_rewrite でURLの統一
今回は以下の方法を利用しました。
※すべて www ありの httpsとなります。
RewriteEngine on
# non-www To www
RewriteCond %{HTTP_HOST} ^[ドメイン](.*)$ [NC]
RewriteRule (.*) https://www.[ドメイン]/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://www.[ドメイン]/$1 [R=301,L]
2011年07月19日:mod_rewrite でURLの統一
今回は以下の方法を利用しました。
※すべて www ありの httpsとなります。
RewriteEngine on
# non-www To www
RewriteCond %{HTTP_HOST} ^[ドメイン](.*)$ [NC]
RewriteRule (.*) https://www.[ドメイン]/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://www.[ドメイン]/$1 [R=301,L]
2018年06月25日
以下のような static masquerade の設定を入れていました。
nat descriptor masquerade static 1 1 10.0.0.2 tcp 8888=80
これでグローバルIPにアクセスで http://[IPアドレス]:8888/ としてアクセスすると、内部にあるサーバーの80番ポートに転送されるようになりました。
# show nat descriptor address all
NAT/IPマスカレード 動作タイプ : 2
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
外側アドレス: ipcp/X
ポート範囲: 60000-64095, 49152-59999, 44096-49151 30 セッション
プロトコル 内側アドレス 宛先 マスカレード 種別
TCP 10.0.0.2.80 *.*.*.*.* 8888 static
このとき、適切なフィルタを当てる必要があるのですが、logをとりながらやってもいまいちうまくいきませんでした。
原因としては、
以下のサイトに。
http://www.rtpro.yamaha.co.jp/RT/FAQ/NAT/http-static-masquerade.html
> RTシリーズのIPパケットフィルタは、 NATの内側で適用されている為、
> NAT変換の有無をほとんど気にすることなく、設定することができます。
ということです。つまりフィルタの設定をするとき、外部からやってくるポートの8888を制御するのではなく、80を制御すれば大丈夫でした。
nat descriptor masquerade static 1 1 10.0.0.2 tcp 8888=80
これでグローバルIPにアクセスで http://[IPアドレス]:8888/ としてアクセスすると、内部にあるサーバーの80番ポートに転送されるようになりました。
# show nat descriptor address all
NAT/IPマスカレード 動作タイプ : 2
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
外側アドレス: ipcp/X
ポート範囲: 60000-64095, 49152-59999, 44096-49151 30 セッション
プロトコル 内側アドレス 宛先 マスカレード 種別
TCP 10.0.0.2.80 *.*.*.*.* 8888 static
このとき、適切なフィルタを当てる必要があるのですが、logをとりながらやってもいまいちうまくいきませんでした。
原因としては、
以下のサイトに。
http://www.rtpro.yamaha.co.jp/RT/FAQ/NAT/http-static-masquerade.html
> RTシリーズのIPパケットフィルタは、 NATの内側で適用されている為、
> NAT変換の有無をほとんど気にすることなく、設定することができます。
ということです。つまりフィルタの設定をするとき、外部からやってくるポートの8888を制御するのではなく、80を制御すれば大丈夫でした。
2018年06月24日
デバッグといっても大げさですが、適用されているかされていないかを確認します。
適用されていない場合、たいていの場合には正規表現のミスですよね。
# ヘッダーチェックを行うときの正規表現を記載しているファイルを指定
vi /etc/postfix/header_checks
/^(From:.*[メールアドレス])/ WARN DEBUG-TEXT
WARN を指定すると、ログにテキストが付与されます。
# サービスのリロードで上記設定が有効になります
service postfix reload
# tail でログを追いかけます。
tail -f /var/log/maillog
上記メールアドレスに自身のメアドを入れ、テスト送信をしてみました。すると、以下のようにログが出ていました。
warning: header From: =?ISO-2022-JP?B?XXX=?= from local; <略>: DEBUG-TEXT
適用されていない場合、たいていの場合には正規表現のミスですよね。
# ヘッダーチェックを行うときの正規表現を記載しているファイルを指定
vi /etc/postfix/header_checks
/^(From:.*[メールアドレス])/ WARN DEBUG-TEXT
WARN を指定すると、ログにテキストが付与されます。
# サービスのリロードで上記設定が有効になります
service postfix reload
# tail でログを追いかけます。
tail -f /var/log/maillog
上記メールアドレスに自身のメアドを入れ、テスト送信をしてみました。すると、以下のようにログが出ていました。
warning: header From: =?ISO-2022-JP?B?XXX=?=
