php time zone settings

[Fabio Leimgruber]

Hello zotero-devs,

I am using the dataserver provided by Klaus Flittner (https://github.com/sualk/dataserver) on Debian Wheezy.

We got the server working this afternoon and are now experimenting with the Group Libraries feature. We found that syncing works not as expected across clients unless we clear out sync history and restore from server every time.

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.

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?

Best Regards,
Fabio

[Klaus Flittner]

Fabio Leimgruber wrote:

> Hello zotero-devs,
>
> I am using the dataserver provided by Klaus Flittner (

> https://github.com/sualk/dataserver<https://github.com/sualk/dataserver/wiki/Installation-Instructions-for-Debian-Wheezy>)

> on Debian Wheezy.
>
> We got the server working this afternoon and are now experimenting with the
> Group Libraries feature. We found that syncing works not as expected across
> clients unless we clear out sync history and restore from server every time.

This should definitely not be required.

> 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.

> 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.

Klaus

[Fabio Leimgruber]

On Tuesday, March 4, 2014 6:31:03 PM UTC+1, Klaus Flittner wrote:

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.

I double checked, and it is set as you described in /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.

but then I was surprised to see that mysql uses the system time zone (which is CET):
mysql> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | SYSTEM              |
+--------------------+---------------------+
1 row in set (0.00 sec)

given that the modification time is stored correctly with UTC time stamps:
+--------------+-----------+------------------+--------------------+----------+---------------------+---------------------+---------------------+---------+
| collectionID | libraryID | collectionName   | parentCollectionID | key      | dateAdded           | dateModified        | serverDateModified  | version |
+--------------+-----------+------------------+--------------------+----------+---------------------+---------------------+---------------------+---------+
|            1 |         4 | Untitled         |               NULL | RFAD5P4J | 2014-03-04 14:37:51 | 2014-03-10 08:09:06 | 2014-03-10 08:10:01 |      16 |
|            2 |         2 | Own Publications |               NULL | 2BJTQQV2 | 2010-12-22 13:10:15 | 2014-01-27 12:09:11 | 2014-03-10 08:08:59 |       5 |
+--------------+-----------+------------------+--------------------+----------+---------------------+---------------------+---------------------+---------+
2 rows in set (0.00 sec)

Am I missing something? Any other ideas?

Fabio

[Klaus Flittner]

Fabio Leimgruber wrote:

> On Tuesday, March 4, 2014 6:31:03 PM UTC+1, Klaus Flittner wrote:

> > [...]

> > 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.
> >
> >
> I double checked, and it is set as you described in
> /etc/mysql/conf.d/zotero.cnf. I also checked that there are no other
> conf files overriding this.
>

> [...]

>
> but then I was surprised to see that mysql uses the system time zone
> (which is CET):
> mysql> SELECT @@global.time_zone, @@session.time_zone;
> +--------------------+---------------------+
> | @@global.time_zone | @@session.time_zone |
> +--------------------+---------------------+
> | SYSTEM | SYSTEM |
> +--------------------+---------------------+
> 1 row in set (0.00 sec)
>

> [...]

I checked the results for the global and session time-zone setting on
our setup with different configuration settings. Here are the results:

With the default-time-zone setting commented out the system setting is
used, which is wrong:

mysql> select @@global.time_zone, @@session.time_zone;

+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM | SYSTEM |
+--------------------+---------------------+
1 row in set (0.00 sec)

With the setting "default-time-zone = '+0:00'" applied, utc is
used and is shown in the result:

mysql> select @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| +00:00 | +00:00 |

+--------------------+---------------------+
1 row in set (0.00 sec)

It seems that you have some error in your mysql configuration.

I can only guess what is wrong:
- Did you restart mysql after changing the configuration?
- Does the configuration file in /etc/mysql/conf.d/ ends in .cnf?
Otherwise it will be ignored

HTH,
Klaus

[Fabio Leimgruber]

I followed your steps and noticed some errors/inconsistencies when restarting mysqld. I assume this had to do with latin1 vs. utf8 issues because I created the db with the wrong config initially.

I simply recreated the db, checked the time zone settings and quick client tests suggest that syncing now works!

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?

Much obliged and Best Regards,
Fabio

[Klaus Flittner]

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/

Regards,
Klaus

[Fabio Leimgruber]

Hello Klaus,

On Thursday, March 20, 2014 6:43:19 PM UTC+1, Klaus Flittner wrote:

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.

 

Ok, good to know.
 

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

I checked this and found the lines
x.x.x.x - testuser [24/Mar/2014:10:40:12 +0100] "GET /groups/2/items/9NFCU3JC/file?auth=1&iskey=1&version=1&info=1 HTTP/1.1" 404 442
x.x.x.x - testuser [24/Mar/2014:10:40:12 +0100] "POST /groups/2/items/9NFCU3JC/file?auth=1&iskey=1&version=1 HTTP/1.1" 200 1034

and then
x.x.x.x - testuser [24/Mar/2014:10:40:14 +0100] "POST /sync/updated HTTP/1.1" 200 538
x.x.x.x - testuser [24/Mar/2014:10:40:14 +0100] "GET /groups/2/laststoragesync HTTP/1.1" 404 442
x.x.x.x - testuser [24/Mar/2014:10:40:14 +0100] "GET /groups/1/laststoragesync HTTP/1.1" 404 442

This looks good from what you wrote, but the green sync arrow keeps on spinning. I can open the attachment in my zotero instance, but not on other group member clients (pdf metadata present as described earlier). Other users cause similar log lines and non-stop spinning green arrow when syncing their group attachments
 

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/

There are no files present in the storage directory. The /var/log/uwsgi/app/zss.log is (and stays) empty.
 
Any idea on what might be causing this behaviour? Maybe related to our port-forwarding setup?

Regards,
Fabio

[Klaus Flittner]

Fabio Leimgruber wrote:

> [...]

> > 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/
> >
> >
> There are no files present in the storage directory. The
> /var/log/uwsgi/app/zss.log is (and stays) empty.
>
> Any idea on what might be causing this behaviour? Maybe related to our
> port-forwarding setup?

I finally found time to do a clean installation of the dataserver to play with.
There is now a short test section at the end of the installation instructions.

Its pretty basic but should at least cover that access to all three services
* sync
* api
* storage
is configured correctly.

Can you check that these tests work in your setup.

Regards,
Klaus

[Fabio Leimgruber]

Hello Klaus,

Finally I found time to test this again. I think the headlines of * api and * storage need to be swapped in the wiki(?) -

Anyways, so the error is with the storage (presumably?):
"https://host.domain.tld/users/1/items"
 
I get
"Forbidden"

instead of
"Not found"

Regards,
Fabio

[Klaus Flittner]

Fabio Leimgruber wrote:

> Hello Klaus,
>
> On Tuesday, April 29, 2014 9:06:26 PM UTC+2, Klaus Flittner wrote:
> >
> > Its pretty basic but should at least cover that access to all three
> > services
> > * sync
> > * api
> > * storage
> > is configured correctly.
> >
> > Can you check that these tests work in your setup.
> >
> >
> 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.

Regards,
Klaus

[Fabio Leimgruber]

On Wednesday, May 14, 2014 5:58:18 PM UTC+2, Klaus Flittner wrote:

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.

Ah well that was that. Thanks again for clarification.
 

> 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.

Same here.
 

If you can access all three from the client computer make sure you get the same result for storage access from the dataserver itself.

Just tried it with the curl tool on the dataserver, same results with all 3 of them.

Regards,
Fabio

[Fabio Leimgruber]

I went through the instructions (plus updates) again and now have the following logs on `tail -f`:

/srv/zotero/log/upload/current
/srv/zotero/log/download/current
/srv/zotero/log/error/current
/srv/zotero/access.log


The daemon logs look good from what you told me earlier, i.e. they start sync processors and tell me that their queue is empty afterwards:

2014-05-22T12:24:04.64762 2014-05-22 08:24:04.6474 0 processors, 0 queued processes
2014-05-22T12:25:02.76792 2014-05-22 08:25:02.7674 Purged 0 lost processors
2014-05-22T12:25:02.76890 2014-05-22 08:25:02.7686 Purged 0 old processes
2014-05-22T12:25:02.77158 2014-05-22 08:25:02.7694 0 processors, 1 queued process
2014-05-22T12:25:02.77159 2014-05-22 08:25:02.7696 Starting 1 new processor
2014-05-22T12:25:02.84358 2014-05-22 08:25:02.8432 [1709265451] Starting sync processor
2014-05-22T12:25:03.00300 2014-05-22 08:25:03.0028 [1709265451] Process completed in 0.16 seconds
2014-05-22T12:25:03.00456 2014-05-22 08:25:03.0044 0 processors, 0 queued processes


Likewise, the access log shows POSTs and GETs:

10.101.13.5 - testuser [22/May/2014:14:56:31 +0200] "GET /?auth=1 HTTP/1.1" 200 426
10.101.13.5 - testuser [22/May/2014:14:56:31 +0200] "GET /groups/1/laststoragesync HTTP/1.1" 404 442
10.101.13.5 - testuser [22/May/2014:14:56:31 +0200] "GET /groups/2/laststoragesync HTTP/1.1" 404 610
10.101.13.5 - testuser [22/May/2014:14:56:32 +0200] "GET /groups/2/items/VABUDRHV/file?auth=1&iskey=1&version=1&info=1 HTTP/1.1" 404 442
10.101.13.5 - testuser [22/May/2014:14:56:32 +0200] "POST /groups/2/items/VABUDRHV/file?auth=1&iskey=1&version=1 HTTP/1.1" 200 1018
10.101.13.5 - - [22/May/2014:14:57:25 +0200] "POST /sync/login HTTP/1.1" 200 1942
10.101.13.5 - - [22/May/2014:14:57:26 +0200] "POST /sync/updated HTTP/1.1" 200 474
10.101.13.5 - - [22/May/2014:14:57:34 +0200] "POST /sync/updated HTTP/1.1" 200 6050
10.101.13.5 - - [22/May/2014:14:57:35 +0200] "GET /?auth=1 HTTP/1.1" 401 458
10.101.13.5 - testuser [22/May/2014:14:57:35 +0200] "GET /?auth=1 HTTP/1.1" 200 426
10.101.13.5 - testuser [22/May/2014:14:57:35 +0200] "GET /groups/1/laststoragesync HTTP/1.1" 404 442
10.101.13.5 - testuser [22/May/2014:14:57:35 +0200] "GET /groups/2/laststoragesync HTTP/1.1" 404 610
10.101.13.5 - testuser [22/May/2014:14:57:35 +0200] "POST /sync/updated HTTP/1.1" 200 538


I think I finally tracked it down in the /var/log/uwsgi/app/zss.log - my bad: you already told me to have a look there...

Thu May 22 14:21:56 2014 - lock engine: pthread robust mutexes
Thu May 22 14:21:56 2014 - uwsgi socket 0 bound to UNIX address /run/uwsgi/app/zss/socket fd 3
Thu May 22 14:21:56 2014 - initialized Perl 5.14.2 main interpreter at 0x97e8918
Thu May 22 14:21:56 2014 - your server socket listen backlog is limited to 100 connections
Thu May 22 14:21:56 2014 - *** Operational MODE: preforking ***
Thu May 22 14:21:57 2014 - PSGI app 0 (/srv/zotero/zss/zss.psgi) loaded in 1 seconds at 0x9cccee0 (interpreter 0x97e8918)
Thu May 22 14:21:57 2014 - *** uWSGI is running in multiple interpreter mode ***
Thu May 22 14:21:57 2014 - spawned uWSGI master process (pid: 2060)
Thu May 22 14:21:57 2014 - spawned uWSGI worker 1 (pid: 2104, cores: 1)
Thu May 22 14:21:57 2014 - spawned uWSGI worker 2 (pid: 2105, cores: 1)

So it looks as though the uWSGI workers do not finish their work, visible in the client by the green sync arrow spinning non-stop since then... where to look next?

Much obliged as always,
Fabio

[Klaus Flittner]

Fabio Leimgruber wrote:

> I went through the instructions (plus updates) again and now have the
> following logs on `tail -f`:
>
> /srv/zotero/log/upload/current
> /srv/zotero/log/download/current
> /srv/zotero/log/error/current
> /srv/zotero/access.log
>

> [...]

>
> I think I finally tracked it down in the /var/log/uwsgi/app/zss.log - my
> bad: you already told me to have a look there...
>
> Thu May 22 14:21:56 2014 - lock engine: pthread robust mutexes
> Thu May 22 14:21:56 2014 - uwsgi socket 0 bound to UNIX address
> /run/uwsgi/app/zss/socket fd 3
> Thu May 22 14:21:56 2014 - initialized Perl 5.14.2 main interpreter at
> 0x97e8918
> Thu May 22 14:21:56 2014 - your server socket listen backlog is limited to
> 100 connections
> Thu May 22 14:21:56 2014 - *** Operational MODE: preforking ***
> Thu May 22 14:21:57 2014 - PSGI app 0 (/srv/zotero/zss/zss.psgi) loaded in
> 1 seconds at 0x9cccee0 (interpreter 0x97e8918)
> Thu May 22 14:21:57 2014 - *** uWSGI is running in multiple interpreter
> mode ***
> Thu May 22 14:21:57 2014 - spawned uWSGI master process (pid: 2060)
> Thu May 22 14:21:57 2014 - spawned uWSGI worker 1 (pid: 2104, cores: 1)
> Thu May 22 14:21:57 2014 - spawned uWSGI worker 2 (pid: 2105, cores: 1)
>
> So it looks as though the uWSGI workers do not finish their work, visible
> in the client by the green sync arrow spinning non-stop since then... where
> to look next?

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.

A successful file upload should look like the following example in the log files:
10.2.0.1 is the ip of the client and 10.2.100.85 is the server.

access.log
10.2.0.1 - testuser2 [24/May/2014:20:30:40 +0200] "GET /users/2/items/BF6CKW7E/file?auth=1&iskey=1&version=1&info=1 HTTP/1.1" 404 329
10.2.0.1 - testuser2 [24/May/2014:20:30:40 +0200] "POST /users/2/items/BF6CKW7E/file?auth=1&iskey=1&version=1 HTTP/1.1" 200 1124
10.2.0.1 - - [24/May/2014:20:30:41 +0200] "POST /zotero/ HTTP/1.1" 201 88
10.2.100.85 - - [24/May/2014:20:30:42 +0200] "HEAD /zotero/340c59926003b2e16e8f47fd58079d4f/pgfplots.pdf HTTP/1.1" 200 44
10.2.0.1 - testuser2 [24/May/2014:20:30:42 +0200] "POST /users/2/items/BF6CKW7E/file?auth=1&iskey=1&version=1 HTTP/1.1" 204 276

zss.log:
[pid: 2091|app: 0|req: 1/1] 10.2.0.1 () {40 vars in 728 bytes} [Sat May 24 20:30:41 2014] POST /zotero/ => generated 0 bytes in 1480 msecs (HTTP/1.1 201) 3 headers in 88 bytes (0 switches on core 0)
[pid: 2091|app: 0|req: 2/2] 10.2.100.85 () {32 vars in 509 bytes} [Sat May 24 20:30:42 2014] HEAD /zotero/340c59926003b2e16e8f47fd58079d4f/pgfplots.pdf => generated 0 bytes in 11 msecs (HTTP/1.1 200) 1 headers in 44 bytes (0 switches on core 0)

HTH,
Klaus

[Fabio Leimgruber]

On Saturday, May 24, 2014 8:42:54 PM UTC+2, Klaus Flittner wrote:

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.

Ah well that does make sense, I should have thought of that.
 
I changed it accordingly and got an error in the /var/log/uwsgi/app/zss.log:
Mon May 26 11:48:50 2014 - [uwsgi-perl error] mkdir /srv/zotero/storagea: Permission denied at /srv/zotero/zss//ZSS/Store.pm line 27

I had a look into that file on line 27:
my $dir = $self->{storagepath} . substr($filename, 0, 1) . "/" . $filename ."/";

So I gathered there must be a missing "/" in the ZSS.pm. I will add a note to the install instructions regarding the trailing slash.

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?

Best Regards,
Fabio

[1] https://groups.google.com/forum/#!topic/zotero-dev/p5Mlvnw3nXY

 

[Klaus Flittner]

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.
That should fix your problem.

Klaus

[Fabio Leimgruber]

I tried both - to no avail. I get "couldn't connect to host" and (for the non 127.0.0.1 IP)

[Mon Jun 02 10:01:53 2014] [error] [client 10.101.13.5] Slow API request : 63.16 sec for POST /groups/1/items/STE24JIF/file?auth=1&iskey=1&version=1

Since I can't get it to work with our weird network setup, I will wait and see if I can convince our ITO to give me a proper server.

Thanks to your help, setting up a new server should be a breeze.

Best Regards,
Fabio

[Fabio Leimgruber]

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.

 

I just got it to work! The key was to set the host "127.0.0.1 zoteroserver" but also to let the VM know about the remapping of 12343 to 8443 via

: sudo iptables -t nat -I PREROUTING --src 0/0 --dst 127.0.0.1 -p tcp --dport 12343 -j REDIRECT --to-ports 8443

: sudo iptables-save

Also, I needed to enable the self-signed certificate via

: sudo cp /etc/apache2/zotero.crt /usr/local/share/ca-certificates/

: sudo update-ca-certificates

Klaus, I very much appreciate your continued help and your efforts on zotero server in general, thanks for that and keep up the good work!

Best Regards,
Fabio