Bug#590528: apache: (optionally) suppress Could not reliably determine the server's fully qualified domain name message
Package: apache2.2-common Version: 2.2.16-1 Severity: minor Justification: pointless error message, clutters logs Files: /etc/logrotate.d/apache2 Hi Stefan, Tollef, Thom, et al, This is an old one. Once a week, I get a friendly reminder from cron: | /etc/cron.daily/logrotate: | apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName which is totally true; this laptop is not supposed to have a public Internet presence. In /usr/share/doc/apache2/README.Debian.gz, I read | 1) Error message Could not determine the server's fully qualified domain name, | using 127.0.0.1 for ServerName during start | | This can usually be ignored but it means that Apache httpd was unable to obtain | a fully-qualified hostname by doing a reverse lookup on your server's IP | address. You may want to add the fully-qualified hostname to /etc/hosts . but no, I do not want to get dynamic DNS just for this and do not want to ignore the message. Is there an option to suppress the message? If so, perhaps that item in the Common Problems list would be a good place to advertize it. :) Totally unrelated, but thanks for making Apache so easy to configure. It is great. :) -- 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/20100727020357.ga4...@burratino
Bug#590528: apache: (optionally) suppress Could not reliably determine the server's fully qualified domain name
Stefan Fritsch wrote: * In README.Debian, suggest an Apache configuration change to get rid of the Could not reliably determine the server's fully qualified domain name warning, as alternative to changing DNS or /etc/hosts. Closes: #590528 Thanks! It works. -- 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/20100901004544.gc22...@burratino
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Arno Töll wrote: However, reading your snippet I realized, you use module directives which aren't available until one enables the rewrite module in your case. We might think how to allow packagers of web applications to tell us, your configuration needs a special module. As we wrote in the announcement mail, we're open to suggestions from packagers of web applications. My bad --- I realized too late I had sent my local configuration. The actual snippet is Alias /gitweb /usr/share/gitweb Directory /usr/share/gitweb Options FollowSymLinks +ExecCGI AddHandler cgi-script .cgi /Directory Ideally the pathinfo stuff should be conditional on whether the rewrite module is already loaded. Thanks, Jonathan -- 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/20120322134624.GA16653@burratino
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Arno Töll wrote: I am not sure whether the NEWS file is an appropriate place for packaging hints but I will think about. I think a brief mention would be useful for sysadmins with local packages who do not necessarily follow debian-devel-announce. Similarly, I will think whether we will give hints to support both configuration styles at the same time. In the end, we do not intend to ship apache2 2.2 in Wheezy. For gitweb, it would be very useful since it would let us adopt the needed changes early (possibly even before an updated apache migrates to sid) and keep the sid package installable on squeeze. Thanks, Jonathan -- 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/20120322144536.GD16653@burratino
RFH: updating gitweb packaging for Apache 2.4
Hi, With Apache 2.2, the gitweb package worked out of the box. With Apache 2.4, it doesn't. http://bugs.debian.org/669292 tracks this problem. Last year, I tried to fix it --- patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292 But I ran into several problems[*] around the upgrade path and uninstallation procedure. I think I understood how packaging for apache 2.2 worked, and I just don't understand how packaging for apache 2.4 works. [*] https://lists.debian.org/debian-webapps/2013/12/msg0.html In particular: * 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. * It's not clear when to run apache2_invoke disconf gitweb. At remove and purge time doesn't seem to be enough. Until this is fixed, installing the gitweb package does not give the user a usable installation of gitweb, meaning I've been sitting with an RC bug for a long time. Help? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140408011714.gc3...@google.com
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
reopen 664761 block 669292 by 664761 quit Hi Arno, Arno Töll wrote: In lack of responses, I assume that all your questions have been answered or properly addressed. Alas, no. Since message #58 wasn't cc-ed to me, I didn't see it. 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. * It's not clear when to run apache2_invoke disconf gitweb. At remove and purge time doesn't seem to be enough. 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? 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? 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. (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. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714211220.gh12...@google.com
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Arno Töll wrote: On 14.07.2014 23:12, Jonathan Nieder wrote: * 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? As you noticed below, I didn't realize this should be called in prerm too. That helps. I think 'prerm deconfigure' needs the same treatment. [...] 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. Yep, I am worried about that case and the case where a webapp's conf is enabled and then Apache is deinstalled before the webapp is removed. If webapps can trust Apache packaging to automatically enable things when apache2 is installed and disable them when it is deinstalled (or if they can treat the lack of such behavior as Somebody Else's Problem :)) then I'd be all set. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140721214605.gy12...@google.com
