LAMP layer

LAMP layer

[Paul Eggleton]

Hi all,

In conjunction with the folks at Wind River I'm currently in the process of 
putting together a layer to support the traditional LAMP stack, and wanted to 
solicit some opinions on how this might be structured/named/etc.

I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe 
(I'm not convinced that's where it should stay, although perhaps it need not 
be tied to this layer either). So the layer would at the very least be adding 
Apache and PHP, with the possibility of web-related python and perl recipes 
being added at a later date.

Some of the other things I'm looking at adding more immediately:

* collectd
* mysql-connector-odbc
* phpMyAdmin
* unixODBC
* xdebug

The question of how this should all be structured is still not fully 
determined. I'm thinking this ought to be at least one additional layer (i.e. 
meta-lamp, or some other name), even in the face of the proposed meta-
networking, since the number of recipes in the LAMP layer is likely to grow 
over time and it's a specific set of functionality that people would explicitly 
select.

I now have updated apache and modphp recipes building and working reasonably 
well, although further testing will be needed. Initially I'm prepared to 
maintain these recipes, however if not immediately at some point in the near 
future it would be good to see a maintainer step forward with more specific 
knowledge of these particular pieces of software.

Thoughts?

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: LAMP layer

[Marcin Juszkiewicz]

W dniu 27.06.2012 16:05, Paul Eggleton pisze:

> In conjunction with the folks at Wind River I'm currently in the 
> process of putting together a layer to support the traditional LAMP 
> stack, and wanted to solicit some opinions on how this might be 
> structured/named/etc.

Great to hear ;)

> I think we have the "L" pretty much covered ;) and we have MySQL in 
> meta-oe (I'm not convinced that's where it should stay, although 
> perhaps it need not be tied to this layer either).

MySQL is at 5.1 version - update to 5.5 would be nice to have.

> So the layer would at the very least be adding Apache and PHP, with 
> the possibility of web-related python and perl recipes being added
> at a later date.
> 
> Some of the other things I'm looking at adding more immediately:

Please add 'php-fpm' into PHP. This gives huge speed improvement
compared to classic FastCGI way.

Re: LAMP layer

[Jack Mitchell]

On 27/06/12 15:05, Paul Eggleton wrote:
> Hi all,
>
> In conjunction with the folks at Wind River I'm currently in the process of
> putting together a layer to support the traditional LAMP stack, and wanted to
> solicit some opinions on how this might be structured/named/etc.
>
> I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe
> (I'm not convinced that's where it should stay, although perhaps it need not
> be tied to this layer either). So the layer would at the very least be adding
> Apache and PHP, with the possibility of web-related python and perl recipes
> being added at a later date.
>
> Some of the other things I'm looking at adding more immediately:
>
> * collectd
> * mysql-connector-odbc
> * phpMyAdmin
> * unixODBC
> * xdebug
>
> The question of how this should all be structured is still not fully
> determined. I'm thinking this ought to be at least one additional layer (i.e.
> meta-lamp, or some other name), even in the face of the proposed meta-
> networking, since the number of recipes in the LAMP layer is likely to grow
> over time and it's a specific set of functionality that people would explicitly
> select.
>
> I now have updated apache and modphp recipes building and working reasonably
> well, although further testing will be needed. Initially I'm prepared to
> maintain these recipes, however if not immediately at some point in the near
> future it would be good to see a maintainer step forward with more specific
> knowledge of these particular pieces of software.
>
> Thoughts?
>
> Cheers,
> Paul
>
>

Hi Paul,

I think this is a fantastic idea in general and if I remember correctly 
someone from Linaro was attempting to do something similar to this the 
other day - so I can't only be me who would appreciate something like this.

The one issue I have (initially) is why should it be limited to the 
Apache web server? There are a couple of good web servers out there 
which lend themselves much more to an embedded style development than 
(IMO) the bloat that is Apache.

For example:

Lighttpd (already in core)
nginx
Hiawatha (my personal favourite - I have a recipe I already use in 
conjunction with PHP)

I also remember someone from WindRiver posted recently regarding a 
meta-networking layer, which I also thought was a great idea if not only 
for (in my use case) tftp/net-snmp support all rolled up and supported. 
Maybe this could be a layer with that "section"?

i.e.

meta-networking
     meta-webserver (meta-l*mp?)
         recipes-*
         recipes-*
     meta-*
         ....
         ....

I'm sure you get the idea...

Regards,

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: [yocto] LAMP layer

[Khem Raj]

On Wed, Jun 27, 2012 at 7:05 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi all,
>
> In conjunction with the folks at Wind River I'm currently in the process of
> putting together a layer to support the traditional LAMP stack, and wanted to
> solicit some opinions on how this might be structured/named/etc.
>
> I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe
> (I'm not convinced that's where it should stay, although perhaps it need not
> be tied to this layer either). So the layer would at the very least be adding
> Apache and PHP, with the possibility of web-related python and perl recipes
> being added at a later date.
>
> Some of the other things I'm looking at adding more immediately:
>
> * collectd
> * mysql-connector-odbc
> * phpMyAdmin
> * unixODBC
> * xdebug
>
> The question of how this should all be structured is still not fully
> determined. I'm thinking this ought to be at least one additional layer (i.e.
> meta-lamp, or some other name), even in the face of the proposed meta-
> networking, since the number of recipes in the LAMP layer is likely to grow
> over time and it's a specific set of functionality that people would explicitly
> select.
>
> I now have updated apache and modphp recipes building and working reasonably
> well, although further testing will be needed. Initially I'm prepared to
> maintain these recipes, however if not immediately at some point in the near
> future it would be good to see a maintainer step forward with more specific
> knowledge of these particular pieces of software.
>
> Thoughts?
>

I think PHP probably is common enough to be part
of meta-oe or core. instead of lamp call it something else may be
meta-webservers or something
and more alternatives can also be put in there
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: LAMP layer

[Khem Raj]

On Wed, Jun 27, 2012 at 7:05 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi all,
>
> In conjunction with the folks at Wind River I'm currently in the process of
> putting together a layer to support the traditional LAMP stack, and wanted to
> solicit some opinions on how this might be structured/named/etc.
>
> I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe
> (I'm not convinced that's where it should stay, although perhaps it need not
> be tied to this layer either). So the layer would at the very least be adding
> Apache and PHP, with the possibility of web-related python and perl recipes
> being added at a later date.
>
> Some of the other things I'm looking at adding more immediately:
>
> * collectd
> * mysql-connector-odbc
> * phpMyAdmin
> * unixODBC
> * xdebug
>
> The question of how this should all be structured is still not fully
> determined. I'm thinking this ought to be at least one additional layer (i.e.
> meta-lamp, or some other name), even in the face of the proposed meta-
> networking, since the number of recipes in the LAMP layer is likely to grow
> over time and it's a specific set of functionality that people would explicitly
> select.
>
> I now have updated apache and modphp recipes building and working reasonably
> well, although further testing will be needed. Initially I'm prepared to
> maintain these recipes, however if not immediately at some point in the near
> future it would be good to see a maintainer step forward with more specific
> knowledge of these particular pieces of software.
>
> Thoughts?
>

I think PHP probably is common enough to be part
of meta-oe or core. instead of lamp call it something else may be
meta-webservers or something
and more alternatives can also be put in there
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: LAMP layer

[Tomas Frydrych]

On 27/06/12 16:22, Jack Mitchell wrote:
> Lighttpd (already in core)
> nginx
> Hiawatha (my personal favourite - I have a recipe I already use in
> conjunction with PHP)

I'd add Cherokee to the list; there is a recipe in meta-oe.

Tomas

Re: [yocto] LAMP layer

[Paul Eggleton]

On Wednesday 27 June 2012 08:49:22 Khem Raj wrote:
> I think PHP probably is common enough to be part
> of meta-oe or core. instead of lamp call it something else may be
> meta-webservers or something
> and more alternatives can also be put in there

I don't know a huge amount about PHP but it appears to me that it can be built 
either standalone or as an Apache module - we had two separate recipes to 
build each alternative in OE-classic, and that split persists today - the 
standalone version is in meta-oe and I'm resurrecting the apache module 
version (modphp).

I don't think PHP belongs in OE-core - it's not something everyone needs. I'm 
willing to accept the standalone version might also belong in this layer 
though particularly if it turns into a more generic web server layer as you're 
suggesting. I'm not sure I can commit to cleaning up the standalone version 
though.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: LAMP layer

[Paul Eggleton]

On Wednesday 27 June 2012 08:49:22 Khem Raj wrote:
> I think PHP probably is common enough to be part
> of meta-oe or core. instead of lamp call it something else may be
> meta-webservers or something
> and more alternatives can also be put in there

I don't know a huge amount about PHP but it appears to me that it can be built 
either standalone or as an Apache module - we had two separate recipes to 
build each alternative in OE-classic, and that split persists today - the 
standalone version is in meta-oe and I'm resurrecting the apache module 
version (modphp).

I don't think PHP belongs in OE-core - it's not something everyone needs. I'm 
willing to accept the standalone version might also belong in this layer 
though particularly if it turns into a more generic web server layer as you're 
suggesting. I'm not sure I can commit to cleaning up the standalone version 
though.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: LAMP layer

[Paul Eggleton]

On Wednesday 27 June 2012 16:22:09 Jack Mitchell wrote:
> I think this is a fantastic idea in general and if I remember correctly
> someone from Linaro was attempting to do something similar to this the
> other day - so I can't only be me who would appreciate something like this.

Indeed, I saw Marcin's earlier thread - at the time I wasn't far enough along 
to reply unfortunately (was just an item on my todo list), but at least 
there's interest :)
 
> The one issue I have (initially) is why should it be limited to the
> Apache web server? There are a couple of good web servers out there
> which lend themselves much more to an embedded style development than
> (IMO) the bloat that is Apache.
> 
> For example:
> 
> Lighttpd (already in core)
> nginx
> Hiawatha (my personal favourite - I have a recipe I already use in
> conjunction with PHP)

I agree Apache is not something you would typically consider to be embedded-
friendly, however if you've already got something web-based that is built on 
top of Apache or relies on functionality that only Apache can provide, and you 
want to integrate that into an embedded product, then nothing else will really 
suffice.

However I do think there's scope to include these other alternatives 
particularly if the layer turns into more of a generic web server layer, but I 
can't commit to maintaining (specifically, updating and testing) the additional 
recipes on my own.
 
> I also remember someone from WindRiver posted recently regarding a
> meta-networking layer, which I also thought was a great idea if not only
> for (in my use case) tftp/net-snmp support all rolled up and supported.
> Maybe this could be a layer with that "section"?
> 
> i.e.
> 
> meta-networking
>      meta-webserver (meta-l*mp?)
>          recipes-*
>          recipes-*
>      meta-*
>          ....
>          ....

Whenever a new layer is introduced there's always the question of where it 
should be physically located. I worry more about the confusion that multi-
level layers cause - particularly when they're named the same thing - than I 
do about multiple repositories, but I realise others have different viewpoints. 
If they are in separate repositories there's still nothing stopping them being 
used together.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: LAMP layer

[Jack Mitchell]

On 27/06/2012 17:27, Paul Eggleton wrote:
> On Wednesday 27 June 2012 16:22:09 Jack Mitchell wrote:
>> I think this is a fantastic idea in general and if I remember correctly
>> someone from Linaro was attempting to do something similar to this the
>> other day - so I can't only be me who would appreciate something like this.
>
> Indeed, I saw Marcin's earlier thread - at the time I wasn't far enough along
> to reply unfortunately (was just an item on my todo list), but at least
> there's interest :)
>   
>> The one issue I have (initially) is why should it be limited to the
>> Apache web server? There are a couple of good web servers out there
>> which lend themselves much more to an embedded style development than
>> (IMO) the bloat that is Apache.
>>
>> For example:
>>
>> Lighttpd (already in core)
>> nginx
>> Hiawatha (my personal favourite - I have a recipe I already use in
>> conjunction with PHP)
>
> I agree Apache is not something you would typically consider to be embedded-
> friendly, however if you've already got something web-based that is built on
> top of Apache or relies on functionality that only Apache can provide, and you
> want to integrate that into an embedded product, then nothing else will really
> suffice.
>
> However I do think there's scope to include these other alternatives
> particularly if the layer turns into more of a generic web server layer, but I
> can't commit to maintaining (specifically, updating and testing) the additional
> recipes on my own.

I would be happy to contribute the hiawatha recipe (it's just simple 
cmake job), but I understand your earlier comment on standalone PHP as 
it is indeed a minefield. I tried to update it some weeks ago and failed 
miserably.

Possibly just do your part and let people send in patches against the 
layer as is done with meta-oe?

>
>   
>> I also remember someone from WindRiver posted recently regarding a
>> meta-networking layer, which I also thought was a great idea if not only
>> for (in my use case) tftp/net-snmp support all rolled up and supported.
>> Maybe this could be a layer with that "section"?
>>
>> i.e.
>>
>> meta-networking
>>       meta-webserver (meta-l*mp?)
>>           recipes-*
>>           recipes-*
>>       meta-*
>>           ....
>>           ....
>
> Whenever a new layer is introduced there's always the question of where it
> should be physically located. I worry more about the confusion that multi-
> level layers cause - particularly when they're named the same thing - than I
> do about multiple repositories, but I realise others have different viewpoints.
> If they are in separate repositories there's still nothing stopping them being
> used together.

I do agree that layers within layers is a bit confusing, however the 
earlier proposed meta-networking included having some of the 
applications in this proposed layer too. If this was instead, then it's 
fine, but if it's as well then it could get confusing.

A possible compromise could be a git sub-module for meta-lamp inside 
meta-networking, or at least a file containing the meta-lamp location 
and highlighting its availability?

>
>
> Cheers,
> Paul
>

Re: LAMP layer

[Paul Eggleton]

On Wednesday 27 June 2012 17:40:44 Jack Mitchell wrote:
> I do agree that layers within layers is a bit confusing, however the
> earlier proposed meta-networking included having some of the
> applications in this proposed layer too. If this was instead, then it's
> fine, but if it's as well then it could get confusing.

It's something I've been discussing with Joe MacDonald already. I think it's 
an either-or situation - the recipes will not need to be in both layers. 
People who want recipes from either or both layers should be able to include 
the layers as needed.
 
> A possible compromise could be a git sub-module for meta-lamp inside
> meta-networking, or at least a file containing the meta-lamp location
> and highlighting its availability?

Given the above I think a pointer in the meta-networking README towards the 
web server layer would be reasonable.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: LAMP layer

[Khem Raj]

On Wed, Jun 27, 2012 at 9:49 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>
> It's something I've been discussing with Joe MacDonald already. I think it's
> an either-or situation - the recipes will not need to be in both layers.
> People who want recipes from either or both layers should be able to include
> the layers as needed.

from my experience of deploying layers for others. Its quite a talk
for folks to get it and on top if you have overlapping recipes they
are not making life any
easier. if we start using this kind of method, it sure will fume into
chaos. I think layers should have some wholeness to them but at the
same time they should
be leveraging other layers to get functionality they need.

Re: LAMP layer

[Paul Eggleton]

On Wednesday 27 June 2012 11:01:09 Khem Raj wrote:
> On Wed, Jun 27, 2012 at 9:49 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > It's something I've been discussing with Joe MacDonald already. I think
> > it's an either-or situation - the recipes will not need to be in both
> > layers. People who want recipes from either or both layers should be able
> > to include the layers as needed.
> 
> from my experience of deploying layers for others. Its quite a talk
> for folks to get it and on top if you have overlapping recipes they
> are not making life any easier. if we start using this kind of method, it
> sure will fume into chaos. I think layers should have some wholeness to them
> but at the same time they should be leveraging other layers to get
> functionality they need.

I agree completely - my intention is not to have any overlapping recipes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre