ORCA
＜２．Etch版ORCA運用＞
１．ORCAの構成
１）機器構成
パソコン２台（主サーバと従サーバ）、ディスプレイ１台、キーボード１個、マウス１個、パソコン自動切替器。
これらを１セットとしてORCAセットとしてます。運用ORCAとバックアップORCAの２セットの構成で、計４台です。
また、テスト用にノートパソコン１台を利用してます。
運用上はバックアップORCAは１台構成でもかまわないと思います。
プリンタに関しては、運用ＯＲＣＡはネットワークプリンタ（Canon LBP-3410）、バックアップＯＲＣＡは
ローカルプリンタ（Epson PX-V630など）を使用しています。
パソコンは、FRONTIER製「DS-KZDS12」「FRDS-420/945X」「FRAI17」「FRAI10」の４台です。
１台６万前後の機能の少ないパソコンです。
RAM1GB、ＨＤ容量160GBでWindowsとデュアルブートでインストールしているのでLinux用は120GBぐらいです。
レセコンとしてのみ使う場合、Windowsとデュアルブートでインストールする必要はないと思います。
パソコンへのEtch版Debianのインストール、プリンタの設定等は「Debianの導入方法」の「３．Debian-Etch版 」
に記載してあります。
２）パソコン自動切替器
私の所では、従サーバはバックアップ専用でデータ入力はしていません。ディスプレイ、キーボード、マウスが２つあってっも
じゃまなので、「パソコン自動切替器」を使って２台のパソコンでディスプレイ、キーボード、マウスを
切り替えて共有してます。
１．COREGA製型番CG-PG2KVMV2
２．BUFFALO製型番BKVM-P201
いずれもキーボード、マウスがPS/2対応の切替器です。USB接続でも、うまくいかは分かりません。
どちらもLinuxで作動します。BUFFALO製は安いのですが、切替時にマウスがフリーズすることがあります。
しかし、コネクタを差し直せば治りますので問題ありません。
３）USBメモリ
バックアップＯＲＣＡへのデータ移行には、USBメモリを使ってます。
運用ORCAでdumpファイルを作成し、それをUSBメモリにコピーして、そのデータをバックアップORCAにコピーしてます。
USBメモリは、FATフォーマットされたWindows用のものをそのまま使ってます。
そのためかLinuxからではデータ削除がうまくいきませんので、Windowsで削除しています。
４）USB接続外付けハードディスク(HD)
Linux用にフォーマットしていればUSBメモリと同じような方法でコピーできます。
フォーマットするために使ったソフトは、Windows用の「Acronis Disk Director Suite 10.0 」です。
このソフトを使って、外付けHDもWindows領域とLinux領域を作ってます。
私の方法ではHDのアクセス権がrootのため、ファイル・ブラウザは（root使用）でしかコピーがうまくいきませんでした。
それで、外付けHDのアクセス権をユーザ名に変えてユーザでもコピーできるようにしています。
「アプリケーション」−＞「システムツール」ー＞「ファイルブラウザ」があります。
１．ログイン・マネジャーの設定変更
ログイン画面で
「アクション」ー＞「ログイン・マネジャーの設定」−＞「セキュリティ」−＞「システム管理者のログインを許可する」
これでrootでログインできるようになります。
２．HDのアクセス権変更
rootでログインするとファイル・ブラウザをroot使用できます。
ファイル・ブラウザでＨＤを選び、画面上の何もない場所で右クリックしてHDのプロパティを開きます。
「プロパティ」−＞「アクセス権」−＞「ファイルの所有者」「ファイルのグループ」をユーザ名に変えます。
これでアクセス権がユーザに変わり、ファイル・ブラウザ（ユーザ使用）でHDにコピーできます。
アクセス権変更後は、「システム管理者のログインを許可する」を取り消して元の状態に戻した方がいいです。
私は、今のところdumpファイルのバックアップにしか使っていません。
２．クライアントの設定
私の所では、主サーバのみでデータ入力していますので、クライアントは接続してはいません。
今までのレセコンも１台だけでしたので、小さな診療所はこれでいいかと思っています。
１）主サーバに接続するためのクライアントの設定
日医レセプトソフト（jma-receipt）をインストールせず、クライアントとしてのみ使う場合です。
ｐ３０までの設定後、ｐ３１の「PostgreSQLのセットアップ」、ｐ３２の「日レセのインストール」をしないで
ｐ３４に飛びます。
# aptitude install -y panda-client （panda-clientのみをインストールします）
データベース機能はインストールしてませんので、データ入力とデータチェック用のパソコンになるかと思います。
後は、以下の方法で接続できます。
サーバ・クライアントの起動手順
$ glclient -port 192.168.**.** -user ormaster -pass [ormasterのパスワード] panda:orca00
192.168.**.**：主サーバのＩＰアドレス
ormasterのパスワード：ｐ３３「３．４パスワードの設定」で設定したormasterのパスワード
192.168.**.**：従サーバのＩＰアドレスを指定すればバックアップされた従サーバのデータベースに接続される事になります。
主サーバに異常があり従サーバで運用するには、クライアントの設定変更が必要になります。
Javaで動くクライアントソフトもあります。
glclient / Java (monsiaj) Java版glclient
これは試していないので、上記設定のクライアントと機能が違うかは知りません。
Javaは違うOSでも動くプログラムを作ることができる言語です。多分、WindowsやMacで動くクライアントソフトの
要望があって作られたのでしょう。
３．従サーバのglclientランチャーの設定
MONTSUQIによるDB2重化の概略図
「２重化の概略図」を見ると、従サーバは主サーバのデータベース（日医レセプト）に接続する設定になってますので
クライアントとして設定が原則です。
従サーバを主サーバのデータベースに接続するには、次のようにクライアントの設定で接続する必要があります。
$ glclient -port 192.168.**.** -user ormaster -pass ****** panda:orca00
１）glclientランチャーの設定変更
glclientランチャーを使って主サーバのデータベースに接続するには
ホスト（ポート）：localhost
localhostを主サーバのＩＰアドレス（192.168.**.**）に設定すれば接続できます。
あるいはサーバ設定を新規に作成して登録するかです。
２）新たなランチャーの作成
新たなランチャーを作成して接続するには、画面を右クリックして「ランチャの生成（A)」をクリックします。
名前（N):主サーバ接続など適当に名前を付けます。
コマンド（A):glclient -port 192.168.**.** -user ormaster -pass ****** panda:orca00
アイコン（Ｉ）：対応するアイコンを適当に選びます。
「端末内で起動する」にチェックを入れます。
これで、アイコンのクリックだけで主サーバのデータベースに接続できます。
日常業務の入力用（主サーバDB接続）、従サーバのデータベースのメンテナンス用（従サーバDB接続）の２種類
ランチャーを使い分けるのも一つの方法かもしれません。
３）当院の従サーバの設定
私の所では従サーバは入力に使ってませんので、初期設定のlocalhostのままにしています。
メンテナンス（プログラムの更新）ため従サーバのデータベース（日医レセプト）に接続する時のみglclientランチャーを
起動してます。
当院では、パソコン自動切替器を使ってディスプレイ１台で運用してます。背景など変えてどちらのパソコンの画面か
分かるようにしてます。
以下をインストールすれば、色々な画面にすることもできるようです。
# aptitude install gtk-engines-pixmap
/usr/share/themes/テーマ/gtk-2.0/gtkrc
上記でうまくいかと思ったら何も変わりませんでした。手順書をよく読むとGTK1.2でなければだめと書いてあります。
古いバージョンGTK1.2をインストールすればいいかもしれませんが、jma-receiptがそのうちGTK2.0に対応するようです。
４）従サーバのデータベースへの接続とデータ入力
localhostの設定では、従サーバは従サーバのデータベースに接続されます。以前のバージョンでは、間違って従サーバのデータベース
に入力してトラブルになる事もありました。
Ver4.3.0からlocalhostのまま従サーバのデータベースに接続しても、「従サーバへ接続しています。」と表示され、
「01 医事業務」ボタンが無効になっるようになっています。ですから、従サーバのデータベースに入力できないようになっています。
ただ、起動のタイミングとかによっては主サーバを起動していても、従サーバのデータベースに入力可能になることもあります。
従サーバの電源を入れ、次に主サーバの電源を入れてきちんと起動してる事を確認の上、従サーバのglclientを起動させれば
従サーバのデータベースに入力可能な状態になることはありません。
従サーバのデータベースに入力したい場合、主サーバを起動させずに従サーバ単独で起動すれば可能です。
主サーバが故障になり従サーバで業務を続けるには、主サーバの電源を切り、従サーバを再起動させれば「従サーバへ接続しています。」
の表示は消え従サーバのデータベースに入力可能になります。
４．日常業務（データのバックアップ）
Ver4.3.0からは自動的にデータのバックアップを取る機能が追加されています。
私の所では、毎日終了時に外付けHDにdumpファイルを保存するシェルスクリプトを作成して外付けHDにバックアップ
を取っています。そして、週１回だけ、USBメモリを利用してバックアップORCAにデータ移行させています。
障害時にdumpファイルがあれば、レセプトデータは復元できます。
主サーバあるいは従サーバどちらかが故障した場合は、正常なパソコンでdumpファイルを作り復旧させます。
主、従両方のサーバが壊れた場合は、保存して置いたdumpファイルから復元することになります。
ただし、保存した時期と壊れて時期との差分のデータが失われることになります。
１）バックアップORCAへのdumpファイルの移行方法
1.dumpファイルの作成
運用ORCAの主サーバでdumpファイルの作成します。
ユーザ名：# sudo -u orca pg_dump -O orca > ******.dump
ユーザ名：$ sudo -u orca pg_dump -O orca > ******.dump
/home/「ユーザ名」に******.dumpができます。
＃でファイル作成した時は、アクセス権がrootになります。
＄でファイル作成した時は、アクセス権がユーザになります。
＃でファイル作成しても、アクセス権のないファイル・ブラウザ（ユーザ使用）でもコピーきますので問題ありません。
おそらく、ユーザ名の所にファイルを置いてるためUSBメモリにコピーできるのかと思います。
この場合アクセス権rootのファイルは、コピーするとアクセス権がユーザに変わります。
＃でファイル作成したdumpファイルを違う場所に置いてる場合は、ファイル・ブラウザ（root使用）でなければ
USBメモリにコピーできません。そして、コピーしたファイルのアクセス権がrootになります。
アクセス権がrootのファイルを他のパソコンにコピーする場合は、ファイル・ブラウザ（root使用）でなければできません。
ユーザ名：$ sudo -u orca pg_dump -O orca > ******.dump
上記でdumpファイルを作った方が無難と思います。
＜備考＞
マスター更新の時は以下の記載があります。
*******************************************************
* 注意
*
* 処理を行うまえにはバックアップをとることを推奨します。
* バックアップの方法
* ktermなどから以下のコマンドを入力します。
* (sarge/etch)
* $ pg_dump -O orca > バックアップファイル名
*
*******************************************************
これがうまくできなく、相談する方がいます。
これはorcaユーザで実行しなければいけないので、そのまま入力してもうまくいきません。
以下を実行してorcaユーザになる必要があります。
$ sudo su orca
Password:ユーザのパスワード
orca@****: /home/ユーザ名 $ pg_dump -O orca > バックアップファイル名
orcaユーザにならずに実行するには
ユーザ名@****:$ sudo -u orca pg_dump -O orca > バックアップファイル名
2.USBメモリ
作成したdumpファイルをコピーするため、USBメモリを接続します。
「アプリケーション」−＞「システムツール」ー＞「ファイルブラウザ」があります。
このファイルブラウザを使って、******.dumpを右クリックして「コピー」を選びます。
次にUSB DISKを左クリックして、画面上で右クリックして「貼り付け」を選びます。
これでUSBメモリに******.dumpが保存されます。アイコンの移動でもコピーできます。
USBメモリはすぐに抜くと保存されていないことがあるので、ある程度時間をおいて抜いた方がいいです。
3.dumpファイルを受け取ったパソコン側の処理
受け取るパソコンにUSBメモリを接続して、/home/「受け取るユーザ名」に******.dumpをコピーして貼り付けます。
バックアップ用パソコンの主サーバでの処理
# /etc/init.d/jma-receipt stop
# sudo -u orca dropdb orca
# sudo -u orca createdb orca
# sudo -u orca psql orca < ******.dump
# /etc/init.d/jma-receipt start
これで、バックアップ用パソコンの主サーバにデータベースが移行します。
１台のみの構成であればこれで終了です。２台構成ですので、次に主従データベースの同期を取ります。
＜注意．１＞
時にコピーした******.dumpがおかしく # sudo -u orca psql orca < ******.dumpでエラーを起こすことがあります。
その時は、USBメモリのデータをWindowsで削除して、再度******.dumpをコピーして上記を行っています。
正しいデータを移さないとデータベースは壊れたままです。
なお、同期の所に書いてるようなERROR、WARNINGが表示されても問題ありません。
＜注意．２＞
この方法では、一見更新されたプログラムパッチも移行しているように表示されます。
しかし、実際はプログラム更新しないとパッチはインストールされていませんので、更新の必要があります。
マスタ更新に関しては移行してるかと思いますが、更新した方が無難と思います。
２）主サーバからdumpファイルを他のパソコンに送る方法
ルータに接続してdumpファイルを他のパソコンに送る方法です。
USBメモリで用が済むのであれば使う事もないかと思いますが、何かだめな場合のための方法です。
主サーバで
$ scp ******.dump 「受け取るユーザ名」@192.168.**.**:/home/「受け取るユーザ名」
192.168.**.**：「受け取るユーザのＩＰアドレス」
password:「受け取るユーザパスワード」
これで、「受け取るユーザのパソコン側」に******.dumpが移行します。
ただし、データを受け取る側で# aptitude install sshしていないとscpを使えません。
セキュリティを考えるなら用が済んだら、sshは削除した方がいいです。
# apt-get remove ssh
＜備考＞
rootでファイルを送る場合。
imageファイルを転送した例。
# scp -r /home/orca/image/ root@192.168.**.**:/home/orca/
root@192.168.**.**'s password:データ受け取るパソコンのrootパスワード
192.168.**.**は、データ受け取るパソコンのＩＰアドレス
３）自動的データのバックアップ
2重化運用を正しく利用するためのサンプルスクリプト(sarge版)
ここに自動的にdumpファイルのバックアップを取るスクリプトが記載されてあります。
Ver4.3.0より上記スクリプトの機能が実装されていますので、この機能を利用してデータのバックアップとる事もできます。
システムパッケージリリース情報（Version 4.3.0）
上記ｐ１３５の「(6)バックアップボタン＆cron 設定」に解説があります。
私の所では２４時間電源を入れているわけでありません。また、dumpファイルを作成しただけでは、パソコンが壊れればデータが
失われます。
そこで、サンプルスクリプトを改良し終了時にdumpファイルを作成して、外付けのHDにバックアップするスクリプトを作り利用しています。
終業時にアイコンをクリックするだけで、dumpファイルが作成され外付けのHDにデータ保存され、自動的にパソコンの電源が落ちます。
ダウンロードファイルを用意してありますので、ダウンロードして一部書き換えることにより、このスクリプトが利用できます。
「４．dumpファイルのバックアップNo.2」
４）頻度学習辞書のバックアップ
ｃａｎｎａの辞書の頻度学習辞書が/var/lib/canna/dic/user/ユーザ名/以下にfrq1.cld からfrq8.cldまであります。
一応バックアップ取っておいた方がいいかと思い、時々主サーバのファイルをUSBメモリにバックアップしています。
このファイルは主サーバが更新されれば、従サーバも自動に更新されるわけではありません。薬剤情報の画像ファイルと
同じでコピーしない限り従サーバのファイルが主サーバと同じになることはありません。
これらのファイルを従サーバにコピーしなくても日常業務に支障はありません。ただ、主サーバが故障になり従サーバで
業務を続けた時に、主サーバと違いいつも使っていた漢字がスムーズに出てこない可能性があります。
大きな支障にはならないと思いますがバックアップだけ取ってます。
従サーバにコピーする場合は、「１．Etch版ORCAインストール」−＞「３．薬剤情報マスタ登録」の
「２）USBメモリーを使った任意の画像データ登録方法」と同じような方法でできます。
「ファイルの所有者」：canna-Canna server、「ファイルのグループ」：cannaに変えます。
たた、コピーはできますが、うまく動いているかどうかは確認が難しいです。
今のところ、データ保存だけで従サーバにコピーはしていません。主サーバが壊れて従サーバで運用して漢字がでにくい
などの不都合がでれば保存したデータをコピーするつもりです。
５．日常業務（日医レセプトのマスタ等の更新）
マスタ更新やプログラムパッチ提供等のアナウンスがあれば更新します。
主サーバだけでなく、従サーバも必要な項目は更新しています。更新しなくても日常業務には問題ないかもしれませんが、
主サーバがトラブルになった際にすぐに従サーバが使えるように日頃から同じ状態にしていた方がいいと考えています。
更新する順番は、従サーバを更新してから主サーバを更新しています。どちらからでもいいかと思うのですが何となくです。
jma-receiptを停止するとか特別なことせずに更新しています。
１）マスタの更新
日医レセプトの業務メニュー画面より「９２マスタ更新」を選び更新します。
dumpファイルのバックアップをとってから、主サーバでのみ更新しています。
マスターの更新のアナウンスの際、バックアップ取るようにとの指示がありますので不都合が生じることもある
のだろうと思います。
主サーバを更新すると従サーバも更新されます。
Ver4.3.0よりマスタ更新の自動化ツールが提供されています。
システムパッケージリリース情報（Version 4.3.0）
ｐ１３６に「(7)マスタ更新の自動化ツール提供」に解説があります。
これを導入するのであれば、ｐ１３５の「(6)バックアップボタン＆cron 設定」にあるdumpファイルの自動作成も
設定した方が安全と思います。
２）プログラムの更新
日医レセプトのマスターメニュー画面より「０３プログラム更新」を選び更新します。
主サーバ、従サーバともにプログラムの更新をしています。
従サーバをクライアントとして設定してる場合は、glclientランチャーのホストをlocalhostに戻して従サーバの
データベースに接続する必要があります。
ランチャーを作成するのも一つの方法です。
画面を右クリックして「ランチャの生成（A)」をクリックします。
名前（N):従サーバ接続など適当に名前を付けます。
コマンド（A):glclient -user ormaster -pass ****** panda:orca00
アイコン（Ｉ）：対応するアイコンを適当に選びます。
「端末内で起動する」にチェックを入れます。
これで、アイコンのクリックだけで従サーバのデータベースに接続できます。
３）帳票の更新
以前のtgzファイルが残っていれば、ファイルブラウザを使って削除します。
帳票ディレクトリ（jma-std-nikkeigekkiなど）は削除しなくても問題はないようですが、削除しています。
削除しない場合、古いバージョンのプログラムも残ります。
次に、新しい帳票のtgzファイルをダウンロード、展開してインストールしてます。
特に古いものをアンイストールしてから、新しくインストールする必要はありません。
主サーバ、従サーバともに同じ事しています。
４）地域公費対応プログラムの更新
青森県版の場合は、手順書に従って以前のプログラムをアンインストールしてから新たにインストールしてます。
「１．Etch版ORCAインストール」にアンインストール、インストール方法を書いてあります。
帳票の更新と同じように以前のtgzファイル、ディレクトリを削除して、新しいtgzファイルをダウンロード、展開して
インストールしてます。
主サーバ、従サーバともに更新しています。
６．日常業務（主従のデータベースの不整合が生じた時の対応）
主サーバに「主従のデータベースに不整合が発生しています」これが表示された場合、従サーバのデータに欠落
（主サーバと従サーバのデータの不一致）が生じている可能性があります。
私の所では２４時間電源入れているわけでないので、再起動時「主従のデータベースに不整合が発生して
います」が表示されなくなります。しかし、表示がされなくなったから不整合が改善されたとい訳でないので、
必ず同期を取っています。
「不整合が発生」が表示されてからはデータは移行しないようです。
再起動して「不整合が発生」が消えてからはデータは移行してるようです。
１）電源を入れる順番
先に従サーバの電源を入れます。従サーバの起動終了した後に、主サーバの電源を入れます。
2台運用の状態取得
上記にあるように順番が逆なら「リダイレクタ接続待ちです」と表示されます。
２）主従データベースの同期方法
１．手順書ｐ４９の「５．５主従データベースの同期の取り方」の方法で同期
# /etc/init.d/jma-receipt stop
# sudo -u orca pg_dump -c -O orca | tee /tmp/orca_db_`date +%Y%m%d`.dump |
sudo -u orca psql -h 192.168.**.** -W orca
# /etc/init.d/jma-receipt start
２．
正常なサーバーより、データベースの内容をコピーする方法
「障害時の対応の解説」にある同期を取る方法です。
主サーバで
$ sudo -u orca pg_dump -O orca > ******.dump
******.dumpファイルをUSBメモリを使って従サーバに移すか、下記の方法で移行させます。
$ scp ******.dump 「受け取るユーザ名」@192.168.**.**:/home/「受け取るユーザ名」
従サーバで
# /etc/init.d/jma-receipt stop
# sudo -u orca dropdb orca
# sudo -u orca createdb orca
# sudo -u orca psql orca < ******.dump
# /etc/init.d/jma-receipt start
日常業務で主従の同期をとる時は、私は１の方法で取ってます。
＜備考＞
Sarge版ORCAの解説に書いてありますが、途中以下の表示
ERROR: must be owner of schema public
ERROR: schema "public" already exists
最後に
WARNING: no privileges could be revoked
WARNING: no privileges were granted
表示されますが同期に失敗したわけでありません。
３）不整合時のorca.logファイル処理
/var/lib/jma-receipt/dbredirector/orca.log
ここに主サーバから従サーバへのデータ送信のログファイルが記録されてあります。
2台運用の状態取得
「不整合が発生」には「不整合後同期し直した後はorca.logを削除するかリネームしておくと再同期すべきか判断できる」
と記載あります。
今の所、私はログファイルの処理は何もしていません。
事務から「不整合が発生」が出たと報告があれば、診療終了後にログファイル確認することなく同期をとっています。
７．日常業務（ログファイル等）
ログファイル等の処理をどうするかについては、手順書等に書かれていません。
１）dbredirectorのorca.logファイルの処理
/var/lib/jma-receipt/dbredirector/orca.log
Re: orcaの 動作が鈍くなる
以前のバージョンの日医レセプトソフトでは、このlogファイルの容量が大きくなり動作が遅くなるという事が
あったようです。
sarge版から「dbredirectorのログのローテーション」でorca.logファイルが最近の７日分だけが保存
されるようになり、ログファイルのクリアの必要が無くなったようです。
私の所では２４時間電源を入れているわけでないのですが、logファイルは自動的に圧縮保存されています。
logファイルは７日分保存されています。当日以外の６日分は圧縮されているのであまり容量はとっていません。
２４時間電源を入れてる場合は、どうなるかは分かりません。
少なくとも私の場合は容量は大きくなることはなさそうですが、何か動作がおかしい時はこれをチェックする
つもりです。
２）/varのデータの処理
Re: /var のデータ量
/var/logにあるsyslogもorca.logと同じように８日分保存されていて、６日分が圧縮保存されています。
syslogが当日のログ、syslog.0が前回のログ、後は圧縮された６日分です。
これも２４時間電源を入れてる場合は、どうなるかは分かりません。
容量が大きくなることはなさそうですが、何か動作がおかしい時はチェックするつもりです。
３）vaccum処理
Re: 動作が 遅くなる
前バージョンの日医レセプトは自動的にvaccum処理が行われていました。現バージョン4.2.0でも同じように
０時、５時、１０時、１５時、２０時にvaccum処理が行われます。私の所では２４時間接続してませんが
１０時、１５時に自動的にvaccum処理が行われますので不都合は生じないと思います。
実際、今のところ問題は発生していません。
Re: Version2.8 の医薬品マスターについて
時には、手動でvaccum処理しなければいけない場合があるようです。
今の日医レセプトはpostgresql-8.1を使っていますので若干変わっているようです。
/etc/cron.d/postgresql-common このファイルを見ると
１）# sudo -u postgres /usr/sbin/pg_maintenance --analyze >/dev/null
という事になるかと思います。
２）# sudo -u postgres /usr/lib/postgresql/bin/do.maintenance -a
２）でうまくいくのであればいのですが、だめであれば１）の方法になるかと思います。
試していませんので、他の情報で確認して自己責任で実行して下さい。
８．ソフトの更新（パッケージのアップグレード）
アップデートマネージャーが赤く表示されていれば、更新パッケージがあることになります。
パッケージには、日医レセプトソフトに関係したものとDebian-Etchに関係したものがあります。
日医レセプトソフトに関係したものとは、プログラムパッチ提供とは別の関連パッケージです。例えばpandaパッケージなど。
いずれも、アップデートマネージャーを使うとアップグレードできまし、アップグレードしたいものだけ選ぶこともできます。
問題は、総てアップグレードしていいかです。
日医のアナウンスがあった日医レセプトパッケージだけ選んでアップグレードするという方法もあるかもしれませんが、
私はセキュリティーホールがあればこまるので、全部アップグレードしています。
普通にEtchをインストールして、無線LANや特別な設定したプリンタを使ってない場合は心配ないのではと思っています。
特殊な方法（私がSargeの時に、したような一般的でない方法）でEtchをインストールしたとか、カーネルに指定した設定
（例えば無線LAN)をした場合にトラブルが起こりそうな気がしてます。実際、無線LANでは不調を起こした設定方法もあります。
Ｈ２０年８月２６日にパッケージのアップグレード後に、軽いトラブルを起こしたパソコンがありました。
パッケージのアップグレードが原因と断定はできませんが、「４．ORCA導入、運用の経過、トラブル」に記載してあります。
日医レセプトソフト（jma-receipt）もアップデートマネージャーでバージョンアップされます。
ただ、jma-receiptのバージョンアップの際は事前のチェックとか準備が必要です。
不用意にアップデートマネージャーでバージョンアップすればjma-receiptもバージョンアップされてしまいます。
無用のトラブルを避けるのであれば、jma-receiptのバージョンアップのアナウンスがあれば慎重に対応する必要があります。
注意した方がいいかもしれなDebian-Etchパッケージ
１）カーネル関係
1.linux-image-2.6-686
2.linux-image-2.6.18-6-686
2.6.18-5-686で設定した無線LANは、2.6.18-6-686でも動くものもあれば動かないものもあります。
新しいカーネルで運用するため、2.6.18-6-686で動くように再設定しています。
そして、GRUBのmenu.lstを編集して古いカーネル2.6.18-5-686がメニューに表示されないようにしてます。
今は、Etchをインストールすれば、2.6.18-6-686のみになっています。2.6.18-5-686は表示されないのでインストール
されていないと思います。
２）ビデオカード関係
1.xserver-xorg-core
これは、パソコンにより違いますのでテストのしようがありません。
おかしくなったら下記の方法で再設定すれば大丈夫でないかと思います。
＃ dpkg-reconfigure xserver-xorg
詳しい設定方法は、Sarge版ORCAの手順書に書いてあります。総て同じという訳でありませんが設定の参考になります。
ただ、Sarge版は＃ dpkg-reconfigure xserver-xfree86ですが、Etch版はxserver-xorgです。
３）プリンタ関係
1.gs-esp（Ｈ２０年３月２日）
gs-espをアップグレードするとトラブルになる事もあるようです。
gs-espのセ キュリティーアップデート に関する注意事項
私は「Canon-LBP3410」を使っていますが、私の設定方法ではアップグレードしても問題なく印刷できています。
ただ、Etch版は心配ないようですがSarge版ではやっかいのようです。
以下に書かれてありますので、慎重に対処した方がいいようです。
ghostscriptの脆弱性によるORCAへの影響
2.cupsys-***、lbcupsys2-***（Ｈ２０年３月２９日）
プリンタに関係したパッケージですが、私の場合はアップグレードしても問題は起こってません。
設定段階で
# aptitude install libcupsys2-gnutls10
を実行していたので、影響あるかなと心配してのですが問題ありませんでした。
ただ、Ｈ２０年３月１７日に新しいプリンタドライバVer1.6が公開されています。
私が使ってるのは、Ver1.5です。
パッケージのアップグレードや日医レセプトソフトのバージョンアップは、テスト用パソコンで異常が起こらないか
確かめてから運用ORCAのアップグレードしています。
運用ORCAが問題なく動くことを確認して、一番最後にバックアップＯＲＣＡをアップグレードします。
９．日医レセプトソフト（jma-receipt）のバージョンアップ
Ver4のjma-receiptのバージョンアップは、以下のように行われています。
（Ｈ２０年 ３月）Ver4.0.0−−＞Ver4.1.0−−＞Ver4.2.0と２回バージョンアップしてます。
（Ｈ２０年１１月）Ver4.2.0−−＞Ver4.3.0とバージョンアップしてます。
Ver4.2.0へのバージョンアップ：
システムパッケージリリース情報（Version 4.2.0）
Ver4.3.0へのバージョンアップ：
システムパッケージリリース情報（Version 4.3.0）
１）スキーマチェック
バージョンアップによる構造変更が失敗しないように、事前にチェックします。
データベーススキーマチェック
「orcaユーザにて /home/orcaで」とは以下の手順です。
$ sudo su orca
Password:「ユーザパスワード」
orca@****: /home/ユーザ名 $ cd /home/orca
次に以下を実行します。
orca@****: ~$ wget http://ftp.orca.med.or.jp/pub/etc/jma-receipt-dbscmchk.tgz
orca@****: ~$ tar xvzf jma-receipt-dbscmchk.tgz
orca@****: ~$ cd jma-receipt-dbscmchk
orca@****:~/jma-rece-dbscmchk$ sh jma-receipt-dbscmchk.sh
バージョンアップ後に再起動して再度チェックします。
$ sudo su orca
orca@****: ~$ cd /home/orca/jma-receipt-dbscmchk
orca@****:~/jma-rece-dbscmchk$ sh jma-receipt-dbscmchk.sh
無事終了したら、次回のバージョンアップ時に混乱が起こらないようにjma-receipt-dbscmchk.tgzファイルと
jma-receipt-dbscmchkディレクトリは削除しておいた方が無難と思います。
間違って別なファイルなどを削除しないように注意が必要です。
orca@****:~/jma-rece-dbscmchk$ cd /home/orca
orca@****: ~$ rm jma-receipt-dbscmchk.tgz
orca@****: ~$ rm -r jma-receipt-dbscmchk
＜備考＞
スキーマチェックのファイルは、バージョンアップの時には更新されています。古いファイルではうまくいチェック
できません。
私は上記に書いてるように、Ver4.0.0からVer4.1.0へのバージョンアップの際のファイル等はすぐに削除しています。
そして、Ver4.1.0からVer4.2.0へのバージョンアップの際には新たにファイルをダウンロードしています。
＜Ver4.1.0からVer4.2.0へバージョンアップ時のスキーマチェック＞の例
バージョンアップする前のチェックではスキーマーバージョン4.1.0と表示されます。
そして、バージョンアップ後のチェックではスキーマーバージョン4.2.0と表示されます。
２）バージョンアップ
バージョンアップの解説書ある手順。
# aptitude dist-upgrade -dy
# aptitude dist-upgrade
アップデートマネージャーでもバージョンアップできます。
ただ、注意が必要なのはjma-receiptの「データベース構造変更処理を自動で実行しますか？。」の設定がどうなってるかです。
私の場合、「データベース構造変更処理を自動で実行しますか？。」を主サーバでは＜いいえ＞
、従サーバは＜はい＞にしています。
従ってこの設定では、主サーバは自動的に構造の更新はしません。
「データベース構造変更処理を自動で実行しますか？。」を＜はい＞に設定していれば自動的に構造更新します。
# dpkg-reconfigure jma-receipt
従サーバは、上記を実行していないので初期状態の＜はい＞に設定になっています。
＜従サーバ＞
アップグレード後、jma-receiptは停止状態ですので以下を実行します。
# /etc/init.d/jma-receipt start
それでもだめなら、再起動します。
＜主サーバ＞
jma-receipt以外のパッケージはうまくインストールされます。
詳細を表示していれば「No good」と表示され、jma-receiptの構造変更処理の失敗が表示されます。
以下でインストールします。
# sh /usr/lib/jma-receipt/bin/jma-receipt-db-setup.sh
# /etc/init.d/jma-receipt start
または、
# dpkg-reconfigure jma-receipt
この設定で「データベース構造変更処理を自動で実行しますか？。」を＜はい＞にして更新するかです。
３）改訂時の感想
Ｈ２０年３月３１日 初めての改訂の経験なのでどうなるかと思っていました。従来のレセコンは業務終了後に
新しいソフトをインストールしますので、業務終了後にマスター更新でもするものと思っていました。
回線が混んだら何時間もかかるのかとなどと心配していたのですが、実は既に改訂版がインストールされていると
知った時は一安心でした。
テスト用のパソコンで帳票印刷のテストしていた事務が、日付を４月に変えると新しい点数が出ると気づき
既に改訂版がインストールされていると知りました。
おかげで設定もスムーズに進み、改訂を乗り越えることができました。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
（Ｈ２０年 ２月１１日記）
（Ｈ２０年 ３月 ５日）「７．日医レセプトソフト（jma-receipt）のバージョンアップ」を追記
（Ｈ２０年 ３月２０日）「１．ORCAの構成」に「外付けハードディスク」を追記
（Ｈ２０年 ４月 ３日）「７．日医レセプトソフトのバージョンアップ」に「改訂時の感想」追記、「７．その他の更新」追記
（Ｈ２０年 ５月３１日）項目再編成と「３．日常業務（データのバックアップ）」に「頻度学習辞書のバックアップ」追記
（Ｈ２０年 ７月１６日）「４．日常業務（日医レセプトのマスタ等の更新）」に「４）地域公費対応プログラムの更新」追記
「３．日常業務（データのバックアップ）」の「３）頻度学習辞書のバックアップ」に追記
（Ｈ２０年 ７月２３日）「６．日常業務（ログファイル等）」追記
（Ｈ２０年１２月 ８日 Ver4.3.0変更に伴う内容変更
ここに書かれていることを行って、何か被害にあっても責任はもてませんので自己責任で行って下さい。
*
娯楽室の各部屋
