From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2399 Path: news.gmane.org!.POSTED!not-for-mail From: Steve Litt Newsgroups: gmane.comp.sysutils.supervision.general Subject: Noclobber supervisor/init installation Date: Sat, 27 Oct 2018 15:11:57 -0400 Message-ID: <20181027151157.03f14173@mydesk.domain.cxm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1540667396 1665 195.159.176.226 (27 Oct 2018 19:09:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2018 19:09:56 +0000 (UTC) Cc: Joel Roth To: supervision@list.skarnet.org Original-X-From: supervision-return-1990-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Oct 27 21:09:52 2018 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gGTy3-0000Im-M9 for gcsg-supervision@m.gmane.org; Sat, 27 Oct 2018 21:09:51 +0200 Original-Received: (qmail 21408 invoked by uid 89); 27 Oct 2018 19:12:26 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21401 invoked from network); 27 Oct 2018 19:12:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; h=X-Originating-IP:Date:From:To:Cc:Subject:Message-ID:X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding; s=default; d=troubleshooters.com; b=XsbmfXKb9QfN/ajyBRe7mfDpMTWiSBn9OjXABi2YQ68jIT3o4vbdx2l35P4xc0Ih1Hb8JgUTQ/95r/laNUg92Tuqh70e7u2eytcsnBwSx0Zra8uaWHy/I73bo+SIQxODrMr1KU/JFMKt6kfRDgGHo6fo1Jqh/waEXVh2I3746As=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1540667518; bh=/Nfast9n/jfNiwBg/Bl8goLwZJ4=; l=5392; h=X-Originating-IP:Date:From:To:Cc:Subject:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; b=N77V4fT/sZONXrTaN79qUW5Ai/OjlbD2uKXjqD6EU3/Q77JK6wd6Qp8GDJUNfAXPX HozngRCPjR+bl6BMtdzxflGJxNB2X1B4a+A1wd++25B6UmzlWjWJfWWPa4zvLB0+bt oGHjmSeOVGJ2c9Vp/3mRZR0z2eCBV7hqJoPzbhXw= X-Originating-IP: [72.188.224.222] X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2399 Archived-At: Hi all, I'm leading the way in making runit an easy and practical choice on the Devuan distribution. For DIY types like we on this list, the supervisor portion of runit, as installed by the Debian runit package, already works perfectly. My task is to make the whole thing compatible with a packaging system. Even as we speak, I'm beginning to curate runit start scripts for close to 100 daemons. Eventially this whole collection of run scripts, finish scripts, log directories, and auxiliary files and directories will be available in a single Devuan package, along with simple programs to make daemon directory installation, within runit, trivial. For Devuan and Devuan alone, I'm putting both the directory containing all available daemon directories and the directory containing symlinks (/service in original djb daemontools) below /etc. I have asked twice on the mailing list, and been given assertions twice, that nobody is planning on using a read-only /etc, so for the purpose of Devuan I'll make it below /etc, but I'll be sure to make it a variable. Please let's not discuss the readonly /etc factor in this thread. It's hugely important to me that all supervisors and inits be installable and runnable without in any way clobbering each other. If somebody plans to init with s6/s6-rc, and within it instantiate a runit, which itself instantiates a daemontools, I want that to work perfectly. Likewise, if someone wants several inits the way we all have several kernels in case one starts to act funny, I want that possible. So I've created the following terminology: du: Daemons used. Refers to the symlink directory or its subdirectories. /service in the original daemontools is an example of a du directory. /etc/sv in both Void Linux and Debian and Devuan is an example. In Devuan I'd make this directory /etc/du/runit. There could later be an /etc/du/s6 or /etc/du/daemontools. da: Daemons available. Refers to the directory housing the real-file directories that are symlinked in the du directory. Material in the da galaxie is site-modifiable to accommodate site specific needs. In Devuan I'd make this directory /etc/da/runit. There could later be an /etc/da/s6 or /etc/da/daemontools. dp: Daemons packaged. Refers to a directory housing unmodified material straight from the runit_daemons package. The dp directory shall consist of a directory holding daemon directories for every daemon in the collection. The daemon directories shall not contain any supervise file, directory or symlink, nor any log files or directories meant to hold log files, nor any other stateful things. The intent of the dp directory is that its material is modified ONLY by later packages, never on-site. It's therefore entirely read-only. In Devuan I'd make this directory /etc/dp/runit. There could later be an /etc/dp/s6 or /etc/dp/daemontools. As far as I can tell, the preceding vocabulary and directory system could enable all daemontools-inspired supervisor/init systems to be installed on the hard disk, at the same time, without in any way interfering with each other, always assuming their PD1 executables have different names. To me it's vitally important that people understand that the daemontools-inspired supervisors are close cousins, each with its subtle advantages and disadvantages, so I want to make sure that nothing I do with runit in any way sabotages future installation or use, even simultaneous supervision use, of its cousins. The runit_collection package will come with the following: * The dp directory populated with all distro-default daemon dirs * Ability to create $da_dir, $du_dir, and $dp_dir on installation. * The runit_tool tool. runit_tool -i daemonname sees whether the dp version of the daemon dir matches the da version, and if so, does nothing. If different or da version is missing, it first backs up the existing dp version then overwrites it. If the now backed-up dp version matches the da version, the da version is assumed not to be custom, and the new dp version overwrites the da version. If the backed-up dp and the da differ, it assumes the da version is customized, and via backups and warnings, walks the user through his/her choices. runit_tool -e daemonname creates a symlink of the da in du. If nothing to symlink to, issues a warning. runit_tool -d packagename removes that symlink. If no symlink, issues a warning. runit_tool -u daemonname issues a warning and refuses to act if there's currently a du->da symlink. If the da version of the daemon doesn't match the dp version, issues a warning about it being customized, and makes the user strenuously opt in to deleting the daemon directory from da. Does not affect dp at all. I specifically don't want to give runit_tool any more powers because I want people to get used to the runit provided commands, and not depend on some supertool that I write. Given what I've written, does the $da_dir, $du_dir and $dp_dir vocabulary sound reasonable? I'd like to thank Joel Roth (copied) for first giving me the idea of separated directories. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz