How to deply web library on my own webserver?

Hi,
Because of local computer file encryption, I can't sync all files between different platform.
How to deply web library on my own webserver so that I can use web library in my all platform.
  • Web library is just a web-based front-end and I don't think deploying it on your own server will address any issue with synchronization you might be experiencing.

    Could you describe what problem is that you're trying to solve exactly? Is this related to your other post?
  • Hi @tnajdek ,
    What a pity that web-library is just a web-based front-end, not a full server side programe.
    That is my post and my problem is:
    1. My situation: My local PC in organization has been installed one kind of local hard disk encryption soft ware, it will encrypt all my local documents include zotero database PDF documents. Then I can't sync these databases and PDF files to other computer such as laptop or macOS, because all files are encrypted and can't read on those device.

    2. my appeal: find a server side full function program and deploy it on my own server, I can upload/manage/read/mark all documents on web side via web pages.

    I did't find this kind of program until now.
  • The entire Zotero ecosystem, including the dataserver, is open source, though setting this up is non-trivial and not something that's officially supported. You can find a couple of third party repos that have semi-packaged solutions for this, all a bit outdated, though (I think "ZotPrime" or so is one of the more recent ones).
  • ZotPrime build failed finally like this, I post issue on github. Can you recommand other third party repos to me so that I can try it now?
    ```
    File "/usr/share/python-wheels/urllib3-1.22-py2.py3-none-any.whl/urllib3/response.py", line 316, in _error_catcher
    raise ReadTimeoutError(self._pool, None, 'Read timed out.')
    ReadTimeoutError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out.
    The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive pip install awscli' returned a non-zero code: 2
    ERROR: Service 'app-zotero' failed to build : Build failed
    ```
  • @freedoc even if you did deploy your own sync infrastructure which, as @adamsmith explained, is not trivial, I don't believe it would fix your issue.

    If I understand correctly, based on your other post, your PC is running a piece of software that encrypts (some?) files in such a way that even software on your on own PC cannot decrypt these without injection of a specially prepared library. Thus, no matter where Zotero syncs, files that are being synced will remain encrypted and therefore not readable, be it on another machine or in the web library.

    The way disk encryption is done on your PC is unusual, in most scenarios disk encryption is done on hardware or OS level, meaning it's completely transparent to user-space software running on given machine.

    Is there someone in your organization you could speak with about relaxing restrictions on your PC?
  • @tnajdek Thank you for your patience, I can't find anyone else to talk about this topic.
    The restrictions can't be relaxed because it is a overall strategy.

    I can use a virtual machine Windows 10 OS to download the literatures and upload it to the server platform, and then read and manage the literatures on the server. So finally the files on my server will not be encrypted.

    I may have two solutions:
    1. Server OS: windows, runs zotero windows client on it. Then I use remote desktop access(RDP protocol) tool to use it. This is not convient on different devices.
    2. Server OS: Linux, runs a kind of zotero platform on it, provides web browser access. This is very convient on different devices.

    If I can deploy the method 2. successfully, that could be better.
  • I mean -- I guess you could install a Zotero server and then run the web library on it and use that to manage Zotero, but the web library is much less powerful than Zotero itself, so at that point, what are you really getting out of this?
    Otoh, running Zotero in a Windows RDS environment works pretty nicely. I'd just go with that.
  • "it's all is open source" does't mean a thing here.

    Its like throwing all parts on the table without any manual and then say, "There you go: a car. It can drive".

    Maybe we should call Zotero "closed server use" as only developers and geeks can run their own server. I sense there are enough people that want this option but it is of no intrest of developers.

    For my humty dumpty project I like to control my own Bibtex manager online behind closed doors on my own website not in the 'cloud'. It can't be that hard to just provide the means to do that right?

    Come forth with the golden server manual! ;-)

    Now I am looking at wikindx, its old, robust does not support csl (yet?) but has soon connectors so it gets the job done.

    my 5ct...
  • Running the type of server operation that Zotero *requires* will always be for geeks. Zotero can do *vastly* more than just sharing a bibtex file (which you can essentially just do with Dropbox or so). If you don't need that, sure you can find a different solution (I think JabRef should work like that since it works of a bibtex database?), so you have to actually be able to set up, run and maintain your own server, including database software etc.

    This could be made *easier* for highly technical users (and that's what 3rd party projects like ZotPrime aim to do), but it will never be an option for people without significant technical skills. That also means it's a fairly labor-intensive thing to do that benefits a very small user group, which is why it's not a major priority for Zotero developers: it's not like this is something that already exists that they're hiding. Zotero devs have mentioned that this is something they're generally interested in doing (most likely in the form of a docker container), but there are many other things that stand to benefit most users rather than .1% of them, so, again, a question of priorities and available time.
Sign In or Register to comment.