astlinux-devel — The AstLinux development environment, compilation, etc

Re: [Astlinux-devel] Astlinux Firewall

[Lonnie A. <li...@lo...>]

Hi Michael,

Thanks for the detailed description.

I think your over estimating the complexity of maintaining iptables custom rules for local WireGuard traffic (per custom_wg_lan_input() in another email).  It really is not that difficult considering only a very small subset of iptables syntax is required.

From how I understand your setup, you have a structured WireGuard mesh of clients, which not all should be allowed to access the server's internals within the WireGuard mesh.  This is a somewhat unique setup, but possibly will become more common.  As such we need to first understand what firewalling is required ... specifically rules limiting local WireGuard traffic.  That is why I suggest you start with custom rules to solve your problem, at least at first.

If you find that your custom rules limiting local WireGuard traffic need constant maintenance, note we already have an AIF wireguard-vpn plugin which is automatically enabled and the plugin configuration is passed via the "WireGuard VPN Configuration" sub-tab.  The "Firewall Options:" are passed to the wireguard-vpn plugin.
... or
If the uniqueness of this problem does not justify cluttering-up the "WireGuard VPN Configuration", new AIF wireguard-vpn plugin config variable options could be added and edited as how other "Firewall Plugins:" are configured.

Possibly something like:
--

# Limit WireGuard WG->Local access
#
# Note: The default policy is to allow all WG->Local traffic
#       unless WIREGUARD_VPN_HOST_OPEN_xxx is defined, then
#       the default policy is to deny all WG->Local traffic.
#
# Syntax:
# "host1,host2~port1,port2 host3,host4~port3,port4 ..."
#
# Example: (allow SSH traffic, deny all other)
#   WIREGUARD_VPN_HOST_OPEN_TCP="0/0~22"
#
# Example: (deny HTTP/HTTPS traffic, allow all other)
#   WIREGUARD_VPN_HOST_DENY_TCP="0/0~80,443"
# ------------------------------------------------------------------------------
WIREGUARD_VPN_HOST_OPEN_TCP=""
WIREGUARD_VPN_HOST_OPEN_UDP=""

WIREGUARD_VPN_HOST_DENY_TCP=""
WIREGUARD_VPN_HOST_DENY_UDP=""
--

Personally I find using a custom rule just as simple, but that is me.

Lonnie


> On Sep 16, 2019, at 6:27 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Devs
>  
> Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration.
>  
> With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s.
>  
> Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff.
>  
> So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab?
> Here are some of my thoughts:
> 	• Could we add an additional Zone called VPN
> 	• Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local)
> 	• Could we pull out some of the Firewall options and create some default Zone to Zone rules
> 	• Maybe look at building out the use of netset rules for Geoblocking etc.
>  
> I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier.
>  
> Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary.
>  
> I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading.
>  
> I look forward to your comments.
>  
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

[Astlinux-devel] Astlinux Firewall

[Michael K. <mic...@ip...>]

Hi Devs

Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration.

With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s.

Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff.

So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab?
Here are some of my thoughts:

  *   Could we add an additional Zone called VPN
  *   Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local)
  *   Could we pull out some of the Firewall options and create some default Zone to Zone rules
  *   Maybe look at building out the use of netset rules for Geoblocking etc.

I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier.

Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary.

I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading.

I look forward to your comments.

Regards
Michael Knill

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4333-55ad13

[Lonnie A. <li...@lo...>]

Announcing Pre-Release Version: astlinux-1.3-4333-55ad13

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Asterisk 13.23.1 ('13se' version)
   Older than latest Asterisk 13.x version but more tested, built --without-pjproject
   Add json-integer-overflow patches.
   Add security patches for: AST-2019-002, AST-2019-003

-- Asterisk 13.28.0 (version bump) and 16.5.0 (version bump)
   New modules: app_attended_transfer.so, app_blind_transfer.so

-- OpenSSL, major version bump to 1.1.1c, the new LTS series.  The previous 1.0.2 LTS series is EOL at the end of 2019.
   Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.

-- php, major version bump to 7.2.21, adds OpenSSL 1.1 compatibility

-- Web Interface Edit tab, add support for CodeMirror text editing.
   (Tip: Shift-Reload browser to get the updated CSS style sheet)
   Keyboard Actions: (after clicking text edit area)
   Note: Windows users, use Ctrl instead of Cmd
   Cmd-f -> Find
   Cmd-g -> Find Next
   Cmd-/ -> Toggle Comment
   Cmd-. -> Toggle Comment
   Tab   -> Toggle between "fullscreen" (full-window) mode and normal
   Esc   -> Return to normal, "fullscreen" (full-window) mode off
   More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map

-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface

-- arnofw (AIF), reload-blocklist-netset cron script, add new netset types
   asterisk: Aggregate multiple Asterisk/SIP/VoIP blacklists, including blocklist_de_sip.
   custom: Use variable BLOCKLIST_CUSTOM_URLS containing one or more (space/newline separated) URLs.
   customv6: Use variable BLOCKLIST_CUSTOMV6_URLS containing one or more (space/newline separated) URLs.
   More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists

-- iprange, version 1.0.4, new command, a tool capable of managing sets of IPs

-- WireGuard VPN, version bump to 0.0.20190702

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt

New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map

Updated Documentation Topics:
Firewall External Block List -
- https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists

Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font

The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html

"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)


AstLinux Team

Re: [Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4325-bca26d

[Michael K. <mic...@ip...>]

Awesome thanks Lonnie. My developer will be pleased!

Regards
Michael Knill

On 19/8/19, 12:16 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Announcing Pre-Release Version: astlinux-1.3-4325-bca26d
    
    The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
    
    -- Asterisk 13.23.1 ('13se' version)
       Older than latest Asterisk 13.x version but more tested, built --without-pjproject
       Add json-integer-overflow patches.
       Add security patches for: AST-2019-002, AST-2019-003
    
    -- Asterisk 13.28.0 (version bump) and 16.5.0 (version bump)
       New modules: app_attended_transfer.so, app_blind_transfer.so
    
    -- OpenSSL, major version bump to 1.1.1c, the new LTS series.  The previous 1.0.2 LTS series is EOL at the end of 2019.
       Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
    
    -- php, major version bump to 7.2.21, adds OpenSSL 1.1 compatibility
    
    -- Web Interface Edit tab, add support for CodeMirror text editing.
       (Tip: Shift-Reload browser to get the updated CSS style sheet)
       Keyboard Actions: (after clicking text edit area)
       Note: Windows users, use Ctrl instead of Cmd
       Cmd-f -> Find
       Cmd-g -> Find Next
       Cmd-/ -> Toggle Comment
       Cmd-. -> Toggle Comment
       Tab   -> Toggle between "fullscreen" (full-window) mode and normal
       Esc   -> Return to normal, "fullscreen" (full-window) mode off
       More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
    
    -- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
    
    -- WireGuard VPN, version bump to 0.0.20190702
    
    -- Complete Pre-Release ChangeLog:
    https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
    
    New Documentation Topics:
    Edit tab w/CodeMirror Keyboard Mapping -
    - https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
    
    Updated Documentation Topics:
    Web Interface Display Font -
    - https://doc.astlinux-project.org/userdoc:tt_web_interface_font
    
    The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
    
    AstLinux Project -> Development
    https://www.astlinux-project.org/dev.html
    
    "Development" tab feature for desktop browsers:
    Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)
    
    
    AstLinux Team
    
    
    
    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4325-bca26d

[Lonnie A. <li...@lo...>]

Announcing Pre-Release Version: astlinux-1.3-4325-bca26d

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Asterisk 13.23.1 ('13se' version)
   Older than latest Asterisk 13.x version but more tested, built --without-pjproject
   Add json-integer-overflow patches.
   Add security patches for: AST-2019-002, AST-2019-003

-- Asterisk 13.28.0 (version bump) and 16.5.0 (version bump)
   New modules: app_attended_transfer.so, app_blind_transfer.so

-- OpenSSL, major version bump to 1.1.1c, the new LTS series.  The previous 1.0.2 LTS series is EOL at the end of 2019.
   Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.

-- php, major version bump to 7.2.21, adds OpenSSL 1.1 compatibility

-- Web Interface Edit tab, add support for CodeMirror text editing.
   (Tip: Shift-Reload browser to get the updated CSS style sheet)
   Keyboard Actions: (after clicking text edit area)
   Note: Windows users, use Ctrl instead of Cmd
   Cmd-f -> Find
   Cmd-g -> Find Next
   Cmd-/ -> Toggle Comment
   Cmd-. -> Toggle Comment
   Tab   -> Toggle between "fullscreen" (full-window) mode and normal
   Esc   -> Return to normal, "fullscreen" (full-window) mode off
   More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map

-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface

-- WireGuard VPN, version bump to 0.0.20190702

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt

New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map

Updated Documentation Topics:
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font

The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html

"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)


AstLinux Team

Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

A curious bit of info, this links shows active WordPress users and what versions of PHP (and other packages) are used on their systems...

https://wordpress.org/about/stats/

PHP 5.6 is the most common, but PHP 7.2 comes in 2'nd at the time of this post.

Lonnie


> On Aug 16, 2019, at 2:44 PM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> Yesterday I reported some best case PHP 7 speed improvements using a PHP benchmark script.
> 
> Today I made a real-world test of the web interface speed, and as probably expected, not much change...
> 
> Box: Jetway NF9HG-2930, time to load Status tab with Prefs "Show NTP Time Sources" unchecked
> --
> time curl -k https://localhost/status.php
> --
> 
> PHP 5.6.40
> real	0m0.264s
> 
> PHP 7.2.21
> real	0m0.259s
> 
> Since our web interface does not heavily use PHP, the system calls to gather data and lighttpd network stack plays more into the processing time.
> 
> Though some special cases like the CDR Log, SQL-Data and LDAP-AB tabs should benefit from PHP 7's improved speed.
> 
> Here is a "CDR Log" tab test example:
> --
> time curl -k --user admin:secret https://localhost/admin/cdrlog.php
> --
> 
> PHP 5.6.40
> real	0m0.122s
> 
> PHP 7.2.21
> real	0m0.097s
> 
> Lonnie
> 
> 
> 
>> On Aug 15, 2019, at 3:37 PM, Lonnie Abelbeck <li...@lo...> wrote:
>> 
>> OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz)
>> 
>> I then tried PHP 7.2.21 ... still works with pcre and libz just fine.
>> 
>> The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 .
>> 
>> Oh, and it is faster :-)
>> 
>> On an APU2:
>> 
>> --------------------------------------
>> |        PHP BENCHMARK SCRIPT        |
>> --------------------------------------
>> Start : 2019-08-15 14:15:15
>> CPU : AMD GX-412TC SOC
>> PHP version : 5.6.40
>> Platform : Linux
>> --------------------------------------
>> test_math                 : 12.422 sec.
>> test_stringmanipulation   : 12.333 sec.
>> test_loops                : 6.945 sec.
>> test_ifelse               : 4.169 sec.
>> --------------------------------------
>> Total time:               : 35.869 sec.
>> 
>> ... and ...
>> 
>> --------------------------------------
>> |        PHP BENCHMARK SCRIPT        |
>> --------------------------------------
>> Start : 2019-08-15 14:26:29
>> CPU : AMD GX-412TC SOC
>> PHP version : 7.2.21
>> Platform : Linux
>> --------------------------------------
>> test_math                 : 2.585 sec.
>> test_stringmanipulation   : 3.859 sec.
>> test_loops                : 2.145 sec.
>> test_ifelse               : 2.180 sec.
>> --------------------------------------
>> Total time:               : 10.769 sec.
>> 
>> DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6
>> 
>> Though PHP 7.2 is bigger (both with our same custom built timezonedb.h)
>> 
>> PHP 5.6.40
>> -rwxr-xr-x    1 root     root       3580688 Aug 12 11:35 /usr/bin/php
>> 
>> PHP 7.2.21
>> -rwxr-xr-x    1 root     root       3921344 Aug 15 14:12 /usr/bin/php
>> 
>> Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256
>> 
>> I do like the idea of OpenSSL 1.1 support built-in without having to add a patch.
>> 
>> So far, testing is going good, the can-of-worms is under control :-)
>> 
>> If you can test, I committed it here:
>> https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e
>> 
>> 
>> Lonnie
>> 
>> 
>> 
>>> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
>>> 
>>> +1 from me
>>> 
>>> Regards
>>> Michael Knill
>>> 
>>> From: David Kerr <da...@ke...>
>>> Reply to: AstLinux Developers Mailing List <ast...@li...>
>>> Date: Wednesday, 14 August 2019 at 2:56 am
>>> To: AstLinux Developers Mailing List <ast...@li...>
>>> Subject: Re: [Astlinux-devel] PHP 5.6 EoL
>>> 
>>> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
>>> 
>>> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
>>> 
>>> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
>>> 
>>> David
>>> 
>>> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
>>>> 
>>>> 
>>>>> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
>>>>> 
>>>>> Hi Devs
>>>>> 
>>>>> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
>>>>> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
>>>> 
>>>> Hi Michael,
>>>> 
>>>> Indeed, this is a can-of-worms.
>>>> 
>>>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
>>>> 
>>>> https://www.php.net/supported-versions.php
>>>> 
>>>> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
>>>> 
>>>> BTW, each new PHP release is not 100% backward compatible.
>>>> 
>>>> 
>>>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
>>>> 
>>>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
>>>> https://bugs.php.net/bug.php?id=69652
>>>> 
>>>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
>>>> 
>>>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
>>>> 
>>>> 
>>>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
>>>> 
>>>> 
>>>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>>>> 
>>>> 
>>>> That is a summary for the can-of-worms.
>>>> 
>>>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
>>>> 
>>>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
>>>> --
>>>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
>>>> --
>>>> 
>>>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
>>>> 
>>>> As always, open to comments.
>>>> 
>>>> Lonnie
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> 
>> 
> 
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 

Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

Yesterday I reported some best case PHP 7 speed improvements using a PHP benchmark script.

Today I made a real-world test of the web interface speed, and as probably expected, not much change...

Box: Jetway NF9HG-2930, time to load Status tab with Prefs "Show NTP Time Sources" unchecked
--
time curl -k https://localhost/status.php
--

PHP 5.6.40
real	0m0.264s

PHP 7.2.21
real	0m0.259s

Since our web interface does not heavily use PHP, the system calls to gather data and lighttpd network stack plays more into the processing time.

Though some special cases like the CDR Log, SQL-Data and LDAP-AB tabs should benefit from PHP 7's improved speed.

Here is a "CDR Log" tab test example:
--
time curl -k --user admin:secret https://localhost/admin/cdrlog.php
--

PHP 5.6.40
real	0m0.122s

PHP 7.2.21
real	0m0.097s

Lonnie



> On Aug 15, 2019, at 3:37 PM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz)
> 
> I then tried PHP 7.2.21 ... still works with pcre and libz just fine.
> 
> The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 .
> 
> Oh, and it is faster :-)
> 
> On an APU2:
> 
> --------------------------------------
> |        PHP BENCHMARK SCRIPT        |
> --------------------------------------
> Start : 2019-08-15 14:15:15
> CPU : AMD GX-412TC SOC
> PHP version : 5.6.40
> Platform : Linux
> --------------------------------------
> test_math                 : 12.422 sec.
> test_stringmanipulation   : 12.333 sec.
> test_loops                : 6.945 sec.
> test_ifelse               : 4.169 sec.
> --------------------------------------
> Total time:               : 35.869 sec.
> 
> ... and ...
> 
> --------------------------------------
> |        PHP BENCHMARK SCRIPT        |
> --------------------------------------
> Start : 2019-08-15 14:26:29
> CPU : AMD GX-412TC SOC
> PHP version : 7.2.21
> Platform : Linux
> --------------------------------------
> test_math                 : 2.585 sec.
> test_stringmanipulation   : 3.859 sec.
> test_loops                : 2.145 sec.
> test_ifelse               : 2.180 sec.
> --------------------------------------
> Total time:               : 10.769 sec.
> 
> DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6
> 
> Though PHP 7.2 is bigger (both with our same custom built timezonedb.h)
> 
> PHP 5.6.40
> -rwxr-xr-x    1 root     root       3580688 Aug 12 11:35 /usr/bin/php
> 
> PHP 7.2.21
> -rwxr-xr-x    1 root     root       3921344 Aug 15 14:12 /usr/bin/php
> 
> Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256
> 
> I do like the idea of OpenSSL 1.1 support built-in without having to add a patch.
> 
> So far, testing is going good, the can-of-worms is under control :-)
> 
> If you can test, I committed it here:
> https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e
> 
> 
> Lonnie
> 
> 
> 
>> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> +1 from me
>> 
>> Regards
>> Michael Knill
>> 
>> From: David Kerr <da...@ke...>
>> Reply to: AstLinux Developers Mailing List <ast...@li...>
>> Date: Wednesday, 14 August 2019 at 2:56 am
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] PHP 5.6 EoL
>> 
>> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
>> 
>> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
>> 
>> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
>> 
>> David
>> 
>> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
>>> 
>>> 
>>>> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
>>>> 
>>>> Hi Devs
>>>> 
>>>> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
>>>> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
>>> 
>>> Hi Michael,
>>> 
>>> Indeed, this is a can-of-worms.
>>> 
>>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
>>> 
>>> https://www.php.net/supported-versions.php
>>> 
>>> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
>>> 
>>> BTW, each new PHP release is not 100% backward compatible.
>>> 
>>> 
>>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
>>> 
>>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
>>> https://bugs.php.net/bug.php?id=69652
>>> 
>>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
>>> 
>>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
>>> 
>>> 
>>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
>>> 
>>> 
>>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>>> 
>>> 
>>> That is a summary for the can-of-worms.
>>> 
>>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
>>> 
>>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
>>> --
>>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
>>> --
>>> 
>>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
>>> 
>>> As always, open to comments.
>>> 
>>> Lonnie
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 

Re: [Astlinux-devel] PHP 5.6 EoL

[Michael K. <li...@mk...>]

> Am 15.08.2019 um 22:37 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz)
> 
> I then tried PHP 7.2.21 ... still works with pcre and libz just fine.
> 
> The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 .
> 
> Oh, and it is faster :-)
> 
> On an APU2:
> 
> --------------------------------------
> |        PHP BENCHMARK SCRIPT        |
> --------------------------------------
> Start : 2019-08-15 14:15:15
> CPU : AMD GX-412TC SOC
> PHP version : 5.6.40
> Platform : Linux
> --------------------------------------
> test_math                 : 12.422 sec.
> test_stringmanipulation   : 12.333 sec.
> test_loops                : 6.945 sec.
> test_ifelse               : 4.169 sec.
> --------------------------------------
> Total time:               : 35.869 sec.
> 
> ... and ...
> 
> --------------------------------------
> |        PHP BENCHMARK SCRIPT        |
> --------------------------------------
> Start : 2019-08-15 14:26:29
> CPU : AMD GX-412TC SOC
> PHP version : 7.2.21
> Platform : Linux
> --------------------------------------
> test_math                 : 2.585 sec.
> test_stringmanipulation   : 3.859 sec.
> test_loops                : 2.145 sec.
> test_ifelse               : 2.180 sec.
> --------------------------------------
> Total time:               : 10.769 sec.
> 
> DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6
> 
> Though PHP 7.2 is bigger (both with our same custom built timezonedb.h)
> 
> PHP 5.6.40
> -rwxr-xr-x    1 root     root       3580688 Aug 12 11:35 /usr/bin/php
> 
> PHP 7.2.21
> -rwxr-xr-x    1 root     root       3921344 Aug 15 14:12 /usr/bin/php
> 
> Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256
> 
> I do like the idea of OpenSSL 1.1 support built-in without having to add a patch.
> 
> So far, testing is going good, the can-of-worms is under control :-)
> 
> If you can test, I committed it here:
> https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e
> 
> 
> Lonnie

Hi Lonnie, great work.

I tested it on my office PBX and everything seems to work fine: incl. Monit, NetStat, phpLiteAdmin, Shellinabox, FOP2.

Cool!

>> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> +1 from me
>> 
>> Regards
>> Michael Knill
>> 
>> From: David Kerr <da...@ke...>
>> Reply to: AstLinux Developers Mailing List <ast...@li...>
>> Date: Wednesday, 14 August 2019 at 2:56 am
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] PHP 5.6 EoL
>> 
>> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
>> 
>> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
>> 
>> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
>> 
>> David
>> 
>> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
>>> 
>>> 
>>>> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
>>>> 
>>>> Hi Devs
>>>> 
>>>> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
>>>> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
>>> 
>>> Hi Michael,
>>> 
>>> Indeed, this is a can-of-worms.
>>> 
>>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
>>> 
>>> https://www.php.net/supported-versions.php
>>> 
>>> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
>>> 
>>> BTW, each new PHP release is not 100% backward compatible.
>>> 
>>> 
>>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
>>> 
>>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
>>> https://bugs.php.net/bug.php?id=69652
>>> 
>>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
>>> 
>>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
>>> 
>>> 
>>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
>>> 
>>> 
>>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>>> 
>>> 
>>> That is a summary for the can-of-worms.
>>> 
>>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
>>> 
>>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
>>> --
>>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
>>> --
>>> 
>>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
>>> 
>>> As always, open to comments.
>>> 
>>> Lonnie

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] PHP 5.6 EoL

[Michael K. <mic...@ip...>]

Great thanks Lonnie.

Looks promising!

Regards
Michael Knill

On 16/8/19, 6:37 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz)
    
    I then tried PHP 7.2.21 ... still works with pcre and libz just fine.
    
    The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 .
    
    Oh, and it is faster :-)
    
    On an APU2:
    
    --------------------------------------
    |        PHP BENCHMARK SCRIPT        |
    --------------------------------------
    Start : 2019-08-15 14:15:15
    CPU : AMD GX-412TC SOC
    PHP version : 5.6.40
    Platform : Linux
    --------------------------------------
    test_math                 : 12.422 sec.
    test_stringmanipulation   : 12.333 sec.
    test_loops                : 6.945 sec.
    test_ifelse               : 4.169 sec.
    --------------------------------------
    Total time:               : 35.869 sec.
    
    ... and ...
    
    --------------------------------------
    |        PHP BENCHMARK SCRIPT        |
    --------------------------------------
    Start : 2019-08-15 14:26:29
    CPU : AMD GX-412TC SOC
    PHP version : 7.2.21
    Platform : Linux
    --------------------------------------
    test_math                 : 2.585 sec.
    test_stringmanipulation   : 3.859 sec.
    test_loops                : 2.145 sec.
    test_ifelse               : 2.180 sec.
    --------------------------------------
    Total time:               : 10.769 sec.
    
    DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6
    
    Though PHP 7.2 is bigger (both with our same custom built timezonedb.h)
    
    PHP 5.6.40
    -rwxr-xr-x    1 root     root       3580688 Aug 12 11:35 /usr/bin/php
    
    PHP 7.2.21
    -rwxr-xr-x    1 root     root       3921344 Aug 15 14:12 /usr/bin/php
    
    Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256
    
    I do like the idea of OpenSSL 1.1 support built-in without having to add a patch.
    
    So far, testing is going good, the can-of-worms is under control :-)
    
    If you can test, I committed it here:
    https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e
    
    
    Lonnie
    
    
    
    > On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > +1 from me
    >  
    > Regards
    > Michael Knill
    >  
    > From: David Kerr <da...@ke...>
    > Reply to: AstLinux Developers Mailing List <ast...@li...>
    > Date: Wednesday, 14 August 2019 at 2:56 am
    > To: AstLinux Developers Mailing List <ast...@li...>
    > Subject: Re: [Astlinux-devel] PHP 5.6 EoL
    >  
    > This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
    >  
    > I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
    >  
    > We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
    >  
    > David
    >  
    > On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
    >> 
    >> 
    >> > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
    >> > 
    >> > Hi Devs
    >> >  
    >> > Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
    >> > I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
    >> 
    >> Hi Michael,
    >> 
    >> Indeed, this is a can-of-worms.
    >> 
    >> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
    >> 
    >> https://www.php.net/supported-versions.php
    >> 
    >> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
    >> 
    >> BTW, each new PHP release is not 100% backward compatible.
    >> 
    >> 
    >> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
    >> 
    >> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
    >> https://bugs.php.net/bug.php?id=69652
    >> 
    >> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
    >> 
    >> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
    >> 
    >> 
    >> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
    >> 
    >> 
    >> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
    >> 
    >> 
    >> That is a summary for the can-of-worms.
    >> 
    >> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
    >> 
    >> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
    >> --
    >> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
    >> --
    >> 
    >> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
    >> 
    >> As always, open to comments.
    >> 
    >> Lonnie
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-devel mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    > _______________________________________________
    > Astlinux-devel mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    
    
    
    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    

Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz)

I then tried PHP 7.2.21 ... still works with pcre and libz just fine.

The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 .

Oh, and it is faster :-)

On an APU2:

--------------------------------------
|        PHP BENCHMARK SCRIPT        |
--------------------------------------
Start : 2019-08-15 14:15:15
CPU : AMD GX-412TC SOC
PHP version : 5.6.40
Platform : Linux
--------------------------------------
test_math                 : 12.422 sec.
test_stringmanipulation   : 12.333 sec.
test_loops                : 6.945 sec.
test_ifelse               : 4.169 sec.
--------------------------------------
Total time:               : 35.869 sec.

... and ...

--------------------------------------
|        PHP BENCHMARK SCRIPT        |
--------------------------------------
Start : 2019-08-15 14:26:29
CPU : AMD GX-412TC SOC
PHP version : 7.2.21
Platform : Linux
--------------------------------------
test_math                 : 2.585 sec.
test_stringmanipulation   : 3.859 sec.
test_loops                : 2.145 sec.
test_ifelse               : 2.180 sec.
--------------------------------------
Total time:               : 10.769 sec.

DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6

Though PHP 7.2 is bigger (both with our same custom built timezonedb.h)

PHP 5.6.40
-rwxr-xr-x    1 root     root       3580688 Aug 12 11:35 /usr/bin/php

PHP 7.2.21
-rwxr-xr-x    1 root     root       3921344 Aug 15 14:12 /usr/bin/php

Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256

I do like the idea of OpenSSL 1.1 support built-in without having to add a patch.

So far, testing is going good, the can-of-worms is under control :-)

If you can test, I committed it here:
https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e


Lonnie



> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
> 
> +1 from me
>  
> Regards
> Michael Knill
>  
> From: David Kerr <da...@ke...>
> Reply to: AstLinux Developers Mailing List <ast...@li...>
> Date: Wednesday, 14 August 2019 at 2:56 am
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] PHP 5.6 EoL
>  
> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
>  
> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
>  
> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
>  
> David
>  
> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
>> 
>> 
>> > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
>> > 
>> > Hi Devs
>> >  
>> > Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
>> > I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
>> 
>> Hi Michael,
>> 
>> Indeed, this is a can-of-worms.
>> 
>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
>> 
>> https://www.php.net/supported-versions.php
>> 
>> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
>> 
>> BTW, each new PHP release is not 100% backward compatible.
>> 
>> 
>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
>> 
>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
>> https://bugs.php.net/bug.php?id=69652
>> 
>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
>> 
>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
>> 
>> 
>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
>> 
>> 
>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>> 
>> 
>> That is a summary for the can-of-worms.
>> 
>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
>> 
>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
>> --
>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
>> --
>> 
>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
>> 
>> As always, open to comments.
>> 
>> Lonnie
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

Hi Michael,

> On Aug 14, 2019, at 11:38 PM, Michael Knill <mic...@ip...> wrote:
> 
> Its not really an issue per se. You can always just throw more resources at it.
> Its more when you have a big phone reset and they are all hammering the startup PHP script.
> We also have a duress alarm script which struggles under load.

It could be the bottleneck you describe is lighttpd spawning php requests rather than the actual PHP code execution.

If you have a test situation where "they (phones) are all hammering the startup PHP script", you could run "htop" in AstLinux and see if any cores are near CPU max ... if not (low'ish CPU usage) it is probably a lighttpd/network bottleneck.

There are lighttpd tweaks an optional /mnt/kd/lighttpd.conf could provide.

Lonnie



> Its also going to be better from a development perspective for us as we are doing quite a bit in PHP now.
> 
> Regards
> Michael Knill
> 
> On 15/8/19, 11:13 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    AFAIK, the only improvement for us in PHP 7 is it's improved execution speed.  Probably not noticeable with our web interface.
> 
>    Michael (Knill) you mentioned you have some PHP based custom apps, can you provide any info on how much CPU they are currently consuming ? Maybe via "htop" or are they a short transaction based app ?
> 
>    In other words, a practical feel on how the execution speed of 5.6 is an issue.
> 
>    Lonnie
> 
> 
>> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> +1 from me
>> 
>> Regards
>> Michael Knill
>> 
>> From: David Kerr <da...@ke...>
>> Reply to: AstLinux Developers Mailing List <ast...@li...>
>> Date: Wednesday, 14 August 2019 at 2:56 am
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] PHP 5.6 EoL
>> 
>> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
>> 
>> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
>> 
>> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
>> 
>> David
>> 
>> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
>>> 
>>> 
>>>> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
>>>> 
>>>> Hi Devs
>>>> 
>>>> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
>>>> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
>>> 
>>> Hi Michael,
>>> 
>>> Indeed, this is a can-of-worms.
>>> 
>>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
>>> 
>>> https://www.php.net/supported-versions.php
>>> 
>>> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
>>> 
>>> BTW, each new PHP release is not 100% backward compatible.
>>> 
>>> 
>>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
>>> 
>>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
>>> https://bugs.php.net/bug.php?id=69652
>>> 
>>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
>>> 
>>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
>>> 
>>> 
>>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
>>> 
>>> 
>>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>>> 
>>> 
>>> That is a summary for the can-of-worms.
>>> 
>>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
>>> 
>>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
>>> --
>>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
>>> --
>>> 
>>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
>>> 
>>> As always, open to comments.
>>> 
>>> Lonnie
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
>    _______________________________________________
>    Astlinux-devel mailing list
>    Ast...@li...
>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] PHP 5.6 EoL

[Michael K. <mic...@ip...>]

Its not really an issue per se. You can always just throw more resources at it.
Its more when you have a big phone reset and they are all hammering the startup PHP script.
We also have a duress alarm script which struggles under load.

Its also going to be better from a development perspective for us as we are doing quite a bit in PHP now.

Regards
Michael Knill

On 15/8/19, 11:13 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    AFAIK, the only improvement for us in PHP 7 is it's improved execution speed.  Probably not noticeable with our web interface.
    
    Michael (Knill) you mentioned you have some PHP based custom apps, can you provide any info on how much CPU they are currently consuming ? Maybe via "htop" or are they a short transaction based app ?
    
    In other words, a practical feel on how the execution speed of 5.6 is an issue.
    
    Lonnie
    
    
    > On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > +1 from me
    >  
    > Regards
    > Michael Knill
    >  
    > From: David Kerr <da...@ke...>
    > Reply to: AstLinux Developers Mailing List <ast...@li...>
    > Date: Wednesday, 14 August 2019 at 2:56 am
    > To: AstLinux Developers Mailing List <ast...@li...>
    > Subject: Re: [Astlinux-devel] PHP 5.6 EoL
    >  
    > This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
    >  
    > I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
    >  
    > We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
    >  
    > David
    >  
    > On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
    >> 
    >> 
    >> > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
    >> > 
    >> > Hi Devs
    >> >  
    >> > Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
    >> > I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
    >> 
    >> Hi Michael,
    >> 
    >> Indeed, this is a can-of-worms.
    >> 
    >> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
    >> 
    >> https://www.php.net/supported-versions.php
    >> 
    >> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
    >> 
    >> BTW, each new PHP release is not 100% backward compatible.
    >> 
    >> 
    >> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
    >> 
    >> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
    >> https://bugs.php.net/bug.php?id=69652
    >> 
    >> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
    >> 
    >> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
    >> 
    >> 
    >> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
    >> 
    >> 
    >> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
    >> 
    >> 
    >> That is a summary for the can-of-worms.
    >> 
    >> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
    >> 
    >> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
    >> --
    >> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
    >> --
    >> 
    >> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
    >> 
    >> As always, open to comments.
    >> 
    >> Lonnie
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-devel mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    > _______________________________________________
    > Astlinux-devel mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    
    
    
    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    

Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

AFAIK, the only improvement for us in PHP 7 is it's improved execution speed.  Probably not noticeable with our web interface.

Michael (Knill) you mentioned you have some PHP based custom apps, can you provide any info on how much CPU they are currently consuming ? Maybe via "htop" or are they a short transaction based app ?

In other words, a practical feel on how the execution speed of 5.6 is an issue.

Lonnie


> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote:
> 
> +1 from me
>  
> Regards
> Michael Knill
>  
> From: David Kerr <da...@ke...>
> Reply to: AstLinux Developers Mailing List <ast...@li...>
> Date: Wednesday, 14 August 2019 at 2:56 am
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] PHP 5.6 EoL
>  
> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
>  
> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.
>  
> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
>  
> David
>  
> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
>> 
>> 
>> > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
>> > 
>> > Hi Devs
>> >  
>> > Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
>> > I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
>> 
>> Hi Michael,
>> 
>> Indeed, this is a can-of-worms.
>> 
>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
>> 
>> https://www.php.net/supported-versions.php
>> 
>> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
>> 
>> BTW, each new PHP release is not 100% backward compatible.
>> 
>> 
>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
>> 
>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
>> https://bugs.php.net/bug.php?id=69652
>> 
>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
>> 
>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
>> 
>> 
>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
>> 
>> 
>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>> 
>> 
>> That is a summary for the can-of-worms.
>> 
>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
>> 
>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
>> --
>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
>> --
>> 
>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
>> 
>> As always, open to comments.
>> 
>> Lonnie
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] PHP 5.6 EoL

[Michael K. <mic...@ip...>]

+1 from me

Regards
Michael Knill

From: David Kerr <da...@ke...>
Reply to: AstLinux Developers Mailing List <ast...@li...>
Date: Wednesday, 14 August 2019 at 2:56 am
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] PHP 5.6 EoL

This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.

I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.

We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).

David

On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...<mailto:li...@lo...>> wrote:


> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>
> Hi Devs
>
> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.

Hi Michael,

Indeed, this is a can-of-worms.

1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.

https://www.php.net/supported-versions.php

Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.

BTW, each new PHP release is not 100% backward compatible.


2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.

Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
https://bugs.php.net/bug.php?id=69652

We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.

It appears later PHP versions use the same timezonedb.h file, though some details may have changed.


3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.


4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.


That is a summary for the can-of-worms.

Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.

BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
--
m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
--

At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.

As always, open to comments.

Lonnie



_______________________________________________
Astlinux-devel mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] PHP 5.6 EoL

[Michael K. <li...@mk...>]

> Am 13.08.2019 um 18:56 schrieb David Kerr <da...@ke...>:
> 
> This feels like something that we should create a GitHub branch for and take our time over.  Since moving our source to GitHub we really have not taken advantage of its development features.  We don't use branches, issues, pull requests, etc.
> 
> I propose creating a branch specifically to work the can of worms.  Leave Master branch stable, continue to apply fixes to it, etc.  But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them.  Once thoroughly tested we merge everything back into the master.

+1

> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5).
> 
> David
> 
> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote:
> 
> 
> > On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
> > 
> > Hi Devs
> >  
> > Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
> > I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.
> 
> Hi Michael,
> 
> Indeed, this is a can-of-worms.
> 
> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.
> 
> https://www.php.net/supported-versions.php
> 
> Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.
> 
> BTW, each new PHP release is not 100% backward compatible.
> 
> 
> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.
> 
> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
> https://bugs.php.net/bug.php?id=69652
> 
> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.
> 
> It appears later PHP versions use the same timezonedb.h file, though some details may have changed.
> 
> 
> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.
> 
> 
> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
> 
> 
> That is a summary for the can-of-worms.
> 
> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.
> 
> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
> --
> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
> --
> 
> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.
> 
> As always, open to comments.
> 
> Lonnie

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] PHP 5.6 EoL

[David K. <da...@ke...>]

This feels like something that we should create a GitHub branch for and
take our time over.  Since moving our source to GitHub we really have not
taken advantage of its development features.  We don't use branches,
issues, pull requests, etc.

I propose creating a branch specifically to work the can of worms.  Leave
Master branch stable, continue to apply fixes to it, etc.  But fork a
branch into which we place PHP 7 and then a small group of us can thrash on
that to uncover all the worms and incrementally commit fixes for them.
Once thoroughly tested we merge everything back into the master.

We'll need to the same at some point for the kernel upgrade to 4.x (or,
gulp, 5).

David

On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...>
wrote:

>
>
> > On Aug 13, 2019, at 2:50 AM, Michael Knill <
> mic...@ip...> wrote:
> >
> > Hi Devs
> >
> > Just wondering if/when we would be looking to go to PHP 7.x considering
> 5.6 was EoL at the beginning of this year?
> > I understand that PHP 7 is much faster than 5.6 so it will make some of
> my busy XML apps a little better.
>
> Hi Michael,
>
> Indeed, this is a can-of-worms.
>
> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release
> cycle is to introduce a new version every year, with new bugs ... fixes for
> two years plus security-only fixes for a year.  Rinse and repeat.
>
> https://www.php.net/supported-versions.php
>
> Our current 5.6 version was the closest to LTS they have offered.  Note a
> LTS series is of higher quality since it is scrutinized for a longer period
> of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at
> 9 x-releases.
>
> BTW, each new PHP release is not 100% backward compatible.
>
>
> 2) Sadly, PHP includes the timezone data within the php binary rather than
> using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard
> 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data,
> more significant extra bloat.
>
> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
> https://bugs.php.net/bug.php?id=69652
>
> We currently work around this by compiling our own 32-bit only
> "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb
> maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the
> latest Linux zoneinfo data.
>
> It appears later PHP versions use the same timezonedb.h file, though some
> details may have changed.
>
>
> 3) A jump to PHP 7.3 would no doubt introduce some backward
> incompatibilities with the web interface, warnings at the very least.
>
>
> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7
> issues, but fixes could be cherrypicked from upstream phpLiteAdmin.
>
>
> That is a summary for the can-of-worms.
>
> Fortunately with AstLinux, PHP is not exposed to untrusted users by
> default, and it is highly recommended to not expose HTTP/HTTPS to anything
> other than trusted endpoints ... thereby limiting PHP's security exposure.
>
> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a
> PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six
> years beyond its EOL.
> --
> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
> --
>
> At some point we will need to make a version jump of PHP, but we are
> currently on solid ground and somewhat uncertain how we might land if we
> made the jump.
>
> As always, open to comments.
>
> Lonnie
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Devs
>  
> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.

Hi Michael,

Indeed, this is a can-of-worms.

1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.

https://www.php.net/supported-versions.php

Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.

BTW, each new PHP release is not 100% backward compatible.


2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.

Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
https://bugs.php.net/bug.php?id=69652

We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.

It appears later PHP versions use the same timezonedb.h file, though some details may have changed.


3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.


4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.


That is a summary for the can-of-worms.

Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.

BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
--
m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
--

At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.

As always, open to comments.

Lonnie

[Astlinux-devel] PHP 5.6 EoL

[Michael K. <mic...@ip...>]

Hi Devs

Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.

Regards
Michael Knill

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4312-7810c3

[Lonnie A. <li...@lo...>]

Announcing Pre-Release Version: astlinux-1.3-4312-7810c3

** Special Request **
Please take a few minutes to test the new web interface Edit tab using CodeMirror.  Besides reporting any issues, we would like to hear suggestions for any tweaks, added modes (syntax), etc. .  If you don't have a spare test box, spin-up the Guest VM x86-64bit ISO found here:
https://www.astlinux-project.org/dev.html

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- OpenSSL, major version bump to 1.1.1c, the new LTS series.  The previous 1.0.2 LTS series is EOL at the end of 2019.
   Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
   Initial testing looks good, more testing is appreciated.

-- Web Interface Edit tab, add support for CodeMirror text editing.
   (Tip: Shift-Reload browser to get the updated CSS style sheet)
   Keyboard Actions: (after clicking text edit area)
   Note: Windows users, use Ctrl instead of Cmd
   Cmd-f -> Find
   Cmd-g -> Find Next
   Cmd-/ -> Toggle Comment
   Cmd-. -> Toggle Comment
   Tab   -> Toggle between "fullscreen" (full-window) mode and normal
   Esc   -> Return to normal, "fullscreen" (full-window) mode off
   More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map

-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface

-- WireGuard VPN, version bump to 0.0.20190702

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt

New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map

Updated Documentation Topics:
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font

The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html

"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)


AstLinux Team

[Astlinux-devel] wan-failover.script

[Michael K. <mic...@ip...>]

Hi Devs

Just thought I would bring to your attention a problem with this script which I experienced at one of my sites.
As it turns out, both the primary and secondary services went down for a short period at the same time and both came back within a couple seconds of each other.

The failover script executed:
SECONDARY)
.......
;;

But did not execute:
PRIMARY)
.......
;;

I use this script to blackhole a route to the main provider so it fails over to a backup so this route remained blackholed when they both returned.
Lucky I was monitoring with Zabbix so caught it before they started for the day.

Do you think there is any way to fix this? It appears that the script needs to go through the standard transitions to be successful.

Regards
Michael Knill

Re: [Astlinux-devel] Removal of External Failover Destination Routes

[Michael K. <mic...@ip...>]

Agreed.
Also is possible to perform a network restart only e.g. not needing to restart the whole system?

Regards
Michael Knill

On 14/7/19, 12:52 am, "Michael Keuter" <li...@mk...> wrote:

    
    > Am 13.07.2019 um 15:24 schrieb Lonnie Abelbeck <li...@lo...>:
    > 
    > Hi Michael,
    > 
    >> when I add or remove an External Failover Destination Route...
    > 
    > Yes, that requires a system "Reboot" as they are configured on network startup.
    > 
    > But, if the changes are only to the "WAN Failover:" section, a "Restart Failover" is all that is needed.
    > 
    > Lonnie
    > 
    >> On Jul 13, 2019, at 2:43 AM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> Hi Devs
    >> 
    >> I noticed that when I add or remove an External Failover Destination Route and restart Failover, the routing table does not seem to be updated?
    >> Does it require more than a failover restart?
    >> 
    >> Regards
    >> Michael Knill
    
    It would be nice if the "WAN Failover" stuff could be decoupled from the standard network startup (if possible).
    
    Michael
    
    http://www.mksolutions.info
    
    
    
    
    
    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    

Re: [Astlinux-devel] Removal of External Failover Destination Routes

[Michael K. <li...@mk...>]

> Am 13.07.2019 um 15:24 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> Hi Michael,
> 
>> when I add or remove an External Failover Destination Route...
> 
> Yes, that requires a system "Reboot" as they are configured on network startup.
> 
> But, if the changes are only to the "WAN Failover:" section, a "Restart Failover" is all that is needed.
> 
> Lonnie
> 
>> On Jul 13, 2019, at 2:43 AM, Michael Knill <mic...@ip...> wrote:
>> 
>> Hi Devs
>> 
>> I noticed that when I add or remove an External Failover Destination Route and restart Failover, the routing table does not seem to be updated?
>> Does it require more than a failover restart?
>> 
>> Regards
>> Michael Knill

It would be nice if the "WAN Failover" stuff could be decoupled from the standard network startup (if possible).

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Removal of External Failover Destination Routes

[Lonnie A. <li...@lo...>]

Hi Michael,

> when I add or remove an External Failover Destination Route...

Yes, that requires a system "Reboot" as they are configured on network startup.

But, if the changes are only to the "WAN Failover:" section, a "Restart Failover" is all that is needed.

Lonnie



> On Jul 13, 2019, at 2:43 AM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Devs
>  
> I noticed that when I add or remove an External Failover Destination Route and restart Failover, the routing table does not seem to be updated?
> Does it require more than a failover restart?
>  
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

[Astlinux-devel] Removal of External Failover Destination Routes

[Michael K. <mic...@ip...>]

Hi Devs

I noticed that when I add or remove an External Failover Destination Route and restart Failover, the routing table does not seem to be updated?
Does it require more than a failover restart?

Regards
Michael Knill

[Astlinux-devel] Announcing AstLinux Release: 1.3.6

[Lonnie A. <li...@lo...>]

Announcing AstLinux Release: 1.3.6

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.3.6 Highlights:
* Asterisk Versions: 13.23.1, 13.27.0, 16.4.0
* Upgrade to Linux Kernel 3.16.69, including the RUNNIX bootloader, security and bug fixes
* busybox, major version bump to 1.30.1, security and bug fixes
* ne, new package, version 3.1.2, the nice editor, alternative to nano, including syntax highlighting
* Asterisk 11.x is no longer included, officially EOL 2017-10-25
* Asterisk '13se' (stable edition) version 13.23.1 is included, older than latest Asterisk 13.x version but more tested, built --without-pjproject
* Asterisk 16.x is now included in the Install ISO and "ast16-firmware-1.x" repository
* Asterisk CDR's, when a Dial() has a B() option 'Return(IgnoreNoAnswerCDR)' ignore unanswered events
* WireGuard VPN, latest development snapshot during its incorporation into the mainline Linux Kernel
* Web Interface, Network, Edit tabs, add "Reload WireGuard VPN" support to apply peer changes/additions/deletions
* Web Interface, Status tab, add "ChangeLog" link to display changes since AstLinux 1.2.0 using local file storage
* Package upgrades providing important security and bug fixes

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.6/docs/ChangeLog.txt

All users are encouraged to upgrade.

Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal.

AstLinux Team