Re: apt-get install apache2 fails in wheezy amd64
Hi, On Friday 01 May 2015 11:14:28 j.halif...@seznam.cz wrote: > where /etc/apt/sources.list contains > > deb http://security.debian.org/ wheezy/updates main contrib > > > deb-src http://security.debian.org/ wheezy/updates main contrib How about using a proper sources.list? https://wiki.debian.org/SourcesList -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: This is a digitally signed message part.
Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy -> jessie upgrade
On 19.11.2014 16:49, Andreas Beckmann wrote: > PS: do you need the apache2.2-common transitional package? would > upgrades work if that would not exist? Please see https://lists.debian.org/debian-devel/2014/07/msg00450.html for all the gory details. We added it very late in the process to work around people's laziness :/ -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy -> jessie upgrade
Hi, On 10.11.2014 00:11, Andreas Beckmann wrote: > that process would have to be distributed to two packages ... We do right that already, the best we can. cf.: http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.preinst http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.postinst We can't use dpkg-maintscript helper for the reason you named, as we renamed the package "owning" it. However, I believe, we cleanly remove/take-over the conffiles in the best way dpkg allows us. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#765347: Disable SSLv3 in default config
For the records, we evaluated the market share of IE6. Several sources indicate it's in the < 0.1% range so that it sounds like a safe default to disable SSLv3. - http://www.w3schools.com/browsers/browsers_explorer.asp says - https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Apache 2.4 backport
Hi, On 24.09.2014 14:41, Alexander Wirt wrote: >> FYI I intend to upload a backport of Apache 2.4, because we're going >> to need it for deploying the next FusionForge on Wheezy. >> >> I'll use this method: >> https://wiki.debian.org/BuildingFormalBackports#Self-contained_example_for_Apache_2.4 > did you talked with the apache maintainers in advance? If not please do so > and ask them what they think about such a backport. personally I do not mind either way but I'd never take the burden to maintain that backport. About the decision itself, it is something the backport ftpmasters need to decide upon, not us. However, as Jan said in the other mail backporting Apache 2.4 to Wheezy is a heavy invasive package that has a few hundred reverse dependencies, that won't work with a backport package as ABIs and APIs are incompatible, and the packaging has changed. To give you an idea: [1] has a list of packages that are instantly RC-buggy without a side backport, and [2] is a list of packages, that may or may not break in one way or another. [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=apache24transition;users=debian-apache@lists.debian.org;archive=both [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=apache24webapptransition;users=debian-apache@lists.debian.org;archive=both -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#762584: apache2: silently changes user configuration /etc/logrotate.d/apache2
On 23.09.2014 15:01, Vincent Lefevre wrote: > On 2014-09-23 14:43:49 +0200, Arno Töll wrote: >> We install this file through dh_installlogrotate and it is listed as a >> conffile in the binary package of apache2. That means, it will be >> handled like any other configuration file in Debian with special care >> and it won't overwrite changes YOU made. > > OK, but then, is there any reason not to announce it in the NEWS file? > This is a significant configuration change! This is a change like the ones which happen every day in Debian during an update. It's not "newsworthy" I think. > Unfortunately it doesn't seem to be possible to hint dpkg: according > to the dpkg(1) man page, all the conffile related options are in the > case "If a conffile is missing" or "If a conffile has been modified" > (while here it exists, but was not modified because the default was > OK). You're looking for --force-confold. See http://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/ for all details. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Apache 2.4.10
Hi, On 20.07.2014 16:36, Torben Dannhauer wrote: > When will Apache 2.4.10 be available as debian package? Apache 2.4.10 is not even released yet. It's being (successfully) voted on the lists, but not officially released yet. Once it is, we will upgrade to it for sure. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Hi Jonathan, On 14.07.2014 23:12, Jonathan Nieder wrote: > https://wiki.debian.org/Apache/PackagingFor24 is helpful (thanks!), > but I'm still stuck --- I really just don't know how to package gitweb > in the new setup. See also http://bugs.debian.org/669292#28: > > * It's not clear when to run "apache2_invoke enconf gitweb" for a >package like gitweb that does not have a Depends against apache >2.4. If I run it conditionally based on the Apache version, then >gitweb will still be broken when the user upgrades apache, unless >gitweb happens to be upgraded later in the same upgrade run. web applications aren't supposed to depend on Apache anyway. We suggest packagers of web applications to recommend on Apache so that other web servers can be used, too if people wish. On that matter I do not think gitweb would be different to other packages, or is it? Therefore, we recommend that you check if Apache 2.4 is installed at time you execute the maintainer scripts. There is not much you or we could do, if it isn't. We do both agree that gitweb should rather not depend on Apache, therefore we need conditionals in maintainer scripts. For Apache 2.4 this works like this: if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper apache2_invoke enconf gitweb.conf || exit $? fi This ensures that your configuration is enabled when Apache is installed, and it will not fail if it is not. You do not need to worry in what context to execute this, as our apache2-maintscript-helper takes care to figure out the right thing in the right context (e.g. postinst configure). > * It's not clear when to run "apache2_invoke disconf gitweb". At >"remove" and "purge" time doesn't seem to be enough. Likewise as for the enable part. Just call if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper apache2_invoke disconf gitweb.conf || exit $? fi ... and apache2-maintscript-helper tries to figure out when to do what. In particular we disable the module in postrm purge, postrm remove and prerm remove. When else do you think it would be necessary? For the archives: apache2-maintscript-helper is reading the maintainer script state out of $@ supplied to your script. If you wish to call it from a function, you must ensure the context is preserved. If you wish, you can set APACHE2_MAINTSCRIPT_DEBUG (e.g. in /etc/apache2/envvars) and get debug output of the apache2-maintscript-helper at runtime to see what it does in various use cases. > And > https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292: > > - prerm deconfigure does not clean up as much as it should > - needs triggers to reconfigure when apache is updated? Not sure what you ask me about here? > Basically, I am stuck on understanding the state machine: > > (1) What is the intended update order between webapps, apache-common, > and apache itself? What Depends, Pre-Depends, or triggers should > be used to make sure everything works okay regardless of the > update order? Please read http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;h=0bbb06c48d628cd7c3b6037a0118574a722f2184;hb=HEAD#l157. Does this answer your questions? It does not talk about triggers, because there are none (though we planned to do at some stage) ;-) > In particular, the conditional enconf and disconf invocations > seem to make it easy to get into a non-working state and never > get out of it. Well, we need to deal with that. This is not different than before. If Apache2 wasn't installed, you putting a conf to conf.d is not going to work out either. If you meant to address situations when you install your conf to conf-available and install Apache at a later stage, it is our business (i.e. Apache maintainer's) to ensure those get enabled then. That's a good point actually, and I need to think if we can and should do something in that case. > (2) What is the intended uninstallation procedure? > https://wiki.debian.org/Apache/PackagingFor24 tells me I should > enconf in postinst and disconf in postrm. That's confusing > because: > > * Usually in packaging, postinst is a mirror image of prerm so >when the package is in a given dpkg state, the state of >configuration matches that. Why here is postinst's mirror >image in postrm instead? > > * Dependencies are not guaranteed to be present during postrm, so >the disconf is not guaranteed to happen. > It is actually preferred that disconf is called in prerm. This is also what dh-a
Re: a2* scripts
Hi, On 15.07.2014 19:10, Taylor Price wrote: > Would there be a licensing or functionality problem for us to include these > in our cookbook for distribution? as for licensing, they are licensed under the Apache 2.0 license (just as the web server itself). That gives you a wide range of permissions to use it for your own purposes. As for functionality, I don't know. It's your software :-) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#745605: apache2: ignores AddDefaultCharset
Hi,
On 16.06.2014 22:59, Arnaud de Prelle wrote:
> It seems Apache 2.4.9-2 misuses the AddDefaultCharset statement.
> By default it should be Off but the current 2.4.9-2 simply overrides the
> value of the parameters and sets it to UTF-8.
are you sure, this isn't overridden by PHP as in Carlos' case? Apache
defaults to
#define DEFAULT_ADD_DEFAULT_CHARSET_NAME "iso-8859-1"
else if (!strcasecmp(arg, "On")) {
d->add_default_charset = ADD_DEFAULT_CHARSET_ON;
d->add_default_charset_name = DEFAULT_ADD_DEFAULT_CHARSET_NAME;
when set to on, and this code hasn't changed a long time.
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
Bug#736809: apache2-bin needs proper Breaks: for Apache 2.4 transition
On 26.01.2014 22:30, Adrian Bunk wrote: > Package: apache2-bin > Version: 2.4.6-3 > Severity: serious > > First, I was surprised to see the many open and non-RC bugs in [1], > shouldn't packages that e.g. use /etc/apache2/conf.d/ have an RC bug > since they'll definitely have to get fixed for jessie? Yes. However, the problem is, that a lot of web apps are not all technically release critical broken. We need to look at all of them on a case by case basis and decide what exactly they do (or don't do). This is on my to do, but if someone beats me on it, I won't complain. :-) > Second, for supporting all possible upgrade and partial upgrade > scenarios (not only between wheezy and jessie, Debian-derived > distributions like Ubuntu might have different collections of > packages), apache2-bin needs to have a versioned Breaks: against > the broken versions of all of the packages in [1] and [2]. Why? Packages in [2] aren't supposed to depend on apache2.2-bin (with some few exceptions, against which ones we /do/ have Breaks in place). Module packages depend on apache2.2-common, where we do force removal upon upgrade, so that in turn, obsolete dependencies without proper replacement are removed, too. For web apps, it's merely a definition of "Breaks", a lot of web apps continue to work just fine, just the automated integration into Apache does not work anymore, or the example configuration needs a few fixes, whereas the package itself just works fine. Not that they would depend on apache2.2-bin. > (Are there more such usertags?) No, there are not. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
reassign mpm-itk thanks Steinar, On 05.04.2014 17:01, Steinar H. Gunderson wrote: > This is almost certainly a configuration issue. It sounds like he is hitting > suexec or suphp. I'm handing this over to you now that itk is its own package. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: Solutions for the Apache upgrade hell
Hello, we've got a problem with Apache that causes problems during upgrades (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4 changed ABIs, so that we need to ensure that dpkg properly removes packages linking against the obsolete ABIs at upgrade time. This is the first time this happened since Debian Etch, so this brings a problem to the spotlight, that hasn't been one for a long time. To summarize the bug reports: The problem is, that Apache package maintainers at that time decided, that third party modules shall depend on apache2.2-common, by guaranteeing ABIs remain stable as long as the package name does not change. This is, so far policy compliant. However, by now ABIs did change and we were forced to rename the package (we did so, by providing a virtual API package third parties must depend on. At time of writing this is apache2-api-20120211). Unfortunately, apache2.2-common also contains conffiles and configuration file handling in postinst/postrm ... I spent a lot of time to properly transition to a new state with conffiles/configuration separated from ABI handling, and this works well enough for regular updates by now. Unfortunately it turns out, that /a lot/ of people use "aptitude --purge-unused safe-upgrade", or the apt equivalent "apt-get dist-upgrade --purge" which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. Those people end up with effects as described in the bugs outlined above, for example with incomplete installations because our maintainer scripts had no chance to properly detect the state of the /etc/apache2 directory before the upgrade. This gives us three possibilities which all have unwanted side effects (unless you come up with an idea that all of us makes happy). I'm writing to this list in hope that someone has a very smart idea to make everyone happy, or express your support for either alternative to give us some insights what people think would be the best alternative. * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING". The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? * Add a apache2.2-commmon transitional package. This gives us a chance to inspect /etc/apache2 in spite of --purge-unused and properly transition to Apache 2.4. HOWEVER, this has the nasty side effect that modules ABIs are considered compatible as far as dpkg is concerned. Therefore, old module packages aren't forced to be removed and this breaks at runtime when people try to start their upgraded web server with incompatible modules. As a workaround we could add a versioned "Breaks" for all modules in Wheezy (~ 75) in the apache2.2-common transitional package, and in addition for packages that existed in Squeeze or Etch only (no, really). That said, this still won't help for third party modules outside Debian which people might use (and to my best knowledge, they do a lot) and it's generally problematic in view of the policy with respect to library packaging (even though we're not a library strictly speaking) * Treat the upgrade as new install in our maintainer scripts when --purge-unused was used (side question: Any idea how to reliably and properly detect that case, as the binary package name changed and it's well possible that in Wheezy apache2.2-common is installed, but not apache2 because of weird(tm) packaging)? This would not preserve user's choices in regard of enabled/disabled modules and thus be a borderline policy violation, too. What would you do in our situation? Side note 2: We kinda expected this situation and added a trapdoor in Wheezy [1], but it turned out, that even that is not good enough to prevent havoc with --purge-unused. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postrm;h=bbe9f740b81cf8af64412f7ba6aace119dd159ad;hb=refs/heads/wheezy#l5 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#752922: apache2 upgrade wheezy->jessie breaks certain apache2 modules
merge 752922 711925 thanks Hi, This is a duplicate of #711925. I will merge the isse you reported. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#753851: apache2: [core:notice] [pid 22446] AH00052: child pid 22554 exit signal Segmentation fault (11)
reassign 753851 libapache2-mod-php5 thanks Hi Rainer, yes - this is indeed an issue in PHP. gc_remove_zval_from_buffer sounds like PHP tries to access a freed value. I'm reassigning to PHP, maybe they can tell you more about. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
Steinar, could you please comment on that? I have no experience with itk whatsoever. Therefore, I do not how if this is a problem in itk or a configuration issue. Moreover, please reasign this bug to the itk source package, if this is a still persisting problem. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Ubuntu and the default page
Hi Robie, On 18.03.2014 18:23, Robie Basak wrote: > Hi, > > This area is a can of worms. I feel that whatever I do I may upset > someone, so this email is an attempt to mitigate this. I've attached my > proposal as a starting point. I'm open to doing something else if there > is consensus that I should. I'm not so sure what you're worried about. I am the author of that page, and I'm perfectly fine if you replace whatever statement you like to make it suitable to Ubuntu. Feel free to remove any mentioning of Debian if you think that's helpful for your users, or the page altogether. > [..] > My proposal is attached. I haven't changed the logo yet but I expect > I'll swap the logo out for a suitable Ubuntu logo - please object if you > think this is not appropriate. I'm fine with those changes. I do not know if you feel like patching this every time you import the package, but that's up to you. If you want, we could also add your index.html to the Debian package, and install either alternative based on the detected build host, you know some conditional file selection based on `dpkg-vendor --query vendor`. However, that implies that you send back changed to use you'd like to have in "your" index.html. Alternatively, we could also try to find a page version that fits both of us (though that may confuse users). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2
Original Message From: marco.ri...@gmail.com Fri Feb 21 09:50:06 2014 Return-Path: X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id 5362C16419A; Fri, 21 Feb 2014 09:50:06 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smart.knallkopp.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 X-policyd-weight: using cached result; rate: -5.5 Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id B18AD164178 for ; Fri, 21 Feb 2014 09:50:00 +0100 (CET) Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]) by muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1WGlny-0002UE-Jp for deb...@toell.net; Fri, 21 Feb 2014 08:49:59 + Received: by mail-ee0-f42.google.com with SMTP id b15so1451736eek.1 for ; Fri, 21 Feb 2014 00:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MnCfXMdLIR8yfrFpVOsC73jng1WPi2xW1MQ0+AGzT2Y=; b=FlCUSqX90YmXIVCaTpes6szFuydunoaEmZTyIBe0w06rBj/p7fqTiFz+f6+pdtFyGs asQeTAIph/zaIR5F/aFZM222ZWkWJvPotko/1KECj9cvzCLZmi76dIxwZOWBOVKFML2Z +OzdQ6GnV+Yepph4qALDfwhnJzMapwbnHu+TLKKBU9bw6Y57kRK8falB0QI7eRr8VAms SFFomsT1rM0BHI+NztKIoQReas4eyEu7Zb6ORDTG5uCK3OS5ZaRftDcz1WH0xUFcx0EW zdCH0cyZGn3nxKW6QdXLwH05DL+bZJ1pF1zJf9wKUpjxlpDnu3k7mcg+svOWQZrr2kvt IFMw== X-Received: by 10.14.175.2 with SMTP id y2mr6817847eel.75.1392972590781; Fri, 21 Feb 2014 00:49:50 -0800 (PST) Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it. [146.48.81.142])by mx.google.com with ESMTPSA id 46sm24014582ees.4.2014.02.21.00.49.50for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Fri, 21 Feb 2014 00:49:50 -0800 (PST) Message-ID: <5307132d.8030...@gmail.com> Date: Fri, 21 Feb 2014 09:49:49 +0100 From: Marco Righi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Arno Töll Subject: Re: Bug#739614: [apache2] unable to execute apache2 References: <53060663.7050...@gmail.com> <5306157d.6020...@debian.org> In-Reply-To: <5306157d.6020...@debian.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit > apachectl start Command 593 of 97 #apachectl start sh: 0: getcwd() failed: No such file or directory AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 2a00:1620:c0:50:f66d:4ff:fe74:f12c. Set the 'ServerName' directive globally to suppress this message (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down AH00015: Unable to open logs Action 'start' failed. The Apache error log may have more information. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530716e7.8060...@debian.org
Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2
Original Message From: marco.ri...@gmail.com Thu Feb 20 16:18:52 2014 Return-Path: X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id 9C42516419A; Thu, 20 Feb 2014 16:18:52 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smart.knallkopp.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 X-policyd-weight: using cached result; rate: -5.5 Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id AF2D9164178 for ; Thu, 20 Feb 2014 16:18:46 +0100 (CET) Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]) by muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1WGVOe-F6-Qc for deb...@toell.net; Thu, 20 Feb 2014 15:18:45 + Received: by mail-ea0-f177.google.com with SMTP id h14so965338eaj.36 for ; Thu, 20 Feb 2014 07:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KCVsdwZl/eWZiXqUrvvp1mY+bJdhHi4DUGiCgkttRX4=; b=a5lP10JdD+rr+mInYKC4E2uh6alFfk0YOLszGp7ykzrQN191K9Ho81hATU9vjd3Kvz ia2jeBmW4YJ9O8pqswIepGLi2L1FvzDu30cFf8YWSNQFT1Tp1xfu7jSJVzlII1WCcDnf R+hhu6RmZj/P0Hxph2mHNB3QAnMSlcEPC5Ui9hL/T+Vzm5Yb6UMLENR5IiALigbfwAZA fUD8lVIYpwME5mxdMWYx3K4GqKHUB+OZywCBghilXRP6Y5ryS5i+kCnMhOdfyqbCxEfI 5rj+DC3SFHJNKEmLRCEDLdOd7lE78FvKZtuY/9vOgxMetlqWHpccDKW00YT71lWo2Ra5 AeRw== X-Received: by 10.15.42.72 with SMTP id t48mr2439607eev.45.1392909517030;Thu, 20 Feb 2014 07:18:37 -0800 (PST) Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it. [146.48.81.142])by mx.google.com with ESMTPSA id v6sm14914396eef.2.2014.02.20.07.18.36for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Thu, 20 Feb 2014 07:18:36 -0800 (PST) Message-ID: <53061ccb.4020...@gmail.com> Date: Thu, 20 Feb 2014 16:18:35 +0100 From: Marco Righi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Arno Töll Subject: Re: Bug#739614: [apache2] unable to execute apache2 References: <53060663.7050...@gmail.com> <5306157d.6020...@debian.org> In-Reply-To: <5306157d.6020...@debian.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit I have try to use /etc/inid.d/apache2 restart The command shell is quick to execute the STOP command. It is very slow during the start session. I have not error messages. I am sure that apache does not run because when I try to connect to localhost with firefox I got a timeout. Moreover, it is strange that the log files are empty! I have try to uninstall completely apache2 using synaptic. After the unistallation I deleted the /etc/apache2 directory. I have installed again apache2 (without delete the apt cache) and I have encountered again the previous problem! do you think that it is important try to execute directly "apachectl start"? Marco Il 20/02/2014 15:47, Arno Töll ha scritto: > Hi Marco, > > On 20.02.2014 14:42, Marco Righi wrote: >> >> Please ask to me if you need more informaitons. > > Of course we do need more information. You didn't tell us anything > we could work with. > > At very least you should tell us why you think Apache won't start, > how you tried, and what happens if you execute "apachectl start". > You know, anything. > > -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530683a7.6070...@debian.org
Bug#739614: [apache2] unable to execute apache2
Hi Marco, On 20.02.2014 14:42, Marco Righi wrote: > > Please ask to me if you need more informaitons. Of course we do need more information. You didn't tell us anything we could work with. At very least you should tell us why you think Apache won't start, how you tried, and what happens if you execute "apachectl start". You know, anything. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#732450: please sign new apache releases only with strong keys -- trimming the KEYS file
Hi, On 27.12.2013 00:18, Nick Kew wrote: > What is Debian's view on the relative importance of key size vs breadth > and depth of the WoT surrounding a key? I would tend to find an ancient > 1024-bit key with 100 strong-set sigs much more reassuring than a shiny > new 4096-bit with just 1 (let alone any number of non-strong-set keys)! Debian /requires/ new developers to obtain a key being 2048R at least and urges existing developers migrate to stronger keys, while aiming to keep a solid WoT. Formal and informal keysigning parties on DebConfs and resigning requests are a used practice to transition to stronger keys. Full details are covered in [1][2]. Debian's best practices for a key migration are documented in [3] [1] http://lists.debian.org/debian-devel-announce/2010/09/msg3.html [2] http://keyring.debian.org/creating-key.html [3] http://keyring.debian.org/replacing_keys.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#732450: debian/watch: help uscan verify PGP signature automatically
Hi, On 23.12.2013 17:48, Daniel Kahn Gillmor wrote: > But if apache is issuing cryptographic signatures from any of the weak > keys in KEYS, we should encourage them to stop doing so. Apache's > source code is a high-value target, and we should not leave the software > distribution mechanism open to fiddling based on weak keys for > cryptographic certifications. [..] > I recommend filtering KEYS by removing every key whose primary key (or > any signing-capable subkey) is less than 3072 bits (assuming RSA or DSA > keys here) before storing it in debian/upstream-signing-key,pgp. I'm absolutely with you on that. I strongly agree that Apache people should use stronger keys. However, we're a distribution - it's not our job to define key requirements for upstreams. We can, and maybe should talk to them on that matter but technically it's not only Jim to be allowed to release new versions of the Apache web server. That being said, it's them to accept/define valid and legit keys used within their project. Therefore, I thought a more complete patch would be a keyring which includes all signatures of people allowed to sign and release code on behalf of the httpd project. I do not mind removing "weak" keys again, but then I wonder if there is an actual benefit if Jim for once doesn't sign a release. Either way, we should move this discussion to upstream I guess. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731531: apache2ctl doesn't create /var/run/apache2/
Hi Harald, On 06.12.2013 11:47, Harald Dunkel wrote: > Package: apache2 > Version: 2.2.22-13 > > I have to start apache using a dedicated account and > > sudo /usr/sbin/apache2ctl -f /my/apache2.conf -k graceful > > instead of root and "/etc/init.d/apache2 start". Problem: > apache2 fails to start with > > Cannot create SSLMutex with file `/var/run/apache2/ssl_mutex' > > /var/run/apache2/ doesn't exist. > > This is not graceful. Indeed. However, you seem to use your own configuration by bypassing the apache2 init.d scripts. In this case, I claim, It's legit to assume that you take care of creating the directories you need in your (private) configuration yourself. I'd think that it is Debian's job to provide an environment which can be started off the default configuration, but you seem to use a private setup instead. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#732450: debian/watch: help uscan verify PGP signature automatically
tag 732450 +pending thanks Hi Daniel, On 18.12.2013 08:53, Daniel Kahn Gillmor wrote: > It looks like Jim Jagielski is signing apache2 releases (at least > those from 2.2 onward, which are all that we care about) with his key > with fingerprint A93D 62EC C3C8 EA12 DB22 0EC9 34EA 76E6 7914 85A8. > > So to get uscan to verify this automatically, you'd do: > > FINGERPRINT='A93D 62EC C3C8 EA12 DB22 0EC9 34EA 76E6 7914 85A8' > gpg --keyserver keys.gnupg.org --recv "$FINGERPRINT" > cd src/apache2 > gpg --export "$FINGERPRINT" > debian/upstream-signing-key.pgp thanks for that suggestion. I added your patch for the upcoming package upload. I did, however, add the full keyring of Apache developers that /could/ sign a release as listed in http://www.apache.org/dist/httpd/KEYS -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#718789: apache2: upgrade wheezy -> testing (2.4.6-2) wiped out all of my log files
Hi, On 26.11.2013 15:39, Marc Dequènes (Duck) wrote: > thus httpd.conf is probably > the most problematic lost file. note that we do not ship httpd.conf in Wheezy. If you still have it, it will remain as it is not "owned" by apache2.2-common anymore. See also: http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postinst;h=a730b9eff5f06d34301c2cb23804553f2ac4c21b;hb=refs/heads/wheezy#l80 > I guess this is all dead for unstable but a stable upload may introduce > some mechanism without recreating an apache2.2-common package. Now that the transition is over, we could reintroduce a -common transitional package, but again, we will carefully evaluate this before, as this causes lots of side-effects. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation
On 07.11.2013 16:06, Vincent Lefevre wrote: >> In fact, it's not even a bug since you installed a leaf package >> directly which is not meant to be used standalone. > > You're wrong. Users are not forced to install metapackages. > I probably did "apt-get install apache2-mpm-itk" to make sure > that this version of the server was installed (something that > "apt-get install apache2" doesn't). It you think that apache2 > must have been installed too, then a "Depends: apache2" must > have been added (and "Provides: apache2" should probably have > been removed), or at least a "Recommends: apache2". Note that > apache2-mpm-itk provided httpd, so that there were no reasons > at all to install apache2 *explicitly*. I did not say, that users are forced to install meta packages, but that -mpm-* packages existed _only_ to let reverse dependencies depend on them at Apache 2.2 time, as some modules require a particular MPM to run. They are not meant to be installed standalone by users, and are now fortunately going to disappear. In fact, all they do is to change the link pointing to the MPM you are going to use. However, we cannot just depend on the "apache2" package as you suggest, because some packages use the binaries only, without wanting the full stack (configuration files, handling, init scripts etc.) - e.g. look at gnome-user-share which pulls apache2.2-bin. If you look into the 2.2 packages you will notice, that neither of the MPM packages _actually_ includes that MPM. They are all, always installed by apache2.2-bin. > No! Apache was already installed (with httpd provided by > apache2-mpm-itk, so that this Recommends was satisfied). The > problem is that apt pulled tntnet *in addition* to Apache. Yes. But that's a problem of apt[itude], not of the packaging of Apache as I said previously. We ensure that people having apache2-mpm-itk installed get the appropriate package with the appropriate MPM providing httpd in Apache 2.4 again. If that makes apt think that there is no httpd installed for a transient moment in time, well, there is not much we could do against other than working around that limitation (or bug, if you may want to put it that way) which we will do in future as you suggested. > A Recommends on httpd | apache2 | apache2-mpm-worker | > apache2-mpm-prefork | apache2-mpm-event | apache2-mpm-itk might > have solved the problem, but I don't think it is up to mailgraph > to know the internals of Apache packages. It is the job of Apache > packages to make sure that the transition is OK. Again, we do, unless you use packages in a way they are not meant to be used. > "Everyone else is supposed to..." without a Depends or Recommends? > That's insane! Well. I gave you the reason why this is problematic. I suppose Gnome users wouldn't like it if it would pull a web server listening on port 80 by default - don't you think? I agree that this is a borderline case to insanity (and not even my decision back then). but that's the way it is for Apache 2.2. Luckily we do not need to worry anymore as in 2.4 MPMs are regular modules and do not need a special treatment anymore. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation
severity 728937 wishlist tags 728937 pending thanks On 07.11.2013 03:08, Vincent Lefevre wrote: > Severity: grave > Justification: renders package unusable Your issue renders the package no way unusable, or "causes data loss, or introduces a security hole allowing access to the accounts of users who use the package". In fact, it's not even a bug since you installed a leaf package directly which is not meant to be used standalone. > I had the following problem when upgrading Ubuntu from 13.04 to 13.10, > and since Debian has more or less the same packages (stable & sid), I > think it can be affected too. Yet this is Debian, and not Ubuntu. I do not doubt your issue is in Debian, too but still it would be helpful if you verified your problem in Debian when reporting to a Debian bug tracker. > Installing tntnet as Recommends of mailgraph > Installing libcxxtools9 as Depends of tntnet > Installing libtntnet11 as Depends of tntnet > Installing tntnet-runtime as Recommends of libtntnet11 > > The mailgraph Recommends has in particular: httpd | apache2. which is perfectly acceptable, since that's precisely what the recommends line tells. If you believe this is a problem and apache should be pulled instead, report a bug against mailgraph. > As > the apache2 package wasn't installed on my machine (it is just > a metapackage with Apache 2.2, such as in Ubuntu 13.04 and the > current Debian stable, so that one can already have an Apache > server without this package), this can lead to the installation > of another web server such as tntnet via httpd. You can. But it's not supported. That use case is meant for people embedding Apache as embedded server into their binaries, such as gnome-user-share. Everyone else is supposed to install apache2. > Note: on this machine, I had apache2-mpm-itk installed, which had > "Provides: ..., httpd, ..." in the 2.2 version, but this line is > no longer present in the 2.4 version (the new apache2-bin package > has one and is eventually installed due to dependencies, but it > seems that apt can't figure this out early enough). Which means, this problem is one existing in apt/aptitude. > I don't know the best solution. Add a "Provides:" line to the > transitional packages (such as apache2-mpm-itk), which corresponds > to what apache2-bin now provides? > At least that seems not to cause problems, so I may add it for the next upload unless I find another unwanted side-effect. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717693: Bug#720591: apache2_invoke: configuration phpbb3 not supported in postinst
tags 717693 +patch +pending +moreinfo thanks Hi, On 28.09.2013 23:47, David Prévot wrote: > Seems like I’m able to reproduce this issue on upgrade too. If I’m not > mistaken, it seems related to #717693 ([im]possible to use > "apache2_invoke disconf" in postinst). That looks like a new behaviour. > apache2 maintainers, can you please confirm the issue? Should I look > into a workaround (any guidance is welcome)? Could either of you please test the patch I wrote [1]. I was not able to find a maintainer script triggering the issue easily, so that I fixed it without testing. Could you let me know if this fixes the issue for you? [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=commit;h=7bbd9734dcb2403505805301c94a6300d225f386 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#727182: apache2: config variables not defined on second reload
tags 727182 +moreinfo
thanks
Richard,
could you please tell us more about your environment? I cannot reproduce
your issue in a clean chroot. I suspect you have some (outdated)
configuration files in your installation, which have not been updated.
Could you also tell us what your output of
dpkg-query -f '${Conffiles}\n' -W apache2
is?
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
Re: apache2 wheezy backport
Hi, On 21.09.2013 23:27, Stefan Fritsch wrote: > That would be a rather large piece of work. It would be incompatible > with basically all apache modules and web-app packages in wheezy, so > those would need backporting, too. Considering that there is still > plenty of work to do in jessie, I don't think a backport will happen > anytime soon. I do not think this will _ever_ happen. An Apache 2.4 backport would trigger a massive chain of reverse dependencies which need a backport, too (we talk about 250+ packages here). This is a massive change of Wheezy which is not conforming to backport policies. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
On 07.08.2013 21:39, Julian Gilbey wrote: > On Sun, Jul 14, 2013 at 02:39:41PM +0200, Arno Töll wrote: >>> * The only way to ship a package named apache2.2-common is to add a >>>Breaks header listing every single reverse dependency with correct >>>version information. >> >> That would be 100+ Breaks. I do not think that is feasible but that may >> need a wider discussion. > > How did you reach that conclusion? I looked at the current testing > distribution, and the only direct dependency on apache2.2-common is > libapache2-svn, which may go away when subversion is able to > transition to testing. It's one now. :) It was the state as of Squeeze at the time I wrote this as we were in the middle of the transition. Now we can seriously consider doing the transition package approach. > Also, it is important to realise that without a dependency from > apache2.4 on apache2.2-common, apache2.2-common could be purged by > apt(itude) before the first apache2.4 package is even unpacked: > looking at my dpkg log, this is exactly what happened. So the > mechanism in apache2.2-common.postrm of checking for > /etc/apache2/upgrade-to-2.4-in-progress doesn't provide any benefit in > this case :-( Right. That's also why we do not use this trapdoor in maintainer scripts. > So it seems like having a dependency on a dummy apache2.2-common would > be the sensible (if annoying) thing to do. Thanks for this list. I'm short of time for the next 2-4 weeks, and unless sf beats me with it I will address all the outstanding Apache packaging issues then (or try to find a feasible solution at least). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#718789: apache2: upgrade wheezy -> testing (2.4.6-2) wiped out all of my log files
On 05.08.2013 16:26, Arno Töll wrote: > It's your responsibility if you use this option or apt's equivalent. > This is the same problem as #717476. Refer there too, why an > apache2.2-common package is problematic. err. #711925 I mean. #717476 is a duplicate of the same issue, too. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#718789: apache2: upgrade wheezy -> testing (2.4.6-2) wiped out all of my log files
severity 718789 important thanks On 05.08.2013 15:33, Julian Gilbey wrote: > Severity: serious > Justification: causes data loss Yes it does, and that's expected. Read the manpage from aptitude (for example): --purge-unused [..] THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING! It's your responsibility if you use this option or apt's equivalent. This is the same problem as #717476. Refer there too, why an apache2.2-common package is problematic. That being said we may just provide it to make these discussions finally (but possibly open a new can'o'worms). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:39, Vincent Lefevre wrote: > If users are allowed to disable these modules in compliance with the > policy, then you need to make sure that Apache still works in such a > case (e.g. for a personal website that doesn't need these modules). > The use of IfModule could be a solution. Try "apt-get remove bash" or "apt-get remove dpkg" and agree with the scary warning and see what works thereafter (no, don't do it for real). You will notice, you just broke your system badly without any safety net. The definition of an essential package is "do not remove it". If you still do, it's your business to deal with the situation. Same for these modules - however, I agree that we need to communicate this more prominently (again, see #709461). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:25, Ondřej Surý wrote: > Wouldn't > > Package: apache2 > Replaces: apache2.2-common (<< 2.4.0) > Breaks: apache2.2-common (<< 2.4.0) > > Solve the problem? That's what we do already (minus breaks). That allows us to overwrite and take-over conffiles from apache2.2-common. This works nicely and does what it is supposed to do - except in cases where people use --purge-unused because they think that's fun. In that case apt[itude] decides to purge all of /etc/apache2 entirely _before_ we have a deterministic chance to do look at the state, because apache2.2-common is going to be removed by upgrading to 2.4. I am not sure if an empty 2.2-common package in addition to that would solve that problem, as it would ship none of the conffiles either, so consequently they would still be purged. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:16, Ondřej Surý wrote: > could you please rethink the idea of re-adding apache2.2-common with > version Breaks: on all reverse depends (with versions from wheezy, the > jessie can be handled by filling RC bugs case-by-case). Yes, we did not definitely decide on that. It is, however, not going to solve this bug in particular as the conffiles would have to move regardless from apache2.2-common to apache2 which is the root cause with --purge-unsued. It may solve other problems you have though, e.g. your pre-depdency in PHP and so on. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:02, Vincent Lefevre wrote: > Then wouldn't it be possible during an upgrade of some packages > (e.g. apache2, apache2-doc) to make sure that these modules are > enabled, and re-enable them if they aren't? As said, unless due to a bug, these modules are always enabled. However, some people might still prefer to disable them by free choice and that's something we have to respect in compliance with the policy and in hope these people know what they are doing. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
Hi, On 25.07.2013 11:52, Vincent Lefevre wrote: > thus depends on the alias module being there, but the dependency > is not enforced anywhere. What if for some reason the alias module > gets disabled in the future? Shouldn't a IfModule directive be used > in order to avoid the full Apache server being down just because of > apache2-doc? There is a certain trade-off to take. We consider some modules crucial for a functioning web-server which shall be enabled on any site. The alias module is one of them. These modules are documented in our PACKAGING policy. This is the same principle as Debian as a whole applies to essential packages, such as dpkg and others. There is no need to express such dependencies explicitly because it is assumed the condition is met on any functioning system. > And some way to warn the admin when the alias module is disabled > (but when the problem occurs, looking at the apache2-doc config > gives the answer). Yes. See #709461. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 24.07.2013 22:47, Stefan Fritsch wrote: >> The bug in apache2 is that we still treat this situation as an >> upgrade in the postinst even if there is nothing left of the old >> install. If we can detect it, we should probably treat it as a new >> install instead. I do not think we could in a deterministic way. We might be able to guess based on certain heuristics, like no conffiles whatsoever but the apache packages being installed. However, I am sure this will bite others who deliberately rm'ed all of /etc/apache2 because they think our configuration sucks anyway. > > We could also add a check to apache2.2-common's prerm to detect the > purging during an upgrade and abort, and get that change into wheezy > in a point release. However, only people who have upgraded to the > latest version will benefit from that change. And I am not sure that > this is a good approach in any case. Not sure about the goodness of that approach either, but that's certainly possible. I am not sure how you would like to detect this situation though? Alternatively we could enforce the modules being installed regardless of it being an upgrade or not (though this might be a debatable choice in view of policy correctness) or get apt[itude] maintainers to display a warning when using --purge-unused during a dist-upgrade. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: apache2.2-common still in sid - maybe manual decrufting needed?
On 24.07.2013 16:13, Andreas Beckmann wrote: >> So your problem should be gone now. > > So you could get a few new bug reports tomorrow :-) "Yay" -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51efe203.4000...@debian.org
Re: apache2.2-common still in sid - maybe manual decrufting needed?
Hi, On 24.07.2013 12:11, Andreas Beckmann wrote: > the package apache2.2-common (2.2.22-13) is still in sid ... but I > couldn't find a good explanation why. The source package apache2 > previously providing it has been successfully rebuilt on all > architectures ... I bribed paultag to have a look at it, and he confirmed it was removed by him yesterday: https://ftp-master.debian.org/removals.822. So your problem should be gone now. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 24.07.2013 13:54, Norbert Preining wrote: > Removal does not work easily, since gnome depends on apache2. Gnome depends on apache2-bin which works fine without apache2 and any configuration file as they are all in apache2. > So how should I know what modules etc should be active and what not? > How should I (and other people) go tback to a working configuration? How did you upgrade? Did you use --purge-unused or whatever the equivalent for apt is? As I say, in a regular upgrade in a unmodified build chroot your issue does not appear. > I would already be happy if you could send a list of modules/conf > that should be linked. for module in authz_host auth_basic access_compat authn_file authz_user \ alias dir autoindex \ env mime negotiation setenvif \ filter deflate \ status ; do a2enmod -m -q $module done -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
enabled by unknown) filter (enabled by maintainer script) unique_id (enabled by unknown) root@build:/# apachectl configtest Syntax OK -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717610: [php-maint] Bug#717610: a second run of aptitude safe-upgrade clears it
On 23.07.2013 12:29, Ondřej Surý wrote: > Control: reassign -1 apache2 > Control: retitle -1 apache2-maintscript-helper doesn't support dpkg triggers Yep, thanks. That is it. Did you recently enable triggers for your maintainer script so that the 2.4.6-1 upload is just coincidence? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80
Hi, On 21.07.2013 17:32, Edward Welbourne wrote: > Even though I > actually have a NameVirtualHost in my enabled sites-available file, > matching exactly the same file's VirtualHost parameter, my configuration > was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing > about. > ... > Given that the directive lives in a user-configurable file > and *must* exactly match the NameVirtualHost directive, it strikes me > that the old way, having the later also in the user-configurable file, > was a better approach than the present, where the user must - in fact - > edit a file that's not in sub-directory in which user-configuration > normally takes place. If there's genuinely a compelling reason to put > the NameVirtualHost somewhere other than *right next to* the > directive (as I'm fairly sure it used to be), where it'll > be obvious that they need to stay in sync, please add a comment to > default, immediately before the directive, saying "be sure > to keep ports.conf's NameVirtualHost in sync; the host:port must match > exactly". First, let me point out that also ports.conf is a user-configurable file. You can safely edit and adapt it to your needs. That what it is meant for. Having NameVirtualHost in 000-default though is dangerous, at is a directive being _shared_ across virtual hosts. It is used by all sites, including but not limited to the default site. Assuming you deactivate the default site, this causes undefined and broken behavior if you have other name based virtual hosts. This is a major problem lots of Debian users stumbled upon over the years. Thus, we're more than glad and very happy NameVirtualHost is no more in 000-default.conf and we are definitely not going back that road. That being said please note, that NameVirtualHost itself is deprecated and not used anymore in Apache2 2.4. There is no chance to fix this in Debian Stable anyway due to our freezing policy, and the next Debian release will have Apache2 2.4 only, not using NameVirtualHost at all anymore. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717448: apache2: Invalid command 'AuthType'
reassign 717448 phpmyadin thanks On 21.07.2013 03:59, Jean-Michel Vourgère wrote: > Try > $ a2enmod authn_core > It fixes the same problem here. "AuthType" is provided by authn_core in httpd 2.4 and no longer provided by the core module. As such, it is not available unconditionally in a apache2 2.4 installation. Packags must not use such directives without protecting them with . Please see our packaging guidelines at [1]. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=master#l194 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: apache2.4 transition
On 20.07.2013 13:53, Lior Kaplan wrote: > Are we still waiting for some dependent packages or we can close this issue We are. Please see [1]. Colin NMUed most of the outstanding packages, and we will discuss together with the Release Team when to migrate to Testing once the NMUs are beyond their 10 day waiting period. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=apache24transition;users=debian-apache@lists.debian.org;archive=both -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Bug#707024: apache2.4 transition
On 20.07.2013 13:53, Lior Kaplan wrote: > Are we still waiting for some dependent packages or we can close this issue We are. Please see [1]. Colin NMUed most of the outstanding packages, and we will discuss together with the Release Team when to migrate to Testing once the NMUs are beyond their 10 day waiting period. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=apache24transition;users=debian-apache@lists.debian.org;archive=both -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
On 14.07.2013 12:38, Helmut Grohne wrote: > My point was that if modules had their dependencies satisfied in such a > way, then dependencies are wrong even for a wheezy -> jessie upgrade, > because as you later point out it would break the whole server. They are wrong and this can get really nasty. I don't know who introduced them this way back then but they hurt us now. > * The only way to prevent apache2 configuration from being purged >during upgrade is to keep shipping a package named apache2.2-common >and to have apache2 depend on it. I am not sure this is the only way. Possibly it could be the other way around and transition from apache2.2-common to apache2 through a transitional package. > * The only way to ship a package named apache2.2-common is to add a >Breaks header listing every single reverse dependency with correct >version information. That would be 100+ Breaks. I do not think that is feasible but that may need a wider discussion. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
On 14.07.2013 12:08, Helmut Grohne wrote: > I do not see how the transition is affecting this option. If it breaks > during the transition, it can also break a partial upgrade. Introducing > apache2.2-common later can cause a broken wheezy->jessie upgrade when a > user fails to upgrade the corresponding apache module. Is this correct > or am I missing something? Pretending we provided apache2.2-common, modules depending on the 2.2 version of the server had their depdencies satisfied. Thus, they would be co-installable with Apache 2.4, they would migrate to Testing and so on. However, if you try to enable such a module, it breaks the whole server which fails to start as there will be symbol lookup errors at runtime. We could possibly discuss your suggestion as soon as nothing in Debian depends on apache2.2-common anymore, but for now that just adds more havoc. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
Hi, On 14.07.2013 09:47, Helmut Grohne wrote: > As far as I can tell the only way to fix this issue is to introduce a > transitional apache2.2-common package containing no files. apache2 would > need to depend on apache2.2-common for one release (skipping a release > is not supported). we cannot do this as long as the transition is ongoing. Sadly lots of packages reverse-depends on on apache2.2-common. Satisfying this dependency would create (even more) havoc on such systems as apt would not force a removal of packages depending ob not provided ABIs. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e2747f.7010...@debian.org
Re: Team maintenance of more Apache modules?
Hi Colin, I appreciate your efforts. It was me, as a main driver of this transition to be responsible for causing you all this work. Sorry about all of this, but I'm deeply impressed on all the good work you spent to patch upstream's code. On 13.07.2013 12:43, Colin Watson wrote: > To me, this suggests that many of these packages would benefit from team > maintenance. [..] but there are plenty of source packages that only > build an Apache module. The contrast with the Haskell team which I > joined recently (almost all team-maintained, very high degree of > packaging consistency, lots of tools, amazingly low bug-to-package > ratio) has been pretty striking to me, and it suggests possible > improvement. Any _working_ team is without doubt an improvement. However, as you pointed out yourself, many modules had no love for years which implies some lack of interest to have them maintained properly. Just having a team umbrella around does not attract more interest on these modules, and the only thing being worse than a single maintainer not caring is a whole team not caring in hope someone else will do. > I don't mean to diss the maintainers involved; it's just > that there are obvious economies of scale here. The Apache 2.4 porting > work has been pretty formulaic for the most part, and no doubt there'll > be an Apache 2.6 in the future and we'll get to do it all over again. True. That being said I hope it will be less painful for the changes we introduced with 2.4 (depending on API versions, packaging helper, consolidated maintainer script handling etc.) > Depending on what the Apache server maintainers are > amenable to in terms of access control and bug mail on > debian-apache@lists, we could either use the existing pkg-apache Alioth > project or start a new pkg-apache-modules project. We could start with > libapache2-mod-auth-plain, which is currently orphaned, but it'd be nice > to have a few more. As an Apache maintainer, I welcome any effort resulting in a *working* team, and I see no problem to use debian-apache@l.d.o for that purpose. I might even join that team. ;-) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#713967: apache2-bin: daemon doesn't close all fds on fork - which causes postinst with debconf to hang
unblock 661958 by 713967 thanks > Hey Apache2 Team, > this is also an 2.4 transition blocker in my eyes. > Please correct me if I'm wrong! I'm not even sure this is a bug at all. Beyond, it is definitely not a blocker for the Apache transition, or let me rephrase: This list of blocking bugs is not what you think it is meant for. The list of blocking bug is only for coordination with the Release Team and is not related to criteria qualifying for the transition to happen or not (it started already anyway). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 11.06.2013 10:41, Norbert Preining wrote: > Hi Arno, > > On Di, 11 Jun 2013, Arno Töll wrote: >> Thus, either mod_alias was disabled by you, or not enabled on your >> system for some other reason (which then might be the "real" bug). Could >> you help us on that and tell us more? > > I didn't do anything to apache configurations at all, how can I check > and let you know? What does "a2query -m" give you? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
severity 711925 important thanks On 11.06.2013 05:16, Norbert Preining wrote: > # env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin /usr/sbin/apache2ctl > configtest > AH00526: Syntax error on line 1 of /etc/apache2/conf-enabled/apache2-doc.conf: > Invalid command 'Alias', perhaps misspelled or defined by a module not > included in the server configuration > Action 'configtest' failed. > The Apache error log may have more information. we enable mod_alias unconditionally in postinst of apache2. Just like "essential" packages in Debian we allow people (and so ourselvses) to use directives from this core set unconditionally. Thus, either mod_alias was disabled by you, or not enabled on your system for some other reason (which then might be the "real" bug). Could you help us on that and tell us more? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711636: apache2: Init script fails if other Apache processes are running
Hi Dominic, On 08.06.2013 14:49, Dominic Hargreaves wrote: > In this case this was a sid chroot running on an underlying system with > Apache installed and running, but I imagine the same could be > true if Apache is running on the same chroot too. what would you imagine to do? I am not sure what we could do in cases where another daemon, within or outside the chroot, binds to the same listening interface already? In that case it is expected that the init script fails, because apache2 itself fails to start. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711534: Disabling strtoul violates C89 and C99 and is unnecessary
severity 711534 important thanks On 07.06.2013 17:20, Matthew Vernon wrote: > i.e. apache intentionally breaks strtoul, a function defined in C89, > C99, SUS, etc. And SunOS 4 has been unsupported by Sun since 2003. Point taken, but this is not a serious issue. I will fix it regardless for the next upload to Sid, but I don't think we are going to change it for Wheezy, but I let this up to sf to decide. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711120: init script is silent
Hi Joey, On 04.06.2013 22:45, Joey Hess wrote: > The init script no longer outputs anything when starting or stopping the > daemon. This is rather disconcerting when one is trying to restart > apache to deal with massive changes to the configuration system. (It's > also probably a policy violation.) looks like you hit a bull's eye here. See #710519, #683654 and #710571. For now I'll make the script (a bit) more verbose by default and let people come up with whatever they decide on a project-wide basis and implement that later. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711493: No default site enabled after fresh (re)install
Hi Michael, On 07.06.2013 10:48, Michael Biebl wrote: > since something went wrong during the upgrade (I've purged the > transitional packages during the upgrade process, leading to a > misconfigured apache configuration), I've decided to purge and > re-install apache2. After the upgrade, I had not default site enabled. I cannot reproduce this in a clean chroot. > This is the purge and install log: > Btw, should this be considered a separate bug, that the /var directories > are not cleaned up on purge? Depends on your point of view. I don't think so. You purge Apache related packages, but you leave back reverse dependencies (e.g. you still had mod-dnssd and php5 installed). These are left in config-file state, and thus let back the conffiles they install into "our" directories. Logs, however, are deliberately not purged. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711127: apache2.2-bin transitional package (binaries only) should not depend on apache2 package (which runs a system daemon)
Hi, On 04.06.2013 23:39, Josh Triplett wrote: > (I debated whether to open this as grave or just important, but I don't > think the new transitional package should transition to testing with > this bug present.) It won't do so anyway. We prefer a coordinated rush together with our reverse dependencies. See #707024. I don't think this is grave, to be honest. > The apache2.2-bin package formerly supplied only the binaries for the > Apache web server, and notably did *not* run a systemwide apache daemon. > However, the new apache2.2-bin transitional package depends on both > apache2-bin (the equivalent binaries-only package) and apache2 (the > system daemon package). Please don't do that; that will cause systems > with only apache2.2-bin installed to suddenly end up with a running > system web server after upgrade. Yes, you raise a valid point. However, I'm pretty sure we did this on purpose back then. Sadly I don't remember details anymore as this transition was originally meant to happen for Wheezy. I think this was somehow related to the MPM packages disappearing. I am going to test this again and let you know. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#710934: apache2: please include a way to automatically move conf.d files to conf-available
Hi Brian, On 03.06.2013 19:36, Brian Minton wrote: > To ease the transition to apache 2.4, could you have a script that > automatically copies files in /etc/apache2/conf.d to > /etc/apache2/conf-available? you can use dpkg-maintscript-helper doing that for you. See dpkg-maintscript-helper(1) or dh_installdeb(1) if you are using debhelper. Doesn't that work good enough? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: Do not migrate to Testing
severity 707024 serious thanks Apache 2.4 is not supposed to enter Testing yet. That breaks lots of stuff. Let's rather rush in once much more modules are ported. Hence, making this bug serious so that Britney does not consider letting us in. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: failed kfreebsd-amd64 build of apache2 2.4.4-4
Hi, On 31.05.2013 00:00, Debian buildds wrote: > * Source package: apache2 > * Version: 2.4.4-4 > * Architecture: kfreebsd-amd64 > * State: failed > * Suite: sid > * Builder: fayrfax.debian.org > * Build log: > https://buildd.debian.org/fetch.cgi?pkg=apache2&arch=kfreebsd-amd64&ver=2.4.4-4&stamp=1369951173&file=log JFYI: We're aware of this problem and this is nothing you need to triage if you feel like fixing porting problems. This is not to worry about it. -lcap is Linux only and is needed for mod_itk. It was definitively broken before but nobody noticed until now because of #702475. However, itk is going to disappear soon from our source so that this is not a serious problem to be addressed. We may do something akin to http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=commitdiff;h=2dd95f8ef64dd68b2acf55c1d1b98637fbb98903 in a way it applies to kfreebsd, too. This leaves itk broken in the package, but I guess that's something we can live with for the time being. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#706822: just make it quiet
On 26.05.2013 06:50, Adam Borowski wrote: > What about just removing the error message, at least when ran from a > logrotate cronjob? What would you suggest? I'm not at all opposed in a patch pleasing all of you, but I don't know one making all of you happy which is not only hiding problems. (err, actually resending my response to the bug and not to the list) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Bug#706822: just make it quiet
On 26.05.2013 06:50, Adam Borowski wrote: > What about just removing the error message, at least when ran from a > logrotate cronjob? What would you suggest? I'm not at all opposed in a patch pleasing all of you, but I don't know one making all of you happy which is not only hiding problems. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#709461: Warn when disabling core modules in a2dismod
Package: apache2 Severity: wishlist For my own remembering: a2dismod should warn when users try to disable modules we enable by default, as we allow packages to use statements from it unconditionally. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: Apache 2.4 upload date scheduled for May 30
Hello fellow maintainers, we are ready to upload Apache2 2.4 to Debian Sid now. This means the transition is effectively starting now, and going to break your modules. We have scheduled the upload for May 30, 2013 BEFORE the 19:52 UTC dinstall on ftp-master. To minimize the breakage to our Sid users, we'd ask all of you having a transitioned package ready in Experimental, to make an upload to Sid AFTER the 13:52 UTC dinstall, and BEFORE 19:52 UTC [1]. Let us know if you need a sponsor, or our help to upload your packages in that time window. Please note, you could also use the DELAYED queue to make timed upload [2]. [1] http://ftp-master.debian.org/#dinstall [2] http://ftp-master.debian.org/deferred.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: Bug#661958: Reboot Apache2 2.4 transition
Hi, On 13.05.2013 10:51, Ondřej Surý wrote: > I can ack that PHP 5.5 RC1 is prepared to enter the unstable. > This will also trigger the libgd and php5.5 transitions. jcristau and me wondered if you want us to wait until you have a libgd package ready? There seems to be some discussion going on on d-devel related to that. Could you please clarify? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: Bug#661958: Reboot Apache2 2.4 transition
Hi, would the Release Team be comfortable with an upload of Apache 2.4 to Sid on May, 20? That's a bit sooner than I expected, but on the other hand there is not much to gain to wait longer. We made good progress with our list of critical reverse dependencies so that only one is missing. Hence I believe, an upload on that date is feasible. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#681545: apache2-dev: dh_apache2 postinst action should run during more actions
tags 681545 pending thanks Hi, along with the fix for #681546 I also changed the behavior for postinst. It's called unconditionally now in postinst, as we disable the module in prerm now, so that we need to cover the rollback case again. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#681546: apache2-dev: consider having dh_apache2 dismod in prerm, not postrm
tag 681546 pending thanks Hi Russ and Ondřej, > I'm not sure whether it would be safer to run > this action only on remove or deconfigure, or to run it on any action other > than upgrade and failed-upgrade. I felt safer to opt for this alternative. That is, I execute the disable code for "remove" and "deconfigure" in prerm now. If you have time, please have a look at the new maintainer scripts (in git) and test. Let me know if you find more problems with it. I hope this fixes your problem as your absolutely right, and we should disable the module in prerm, not postrm. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707109: apxs2 outputs "uninitialized value" warnings
tags 707109 pending thanks Hi, > $ apxs2 -q LIBEXECDIR > Use of uninitialized value $includedir in concatenation (.) or string > at (eval 9) line 1. > /usr/lib/apache2/modules I've just commited a fix to our 2.4 branch fixing the problem. Thanks for noticing. I don't think we're going to fix that for Wheezy though, as the problem is noisy but harmless. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#633897: apache2.2-common: a2enmod does not care for dependencies for authz_svn
reassign 633897 subversion thanks Hi, > Some of the modules have mutual dependencies. > E.g. authz_svn depends on dav_svn depends on dav. that's right. Some modules have such dependencies. They can be expressed in module load files by maintainers of the respective modules. Thus, in this case subversion maintainers should make sure dependent modules are declared as dependency in their module .load file. In some rare cases there are load order dependencies which could be worked around upstream, but if that's not possible we have a documented policy how to handle this in our PACKAGING guide [1]. Our guide should suffice to cover this case, hence I'm reassigning to subversion maintainers providing your modules in question. Please reassign back if the maintainers think this should be addressed in a2enmod (I disagree though). [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=next#l79 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Jonathan, we're approaching Sid so I'm coming back to your bug. Do you have any suggestion what you'd like to read in the NEWS file? As I read the remaining discussion of this bug, I think everything else was clarified already, right? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#702475: Bug#707879: apache2: mod_mpm_itk.so: undefined symbol: cap_set_proc
forcemerge 702475 707879 thanks Hi Ángel, On 12.05.2013 00:12, Ángel González wrote: > mod_mpm_itk.so wasn't linked using -lcap ? Right. See #702475 as this bug is a duplicate of that. There is also a workaround noted. Having that said, fixing this is not a high priority as we are likely to split out the itk package soon, so that the issue can be addresses properly there. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#681544: apache2-dev: provide dh_apache2 option to avoid enabling module by default
tags 681544 +pending thanks Hi Russ, On 13.03.2013 02:44, Russ Allbery wrote: > Sure, yes, that would be fine. I'm not sure what I was thinking of when > it came to the *.load configuration. There's no need to change the *.load > files, of course; all this would affect is whether the module was enabled > by default. as promised, I implemented a switch. The next upload will feature a dh_apache2 which has a -e|--noenable option which does not install postinst hooks, but lets others untouched. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: mod_security2 is ready
I've prepared a working patch for mod_security. It is ready to be NMUed unless the maintainer steps in. The patch is in #666848. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: Acknowledgement (Transition coordination bug)
As a follow-up: - PHP is ready in experimental - JK is ready in experimental - mod-dnssd has a patch - mod-wsgi has a patch -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: Transition coordination bug
Source: apache2 Version: 2.4.4-2 Severity: wishlist This is a transition coordination bug. According our plan formulated in #661958, these packages need to be transitioned before we can upload to Sid. - mod_php (#666820) - mod_security (#666848) - mod_wsgi (#666818) - mod_dnssd (gnome-user-share; #666829) - mod_jk (#666851) - mod_fcgid (#666863) - subversion (#666794) Let's track progress here. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#706822: default behavior of setting ulimit
Hi Kiro, On 05.05.2013 12:00, Kiro Zimmer wrote: > I think the default > behavior > should be changed to not set the ulimit by default. thing is, we can't just please everyone. We recently enabled this because people asked for it. Please see #615632 > My temporary dirty workaround is to change /etc/apache2/envvars to > APACHE_ULIMIT_MAX_FILES='sleep 0.01' You could just set it to "true" or whatever other no-op. Just make sure it's defined (i.e. non-zero). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#704639: apache2: typo in mpm_event.load
tags 704639 +pending thanks Hello Bastian, thanks for spotting and your patch. I've just committed it to git and we'll feature it in the upcoming 2.4 upload. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#703408: apache2: Segmentation fault running TYPO3 on wheezy
reassign 703408 libapache2-mod-php5 thanks On 19.03.2013 10:32, Christian Blank wrote: > [Mon Mar 18 22:14:28 2013] [notice] child pid 4962 exit signal > Segmentation fault (11) This is your PHP dying. > There are still apache-processes running, but the website is empty. > After restarting apache, it works again for a few days. > I can't reproduce this Problem with a specific site or php-function. I'm > not sure, if this is problem is > caused by apache, php or apache-mod-php It's most likely mod_php5. Please read README.backtrace to provide more useful debugging information to PHP maintainers. Please reassign back to Apache2 in the unlikely case the backtrace reveals a problem in a core module. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#703121: apache2: Apache2 ignores/overwrites UMASK setting of pam_umask
Hi, On 16.03.2013 00:33, Michael Herold wrote: > Right now I don't see any reason why it is not sufficient that files > created by www-data are readable by others then www-data per default. Frankly I'd urge you to use another user for scripts. Do not let your server side scripting languages run as www-data, but let them run as their own user. If you have several virtual hosts that's required, otherwise a script vulnerability in one vhost causes security implications to the remaining hosts, because an attacker can access that data. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#703121: apache2: Apache2 ignores/overwrites UMASK setting of pam_umask
Hi, On 15.03.2013 21:11, Michael Herold wrote: > Package: apache2 > > I am running a server with a 'UMASK 027' setting in /etc/login.defs and > pam_umask enabled. This leads to a default umask of 027 for all shell > users. However I also expect the apache2 to run with this umask. /etc/login.defs is for shell users, however the web server is started as root and drops privileges after binding to the socket. Thus, this is a expected behavior, given the Apache's parent process is init (PID: 1). > Apache always runs with a umask of 022 causing cgi-scripts to create new > files with rather generous permissions. This also implies that there are > debian packages which expose private uploads to all users in /tmp/ with > default settings. The behavior has been produced with fcgid and mod_php > under squeeze and wheezy. You can override the default umask by configuring /etc/apache2/envvars. If you prfer, it also works to override the umask in /etc/init.d/apache2 which will be inherited to Apache. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#702866: mod_authn_core not enabled by default
On 12.03.2013 10:37, Thijs Kinkhorst wrote: > mod_authn_core is not enabled by default. This module makes common directives > like AuthType work. Also, other authn_* types are enabled by default. Stefan, do you remember why we didn't enable this module when discussing the default modules? Did we have a good reason which I simply forgot? Otherwise I may fix it by enabling the module as Thijs suggests. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
tags 702475 experimental notfound 702475 2.2.22-12 thanks On 08.03.2013 18:46, Andrey Rahmatullin wrote: > On Thu, Mar 07, 2013 at 12:55:39AM +0100, Arno Töll wrote: >> While testing the 2.4.4 upload I noticed the ITK MPM does not load anymore, >> because it is underlinked despite of -lcap being there and used. > In 2.4.4-1 i386 build logs -lcap is not used for mod_mpm_itk.la. > ... but it is used for regular modules which are linked with apr. Looks like the (itk) MPM link command line ignores EXTRA_LIBS which contains -lcap. Looking to our older build logs, it looks itk was never linked with -lcap for 2.4. Sesse, do you want to fix that? Alternatively we could wait until 2.4.5 is released which might contain all patches you require for your most recent itk patch. That would allow us to build itk with apxs without patching the Apache source, possibly even in a separate source package. That might be worth a discussion as well. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: apache2_2.4.4-1_amd64.changes REJECTED
On 07.03.2013 01:02, Debian FTP Masters wrote: > Version check failed (binary=libapache2-mod-proxy-html, version=2.4.4-1, > other-version=3.0.1-1.1, suite=unstable) Oh, never mind. I guess you are trying to tell me that libapache2-mod-proxy-html from unstable has a newer version. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: apache2_2.4.4-1_amd64.changes REJECTED
Hi, On 07.03.2013 01:02, Debian FTP Masters wrote: > Version check failed (binary=libapache2-mod-proxy-html, version=2.4.4-1, > other-version=3.0.1-1.1, suite=unstable) sorry, what? The upload was targeting experimental. Date: Wed, 06 Mar 2013 00:24:15 +0100 Source: apache2 Binary: apache2 apache2-data apache2-bin apache2-mpm-worker apache2-mpm-prefork apache2-mpm-event apache2-mpm-itk apache2.2-bin libapache2-mod-proxy-html apache2-utils apache2-suexec apache2-suexec-pristine apache2-suexec-custom apache2-doc apache2-dev apache2-dbg Architecture: source amd64 all Version: 2.4.4-1 Distribution: experimental Urgency: low Maintainer: Debian Apache Maintainers Changed-By: Arno Töll Description: ... libapache2-mod-proxy-html - Transitional package for apache2-bin - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
Package: apache2 Version: 2.4.2 Severity: serious While testing the 2.4.4 upload I noticed the ITK MPM does not load anymore, because it is underlinked despite of -lcap being there and used. I don't know enough about the ITK MPM to know where the problem exactly is. Trying to load їt yields: apache2: Syntax error on line 139 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/mpm_itk.load: Cannot load /usr/lib/apache2/modules/mod_mpm_itk.so into server: /usr/lib/apache2/modules/mod_mpm_itk.so: undefined symbol: cap_set_proc I could reproduce this problem on both, 2.4.2-2 and 2.4.4-1 so our changes in the ITK patch are unlikely the cause. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.6-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130306235539.7094.53983.reportbug@snowball
Bug#681544: apache2-dev: provide dh_apache2 option to avoid enabling module by default
Hi Russ, On 14.07.2012 05:06, Russ Allbery wrote: > A nicer mechanism would be to allow the *.apache2 configuration file > have an option for mod *.load lines saying not to enable the module > by default. I think, we should rather stick with a specialized dh_apache command line argument, say dh_apache2 --no-start-by-default or whatever instead of adding even more complexity to .load files. Does that sound acceptable to you? Moreover, we planned to let the maintainer give a local policy on that regard. I could imagine a variable in /etc/default/apache2 determining the web server reload behavior. In fact, that's quite the point to abstract the module load behavior through our wrapper script, although such policies are not implemented yet. > If the module is enabled, then Apache should still be restarted on > upgrade (or other configuration actions). If the module is not > enabled or wasn't previously installed, nothing should be done by > default in postinst. The postrm handling would remain the same. We do so, don't we? At least we wrote code which should do right that, but it might have bugs of course :> -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#681545: apache2-dev: dh_apache2 postinst action should run during more actions
Hi Russ, I'm finally coming back to the dh_apache issues you filed long ago. > I believe you should therefore just remove this conditional and run this > code in postinst unconditionally. Your explanation sounds right to me. However, we do not unconditionally disable the module either. We only do so in case of postrm purge|remove to ensure the web server is not reloaded without need. This makes the abort-upgrade|abort-remove|abort-deconfigure operations a no op with respect to Apache maintainer scripts. Our goal should be to minimize the impact of an upgrade. Many people tend to be annoyed when the web server is restarted during upgrades. Hence, I do believe "configure" is correct, but I might try some of the abort/failure cases you mentioned before deciding what to do eventually with your bug. Does my explanation make sense to you? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#701117: Fwd: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing
Original Message From: christo...@guilloux.info Fri Feb 22 00:16:41 2013 Return-Path: X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id DBAA4164090; Fri, 22 Feb 2013 00:16:40 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smart.knallkopp.de X-Spam-Level: * X-Spam-Status: No, score=1.3 required=3.0 tests=RDNS_NONE autolearn=disabled version=3.3.1 X-policyd-weight: using cached result; rate: -5.5 Received: from master.debian.org (unknown [82.195.75.110]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id 442F0164059 for ; Fri, 22 Feb 2013 00:16:39 +0100 (CET) Received: from srv002.dedinux.com ([46.105.37.180]) by master.debian.org with esmtp (Exim 4.80) (envelope-from ) id 1U8fNW-0006tv-Tn for deb...@toell.net; Thu, 21 Feb 2013 23:16:38 + Received: from localhost (localhost.localdomain [127.0.0.1]) by srv002.dedinux.com (Postfix) with ESMTP id 6A38E2C0579 for ; Fri, 22 Feb 2013 00:16:33 +0100 (CET) X-Virus-Scanned: spam & virus filtering at Received: from srv002.dedinux.com ([127.0.0.1]) by localhost (srv002.dedinux.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OzGGWBjbcLBs for ; Fri, 22 Feb 2013 00:16:33 +0100 (CET) Received: from srv002.dedinux.com (localhost.localdomain [127.0.0.1]) by srv002.dedinux.com (Postfix) with ESMTP id 085152C376C for ; Fri, 22 Feb 2013 00:16:33 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 22 Feb 2013 00:16:33 +0100 From: Christophe GUILLOUX To: Arno Töll Subject: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing In-Reply-To: <51268e3f.7090...@debian.org> References: <0f6a07fa3ffe54e44a2738c4f5071...@srv002.dedinux.com> <51268e3f.7090...@debian.org> Message-ID: X-Sender: christo...@guilloux.info User-Agent: Roundcube Webmail/0.7.1 Le 2013-02-21 22:14, Arno Töll a écrit : > On 21.02.2013 20:26, Christophe GUILLOUX wrote: >> This bug is affecting debian wheezy, some browser can be affected >> and >> other not (because they interpret the page as a html by default) : >> https://issues.apache.org/bugzilla/show_bug.cgi?id=48357 > > I am not sure how your description matches the bug you mentioned. The > bug you linked is about custom error page handling when clients > violating the HTTP 1.1 protocol are requesting pages. > > Do you mind to explain? Sorry, I don't understand the entire second sentence. I think apache should respond with header even if the client sent a bad request. RFC is too long but i suppose they write that server must respond : HTTP/1.1 400 Bad Request ... and not directly the html or text. For example, i do : telnet alioth.debian.org 443 Trying 217.196.43.134... Connected to alioth.debian.org. Escape character is '^]'. GET / HTTP/1.1 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://alioth.debian.org/";>https://alioth.debian.org/ Apache/2.2.16 (Debian) Server at alioth.debian.org Port 443 Connection closed by foreign host. I think it miss this before the html response: HTTP/1.1 400 Bad Request Date: Thu, 21 Feb 2013 23:13:29 GMT Server: Apache/2.2.16 (Debian) Vary: Accept-Encoding Content-Length: 309 Connection: close Content-Type: text/html; charset=iso-8859-1 It seems that the problem appear only when client do a clear request on a SSL port. -- Cordialement, Christophe GUILLOUX -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5126b0e2.2070...@debian.org
Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing
On 21.02.2013 20:26, Christophe GUILLOUX wrote: > This bug is affecting debian wheezy, some browser can be affected and > other not (because they interpret the page as a html by default) : > https://issues.apache.org/bugzilla/show_bug.cgi?id=48357 I am not sure how your description matches the bug you mentioned. The bug you linked is about custom error page handling when clients violating the HTTP 1.1 protocol are requesting pages. Do you mind to explain? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#701118: libapache2-mod-fastcgi missing
severity 701118 wishlist reassign 701118 libapache2-mod-fastcgi thanks Hi, On 21.02.2013 20:40, Christophe GUILLOUX wrote: > Package: apache2 > Version: 2.2.22-12 > Tags: wheezy > Severity: grave How does your problem "make[s] the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package"? > Some people actually in squeeze use this package because it is working > like a proxy to a fastcgi server (FastCgiExternalServer). > If they upgrade to wheezy, their application stop working without any > workaround (they can delete apache and use nginx in place but it is not > the question here). What's your point? mod-fastcgi is a third party application not shipped with the Apache core package and never was. In fact, mod_fastcgi does not even have the same upstream. Thus, this is not a bug in the Apache package itself and you're yelling at the wrong address. We, as Apache maintainers cannot change anything here. Moreover, I don't understand your problem after all. mod_fastcgi is still in Wheezy [1] and you don't need mod_fastcgi at all in order to run PHP-FPM with mod_fcgid. > There is two solution : compiling this module or upgrading apache to a > recent version because there is a proxy module > (http://httpd.apache.org/docs/2.4/fr/mod/mod_proxy_fcgi.html) or if you > can, compile this module with apache 2.2.22 which is obsolete :-( > > 2.2.22: Released January 31, 2012 > 2.4.2 : Released April 17, 2012 (before wheezy freezing) Sorry, what? > Other bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592937 > [1] http://packages.debian.org/source/testing/libapache-mod-fastcgi -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#645460: apache2.2-common: /etc/init.d/apache2 start and restart need to wait until really started
Hi, On 30.01.2013 15:39, Nerijus Kislauskas wrote: > It makes lsb:apache2 unusable on pacemaker clusters. this is a known problem. I tried to address this problem partially in our upcoming Apache 2.4 tree, but since complex init scripts such as Apache's are error prone, we decided not to backport my improvements to 2.2. Could you try the new init script [1] and tell me if it fixes your problem? There I wait until the server is stopped, start is left as is so far. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.init;h=130c0f533d18abea263622dbd2673f134989b5ad;hb=refs/heads/next -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#698967: apache2 default conf file contains Listen directive
Hi, On 25.01.2013 21:30, Thomas Ward wrote: >> however if the default site is removed or moved to another port, >> Apache continues to listen on that port. For example, if Apache listens on >> Port 80 and you change the default site to listen on port 1080, Apache will >> listen on Port 80 and Port 1080 due to the Listen directive in ports.conf. I am not sure to follow here. If you change the desired port through the listening port is /not/ affected (see also upstream docs [1]). That means, if you wanted to change that behavior you'd need another Listen directive anyhow, regardless what you configured in your default site where Apache shall listen. Admittedly you don't need to use ports.conf for that, but you need to add it somewhere. While you're at it, you could use ports.conf for that, don't you? [1] http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#697465: apache2.2-common: initial install fails: Could not read /etc/apache2/envvars
On 07.01.2013 16:58, Jean-Michel Vourgère wrote: > Arno: > a2ensite reads /etc/apache2/envvars in function read_env_file on line 331: > env - sh -c '. /etc/apache2/envvars && env' I could have sworn I removed that code and replaced it by pure Perl. Sorry for the confusion. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#697465: apache2.2-common: initial install fails: Could not read /etc/apache2/envvars
Hi, On 05.01.2013 18:05, Jonas Smedegaard wrote: > Severity: serious > Justification: Policy 7.2 I doubt this applies in your case. But anyway, let's not discuss about bug severities. > Setting up apache2.2-common (2.2.22-12) ... > sh: 1: .: Can't open /etc/apache2/envvars > Could not read /etc/apache2/envvars > dpkg: error processing apache2.2-common (--configure): > subprocess installed post-installation script returned error exit status 2 Could you provide a full output and what exactly you did? At very least you are probably not using the multistrap default setup which does not include Apache for obvious reasons. > Seems that error comes from a2ensite call, so I suspect the cause might > be some dependency of that script has not yet been configured. a2ensite does not call a shell to read /etc/apache2/envvars. Your output makes me suspect this is rather coming from the init script which is invoked from postinst. What makes you think a2ensite is the problem? That makes this error really strange because envvars comes from the same package and is installed through dpkg, not a maintainer script, i.e. long before the init script is called. > Perhaps apache2.2-common must pre-depend (not depend) on perl, to ensure > perl is fully configured before used. In fact, a2enmod (almost) works already with perl-base installed, which is an essential package. I say almost, because it does not include File::Basename which we use. If perl was the problem, it would fail out there. > The installation was done using multistrap which postpones more postinst > scripts than debootstrap and debian-installer. Perhaps multistrap should be fixed then. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#674142: make it possible to disable ssl compression in apache2
Hi, On 11/22/2012 11:12 AM, James Greig wrote: > Out of interest, you said it is already backported? I'm using > squeeze-backports but it hasn't appeared as an update? Am I doing something > wrong here? I meant, I backported the patch in our source code repository: http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/patches/300_disable-ssl-compression.dpatch;h=fd497646c6fe675d47821f729cff8b516319c2d7;hb=refs/heads/squeeze It is not available in any package (we support) yet. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#674142: make it possible to disable ssl compression in apache2
On 11/21/2012 10:32 AM, James Greig wrote: > I second the last message. I have a number of systems failing PCI compliance > that run squeeze so would really welcome this patch to debian squeeze even if > it's backported. It *IS* backported already and we *WILL* upload it as an update to Stable. But since this is not a critical issue [1] and since uploads to Stable are extremely sensitive it may well be we wait for another issue we need to fix in Stable as well. [1] it is a browser issue in reality, no really. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
