Bug#708515: Bug #708515 in Debian
Thomas Goirand wrote: I was wondering if you could help me here. I'm worried about this new bug in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708515 The CVE and bug are lacking a bit of information, but it really looks like a duplicate of Debian bug 700240 (CVE-2013-0270): large POST requests consuming server memory/CPU. Both would be mitigated by a request-limiting front-end (for Folsom and before) or the sizelimit middleware (for Grizzly and after), which were suggested as workarounds for CVE-2013-0270 already. Already CVE-2013-0247 and CVE-2013-0270 were duplicates. Is it possible that CVE-2013-2014 is also a duplicate of the same issue? CVE-2013-0247 is not a duplicate of CVE-2013-0270. CVE-2013-0270: Large POST consuming memory/CPU CVE-2013-0247: Malicious POST to /tokens consuming disk space Hope this helps, -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703242: [openstack-dev] Bug#703242: Bugging issue with nova-consoleauth on newest nova build 2012.1.1-15
Thomas Goirand wrote: Vish, TTX, Michael, do you know if this will happen anytime soon? Or do you think that the patch from Jules is actually ok, and I should apply it and release it in Debian? I really need your input here. I'll look into it and try to corner Michael, Vish and the Essex stable maintenance folks about it today. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700240: Vulnerability in OpenStack Keystone
Thomas Goirand wrote: Hi Thierry and Dan, I got very confused about CVE-2013-0247 and CVE-2013-0270. I have already uploaded the fix for CVE-2013-0247 in Debian SID, and now I'm trying to understand what CVE-2013-0270 is about. My request about it in the Openstack development list was left without an answer, so I'm asking you directly, with Cc: to the already opened Debian bug. Sorry for the delay in answering, I'm travelling right now so it's a bit difficult to make the research. I have no idea what CVE-2013-0270 is. So it might indeed be a duplicate of CVE-2013-0247, which is the one we issued OSSA-2013-003 for. The problem is that the patches I've read for CVE-2013-0270 for Essex seem to do the exact same thing as the patches for CVE-2013-0247 (in a slightly different way), and of course, both patches are conflicting. So, could you please confirm what my guts are telling me, which is that this patch: http://anonscm.debian.org/gitweb/?p=openstack/keystone.git;a=commitdiff;h=b6fe7d8c7719996b3b5a8765dee55bb0eb2944df which fixes CVE-2013-0247 also fixes CVE-2013-0270 which must be a duplicate of CVE-2013-0247. If this isn't the case, please tell me what's going on, and what you think I should do to fix Keystone in Debian Wheezy. I can apply things by hand if needed... I think you are right. I suspect CVE-2013-0270 was assigned after we released our advisory which was about -0247. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647726: Teardown patch in dnsmasq
Yes, the original change was in Ubuntu in a global effort to speed up shutdown (sending SIGTERM is slightly faster than spawning a shell script to do exactly the same) -- then it was proposed and accepted upstream. If there is any difficult-to-solve corner case that could result in it taking 10 seconds to stop instead of being immediate, then I agree that the above change is not worth it. -- Thierry Carrez (ttx) Ubuntu core developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591896: debian-maintainers: Please add Thierry Carrez to Debian Maintainers keyring
Package: debian-maintainers Severity: normal Please add Thierry Carrez to Debian Maintainers keyring. You'll find the jetring changeset attached. Thanks, -- Thierry Carrez Comment: Add Thierry Carrez (ttx) thierry.car...@ubuntu.com as a Debian Maintainer Date: Fri, 06 Aug 2010 11:37:05 +0200 Recommended-By: Steffen Möller steffen_moel...@gmx.de Torsten Werner twer...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2010/07/msg00045.html Advocates: http://lists.debian.org/debian-newmaint/2010/07/msg00047.html http://lists.debian.org/debian-newmaint/2010/07/msg00049.html Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.10 (GNU/Linux) mQINBEv77wYBEADBvhYIzN14XvsPPtgKhxRg3ULe9aNkQ3zBLAN6/zaNcnypzJuN CzA+SLgDBxmzWe5dQGfrOtc4Fv51M+V0/OsRsyxNgUg6rvN2yOt+QJfGpE/p6U0l vyL1EfDatVLoD7llJ04WydLITRiMnjg1rtEuAydQwRi2tgLCbBeFRtT+CH50D/xz syo8TVYqiVnf9DkVDxDu/myc3Pybs9TBvCFLxIU9yRuQkmLlkBaXUMx3y7wQ5RNG 8+2actH0B/v9nT/8VV1fRfr9BLM4143TXYSzsqEmlQIjGmyPZWRW+UdPrZBGeuFM cysKBGFP0sIk2ckoBurwzS6tWn4MGafvWoWbFaAR4T8Zq326kDuZ25R0GmjY4q7/ qQ4es6YnDAJe/tLO+Wc9Z29s95GvGXqZikgqM6WZv9yigxMhl0DzY0ZCRsGXH0+g UYojp54erqAKXg1txGNARsspVcjrJXRd7t4dwoHeQMeOjj7BBC4y1XxepEeXMDtu kCqNijt+Cv07qIzwvuB5X1ErwJVCvMlUE/yBtcdR7ppwiG2z4hYktSVBp4IEMHjr ovYT0DtwjzZBM978TiVaFXqxxgzfP9JinCyEAny2ThBTrHJ6NR1aMbao3wajuCBZ e6cO1bIF4Z6bo1vfqqisJJxAycsqEctDhTUEi9K/1Gtrcst7eMUEfcIdVQARAQAB tDBUaGllcnJ5IENhcnJleiAodHR4KSA8dGhpZXJyeS5jYXJyZXpAdWJ1bnR1LmNv bT6JAjgEEwECACICGwMCHgECF4AFAkwGhKMGCwkIBwMCBhUIAgkKCwQWAgMBAAoJ EFB6+JAlsQQjzuMQAJbHN7k599IYL5d9Ff1osERTOvEuX16z9NbDnucJfYYmNpRk kXqQg9u+Silvaf6LqUG8Y8Pg38Yt22VN0ogeCPvTuFfl52lCWhfCMde5QlAjqDaj /6PmP/tI6eFSHMKFciWIQPcYGy29Fp1Xp+u/rACHHEOVszcic4EeUhCaXRhbd4fx /M4f8M/L14QwZzXEnUH5KEgvY80b16+tDepvlhAx4j/8tEVeoHQqxbVJtGXHW77y SIBe8TkvirItn6AC9KVFrKFL7f2H03Uu2r+xk+VuEqYfzWisT1w/aF4pYiP1isMj p/0msWdfUDmxOyz4TiN8TVW0fXHnWdUk+KYNzaQDIPxBir+mf0yDv2LL0K9+Be1t HEbVmbsXTpuE5n6CGCxn40i1afwMG2NGGP80Rztj80GdIFtGp3MFDih6S+9za7R9 ve7vWMG2ODoxyELWipr0n7HvKQELdGs0lT/koVp/1rBUl89CUwfKijzOGlUhz+Bb JE/MRHuOpF2m3qc6NuuW2Ehva4ttEWc8rw9OQa9beF1LGzLz586+oKRMmVI9SdIE XqpRdZwmmHE5V7sVQJVDRJ6P/JZcP/u44JG/3az23BRiAyb44kY6cZcXHXS0ozBc p85xBN1z69NTfogZDI3ur4zwb8aQiwdMgRCvNfGySv6AJWYgLTQilOJd4KL1iEYE EBECAAYFAkv78wAACgkQvcL1obalX0+idACfSuI8Yd1SINMUJcQUbGLIa+oqcqcA njtLP1vOYqZKWgEeXVFq/x548mNbiQI4BBMBAgAiBQJL++8GAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRBQeviQJbEEI6l0D/sHvP161GZvj5oMwg3ppCQU c0C53k8Oj0WU969kaR/xXgCTZMT39gaJRxzWFycFPTPZ8GcCycu4kgiHsKRCnLOe eXrNGw6C1R+yhy+0ilyi7I2wGQ6/qbuX5OfQ+IlkB0jsTLIh0h02Ak59iVdhni8W DHipVEnplCEoBoPXqFkNmi4JP4Uwf+Nr75t3hQ6O6ROQZSixSn1s85x33JvbURG9 WViAPlfnKnsxVKA6eYIDCVduBAmbR2O/IkoW+z7fLiClq7OwmurPCXRYYM35kRKs OdDfBoS/sOlCvw1fz3CdcGwFs9Iqx3Ucd21sniH2PaaK7gS2DJWwsP85wjNqb5Bx YLjcc9ogDHc74GcUHaQXTpRIRMzGD3ZvYaYJKEzryD+vsATKS5OBHeIsmdR9fQF0 YjWHaEEQv/HfS2xtAikIloUbf86ulb1fOSQBkCHuez5ITjmKBRV3+uV3AiWxj84d AU3JyttswSErL94BJlzcqgaTSowWZRF3GK/pVNGxY9VtFTA3aCKNTE4YeT4Obd3p PQmd9rYvFgdr5Jc+9NQb+9BIyut9snKL0lrr6d6JvuScVAC7Ddh1lAW//3DrcGtO uWvmB/5Wg2E/YYMGgk5tC8jOXBbPQ8uaAmE5YPdVKtSEK7cBJXxTI5cD0cyi2GIG pSOkvzcNZiIofZA/nHlLuYkCHAQQAQgABgUCTEhSUgAKCRBXWfNQAapKZMayEADM HsHA143tDg+TsGfeYIDdMZzoMrRhV9/cr+TQ+89oPX5WMBBLu4zZSWnCov1TLRzb VbwyM2intXLuPxsD0tMrOWAhu0jqtPqzA/PZYWMd33ebzbXCPNsB9OmIq89SnNaU qvS153WwPl9TRvFTFjYjuXbGk6FoW0exWsmvME52JcKAZFPqvF7pK1jCGpQg1agZ p2RjFsrjhGGulKRjC0Xb6UG4aUOSgyZRK5eSs2UnTSTv2RhF6aF2s1j6N9AOZ2qU mMQ0o4/pEE2BlxGa44mHV9jr5AbJrLmJeguL/HqKEMNNbjwMpKQTD/21jYboG5HG j00emnItyKi2O8uRbUDl1vz0pxUjAFk918X+u6ZFxvg20rkxmGTapjx32tzXXp+5 svjj120KNNUQ5frtKvzvj+SMO5vVx18Q7cjbXmQ9Lm+5xESACmOlDDIR4XKTD0ja m5PEZ+6NPOpxNbjn+1uVcEe4baRVJ8VZDRkxD0f7JqD/WHaCMfgBnYd/tq1lpd2W e07yrGFiBzvry0txhI1FL0RrZ+E+66C48qdNyMJb1R9T7cTRMyWl9EgwS1TAAtvd n8CuuDPqMbSu/b9Mi3Wvq8SCIQG+MiWzYirWKbaBympYieNBr0F8V8Kaa6Rq7kRG UWDYoWEY0AAHDuB24rDznh5+fi9+BG1vgSplekcfV4hGBBARAgAGBQJMSM2DAAoJ EOFVF/IrCSDAd4YAmwaK3Obbje6FUugSelsYVY+RINCOAKCIRCsBg2WsQfAkBc0X gTLmk7qDHokCHAQQAQIABgUCTEjNvwAKCRDxFAhMCGEREfJCD/wLeD5Evhy+A2cQ IMtrDykXFF7TfugC+RSmUx73kuYmCxrh6Ih1MdrK9Gb3QDNIhQLb8sNWJbJA4BPG xdh2xs3u2RrgrJM7PQoAgc9+VW2b7rhlAjcPSxTrPOQezinOvP9RuMGWASN5Kbts 2MFQ5ADMEkvRB3ajeicCYbF7t59ZQ1a/LKs0cbKafosyCYi9CAlBmd0TXCjN0OBT 5iWrq04DPSz7UaSpGI/JK7FLu5Q1cvj9OY8mXF1LbyslwKI2OIfvPkOFoFrZ0Udm rtrw8ZqhJTuWZu1DPgfYZrh6knfrZFhnUaOGPr/q/LgH06FGCCURXcOXYIsZ3y6F W7LfLM7UdSrVGD2jY/zs/wGWKZNcpEWI0Mz0hFitzcv+wSKwhFtbWSQuwOPfRTbd ye7BakMNWYGRns+wPQVZQ/9tNXUAOovw6/K4VbpFv2hQeOW45tNlUMqQebBasPAL hrRaQoxCx50wNsboPwCcjQJSYkcYyBIiUkhC66x+31omLdTz98pk4IJUgcLDydu0 68QkPZutpGXgcwKM/0CAUKMEF+AkI3J7/c7lkCosMzO6b2ELIh3ybsOLjMDMg2qR SW5wXkcydl7zeRLp5ig6T5Hkw0EIGpCmMLnZLe3Ty0r15O1EpTGA75Xo+Go3UGgP UqquDlw43MizY6G2w5vnXW32IdTVA4hGBBARAgAGBQJMB68EAAoJEEq9NjU6FLLd scYAnjlPXPBjXumrh+mrgAXl0Ks7PzEcAJ9bc9nq1D/2XX2Y4O6cSPv5CqJOQ4kB HAQQAQIABgUCTFNc2AAKCRBTjAdm9Lyzjt7/CACplqLGRLfhbfvfY1UxGyBkbyHh
Bug#587414: Client hang when server does not push anything
Package: openvpn
Severity: normal
Version: 2.1.0-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch maverick
Starting with OpenVPN 2.1~rc20, if the server does not push any option
to the client, the client connection hangs while waiting for an answer
to its PUSH_REQUEST:
https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/579737
Proposed patch is taken from upstream bug at:
https://community.openvpn.net/openvpn/ticket/13
Hope this helps,
--
Thierry Carrez
diff -Nru openvpn-2.1.0/debian/patches/client_hang_when_server_dont_push.patch openvpn-2.1.0/debian/patches/client_hang_when_server_dont_push.patch
--- openvpn-2.1.0/debian/patches/client_hang_when_server_dont_push.patch 1970-01-01 01:00:00.0 +0100
+++ openvpn-2.1.0/debian/patches/client_hang_when_server_dont_push.patch 2010-06-28 11:04:51.0 +0200
@@ -0,0 +1,53 @@
+Description: When the client sends PUSH_REQUESTS, it waits until the server
+ sends PUSH_REPLY. If the server do not have anything to push to the client
+ nothing happens. The client will then regularly send new PUSH_REQUESTS until
+ it gets an answer, which results in not completing the connection negotiation.
+ This patch makes the server send an empty PUSH_REPLY when it has nothing
+ more to push to the client.
+Author: David Sommerseth d...@users.sourceforge.net
+Origin: upstream, https://community.openvpn.net/openvpn/attachment/ticket/13/0001-Fixed-client-hang-when-server-don-t-PUSH-aka-the-NO_.patch
+Bug: https://community.openvpn.net/openvpn/ticket/13
+Reviewed-By: James Yonan ja...@openvpn.net
+
+Index: openvpn/push.c
+===
+--- openvpn.orig/push.c 2010-06-28 11:02:21.697220261 +0200
openvpn/push.c 2010-06-28 11:02:24.247222587 +0200
+@@ -176,6 +176,7 @@
+ static char cmd[] = PUSH_REPLY;
+ const int extra = 64; /* extra space for possible trailing ifconfig and push-continuation */
+ const int safe_cap = BCAP (buf) - extra;
++ bool push_sent = false;
+
+ buf_printf (buf, cmd);
+
+@@ -191,6 +192,7 @@
+ const bool status = send_control_channel_string (c, BSTR (buf), D_PUSH);
+ if (!status)
+ goto fail;
++ push_sent = true;
+ multi_push = true;
+ buf_reset_len (buf);
+ buf_printf (buf, cmd);
+@@ -217,6 +219,21 @@
+ {
+ const bool status = send_control_channel_string (c, BSTR (buf), D_PUSH);
+ if (!status)
++goto fail;
++ push_sent = true;
++}
++
++ /* If nothing have been pushed, send an empty push,
++ * as the client is expecting a response
++ */
++ if (!push_sent)
++{
++ bool status = false;
++
++ buf_reset_len (buf);
++ buf_printf (buf, cmd);
++ status = send_control_channel_string (c, BSTR(buf), D_PUSH);
++ if (!status)
+ goto fail;
+ }
+
diff -Nru openvpn-2.1.0/debian/patches/series openvpn-2.1.0/debian/patches/series
--- openvpn-2.1.0/debian/patches/series 2010-05-05 04:06:18.0 +0200
+++ openvpn-2.1.0/debian/patches/series 2010-06-28 11:02:17.0 +0200
@@ -9,3 +9,4 @@
eurephia.patch
counter_type_for_bytes.patch
route_default_nil.patch
+client_hang_when_server_dont_push.patch
Bug#585379: Fix committed to SVN
The fix for this was committed to debian-java SVN. -- Thierry Carrez Ubuntu server team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583581: sudo etckeeper creates root-owned .bazaar and .bzr.log in home directory
Package: etckeeper Severity: minor Version: 0.46 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch maverick When run using sudo with VCS=bzr, etckeeper will create root-owned $HOME/.bazaar and $HOME/.bzr.log (if they were not created before by bzr itself). https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/376388 The proposed patch is to set and export HOME=~root if VCS=bzr. Hope this helps, -- Thierry Carrez --- etckeeper-0.46/etckeeper 2009-09-26 21:57:49.0 +0200 +++ etckeeper-0.46ubuntu1/etckeeper 2010-05-17 16:41:13.0 +0200 @@ -22,6 +22,13 @@ fi export VCS +if [ $VCS = bzr ]; then + # Avoid creating root-owned .bazaar and .bzr.log directories in users + # home directory when etckeeper is run under sudo (LP: #376388) + HOME=~root + export HOME +fi + if [ ! -z $GIT_COMMIT_OPTIONS ]; then export GIT_COMMIT_OPTIONS fi
Bug#581018: Patch committed to SVN
I committed a patch for this to debian-java SVN, revision 12475. Feel free to review/revert/upload :) -- Thierry Carrez Ubuntu server team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532284: Permissions for tomcat6
I'm not sure it's a good change. When I worked on tomcat6 packaging, I changed the permissions used in tomcat5.5 on purpose. /etc/tomcat6: This was set to root:root 644, with two exceptions: - tomcat-users.xml that needs to be read by tomcat and hidden to users, so it is root:tomcat6 640 - Catalina directory that should allow autodeploy of new contexts by tomcat, so it is root:tomcat6 775 The idea behind this was to specifically *exclude* the tomcat6 user from messing with key configuration files like server.xml or tomcat-users.xml, and it is a security measure against any traversal by the tomcat6 user. Your argument is that you need to be root to configure Tomcat. Well, this mimics what is done for every other daemon out there: allow root to configure it, and do not allow the user the daemon is run under to modify its own configuration. See /etc/apache2 for an example of this. /var/lib/tomcat6/webapps: This was set to 775 root:tomcat6 so that tomcat can autodeploy applications. Additionally, members of the tomcat6 group are also allowed to deploy applications. Changing that to tomcat6:adm just transfers that capability from the tomcat6 group to the adm group. Looks like we lose some granularity, and I fail to see why adding users to the tomcat6 group does not look like a good idea. But I can live with that :) -- Thierry Carrez -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532284: Permissions for tomcat6
Ludovic Claude wrote: Well that sounds well argumented, in particular the issue of permissions for /etc/tomcat6. Do you recommend reverting permissions in /etc/tomcat6 to root:root 640? Yes, I would recommend reverting /etc permissions the way they were before (root:root 640 with the 2 exceptions). For /var/lib/tomcat6/webapps, the new setting doesn't lessen security so I don't care so much. If someone has a good argument on why allowing the adm group to deploy tomcat6 webapps is better than using the tomcat6 group, then so be it. To me it just sounds like we lose the possibility of allowing someone to deploy webapps without making him a full member of the adm group... In any case, such security issues should have been well documented in the package, to prevent ignorant maintainers (me!) from messing up with those sensitive issues. Yes, I missed that in my changes-from-tomcat5.5 notes in README.Debian. -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532889: Proposed patch
Here is the patch I recently applied to Ubuntu. Hoping this helps. -- Thierry Carrez Ubuntu server team diff -u libcommons-fileupload-java-1.2.1/debian/copyright libcommons-fileupload-java-1.2.1/debian/copyright --- libcommons-fileupload-java-1.2.1/debian/copyright +++ libcommons-fileupload-java-1.2.1/debian/copyright @@ -13,58 +13,17 @@ Copyright: +Copyright 2002-2008 The Apache Software Foundation - - -The Apache Software License, Version 1.1 - -Copyright (c) 2001 The Apache Software Foundation. All rights -reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions -are met: - -1. Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - -2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - -3. The end-user documentation included with the redistribution, if - any, must include the following acknowlegement: - This product includes software developed by the - Apache Software Foundation (http://www.apache.org/). - Alternately, this acknowlegement may appear in the software itself, - if and wherever such third-party acknowlegements normally appear. - -4. The names The Jakarta Project, Commons, and Apache Software - Foundation must not be used to endorse or promote products derived - from this software without prior written permission. For written - permission, please contact apa...@apache.org. - -5. Products derived from this software may not be called Apache, - Velocity nor may Apache appear in their names without prior - written permission of the Apache Group. - -THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED -WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES -OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE -DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR -ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF -USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND -ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, -OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT -OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -SUCH DAMAGE. - - -This software consists of voluntary contributions made by many -individuals on behalf of the Apache Software Foundation. For more -information on the Apache Software Foundation, please see -http://www.apache.org/. - +License: +Licensed under the Apache License, Version 2.0 (the License); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an AS IS BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License.
Bug#533290: Do etckeeper commit at install time
Joey Hess wrote: Thierry Carrez wrote: How often do you think admins need to edit the added file set for security/clutter reasons ? I don't know, but I also doubt that it's common for anyone to need access to the state of /etc at the instant etckeeper was installed, rather than slightly later when something causes it to commit. You're right. The user ignoring everything will get the first step committed as part of the next apt preinstall hook or the daily autocommit. So we don't really make it easier for him. I'll revert that change in Ubuntu so that both distributions behave the same from a user interaction perspective. And feel free to close this wishlist bug :) Thanks, -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533290: Do etckeeper commit at install time
Joey Hess wrote: Thierry Carrez wrote: You're right. The user ignoring everything will get the first step committed as part of the next apt preinstall hook or the daily autocommit. So we don't really make it easier for him. I'll revert that change in Ubuntu so that both distributions behave the same from a user interaction perspective. And feel free to close this wishlist bug :) Acting as devil's advocate before closing it.. One reason a user might care is if they're treating etckeeper as a quick and dirty backup mechanism. If so, there'd be an expectation that as soon as it is installed, you can begin to muck about with /etc and be able to revert your changes. It could be suprising to find that there was no history to revert to yet. Hmm... how about printing a message at the end of etckeeper init advising people to review the added file set and run etckeeper commit ? 1/ People explicitely installing etckeeper for quick backup would/should see the message 2/ It serves as a basic usage reminder 3/ People ignoring the message would get saved by autocommit at the end of the day -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533298: Daily autocommits generate cron emails with VCS=hg
Joey Hess wrote: How about fixing this inside commit.d/ rather than in the cron job? I'd do it myself, but I am unsure whether only commit.d/50vcs-commit would need changing, or if the call to hg in commit.d/30hg-addremove might also trigger the warning message. I'm no hg expert myself :) My understanding was that the warning message was causing real trouble only in the cronjob case (systematically generating an email, as HGUSER is never set in that case). HGUSER might (or should ?) be set by the user in his environment so issuing a warning in all other cases might, in fact, make sense ? -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533290: Do etckeeper commit at install time
Joey Hess wrote: Thierry Carrez wrote: etckeeper currently runs etckeeper init in postinst, as a fix for bug 505772. However this bug suggested to run both init and commit at install-time, in order to have a working setup just after the install command. This makes sense especially as the nifty etckeeper uninit allows you to undo both init and commit anyway. The reason I don't immediatly autocommit is because the user might want to examine the files that etckeeper has added to version control and remove some of them from it, for security or clutter reasons. They also might want to update the VCS's ignore file. It makes sense to let them do so before the initial commit. Of course, the commit will probably happen soon after install anyway, either by the cron job, or by another apt run triggering it. Still, at least this way the user has a window and doesn't need to do a tedious uninit and reinit. Yes, it's obviously a trade-off between: * Having it up and running just after installation * Offering systematically the opportunity to review the added set My (final) goal for etckeeper is to make it a potential default install target (in Ubuntu), so that people can run it without even knowing it's there, and when they happen to need the history they can learn more about it and discover that it's been logging changes all along. That was the idea behind the daily autocommit. With that goal in mind, it makes sense for us to balance the tradeoff in the up without any user interaction direction. We make it easier for newbies, at the expense of making it slightly harder for experienced users (potential need to uninit + init + add + commit if you want to edit the set manually). However I'd perfectly understand if you prefer to balance that trade-off in the other direction in Debian :) I just submitted the idea, because the less delta we have the better it is for everyone. How often do you think admins need to edit the added file set for security/clutter reasons ? Cheers, -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534564: JDK could be a suggestion rather than a dependency
Package: ant Severity: wishlist Version: 1.7.0-6 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu karmic ant currently has: Depends: java-gcj-compat-dev | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime, libxerces2-java However, ant doesn't *require* a JDK to run. It is used increasingly in server packages to run tasks that don't involve compilation, and having this hard dependency on java-gcj-compat-dev | java-virtual-machine pulls a complete JDK (with related X libraries) in a server install. The suggestion would be to depend on a headless runtime, and make default-jdk a Suggests instead: Depends: default-jre-headless | java1-runtime-headless | java2-runtime-headless, libxerces2-java Recommends: ant-optional, ant-gcj Suggests: default-jdk | java-compiler | java-sdk, ant-doc This is what is currently used in Ubuntu karmic. Cheers, -- Thierry Carrez -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533290: Do etckeeper commit at install time
Package: etckeeper Severity: wishlist Version: 0.37 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch karmic etckeeper currently runs etckeeper init in postinst, as a fix for bug 505772. However this bug suggested to run both init and commit at install-time, in order to have a working setup just after the install command. This makes sense especially as the nifty etckeeper uninit allows you to undo both init and commit anyway. See attached patch for proposed implementation. Hope this helps, -- Thierry Carrez diff -Nru etckeeper-0.37/debian/postinst etckeeper-0.37ubuntu1/debian/postinst --- etckeeper-0.37/debian/postinst 2009-05-27 21:26:53.0 +0200 +++ etckeeper-0.37ubuntu1/debian/postinst 2009-06-16 09:56:57.0 +0200 @@ -77,7 +77,11 @@ # Fresh install. . /etc/etckeeper/etckeeper.conf || true if [ -n $VCS ] [ -x `which $VCS 2/dev/null` ]; then - etckeeper init || echo etckeeper init failed; run it by hand 2 + if etckeeper init; then +etckeeper commit Initial commit + else +echo etckeeper init failed; run it by hand 2 + fi else echo etckeeper init not ran as $VCS is not installed 2 fi
Bug#533295: etckeeper fails to commit if hostname -f fails
Package: etckeeper Severity: low Version: 0.37 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch karmic etckeeper fails to commit if hostname -f fails (because of a misconfigured hostname). I tend to think that the user should fix his hostname in that corner case, but nevertheless added support for working around that in 0.37ubuntu1. https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/377265 See attached patch for proposed implementation. Basically it uses hostname if hostname -f fails to avoid any commit failure. Hope this helps, -- Thierry Carrez diff -Nru etckeeper-0.37/commit.d/50vcs-commit etckeeper-0.37ubuntu1/commit.d/50vcs-commit --- etckeeper-0.37/commit.d/50vcs-commit 2009-02-05 03:40:27.0 +0100 +++ etckeeper-0.37ubuntu1/commit.d/50vcs-commit 2009-06-16 10:53:36.0 +0200 @@ -2,7 +2,7 @@ set -e message=$1 -hostname=`hostname -f` +hostname=`hostname -f 2/dev/null || hostname` if [ $VCS = git ] [ -d .git ]; then if [ -n $SUDO_USER ]; then
Bug#533298: Daily autocommits generate cron emails with VCS=hg
Package: etckeeper Severity: minor Version: 0.37 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch karmic When run with VCS=hg, the daily autocommit cronjob generates cron emails with a No username found, using 'r...@hostname' instead message. https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/364344 See attached patch for proposed fix. Hope this helps, -- Thierry Carrez diff -Nru etckeeper-0.37/debian/cron.daily etckeeper-0.37ubuntu1/debian/cron.daily --- etckeeper-0.37/debian/cron.daily 2009-02-13 19:52:49.0 +0100 +++ etckeeper-0.37ubuntu1/debian/cron.daily 2009-06-16 11:00:34.0 +0200 @@ -3,6 +3,10 @@ if [ -x /usr/sbin/etckeeper ] [ -e /etc/etckeeper/etckeeper.conf ]; then . /etc/etckeeper/etckeeper.conf if [ $AVOID_DAILY_AUTOCOMMITS != 1 ]; then + if [ $VCS = hg ]; then + hostname=`hostname -f 2/dev/null || hostname` + export hguser=c...@$hostname + fi if etckeeper unclean; then etckeeper commit daily autocommit /dev/null fi
Bug#528625: exiqgrep error on messages without size
Package: exim4
Severity: minor
Version: 4.69-11
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch
exiqgrep might return a Line mismatch error:
# exiqgrep -x
Line mismatch: 42h 1JCb3k-0007bY-P1 addr-removed-for-priv...@home.nl
This happens when exim4 -bp (mailq) reports lines without size info.
The attached patch was included in Ubuntu's exim4 [1]. You might
consider including it in Debian as well.
[1] https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/181948
Regards,
--
Thierry Carrez
diff -u exim4-4.69/debian/patches/00list exim4-4.69/debian/patches/00list
--- exim4-4.69/debian/patches/00list
+++ exim4-4.69/debian/patches/00list
@@ -14,0 +15 @@
+71_exiq_grep_error_on_messages_without_size.dpatch
only in patch2:
unchanged:
--- exim4-4.69.orig/debian/patches/71_exiq_grep_error_on_messages_without_size.dpatch
+++ exim4-4.69/debian/patches/71_exiq_grep_error_on_messages_without_size.dpatch
@@ -0,0 +1,37 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 71_exiq_grep_error_on_messages_without_size.dpatch
+##
+## DP: https://bugs.edge.launchpad.net/ubuntu/+source/exim4/+bug/181948
+## DP: Patch from Daniel van Eeden
+
+...@dpatch@
+--- experimental~/build-tree//src/exiqgrep.src
experimental/build-tree//src/exiqgrep.src
+@@ -106,7 +106,26 @@
+ # Increment message counter.
+ $count++;
+ } else {
+- print STDERR Line mismatch: $line\n; exit 1;
++ if ($line =~ /^\s*(\w+)\s+(\w{6}-\w{6}-\w{2})\s+(.*?)/) {
++ my $msg = $2;
++ $id{$msg}{age} = $1;
++ $id{$msg}{size} = 0K;
++ $id{$msg}{from} = $3;
++ $id{$msg}{birth} = msg_utc($msg);
++ $id{$msg}{ages} = time - $id{$msg}{birth};
++ if ($line =~ /\*\*\* frozen \*\*\*$/) {
++ $id{$msg}{frozen} = 1;
++ } else {
++ $id{$msg}{frozen} = 0;
++ }
++ while(QUEUE =~ /\s+(@.*)$/) {
++ push(@{$id{$msg}{rcpt}},$1);
++ }
++ # Increment message counter.
++ $count++;
++ } else {
++ print STDERR Line mismatch: $line\n; exit 1;
++ }
+ }
+ }
+ close(QUEUE) or die(Error closing pipe: $!\n);
Bug#527033: tomcat6 patch needed to work with libtcnative-1 and ipv6 enabled
Package: tomcat6
Severity: normal
Version: 6.0.18-3
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch jaunty
Debian bug #517163 and #521306 are about tomcat6 failing to start with
libtcnative-1 installed and ipv6 enabled, with the following error:
Socket bind failed: [22] Invalid argument
Those bugs were fixed on the tomcat-native side by bumping to the 1.1.16
release. However, according to the upstream bug[1] and my testing, this
also requires a patch to be applied to tomcat6 itself.
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43327
Ubuntu applied the attached patch to fix this, please consider including
it in a future release. The patch was taken from upstream SVN and will
be part of 6.0.19 one day.
Thanks !
--
Thierry Carrez
diff -u tomcat6-6.0.18/debian/patches/series tomcat6-6.0.18/debian/patches/series
--- tomcat6-6.0.18/debian/patches/series
+++ tomcat6-6.0.18/debian/patches/series
@@ -4,0 +5 @@
+tcnative-ipv6-fix-43327.patch
only in patch2:
unchanged:
--- tomcat6-6.0.18.orig/debian/patches/tcnative-ipv6-fix-43327.patch
+++ tomcat6-6.0.18/debian/patches/tcnative-ipv6-fix-43327.patch
@@ -0,0 +1,15 @@
+Index: tomcat6-6.0.18/java/org/apache/tomcat/util/net/AprEndpoint.java
+===
+--- tomcat6-6.0.18.orig/java/org/apache/tomcat/util/net/AprEndpoint.java 2009-02-16 16:05:35.0 +
tomcat6-6.0.18/java/org/apache/tomcat/util/net/AprEndpoint.java 2009-02-16 16:06:38.0 +
+@@ -599,8 +599,8 @@
+ long inetAddress = Address.info(addressStr, family,
+ port, 0, rootPool);
+ // Create the APR server socket
+-serverSock = Socket.create(family, Socket.SOCK_STREAM,
+-Socket.APR_PROTO_TCP, rootPool);
++serverSock = Socket.create(Address.getInfo(inetAddress).family,
++Socket.SOCK_STREAM, Socket.APR_PROTO_TCP, rootPool);
+ if (OS.IS_UNIX) {
+ Socket.optSet(serverSock, Socket.APR_SO_REUSEADDR, 1);
+ }
Bug#519802: Tomcat6 and low ports
Hello Andreas, I can't reproduce your problem: setting HTTP port 80 in server.xml works for me... The init script (run as root) is using jsvc to bind to the privileged port and then drop privileges to the tomcat6 user... Using jsvc leads to a whole lot of problems (like the strange permissions on log files) but I kept using it in the packaging just so that we could run as an unprivileged user without the usual drawback of doing so. -- Thierry Carrez -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517857: Do not create useless lib subdirectory in /var/lib/tomcat6 and private instances
Package: tomcat6
Severity: minor
Version: 6.0.18-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch jaunty
Tomcat6 Java libraries are located in /usr/share/tomcat6/lib
($CATALINA_HOME/lib) but also linked to in /var/lib/tomcat6/lib
($CATALINA_BASE/lib). Tomcat 6 completely ignores $CATALINA_BASE/lib
(see /usr/share/doc/tomcat6-common/RUNNING.txt.gz for details) so this
directory is useless. It is confusing because the user tends to think he
can add libraries there as well.
In the same vein, tomcat6-instance-create also creates a lib
subdirectory in private tomcat6 instances... which is also ignored.
Proposed patch disables both useless directories. It's taken from
Ubuntu's recent 6.0.18-0ubuntu6.
Regards,
--
Thierry Carrez
diff -u tomcat6-6.0.18/debian/tomcat6-instance-create tomcat6-6.0.18/debian/tomcat6-instance-create
--- tomcat6-6.0.18/debian/tomcat6-instance-create
+++ tomcat6-6.0.18/debian/tomcat6-instance-create
@@ -114,10 +114,6 @@
mkdir ${TARGET}/conf
mkdir ${TARGET}/logs
-mkdir ${TARGET}/lib
-for jar in /usr/share/tomcat6/lib/*; do
- ln -s $jar ${TARGET}/lib/`basename $jar`
-done
mkdir ${TARGET}/webapps
mkdir ${TARGET}/work
mkdir ${TARGET}/temp
diff -u tomcat6-6.0.18/debian/tomcat6.links tomcat6-6.0.18/debian/tomcat6.links
--- tomcat6-6.0.18/debian/tomcat6.links
+++ tomcat6-6.0.18/debian/tomcat6.links
@@ -4,14 +3,0 @@
-/usr/share/tomcat6/lib/annotations-api.jar /var/lib/tomcat6/lib/annotations-api.jar
-/usr/share/tomcat6/lib/catalina-ant.jar /var/lib/tomcat6/lib/catalina-ant.jar
-/usr/share/tomcat6/lib/catalina-ha.jar /var/lib/tomcat6/lib/catalina-ha.jar
-/usr/share/tomcat6/lib/catalina.jar /var/lib/tomcat6/lib/catalina.jar
-/usr/share/tomcat6/lib/catalina-tribes.jar /var/lib/tomcat6/lib/catalina-tribes.jar
-/usr/share/tomcat6/lib/commons-dbcp.jar /var/lib/tomcat6/lib/commons-dbcp.jar
-/usr/share/tomcat6/lib/commons-pool.jar /var/lib/tomcat6/lib/commons-pool.jar
-/usr/share/tomcat6/lib/el-api.jar /var/lib/tomcat6/lib/el-api.jar
-/usr/share/tomcat6/lib/jasper-el.jar /var/lib/tomcat6/lib/jasper-el.jar
-/usr/share/tomcat6/lib/jasper.jar /var/lib/tomcat6/lib/jasper.jar
-/usr/share/tomcat6/lib/jasper-jdt.jar /var/lib/tomcat6/lib/jasper-jdt.jar
-/usr/share/tomcat6/lib/jsp-api.jar /var/lib/tomcat6/lib/jsp-api.jar
-/usr/share/tomcat6/lib/servlet-api.jar /var/lib/tomcat6/lib/servlet-api.jar
-/usr/share/tomcat6/lib/tomcat-coyote.jar /var/lib/tomcat6/lib/tomcat-coyote.jar
Bug#480132: AspectJ bootstrapping
Here's a list: 1. org.aspectj/modules/lib/aspectj/lib/aspectjrt121.jar 2. org.aspectj/modules/lib/aspectj/lib/aspectjrt.jar 3. org.aspectj/modules/lib/aspectj/lib/aspectjtools.jar 4. org.aspectj/modules/lib/build/build.jar 5. org.aspectj/modules/org.eclipse.jdt.core/jdtcore-for-aspectj.jar [...] 1. 2. and 3. are a typical chicken/egg problem, and I have no idea how to solve it. This looks like a classic bootstrapping issue. The package could build-depend on itself, that should give you the missing JARs (except the 121 thing) ? -- Thierry Carrez Ubuntu server team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515100: Daily autocommit cronjob for etckeeper
Package: etckeeper
Severity: wishlist
Version: 0.28
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch jaunty
etckeeper already autocommits pre/post package installation
modifications. It could also offer a daily cronjob to catch uncommitted
modifications every night. This would allow much better default tracking.
This should be optional, though I would argue it should be on by
default, since those that would most likely need it are the ones that
would not touch the configuration file anyway.
See attached patch for proposed implementation.
Hope this helps,
--
Thierry Carrez
--- debian/control 2009-01-27 10:41:15 +
+++ debian/control 2009-01-27 12:25:20 +
@@ -12,6 +12,7 @@
Architecture: all
Section: admin
Depends: git-core (= 1:1.5.4) | mercurial | bzr (= 1.4~) | darcs, ${misc:Depends}
+Recommends: cron
Conflicts: bzr ( 1.4~)
XB-Python-Version: ${python:Versions}
Description: store /etc in git, mercurial, bzr or darcs
--- debian/cron.daily 1970-01-01 00:00:00 +
+++ debian/cron.daily 2009-01-27 12:25:20 +
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+. /etc/etckeeper/etckeeper.conf
+if [ $AVOID_DAILY_AUTOCOMMITS != 1 ]; then
+ if /usr/sbin/etckeeper unclean; then
+ /usr/sbin/etckeeper commit Daily autocommit
+ fi
+fi
--- etckeeper.conf 2009-01-25 15:53:58 +
+++ etckeeper.conf 2009-01-28 13:55:41 +
@@ -16,6 +16,10 @@
# Options passed to darcs commit when run by etckeeper.
#DARCS_COMMIT_OPTIONS=
+# Uncomment to avoid etckeeper committing existing changes
+# to /etc automatically once per day.
+#AVOID_DAILY_AUTOCOMMITS=1
+
# Uncomment to avoid etckeeper committing existing changes to
# /etc before installation. It will cancel the installation,
# so you can commit the changes by hand.
Bug#498739: Proposed patch
tags 498739 + patch user ubuntu-de...@lists.ubuntu.com usertag 498739 + ubuntu-patch Proposed patch to implement this. -- Thierry Carrez === modified file 'commit.d/50vcs-commit' --- commit.d/50vcs-commit 2008-12-31 18:02:14 + +++ commit.d/50vcs-commit 2009-01-26 16:45:31 + @@ -2,20 +2,32 @@ set -e message=$1 +author=$SUDO_USER +hostname=`hostname -f` if [ $VCS = git ] [ -d .git ]; then + if [ -n $author ]; then + export GIT_AUTHOR_NAME=$author + export GIT_AUTHOR_EMAIL=$aut...@$hostname + fi if [ -n $message ]; then git commit $GIT_COMMIT_OPTIONS -m $message else git commit $GIT_COMMIT_OPTIONS fi elif [ $VCS = hg ] [ -d .hg ]; then + if [ -n $author ]; then + export LOGNAME=$author + fi if [ -n $message ]; then hg commit $HG_COMMIT_OPTIONS -m $message else hg commit $HG_COMMIT_OPTIONS fi elif [ $VCS = bzr ] [ -d .bzr ]; then + if [ -n $author ]; then + export EMAIL=$author $aut...@$hostname + fi if [ -n $message ]; then bzr commit $BZR_COMMIT_OPTIONS -m $message else
Bug#498739: Proposed patch
Jelmer Vernooij wrote: This seems to implement different behaviour for bzr and git, both of which support a distinction between the committer of a revision and the author of that revision. The patch overrides the author for git and the committer for bzr. True :) I should have used GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL rather than the GIT_AUTHOR_* counterparts. Will post a new patch here after some tests. -- Thierry Carrez -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498739: Proposed patch
Thierry Carrez wrote: Jelmer Vernooij wrote: This seems to implement different behaviour for bzr and git, both of which support a distinction between the committer of a revision and the author of that revision. The patch overrides the author for git and the committer for bzr. True :) I should have used GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL rather than the GIT_AUTHOR_* counterparts. Will post a new patch here after some tests. Here is a new one using GIT_COMMITTER_*. It also avoids the useless copy of $SUDO_USER into $author. -- Thierry Carrez --- commit.d/50vcs-commit 2008-12-31 18:02:14 + +++ commit.d/50vcs-commit 2009-01-28 14:01:43 + @@ -2,20 +2,31 @@ set -e message=$1 +hostname=`hostname -f` if [ $VCS = git ] [ -d .git ]; then + if [ -n $SUDO_USER ]; then + export GIT_COMMITTER_NAME=$SUDO_USER + export GIT_COMMITTER_EMAIL=$sudo_u...@$hostname + fi if [ -n $message ]; then git commit $GIT_COMMIT_OPTIONS -m $message else git commit $GIT_COMMIT_OPTIONS fi elif [ $VCS = hg ] [ -d .hg ]; then + if [ -n $SUDO_USER ]; then + export LOGNAME=$SUDO_USER + fi if [ -n $message ]; then hg commit $HG_COMMIT_OPTIONS -m $message else hg commit $HG_COMMIT_OPTIONS fi elif [ $VCS = bzr ] [ -d .bzr ]; then + if [ -n $SUDO_USER ]; then + export EMAIL=$SUDO_USER $sudo_u...@$hostname + fi if [ -n $message ]; then bzr commit $BZR_COMMIT_OPTIONS -m $message else
Bug#500129: Status update
There is a certain range of NAS boxes which exhibits lots of problems with Samba 3.2.x, in particular: - Crash when listing directories - Once crash is fixed, missing info - ERRHRD 39 returned when writing This is followed upstream in: https://bugzilla.samba.org/show_bug.cgi?id=5953 Also in Ubuntu as: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/264943 So far there is a fix for the crash in 3.2.6, a fix for the missing info in 3.2-test git, and the ERRHRD 39 is still under investigation. -- Thierry Carrez -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506734: Support for fast shutdown in dnsmasq daemon
Package: dnsmasq Severity: wishlist Version: 2.46-1 Tags: patch User: [EMAIL PROTECTED] Usertags: origin-ubuntu ubuntu-patch jaunty Following discussions on debian-devel [1] [2], here is a patch that implements fast shutdown for the dnsmasq daemon. It basically avoids the init script to be called at system shutdown or reboot, and instead rely on the processes being correctly terminated and killed by the sendsigs script. [1] http://lists.debian.org/debian-devel/2008/08/msg00030.html [2] http://lists.debian.org/debian-devel/2008/07/msg00198.html Hope this helps, -- Thierry Carrez diff -u dnsmasq-2.46/debian/postinst dnsmasq-2.46/debian/postinst --- dnsmasq-2.46/debian/postinst +++ dnsmasq-2.46/debian/postinst @@ -11,7 +11,7 @@ fi -update-rc.d dnsmasq defaults 15 85 /dev/null +update-rc.d dnsmasq start 15 2 3 4 5 . stop 85 1 . /dev/null if [ $1 = configure ] || [ $1 = abort-upgrade ]; then if [ -e /var/run/dnsmasq.pid ]; then diff -u dnsmasq-2.46/debian/init dnsmasq-2.46/debian/init --- dnsmasq-2.46/debian/init +++ dnsmasq-2.46/debian/init @@ -4,7 +4,7 @@ # Required-Start: $network $remote_fs $syslog # Required-Stop: $network $remote_fs $syslog # Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Default-Stop: 1 # Description:DHCP and DNS server ### END INIT INFO
Bug#506734: Support for fast shutdown in dnsmasq daemon
Simon Kelley wrote: AFAICS that is the the only difference between the Ubuntu and Debian packages, is that still correct? Yes, I just merged 2.46-1 and that's the only delta left. There's a theoretical worst-case that sees dnsmasq take 3.5 seconds to respond to SIGTERM. Is that likely to be a problem? sendsigs apparently waits 10 seconds after SIGTERM before sending SIGKILL to the remaining processes, so I'd say that's not an issue. BTW, Thierry, I have a fix to https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/291186 which is in http://thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.47test1.tar.gz Cool, thanks for the pointer ! keep up the great work, -- Thierry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506078: Support for fast shutdown in pure-ftpd daemon
Package: pure-ftpd Severity: wishlist Version: 1.0.21-11.4 Tags: patch User: [EMAIL PROTECTED] Usertags: origin-ubuntu ubuntu-patch jaunty Following discussions on debian-devel [1] [2], here is a patch that implements fast shutdown for the pure-ftpd daemon. It basically avoids the init script to be called at system shutdown or reboot, and instead rely on the processes being correctly terminated and killed by the sendsigs script. [1] http://lists.debian.org/debian-devel/2008/08/msg00030.html [2] http://lists.debian.org/debian-devel/2008/07/msg00198.html -- Thierry Carrez diff -u pure-ftpd-1.0.21/debian/rules pure-ftpd-1.0.21/debian/rules --- pure-ftpd-1.0.21/debian/rules +++ pure-ftpd-1.0.21/debian/rules @@ -118,7 +118,7 @@ # pam and init install -p -m644 debian/pam debian/pure-ftpd-common/etc/pam.d/pure-ftpd - dh_installinit + dh_installinit -- start 20 2 3 4 5 . stop 80 1 . # logrotate dh_installlogrotate diff -u pure-ftpd-1.0.21/debian/pure-ftpd.init.d pure-ftpd-1.0.21/debian/pure-ftpd.init.d --- pure-ftpd-1.0.21/debian/pure-ftpd.init.d +++ pure-ftpd-1.0.21/debian/pure-ftpd.init.d @@ -4,7 +4,7 @@ # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Default-Stop: 1 ### END INIT INFO # # pure-ftpd starts and stops the pure-ftpd ftp daemon
Bug#506081: Pure-ftpd should default to standalone rather than inetd
Package: pure-ftpd Severity: wishlist Version: 1.0.21-11.4 Tags: patch User: [EMAIL PROTECTED] Usertags: origin-ubuntu ubuntu-patch jaunty Current debconf default for pure-ftpd is to use it with inetd. It is more common today to deploy it as a standalone daemon, so I propose to change that default behavior. The following patch implements the proposed change. -- Thierry Carrez diff -u pure-ftpd-1.0.21/debian/pure-ftpd-common.templates pure-ftpd-1.0.21/debian/pure-ftpd-common.templates --- pure-ftpd-1.0.21/debian/pure-ftpd-common.templates +++ pure-ftpd-1.0.21/debian/pure-ftpd-common.templates @@ -1,7 +1,7 @@ Template: pure-ftpd/standalone-or-inetd Type: select _Choices: inetd, standalone -Default: inetd +Default: standalone _Description: Run pure-ftpd from inetd or as a standalone server: Pure-ftpd can be run from inetd or as a standalone daemon. Using inetd is a suitable option for small ftp servers because the inetd super-server
Bug#506077: /var/run/pure-ftpd should be created if missing
Package: pure-ftpd
Severity: minor
Version: 1.0.21-11.4
Tags: patch
User: [EMAIL PROTECTED]
Usertags: origin-ubuntu ubuntu-patch jaunty
/var/run/pure-ftpd is created at install time. However, to support
configurations using tmpfs for /var/run, it is good to check for
directory existence at run-time and create it if it is missing.
The following proposed patch also changes all references to the .pid
file to a $PIDFILE.
--
Thierry Carrez
diff -ruN pure-ftpd-1.0.21.orig/debian/pure-ftpd.init.d pure-ftpd-1.0.21/debian/pure-ftpd.init.d
--- pure-ftpd-1.0.21.orig/debian/pure-ftpd.init.d 2008-11-17 14:08:00.0 +0100
+++ pure-ftpd-1.0.21/debian/pure-ftpd.init.d 2008-11-18 09:27:50.0 +0100
@@ -18,6 +18,8 @@
UDDESC=ftp upload handler
WRAPPER=/usr/sbin/pure-ftpd-wrapper
+PIDFILE=/var/run/pure-ftpd/pure-ftpd.pid
+
# try to figure with suffix this script is called,
# $0 might be a symlink pointing to this script
if [ -h $0 ]; then
@@ -50,6 +52,10 @@
set -e
+if [ ! -e `dirname $PIDFILE` ];then
+ mkdir `dirname $PIDFILE`
+fi
+
start_uploadscript() {
if [ $UPLOADSCRIPT -a $STANDALONE_OR_INETD != inetd ] \
egrep -i '^[ ]*(yes|1|on)[ ]*' /etc/pure-ftpd/conf/CallUploadScript /dev/null 21
@@ -69,14 +75,14 @@
start)
test $STANDALONE_OR_INETD = standalone || exit 0
echo -n Starting $DESC:
- start-stop-daemon --start $SSDAEMONLOGOPTS --pidfile /var/run/pure-ftpd/pure-ftpd.pid \
+ start-stop-daemon --start $SSDAEMONLOGOPTS --pidfile $PIDFILE \
--exec $WRAPPER -- $SUFFIX
start_uploadscript Starting
;;
stop)
echo -n Stopping $DESC:
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo \
- --pidfile /var/run/pure-ftpd/pure-ftpd.pid
+ --pidfile $PIDFILE
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo --exec $UPLOADDAEMON
echo $NAME.
;;
@@ -84,11 +90,11 @@
test $STANDALONE_OR_INETD = standalone || exit 0
echo -n Restarting $DESC:
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo \
- --pidfile /var/run/pure-ftpd/pure-ftpd.pid
+ --pidfile $PIDFILE
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo --exec $UPLOADDAEMON
sleep 1
- start-stop-daemon --start $SSDAEMONLOGOPTS --pidfile \
- /var/run/pure-ftpd/pure-ftpd.pid --exec $WRAPPER -- $SUFFIX
+ start-stop-daemon --start $SSDAEMONLOGOPTS --pidfile $PIDFILE \
+ --exec $WRAPPER -- $SUFFIX
start_uploadscript Restarting
;;
*)
Bug#505982: Missing status action in pure-ftpd init script
Package: pure-ftpd Severity: wishlist Version: 1.0.21-11.4 Tags: patch User: [EMAIL PROTECTED] Usertags: origin-ubuntu ubuntu-patch jaunty The pure-ftpd init script doesn't provide a status action to query the state of the daemon. The following proposed patch leverages the new status_of_proc helper provided in lsb-base (= 3.2-14) to provide a status action. -- Thierry Carrez --- debian/tomcat5.5.init.old 2008-11-14 15:30:23.0 +0100 +++ debian/tomcat5.5.init 2008-11-14 15:30:47.0 +0100 @@ -196,8 +196,10 @@ if [ -f $CATALINA_PID ]; then log_success_msg $DESC is not running, but pid file exists. + exit 1 else log_success_msg $DESC is not running. + exit 3 fi else log_success_msg $DESC is running with pid `cat $CATALINA_PID`
Bug#505982: Oops, here is the good patch
Sorry, wrong patch attached. here is the good one.
--
Thierry Carrez
diff -ruN pure-ftpd-1.0.21.orig/debian/control pure-ftpd-1.0.21/debian/control
--- pure-ftpd-1.0.21.orig/debian/control 2008-11-17 14:08:00.0 +0100
+++ pure-ftpd-1.0.21/debian/control 2008-11-17 14:04:29.0 +0100
@@ -18,7 +18,7 @@
Package: pure-ftpd
Architecture: any
-Depends: pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
+Depends: lsb-base (= 3.2-14), pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
Provides: ftp-server
Conflicts: ftp-server
Replaces: ftp-server
@@ -33,7 +33,7 @@
Package: pure-ftpd-mysql
Architecture: any
-Depends: pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
+Depends: lsb-base (= 3.2-14), pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
Provides: ftp-server, pure-ftpd
Conflicts: ftp-server, pure-ftpd
Replaces: ftp-server, pure-ftpd
@@ -48,7 +48,7 @@
Package: pure-ftpd-postgresql
Architecture: any
-Depends: pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
+Depends: lsb-base (= 3.2-14), pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
Provides: ftp-server, pure-ftpd
Conflicts: ftp-server, pure-ftpd
Replaces: ftp-server, pure-ftpd
@@ -63,7 +63,7 @@
Package: pure-ftpd-ldap
Architecture: any
-Depends: pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
+Depends: lsb-base (= 3.2-14), pure-ftpd-common (=${source:Version}), ${shlibs:Depends}
Provides: ftp-server, pure-ftpd
Conflicts: ftp-server, pure-ftpd
Replaces: ftp-server, pure-ftpd
diff -ruN pure-ftpd-1.0.21.orig/debian/pure-ftpd.init.d pure-ftpd-1.0.21/debian/pure-ftpd.init.d
--- pure-ftpd-1.0.21.orig/debian/pure-ftpd.init.d 2008-11-17 14:08:00.0 +0100
+++ pure-ftpd-1.0.21/debian/pure-ftpd.init.d 2008-11-17 14:09:34.0 +0100
@@ -18,6 +18,9 @@
UDDESC=ftp upload handler
WRAPPER=/usr/sbin/pure-ftpd-wrapper
+# load LSB init-functions to get status_of_proc helper
+. /lib/lsb/init-functions
+
# try to figure with suffix this script is called,
# $0 might be a symlink pointing to this script
if [ -h $0 ]; then
@@ -91,9 +94,12 @@
/var/run/pure-ftpd/pure-ftpd.pid --exec $WRAPPER -- $SUFFIX
start_uploadscript Restarting
;;
+ status)
+ status_of_proc -p /var/run/pure-ftpd/pure-ftpd.pid $DAEMON $NAME exit 0 || exit $?
+ ;;
*)
N=/etc/init.d/$NAME
- echo Usage: $N {start|stop|restart|force-reload} 2
+ echo Usage: $N {start|stop|restart|force-reload|status} 2
exit 1
;;
esac
Bug#495235: Tomcat 5.5 still doesn't accept JREs
reopen 495235 severity important thanks The applied fix allows tomcat5.5 to run with openjdk-6-jdk, however it is not enough to make it accept openjdk-6-jre for running (which is the title of this bug). There is a check in tomcat5.5.init that ensures that the chosen JVM is a JDK and not a JRE. That check needs to be removed if you want to support running with a JRE (using libecj-java as the JSP compiler). See http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;filename=jre.diff;att=1;bug=495235 for a patch. -- Thierry Carrez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505709: status initscript action should not always returns 0
Package: tomcat5.5 Severity: minor Version: 5.5.26-5 Tags: patch User: [EMAIL PROTECTED] Usertags: origin-ubuntu jaunty Calling Tomcat 5.5 status initscript action always returns 0. It should return following the LSB rules [1], in particular it should return 3 if Tomcat is not running (or 1 if Tomcat is not running and the PID file exists). See attached patch, which adds the relevant exit codes. [1] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html -- Thierry Carrez --- debian/tomcat5.5.init.old 2008-11-14 15:30:23.0 +0100 +++ debian/tomcat5.5.init 2008-11-14 15:30:47.0 +0100 @@ -196,8 +196,10 @@ if [ -f $CATALINA_PID ]; then log_success_msg $DESC is not running, but pid file exists. + exit 1 else log_success_msg $DESC is not running. + exit 3 fi else log_success_msg $DESC is running with pid `cat $CATALINA_PID`
Bug#499359: Proposed patch
Please find attached the patch I just submitted an Ubuntu bug that covers the same issue [1]. Note that libpam-smbpass also needs /var/lib/samba to be created, or else it will fail rather badly (blocking all logins by segfaulting). Hope this helps. [1] https://bugs.launchpad.net/ubuntu/+source/samba/+bug/260687 -- Thierry Carrez Ubuntu server team || Canonical Ltd. diff -u samba-3.2.3/debian/samba-common.dirs samba-3.2.3/debian/samba-common.dirs --- samba-3.2.3/debian/samba-common.dirs +++ samba-3.2.3/debian/samba-common.dirs @@ -2,4 +2,5 @@ etc/dhcp3/dhclient-enter-hooks.d var/cache/samba +var/lib/samba var/log/samba var/run/samba diff -u samba-3.2.3/debian/samba.postrm samba-3.2.3/debian/samba.postrm --- samba-3.2.3/debian/samba.postrm +++ samba-3.2.3/debian/samba.postrm @@ -2,7 +2,7 @@ if [ $1 = purge ]; then rm -rf /var/cache/samba/browse.dat - rm -rf /var/lib/samba/ + rm -rf /var/lib/samba/printers/ rm -rf /var/log/samba/log.nmbd* /var/log/samba/log.smbd* /var/log/samba/cores/ rm -rf /var/run/samba/nmbd.pid /var/run/samba/smbd.pid /var/run/samba/*.tdb
Bug#494504: Patches
Digging in the Apache Tomcat SVN and commit logs revealed the following 5.5.x fixes: CVE-2008-1232: http://svn.apache.org/viewvc?rev=680947view=rev CVE-2008-2370: http://svn.apache.org/viewvc?view=revrevision=680949 CVE-2008-2938: http://svn.apache.org/viewvc?view=revrevision=681065 Hopes this helps. -- Thierry Carrez Ubuntu server team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498487: Superfluous /etc/tomcat5.5/tomcat5.5 - /etc/tomcat5.5 link
Package: tomcat5.5 Severity: minor Version: 5.5.26-3 Tags: patch User: [EMAIL PROTECTED] Usertags: origin-ubuntu intrepid A superfluous /etc/tomcat5.5/tomcat5.5 - /etc/tomcat5.5 link is created on install. This is confusing, and makes purging files fail because /etc/tomcat5.5 is never empty. Analysis: tomcat5.5.links creates a link : /var/lib/tomcat5.5/conf - /etc/tomcat5.5 but then in tomcat5.5.postinst there is : ln -sf /etc/tomcat5.5 /var/lib/tomcat5.5/conf This creates a tomcat5.5 link inside /var/lib/tomcat5.5/conf, which points to /etc/tomcat5.5. Final result is a /etc/tomcat5.5/tomcat5.5 - /etc/tomcat5.5 link. Obvious solution is to drop the ln -sf in postinst, see attached patch. -- Thierry Carrez diff -u tomcat5.5-5.5.26/debian/tomcat5.5.postinst tomcat5.5-5.5.26/debian/tomcat5.5.postinst --- tomcat5.5-5.5.26/debian/tomcat5.5.postinst +++ tomcat5.5-5.5.26/debian/tomcat5.5.postinst @@ -25,7 +25,6 @@ chmod -R 770 /etc/tomcat5.5 chmod 750 /var/log/tomcat5.5 /etc/tomcat5.5 chmod 700 /var/cache/tomcat5.5 - ln -sf /etc/tomcat5.5 /var/lib/tomcat5.5/conf # Moving conffiles. if dpkg --compare-versions $2 le 5.5.25-4; then
Bug#495235: tomcat5.5 doesn't recognize openjdk-6-jre for running
Hello Marcus,
I've been working on this issue for the Ubuntu version of tomcat5.5 to
try to make sure it would run with openjdk-6-jre-headless which is our
target for default java server runtime environment.
Since Tomcat uses libecj-java to compile JSPs, it doesn't really need a
JDK. So I removed the JDK test in the init script and adjusted deps in
the control file to use the new java-common virtuals (and moved the
depends to libtomcat5.5-java as it is in debian policy to have the
lib*-java depend on a runtime).
I also adjusted the JDK_DIRS list to preferably use the one in
/usr/lib/jvm/default-java.
Please see attached patch, applies to current 5.5.26-3.
Hoping this helps, let me know what you think of it.
--
Thierry Carrez
Ubuntu server team
diff -u tomcat5.5-5.5.26/debian/control tomcat5.5-5.5.26/debian/control
--- tomcat5.5-5.5.26/debian/control
+++ tomcat5.5-5.5.26/debian/control
@@ -12,8 +13,8 @@
Package: tomcat5.5
Architecture: all
-Depends: java-gcj-compat-dev (= 1.0.30-5) | java2-runtime, libtomcat5.5-java (= ${source:Version}), adduser (= 3.34), libecj-java, jsvc (= 1.0.2~svn20061127-6)
-Suggests: java-virtual-machine, libapache2-mod-jk, tomcat5.5-webapps (= ${source:Version}), tomcat5.5-admin (= ${source:Version})
+Depends: libtomcat5.5-java (= ${source:Version}), adduser (= 3.34), jsvc (= 1.0.2~svn20061127-6)
+Suggests: libapache2-mod-jk, tomcat5.5-webapps (= ${source:Version}), tomcat5.5-admin (= ${source:Version})
Conflicts: tomcat5.5-admin (= 5.5.20-5)
Description: Servlet and JSP engine
Apache Tomcat is the reference implementation for the Java Servlet
@@ -25,7 +26,7 @@
Package: libtomcat5.5-java
Architecture: all
-Depends: libxerces2-java, libservlet2.4-java, libcommons-el-java, ant, libcommons-launcher-java, libcommons-logging-java, libcommons-modeler-java (= 2.0), libmx4j-java, libcommons-collections3-java, libcommons-dbcp-java, libcommons-pool-java
+Depends: default-jre-headless | java2-runtime-headless, libecj-java, libxerces2-java, libservlet2.4-java, libcommons-el-java, ant, libcommons-launcher-java, libcommons-logging-java, libcommons-modeler-java (= 2.0), libmx4j-java, libcommons-collections3-java, libcommons-dbcp-java, libcommons-pool-java
Suggests: tomcat5.5
Description: Java Servlet engine -- core libraries
Apache Tomcat is the reference implementation for the Java Servlet
diff -u tomcat5.5-5.5.26/debian/tomcat5.5.init tomcat5.5-5.5.26/debian/tomcat5.5.init
--- tomcat5.5-5.5.26/debian/tomcat5.5.init
+++ tomcat5.5-5.5.26/debian/tomcat5.5.init
@@ -48,17 +48,12 @@
# The first existing directory is used for JAVA_HOME (if JAVA_HOME is not
# defined in $DEFAULT)
-JDK_DIRS=/usr/lib/jvm/java-6-sun /usr/lib/jvm/java-1.5.0-sun /usr/lib/j2sdk1.5-sun /usr/lib/j2sdk1.5-ibm /usr/lib/j2sdk1.4-sun /usr/lib/j2sdk1.4-blackdown /usr/lib/j2se/1.4 /usr/lib/j2sdk1.4-ibm /usr/lib/j2sdk1.3-sun /usr/lib/j2sdk1.3-blackdown /usr/lib/jvm/java-gcj /usr/lib/kaffe
+JDK_DIRS=/usr/lib/jvm/default-java /usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-cacao /usr/lib/jvm/java-6-sun /usr/lib/jvm/java-1.5.0-sun /usr/lib/jvm/java-gcj
# Look for the right JVM to use
for jdir in $JDK_DIRS; do
if [ -r $jdir/bin/java -a -z ${JAVA_HOME} ]; then
- JAVA_HOME_TMP=$jdir
- # checks for a real JDK like environment, needed to check if
- # really the java-gcj-compat-dev package is installed
- if [ -r $jdir/bin/jdb ]; then
- JAVA_HOME=$JAVA_HOME_TMP
- fi
+ JAVA_HOME=$jdir
fi
done
export JAVA_HOME
Bug#498493: Missing status action in init script
Package: openvpn
Severity: wishlist
Version: 2.1~rc9-3
Tags: patch
User: [EMAIL PROTECTED]
Usertags: origin-ubuntu ubuntu-patch intrepid
The init script for openvpn is missing a status action. It is a little
complex because the init script can start zero-to-many VPNs based on
configuration.
The proposed implementation is to have the status action list the VPNs
available and their specific status, then consider it a global success
when all VPNs that should be autostarted are running, and failure
otherwise. If no VPN is configured, then it should be considered a failure.
See proposed patch to init script.
Hopes this helps !
--
Thierry Carrez
diff -ruN openvpn-2.1~rc9.orig/debian/control openvpn-2.1~rc9/debian/control
--- openvpn-2.1~rc9.orig/debian/control 2008-09-10 15:07:19.0 +0200
+++ openvpn-2.1~rc9/debian/control 2008-09-10 15:07:08.0 +0200
@@ -7,7 +7,7 @@
Package: openvpn
Architecture: any
-Depends: debconf | debconf-2.0, ${shlibs:Depends}, libssl0.9.8 (= 0.9.8g-9), openssl-blacklist (= 0.4), openvpn-blacklist
+Depends: debconf | debconf-2.0, ${shlibs:Depends}, libssl0.9.8 (= 0.9.8g-9), openssl-blacklist (= 0.4), openvpn-blacklist, lsb-base (= 3.2-14)
Recommends: net-tools
Suggests: openssl, resolvconf
Description: virtual private network daemon
diff -ruN openvpn-2.1~rc9.orig/debian/openvpn.init.d openvpn-2.1~rc9/debian/openvpn.init.d
--- openvpn-2.1~rc9.orig/debian/openvpn.init.d 2008-09-10 15:07:19.0 +0200
+++ openvpn-2.1~rc9/debian/openvpn.init.d 2008-09-10 15:05:41.0 +0200
@@ -189,8 +189,70 @@
done
log_end_msg 0
;;
+status)
+ GLOBAL_STATUS=0
+ if test -z $2 ; then
+# We want status for all defined VPNs.
+# Returns success if all autostarted VPNs are defined and running
+if test x$AUTOSTART = xnone ; then
+ # Consider it a failure if AUTOSTART=none
+ log_warning_msg No VPN autostarted
+ GLOBAL_STATUS=1
+else
+ if ! test -z $AUTOSTART -o x$AUTOSTART = xall ; then
+# Consider it a failure if one of the autostarted VPN is not defined
+for VPN in $AUTOSTART ; do
+ if ! test -f $CONFIG_DIR/$VPN.conf ; then
+log_warning_msg VPN '$VPN' is in AUTOSTART but is not defined
+GLOBAL_STATUS=1
+ fi
+done
+ fi
+fi
+for CONFIG in `cd $CONFIG_DIR; ls *.conf 2 /dev/null`; do
+ NAME=${CONFIG%%.conf}
+ # Is it an autostarted VPN ?
+ if test -z $AUTOSTART -o x$AUTOSTART = xall ; then
+AUTOVPN=1
+ else
+if test x$AUTOSTART = xnone ; then
+ AUTOVPN=0
+else
+ AUTOVPN=0
+ for VPN in $AUTOSTART; do
+if test x$VPN = x$NAME ; then
+ AUTOVPN=1
+fi
+ done
+fi
+ fi
+ if test x$AUTOVPN = x1 ; then
+# If it is autostarted, then it contributes to global status
+status_of_proc -p /var/run/openvpn.${NAME}.pid openvpn VPN '${NAME}' || GLOBAL_STATUS=1
+ else
+status_of_proc -p /var/run/openvpn.${NAME}.pid openvpn VPN '${NAME}' (non autostarted) || true
+ fi
+done
+ else
+# We just want status for specified VPNs.
+# Returns success if all specified VPNs are defined and running
+while shift ; do
+ [ -z $1 ] break
+ NAME=$1
+ if test -e $CONFIG_DIR/$NAME.conf ; then
+# Config exists
+status_of_proc -p /var/run/openvpn.${NAME}.pid openvpn VPN '${NAME}' || GLOBAL_STATUS=1
+ else
+# Config does not exist
+log_warning_msg VPN '$NAME': missing $CONFIG_DIR/$NAME.conf file !
+GLOBAL_STATUS=1
+ fi
+done
+ fi
+ exit $GLOBAL_STATUS
+ ;;
*)
- echo Usage: $0 {start|stop|reload|restart|force-reload|cond-restart} 2
+ echo Usage: $0 {start|stop|reload|restart|force-reload|cond-restart|status} 2
exit 1
;;
esac
Bug#413906: Tomcat 6 full server stack packaging
Since the source package already exists, I have been told it's probably better to file this as a bug against the current tomcat6 package rather than as part of the Tomcat6 ITP bug. This full server stack packaging proposal is now tracked in bug #494674: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494674 Sorry for the noise. -- Thierry Carrez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413906: Tomcat 6 full server stack packaging
Everyone, I've been working on a full server stack packaging for Tomcat 6 to land in Ubuntu Intrepid Ibex, based on the great work done in Debian on Tomcat 5.5 and the preliminary work of David Pashley posted here. This is an extension of the current tomcat6 source package. The spec covering the work is accessible at: https://wiki.ubuntu.com/Tomcat6StackSpec Your comments, by mail or directly on the Wiki, are greatly welcomed. The packaging is still work in progress and hasn't been submitted for inclusion in Ubuntu yet. I wanted to involve the Tomcat Debian maintainers early in the process so that you can make remarks that I can fix before inclusion. I would be very happy if you could take a look at the packaging work done so far and let me know if there is anything I should change to make it more likely for Debian to adopt it at one point in the future. You can access the debian/ bits at: http://launchpadlibrarian.net/16559607/tomcat6_6.0.16-1ubuntu1%7Eppa2.diff.gz or through the bzr branch at: https://code.launchpad.net/~tcarrez/tomcat6/full-stack-packaging You can also install debs directly through the PPA described at: https://launchpad.net/~tcarrez/+archive Thanks ! -- Thierry Carrez Ubuntu Server Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486455: dnsmasq: incorrect log_msg_end calls in init script
Package: dnsmasq Version: 2.42-2 Severity: normal Tags: patch In bug 473117 you included an Ubuntu fix making use of log_*_msg functions rather than calling echo in the init script. Eric Shattow discovered that this fix makes improper calls to a log_msg_end function. The attached patch (from Eric Shattow) corrects the typo. Regards, -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-19-generic (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- dnsmasq-2.42/debian/init.orig 2008-06-16 10:07:27.0 +0200 +++ dnsmasq-2.42/debian/init2008-06-16 10:08:09.0 +0200 @@ -214,10 +214,10 @@ log_daemon_msg Checking $DESC $NAME status case $? in - 0) log_warning_msg running ; log_msg_end 0; exit 0 ;; - 1) log_warning_msg dead, pid file exists ; log_msg_end 1; exit 1 ;; - 3) log_warning_msg not running ; log_msg_end 3; exit 3 ;; - *) log_warning_msg unknown ; log_msg_end 4; exit 4 ;; + 0) log_warning_msg running ; log_end_msg 0; exit 0 ;; + 1) log_warning_msg dead, pid file exists ; log_end_msg 1; exit 1 ;; + 3) log_warning_msg not running ; log_end_msg 3; exit 3 ;; + *) log_warning_msg unknown ; log_end_msg 4; exit 4 ;; esac ;; *)
Bug#482179: Comment on bug 482179
Tags: patch
In fact the error comes from the configure script in nagios2 that has
errors in the tests that make it ignore the --with-mail option (and
build the config files with /bin/mail as a default).
This is fixed in the configure used in nagios3, and I backported the
fixes for nagios2. The patch also changes the cfg-commands.cfg.diff file
accordingly so that it doesn't break with the new mail command value.
Please see attached patch.
Regards,
--
Thierry (koon)
diff -u nagios2-2.11/debian/cfg-commands.cfg.diff nagios2-2.11/debian/cfg-commands.cfg.diff
--- nagios2-2.11/debian/cfg-commands.cfg.diff
+++ nagios2-2.11/debian/cfg-commands.cfg.diff
@@ -180,8 +180,8 @@
# 'host-notify-by-email' command definition
define command{
command_name host-notify-by-email
-- command_line /usr/bin/printf %b * Nagios 2.11 *\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n | /bin/mail -s Host $HOSTSTATE$ alert for $HOSTNAME$! $CONTACTEMAIL$
-+ command_line /usr/bin/printf %b * Nagios *\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n | /bin/mail -s Host $HOSTSTATE$ alert for $HOSTNAME$! $CONTACTEMAIL$
+- command_line /usr/bin/printf %b * Nagios 2.11 *\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n | /usr/bin/mail -s Host $HOSTSTATE$ alert for $HOSTNAME$! $CONTACTEMAIL$
++ command_line /usr/bin/printf %b * Nagios *\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n | /usr/bin/mail -s Host $HOSTSTATE$ alert for $HOSTNAME$! $CONTACTEMAIL$
}
@@ -189,8 +189,8 @@
# 'notify-by-email' command definition
define command{
command_name notify-by-email
-- command_line /usr/bin/printf %b * Nagios 2.11 *\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$ | /bin/mail -s ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** $CONTACTEMAIL$
-+ command_line /usr/bin/printf %b * Nagios *\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$ | /bin/mail -s ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** $CONTACTEMAIL$
+- command_line /usr/bin/printf %b * Nagios 2.11 *\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$ | /usr/bin/mail -s ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** $CONTACTEMAIL$
++ command_line /usr/bin/printf %b * Nagios *\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$ | /usr/bin/mail -s ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** $CONTACTEMAIL$
}
diff -u nagios2-2.11/debian/patches/00list nagios2-2.11/debian/patches/00list
--- nagios2-2.11/debian/patches/00list
+++ nagios2-2.11/debian/patches/00list
@@ -2,0 +3 @@
+30_configure_with_mail_fix.dpatch
only in patch2:
unchanged:
--- nagios2-2.11.orig/debian/patches/30_configure_with_mail_fix.dpatch
+++ nagios2-2.11/debian/patches/30_configure_with_mail_fix.dpatch
@@ -0,0 +1,28 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 30_configure_with_mail_fix.dpatch by Thierry Carrez [EMAIL PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: No description.
+
[EMAIL PROTECTED]@
+diff -urNad nagios2-2.11~/configure nagios2-2.11/configure
+--- nagios2-2.11~/configure 2008-03-12 15:01:03.0 +0100
nagios2-2.11/configure 2008-06-12 14:57:15.0 +0200
+@@ -4866,7 +4866,7 @@
+ else
+ MAIL_PROG=no
+ fi;
+-if test MAIL_PROG=no; then
++if test x$MAIL_PROG = xno; then
+ # Extract the first word of mail, so it can be a program name with args.
+ set dummy mail; ac_word=$2
+ echo $as_me:$LINENO: checking for $ac_word 5
+@@ -4907,7 +4907,7 @@
+ fi
+
+ fi
+-if test x$MAIL_PROG=x; then
++if test x$MAIL_PROG = x; then
+ MAIL_PROG=/bin/mail
+ fi
+
Bug#486100: unzip: 5.52-11 misses large file support
Package: unzip Version: 5.52-11 Severity: wishlist Tags: patch unzip can be compiled to support large files (2Gb) by defining -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64. This has been reported and fixed in the past [1] but the versions since 5.52-10 have lost that change. You should consider re-enabling it in the latest version. Please find attached the obvious patch. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192253 -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-19-generic (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages unzip depends on: ii libc6 2.7-10ubuntu3 GNU C Library: Shared libraries unzip recommends no packages. -- no debconf information --- 5.52-11/debian/rules 2008-03-21 11:47:22.0 + +++ 5.52-11ubuntu1/debian/rules 2008-03-21 11:47:29.0 + @@ -6,7 +6,7 @@ history = History.552 CC = gcc CFLAGS = -g -Wall $$(getconf LFS_CFLAGS) -DEFINES = -DACORN_FTYPE_NFS -DWILD_STOP_AT_DIR +DEFINES = -DACORN_FTYPE_NFS -DWILD_STOP_AT_DIR -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 INSTALL_PROGRAM = install ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
Bug#486100: unzip: 5.52-11 misses large file support
Santiago Vila wrote: What do you mean by have lost that change? Please look at the source. The current package uses getconf LFS_CFLAGS, which is the right way to do that. Oops. You are right. For some reason I thought you needed -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 explicitely. Sorry for the waste of your time and bandwidth. -- Thierry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485951: missing Conflicts: line for libcgi-dev
Package: libcgi-dev Version: 1.0-6 Severity: normal cgilib and libcgi-dev both provide the /usr/lib/libcgi.a file. Bug #462944 fixed the conflict in cgilib, but the Conflicts: line should also be added in libcgi control file (for libcgi-dev). -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-19-generic (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485439: nagios3: XSS vulnerabilities in CGI scripts (CVE-2007-5803)
Package: nagios3 Version: 3.0.1-1 Severity: grave Tags: security Justification: user security hole Multiple cross-site scripting (XSS) vulnerabilities in CGI programs in Nagios might allow remote attackers to inject arbitrary web script or HTML via unspecified vectors. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2007-5803 Nagios 3.0.2 was released to address this issue in the 3.x line. http://www.nagios.org/development/history/nagios-3x.php -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-18-generic (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
