Bug 22833 - apache new security issues CVE-2017-1571[05], CVE-2018-1283, CVE-2018-130[1-3], CVE-2018-1312, CVE-2018-1333, CVE-2018-11763
Summary: apache new security issues CVE-2017-1571[05], CVE-2018-1283, CVE-2018-130[1-3...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA6-32-OK MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-03-27 03:55 CEST by David Walser
Modified: 2018-11-20 12:12 CET (History)
8 users (show)

See Also:
Source RPM: apache-2.4.29-4.mga7.src.rpm
CVE:
Status comment: Fixed upstream in 2.4.34


Attachments

David Walser 2018-03-27 03:57:35 CEST

Status comment: (none) => Fixed upstream in 2.4.30
Whiteboard: (none) => MGA6TOO, MGA5TOO

Comment 1 David Walser 2018-03-27 11:37:47 CEST
apache-2.4.33-1.mga7 uploaded for Cauldron by Shlomi.

Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
Version: Cauldron => 6

Comment 2 David Walser 2018-04-03 23:38:54 CEST
Debian has issued an advisory for this today (April 3):
https://www.debian.org/security/2018/dsa-4164
Comment 3 David Walser 2018-04-21 23:09:02 CEST
Ubuntu has issued an advisory for this on April 19:
https://usn.ubuntu.com/3627-1/
Comment 4 David Walser 2018-06-07 23:09:43 CEST
openSUSE has issued an advisory for this on May 10:
https://lists.opensuse.org/opensuse-updates/2018-05/msg00023.html
Comment 5 David Walser 2018-07-18 14:02:11 CEST
Upstream has issued advisories today (July 18):
http://openwall.com/lists/oss-security/2018/07/18/1
http://openwall.com/lists/oss-security/2018/07/18/2

CVE-2018-1333 only affects Mageia 6 and Cauldron.  CVE-2018-8011 affects Cauldron.

Summary: apache new security issues CVE-2017-1571[05], CVE-2018-1283, CVE-2018-130[1-3], CVE-2018-1312 => apache new security issues CVE-2017-1571[05], CVE-2018-1283, CVE-2018-130[1-3], CVE-2018-1312, CVE-2018-1333, CVE-2018-8011
Status comment: Fixed upstream in 2.4.30 => Fixed upstream in 2.4.34

Comment 6 David Walser 2018-08-02 17:51:55 CEST
Fedora has issued an advisory for CVE-2018-8011 on July 25:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/OAKZ4JYHJT62MCIGQ4J2TCJI6CXXZRCB/
Comment 7 David Walser 2018-08-28 22:39:58 CEST
openSUSE has issued an advisory for the two newest issues on August 19:
https://lists.opensuse.org/opensuse-updates/2018-08/msg00123.html
Comment 8 David Walser 2018-10-10 00:41:55 CEST
CVE-2018-11763 wasn't previously mentioned:
https://usn.ubuntu.com/3783-1/
Thomas Backlund 2018-10-16 17:29:53 CEST

Whiteboard: MGA5TOO => (none)
CC: (none) => tmb

Comment 9 David Walser 2018-10-17 22:56:18 CEST
(In reply to David Walser from comment #8)
> CVE-2018-11763 wasn't previously mentioned:
> https://usn.ubuntu.com/3783-1/

https://lists.opensuse.org/opensuse-updates/2018-10/msg00081.html
Comment 10 David Walser 2018-10-21 18:49:25 CEST
apache-2.4.35-1.mga7 uploaded for Cauldron by Bruno.

CC: (none) => bruno

Comment 11 Bruno Cornec 2018-10-21 19:11:33 CEST
apache-2.4.35-1.mga7 and apache-2.4.35-1.mga6 have now been pushed in cauldron and core/updates_testing
Bruno Cornec 2018-10-21 19:12:08 CEST

Status: NEW => ASSIGNED
Assignee: shlomif => qa-bugs

Comment 12 David Walser 2018-10-21 19:19:05 CEST
Apache build for Mageia 6 failed.  mod_systemd.so fails to build some percentage of the time due to buggy Makefiles that don't handle parallel builds correctly.  Unfortunately if the build succeeded on one arch, we'll need that removed before it can be resubmitted.

Assignee: qa-bugs => sysadmin-bugs
CC: (none) => qa-bugs

Comment 13 Bruno Cornec 2018-10-21 19:35:41 CEST
I think it's different than that. It seems that on my system, configure detects systemd-devel correctly, but not on the build system. In my local logs I have:

checking for tm_gmtoff in struct tm... yes
checking systemd/sd-daemon.h usability... yes
checking systemd/sd-daemon.h presence... yes
checking for systemd/sd-daemon.h... yes
  setting LIBS to "-lsystemd"
checking whether gcc accepts PIE flags... yes

On the build system:
checking for tm_gmtoff in struct tm... yes
checking whether gcc accepts PIE flags... yes

So I think the detection is incorrect (while the package is indeed installed). So I'm unsure of what is happening in fact :-(
Comment 14 David Walser 2018-10-21 19:37:23 CEST
It's a non-deterministic issue and it's been this way for years.  Sometimes it works and sometimes it doesn't.  We've reduced the parallelism in the build to make it work more often, but it still fails sometimes.
Comment 15 Bruno Cornec 2018-10-21 20:04:02 CEST
Hummm, I tend to think that when you write "non-deterministic" it means a difficult bug to catch ;-)  Software Computing *is* deterministic (hardware failures not) but parallelism makes it hard for us to understand and fix :-(

Anyway, I think the problem is *not* in the build, but in the configure phase which is not // as far as I know. And BTW make is called without parameters, so should not be //.
Comment 16 Bruno Cornec 2018-10-21 20:26:21 CEST
2 additional points:

- on mga7 I don't have that roblem at wall with a very similar build (did twice just now)
- maybe we should call buildconf before to regenerate the autoconf and that may help building a correct configure ?
Comment 17 David Walser 2018-10-21 20:28:36 CEST
You know better than that :o).  Computing is not always deterministic.  There's randomness, and parallelism makes things non-deterministic too.  However, I just noticed the %__make and I can't tell when that was changed, but yet it's been that way over a long period of time that we've still had non-deterministic failures sometimes to build mod_systemd.so.

You got lucky that it built on Mageia 7.  It usually does, but like I said, sometimes it doesn't.
Comment 18 David Walser 2018-10-23 16:37:25 CEST
We could try building 2.4.37:
http://www.apache.org/dist/httpd/CHANGES_2.4.37

I suggest doing Mageia 6 until it builds and uploads and then doing Cauldron in this case (usually you should do the opposite) so you know if it builds on first try or if you need to increment the release tag in Cauldron.
Comment 19 Bruno Cornec 2018-10-24 19:47:40 CEST
Indeed !! it built on mga6.
So: apache-2.4.37-1.1.mga6 is now available to test. 
Jumping on cauldron just after.
Comment 20 Bruno Cornec 2018-10-24 20:58:56 CEST
apache-2.4.37-2.mga7 is uploaded to cauldron

Assignee: sysadmin-bugs => qa-bugs

David Walser 2018-10-25 00:53:35 CEST

Summary: apache new security issues CVE-2017-1571[05], CVE-2018-1283, CVE-2018-130[1-3], CVE-2018-1312, CVE-2018-1333, CVE-2018-8011 => apache new security issues CVE-2017-1571[05], CVE-2018-1283, CVE-2018-130[1-3], CVE-2018-1312, CVE-2018-1333, CVE-2018-11763

Comment 21 David Walser 2018-10-25 16:09:31 CEST
Advisory:
========================

Updated apache packages fix security vulnerabilities:

mod_authnz_ldap, if configured with AuthLDAPCharsetConfig, uses the
Accept-Language header value to lookup the right charset encoding when
verifying the user's credentials. If the header value is not present in the
charset conversion table, a fallback mechanism is used to truncate it to a two
characters value to allow a quick retry (for example, 'en-US' is truncated to
'en'). A header value of less than two characters forces an out of bound write
of one NUL byte to a memory location that is not part of the string. In the
worst case, quite unlikely, the process would crash which could be used as a
Denial of Service attack. In the more likely case, this memory is already
reserved for future use and the issue has no effect at all (CVE-2017-15710).

A regular expression could match '$' to a newline character in a malicious
filename, rather than matching only the end of the filename. leading to
corruption of uploaded files (CVE-2017-15715).

When mod_session is configured to forward its session data to CGI applications
(SessionEnv on, not the default), a remote user may influence their content by
using a \"Session\" header leading to unexpected behavior (CVE-2018-1283).

Due to an out of bound access after a size limit being reached by reading the
HTTP header, a specially crafted request could lead to remote denial of
service (CVE-2018-1301).

When an HTTP/2 stream was destroyed after being handled, it could have written
a NULL pointer potentially to an already freed memory. The memory pools
maintained by the server make this vulnerability hard to trigger in usual
configurations, the reporter and the team could not reproduce it outside debug
builds, so it is classified as low risk (CVE-2018-1302).

A specially crafted HTTP request header could lead to crash due to an out of
bound read while preparing data to be cached in shared memory (CVE-2018-1303).

When generating an HTTP Digest authentication challenge, the nonce sent to
prevent reply attacks was not correctly generated using a pseudo-random seed.
In a cluster of servers using a common Digest authentication configuration,
HTTP requests could be replayed across servers by an attacker without
detection (CVE-2018-1312).

Fixed a worker exhaustion that could have lead to a denial of service via
specially crafted HTTP/2 requests (CVE-2018-1333).

In Apache HTTP Server by sending continuous, large SETTINGS frames a client
can occupy a connection, server thread and CPU time without any connection
timeout coming to effect. This affects only HTTP/2 connections
(CVE-2018-11763).

The apache package has been updated to version 2.4.37, fixing these issues and
several other bugs.  See the upstream CHANGES files for details.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15710
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15715
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1283
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1301
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1302
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1303
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1333
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1312
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11763
http://www.apache.org/dist/httpd/CHANGES_2.4
http://www.apache.org/dist/httpd/CHANGES_2.4.37
https://lists.opensuse.org/opensuse-updates/2018-05/msg00023.html
https://lists.opensuse.org/opensuse-updates/2018-08/msg00123.html
https://lists.opensuse.org/opensuse-updates/2018-10/msg00081.html
========================

Updated packages in core/updates_testing:
========================
apache-2.4.37-1.1.mga6
apache-mod_dav-2.4.37-1.1.mga6
apache-mod_ldap-2.4.37-1.1.mga6
apache-mod_session-2.4.37-1.1.mga6
apache-mod_cache-2.4.37-1.1.mga6
apache-mod_proxy-2.4.37-1.1.mga6
apache-mod_proxy_html-2.4.37-1.1.mga6
apache-mod_suexec-2.4.37-1.1.mga6
apache-mod_userdir-2.4.37-1.1.mga6
apache-mod_ssl-2.4.37-1.1.mga6
apache-mod_dbd-2.4.37-1.1.mga6
apache-mod_http2-2.4.37-1.1.mga6
apache-htcacheclean-2.4.37-1.1.mga6
apache-devel-2.4.37-1.1.mga6
apache-doc-2.4.37-1.1.mga6

from apache-2.4.37-1.1.mga6.src.rpm
Comment 22 Frédéric "LpSolit" Buclin 2018-10-27 20:10:10 CEST
I tested apache 2.4.37 on Mageia 6 with Bugzilla, Drupal, LimeSurvey and some other PHP applications. Everything works fine.
Comment 23 PC LX 2018-10-27 23:39:50 CEST
Installed and tested without issues.

System: Mageia 6, x86_64, Intel CPU.

Tests included:
- GET, POST, HEAD, PUT;
- HTTPS/SSL;
- Static files;
- Several PHP scripts (e.g. wordpress, drupal, roundcube, custom);
- CGI-BIN binaries and scripts;
- Multiple sites by host name and by IP;

$ uname -a
Linux marte 4.14.78-desktop-1.mga6 #1 SMP Sun Oct 21 20:31:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qa | grep apache | sort
apache-2.4.37-1.1.mga6
apache-mod_php-5.6.38-1.mga6
apache-mod_ssl-2.4.37-1.1.mga6

CC: (none) => mageia

Comment 24 Herman Viaene 2018-10-31 10:40:49 CET
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues.
httpd is running from startup,so I stopped it, ran the update and then started again, but failed
# systemctl -l status httpd
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since wo 2018-10-31 10:17:01 CET; 14min ago
  Process: 27974 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
 Main PID: 27974 (code=exited, status=1/FAILURE)

: Starting The Apache HTTP Server...
: httpd: Syntax error on line 54 of /etc/httpd/conf/httpd.conf: Syntax error
: httpd.service: Main process exited, code=exited, status=1/FAILURE
: Failed to start The Apache HTTP Server.
: httpd.service: Unit entered failed state.
: httpd.service: Failed with result 'exit-code'.

Checked etc/httpd/conf/httpd.conf, that line contains as usual
Include conf/modules.d/*.conf

CC: (none) => herman.viaene

Comment 25 Herman Viaene 2018-10-31 11:02:16 CET
Googling found a similar error occured in CentOS, but there the error pointed to mod_antiloris.
So possibly something is wrong in one of the files in modules.d
To exclude that some leftover from the previous version caused problems, I removed all apache packages, deleted /etc/httpd and reinstalled the updates.
Starting httpd now gives same error.
I get more info from:
# httpd -k start
httpd: Syntax error on line 54 of /etc/httpd/conf/httpd.conf: Syntax error on line 5 of /etc/httpd/conf/modules.d/01_mod_dbd.conf: Cannot load modules/mod_session_dbd.so into server: /etc/httpd/modules/mod_session_dbd.so: undefined symbol: ap_hook_session_save
Comment 26 Herman Viaene 2018-10-31 11:34:41 CET
More googling points to same issue I had on bug 21741, but to me it is not clear how this was resolved.
Checked that both apache-mod_session and apache-mod_userdir are installed.
Comment 27 Bruno Cornec 2018-11-08 00:52:25 CET
# urpmf mod_session_dbd.so
apache-mod_dbd:/usr/lib64/httpd/modules/mod_session_dbd.so

So I'd suggest you remove that package to just test apache.
Comment 28 Herman Viaene 2018-11-08 11:36:21 CET
@Bruno
Tx, that did the tric. so now pointing firefox to localhost says "It works". I will use it on bug 23780 squid to do a further test.
Comment 29 Herman Viaene 2018-11-08 11:46:10 CET
httpd did the job in bug 23780, so OK for me.

Whiteboard: (none) => MGA6-32-OK

Comment 30 Thomas Backlund 2018-11-08 13:34:20 CET
(In reply to Bruno Cornec from comment #27)
> # urpmf mod_session_dbd.so
> apache-mod_dbd:/usr/lib64/httpd/modules/mod_session_dbd.so
> 
> So I'd suggest you remove that package to just test apache.

Um, you do realize that apache-mod_dbd is part of this update, so if that is broken, we cant push the update

Keywords: (none) => feedback

Comment 31 Bruno Cornec 2018-11-09 01:16:34 CET
It seems related to 32 bits as the 2 users on 64 bits didn't get that issue right ?

Could it be that the apr and/or apr-utils packages are too old ?

Also following the thread here: http://apache-http-server.18135.x6.nabble.com/httpd-test-suite-breakage-td5033288.html it seems it could be a problem with the order in which modules are loaded.

What we have is:
/etc/httpd/conf/modules.d/01_mod_dbd.conf
/etc/httpd/conf/modules.d/01_mod_session.conf

I think the mod_dbd.so should be loaded *after* mod_session, which is not the case currently if we follow the alphabetic order.

@Herman: could you try to re-install apache-mod_dbd and do as root:
mv /etc/httpd/conf/modules.d/01_mod_dbd.conf /etc/httpd/conf/modules.d/02_mod_dbd.conf

and relaunch apache afterwards to check that idea ? If it works then that's an order issue and I'll make a new version for this.

However, I'm not sure I understand why it's only seen on 32 bits...
Comment 32 PC LX 2018-11-09 01:42:11 CET
(In reply to Bruno Cornec from comment #31)
> It seems related to 32 bits as the 2 users on 64 bits didn't get that issue
> right ?

From comment #23, I don't have the package apache-mod_dbd installed so I would not be affected by any issues with it.
Comment 33 Herman Viaene 2018-11-09 08:26:20 CET
@ Bruno Comment 31
I won't be able to do the test right now as I am hospitalized till next week Tuesday (probably), so I don't have access to my 32-bit laptop.
I will test ASAP unless someone else can jump in.
Comment 34 Bruno Cornec 2018-11-10 01:40:32 CET
@ Herman
Don't worry with time, there is nothing more urgent than your health here, so take care and come soon with us to continue improving Mageia !
Comment 35 Herman Viaene 2018-11-14 11:23:15 CET
@ Bruno Comment 31

# systemctl stop httpd
# systemctl -l status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since wo 2018-11-14 11:15:53 CET; 20s ago
  Process: 23251 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
  Process: 6843 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=0/SUCCESS)
 Main PID: 6843 (code=exited, status=0/SUCCESS)
   Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec:   0 B/sec"

nov 14 09:34:38 mach6.hviaene.thuis systemd[1]: Starting The Apache HTTP Server...
nov 14 09:35:07 mach6.hviaene.thuis systemd[1]: Started The Apache HTTP Server.
nov 14 10:45:13 mach6.hviaene.thuis systemd[1]: Reloading The Apache HTTP Server.
nov 14 10:45:17 mach6.hviaene.thuis httpd[23251]: AH00558: httpd: Could not reliably determine the serv
nov 14 10:45:17 mach6.hviaene.thuis systemd[1]: Reloaded The Apache HTTP Server.
nov 14 11:15:42 mach6.hviaene.thuis systemd[1]: Stopping The Apache HTTP Server...
nov 14 11:15:53 mach6.hviaene.thuis systemd[1]: Stopped The Apache HTTP Server.

here I installed apache-mod_dbd again, then

# mv /etc/httpd/conf/modules.d/01_mod_dbd.conf /etc/httpd/conf/modules.d/02_mod_dbd.conf
# systemctl start httpd
# systemctl -l status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled)
   Active: active (running) since wo 2018-11-14 11:19:24 CET; 8s ago
  Process: 23251 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
 Main PID: 968 (httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─968 /usr/sbin/httpd -DFOREGROUND
           ├─980 /usr/sbin/httpd -DFOREGROUND
           ├─981 /usr/sbin/httpd -DFOREGROUND
           ├─982 /usr/sbin/httpd -DFOREGROUND
           ├─991 /usr/sbin/httpd -DFOREGROUND
           └─992 /usr/sbin/httpd -DFOREGROUND

nov 14 11:19:21 mach6.hviaene.thuis systemd[1]: Starting The Apache HTTP Server...
nov 14 11:19:23 mach6.hviaene.thuis httpd[968]: AH00558: httpd: Could not reliably determine the server
nov 14 11:19:24 mach6.hviaene.thuis systemd[1]: Started The Apache HTTP Server.
Comment 36 Thomas Backlund 2018-11-15 23:18:06 CET
(In reply to Bruno Cornec from comment #31)
> It seems related to 32 bits as the 2 users on 64 bits didn't get that issue
> right ?
> 
> Could it be that the apr and/or apr-utils packages are too old ?
> 
> Also following the thread here:
> http://apache-http-server.18135.x6.nabble.com/httpd-test-suite-breakage-
> td5033288.html it seems it could be a problem with the order in which
> modules are loaded.
> 
> What we have is:
> /etc/httpd/conf/modules.d/01_mod_dbd.conf
> /etc/httpd/conf/modules.d/01_mod_session.conf
> 
> I think the mod_dbd.so should be loaded *after* mod_session, which is not
> the case currently if we follow the alphabetic order.
> 
> @Herman: could you try to re-install apache-mod_dbd and do as root:
> mv /etc/httpd/conf/modules.d/01_mod_dbd.conf
> /etc/httpd/conf/modules.d/02_mod_dbd.conf
> 
> and relaunch apache afterwards to check that idea ? If it works then that's
> an order issue and I'll make a new version for this.
> 
> However, I'm not sure I understand why it's only seen on 32 bits...

Yeah, this seems to be load ordering/timing issue.

As for why it works on 64bit can also be hw/vm performance related that its loading faster there so it manages to load mod_session fast enough before mod_dbd bails out...

Of course also locales comes in to play as not all locales treats ordering the same way
Comment 37 Bruno Cornec 2018-11-19 01:45:14 CET
apache-2.4.37-1.2.mga6 on its way with the fix mentionned above done.
Comment 38 David Walser 2018-11-19 12:42:24 CET
apache-2.4.37-1.2.mga6
apache-mod_dav-2.4.37-1.2.mga6
apache-mod_ldap-2.4.37-1.2.mga6
apache-mod_session-2.4.37-1.2.mga6
apache-mod_cache-2.4.37-1.2.mga6
apache-mod_proxy-2.4.37-1.2.mga6
apache-mod_proxy_html-2.4.37-1.2.mga6
apache-mod_suexec-2.4.37-1.2.mga6
apache-mod_userdir-2.4.37-1.2.mga6
apache-mod_ssl-2.4.37-1.2.mga6
apache-mod_dbd-2.4.37-1.2.mga6
apache-mod_http2-2.4.37-1.2.mga6
apache-htcacheclean-2.4.37-1.2.mga6
apache-devel-2.4.37-1.2.mga6
apache-doc-2.4.37-1.2.mga6

from apache-2.4.37-1.2.mga6.src.rpm

Keywords: feedback => (none)
Whiteboard: MGA6-32-OK => (none)

Comment 39 Herman Viaene 2018-11-19 14:22:47 CET
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues for versions 2.4.37-1.2
At CLI:
# systemctl stop httpd
# systemctl -l status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since ma 2018-11-19 13:41:16 CET; 7s ago
  Process: 7484 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=0/SUCCESS)
 Main PID: 7484 (code=exited, status=0/SUCCESS)
   Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec:   0 B/sec"

nov 19 13:36:11 mach6.hviaene.thuis systemd[1]: Starting The Apache HTTP Server...
nov 19 13:36:24 mach6.hviaene.thuis httpd[7484]: AH00558: httpd: Could not reliably determine the serve
nov 19 13:36:25 mach6.hviaene.thuis systemd[1]: Started The Apache HTTP Server.
nov 19 13:41:04 mach6.hviaene.thuis systemd[1]: Stopping The Apache HTTP Server...
nov 19 13:41:16 mach6.hviaene.thuis systemd[1]: Stopped The Apache HTTP Server.

Then install the updates.

# systemctl start httpd
# systemctl -l status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: enabled)
   Active: active (running) since ma 2018-11-19 14:15:08 CET; 5s ago
 Main PID: 18725 (/usr/sbin/httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─18725 /usr/sbin/httpd -DFOREGROUND
           ├─18757 /usr/sbin/httpd -DFOREGROUND
           ├─18758 /usr/sbin/httpd -DFOREGROUND
           ├─18763 /usr/sbin/httpd -DFOREGROUND
           ├─18768 /usr/sbin/httpd -DFOREGROUND
           └─18775 /usr/sbin/httpd -DFOREGROUND

nov 19 14:15:00 mach6.hviaene.thuis systemd[1]: Starting The Apache HTTP Server...
nov 19 14:15:03 mach6.hviaene.thuis httpd[18725]: AH00558: httpd: Could not reliably determine the serv
nov 19 14:15:08 mach6.hviaene.thuis systemd[1]: Started The Apache HTTP Server.

Checked working of httpd by accessing phpmyadmin: works OK

Whiteboard: (none) => MGA6-32-OK

Comment 40 Thomas Andrews 2018-11-19 15:46:17 CET
It feels like I'm treading in unknown waters here, crocodiles nipping at my heels, but plunging ahead anyway.

I know nothing here, but just going by package names, it would appear that this bug and Bug 23541 are related, if perhaps distantly. Should they be tested together, and perhaps pushed together? Or should one or the other be done first?

Realizing, of course, that 23541 is labeled as critical, where this one is not.

(Posting a similar comment in bug 23541.)

CC: (none) => andrewsfarm

Comment 41 PC LX 2018-11-19 16:19:05 CET
Installed and tested without issues.

System: Mageia 6, x86_64, Intel CPU.

Redid much of the tests in comment #23.

$ uname -a
Linux marte 4.14.78-desktop-1.mga6 #1 SMP Sun Oct 21 20:31:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qa | grep apache | sort
apache-2.4.37-1.2.mga6
apache-mod_php-7.2.11-3.mga6
apache-mod_ssl-2.4.37-1.2.mga6
Comment 42 Lewis Smith 2018-11-19 20:36:59 CET
Adding x32 OK for PC_LX. Many thanks to you & Herman & Bruno for clearing this.
Advisory done from comments 21 (mostly) & 37 (SRPM). Validating.

Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OK
Keywords: (none) => advisory, validated_update
CC: (none) => lewyssmith, sysadmin-bugs

Comment 43 Mageia Robot 2018-11-20 12:12:23 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0460.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.