PAR extract path, and libcrypto version.

sutaburosusutaburosu
in Feedback
fop_server2 extracts ~11MiB of files to /tmp/par-root. In accordance with the FHS's suggestion that /tmp be used only for ephemeral files, on many systems /tmp is a small RAM disk. Perhaps you might amend fop_server2 to use /var/tmp instead. If not, it would be useful to mention in your documentation that it's possible to change the location by exporting an environment variable: export PAR_GLOBAL_TEMP=/var/tmp/par-root

Currently all available versions of fop_server2 are dynamically linked against /usr/lib[64]/libcrypto.so.0.9.8.
It would be nice to have builds available linked against OpenSSL 1.0.0 too. A symlink works for the purposes of 'fop_server2 --test', but I'm worried about run-time problems due to possible API changes.

Thanks for your attention.

Comments

  • nicolasnicolas
    fop_server2 extracts ~11MiB of files to /tmp/par-root. In accordance with the FHS's suggestion that /tmp be used only for ephemeral files, on many systems /tmp is a small RAM disk. Perhaps you might amend fop_server2 to use /var/tmp instead. If not, it would be useful to mention in your documentation that it's possible to change the location by exporting an environment variable: export PAR_GLOBAL_TEMP=/var/tmp/par-root

    I will probably add it to the documentation body as you suggest. There is a mention on the FAQ about the PAR_GLOBAL_TMPDIR variable and how to modify the init script to use it, but maybe it is worth mentioning this in the standard docs as the FAQ is not related to the size of /tmp but to a specific problem if the par-root dir gets corrupted.
    Currently all available versions of fop_server2 are dynamically linked against /usr/lib[64]/libcrypto.so.0.9.8.
    It would be nice to have builds available linked against OpenSSL 1.0.0 too. A symlink works for the purposes of 'fop_server2 --test', but I'm worried about run-time problems due to possible API changes.

    As far as I know there are no issues with symlinking. FOP2 is packaged in standard (base) distributions, having separate builds based on these kind of dependencies will put most of the users in linking hell. And support requests will skyrocket too. It is already confusing enough having just 32 or 64 bit versions, centos or debian. There are lot of users with no linux experience. These are the tradeoffs of using PAR..

    Best regards,
Sign In or Register to comment.

© Asternic Corp 2024