Fabio Leimgruber wrote:
> I am picking at straws here, but an odd thing I noticed: The log output of
> the upload/download/error daemons shows time stamps that are off by 6 hours
> compared to the local time zone. I already checked the host date time via
> `date` and changed the 'date.timezone' variable in
> /etc/php5/apache2/php.ini accordingly - still a 6 hours difference there.
The time zone used for logging can be changed in the configuration file. The default value in the example configuration is 'US/Eastern'. This is only used for logging and has no influence on syncing.
You don't need to change any time zone settings for php. The only setting that is required, and probably your issue, is the time zone setting of mysql.
You need to set the default time zone of mysql to utc with the following setting:
[mysqld]
default-time-zone = '+0:00'
If you added it in a file in /etc/mysql/conf.d/ make sure the setting is not overwritten in other configuration files.
/etc/mysql/conf.d/zotero.cnf
. I also checked that there are no other conf files overriding this.> Does this even have any influence? I am thinking it should not, because the
> default zotero dataserver is accessible and sync-able from any time zone?
> Is there another way to debug this?
You can manually look at the database content and see what modification time is stored there.
Fabio Leimgruber wrote
> [...]
> One last thing: pdf attachments are not synced. I was watching the
> upload and download daemons and noticed that uploads are done when
> adding a reference with attachment to group library, but no download
> process was triggered when syncing with another client. The metadata
> must have been transferred correctly since I can see the .pdf
> attachment in the reference on the other client, but "View PDF" gives
> me the "File Not Found" dialog and asks me to locate it.
>
> The $ATTACHMENT_SERVER* variables in config.inc.php are not used, are
> they?
>
Hello Fabio,
the upload and download daemons are only used for metadata synchronization. File synchronization uses the zotero api.
The attachment server configuration is not required. It is used for, as far as i understand, for viewing of attachments on the zotero website.
If a file up- or download happens you should see something like the following in your apache log file:
"GET /users/104/items/TD6I68GZ/file?auth=1&iskey=1&version=1&info=1 HTTP/1.1" 404 394
"POST /users/104/items/TD6I68GZ/file?auth=1&iskey=1&version=1 HTTP/1.1" 200 1018
You can also look if the uploaded files are present in the storage directory on the server. If they are not and you have enabled file synchronization in the client you can look in the zss log file and see if it shows some errors. The log file is located in /var/log/uwsgi/app/
"https://host.domain.tld/users/1/items"
Fabio Leimgruber wrote:
> Finally I found time to test this again. I think the headlines of * api and
> * storage need to be swapped in the wiki(?) -
No they are correct. Storage access means the S3 clone, which should be available at https://host.domain.tld/zotero.
And the zotero API is directly available at https://host.domain.tld/.
"users/1/items" is the API URL to access all items of the user with id 1.
> Anyways, so the error is with the storage (presumably?):
> "https://host.domain.tld/users/1/items"
>
> I get
> "Forbidden"
>
> instead of
> "Not found"
That is not a problem. The tests assume a clean install without users. If you created a user with id 1 then you either get the items, if the user library is set to be public, or "forbidden" if it is not.
If you can access all three from the client computer make sure you get the same result for storage access from the dataserver itself.
As you are running the server on a non standard port, you also need to specify the port for the S3_ENDPOINT in the config.inc.php of the dataserver. Otherwise the client is told to upload the file to the server on the standard port.
I updated the installation instructions accordingly.
On Monday, May 26, 2014 6:44:24 PM UTC+2, Klaus Flittner wrote:Fabio Leimgruber wrote:
> [...]
>
> The next error reads in the /srv/zotero/error.log:
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP Warning: S3::getObjectInfo(zotero, d7565fbf9c53d7a963d6ff5f37d5e9e9/test.pdf): [6] Couldn't resolve host 'zoteroserver' in /srv/zotero/dataserver/model/S3Lib.inc.php on line 224
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP Stack trace:
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 1. {main}() /srv/zotero/dataserver/htdocs/index.php:0
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 2. call_user_func() /srv/zotero/dataserver/htdocs/index.php:54
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 3. ItemsController->items() /srv/zotero/dataserver/htdocs/index.php:54
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 4. ItemsController->_handleFileRequest() /srv/zotero/dataserver/controllers/ItemsController.php:117
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 5. Zotero_S3::getRemoteFileInfo() /srv/zotero/dataserver/controllers/ItemsController.php:1054
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 6. S3::getObjectInfo() /srv/zotero/dataserver/model/S3.inc.php:393
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 7. S3::__triggerError() /srv/zotero/dataserver/model/S3Lib.inc.php:629
> [Mon May 26 12:10:05 2014] [error] [client 10.101.13.5] PHP 8. trigger_error() /srv/zotero/dataserver/model/S3Lib.inc.php:224
>
> this error is again caused by our network setup where 'zoteroserver' acts as a gateway for the debian VM running the dataserver. Now the VM's hostname is something like 'vm123' (see also [1]) and it does not know the 'zoteroserver' host. Do you know of an easy way to make this more flexible? Along the lines of 'localhost' maybe?
The easiest way would be to add an entry to /etc/hosts like:
1.2.3.4 zoteroserver
Replace 1.2.3.4 with the real ip of the zoteroserver or try 127.0.0.1.