Configure Perl libnet Safely with libnetcfg

Perl's libnet modules read their defaults from one file, and libnetcfg builds it interactively so you never hand-edit Perl data structures. You will finish with a readable libnet.cfg candidate, plus a way to inspect the values before anything actually uses them. The examples match the libnetcfg installed with Perl 5.38.2-3.2ubuntu0.6 on this machine.

Allow about ten minutes. You need Perl and a writable working directory. The command normally runs as your own user. Do not use sudo for the working copy: it makes review and recovery harder, and the manual does not require elevated privileges.

1. Check the installed command

Start by confirming which executable will run and reading its built-in usage text:

$ command -v libnetcfg
/usr/bin/libnetcfg
$ libnetcfg -h
/usr/bin/libnetcfg: Usage: /usr/bin/libnetcfg [-c] [-d] [-i oldconfigile] [-o newconfigfile]

The spelling oldconfigile in this version's usage line is just the program's help text; use the option with a normal file path regardless.

Checkpoint: the command should resolve inside your intended Perl installation. If command -v finds nothing, fix the Perl package or PATH before creating a configuration.

2. Inspect the current configuration without changing it

Run libnetcfg with no arguments from a directory where you do not expect it to create a file:

$ mkdir -p /tmp/libnetcfg-check
$ cd /tmp/libnetcfg-check
$ libnetcfg
daytime_hosts
ftp_int_passive      0
inet_domain
nntp_hosts
ph_hosts
pop3_hosts
smtp_hosts
snpp_hosts
test_exist           1
test_hosts           1
time_hosts
# /usr/bin/libnetcfg -h for help

Without options, the utility just displays the current configuration. It first looks for the old configuration name, libnet.cfg, in the current directory, then on the Perl module path, and the output identifies where it found one. The exact list can vary between libnet releases, so treat the names your installed command prints as authoritative.

This is a read-only checkpoint. Confirm you recognise the host values and flags before changing anything. Host entries such as smtp_hosts and nntp_hosts are defaults for libnet modules, not proof that those services are reachable.

3. Generate a separate configuration candidate

Choose an output path explicitly so the command cannot silently replace a file in an unrelated working directory:

$ mkdir -p "$HOME/libnetcfg-review"
$ libnetcfg -c -o "$HOME/libnetcfg-review/libnet.cfg"

This starts the interactive configuration flow and writes the new file at the end. It asks about hostname lookups, service host lists, FTP firewall behaviour, passive FTP, your local internet domain and optional test settings. Answer only with values you have verified. If you have no host for a service, the prompt explains that a single space followed by Enter leaves that list empty.

Warning: hostname lookups are a real network side effect. Answer n when asked whether to perform them if you are offline, on a metered connection, or configuring a machine whose DNS queries must be controlled. The lookup only validates during configuration; it does not make a bad service choice safe.

When the prompts finish, check the exit status immediately:

$ printf '%s\n' "$?"
0
$ test -s "$HOME/libnetcfg-review/libnet.cfg" && echo 'configuration written'
configuration written

4. Reuse an old file deliberately

Use -i when the source file is not named libnet.cfg or sits outside the current directory, and -o for a separate destination:

$ libnetcfg -c \
    -i /path/to/known-good/libnet.cfg \
    -o "$HOME/libnetcfg-review/libnet.cfg"

The old file is input, the new file is output. Keep both paths different until you have reviewed the result. A missing -i file does not fall back to some hidden correct configuration: the utility falls back to its normal search rules and can start with empty values instead.

The -d option takes defaults from the old configuration and implies -c. In the installed version, that does not mean a fully unattended run: when the old file is absent or incomplete, the command still asks questions. Watch the prompts and capture the output path explicitly:

$ libnetcfg -d \
    -i /path/to/known-good/libnet.cfg \
    -o "$HOME/libnetcfg-review/libnet-from-defaults.cfg"

5. Review before making the file live

Inspect the generated file as Perl data, without executing a network client:

$ sed -n '1,160p' "$HOME/libnetcfg-review/libnet.cfg"
$ libnetcfg -i "$HOME/libnetcfg-review/libnet.cfg"

The second command should print the recognised settings and exit successfully. Check particularly for an unintended SMTP, POP3, NNTP or FTP host, an unexpected local domain, and whether passive FTP matches the network path. Empty host lists are valid, and safer than invented endpoints.

Do not treat the configuration file as a password store. The generated data holds connection defaults, not credentials. Still, keep it readable only by the users who need it if your environment treats hostnames or internal domains as sensitive:

$ chmod 600 "$HOME/libnetcfg-review/libnet.cfg"
$ stat -c '%A %n' "$HOME/libnetcfg-review/libnet.cfg"
-rw------- /home/you/libnetcfg-review/libnet.cfg

6. Recover from a bad candidate

If a review finds a wrong value, rerun the command with a new output filename, or remove only the unneeded candidate after confirming its path. Never overwrite a known-good file through shell redirection or by reusing -o blindly. If a generated file is already in service, restore the previous copy from your normal backup, then rerun the read-only inspection command.

If the command reports it cannot open an old file, verify the path and permissions without changing them:

$ ls -l /path/to/known-good/libnet.cfg
$ test -r /path/to/known-good/libnet.cfg && echo readable

A successful write only proves a file was created. It does not prove that DNS, SMTP, FTP or another remote service will accept connections. Test those services separately, with the relevant libnet module and a test account, once the configuration has passed review.

Done means