You were spot-on on the diagnosis. In the end, I simply added a softlink in [/usr/bin] named `gpg2` that points to `gpg` instead of tweaking the SRPM configure script. Incidentally, running `gpgme-config --get-gpg` inside the initrd does indicate the use of [/usr/bin/gpg2] by `gpgme.` I also double-checked the SRPM logs and found the autoconfig does correctly indicate [/usr/bin/gpg] as the engine and there were no consequential references to gpg2 upon a grep of the rpmbuild directory. I did not build the gpgme libraries from an SRPM, so perhaps the binary RPMs for gpgme default to `gpg2`? In any case, it is working perfectly now, and I look forward to the aforementioned feature enhancement in a future release! Now on to the OpenWRT build...
Thanks again -
Based on the error message it appears that libgpgme is not finding gpg or it is not able to run /usr/bin/gpg for some reason. Can you look at your SRPM build logs to see the final output of the fwknop's configure script and see what it indicated as the path it used for "Gpgme engine;"? Actually, it would be a good idea to scan the configure log for clues (i.e. warnings or missing files/libs/packages that should be there but were not treated as an error).
Most recent gpgme implementations use /usr/bin/gpg2, but libfko requires gpgme to use /usr/bin/gpg. Typically, configure will find /usr/bin/gpg and set that as the default engine for libfko. If it is not found by configure, the the libgpgme default will be used (gpg2).
I'm not sure if this is the issue, but it does bring to light the fact that we should add the ability to set/override the gpg engine at runtime in both the fwknop client and server programs. Libfko does have a function to do this.
Other things you may want to try from within your initrd is "gpgme-config --get-gpg" to see what it reports (will most likely be /usr/bin/gpg2). Also try running some /usr/bin/gpg commands to make sure gpg is indeed working in that environment.
Lastly, make sure that libgpgme.so has all of its dependencies (a la ldd).
I hope this help. Please keep us posted.
On 09/07/2010 06:08 PM, firstname.lastname@example.org wrote:Hi -
I am building an initrd for a Fedora Core 13 machine (both x86_64 and i686 architectures on boxes and virtual machines). I had the perl-based fwknop v1.9.12 working inside an initrd build and decided to update to the fwknop-2.0rc1 libfko-based version to reduce the initrd size and complexity. However, after building the SRPM into the initrd environment (keeping the same GnuPG keys as before the update), I receive the following fko error upon the fwknopd server receipt of a SPA packet:
Error creating fko context: This GPGME implementation does not support OpenGPG - GPG ERROR: Invalid crypt engine.
Steps to recreate:
1) Untar existing initrd compressed tarball
2) Copy in GnuPG keyring
3) Build fwknop SRPM into initrd tree (inluding libfko libraries) & configure access.conf. fwknopd.conf
4) Copy following RPMs (via rpm -q --filesbypkg <rpmname>:into initrd tree
5) Copy in shared libraries for the following files (via ldd):
5) Re-tar & compress customized initrd into /boot & modify grub
6) Restart machine and boot into customized initrd, running fwknop daemon
7) Send SPA packet from a different machine running a fwknop client to the machine running the fwknop server inside the customized initrd
The fwknop daemon successfully runs within the initrd. However, upon receipt of a valid SPA packet from the fwknop client (client is v 1.9.12), the above error message arises. Do I need to rebuild the fwknop-server/ libfko SPRM with an additional flag and/ or copy specific OpenPGP libraries into the initrd environemnt (other than those included using the process noted above)?
As a side note, I am able to successfully ssh into the system with the customized initrd after a full boot up (after copying the appropriate configuration files from /etc/fwknop and GnuPG keyring). Given this, I think I am simply missing a few libraries from the initrd. I'll continue to dig a bit, but any pointers would be helpful!
BTW - the above processes are for testing purposes only and poses significant security risks if implemented into a production environment (particularly using the same configuration/ keys in the initrd and running system).
------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Fwknop-discuss mailing list Fwknopemail@example.com https://lists.sourceforge.net/lists/listinfo/fwknop-discuss