This would also support the 'multiple reservations for one IP' situation, where a single host has multiple interfaces with different identifiers but which are guaranteed to never be in use simultaneously. When the host switches interfaces, Kea will not give it the reserved IP unless the host released the lease prior to the switch, and that will not always occur (in my case, it's a laptop with both wired and wireless interfaces, and bringing the laptop out of sleep mode with the wired interface connected will not cause the lease on the wireless interface to be released).
If you run rake build:agent_pkg
instead you'll get a native package you can install elsewhere.
This is excellent news... I will no longer need to carry a local patch :-) Building the packages is not much of a burden, but it will be even better when that's done upstream too.
Confirmed. Setting STORK_DATABASE_HOST=127.0.0.1
solves the problem.
Describe the bug Working system running Stork 1.9 was upgraded to 1.10; server will no longer start, see log below.
To Reproduce Steps to reproduce the behavior:
systemctl start isc-stork-server
Expected behavior Stork server should start as it did before the upgrade.
Environment:
Additional Information
Apr 10 06:44:20 stork22 systemd[1]: Started ISC Stork Server.
Apr 10 06:44:20 stork22 stork-server[73617]: time="2023-04-10 06:44:20" level="warning" msg="The hook directory: '/var/lib/stork-server/hooks' doesn't exist" file=" server.go:195 " error="cannot find plugin paths in: /var/lib/stork-server/hooks: cannot list hook directory: /var/lib/stork-server/hooks: open /var/lib/stork-server/hooks: no such file or directory"
Apr 10 06:44:20 stork22 stork-server[73617]: time="2023-04-10 06:44:20" level="info" msg="Checking connection to database" file=" connection.go:90 "
Apr 10 06:44:20 stork22 stork-server[73617]: time="2023-04-10 06:44:20" level="fatal" msg="Cannot start the Stork Server: Not running in a terminal\nisc.org/stork/util.GetSecretInTerminal\n\t/builds/isc-projects/stork/backend/util/util.go:232\nisc.org/stork/server/database.NewPgDBConn\n\t/builds/isc-projects/stork/backend/server/database/connection.go:103\nisc.org/stork/server/database.NewApplicationDatabaseConn\n\t/builds/isc-projects/stork/backend/server/database/connection.go:152\nisc.org/stork/server.(*StorkServer).Bootstrap\n\t/builds/isc-projects/stork/backend/server/server.go:202\nmain.main\n\t/builds/isc-projects/stork/backend/cmd/stork-server/main.go:61\nruntime.main\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/proc.go:250\nruntime.goexit\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/asm_amd64.s:1594" file=" main.go:63 "
Apr 10 06:44:20 stork22 systemd[1]: isc-stork-server.service: Main process exited, code=exited, status=1/FAILURE
Apr 10 06:44:20 stork22 systemd[1]: isc-stork-server.service: Failed with result 'exit-code'.
server.env contains:
STORK_DATABASE_NAME=stork
STORK_DATABASE_USER_NAME=stork
STORK_DATABASE_PASSWORD=<redacted>
STORK_REST_HOST=2001:470:8afe:64::115
STORK_REST_PORT=8989
STORK_REST_STATIC_FILES_DIR=/usr/share/stork/www
STORK_SERVER_ENABLE_METRICS=true
And finally.. I've got the arm64 agents deployed and running now. They work as they should, the same as the x86_64 versions :-)
Almost forgot... I did my testing against the v1.9.0 tag, since that's what I want to install. The patch above applies cleanly to master
though.
And now I have a result. On a Linux/arm64 system, with the patch above, rake build
completes successfully. I only need the agent on these boxes but I got the full build working anyway :-)
If the system has Python 3.11, then there will be a build failure. At that point editing tools/nodejs/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/input.py
to replace 'rU' with 'r' will allow the build to proceed; when an updated version of gyp-next/node-gyp gets published to PyPI this problem will disappear.
This will get me to working systems now, I can copy the agent binary into the proper location and clone the systemd service file (and other needed bits) from one of my Linux/amd64 machines.
One of those statements was incorrect: the current version of gyp-next on PyPI doesn't work with modern versions of Python (see https://github.com/nodejs/gyp-next/issues/29). Presumably when that package on PyPI gets upgraded this will be fixed.
I've made some progress; the patch below gets the build to almost work... except something deep in the Node dependency graph is pulling in an old version of node-gyp which is not compatible with any version of Python > 3.8, and my system has 3.11.
index e73815c0..efc01daa 100644
--- a/rakelib/00_init.rake
+++ b/rakelib/00_init.rake
@@ -365,9 +365,9 @@ def fetch_file(url, target)
end
### Recognize the operating system
-uname=`uname -s`
+uname_s=`uname -s`
-case uname.rstrip
+case uname_s.rstrip
when "Darwin"
OS="macos"
when "Linux"
@@ -377,7 +377,20 @@ case uname.rstrip
when "OpenBSD"
OS="OpenBSD"
else
- puts "ERROR: Unknown/unsupported OS: %s" % UNAME
+ puts "ERROR: Unknown/unsupported OS: %s" % UNAME_S
+ fail
+end
+
+### Recognize the CPU architecture
+uname_m=`uname -m`
+
+case uname_m.rstrip
+ when "x86_64"
+ ARCH="x86_64"
+ when "aarch64"
+ ARCH="aarch64"
+ else
+ puts "ERROR: Unknown/unsupported architecture: %s" % UNAME_M
fail
end
@@ -423,12 +436,23 @@ when "macos"
puts "WARNING: MacOS is not officially supported, the provisions for building on MacOS are made"
puts "WARNING: for the developers' convenience only."
when "linux"
- go_suffix="linux-amd64"
- protoc_suffix="linux-x86_64"
- node_suffix="linux-x64"
- golangcilint_suffix="linux-amd64"
- chrome_drv_suffix="linux64"
- shellcheck_suffix="linux.x86_64"
+ case ARCH
+ when "x86_64"
+ go_suffix="linux-amd64"
+ protoc_suffix="linux-x86_64"
+ node_suffix="linux-x64"
+ golangcilint_suffix="linux-amd64"
+ chrome_drv_suffix="linux64"
+ shellcheck_suffix="linux.x86_64"
+ when "aarch64"
+ go_suffix="linux-arm64"
+ protoc_suffix="linux-aarch_64"
+ node_suffix="linux-arm64"
+ golangcilint_suffix="linux-arm64"
+ # Chrome Driver is not available for Linux on arm64
+ chrome_drv_suffix="NOT AVAILABLE"
+ shellcheck_suffix="linux.aarch64"
+ end
when "FreeBSD"
go_suffix="freebsd-amd64"
golangcilint_suffix="freebsd-amd64"
@@ -739,11 +763,18 @@ add_version_guard(GO, go_ver)
GOSWAGGER = File.join(go_tools_dir, "goswagger")
file GOSWAGGER => [WGET, GO, TAR, go_tools_dir] do
if OS != 'FreeBSD' && OS != "OpenBSD"
- goswagger_suffix = "linux_amd64"
- if OS == 'macos'
- # GoSwagger fails to build on macOS due to https://gitlab.isc.org/isc-projects/stork/-/issues/848.
- goswagger_suffix="darwin_amd64"
+ case OS
+ when "macos"
+ # GoSwagger fails to build on macOS due to https://gitlab.isc.org/isc-projects/stork/-/issues/848.
+ goswagger_suffix="darwin_amd64"
+ when "linux"
+ case ARCH
+ when "x86_64"
+ goswagger_suffix = "linux_amd64"
+ when "aarch64"
+ goswagger_suffix = "linux_arm64"
end
+ end
fetch_file "https://github.com/go-swagger/go-swagger/releases/download/#{goswagger_ver}/swagger_#{goswagger_suffix}", GOSWAGGER
sh "chmod", "u+x", GOSWAGGER
else
OK, even a native build is failing, because the build system is downloading/installing binaries for the wrong architecture (protoc and node so far). I'll take a look and see if this is something that is reasonable to tackle.
It appears that the build system won't work with cross-building, at least not without something more complex than just GOARCH
... it needs to know the difference between binaries for the build system and binaries for the host system.
kpfleming@balrog22:~/git-personal/stork$ rake build:agent GOARCH=arm64
/home/kpfleming/git-personal/stork/tools/golang/go/bin/go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.26.0
go: cannot install cross-compiled binaries when GOBIN is set
rake aborted!
Command failed with status (1): [/home/kpfleming/git-personal/stork/tools/g...]
/home/kpfleming/git-personal/stork/rakelib/00_init.rake:788:in `block in <top (required)>'
Tasks: TOP => build:agent => backend/cmd/stork-agent/stork-agent => backend/api/agent.pb.go => /home/kpfleming/git-personal/stork/tools/golang/go/bin/protoc-gen-go
(See full trace by running task with --trace)
I'm going to run the arm64 builds natively on an arm64 system anyway, so this won't be an issue for me.
OK, I've been able to successfully build Kea 2.2.0 packages on both amd64 and arm64 systems, using Debian Bookworm as the distribution. Here's what I did:
v2_2
branch into the source directory.tex-gyre
and texlive-latex-extra
to Build-Depends
in 'debian/control'; without them the pdflatex
test in the configure script fails.With all of that done I was able to use dpkg-source to make the 'source package' files and then build from them. This is probably similar to the packaging configuration used in Debian itself, although the Debian packages have different names and may have other differences... I'd rather stick with the ISC-style packages as I've been using them for some time.
I'm using pbuilder
after using dpkg-source
to make a 'source package' three-file combination (.orig.tar.gz
, .debian.tar.xz
, and .dsc
). This is effectively the same as using debuild
so it does believe it needs to apply the patches because the series
file is there.
I'll give this a try again after just removing the content of the patches
directory (and I am using the v2_2
branch as well, since I'm building packages of 2.2.0).
There are two related questions here:
Stork support for Arm in any form (regardless of packaging).
Stork packages for Arm-based systems.
I've been assuming all along that Stork should work without issue on an arm64 system, as it does on an x86_64/amd64 system, as it is relatively new software and shouldn't contain any architecture-specific code. That may not be a safe assumption, but it does seem reasonable :-)
On the packaging side, at least for Debian there isn't any special work required; the same debian
directory used for building amd64 packages will work for building arm64 packages. I've just done this exact thing for a different set of (unrelated) software and the results were as expected: the builds completed, tests passed, packages got built. It does require building on an arm64 machine as has been noted earlier in this issue, as cross-building is much more complicated, but I'm building on the boxes where I plan to run the software so that's not a concern for me.
The linked MR doesn't seem to contain very much content, and what little is there appears to be macOS-related. Since I'm building and running on Linux that won't apply to my situation.
I am also wanting to run Stork (agents) on arm64 machines, and would really like to be able to install and manage the software using the standard package manager (apt/dpkg in my case). I found this issue and read through it, but as far as I can tell the Rake tasks referred to here are no longer present in the repository.
I'm fine with building my own packages, but to do that I need to be able to get a copy of the 'debian' subdirectory that is being used to build them for upload to Cloudsmith. Where does that live now?
I'm trying to build Kea packages locally, on an arm64 machine since I need packages for that architecture and they aren't available in the Cloudsmith repositories.
While this repo's description says it is 'private', it's not actually private so I decided to try to use it.
Unfortunately dropping the debian
directory from this repository into a Kea source tree and then trying to build the packages failed, because the debian
directory contains patches which cannot be applied to Kea 2.2.x sources.
Is this repository actively in use for building Kea packages?
Here's a probably-way-too-simplistic proposal :-)
As an opt-in feature, modify the current request processing as follows:
unacked-clients
list even though the other server is not in partner-down
state. Emit a log message documenting what happened as well.unacked-clients
list reaches the max-unacked-clients
configured threshold, even though the other server is not in partner-down
state, then take action to tell it to stop handling requests and transition it to partner-down
as if the communications link had failed.This may be a terrible idea, and that's fine, it at least gives people something to criticize!
Kevin Fleming (fe3ca247) at 15 Jul 16:02
[#2494] correct JSON syntax in some configuration examples
... and 422 more commits