From owner-freebsd-stable@freebsd.org Sun Dec 20 04:59:18 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E345A4D2F0 for ; Sun, 20 Dec 2015 04:59:18 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 70A261AA2 for ; Sun, 20 Dec 2015 04:59:18 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3EBE9963 for ; Sun, 20 Dec 2015 04:59:18 +0000 (UTC) Date: Sun, 20 Dec 2015 04:59:17 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: freebsd-stable@freebsd.org Message-ID: <2034784120.23.1450587557911.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <798019824.22.1450576499305.JavaMail.jenkins@jenkins-9.freebsd.org> References: <798019824.22.1450576499305.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #2882 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 04:59:18 -0000 See From owner-freebsd-stable@freebsd.org Sun Dec 20 07:41:35 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E22BCA40669 for ; Sun, 20 Dec 2015 07:41:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D5F2412ED for ; Sun, 20 Dec 2015 07:41:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6DD2A9C5 for ; Sun, 20 Dec 2015 07:41:35 +0000 (UTC) Date: Sun, 20 Dec 2015 07:41:35 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: freebsd-stable@freebsd.org Message-ID: <638857541.25.1450597295115.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1697614207.24.1450587608492.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1697614207.24.1450587608492.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #2884 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 07:41:36 -0000 See From owner-freebsd-stable@freebsd.org Sun Dec 20 16:45:27 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4764CA4E1BF for ; Sun, 20 Dec 2015 16:45:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3A51D129C for ; Sun, 20 Dec 2015 16:45:27 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 53ED8B06 for ; Sun, 20 Dec 2015 16:45:27 +0000 (UTC) Date: Sun, 20 Dec 2015 16:45:27 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: freebsd-stable@freebsd.org Message-ID: <1478923867.34.1450629927287.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1394100763.27.1450619559166.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1394100763.27.1450619559166.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #2887 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 16:45:27 -0000 See From owner-freebsd-stable@freebsd.org Sun Dec 20 23:21:25 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDADDA4E056 for ; Sun, 20 Dec 2015 23:21:25 +0000 (UTC) (envelope-from robertames@hotmail.com) Received: from BLU004-OMC2S5.hotmail.com (blu004-omc2s5.hotmail.com [65.55.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CF0D1EBA for ; Sun, 20 Dec 2015 23:21:25 +0000 (UTC) (envelope-from robertames@hotmail.com) Received: from BLU177-W45 ([65.55.111.72]) by BLU004-OMC2S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 20 Dec 2015 15:21:18 -0800 X-TMN: [Xpxr4wg9YWaHJpL34pVovxMSrc04XBSh] X-Originating-Email: [robertames@hotmail.com] Message-ID: From: Robert Ames To: "freebsd-stable@freebsd.org" Subject: calendar -a failing in 10.2-RELEASE Date: Sun, 20 Dec 2015 18:21:17 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2015 23:21:18.0103 (UTC) FILETIME=[20FFA270:01D13B7D] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 23:21:26 -0000 In 10.2-RELEASE running "calendar -a" as root fails when user calendar file= s have a #include line. This worked in 10.0-RELEASE (and before). From my= limited testing I think it's looking for the included files relative to ro= ot's home directory and not the user's home directory. The svn repository = shows some changes in this area in recent releases. Not sure if this new b= ehavior is intentional. $ uname -a FreeBSD freebsd.example.com 10.2-RELEASE FreeBSD 10.2-RELEASE #0: Sun Dec 2= 0 10:00:14 CST 2015 root@freebsd.example.com:/usr/obj/usr/src/sys/GENER= IC i386 $ id uid=3D1000(robert) gid=3D20(staff) groups=3D20(staff)=2C0(wheel)=2C5(operat= or) $ date Sun Dec 20 16:47:44 CST 2015 $ cat ~/.calendar/calendar=20 #include $ cat ~/.calendar/moredates=20 12/20 Today is December 20 $ calendar Dec 20 Today is December 20 root@freebsd# id uid=3D0(root) gid=3D0(wheel) groups=3D0(wheel)=2C5(operator) root@freebsd# calendar -a calendar: can't open calendar file "moredates" = From owner-freebsd-stable@freebsd.org Mon Dec 21 04:07:19 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 021FEA4DD8F for ; Mon, 21 Dec 2015 04:07:19 +0000 (UTC) (envelope-from ike@michaeleichorn.com) Received: from mx1.eichornenterprises.com (mx1.eichornenterprises.com [104.236.13.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.eichornenterprises.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A314F1E8B for ; Mon, 21 Dec 2015 04:07:17 +0000 (UTC) (envelope-from ike@michaeleichorn.com) Received: from smtp.eichornenterprises.com (cpe-184-59-147-149.neo.res.rr.com [184.59.147.149]) by mx1.eichornenterprises.com (OpenSMTPD) with ESMTP id f6fdb2ae; Sun, 20 Dec 2015 23:07:14 -0500 (EST) Received: by smtp.eichornenterprises.com (OpenSMTPD) with ESMTPSA id b4eca890 TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Sun, 20 Dec 2015 23:07:13 -0500 (EST) Message-ID: <1450670833.594.12.camel@michaeleichorn.com> Subject: Re: calendar -a failing in 10.2-RELEASE From: "Michael B. Eichorn" To: Robert Ames , "freebsd-stable@freebsd.org" Date: Sun, 20 Dec 2015 23:07:13 -0500 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-uxHAU3xNoVg2C5jLyJK2" X-Mailer: Evolution 3.18.2 Mime-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 04:07:19 -0000 --=-uxHAU3xNoVg2C5jLyJK2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2015-12-20 at 18:21 -0500, Robert Ames wrote: > In 10.2-RELEASE running "calendar -a" as root fails when user > calendar files have a #include line.=C2=A0=C2=A0This worked in 10.0-RELEA= SE > (and before).=C2=A0=C2=A0From my limited testing I think it's looking for= the > included files relative to root's home directory and not the user's > home directory.=C2=A0=C2=A0The svn repository shows some changes in this = area > in recent releases.=C2=A0=C2=A0Not sure if this new behavior is intention= al. >=20 > $ uname -a > FreeBSD freebsd.example.com 10.2-RELEASE FreeBSD 10.2-RELEASE #0: Sun > Dec 20 10:00:14 CST 2015=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0root@freebsd.exampl= e.com:/usr/obj/usr/sr > c/sys/GENERIC=C2=A0=C2=A0i386 > $ id > uid=3D1000(robert) gid=3D20(staff) groups=3D20(staff),0(wheel),5(operator= ) > $ date > Sun Dec 20 16:47:44 CST 2015 > $ cat ~/.calendar/calendar=20 > #include > $ cat ~/.calendar/moredates=20 > 12/20=C2=A0=C2=A0=C2=A0Today is December 20 > $ calendar > Dec 20=C2=A0=C2=A0Today is December 20 >=20 > root@freebsd# id > uid=3D0(root) gid=3D0(wheel) groups=3D0(wheel),5(operator) > root@freebsd# calendar -a > calendar: can't open calendar file "moredates" I can confirm the above behavior on my 10.2R system. And since it is documented as a working option `calendar -a` should probably be fixed. But for the record: $ cat=C2=A0/etc/periodic/daily/300.calendar ... # `calendar -a' needs to die. Why? Because it's a bad idea, particular # with networked home directories, but also in general.=C2=A0=C2=A0If you w= ant the # output of `calendar' mailed to you, set up a cron job to do it, # or run it from your ~/.profile or ~/.login. ... --=-uxHAU3xNoVg2C5jLyJK2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEqAw ggYwMIIFGKADAgECAgMOXcYwDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQTAeFw0xNTA2MTMyMDI0NDZaFw0xNjA2MTQwMDM1NTBaMEgxHzAdBgNVBAMMFmlrZUBtaWNo YWVsZWljaG9ybi5jb20xJTAjBgkqhkiG9w0BCQEWFmlrZUBtaWNoYWVsZWljaG9ybi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJVdWALPz5h2s5zUQGIJYl6Vp8FPtZNko8q/3s crCsxXJLprMaDdpnqTsmkbmEfKvsqPQE6HVOpGxVRTl/tCm+VvouW9eY9ITMigb1OnHdU13CKO0j drgeU1nHst0qxwsIofRD7nC4dakT6exnrVndlBmLrf/bLPh2qOM8YK5qKK6m33fE7AyYrwiYAWFT 3fERI7LakjaabrIoS/Y1rCdL5FaCTMOlRbZyduc8HkrgjT2JW+i4fVcKyGL5gExBJWfS3q1uGFaB ie6pYtl8lZPtvN0JSfibP003RBoLgzqHJKW91RL0qNeDjKZi/5nrlU398l9UoVvLLO3KxoPBXKCx AgMBAAGjggLcMIIC2DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFJZqarc6CcrOs6eAwOgrMznk5ZWWMB8GA1UdIwQYMBaAFFNy 7ZKc4NrLAVx8fpY1TvLUuFGCMCEGA1UdEQQaMBiBFmlrZUBtaWNoYWVsZWljaG9ybi5jb20wggFM BgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh Y2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu Y2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBCwUAA4IBAQB4K8iQw+0FRn3xEnB3vIIu2Vi4C3ZGnOMWP90FFXLrZ6uAu9AK xVCjXUVP6nAEsOopTMu769vVecdBvg0KO2i5aTDTdTLX4g9d020g4OLWW1NiynAkX8oKqJLqZ53q vHK4zP4KWPS3bSqDWVCosTMfI+H6tkg+6G3gS0HHoHTLKZhIT3z6PQZAfeofM7ed6NOdAcj0J2lP ODHzzz7Y9x4wMwYJdidorzUDVYkNIkim8ak7hK9F60NadA5w/BirFATSlzRyV0h1tl6oNisEaQcq tGvy6UoCTDhzaJ7pQValfDXJ/A47P0hNj/CX/PmkY1wQHsEJz2pbh5lqteP/fO0rMIIGMDCCBRig AwIBAgIDDl3GMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTUwNjEzMjAyNDQ2WhcNMTYwNjE0MDAzNTUwWjBIMR8wHQYDVQQDDBZpa2VAbWljaGFlbGVpY2hv cm4uY29tMSUwIwYJKoZIhvcNAQkBFhZpa2VAbWljaGFlbGVpY2hvcm4uY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyVXVgCz8+YdrOc1EBiCWJelafBT7WTZKPKv97HKwrMVyS6az Gg3aZ6k7JpG5hHyr7Kj0BOh1TqRsVUU5f7Qpvlb6LlvXmPSEzIoG9Tpx3VNdwijtI3a4HlNZx7Ld KscLCKH0Q+5wuHWpE+nsZ61Z3ZQZi63/2yz4dqjjPGCuaiiupt93xOwMmK8ImAFhU93xESOy2pI2 mm6yKEv2NawnS+RWgkzDpUW2cnbnPB5K4I09iVvouH1XCshi+YBMQSVn0t6tbhhWgYnuqWLZfJWT 7bzdCUn4mz9NN0QaC4M6hySlvdUS9KjXg4ymYv+Z65VN/fJfVKFbyyztysaDwVygsQIDAQABo4IC 3DCCAtgwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBSWamq3OgnKzrOngMDoKzM55OWVljAfBgNVHSMEGDAWgBRTcu2SnODaywFc fH6WNU7y1LhRgjAhBgNVHREEGjAYgRZpa2VAbWljaGFlbGVpY2hvcm4uY29tMIIBTAYDVR0gBIIB QzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5n IHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBD QSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeG JWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8w OQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG 9w0BAQsFAAOCAQEAeCvIkMPtBUZ98RJwd7yCLtlYuAt2RpzjFj/dBRVy62ergLvQCsVQo11FT+pw BLDqKUzLu+vb1XnHQb4NCjtouWkw03Uy1+IPXdNtIODi1ltTYspwJF/KCqiS6med6rxyuMz+Clj0 t20qg1lQqLEzHyPh+rZIPuht4EtBx6B0yymYSE98+j0GQH3qHzO3nejTnQHI9CdpTzgx888+2Pce MDMGCXYnaK81A1WJDSJIpvGpO4SvRetDWnQOcPwYqxQE0pc0cldIdbZeqDYrBGkHKrRr8ulKAkw4 c2ie6UFWpXw1yfwOOz9ITY/wl/z5pGNcEB7BCc9qW4eZarXj/3ztKzCCBjQwggQcoAMCAQICAR4w DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1 NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7 zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8 VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+ jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQO Jebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB /wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5z dGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3Js MIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywGXLhjjF6uHLkjd02h cdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXltUfO4n4bGGdKo3awP Wp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8C h507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893 gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0 PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBm unwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2L L9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwF i2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhE puP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMYIDfzCCA3sCAQEwgZQwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDl3GMA0GCWCGSAFlAwQCAQUAoIIBuzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMjEwNDA3MTNaMC8GCSqGSIb3DQEJ BDEiBCBMFnJPdSVcaMixbEoAk7yfn2zALx1fVvQ7oaR4BmdzcjCBpQYJKwYBBAGCNxAEMYGXMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw5dxjCBpwYLKoZIhvcNAQkQAgsxgZeggZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDl3GMA0GCSqGSIb3DQEBAQUABIIBAKi2CS5q LGiiwvra5DkIWtKgwd01xw8VaKekgy2FrqaSOUUlfDxc/9YcUcFZuabxD8C7I0sBpjfIJNPnSl8E aodxCqkVXwklIt3BiOkxEavmN3FsSr1MJz0HxcJMSpqeSXbxiM/gQUqQxRVV8UCYUngzIx8V54PE kQiXoHpscJNeaKVSn//Tc0bHBzWop9em28XzzMenmNZmBz606EWaIWows+BI0WiGtWqEyK7rTsfC nn15V7rL4P+mYY/WCqeBMOneYRVQ0Oky+fPrU9RWbDvnz/7Q4O9l8dqpfoKaWtR+l4R/T/OBMm+F nFR/zkXIxZ+Xo3clQpkr/e4L/w/iXf4AAAAAAAA= --=-uxHAU3xNoVg2C5jLyJK2-- From owner-freebsd-stable@freebsd.org Tue Dec 22 17:05:14 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62F54A4E8D3; Tue, 22 Dec 2015 17:05:14 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 126A41770; Tue, 22 Dec 2015 17:05:13 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id tBMH57IP097108; Tue, 22 Dec 2015 12:05:07 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id tBMH57h1097105; Tue, 22 Dec 2015 12:05:07 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22137.33475.645324.203196@hergotha.csail.mit.edu> Date: Tue, 22 Dec 2015 12:05:07 -0500 From: Garrett Wollman To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Have I got this VIMAGE setup correct? X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 22 Dec 2015 12:05:07 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 17:05:14 -0000 The consensus when I asked seemed to be that VIMAGE+jail was the right combination to give every container its own private loopback interface, so I tried to build that. I noticed a few things: 1) The kernel prints out a warning message at boot time that VIMAGE is "highly experimental". Should I be concerned about running this in production? 2) Stopping jails with virtual network stacks generates warnings from UMA about memory being leaked. 3) It wasn't clear (or documented anywhere that I could see) how to get the host network set up properly. Obviously I'm not going to have a vlan for every single jail, so it seemed like what most people were doing was "bridge" along with a bunch of "epair" interfaces. I ended up with the following: network_interfaces="lo0 bridge0 bce0" autobridge_interfaces="bridge0" autobridge_bridge0="bce0 epair0a epair1a" cloned_interfaces="bridge0 epair0 epair1" ifconfig_bridge0="inet [deleted] netmask 0xffffff00" ifconfig_bridge0_ipv6="inet6 [deleted] prefixlen 64 accept_rtadv" ifconfig_bce0="up" ifconfig_epair0a="up" ifconfig_epair1a="up" The net.link.bridge.inherit_mac sysctl, which is documented in bridge(4), doesn't appear to work; I haven't yet verified that I can create a /etc/start_if.bridge0 to set the MAC address manually without breaking something else. The IPv6 stack regularly prints "in6_if2idlen: unknown link type (209)" to the console, which is annoying, and IPv6 on the host doesn't entirely work -- it accepts router advertisements but then gives [ENETUNREACH] trying to actually send packets to the default gateway. (IPv6 to the jails *does* work!) In each of the jails I have to manually configure a MAC address using /etc/start_if.epairNb to ensure that it's globally unique, but then everything seems to work. Does this match up with what other people have been doing? Anything I've missed? Any patches I should pull up to make this setup more reliable before I roll it out in production? -GAWollman From owner-freebsd-stable@freebsd.org Wed Dec 23 01:20:40 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D02ADA4EDAD; Wed, 23 Dec 2015 01:20:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92C491A0E; Wed, 23 Dec 2015 01:20:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-234-233.lns20.per1.internode.on.net [121.45.234.233]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tBN1KIwN028503 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2015 17:20:21 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Have I got this VIMAGE setup correct? To: Garrett Wollman , freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <22137.33475.645324.203196@hergotha.csail.mit.edu> From: Julian Elischer Message-ID: <5679F6CD.6020105@freebsd.org> Date: Wed, 23 Dec 2015 09:20:13 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <22137.33475.645324.203196@hergotha.csail.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 01:20:40 -0000 On 23/12/2015 1:05 AM, Garrett Wollman wrote: > The consensus when I asked seemed to be that VIMAGE+jail was the right > combination to give every container its own private loopback > interface, so I tried to build that. I noticed a few things: > > 1) The kernel prints out a warning message at boot time that VIMAGE is > "highly experimental". Should I be concerned about running this in > production? CYA only If you are not doing much that is super unusual you should be fine. > > 2) Stopping jails with virtual network stacks generates warnings from > UMA about memory being leaked. I haven't any information about that. > > 3) It wasn't clear (or documented anywhere that I could see) how to > get the host network set up properly. Obviously I'm not going to have > a vlan for every single jail, so it seemed like what most people were > doing was "bridge" along with a bunch of "epair" interfaces. I ended > up with the following: there are exapmples in /usr/share/examples/netgraph for some things.. I've never used the build in configuration stuff,, always handcoded it.. It's probably improved a lot since then. > network_interfaces="lo0 bridge0 bce0" > autobridge_interfaces="bridge0" > autobridge_bridge0="bce0 epair0a epair1a" > cloned_interfaces="bridge0 epair0 epair1" > ifconfig_bridge0="inet [deleted] netmask 0xffffff00" > ifconfig_bridge0_ipv6="inet6 [deleted] prefixlen 64 accept_rtadv" > ifconfig_bce0="up" > ifconfig_epair0a="up" > ifconfig_epair1a="up" > > The net.link.bridge.inherit_mac sysctl, which is documented in > bridge(4), doesn't appear to work; I haven't yet verified that I can > create a /etc/start_if.bridge0 to set the MAC address manually without > breaking something else. The IPv6 stack regularly prints > "in6_if2idlen: unknown link type (209)" to the console, which is > annoying, and IPv6 on the host doesn't entirely work -- it accepts > router advertisements but then gives [ENETUNREACH] trying to actually > send packets to the default gateway. (IPv6 to the jails *does* work!) > > In each of the jails I have to manually configure a MAC address using > /etc/start_if.epairNb to ensure that it's globally unique, but then > everything seems to work. > > Does this match up with what other people have been doing? Anything > I've missed? Any patches I should pull up to make this setup more > reliable before I roll it out in production? I haven't used it for a couple of years.. I know others are, so I'll let them pipe up. > > -GAWollman > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Wed Dec 23 04:42:36 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A33CA4F81C; Wed, 23 Dec 2015 04:42:36 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [199.15.120.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 462AC108B; Wed, 23 Dec 2015 04:42:35 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 3pQMMt0f0LzTB; Tue, 22 Dec 2015 22:42:34 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3pQMMs2JqkzqZ; Tue, 22 Dec 2015 22:42:33 -0600 (CST) Date: Tue, 22 Dec 2015 22:42:33 -0600 From: "Matthew D. Fuller" To: Garrett Wollman Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Have I got this VIMAGE setup correct? Message-ID: <20151223044233.GM33115@over-yonder.net> References: <22137.33475.645324.203196@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22137.33475.645324.203196@hergotha.csail.mit.edu> X-Editor: vi X-OS: FreeBSD X-Virus-Scanned: clamav-milter 0.99 at mail.tarragon.infocus-llc.com X-Virus-Status: Clean User-Agent: Mutt/1.5.24-fullermd.4 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 04:42:36 -0000 On Tue, Dec 22, 2015 at 12:05:07PM -0500 I heard the voice of Garrett Wollman, and lo! it spake thus: > > The consensus when I asked seemed to be that VIMAGE+jail was the > right combination to give every container its own private loopback > interface, so I tried to build that. I noticed a few things: I've got a server running a dozen or so VIMAGE jails, so I can at least chime in a little... > 1) The kernel prints out a warning message at boot time that VIMAGE > is "highly experimental". Should I be concerned about running this > in production? It hasn't blown up anything for me yet. > 2) Stopping jails with virtual network stacks generates warnings from > UMA about memory being leaked. I'm given to understand that's Known, and presumably Not Quite Trivial To Fix. Since I'm not starting/stopping jails repeatedly as a normal runtime thing, I'm ignoring it. If you were spinning jails up and down dynamically dozens of times a day, I'd want to look more closely at just what is leaking and why... > 3) It wasn't clear (or documented anywhere that I could see) how to > get the host network set up properly. Obviously I'm not going to > have a vlan for every single jail, so it seemed like what most > people were doing was "bridge" along with a bunch of "epair" > interfaces. I ended up with the following: Is what I'm doing, though I'm creating the epair's and adding them to the bridges in the setup script rather than rc.conf (exec.prestart in jail.conf), because that makes it a more manageable IME, and since I'm already doing a bunch of setup in the script anyway... > In each of the jails I have to manually configure a MAC address > using /etc/start_if.epairNb to ensure that it's globally unique, but > then everything seems to work. I hardcode (well, dynamically generated hardcoded) MAC addresses on the epair's in the setup script, since bit me hard when I was first setting it up. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@freebsd.org Wed Dec 23 06:17:39 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47149A4F15D; Wed, 23 Dec 2015 06:17:39 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 187811E4D; Wed, 23 Dec 2015 06:17:39 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by mail-io0-x234.google.com with SMTP id 186so210387612iow.0; Tue, 22 Dec 2015 22:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VUijpA3o8XIlNxyZyhB2c0gpBfltIX/MysBh5xhmCKg=; b=tPpF5Mg22f70/1Fd0NiKapRcqw7qbkzqZiULzYWG/f5jQwkA/ZbpQ00W9SPG7K3zPz YGQihn2bC6aIFUCYeejgBhAiUGbZ7RR7AgeWTQEll6ifr6tqkH1LIdrOBCJ2vbWHNbiM ZJW0X+1jWRFAW5UmWYoHT1riWFwG2REKAAKY6bl10ujrxy1JXr/rQaxGm4X/jwn8yqb5 I5Vtu4aL7ylTFFDn2KijGYi5+u0Ut5Ho77dIFnCAgAiMeUNhcp/vwO4b5Qa+Ix5dMMKa 17owlaQxvzTnI/d84EG4AC82vi+pZqKHbTpA3RLy1mvqcyVqLS3j310diUnHIPh5teNw UuRA== MIME-Version: 1.0 X-Received: by 10.107.156.21 with SMTP id f21mr24400183ioe.54.1450851458307; Tue, 22 Dec 2015 22:17:38 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.50.152.69 with HTTP; Tue, 22 Dec 2015 22:17:38 -0800 (PST) In-Reply-To: <22137.33475.645324.203196@hergotha.csail.mit.edu> References: <22137.33475.645324.203196@hergotha.csail.mit.edu> Date: Tue, 22 Dec 2015 22:17:38 -0800 X-Google-Sender-Auth: JckGZPGLWt-UwqQuMWEyaufoA_M Message-ID: Subject: Re: Have I got this VIMAGE setup correct? From: Craig Rodrigues To: Garrett Wollman Cc: FreeBSD Net , FreeBSD stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 06:17:39 -0000 On Tue, Dec 22, 2015 at 9:05 AM, Garrett Wollman wrote: > Any patches I should pull up to make this setup more > reliable before I roll it out in production? > > If you loook at CURRENT, bz@ has committed a few VIMAGE related fixes this week which you might want to look at. -- Craig From owner-freebsd-stable@freebsd.org Wed Dec 23 12:40:21 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B466A4E0F8 for ; Wed, 23 Dec 2015 12:40:21 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from mail16.tpgi.com.au (smtp-out16.tpgi.com.au [220.244.226.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL SHA256 CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F1B81483 for ; Wed, 23 Dec 2015 12:40:20 +0000 (UTC) (envelope-from ari@ish.com.au) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Wed, 23 Dec 2015 23:25:38 +1100 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail16.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id tBNCPa5m023221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Dec 2015 23:25:38 +1100 Received: from [10.242.2.26] (port=51261 helo=Aristedess-MacBook-Pro.local) by fish.ish.com.au with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aBiU2-0004TG-2v for freebsd-stable@freebsd.org; Wed, 23 Dec 2015 23:25:35 +1100 X-CTCH-RefID: str=0001.0A150204.567A92BF.00A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 To: freebsd-stable From: Aristedes Maniatis Subject: freebsd-update incorrect hashes X-Enigmail-Draft-Status: N1110 Message-ID: <567A92BD.5010105@ish.com.au> Date: Wed, 23 Dec 2015 23:25:33 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0hmoLn3a8VgwDSKRx8AHUuF68NcQviQJ9" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 12:40:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0hmoLn3a8VgwDSKRx8AHUuF68NcQviQJ9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've had problems with freebsd-update for many years now. It is by far th= e least reliable component of FreeBSD since I started with the operating = system back at 3.4 in 1999. Anyhow, I'm usually able to get past the exceedingly slow downloads and e= rrors to the upgrade process, but this time nothing I do will get me to t= he end. I've tried deleting /var/db/freebsd-update but several hours late= r I was at the same place again. The internet link is fast, but with a we= b proxy in this location, some downloads are slightly delayed while the v= irus scanner on the proxy does its thing. Perhaps 3-5 seconds delayed. I've run the update maybe a dozen times, progressing a few patches each t= ime. But it will always fetch 64 patches and then the number of files to = fetch will drop by 5-25 # freebsd-update upgrade -r 10.2 -s update.freebsd.org Looking up update.freebsd.org mirrors... 4 mirrors found. Fetching metadata signature for 9.3-RELEASE from update6.freebsd.org... d= one. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic world/base world/doc world/lib32 The following components of FreeBSD do not seem to be installed: world/games Does this look reasonable (y/n)? y Fetching metadata signature for 10.2-RELEASE from update6.freebsd.org... = done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. Fetching files from 9.3-RELEASE for merging... done. Preparing to download files... done. Fetching 64 patches.....10....20....30....40....50....60.. done. Applying patches... done. Fetching 1834 files... 109e9b1e3e8719aa81bc06e4c4c8dc642db7137ea8330f11f7= 0b8e91524afef7 has incorrect hash. Different file each time with an incorrect hash. So it will make very slo= w progress. Oddly, it had no issue downloading the 10,000 patches it need= ed, except for the last 64. No idea why it downloads them again and again= each time I attempt this. Are there any ways to manually dump the right files in the right place? W= hen I run phttpget by hand, I have no trouble very quickly downloading th= e files it seems to want. But how do I trick the system into skipping dow= nloading them again? phttpget has no man pages, so I've been unable to get it to spit out any = more verbose options. Thanks Ari --=20 --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A --0hmoLn3a8VgwDSKRx8AHUuF68NcQviQJ9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlZ6kr0ACgkQ72p9Lj5JECoXMgCeIv3GJkQA28LFJMy9uk1Lrxgi +PgAn1xpDjFIOFFM9GeeHOrtiviipX5I =EreE -----END PGP SIGNATURE----- --0hmoLn3a8VgwDSKRx8AHUuF68NcQviQJ9-- From owner-freebsd-stable@freebsd.org Wed Dec 23 13:23:16 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 696A8A4EED3 for ; Wed, 23 Dec 2015 13:23:16 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id B4C9215D1 for ; Wed, 23 Dec 2015 13:23:15 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Wed, 23 Dec 2015 14:23:08 +0100 Authentication-Results: connect.ultra-secure.de; auth=pass (login); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.16 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.16; helo=connect.ultra-secure.de; envelope-from= Received: from connect.ultra-secure.de (expwebmail [127.0.0.16]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id A33F5803-B37C-45DD-B6EA-814C62516EEA.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=NO); Wed, 23 Dec 2015 14:22:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Dec 2015 14:22:51 +0100 From: rainer@ultra-secure.de To: Aristedes Maniatis Cc: freebsd-stable Subject: Re: freebsd-update incorrect hashes In-Reply-To: <567A92BD.5010105@ish.com.au> References: <567A92BD.5010105@ish.com.au> Message-ID: <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> X-Sender: rainer@ultra-secure.de User-Agent: Roundcube Webmail/1.1.3 X-Haraka-GeoIP: --, , NaNkm X-Haraka-GeoIP-Received: X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 5, bad: 0, connections: 20, history: 5, pass:relaying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 13:23:16 -0000 Am 2015-12-23 13:25, schrieb Aristedes Maniatis: > I've had problems with freebsd-update for many years now. It is by far > the least reliable component of FreeBSD since I started with the > operating system back at 3.4 in 1999. > > Anyhow, I'm usually able to get past the exceedingly slow downloads > and errors to the upgrade process, but this time nothing I do will get > me to the end. I've tried deleting /var/db/freebsd-update but several > hours later I was at the same place again. The internet link is fast, > but with a web proxy in this location, some downloads are slightly > delayed while the virus scanner on the proxy does its thing. Perhaps > 3-5 seconds delayed. The problem is phttpget or the proxy, depending on the point of view. Some proxies have (had) problems with the pipelined http requests that phttpget seems to use. apt (Debian/Ubuntu) has, too - but they can be disabled altogether there. http://webcache.googleusercontent.com/search?q=cache:OwcOVJamJOoJ:https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/55213-http-pipelining-broken-after-upgrade-utm-9-3-a.html+&cd=1&hl=de&ct=clnk&gl=ch IMO, there should be an option to use wget instead of phttpget. Or at least disable the request-pipelining. There was a PR with patches floating around to make freebsd-update use wget, but it never gained traction. Also, didn't phttpget have problems with proxies needing authentication? I usually have authentication at the proxy disabled for *.freebsd.org for this reason. From owner-freebsd-stable@freebsd.org Wed Dec 23 14:00:07 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E4DAA4F8D1 for ; Wed, 23 Dec 2015 14:00:07 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from mail13.tpgi.com.au (smtp-out13.tpgi.com.au [220.244.226.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL SHA256 CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0D9812E1 for ; Wed, 23 Dec 2015 14:00:05 +0000 (UTC) (envelope-from ari@ish.com.au) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Thu, 24 Dec 2015 00:40:58 +1100 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail13.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id tBNDeuAO004570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Dec 2015 00:40:58 +1100 Received: from [10.242.2.26] (port=51563 helo=Aristedess-MacBook-Pro.local) by fish.ish.com.au with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aBjev-0000W1-2V; Thu, 24 Dec 2015 00:40:54 +1100 X-CTCH-RefID: str=0001.0A150208.567AA466.0024, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: freebsd-update incorrect hashes To: rainer@ultra-secure.de References: <567A92BD.5010105@ish.com.au> <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> Cc: freebsd-stable From: Aristedes Maniatis X-Enigmail-Draft-Status: N1110 Message-ID: <567AA464.4060706@ish.com.au> Date: Thu, 24 Dec 2015 00:40:52 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VwLeixnkGcEsM5UT3Vh6hGrkA05Kkl9eq" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 14:00:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VwLeixnkGcEsM5UT3Vh6hGrkA05Kkl9eq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 24/12/2015 12:22am, rainer@ultra-secure.de wrote: > Am 2015-12-23 13:25, schrieb Aristedes Maniatis: >> I've had problems with freebsd-update for many years now. It is by far= >> the least reliable component of FreeBSD since I started with the >> operating system back at 3.4 in 1999. >> >> Anyhow, I'm usually able to get past the exceedingly slow downloads >> and errors to the upgrade process, but this time nothing I do will get= >> me to the end. I've tried deleting /var/db/freebsd-update but several >> hours later I was at the same place again. The internet link is fast, >> but with a web proxy in this location, some downloads are slightly >> delayed while the virus scanner on the proxy does its thing. Perhaps >> 3-5 seconds delayed. >=20 >=20 >=20 > The problem is phttpget or the proxy, depending on the point of view. >=20 > Some proxies have (had) problems with the pipelined http requests that = phttpget seems to use. >=20 > apt (Debian/Ubuntu) has, too - but they can be disabled altogether ther= e. >=20 > http://webcache.googleusercontent.com/search?q=3Dcache:OwcOVJamJOoJ:htt= ps://www.astaro.org/gateway-products/web-protection-web-filtering-applica= tion-visibility-control/55213-http-pipelining-broken-after-upgrade-utm-9-= 3-a.html+&cd=3D1&hl=3Dde&ct=3Dclnk&gl=3Dch >=20 > IMO, there should be an option to use wget instead of phttpget. Or at l= east disable the request-pipelining. > There was a PR with patches floating around to make freebsd-update use = wget, but it never gained traction. >=20 > Also, didn't phttpget have problems with proxies needing authentication= ? > I usually have authentication at the proxy disabled for *.freebsd.org f= or this reason. In my case, the proxy doesn't need authentication. But I can see from the= code (I've just discovered that freebsd-update is in fact a shell script= ) that if it fails, then on the next run it starts again from the beginni= ng. No downloaded files are moved into the files folder until they all su= cceed. I've found debug mode, and what it is doing is downloading every single f= ile (1800 of them in my case) and then only at the end checking to see if= the hashes are right. When it fails, it just stops and I need to start a= gain. Each run takes about 40 minutes. Ari --=20 --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A --VwLeixnkGcEsM5UT3Vh6hGrkA05Kkl9eq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlZ6pGQACgkQ72p9Lj5JECo5mgCeMMOa4pMLx2d80z3HjMj1j2x/ ipcAn2TkE5W9AALQclduGwRcB6qPthUo =v/tY -----END PGP SIGNATURE----- --VwLeixnkGcEsM5UT3Vh6hGrkA05Kkl9eq-- From owner-freebsd-stable@freebsd.org Wed Dec 23 15:42:08 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C936A4F729 for ; Wed, 23 Dec 2015 15:42:08 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1EEF1B17 for ; Wed, 23 Dec 2015 15:42:07 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id tBNFg7sC098386 for ; Wed, 23 Dec 2015 07:42:13 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> References: <567A92BD.5010105@ish.com.au>, <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> From: "Chris H" Subject: Re: freebsd-update incorrect hashes Date: Wed, 23 Dec 2015 07:42:13 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <62d141c46b3f32c3f81d7faf877ac2af@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 15:42:08 -0000 On Wed, 23 Dec 2015 14:22:51 +0100 rainer@ultra-secure.de wrote > Am 2015-12-23 13:25, schrieb Aristedes Maniatis: > > I've had problems with freebsd-update for many years now. It is by far > > the least reliable component of FreeBSD since I started with the > > operating system back at 3.4 in 1999. > > > > Anyhow, I'm usually able to get past the exceedingly slow downloads > > and errors to the upgrade process, but this time nothing I do will get > > me to the end. I've tried deleting /var/db/freebsd-update but several > > hours later I was at the same place again. The internet link is fast, > > but with a web proxy in this location, some downloads are slightly > > delayed while the virus scanner on the proxy does its thing. Perhaps > > 3-5 seconds delayed. > > > > The problem is phttpget or the proxy, depending on the point of view. > > Some proxies have (had) problems with the pipelined http requests that > phttpget seems to use. > > apt (Debian/Ubuntu) has, too - but they can be disabled altogether > there. > > http://webcache.googleusercontent.com/search?q=cache:OwcOVJamJOoJ:https://www > .astaro.org/gateway-products/web-protection-web-filtering-application-visibil > ity-control/55213-http-pipelining-broken-after-upgrade-utm-9-3-a.html+&cd=1&h > l=de&ct=clnk&gl=ch > > IMO, there should be an option to use wget instead of phttpget. Or at > least disable the request-pipelining. > There was a PR with patches floating around to make freebsd-update use > wget, but it never gained traction. > > Also, didn't phttpget have problems with proxies needing authentication? > I usually have authentication at the proxy disabled for *.freebsd.org > for this reason. I concur, to the extent that phttpget[1] runs pretty much "blind". As it it, phttpget blindly accepts any 200 response, and drops any other response. What does this mean? Why would/could this be a problem? It slurps all 200 responses; meaning; if the response is not a file, but a web page asking for some kind of response from you, *that's* what phttpget downloads. It also means that if the 200 response is a web page indicating that the file you are looking for has moved, and has a link to it's new location. Then *that's* what phttpget downloads. The possibility's go on, and on. But you get the picture. :) --Chris [1] http://www.daemonology.net/phttpget/ From owner-freebsd-stable@freebsd.org Thu Dec 24 07:52:55 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3F1BA50696 for ; Thu, 24 Dec 2015 07:52:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 681E21BBC for ; Thu, 24 Dec 2015 07:52:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aC0hh-000IV8-En for freebsd-stable@freebsd.org; Thu, 24 Dec 2015 10:52:53 +0300 Date: Thu, 24 Dec 2015 10:52:53 +0300 From: Slawa Olhovchenkov To: freebsd-stable@freebsd.org Subject: bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop Message-ID: <20151224075253.GF70867@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 07:52:55 -0000 I am try to upgrade very old 10-CURRENT to latest 10-STABLE and got next error: ===> usr.bin/yacc (obj,depend,all,install) bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop bmake[1]: stopped in /usr/src *** Error code 2 Stop. bmake: stopped in /usr/src *** [buildworld] Error code 1 Stop in /usr/src. From owner-freebsd-stable@freebsd.org Thu Dec 24 17:03:05 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E85CA508D8 for ; Thu, 24 Dec 2015 17:03:05 +0000 (UTC) (envelope-from no-reply@wpengine.com) Received: from mail-183-221.wpengine.com (mail-183-221.wpengine.com [23.253.183.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E492715C1 for ; Thu, 24 Dec 2015 17:03:04 +0000 (UTC) (envelope-from no-reply@wpengine.com) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=wpengine.com; q=dns/txt; s=k1; t=1450976583; h=Content-Type: Content-Transfer-Encoding: MIME-Version: Message-ID: Subject: From: To: Date; bh=pkvT9GzSifDphLkG94px+D64MD8KNLG3hrRyHf/V0dU=; b=V1LwMMiT1iHyD0G4X2X/UJ9342awTmI8/dILICs9mbe5ptq87hXhmU0vItVx39mBlIK5RHWw Xdu5IG+amKcSo8gqxl8Ru9xBkcY2LohXGe8wDLsZf+uudpXMJbUTUVAbCfUVRShvp8OUgTzi IIfAO5UH3hSgUpch8+Z5apaoLYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=wpengine.com; s=k1; q=dns; h=Date: To: From: Subject: Message-ID: MIME-Version: Content-Transfer-Encoding: Content-Type; b=sviF5E+WB26l+549r0kFeSWepTT6v16JFTsAvKk2NNkxcJLxCfgk67NblRpY1QytWy0N5A 6Ps1e0wqmTgdM3kNCJ4VBJ1oQpQyyU3BqYkoJOwLaBec2eID/OYzHZ0Y1Bkx5/2QVI6131aN NOF4RBpqqoyaka+wRZ1IR4THOPCsQ= X-Mailgun-Sid: WyJkYWI2MSIsICJmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyIsICJkMzRiNDQiXQ== Received: from pod-42419 (li1370-87.members.linode.com [139.162.207.87]) by mxa.mailgun.org with ESMTP id 567c234e.739f840-in1; Thu, 24 Dec 2015 16:54:38 -0000 (UTC) Received: from pod-42419 (localhost [127.0.0.1]) by pod-42419 (Postfix) with ESMTP id E8C25321E5 for ; Thu, 24 Dec 2015 16:54:34 +0000 (UTC) X-Mailgun-Native-Send: yes Received: from onlineservices.wpengine.com (localhost [127.0.0.1]) by pod-42419 (Postfix) with ESMTP id DE662321E6 for ; Thu, 24 Dec 2015 16:54:34 +0000 (UTC) Date: Thu, 24 Dec 2015 16:54:34 +0000 To: "freebsd-stable@freebsd.org" From: "service@paypal.com" Subject: Account Alert - Additional Verification Required! Message-ID: <2fae33afc796983911078feb74a35e18@onlineservices.wpengine.com> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 17:03:05 -0000 From owner-freebsd-stable@freebsd.org Sat Dec 26 15:10:14 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9570A52DB8 for ; Sat, 26 Dec 2015 15:10:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 830451F3C; Sat, 26 Dec 2015 15:10:12 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id tBQFA0OA012299; Sun, 27 Dec 2015 02:10:00 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 27 Dec 2015 02:09:59 +1100 (EST) From: Ian Smith To: Tom Evans cc: FreeBSD Stable , Alexander Motin , Jeremy Chadwick , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: stable/10: high load average when box is idle In-Reply-To: Message-ID: <20151106212735.U12989@sola.nimnet.asn.au> References: <20151027050508.GA7612@icarus.home.lan> <20151104025748.F10372@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 15:10:14 -0000 On Wed, 4 Nov 2015 14:31:35 +0000, Tom Evans wrote: > On Tue, Nov 3, 2015 at 5:47 PM, Ian Smith wrote: > > Like yourself, I think this is far from 'cosmetic' as is oft suggested, > > especially in some fairly ill-informed forum posts but also various list > > posts. I've been watching load averages since OS/2 through FreeBSD 2.2 > > till present and some Linux systems, and have never before seen anything > > like this, especially on virtually entirely idle systems. While the LAs > > reported during (say) make -j4 buildworld appear more same, who knows? > > > > I'm not suggesting that I think there's any sort of performance hit from > > this; so far I don't, but 'cosmetic' suggests that it doesn't matter .. I'm afraid I can't resist being undoubtedly too thorough with this post, but it does summarise quite a lot of time I've spent this year, and I'm feeling a little in need of celebrating an apparent win as a result .. > Have you read mav's explanation on the PR? It certainly seems a valid > explanation of why it is probably a cosmetic issue - that is, we could > wake up more to get a truly perfect load average, but why bother? I've read it over and again. I think it may well explain some relative 'fuzziness' in LAs over perhaps a 0.1 to 0.3 range that I see now since finding - more truthfully, stumbling upon - and implementing a fix for the major issue I've had and been working on in bursts over many months. Being that on recent stable/9, 2.4GHz Core2Duo, ~99.99% idle after boot, just sshd, powerd, ntpd and hald; showing worst-seen extremes, commonly seen range and more or less steady at 1, 5, 15 min loadavg respectively: eventtimer mode 1min 5 min 15min HPET one-shot 0.4-0.85 0.5-0.75 0.6-0.7 HPET periodic 0.99-1.00 (!) 0.99-0.99 to 0.99 LAPIC one-shot 0.0-0.05 0.0-0.02 0.0-0.0 LAPIC periodic 0.0-0.05 0.0-0.02 0.0-0.0 I run a task that's 100% cpu-bound (well, about 7 I/O reads in the first few milliseconds) that is configured to run for 15.5 minutes, in bg so I can watch and take measurements throughout. It uses 100% of one CPU (so scheduled as ~50% per cpu) for that long. With LAPIC eventtimer, 1min LAs soon reach 0.99-1.00, with 5min LA getting there in ~15 minutes. If I run 2 instances, each runs in 15.5 minutes (plus ~5 seconds) and both cpus show 100% for those tasks, 1min LA soon reaches 1.99-2.00. If I run 4 instances, on its 2 cpus, 1min LAs soon reach 3.99-4.00, and 5min LAs reach 3.99 after 15-20 minutes. Since 4 CPU-bound tasks want to run on 2 cpus, each runs for ~15.5m cpu time, so total runtime for each is ~31 minutes, by which time 15min LA is heading for 4 also. In other words, load averages shown with LAPIC are pretty much exactly what one would (and should) expect for 1, 2 or 4 longrunning cpu-bound tasks, true even in periodic mode, which has almost as few interrupts and context switches as with HPET (but without its valuable C3 usage) I should add that with HPET one-shot mode, 2 such tasks report ~2.4 LA, while 4 tasks report ~4.4 LA, so there's definitely an increment there. However switching back to HPET soon reverts to 'normal' behaviour, which over long idles (hours) show 0.66 or 0.67 15min LA as 'average average'. HPET in periodic mode, which has helped some using 10.x w/ LAPIC, here only rapidly pins LAs to 0.99-1.00 at idle, before and after more load. Both of these HPET reported LAs just smelled like bad maths. I spent way too much time down the (upper parts of) the rabbit hole/s with little to show; I should have asked more questions but wanted to suss it out .. > ISTM, the problem reports are of the form "My server is idle and it is > reporting a non-idle load average below 1", and not "My server is > supposedly idle, but is doing actual work causing the load average to > be higher than it should be". Is there any evidence that we have the > latter and not the former? Er yes, it is the former, not the latter. And not that it's shown as below 1, as much as it's shown above 0.00 - ie, something > 0.005 - when yes, genuinely idle below that level, top showing 100.00% idle on both cpu idle tasks, and say 100.0% and 99.8% idle each from cp_times (-SCHP) So I was wondering if I really had to post my hundreds of ks of logs and running reports of the above to properly demonstrate what was happening here, when I thought I'd try cpuset(1) to pin the abovementioned task to one cpu, rather than letting the scheduler share it out over both, and so first up I tried one of the examples (except for 1 of 2 cpus): # cpuset -l 0 -s 1 And lo! the previously 0.66-ish HPET LAs headed towards 0.00, taking around 5 minutes to get there. Wow. So I ran some more tests using abovementioned tasks, and sure enough, LAs as good as with LAPIC. Then after a while I reenabled CPU1 .. # cpuset -l 0-1 -s 1 # cpuset -g pid -1 mask: 0, 1 .. fully expecting LAs to climb back to 'normal' HPET behaviour .. but they did not! They stayed where they were, basically 0.00 0.00 0.00 in such idleness, and appropriately like 0.1 - 0.2 with X fired up, idle. Reboot. Straight away log in as root: # cpuset -l 0 -s 1 # cpuset -l 0-1 -s 1 # ie: -l "0-`sysctl -n kern.smp.maxid`" LAs headed back toward 0.00, taking around 5 minutes. Wow again .. Adding the above cpuset commands to (a new) /etc/rc.local, not even the sleep between that I thought may be needed. Reboot. 0.00 LAs. Whee! So, is this going to be a fix that Affects Only Me? I'm keen to hear. Yes I will update the PR, after I'm quite sure I'm not hallucinating :) Importantly, will doing that for those using LAPIC eventtimer who had unexpectedly high LAs make any difference? Perhaps so if it's the first eventtimer configured at boot that has - in some cases - such problem? Or perhaps this only works for 9.x? I have no 10.x system currently, and could easily have missed some commit that picked up on $whatever. Current hypothesis: some variable/s are getting improperly initialised at boot, but are (somehow?) getting properly re-initialised on changing cpuset to 1 then back to 2 cpus - though I've no idea how, or by what. Again, apologies for a short story writ too long. cheers, Ian