Skip to content

Conversation

@aimacintyre
Copy link
Contributor

A series of commits to simplify and streamline how Gargoyle target profile image configurations are managed with the goal to minimise maintenance for target profile configurations once they're created. The general approach is to leverage default setting mechanisms supported by the underlying OpenWrt build system as much as possible.

NB: I think I've made a mis-step in setting up this PR as GitHub is showing 3 commits (61ea942, e1a7030 and 1ac5669) which I covered in PR #1026 intending to try and keep them separate. :(

- only SquashFS images required
- fix image name pattern by removing an excess dash
- device doesn't have USB so set to VPN profile package

Signed-off-by: Andrew MacIntyre <[email protected]>
- M3000 lacks USB so VPN profile
- TR3000 has USB so Large profile

Signed-off-by: Andrew MacIntyre <[email protected]>
All 3 devices lack USB so set to VPN profile

Signed-off-by: Andrew MacIntyre <[email protected]>
Where it makes sense the Gargoyle kconfig can be used to set
symbol and package defaults for the directly supported targets
to reduce reliance on, and maintenance of, the individual target
profile config files.

Enhancements include:
- include some additional general config symbol settings for all
  builds
- add additional menu items for package groups such as target
  specific ethernet drivers, optional ethernet drivers and optional
  wifi drivers
- fine tune some symbol and/or package inclusions for specific targets

Limitations of the kconfig system mean that symbols defaulting to
enabled (i.e. "=m" or "=y") that need be disabled (i.e. set "=n")
can't be incorporated in the Gargoyle kconfig and must be unset in
the target profile config(s) instead.

Signed-off-by: Andrew MacIntyre <[email protected]>
- kmod-usb-net is a direct dependency of all the specified drivers
  so doesn't need to be explicitly specified
- add an extra USB network driver for the RPi5

Signed-off-by: Andrew MacIntyre <[email protected]>
The extra packages aren't direct dependencies but other parts of
Gargoyle expect them to be available as part of the firewall
functionality.

Signed-off-by: Andrew MacIntyre <[email protected]>
The extra package isn't a direct dependency but other parts of
Gargoyle expect it to be available as part of the firewall3
functionality.

Signed-off-by: Andrew MacIntyre <[email protected]>
The PROVIDES=msmtp for the nossl variant of the msmtp package defeats
the dependency for the SSL variant of the plugin, resulting in only
the nossl variant of the msmtp package being built by default.

Fix this by deactivating the PROVIDES and adding explicit msmtp package
variant selection in both plugin variants to match the SSL variant.
NB: PROVIDES has been commented out rather than removed to ease
    restoration in any future restructure of these packages.

Signed-off-by: Andrew MacIntyre <[email protected]>
Unfortunately it appears that having the build statements with the
OpenSSL option first ensures that openvpn-gargoyle-openssl gets
built as the default despite other settings that should have the
mbedtls variant built, so reorder the statements with mbedtls
variants first.

Signed-off-by: Andrew MacIntyre <[email protected]>
…iable

Making the default library selection depend on an an existing external
(to the package) symbol improves default libary selection reliability.

Additionally minor editorial improvements to the package Makefile
to match common OpenWrt packaging practice.

Signed-off-by: Andrew MacIntyre <[email protected]>
OpenWrt's default package machinery runs into trouble with the mvebu
target, possibly provoked by other recent changes, and images fail
to build because of a clash between wpad-basic-mbedtls (which gets
added to an image first) and wpad-mbedtls.

A general solution would be to scan all target image recipes in the
OpenWrt build directory and substitute wpad-mbedtls for
wpad-basic-mbedtls e.g. using sed.  No other target currently
experiences this problem so for now just implement a target specific
patch for the substitution rather than try and change the build
machinery to implement a general solution.

Signed-off-by: Andrew MacIntyre <[email protected]>
Now that a `make defconfig` is done with each build, the target
profile config file only needs the bare minimum config statements
that result in the required buildable config - OpenWrt refers to
such a config file to as a `diffconfig` file, which
`make defconfig` turns into a buildable config file.

This approach achieves much better maintainability for Gargoyle's
supported devices by focussing only on the specific non-default
settings required for the profile and each device, with additional
devices only needing the relevant device statements to be added for
their images to be built (the profile_images patterns also need to
added).  There are only a relatively small number of non-default
settings required for Gargoyle builds and it is much easier to
maintain this small number in isolation without having to wade
through a few thousand lines found in a full config file.

Going forward the intention would be to maintain these configs
only by changing settings that can't be satisfactorily adjusted
any other way.  Preference should given to making setting
adjustments through the global Gargoyle Config.in or package
configurations where possible.  However settings enabled by
default in OpenWrt that Gargoyle needs disabled can frequently
only be disabled by explicit profile config settings (e.g.
default packages, and some kernel and BusyBox settings).

There are a number of OpenSSL related packages that won't be built
(e.g. wpad-openssl) with these configs; if these packages are
still required to be built by default changes should be made to
the global Gargoyle Config.in or gargoyle-extras package structure
to implement this rather than including them in these configs.

The custom default config has been refreshed from the ath79
default config.

Signed-off-by: Andrew MacIntyre <[email protected]>
@aimacintyre
Copy link
Contributor Author

Superceded by #1028

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant