« 2014年11月 | トップページ | 2015年2月 »

2014年12月

2014年12月24日 (水)

Yosemite で Server.app (v4.0) の postgres を使う

OS X Server version 3.2.2 の postgres だけを無理矢理 Yosemite で起動することに成功していたが,やっぱりちゃんと新しい Server を買おうと思って,Server.app 4.0 を購入した。

ところが,起動して調べてみると・・・

$ sudo serveradmin status postgres
postgres:error = <62706c69 73743030 d4010203 04050618 19582476 65727369 6f6e5824 6f626a65 63747359 24617263 68697665 72542474 6f701200 0186a0a4 07081112 55246e75 6c6cd409 0a0b0c0d 0e0f1056 4e53436f 64655a4e 53557365 72496e66 6f584e53 446f6d61 696e5624 636c6173 73100180 00800280 035f1014 636f6d2e 6170706c 652e7365 72766572 6d677264 d2131415 165a2463 6c617373 6e616d65 5824636c 61737365 73574e53 4572726f 72a21517 584e534f 626a6563 745f100f 4e534b65 79656441 72636869 766572d1 1a1b5472 6f6f7480 0108111a 232d3237 3c424b52 5d666d6f 7173758c 919ca5ad b0b9cbce d3000000 00000001 01000000 00000000 1c000000 00000000 00000000 00000000 d5>
postgres:errorDescription = "The operation couldn’t be completed. (com.apple.servermgrd error 1.)"
postgres:errorCode = 1

起動していない? サービスのリストを確認すると,postgres がなくなっている!!

$ sudo serveradmin list | grep postgres
$

でも ps を見てみると

$ ps aux | grep postgres
/Applications/Server.app/Contents/ServerRoot/usr/bin/postgres_real -D /Library/Server/Wiki/Database.xpg/Cluster.pg -c log_line_prefix=%t -c log_lock_waits=on -c log_statement=ddl -c logging_collector=on -c max_connections=500 -c unix_socket_directories=/Library/Server/Wiki/PostgresSocket -c unix_socket_group=_teamsserver -c unix_socket_permissions=0770 -c log_connections=on -c listen_addresses= -c log_directory=/Library/Server/Wiki/Logs -c log_filename=postgres-%a.log -c log_rotation_age=1440 -c log_truncate_on_rotation=on

起動している。しかし,起動オプションをよく見てみると

-D /Library/Server/Wiki/Database.xpg/Cluster.pg

Wiki だけのために立ち上がっているようだ。どうやら,新しいサーバでは Server.app のサービスだけが postgres を使えるという仕組みになってしまったようだ。そんな・・・。仕方がないので,Server 3.2.2 と同じように postgres だけ立ち上げることにした。

インストールした OS X Server を,なかったことにする方法

  1. /Applications/Server.app を移動する
    $ sudo mv /Applications/Server.app ~/tmp/
    
  2. /Library/Server を削除する
    $ sudo rm -rf /Library/Server
    
  3. 再起動する
  4. Server.app を元に戻す
    $ sudo mv ~/tmp/Server.app /Applications/
    

あとは,/Library/Server/PostgreSQL/Data フォルダを作って,3.2.2 と同じように設定する。postgres のバージョンは 9.3.5 になっていた。

$ sudo -u _postgres psql -U dolphin dolphin
psql (9.3.5)
Type "help" for help.

dolphin=>

・・・多分 Server.app の使い方としては間違っている。

2014年12月22日 (月)

Yosemite で Server.app (v3.2.2) の postgres を起動する

Yosemite にアップグレードしてふと Application フォルダを見てみると・・・

Server

Server.app が使えなくなっていた。もともと,Server.app は dolphin server を mac で起動するのに postgres が必要だったために購入したものなので,とりあえず Server.app 内の postgres だけ動かすことにした。

まず,postgres がどうなったか調べてみると

$ sudo serveradmin status postgres
postgres:state = "STOPPED"
$ sudo serveradmin start postgres
postgres:error = "CANNOT_START_SERVICE_TIMEOUT_ERR"

当然,postgres は起動しない。そこで,直接 Server.app 内の postgres を起動してみる。

$ sudo -u _postgres /Applications/Server.app/Contents/ServerRoot/usr/bin/postgres -D /Library/Server/PostgreSQL/Data -k /var/pgsql_socket/
FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 9.2, which is not compatible with this version 9.3.4.

postgres のバージョンがいつの間にか 9.2 から 9.3.4 に上がってしまっていた。仕方がないので,一旦データベースを消去して作り直すことにする。

$ sudo rm -rf /Library/Server/PostgreSQL/Data
$ sudo mkdir /Library/Server/PostgreSQL/Data
$ sudo chown -R _postgres:_postgres /Library/Server/PostgreSQL
$ sudo -u _postgres /Applications/Server.app/Contents/ServerRoot/usr/bin/initdb -D /Library/Server/PostgreSQL/Data

The files belonging to this database system will be owned by user "_postgres".
This user must also own the server process.

The database cluster will be initialized with locale "ja_JP.UTF-8".
The default database encoding has accordingly been set to "UTF8".
initdb: could not find suitable text search configuration for locale "ja_JP.UTF-8"
The default text search configuration will be set to "simple".

Data page checksums are disabled.

fixing permissions on existing directory /Library/Server/PostgreSQL/Data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
creating configuration files ... ok
creating template1 database in /Library/Server/PostgreSQL/Data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating collations ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
loading PL/pgSQL server-side language ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    postgres -D /Library/Server/PostgreSQL/Data/ -k /Library/Server/PostgreSQL/Data/
or
    pg_ctl -D /Library/Server/PostgreSQL/Data/ -l logfile -o "-k /Library/Server/PostgreSQL/Data/" start

これで postgres が起動するようになる。

$ sudo -u _postgres /Applications/Server.app/Contents/ServerRoot/usr/bin/postgres -D /Library/Server/PostgreSQL/Data -k /var/pgsql_socket/
LOG:  database system was shut down at 2014-12-22 11:09:41 JST
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

dolphin データベースをバックアップから復旧する

$ sudo -u _postgres createuser dolphin
$ sudo -u _postgres createdb -O dolphin dolphin
$ sudo -u _postgres /Applications/Server.app/Contents/ServerRoot/usr/bin/pg_restore -Fc -d dolphin dolphin_db.dump
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1409594; 0 0 ACL public postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  role "postgres" does not exist
    Command was: REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
...
WARNING: errors ignored on restore: 1

psql で確認してみる

$ sudo -u _postgres psql -U dolphin dolphin
psql (9.3.4)
Type "help" for help.

dolphin=> \d
 public | d_admin            | table    | dolphin
 public | d_admin_comment    | table    | dolphin
 :

無事 postgres だけ起動できるようになった。

2014年12月19日 (金)

orca api の仕様変更(4)

  • ORCA の 2014/11/25 の orca api の仕様変更でもう一つ不具合がおきた。初診で受給者番号未記入の生保の患者さんを受け付けた際に,保険組み合わせが 0000 となってしまった。
     受付の CLAIM では,受給者番号未記入の場合 "mikinyu" という文字列が送られてくる。これまではこれをそのまま api に送っても大丈夫だったが,仕様変更で受け付けなくなってしまった。受給者番号が "mikinyu" の場合,空文字 "" に置き換えるようにした。

    OrcaApiElementXml2.java

    public static class PublicInsurance_Information extends Element {
      :
      for(PVTPublicInsuranceItemModel m : models) {
      :
        // 生保受給者番号未記入の場合,"mikinyu" という文字列が入っているが,2014/11/25 の orca api 仕様変更で受け付けなくなった
        String jukyushaBango = "mikinyu".equals(m.getRecipient())? "" : m.getRecipient();
        record.addContent(new Element("PublicInsuredPerson_Number").setAttribute("type", "string").addContent(jukyushaBango));
      :
    
  • さらに,保険証忘れで自費受付した初診患者さんの場合,保険者番号「9999」,保険記号・番号「記載なし」という文字列が送られてくることも判明し,これも対応した。
    public static class HealthInsurance_Information extends Element {
      :
      // 自費の場合は,Number "9999",Person_Symbol および Person_Numver に "記載なし" という文字列が入っているが,2014/11/25 の orca api 仕様変更で受け付けなくなった
      String number = "9999".equals(model.getInsuranceNumber())? "" : model.getInsuranceNumber();
      String personSymbol = "記載なし".equals(model.getClientGroup())? "" : model.getClientGroup();
      String personNumber = "記載なし".equals(model.getClientNumber())? "" : model.getClientNumber();
      :
      addContent(new Element("InsuranceProvider_Number").setAttribute("type", "string").addContent(number));
      addContent(new Element("HealthInsuredPerson_Symbol").setAttribute("type", "string").addContent(personSymbol));
      addContent(new Element("HealthInsuredPerson_Number").setAttribute("type", "string").addContent(personNumber));
      :
    

2014年12月 9日 (火)

orca api の仕様変更(3)

ORCA の 2014/11/25 のパッチでまた orca api の仕様変更があった。アップデート後,中途終了データで国保の保険情報が送られなくなり,保険組み合わせが 0000 となってしまう事態が発生した。
 受付から送られてくる CLAIM では,国保の ClassCode が 00 となっているが,これを中途終了 API にそのまま 000 で返していたのが原因であった。これまでは ORCA 内部で良きに計らってくれていたようだ。060 を返すように変更した。

OrcaApiElementXml2.java

private static String convertToOrcaInsuranceClassCode(String claimInsuranceClassCode) {
  :
  if (claimInsuranceClassCode.equals("00")) { return "060"; }
  :
}

« 2014年11月 | トップページ | 2015年2月 »