DietPi-Software | Allow for webserver stack choices when installing software that requires a webserver.

[Fourdee]

http://fuzon.co.uk/phpbb/viewtopic.php?f=9&t=314&p=1392#p1390

Note to self: http://fuzon.co.uk/phpbb/viewtopic.php?f=9&t=314#p1384 Come to think of it, it's only the web software that we install with apt-get that would be an issue for non-apache webstacks.

Status: https://github.com/Fourdee/DietPi/issues/205#issuecomment-198367760

[rhkean]

I'll be home in 1/2 hour. I'll test the patch on my RPi2 as soon as I get home.

I'm not sure about the debconf-set-selections issue that I mentioned is actual or outdated... I got an error when I added the lighttpd patch. It prompted for one of the options last night while I was testing and then hung on that screen. while researching it today, I ran across that write-up and I thought I should mention it. (it is just between the last 2 fields... so I figured 'better safe than sorry')

I figured the spacing was for readability... I right-justified the question-type to keep it readable for you. :)

[rhkean]

I've tested WEBSERVER_PHPIMAGEGALLERY with this logic also. It works with lighttpd also. I did find a bug with it, though... the version rev'd and the link changed. I created Issue 206 for this.

[Fourdee]

@rhkean Great stuff. :+1:

I've created a list at the top of this ticket, so we can track which webserver stacks and software combos have been tested: https://github.com/Fourdee/DietPi/issues/205#issue-135861139. Let me know if i've missed any.

This should speed things up when it comes to modifying the sourcecode to implement a choice system, for software that requires a webserver stack.

[rhkean]

Testing updates (using LLAP)

• Grasshopper: no very familiar with this, but it requires SQLite. appears to run, however, with LLSP stack. (installs in root folder of webserver, though). http://<< server >>/phpliteadmin/phpliteadmin.php seems to be working correctly, also.
• DietPi Cam: I do not have a pi cam, so it's throwing some errors that I believe are related to the missing camera. The schedule page displays properly, though.
• RaspControl: Can't seem to get this to work. It installs but throws a 500 Server error.

[Fourdee]

@rhkean Thanks for the testing updates :+1:

RaspControl: Can't seem to get this to work. It installs but throws a 500 Server error.

The project hasn't been updated in over 4 years, and, i was unable to get this working on Jessie. I think with the same error. As of v113, Raspcontrol has been removed from the Jessie dietpi-software list, so we can skip this one.

DietPi Cam: I do not have a pi cam, so it's throwing some errors that I believe are related to the missing camera. The schedule page displays properly, though.

No RPi camera!? You haven't lived :). I've sent you an email regarding this.

[rhkean]

Testing status as of version 112

	Apache	lighttpd	nginx	Notes
phpMyAdmin	:white_check_mark:	:star:	:star:	:star: patch to php-fpm install logic
phpSysInfo	:white_check_mark:	:white_check_mark:	:star:	:star: added php5-xsl to php install block
Linux Dash	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
Single File Image Gallery	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
Grasshopper	:white_check_mark:	:white_check_mark:	:white_check_mark:	install appears to work, but I don't have a Bticino MyHome setup
DietPiCam	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
RaspControl	:x:	:x:	:x:	not supported on jessie
PiHole	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
OwnCloud	:white_check_mark:	:white_check_mark:	:star:	:star:requires changes to nginx default site
phpBB	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
WordPress	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
Ampache	:white_check_mark:	:white_check_mark:	:star:	:star: in /etc/nginx/sites-available/default, change server_name localhost; to servername "$hostname";
Pydio	:white_check_mark:	:white_check_mark:	:white_check_mark:	works out of box
Baikal	:white_check_mark:	:white_check_mark:	:white_check_mark:
EmonCMS	:question:	:question:	:question:	?? disabled in v113 ??

\ "out of box" means without changes to current installation code. (All of this requires changes to dietpi-software to not force LAMP or LASP stack)

[Fourdee]

@rhkean Nice table :+1:. I've updated the 1st post to link to your table.

[rhkean]

phpSysInfo, OwnCloud, and Ampache require some tweaks under Nginx.

I'll work on the fixes....

[Fourdee]

@rhkean

phpSysInfo, OwnCloud, and Ampache require some tweaks under Nginx. I'll work on the fixes....

Excellent :+1: I'am surprised, lighttpd seems to support more than nginx without modifications?

EmonCMS:

You can ignore this one. It will stay disabled.

[rhkean]

I'am surprised, lighttpd seems to support more than nginx without modifications?

well, all of that testing include the cgi.fix_pathinfo patch that I made to get phpMyAdmin to work with lighttpd. (yes, I've verified that didn't break nginx). I'm baffled on the phpSysInfo issue... load the page and you just get the header. Hit refresh a few times and it executes. I don't think it's a php issue, b/c it works without any issues on lighttpd. There's nothing on the phpsysinfo github repository to indicate an issue with nginx, though.

Since the refresh seems to get it to execute without error, though, I can't think of a code or config fix for it. I did try inserting a $(document).delay(1000); in a couple spots to see if a 1 sec delay would help... it didn't.

I'm going to start looking into Ampache next.

[rhkean]

got owncloud working; still working on ampache.

it's a nginx issue

[Fourdee]

@rhkean That was fast, thanks for the update :+1:

So its just phpSysInfo and Ampache for Nginx left?

[rhkean]

So its just phpSysInfo and Ampache for Nginx left?

yup.

I updated the chart to show which install combinations require install logic changes. I'll send you the patches when I'm done, or I can just add them to the repository if you prefer.

Working on Ampache now....

[rhkean]

fixed ampache... in /etc/nginx/sites-available/default change server_name directive from localhost to "$hostname"

yeah... really was that simple.

[rhkean]

fixed phpSysInfo

[Fourdee]

@rhkean Great work :+1:

If you can create a text file (or files) for the fixes you applied (:star:) I'd be greatful.

Then its the mammoth task for me to code all this into DietPi. Its going to take a lot of time as most of the installation logic will need to be redone for the webserver stacks. Depending on how much I can get done in v114, i'll try and start this for v115. Then I/we would need to re-test the installations with the new webserver choice system and options.

I'll let you know when I start work on this.

[rhkean]

oh.... probably wouldn't be very helpful if I did most (if not all) of that work for you already, then? :)

[rhkean]

These don't require a database, so the code verifies that any stack is selected. If none, the it selects LASP (as original): pi-hole,phpSysInfo,LinuxDash,dietpicam

Grasshopper requires SQLite, so the code adds the appropriate L?SP stack based on which stack is currently selected. If none, it selects LASP.

These require MySQL or MariaDB, so it verifies that L?MP or L?AP stack is selected. If a L?SP stack is selected, it'll add the same L?MP stack. If no stack is selected, it'll add LAMP: wordpress,phpbb3,pydio,owncloud,ampache

[Fourdee]

@rhkean

oh.... probably wouldn't be very helpful if I did most (if not all) of that work for you already, then? :)

You've already implemented this into dietpi-software code? :)

[rhkean]

yes. and tested.

• performed a base (image-only) rpi2 install.
• updated dietpi from v111 to v113
• installed git, buildessentials, and vi
• applied my patches
• set hostname
• installed LESP stack
• installed ALL of the above listed apps and just finished testing

[Fourdee]

@rhkean

yes. and tested. installed ALL of the above listed apps and just finished testing

Legend :+1:. I'll nudge this to v115. Aiming to get v114 out today/tomorrow, once thats done i'll prep the testing branch for v115. Then you can send a pull request for your updated code. Sound good? :)

[rhkean]

sounds good. I just checked the testing branch (diffs between v113 and v114). It doesn't look there will be any conflicts between v114 and my changes. Just let me know when you're ready for me update your repository.

I've got: 2 file changes (dietpi-software & conf/nginx.site-available-default) 1 new file (conf/nginx.sites-dietpi.owncloud.conf)

[Fourdee]

@rhkean

I just checked the testing branch (diffs between v113 and v114). It doesn't look there will be any conflicts between v114 and my changes. Just let me know when you're ready for me update your repository.

Excellent :+1:

I'am wrapping up v114 now, will let you know when everything is ready for the pull request.

[Fourdee]

@rhkean

Ok, v114 is released. I've updated the testing branch to v115. Pull away :D

[rhkean]

@Fourdee , I sent the pull request. I wasn't sure if you wanted me to merge the changes or leave that for you to review first...

-rob

[Fourdee]

@rhkean Excellent work on this, looks solid. I'll merge this now and run some tests today.

I was also thinking we could take this further by adding a webserver stack choice system in dietpi-software, similar to to SSH and Fileserver?

So the user has a choice of Apache2 Nginx and Lighttpd as their base webserver, then under "" "────Webserver Stacks───────────────────────" "off" \ we could show only the webserver stacks based on their choice (hiding the others). We'd also need to prevent the user changing their webserver choice by a simple dpkg -l | grep apache / nginx / lighttpd check.

Whats your thoughts on this?

I've been meaning to convert the Menu_Dietpi_Software() into an array anyway (so we dont have multiple whiptail code for each device as we do currently).

Once i've finished up with the OPi: https://github.com/Fourdee/DietPi/issues/263, and testing the latest pull, I'll take a stab at the above.

[rhkean]

Sounds great! I figured that you were going to want to do that, but I decided implement that base functionality and not muck with your base logic too much since I wasn't intimately familiar with it

[Fourdee]

@rhkean

(( $OWNCLOUD || $PHPBB

I never knew you could do or statements inside (( )) with bash.

And bash allows 0/1 as a bool:

(( ! $WEBSERVER_LASP

Learn something new everyday :+1:

I just finished a Lighttpd install with owncloud. Looking good :+1:.

[rhkean]

yup... the (( )) logic is nice. It's more c-like in its logic evaluation.... I don't think you can do this with [ ] or [[ ]] ... :smile:

#!/bin/bash
for x in 0 1 2; do
        if (( $x )); then
                echo "value (( $x )) = true"
        else
                echo "value (( $x )) = false"
        fi
done
for x in 0 1 2; do
        if (( ! $x )); then
                echo "value (( ! $x )) = true"
        else
                echo "value (( ! $x )) = false"
        fi
done

output:

value (( 0 )) = false
value (( 1 )) = true
value (( 2 )) = true
value (( ! 0 )) = true
value (( ! 1 )) = false
value (( ! 2 )) = false

[Fourdee]

value (( 2 )) = true

value (( ! 2 )) = false

Interesting :+1:. So bash treats 0 integer as a bool false, and >0 as a bool true? Wonder if its the same for negative numbers, I'll have to try it :)

[rhkean]

ONLY IN (( )) ... NOT in [ ] or [[ ]]

The (( ... )) and let ... constructs return an exit status, according to whether the arithmetic expressions they evaluate expand to a non-zero value. These arithmetic-expansion constructs may therefore be used to perform arithmetic comparisons. http://www.tldp.org/LDP/abs/html/testconstructs.html

[Fourdee]

ONLY IN (( )) ... NOT in [ ] or [[ ]]

Yeah i figured. I only use (( )) for integers and [ ] for strings.

[Fourdee]

@rhkean

Ok, i've done the logic for the webserver preference system: https://github.com/Fourdee/DietPi/commit/7b58598cf304b65ef377dda589485ab871a8e41e

I'll run some tests and check for bugs in the code i've modified.

[Fourdee]

@rhkean

Any feedback regarding the descriptions?

Reason for : "Recommended for users who expect low webserver traffic." I believe Lighttpd is a single thread application, so no performance gain from multiple cores, and, high traffic may cause a bottleneck. I know PHP-FPM is multithreaded.

[rhkean]

Wow! that was fast... :smile:

the descriptions look pretty good... I'm lousy with wording, so this is the best I can offer... Apache: maybe add something about "larger community support" (more 'out-of-the-box' support) Nginx: maybe add something about "targeting high use servers (large concurrent sessions)" and geared towards more advanced users Lighttpd: maybe add "geared toward intermediate to advanced users"

[WolfganP]

Good work! You may link the announcement in the forum to any comparison article with the main features (ie http://detechter.com/the-battle-of-the-web-servers-apache-vs-nginx-vs-lighttpd-2/ comes up first on google) to let users take a (more) informed decision

[Fourdee]

@rhkean

Wow! that was fast... :smile:

Only because you did such a good job of the updated webserver install code :) Everything went straight in.

Apache: maybe add something about "larger community support" (more 'out-of-the-box' support) Nginx: maybe add something about "targeting high use servers (large concurrent sessions)" and geared towards more advanced users Lighttpd: maybe add "geared toward intermediate to advanced users"

Good advice. The only thing that worries me is if we say "Lighttpd is for advanced users", non-DietPi users may get put off by that option. As DietPi-Software does all the installation for them, they dont really need any knowledge aslong as they are only using the available installation options we have. So I need to think of a way of saying "Lighttpd is for advanced users" however "If you install with DietPi-Software, anyone can use it" etc etc. I'll think on it.

I'am also tempted to make Lighttpd the default preference option on new installations, as it offers the "best performance" and is lightest of the bunch, it should be, again i'll have a think about it.

@WolfganP

Good work! You may link the announcement in the forum to any comparison article with the main features (ie http://detechter.com/the-battle-of-the-web-servers-apache-vs-nginx-vs-lighttpd-2/ comes up first on google) to let users take a (more) informed decision

I might be able to put that link into the current menu, so SSH users can view it whilst making a decision. But I need to update the documentation for all webserver stacks (eg: http://fuzon.co.uk/phpbb/viewtopic.php?f=8&t=5&p=1335#p1335), so i'll add that info at the same time.

[Fourdee]

@rhkean Going to have to put v115 on hold for a bit. Might be a few days, or a week+, but i'll pick this back up when I can. You've done great work on this feature, really looking forward to getting it released to our users.

Unfortunately, I'am going to be a lot less active for some time. So i apologise for any delays. http://fuzon.co.uk/phpbb/viewtopic.php?f=9&t=355

In the mean time, if you (or anyone else) are able to test the new preference system with a few webserver based installations (ideally the ones that required additional fixes, I think Ownclou?), i'd be grateful. Just change dietpi.txt gitbranch=testing after writing the DietPi image, and before booting.

note to self: Disable web stacks that are not selected as user preference.

[Fourdee]

@rhkean Ok, just wrapping this up:

• Lighttpd is now the default webserver preference
• Added warning when user selects any webserver stack for installation in dietpi-software
• Nearly finished updating the documentation: http://fuzon.co.uk/phpbb/viewtopic.php?f=8&t=5&p=1549#p1549

Few more tests then I'll get v115 wrapped up and released.

[rhkean]

Love the TLDR; :laughing:

[Fourdee]

@rhkean hehe, its too easy to spend hours trying to think of the best wording. But TLDR nails it lol.

[Fourdee]

@rhkean Marking this as completed. Great work on this :+1:

As its too time consuming to test every program against every webserver type, there is always a chance a few hidden bugs may be in v115, but if there is, we can resolve it quickly and release a v116 hotfix if required. I'll keep my eye on any bug reports.

[gstrauss]

I'm a little late to the party, but wanted to add a note about lighttpd 1.4.41 (released 2016-07-31). If you have any feedback or suggestions, feel free to open an issue at https://github.com/lighttpd/lighttpd1.4/

lighttpd can scale to multiple CPUs. :)

@Fourdee wrote above that lighttpd is single threaded. This is true in the default configuration, although lighttpd does scale to multiple worker subprocesses when server.max-worker = 2 (or more) in lighttpd.conf

Note: There is a caveat that some lesser-used modules do not work with multi-process lighttpd, since lighttpd currently avoids the overhead of synchronizing data between the subprocesses (e.g. in shared memory). The modules which do not work across subprocesses are mod_evasive, mod_rrdtool, and mod_uploadprogress. mod_status and lighttpd rate limiting are incomplete and less accurate, being run separately in each subprocess.

[Fourdee]

@gstrauss

Thank you for the info. :+1: I will be giving this a spin :dancer:

The modules which do not work across subprocesses are mod_evasive, mod_rrdtool, and mod_uploadprogress. mod_status and lighttpd rate limiting are incomplete and less accurate, being run separately in each subprocess.

I think its best we add this to the documentation as a user option, rather than apply server.max-worker = i to the installation code.

I've updated the DietPi documentation and referenced @gstrauss 's post above. http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=1549#p1549

@gstrauss is this a new feature for 1.4.41? Jessie repo is currently 1.4.35-4.

[gstrauss]

server.max-worker is not new -- it's available in every single version of 1.4.x.

I do still recommend lighttpd 1.4.41 :)