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.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 15, 5:08 AM
Unknown Object (File)
Feb 24 2024, 2:57 AM
Unknown Object (File)
Feb 23 2024, 2:06 PM
Unknown Object (File)
Feb 23 2024, 2:05 PM
Unknown Object (File)
Feb 23 2024, 2:05 PM
Unknown Object (File)
Feb 23 2024, 1:24 PM
Unknown Object (File)
Feb 23 2024, 1:11 PM
Unknown Object (File)
Feb 4 2024, 10:14 PM

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 7542
Build 7696: arc lint + arc unit

Event Timeline

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.

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.

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).

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 added a subscriber: manpages.
ngie added inline comments.
tools/build/options/WITHOUT_SERVICESDB
2

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.

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.

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 added a subscriber: ngie.

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

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

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

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.