From owner-freebsd-arch@freebsd.org Sun Dec 10 10:17:25 2017 Return-Path: Delivered-To: freebsd-arch@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 3EF0EE88385 for ; Sun, 10 Dec 2017 10:17:25 +0000 (UTC) (envelope-from freebsd.arch@clogic.com.ua) Received: from gate.krrt.pl.ua (gate.krrt.pl.ua [193.111.188.121]) (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 E6B496B613 for ; Sun, 10 Dec 2017 10:17:23 +0000 (UTC) (envelope-from freebsd.arch@clogic.com.ua) Received: from gate.krrt.pl.ua (localhost [127.0.0.1]) by gate.krrt.pl.ua (Postfix) with ESMTP id AF0621E7B for ; Sun, 10 Dec 2017 12:11:00 +0200 (EET) Received: from mail.krrt.pl.ua (localhost [IPv6:::1]) (Authenticated sender: freebsd.arch@clogic.com.ua) by gate.krrt.pl.ua (Postfix) with ESMTPA id 501DB1E7A for ; Sun, 10 Dec 2017 12:11:00 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clogic.com.ua; s=default; t=1512900660; i=@clogic.com.ua; bh=dQkETTcMFMsR5AtG72QyEDEsXCc9CBoKsUiRZ+EUTLA=; h=Date:From:To:Subject:In-Reply-To:References; b=EljOwvCg4kxZtIMGXsTqL+3+Ugsq2eesLtusfFrCTnOBsWft4hhnr7rGEnlQc70gK Xq4AdYrLjRrhXnNriIM7oAGDpUTFymhltNB74lK1bosc7xrk/FFKVOvVLKMWDwo4/+ 59x/Pe+PowEiXKxoP0qfzR3TgYsdRURAsbj6UmSQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 10 Dec 2017 12:11:00 +0200 From: freebsd.arch@clogic.com.ua To: freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? In-Reply-To: <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> Message-ID: <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> X-Sender: freebsd.arch@clogic.com.ua User-Agent: Roundcube Webmail/1.3.3 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 10:17:25 -0000 On 2017-12-09 19:08, Julian Elischer wrote: > On 7/12/17 12:16 pm, Don Lewis wrote: >> On 6 Dec, Baptiste Daroussin wrote: >>> Hi all, >>> >>> I would like to propose the deprecation then removal of sendmail in >>> base. >>> >>> Deprecation will happen in the form of FreeBSD 12.0 being built >>> WITHOUT_SENDMAIL >>> by default >>> >>> removal would happen in FreeBSD 13.0 >>> >>> sendmail in base it not really usable as a full featured mta due to >>> the fact it >>> does not support anything an entreprised grade mta setup would >>> require: ldap >>> support for example, check the number of options available in the >>> sendmail port. >>> >>> Users for that use case would be better served by the port version of >>> sendmail. >>> >>> The other kind of users are the one using the default setup of >>> sendmail: >>> relaying emails externally and deliver locally. >> I've found that sendmail in base meets my needs. I haven't had the >> need >> for any of the features that are only available in the port. > "me too". > How about you just leave it there until we have pkgbase by default and > then just swap it. > I have enough scripts and configs around that I don't want to revisit > to fix all this. > I hardly remember how they work.. They've been untouched except for > upgrades > for about a decade. > Most users don't need a sandmail in base. As example, I always disable sendmail and install dma for local use or postfix for mail servers. So I can't understand, why I need do this every time as I install new instance of FreeBSD in 2017? > >> It doesn't looks like dma(8) would be useful for me on my primary >> machines since I basically need its inverse. It would only be useful >> on my headless machines to forward cron-generated mail to my mail >> server. I don't do any local delivery of mail to mbox files. My mail >> server delivers all mail to cyrus-imapd via lmtp, which is a fairly >> simple tweak to the sendmail.mc file. I also have a couple of mail >> relays that do some smart routing and spam filtering. >> >> One thing that is comes with sendmail in base but is missing from the >> sendmail port is all the handy stuff in /etc/mail, such as the >> freebsd.mc template, the aliases file, and the Makefile which makes >> maintaining the config files and the .db files much easier. Without >> this stuff, setting up the sendmail port would be much more >> intimidating. > amen > a sendmail-freebsd port maybe? > Best regards. From owner-freebsd-arch@freebsd.org Sun Dec 10 13:13:59 2017 Return-Path: Delivered-To: freebsd-arch@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 E94F9E8C4F7 for ; Sun, 10 Dec 2017 13:13:59 +0000 (UTC) (envelope-from rsk@gsp.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D667A70944 for ; Sun, 10 Dec 2017 13:13:59 +0000 (UTC) (envelope-from rsk@gsp.org) Received: by mailman.ysv.freebsd.org (Postfix) id D5D49E8C4F6; Sun, 10 Dec 2017 13:13:59 +0000 (UTC) Delivered-To: arch@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 D50D5E8C4F5 for ; Sun, 10 Dec 2017 13:13:59 +0000 (UTC) (envelope-from rsk@gsp.org) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "taos.firemountain.net", Issuer "taos.firemountain.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E69E70943 for ; Sun, 10 Dec 2017 13:13:59 +0000 (UTC) (envelope-from rsk@gsp.org) Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id vBADDuOX020109 for ; Sun, 10 Dec 2017 08:13:57 -0500 (EST) Date: Sun, 10 Dec 2017 08:13:56 -0500 From: Rich Kulawiec To: arch@FreeBSD.org Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171210131356.GA1900@gsp.org> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <20171208074456.GA2035@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208074456.GA2035@ns.kevlo.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 13:14:00 -0000 On Fri, Dec 08, 2017 at 03:44:56PM +0800, Kevin Lo wrote: > I seriously don't think dma(8) is a full featured mta. I would recommend > OpenSMTPD. OpenSMTPD makes smtp easier to implement and manage and more > secure. There is little evidence supporting these claims. OpenSMTPD is an interesting experiment and it shows some promise, but it's far from a professional MTA suitable for deployment in production environments. (And any claims about its security compared to other MTAs are wildly premature.) It's also missing quite a few features that are must-haves for anyone who is serious about running an Internet-facing MTA. Maybe in 3 or 5 or 10 years it will have those features, and maybe it will have undergone the kind of rigorous real-world vetting (perhaps "beating" would be more apropos) that postfix and sendmail and others have, but it's not there yet. At this time, I can only recommend it for small (in terms of volume, users, traffic) environments that have limited defensive requirements and do not require ready integration with other mail-related software. (Note: I'm using it in one that meets that description, as a long-running experiment in its side-by-side performance compared to that of postfix.) So should it be offered as an alternative? Yes. Should people with very limited operational requirements consider it? Yes. Should people who are willing to test it/experiment with it do so? Yes. But until it's far more thoroughly vetted, it's not suitable to be the default. ---rsk From owner-freebsd-arch@freebsd.org Sun Dec 10 13:31:47 2017 Return-Path: Delivered-To: freebsd-arch@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 A146AE8CBE1 for ; Sun, 10 Dec 2017 13:31:47 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 6D1E97149D for ; Sun, 10 Dec 2017 13:31:47 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vBADVdaV078615; Sun, 10 Dec 2017 13:31:40 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vBADVcxH078614; Sun, 10 Dec 2017 13:31:38 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712101331.vBADVcxH078614@donotpassgo.dyslexicfish.net> Date: Sun, 10 Dec 2017 13:31:38 +0000 Organization: Dyslexic Fish To: freebsd.arch@clogic.com.ua, freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> In-Reply-To: <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 10 Dec 2017 13:31:40 +0000 (GMT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 13:31:47 -0000 freebsd.arch@clogic.com.ua wrote: > Most users don't need a sandmail in base. As example, I always disable > sendmail and install dma for local use or postfix for mail servers. So I > can't understand, why I need do this every time as I install new > instance of FreeBSD in 2017? There are many valid arguments for and against removal, but I'm afraid that isn't one of them. Many things aren't used by "most users" - Most don't use bhyve, for example, and I bet a high proportion don't even use clang, or many of the other installed utilities. As for dma, it's already installed by default - but as most people don't use it, by your logic, it shouldn't be! :-) cheers, jamie From owner-freebsd-arch@freebsd.org Sun Dec 10 14:27:59 2017 Return-Path: Delivered-To: freebsd-arch@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 37C28E8DCAB for ; Sun, 10 Dec 2017 14:27:59 +0000 (UTC) (envelope-from freebsd.arch@clogic.com.ua) Received: from gate.krrt.pl.ua (gate.krrt.pl.ua [193.111.188.121]) (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 E0DAC73035 for ; Sun, 10 Dec 2017 14:27:57 +0000 (UTC) (envelope-from freebsd.arch@clogic.com.ua) Received: from gate.krrt.pl.ua (localhost [127.0.0.1]) by gate.krrt.pl.ua (Postfix) with ESMTP id D1C3224D5 for ; Sun, 10 Dec 2017 16:27:52 +0200 (EET) Received: from mail.krrt.pl.ua (localhost [IPv6:::1]) (Authenticated sender: freebsd.arch@clogic.com.ua) by gate.krrt.pl.ua (Postfix) with ESMTPA id 4735824D4 for ; Sun, 10 Dec 2017 16:27:52 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clogic.com.ua; s=default; t=1512916072; i=@clogic.com.ua; bh=DcVqu6/MPPuNOaqiJr7Uhfnv546bqqrU+atOQ/Pb7ik=; h=Date:From:To:Subject:In-Reply-To:References; b=MQOGuBDdYe1CgQ1EkoHYmpFucHAgdlYZZTMYDXo4dAl7xkUfcA7ECwbhQQNxjHFgr DtIApSQl+JCixXrCw8yyzpM6ZEbetXc5qfsVCRSjW3O/nNCLJsu7PRtSbOkNHbwu1E UDOaCDCv5aUZqRTLjmVRaJMqBVlXgUAf585qCt3s= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 10 Dec 2017 16:27:52 +0200 From: freebsd.arch@clogic.com.ua To: freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? In-Reply-To: <201712101331.vBADVcxH078614@donotpassgo.dyslexicfish.net> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> <201712101331.vBADVcxH078614@donotpassgo.dyslexicfish.net> Message-ID: X-Sender: freebsd.arch@clogic.com.ua User-Agent: Roundcube Webmail/1.3.3 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 14:27:59 -0000 On 2017-12-10 15:31, Jamie Landeg-Jones wrote: > freebsd.arch@clogic.com.ua wrote: > >> Most users don't need a sandmail in base. As example, I always disable >> sendmail and install dma for local use or postfix for mail servers. So >> I >> can't understand, why I need do this every time as I install new >> instance of FreeBSD in 2017? > > There are many valid arguments for and against removal, but I'm afraid > that isn't one of them. This is counterargument for people who use sendmail from base because they do this many years before and have configs. And I not only don't use sendmail, I need disable it any time as install new instance of FreeBSD. And I am not alone in this. > Many things aren't used by "most users" - Most don't use bhyve, for > example, > and I bet a high proportion don't even use clang, or many of the other > installed utilities. > > As for dma, it's already installed by default - but as most people > don't > use it, by your logic, it shouldn't be! :-) > > cheers, > jamie There is no suitable bhyve(or clang) alternatives on FreeBSD, so we use better ones. 1. Sendmail not suitable for modern mail system and not actively developed anymore. 2. We have modern lightweight alternatives like dma or opensmtpd. 3. FreeBSD is OS for general use, not for mail server systems. If anyone need fully functional mail server he can install it from ports. P.S. Sendmail was removed from default install in almost all Linux distributions and from base system in DragonflyBSD, OpenBSD and NetBSD. Best regards. From owner-freebsd-arch@freebsd.org Sun Dec 10 20:08:18 2017 Return-Path: Delivered-To: freebsd-arch@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 D555CE99DC3 for ; Sun, 10 Dec 2017 20:08:18 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 9673D808D6 for ; Sun, 10 Dec 2017 20:08:18 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-oi0-x22a.google.com with SMTP id s9so10334715oie.5 for ; Sun, 10 Dec 2017 12:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Yi6Jqh6SSM4TgicfaHoqXd2oqKDHUfZRxwsKlsZXUco=; b=XfuJXW+TL+P1xyfHnpp83R4I21BBpP0ksRVTJ4TPkDwg/9a6VHdOJbAqcnLHYxqWPR Zxo4R+mOKqGT+Du9aOLi6wO8W1fJXogTLd/C9yLHjTG6ClTw1UIjupEiCrBSicDbbQSQ 1bZai/CtrqlJNWHXTOMl/QSLIfxTZFoEjJIGo6x9LN9MXAM8L9mHgT9zuykhxBbcl0hr Mq1a6drOE45skWr+H7y6uY+71RuId708DAlChtGXJMq/xPpui+13X+3ik/hCNVF+2vW8 Ntei00oJwVpgaXC4+I+ErdFWLZQrLqy8RNbTqcdNUE7xZBl/0mjTUtiNr0G6CXXYD002 IIkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Yi6Jqh6SSM4TgicfaHoqXd2oqKDHUfZRxwsKlsZXUco=; b=QXHzFpDylibdPnG89N25mqRKwtGxWIslllqURnm4Kqs8ylLGf7HPtPlF2qIMzUuq71 4KMwDcere63DJIvbEiSxgc8oojlkzr7URxJIGwj5oa8lV71ii9WFaOiXsCkSX5QUqKCr 482igW/67JoR6ckdG/KCEgYFiEpYaGLUBwtMTc7/fxVvpeWUNWr62nzqqHAMZ5qOhdrl HpEHyE0MfIRhE8aZsb1NKOoOkrugEvb5G5Yi0YcMaZgIyoDY6X+T+LGY8dYYSUVL7OR9 Kl+w+Z6DJIFSoEDljX18RZKVeINg9V60oGLqbEtsRkMOKf6kpgmn2bZxr6O+twKrf4Tr U1HQ== X-Gm-Message-State: AJaThX7Rigk8rJM8emMjbabP44nzahIDqCw/5gnkD8YUop/CpHKDnAI4 LJgWfbl1M/wF/jSp73YdZ+YxKE2LsTWhAaxBK+9liw== X-Google-Smtp-Source: AGs4zMZRCaDMq+ezdLdBS2lxDtySQqGcI/c4otV9uCge2flzUanw1UsCPJevQMT9IlbSJahldFlVv1OB5r0XkcQHJCo= X-Received: by 10.202.245.144 with SMTP id t138mr28053377oih.201.1512936497811; Sun, 10 Dec 2017 12:08:17 -0800 (PST) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.157.66.238 with HTTP; Sun, 10 Dec 2017 12:08:17 -0800 (PST) In-Reply-To: References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> <201712101331.vBADVcxH078614@donotpassgo.dyslexicfish.net> From: "K. Macy" Date: Sun, 10 Dec 2017 12:08:17 -0800 X-Google-Sender-Auth: qInZVjwTnghuo-rSneURLzN7Tmo Message-ID: Subject: Re: RFC: Sendmail deprecation ? To: freebsd.arch@clogic.com.ua Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 20:08:18 -0000 On Sun, Dec 10, 2017 at 6:27 AM, wrote: > On 2017-12-10 15:31, Jamie Landeg-Jones wrote: >> >> freebsd.arch@clogic.com.ua wrote: >> >>> Most users don't need a sandmail in base. As example, I always disable >>> sendmail and install dma for local use or postfix for mail servers. So I >>> can't understand, why I need do this every time as I install new >>> instance of FreeBSD in 2017? >> >> >> There are many valid arguments for and against removal, but I'm afraid >> that isn't one of them. That's not really the question. The question is "why won't 'pkg install sendmail' work for users that need it?" There are two technical reasons for why a component is in base and two emotional / political. The two technical reasons are: 1) The system won't work without it (e.g. rc files, kill, rm, etc) 2) The component is tightly coupled to the kernel (e.g. bhyve) There are of course plenty of things which fall in to both buckets: libc, ifconfig, etc. The two emotional reasons are: 1) Emotional attachment (e.g. fortune) 2) Inertia (rcs, sendmail, etc) Thanks to bapt and friends pkg "just works" for most people for most cases. In conclusion, further discussion needs to either a) make a compelling case for why either my technical points are insufficient or the emotional drivers are critical; or b) explain why "pkg install sendmail" won't work. Cheers. -M From owner-freebsd-arch@freebsd.org Mon Dec 11 01:06:03 2017 Return-Path: Delivered-To: freebsd-arch@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 9EC5EE81460 for ; Mon, 11 Dec 2017 01:06:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 891466AB6A for ; Mon, 11 Dec 2017 01:06:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([149.142.15.7]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vBB0tLce006725 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 10 Dec 2017 16:55:21 -0800 Subject: Re: RFC: Sendmail deprecation ? To: freebsd-arch@freebsd.org References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> <201712101331.vBADVcxH078614@donotpassgo.dyslexicfish.net> From: Nathan Whitehorn Message-ID: <310c26e3-1818-a7de-9606-2a74c3cd84c3@freebsd.org> Date: Sun, 10 Dec 2017 16:55:21 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVamMtJzOOSmqW1xJojcr/xKdyELpeh3242P1AXqnBbGc8rwHF85k1SGgKDktIzfaAcWDPeVfkcz8tTpKvay/GDh0255gBkgmUo= X-Sonic-ID: C;XOq69g3e5xG36esnWtmBlw== M;VNv+9g3e5xG36esnWtmBlw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 01:06:03 -0000 On 12/10/17 12:08, K. Macy wrote: > On Sun, Dec 10, 2017 at 6:27 AM, wrote: >> On 2017-12-10 15:31, Jamie Landeg-Jones wrote: >>> freebsd.arch@clogic.com.ua wrote: >>> >>>> Most users don't need a sandmail in base. As example, I always disable >>>> sendmail and install dma for local use or postfix for mail servers. So I >>>> can't understand, why I need do this every time as I install new >>>> instance of FreeBSD in 2017? >>> >>> There are many valid arguments for and against removal, but I'm afraid >>> that isn't one of them. > That's not really the question. The question is "why won't 'pkg > install sendmail' work for users that need it?" There are two > technical reasons for why a component is in base and two emotional / > political. > > The two technical reasons are: > 1) The system won't work without it (e.g. rc files, kill, rm, etc) As a sub-point, we do want the base system to be a reliable and consistent set of things such that scripts and instructions can reference them; one of FreeBSD's strong points is that I can write a script targeting "FreeBSD" and know that a reasonably complete system is going to be present and that I won't find out that, say, ping or telnet are not installed. This expands the set of important tools much beyond "kill" and "rm" and means we should tread very, very carefully in terms of moving things out of the base system -- this is one of my major general reservations about the proposed implemention of pkgbase. That said, sendmail is *definitely* not in that category so long as some basic MTA is there that makes reports from periodic etc. work. The important thing is that mail(1) work, not that it be sendmail. So I'm 100% in favor of dropping sendmail. -Nathan > 2) The component is tightly coupled to the kernel (e.g. bhyve) > > There are of course plenty of things which fall in to both buckets: > libc, ifconfig, etc. > > The two emotional reasons are: > 1) Emotional attachment (e.g. fortune) > 2) Inertia (rcs, sendmail, etc) > Thanks to bapt and friends pkg "just works" for most people for most > cases. In conclusion, further discussion needs to either a) make a > compelling case for why either my technical points are insufficient or > the emotional drivers are critical; or b) explain why "pkg install > sendmail" won't work. > > Cheers. > -M > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Mon Dec 11 11:10:58 2017 Return-Path: Delivered-To: freebsd-arch@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 90249E8E957 for ; Mon, 11 Dec 2017 11:10:58 +0000 (UTC) (envelope-from freebsd.arch@clogic.com.ua) Received: from gate.krrt.pl.ua (gate.krrt.pl.ua [193.111.188.121]) (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 0C26680CD6 for ; Mon, 11 Dec 2017 11:10:57 +0000 (UTC) (envelope-from freebsd.arch@clogic.com.ua) Received: from gate.krrt.pl.ua (localhost [127.0.0.1]) by gate.krrt.pl.ua (Postfix) with ESMTP id 84A0F7987 for ; Mon, 11 Dec 2017 13:10:47 +0200 (EET) Received: from mail.krrt.pl.ua (localhost [IPv6:::1]) (Authenticated sender: freebsd.arch@clogic.com.ua) by gate.krrt.pl.ua (Postfix) with ESMTPA id 30AAE7986 for ; Mon, 11 Dec 2017 13:10:47 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clogic.com.ua; s=default; t=1512990647; i=@clogic.com.ua; bh=Tht+23rKrhq4vp/ThJIp1Qb+TCl5LiSZBbQi8B4sKFY=; h=Date:From:To:Subject:In-Reply-To:References; b=Kl1dxv9vkBwvSTlKqZ9GLPMM9/j7O7F1b52X1VGe1Q7cz5IRjLUy2Wdh/0O4DiQxF OSsoaWuMnAF3L94w9BUNnvZWRGCMBa7y/xQdqG7LLFwUJI4xkdfEMwpZMdXO3/jNzM v6UJUbG1055ujKV8TdN5YcYn5h9Cs7VMSmfQPcIk= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Dec 2017 13:10:47 +0200 From: freebsd.arch@clogic.com.ua To: freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? In-Reply-To: <310c26e3-1818-a7de-9606-2a74c3cd84c3@freebsd.org> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <0f11ca9a-c28f-6667-9509-11a1ba05ff98@freebsd.org> <98201b70579455dfa4fa58aebd3181b3@clogic.com.ua> <201712101331.vBADVcxH078614@donotpassgo.dyslexicfish.net> <310c26e3-1818-a7de-9606-2a74c3cd84c3@freebsd.org> Message-ID: X-Sender: freebsd.arch@clogic.com.ua User-Agent: Roundcube Webmail/1.3.3 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 11:10:58 -0000 On 2017-12-11 02:55, Nathan Whitehorn wrote: > On 12/10/17 12:08, K. Macy wrote: >> On Sun, Dec 10, 2017 at 6:27 AM, wrote: >>> On 2017-12-10 15:31, Jamie Landeg-Jones wrote: >>>> freebsd.arch@clogic.com.ua wrote: >>>> >>>>> Most users don't need a sandmail in base. As example, I always >>>>> disable >>>>> sendmail and install dma for local use or postfix for mail servers. >>>>> So I >>>>> can't understand, why I need do this every time as I install new >>>>> instance of FreeBSD in 2017? >>>> >>>> There are many valid arguments for and against removal, but I'm >>>> afraid >>>> that isn't one of them. >> That's not really the question. The question is "why won't 'pkg >> install sendmail' work for users that need it?" There are two >> technical reasons for why a component is in base and two emotional / >> political. >> >> The two technical reasons are: >> 1) The system won't work without it (e.g. rc files, kill, rm, etc) > > As a sub-point, we do want the base system to be a reliable and > consistent set of things such that scripts and instructions can > reference them; one of FreeBSD's strong points is that I can write a > script targeting "FreeBSD" and know that a reasonably complete system > is going to be present and that I won't find out that, say, ping or > telnet are not installed. This expands the set of important tools much > beyond "kill" and "rm" and means we should tread very, very carefully > in terms of moving things out of the base system -- this is one of my > major general reservations about the proposed implemention of pkgbase. > > That said, sendmail is *definitely* not in that category so long as > some basic MTA is there that makes reports from periodic etc. work. > The important thing is that mail(1) work, not that it be sendmail. So > I'm 100% in favor of dropping sendmail. > -Nathan I think the situation is similar to the one that was when bind replaced with unbound/ldns. A fully featured authoritative DNS server was removed from the base system and replaced with small and secure DNS resolver. >> 2) The component is tightly coupled to the kernel (e.g. bhyve) >> >> There are of course plenty of things which fall in to both buckets: >> libc, ifconfig, etc. >> >> The two emotional reasons are: >> 1) Emotional attachment (e.g. fortune) >> 2) Inertia (rcs, sendmail, etc) >> Thanks to bapt and friends pkg "just works" for most people for most >> cases. In conclusion, further discussion needs to either a) make a >> compelling case for why either my technical points are insufficient or >> the emotional drivers are critical; or b) explain why "pkg install >> sendmail" won't work. >> >> Cheers. >> -M From owner-freebsd-arch@freebsd.org Mon Dec 11 14:51:59 2017 Return-Path: Delivered-To: freebsd-arch@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 96D97E93E27 for ; Mon, 11 Dec 2017 14:51:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 71AAE68941 for ; Mon, 11 Dec 2017 14:51:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBBEpklN081612; Mon, 11 Dec 2017 06:51:46 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBBEpjIW081611; Mon, 11 Dec 2017 06:51:45 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> Subject: Re: RFC: Sendmail deprecation ? In-Reply-To: To: freebsd.arch@clogic.com.ua Date: Mon, 11 Dec 2017 06:51:45 -0800 (PST) CC: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 14:51:59 -0000 > On 2017-12-11 02:55, Nathan Whitehorn wrote: > > On 12/10/17 12:08, K. Macy wrote: > >> On Sun, Dec 10, 2017 at 6:27 AM, wrote: > >>> On 2017-12-10 15:31, Jamie Landeg-Jones wrote: > >>>> freebsd.arch@clogic.com.ua wrote: > >>>> > >>>>> Most users don't need a sandmail in base. As example, I always > >>>>> disable > >>>>> sendmail and install dma for local use or postfix for mail servers. > >>>>> So I > >>>>> can't understand, why I need do this every time as I install new > >>>>> instance of FreeBSD in 2017? > >>>> > >>>> There are many valid arguments for and against removal, but I'm > >>>> afraid > >>>> that isn't one of them. > >> That's not really the question. The question is "why won't 'pkg > >> install sendmail' work for users that need it?" There are two > >> technical reasons for why a component is in base and two emotional / > >> political. > >> > >> The two technical reasons are: > >> 1) The system won't work without it (e.g. rc files, kill, rm, etc) > > > > As a sub-point, we do want the base system to be a reliable and > > consistent set of things such that scripts and instructions can > > reference them; one of FreeBSD's strong points is that I can write a > > script targeting "FreeBSD" and know that a reasonably complete system > > is going to be present and that I won't find out that, say, ping or > > telnet are not installed. This expands the set of important tools much > > beyond "kill" and "rm" and means we should tread very, very carefully > > in terms of moving things out of the base system -- this is one of my > > major general reservations about the proposed implemention of pkgbase. > > > > That said, sendmail is *definitely* not in that category so long as > > some basic MTA is there that makes reports from periodic etc. work. > > The important thing is that mail(1) work, not that it be sendmail. So > > I'm 100% in favor of dropping sendmail. > > -Nathan > > I think the situation is similar to the one that was when bind replaced > with unbound/ldns. A fully featured authoritative DNS server was removed > from the base system and replaced with small and secure DNS resolver. It is very different, bind had decided to recode in a new language which would of required stuff not in base to build it, that made bind very unattractive. Also no one has made any proof what so ever that DMA is more secure than sendmail, infact the opposite is actually more likely simply due to useage exposure. > >> 2) The component is tightly coupled to the kernel (e.g. bhyve) > >> > >> There are of course plenty of things which fall in to both buckets: > >> libc, ifconfig, etc. > >> > >> The two emotional reasons are: > >> 1) Emotional attachment (e.g. fortune) > >> 2) Inertia (rcs, sendmail, etc) > >> Thanks to bapt and friends pkg "just works" for most people for most > >> cases. In conclusion, further discussion needs to either a) make a > >> compelling case for why either my technical points are insufficient or > >> the emotional drivers are critical; or b) explain why "pkg install > >> sendmail" won't work. > >> > >> Cheers. > >> -M > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Mon Dec 11 18:28:58 2017 Return-Path: Delivered-To: freebsd-arch@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 27380E9A11C for ; Mon, 11 Dec 2017 18:28:58 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 092CD725E9; Mon, 11 Dec 2017 18:28:57 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 940AEC85; Mon, 11 Dec 2017 12:28:55 -0600 (CST) Date: Mon, 11 Dec 2017 12:28:54 -0600 From: Mark Linimon To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171211182854.GA31885@lonesome.com> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <9013f916-b431-fa8b-81d1-50f380d10aa1@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9013f916-b431-fa8b-81d1-50f380d10aa1@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 18:28:58 -0000 On Sun, Dec 10, 2017 at 01:00:01AM +0800, Julian Elischer wrote: > I would like to propose the deprecation then removal of the BSD kernel > in base. Deprecation will happen in the form of FreeBSD 12.0 being built > WITHOUT_KERNEL by default removal would happen in FreeBSD 13.0 Thank you helping to turn this mailing list into one more thing that demotivates as well. (ports@ had already achieved that status.) Merry Christmas and plonk. mcl From owner-freebsd-arch@freebsd.org Mon Dec 11 20:09:43 2017 Return-Path: Delivered-To: freebsd-arch@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 4D9DEE9CF61 for ; Mon, 11 Dec 2017 20:09:43 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com [174.136.104.178]) (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 3A14C76986 for ; Mon, 11 Dec 2017 20:09:42 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from localhost (unknown [208.184.5.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sean@chittenden.org) by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id 8EF192F8577; Mon, 11 Dec 2017 11:59:39 -0800 (PST) Date: Mon, 11 Dec 2017 11:59:38 -0800 From: Sean Chittenden To: "Rodney W. Grimes" Cc: freebsd.arch@clogic.com.ua, freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171211195938.dxfji2pf2sq63my7@chittenden.org> References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aevwyz7tynjkpmnv" Content-Disposition: inline In-Reply-To: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 20:09:43 -0000 --aevwyz7tynjkpmnv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > That's not really the question. The question is "why won't 'pkg install > sendmail' work for users that need it?" There are two technical reasons f= or > why a component is in base and two emotional / political. There's also a workflow issue. Receiving feedback from systems via email messages is quaint (albeit convenient for low numbers of systems). It's on= ly has value for administrators who have a process setup that lets them consume this information or use the information as an audit log (??!!??). If someo= ne has opted into this style of workflow, they're going to drop something off = in sendmail.cf or whatever their MDA config file happens to be. +1 for deprecating this from base and giving people the choice to `pkg inst= all sendmail`. For everyone else deploying large numbers of systems, this is tedious to rip out and yet-another-thing to explain as a requirement when operationalizing FreeBSD for production workloads. -sc --=20 Sean Chittenden --aevwyz7tynjkpmnv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTRIj1cp7k0J1oEx9ROvJ3BbC5eFgUCWi7jqgAKCRBOvJ3BbC5e Fil0AKCCzq3yXVNzAOpKigJLNx7QHL34GwCfUpcij3x7CzPXP5VLht/T7Ilsdt4= =ZkWP -----END PGP SIGNATURE----- --aevwyz7tynjkpmnv-- From owner-freebsd-arch@freebsd.org Mon Dec 11 23:49:16 2017 Return-Path: Delivered-To: freebsd-arch@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 692ACE80325 for ; Mon, 11 Dec 2017 23:49:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE0D7FE36 for ; Mon, 11 Dec 2017 23:49:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from [10.0.0.64] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTPSA id vBBNiBE4016179 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Dec 2017 18:44:11 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Mon, 11 Dec 2017 18:44:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: RFC: Sendmail deprecation ? From: Daniel Eischen X-Mailer: iPhone Mail (15C114) In-Reply-To: <20171211195938.dxfji2pf2sq63my7@chittenden.org> Date: Mon, 11 Dec 2017 18:44:11 -0500 Cc: "Rodney W. Grimes" , freebsd.arch@clogic.com.ua, freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> To: Sean Chittenden X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:49:16 -0000 On Dec 11, 2017, at 2:59 PM, Sean Chittenden wrote: > +1 for deprecating this from base and giving people the choice to `pkg ins= tall > sendmail`. For everyone else deploying large numbers of systems, this is > tedious to rip out and yet-another-thing to explain as a requirement when > operationalizing FreeBSD for production workloads. I do tend to agree with rgrimes, when -base is pkg-ized, folks will have a c= hance to 'pkg install' or 'pkg remove' sendmail or anything else regardless o= f whether it is in -base or -ports. The question should be, where do we wan= t to maintain it? (There's also the history that exists in base that gets d= isconnected when it's in ports.) -base is a set of packages that we deem more important than ports. Does sen= dmail, as it is exists and configured in -base, pass muster for being someth= ing that we consider important enough to warrant being in base? I think thi= s is more of the question to ask than "why can't they install it from ports?= " Consensus seems to indicate no, but that we need some mail delivery agent= . I also think it should be incumbent on whomever removes something from -base= to make a port of it. I don't think we should just throw it over the fence= and expect the ports team to do the work, unless they volunteer for it. -- DE= From owner-freebsd-arch@freebsd.org Tue Dec 12 00:17:59 2017 Return-Path: Delivered-To: freebsd-arch@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 ABBD2E80F26 for ; Tue, 12 Dec 2017 00:17:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (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 789EE80BB8; Tue, 12 Dec 2017 00:17:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f47.google.com with SMTP id o130so14977056itg.0; Mon, 11 Dec 2017 16:17:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=lj1v+/6MxIm241hjLd9BT0tAdQERoSDN0wRk+qmF38c=; b=HkhjVxz8tFCR4qyYTMbMTf2OS97zQrrRr5aYEsPvxjwzjZrnsniO6BGwjgdqtCzOyy YAjBGahd0B4BKyieJ4fz+Rr9KUy6eWVDY924+WQfT+RK9js5N4lASjOz4vZTFty5lsHn kzqe1nsjiikuWP9vXZ9WAIv88+EX+Gw1XzjzNL0XPDI4IpgiXPQMjiFvRSgy2oSxWc8m QIW5yMAYcXbmSBNhSAhudZDBJMBdS6ZGF3sGKtU5Iy3/JhM3kTxUOlZS9IR0IwKUaDuh Oa8jCW6ltQDdGHAsTczmuux8A0IxzKgXmDjEOU3BW/Co9rU4AJ2LnfABnyocrTJYoG/g grMA== X-Gm-Message-State: AKGB3mK5yAsRBsAeP02fPGgI2SXbkX6ZoQzSxCSRHfipncyZl6KBMajh CPxANlq2Wtp44/roRyxbN0cVdlag X-Google-Smtp-Source: ACJfBou+5jNEzzGOJtESS8McTVt3Ao5cH2NJcCG3Z45CqRA/PO3tB5pFRox6EFnEyMW+QVwKB7n+1A== X-Received: by 10.36.173.92 with SMTP id a28mr148137itj.122.1513037502745; Mon, 11 Dec 2017 16:11:42 -0800 (PST) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com. [209.85.214.46]) by smtp.gmail.com with ESMTPSA id i82sm3078273iod.6.2017.12.11.16.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 16:11:41 -0800 (PST) Received: by mail-it0-f46.google.com with SMTP id m11so14963670iti.1; Mon, 11 Dec 2017 16:11:41 -0800 (PST) X-Received: by 10.107.7.169 with SMTP id g41mr3241105ioi.38.1513037501729; Mon, 11 Dec 2017 16:11:41 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.165.150 with HTTP; Mon, 11 Dec 2017 16:11:41 -0800 (PST) In-Reply-To: <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> From: Conrad Meyer Date: Mon, 11 Dec 2017 16:11:41 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Sendmail deprecation ? To: Daniel Eischen Cc: freebsd.arch@clogic.com.ua, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 00:17:59 -0000 On Mon, Dec 11, 2017 at 3:44 PM, Daniel Eischen wrot= e: > I do tend to agree with rgrimes, when -base is pkg-ized, folks will have = a chance to 'pkg install' or 'pkg remove' sendmail or anything else regardl= ess of whether it is in -base or -ports. pkg-base is totally orthogonal to the selection of what components we want to have in base. Base is really about defaults, and "what makes a FreeBSD system." There's no reason to block this change on pkgbase, or vice versa. People can remove the sendmail component on their system today, but it isn't the default. > The question should be, where do we want to maintain it? (There's also = the history that exists in base that gets disconnected when it's in ports.) > > -base is a set of packages that we deem more important than ports. Does = sendmail, as it is exists and configured in -base, pass muster for being so= mething that we consider important enough to warrant being in base? I thin= k this is more of the question to ask than "why can't they install it from = ports?" Consensus seems to indicate no, but that we need some mail deliver= y agent. > > I also think it should be incumbent on whomever removes something from -b= ase to make a port of it. I disagree with that idea in general. The burden lands on people who actually want to maintain the component, which may or may not overlap with the person removing it from base. Removing a component is not volunteering to maintain a port of that component, and shouldn't be. (Also, having people who are willing to maintain a component is not by itself sufficient justification for a component to remain in base.) > I don't think we should just throw it over the fence and expect the port= s team to do the work, unless they volunteer for it. mail/sendmail has been available as a port since 2000. Best, Conrad From owner-freebsd-arch@freebsd.org Tue Dec 12 12:53:05 2017 Return-Path: Delivered-To: freebsd-arch@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 39AF8E97AF6 for ; Tue, 12 Dec 2017 12:53:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9E2D7B154; Tue, 12 Dec 2017 12:53:04 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from [10.0.0.64] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTPSA id vBCCqvH3020680 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Dec 2017 07:52:58 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 12 Dec 2017 07:52:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: RFC: Sendmail deprecation ? From: Daniel Eischen X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Tue, 12 Dec 2017 07:52:57 -0500 Cc: freebsd.arch@clogic.com.ua, "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4C07192B-7B02-4A39-BEE5-CF60C6B2A335@freebsd.org> References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> To: cem@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 12:53:05 -0000 > On Dec 11, 2017, at 7:11 PM, Conrad Meyer wrote: >=20 >> On Mon, Dec 11, 2017 at 3:44 PM, Daniel Eischen wr= ote: >> I do tend to agree with rgrimes, when -base is pkg-ized, folks will have a= chance to 'pkg install' or 'pkg remove' sendmail or anything else regardles= s of whether it is in -base or -ports. >=20 > pkg-base is totally orthogonal to the selection of what components we > want to have in base. That's sort of my point, in reverse. Don't use "if you want softwareX, just= 'pkg install softwareX'" as a reason to remove softwareX from base. > Base is really about defaults, and "what makes > a FreeBSD system." There's no reason to block this change on pkgbase, > or vice versa. People can remove the sendmail component on their > system today, but it isn't the default. How do they remove sendmail once it's installed ('rm' is so quaint ;-))?. T= hey can't pkg remove it. And when upgrading from media again, it gets reins= talled? When base is pkg-ized, once it's pkg removed it is never reinstalle= d when upgrading. It is also easier to turn off the installation defaults w= ith pkg base, so that some software is never installed by default. Sure, wh= en building and installing world it, you have the WITHOUT knobs, but that do= esn't help other common installation methods. >> The question should be, where do we want to maintain it? (There's also t= he history that exists in base that gets disconnected when it's in ports.) >>=20 >> -base is a set of packages that we deem more important than ports. Does s= endmail, as it is exists and configured in -base, pass muster for being some= thing that we consider important enough to warrant being in base? I think t= his is more of the question to ask than "why can't they install it from port= s?" Consensus seems to indicate no, but that we need some mail delivery age= nt. >>=20 >> I also think it should be incumbent on whomever removes something from -b= ase to make a port of it. >=20 > I disagree with that idea in general. The burden lands on people who > actually want to maintain the component, which may or may not overlap > with the person removing it from base. Removing a component is not > volunteering to maintain a port of that component, and shouldn't be. > (Also, having people who are willing to maintain a component is not by > itself sufficient justification for a component to remain in base.) >=20 >> I don't think we should just throw it over the fence and expect the ports= team to do the work, unless they volunteer for it. >=20 > mail/sendmail has been available as a port since 2000. But that port reportedly doesn't have the FreeBSD configuration files that w= e have in base. You'd be pushing the burden of maintaining them onto the po= rts maintainer, making sure they work on all supported branches; they may no= t want that responsibility. -- DE= From owner-freebsd-arch@freebsd.org Wed Dec 13 00:42:56 2017 Return-Path: Delivered-To: freebsd-arch@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 54C29E8B5A5 for ; Wed, 13 Dec 2017 00:42:56 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3246D7AEF7; Wed, 13 Dec 2017 00:42:56 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vBD0gobj044049 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 13 Dec 2017 00:42:52 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vBD0gcOx052419 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2017 16:42:38 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Tue, 12 Dec 2017 16:42:32 -0800 (PST) From: Don Lewis Subject: Re: RFC: Sendmail deprecation ? To: Daniel Eischen cc: cem@freebsd.org, freebsd.arch@clogic.com.ua, "freebsd-arch@freebsd.org" In-Reply-To: <4C07192B-7B02-4A39-BEE5-CF60C6B2A335@freebsd.org> Message-ID: References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> <4C07192B-7B02-4A39-BEE5-CF60C6B2A335@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:42:56 -0000 On 12 Dec, Daniel Eischen wrote: > >> On Dec 11, 2017, at 7:11 PM, Conrad Meyer wrote: >> mail/sendmail has been available as a port since 2000. > > But that port reportedly doesn't have the FreeBSD configuration files > that we have in base. You'd be pushing the burden of maintaining them > onto the ports maintainer, making sure they work on all supported > branches; they may not want that responsibility. I haven't played with the port, but it may well be looking for the existing config files in /etc and not look in ${LOCALBASE}/etc at all. If that is the case, then if you modify the port to look in ${LOCALBASE}/etc, you'll break things for everybody who currently uses the port. If you try to limit that problem by having the port look at ${LOCALBASE}/etc only for FreeBSD versions where sendmail is removed from base, it complicates the port and the transition will still be messy for anyone who is using the binary packages that we distribute. From owner-freebsd-arch@freebsd.org Wed Dec 13 07:04:48 2017 Return-Path: Delivered-To: freebsd-arch@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 3527EE93752 for ; Wed, 13 Dec 2017 07:04:48 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CFEC564F98 for ; Wed, 13 Dec 2017 07:04:47 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (unknown [IPv6:2001:8b0:151:1:5806:dae1:c481:686c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id D6E67DDCC for ; Wed, 13 Dec 2017 07:04:44 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Subject: Re: RFC: Sendmail deprecation ? To: freebsd-arch@freebsd.org References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> <4C07192B-7B02-4A39-BEE5-CF60C6B2A335@freebsd.org> From: Matthew Seaman Message-ID: <28aa78af-bab6-b989-ade5-323a107b5842@FreeBSD.org> Date: Wed, 13 Dec 2017 07:04:43 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="okIeaOWbxw9n9ONFIGdSf1r8u3aLHJMJ8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:04:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --okIeaOWbxw9n9ONFIGdSf1r8u3aLHJMJ8 Content-Type: multipart/mixed; boundary="duQaC9HqsM6cswk8MMscJ2Kl3f1VctWNj"; protected-headers="v1" From: Matthew Seaman To: freebsd-arch@freebsd.org Message-ID: <28aa78af-bab6-b989-ade5-323a107b5842@FreeBSD.org> Subject: Re: RFC: Sendmail deprecation ? References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> <4C07192B-7B02-4A39-BEE5-CF60C6B2A335@freebsd.org> In-Reply-To: --duQaC9HqsM6cswk8MMscJ2Kl3f1VctWNj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 13/12/2017 00:42, Don Lewis wrote: > On 12 Dec, Daniel Eischen wrote: >> >>> On Dec 11, 2017, at 7:11 PM, Conrad Meyer wrote: >=20 >>> mail/sendmail has been available as a port since 2000. >> >> But that port reportedly doesn't have the FreeBSD configuration files >> that we have in base. You'd be pushing the burden of maintaining them= >> onto the ports maintainer, making sure they work on all supported >> branches; they may not want that responsibility. >=20 > I haven't played with the port, but it may well be looking for the > existing config files in /etc and not look in ${LOCALBASE}/etc at all. > If that is the case, then if you modify the port to look in > ${LOCALBASE}/etc, you'll break things for everybody who currently uses > the port. If you try to limit that problem by having the port look at > ${LOCALBASE}/etc only for FreeBSD versions where sendmail is removed > from base, it complicates the port and the transition will still be > messy for anyone who is using the binary packages that we distribute. I don't use sendmail for my principle MTA any more, but I used to run the ports version of sendmail with the standard FreeBSD sendmail config bits in /etc/mail and the rc scripts from /etc/rc.d, since those aren't in the ports version yet. As I recall, it took about two variables in /etc/rc.conf to make that setup use the .mc library files installed by the port to build the sendmail config. To run everything out of ${LOCALBASE}/etc/mail, the port basically needs to take four files from the base system: /etc/rc.d/sendmail, /etc/mail/freebsd.mc, /etc/mail/freebsd.submit.mc and /etc/mail/Makefile. These can be copied into the port with minor changes, plus possibly with the addition one or two sample database files. All that can be installed conditionally on FreeBSD versions where the base sendmail has been removed, something that's quite common in the ports, and will not add much in the way of complexity to what is already a very complex port. All in all, not really an impediment to removing sendmail from base. Cheers, Matthew --duQaC9HqsM6cswk8MMscJ2Kl3f1VctWNj-- --okIeaOWbxw9n9ONFIGdSf1r8u3aLHJMJ8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKoBAEBCgCSFiEEGfFU7L8RLlBUTj8wAFE/EOCp5OcFAlow0QxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDE5 RjE1NEVDQkYxMTJFNTA1NDRFM0YzMDAwNTEzRjEwRTBBOUU0RTcUHG1hdHRoZXdA ZnJlZWJzZC5vcmcACgkQAFE/EOCp5OfAwRAAjE8vgw5E+8Jmh6b17aqb7Z6setVK 2x5MtAG/0q8ql12POtkjC9PVABZEzX4ZhxqaEvvzp5zgH35KIyqIGR6+yAQIsAVX sZ80IKc0Z8EytK2hCiXzM5BIXJB42h7FejULGrndAKFHYombkJ4AT7htWwr1vHv+ j77ADpt2ZL5DYrWew6ZFI+BAQNEc0delbbxNUO7W/b1vGkO+1UE/5CNlhLCC90Zy R99z4IQEHluXsAzJywIf3A4V5ac94JfEC0T7X+ywJemapwQ9gBovYxfH272BzZLy ZjKfki8k6w7Nj63L8Kg7BpjuY5xQhGuWASh2lt+qHTs5LrepJFpgO9j16AuFtRbt MvaEu2z6W9Loc6+EpKOZdFfksswHOT6wMWj0RZwNNh/NBjHTZsK5O/dLNZTyr4uK 2eMqIjRWIdrFltUOP9Q1ApZxfSHXQEUIeex9JaL4iMaJZheuhaFZ65OOBEhOnoGj fPcV8Y2S+/x3PRclWC+JvlB1Y6pH6cHduc3v3WvNDkJZkLK35c8T2UfhJ7i8gfLY 13VoZYc5Yxaa6QEmDMcQFbXUetc24TDjcb7msd4PHgATRvGtrcEyjFnyY76IOXS4 y+RNe6wa4V94YTJbJS5qpYV2q09EGsrvw6ooJ/Dq91T2OyobyJdCiKe5IUKP5aix FLHMDEqU8hFZ8Ts= =9mV8 -----END PGP SIGNATURE----- --okIeaOWbxw9n9ONFIGdSf1r8u3aLHJMJ8-- From owner-freebsd-arch@freebsd.org Wed Dec 13 13:21:05 2017 Return-Path: Delivered-To: freebsd-arch@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 04701E9DD06 for ; Wed, 13 Dec 2017 13:21:05 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id BBC1E702E0 for ; Wed, 13 Dec 2017 13:21:04 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id vBDDL29q039904 for ; Wed, 13 Dec 2017 07:21:02 -0600 (CST) (envelope-from karels@FreeBSD.org) Message-Id: <201712131321.vBDDL29q039904@mail.karels.net> To: "freebsd-arch@freebsd.org" From: Mike Karels Reply-to: karels@FreeBSD.org Subject: Re: RFC: Sendmail deprecation ? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39902.1513171262.1@mail.karels.net> Date: Wed, 13 Dec 2017 07:21:02 -0600 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 13:21:05 -0000 It is clear that there isn't a consensus on a single choice of MTA, and that is fine. Here is a summary of my take on current options after reading the discussion to this point: First, we seem to agree that the target for a default setup is not that of an Internet-facing MTA, which requires some thought and configuration. Instead, the target is an originate-only system that does either on-box mail delivery or outbound delivery. At the very least, it can deliver the sysadmin emails configured by default. The options that have been presented: o Use dma. That would apparently suffice for some systems, and is already in base. However, in my opinion, it is missing some capabilities that some sites (including mine) may require: - .forward processing - Its masqerade configuration seems to be too simplistic, e.g. masquerade all or nothing, rather then exempting root and other specified system users. - Some mail clients, e.g. perl packages that we use at $JOB, connect to localhost:25 (or SMTP on some other host) rather than invoking "sendmail" directly. dma will not support these. In addition, it is not as well integrated into the system. It wasn't immediately obvious to me how to enable it, until I followed the "See Also" to mailwrapper; I guess I knew that at one time. It also requires manual configuration of TLS and a certificate if you want to use TLS. o Use the sendmail in base, configured for submission only. This is completely integrated and works out of the box. It has none of the limitations listed for dma. IIRC, a certificate is generated automatically so that TLS could work with no additional configuration. Presumably this could be done for dma as well, but it has not been done. o Use the sendmail in ports. This is apparently more full-featured, but not as nicely integrated with FreeBSD. No one has volunteered to resolve this so far. Or maybe it isn't that hard. But it wouldn't work "out of the box;" the system woudln't have this MTA available until manually installed. o Use some other MTA, e.g. OpenSMTPD. Of course there are Postfix, Exim and probably others, mostly aimed at full-service MTAs. I know little about these, but they are not pre-configured. (OK, I once configured an Exim system and got it to do what was required for a test, but I've blocked it from my mind.) Another issue that has been brought up: o It's a bother to remove sendmail to replace it with something else if it is not a package. I don't understand; isn't it just a matter of putting sendmail_submit_enable="NO" into /etc/rc.conf to be ready to configure something else? Or are people so short of disk space that they need to remove the binary, config files, etc? It seems to me that the option that is best-integrated, and which serves the needs of the greatest number of systems, is the sendmail in base. I still favor a configuration step that selects one of a small number of MTA choices and configures it, but we don't seem to have a framework for doing that now if we want something to be working out-of-the box. Thus, I think that removing sendmail from base now would make the system less flexible and usable. Mike From owner-freebsd-arch@freebsd.org Wed Dec 13 16:25:51 2017 Return-Path: Delivered-To: freebsd-arch@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 0CB14EA3154 for ; Wed, 13 Dec 2017 16:25:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EAF9377762 for ; Wed, 13 Dec 2017 16:25:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E7516EA3153; Wed, 13 Dec 2017 16:25:50 +0000 (UTC) Delivered-To: arch@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 E6EE8EA3152 for ; Wed, 13 Dec 2017 16:25:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C176F77761; Wed, 13 Dec 2017 16:25:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (unknown [128.57.46.190]) by mail.baldwin.cx (Postfix) with ESMTPSA id CA1FE10A87D; Wed, 13 Dec 2017 11:25:42 -0500 (EST) Subject: Re: RFC: Sendmail deprecation ? To: "Rodney W. Grimes" , Baptiste Daroussin References: <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net> Cc: arch@freebsd.org, gshapiro@freebsd.org From: John Baldwin Message-ID: <30011daa-f732-b1cb-2375-e940d02b3552@FreeBSD.org> Date: Wed, 13 Dec 2017 11:25:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 13 Dec 2017 11:25:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 16:25:51 -0000 On 12/7/17 11:05 AM, Rodney W. Grimes wrote: >> Hi all, >> >> I would like to propose the deprecation then removal of sendmail in base. >> >> Deprecation will happen in the form of FreeBSD 12.0 being built WITHOUT_SENDMAIL >> by default > > Thats not proper by procedure, FreeBSD 12.0 needs to have a binary that > spits out a > "This program is depricated and well be removed in the next release", > that would include all programs that are part of sendmail. It would be sufficient to emit a warning from rc.sendmail during boot if sendmail is enabled. It is not required that /usr/bin/sendmail issue a warning, just that "use of the feature". Also, the deprecation policy are guidelines, not hard rules. For some programs it would break the program's functionality to alter a program's output. >> removal would happen in FreeBSD 13.0 > > if you set WITHOUT_SENDMAIL in 12.- it is removed from 12.0 release, > so if your intent is to "remove" it in 13 you need to change when > you set WITHOUT_SENDMAIL to 13.0 Pragmatically, we aren't going to maintain sendmail in base for another 10 years. We can also merge the deprecation notices to 11 which will then ship in releases for a year before 12.0 is released. > I suspect that less than 1% of FreeBSD users are "entreprised(sp) grade" so the > argument that our users need ldap is just a strawman. The fact that you > use dma(8) to replace it only reinforces that fact. Actually, the point is most FreeBSD users don't need an actual mail server, just mail forwarding for which dma(8) is fine. It is very analagous to unbound vs bind. > Strong opinion expressed, procedure is not being followed by this request, > hence I would say no to this request as worded. I think this is open to interpretation. Your interpretation in general seems to be tighter than the view of most other developers (including those who drafted the existing policy). In part, the wording in the committer's guide is actually rather old and dates from a time when we as a Project did not have as much experience with removing things that are stale and no longer maintained (at least in base. ports has a more-regularly-enforced policy). The policy in the committer's guide should probably be revisisted and possibly adjusted. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Dec 13 17:10:36 2017 Return-Path: Delivered-To: freebsd-arch@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 6A4BBE8039E for ; Wed, 13 Dec 2017 17:10:36 +0000 (UTC) (envelope-from markic296@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 E482A791E4 for ; Wed, 13 Dec 2017 17:10:35 +0000 (UTC) (envelope-from markic296@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id 94so3471151lfy.10 for ; Wed, 13 Dec 2017 09:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7dH00Chycu6FbGH5deebtU67dknQzalpjtkr3EjZcXg=; b=EOOCWD1Ox0+yUYHL7Bzp/NnhZ6NWw5Gjz9W03qy9HWo/kLkPdBXalgC8cx2m/rQFrj wDJu3/ieoT+Xl4owxSCbwLADOpxXevlc4ur35+YJ2z04Aoq+hcH5BfBosdfv52qnFxk6 1pOHpzos28e4L8G9xU2zmt2UVf2XQINySN4Xp27UFkc1v7dDQ/w8pnCnM64+mU2FVkD1 waCNgVbfKl0pTm71fjKTOGguEBeq/0KOTyuik7tNeB9yEH/eZZVeEHjGrcx4fxPEpE2a HibmYH9IPNRztURYh9dZa9fNeQDMB4h4uwWTnmCeDFQi+by5w/rTdltsHvMlJqdzRQRH W2tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7dH00Chycu6FbGH5deebtU67dknQzalpjtkr3EjZcXg=; b=m4Ba7Vdal1tfqLCW4bnXSWdOlGedNRGmGsbUJsIcofilv91dTqKAZDs+BzOr5Baj1j suVa2a+hEeYpIcyy+y0QIFDkwbAUJOHnuNzoxACTtSoXSNaCOZTbRSQBPA8XnneWcM5H GJ8S7PvTZ7VVPypXrLRxNo5l57ls4a7/lN0z/Enz8uChm6ZPJUJaSVEiMpLZwgxYhYlZ uBLE+cSlsataQW9ECadrZt1LUOmSBAa4Rf/OQUJOubRvM/DX3wRTMUa0738rVVgjRtQg GRfShP6a2Yw96cnOZY7veaqcnDkBmdeNJi2CdfNaUaZuPi8rYDp6WKf5+bo6HKFpudQH emIA== X-Gm-Message-State: AKGB3mLqcCHO0KD2wzX3V2hPcIHf1oPaC10qgnSzWSV5V9Ry8Ij5jC97 Pr7ApWUf6aTKHqfefhjC3YVD0Nhyn2N1Rnitnss= X-Google-Smtp-Source: ACJfBotXgi5vqm/Z+MT8DGJ/k5PqpoZjDd7ZKCeuAZLZbpUTyjigGkQ7jwQTIjOKp7HEMlSeAYiZZAwX83mJtoWopsk= X-Received: by 10.46.75.1 with SMTP id y1mr1951047lja.141.1513185033822; Wed, 13 Dec 2017 09:10:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.15.161 with HTTP; Wed, 13 Dec 2017 09:10:32 -0800 (PST) Received: by 10.25.15.161 with HTTP; Wed, 13 Dec 2017 09:10:32 -0800 (PST) From: marko markic Date: Wed, 13 Dec 2017 19:10:32 +0200 Message-ID: Subject: To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 17:10:36 -0000 From owner-freebsd-arch@freebsd.org Thu Dec 14 00:39:01 2017 Return-Path: Delivered-To: freebsd-arch@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 6EC89E8C1B7 for ; Thu, 14 Dec 2017 00:39:01 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 566C56A50F; Thu, 14 Dec 2017 00:39:00 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id A06781160; Wed, 13 Dec 2017 18:38:53 -0600 (CST) Date: Wed, 13 Dec 2017 18:38:52 -0600 From: Mark Linimon To: Mike Karels Cc: "freebsd-arch@freebsd.org" Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171214003852.GA7123@lonesome.com> References: <201712131321.vBDDL29q039904@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712131321.vBDDL29q039904@mail.karels.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 00:39:01 -0000 On Wed, Dec 13, 2017 at 07:21:02AM -0600, Mike Karels wrote: > It seems to me that the option that is best-integrated, and which serves > the needs of the greatest number of systems, is the sendmail in base. I will submit the following from one of my boards: # uname -a FreeBSD orangepiplus2e 12.0-CURRENT FreeBSD 12.0-CURRENT #10 r326497M: Sun Dec 3 22:14:12 UTC 2017 linimon@burner12.lonesome.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm # whereis sendmail sendmail: /usr/sbin/sendmail /usr/share/man/man8/sendmail.8.gz /usr/ports/mail/sendmail i.e. we are installing sendmail, by default, on single-board systems that may have less than or equal to 512M of RAM. I think this is silly. mcl From owner-freebsd-arch@freebsd.org Thu Dec 14 01:46:12 2017 Return-Path: Delivered-To: freebsd-arch@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 197DAE8EA3C for ; Thu, 14 Dec 2017 01:46:12 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ECF646CB49; Thu, 14 Dec 2017 01:46:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vBE1kFcg047456 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 14 Dec 2017 01:46:16 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vBE1k27W088835 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2017 17:46:03 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Wed, 13 Dec 2017 17:45:57 -0800 (PST) From: Don Lewis Subject: Re: RFC: Sendmail deprecation ? To: Mark Linimon cc: Mike Karels , "freebsd-arch@freebsd.org" In-Reply-To: <20171214003852.GA7123@lonesome.com> Message-ID: References: <201712131321.vBDDL29q039904@mail.karels.net> <20171214003852.GA7123@lonesome.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:46:12 -0000 On 13 Dec, Mark Linimon wrote: > On Wed, Dec 13, 2017 at 07:21:02AM -0600, Mike Karels wrote: >> It seems to me that the option that is best-integrated, and which serves >> the needs of the greatest number of systems, is the sendmail in base. > > I will submit the following from one of my boards: > > # uname -a > FreeBSD orangepiplus2e 12.0-CURRENT FreeBSD 12.0-CURRENT #10 r326497M: Sun Dec 3 22:14:12 UTC 2017 linimon@burner12.lonesome.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm > # whereis sendmail > sendmail: /usr/sbin/sendmail /usr/share/man/man8/sendmail.8.gz /usr/ports/mail/sendmail > > i.e. we are installing sendmail, by default, on single-board systems > that may have less than or equal to 512M of RAM. > > I think this is silly. Not really silly. This machine runs sendmail as one of its primary jobs: FreeBSD 11.1-STABLE #0 r325913: Fri Nov 17 04:13:36 UTC 2017 dl@mousie.catspoiler.org:/usr/obj/i386.i386/usr/src/sys/GW i386 FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) VT(vga): resolution 640x480 CPU: VIA Nehemiah (1000.06-MHz 686-class CPU) Origin="CentaurHauls" Id=0x698 Family=0x6 Model=0x9 Stepping=8 Features=0x381b93f VIA Padlock Features=0xdd real memory = 268435456 (256 MB) avail memory = 245055488 (233 MB) I used to run a corporate mail relay with sendmail on a Pentium machine with 128 MB of RAM. From owner-freebsd-arch@freebsd.org Thu Dec 14 01:47:24 2017 Return-Path: Delivered-To: freebsd-arch@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 36BF0E8EAD2 for ; Thu, 14 Dec 2017 01:47:24 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5586CC27; Thu, 14 Dec 2017 01:47:23 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 6108812F4; Wed, 13 Dec 2017 19:47:22 -0600 (CST) Date: Wed, 13 Dec 2017 19:47:21 -0600 From: Mark Linimon To: Don Lewis Cc: "freebsd-arch@freebsd.org" , Mike Karels Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171214014721.GC7123@lonesome.com> References: <201712131321.vBDDL29q039904@mail.karels.net> <20171214003852.GA7123@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:47:24 -0000 On Wed, Dec 13, 2017 at 05:45:57PM -0800, Don Lewis wrote: > Not really silly. It's silly to be in the default install on an arm board IMHO. mcl From owner-freebsd-arch@freebsd.org Thu Dec 14 02:02:56 2017 Return-Path: Delivered-To: freebsd-arch@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 2582EE8F36D for ; Thu, 14 Dec 2017 02:02:56 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id D2C9D6D57D; Thu, 14 Dec 2017 02:02:55 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id vBE22stW041959; Wed, 13 Dec 2017 20:02:54 -0600 (CST) (envelope-from karels@FreeBSD.org) Message-Id: <201712140202.vBE22stW041959@mail.karels.net> To: Mark Linimon cc: Don Lewis , "freebsd-arch@freebsd.org" From: Mike Karels Reply-to: karels@FreeBSD.org Subject: Re: RFC: Sendmail deprecation ? In-reply-to: Your message of Wed, 13 Dec 2017 19:47:21 -0600. <20171214014721.GC7123@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41957.1513216974.1@mail.karels.net> Date: Wed, 13 Dec 2017 20:02:54 -0600 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:02:56 -0000 > On Wed, Dec 13, 2017 at 05:45:57PM -0800, Don Lewis wrote: > > Not really silly. > It's silly to be in the default install on an arm board IMHO. > mcl Presumably dealing with this issue is one of the goals of turning base into packages, and hopefully there can be different defaults for different architectures or profiles. Removing just sendmail won't get you much space back (especially if you just remove /usr/sbin/sendmail, which is just a symlink to mailwrapper). A small arm board is more likely to be single-purpose, but it's hard to guess what that purpose might be. I certainly wouldn't rule out the possibility of such a board originating mail, though. Mike From owner-freebsd-arch@freebsd.org Thu Dec 14 02:27:15 2017 Return-Path: Delivered-To: freebsd-arch@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 9C8CBE8FB99 for ; Thu, 14 Dec 2017 02:27:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 586C26DE5D; Thu, 14 Dec 2017 02:27:14 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id PJEseZuafss4TPJEteJi48; Wed, 13 Dec 2017 19:27:13 -0700 X-Authority-Analysis: v=2.2 cv=JuuBlIwC c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=ocR9PWop10UA:10 a=1QTDH3R-AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=pGGrLNlAlgBt3Z1z_qgA:9 a=CjuIK1q_8ugA:10 a=A7PbjfUNzwAiWwc5k9lq:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 22F65A7E; Wed, 13 Dec 2017 18:27:10 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id vBE2R9E1011354; Wed, 13 Dec 2017 18:27:09 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id vBE2R9e4011351; Wed, 13 Dec 2017 18:27:09 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201712140227.vBE2R9e4011351@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: karels@FreeBSD.org cc: Mark Linimon , Don Lewis , "freebsd-arch@freebsd.org" Subject: Re: RFC: Sendmail deprecation ? In-Reply-To: Message from Mike Karels of "Wed, 13 Dec 2017 20:02:54 -0600." <201712140202.vBE22stW041959@mail.karels.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 2017 18:27:09 -0800 X-CMAE-Envelope: MS4wfCLOjOej2ZgCYNZhhrTAzqgBPZF1I+BtSExZjAJmPRYzR8vlDq2Y5rXwrzX3/D/RVwXxt57p4BJHaoNmpIL+kdikyz8YwU31REUXNsE0bnIsNyIdOvga idDR5uCHMsKDqqGrTjMNAMPJRYWKAr2pxN7ndsXzdDxodwf/n6/k/jrJkCw6U101lyQUFkx1eIEWTknI7CXoV6df5qNFauI/Xuz7yCJU0+utTeE8aukDWX+q VFK2XR/ELEG2ul60moOc7FP3EyThIQWS5qEOrZITnHU= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:27:15 -0000 In message <201712140202.vBE22stW041959@mail.karels.net>, Mike Karels writes: > > On Wed, Dec 13, 2017 at 05:45:57PM -0800, Don Lewis wrote: > > > Not really silly. > > > It's silly to be in the default install on an arm board IMHO. > > > mcl > > Presumably dealing with this issue is one of the goals of turning base > into packages, and hopefully there can be different defaults for > different architectures or profiles. Removing just sendmail won't get > you much space back (especially if you just remove /usr/sbin/sendmail, > which is just a symlink to mailwrapper). A small arm board is more > likely to be single-purpose, but it's hard to guess what that purpose > might be. I certainly wouldn't rule out the possibility of such a board > originating mail, though. Especially with meta-packages for desktop, mail server, FAMP (FreeBSD, Apache, MySQL, PHP), network infrastructure, and other general server, or whatever else. What comes to mind are RPM groupings Red Hat has. At $JOB we use HPSA. Packaged base would allow us to play better in this space too. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Thu Dec 14 05:07:00 2017 Return-Path: Delivered-To: freebsd-arch@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 B389DE94D1C for ; Thu, 14 Dec 2017 05:07:00 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 69D1173146; Thu, 14 Dec 2017 05:07:00 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id w75so1677325vkd.7; Wed, 13 Dec 2017 21:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DEBqrq360WfWtu75g1BPHaXQG6Ls/bbvIPPK17PMTbo=; b=bKdgGtb8tgXKAZ8zJhFTSnvc2yX6nDa0gCDuT0LcrG/PX/wArnuJ8444zm9KFCFBtL c+YLUdIe3Up0+1n2uoXh4OH16TlpBnFiuEIYN+uSH8kFWm3XHfZafT75XBE6pRhoxK3T pvbm/3K8rdUdkpl0wsjbiXbInNwUc9c5kYrxp2NO29b1H0usNebIDaktsIi5Dt210h7y Vhco4gQLzodDy8+37+EFZtS2D1KNbqgOYyUoA/JZsryK4rzGMrkkcmr2UW97ZgbNuQiq DO1lGuK+8cr70Xz7EZjuAFo4UNgTV4k8+r6EhDLiS0P46mtqjWy5COC2Yvuvd4izURaD HpqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DEBqrq360WfWtu75g1BPHaXQG6Ls/bbvIPPK17PMTbo=; b=Ek1fN+GZnOmhj9XGYxHcZx/Hdhj0sDnnWoe1pC75KX+W5vhXlaPtZTPgmwv5D2ejAf SwKQbL8eo4Ll9l49yjw67JEHWozwIMsBBFfYllvRN54y3FDg+r8B9qWZGq5tfVy82Pv1 RucyDGOZyq/B02LFutaQWr08OwBkIzLOjbwjJelZLfLQlr8dxwx7Aj6N4Mnu8LCK/KWb SsbyeYh4jz26seF8H4H/7axEPxyZXjxu7u90BSR5rzr9t0lhuFMFOqA02zBtxG8Fzxl1 6CYwyPvvao23OXX0fxd7HJvp7oyLA8FwPk1gHpk1AdNQLII43MDLn9KlSf3y8giT15V7 pHwg== X-Gm-Message-State: AKGB3mLOKiWcEZnVvg07nyPmevRdNiIbeUpKemqEf4CJcyFEFiuZ94NF pTOcvszJcNsT5XdOlo4Ww8A3vltj1Kzieghg7mIeGg== X-Google-Smtp-Source: ACJfBouRA5NcZ1ejbE1cpWv7BkCpwYQIZ5O0UvaxpKwLaCMJAcY6jbiKZvFqOPET31MuuyLymYjnCjPecKvqHz0ELPY= X-Received: by 10.31.159.148 with SMTP id i142mr9844639vke.1.1513228019220; Wed, 13 Dec 2017 21:06:59 -0800 (PST) MIME-Version: 1.0 References: <20171214014721.GC7123@lonesome.com> <201712140202.vBE22stW041959@mail.karels.net> In-Reply-To: <201712140202.vBE22stW041959@mail.karels.net> From: Ben Woods Date: Thu, 14 Dec 2017 05:06:48 +0000 Message-ID: Subject: Re: RFC: Sendmail deprecation ? To: karels@freebsd.org Cc: Don Lewis , Mark Linimon , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 05:07:00 -0000 On Thu, 14 Dec 2017 at 3:03 pm, Mike Karels wrote: > > On Wed, Dec 13, 2017 at 05:45:57PM -0800, Don Lewis wrote: > > > Not really silly. > > > It's silly to be in the default install on an arm board IMHO. > > > mcl > > Presumably dealing with this issue is one of the goals of turning base > into packages, and hopefully there can be different defaults for > different architectures or profiles. I personally think that pkgbase doesn=E2=80=99t answer 2 questions: 1. What mail agent(s) do FreeBSD developers want to maintain the source for in the base tree? 2. What mail agent do we want installed and running on FreeBSD systems by default (without having answered any questions or made any changes... e.g. quickly provisioning 100 jails with a stock install). Sure people can remove packages, but to me that shouldn=E2=80=99t get in th= e way of making changes to match the general consensus answer to these 2 questions (whatever that may be). My vote is for dma, because it is small and simple. If a few features need to be added to dma to make it work for more people, suggest they should be added first (with the status of the necessary steps to progress towards removing sendmail being tracked on a wiki page). I think I am seeing the majority of people are for this, but there are a number of the people in the community and developers who are not. If there is not a clear consensus, perhaps this should be submitted as a FreeBSD Community Proposal (FCP). https://github.com/freebsd/fcp Regards, Ben > -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-arch@freebsd.org Thu Dec 14 06:34:05 2017 Return-Path: Delivered-To: freebsd-arch@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 C225BE983F1 for ; Thu, 14 Dec 2017 06:34:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 82EEA7680A; Thu, 14 Dec 2017 06:34:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 77C874221F6; Thu, 14 Dec 2017 17:33:57 +1100 (AEDT) Date: Thu, 14 Dec 2017 17:33:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Don Lewis cc: Mark Linimon , "freebsd-arch@freebsd.org" , Mike Karels Subject: Re: RFC: Sendmail deprecation ? In-Reply-To: Message-ID: <20171214165537.L835@besplex.bde.org> References: <201712131321.vBDDL29q039904@mail.karels.net> <20171214003852.GA7123@lonesome.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=cK6QihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=-FGs326eAAAA:8 a=e4myGqrZceLww_tcZxcA:9 a=CjuIK1q_8ugA:10 a=7Nw9HX5Nqxt2AnyyOhBr:22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 06:34:05 -0000 On Wed, 13 Dec 2017, Don Lewis wrote: > On 13 Dec, Mark Linimon wrote: >> On Wed, Dec 13, 2017 at 07:21:02AM -0600, Mike Karels wrote: >>> It seems to me that the option that is best-integrated, and which serves >>> the needs of the greatest number of systems, is the sendmail in base. >> >> I will submit the following from one of my boards: >> >> # uname -a >> FreeBSD orangepiplus2e 12.0-CURRENT FreeBSD 12.0-CURRENT #10 r326497M: Sun Dec 3 22:14:12 UTC 2017 linimon@burner12.lonesome.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm >> # whereis sendmail >> sendmail: /usr/sbin/sendmail /usr/share/man/man8/sendmail.8.gz /usr/ports/mail/sendmail >> >> i.e. we are installing sendmail, by default, on single-board systems >> that may have less than or equal to 512M of RAM. >> >> I think this is silly. > > Not really silly. This machine runs sendmail as one of its primary > jobs: > ... > real memory = 268435456 (256 MB) > avail memory = 245055488 (233 MB) > > I used to run a corporate mail relay with sendmail on a Pentium machine > with 128 MB of RAM. 512 MB is enormous. 128 MB is also large. Sendmail just worked for light use on a 486 with 16 MB. An i386 with 8 MB was more challenging. I only had 32 MB on a Pentium-1 machine. 32 MB still needed swapping, but I turned off swapping when 64 MB RAM became affordable (and used). The 32MB system ran netscape will no obvious problem except that it needed swapping for not much more than netscape. Bruce From owner-freebsd-arch@freebsd.org Thu Dec 14 17:56:19 2017 Return-Path: Delivered-To: freebsd-arch@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 9306AE893F3 for ; Thu, 14 Dec 2017 17:56:19 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [209.237.23.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 882616FE95 for ; Thu, 14 Dec 2017 17:56:19 +0000 (UTC) (envelope-from marquis@roble.com) Received: from roble.com (roble.com [209.237.23.50]) by mx5.roble.com (Postfix) with ESMTP id 6D2684C355 for ; Thu, 14 Dec 2017 09:56:13 -0800 (PST) Date: Thu, 14 Dec 2017 09:56:13 -0800 (PST) From: Roger Marquis To: freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:56:19 -0000 Mike Karels wrote: > Use dma. That would apparently suffice for some systems, and is already > in base. However, in my opinion, it is missing some capabilities ... > it is not as well integrated into the system. It wasn't > immediately obvious to me how to enable it, until I followed the > "See Also" to mailwrapper DMA has the best KIS, however, as you note it lacks key feature/s. IMO, it should be moved to ports. Mailwrapper should be moved as well (following the example of javavmwrapper). We've had so many issues with mailwrapper that it now is deleted on install, as well as **/etc/mail. > Use the sendmail in ports. When even sendmail's author recommends against it? > Use some other MTA Until Postfix has a BSD-compatible license my vote goes to OpenSMTPD configured not to listen to port 25 (for KIS and to keep it from being shared with jail localhosts). Roger From owner-freebsd-arch@freebsd.org Sat Dec 16 00:57:16 2017 Return-Path: Delivered-To: freebsd-arch@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 4AA18E917E2 for ; Sat, 16 Dec 2017 00:57:16 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 1A22F6DD24; Sat, 16 Dec 2017 00:57:16 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.78] (unknown [172.16.0.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4E961627E; Sat, 16 Dec 2017 00:57:15 +0000 (UTC) To: "freebsd-arch@freebsd.org" Cc: Warner Losh , Allan Jude From: Eric McCorkle Subject: loader.efi architecture for replacing boot1.efi Message-ID: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> Date: Fri, 15 Dec 2017 19:57:14 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 00:57:16 -0000 I have posted a review which begins to move loader.efi in the direction of replacing boot1.efi. The review can be found here: https://reviews.freebsd.org/D13497 This patch enables loader.efi to be installed to /efi/boot/BOOTX64.EFI on the ESP. It implements what I envision being the last-resort fallback mechanism, but this is enough to allow it to boot a FreeBSD system. It also preserves the existing behavior, so as not to break anyone's install. The *eventual* procedure for initial partition selection looks like this: 1) See if the boot loader arguments directly specify a kernel and/or partition, use that if they do. 2) If not, then attempt to read EFI vars to determine the boot location 3) If no EFI vars are defined, and no partition was specified, fall back to looking for an installed system on devices 4) At the very last, do the legacy (what loader.efi currently does) behavior. Step (3) is done by attempting to stat /boot/loader.conf and /boot/kernel. First, all partitions on the same disk are searched, then all remaining partitions are searched. This should allow mechanisms like EFI vars and command-line args to work without interference from the fallback mechanisms. However, it also provides robustness in the face of failure modes and uninitialized systems (I personally ran into a problem a while back with a linux system, where I couldn't boot with EFI, because the EFI vars weren't set, because I couldn't set them if I couldn't boot with EFI; had to use Shell.efi to sort out the mess...) More importantly, it provides a seamless transition from the way things are now to the way we want things to be. Please provide comments and feedback. From owner-freebsd-arch@freebsd.org Sat Dec 16 01:09:20 2017 Return-Path: Delivered-To: freebsd-arch@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 B7FA3E91A16 for ; Sat, 16 Dec 2017 01:09:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 79E7B6E19E for ; Sat, 16 Dec 2017 01:09:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id u62so22686250ita.2 for ; Fri, 15 Dec 2017 17:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Bt3k6aG5cstyBZeHXhvsMpVKCf4I8/NA0/Dqe5aZHtk=; b=HLrvy7xWYutNNZl3/NTtJnVfOiKpDeKc/5OeTZpkanlKne7t4nCBGhHv9tES8ecA9R XUPTrIkbdporzPV3L2TFgHy1r1HoyGncq1s3sVzOVkYNbfrLK1uwfNurUPCXJAy8dyUm elKTFvhM8RR2TPyoNwLhipMTcbGE1LOWfHThqHtMNUjJtMUhx6ztfQkWUufauSGHkg8f LBu2aieyv61ZuVgX8uDe6ypSkNo7bnAb0vAqUqd2ugbNM9QIWXrjsi1syFdYTSmCLE6Z LRJvm2dXblU+9xNXdbSM8c2I+fUEOqKE/JdvGTPeg8N4emImWtGfpngCodeQOw+7WpRZ RMkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Bt3k6aG5cstyBZeHXhvsMpVKCf4I8/NA0/Dqe5aZHtk=; b=UFgbRnRXtJBi0LJDlK3/oZBaMg8ZB7q9RWldUKrZgMJN56VgRG0omTGfMlPty6yICM M88AcquCRDDUT58UkyXzDbNYDJiJuzhwnI7VH7VeqYi6g1QH9HZ1UR/W0zcD/55KVky0 HxrbE7cNSklgH3Tt7Fgm3m7h7h+/L3pvdSDGCAHzKIjuAALG9XR4yj2pNGlojBKvrSL1 qFwT3C3A05VThR7JUuorldltMvR9WWWUx8vLP+6i3lcFh5cAWsfg1WaQi4ni9Z4n38OZ aAyPSpzBVotqYFubvbrCz8VRxgmhyx7hY1PfvgwtbJVuLzm4ETHXu6Z6aq09FH6TDQLe hMPQ== X-Gm-Message-State: AKGB3mJVyiXCalo6DNQDa+COQ6lKKR48zfgFD+exqcHhjtbbzDR/I83Q 5BCg1CuEGu860ZOX3EawgEchkmTloM0UT3lulTIimg== X-Google-Smtp-Source: ACJfBoskIaP6rLDfT68EdmnIvK+OnpdxyEy8eVp28+CWc509xCIn4FYbM7giLCnqGx3S+ZXXCJrUcGnk6MwKIPbvuDE= X-Received: by 10.36.147.193 with SMTP id y184mr3606006itd.64.1513386559684; Fri, 15 Dec 2017 17:09:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 17:09:18 -0800 (PST) X-Originating-IP: [2607:fb90:6f64:50fc:8dcb:1f9d:9ad:1368] Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 17:09:18 -0800 (PST) In-Reply-To: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> From: Warner Losh Date: Fri, 15 Dec 2017 18:09:18 -0700 X-Google-Sender-Auth: G3ZPA5QzZ0nbXKElwhp10z_Ml64 Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: freebsd-arch@freebsd.org, Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 01:09:20 -0000 On Dec 15, 2017 5:57 PM, "Eric McCorkle" wrote: I have posted a review which begins to move loader.efi in the direction of replacing boot1.efi. The review can be found here: https://reviews.freebsd.org/D13497 This patch enables loader.efi to be installed to /efi/boot/BOOTX64.EFI on the ESP. It implements what I envision being the last-resort fallback mechanism, but this is enough to allow it to boot a FreeBSD system. This will move to /efi/freebsd/loader.efi It also preserves the existing behavior, so as not to break anyone's install. The *eventual* procedure for initial partition selection looks like this: 1) See if the boot loader arguments directly specify a kernel and/or partition, use that if they do. This should be second. Uefi variables Trump all. 2) If not, then attempt to read EFI vars to determine the boot location 3) If no EFI vars are defined, and no partition was specified, fall back to looking for an installed system on devices This is fine, so long as it is only on the device that the loader loaded from. 4) At the very last, do the legacy (what loader.efi currently does) behavior. This is bogus. It violates the uefi boot loader protocol. We must abandon this legacy behavior. The behavior is actively harmful since something random will boot. This has caused actual operational issues at Netflix. Guessing is really bad. Step (3) is done by attempting to stat /boot/loader.conf and /boot/kernel. First, all partitions on the same disk are searched, then all remaining partitions are searched. This should allow mechanisms like EFI vars and command-line args to work without interference from the fallback mechanisms. However, it also provides robustness in the face of failure modes and uninitialized systems (I personally ran into a problem a while back with a linux system, where I couldn't boot with EFI, because the EFI vars weren't set, because I couldn't set them if I couldn't boot with EFI; had to use Shell.efi to sort out the mess...) More importantly, it provides a seamless transition from the way things are now to the way we want things to be. Please provide comments and feedback. Please listen when I say searching all devices is actively harmful. The uefi boot manager, which I'm in the process of bringing in, offers a way to specifically say what you want to boot. If someone needs something complicated, they must use that moving forward. Part of what makes the protocol work is loaders giving up early so the next one on the list can be tried. Warner From owner-freebsd-arch@freebsd.org Sat Dec 16 01:44:06 2017 Return-Path: Delivered-To: freebsd-arch@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 09E01E93ADE for ; Sat, 16 Dec 2017 01:44:06 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id D8D936FA3A; Sat, 16 Dec 2017 01:44:05 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.78] (unknown [172.16.0.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B777C6294; Sat, 16 Dec 2017 01:43:58 +0000 (UTC) Subject: Re: loader.efi architecture for replacing boot1.efi To: Warner Losh Cc: freebsd-arch@freebsd.org, Warner Losh , Allan Jude References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> From: Eric McCorkle Message-ID: <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> Date: Fri, 15 Dec 2017 20:43:58 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 01:44:06 -0000 On 12/15/2017 20:09, Warner Losh wrote: > This should be second. Uefi variables Trump all. > > 2) If not, then attempt to read EFI vars to determine the boot location > > 3) If no EFI vars are defined, and no partition was specified, fall back > to looking for an installed system on devices > > > This is fine, so long as it is only on the device that the loader loaded > from. It's fine if it's configurable, but there needs to be sane behavior if the EFI vars aren't set. > 4) At the very last, do the legacy (what loader.efi currently does) > behavior. > > > This is bogus. It violates the uefi boot loader protocol. We must > abandon this legacy behavior. The behavior is actively harmful since > something random will boot. This has caused actual operational issues at > Netflix. Guessing is really bad. We can't just ditch the current behavior and break everyone's existing install, though. Legacy behavior should be supported at least until the next major release. > > Step (3) is done by attempting to stat /boot/loader.conf and > /boot/kernel.  First, all partitions on the same disk are searched, then > all remaining partitions are searched. > > This should allow mechanisms like EFI vars and command-line args to work > without interference from the fallback mechanisms.  However, it also > provides robustness in the face of failure modes and uninitialized > systems (I personally ran into a problem a while back with a linux > system, where I couldn't boot with EFI, because the EFI vars weren't > set, because I couldn't set them if I couldn't boot with EFI; had to use > Shell.efi to sort out the mess...) > > More importantly, it provides a seamless transition from the way things > are now to the way we want things to be. > > Please provide comments and feedback. > > > Please listen when I say searching all devices is actively harmful. The > uefi boot manager, which I'm in the process of bringing in, offers a way > to specifically say what you want to boot. If someone needs something > complicated, they must use that moving forward. Part of what makes the > protocol work is loaders giving up early so the next one on the list can > be tried. We also have to deal with the reality that some EFI implementations are adversarial. We have to be able to deal with implementations that make it difficult to set EFI vars, or which mess with their values (Lenovo is particularly notorious for this). You can disable fallback mechanisms with command-line args or macros or whatever, but they need to be there. From owner-freebsd-arch@freebsd.org Sat Dec 16 02:05:19 2017 Return-Path: Delivered-To: freebsd-arch@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 6C777E95025 for ; Sat, 16 Dec 2017 02:05:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 2D53770ABD for ; Sat, 16 Dec 2017 02:05:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id x129so4528704iod.13 for ; Fri, 15 Dec 2017 18:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CZfcKAUk0jevRx8o9e/v3aqOXClZLrNkERE6A0YhQwA=; b=HpVLO5n6BVXc/I+24W87+4BRYqWtgKX3TgB4m/0Mfij8YeTEkn2c43B3aM1RC60iwn eqzcWaz9h9M4mI0i8vRnH24SQB8meZEzwowtf1MKNFp/saKYYBE8zhLa+UMXT2IEBmdS NTspvmstpJm892DgjmT+HW80BqTTsKC725cs7HD3WA8CHGLI6cG/50s7ruPnqT280izt upuLnS/DyfStDgoeErgXoIwSi3nuI5fqx4KF7jKNN8yD6Hva4Y7JN+ejL0P7/zw1zgLC A1aHraWKuJqt0BGru3MaduXVuNHDANztrTyOstHOB9QAYhtIf/pawcJNrHQ4MgTqibws 2p5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CZfcKAUk0jevRx8o9e/v3aqOXClZLrNkERE6A0YhQwA=; b=gO4ho74p7C6ceKizY3WQRn2u9YVGUwzxvONlbX+Mz97Oi0eDwBpfd6K9sKarPOZ8UX JRbq/GkYPTTDREM5JZBl4Fn0IpLqOmHkxnXQ0IKgi6peYv3KqlWeKJ85Kgx9ih6uGlY1 kXZFB8Hb52W2/4HM3/hYkRpwy9vg1m9nOZCM+PJ4GOzZ35G/rT56534MFApahZlL22v8 ATOh+LQUHRAuxsHpDIdCVON4deA+RlAZZjcqhibLX2yhZwQhWkT6oKGdXclDH+Q2Su6H Mqj4rLwyc0YhOQ/1htbzOLZ8jdYr2brv4gURW0RlUrsNWM4SWtomDZqDY3zJeBaLzrTF +xHw== X-Gm-Message-State: AKGB3mKbV5dW5LLjthsW4iWPnzVr2T9RApS4NJNrXxrkYU6fjUgp+4Ez UJPMQyWvWnXSmJbFJn3o4c68PUybHJLJbese4uOZ1w== X-Google-Smtp-Source: ACJfBovFP+X3G2u+b3UYbtxredzSESttrvrKvsmIkkVy7Jh1TCgTnl3qfwxQoSksAHMLtMvYFeZr5r0tMCyJIETzCyg= X-Received: by 10.107.48.197 with SMTP id w188mr14793945iow.301.1513389918303; Fri, 15 Dec 2017 18:05:18 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 18:05:17 -0800 (PST) X-Originating-IP: [2607:fb90:6f64:50fc:8dcb:1f9d:9ad:1368] Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 18:05:17 -0800 (PST) In-Reply-To: <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> From: Warner Losh Date: Fri, 15 Dec 2017 19:05:17 -0700 X-Google-Sender-Auth: CMf44LoMHcgkbCq4YQaASNaojU0 Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: freebsd-arch@freebsd.org, Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 02:05:19 -0000 On Dec 15, 2017 6:43 PM, "Eric McCorkle" wrote: On 12/15/2017 20:09, Warner Losh wrote: > This should be second. Uefi variables Trump all. > > 2) If not, then attempt to read EFI vars to determine the boot location > > 3) If no EFI vars are defined, and no partition was specified, fall back > to looking for an installed system on devices > > > This is fine, so long as it is only on the device that the loader loaded > from. It's fine if it's configurable, but there needs to be sane behavior if the EFI vars aren't set. Where do we get this info for such a broken setup? Do you have actual examples? > 4) At the very last, do the legacy (what loader.efi currently does) > behavior. > > > This is bogus. It violates the uefi boot loader protocol. We must > abandon this legacy behavior. The behavior is actively harmful since > something random will boot. This has caused actual operational issues at > Netflix. Guessing is really bad. We can't just ditch the current behavior and break everyone's existing install, though. Legacy behavior should be supported at least until the next major release. What useful setups does this break? Absent a real example, we absolutely are breaking this. There is a real cost to doing this that as the de facto maintainer of stand I'm unwilling to maintain, test or commit to not breaking. The legacy behavior is broken and has caused me hours of pain in production. There has been no articulated use case this enables, especially since boot loader can be interrupted to specify something in recovery scenarios. > > Step (3) is done by attempting to stat /boot/loader.conf and > /boot/kernel. First, all partitions on the same disk are searched, then > all remaining partitions are searched. > > This should allow mechanisms like EFI vars and command-line args to work > without interference from the fallback mechanisms. However, it also > provides robustness in the face of failure modes and uninitialized > systems (I personally ran into a problem a while back with a linux > system, where I couldn't boot with EFI, because the EFI vars weren't > set, because I couldn't set them if I couldn't boot with EFI; had to use > Shell.efi to sort out the mess...) > > More importantly, it provides a seamless transition from the way things > are now to the way we want things to be. > > Please provide comments and feedback. > > > Please listen when I say searching all devices is actively harmful. The > uefi boot manager, which I'm in the process of bringing in, offers a way > to specifically say what you want to boot. If someone needs something > complicated, they must use that moving forward. Part of what makes the > protocol work is loaders giving up early so the next one on the list can > be tried. We also have to deal with the reality that some EFI implementations are adversarial. We have to be able to deal with implementations that make it difficult to set EFI vars, or which mess with their values (Lenovo is particularly notorious for this). You can disable fallback mechanisms with command-line args or macros or whatever, but they need to be there. No. Absent a sane use case, I refuse. Give me a reasonable use case, I will reconsider. Warner From owner-freebsd-arch@freebsd.org Sat Dec 16 03:28:02 2017 Return-Path: Delivered-To: freebsd-arch@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 BBDD9E99A58 for ; Sat, 16 Dec 2017 03:28:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 7B20174307 for ; Sat, 16 Dec 2017 03:28:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id h12so4625424iof.6 for ; Fri, 15 Dec 2017 19:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=h+b8cpnyNsY842D9pRSPKOLtNvFYnE7tvekWx82q4js=; b=U+mEVUWB3kkW4p6ppbE5VSq/jy+Cz4dGNbXaeU+HLCufjqwSqNecbx9eWN8KWugZTQ upn0MFuDXHgEq2Y5yJO9BsBWFJhq2DwoLED6Dagysh4S4LFlki0sirV9mjffb9M2Gst9 58fk+lcIR7kfOMixAGf39jDTm3CHGx7o1qisbsl+eHhJF9i0EX9X+9yhEEAUG4RFaFOp fEdH5mIrLHX78dqjh6mj7lR5lsiTkU8wTz5YlnsKX8dL3HmibL0WOcS5hYM/Iib9WcVq 59ig18ugQSD9o67a/74bPrTwyWlmS8szdEHsrVyEOm+h6LJmTSHfkkiUu3fho2Oo3CkN DmlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=h+b8cpnyNsY842D9pRSPKOLtNvFYnE7tvekWx82q4js=; b=kaBEhkK8hgCSiozkfQwnBCGC1tTUTLW5Xcu4V6QtHSCLRruC5mzedCh1WNt2VYMIBQ FbV9b1lTLxk9vNqgWeW+MJ/vvuS/woFYYB1OSaz0mM9H/tyum4QpUjGWCITs3yW2HiQ4 60VT79BE6wsZYOC8B0yzqrsah3xh/R7qvT/C8H5+xCQpKJPrW9tkfFIydUbV60mvQVOt 6xSftFIOML/85UZ4jxSakpKAG/VhrHzCjt2R30CacszsSQz11YYzZvaHJqkJBlWBD7T/ tFgmSIDP3qHG7K44wy80+mYuXmiHe9YY/TBqvyHtBqjl5jbckufbfNtPjWkgWF5WNxo8 HGBA== X-Gm-Message-State: AKGB3mKOcEfrE0fHpscdgiiwL6nYu57m+igOmisQW+3a37VPlWkoNuBs o207Agkp7r8AmsqI087pWwodyHtCVZeUhdEVasRY8g== X-Google-Smtp-Source: ACJfBotPtm70C4+85chXneJwfuyLXYz8sYIlzH4MzAZGmEyY1z7sdA72g5wxjNZphom+9do8bAmQeNFXr1IHgmL7H1Y= X-Received: by 10.107.16.158 with SMTP id 30mr6610765ioq.291.1513394881588; Fri, 15 Dec 2017 19:28:01 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 19:28:00 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> From: Warner Losh Date: Fri, 15 Dec 2017 20:28:00 -0700 X-Google-Sender-Auth: OJet9z2R5MTgb7hymLkjUPBIiCE Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 03:28:02 -0000 On Fri, Dec 15, 2017 at 7:05 PM, Warner Losh wrote: > > > On Dec 15, 2017 6:43 PM, "Eric McCorkle" wrote: > > On 12/15/2017 20:09, Warner Losh wrote: > > > This should be second. Uefi variables Trump all. > > > > 2) If not, then attempt to read EFI vars to determine the boot > location > > > > 3) If no EFI vars are defined, and no partition was specified, fall > back > > to looking for an installed system on devices > > > > > > This is fine, so long as it is only on the device that the loader loaded > > from. > > It's fine if it's configurable, but there needs to be sane behavior if > the EFI vars aren't set. > > > Where do we get this info for such a broken setup? Do you have actual > examples? > > > 4) At the very last, do the legacy (what loader.efi currently does) > > behavior. > > > > > > This is bogus. It violates the uefi boot loader protocol. We must > > abandon this legacy behavior. The behavior is actively harmful since > > something random will boot. This has caused actual operational issues at > > Netflix. Guessing is really bad. > > We can't just ditch the current behavior and break everyone's existing > install, though. Legacy behavior should be supported at least until the > next major release. > > > What useful setups does this break? Absent a real example, we absolutely > are breaking this. There is a real cost to doing this that as the de facto > maintainer of stand I'm unwilling to maintain, test or commit to not > breaking. The legacy behavior is broken and has caused me hours of pain in > production. There has been no articulated use case this enables, especially > since boot loader can be interrupted to specify something in recovery > scenarios. > > > > > > Step (3) is done by attempting to stat /boot/loader.conf and > > /boot/kernel. First, all partitions on the same disk are searched, > then > > all remaining partitions are searched. > > > > This should allow mechanisms like EFI vars and command-line args to > work > > without interference from the fallback mechanisms. However, it also > > provides robustness in the face of failure modes and uninitialized > > systems (I personally ran into a problem a while back with a linux > > system, where I couldn't boot with EFI, because the EFI vars weren't > > set, because I couldn't set them if I couldn't boot with EFI; had to > use > > Shell.efi to sort out the mess...) > > > > More importantly, it provides a seamless transition from the way > things > > are now to the way we want things to be. > > > > Please provide comments and feedback. > > > > > > Please listen when I say searching all devices is actively harmful. The > > uefi boot manager, which I'm in the process of bringing in, offers a way > > to specifically say what you want to boot. If someone needs something > > complicated, they must use that moving forward. Part of what makes the > > protocol work is loaders giving up early so the next one on the list can > > be tried. > > We also have to deal with the reality that some EFI implementations are > adversarial. We have to be able to deal with implementations that make > it difficult to set EFI vars, or which mess with their values (Lenovo is > particularly notorious for this). > > You can disable fallback mechanisms with command-line args or macros or > whatever, but they need to be there. > > > No. Absent a sane use case, I refuse. Give me a reasonable use case, I > will reconsider. > > So the current behavior leads to absurd results that nobody else does, and that we don't do for legacy boot: If we boot loader.efi/boot1.efi off a hard drive, and find there's no kernel, we'll load off cdrom or a floppy if we happen to find a kernel there. That's nuts. What's more, we'll load off a different device (say a thumb drive), which is also crazy. The last thing you want is to accidentally pick the thumb drive recovery kernel that happens to be in a USB slot when you have a primary and secondary partition on two main disks, but today's behavior chooses that. It's so crazy that I can see no benefit from supporting, testing and maintaining this. If someone wants to recover a system, they can do it at the boot loader prompt now (they couldn't before). If someone really wants to boot his crazy thing, we have a new way to specify it specifically w/o any ambiguity based on how the devices might move around. We already support about 100 boot scenarios that are hard enough to test. I don't want to commit to supporting this and making it 120 or 150 once you work out all the combinatorics. We have to trim the matrix of useless things. So absent a use case that makes sense, that people are actually doing, I'm having a hard time justifying keeping it around as we transition. Warner P.S. On x86, we support geli/nogeli, gpt/mbr, ufs/zfs, and uefi/legacy/both (24 combinations). Plus we support booting off CDROM, netbooting, etc. For arm, and arm64 we have a similar number that are possible. zfs/ufs, u-boot/uefi, and mbr/gpt (plus a number of different u-boot boards). For mips we have a similar mix. Powerpc we support 4 or 6 ways. It's just too much to hope to test and ensure works. Each new thing has an non-trivial cost, and I see zero benefit from this one more thing, especially since it gets in the way of UEFI boot manager support. From owner-freebsd-arch@freebsd.org Sat Dec 16 04:54:19 2017 Return-Path: Delivered-To: freebsd-arch@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 C734FE9D48B for ; Sat, 16 Dec 2017 04:54:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 781FD774A2; Sat, 16 Dec 2017 04:54:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 0264962EB; Sat, 16 Dec 2017 04:54:18 +0000 (UTC) Subject: Re: loader.efi architecture for replacing boot1.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> From: Eric McCorkle Message-ID: Date: Fri, 15 Dec 2017 23:54:18 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 04:54:19 -0000 On 12/15/2017 22:28, Warner Losh wrote: > > > On Fri, Dec 15, 2017 at 7:05 PM, Warner Losh > wrote: > > > > On Dec 15, 2017 6:43 PM, "Eric McCorkle" > wrote: > > On 12/15/2017 20:09, Warner Losh wrote: > > > This should be second. Uefi variables Trump all. > > > >     2) If not, then attempt to read EFI vars to determine the boot location > > > >     3) If no EFI vars are defined, and no partition was specified, fall back > >     to looking for an installed system on devices > > > > > > This is fine, so long as it is only on the device that the loader loaded > > from. > > It's fine if it's configurable, but there needs to be sane > behavior if > the EFI vars aren't set. > > > Where do we get this info for such a broken setup? Do you have > actual examples? > > >     4) At the very last, do the legacy (what loader.efi currently does) > >     behavior. > > > > > > This is bogus. It violates the uefi boot loader protocol. We must > > abandon this legacy behavior. The behavior is actively harmful since > > something random will boot. This has caused actual operational issues at > > Netflix. Guessing is really bad. > > We can't just ditch the current behavior and break everyone's > existing > install, though.  Legacy behavior should be supported at least > until the > next major release. > > > What useful setups does this break? Absent a real example, we > absolutely are breaking this. There is a real cost to doing this > that as the de facto maintainer of stand I'm unwilling to maintain, > test or commit to not breaking. The legacy behavior is broken and > has caused me hours of pain in production. There has been no > articulated use case this enables, especially since boot loader can > be interrupted to specify something in recovery scenarios. > > > > > >     Step (3) is done by attempting to stat /boot/loader.conf and > >     /boot/kernel.  First, all partitions on the same disk are > searched, then > >     all remaining partitions are searched. > > > >     This should allow mechanisms like EFI vars and > command-line args to work > >     without interference from the fallback mechanisms.  > However, it also > >     provides robustness in the face of failure modes and > uninitialized > >     systems (I personally ran into a problem a while back with > a linux > >     system, where I couldn't boot with EFI, because the EFI > vars weren't > >     set, because I couldn't set them if I couldn't boot with > EFI; had to use > >     Shell.efi to sort out the mess...) > > > >     More importantly, it provides a seamless transition from > the way things > >     are now to the way we want things to be. > > > >     Please provide comments and feedback. > > > > > > Please listen when I say searching all devices is actively > harmful. The > > uefi boot manager, which I'm in the process of bringing in, > offers a way > > to specifically say what you want to boot. If someone needs > something > > complicated, they must use that moving forward. Part of what > makes the > > protocol work is loaders giving up early so the next one on > the list can > > be tried. > > We also have to deal with the reality that some EFI > implementations are > adversarial.  We have to be able to deal with implementations > that make > it difficult to set EFI vars, or which mess with their values > (Lenovo is > particularly notorious for this). > > You can disable fallback mechanisms with command-line args or > macros or > whatever, but they need to be there. > > > No. Absent a sane use case, I refuse. Give me a reasonable use case, > I will reconsider. > > > So the current behavior leads to absurd results that nobody else does, > and that we don't do for legacy boot: > > If we boot loader.efi/boot1.efi off a hard drive, and find there's no > kernel, we'll load off cdrom or a floppy if we happen to find a kernel > there. That's nuts. What's more, we'll load off a different device (say > a thumb drive), which is also crazy. The last thing you want is to > accidentally pick the thumb drive recovery kernel that happens to be in > a USB slot when you have a primary and secondary partition on two main > disks, but today's behavior chooses that. It's so crazy that I can see > no benefit from supporting, testing and maintaining this. If someone > wants to recover a system, they can do it at the boot loader prompt now > (they couldn't before). If someone really wants to boot his crazy thing, > we have a new way to specify it specifically w/o any ambiguity based on > how the devices might move around. > > We already support about 100 boot scenarios that are hard enough to > test. I don't want to commit to supporting this and making it 120 or 150 > once you work out all the combinatorics. We have to trim the matrix of > useless things.  So absent a use case that makes sense, that people are > actually doing, I'm having a hard time justifying keeping it around as > we transition. > > Warner > > P.S. On x86, we support geli/nogeli, gpt/mbr, ufs/zfs, and > uefi/legacy/both (24 combinations). Plus we support booting off CDROM, > netbooting, etc. For arm, and arm64 we have a similar number that are > possible. zfs/ufs, u-boot/uefi, and mbr/gpt (plus a number of different > u-boot boards). For mips we have a similar mix. Powerpc we support 4 or > 6 ways. It's just too much to hope to test and ensure works. Each new > thing has an non-trivial cost, and I see zero benefit from this one more > thing, especially since it gets in the way of UEFI boot manager support. Whatever happens, this needs to not break existing installs. We can remove probing floppy drives, fine (does anyone even HAVE those anymore?). CD-ROM drives, will break auto-detection when booting from a liveDVD, but that can be mitigated by specifying loader args (I suppose we'll need to have loader get args from the boot.config files eventually). But for now, loader.efi has got to work whether installed in a boot1/loader (legacy) configuration, or installed directly to the ESP. Otherwise, there's going to be a lot of unhappy people out there. As for the fallback search, it's just that: a fallback mechanism. Its job is to make a sane guess as to where to find the system, but ultimately it's not doing anything the user can't do themselves. And it will only run if the EFI vars aren't set anyway, so it can't possibly interfere with any of that. From owner-freebsd-arch@freebsd.org Sat Dec 16 05:49:54 2017 Return-Path: Delivered-To: freebsd-arch@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 2AF7CE9E31A for ; Sat, 16 Dec 2017 05:49:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 DE5C178961 for ; Sat, 16 Dec 2017 05:49:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id 87so620354ior.5 for ; Fri, 15 Dec 2017 21:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c3zSI1/GkrhMzrJ4oiaMsMTVN+IafnH7+A3/ozQGA08=; b=B5kEKTZyOz2S9DfMw2UormIslzpG89BiRsGXTYMq1q6TiBFZH4Xd7d0yE2kxfYYtMd EiIGSe9et+jzMeeREmOieDHWD8MuPeFN0V76lDpn3k01pfWXCUrwb6o6neJqqtNU1HuU k7grKlDNUsUFTlD4M/TYeRkIksv5ik64FLucyGIm0ZoI5INHFqRoPXldOfXw6BkINBQw DjsG4rQulW6pyCiOOuTXXhZ1+p0CUxXTm6COT9qQ9TGRHRzVZO52+QbC/lD1CuDw/51c 7SC04dD1vNup1VGVxxsANQHxwivX3d67KDHuwXd9FRhmnCQ4KuZSgWT5zGYuwq82Leu1 LwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=c3zSI1/GkrhMzrJ4oiaMsMTVN+IafnH7+A3/ozQGA08=; b=oldTzIsqlbbgM6E71k19vIUhS4H65N/Ob08mFysDAXG+5K15K93FeC/2dVxdiQCAY+ 4faWQCXvgDDdsu5G2JtcF2vrjSsXj1zkKBGvCeUflUPAhr1FgSoMsctMHIpoW50TD1uh A2JLZjYNW10JtQe7ZaZJFkv/97tNBJEFBnOts1O17XsavtErzV4tDZxO0k6I2q+nkBvR /qfXZkD5itluBwtbA4z+2lUBubTAs9R5Jqj2IhOZkyrH42p1RKNhi1pExVTgMx42ro0r rsepLfeaA3Q3P/RD70iriRa94WDplb+CywFYu1guFbICG5IBGv+2tmNF72FnSjBEH93T W97A== X-Gm-Message-State: AKGB3mLPFhWh66fXZUhsEykjG+Mt/uMtWoh+Oi0KqxMCR8NsITWVoOTg mr7feRYTuzGHbz6zGAFN3J0HMzuZr6pBOZOJ9igyng== X-Google-Smtp-Source: ACJfBouqnwIil4jDL/PZJxCUaGGxqHuRrZOC2TTvNUCcifRw/pQ5Q0oJfJw04Xg0KOl5t1aTHooRJwOxPa4HCXcLLso= X-Received: by 10.107.83.8 with SMTP id h8mr14536957iob.63.1513403392843; Fri, 15 Dec 2017 21:49:52 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 21:49:52 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> From: Warner Losh Date: Fri, 15 Dec 2017 22:49:52 -0700 X-Google-Sender-Auth: EgJZnzomqS2XESZr0K91hstB37c Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 05:49:54 -0000 On Fri, Dec 15, 2017 at 9:54 PM, Eric McCorkle wrote: > > > On 12/15/2017 22:28, Warner Losh wrote: > > > > > > On Fri, Dec 15, 2017 at 7:05 PM, Warner Losh > > wrote: > > > > > > > > On Dec 15, 2017 6:43 PM, "Eric McCorkle" > > wrote: > > > > On 12/15/2017 20:09, Warner Losh wrote: > > > > > This should be second. Uefi variables Trump all. > > > > > > 2) If not, then attempt to read EFI vars to determine the > boot location > > > > > > 3) If no EFI vars are defined, and no partition was > specified, fall back > > > to looking for an installed system on devices > > > > > > > > > This is fine, so long as it is only on the device that the > loader loaded > > > from. > > > > It's fine if it's configurable, but there needs to be sane > > behavior if > > the EFI vars aren't set. > > > > > > Where do we get this info for such a broken setup? Do you have > > actual examples? > > > > > 4) At the very last, do the legacy (what loader.efi > currently does) > > > behavior. > > > > > > > > > This is bogus. It violates the uefi boot loader protocol. We > must > > > abandon this legacy behavior. The behavior is actively harmful > since > > > something random will boot. This has caused actual operational > issues at > > > Netflix. Guessing is really bad. > > > > We can't just ditch the current behavior and break everyone's > > existing > > install, though. Legacy behavior should be supported at least > > until the > > next major release. > > > > > > What useful setups does this break? Absent a real example, we > > absolutely are breaking this. There is a real cost to doing this > > that as the de facto maintainer of stand I'm unwilling to maintain, > > test or commit to not breaking. The legacy behavior is broken and > > has caused me hours of pain in production. There has been no > > articulated use case this enables, especially since boot loader can > > be interrupted to specify something in recovery scenarios. > > > > > > > > > > Step (3) is done by attempting to stat /boot/loader.conf > and > > > /boot/kernel. First, all partitions on the same disk are > > searched, then > > > all remaining partitions are searched. > > > > > > This should allow mechanisms like EFI vars and > > command-line args to work > > > without interference from the fallback mechanisms. > > However, it also > > > provides robustness in the face of failure modes and > > uninitialized > > > systems (I personally ran into a problem a while back with > > a linux > > > system, where I couldn't boot with EFI, because the EFI > > vars weren't > > > set, because I couldn't set them if I couldn't boot with > > EFI; had to use > > > Shell.efi to sort out the mess...) > > > > > > More importantly, it provides a seamless transition from > > the way things > > > are now to the way we want things to be. > > > > > > Please provide comments and feedback. > > > > > > > > > Please listen when I say searching all devices is actively > > harmful. The > > > uefi boot manager, which I'm in the process of bringing in, > > offers a way > > > to specifically say what you want to boot. If someone needs > > something > > > complicated, they must use that moving forward. Part of what > > makes the > > > protocol work is loaders giving up early so the next one on > > the list can > > > be tried. > > > > We also have to deal with the reality that some EFI > > implementations are > > adversarial. We have to be able to deal with implementations > > that make > > it difficult to set EFI vars, or which mess with their values > > (Lenovo is > > particularly notorious for this). > > > > You can disable fallback mechanisms with command-line args or > > macros or > > whatever, but they need to be there. > > > > > > No. Absent a sane use case, I refuse. Give me a reasonable use case, > > I will reconsider. > > > > > > So the current behavior leads to absurd results that nobody else does, > > and that we don't do for legacy boot: > > > > If we boot loader.efi/boot1.efi off a hard drive, and find there's no > > kernel, we'll load off cdrom or a floppy if we happen to find a kernel > > there. That's nuts. What's more, we'll load off a different device (say > > a thumb drive), which is also crazy. The last thing you want is to > > accidentally pick the thumb drive recovery kernel that happens to be in > > a USB slot when you have a primary and secondary partition on two main > > disks, but today's behavior chooses that. It's so crazy that I can see > > no benefit from supporting, testing and maintaining this. If someone > > wants to recover a system, they can do it at the boot loader prompt now > > (they couldn't before). If someone really wants to boot his crazy thing, > > we have a new way to specify it specifically w/o any ambiguity based on > > how the devices might move around. > > > > We already support about 100 boot scenarios that are hard enough to > > test. I don't want to commit to supporting this and making it 120 or 150 > > once you work out all the combinatorics. We have to trim the matrix of > > useless things. So absent a use case that makes sense, that people are > > actually doing, I'm having a hard time justifying keeping it around as > > we transition. > > > > Warner > > > > P.S. On x86, we support geli/nogeli, gpt/mbr, ufs/zfs, and > > uefi/legacy/both (24 combinations). Plus we support booting off CDROM, > > netbooting, etc. For arm, and arm64 we have a similar number that are > > possible. zfs/ufs, u-boot/uefi, and mbr/gpt (plus a number of different > > u-boot boards). For mips we have a similar mix. Powerpc we support 4 or > > 6 ways. It's just too much to hope to test and ensure works. Each new > > thing has an non-trivial cost, and I see zero benefit from this one more > > thing, especially since it gets in the way of UEFI boot manager support. > > Whatever happens, this needs to not break existing installs. I don' tthink it will. We can > remove probing floppy drives, fine (does anyone even HAVE those > anymore?). The kernel is likely too big. But my point was more that if I boot loader.efi off a hard drive, the floppy isn't the place to find a kernel by default in the absence of very explicit instructions to do so. > CD-ROM drives, will break auto-detection when booting from a > liveDVD, but that can be mitigated by specifying loader args (I suppose > we'll need to have loader get args from the boot.config files > eventually). CD/DVD booing won't break. We'll still load a kernel from them. No boot.config needed for this case (though it might be for others). > But for now, loader.efi has got to work whether installed > in a boot1/loader (legacy) configuration, or installed directly to the > ESP. Otherwise, there's going to be a lot of unhappy people out there. > Correct. My proposed behavior will do just that, and if we get it wrong by default (a) you can be explicit with boot variables or (b) you can type something into the OK prompt, which you didn't have before. > As for the fallback search, it's just that: a fallback mechanism. Its > job is to make a sane guess as to where to find the system, but > ultimately it's not doing anything the user can't do themselves. And it > will only run if the EFI vars aren't set anyway, so it can't possibly > interfere with any of that. > And the fallback mechanism of typing what you want is wrong because? But it's job isn't to guess. If we don't know for sure what to boot, it's our job to fail so the next OS in the list gets a shot at booting. So, if we look at the sequence coming up, I'd like to propose the following: We look at BootCurrent. If this exists, we look at BootXXXX to see the current boot vars. This bootvar will have two things in it. It will have a path to what was boot (possibly with a path of what to boot next) and a command line. This command line is also passed to us by the BIOS. If the command line has a root filesystem specifier, use it for currdir. If there was a next thing to load (eg HD()/boot/kernel/kernel), then use HD() as currdir. Otherwise, if can find a ZFS pool (or there's more than one and one is specified as bootenv), use it as currdir. Otherwise, if we can find a UFS partition on the same drive as loader.efi came from that has /boot/loader.rc (or whatever the file is in lua loader), use that for currdir. If we still can't find currdir at this point, prompt for a currdir (timeout after 10s) -- we have no scipt loaded at this point to do prompting... We could add loading boot.config from the same ESP \efi\freebsd\boot.config at the beginning.... This is going to be tricky to code up as it is... This is basically what I'd written up things in two docs: https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit#heading=h.jdwnfj2sxlfb (UEFI boot protocol, lightly edited to include the above summary) https://docs.google.com/document/d/1l9tognVBx_QmWx6ZvilgEj2ndoIaMJhPPNllZZyHJj0/edit#heading=h.9ps7k4bunurf (ZFS UEFI media type to be able to specify things exactly if one wants) to try to get this all sorted out... Warner From owner-freebsd-arch@freebsd.org Sat Dec 16 15:31:37 2017 Return-Path: Delivered-To: freebsd-arch@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 5E25FE85BC0 for ; Sat, 16 Dec 2017 15:31:37 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3010668533; Sat, 16 Dec 2017 15:31:37 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 46C516352; Sat, 16 Dec 2017 15:31:36 +0000 (UTC) Subject: Re: loader.efi architecture for replacing boot1.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> From: Eric McCorkle Message-ID: <23c05735-4046-a41f-676c-877d9f07d5f8@metricspace.net> Date: Sat, 16 Dec 2017 10:31:35 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 15:31:37 -0000 On 12/16/2017 00:49, Warner Losh wrote: > CD/DVD booing won't break. We'll still load a kernel from them. No > boot.config needed for this case (though it might be for others). How is that possibly going to work for a liveDVD on a random system? People expect it to "just work" (meaning, it correctly guesses the kernel, then loads it). I can see it working with boot.config (which I'd be fine with), but if we don't search the CD drives, there's no way it can work. > But for now, loader.efi has got to work whether installed > in a boot1/loader (legacy) configuration, or installed directly to the > ESP.  Otherwise, there's going to be a lot of unhappy people out there. > > Correct. My proposed behavior will do just that, and if we get it wrong > by default (a) you can be explicit with boot variables or (b) you can > type something into the OK prompt, which you didn't have before. No, I'm talking about people with existing installations, which still have both boot1 and loader.efi. A change this big needs to be phased in over time, which means both modes of operation need to be supported for a while.   > As for the fallback search, it's just that: a fallback mechanism.  Its > job is to make a sane guess as to where to find the system, but > ultimately it's not doing anything the user can't do themselves.  And it > will only run if the EFI vars aren't set anyway, so it can't possibly > interfere with any of that. > > > And the fallback mechanism of typing what you want is wrong because? Because every single person out there with an install is going to suddenly have to type, and that's going to lead to a whole bunch of people saying we broke loader. > But it's job isn't to guess. If we don't know for sure what to boot, it's > our job to fail so the next OS in the list gets a shot at booting. That won't happen though. If loader fails to find an installed system, it drops out to a prompt, but it doesn't exit. Given that, it makes sense to make an effort at finding an installed system. From owner-freebsd-arch@freebsd.org Sat Dec 16 17:07:38 2017 Return-Path: Delivered-To: freebsd-arch@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 EFBA8E889CA for ; Sat, 16 Dec 2017 17:07:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 AF7B16B223 for ; Sat, 16 Dec 2017 17:07:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id m11so1435488iti.1 for ; Sat, 16 Dec 2017 09:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RuND/c8Maq1jdSunTWkoSOkEFibhxs8B872VDfNbP2Q=; b=EVPdHdVBTygVVM5fvXBzFJSbrMWzdKjtxu8WjFUpzyMcj6fcVfeA4R11sABI8toNo0 x1yfA0B6cBsd0gQe/rPuRYGMxIlwyTqSWStIdNp5uaB3iIEzKG+QHcxsdwksnuHeQ+km 3IFPDOvhO1FDPglhxHXUuz5Fw9rlqxbuaAMfYp6o6P4zfC6H3Y/5mfWcI8RXRT+FC4dt pHsfVZcU8dy6q/43fOfYNKpj6EOt8qlMtB+JJrr4h+qYrY4dQUWP4z8eHQQACRypcwnz jvylx9zG9kTyiLVdsleYLGvbO/L8AytqthcgjnB+zqVfgJTMR6AhGiTo+uay8PIN0SJJ 2ILQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RuND/c8Maq1jdSunTWkoSOkEFibhxs8B872VDfNbP2Q=; b=NfmANNOn67O0WKz6DJEV4qckDshf3IM7eV+c22Tgxu+Na6niLqN1WlPtsp0e0IVhtb yW8zeuu5id2p0ULa9ZhH4NhQMozVbPpSM+EybjgJGDIt0oUPTXpVhe1sls/reqv/lTnj uJazjQlfGAgjiOvpGFCc8QfMWjlcoKRb8g9NLKi3uJeGtThNgnNREjjOFZEnkywvP62e XE9Dl5VGP4WnqkCDsiY5rCWKyyrXSZfJQb4Hg7ANONTCemZW4BTv0Cyg0OMkqZhDUsyv wsE//JkBtLaMxHYotm8LFrGZeFTabwHvrCxlNamP2fUStbdhUnBG6ai75pvbTsFyv2ue xPlg== X-Gm-Message-State: AKGB3mKoxKLUgDtI2dFRbHkeGLNcoPupg+A9KOIf0ETKyI616EMKhuit hg6EiArhDog8WZgXjE4+BceygIF9gdvZ4XSGhKTryw== X-Google-Smtp-Source: ACJfBosN2GGBgDy+8yv3VIAyZhAMkh6y/UiugLECq+6kvl+SV8hLqRaNLISC3XEs35bSQ5O7RtARYUXbW5sJnx0snKk= X-Received: by 10.36.164.13 with SMTP id z13mr13950701ite.115.1513444057861; Sat, 16 Dec 2017 09:07:37 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 16 Dec 2017 09:07:37 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <23c05735-4046-a41f-676c-877d9f07d5f8@metricspace.net> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> <23c05735-4046-a41f-676c-877d9f07d5f8@metricspace.net> From: Warner Losh Date: Sat, 16 Dec 2017 10:07:37 -0700 X-Google-Sender-Auth: -s2kkTqO7tjpQWnW5QKLujhdZGU Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 17:07:39 -0000 On Sat, Dec 16, 2017 at 8:31 AM, Eric McCorkle wrote: > On 12/16/2017 00:49, Warner Losh wrote: > > > CD/DVD booing won't break. We'll still load a kernel from them. No > > boot.config needed for this case (though it might be for others). > > How is that possibly going to work for a liveDVD on a random system? > People expect it to "just work" (meaning, it correctly guesses the > kernel, then loads it). > > I can see it working with boot.config (which I'd be fine with), but if > we don't search the CD drives, there's no way it can work. And it will. It booted off the CD device, and will search the CD device (and only the CD device) for the kernel. It will find it there. How could that not work? > > > But for now, loader.efi has got to work whether installed > > in a boot1/loader (legacy) configuration, or installed directly to > the > > ESP. Otherwise, there's going to be a lot of unhappy people out > there. > > > > Correct. My proposed behavior will do just that, and if we get it wrong > > by default (a) you can be explicit with boot variables or (b) you can > > type something into the OK prompt, which you didn't have before. > > No, I'm talking about people with existing installations, which still > have both boot1 and loader.efi. A change this big needs to be phased in > over time, which means both modes of operation need to be supported for > a while. Unless they have a totally whacked out system, the proposed thing that I'm suggesting will just work for them. If they are booting with multiple disks where /boot/loader comes from a different disk than the boot disk, they will have to do something to configure it. The number of such people is likely zero given how fragile this setup is (it breaks when you plug in a thumb drive with a release on it, for example). > As for the fallback search, it's just that: a fallback mechanism. Its > > job is to make a sane guess as to where to find the system, but > > ultimately it's not doing anything the user can't do themselves. > And it > > will only run if the EFI vars aren't set anyway, so it can't possibly > > interfere with any of that. > > > > > > And the fallback mechanism of typing what you want is wrong because? > > Because every single person out there with an install is going to > suddenly have to type, and that's going to lead to a whole bunch of > people saying we broke loader. I maintain no such people will have to do that. The UEFI BIOS is required to set BootCurrent and BootXXXX. However, even in the absence of this, we'll look for a ZFS pool (and disks) or UFS partition on the same disk. This should generally work by default. > > But it's job isn't to guess. If we don't know for sure what to boot, it's > > our job to fail so the next OS in the list gets a shot at booting. > > That won't happen though. If loader fails to find an installed system, > it drops out to a prompt, but it doesn't exit. Given that, it makes > sense to make an effort at finding an installed system. > No. It doesn't. You're assuming that if we fail, the system won't boot. That's false. If we fail to boot device X, it's our job to fail so that if there's a Y or a Z it can be next. We have no knowledge of whether the user would prefer Y or Z as the next one to try, but the boot manager that runs inside every single UEFI firmware does and it will go to the next one. Y might be a recovery disk or copy of a freebsd memory stick release and Z might be a redundant copy of X to use in cases where X fails. Or vice versa. Do we want to boot to the installer? Not as a first choice, but maybe as a last resort. But we should let UEFI orchestrate the retries. Trying to second guess is fundamentally wrong, especially in UEFI where the boot order and boot recovery stuff is so extensively and particularly defined. Having fought the "oh, I'm going to guess" code in boot1.efi for over a year and after having it consistently pick the wrong thing to boot on some tiny fraction of the hundreds of systems I've had deployed give me strong empirical data that shows the guessing too hard bit is actually actively harmful. I've thought about this a lot. I've thought through all the supported scenarios. I've written up documents and solicited feedback. Nobody to date has said "oh no! I really want the random installed system roulette! I love it! Don't kill it." Warner