Safely Read and Edit /etc/netconfig for TI-RPC

One wrong edit to /etc/netconfig and every RPC client on the box can start picking the wrong transport. This walks you through reading the TI-RPC transport database at /etc/netconfig, understanding which transports the RPC library prefers, and making a narrowly scoped edit only when you have a real reason to. On this machine the file belongs to libtirpc-common version 1.3.4+ds-1.1build1, and the installed netconfig(5) manual describes the same seven-field format.

Time: about fifteen minutes.
You need: a shell and read access to the file. Inspection is unprivileged.
Editing needs: elevated privileges, and it can change how applications using TI-RPC select a transport.
Not this: a firewall, DNS or socket-listening configuration. Changing it does not restart a service by itself.

1. Confirm the file and package

Start with read-only checks. They establish which file you are looking at and whether the installed package owns it:

$ command -v dpkg-query
/usr/bin/dpkg-query
$ dpkg-query -S /etc/netconfig
libtirpc-common: /etc/netconfig
$ dpkg-query -W -f='${Package} ${Version}\n' libtirpc-common
libtirpc-common 1.3.4+ds-1.1build1
$ sed -n '1,40p' /etc/netconfig

Your version may differ. The final command prints comments followed by transport entries. Do not edit the file just because its order differs from an example on another host.

Checkpoint: If /etc/netconfig is absent, stop and investigate the package installation rather than creating a replacement from memory.

2. Read one entry as seven fields

The manual defines entries as network_id semantics flags family protoname device libraries. The last two fields are represented by - in this libtirpc implementation. Display the non-comment lines with numbered fields:

$ awk 'NF && $1 !~ /^#/ { printf "id=%s semantics=%s flags=%s family=%s protocol=%s device=%s libraries=%s\n", $1, $2, $3, $4, $5, $6, $7 }' /etc/netconfig
id=udp semantics=tpi_clts flags=v family=inet protocol=udp device=- libraries=-
id=tcp semantics=tpi_cots_ord flags=v family=inet protocol=tcp device=- libraries=-
id=udp6 semantics=tpi_clts flags=v family=inet6 protocol=udp device=- libraries=-
id=tcp6 semantics=tpi_cots_ord flags=v family=inet6 protocol=tcp device=- libraries=-
id=rawip semantics=tpi_raw flags=- family=inet protocol=- device=- libraries=-
id=local semantics=tpi_cots_ord flags=- family=loopback protocol=- device=- libraries=-
id=unix semantics=tpi_cots_ord flags=- family=loopback protocol=- device=- libraries=-

tpi_clts means connectionless.
tpi_cots_ord means connection-oriented and ordered.
The v flag makes an entry visible to the getnetconfig(3) lookup API; - leaves that flag unset.
Documented families here are inet, inet6 and loopback.
Protocol names are normally udp, tcp or -.

This field split is a check, not a repair tool. If a line has fewer than seven fields, or a value is outside the documented set, do not guess what it means. Preserve the original and compare the line with the package's expected format.

3. Understand order before changing it

Entry order is significant when the RPC library is asked for a network type that matches more than one transport. In the installed file, IPv4 entries appear before IPv6 entries, so udp is listed before udp6. The manual's example demonstrates the reverse preference for a file that puts udp6 first. A reorder can therefore alter connection selection for RPC callers without changing the protocol definitions themselves.

There is no general command that proves every application will use one particular line. Check the consumer's documentation and test that application in its own maintenance window. A missing rpcinfo command, for example, is an absent diagnostic utility, not proof that /etc/netconfig is unused.

Checkpoint: Write down the exact transport ID you intend to affect and why its position or visibility must change. If you cannot name the consumer, leave the file alone.

4. Make a reversible backup before editing

Editing this file is the first state-changing step. The following commands use sudo only for the copy and editor; do not run them until you have identified the exact target:

$ sudo cp --preserve=mode,ownership,timestamps /etc/netconfig /etc/netconfig.bak
$ sudoedit /etc/netconfig

In the editor, make one documented change. Keep the seven columns separated by whitespace, retain the comments, and do not replace - in the device or libraries columns with a guessed path. The file's current libtirpc implementation treats those fields as empty.

Warning: Do not use a shell redirect such as sudo sh -c '... > /etc/netconfig' for an unreviewed generated file. It can truncate the working configuration before you notice a syntax mistake.

5. Check the edited file before relying on it

Run the same field inspection after saving, then compare the backup and current file:

$ awk 'NF && $1 !~ /^#/ { if (NF != 7) { print "bad field count on line " NR; bad=1 } } END { exit bad }' /etc/netconfig
$ diff -u /etc/netconfig.bak /etc/netconfig
--- /etc/netconfig.bak
+++ /etc/netconfig
@@
 ...your reviewed change...

The first command prints nothing and exits successfully when every non-comment entry has seven fields. The second should show only the change you intended. A patch header containing an unexpected line is a reason to stop, restore the backup, and investigate.

To undo this example, restore the backup and retain its ownership and mode:

$ sudo cp --preserve=mode,ownership,timestamps /etc/netconfig.bak /etc/netconfig
$ diff -u /etc/netconfig.bak /etc/netconfig

Restoring the file does not undo an application that already cached transport information. Restart or reload that application only according to its own documentation, and treat that as a separate service change.

Done means

Confirmed the installed libtirpc-common version and the package-owned path.
Can identify all seven fields in each non-comment entry.
Understand that v controls visibility and that entry order influences RPC transport preference.
Made any edit with elevated privileges, reviewed it with diff, and backed up first.
Can restore /etc/netconfig.bak without guessing, and know application reloads are separate.