To get the environment variables in snapping

[Jin Hsieh]

Hey Manik,

Thanks for the reply!

Right, we considered that before it is obviously okay if we snap it as a
classic one,
but now we are trying to deploy such the services into Ubuntu Core.
(the services in this case: Postfix, Dovecot, ...etc.)

So you may understand what we did becomes to give those modifications to
make it works with Ubuntu Core,
and the patches we delivered are hard to sync with the upstream master
branches.
(now we have a trick to apply local patch in our launching script to
override the upstream code,
but the way is not very flexible if any updates occurred from upstream,
only prefer in using a specific version/repo)

And this is also why I want to have this discussion maybe with
snapd/snapcraft team to manage a cooler way for doing this...

But anyway,
thanks :)

BR.
Jin

On Tue, Mar 14, 2017 at 10:16 AM, Manik Taneja <manik at canonical.com> wrote:

> jin,
>
> i wonder if this would be better confined as classic?
>
> /manik
>
> On Mon, Mar 13, 2017 at 1:29 AM, Jin Hsieh <jin.hsieh at canonical.com>
> wrote:
>
> > Hello guys,
> >
> > We are making a workable mail solution snap,
> > the selected back-end services are Postfix(SMTP) and Dovecot(POP3/IMAP).
> >
> > For those services as you known they have some dependencies with classic
> > paths,
> > for example the /etc/postfix/main.cf and /etc/dovecot/dovecot.conf so we
> > made some changes on the upstream code,
> > to get the environment variables such as SNAP, SNAP_DATA/SNAP_COMMON by
> > getenv(),
> > then replace the classic one into $SNAP_DATA/etc/postfix/* to make it
> works
> > properly.
> >
> > Also, for a bigger snap like this,
> > the component(one of the parts) will execute external command to trigger
> > another one,
> > in such the case Postfix forks its child process: pipe to call
> dovecot-lda
> > (which is a sub-process of Dovecot),
> > to complete the mail retrieving function, now I would say *it is lucky to
> > have a useful configuration parameter* "export_environment" in Postfix,
> > so that we can make sure the commands could be executed correctly in our
> > snap world with specific $SNAP exported.
> >     http://www.postfix.org/postconf.5.html
> >
> >
> > But you could recognize the modification we made *is hard to upstream
> guys
> > to accept/merge the changes into their trunk*,
> > so many getenv("SNAP") in the code or in where the code flow uses
> > clean_env() we also need to cache the SNAP-related variables,
> > I am wondering if we have a better way to do this, for example an
> interface
> > or environment-sharing could make the life easier?
> >     1. then have the chances to make the upstream code up without
> > getenv("SNAP") to make their code snap-adaptive
> >     2. then have a much regular way to export environment when one
> > component calls another one externally without "export_environment"
> support
> >
> > Any feedback would be welcomed,
> > many thanks.
> >
> > BR.
> > Jin
> > --
> > Snapcraft mailing list
> > Snapcraft at lists.snapcraft.io
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/
> > mailman/listinfo/snapcraft
> >
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>