【92】ArchivematicaのArchival Storageについて考える

 始まりました。人数も少ないですし、地震もきましたし、サッカーも相手へのナイス・パスで負けたので、まったりいきます。

本日のテーマは！それは！！なんと！！まさかの！！！

これから考えます！

という会になりました。

ずーっとああでもない、こうでもないっていう話を。
頭のなかが… Storage 管理に関するサードパーティーのアプリケーションを入れ込んで欲しいのですが、お金がかかるものが多くワレワレのような貧乏人には無料じゃないと…（涙

ん～・・・ってことで、1.5h話し合ったところで決まりましたよ！
ドラムロールスタート！ｄｒｄｒｄｒｄｒｄｒｄｒdrdrdrdr....daaaaan!

LOKKS！！

に決まりました！！！
詳細は、GitHub（https://github.com/lockss/lockss-daemon）をご確認ください。
みんなで見てると、いろいろと意見が…ここで決めてくれ！！（祈

ん。。。だめ。。。なのか。。。また。。。なのか。。。…

LOKKSつかってOAIS参照モデルって…
ネットワーク入れば簡単にできるんじゃね？…
本来はe-Journalを管理できるように作られたんですよね？
そうそう、そんで他にも使うことができるから派生シテ…
etc. など、

あれれ。。。

それはそうと、こんなんのもあるよ！（file:///C:/Users/hori6/Downloads/iprespaper-finaledit.pdf）
おお～！！OAISの図がカックイイ！！

とか。

ペーパーに文脈関係ないのに、自分の写真出しちゃうやつって。。。←これはH（私）

とか。。。これは、LOKKSは止めるのか。。。
ここで急浮上！

iRODS！！

もう。。。追えないよ。。。
ってなか、みーーーーんな、勝手にiRODSのことをバンバン調べだし、笑うくらい五月雨式に話だすっていうリモートの"マナー”に違反しまくり…

ってことで、

First！　iRODS

Second！ LOKKS

に。

ってことで、次回までに読むものリストです。
https://arodes.hes-so.ch/record/1907/files/makhlouf_research_data_management_switzerland_2017.pdf

https://docs.irods.org/4.2.10/

https://sciencenode.org/feature/isgtw-technology-taming-data-deluge-new-open-source-irods-data-grid-system.php

さーーがんばりましょう！！

次回は、恐らく22日です！！

【91】Archivmaticaで日本語のOCR認識（Tesseract利用）

今日は前回の続きのTesseractのテストです。

Archivemimaticaは、デフォルトでOCR認識用としてTesseractを使っています。基本は英語認識になっているので、日本語を認識できるようにしてみましょう！

Tesseractのファイルは、/usr/share/tesseract-ocr/ の下に実行ファイルがあります。まずは、そこをみてましょう。

学習した言語ファイルがあるところは、tessdataの中です。先週日本語版Tesseractを入れているので、下記には日本語認識に関わるファイルが存在している状態です。

各ファイルは以下のように関係しています。

jpn.traineddata：日本語

jpn_vert.traineddata：日本語（縦書き）

Japanese.traineddata：日本語

eng.traineddata：英語

osd.traineddata：文字の方向の判定

ここで日本語と英語のファイルをちょっといじってみます。Archivematicaでは英語だけを処理するように設定されているので、こっそりeng.traineddataの中身をjpn.traineddataにすり替えてテストしてみます。とりあえず、元のデータがなくなるとまずいので、eng.traineddata.originalにしておきます。

次に、eng.traineddataの中身をjpn.traineddataに入れ替えます。

このあと、Archivematicaに日本語文書のJPGファイルを入れてingestしてみます。

以下の画像をingestしました。

ingestしたJPGファイル

Transcriptionのマイクロサービスでは、Yesを選んでください。

結果は〜〜〜以下のように日本語を認識してくれました！

OCR認識で出力された結果

師匠ありがとうございます！これでTesseractの仕組みが少し理解できました！

今度は、ArchivematicaのPreservation planning からcommandを変更してみましょう。どちらかというとこちらが正式な方法です。先いじったファイルは元の状態に戻してから試してください。

Preservation planningでは、コマンドやルールの変更・追加ができます。マイクロサービスで行われる処理の中で正規化（Normalization）のようにルールが必要なタスクについては、行う処理内容をコマンドで書いて、実行する対象と結びつけます。これが、ルールというわけですね。

OCRの処理はTranscriptionのマイクロサービスで行われますので、TranscriptionのCommandを変更してみます。

関連マニュアルはここ↓
https://www.archivematica.org/en/docs/archivematica-1.13/user-manual/preservation/preservation-planning/#transcription-commands

以下が、Transcriptionのコマンドを変更する画面です。


上記のCommandの最後に　-l jpn を追記しました。languageをjpnにしてくださいというコマンドです。試した結果……成功しました！（^^）/

では、次は縦書きも試してみます。

今度は以下のコマンドを最後に入れてみます。

-l jpn +Japanese_vert

これも成功しましたが、縦書きの認識率は少し低いです。でも7割程度は認識しているように見えます。

日本語関係の学習ファイルが2つあったので、以下でも試してみます。

-l Japanese +Japanese_vert

そうすると、以下のように結果が少し異なりました。

左：jpn  右：Japanese

Japanese.traineddataの場合は日本語と英語の学習用テキストを混在した状態で学習させた代物ということらしいです。また、出力結果に余計な空白が含まれる問題があるとのことです。（それで右のJapaneseで試した結果がああなったわけね…）

参考サイト

https://a244.hateblo.jp/entry/2018/06/20/200000

今日はここまでです！

今日は意外と順調に進みました。いつもこうだといいですね〜〜

================================

10月8日（金）19：00〜

やることは後日連絡です。ではまたね〜

【90】Tesseractの日本語版を使い、Archivematicaで日本語をOCRする。

ほとんどやる気のないHが担当で、更新が遅れに遅れました。すみません。

Archivematicaには、画像（JPGやTIFFファイル）のOCR機能があります。オープンソースのTesseract (テッセラクト)を使っています。

https://www.archivematica.org/en/docs/archivematica-1.13/user-manual/ingest/ingest/#transcribe-contents

Tesseractのウィキペディア、https://ja.wikipedia.org/wiki/Tesseract_(ソフトウェア)

こちらhttps://www.kkaneko.jp/tools/ubuntu/tesseract.htmlを参照し、日本語読み取り可能なものを入れます。

$ sudo apt -y update

$ sudo apt -y install tesseract-ocr tesseract-ocr-jpn tesseract-ocr-jpn-vert libtesseract-dev libleptonica-dev tesseract-ocr-script-jpan tesseract-ocr-script-jpan-vert  

vertは縦書き、scriptは手書きに対応しています。

使用できる言語の確認

$ tesseract --list-langs

コマンドの確認

$ tesseract --help

画像を使ってテスト。次のコマンドで実行。

$ tesseract <対象とする画像ファイル名> <出力ファイル名(.txtは自動付与される)> -l jpn

最後の-l jpnで日本語対応。つけないと英語の認識になります。

読み取れたかどうか確認します。

$ less ファイル名.txt 

印刷の字体は、結構読めました。一方で、手書きの文章は、あまり認識できませんでした。

続いて、-l jpnと-l Japaneseの違いを検証しました。Japaneseの方が認識している量が多いことが判明。

Archivematicaで実際にテストしました。Archivematicaのマニュアル該当箇所は次のページ。

https://www.archivematica.org/en/docs/archivematica-1.13/user-manual/administer/dashboard-admin/#processing-configuration

Micro-servicesを進めて作成されたAIPを確認。AIP内に、Objects>Metadata>OCRというディレクトリーあり。

確認すると英語しか認識していないことが判明。

Archivematicaのコマンド上の標準設定が英語になっていると推測。

設定ファイルを確認する。https://blog.machine-powers.net/2018/08/02/learning-tesseract-command-utility/ により、/usr/share/tesseract-ocrにあることをわかる。

見てもよくわからず。

TesseractのGUIツールであるgImageReaderで環境設定できないかを検討。https://websetnet.net/ja/use-gimagereader-to-extract-text-from-images-and-pdfs-on-linux/

$ sudo apt -y install gimagereader

日本語にはできませんでした。

わからなくなったので解散です。

後日談

師匠がArchivematicaでの日本語読み取りに成功。

Tesseractにデータが渡った時点でeng.traineddataを使って文字認識すると仮定。

元のeng.traineddataを名前の変更してjpn.traineddataにして文字認識させたら、英文も日本語も文字認識しました。

ちなみに、eng.traineddataとjpn.traineddataは

/usr/share/tesseract-ocr/4.00/tessdata/にあり。

【89】archivematica1.13.0へのアップデート：from 1.12.0 upgrade to 1.13.0

人が少ないながら今日もスタート。
前回出てないので「なんとも・・・」のなかなので、不適格なことがあったらすみません。

結論からいうと、最期の＜正解＞から見ていただければアップグレードはうまくいきます。

Ver. 1.12.0から最新Ver. 1.13.0へアップグレードです。
同じような問題を抱えている方がいたらしく、それに対するコメントにしたがって進めます。

ちなみに、参考にしたのは
https://groups.google.com/g/archivematica/c/QcRQobqdnU4?pli=1
https://docs.djangoproject.com/en/1.11/ref/django-admin/#showmigrations

です。

1.13のドキュメンテーション：Upgradeの手順を確認していきます。
https://www.archivematica.org/en/docs/archivematica-1.13/admin-manual/installation-setup/upgrading/upgrading/#upgrade

ここでは＜2．Update packages sources＞のコマンドに
"sudo -sh" を冒頭に入れます。すなわち、

 'echo "deb [arch=amd64] http://packages.archivematica.org/1.13.x/ubuntu bionic main" >> /etc/apt/sources.list'
sudo sh -c 'echo "deb [arch=amd64] http://packages.archivematica.org/1.13.x/ubuntu-externals bionic main" >> /etc/apt/sources.list'

としました。
結果は…

見事にエラーです。前回の復習的作業でした。

こっからです。
エラーの詳細を確認します。

sudo journalctl -u archivematica-mcp-server -xe

大量なエラーログの結果、

django.db.utils.OperationalError: (1054, "Unknown colum 'Transfers.status' in 'where clause'")

を確認しました。

ここから、mysqlでDBを確認。

sudo mysql -u root -p

Pass:

>mysql> show databases;

DB"MCP”をセレクトします。

mysql> use MCP;
ここで、次のTransfersを選択。

mysql> select * from Transfers;

と、カラだとのこと。が、並行に作業していたW氏のPCでは、

と、artefactuals社の返答の通りの表示に。ですので、ここからはW氏のPCに替えます。

次に、

https://www.archivematica.org/en/docs/archivematica-1.13/admin-manual/installation-setup/upgrading/upgrading/#upgrade-centos

のうち、"4"のコマンドを実行します。

実行すると、質問者と同じエラー表示が出ます。
ImportError: bad magic number in 'components.administration.management': b'\x03\xf3\r\n

そこで、指示通りに"*.pyc"ファイルをすべて削除するコマンドを実行します。

sudo find . -name "*.pyc" -exec rm -f {} \;

結果は。。。うまくいかず。。。これでうまくいったって言ってたじゃ無いOlixxx!!

ここで、mysqlにログイン

mysql> use MCP;

mysql> select * from django_migrations;

から、"81"が入ってないとならないので確認しましたが、ありません。。。

そこで、またまた質問に戻ります。再度、

sudo find . -name "*.pyc" -exec rm -f {} \;

から、”4”のコマンドを再実行します。

すると、いっぱい"OK"の文字が！！←W氏のオペレートは早すぎてキャプチャーできず。

ここで、再起動。

結果は。。。。うまくつながりました！！！！

＜正解＞

振り返りますと、

"Upgrad on Ubuntu packages"の手順"4"と"5"の間に下記のコマンドを実行します。

まず、Dashboardにcdします。

cd /usr/share /archivematica/dashboard/

次に、

sudo find . -name "*.pyc" -exec rm -f {} \;

を実行。

をし、ストレージサービス等のRestartをするとうまくいくということになります。

めでたしめでたし！！

【88】archivematica1.13.0へのアップデート

本日は参加者も少なく短時間で終わりました。お盆ですしね。その分、内容も短いです。

前回、1.12から1.13にアップデートしたところ、ダッシュボードの右上に、"Error trying to connect to MCP server. Trying again..."と表示されてしまいました。

どのようなエラーが起こっているかを確認します（日付は別の日となっていますが、道場当日に起こっていたものと同じです）。

ダッシュボードのエラー。

$ sudo journalctl -u archivematica-dashboard

 7月 02 19:47:52 matica-vm systemd[1]: Started Archivematica Dashboard.

 7月 02 19:47:52 matica-vm gunicorn[28503]: [2021-07-02 19:47:52 +0000] [28503] [INFO] Starting gunicorn 19.9.0

 7月 02 19:47:52 matica-vm gunicorn[28503]: [2021-07-02 19:47:52 +0000] [28503] [INFO] Listening at: http://127.0.0.1:8002 (28503)

 7月 02 19:47:52 matica-vm gunicorn[28503]: [2021-07-02 19:47:52 +0000] [28503] [INFO] Using worker: gevent

 7月 02 19:47:52 matica-vm gunicorn[28503]: [2021-07-02 19:47:52 +0000] [28646] [INFO] Booting worker with pid: 28646

 7月 02 19:47:52 matica-vm gunicorn[28503]: [2021-07-02 19:47:52 +0000] [28656] [INFO] Booting worker with pid: 28656

 7月 02 19:47:52 matica-vm gunicorn[28503]: [2021-07-02 19:47:52 +0000] [28697] [INFO] Booting worker with pid: 28697

 7月 02 19:47:53 matica-vm gunicorn[28503]: /usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/cryptography/__init__.py:39: CryptographyDepreca

 7月 02 19:47:53 matica-vm gunicorn[28503]:   CryptographyDeprecationWarning,

 7月 02 19:47:53 matica-vm gunicorn[28503]: /usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/cryptography/__init__.py:39: CryptographyDepreca

 7月 02 19:47:53 matica-vm gunicorn[28503]:   CryptographyDeprecationWarning,

 7月 02 19:47:53 matica-vm gunicorn[28503]: /usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/cryptography/__init__.py:39: CryptographyDepreca

 7月 02 19:47:53 matica-vm gunicorn[28503]:   CryptographyDeprecationWarning,

 7月 02 19:48:06 matica-vm gunicorn[28503]: [2021-07-02 10:48:06 +0000] [28646] [ERROR] Exception in worker process

 7月 02 19:48:06 matica-vm gunicorn[28503]: Traceback (most recent call last):

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 583, in spawn

 7月 02 19:48:06 matica-vm gunicorn[28503]:     worker.init_process()

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/workers/ggevent.py", line 203,

 7月 02 19:48:06 matica-vm gunicorn[28503]:     super(GeventWorker, self).init_process()

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/workers/base.py", line 129, in

 7月 02 19:48:06 matica-vm gunicorn[28503]:     self.load_wsgi()

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/workers/base.py", line 138, in

 7月 02 19:48:06 matica-vm gunicorn[28503]:     self.wsgi = self.app.wsgi()

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/app/base.py", line 67, in wsgi

 7月 02 19:48:06 matica-vm gunicorn[28503]:     self.callable = self.load()

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/app/wsgiapp.py", line 52, in lo

 7月 02 19:48:06 matica-vm gunicorn[28503]:     return self.load_wsgiapp()

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/app/wsgiapp.py", line 41, in lo

 7月 02 19:48:06 matica-vm gunicorn[28503]:     return util.import_app(self.app_uri)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/util.py", line 350, in import_a

 7月 02 19:48:06 matica-vm gunicorn[28503]:     __import__(module)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gevent/builtins.py", line 96, in __impor

 7月 02 19:48:06 matica-vm gunicorn[28503]:     result = _import(*args, **kwargs)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/dashboard/wsgi.py", line 15, in <module>

 7月 02 19:48:06 matica-vm gunicorn[28503]:     elasticSearchFunctions.setup_reading_from_conf(settings)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/lib/archivematica/archivematicaCommon/elasticSearchFunctions.py", line 148, in setup_reading_from_conf

 7月 02 19:48:06 matica-vm gunicorn[28503]:     settings.SEARCH_ENABLED,

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/lib/archivematica/archivematicaCommon/elasticSearchFunctions.py", line 137, in setup

 7月 02 19:48:06 matica-vm gunicorn[28503]:     create_indexes_if_needed(_es_client, indexes)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/lib/archivematica/archivematicaCommon/elasticSearchFunctions.py", line 214, in create_indexes_if_needed

 7月 02 19:48:06 matica-vm gunicorn[28503]:     if client.indices.exists(index=",".join(indexes)):

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/elasticsearch/client/utils.py", line 84,

 7月 02 19:48:06 matica-vm gunicorn[28503]:     return func(*args, params=params, **kwargs)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/elasticsearch/client/indices.py", line 2

 7月 02 19:48:06 matica-vm gunicorn[28503]:     return self.transport.perform_request("HEAD", _make_path(index), params=params)

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/elasticsearch/transport.py", line 358, i

 7月 02 19:48:06 matica-vm gunicorn[28503]:     timeout=timeout,

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/elasticsearch/connection/http_urllib3.py

 7月 02 19:48:06 matica-vm gunicorn[28503]:     raise ConnectionError("N/A", str(e), e)

 7月 02 19:48:06 matica-vm gunicorn[28503]: ConnectionError: ConnectionError(<urllib3.connection.HTTPConnection object at 0x7f586f44cbd0>: Failed to establish a new connection: [Errno 111

 7月 02 19:48:06 matica-vm gunicorn[28503]: [2021-07-02 10:48:06 +0000] [28646] [INFO] Worker exiting (pid: 28646)

 7月 02 19:48:06 matica-vm gunicorn[28503]: [2021-07-02 10:48:06 +0000] [28697] [ERROR] Exception in worker process

 7月 02 19:48:06 matica-vm gunicorn[28503]: Traceback (most recent call last):

 7月 02 19:48:06 matica-vm gunicorn[28503]:   File "/usr/share/archivematica/virtualenvs/archivematica-dashboard/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 583, in spawn

 7月 02 19:48:06 matica-vm gunicorn[28503]:     worker.init_process()

次に、MCP Serverのエラー。

$ sudo journalctl -u archivematica-mcp-server

-- Logs begin at Fri 2021-07-02 17:33:32 JST, end at Fri 2021-08-13 22:21:03 JST. --

 7月 02 19:44:47 matica-vm systemd[1]: Started Archivematica MCP Server Service.

 7月 02 19:44:47 matica-vm python[24961]: Traceback (most recent call last):

 7月 02 19:44:47 matica-vm python[24961]:   File "/usr/lib/archivematica/MCPServer/archivematicaMCP.py", line 2, in <module>

 7月 02 19:44:47 matica-vm python[24961]:     from server.mcp import main

 7月 02 19:44:47 matica-vm python[24961]:   File "/usr/lib/archivematica/MCPServer/server/mcp.py", line 36, in <module>

 7月 02 19:44:47 matica-vm python[24961]:     django.setup()

 7月 02 19:44:47 matica-vm python[24961]:   File "/usr/share/archivematica/virtualenvs/archivematica-mcp-server/local/lib/python2.7/site-packages/django

 7月 02 19:44:47 matica-vm python[24961]:     apps.populate(settings.INSTALLED_APPS)

 7月 02 19:44:47 matica-vm python[24961]:   File "/usr/share/archivematica/virtualenvs/archivematica-mcp-server/local/lib/python2.7/site-packages/django

 7月 02 19:44:47 matica-vm python[24961]:     app_config = AppConfig.create(entry)

 7月 02 19:44:47 matica-vm python[24961]:   File "/usr/share/archivematica/virtualenvs/archivematica-mcp-server/local/lib/python2.7/site-packages/django

 7月 02 19:44:47 matica-vm python[24961]:     module = import_module(entry)

 7月 02 19:44:47 matica-vm python[24961]:   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module

 7月 02 19:44:47 matica-vm python[24961]:     __import__(name)

 7月 02 19:44:47 matica-vm python[24961]: ImportError: No module named main

 7月 02 19:44:47 matica-vm systemd[1]: archivematica-mcp-server.service: Main process exited, code=exited, status=1/FAILURE

 7月 02 19:44:47 matica-vm systemd[1]: archivematica-mcp-server.service: Failed with result 'exit-code'.

 7月 02 20:00:34 matica-vm systemd[1]: Started Archivematica MCP Server Service.

 7月 02 20:00:35 matica-vm python[6838]: /usr/share/archivematica/virtualenvs/archivematica-mcp-server/local/lib/python2.7/site-packages/cryptography/__

 7月 02 20:00:35 matica-vm python[6838]:   CryptographyDeprecationWarning,

 7月 02 21:39:34 matica-vm systemd[1]: Stopping Archivematica MCP Server Service...

 7月 02 21:39:35 matica-vm systemd[1]: Stopped Archivematica MCP Server Service.

Nginxのログ（/var/log/nginx/error.log）やダッシュボードのログ（/var/log/archivematica/dashboard/dashboard.debug.log）を確認しましたが、よくわからず。再度、同じアップグレードの処理を繰り返しましたが、効果なし。それで解散となりました。

次回の予定

8/20（金）です。

＜後日＞

次の日、個人的にもう一度確認してみました。上記のエラーが、/usr/share/archivematica/virtualenvs/archivematica-mcp-server/local/lib/python2.7/site-packagesに関係しているので、調べたところ、/usr/share/archivematica/virtualenvs/archivematica-mcp-server/local以下がごっそりありませんでした。

そこで、https://github.com/archivematica/Issues/issues/903を参照し、次のコマンドを遂行。

$ sudo apt install virtualenv

すると、archivematica-mcp-server/local以下が入りました。

ところが、またも"Error trying to connect to MCP server. Trying again..."です。一応、エラーを確認します。

Mcp Server

$ sudo journalctl -u archivematica-mcp-server

8月 14 17:57:32 matica-vm systemd[1]: Started Archivematica MCPServer.

 8月 14 17:57:32 matica-vm python[28671]: Traceback (most recent call last):

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/back

 8月 14 17:57:32 matica-vm python[28671]:     return self.cursor.execute(sql, params)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/back

 8月 14 17:57:32 matica-vm python[28671]:     return self.cursor.execute(query, args)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/MySQLdb/cursor

 8月 14 17:57:32 matica-vm python[28671]:     res = self._query(query)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/MySQLdb/cursor

 8月 14 17:57:32 matica-vm python[28671]:     db.query(q)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/MySQLdb/connec

 8月 14 17:57:32 matica-vm python[28671]:     _mysql.connection.query(self, query)

 8月 14 17:57:32 matica-vm python[28671]: MySQLdb._exceptions.OperationalError: (1054, "Unknown column 'Transfers.status' in 'where clause'")

 8月 14 17:57:32 matica-vm python[28671]: The above exception was the direct cause of the following exception:

 8月 14 17:57:32 matica-vm python[28671]: Traceback (most recent call last):

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/lib/archivematica/MCPServer/archivematicaMCP.py", line 5, in <module>

 8月 14 17:57:32 matica-vm python[28671]:     main()

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/lib/archivematica/MCPServer/server/mcp.py", line 106, in main

 8月 14 17:57:32 matica-vm python[28671]:     Package.cleanup_old_db_entries()

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/lib/python3.6/contextlib.py", line 52, in inner

 8月 14 17:57:32 matica-vm python[28671]:     return func(*args, **kwds)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/lib/archivematica/MCPServer/server/packages.py", line 574, in cleanup_old_db_entries

 8月 14 17:57:32 matica-vm python[28671]:     completed_at=completed_at,

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/mode

 8月 14 17:57:32 matica-vm python[28671]:     rows = query.get_compiler(self.db).execute_sql(CURSOR)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/mode

 8月 14 17:57:32 matica-vm python[28671]:     cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/mode

 8月 14 17:57:32 matica-vm python[28671]:     raise original_exception

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/mode

 8月 14 17:57:32 matica-vm python[28671]:     cursor.execute(sql, params)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/back

 8月 14 17:57:32 matica-vm python[28671]:     return self.cursor.execute(sql, params)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/util

 8月 14 17:57:32 matica-vm python[28671]:     six.reraise(dj_exc_type, dj_exc_value, traceback)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/utils/s

 8月 14 17:57:32 matica-vm python[28671]:     raise value.with_traceback(tb)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/back

 8月 14 17:57:32 matica-vm python[28671]:     return self.cursor.execute(sql, params)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/db/back

 8月 14 17:57:32 matica-vm python[28671]:     return self.cursor.execute(query, args)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/MySQLdb/cursor

 8月 14 17:57:32 matica-vm python[28671]:     res = self._query(query)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/MySQLdb/cursor

 8月 14 17:57:32 matica-vm python[28671]:     db.query(q)

 8月 14 17:57:32 matica-vm python[28671]:   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/MySQLdb/connec

 8月 14 17:57:32 matica-vm python[28671]:     _mysql.connection.query(self, query)

 8月 14 17:57:32 matica-vm python[28671]: django.db.utils.OperationalError: (1054, "Unknown column 'Transfers.status' in 'where clause'")

 8月 14 17:57:33 matica-vm systemd[1]: archivematica-mcp-server.service: Main process exited, code=exited, status=1/FAILURE

 8月 14 17:57:33 matica-vm systemd[1]: archivematica-mcp-server.service: Failed with result 'exit-code'.

ダッシュボード

$ sudo journalctl -u archivematica-dashboard

8月 14 17:42:04 matica-vm systemd[1]: Stopping Archivematica Dashboard...

 8月 14 17:42:04 matica-vm gunicorn[17544]: [2021-08-14 17:42:04 +0900] [17544] [INFO] Handling signal: term

 8月 14 17:42:34 matica-vm gunicorn[17544]: [2021-08-14 17:42:34 +0900] [17544] [INFO] Shutting down: Master

 8月 14 17:42:34 matica-vm systemd[1]: Stopped Archivematica Dashboard.

 8月 14 17:42:34 matica-vm systemd[1]: Started Archivematica Dashboard.

 8月 14 17:42:34 matica-vm gunicorn[28072]: [2021-08-14 17:42:34 +0900] [28072] [INFO] Starting gunicorn 19.9.0

 8月 14 17:42:34 matica-vm gunicorn[28072]: [2021-08-14 17:42:34 +0900] [28072] [INFO] Listening at: http://127.0.0.1:8002 (28072)

 8月 14 17:42:34 matica-vm gunicorn[28072]: [2021-08-14 17:42:34 +0900] [28072] [INFO] Using worker: gevent

 8月 14 17:42:34 matica-vm gunicorn[28072]: [2021-08-14 17:42:34 +0900] [28076] [INFO] Booting worker with pid: 28076

 8月 14 17:42:34 matica-vm gunicorn[28072]: [2021-08-14 17:42:34 +0900] [28077] [INFO] Booting worker with pid: 28077

 8月 14 17:42:34 matica-vm gunicorn[28072]: [2021-08-14 17:42:34 +0900] [28078] [INFO] Booting worker with pid: 28078

 8月 14 17:57:46 matica-vm systemd[1]: Stopping Archivematica Dashboard...

 8月 14 17:57:46 matica-vm gunicorn[28072]: [2021-08-14 17:57:46 +0900] [28072] [INFO] Handling signal: term

 8月 14 17:57:47 matica-vm gunicorn[28072]: [2021-08-14 08:57:47 +0000] [28078] [INFO] Worker exiting (pid: 28078)

 8月 14 17:58:06 matica-vm gunicorn[28072]: [2021-08-14 08:58:06 +0000] [28077] [INFO] Worker exiting (pid: 28077)

 8月 14 17:58:16 matica-vm gunicorn[28072]: [2021-08-14 17:58:16 +0900] [28072] [INFO] Shutting down: Master

 8月 14 17:58:16 matica-vm systemd[1]: Stopped Archivematica Dashboard.

 8月 14 17:58:16 matica-vm systemd[1]: Started Archivematica Dashboard.

 8月 14 17:58:16 matica-vm gunicorn[28698]: [2021-08-14 17:58:16 +0900] [28698] [INFO] Starting gunicorn 19.9.0

 8月 14 17:58:16 matica-vm gunicorn[28698]: [2021-08-14 17:58:16 +0900] [28698] [INFO] Listening at: http://127.0.0.1:8002 (28698)

 8月 14 17:58:16 matica-vm gunicorn[28698]: [2021-08-14 17:58:16 +0900] [28698] [INFO] Using worker: gevent

 8月 14 17:58:16 matica-vm gunicorn[28698]: [2021-08-14 17:58:16 +0900] [28701] [INFO] Booting worker with pid: 28701

 8月 14 17:58:17 matica-vm gunicorn[28698]: [2021-08-14 17:58:17 +0900] [28703] [INFO] Booting worker with pid: 28703

 8月 14 17:58:17 matica-vm gunicorn[28698]: [2021-08-14 17:58:17 +0900] [28705] [INFO] Booting worker with pid: 28705

続いて、ダッシュボードのログ（/var/log/archivematica/dashboard/dashboard.debug.log）を確認。

4873 ERROR     2021-08-13 10:45:56  django.request:exception:handle_uncaught_exception:135:  Internal Server Error: /status/

4874 Traceback (most recent call last):

4875   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner

4876     response = get_response(request)

4877   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/core/handlers/base.py", line 187, in _get_response

4878     response = self.process_exception_by_middleware(e, request)

4879   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/django/core/handlers/base.py", line 185, in _get_response

4880     response = wrapped_callback(request, *callback_args, **callback_kwargs)

4881   File "/usr/share/archivematica/dashboard/main/views.py", line 80, in status

4882     xml = etree.XML(client.list())

4883   File "/usr/share/archivematica/dashboard/contrib/mcp/client.py", line 162, in list

4884     b"getJobsAwaitingApproval", six.moves.cPickle.dumps({}, protocol=0)

4885   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/gearman/client.py", line 49, in submit_job

4886     jobs_to_submit=[job_info], **kwargs

4887   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/gearman/client.py", line 70, in submit_multiple_jobs

4888     return self.submit_multiple_requests(requests_to_submit, **kwargs)

4889   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/gearman/client.py", line 90, in submit_multiple_requests

4890     processed_requests = self.wait_until_jobs_completed(processed_requests, poll_timeout=time_remaining)

4891   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/gearman/client.py", line 134, in wait_until_jobs_completed

4892     self.poll_connections_until_stopped(self.connection_list, continue_while_jobs_incomplete, timeout=poll_timeout)

4893   File "/usr/share/archivematica/virtualenvs/archivematica/lib/python3.6/site-packages/gearman/connection_manager.py", line 248, in poll_connections_until_stopped

4894     raise ServerUnavailable('Found no valid connections in list: %r' % self.connection_list)

4895 gearman.errors.ServerUnavailable: Found no valid connections in list: [GearmanConnection(host='127.0.0.1', port=4730, keyfile=None, certfile=None, ca_certs=None)]

続いて、Nginxのログ（/var/log/nginx/error.log）

1  2021/08/13 16:23:17 [error] 933#933: *474 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.56.1, server: _, request: "GET /transfer/status/?1628839396328 HTTP/1.1", upstream: "http://127.0.0.1:8002/transfer/status/?1628839396328", host: "192.168.56.3", referrer: "http://192.168.56.3/transfer/"

2 2021/08/13 16:23:28 [error] 933#933: *474 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.56.1, server: _, request: "GET /transfer/status/?1628839406336 HTTP/1.1", upstream: "http://127.0.0.1:8002/transfer/status/?1628839406336", host: "192.168.56.3", referrer: "http://192.168.56.3/transfer/"

3 2021/08/13 16:23:35 [error] 933#933: *463 upstream prematurely closed connection while reading response header from upstream, client: 192.168.56.1, server: _, request: "GET /status/?1628839311270 HTTP/1.1", upstream: "http://127.0.0.1:8002/status/?1628839311270", host: "192.168.56.3", referrer: "http://192.168.56.3/transfer/"

4 2021/08/13 19:46:46 [error] 933#933: *877 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.56.1, server: _, request: "GET /transfer/status/?1628851605901 HTTP/1.1", upstream: "http://127.0.0.1:8002/transfer/status/?1628851605901", host: "192.168.56.3", referrer: "http://192.168.56.3/transfer/"

5 2021/08/13 19:46:53 [error] 933#933: *811 upstream prematurely closed connection while reading response header from upstream, client: 192.168.56.1, server: _, request: "GET /status/?1628851560793 HTTP/1.1", upstream: "http://127.0.0.1:8002/status/?1628851560793", host: "192.168.56.3", referrer: "http://192.168.56.3/transfer/"

ここで、よくわからなくなったので諦めました。Archivematicaの掲示板にError connecting to MCP serverがあがっています。

https://groups.google.com/g/archivematica/c/zDC2yh-pJ_E

ところが、エラーの種類が異なるようですので、どうしていいかわかりません。

【87】archivematica1.13.0へのアップデートと新機能：Audit logを中心に

 前回は、難しいお話。その前はarchivematicaのインストールとAtoMへのDipアップロードをしましたが、マニュアル通りのために割愛しました。結果、1ヶ月ぶりの更新となります。ご容赦を。

1.13へのアップデート
さて、本日ですが、maticaがVer.1.12から1.13になりましたので、アップグレードからはじめます。maticaのドキュメンテーションを参照します。

https://www.archivematica.org/en/docs/archivematica-1.13/admin-manual/installation-setup/upgrading/upgrading/#upgrade

内容を見ていただければわかるのですが、インストールとほぼマニュアル通りです。それでは作業をすすめます。が、ここで躓きます。＜echo＞コマンドが権限の問題で通りません。以下のコマンドで、スーパーユーザーになった上で進めてください。

sudo su

進めて行くと、データを残すかどうか聞かれます。今回、データを入れていないで、残さない＜Y＞を選択しましたが、皆さんはご自分の環境を確認してください。

無事に終わり、ダッシュボード＜maticaのIPアドレス：80＞にログインします。ダッシュボードは無事見えましたが、MCP Server connectionエラーが出ました。ダッシュボードの右上には、接続状況が小さい文字で表示されるので、エラーもそこを確認してください。

結局1.12から1.13へのアップデートは失敗しました。まぁ、この問題は後日解決することにし、今日は他のマシーンのArchivematciaに変更することにします。「橋号」から「堀号」へ移動です。笑

ダッシュボードからBrowsができない場合

「堀号」にも早速問題が発生しました。ダッシュボードからbrowseしても、/homeが見えません。これが見えないと転送するファイルの選択ができません。しかし、最初の設定でよく出る問題なので、覚えておきましょう。ダッシュボードとStorage Serviceが会話するために同一APIキーが必要ですが、それが合わないことが原因である場合が多いようです。

APIキーがあるところは以下２ヶ所。

１．ストレージサービス>PipelineのAPI key

２．Dashboard>Administration>GeneralのAPI key

１がインストール時のAPIキーなので、２も同じAPIキーを持つ必要があります。

※Dashboard>Administration>Users>EditにもAPIキーがあるが、再生成できるようになっており、現在のものは見えない状態。これが他のAPIキーとどんな関係があるかは今のところ分からない。これでこんがらがって、再発行したもので一致させたりして混乱したことがあります。

これでbrowseもできるようになったので、Archivematcia1.13に追加された新しいメニューや機能を確認します。

Auditmaticaをインストールしてみる
Arivhimaitca1.13の新しくなった情報は、以下のサイトで確認できます。

Archivematica 1.13.0 and Storage Service 0.18.0 release notes

中でも、監査ログを取る機能として、Auditmaticaというものがが追加されたみたいなので、それを確認することにします。以下のGithubで公開されているマニュアル通りインストールを試みます。

https://github.com/artefactual-labs/auditmatica

短いマニュアルですが、なめたらあかん〜でした。

まず問題となったのは、pythonのバージョンが合わないことでした。auditmaitcaはpython3.6+で動きますが、「堀号」のArchivematciaはpython2??でした。しかし、調べると「堀号」にはpython3.6もありました。

そこで、インストールコマンドの　pip install auditmatica　を　pip3 install auditmatica　にしてインストールしたら、エラーなく無事インストールされました。

その後、マニュアル通り　auditmatica write-cef /path/to/nginx/access.log　を実行。しかしここでそのようなコマンドはないという問題が発生しました。

もしかしてと思い、マニュアルでのインストール方法も試しました。

git clone https://github.com/artefactual-labs/auditmatica.git

cd auditmatica/ 

pip install .

上記を実行したら、今度はエラーが一つ出ました。↓

ここから「堀号」の冒険がはじまります。ネット上のあらゆる情報を頼りに、あれこれ試していたら時間切れで「堀号」のArchivematciaは出番無しで終わってしまいました。いつも思いますが、正直Githubのマニュアルは初心者には不親切で、使い方がよくわからないのです。それに、２つのインストール結果が異なるので、無事インストールされのか、エラーが出たのでダメだったのかもわかりません。どっちかひとつにして〜〜【T__T】

仕方がなにので、参考にしたサイトや試したあれこれを記録として残しておきます。

pythonのリンクを変更してみる

python -> python2.7 をpython3.6へ変更

水色のコマンドを入れると、緑色のコマンドが実行される

同じく、python-configもpython3.6-configが実行されるようにリンクを変更

エラー参考サイト

pip でインストールエラー: Command “python setup.py egg_info” failed

https://ja.stackoverflow.com/questions/46978/pip-%E3%81%A7%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%82%A8%E3%83%A9%E3%83%BC-command-python-setup-py-egg-info-failed

「"python setup.py egg_info" failed with error code 1 」

https://miyabikno-jobs.com/setuppy-egginfo-1/

マニュアル参考サイト

archivematica/hack/etc/nginx/nginx.conf　のGithubサイト

https://github.com/artefactual/archivematica/blob/69be7f0581b2a2f31ca5d2d84ca45fb9330ed2b2/hack/etc/nginx/nginx.conf#L18-L20

auditmaticaマニュアルサイト（Tessa Walshさん）

https://libraries.io/pypi/auditmatica

その他参考サイト

pipでインストールしたパッケージの場所を調べる

https://qiita.com/t-fuku/items/83c721ed7107ffe5d8ff

するとここにあることを確認（なのになぜ動かないのよ〜〜〜）

どれもうまくいかず、問題解決は失敗です。ということで、今日はここまでです。この問題は次回に続けますが、果たしてどうやることやら。

========================

次回は8月13日（金）19時頃からです。

この問題の続きを試します〜

【49】DIPをAtoMへUpload（続々々々）

DIPのUploadのエラー問題が続いています。
AtoMのコミュニティに投げてみているのですが、有効なレスポンスはまだです。

先生から
「エラーはElasticsearchが原因なのでは？」
というご助言をメールで頂いたので、そのあたりの問題をクリアにすることに。　
以前、何かの拍子でＤＢにエラーが出た後、上手くアップロード出来なくなったことがあったそうです。

MySQLはRDBなので階層構造をフラットに表現している。親子関係を表現するのに使うのが“Nested set model”だが、それがサーバーのタイムアウトなどが原因で崩れてしまうことがあるらしい。
ということで今回の最初のタスクは「AtoMのＤＢの階層を再構築」になります。

Documentation>Administrator manual>Populate search index
に詳細があります。リンクはこれ↓
https://www.accesstomemory.org/en/docs/2.5/admin-manual/maintenance/populate-search-index/#maintenance-populate-search-index

php symfony search:populate

実行します。
するとなんとエラーに。

そういえば、AtoMのdescriptionで消そうとしたらエラーで消せなかったのがありました。それがエラー原因では、と推測します。
スラッグをコピペして、以下を実行。

php symfony tools:delete-description <slug>

詳しくは＞command line tools＞Delete a descriptionを参照。

その後Populate search indexに再挑戦。
成功します。
次にnestの再構成です。
＞command line tools＞Rebuild the nested set

php symfony propel:build-nested-set

実行。

ということで、もう一度DIPをUploadします。
その前にブラウザでAtoMにログインして、前々回に作ったtestフォンドの下に新しいシリーズを作ります。
マティカからのアップロードはいつも通りです。
結果は失敗。untitledのアイテムが出来てしまいました。

DBのエラーなのか、DBに入れ込む前のエラーなのかがわからないのが辛いです。

原因がわからないので、とりあえず一度AtoMをRebuildします。
先生から頂いたスクリプトを使います。

AtoMのDBのDropは成功してCreateに失敗したようなので、
Administrator manualのCreate the databaseを参考にDBを作成
AtoMに入れません。真っ白な画面が広がります。

どうやらtarファイルの解凍に失敗していた模様。

次回はAtoMのRebuildとDIPUploadを再挑戦です。

次回は変則的に木曜日にやります！
金曜日が春分の日なので3月19日（木）です。

以後経過

開発者から、質問板にお返事いただきました。

バグチケットが発行されました。

推測ですが、Archivematica 1.9とAtoM 2.5のPREMISバージョンが違うために生じる

不都合ではないかということでした。

https://groups.google.com/forum/#!topic/ica-atom-users/mBBfFIAqDWk

Archivematica 1.10へのアップグレードを試してくれとの助言をもらいましたので、

次回はこれにトライしましょう。

【48】DIPをAtoMへアップロード（続々々）

新型コロナウィルスで世の中が騒がしい中、今日も集まりました〜〜
しかし、せっかく集まったのに、道場くんのVirtual Boxがシステムエラーで立ち上がりません。まさかの機械がウィルスに感染か！
非常時代です。

Virtual Boxの更新
ということで、まずこの問題を解決しなければなりません。
エラーメッセージをググって、とりあえずVirtual Boxを6.1にバージョンアップしてみます。

なんとうまくいきました。
Maticaが立ち上がりましたので、今日の作業を始めます。
Virtual Boxも古すぎるとダメなんですね。

DIPを生成してAtoMへアップロード
１回目のテスト
今日はJPEG一つをMaticaに入れて、AtoMに移す作業を試します。以前はPDFやDOCXが混ざっていましたが、今日はとりあえず単純なデータでテストして、成功することを目指します。

いつもの作業を進めます。MaticaからDIPを作成して、AtoMに入れました。画像はちゃんと登録されましたが、画像のタイトルはやはりできていません。Untitledのままです。つまり、失敗です。

そこで、MaticaのArchival storageメニューから登録された画像を確認すると、サムネイルが作成しれていませんでした。Archival storageにはMaticaが作成したAIPが保存されます。どのようなものがあるか理解する必要がありそうです。ぜひ一読しましょう。

Archival Storage
https://www.archivematica.org/en/docs/archivematica-1.10/user-manual/administer/dashboard-admin/#dashboard-processing

２回目のテスト
ここでMaticaの作業方法を少し見直しました。Administrationー＞Processing Configuration　のところで、defaultとautomatedの２つがあることを発見しました。

これについては、Processing configurationを参照してください。default設定のPROCESSING CONFIGURATION FIELDSを我々が必要な内容で設定しておけば、Maticaが自動で作業を進めてくれます。

Processing configuration
https://www.archivematica.org/en/docs/archivematica-1.10/user-manual/administer/dashboard-admin/#dashboard-processing

今度は、JPEG2個、DOCX1個を入れてみました。今回は自動で次々と作業が進むので、楽でした。ここで一つ覚えて起きましょう。Maticaの作業過程には、Examine contentsというプロセスがあるのですが、個人情報のようなものを確認する作業のようです。以下を一度読んでおきましょう。

Examine contents
https://www.archivematica.org/en/docs/archivematica-1.10/user-manual/transfer/forensic/#examine-contents

今回のテストでは、やはりDOCXが3つ、AtoMに入りました。よくわかりませんが、以前と同様、一つのデータが入力したデータの数分AtoMに重複して登録されるエラーです。失敗ですね。

ここで一つだけ問題を解決できました。
AtoMでサムネイルが出てなかったのは、AtoMのAdminの設定からサムネイルを表示しない設定にしていたためだそうです。
Admin->Settings->Default page elements->Digital object carousel をオンにしましょう。

ということで、今日はVirtual Boxのバージョンアップ、AtoMのサムネイルの設定ミスを解決し、いくつかMaticaの機能について勉強しました。本当に大事な問題は解決できませんでしたが…^^;

今日はこれで撤収します〜

余談ですが、こんなエラーばっかり出るArchivematicaを実際使っているところを見に行きたいという話で盛り上がりました。ユーザーフォーラムに質問しても誰も答えてくれないので、Artefactual社を訪問して、我々苦労しているんだよ～といいたい（笑）。やはりあしながおじさんが必要でしょうか。どこかから研究費でももらえるといいのですが…

ではでは次回は、2/21です。
皆来てね～

〜以後経過〜

AtoMの質問掲示板に質問を投稿しました。
https://groups.google.com/forum/#!topic/ica-atom-users/mBBfFIAqDWk
Archivematica 1.10でもうまく動かないらしい。
DIPファイルを渡して、アドバイスを待ちます。

【47】AtoMとマティカの連携（続々）

maticaからAtoMに運ばれたDIPが、Archival Descriptionに反映しない問題について、検討を続けます。

原因はおそらくAtoM-Workerがうまく機能してないのではないかとにらみつつ、まずはエラーを起こすため、再度Dipアップロードにトライします。
エラーを起こすのは、Artefactualの専門家に画面つけて質問するためです。

まずは念の為、Gearman、php7.2-fpm、atom-workerを順番に再起動

root@atom-host:/var/log/nginx# sudo service gearman-job-server restart
root@atom-host:/var/log/nginx# sudo service php7.2-fpm restart
root@atom-host:/var/log/nginx# sudo service atom-worker restart

前に使った記述は、エラーが起こりややこしい状態になっていたので、新しくフォンド「test」を作成。
maticaでいつもの作業。いつも通り４つのデジタルオブジェクトをマイクロサービスで処理していきます。
AIP完成。AIP 内のメタデータであるMETS.xmlを確認し、ファイル名が正しく記述されていることを確認します。理由は、メタデータ内のファイル名がおかしくなっているために、AtoM側の処理にエラーを起こしているのではないか？と考えたためです。ですが、問題なし。

maticaでDIPアップロードを実行。
maticaのDIPアップロードのジョブの色は緑で正常動作であると示していますが、ジョブの右にあるギアを押して詳細を開くと、赤でエラーと出ているジョブキューがありました。不思議です。
AtoMの「test」フォンドに組んだファイルレベルを見ると、同じオブジェクトが４つ。メタデータも一緒。前回と同じエラーです。
AtoM側でmaticaから受け取るtmpファイルを確認すると、オブジェクトもメタデータも丸ごと来ていました。ところが、AtoMに来ているthumbnailフォルダーを見ると、全部同一のファイルになっている疑いが！
maticaでthumbnailができているかを見ると、きちんと生成されていなかった！
さらなる混乱の事態となり、もはやなすすべなし。

https://projects.artefactual.com/issues/13109
をもう一度見直してみると、#23に気になる投稿文が見つかります。
AtoM-workerが再起動すると、同じジョブを繰り返し、複製データをデータベースに送るとありました。同じデータが４つArchival Descriptionに出現している事態と何となく辻褄が合うようなエラーであるようにも思えます。
また、maticaのthumbnail問題はAtoM-workerとは別の現象にも見えます。
もうよくわからないから、開発者に質問を投げます。

機材を片付けた後、みんなでカンパして処理速度の速いマシンを購入してみるか...という話にもなりました。そうすれば、maticaも早く動き、作業時間が短縮できるかも。あしながおじさん、僕らは孤児でもない大人ですが、ご寄付をお待ち申し上げます。

さて次回以降の日程は、次の通りです。
1/31
2/21
です。
31ですから、お間違えなきよう。

【46】AtoMとマティカの連携（続き）

2020年最初の道場です。
更新が遅くなってしまってすみません・・・

ArchivematicaとAtoMの連携の続きをやります。

前回の失敗は道場ブログ記事【40】で指摘があるように
　＞AtoM2.5では、MySQLをバージョンアップしたことが原因で、AtoM workerが不安定になってしまっているそうです。
現在のところの対応策が、こちらにありました。の「こちら」部分をやっていないからではないかという指摘からスタートしました。

Tera Termから道場君に入っているAtoMに入ります。※この時ファイル→ログ→今日の日付のファイル名を作る（タイムスタンプとプレーンテキストにチェックを入れる）

AtoM workerの環境変更→リロード
This is going to be useful in case you need to troubleshoot the worker.
とあるところは、念のためやります。

確認のためヴァーチャルボックス内のArchivematicaを起動しブラウザからログイン。
ついでにブラウザからAtoMにログインします。

現状では以前作ったフォンド「絶望」内にあるシリーズ「失望」の中にエラーアイテムがある状態です。
とりあえず新しいシリーズを作成します。無事「通る」ように縁起を担いでCalrosと命名しました。

ArchivematicaからCalrosにオブジェクトをアップロードしてみます。
　ブラウザのIngestのタブからUpload to AtomEditor・・・・・・失敗です。
　シリーズ「Calros」には「Untitled」という謎アイテムがあるのみです。
つながってはいるけど、オブジェクトが来ていない？どこで差し止められているのでしょう？

Tera TermでAtoMのログを確認します。
AtoMに4つのオブジェクトを送ったはずなのに、1つめのTransfarでエラーの模様
See setting directory and file permissions documentation
という指示が出ています。

今度は権限に問題があるのではないかという仮定に基づき、AtoMのUploadsの中にあるrというディレクトリについてチェンジオーナーでRootからwww-dataに変えます。

ArchivematicaからCarlosにアップロードを再挑戦・・・・・・今度は同じ画像が4点も来てしまいました。影武者状態です！！

原因を探るべくNginxのエラーログを確認をします。
phpメッセージは　non publication status set for information object id:477
/user/share/nginx/atomにチェンジディレクトリ
sudo -u www-data php symfony jobs:woker
リスタートします。

3回目の挑戦です。
こちらのNote（We recommend...の方） に従って、AIPを作ってからDIPをUploadしてみることにしました。

AIPをstoreをしてみて、Storageタブからオブジェクトの確認です。
ここまでは異常なしです。
DIPのアップロードを再度試みます・・・・・・やっぱり失敗
Untitledという名前の同じオブジェクトが４つ来てしまいます。

ls -la /tmp
でAtoMのDIPを受け入れるtmpファイルを確認します
sudo find /tmp -name *animal*￥
見つかりました

やっぱりAtoM側に問題がある模様
次回はMaticaのUpgradeをして、もう一度挑戦です。

次回は1月24日です。

そして最後に。
最後に橋本さんがArchives and ManuscriptのSpecial issueのAbstractの審査に通ったそうです！すごい！！続報を待ちましょう！！！

【39】archivematicaから共生研のアーカイブズ(AtoM)へのDIP uploadを試みる(1st attempt)

ブログ当番、出張と通学のため永らく更新ができておりませんでした。みなさま申し訳ございません。

前回は、archivematicaからAtoMへのDIP uploadを成功させましたので、今回はいよいよ立教のアーカイブズ(AtoM)へ同じhostのarchivematicaからDIP uploadを試みます。

maticaのバージョンは、すでにlegacyとなった1.9.2です。

前回は、rsync機能を動かす際にパスワードを聞かれてしまう（公開鍵方式ではない）対策として、パスワードを指定する（archivematicaのマニュアルには書いていない）ことでsshの接続を公開鍵方式で実現し、archivematicaからAtoMへのDIP uploadに成功しましたが、本当は、パスワードの指定しなくてもrsync機能は動いたようです。

パスワードが聞かれてしまっていたのは、リモートホスト（今回の場合はarchivematicaの入った仮想マシン）に操作PCから「最初に接続する時だけ」表示されるメッセージに答えていなかったことが原因のようです。

The authenticity of host 'xxx' can't be established.
RSA key fingerprint is yyy
Are you sure you want to continue connecting (yes/no)?

↑こんな感じのメッセージが出ます。yyyのところにはハッシュ値が表示されます。

ということで、共生研のAtoMへのアクセスを操作PCから試みます。

...アクセスできない（connection refused / could not resolve hostname vsphere）。ポート開いてる？別PCではアクセスできることを確認。再起動...

時間はかかりましたが、うまくいきました。

以下のdocumentationの DIP upload (AtoM server configuration)の記述に従って共生研のAtoMが入ったホストを、前回のホストと同じように設定して行きます。

https://www.archivematica.org/en/docs/archivematica-1.9/admin-manual/installation-setup/customization/dashboard-config/#admin-dashboard-atom

準備完了。いよいよarchivematicaから共生研AtoMへDIP uploadを実施します。

...うまくいかない。おかしい。

そういえば、AtoMのPlugin設定大丈夫？...忘れていました。

The SWORD plugin (Admin –> Plugins –> qtSwordPlugin) must be enabled in order for AtoM to receive uploaded DIPs.

AtoMのuser interface上でpluginをenableにしてリトライ、がうまくいかず。

SwordPluginをactivateしたときに、AtoM workerを再起動する必要がありましたよね？（これは覚えていないですよね、普通）ので、再起動。

やっぱり内部エラー(コード500)、さて困った。

時間をかけて色々やってみましたが、qtSwordPluginWorkerのが上手く動作していないことが原因のようです。しかし解決策わからず、今回は時間切れとなりました。

次回は9月20日です。今回うまく行かなかったところ、2nd attemptです。

今度こそうまく行きますよう...!

【38】ArchivematicaのDIPをAtoMへupload（成功）

勉強会始まりました〜
しばらく間が空いたので、何をすればよいかすっかり忘れていますが、なんとかついていきます。

Archivematicaから生成したDIPをAtoMへアップロードするための設定がうまく行かず、ずっと苦労しています。今日は、前回から続いているRsyncがうまく動作しない問題から取り組みます。

マニュアルを再確認したい人はここ↓
AtoM DIP upload
https://www.archivematica.org/en/docs/archivematica-1.9/admin-manual/installation-setup/customization/dashboard-config/#atom-dip-upload

【実験１】
ずっと聞かないはずのPWを聞いてくるのは、そもそも2台のマシン間で会話ができる設定をする必要があったのではないかということで、以下のようにmaticaからコマンドを入れてみます。

$ ssh xxx.xxx.xxx.xxx

ここで、xxxはアトムのIPアドレスです。これを入力するとpasswordを聞いてくる。ここで最初につなげておけば、AtoMとmaticaのマシン間に会話ができるようになるはずなので、Rsyncで起きたエラー（AtoMへの接続のためのPWを聞いてくる）は解決できるのでは？

しかし、rsync error: unexplained error (code 255)が出て失敗しました。


【実験２】
今度はAtoMのマシンに、ユーザーarchivematicaを作成して、PWを作成しました。（マニュアルでは、PWなしで動くサーバーの設定方法が書いてあります。）そして、maticaから事前に作成した公開Keyをコピーして、AtoMの指定されたフォルダに移動しておきます（場所はマニュアルを参照）。

その後、$ sudo passwd -l archivematica　でPWをロック（受け付けない設定）しました。そのあとRsyncで会話ができるか確認します。

$ sudo -u archivematica rsync -av a archivematica@xxx.xxx.xxx.xxx

すると、PWを聞かれませんでした。成功です。

以前は前半でも書きましたが、ユーザーarchivematicaをPWなしの状態で作成して、すぐpasswordをロック（-l　設定）しており、コマンドで　$ ssh xxx.xxx.xxx.xxx　を実行すると、PWを聞かれていました。PWを設定してないのに、なぜ聞いて来るかがわかりません。設定してないので入力仕様がありません。そのマニュアルが以下の部分です。

$ sudo apt-get install rssh 

$ sudo useradd -d /home/archivematica -m -s /usr/bin/rssh archivematica 

$ sudo passwd -l archivematica

なぜマニュアル通りにするとPWを聞かれるのかわかりませんが、一応実験２でRsyncがうまく機能するようになりましたので、次に進みます。

次は、maticaからDIPを作って、先ほどの設定がちゃんと動くが試してみると、ちゃんとmaticaとAtoMが会話でき、DIPをuploadできました。ついに成功です！わーい！

※参考１
Ubuntuでrsshを利用する方法については、以下が参考になります。ここでも、一旦PWを作成して会話できるようにしてから、ロックするという方法が書いてあります。とういうことで、今回の解決方法は正しかったと思います。
https://www.thomaslaurenson.com/blog/2018/09/07/restricting-ssh-access-using-rssh/

※参考２
rsshとsshについても理解しておきましょう。
https://kazmax.zpp.jp/cmd/r/rssh.1.html

ということで、今日はここでやっと帰れるようになりました。笑

=============================
次回は９月６日です〜
立教のAtoMとArchivematicaの同期をチャレンジします。
時間があれば、Alfrescoのダウンロードを行います。
https://www.alfresco.com/jp/thank-you/thank-you-downloading-alfresco-community-edition

ブログ当番やらなくてもいいので（笑）、時間のある方は来てくださいな～