From owner-svn-src-head@FreeBSD.ORG Wed May 5 08:10:27 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90C1D1065673; Wed, 5 May 2010 08:10:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 03B488FC1B; Wed, 5 May 2010 08:10:26 +0000 (UTC) Received: from outgoing.leidinger.net (pD954F941.dip.t-dialin.net [217.84.249.65]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 8911784446F; Wed, 5 May 2010 10:10:20 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5448B5120; Wed, 5 May 2010 10:10:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1273047015; bh=4BlLt4+Wa4lohxSnZ9oT58xvjFwXVkIor0JR4vki744=; h=Message-ID:Date:From:To:Cc:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=eu+8xiCbUJTWmpgfw6nVEtLsovcg2GmS8sUtVKMYvDgh54B0la5XbvZLvktLoDY04 CiwT+W8lcQmlqrLAoroE/wpLXcFZoUKMVlVkxtXGtYMEDqKHqi00RecuEJUmbTLqTa zbZ4dYIikbMnyWN/m0EaOJdMIs2On3ExSFg41AOIqTtWivkts+Ag2e6l6dMhbqrfqs iBdtjxFY0usxfGJdOf2UrrBz21IS+TOglFidh6Y6GWimY93niurMtLiYfMk23W1vZf bZkk8Z7bXJ0LX/zRB0b2eJnBOIqAn1p26jAdqPKyAv25JSSMtYf3ujIt+vWvkjPEG8 sPnP/W2dyzpzg== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o458AFEO080875; Wed, 5 May 2010 10:10:15 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 05 May 2010 10:10:14 +0200 Message-ID: <20100505101014.21013q8knucsqo00@webmail.leidinger.net> Date: Wed, 05 May 2010 10:10:14 +0200 From: Alexander Leidinger To: Doug Barton MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 8911784446F.22E31 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.363, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, TW_SV 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1273651822.38624@uUlS5k7NgpPRowQdKr3F6A X-EBL-Spam-Status: No Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Norikatsu Shigemura Subject: Re: svn commit: r207612 - head/usr.sbin/mergemaster X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 08:10:27 -0000 Quoting Doug Barton (from Tue, 04 May 2010 09:00:33 -0700): > On 5/4/2010 7:02 AM, Alexander Leidinger wrote: >> Quoting Norikatsu Shigemura (from Tue, 4 May 2010 >> 11:25:04 +0000 (UTC)): >> >>> Author: nork >>> Date: Tue May 4 11:25:04 2010 >>> New Revision: 207612 >>> URL: http://svn.freebsd.org/changeset/base/207612 >>> >>> Log: >>> Add support run services_mkdb(8). >> >> Shouldn't this (and similar messages) only be done if there is a >> corresponding DB file? > > This is the first case where the db file is "optional." All the others No, the DB for login.conf is optional too. The man page of login.conf is wrong. The cgetent(3) man-page explicitely tells that it first looks in the DB file, but falls back to the ASCII file if the DB file is not available. > have been created by default for ages now, and nork was simply copying > the existing code (including the "make sure" bit). I was assuming that it is just a copy of what exists. > As he pointed out, I asked him to make the prompt unconditional since > the db file is small, and harmless if not being used. Making it > conditional now is a pointless micro-optimization that will have to be > removed down the road when having/needing it becomes the default. Is there some movement to make it not optional? I do not think it is a micro-optimization. I do not talk about some performance impact (be it work which has to do be done by a person or by a CPU), it is about system knowledge. The DB is optional, if you ask someone without enough knowledge (and there are a lot of such people which do sysadministration stuff) to do this, he will not understand what this implies (that he has to run such a command every time /etc/services is changed). The DB file is only harmless if it is in sync with the ASCII file. If they are not in sync, the DB file is harmful to people which do not know about this feature. As an example of what I talk about: my client is a part of the european comission. This means we talk about a some kind of government entity (what follows can be told about big corporations too). They outsource the work for some specific time, and after that they make a new call for tender for this position. Most of the time the cheapest offer wins (decission of the bean counters, not by people which know what it means technically). I was there in the previous contract and in the current contract. In the previous contract we all where highly skilled. Now with a new manager (who has himself some sysadmin knowledge) everything changed. Junior admins are taking care about all sysadmin stuff, and the few seniors which are left are some kind of firefighters and do some kind of special investigations work. Now, if a junior admin sees some kind of procedure, he follows it. He does not see strange things, he does not know the implications of a lot of stuff, and not all ask questions of what it means for the system if he runs a command he does not know about. That's bad, but this is life. They do what they get told to do to earn money. To make my life a little bit more easy, I wrote a script which checks a system (Solaris) for the correct setup. It checks a lot of things, simple things (hostname, domainname, TZ, ...) and complex things (multipathing, ZFS/VxVM stuff, Zones, SMF, ...), generic stuff and the site specific configs. There I do not say only OK or ERROR, I also give infos. The infos are not only like 'do this', but also sometimes also 'ask someone with knowledge about this'. What I try to do there is to be as precise as possible (if there are conditions, I check the conditions if possible, or to tell as good as possible how to check conditions, which the script can not check itself), because I've already seen what people make out of not so detailed explanations. To come back to FreeBSD: a port may tell to modify /etc/services, but it may not tell to recreate the optional DB file (or the user may decide to not act because of the 'optional' and because he does not know what this is). The ports we can fix, but if someone is using some 3rd party application which is not in ports, and this application tells to modify /etc/services, then it is not within our control to fix the problem which may be caused by a stale DB file which the person installing the application does not know about. I hope this makes it more clear what kind of problem I see with the DB files for login.conf and the services file. Bye, Alexander. -- My brain is my second favorite organ. -- Woody Allen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137