Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-21 Thread David Vincent 
On 2017-04-20 15:04 GMT+02:00 Martin Jansa :
> On Thu, Apr 20, 2017 at 03:37:24PM +0300, Alexander Kanavin wrote:
>> On 04/19/2017 04:03 PM, David Vincent wrote:
>> > The problem is that I must be able to manage the configuration of a machine
>> > without physical intervention and only via package upgrades. A new
>> > configuration can be applied simply by incrementing the PR of a 
>> > configuration
>> > package.
>> >
>> > But maybe this is a use case only needed by me and I should manage it in my
>> > own specific layer ?
>> >
>> > Now that I think of it, I have the same kind of problem for all machine
>> > specific configurations. For now, I just replace the PACKAGE_ARCH in my BSP
>> > layer with a machine specific one to indicate that a package contains a
>> > configuration valid only for a specific machine. Maybe, in a future 
>> > release, it
>> > should be desirable to create -conf packages based on the CONFFILES 
>> > variable ?
>> > I don't know if it's a good idea, but maybe I could bring that up on the
>> > architecture mailing list ?
>>
>> By all means please do so. Yocto lacks a solution for configuration
>> management, and this was discussed some time ago, although I cannot
>> anymore find where it happened. Mark, do you remember?

Yes I'll bring that up on the architecture mailing list to gather some advices.

>
> I still haven't seen any argument why not use u-a like for any other
> alternative files.

I don't really have an argument, it's just that it feels wrong to me to manage
configuration files via update-alternatives. Just like it did for
initscripts. I agree that
it works, until some corner cases reveal problems.
(see https://bugzilla.yoctoproject.org/show_bug.cgi?id=10433)

>
> All you have to do is create openssl bbappend (this part might be
> integrated into oe-core):
>
> inherit update-alternatives
> ALTERNATIVE_${PN} = "openssl-cnf"
> ALTERNATIVE_LINK_NAME[openssl-cnf] = "${sysconfdir}/ssl/openssl.cnf"
> ALTERNATIVE_PRIORITY[openssl-cnf] ?= "1"
>
> And then in your recipe which provides alternative config add similar
> fragment:
>
> inherit update-alternatives
> ALTERNATIVE_${PN} = "openssl-cnf"
> ALTERNATIVE_LINK_NAME[openssl-cnf] = "${sysconfdir}/ssl/openssl.cnf"
> ALTERNATIVE_PRIORITY[openssl-cnf] ?= "10"
>
> And that's it. We're using this for last 4 years since:
> https://github.com/openwebos/meta-webos/commit/b13980be3f28bf60582ec3f691e392db03942e21
> and it worked fine until this oe-core change was merged (and I had to
> undo it in the same bbappend).

OTOH, I could also append the install task for my target. There are
many solutions to
this problem, but I think that like it was said before, the main one
is handling properly the
configuration and provide a way to override it in BSP or distro layers.

>
> Regards,
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

David
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-20 Thread Martin Jansa 
On Thu, Apr 20, 2017 at 03:37:24PM +0300, Alexander Kanavin wrote:
> On 04/19/2017 04:03 PM, David Vincent wrote:
> > The problem is that I must be able to manage the configuration of a machine
> > without physical intervention and only via package upgrades. A new
> > configuration can be applied simply by incrementing the PR of a 
> > configuration
> > package.
> >
> > But maybe this is a use case only needed by me and I should manage it in my
> > own specific layer ?
> >
> > Now that I think of it, I have the same kind of problem for all machine
> > specific configurations. For now, I just replace the PACKAGE_ARCH in my BSP
> > layer with a machine specific one to indicate that a package contains a
> > configuration valid only for a specific machine. Maybe, in a future 
> > release, it
> > should be desirable to create -conf packages based on the CONFFILES 
> > variable ?
> > I don't know if it's a good idea, but maybe I could bring that up on the
> > architecture mailing list ?
> 
> By all means please do so. Yocto lacks a solution for configuration 
> management, and this was discussed some time ago, although I cannot 
> anymore find where it happened. Mark, do you remember?

I still haven't seen any argument why not use u-a like for any other
alternative files.

All you have to do is create openssl bbappend (this part might be
integrated into oe-core):

inherit update-alternatives
ALTERNATIVE_${PN} = "openssl-cnf"
ALTERNATIVE_LINK_NAME[openssl-cnf] = "${sysconfdir}/ssl/openssl.cnf"
ALTERNATIVE_PRIORITY[openssl-cnf] ?= "1"

And then in your recipe which provides alternative config add similar
fragment:

inherit update-alternatives
ALTERNATIVE_${PN} = "openssl-cnf"
ALTERNATIVE_LINK_NAME[openssl-cnf] = "${sysconfdir}/ssl/openssl.cnf"
ALTERNATIVE_PRIORITY[openssl-cnf] ?= "10"

And that's it. We're using this for last 4 years since:
https://github.com/openwebos/meta-webos/commit/b13980be3f28bf60582ec3f691e392db03942e21
and it worked fine until this oe-core change was merged (and I had to
undo it in the same bbappend).

Regards,
-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-20 Thread Mark Hatle 
On 4/20/17 7:37 AM, Alexander Kanavin wrote:
> On 04/19/2017 04:03 PM, David Vincent wrote:
>> The problem is that I must be able to manage the configuration of a machine
>> without physical intervention and only via package upgrades. A new
>> configuration can be applied simply by incrementing the PR of a configuration
>> package.
>>
>> But maybe this is a use case only needed by me and I should manage it in my
>> own specific layer ?
>>
>> Now that I think of it, I have the same kind of problem for all machine
>> specific configurations. For now, I just replace the PACKAGE_ARCH in my BSP
>> layer with a machine specific one to indicate that a package contains a
>> configuration valid only for a specific machine. Maybe, in a future release, 
>> it
>> should be desirable to create -conf packages based on the CONFFILES variable 
>> ?
>> I don't know if it's a good idea, but maybe I could bring that up on the
>> architecture mailing list ?
> 
> By all means please do so. Yocto lacks a solution for configuration 
> management, and this was discussed some time ago, although I cannot 
> anymore find where it happened. Mark, do you remember?
> 

I don't remember anything specific about the configuration management, just that
we discussed it.  Sorry.

I do know that this is an issue, and what we've said in the past was create a
.bbappend, set PACKAGE_ARCH to MACHINE_ARCH, add your machine specific
configuration to the package.

Down side of this is that if only the configuration file is different then you
now have a separate binary specific to that machine -- wasted space on a feed
server.

The other alternative I know of is to use the rootfs post scripting and replace
the conf files with the ones specific to that -build-.  This is similar to a
manufacturing step in a traditional ODM/OEM relationship.

At least with RPM, if the CONFFILES are set right, any configurations set this
way should NOT be overridden on a target upgrade.

(and any CONFFILE entries not set right are bugs IMHO...)

--Mark

> Alex
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-20 Thread Alexander Kanavin 

On 04/19/2017 04:03 PM, David Vincent wrote:

The problem is that I must be able to manage the configuration of a machine
without physical intervention and only via package upgrades. A new
configuration can be applied simply by incrementing the PR of a configuration
package.

But maybe this is a use case only needed by me and I should manage it in my
own specific layer ?

Now that I think of it, I have the same kind of problem for all machine
specific configurations. For now, I just replace the PACKAGE_ARCH in my BSP
layer with a machine specific one to indicate that a package contains a
configuration valid only for a specific machine. Maybe, in a future release, it
should be desirable to create -conf packages based on the CONFFILES variable ?
I don't know if it's a good idea, but maybe I could bring that up on the
architecture mailing list ?


By all means please do so. Yocto lacks a solution for configuration 
management, and this was discussed some time ago, although I cannot 
anymore find where it happened. Mark, do you remember?



Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-19 Thread David Vincent 
On mercredi 19 avril 2017 13:57:40 CEST Alexander Kanavin wrote:
> On 04/19/2017 02:53 PM, David Vincent wrote:
> >> This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
> >> think. Look for examples in rootfs-postcommands.bbclass.
> > 
> > The problem of ROOTFS_POSTPROCESS_COMMAND is that it is a one shot
> > function
> > that is run at image creation. In my case, I must be able to upgrade the
> > package over time via package management tools. Sorry for not bringing
> > that up before.
> 
> What is it in the openssl config file that must be managed via package
> updates?
The problem is that I must be able to manage the configuration of a machine 
without physical intervention and only via package upgrades. A new 
configuration can be applied simply by incrementing the PR of a configuration 
package.

But maybe this is a use case only needed by me and I should manage it in my 
own specific layer ?

Now that I think of it, I have the same kind of problem for all machine 
specific configurations. For now, I just replace the PACKAGE_ARCH in my BSP 
layer with a machine specific one to indicate that a package contains a 
configuration valid only for a specific machine. Maybe, in a future release, it 
should be desirable to create -conf packages based on the CONFFILES variable ? 
I don't know if it's a good idea, but maybe I could bring that up on the 
architecture mailing list ?
> 
> Alex

David
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-19 Thread Alexander Kanavin 

On 04/19/2017 02:57 PM, Alexander Kanavin wrote:

On 04/19/2017 02:53 PM, David Vincent wrote:


This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
think. Look for examples in rootfs-postcommands.bbclass.


The problem of ROOTFS_POSTPROCESS_COMMAND is that it is a one shot
function
that is run at image creation. In my case, I must be able to upgrade the
package over time via package management tools. Sorry for not bringing
that up
before.


What is it in the openssl config file that must be managed via package
updates?


I mean, if you need to perform a customization to openssl.cnf, why not 
patch it in the source tree via openssl.bbappend?



Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-19 Thread Alexander Kanavin 

On 04/19/2017 02:53 PM, David Vincent wrote:


This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
think. Look for examples in rootfs-postcommands.bbclass.


The problem of ROOTFS_POSTPROCESS_COMMAND is that it is a one shot function
that is run at image creation. In my case, I must be able to upgrade the
package over time via package management tools. Sorry for not bringing that up
before.


What is it in the openssl config file that must be managed via package 
updates?


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-19 Thread David Vincent 
On mercredi 19 avril 2017 12:21:18 CEST Alexander Kanavin wrote:
> On 04/19/2017 11:27 AM, David Vincent wrote:
> > The package is then chosen during image creation based on some
> > MACHINE_FEATURES, i.e. if the machine provides a crypto accelerator to use
> > instead of relying on software implementations. I hope that these new
> > details will help you understand what I was trying to achieve.
> 
> This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I
> think. Look for examples in rootfs-postcommands.bbclass.

The problem of ROOTFS_POSTPROCESS_COMMAND is that it is a one shot function 
that is run at image creation. In my case, I must be able to upgrade the 
package over time via package management tools. Sorry for not bringing that up 
before.

> 
> Alex

David


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-19 Thread Alexander Kanavin 

On 04/19/2017 11:27 AM, David Vincent wrote:

The package is then chosen during image creation based on some
MACHINE_FEATURES, i.e. if the machine provides a crypto accelerator to use
instead of relying on software implementations. I hope that these new details
will help you understand what I was trying to achieve.


This kind of thing is better done via ROOTFS_POSTPROCESS_COMMAND, I 
think. Look for examples in rootfs-postcommands.bbclass.


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-19 Thread David Vincent 
On jeudi 13 avril 2017 10:05:29 CEST Jussi Kukkonen wrote:
> Hi David,
> 
> Just a heads-up: I will propose a revert of this patch this week unless
> better ideas come up in the mean time.
Sorry, I've been away last week so didn't have time to respond to your 
previous mails. I've seen the revert proposal but I think I could provide some 
heads-up to find a better solution to deal with my problem after the revert.
> 
> I get that you have an actual problem you're solving but I don't think
> postinstall is a correct solution. I'm sorry I don't have an alternative
> solution ready for you: if you share your other configuration recipe and
> explain how you use the two, maybe we can figure something out.
This is my other recipe that installs the alternative configuration:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://openssl-hwengine.cnf"

do_install_append () {
install -m 0644 ${WORKDIR}/openssl-hwengine.cnf ${D}${sysconfdir}/ssl/
}

PACKAGES =+ "${PN}-conf-hwengine"

FILES_${PN}-conf-hwengine = "${sysconfdir}/ssl/openssl-hwengine.cnf"
CONFFILES_${PN}-conf-hwengine = "${sysconfdir}/ssl/openssl-hwengine.cnf"
RPROVIDES_${PN}-conf-hwengine += "${PN}-conf"
RCONFLICTS_${PN}-conf-hwengine += "${PN}-conf"
RREPLACES_${PN}-conf-hwengine += "${PN}-conf"
RDEPENDS_${PN}-conf-hwengine = "libp11-engine"
RDEPENDS_${PN}-conf-hwengine_class-native = ""
RDEPENDS_${PN}-conf-hwengine_class-nativesdk = ""

pkg_postinst_${PN}-conf-hwengine () {
#!/bin/sh
if [ -e $D${libdir}/ssl/openssl.cnf ]; then
rm -f $D${libdir}/ssl/openssl.cnf
fi

# If openssl-conf is installed before openssl, we must ensure that the symlink
# destination exists
mkdir -p $D${libdir}/ssl/
ln -s ${sysconfdir}/ssl/openssl-hwengine.cnf $D${libdir}/ssl/openssl.cnf
}


The package is then chosen during image creation based on some 
MACHINE_FEATURES, i.e. if the machine provides a crypto accelerator to use 
instead of relying on software implementations. I hope that these new details 
will help you understand what I was trying to achieve.

> 
> Jussi
> 

David
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-07 Thread Martin Jansa 
On Fri, Apr 07, 2017 at 02:27:45PM +0200, David Vincent wrote:
> On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote:
> > I still don't understand why not use standard update-alternatives and
> > install another package with your favorite openssl.conf which has higher
> > ALTERNATIVE_PRIORITY.
> 
> Why not, but maybe this https://bugzilla.yoctoproject.org/show_bug.cgi?
> id=10777 can be a stopper since libcrypto RRECOMMENDS openssl-conf

Why would it be a stopper? With u-a you can have any number of the u-a
alternative providers installed in the image at the same time.

> > This way u-a will switch to new config even when you just install the
> > package which require it on the target later and will switch back to
> > default openssl.conf when the alternative package with config file is
> > uninstalled.
> > 
> > On Thu, Apr 6, 2017 at 12:55 PM, Jussi Kukkonen 
> >> So previously openssl-conf package included etc/ssl/openssl.cnf and the
> >> symlink ${libdir}/ssl/openssl.conf.
> 
> The symlink is not inside openssl-conf package but rather inside openssl.
> 
> >> Nothing RDEPENDS on this package (but
> >> libcrypto RRECOMMENDS it).
> >> 
> >> After your patch the actual configuration file is still installed. In a
> >> postinst
> >> 
> >>   * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it's for
> >> upgrading, then this should happen in a prerm or postrm)
> >>   * the symlink ${libdir}/ssl/openssl.conf is created
> >> 
> >> My confusion is this: how does the above solve the problem you describe?
> >> If you've managed to use RCONFLICTS to prevent the configuration package
> >> from getting included in the image, why are changes to the package needed?
> >> 
> 
> To avoid creation of the symlink inside openssl package. But I agree for the 
> postrm/prerm tasks instead of postinst.
> 
> >> 
> >> Some alternative solutions to your problem I think might work:
> >> * openssl_%.bbappend with a do_install_append() that simply copies your
> >> conf file over the one from upstream recipe. No extra packages needed
> >> * BAD_RECOMMENDATIONS or PACKAGE_EXCLUDE to prevent openssl-conf from
> >> getting included in your image, then adding your own package with your
> >> configuration (does not work for dpkg I think)
> >> 
> 
> I could consider this if the patch gets reverted, but I still prefer using 
> extra packages. It's easier this way to know which configuration has been 
> applied (but update-alternatives could work too).
> 
> TBH, I say that because I've submitted a similar series of patches for 
> openssh 
> based on the same principle. I think my main problem is the handling of 
> configuration files at build time. This holds especially true for read-only 
> rootfs where these files must be available at build time. Is there guidelines 
> for that ?
> 
> >> Jussi
> >> 
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> David

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-07 Thread Jussi Kukkonen 
On 7 April 2017 at 15:27, David Vincent  wrote:
>
> On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote:
> > I still don't understand why not use standard update-alternatives and
> > install another package with your favorite openssl.conf which has higher
> > ALTERNATIVE_PRIORITY.
>
> Why not, but maybe this https://bugzilla.yoctoproject.org/show_bug.cgi?
> id=10777 can be a stopper since libcrypto RRECOMMENDS openssl-conf
>
> > This way u-a will switch to new config even when you just install the
> > package which require it on the target later and will switch back to
> > default openssl.conf when the alternative package with config file is
> > uninstalled.
> >
> > On Thu, Apr 6, 2017 at 12:55 PM, Jussi Kukkonen <
jussi.kukko...@intel.com>
> >> So previously openssl-conf package included etc/ssl/openssl.cnf and the
> >> symlink ${libdir}/ssl/openssl.conf.
>
> The symlink is not inside openssl-conf package but rather inside openssl.

Right.

> >> Nothing RDEPENDS on this package (but
> >> libcrypto RRECOMMENDS it).
> >>
> >> After your patch the actual configuration file is still installed. In a
> >> postinst
> >>
> >>   * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it's
for
> >> upgrading, then this should happen in a prerm or postrm)
> >>   * the symlink ${libdir}/ssl/openssl.conf is created
> >>
> >> My confusion is this: how does the above solve the problem you
describe?
> >> If you've managed to use RCONFLICTS to prevent the configuration
package
> >> from getting included in the image, why are changes to the package
needed?
> >>
>
> To avoid creation of the symlink inside openssl package.

I'm really not trying to be difficult but ... that still doesn't help me
understand your reasons at all and I think I need to if I want to fix the
current issue.

Could you please explain what your other configuration recipe does and what
files it contains, how you switch between the two and why the symlink in a
postinstall works for you but an installed symlink does not.

Thank you,
 Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-07 Thread David Vincent 
On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote:
> I still don't understand why not use standard update-alternatives and
> install another package with your favorite openssl.conf which has higher
> ALTERNATIVE_PRIORITY.

Why not, but maybe this https://bugzilla.yoctoproject.org/show_bug.cgi?
id=10777 can be a stopper since libcrypto RRECOMMENDS openssl-conf

> This way u-a will switch to new config even when you just install the
> package which require it on the target later and will switch back to
> default openssl.conf when the alternative package with config file is
> uninstalled.
> 
> On Thu, Apr 6, 2017 at 12:55 PM, Jussi Kukkonen 
>> So previously openssl-conf package included etc/ssl/openssl.cnf and the
>> symlink ${libdir}/ssl/openssl.conf.

The symlink is not inside openssl-conf package but rather inside openssl.

>> Nothing RDEPENDS on this package (but
>> libcrypto RRECOMMENDS it).
>> 
>> After your patch the actual configuration file is still installed. In a
>> postinst
>> 
>>   * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it's for
>> upgrading, then this should happen in a prerm or postrm)
>>   * the symlink ${libdir}/ssl/openssl.conf is created
>> 
>> My confusion is this: how does the above solve the problem you describe?
>> If you've managed to use RCONFLICTS to prevent the configuration package
>> from getting included in the image, why are changes to the package needed?
>> 

To avoid creation of the symlink inside openssl package. But I agree for the 
postrm/prerm tasks instead of postinst.

>> 
>> Some alternative solutions to your problem I think might work:
>> * openssl_%.bbappend with a do_install_append() that simply copies your
>> conf file over the one from upstream recipe. No extra packages needed
>> * BAD_RECOMMENDATIONS or PACKAGE_EXCLUDE to prevent openssl-conf from
>> getting included in your image, then adding your own package with your
>> configuration (does not work for dpkg I think)
>> 

I could consider this if the patch gets reverted, but I still prefer using 
extra packages. It's easier this way to know which configuration has been 
applied (but update-alternatives could work too).

TBH, I say that because I've submitted a similar series of patches for openssh 
based on the same principle. I think my main problem is the handling of 
configuration files at build time. This holds especially true for read-only 
rootfs where these files must be available at build time. Is there guidelines 
for that ?

>> Jussi
>> 
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

David
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-06 Thread Martin Jansa 
I still don't understand why not use standard update-alternatives and
install another package with your favorite openssl.conf which has higher
ALTERNATIVE_PRIORITY.

This way u-a will switch to new config even when you just install the
package which require it on the target later and will switch back to
default openssl.conf when the alternative package with config file is
uninstalled.

On Thu, Apr 6, 2017 at 12:55 PM, Jussi Kukkonen 
wrote:

> On 6 April 2017 at 12:23, David Vincent  wrote:
> >
> > On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:
> > > This apparently breaks key generation with openssl-native because the
> file
> > > doesn't exist.
> >
> > Looking at the recipe right now, I understand why key generation is
> broken for
> > native build (I should have been more careful). I see two ways of fixing
> it :
> > - either recreate the symlink in do_install_append_class_native
> > - or simply modifiyng the OPENSSL_CONF variable in the same task.
> >
> > >
> > > I can fix it by adding one more complication to the recipe (will send a
> > > patch) but I don't think the current solution is all that great: I've
> been
> > > looking at this patch for a while now and still don't really
> understand why
> > > it is needed and how these different packages interact. I'm sure it
> makes
> > > sense when you look at the other recipe but ... isn't it a bad sign
> that
> > > that context seems to be needed?
> >
> > OK, I will provide some context because maybe my approach was wrong. In
> some
> > of my builds, I require some images to have a very specific
> configuration to
> > make OpenSSL use engines. My idea was to provide a package for this task
> since
> > the default file can not be overridden (and in fact shouldn't be for the
> native
> > build).
>
>
> So previously openssl-conf package included etc/ssl/openssl.cnf and the
> symlink ${libdir}/ssl/openssl.conf. Nothing RDEPENDS on this package (but
> libcrypto RRECOMMENDS it).
>
> After your patch the actual configuration file is still installed. In a
> postinst
>   * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it's for
> upgrading, then this should happen in a prerm or postrm)
>   * the symlink ${libdir}/ssl/openssl.conf is created
>
> My confusion is this: how does the above solve the problem you describe?
> If you've managed to use RCONFLICTS to prevent the configuration package
> from getting included in the image, why are changes to the package needed?
>
>
>
> Some alternative solutions to your problem I think might work:
> * openssl_%.bbappend with a do_install_append() that simply copies your
> conf file over the one from upstream recipe. No extra packages needed
> * BAD_RECOMMENDATIONS or PACKAGE_EXCLUDE to prevent openssl-conf from
> getting included in your image, then adding your own package with your
> configuration (does not work for dpkg I think)
>
> Jussi
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-06 Thread Jussi Kukkonen 
On 6 April 2017 at 12:23, David Vincent  wrote:
>
> On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:
> > This apparently breaks key generation with openssl-native because the
file
> > doesn't exist.
>
> Looking at the recipe right now, I understand why key generation is
broken for
> native build (I should have been more careful). I see two ways of fixing
it :
> - either recreate the symlink in do_install_append_class_native
> - or simply modifiyng the OPENSSL_CONF variable in the same task.
>
> >
> > I can fix it by adding one more complication to the recipe (will send a
> > patch) but I don't think the current solution is all that great: I've
been
> > looking at this patch for a while now and still don't really understand
why
> > it is needed and how these different packages interact. I'm sure it
makes
> > sense when you look at the other recipe but ... isn't it a bad sign that
> > that context seems to be needed?
>
> OK, I will provide some context because maybe my approach was wrong. In
some
> of my builds, I require some images to have a very specific configuration
to
> make OpenSSL use engines. My idea was to provide a package for this task
since
> the default file can not be overridden (and in fact shouldn't be for the
native
> build).


So previously openssl-conf package included etc/ssl/openssl.cnf and the
symlink ${libdir}/ssl/openssl.conf. Nothing RDEPENDS on this package (but
libcrypto RRECOMMENDS it).

After your patch the actual configuration file is still installed. In a
postinst
  * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it's for
upgrading, then this should happen in a prerm or postrm)
  * the symlink ${libdir}/ssl/openssl.conf is created

My confusion is this: how does the above solve the problem you describe? If
you've managed to use RCONFLICTS to prevent the configuration package from
getting included in the image, why are changes to the package needed?



Some alternative solutions to your problem I think might work:
* openssl_%.bbappend with a do_install_append() that simply copies your
conf file over the one from upstream recipe. No extra packages needed
* BAD_RECOMMENDATIONS or PACKAGE_EXCLUDE to prevent openssl-conf from
getting included in your image, then adding your own package with your
configuration (does not work for dpkg I think)

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-06 Thread David Vincent 
On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:
> This apparently breaks key generation with openssl-native because the file
> doesn't exist.

Looking at the recipe right now, I understand why key generation is broken for 
native build (I should have been more careful). I see two ways of fixing it :
- either recreate the symlink in do_install_append_class_native
- or simply modifiyng the OPENSSL_CONF variable in the same task.

> 
> I can fix it by adding one more complication to the recipe (will send a
> patch) but I don't think the current solution is all that great: I've been
> looking at this patch for a while now and still don't really understand why
> it is needed and how these different packages interact. I'm sure it makes
> sense when you look at the other recipe but ... isn't it a bad sign that
> that context seems to be needed?

OK, I will provide some context because maybe my approach was wrong. In some 
of my builds, I require some images to have a very specific configuration to 
make OpenSSL use engines. My idea was to provide a package for this task since 
the default file can not be overridden (and in fact shouldn't be for the native 
build). This way, using RCONFLICTS I can provide a new configuration package 
for these specific builds while maintaining the default behavior for all 
others.

> 
> Jussi
> 

David
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: Fix symlink creation

2017-04-05 Thread Jussi Kukkonen 
On 23 January 2017 at 15:59, David Vincent  wrote:

> Symlinking the openssl configuration file at install time results in
> errors when overriding it using an external package which also provides
> openssl-conf. This should be done as a postinstall task for such
> packages.
>

This apparently breaks key generation with openssl-native because the file
doesn't exist.

I can fix it by adding one more complication to the recipe (will send a
patch) but I don't think the current solution is all that great: I've been
looking at this patch for a while now and still don't really understand why
it is needed and how these different packages interact. I'm sure it makes
sense when you look at the other recipe but ... isn't it a bad sign that
that context seems to be needed?

Jussi


> Signed-off-by: David Vincent 
> ---
>  meta/recipes-connectivity/openssl/openssl.inc | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl.inc
> b/meta/recipes-connectivity/openssl/openssl.inc
> index 5cca019e1d..696b564cdd 100644
> --- a/meta/recipes-connectivity/openssl/openssl.inc
> +++ b/meta/recipes-connectivity/openssl/openssl.inc
> @@ -201,7 +201,6 @@ do_install () {
>${D}${sysconfdir}/ssl/
> ln -sf ${sysconfdir}/ssl/certs ${D}${libdir}/ssl/certs
> ln -sf ${sysconfdir}/ssl/private ${D}${libdir}/ssl/private
> -   ln -sf ${sysconfdir}/ssl/openssl.cnf ${D}${libdir}/ssl/openssl.cnf
>  }
>
>  do_install_ptest () {
> @@ -245,4 +244,16 @@ do_install_append_class-native() {
> OPENSSL_ENGINES=${libdir}/ssl/engines
>  }
>
> +pkg_postinst_openssl-conf () {
> +#!/bin/sh
> +if [ -e $D${libdir}/ssl/openssl.cnf ]; then
> +   rm -f $D${libdir}/ssl/openssl.cnf
> +fi
> +
> +# If openssl-conf is installed before openssl, we must ensure that the
> symlink
> +# destination exists
> +mkdir -p $D${libdir}/ssl/
> +ln -s ${sysconfdir}/ssl/openssl.cnf $D${libdir}/ssl/openssl.cnf
> +}
> +
>  BBCLASSEXTEND = "native nativesdk"
> --
> 2.11.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] openssl: Fix symlink creation

2017-01-23 Thread David Vincent 
Symlinking the openssl configuration file at install time results in
errors when overriding it using an external package which also provides
openssl-conf. This should be done as a postinstall task for such
packages.

Signed-off-by: David Vincent 
---
 meta/recipes-connectivity/openssl/openssl.inc | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc 
b/meta/recipes-connectivity/openssl/openssl.inc
index 5cca019e1d..696b564cdd 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -201,7 +201,6 @@ do_install () {
   ${D}${sysconfdir}/ssl/
ln -sf ${sysconfdir}/ssl/certs ${D}${libdir}/ssl/certs
ln -sf ${sysconfdir}/ssl/private ${D}${libdir}/ssl/private
-   ln -sf ${sysconfdir}/ssl/openssl.cnf ${D}${libdir}/ssl/openssl.cnf
 }
 
 do_install_ptest () {
@@ -245,4 +244,16 @@ do_install_append_class-native() {
OPENSSL_ENGINES=${libdir}/ssl/engines
 }
 
+pkg_postinst_openssl-conf () {
+#!/bin/sh
+if [ -e $D${libdir}/ssl/openssl.cnf ]; then
+   rm -f $D${libdir}/ssl/openssl.cnf
+fi
+
+# If openssl-conf is installed before openssl, we must ensure that the symlink
+# destination exists
+mkdir -p $D${libdir}/ssl/
+ln -s ${sysconfdir}/ssl/openssl.cnf $D${libdir}/ssl/openssl.cnf
+}
+
 BBCLASSEXTEND = "native nativesdk"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core