Page MenuHomeFreeBSD

Add src.conf knob to disable the installation of /var/db/services.db
ClosedPublic

Authored by sbruno on Feb 17 2017, 8:11 PM.

Details

Summary

Allow make distribution to skip /var/db/services.db

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

sbruno updated this revision to Diff 25328.Feb 17 2017, 8:11 PM
sbruno retitled this revision from to Add src.conf knob to disable the installation of /var/db/services.db.
sbruno updated this object.
sbruno edited the test plan for this revision. (Show Details)
sbruno added a reviewer: ngie.
emaste added a subscriber: adrian.Feb 17 2017, 8:29 PM

I strongly support the ability to make small root filesystems, but I'm a bit worried about ending up with dozens of fiddly WITHOUT_ knobs (even though I'm guilty of adding a few myself).

A couple of questions:

  • are there other generated files (.db or otherwise) that we can do without, where the system falls back to a plain-text source file like in this case?
  • why is services.db 2M in the first place? as @adrian mentioned on IRC maybe there's some bdb tuning knob that could be set to have a more reasonable size?
  • could we perhaps have one high-level knob to select between a fast and small FreeBSD world and put this and other things into it?

But why? Why install master.passwd and not services.db?

But why? Why install master.passwd and not services.db?

master.passwd is ~1700 bytes on a fresh install and services.db is ~2MB.

I strongly support the ability to make small root filesystems, but I'm a bit worried about ending up with dozens of fiddly WITHOUT_ knobs (even though I'm guilty of adding a few myself).
A couple of questions:

  • are there other generated files (.db or otherwise) that we can do without, where the system falls back to a plain-text source file like in this case?
  • why is services.db 2M in the first place? as @adrian mentioned on IRC maybe there's some bdb tuning knob that could be set to have a more reasonable size?
  • could we perhaps have one high-level knob to select between a fast and small FreeBSD world and put this and other things into it?

I'm open to suggestions here. services_mkdb doesn't appear to have any options like that according to its man page.

pwd_mkdb defines its HASINFO:

static HASHINFO openinfo = {
        4096,           /* bsize */
        32,             /* ffactor */
        256,            /* nelem */
        2048 * 1024,    /* cachesize */
        NULL,           /* hash() */
        BYTE_ORDER      /* lorder */
};

vs services_mkdb:

HASHINFO hinfo = {
        .bsize = 256,
        .ffactor = 4,
        .nelem = 32768,
        .cachesize = 1024,
        .hash = NULL,
        .lorder = 0
};

But why? Why install master.passwd and not services.db?

master.passwd is ~1700 bytes on a fresh install and services.db is ~2MB.

How will you run a system without services.db? I'm missing some context here.

But why? Why install master.passwd and not services.db?

master.passwd is ~1700 bytes on a fresh install and services.db is ~2MB.

How will you run a system without services.db? I'm missing some context here.

My understanding is that services.db is preferred, but the system can still parse /etc/services.

ngie edited edge metadata.Feb 17 2017, 11:59 PM

Let me dig back through my mail archives a bit... the last time I asked this question (I think 1-2 years ago), it seemed like services.db wasn't in use, or wasn't absolutely required (IIRC services.db is an optimization as /etc/services is a flat text file and there was concern around lookup times).

ngie added a comment.Feb 18 2017, 12:54 AM
In D9655#199663, @ngie wrote:

Let me dig back through my mail archives a bit... the last time I asked this question (I think 1-2 years ago), it seemed like services.db wasn't in use, or wasn't absolutely required (IIRC services.db is an optimization as /etc/services is a flat text file and there was concern around lookup times).

Ah... my case was /var/db/termcap.db, not services.db.

Should the code in libc be conditionally disabled if we go down the path of not installing /var/db/services.db?

lib/libc/net/getservent.c: st->db = dbopen(_PATH_SERVICES_DB, O_RDONLY, 0, DB_HASH, NULL);

Sidenote (because I know kind of which path you're trying to follow with this work), have you looked at using either .bz2 or .gz compressed mfsroot's?

ngie edited edge metadata.Feb 18 2017, 12:55 AM
ngie added a subscriber: manpages.
ngie added inline comments.
tools/build/options/WITHOUT_SERVICESDB
2 ↗(On Diff #25328)

This markup looks incorrect. It should probably be .Pa /var/db/services.db . -- I'd check with manpages though...

In D9655#199665, @ngie wrote:
In D9655#199663, @ngie wrote:

Let me dig back through my mail archives a bit... the last time I asked this question (I think 1-2 years ago), it seemed like services.db wasn't in use, or wasn't absolutely required (IIRC services.db is an optimization as /etc/services is a flat text file and there was concern around lookup times).

Ah... my case was /var/db/termcap.db, not services.db.
Should the code in libc be conditionally disabled if we go down the path of not installing /var/db/services.db?
lib/libc/net/getservent.c: st->db = dbopen(_PATH_SERVICES_DB, O_RDONLY, 0, DB_HASH, NULL);
Sidenote (because I know kind of which path you're trying to follow with this work), have you looked at using either .bz2 or .gz compressed mfsroot's?

Maybe. I think "my problem" is that the current version of this file is ~2M on today's head. I'm unsure why it would be *that* big for it.

ngie added a comment.Mar 1 2017, 3:43 AM
In D9655#199665, @ngie wrote:
In D9655#199663, @ngie wrote:

Let me dig back through my mail archives a bit... the last time I asked this question (I think 1-2 years ago), it seemed like services.db wasn't in use, or wasn't absolutely required (IIRC services.db is an optimization as /etc/services is a flat text file and there was concern around lookup times).

Ah... my case was /var/db/termcap.db, not services.db.
Should the code in libc be conditionally disabled if we go down the path of not installing /var/db/services.db?
lib/libc/net/getservent.c: st->db = dbopen(_PATH_SERVICES_DB, O_RDONLY, 0, DB_HASH, NULL);
Sidenote (because I know kind of which path you're trying to follow with this work), have you looked at using either .bz2 or .gz compressed mfsroot's?

Maybe. I think "my problem" is that the current version of this file is ~2M on today's head. I'm unsure why it would be *that* big for it.

Coming back to this PR, I think that this could be made more general.. in particular, there are other databases which could be compiled out:

$ du -sh `sudo find /etc /var/ -name \*.db`
 40K    /etc/spwd.db
128K    /etc/mail/aliases.db
 40K    /etc/pwd.db
 16K    /etc/login.conf.db
2.1M    /var/db/services.db

I think that there should be a global knob for removing all of these databases.

emaste added a comment.Mar 1 2017, 2:21 PM

I think that there should be a global knob for removing all of these databases.

services.db has the beneficial property that it's just an optimization, and there's no functional impact from omitting it. Is this the case for the other databases?

Regardless of whether or not we add the knob, I think we should address the issue of it being 2MB.

ngie removed a reviewer: ngie.Mar 8 2017, 6:40 AM
ngie added a subscriber: ngie.

Resigning as reviewer because I do not plan on working on build system items unrelated to testing.

sbruno updated this revision to Diff 43666.Jun 12 2018, 7:43 PM

After building the src.conf man page, update the WITHOUT_SERVICESDB entry to
generate something that looks more sensible.

sbruno accepted this revision.Jun 19 2018, 9:09 PM

Heh, I can accept my own revision. :-)

Any further objections?

This revision is now accepted and ready to land.Jun 19 2018, 9:09 PM
bdrewery accepted this revision.Jun 19 2018, 9:34 PM

Hm this isn't even used by default since nsswitch.conf has 'compat' rather than 'db'. It defaults to 'files' behind the scenes and uses /etc/services.

This revision was automatically updated to reflect the committed changes.