From nobody Tue May 10 16:38:32 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E43661AC3E15 for ; Tue, 10 May 2022 16:38:42 +0000 (UTC) (envelope-from SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4KyNyn5S8vz4ZSm; Tue, 10 May 2022 16:38:41 +0000 (UTC) (envelope-from SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CFAFC28417; Tue, 10 May 2022 18:38:33 +0200 (CEST) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id BCA0B28411; Tue, 10 May 2022 18:38:32 +0200 (CEST) Subject: Re: Upgrade automation To: Alan Somers , Cristian Cardoso Cc: FreeBSD CURRENT References: From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Tue, 10 May 2022 18:38:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: cs Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KyNyn5S8vz4ZSm X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz" X-Spamd-Result: default: False [0.52 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.67)[-0.674]; NEURAL_SPAM_LONG(1.00)[0.998]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[78.45.215.131:received] X-ThisMailContainsUnwantedMimeParts: N On 10/05/2022 17:46, Alan Somers wrote: > On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso > wrote: >> >> Hi >> >> I have some FreeBSD servers in my machine park and I would like to perform the version upgrade in an automated way with ansible. >> >> In my example, I want to perform the upgrade from version 12.3 to 13, it is possible to run the upgrade with the command below: >> >> freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE >> >> I ask this, because I don't know if it's the most correct way to execute this. >> >> Grateful for any assistance. > > Yes, that's perfect. But there's another step too. You'll have to do: > freebsd-update install > And _this_ step isn't easy to perfectly automate, because etcupdate > may ask for your input when it merges config files. If you know > exactly which etc files you've modified, you can add them to > IgnorePaths. That way etcupdate won't run interactively, it will > simply throw away changes from upstream. Automation with etcupdate sounds very scary to me because etcupdate breaks real life configuration files inplace. Mergemaster did it on temporary copies. But if you let etcupdate to left something (after merge conflict) in vital config file(s) wich will have syntax error on next boot, then you are out. It would be much better if etcupdate do not edit target file on merge conflicts. Kind regards Miroslav Lachman