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 A47E61381F3 for ; Fri, 21 Dec 2012 08:24:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C21A421C0FF; Fri, 21 Dec 2012 08:23:59 +0000 (UTC) Received: from smtpq1.gn.mail.iss.as9143.net (smtpq1.gn.mail.iss.as9143.net [212.54.34.164]) by pigeon.gentoo.org (Postfix) with ESMTP id 3792A21C0D5 for ; Fri, 21 Dec 2012 08:23:28 +0000 (UTC) Received: from [212.54.34.136] (helo=smtp5.gn.mail.iss.as9143.net) by smtpq1.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Tlxt9-0007HS-8l for gentoo-dev@lists.gentoo.org; Fri, 21 Dec 2012 09:23:27 +0100 Received: from 54698b76.cm-12-2c.dynamic.ziggo.nl ([84.105.139.118] helo=data.antarean.org) by smtp5.gn.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Tlxt8-0002Vt-4h for gentoo-dev@lists.gentoo.org; Fri, 21 Dec 2012 09:23:27 +0100 Received: from eve.localnet (eve.adm.antarean.org [10.55.16.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPS id AC5E6124C for ; Fri, 21 Dec 2012 09:23:20 +0100 (CET) From: "J. Roeleveld" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: eudev project announcement Date: Fri, 21 Dec 2012 09:23:04 +0100 Message-ID: <22234620.jdiWnPB7po@eve> User-Agent: KMail/4.9.3 (Linux/3.3.8-gentoo; KDE/4.9.3; x86_64; ; ) In-Reply-To: References: <20121215203359.4552d807@pomiocik.lan> <50D2F4A5.9050505@gentoo.org> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Ziggo-spambar: / X-Ziggo-spamscore: 0.4 X-Ziggo-spamreport: RDNS_DYNAMIC=0.363,T_RP_MATCHES_RCVD=-0.01 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 56631819-6318-40cf-bb05-2d1bbd174d40 X-Archives-Hash: f70ed96fcfb0522c94dd6b9deb1da654 On Thursday, December 20, 2012 07:02:06 AM Rich Freeman wrote: > On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao wrote: > > No one has proposed moving everything to /usr. At the minimum, we would > > still have /etc and /var in /, as well as various mountpoints. If we do > > move those to /usr, then we effectively renamed / to /usr, which is > > pointless. The absurdity of mounting /usr over NFS instead of / is > > precisely why people are saying to just mount / (with /usr as being part > > of it). > > We're drifting here, but the concept is that machine-local stuff like > configuration stays out of /usr, and generic distro stuff stays in > /usr. > > A webserver for site1 vs site2 would be identical in /usr, but > different elsewhere. It would be identical everywhere but on: /etc/apache /var/www (using default locations) I would actually put /var/www on the share as well and use symlinks from /etc/apache to point to the specific vhost-config files. That way I could quickly move websites to a different node when I'd need to take one down for maintenance. Having only /usr shared betweehn those wouldn't be sufficient and would make patching and updates more risky as I would then be updating the whole environment at once. > However, that whole approach makes less sense for a distro that prides > itself on you being able to make every installation unique. That > said, if you do want to make a whole bunch of Gentoo installs the same > then sticking everything important in /usr and network mounting it is > a good way to accomplish it. How does portage handle a situation like this? Would I be able to use emerge on any node to add additional software along with all the config-file changes? If we take the webserver examples: The software is under /usr The configuration is under /etc/apache If I update apache and there are additional options and/or changes to the config files, how do I migrate those to all the different nodes? If the config is the same on all nodes, why not simply share the " / " ? If it differs, I then need to write down all the new options and go through every single node and update the config there. The same is true with any other environment where multiple nodes are used for the same purpose. For the usecases that I generally deal with, the only time where a shared /usr would make sense is when I select " Install everything " during the install. I used to do that to avoid having to deal with RPM-dependencies when I was using Redhat. -- Joost