From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5CF071381F3 for ; Sat, 22 Jun 2013 07:00:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7917EE0AF4; Sat, 22 Jun 2013 07:00:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 71728E0AB6 for ; Sat, 22 Jun 2013 07:00:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A412433E663 for ; Sat, 22 Jun 2013 07:00:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5.5 tests=[AWL=-0.514, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.522, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8C7hqKBYw21 for ; Sat, 22 Jun 2013 07:00:09 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 9B09033E643 for ; Sat, 22 Jun 2013 07:00:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UqHno-0007E7-Js for gentoo-dev@gentoo.org; Sat, 22 Jun 2013 09:00:04 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Jun 2013 09:00:04 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Jun 2013 09:00:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: eselect init Date: Sat, 22 Jun 2013 06:59:47 +0000 (UTC) Message-ID: References: <51A08A68.3020900@gentoo.org> <20130620205609.GB23719@linux1> <20130621043959.7eae0921@gentoo.org> <51C42B33.9090709@gentoo.org> <1371814006.2486.10.camel@localhost> <51C43DEA.6000006@gentoo.org> <20130621143657.GA26044@linux1> <1371829739.2486.20.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 459f52e /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: bc010ed1-d46f-477a-924b-9943d58ba673 X-Archives-Hash: ee0a8a3058976051f99093d9cd97451d Pacho Ramos posted on Fri, 21 Jun 2013 17:48:59 +0200 as excerpted: > El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió: > [...] >> No, he has his own versions of the systemd and sysvinit ebuilds which >> move some of the installation to non-standard places as part of this >> machinery, so it is not opt-in. >> >> Also, there was an email on this thread showing that using >> init=/sbin/einit works, so I'm not seeing what mgorny's objections are. >> >> William > > I think mgorny was referring to a case where einit fails to work and, > then, kernel will fallback to using /sbin/init, that could cause > problems as it would always run /sbin/init from sysvinit... but maybe he > was referring to something else :| This is my understanding as well. If there's a problem with /sbin/einit, the kernel will fallback to /sbin/init. If /sbin/init runs a sysv init that's setup for an old, no longer sysadmin maintained openrc (or whatever other) setup, there's little telling what sort of unpredictable things that openrc config from three years ago might end up doing to a painstakingly configured systemd (or runit, or...) current config. That's the worry, and as an admin, I'd be worried about it myself, but in practice, I'm not sure it's particularly valid, simply because in the real world, the failures are more likely to be full service breakage, etc, than they are to be anything really destructive. The caveat, and this one's big enough to give an admin ulcers for sure, is if the machine is a server, and that old no-longer-maintained openrc config starts up say a no-longer-maintained sshd instance with a poor password that has long since been forgotten about, thus exposing the machine to any cracker taking a probe. However unlikely that is (such an unmaintained sshd config should have long since been removed on any responsibly administered gentoo system), just the possibility is enough to give a responsible admin ulcers worrying about it, because even responsible sysadmins fat-finger things, or simply forget about them, once in awhile. THAT's our REAL weakness, and we know it all too well! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman