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

2021年5月22日土曜日

【85】番外編、AtoMへのsudachiインストール更新

以前、Kuromojiよりも語彙や分割能力に優れた形態素解析器sudachiをAtoM2.6に導入できた事例を報告しました。

http://irisawadojo.blogspot.com/search/label/Sudachi

これが全く無効となったことが判明しました。sudachiのバージョンが古くなったためか、git hub上でproject not foundとなって引退です。

https://github.com/WorksApplications/elasticsearch-sudachi/tree/v5.6.16-2.0.2

お疲れ様でした。

というわけで、現行最新ver. AtoM2.6.4のために使っているElasticsearchに、プラグインelasticsearch-sudachiをインストールするための手続きを新たに紹介します。以前より簡単になりました。参照したサイトはhttps://github.com/WorksApplications/elasticsearch-sudachi/blob/develop/docs/tutorial.mdhttps://js-challenge.dev/posts/elasticsearch-install-sudachi/です。

最初にElastic Search (ES)のバージョンを念のため確認。

VMなんかにAtoMをインストールした初期状態では、curlできないのでインストール。

$ sudo apt install curl

$ curl http://localhost:9200

そうしたら、

"version" : {

    "number" : "5.6.16",

    .........

と出ます(AtoM2.6.4)。

ここからSudachiをいれていきます。ESのプラグインであるanalysis-sudachiをインストールします。

めんどいのでrootユーザーになります。

$ sudo su

ES 5.6にあったバージョンのanalysis-sudachiをとってくる。

$ /usr/share/elasticsearch/bin/elasticsearch-plugin install https://github.com/WorksApplications/elasticsearch-sudachi/releases/download/v2.1.0-es5.6/analysis-sudachi-5.6.16-2.1.0.zip

本当に入ったかを確認。

$ /usr/share/elasticsearch/bin/elasticsearch-plugin list

analysis-sudachi

と表示されていたらOK。

次に辞書を入れます。

/etc/elasticsearch/sudachi/ を作成し、そこにsystem_core.dicという名前で辞書を配置します。

$ mkdir /etc/elasticsearch/sudachi

$ cd /etc/elasticsearch/sudachi

最新の辞書のコア版を入れます。フルの辞書が欲しい人は、以下coreのところをfullに書き換えてください。

$ wget https://object-storage.tyo2.conoha.io/v1/nc_2520839e1f9641b08211a5c85243124a/sudachi/sudachi-dictionary-latest-core.zip

うまくいくはずがなぜか拒否されたので、次のページ(http://sudachi.s3-website-ap-northeast-1.amazonaws.com/sudachidict/)からダウンロード。

$ wget http://sudachi.s3-website-ap-northeast-1.amazonaws.com/sudachidict/sudachi-dictionary-20201223-core.zip

$ unzip sudachi-dictionary-20201223-core.zip

$ cp sudachi-dictionary-*/system_core.dic .

Elasticsearchを起動

$ sudo /etc/init.d/elasticsearch restart

次のコマンドでanalysis-sudachiが "plugins”に入っていればOK.

$ curl -X GET 'http://localhost:9200/_nodes/plugins?pretty'

.........

 "plugins" : [

        {

          "name" : "analysis-sudachi",

          "version" : "2.1.0",

          "description" : "The Japanese (Sudachi) Analysis plugin integrates Lucene Sudachi analysis module into elasticsearch.",

          "classname" : "com.worksap.nlp.elasticsearch.sudachi.plugin.AnalysisSudachiPlugin",

          "has_native_controller" : false

        }

      ],

.........

上記のように入っていることを確認。

最後にAtoMの設定ファイルを変更。

$ sudo nano /usr/share/nginx/atom/plugins/arElasticSearchPlugin/config/search.yml

もちろん、nanoじゃなくてviでもいい。

italian:

  tokenizer: standard

  filter: [lowercase, italian_stop, preserved_asciifolding]

の下に

japanese:

  tokenizer: sudachi_tokenizer

  filter: [sudachi_baseform, sudachi_normalizedform]

を挿入。インデントを他の行とずれないように注意。

今回入れたfilterは、sudachi_baseformが形容詞と動詞を終止形にして検索。sudachi_normalizedformが、異体字などを統制して検索してくれる。

filterについては色々あるので、以下を参照。

https://github.com/WorksApplications/elasticsearch-sudachi/blob/develop/docs/tutorial.mdのフィルター説明。

https://www.ai-shift.co.jp/techblog/168 はtoken filterのところ。

https://qiita.com/sorami/items/99604ef105f13d2d472b は様々なフィルターのところ。

$ sudo nano /usr/share/nginx/atom/plugins/arElasticSearchPlugin/lib/arElasticSearchMapping.class.php 

'it' => 'italian’, の下に
'ja' => 'japanese’, を記入。こちらもインデントを他の行とずれないように注意。

Nginxを再起動し、インデックスの再読み込み。

$ sudo systemctl restart nginx

$ sudo php /usr/share/nginx/atom/symfony search:populate

これにて終了。

2020年7月23日木曜日

【62】番外編AtoM2.6のインストール

AtoM2.6のインストールについて、マニュアルhttps://www.accesstomemory.org/en/docs/2.6/admin-manual/installation/linux/ubuntu-bionic/#mysql
のみでは不十分な点があったので、備忘録としてブログを更新します。
マニュアル通りに進めると、最後のRun the web installerのDatabase登録のところで詰みます。データベースのパスワードを拒否するのです。これはAtoM2.6から、mysql8.xを使うようになり、DBユーザーの認証の初期設定が変ったために起こる問題です。

工夫がいるのは、mysqlの設定です。
Create Databaseの作業は、まずマニュアル通り、

sudo mysql -h localhost -u root -p -e "CREATE DATABASE atom CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;"

を打ちます。
さらに、マニュアルにしたがい、

sudo mysql -h localhost -u root -p -e "CREATE USER 'atom'@'localhost' IDENTIFIED BY '12345';"
sudo mysql -h localhost -u root -p -e "GRANT ALL PRIVILEGES ON atom.* TO 'atom'@'localhost';"

を打ちます。'12345'は、任意のパスワードです。

それで、追加するのは次の命令文。

sudo mysql -h localhost -u root -p -e "ALTER USER ‘atom’@‘localhost' IDENTIFIED WITH mysql_native_password BY '12345';"

'12345'は、上記のパスワードなので、必ず一致させます。

この命令文が何をやったかは次の記事が参考になります。
https://motomotosukiyaki.com/mysql-from-php-server-requested-authentication-method-unknown-to-the-client/

完全に理解していないので、推測で説明します。
まずMysqlに入ります。

$ sudo mysql -u root -p

データベースのユーザーを示すテーブルに切り替える?

mysql> use mysql 

ユーザー一覧を表示します。

mysql> select user, host, plugin from user;

ここで、atomの認証(plugin)がcaching_sha2_passwordとなっているのが問題です。
認証を上で設定したパスワードの12345に変更してやります。

mysql> alter user 'atom'@'localhost' identified with mysql_native_password by '12345';

atomというユーザーがパスワード12345でMysqlに入れるようになりました。
mysql> select user, host, plugin from user;
で再確認。

以上の設定で、Run the web installerのDatabase登録を無事終えることができました。

さて、次回の道場は7/31(金)です。
よろしくお願いします。





2020年2月24日月曜日

【49】DIPをAtoMへUpload(続々々々)

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

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

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

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バージョンが違うために生じる
不都合ではないかということでした。

Archivematica 1.10へのアップグレードを試してくれとの助言をもらいましたので、
次回はこれにトライしましょう。


2020年1月31日金曜日

【48】DIPをAtoMへアップロード(続々々)

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

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

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

DIPを生成してAtoMへアップロード
1回目のテスト
今日は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

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

これについては、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ファイルを渡して、アドバイスを待ちます。



2020年1月26日日曜日

【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でいつもの作業。いつも通り4つのデジタルオブジェクトをマイクロサービスで処理していきます。
AIP完成。AIP 内のメタデータであるMETS.xmlを確認し、ファイル名が正しく記述されていることを確認します。理由は、メタデータ内のファイル名がおかしくなっているために、AtoM側の処理にエラーを起こしているのではないか?と考えたためです。ですが、問題なし。

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

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

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

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




2020年1月22日水曜日

【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という名前の同じオブジェクトが4つ来てしまいます。

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

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

次回は1月24日です。

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



2019年12月21日土曜日

【45】AtoMアップグレードの練習(続々編)

Hi!! Guys!!

本日は、前々回から続く、AtoMの練習です。ボク、出てないけど…
初めてこちらを更新するので、どうなるか…概要だけでも何とか書き留めたいと…

今日は、

アップグレードしたAtoMとAchieveMaticaがつながっているか?

を確認します。そんだけ?いやいや今日は12月20日ですよ!つまりは、
忘年会>※9時に新しい豚肉の食べ方を体験しにいくのです
です。作業をちゃんとするだけ、偉いです!!!ってことで、始めます。

<1>AtoMとmaticaの連携を確認
(1)AtoMを開きます。
→起動OK
(2)RemoteDesktopからmaticaを起動をします。※Win10からUbuntuにアクセスする場合は<console>選択
→起動OK
=どちらも起動を確認|連携を確認
(3)AtoMの設定:plugin管理
  ・qtSwordplugin/ restAPIpluginのチェックボックスをチェック
        REST APIは、次を参照、https://qiita.com/masato44gm/items/dffb8281536ad321fb08
(4)AtoMのシステムをリスタート
  ※コマンド:hitstory
           にて過去のコマンドラインを確認すると便利です。
   1: sudo systemctl restart gearman-job-server
            2: sudo systemctl restart php7.2-fpm
            3: sudo systemctl restart atom-wor ker
(5)maticaの作業:Transfer※過去のブログ内容を参照してください
      ※好みの機能を選択し、いらない項目は"cancell"を選択
  ※AtoM/Binderのアドレス等、AtoM(相手の情報)を確認しないと、当然Transferしません。
  →が…なぜかうまくいきません。maticaでのTransferはうまく言ってるのですが(faileになった項目がないので)、AtoM上には「untitled」に…さらに、Internal Server Error 500…
  ・最後のチャンス(お店9時予約なので)=AtoM-Workerを改めてスタート
  コマンド: sudo systemctl start atom-worker
  →ここから再度maticaでtransferを…(祈
  ダメです。同じ結果でした。

 ということで、本日はタイムアップです。今年最後の道場は、スッキリした気分を得られないまま終了となりました。とはいえ、「通常通り」なんていいながらビールを飲んでました。

 本年もお世話になりました。新年は1月10日からスタートです。

 みなさま良いお年を!!
  

 

          


 

2019年11月30日土曜日

【44】AtoMアップグレードの練習(続編)

前回AtoMのアップグレードを失敗。師範の教えに従いその続きをやります。
師範が示した本日のシナリオは次の通り。
(1)AtoMの再構築
(2)WEBでAtoMに適当にデータを入力する
(3)バックアップの作成
(4)再びAtoMを新規構築
(5)バックアップしたデータの移動
師範の指南書(スクリプト集)を、師範代の力を借りて解読しながら1行ずつ実行。

(1)前回壊してしまったので、新しくAtoM2.5.1を入れます。
次の命令文で再構築。
mysql - h localhost -u root -p -e 'DROP database atom; CREATE DATABASE atom CHARACTER SET uft8 COLLATE ytf8_unicode_ci;'
 atomというデータベースを壊して、同じ名前の新しいデータベースを作る。
sudo rm -r /usr/share/nginx/atom
 昔インストールしたatomファイルを廃棄します。
sudo cp -r /home/.../atom251 /usr/share/nginx/atom
 過去にどこかに入れておいたatom2.5.1を所定のnginx以下のatomにコピー
sudo chown -R www-data:www-data /usr/share/nginx/atom
 Nginxから動かせるように、権限を初期のrootからwww-dataに変更

続いてAtoMのブラウザ画面で初期設定を行う。
以下コマンドで最終調整。
sudo php /usr/share/nginx/atom/symfony cc  (キャッシュ消す)
sudo php /usr/share/nginx/atom/symfony search:populate   (AtoM内のインデクスを再構成)
sudo php systemctl restart php7.2-fpm
systemctlコマンドはsystemdの制御に使います。systemdはLinuxの起動処理やシステム管理を行う仕組みです。https://dev.classmethod.jp/cloud/aws/systemd-getting-started/を見てください。
sudo php systemctl restart memcached
https://www.accesstomemory.org/fr/docs/2.5/adminmanual/maintenance/troubleshooting/#troubleshooting-restart-memcached を参照。memcachedは、分散型メモリキャッシュシステムでして、Webサイトの反応を速くします。そいつをリスタート。
sudo systemctl restart atom-worker

(2)ウェブブラウザでATOMデータを入力する
ll /usr/share/nginx/atom/uploads
ll /usr/share/nginx/atom/downloads
を見て、空であることを確認
その後、目録記述を入力した上で画像をアップロード。
ll /usr/share/nginx/atom/uploads
上の命令文でアップロードしたデータがあることを確認。
目録プリント(AtoMウェブサイトのインターフェースの右側にある機能)でcsvファイルでアイテムリストをダウンロード。
ll /usr/share/nginx/atom/downloadsにあるcsvファイルを命令文catで見て、確かに存在していることを確認。

(3)バックアップを作る
cp -r /usr/share/nginx/atom/uploads /.../uploads
cp -r /usr/share/nginx/atom/downloads /.../downloads
アップロードしたデータ、ダウンロードしたデータを、バックアップするために別の場所(上記の事例ではどこかに"uploads""downloads"というディレクトリを作成)にコピー。前回はうっかり/tmpに入れたので、シャットダウンした時点で全部消えました。自分の恥ずかしい過去もtmpファイルに入れて、寝た(シャットダウン)時点で消えてくれてたらどれだけ嬉しいでしょう。僕は、はるか昔に合コンで女性に枝豆を投げつけたことが...いや本題に戻りましょう。
ls -lR /.../uploads/
ls -lR /.../downloads/
で、きちんとコピーできていることを確認しました。
引数の-lで各ファイルの詳細を、-Rでディレトリに含まれる内容を全部含めて表示します。
mysqldump -u atom -p atom > /.../atomdb.sql
もともとつかっていたAtoMのデータベース登録分を別のところに出力しました。
llでバックアップしたファイルatomdb.sqlに容量があることを確認。

(4)再びATOMを新規構築
最新版AtoM2.5.3に差し替えて、(1)と同じ作業を行います。
AtoM2.5.3のインストールはhttps://www.accesstomemory.org/en/docs/2.5/admin-manual/installation/linux/ubuntu-bionic/#download-atomを参照。今回はoption1です。
sudo mkdir /usr/share/nginx/atom
sudo tar xzf atom-2.5.3.tar.gz -C /usr/share/nginx/atom --strip 1
--strip 1は、https://kakakakakku.hatenablog.com/entry/2018/06/13/220940によれば、
展開後のディレクトリを切り捨てて,第2階層をフラットに展開することができるようです。
atom-2.5.3.tar.gzファイルの第1階層を無視して/usr/share/nginx/atomに展開しとるようです。
それで、(1)「AtoMのブラウザ画面で初期設定を行う以下」同様の処理。
で所定の場所にatom2.5.3を入れました。



(5)バックアップしたデータの移動
sudo cp -r /コピー保存したところ/.../uploads /usr/share/nginx/atom/.
sudo cp -r /コピー保存したところ/.../downloads /usr/share/nginx/atom/.
sudo rm -f /usr/share/nginx/atom/downloads/jobs/*
 過去のexportファイルを消去する。

mysql - h localhost -u root -p -e 'DROP database atom; CREATE DATABASE atom CHARACTER SET uft8 COLLATE utf8_unicode_ci;'
mysql -u atom -p atom < atoms.sql
 バックアップしておいたデータベースファイルをSQLに入れる。
cd /usr/share/nginx/atom
sudo php symfony tools:upgrades-sql 
 最新のAtoMにデータベースをくっつける。ミスしたら過去はサヨナラ、あなたのAtoMは赤ん坊です。
sudo php symfony digitalobject:regen-derivatives 
 デジタルファイルとそのアクセス用ファイル、サムネイルを再構成。


以下は以前と同文。

sudo php symfony search:populate
sudo php symfony ccsudo php systemctl restart php7.2-fpm
sudo php systemctl 
restart memcached
sudo systemctl restart atom-worker
はい、今回はうまくいきました。今後は師範のアップデート用の命令文集を今の環境に合わせて少し更新してもよさそうです。
次回はArchivematicaを弟子たちが自力で構築し、AtoMとRsyncです。
日程は、

12/20(金)
です。
皆さん来てください。



2019年11月23日土曜日

【43】AtoMインストール、アップグレードの練習

今日は師匠の力を借りず、自力でAtoMのアップグレード&インストールができるように練習します!できるだけ多くの作業を体験するために、以下の作業をします。

1)AtoM2.5.1を2.5.3にアップグレードする
2)アップグレードしたものを消す
3)AtoM2.5.3をインストールしする

入れたり消したり、ちょっとバカみたいですが、皆がわかるようにやってみましょう!

作業のログを記録する方法
今日はTera Termを使って、道場君(AtoMサーバ)にリモートで操作します。Tera Termの「file」 メニューから「log」をクリックして、 logの保存場所とファイル名を指定しておくと今日の作業記録のログが残ります。作業の開始と同時にデスクトップにテキストファイルが生成されます。

では、作業に入りましょう。

まずは、AtoM マニュアルからadministrator manualのUpgradingを読みながら進めます。
https://www.accesstomemory.org/en/docs/2.5/admin-manual/installation/upgrading/#installation-upgrading

以下の3つは飛ばします。
Check minimum requirements
Read the release notes
Make sure the dependencies are updated

ここから本格的なアップグレード作業になりますが、大まかな手順は、

  1. 既存データのバックアップをとる
  2. AtoM2.5.3をインストールする
  3. バックアップを取ったデータをコピーする
  4. アップグレードを実施する

です。

1.バックアップを作成
AtoMのuploads、downloadsのディレクトリ、そしてMySQLのデータベースが対象です。
#cp コピー元 コピー先
$ cp  /usr/share/nginx/atom/uploads/ /tmp/uploads/
$ cp  /usr/share/nginx/atom/uploads/ /tmp/downloads/
cpではなくrsync -avでもOKです。rsync=同期は以下を参照。
今回はrsyncを使いました。

#mysqldump -u ユーザー名 -p 古いDB名 > /tmp/database.sql
$ sudo mysql -u atom -p atom > /tmp/database.sql
私たちの場合、ユーザー名=atom、古いDB名=atomだったので、上記の命令文になっとります。

この部分は、マニュアルと若干違いますが、解釈が難しかったです。要するの、マニュアルでは、uploadsとdownloadsの二つのディレクトリのバックアップを取るのですが、rsync(二つを同期)または、cp(必要なファイルだけコピー)の二つの方法が紹介されています。cpは指定のものをコピーするだけですので、コピー先にすでにあったものに影響はありません。rsyncは、同期先が同期元と一緒の状態になるので、同期先にだけあったものは削除されます。

また、$ rsync -av /var/www/icaatom_old/uploads/ /usr/share/nginx/atom/uploads/ で、/var/www/icaatom_old/uploads/ は古いAtoMの情報なので、もしこれがすでに/usr/share/nginx/atom/uploads/ であれば、二つは同じになる。

しかし、私たちは、uploadsディレクトリの場合、/tmp/uploadsにバックアップを取っているので、これを/usr/share/nginx/atom/uploads/ に入れればOKです。downloadsも同じです。

2.AtoM2.5.3をインストール

方法は2つありますが、今日はGithubを利用します。

#2.5.xは2.5.3にしないで、このままにする。
$ sudo git clone -b stable/2.5.x http://github.com/artefactual/atom.git /usr/share/nginx/atom

3.バックアップしたデータを移動
# cp コピー元 コピー先 $ cp -r /tmp/uploads/ /usr/share/nginx/atom/uploads/
$ cp  /tmp/downloads/ /usr/share/nginx/atom/downloads/
rsync -avでも可。今回はrsyncを使用しました。

JobsはAtoMを動かすと生成されるものなので、Jobs下にある過去の記録は消します。
$ rm -r /usr/share/nginx/atom/downloads/jobs/*
ちなみに-rでも-Rでも一緒。

古いデータベースを消して、新しいデータベースを作成します。
(マニュアルでは、この作業の直前にDBのバックアップを取りますが、バックアップはすべての作業をする前に取っておきましたので、すぐこの作業をはいります。)
$ sudo mysql -u username -p -e 'drop database atom; create database atom character set utf8 collate utf8_unicode_ci;'

次はバックアップを新しく作成したDBへコピーします。
$ sudo mysql -u atom -p atom < /tmp/database.sql

以下のようにコマンドを打つとDBが作成されたか確認できます。
#llは、「ls -l」と同じ
$ ll /tmp/database.sql

4.アップグレードを実施
まず、AtoMのディレクトリへ移動します。
$ cd /usr/share/nginx/atom

そして、アップグレード実施
$ sudo php symfony tools:upgrade-sql

しかし、Database 'propel' does not exist. とういうエラーがでました。

ヒューここまで来るのに、かなりの時間がかかりましたが、結局アップグレードは失敗しました。しかも、今日やろうとしていたことの一つもできていません。そして、既存のAtoMはデータベースをけしたり、ディレクトリを消したりといじったので、めちゃくちゃになりました〜〜ハハハハハハハハハハハハ (^O^;) 

もう帰ります~(ToT) 

===================
次回は、11月29日(金)です。
皆来てね〜

次回はエラーを直してみるところから続けます。エラーについては、ユーザーフォーラムを参考にしましょう。ここにあるようにconfigファイルを少しいじってみます。

後日師匠のコメント

やりたかったことは、ATOMのアップグレードだと思いました。
ブログの
1.(バックアップの作成:backup.sh)
2.(ATOM2.5.3をインストール:rebuild.sh)
3.(バックアップしたデータを移動:upgradeatom.sh)

の2.の段階の詳細が無いので正確ではないのですが、この(2.の)段階で処理を省略した部分があったのではないでしょうか?

2.でATOMのセットアップを一旦完了する必要があります。例えばデータベース名や、その持ち主のパスワード等を設定する必要があります。
この設定がなされていると/usr/share/nginx/atom/config/config.php
ファイルが作られ、settings.ymlやpropel.ini等が設定されます。
他にもATOMの初期設定が行われているかもしれません。
もし、2.で設定を完了せずに3.へ進むと指摘されたエラーなると思います。

上記の場合:

1.で保存すべきデータ(ディレクトリー)が/tmpに保存した場合はシステムをリブートするとなくなっているので、以下の手順でやってみてはいかがでしょうか。

(1)ATOMの再構築:参考:rebiuld.sh
(2)WEBでATOMに適当にデータを入力する
(3)バックアップの作成:参考:backup.sh
(4)再びATOMを新規構築:rebiuld.sh
(5)バックアップしたデートの移動:upgradeatom.sh

各スクリプトに書かれていることを理解してください。
なお、ブログ内でcpコマンドとrsyncコマンドが少し説明されていましたが、cpでディレクトリー以下全体をコピーするには、
「cp -r」で再帰的(-r)にコピーする必要があり、UBUNTUでは
チェックなしに上書きコピーされます。





2019年11月18日月曜日

【42】Reborn: AtoMインストールまで。

少しずつ、寒さが忍び寄っている気がします(これを書いている部屋はストーブを焚いています。)。
皆さま体調にお気をつけください。

前回話した内容を踏まえ、今回は自分たちで独自に
ゼロから(Ubuntuのインストールから)システムを構築することを想定して、
技術的にわからないことを置き去りにせずに確認していく、内容となりました。
実際にPCを操作された小澤さん、お疲れ様でした。
箇条書きになってしまいますが、設定項目は以下の通りです。

VirtualBoxにて立ち上げる仮想マシン
- ディスプレイ
- プロセッサの数
- メモリサイズ (8GB/16GB 選べるメモリはマシン依存)
- ハードディスク (画像/映像を入れる場合には多めに設定、今は50GBくらい)
- ネットワーク ブリッジに設定

OSをUbuntu desktopとUbuntu serverどちらにする問題
→グラフィカルユーザーインターフェイス(GUI)の有る無しによる違い、isoファイルのサイズは全然違います。
→操作性の良さから、今回もUbuntu desktopをインストールします。

AtoM(2.5.3)のダウンロードとインストール
以下サイトの進行に合わせて操作、はいつも通りか。
https://www.accesstomemory.org/en/docs/2.5/admin-manual/installation/linux/ubuntu-xenial/

最終的に、AtoMのインストールまで行けました。

ブログ記事を書いていて、それも全く大した内容ではないにもかかわらず思うのですが、
やっぱり内容が専門的で、理解が難しいです。

今日の議論をきちんと理解して、自分で実践できるまでには道のりが長いこと痛感しました。
コンピュータについての基本的な知識を、どこか別の場所で仕入れる必要があるのかもしれません。
ITパスポートとか、基本情報技術者試験の参考書等が役に立つのではないか、と思いました。

2019年9月26日木曜日

【40】 AtoM workerの起動

ウォウウォウ!の掛け声で始まりました本日の道場。

AtoMサーバーでAtoM worker(qtSwordPlugin)が動いていなかった問題を引き続き検討していきます。
まず、ArchivematicaのDIPが問題なくAtoMに移行される別マシンでAtoM workerが起動した状態、つまり正常な状態はどうなのかを確認します。
データベースのSQLファイルの中で、AtoMのAdmin –> Pluginsが登録されている Setting i18n のテーブルを見ます。id_1のテーブルにAdmin –> Pluginsでオンにしたプラグインが入っています。初期設定のatomdb.sql.0とqtSwordPlugin(AtoMWorker)をオンにしたatomdb.sql.1の差分があるかをみるため、Linuxのdiffコマンドで双方のファイルを比較すると、sql.1つまりid_1の方にのみ、qtSwordPlugin(AtoM worker)がありました。
同じ作業をAtoM workerの起動しないテスト中のAtoMで試みたところ、全く同じ状態の設定でした。

したがって、前回はエラー後のキャッシュ(ウェブサーバーのNginxにはけっこう残る)をすべて消せていなかったのではないかと考え、再度DIP アップロードをテストしました。やはり同じエラーが起こります。
sudo php usr/share/nginx/atom/symfony jobs:worker
を実行しても、AtoM workerが起動していません。

いつものように、AtoMの相談掲示板を見ていると
AtoM2.5.1にAtom workerのエラーがあり、バグのチケットになっていることがわかりました!本日テストしているマシンは、2.5.1です。
2.5.2で解決したとのことなので、バージョンアップを試みます。
アップグレードの記述はこちら
アップグレード後は、忘れずにAdmin –> PluginsでqtSwordPluginをオンにする。
でも失敗。
どうやら、2.5.2で修正したのは一部で、まだバグは残っているようです。
AtoM2.5では、MySQLをバージョンアップしたことが原因で、AtoM workerが不安定になってしまっているそうです。
現在のところの対応策が、こちらにありました。MySQLとAtom workerがうまく連携しない場合、SQLからのスタートを待つため、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-host restart
したがってやってみます。
なんとDip アップロードが成功しました。

AtoM内でDIPがあるべき場所(ディレクトリ)に運ばれるには、Gearman -> php7.2 fpm->Atom workerという手順で各アプリが起動している必要があるそうです。これが上記の命令文で正常に動いたのではないかと考えられます。

さて、次回以降の日程は
10/11
10/25
11/8
です。

レコマネのソフトウェア、Alfrescoをテストします。

2019年9月15日日曜日

【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が入ったホストを、前回のホストと同じように設定して行きます。


準備完了。いよいよ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です。
今度こそうまく行きますよう...!

2019年8月23日金曜日

【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

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

$ ssh xxx.xxx.xxx.xxx

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

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


実験2】
今度は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を聞かれるのかわかりませんが、一応実験2でRsyncがうまく機能するようになりましたので、次に進みます。

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

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

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

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

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

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


2019年7月28日日曜日

【37】Archivematica生成のDIPをAtoMにアップロード

暑くなってまいりました。
ビール飲んでから来る参加者も増えてきました。いい流れです。

本日は、Virtual Machine上のArchivematicaとホストマシンのAtoMをRsyncでお話しできるようにします。

まず、Virtual Machine上のArchivematicaを起動します。
IPアドレスを調べます。

<ちなみにブラウザがIEだと、ArchivematicaのダッシュボードでTransferの表示がうまく機能しない>。

今回、道場では初めてArchivematica1.9を確認しましたが、Access System IDが追加されていました。ここにslug(AtoM内のターゲットとなる記述のURL)を記入しておくと、transferするパッケージから作るDIPを自動的にAtoMに渡せます(事前設定は必要らしい)。
また、Transcribe SIP contentsという機能も入っていました。SIPの文書ファイルをOCR認識する機能のようです。TesseractというオープンソースのOCRアプリを働かせて文字認識させます。

これからRsyncの設定をします。
具体的にはArchivematicaでつくるDIPが、AtoMサイドのマシンの特定のディレクトリにパスワードなしでログインし、コマンドを展開できるようにします。
ややこしいのがAtoM側のディレクトリの名前もarchivematicaである点です。Virtual Machine上のArchivematicaと区別するためにブログではmaticaAtoMと名付けます(実際はarchivematicaです)。

環境設定の説明にしたがって、作業を進めます。
Archivematicaの方で公開鍵・秘密鍵を生成。
公開鍵をコピーしてmaticaAtoMに貼り付け。
AtoMサーバーで説明書通りにコマンドを実行。
chmod700でmaticaAtoMというユーザー以外何もできないという設定になる。

AtoMでの設定が終わると、ArchivemaricaのGUIで設定を行います。
今までRsync commandの項目を打ち込んでませんでした。
例はssh -p 22222 -l user。意味は次の通り。ssh:シェル起動コマンド、-p:ポート、l:ログインuserのネーム。

いつもの通りエラーが発生。
maticaAtoMのディレクトリとお話しできません。ArchivematicaとAtoMは倦怠期の夫婦です。
エラーメッセージをもとに、AtoM内の/tmp/tmpxxxファイルを開くと次のエラーメッセージが表示されていました。
Host key verification failed (code 255)

Rsync設定についてネット検索してここに従い
/home/archivematica/.ssh/authorized_keysのパーミッションを600に変更。

それでも失敗...
セキュリティ上 passwd -l archivematica (パスワード認証によるアクセス不可)としているが、
maticaAtoMにアクセスする際にパスワード要求されてしまう。
maticaAtoMのシェル設定ではrsshで入れるようにしたのに、困ったことです(シェルはここを参照)。
今回はここで打ち止めです。

後日のメーリスの議論でシェル設定が問題では?という話になりました。
/etc/shellsの設定
/etc/rssh.confの設定 
/etc/ssh/sshd_configの設定
Ubuntu 18.04での設定
開発者のうちの一人のブログ
 シェル設定が/bin/bashとなっていて現在の設定と違う
掲示板に出ていた同じタイプのエラー
です。次回はここの検討から始めたいと思います。

次回は
8/23(金)
です。

ビール飲んでも飲まなくても来てください。





2019年7月17日水曜日

【36】AtoM 2.5.1とArchivematica1.9.2のインストール

季節の変わり目でしょうか、本日は風邪でお休みの方が多くいらっしゃいました。お大事になさってください。

今回は途中まで進んでいたArchivematicaのインストールから再開です。
前回、メモリがずいぶん消費されて作業がスタックしておりましたが、原因はUbuntuDesktop18.04のupgradeの際、APT Snap機能が起こしたバグにあるようです。(Archivematicaに原因があるわけではないようです。)

sshやviエディタ、MySQL等の動作環境が準備されていることを確認して、ホストPCからArchivematicaのパッケージを仮想マシンへコピーします。実行!

...長い待ち時間の末、今回は無事にインストール終了しました。

仮想マシンのアドレスlocalhost:8000からArchivematicaのStorage Serviceへアクセスし、API Keyをコピーします。


...リボンがだいぶ張り出してます(↑白い部分しかスクロールできない...)。こういうときは、仮想マシンのディスプレイ設定を変更して解決しました(が、プロセスをメモするできませんでした。あしからず...)。

続いて、localhostからArchivematicaのメインのインターフェイスにアクセスしてアカウント登録を行います。このとき、Storage ServiceでコピーしてきたAPIを入力します。


あれ?Available Transfer Sourceに何も表示が出ていないぞ。AIPのStorage Locationも”No Available”じゃないか...よくよく確認してみると、Administration / General / Storage Service Userの名称が"test"のまま変更されていなかったことがわかりました。ので、先ほどStorage Serviceに登録した名称と揃えます。

どうやら、張り出しすぎていたリボンのせいで存在が確認できていなかったみたいです。皆さま、ディスプレイ設定にはどうかお気をつけください。


今回はコンテンツの管理用PCは別途用意する、という想定から仮想マシンの中にArchivematicaをインストールしました。一方、外からのコンテンツ閲覧を想定して、サーバ本体の中にAtoM2.5.1をインストールしました。

ArchivematicaとAtoMともに、今回無事にインストール相成ったので次回は2つのシステムをリンクしていきます。ArchivematicaのDashboardでの秘密鍵の作成と、AtoMへの公開鍵の交付が最初の作業になります。

最近の投稿

【108】Archives in the Digital Age: The use of AI and machine learning in the Swedish archival sectorを読む

 Gijs Aangenendt氏の修士論文、Archives in the Digital Age: The use of AI and machine learning in the Swedish archival sectorを半分読みました。 前半は、AIを扱ったアーカ...

人気の投稿