|
|
[[_TOC_]]
|
|
|
|
|
|
## Introduction
|
|
|
|
|
|
High level requirements are located in [Kea 1.6 charter](https://wiki.isc.org/bin/view/Main/KeaCharter16). User complaints about Kea installation are gathered [here](https://gitlab.isc.org/isc-private/kea/wikis/install-complaints).
|
|
|
|
|
|
## Background
|
|
|
Kea supports many optional environments. Some of them are easy set up (MySQL, PostgreSQL), but others are not. Cassandra packages are often outdated in distros and installing packages from cassandra.apache.org is required. Furthermore, we need a cpp-driver (a C++ interface for Cassandra), which is available on github only. The second tricky environment is RADIUS. We use a FreeRADIUS client patched by Francis. The third and by far the most difficult environment Kea can work with is NETCONF. It requires Sysrepo, which has many dependencies that are not packaged even on popular OSes such as Ubuntu. The compilation is far more complicated than `configure && make`. See [netconf install notes on Ubuntu](https://gitlab.isc.org/isc-projects/kea/wikis/docs/Ubuntu-installation-notes) for example.
|
|
|
|
|
|
On top of that, we have a number (8 in kea 1.6) of paid hooks. The number is increasing with every release. We want to give people an easy way to install them. In Kea 1.5 the only way to compile hooks was to extract kea sources, extract hooks package into premium/ subdir and then recompile everything.
|
|
|
|
|
|
## Detailed Requirements
|
|
|
|
|
|
### Requirements for Packages
|
|
|
|
|
|
1. Kea packages content
|
|
|
1. Kea modules and extra features should be packaged separately into dynamically loaded libraries, see more in #435.
|
|
|
1. packages should be prepared in a way that allow installation and upgrading
|
|
|
1. coordinate packaging with distro maintainers
|
|
|
1. keep solution close to distros solutions so maintainers could gain from packaging changes on Kea side and quickly update their side when something changes in Kea e.g. new daemon has been added, etc.
|
|
|
1. formats
|
|
|
1. minimum: deb and rpm
|
|
|
1. stretch goal: docker, snap?, flatpak?
|
|
|
1. supported distros
|
|
|
1. TBD minimum: ubuntu 18.04, centos 7, fedora 29, debian 9
|
|
|
1. TBD stretch goal: all tested distros
|
|
|
1. packages list:
|
|
|
1. our list of packages should take into account #435 so mysql is plugable as package, etc.
|
|
|
1. our package names should be different to avoid mixing
|
|
|
1. our packages should be in conflict with distro packages so it should not be possible to install both at the same time
|
|
|
1. note: extra packages for 3rd party dependencies not available as packages e.g. NETCONF
|
|
|
1. packages compliance
|
|
|
1. packages should be compliant with distros policies
|
|
|
1. Kea processes should use native solutions for services, systemd on Linuxes, daemon on FreeBSD
|
|
|
1. distribution
|
|
|
1. distributing open source packages and premium/subscription packages should be supported
|
|
|
1. packages should be exposed as just a folder of files on FTP/HTTP server
|
|
|
1. all types of packages should be served from one location if possible
|
|
|
1. packages should be exposed via native repositories e.g. generated deb/rpm repository, so they can be added to distro in /etc/apt/sources.list or /etc/yum.repos.d/ and installed by apt or dnf, eg. using [Nexus Repository OSS from Sonatype](https://www.sonatype.com/nexus-repository-oss)
|
|
|
1. repositories should be signed
|
|
|
1. rpm packages should be signed
|
|
|
1. access control should be applied to premium and subscription packages
|
|
|
1. there should be 2 flavours of repositories:
|
|
|
1. release repos for keeping all release packages
|
|
|
1. CI/engineering repos where packages will be added after each successful CI build
|
|
|
|
|
|
### Requirements for Repository Hosting Solution
|
|
|
|
|
|
1. different package formats: rpm, deb, docker (in the future)
|
|
|
1. public and private repositories
|
|
|
1. fine grain access control (selected packages can be accessed by selected customers)
|
|
|
1. release repositories with content uploaded infrequently
|
|
|
1. CI/engineering repositories where content is uploaded several times a day
|
|
|
1. creating customer accounts, giving and revoking access to repositories
|
|
|
1. API for creating accounts and for giving and revoking access
|
|
|
1. signing repositories
|
|
|
1. sufficient storage place for Kea builds
|
|
|
1. sufficient bandwidth for downloading Kea builds
|
|
|
|
|
|
#### Candidates
|
|
|
|
|
|
Accepted:
|
|
|
|
|
|
- Nexus (https://help.sonatype.com/repomanager3)
|
|
|
|
|
|
Rejected:
|
|
|
|
|
|
- Pulp (https://pulpproject.org/) - next version not ready yet and will not be compatible with previous ones so no clear future
|
|
|
- Artifactory OSS (https://jfrog.com/open-source/) - does not support RPM, Deb and Docker packages
|
|
|
|
|
|
Considered hosted externally:
|
|
|
|
|
|
- https://packagecloud.io/pricing
|
|
|
- https://jfrog.com/artifactory/
|
|
|
- https://cloudsmith.io/
|
|
|
|
|
|
## Design
|
|
|
|
|
|
### Packages
|
|
|
|
|
|
#### RPM
|
|
|
|
|
|
* isc-kea
|
|
|
* isc-kea-devel
|
|
|
* isc-kea-hooks
|
|
|
* isc-kea-libs
|
|
|
* isc-kea-premium-cb-cmds
|
|
|
* isc-kea-premium-class-cmds
|
|
|
* isc-kea-premium-flex-id
|
|
|
* isc-kea-premium-forensic-log
|
|
|
* isc-kea-premium-host-cache
|
|
|
* isc-kea-premium-host-cmds
|
|
|
* isc-kea-premium-radius
|
|
|
* isc-kea-premium-subnet-cmds
|
|
|
|
|
|
#### Deb
|
|
|
|
|
|
* isc-kea-admin
|
|
|
* isc-kea-common
|
|
|
* isc-kea-ctrl-agent
|
|
|
* isc-kea-dev
|
|
|
* isc-kea-dhcp4-server
|
|
|
* isc-kea-dhcp6-server
|
|
|
* isc-kea-dhcp-ddns-server
|
|
|
* isc-kea-doc
|
|
|
* isc-kea-premium-cb-cmds
|
|
|
* isc-kea-premium-class-cmds
|
|
|
* isc-kea-premium-flex-id
|
|
|
* isc-kea-premium-forensic-log
|
|
|
* isc-kea-premium-host-cache
|
|
|
* isc-kea-premium-host-cmds
|
|
|
* isc-kea-premium-subnet-cmds
|
|
|
* python3-isc-kea-connector
|
|
|
|
|
|
#### Versioning
|
|
|
|
|
|
There are two parts of package version:
|
|
|
* Kea version e.g. 1.5.0
|
|
|
* build date or build number e.g. isc20190408163048
|
|
|
|
|
|
Examples:
|
|
|
* isc-kea-admin_1.5.0-isc20190408163048_amd64.deb
|
|
|
* isc-kea-1.5.0-isc20190408125858.fc28.x86_64.rpm
|
|
|
|
|
|
### Repository Design
|
|
|
|
|
|
Repos hierarchy and naming convention is as follows.
|
|
|
|
|
|
`kea-<branch-version>-<system-name>-<system-revision>[-ci]`
|
|
|
|
|
|
Examples:
|
|
|
- kea-1.6-ubuntu-18.04 - repository for released packages for 1.6 branch for Ubuntu 18.04
|
|
|
- kea-1.7-centos-7 - repository for released packages for 1.7 branch for Centos 7
|
|
|
- kea-1.8-freebsd-12-ci - repository for engineering packages, not yet released for 1.8 branch for FreeBSD 12
|
|
|
|
|
|
#### Premium Packages in Repos
|
|
|
|
|
|
Premium packages in repositories are protected by defined [content selectors](https://help.sonatype.com/repomanager3/configuration/repository-management#RepositoryManagement-ContentSelectors). All the packages in given repository are public but the ones indicated by content selector which have ```premium``` word in their name. These premium packages are only visible to logged in users with given permission.
|
|
|
|
|
|
* We should also assess whether we can use this repo for the premium sales from the web site. Currently we do this by uploading the package to the 'store' and having the store handle the downloading, but as we will have more OS options, it would be better to use this repo directly.
|
|
|
* We also need to have a way to give prospective new users a 'trial copy' (done via sales). For this we can create a dummy user account and just change the pwd periodically.
|
|
|
* If the repo can email registered users when a new version is uploaded, that would be a very useful feature.
|
|
|
* We need to check the user account creation and pwd reset - it is probably ok, but this is a significant usability and supportability factor. Do we want accounts for each individual user (e.g. 6 * number of support customers), or shared 'customer' accounts?
|
|
|
|
|
|
### Statistics
|
|
|
It is useful to be able to see downloads by time period, and version. This enables us to see what is the most popular version and to see when the bulk of users have updated to a new version.
|
|
|
|
|
|
### Issues
|
|
|
We don't want people logging issues against the packages in the package system, do we? It would be good if we can configure in links to the relevant Gitlab projects.
|
|
|
|
|
|
### Signing
|
|
|
|
|
|
#### RPM
|
|
|
TBD
|
|
|
|
|
|
#### Deb
|
|
|
TBD
|
|
|
|
|
|
## Synchronization with Distributions
|
|
|
|
|
|
Kea is being tested on:
|
|
|
|
|
|
| System | EOL |
|
|
|
|---------|-------|
|
|
|
|Fedora 31||
|
|
|
|Fedora 32||
|
|
|
|CentOS 7|2020.11|
|
|
|
|Debian 8|2020.06|
|
|
|
|Debian 9|2022.06|
|
|
|
|Debian 10||
|
|
|
|Ubuntu 18.04|2023.04|
|
|
|
|Ubuntu 19.10||
|
|
|
|Ubuntu 20.04||
|
|
|
|FreeBSD 11.2|2019.10|
|
|
|
|FreeBSD 11.3 ???||
|
|
|
|FreeBSD 12.0||
|
|
|
|
|
|
### Fedora
|
|
|
|
|
|
* Fedora 28 - supported till 2019.06
|
|
|
* Fedora 29 - supported till ~2019.12
|
|
|
* **Fedora 30 - planned release on 2019.05.07, will include Kea ???**
|
|
|
|
|
|
Old release X is maintained until 1 month after the release of X+2.
|
|
|
|
|
|
### RHEL
|
|
|
|
|
|
* RHEL 7 - End of Full Support: 2019 Q4, End of Maintenance Support 2 - 2024.06.30
|
|
|
* **RHEL 8 - beta released on 2018.11.14, planned release on ~2019, will include Kea ???**
|
|
|
|
|
|
### CentOS
|
|
|
|
|
|
Releases 1 month after RHEL releases. Support is the same as in RHEL.
|
|
|
|
|
|
### Debian
|
|
|
|
|
|
* Debian 8 "jessie" - obsolete stable release, EOLed, LTS supported till 2020.06.06
|
|
|
* Debian 9 "stretch" - current stable release, full supported till 2020, LTS till 2022
|
|
|
* **Debian 10 "buster" - no release date has been set, will include Kea ???**
|
|
|
|
|
|
### Ubuntu
|
|
|
|
|
|
* Ubuntu 16.04 LTS - supported till 2021.04
|
|
|
* Ubuntu 18.04 LTS - supported till 2023.04
|
|
|
* Ubuntu 18.10 - supported till 2019.06
|
|
|
* **Ubuntu 19.04 - planned release on 2019.04.18 - will include Kea ???**
|
|
|
|
|
|
### FreeBSD
|
|
|
|
|
|
* FreeBSD 11 - 11.2 released on 2018.06, supported till 2021.09.30
|
|
|
* FreeBSD 12 - 12.0 released on 2018.12, supported till ~2023
|
|
|
* FreeBSD 13 - probable release on 2020
|
|
|
|
|
|
Each major version supported for about 5 years.
|
|
|
|
|
|
## Package Standardization Across Distros
|
|
|
|
|
|
All distros should have the following packages available:
|
|
|
|
|
|
- [ ] `isc-kea`
|
|
|
- **Summary:** Kea metapackage that installs the entire Kea DHCP server software suite
|
|
|
- [ ] `isc-kea-common`
|
|
|
- **Summary:** Common files and libraries for Kea DHCP Server
|
|
|
- **Caveat:** `isc-kea-libs` is split on redhat systems and should be merged
|
|
|
- [ ] `isc-kea-admin`
|
|
|
- **Summary:** Database administration tools for Kea DHCP server
|
|
|
- **Caveat:** `isc-kea-shell` should be merged into this package.
|
|
|
- [ ] `isc-kea-ctrl-agent`
|
|
|
- **Summary:** Kea Control Agent - REST service for controlling Kea DHCP server
|
|
|
- [ ] `isc-kea-dhcp-ddns`
|
|
|
- **Summary:** Kea DHCP Dynamic DNS Server
|
|
|
- [ ] `isc-kea-dhcp4`
|
|
|
- **Summary:** Kea IPv4 DHCP Server
|
|
|
- [ ] `isc-kea-dhcp6`
|
|
|
- **Summary:** Kea IPv6 DHCP Server
|
|
|
- [ ] `isc-kea-doc`
|
|
|
- **Summary:** DHCPv4 and DHCPv6 server from ISC (documentation)
|
|
|
- [ ] `isc-kea-dev`
|
|
|
- **Summary:** DHCPv4 and DHCPv6 server from ISC (development files)
|
|
|
- **Caveat:** `isc-kea-devel` on RPM systems
|
|
|
- [ ] `isc-kea-perfdhcp`
|
|
|
- **Summary:** Kea Optional Utils - perfdhcp
|
|
|
- [ ] `isc-kea-hooks`
|
|
|
- **Summary:** This package contains all of the open source Kea hooks.
|
|
|
- `bootp` -- BOOTP hooks library
|
|
|
- `mysql-cb` -- MySQL Configuration Backend hooks library
|
|
|
- `pgsql-cb` -- PostgreSQL Configuration Backend hooks library
|
|
|
- `ha` -- High Availability hooks library
|
|
|
- `stat-cmds` -- Statistics Commands hooks library
|
|
|
- `run-script` -- Run Script hooks library
|
|
|
- `lease-cmds` -- Lease Commands hooks library
|
|
|
- `flex-option` -- Flexible Option hooks library
|
|
|
- [ ] `isc-kea-hook-premium-cb-cmds`
|
|
|
- **Summary:** Kea Config Backend Commands hook library
|
|
|
- [ ] `isc-kea-hook-premium-class-cmds`
|
|
|
- **Summary:** Kea Classification Commands hook library
|
|
|
- [ ] `isc-kea-hook-premium-ddns-tuning`
|
|
|
- **Summary:** Kea DDNS tuning hook library
|
|
|
- [ ] `isc-kea-hook-premium-flex-id`
|
|
|
- **Summary:** Kea Flex ID hook library
|
|
|
- [ ] `isc-kea-hook-premium-forensic-log`
|
|
|
- **Summary:** Kea Forensic Log hook library
|
|
|
- [ ] `isc-kea-hook-premium-gss-tsig`
|
|
|
- **Summary:** Kea GSS-TSIG hook library
|
|
|
- [ ] `isc-kea-hook-premium-host-cache`
|
|
|
- **Summary:** Kea Host Cache hook library
|
|
|
- [ ] `isc-kea-hook-premium-host-cmds`
|
|
|
- **Summary:** Kea Host Commands hook library
|
|
|
- [ ] `isc-kea-hook-premium-lease-query`
|
|
|
- **Summary:** Kea Lease Query hook library
|
|
|
- [ ] `isc-kea-hook-premium-limits`
|
|
|
- **Summary:** Kea limits hook library
|
|
|
- [ ] `isc-kea-hook-premium-rbac`
|
|
|
- **Summary:** Kea Control Agent Role Based Access Control hook library
|
|
|
- [ ] `isc-kea-hook-premium-subnet-cmds`
|
|
|
- **Summary:** Kea Subnet Commands hook library
|
|
|
- [ ] `isc-kea-hook-premium-radius`
|
|
|
- **Summary:** Kea Premium RADIUS hook library
|
|
|
|
|
|
The package manager build files for Kea can be found here: https://gitlab.isc.org/isc-projects/kea-packaging
|
|
|
|
|
|
`isc-kea-static` and `isc-kea-http` subpackages should be removed if they exist. The http libraries should be packaged in `isc-kea-common` with the rest of the libraries. In regards to `isc-kea-static`, if someone needs Kea static libraries they can build it themselves. Static libraries are quite large and I can't imagine a common scenario where someone would need them.
|
|
|
|
|
|
`isc-kea-libs` and `isc-kea-common` should be combined into `isc-kea-common` if they are not already.
|
|
|
|
|
|
`isc-kea-shell` should be merged into `isc-kea-admin` as it is an admin tool, and doesn't need to be split.
|
|
|
|
|
|
`isc-kea` should depend on all of the subpackages under it in the heirarchy.
|
|
|
|
|
|
Installing `isc-kea` should install all of the daemons and libraries out of the box, but should also allow customers to instead opt to only install specific daemons, such as `dhcp4` and `dhcp-ddns`. `isc-kea-hooks` should install all available open source hooks. The premium hooks cannot be bundled up into a metapackage, because not all distros support weak dependencies. The goal here is to keep package naming as consistent as possible across distributions, and document differences when it is absolutely necessary (for example, debian requires service users to begin with a _).
|
|
|
|
|
|
The daemon packages should contain everything that is needed to start and help users use each daemon, such as the init script/unit file, the binary, a configuration file, and the manpage.
|
|
|
|
|
|
`isc-kea-docs` should contain the HTML documentation and the other related doxygen files.
|
|
|
|
|
|
Each package should install a similar subset of files onto each distribution, and pathnames used for configuration files, sockets, temp files, logfiles, etc should be as consistent as possible across distributions. The only major differences in packaging we should see are related to differences in distributuions init systems.
|
|
|
|
|
|
### Notable differences
|
|
|
- Alpine Linux:
|
|
|
- Uses openrc service init instead of systemd
|
|
|
- Uses musl libc instead of glibc, but should have little impact on code as musl is well tested for compatibility.
|
|
|
- glibc specific features should be avoided.
|
|
|
- Lack of systemd means no journald; must log to a real file.
|
|
|
- FreeBSD:
|
|
|
- Uses rc for service init instead of systemd
|
|
|
- Debian/Ubuntu:
|
|
|
- Requires service usernames to be prefixed with an underscore (_)
|
|
|
- *All packages, except Debian/Ubuntu, should have deamons running as user 'kea'. Debian/Ubuntu will use '\_kea' instead*. |