openca-ocspd — Discussions about OCSP Responder

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Jim,

you can also try out the bugfixes branch of my fork of libpki at github:

https://github.com/mrbaseman/libpki/tree/bugfixes

if you encounter any further difficulties with that branch, please let
me know, so I can push commits with the fixes directly to the pull
request that I have opened in the official repo.

Martin

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi Martin,
I was chatting with some people here (with me) and I gather that I need to wait until you all merge your changes in, and then I should be able to download the libpki master ZIP file and use that to  try a build on RHEL 6.10/gcc 4.4.7.
Is that correct?
Thanks!
Jim



    On Friday, April 12, 2019, 12:29:29 PM UTC, o haya via Openca-ocspd <ope...@li...> wrote:  
 
  Hi Martin,
I just was looking at the libpki github and I saw your comments about the gcc version.  Ok, thanks.
So I am not so familiar with github, what do I need to download so I can try to build libpki and ocspd on RHEL 6.10 now?
Thanks again,Jim


    On Friday, April 12, 2019, 12:09:01 PM UTC, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

oh, sorry, I have looked up the version on the wrong machine when I
wrote the email (and I should correct the commit message on github,
too). I have built libpki 0.9.0 with that patch using gcc 4.4.7 on SL
6.10. So no need anymore to build on RHEL 7, no backported glibc
required and no gcc upgrade needed anymore. Also, the --disable-ecdsa
switch is fixed so that you can build against the system's openssl. Of
course you can't handle ecdsa keys for signing the ocspd answers etc.
then, but I guess you have rsa keys in use anyway.

Yes, I have seen your message, but I wouldn't trust such an environment.
Compared to that I would consider an upgrade of gcc a much safer move.
Anyhow, with the patches neither of both is required.

Martin

  _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi Martin,
I just was looking at the libpki github and I saw your comments about the gcc version.  Ok, thanks.
So I am not so familiar with github, what do I need to download so I can try to build libpki and ocspd on RHEL 6.10 now?
Thanks again,Jim


    On Friday, April 12, 2019, 12:09:01 PM UTC, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

oh, sorry, I have looked up the version on the wrong machine when I
wrote the email (and I should correct the commit message on github,
too). I have built libpki 0.9.0 with that patch using gcc 4.4.7 on SL
6.10. So no need anymore to build on RHEL 7, no backported glibc
required and no gcc upgrade needed anymore. Also, the --disable-ecdsa
switch is fixed so that you can build against the system's openssl. Of
course you can't handle ecdsa keys for signing the ocspd answers etc.
then, but I guess you have rsa keys in use anyway.

Yes, I have seen your message, but I wouldn't trust such an environment.
Compared to that I would consider an upgrade of gcc a much safer move.
Anyhow, with the patches neither of both is required.

Martin

  

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Jim,

oh, sorry, I have looked up the version on the wrong machine when I
wrote the email (and I should correct the commit message on github,
too). I have built libpki 0.9.0 with that patch using gcc 4.4.7 on SL
6.10. So no need anymore to build on RHEL 7, no backported glibc
required and no gcc upgrade needed anymore. Also, the --disable-ecdsa
switch is fixed so that you can build against the system's openssl. Of
course you can't handle ecdsa keys for signing the ocspd answers etc.
then, but I guess you have rsa keys in use anyway.

Yes, I have seen your message, but I wouldn't trust such an environment.
Compared to that I would consider an upgrade of gcc a much safer move.
Anyhow, with the patches neither of both is required.

Martin

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi Martin,
Thank you for that work!
You said "code backwards compatible for gcc 4.8.5 on RHEL/Centos 6"?  But RHEL 6 has gcc 4.4.7 and not gcc 4.8.5, right?
So to build libpki on a RHEL 6.10 system I would need to upgrade the gcc from 4.4.7 to gcc 4.8.5 somehow first, before building libpki on that RHEL 6.10 system?

Also, BTW, did you see the message I sent, re. being able to run the ocspd (and libpki) that I built on RHEL 7.6 and using gcc 4.8.5 on a RHEL 6.10 system?  We've been testing with the ocspd/libpki we built on RHEL 7.6/gcc 4.8.5 on a RHEL 6.10 system and it seems to be working all right other than complaining about the xml version (207 vs. 209, I think).
Jim



    On Friday, April 12, 2019, 9:32:37 AM UTC, Martin Hecht <he...@hl...> wrote:  
 
 Hi Max and Jim,

I have created the github pull request #41 for libpki.
Apart form the fixes for the --disable-ecdsa  switch and the database
interfaces I have also included a commit that makes the code backwards
compatible for gcc 4.8.5 on RHEL/Centos 6

I haven't build ocspd yet against the patched libpki, but I believe the
changes to the library interface are so tiny that the application should
still compile aginst the newer version. I had to make the URL strings
constant, but changing it in this direction is no problem for the
application.

I had some struggles with the ecdsa data structure. I didn't manage to
disable everything, but the relevant function calls should be skipped
now, so that the code can be linked against older openssl versions (like
in RHEL/CentOS 6) which do not yet fully support ECDSA.

Cheers, Martin




_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Max and Jim,

I have created the github pull request #41 for libpki.
Apart form the fixes for the --disable-ecdsa  switch and the database
interfaces I have also included a commit that makes the code backwards
compatible for gcc 4.8.5 on RHEL/Centos 6

I haven't build ocspd yet against the patched libpki, but I believe the
changes to the library interface are so tiny that the application should
still compile aginst the newer version. I had to make the URL strings
constant, but changing it in this direction is no problem for the
application.

I had some struggles with the ecdsa data structure. I didn't manage to
disable everything, but the relevant function calls should be skipped
now, so that the code can be linked against older openssl versions (like
in RHEL/CentOS 6) which do not yet fully support ECDSA.

Cheers, Martin

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi Martin,
Thanks!  Does that mean we will be able to build on RHEL 6.x with gcc 4.4.7 then?
Jim

    On Thursday, April 11, 2019, 2:58:27 PM UTC, Martin Hecht <he...@hl...> wrote:  
 
 Hi Max,

I think I have solved the "disable ecdsa" problem  and the problem with
the mysql interface as well.
I'll create a pull request

Cheers, Martin



_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Max,

I think I have solved the "disable ecdsa" problem  and the problem with
the mysql interface as well.
I'll create a pull request

Cheers, Martin

Re: [Openca-ocspd] Any suggestions for reducing OCSPD memory usage

[o h. <oh...@ya...>]

 Hi,
For example, right now, we have our own application that will download CRLs (the ocspd doesn't download the CRLs from the CAs) and places the downloaded CRLs on the filesystem.  I noticed that ocspd can be configured to retrieve CRLs from LDAP or DBMS?
If we configured ocspd to retrieve the CRLs from, say, LDAP, would that reduce the amount of memory that ocspd would use?
Or maybe some other ideas?
Thanks,Jim


    On Wednesday, April 10, 2019, 11:12:11 AM UTC, o haya via Openca-ocspd <ope...@li...> wrote:  
 
  Hi,
Now that I have figured out how to run the newer built version on RHEL 6.10, I need to find out if there is any hope/suggestion of how to configure ocspd to use less system memory (RAM).  

We have some systems with less RAM (like 2GB) but with the same set of CRLs as our larger systems that we would like to be able to run ocspd on.  For these smaller systems, we are willing to trade-off response speed vs. system memory usage, but right now, if we try to start ocspd on those smaller systems with the full sets of CRLs, ocspd is grabbing almost all of the system memory and basically crashes those systems.  

So we would like to find out if there is some way to configure OCSPD to work in the situations with the systems with smaller memory (but with same set of CRLs)?
Thanks,Jim




    On Tuesday, April 9, 2019, 2:42:00 PM UTC, o haya <oh...@ya...> wrote:  
 
  Hi,
I was wondering if there is any feedback/recommendations/suggestions on this (configuring OCSPD so that it uses less system memory)?
Thanks,Jim

    On Monday, April 8, 2019, 4:39:10 PM EDT, o haya <oh...@ya...> wrote:  
 
 Hi,
Now that we are able to build the "latest" OCSPD (source from https://www.openca.org/projects/ocspd/downloads.shtml; libpki 0.9.0), we have gotten a test environment configured with it on RHEL 7.6.
We have configured this environment with all of the CRLs that we had in our production environment, and now we are seeing similar behavior vis-a-vis memory usage.
When the ocspd process is started, it is taking a large amount of memory and the running OCSPD process maintains that memory continually after the startup.
For example, on the new test environment, which is an RHEL 7.6 instance with 16GB of memory (RAM), the OCSPD process appears to be taking approximately 5.6GB of memory.  The size of the files (using 'du -sbh') in the CRL directory is 643MB.
It seems like memory/RAM-to-CRL disk space is about a 10-to-1 ratio?  Does that what you all would expect as far as memory (RAM) usage?  

Are there any suggestions or recommendations for reducing the memory/RAM usage?  Are there any configuration trade-offs (e.g., not keep all CRL information in-memory) that we can do, to try to reduce the OCSPD memory usage?

FYI, the reason I/we are askling this question is that we have some environments where the system memory (RAM) is much smaller than 16GB, and we have had to shutdown (not run) OCSPD in some of those environments, because of the OCSPD memory usage, and we would like to be able to run the OCSPD, possibly even with having to trade-off speed/performance.
Thanks,Jim
    _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Any suggestions for reducing OCSPD memory usage

[o h. <oh...@ya...>]

 Hi,
Now that I have figured out how to run the newer built version on RHEL 6.10, I need to find out if there is any hope/suggestion of how to configure ocspd to use less system memory (RAM).  

We have some systems with less RAM (like 2GB) but with the same set of CRLs as our larger systems that we would like to be able to run ocspd on.  For these smaller systems, we are willing to trade-off response speed vs. system memory usage, but right now, if we try to start ocspd on those smaller systems with the full sets of CRLs, ocspd is grabbing almost all of the system memory and basically crashes those systems.  

So we would like to find out if there is some way to configure OCSPD to work in the situations with the systems with smaller memory (but with same set of CRLs)?
Thanks,Jim




    On Tuesday, April 9, 2019, 2:42:00 PM UTC, o haya <oh...@ya...> wrote:  
 
  Hi,
I was wondering if there is any feedback/recommendations/suggestions on this (configuring OCSPD so that it uses less system memory)?
Thanks,Jim

    On Monday, April 8, 2019, 4:39:10 PM EDT, o haya <oh...@ya...> wrote:  
 
 Hi,
Now that we are able to build the "latest" OCSPD (source from https://www.openca.org/projects/ocspd/downloads.shtml; libpki 0.9.0), we have gotten a test environment configured with it on RHEL 7.6.
We have configured this environment with all of the CRLs that we had in our production environment, and now we are seeing similar behavior vis-a-vis memory usage.
When the ocspd process is started, it is taking a large amount of memory and the running OCSPD process maintains that memory continually after the startup.
For example, on the new test environment, which is an RHEL 7.6 instance with 16GB of memory (RAM), the OCSPD process appears to be taking approximately 5.6GB of memory.  The size of the files (using 'du -sbh') in the CRL directory is 643MB.
It seems like memory/RAM-to-CRL disk space is about a 10-to-1 ratio?  Does that what you all would expect as far as memory (RAM) usage?  

Are there any suggestions or recommendations for reducing the memory/RAM usage?  Are there any configuration trade-offs (e.g., not keep all CRL information in-memory) that we can do, to try to reduce the OCSPD memory usage?

FYI, the reason I/we are askling this question is that we have some environments where the system memory (RAM) is much smaller than 16GB, and we have had to shutdown (not run) OCSPD in some of those environments, because of the OCSPD memory usage, and we would like to be able to run the OCSPD, possibly even with having to trade-off speed/performance.
Thanks,Jim
    

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi,
I was able to get libpki and ocspd that I built from source, built on RHEL 7.6 using gcc 4.8.5, to run on RHEL 6.10.
What I did was:
   
   - Build libpki and ocspd on RHEL 7.6 using gcc 4.8.5
   - Zip up the libpki and ocspd directories
   - On a target RHEL 6.10 system:
   
   - Build/Install a parallel GLIBC 2.14 (https://unix.stackexchange.com/questions/176489/how-to-update-glibc-to-2-14-in-centos-6-5)
   - Copy the libpki and ocspd ZIP files
   - Unzip the libpki and ocspd ZIP files in the identical directories
   - Export LD_LIBRARY_PATH
   - Run ocspd

When ocspd is run on the target RHEL 6.10 system, it gives warnings about XML2 version, but it does seem to work all right.





    On Wednesday, April 10, 2019, 9:19:49 AM UTC, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,


Re. building on RHEL 6.x: Maybe you have a different compiler installed
that you could try out, Intel perhaps? That might work, but still,
openssl has a problem with ecdsa. It's not fully supported in 1.0.1 and
libpki probably has a problem when disabling it (see my other message)

Re. your question about deploying the OCSPD:
the "make install" of libpki and ocspd places everything below the path that you can adjust with "--prefix". 
There are, however, dependencies on other libraries. Basically, configure tells you at the end against which libraries it intends to link, something like

  Libs .................: -lpthread -ldl -lrt -lldap_r -lssl -lcrypto  -lxml2 -lz -lm    -lresolv

The corresponding files are shared object files, in the case of -lssl for examlple it is libssl.so and they are searched in the $LD_LIBRARY_PATH or in the locations configured for the dynamic loader (/etc/ld.so.conf and the files included therein). Those must be available in the correct version (but don't be confused by the version numbers of the symbolic links that you might find, too. They should reflect the version number of the library, but in practice they often don't). Basically, on the production system you have to "yum install" the same libraries as on the build system, at least the ones against which you link dynamically. Then, for an upgrade, you should be able to just copy the installation directories over to the production system.

Martin



_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Jim,


Re. building on RHEL 6.x: Maybe you have a different compiler installed
that you could try out, Intel perhaps? That might work, but still,
openssl has a problem with ecdsa. It's not fully supported in 1.0.1 and
libpki probably has a problem when disabling it (see my other message)

Re. your question about deploying the OCSPD:
the "make install" of libpki and ocspd places everything below the path that you can adjust with "--prefix". 
There are, however, dependencies on other libraries. Basically, configure tells you at the end against which libraries it intends to link, something like

  Libs .................: -lpthread -ldl -lrt -lldap_r -lssl -lcrypto   -lxml2 -lz -lm    -lresolv

The corresponding files are shared object files, in the case of -lssl for examlple it is libssl.so and they are searched in the $LD_LIBRARY_PATH or in the locations configured for the dynamic loader (/etc/ld.so.conf and the files included therein). Those must be available in the correct version (but don't be confused by the version numbers of the symbolic links that you might find, too. They should reflect the version number of the library, but in practice they often don't). Basically, on the production system you have to "yum install" the same libraries as on the build system, at least the ones against which you link dynamically. Then, for an upgrade, you should be able to just copy the installation directories over to the production system.

Martin

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Max,

I think libpki 0.9.0 has a problem with disabling ECDSA. When configured
with --disable-ecdsa the following compile error occurs:

In file included from ../../libpki/pki.h:323:0,
from openssl_hsm.c:4:
../../libpki/pki_keyparams.h:18:29: error: unknown type name
‘PKI_EC_KEY_FORM’
PKI_EC_KEY_FORM curveForm,
^
compilation terminated due to -Wfatal-errors.

PKI_EC_KEY_FORM is not defined in this case, but it is used nevertheless.

I haven't looked deeply into this, yet, maybe it's just a missing #ifdef
somewhere...

Martin

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi Martin,
Re. building on RHEL 6.x:  If building on RHEL 6.x is going to require things like you mentioned (upgrading gcc, etc.), I don't think that that will be feasible for us then.  The reason is that in our production environments, the OS and components are all baselined and strictly controlled and so we cannot just do things like change the gcc or lib versions.  Given that, I think we will need to forego upgrading the OCSPD and libpki until our baseline moves to RHEL 7.x.

Re. my question about deploying the OCSPD, what I really was trying to ask was:  To deploy libpki and OCSPD to (NOTE THIS QUESTION is not asking about config file changes):
a) A target system that doesn't have either libpki or ocspd:  If we just copy the entire /xxx/libpki and /xxx/ocspd directory trees, will that be sufficient.  What I am trying to get at (i.e., find out) is, are there libs, etc. that get put into places like /usr/lib, that we'd also have to put onto the target system?
b) A target system that has an older version of libpki and ocspd:  I have kind of the same question as for (a).  In this case, if we just replace the /xxx/libpki and /xxx/ocspd directory trees on the target system, is that sufficient to upgrade the ocspd on the target system?  Or, are there other libs in places like /usr/lib, /usr/lib64, etc. that also need to be replaced on the target system.

In other words, right now/today, we have libpki and ocspd that were built from 2015, and they are in /apps/oracle/libpki and /apps/oracle/ocspd (ignore the "oracle" part of the path - that is just how we structure our directories on our systems).

Now, if we SOMEHOW (so this is a theoretical question) were able to build a newer version libpki and ocspd on RHEL 6.x and using gcc 4.4.7, then, could we just take the /apps/oracle/libpki and /apps/oracle/ocspd directories from the build system and copy them over to our prod systems, to upgrade the ocspd on our production system?
Or, are there also libs, etc. in places like /usr/lib and /usr/lib64 on the build system that we would also have to copy over to the production systems in order to upgrade the OCSPD on the production system?
Thanks.  I hope that clarifies what I was trying to ask?
Jim






    On Tuesday, April 9, 2019, 11:07:32 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

configure tries to find the necessary settings (environment variables,
command line parameters, preprocessor definitions,...) to build the
software. It sometimes thinks that it has found a suitable setup for the
compile run, but it's not always what you have intended (due to mistakes
in the inputs for the configure script, flaws of the software that
builds the configure, but often due to misleading parameters or
environment that has been presented to the configure script. So, the
config.log may help to find out what has gone wrong at configure time
that makes the compile run fail.

I have succeeded to build libpki 0.9.0 and ocspd 3.1.2 on SL 6. But....
it's a veeeery long path to get there. Probably it makes more sense to
replace the installation with a CentOS 7 or something else that is
better supported.
One problem was the compiler. The system gcc on CentOS 6 is too old to
build the latest libpki. So the procedure is:
- install the dependencies to build a newer gcc from source. In my case
it was
  yum install glibc-devel.i686 glibc-devel gcc-c++ gmp mpfr libmpc
gmp-devel mpfr-devel libmpc-devel
  but it may be a longer list, depending on what you have already installed
- build gcc 4.8.5 from source, install it to e.g. /usr/local and make
sure it is included in the $PATH, the lib directory is in
$LD_LIBRARY_PATH etc. (be prepared that this is a big task - on my
single core VM this took a couple of hours and I had to move the source
to a different partition because I was running out of disk space)
- next, the openssl 1.0.1 is too old, so you have to build
openssl-1.0.2r from source (which is the latest one on that branch at
the time of writing, and as Max has pointed out recently, the 1.1.x
branches are too new, so we are confined to the 1.0.2 branch). Install
it, make sure to build the shared library, too (it's not installed by
default), and choose a non-standard location (see below):
  ./config --prefix=/usr/local/openssl-1.0.2k shared
  then compile and install with: make ; make install
- now build libpki and pass the openssl-prefix
  ./configure --prefix=/usr/local/libpki-0.9.0
--with-openssl-prefix=/usr/local/openssl-1.0.2k --disable-mysql
  note that it is by intention that the openssl prefix is not just
/usr/local. For some reason that I don't understand (yet), the prefix
was omitted (maybe because /usr/local/lib is already in the
$LD_LIBRARY_PATH) and then the configure script did not find the ssl
libraries and chose to use the system libraries which are too old.
  Well, I have added --disable-mysql because I have the sql headers and
then the build fails, but my ocspd fetches the CRLS from disk instead of
direct database access, so I don't need that feature.
- finally build ocspd and supply the path to libpki at configure time
--with-libpki-prefix=/usr/local/libpki-0.9.0 ...

About your question how to deploy the software from a build host to a
target machine: Essentially, if the distribution is the same and the
required software packages are installed, you just can copy the software
over to the target machine. The distributions use a package manager
(yum, zypper, apt,...) and their respective format to deploy the
compiled software together with meta information like the dependencies
on other libraries, version numbers etc., but on the small scale, where
you can manually ensure that the dependencies are installed, you just
can copy the installation using scp or rsync.

Martin




_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Jim,

configure tries to find the necessary settings (environment variables,
command line parameters, preprocessor definitions,...) to build the
software. It sometimes thinks that it has found a suitable setup for the
compile run, but it's not always what you have intended (due to mistakes
in the inputs for the configure script, flaws of the software that
builds the configure, but often due to misleading parameters or
environment that has been presented to the configure script. So, the
config.log may help to find out what has gone wrong at configure time
that makes the compile run fail.

I have succeeded to build libpki 0.9.0 and ocspd 3.1.2 on SL 6. But....
it's a veeeery long path to get there. Probably it makes more sense to
replace the installation with a CentOS 7 or something else that is
better supported.
One problem was the compiler. The system gcc on CentOS 6 is too old to
build the latest libpki. So the procedure is:
- install the dependencies to build a newer gcc from source. In my case
it was
  yum install glibc-devel.i686 glibc-devel gcc-c++ gmp mpfr libmpc
gmp-devel mpfr-devel libmpc-devel
  but it may be a longer list, depending on what you have already installed
- build gcc 4.8.5 from source, install it to e.g. /usr/local and make
sure it is included in the $PATH, the lib directory is in
$LD_LIBRARY_PATH etc. (be prepared that this is a big task - on my
single core VM this took a couple of hours and I had to move the source
to a different partition because I was running out of disk space)
- next, the openssl 1.0.1 is too old, so you have to build
openssl-1.0.2r from source (which is the latest one on that branch at
the time of writing, and as Max has pointed out recently, the 1.1.x
branches are too new, so we are confined to the 1.0.2 branch). Install
it, make sure to build the shared library, too (it's not installed by
default), and choose a non-standard location (see below):
  ./config --prefix=/usr/local/openssl-1.0.2k shared
  then compile and install with: make ; make install
- now build libpki and pass the openssl-prefix
  ./configure --prefix=/usr/local/libpki-0.9.0
--with-openssl-prefix=/usr/local/openssl-1.0.2k --disable-mysql
  note that it is by intention that the openssl prefix is not just
/usr/local. For some reason that I don't understand (yet), the prefix
was omitted (maybe because /usr/local/lib is already in the
$LD_LIBRARY_PATH) and then the configure script did not find the ssl
libraries and chose to use the system libraries which are too old.
  Well, I have added --disable-mysql because I have the sql headers and
then the build fails, but my ocspd fetches the CRLS from disk instead of
direct database access, so I don't need that feature.
- finally build ocspd and supply the path to libpki at configure time
--with-libpki-prefix=/usr/local/libpki-0.9.0 ...

About your question how to deploy the software from a build host to a
target machine: Essentially, if the distribution is the same and the
required software packages are installed, you just can copy the software
over to the target machine. The distributions use a package manager
(yum, zypper, apt,...) and their respective format to deploy the
compiled software together with meta information like the dependencies
on other libraries, version numbers etc., but on the small scale, where
you can manually ensure that the dependencies are installed, you just
can copy the installation using scp or rsync.

Martin

Re: [Openca-ocspd] Any suggestions for reducing OCSPD memory usage

[o h. <oh...@ya...>]

 Hi,
I was wondering if there is any feedback/recommendations/suggestions on this (configuring OCSPD so that it uses less system memory)?
Thanks,Jim

    On Monday, April 8, 2019, 4:39:10 PM EDT, o haya <oh...@ya...> wrote:  
 
 Hi,
Now that we are able to build the "latest" OCSPD (source from https://www.openca.org/projects/ocspd/downloads.shtml; libpki 0.9.0), we have gotten a test environment configured with it on RHEL 7.6.
We have configured this environment with all of the CRLs that we had in our production environment, and now we are seeing similar behavior vis-a-vis memory usage.
When the ocspd process is started, it is taking a large amount of memory and the running OCSPD process maintains that memory continually after the startup.
For example, on the new test environment, which is an RHEL 7.6 instance with 16GB of memory (RAM), the OCSPD process appears to be taking approximately 5.6GB of memory.  The size of the files (using 'du -sbh') in the CRL directory is 643MB.
It seems like memory/RAM-to-CRL disk space is about a 10-to-1 ratio?  Does that what you all would expect as far as memory (RAM) usage?  

Are there any suggestions or recommendations for reducing the memory/RAM usage?  Are there any configuration trade-offs (e.g., not keep all CRL information in-memory) that we can do, to try to reduce the OCSPD memory usage?

FYI, the reason I/we are askling this question is that we have some environments where the system memory (RAM) is much smaller than 16GB, and we have had to shutdown (not run) OCSPD in some of those environments, because of the OCSPD memory usage, and we would like to be able to run the OCSPD, possibly even with having to trade-off speed/performance.
Thanks,Jim
  

[Openca-ocspd] Any suggestions for reducing OCSPD memory usage

[o h. <oh...@ya...>]

Hi,
Now that we are able to build the "latest" OCSPD (source from https://www.openca.org/projects/ocspd/downloads.shtml; libpki 0.9.0), we have gotten a test environment configured with it on RHEL 7.6.
We have configured this environment with all of the CRLs that we had in our production environment, and now we are seeing similar behavior vis-a-vis memory usage.
When the ocspd process is started, it is taking a large amount of memory and the running OCSPD process maintains that memory continually after the startup.
For example, on the new test environment, which is an RHEL 7.6 instance with 16GB of memory (RAM), the OCSPD process appears to be taking approximately 5.6GB of memory.  The size of the files (using 'du -sbh') in the CRL directory is 643MB.
It seems like memory/RAM-to-CRL disk space is about a 10-to-1 ratio?  Does that what you all would expect as far as memory (RAM) usage?  

Are there any suggestions or recommendations for reducing the memory/RAM usage?  Are there any configuration trade-offs (e.g., not keep all CRL information in-memory) that we can do, to try to reduce the OCSPD memory usage?

FYI, the reason I/we are askling this question is that we have some environments where the system memory (RAM) is much smaller than 16GB, and we have had to shutdown (not run) OCSPD in some of those environments, because of the OCSPD memory usage, and we would like to be able to run the OCSPD, possibly even with having to trade-off speed/performance.
Thanks,Jim

[Openca-ocspd] How to replace/upgrade OCSPD *software* to newer version?

[o h. <oh...@ya...>]

Hi,
Now that we are able to build ocspd on at least RHEL 7.6, I wanted to find out:
Assuming that we had ocspd and libpki deployed on system (call this our "target system"), and let's say we built a newer version (same OS on both the target system and the build system), what would we need to do to update the ocspd on the target system with the newer ocspd version?
Assuming that libpki was built in /apps/libpki and ocspd was build in /apps/ocspd, do we just copy over the contents of the /apps/libpki and /apps/ocspd directories from the build system to the target system?
For this question, I am mainly asking about the software itself, and not including any configuration parameters/files differences.
Thanks,Jim

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi,
Ok, I figured the build out (for RHEL 7.6).
When running the "configure" for the ocspd under RHEL 7.6, instead setting the LDFLAGS to "-R" it should be "-L", i.e.,
export LDFLAGS="-L/apps/oracle/libpki/lib64"

Jim



    On Monday, April 8, 2019, 1:43:01 PM EDT, o haya via Openca-ocspd <ope...@li...> wrote:  
 
  Hi,
We decided that, for the moment, we will try to build the ocspd on RHEL 7.6 and test to see how it behaves with our large CRLs and memory usage.

HOWEVER, now I am having trouble running the "configure" for the ocspd on RHEL 7.6 using gcc 4.8.5.  

I have downloaded the tar.gz from the Open CA OCSPD page.  After I build the libpki and do the "make install", then I bounce the machine.
And then I untar the ocdpd tar.gz file, and change dir to the untarred directory.
Then I run:
export LDFLAGS="-R/apps/oracle/libpki/lib64"
./configure --prefix=/apps/oracle/ocspd --with-libpki-prefix=/apps/oracle/libpki

and this is what happens:
[orcladmin@ip-192-168-0-204 openca-ocspd-3.1.2]$ ./configure --prefix=/apps/oracle/ocspd --with-libpki-prefix=/apps/oracle/libpki
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/apps/STAGING/openca-ocspd-3.1.2':
configure: error: C compiler cannot create executables
See `config.log' for more details

I am attaching the config.log.  Can someone tell me what might be causing this problem (I could've sworn that this worked yesterday!)?
It looks like it is doing a test compile and that compile is failing and then it quits, but I am not quite sure why.
Thanks,Jim







    On Monday, April 8, 2019, 9:43:10 AM EDT, o haya via Openca-ocspd <ope...@li...> wrote:  
 
  Hi,
I figured out how to do the build on RHEL 7.6.  I had to include a "--with-openssl-prefix=/usr" parameter.  The "configure" adds "/include/openssl" to that prefix and then looks in "/usr/include/openssl" for the *.h files that it needs to do the configuration.  

In my case, if I didn't include that parameter in the configure, it was defaulting to the directory in the "--prefix" and the "configure" would not find "ec.h" the "configure" thought that ECDSA was not enabled.
NOTE that this is only for RHEL 7.6/gcc 4.8.5.  I am not sure yet what the problem is when building libpki on RHEL 6.x :(.
Jim




    On Monday, April 8, 2019, 6:50:18 AM EDT, o haya <oh...@ya...> wrote:  
 
  Hi Martin,
Thanks for the comments, but just to be clear, when I tried to build the libpki (0.8.8  through 0.9.0), I got the error when I tried to run the "make".
Running the "configure" worked fine (no problem).
So I am not sure what you mean about checking the config.log.  Doesn't that log just reflect what happened when the "configure" was run?

Also, the real problem for us is that most (maybe all of our production and most of our development) machines are still on RHEL 6.9 or 6.10, so we are kind of stuck with gcc 4.4.7 :(...

My attempts to build with RHEL 7.6 and gcc 4.8.5 was just me trying to see if I could get the build working at all, but were not completely relevant to what we actually can use...
Jim




    On Monday, April 8, 2019, 6:39:34 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

On CentOS 7 I could build libpki 0.9.0 after I have installed the
dependencies.M aybe you find a hint in the config.log what went wrong in
your case with the ECDSA support of the openssl library.

However, when mysql is enabled I get the following compile time error
message:

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc  -I.
-I../../src/libpki  -I.. -DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   
-D__LIB_BUILD__  -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c -o
libpki_net_la-url.lo `test -f 'url.c' || echo './'`url.c

libtool: compile:  gcc -I. -I../../src/libpki -I.. -DOPENSSL_LOAD_CONF
-DENABLE_ECDSA=1 -D__LIB_BUILD__ -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF -DENABLE_ECDSA=1 -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c url.c 
-fPIC -DPIC -o .libs/libpki_net_la-url.o
url.c: In function ‘URL_get_data_url’:
url.c:305:4: error: passing argument 1 of ‘URL_get_data_mysql_url’
discards ‘const’ qualifier from pointer target type [-Werror]
    ret = URL_get_data_mysql_url( url, size );
    ^
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Makefile:583: recipe for target 'libpki_net_la-url.lo' failed

I have also tried Ubuntu 16.04 and SLES 12 SP3. On all three platforms I
see the same problem: It compiles as long as mysql client development
headers are not installed and the mysql-interface is disabled.

To come back to Jim's question about CentOS / RHEL: I ran into the same
issue on SL6 (same error messages). I could not yet compile libpki 0.9.0
on that platform. I have tried to update gcc to something newer but
couldn't resolve the dependencies yet. Anyhow, CentOS 7 should be fine,
apart from the problem with the mysql bindings.

Martin






_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
    _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi,
We decided that, for the moment, we will try to build the ocspd on RHEL 7.6 and test to see how it behaves with our large CRLs and memory usage.

HOWEVER, now I am having trouble running the "configure" for the ocspd on RHEL 7.6 using gcc 4.8.5.  

I have downloaded the tar.gz from the Open CA OCSPD page.  After I build the libpki and do the "make install", then I bounce the machine.
And then I untar the ocdpd tar.gz file, and change dir to the untarred directory.
Then I run:
export LDFLAGS="-R/apps/oracle/libpki/lib64"
./configure --prefix=/apps/oracle/ocspd --with-libpki-prefix=/apps/oracle/libpki

and this is what happens:
[orcladmin@ip-192-168-0-204 openca-ocspd-3.1.2]$ ./configure --prefix=/apps/oracle/ocspd --with-libpki-prefix=/apps/oracle/libpki
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/apps/STAGING/openca-ocspd-3.1.2':
configure: error: C compiler cannot create executables
See `config.log' for more details

I am attaching the config.log.  Can someone tell me what might be causing this problem (I could've sworn that this worked yesterday!)?
It looks like it is doing a test compile and that compile is failing and then it quits, but I am not quite sure why.
Thanks,Jim







    On Monday, April 8, 2019, 9:43:10 AM EDT, o haya via Openca-ocspd <ope...@li...> wrote:  
 
  Hi,
I figured out how to do the build on RHEL 7.6.  I had to include a "--with-openssl-prefix=/usr" parameter.  The "configure" adds "/include/openssl" to that prefix and then looks in "/usr/include/openssl" for the *.h files that it needs to do the configuration.  

In my case, if I didn't include that parameter in the configure, it was defaulting to the directory in the "--prefix" and the "configure" would not find "ec.h" the "configure" thought that ECDSA was not enabled.
NOTE that this is only for RHEL 7.6/gcc 4.8.5.  I am not sure yet what the problem is when building libpki on RHEL 6.x :(.
Jim




    On Monday, April 8, 2019, 6:50:18 AM EDT, o haya <oh...@ya...> wrote:  
 
  Hi Martin,
Thanks for the comments, but just to be clear, when I tried to build the libpki (0.8.8  through 0.9.0), I got the error when I tried to run the "make".
Running the "configure" worked fine (no problem).
So I am not sure what you mean about checking the config.log.  Doesn't that log just reflect what happened when the "configure" was run?

Also, the real problem for us is that most (maybe all of our production and most of our development) machines are still on RHEL 6.9 or 6.10, so we are kind of stuck with gcc 4.4.7 :(...

My attempts to build with RHEL 7.6 and gcc 4.8.5 was just me trying to see if I could get the build working at all, but were not completely relevant to what we actually can use...
Jim




    On Monday, April 8, 2019, 6:39:34 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

On CentOS 7 I could build libpki 0.9.0 after I have installed the
dependencies.M aybe you find a hint in the config.log what went wrong in
your case with the ECDSA support of the openssl library.

However, when mysql is enabled I get the following compile time error
message:

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc  -I.
-I../../src/libpki  -I.. -DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   
-D__LIB_BUILD__  -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c -o
libpki_net_la-url.lo `test -f 'url.c' || echo './'`url.c

libtool: compile:  gcc -I. -I../../src/libpki -I.. -DOPENSSL_LOAD_CONF
-DENABLE_ECDSA=1 -D__LIB_BUILD__ -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF -DENABLE_ECDSA=1 -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c url.c 
-fPIC -DPIC -o .libs/libpki_net_la-url.o
url.c: In function ‘URL_get_data_url’:
url.c:305:4: error: passing argument 1 of ‘URL_get_data_mysql_url’
discards ‘const’ qualifier from pointer target type [-Werror]
    ret = URL_get_data_mysql_url( url, size );
    ^
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Makefile:583: recipe for target 'libpki_net_la-url.lo' failed

I have also tried Ubuntu 16.04 and SLES 12 SP3. On all three platforms I
see the same problem: It compiles as long as mysql client development
headers are not installed and the mysql-interface is disabled.

To come back to Jim's question about CentOS / RHEL: I ran into the same
issue on SL6 (same error messages). I could not yet compile libpki 0.9.0
on that platform. I have tried to update gcc to something newer but
couldn't resolve the dependencies yet. Anyhow, CentOS 7 should be fine,
apart from the problem with the mysql bindings.

Martin






_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
    _______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi,
I figured out how to do the build on RHEL 7.6.  I had to include a "--with-openssl-prefix=/usr" parameter.  The "configure" adds "/include/openssl" to that prefix and then looks in "/usr/include/openssl" for the *.h files that it needs to do the configuration.  

In my case, if I didn't include that parameter in the configure, it was defaulting to the directory in the "--prefix" and the "configure" would not find "ec.h" the "configure" thought that ECDSA was not enabled.
NOTE that this is only for RHEL 7.6/gcc 4.8.5.  I am not sure yet what the problem is when building libpki on RHEL 6.x :(.
Jim




    On Monday, April 8, 2019, 6:50:18 AM EDT, o haya <oh...@ya...> wrote:  
 
  Hi Martin,
Thanks for the comments, but just to be clear, when I tried to build the libpki (0.8.8  through 0.9.0), I got the error when I tried to run the "make".
Running the "configure" worked fine (no problem).
So I am not sure what you mean about checking the config.log.  Doesn't that log just reflect what happened when the "configure" was run?

Also, the real problem for us is that most (maybe all of our production and most of our development) machines are still on RHEL 6.9 or 6.10, so we are kind of stuck with gcc 4.4.7 :(...

My attempts to build with RHEL 7.6 and gcc 4.8.5 was just me trying to see if I could get the build working at all, but were not completely relevant to what we actually can use...
Jim




    On Monday, April 8, 2019, 6:39:34 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

On CentOS 7 I could build libpki 0.9.0 after I have installed the
dependencies.M aybe you find a hint in the config.log what went wrong in
your case with the ECDSA support of the openssl library.

However, when mysql is enabled I get the following compile time error
message:

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc  -I.
-I../../src/libpki  -I.. -DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   
-D__LIB_BUILD__  -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c -o
libpki_net_la-url.lo `test -f 'url.c' || echo './'`url.c

libtool: compile:  gcc -I. -I../../src/libpki -I.. -DOPENSSL_LOAD_CONF
-DENABLE_ECDSA=1 -D__LIB_BUILD__ -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF -DENABLE_ECDSA=1 -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c url.c 
-fPIC -DPIC -o .libs/libpki_net_la-url.o
url.c: In function ‘URL_get_data_url’:
url.c:305:4: error: passing argument 1 of ‘URL_get_data_mysql_url’
discards ‘const’ qualifier from pointer target type [-Werror]
    ret = URL_get_data_mysql_url( url, size );
    ^
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Makefile:583: recipe for target 'libpki_net_la-url.lo' failed

I have also tried Ubuntu 16.04 and SLES 12 SP3. On all three platforms I
see the same problem: It compiles as long as mysql client development
headers are not installed and the mysql-interface is disabled.

To come back to Jim's question about CentOS / RHEL: I ran into the same
issue on SL6 (same error messages). I could not yet compile libpki 0.9.0
on that platform. I have tried to update gcc to something newer but
couldn't resolve the dependencies yet. Anyhow, CentOS 7 should be fine,
apart from the problem with the mysql bindings.

Martin






_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
    

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi Martin,
Thanks for the comments, but just to be clear, when I tried to build the libpki (0.8.8  through 0.9.0), I got the error when I tried to run the "make".
Running the "configure" worked fine (no problem).
So I am not sure what you mean about checking the config.log.  Doesn't that log just reflect what happened when the "configure" was run?

Also, the real problem for us is that most (maybe all of our production and most of our development) machines are still on RHEL 6.9 or 6.10, so we are kind of stuck with gcc 4.4.7 :(...

My attempts to build with RHEL 7.6 and gcc 4.8.5 was just me trying to see if I could get the build working at all, but were not completely relevant to what we actually can use...
Jim




    On Monday, April 8, 2019, 6:39:34 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 Hi Jim,

On CentOS 7 I could build libpki 0.9.0 after I have installed the
dependencies.M aybe you find a hint in the config.log what went wrong in
your case with the ECDSA support of the openssl library.

However, when mysql is enabled I get the following compile time error
message:

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc  -I.
-I../../src/libpki  -I.. -DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   
-D__LIB_BUILD__  -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c -o
libpki_net_la-url.lo `test -f 'url.c' || echo './'`url.c

libtool: compile:  gcc -I. -I../../src/libpki -I.. -DOPENSSL_LOAD_CONF
-DENABLE_ECDSA=1 -D__LIB_BUILD__ -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF -DENABLE_ECDSA=1 -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c url.c 
-fPIC -DPIC -o .libs/libpki_net_la-url.o
url.c: In function ‘URL_get_data_url’:
url.c:305:4: error: passing argument 1 of ‘URL_get_data_mysql_url’
discards ‘const’ qualifier from pointer target type [-Werror]
    ret = URL_get_data_mysql_url( url, size );
    ^
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Makefile:583: recipe for target 'libpki_net_la-url.lo' failed

I have also tried Ubuntu 16.04 and SLES 12 SP3. On all three platforms I
see the same problem: It compiles as long as mysql client development
headers are not installed and the mysql-interface is disabled.

To come back to Jim's question about CentOS / RHEL: I ran into the same
issue on SL6 (same error messages). I could not yet compile libpki 0.9.0
on that platform. I have tried to update gcc to something newer but
couldn't resolve the dependencies yet. Anyhow, CentOS 7 should be fine,
apart from the problem with the mysql bindings.

Martin






_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
  

Re: [Openca-ocspd] Building ocspd from files from github

[Martin H. <he...@hl...>]

Hi Jim,

On CentOS 7 I could build libpki 0.9.0 after I have installed the
dependencies.M aybe you find a hint in the config.log what went wrong in
your case with the ECDSA support of the openssl library.

However, when mysql is enabled I get the following compile time error
message:

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc  -I.
-I../../src/libpki  -I.. -DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   
-D__LIB_BUILD__  -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF  -DENABLE_ECDSA=1   -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c -o
libpki_net_la-url.lo `test -f 'url.c' || echo './'`url.c

libtool: compile:  gcc -I. -I../../src/libpki -I.. -DOPENSSL_LOAD_CONF
-DENABLE_ECDSA=1 -D__LIB_BUILD__ -I/usr/include -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable
-DOPENSSL_LOAD_CONF -DENABLE_ECDSA=1 -I/usr/include/libxml2
-I/usr/include/mysql -I/usr/include/pgsql -DLINUX -g -O2 -fstack-check
-maccumulate-outgoing-args -Werror -Wfatal-errors -MT
libpki_net_la-url.lo -MD -MP -MF .deps/libpki_net_la-url.Tpo -c url.c 
-fPIC -DPIC -o .libs/libpki_net_la-url.o
url.c: In function ‘URL_get_data_url’:
url.c:305:4: error: passing argument 1 of ‘URL_get_data_mysql_url’
discards ‘const’ qualifier from pointer target type [-Werror]
    ret = URL_get_data_mysql_url( url, size );
    ^
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Makefile:583: recipe for target 'libpki_net_la-url.lo' failed

I have also tried Ubuntu 16.04 and SLES 12 SP3. On all three platforms I
see the same problem: It compiles as long as mysql client development
headers are not installed and the mysql-interface is disabled.

To come back to Jim's question about CentOS / RHEL: I ran into the same
issue on SL6 (same error messages). I could not yet compile libpki 0.9.0
on that platform. I have tried to update gcc to something newer but
couldn't resolve the dependencies yet. Anyhow, CentOS 7 should be fine,
apart from the problem with the mysql bindings.

Martin

Re: [Openca-ocspd] Building ocspd from files from github

[o h. <oh...@ya...>]

 Hi,
So I was wondering: Do you all think it will be possible to get the libpki built on RHEL 6.x with gcc 4.4.7?
Thanks,Jim


    On Friday, April 5, 2019, 4:25:59 PM EDT, o haya <oh...@ya...> wrote:  
 
  Hi,
I made a new RHEL 7.6 RHEL machine with the dev tools on it and tried to build libpki 0.8.9 and also tried 0.9.0, and got the following error :(!!
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$ make
Making all in src
make[1]: Entering directory `/apps/STAGING/libpki-libpki-0.9.0/src'
Making all in drivers
make[2]: Entering directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers'
Making all in openssl
make[3]: Entering directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers/openssl'
/bin/sh ../../../libtool  --tag=CC   --mode=compile gcc  -I. -I../../../src/libpki  -I../..     -D__LIB_BUILD__  -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c -o libpki_token_openssl_la-openssl_hsm.lo `test -f 'openssl_hsm.c' || echo './'`openssl_hsm.c
libtool: compile:  gcc -I. -I../../../src/libpki -I../.. -D__LIB_BUILD__ -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c openssl_hsm.c  -fPIC -DPIC -o .libs/libpki_token_openssl_la-openssl_hsm.o
In file included from ../../libpki/pki.h:323:0,
                 from openssl_hsm.c:4:
../../libpki/pki_keyparams.h:18:29: error: unknown type name ‘PKI_EC_KEY_FORM’
                             PKI_EC_KEY_FORM   curveForm,
                             ^
compilation terminated due to -Wfatal-errors.
make[3]: *** [libpki_token_openssl_la-openssl_hsm.lo] Error 1
make[3]: Leaving directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers/openssl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/apps/STAGING/libpki-libpki-0.9.0/src'
make: *** [all-recursive] Error 1


So the problems are not just with RHEL6 + gcc 4.4.7, but also RHEL7 + gcc 4.8.5 has problems.
Jim







    On Friday, April 5, 2019, 3:37:53 PM EDT, o haya <oh...@ya...> wrote:  
 
  Hi Martin,
Sorry, I clicked "send" button too early...  Here is what I meant to say:
I just realized I nay have misunderstood what you said.  Are you saying that you were able to get the build to succeed?
I myself did try to comment out that line 167, but then I got a similar error but for a different typedef.
So is there a way to get this build to succeed?
Thanks,Jim



    On Friday, April 5, 2019, 3:27:00 PM EDT, oh...@ya... <oh...@ya...> wrote:  
 
 I just realized I nay have misunderstood what you said?

Sent from Yahoo Mail on Android 
 
  On Fri, Apr 5, 2019 at 8:59 AM, o haya<oh...@ya...> wrote:    Hi Martin,
Wow and "phew" :)!
I was starting to feel like I was going crazy :(!!
FYI, on my CENTOS/RHEL 6.9  and 6.10 envs, it is also gcc 4.4.7.
Jim


    On Friday, April 5, 2019, 8:46:45 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 I can reproduce this issue on Scientific Linux 6.10 (a Redhat clone)

I think it is a compiler issue and how it handles the forward
decalrations in combination with the typedef

It's gcc 4.4.7 on this platform. Commenting out that line makes the
error go away, but there are many similar places in the same file.

On 4/4/19 8:02 PM, o haya via Openca-ocspd wrote:
>  Hi,
> I went ahead and am trying to build libpki, but I am getting an error when I do the make:
>  make
> Making all in src
> make[1]: Entering directory `/apps/STAGING/libpki-master/src'
> Making all in drivers
> make[2]: Entering directory `/apps/STAGING/libpki-master/src/drivers'
> Making all in openssl
> make[3]: Entering directory `/apps/STAGING/libpki-master/src/drivers/openssl'
> /bin/sh ../../../libtool  --tag=CC   --mode=compile gcc  -I. -I../../../src/libpki  -I../..     -D__LIB_BUILD__  -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c -o libpki_token_openssl_la-openssl_hsm.lo `test -f 'openssl_hsm.c' || echo './'`openssl_hsm.c
> libtool: compile:  gcc -I. -I../../../src/libpki -I../.. -D__LIB_BUILD__ -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c openssl_hsm.c  -fPIC -DPIC -o .libs/libpki_token_openssl_la-openssl_hsm.o
> In file included from ../../libpki/openssl/data_st.h:717,
>                  from ../../libpki/crypto.h:12,
>                  from ../../libpki/pki.h:300,
>                  from openssl_hsm.c:4:
> ../../libpki/hsm_st.h:167: error: redefinition of typedef ‘PKI_MEM’
> compilation terminated due to -Wfatal-errors.
> make[3]: *** [libpki_token_openssl_la-openssl_hsm.lo] Error 1
> make[3]: Leaving directory `/apps/STAGING/libpki-master/src/drivers/openssl'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/apps/STAGING/libpki-master/src/drivers'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/apps/STAGING/libpki-master/src'
> make: *** [all-recursive] Error 1
>
>
> Has anyone encountered this problem before, and how did you fix it?
> Thanks,Jim
>
>    On Thursday, April 4, 2019, 12:35:32 PM EDT, o haya <oh...@ya...> wrote:  
>  
>  Per the earlier thread, I will download and use the tar.gz for the ocspd source, but I still am not sure about which libpki source to use?  I noted that in github, it had a change to the libpki version, from 0.8.8 to 0.8.9, so should I be downloading the libpki 0.8.9 specifically?
> Or should I be downloading the libpki-master.zip?
> Thanks,Jim
>
>    On Thursday, April 4, 2019, 11:53:03 AM EDT, o haya <oh...@ya...> wrote:  
>  
>  Hi,
> This is a followup for my previous thread (about status of ocspd).  
>
> I am going to try to build ocspd from source from github, as it appears that even though the ocspd that we shows "3.1.2" when we run "ocspd -v", that our OCSPD was built from actually more like from the 2015-2016 timeframe.  So I wanted to separate questions about doing the build here.
>
> So I downloaded the following from the github website, using the green "Download" buttons for libpki and for ocspd:
> libpki-master.zipopenca-ocspd-openca-ocspd-pre-stage.zip
> Is that the correct ZIP file for the libpki?  
>
> Thanks,Jim
>    



_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd
    
      

Re: [Openca-ocspd] GOT LIBPKI BUILD working (via hack) with RHEL7.6 and gcc 4.8.5 was Re: Building ocspd from files from github

[o h. <oh...@ya...>]

 FYI, I was also able to build the OCSPD 3.1.2 on the RHEL 7.6 and using the gcc 4.8.5.

So I think we still need to try to get the build for libpki working on RHEL 6.x and then re-test the build of ocspd after that.
Thanks,Jim



    On Friday, April 5, 2019, 5:19:40 PM EDT, o haya <oh...@ya...> wrote:  
 
  Hi,
Sorry that I changed the Subject, but wanted to flag this message.
I was able to get the "make" for libpki 0.8.9 (and 0.9.0 also) working on RHEL 7.6 and using gcc 4.8.5 (which is the gcc that goes with RHEL 7.6), but in order to do that, I had to modify the following file:
src/libpki/data_st.h
The modification that I made was to change change line 8 from empty to:
#define ENABLE_ECDSA
I was also able to do the "make install" and I *think* that that worked:
[orcladmin@ip-192-168-0-204 libpki-libpki-0.8.9]$ ls /apps/oracle/libpki/
bin  etc  include  lib64  share


Is there a way to see if the libpki build worked ok??  I ran a couple of the binaries in the bin directory and they seem to work:
[orcladmin@ip-192-168-0-204 bin]$ ./url-tool

URL Tool - v1.0
(c) 2007-2015 by Massimiliano Pala and OpenCA Labs
OpenCA Licensed software

  USAGE: url-tool [options] <URL>

Where options are:
  -out <uri>           output target uri
  -timeout <secs>      connection timeout (def. 0)
  -trusted <file>      trusted certificates file
  -no_selfsigned       don't allow self-signed certs
  -dumpcert <file>     save server cert in <file>
  -dumpchain <file>    save cert chain in <file>
  -no_verify           do not verify cert chain
  -debug               enables debugging info



So, this is all still not good, for us at least, because our machines are mostly on RHEL 6.x and not RHEL 7.x, so I think we really need to get this (libpki build and ocspd build) working on RHEL 6.x, but I hope that this might help diagnose why the build using RHEL 6.x and gcc 4.4.7 is not working??
Thanks,Jim




    On Friday, April 5, 2019, 4:25:59 PM EDT, o haya <oh...@ya...> wrote:  
 
  Hi,
I made a new RHEL 7.6 RHEL machine with the dev tools on it and tried to build libpki 0.8.9 and also tried 0.9.0, and got the following error :(!!
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$
[orcladmin@ip-192-168-0-204 libpki-libpki-0.9.0]$ make
Making all in src
make[1]: Entering directory `/apps/STAGING/libpki-libpki-0.9.0/src'
Making all in drivers
make[2]: Entering directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers'
Making all in openssl
make[3]: Entering directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers/openssl'
/bin/sh ../../../libtool  --tag=CC   --mode=compile gcc  -I. -I../../../src/libpki  -I../..     -D__LIB_BUILD__  -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c -o libpki_token_openssl_la-openssl_hsm.lo `test -f 'openssl_hsm.c' || echo './'`openssl_hsm.c
libtool: compile:  gcc -I. -I../../../src/libpki -I../.. -D__LIB_BUILD__ -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c openssl_hsm.c  -fPIC -DPIC -o .libs/libpki_token_openssl_la-openssl_hsm.o
In file included from ../../libpki/pki.h:323:0,
                 from openssl_hsm.c:4:
../../libpki/pki_keyparams.h:18:29: error: unknown type name ‘PKI_EC_KEY_FORM’
                             PKI_EC_KEY_FORM   curveForm,
                             ^
compilation terminated due to -Wfatal-errors.
make[3]: *** [libpki_token_openssl_la-openssl_hsm.lo] Error 1
make[3]: Leaving directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers/openssl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/apps/STAGING/libpki-libpki-0.9.0/src/drivers'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/apps/STAGING/libpki-libpki-0.9.0/src'
make: *** [all-recursive] Error 1


So the problems are not just with RHEL6 + gcc 4.4.7, but also RHEL7 + gcc 4.8.5 has problems.
Jim







    On Friday, April 5, 2019, 3:37:53 PM EDT, o haya <oh...@ya...> wrote:  
 
  Hi Martin,
Sorry, I clicked "send" button too early...  Here is what I meant to say:
I just realized I nay have misunderstood what you said.  Are you saying that you were able to get the build to succeed?
I myself did try to comment out that line 167, but then I got a similar error but for a different typedef.
So is there a way to get this build to succeed?
Thanks,Jim



    On Friday, April 5, 2019, 3:27:00 PM EDT, oh...@ya... <oh...@ya...> wrote:  
 
 I just realized I nay have misunderstood what you said?

Sent from Yahoo Mail on Android 
 
  On Fri, Apr 5, 2019 at 8:59 AM, o haya<oh...@ya...> wrote:    Hi Martin,
Wow and "phew" :)!
I was starting to feel like I was going crazy :(!!
FYI, on my CENTOS/RHEL 6.9  and 6.10 envs, it is also gcc 4.4.7.
Jim


    On Friday, April 5, 2019, 8:46:45 AM EDT, Martin Hecht <he...@hl...> wrote:  
 
 I can reproduce this issue on Scientific Linux 6.10 (a Redhat clone)

I think it is a compiler issue and how it handles the forward
decalrations in combination with the typedef

It's gcc 4.4.7 on this platform. Commenting out that line makes the
error go away, but there are many similar places in the same file.

On 4/4/19 8:02 PM, o haya via Openca-ocspd wrote:
>  Hi,
> I went ahead and am trying to build libpki, but I am getting an error when I do the make:
>  make
> Making all in src
> make[1]: Entering directory `/apps/STAGING/libpki-master/src'
> Making all in drivers
> make[2]: Entering directory `/apps/STAGING/libpki-master/src/drivers'
> Making all in openssl
> make[3]: Entering directory `/apps/STAGING/libpki-master/src/drivers/openssl'
> /bin/sh ../../../libtool  --tag=CC   --mode=compile gcc  -I. -I../../../src/libpki  -I../..     -D__LIB_BUILD__  -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c -o libpki_token_openssl_la-openssl_hsm.lo `test -f 'openssl_hsm.c' || echo './'`openssl_hsm.c
> libtool: compile:  gcc -I. -I../../../src/libpki -I../.. -D__LIB_BUILD__ -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -Wunused-variable -I/usr/include/libxml2 -DLINUX -g -O2 -fstack-check -maccumulate-outgoing-args -Werror -Wfatal-errors -MT libpki_token_openssl_la-openssl_hsm.lo -MD -MP -MF .deps/libpki_token_openssl_la-openssl_hsm.Tpo -c openssl_hsm.c  -fPIC -DPIC -o .libs/libpki_token_openssl_la-openssl_hsm.o
> In file included from ../../libpki/openssl/data_st.h:717,
>                  from ../../libpki/crypto.h:12,
>                  from ../../libpki/pki.h:300,
>                  from openssl_hsm.c:4:
> ../../libpki/hsm_st.h:167: error: redefinition of typedef ‘PKI_MEM’
> compilation terminated due to -Wfatal-errors.
> make[3]: *** [libpki_token_openssl_la-openssl_hsm.lo] Error 1
> make[3]: Leaving directory `/apps/STAGING/libpki-master/src/drivers/openssl'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/apps/STAGING/libpki-master/src/drivers'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/apps/STAGING/libpki-master/src'
> make: *** [all-recursive] Error 1
>
>
> Has anyone encountered this problem before, and how did you fix it?
> Thanks,Jim
>
>    On Thursday, April 4, 2019, 12:35:32 PM EDT, o haya <oh...@ya...> wrote:  
>  
>  Per the earlier thread, I will download and use the tar.gz for the ocspd source, but I still am not sure about which libpki source to use?  I noted that in github, it had a change to the libpki version, from 0.8.8 to 0.8.9, so should I be downloading the libpki 0.8.9 specifically?
> Or should I be downloading the libpki-master.zip?
> Thanks,Jim
>
>    On Thursday, April 4, 2019, 11:53:03 AM EDT, o haya <oh...@ya...> wrote:  
>  
>  Hi,
> This is a followup for my previous thread (about status of ocspd).  
>
> I am going to try to build ocspd from source from github, as it appears that even though the ocspd that we shows "3.1.2" when we run "ocspd -v", that our OCSPD was built from actually more like from the 2015-2016 timeframe.  So I wanted to separate questions about doing the build here.
>
> So I downloaded the following from the github website, using the green "Download" buttons for libpki and for ocspd:
> libpki-master.zipopenca-ocspd-openca-ocspd-pre-stage.zip
> Is that the correct ZIP file for the libpki?  
>
> Thanks,Jim
>    



_______________________________________________
Openca-ocspd mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openca-ocspd