DocCyblade / tkl-mayan-edms

Turnkey Linux - Mayan EDMS
https://www.turnkeylinux.org/mayan-edms
Other
4 stars 12 forks source link

Add Nginx + Adminer common config #3

Closed DocCyblade closed 7 years ago

DocCyblade commented 7 years ago

Do we want to create a common config for Adminer to use Nginx?

Would need to add a config file for adminer in common: https://github.com/turnkeylinux/common/tree/master/overlays/adminer/etc/adminer

DocCyblade commented 7 years ago

@JedMeister - thoughts? I could just create the overlay file here, and we could decide later to use it instead

JedMeister commented 7 years ago

That sounds like a good idea to me.

Not necessarily saying you should do it, but we should also adjust the Nginx appliance as well as Mattermost and move what we can from them into common.

As you can see, I actually started doing that for Mattermost but bailed out because I was in a rush. So it's up to you whether you'd like to just do the same (and we'll clean up for v14.2) or whether you want to do it "right" from the start. Either way that commit should give you some insight into what needs to be done to get Adminer working on Nginx.

Also as an aside, we got the latest version of Adminer backported in the Debian backports repos. I plan to include that in v14.2 when we get there...

DocCyblade commented 7 years ago

@JedMeister - as always thanks for the input. I always have said if your going to do something, do it right the rust time :-)

I'll take a look and get started.

JedMeister commented 7 years ago

No worries mate. As always, feel free to ping me if you have further questions/issues/etc...

DocCyblade commented 7 years ago

@JedMeister - So hashing through this, I noticed in my own personal builds I am using Nginx more over Apache2. I am seeing it a lot more where Nginx is replacing Apache2. I see we have a lamp/lapp stack in common. How about lnpp (Linux/Nginx/PostgreSQL/PHP&Python)

If this would be the case, lnpp.mk would call the needed adminer overlay (would include the new nginx.conf), the conf scrips adminer-nginx(new). This would simplify my MayanEDMS build as it's base is LNPP.

Actually this would create a new appliance in its self (LNPP Stack) and if you want to use MySQL (LNAP).

Just thinking out loud. If you think this would be a worth while endeavor let me know. Most all of that work would be in common, that can be updated before a v14.2 release, in turn I can use that to simplify the prerequisites for Mayan, and when ready could have a LNPP Stack too.

JedMeister commented 7 years ago

We have considered moving to Nginx as default webserver (rather than Apache) but decided not to on the basis that Apache is generally more flexible and user friendly (especially considering it has a Webmin module) than Nginx. Apache also has much better documentation IMO and from my reading is the most standards complaint webserver around.

Having said that, Nginx is clearly more resource friendly and in many scenarios makes more sense.

Regarding your suggestion of a common make file, I'm not totally against the idea, but we'll probably need to convince Alon. I can anticipate that unless it is relevant to at least 2 appliances he probably won't be enthused.

FWIW a Linux Nginx MySQL/MariaDB PHP/Perl/Python stack is also often called a LEMP stack. The E comes from the pronunciation of Nginx (en-gin-x). So I guess that could make one with Postgres a LEPP stack?!?

DocCyblade commented 7 years ago

@JedMeister well Mayan EDMS is one, you get a LEPP stack, and I guess I just need one more :-)

Going to go ahead an write Mayan without any common files. Goal to get this out ASAP, and then maybe we can target a few apps that already use Nginx/PostgreSQL/PHP/Python/Perl and refactor them all :-)

JedMeister commented 7 years ago

Sounds like a fair plan to me :smile:

Although I just remembered that Alon did actually introduce a new feature into Fab a while ago (back in April) that may be relevant here? He called it unit.d (see here).

I haven't used it before, but it uses the same structure as normal (i.e. plan, overlay & conf) but allows blocks of relevant code to be gathered together (as a unit). Perhaps this might be a use case to allow moving the code to common easily?

I think that to implement it, you'd need to just create a new directory within the base of your build code repo (called unit.d), then a sub dir with a useful name, then sub dirs (plan, overlay & conf). But as I said I've never tested/used it so not sure. I guess it depends on how adventurous you're feeling vs how much you just want it done...! :smile:

DocCyblade commented 7 years ago

@JedMeister - I did see unit.d while I was looking at the deck issue and the make files. I tried your link but it won't load.

JedMeister commented 7 years ago

Hmmm, not sure why that link isn't working for you? It works fine here...?! It (should) point to the commit where Alon added unit.d support to fab:

https://github.com/turnkeylinux/fab/commit/417b7c380c06e7384905f2b00ab9b4ff834c21bc

DocCyblade commented 7 years ago

That linked worked. I'll take a look, I have always liked doing things the hard way!

DocCyblade commented 7 years ago

I really do like this idea. Would make moving common elements out and into common units!

I'll get the build working with the current then when it's working split it up into units

:-)

JedMeister commented 7 years ago

Weird that the second link worked, all I did was copy the link from the previous post and pasted it straight into the text box...

Sounds like a solid plan to me. I look forward to seeing it in motion! :smile:

DocCyblade commented 7 years ago

As per conversation above we may look at using units later time