OpenVPN removed but /etc/openvpn remains: remove vs purge

The directory is still there, the service is gone, and it is not obvious whether the package is installed. On Debian-family systems a leftover /etc/openvpn usually means the package was removed without being purged, which is a documented state and not a broken one. The files you see are probably configuration, not a program.

Work in runbook order: read the package state, decide what to keep, purge deliberately, then verify what remains. Each step is reversible up to the purge.

Read the package state first

Start with the package database rather than the filesystem. dpkg -l openvpn prints a two-letter state, and rc means the package was removed while its configuration files were kept. dpkg-query -W -f='${Status}\n' openvpn gives the same answer in words. A directory listing cannot tell you any of that.

Do not confuse Community OpenVPN with Access Server or a NetworkManager plugin. They are different packages with different removal paths.

If the state is ii, the package is installed and the directory is expected. If it is rc, only configuration remains. If the query returns nothing, the package was purged and the directory belongs to something else.

Choose between remove and purge

remove deletes the programs and leaves configuration. purge deletes the configuration as well and runs the package's cleanup script. Both are administrative decisions about state, not different spellings of the same command.

Before choosing, list what the package owns with dpkg -L openvpn. That output is the map of package-managed paths, and it is the right input for a decision about what a purge would delete. Anything you see in the directory that is not on that list came from somewhere else. Treat those files as yours to review, not as package residue.

Purging an already-removed package is allowed. Reinstalling first is not a requirement.

Preserve what you still need

Preserve what you still need before the purge: profiles, client certificates, private keys, CCD files and any local scripts. Copy them with permissions appropriate to secrets, and record where the copies live.

Check whether another service or manager uses the same directory. A second VPN instance or an automation script can depend on a path that looks like leftover configuration.

If the machine is being decommissioned, the local files are the smaller half of the problem. Exported profiles and remote authorizations outlive any directory you delete.

Purge and verify

Run the purge through the package manager, not by deleting the directory. sudo apt purge openvpn keeps the package database and the cleanup scripts in the loop.

Afterwards, repeat the state query and confirm the package no longer appears. Check that the service is gone with systemctl status openvpn@server or the unit name you used, and test ordinary networking.

Files a purge will not remove

Some files survive a purge by design. Generated configuration handled by maintainer scripts is not always known to dpkg's file database. Configuration in users' home directories is outside the system-directory cleanup. And anything an administrator created by hand was never owned by the package. Each of those needs its own review.

A recursive delete of every path with VPN in the name is how working credentials and unrelated configuration disappear.

Finish by revoking what the machine no longer needs: exported profiles, issued client certificates and any account that authenticated through it. Removing a local directory does not revoke a credential that still exists elsewhere. The dpkg reference documents the states and the purge scope.