Page MenuHomeVyOS Platform

Revamp the directory structure
Closed, ResolvedPublic

Description

If we are rewriting and moving things to vyos-1x already, perhaps it's time to rethink the directory structure until it's too late.
Originally we left it as is because the effect of the changes on existing code is quite unpredictable, but for new code it's not an issue.

The original directory structure of Vyatta doesn't make much sense. Why keep things in /opt if nothing there is installable or removable without breaking the system? Things inside /opt are not pretty either.

We have /opt/vyatta/sbin that is used mostly but not exclusively for config scripts. However, the binaries of the CLI (my_set etc.) are also there. But not all of them, cli-shell-api is in /bin
We have /opt/vyatta/bin which is mostly used for op mode scripts, but some of op mode if in fact in sbin/ (such as installation scripts). There's also sudo-users dir inside bin/, but it doesn't mean none of the files in bin/ requires root priviliges.

Of course the transition will be gradual, and having two parallel directory structures can be aesthetically annoying, but I believe in the long run we'll have to it anyway. Let's make it more logical and FHS-compliant. Now that we have only a few scripts in vyos-1x, it's still easy to start doing it for the new code.

Here's my proposal:

  • /usr/libexec/vyos/conf-mode — config scripts
  • /usr/libexec/vyos/op-mode — op mode scripts
  • /usr/libexec/vyos/validators — value validators
  • /usr/libexec/vyos/ — miscelanneous helper programs

Since none of the old scripts use ${vyos_libexec_dir} for obvious reasons, it's safe to point it to /usr/libexec/vyos
We may also want to remove vyos- and words such as "config", "update" etc. from file names since their origin and purpose will be obvious from their location.

The original */share hierarchies are too risky to touch until the last bits of the old code are gone I suppose, but if we introduce new data files, I think it's a good idea to place them in /usr/share/vyos

The new environment variables:

vyos_libexec_dir=/usr/libexec/vyos
vyos_op_scripts_dir=/usr/libexec/vyos/op_mode
vyos_validators_dir=/usr/libexec/vyos/validators
vyos_completion_dir=/usr/libexec/vyos/completion
vyos_conf_scripts_dir=/usr/libexec/vyos/conf_mode
vyos_sbin_dir=/usr/sbin
vyos_bin_dir=/usr/bin

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

dmbaturin triaged this task as Normal priority.May 16 2018, 2:56 AM
dmbaturin created this task.
dmbaturin created this object with visibility "Public (No Login Required)".

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html states:

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts

/usr/libexec/vyos/conf-mode contain scripts and not binaries ... but as VyOS is an embedded appliance it should be ok to bend FHS a bit.

@c-po I think the spirit of it is to keep programs that are not useful for end users separate from programs that are, out of their $PATH, which would only pollute the completion and enable accidental execution of programs that may have strange effect when used in an unintended way outside of their normal workflow.

I've had a quick look at Debian filesystem. Oddly, there's no libexec and /usr/lib is used instead, I wonder if we should follow that convention or rather introduce libexec as per FHS.
But, my point is, packages that keep shell and/or perl scripts in /usr/lib/$packagename include APT, GnuPG, OpenSSH, and Squid. If such long standing and popular projects do it, I don't think we will go against an established practice if we do it as well, regardless of the letter of the FHS.

@higebu and @UnicronNL agreed to the change, so I'm going to proceed with it.

Already in use by now.