ページビューの合計

ラベル traveler の投稿を表示しています。 すべての投稿を表示
ラベル traveler の投稿を表示しています。 すべての投稿を表示

2020年2月19日水曜日

#Traveler サーバーのマイグレーションについて

Today we've migrated the Traveler server prior to the Domino server, so I'll give you a quick status report.

みなさま、こんにちは!

今回は弊社でのマイグレーション案件について、小出しにさせて頂きます。

今回の作業は、Travelerサーバーを 9→V11 にマイグレーションを行った内容となります。
※立ち上げ含め、作業はパートナー様に行って頂きましたので、私のほうではテストと検証のみの作業となります。

さて手順ですが、新しいTravelerサーバーを一旦DMZではなく社内ネットワークに構築し、設定等を完了させて頂きました。
この時点でサーバーはドメイン参加しておらず、新たなIPアドレスで、FQDN名は既存サーバーと同一としてあります。

続いてテストです。
1台のiOS端末の既存プロファイルを削除し、新しいサーバーにIPアドレスでアクセスしてプロファイルをインストールしました。
問題なくインストールはできたのですが、iOS端末のメールアカウントを見ると、FQDN名で登録されてしまっています。

メールの疎通は問題なくできたのですが、これではどのルートで届いたものか確定することができませんでした。

ということで・・・
これ以上のテストは諦めて、本日本番サーバーとの切り替えを実施致しました。
切り替えについては、旧サーバーを停止して、新サーバーをDMZに移動させ、IPアドレスを旧サーバーと同じにするという手段です。

希望としては、各個人のiOS端末にプロファイルの再インストールなく繋がってくれれば・・・

です。

さていきなり結果ですが、今回は2種類のプロファイルがインストールされた端末が準備できています。

①旧Travelerサーバーより生成したものと、先ほどテストで②新Travelerサーバーから生成したものになります。

まずは②についてです。
プロファイルは既にインストールされていますので、メールアプリを開きます。

すると・・・・

かなーり長い時間がかかりましたが、受信ボックスが更新され、最新のメールまで同期されました。
メールを開くと、問題なくメールの内容が見ることができました。

2回目以降の同期はサクサク動いてくれますので、初回起動時のみおそらくIPアドレスが変更されたことにより、時間がかかったのではないかと推測されます。

次に本題の①です。

こちらも同じく初回起動時に長い時間がかかりました。
②よりも長くかかりましたが、無事受信ボックスは更新されました。

しかし!
メールを開いても本文を読み込んでくれません。
しばらく待ったのですが、画面はグレーのまま・・・
あきらめて受信ボックスに戻り、こちらを再度更新してみましたが、②とは違い、更新には再度時間がかかる状況でした。

やはり・・・
サーバーを切り替えてしまっているため、異なる証明書が利用されることになることから、プロファイルの入れ替えは必要なようです。

想定していた通りではありますが、逆に受信ボックスが更新されたことが少し不安・・・。

ということで、現在は利用ユーザーにプロファイルの入れ替えを行って頂いております。

但し・・・
iOSのバージョンアップでTLSの影響を受け、旧Travelerサーバーのプロファイルをインストールできなかったユーザーが救われることになりましたので、ひとまずは安心といったところでしょうか。

ちなみに予断ですが、実は本作業少しトラブルがありました。
私は問題なく動いたのですが、他のユーザーは新しいプロファイルがインストールできないというトラブルです。
これについては、Travelerのちょっとした変更に起因していたもようで、無事復旧しております。

ただこのやり取りについて、ひとつ気になったので報告させて頂きます。
パートナー SE様で原因がつかめなかったため、HCL社にサポートを投げて頂きました。
すぐにサポート窓口に繋がったそうで、状況報告とログ提出を行い、遅い時間でしたが、有効に回答が得られ、無事現在に至るというまさにサポートの模範!!のような対応を頂けたそうです。

HCLサポート窓口のご担当者様、ほんとうにありがとうございました!!


さて今後の予定です。
本題のDominoサーバーですが、3/6夜からデータコピーを行い、3/7に入れ替えの予定です。
こちらもTravelerサーバーと近いのですが、現在は社内ネットワークにほぼ設定完了した状態で存在しております。

各アプリケーションテストは既に実施済みで、弊社内で運用しているほぼすべてのアプリケーションの稼動確認まで完了した状態です。

あまり心配してはいませんでしたが、このあたりさすがNotesですね!!

3/7の入れ替えからは、IDVaultが有効になります。
この時点で全社にNomadをリリースすることになります。

またVerseオンプレミスも動きますので、こちらもリリースします。

以上だけモバイル環境のメール環境は大きく変化してくれます。
現在は

・Traveler経由でメールアプリを使用(但し、文書リンクが使えない・・・)
・iNotes経由で使用

でしたが、加えてNomad、Verseが使えるようになります。
やはりNomadの登場は大きいですね。
いずれのメールからでもノーツアプリにアクセスできるようになるため、モバイル端末の利用頻度が格段に変化するものと予測されます。

クライアントはもうしばらく9.0を使用しますが、VDIの切り替え時に一緒にV11でリリースし、テンプレートを更新という流れを予定しています。

またこちらについても、ぽつぽつ状況報告させて頂ければと思いますので、よろしくお願いします。

2019年5月22日水曜日

ほんとに困った #traveler のはなし・・・

This time, I am talking about the setting of the Traveler who really got in trouble with us.

みなさま、こんにちは!!
早速ですが、今回は弊社で発生しました、ほんとうに困ったTravelerの設定に関しての話題になります。

弊社ではiPhoneにプロファイルを取り込んで、Travelerを利用できるよう設定しています。
具体的にはiPhoneのブラウザ・・・基本的にはSafari・・・からTravelerサーバーにアクセスし、認証を介することでiPhone内にプロファイルが取り込まれ、iPhoneのデフォルトメールアプリでDominoサーバーのメールと同期できるようになります。

さてそれでは困った背景です。
ご存知の通り、iOSはさまざまな設定がOSのアップデートに含まれております。
以前にも一部のSSLを一方的に遮断され、大騒ぎしたことがありました。


今回は証明書に関する設定変更になります。
iOS10以降、自己証明書を使ってhttps通信が接続できなくなったことに起因していました。

そのため、SafariでTravelerサーバーのURLを表示させると、以下のような画面が表示されます。



この画面については従来から表示されていたため、何の違和感もなく「詳細を表示」をタップします。すると・・・


こちらの画面が開きます。この画面が以前と違っていました。
以前はこの文面に「詳しくは、証明書を見ることができます。それに伴う危険性を理解している場合には、このWebサイトを閲覧できます。」のようなリンクがあり、こちらをタップすることでTravelerサーバーにアクセスすることができました。
ところが!!
現在はそのリンクがなくなっており、アクセスする手段が絶たれてしまったのです。

さらにこの中の「詳細を表示」をタップしますと、以下証明書が表示されました。


期限は2024年までのため、少なくとも期限切れでないことはわかりますが、さらに「詳細」を見ても、


証明書の内容が表示されるだけで、何のアクションも行うことができませんでした。

その後いろいろと調査しました。
キャリアへはこのままだとAndroidに切り替えるかもというプレッシャーを与えたり、MDMのメーカーともバージョンアップ等の作業。もちろんApple社にも相談し、iPhone構成ユーティリティ・・・現在はApple Configuratorという製品に切り替わっているそうです・・・を試してみたり。

そうこうしているところ、弊社の窓口会社より以下連絡が入りました。

 「Windows 環境で OpenSSL KYRTool を利用して自己署名証明書を作成する」

ただし、この前提として

ただiOS9以降、暗号化通信を行う場合、TLS1.2のサポートとSHA256の証明書は必要となる様です。
DominoTravelerモジュール共、TLSに対応したバージョンが必要です。
 ※TLS1.2のサポートのために必要なDominoバージョン:Domino 9.0.1 FP3 IF2 以降

 ※iOS9対応TravelerTraveler 9.0.1.7 以降

ということでした。

現在、Verse移行も含めたハイブリット化+V10マイグレーションを予定しているため、TLSだけの作業を先行するか、ハイブリット化を早めるかを検討することになりました。

また進展しましたら、改めて報告させて頂きます。

2018年12月4日火曜日

IBM Notes #Traveler データベースのデフラグについて

Let's regularly defragment the Traveler server !!

みなさま、こんにちは!!
いよいよ今年もあと1ヶ月を切ってしまいました。
クリスマスやお正月が楽しみな反面、年末の繁忙期を乗り越えなければなりません。

さて本日はタイトルの通り、Travelerサーバーのデフラグについて書かせて頂きます。

まず弊社の環境ですが、社内にDominoサーバーがあり、DMZ上にTravelerサーバーがあるというごく単純な構成になっています。
Travelerサーバーは定期的に再起動を行っております。

さて今回の背景です。
数ヶ月前までは、社内で使用しているノーツクライアントにメールが着信するのが早いか、Travelerを経由してiPhoneに通知が出るのが早いかというほどでした。
ところが最近になりiPhoneへの通知が遅れたり、場合によっては通知がない(正しくは通知前にクライアント側で閲覧したため、通知されない?)という状況になってしまいました。

一番にTravelerサーバーの再起動やサーバーそのものの再起動を試してみたのですが、改善されませんでした。
そこで弊社のパートナー様へ情報提供を依頼したところ、以下記事のリンクを送っていただけたのです。

(参考) IBM Notes Traveler データベースのデフラグによるパフォーマンスの改善について

詳細はリンク先を見て頂きたいのですが、要は

「IBM Notes Traveler のインストールサイズが大きくなり、稼働時間が延びるにともない、IBM Notes Traveler の内部データベースのサイズが増加してシステムのパフォーマンスに影響を及ぼしうるケースが見られる」ようになるそうです。
この対策として、データベースを圧縮・最適化するデフラグコマンドを追加頂けたました。
またシステムを良好な状態に維持するため、1ヶ月に1回程度はこのコマンドを実行することが推奨されているとも記載されております。
恥ずかしながらこの情報は全く知らずに使い続けていたことが原因のようです。
ということで、早速Travelerサーバーのデフラグを行い、また今後のために30日に1回実行するように設定してみたいと思います。

手順もすべて先のURLに書かれているのですが、実に簡単です。


サーバーの notes.ini に以下の1行を追加するだけ・・・。

    NTS_DEFRAG_INTERVAL_DAYS=30
保存して、Travelerサーバーを再起動すると、前回のデフラグより30日が経過されている場合(弊社では1回も実行していないため、もちろん該当)、起動時にデフラグが実行されます。

デフラグの時間を計り忘れたのですが、1~2分程度ではなかったかと思います。
恐らく次回以降はこの時間も短縮されるのではないかと推測します。


なお手動で実行する場合は、Traveler タスクと HTTP タスクをシャットダウン

  tell traveler quit
       tell http quit


した上で、以下コマンドを実行します。

load traveler -defrag


デフラグが完了すると、自動でTravelerサーバーが起動し(httpタスクも含む)、完了です。


以上、本来ユーザーが知っておかなければいけない情報かと思いますので、掘り起こさせて頂きました。