svn commit: r207612 - head/usr.sbin/mergemaster

[Alexander Leidinger]

Quoting Doug Barton <dougb at FreeBSD.org> (from Tue, 04 May 2010  
09:00:33 -0700):

> On 5/4/2010 7:02 AM, Alexander Leidinger wrote:
>> Quoting Norikatsu Shigemura <nork at FreeBSD.org> (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