Add script to build peach-go-sbot debian package #10
No reviewers
Labels
No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PeachCloud/peach-package-builder#10
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "peach-go-sbot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
There are a few ways to build a debian package, from more low-level to more scripted.
It seems to me the most polished way to build a debian package for a go binary would be to use one of the go-specific tools, as described here https://go-team.pages.debian.net/packaging.html. But it looks to me like this goes into go land a bit. Ways to make a package which include the "source" and the "package".
What I did here was make a simple version, which is just a debian package for a binary executable. I cross-compile go to create the binary executable separately, and then I create a debian package around the binary executables.
The script here,
The debian configuration I ended up using was based off of this SO post:
https://unix.stackexchange.com/questions/627689/how-to-create-a-debian-package-from-a-bash-script-and-a-systemd-service
I ended up the using maintainer scripts that were generated by cargo-deb (as for our other services) but then modified for this service.
More to discuss, but this is tested on the pi and working.
There are also some interesting questions that came up about users, systemd and debian packages.
See this article: https://wiki.debian.org/AccountHandlingInMaintainerScripts
We could consider to modify our other microservices to create their own users that they need,
instead of depending on setup_dev_env to have previously created the users.
Something like this could have advantages in terms of update-ability. Each package doing the necessary installation it needs to run instead of relying on something else. I also like the idea of packages doing their own installation stuff, so that you don't need to make a PR to peach-config at the same time as you make a PR to a microservice, in order for it to work, ideally.
We could also consider to wrap peach-config in a debian package,
which could be useful for thinking about how upgrading works in the future
... as upgrades may very well involve changes to stuff that currently happens in peach-config and not just the microservices
... but just some things that came up and outside the scope of this PR
for this PR, I am using useradd to create a peach-go-sbot user in the postint script,
which then is the user that runs go-sbot via the systemd unit
Lastly, one more issue, it seems that go-sbot and sbotcli expect to run as the same user to work together (at least without some other config which I haven't seen yet, when I run them as different users it throws an error). So we need to think about how other peach services running as other users will interact with go-sbot and sbotcli in terms of user permissions, or maybe talk to cryptix about this
Small typo here: "This build ..." -> "This builds...".
Please capitalize Debian and Freight so we can keep uniformity in the docs 🙏🏻 It's such a silly thing but is somehow highly satisfying to my brain.
Looks great overall! I'm excited to try this. I've left a few comments. The "requested changes" is mostly about the doc consistency (comment above). No other changes are needed if the URL stuff I pointed out isn't an issue.
@ -0,0 +2,4 @@set -e# create user which go-sbot runs asadduser --quiet --system peach-go-sbotThis is so nice <3 Being able to create the user and set binary permissions right here is awesome. Great find! This is going to make our whole installation and system maintenance process so much simpler.
@ -0,0 +22,4 @@def crosscompile_peach_go_sbot():subprocess.check_call(["git", "pull"], cwd=GO_SSB_DIR)# TODO: confirm that version number in the repo matches the version number we set for the package we are buildingSounds like a job for Regex :)
@ -0,0 +47,4 @@render_template(src=src, dest=dest, template_vars={"version": version})# copy systemd service fileSERVICE_DIR = os.path.join(DEB_BUILD_DIR, 'lib/systemd/system')Is
SERVICE_DIRmissing a forward slash?DEB_BUILD_DIR= "/tmp/peach_go_sbot" and we're appending "lib/systemd/system", which would makeSERVICE_DIR=/tmp/peach_go_sbotlib/systemd/systemMaybe that's intended and I'm missing something?
Same thing appears on line 59 for
BIN_DIR.@ -0,0 +47,4 @@render_template(src=src, dest=dest, template_vars={"version": version})# copy systemd service fileSERVICE_DIR = os.path.join(DEB_BUILD_DIR, 'lib/systemd/system')I just confirmed in a python shell, os.path.join inserts the "/" in between parts as needed.
the way I think about it, the second part is like a relative path joined to the first part (and so the second part doesn't start with a slash)
@ -0,0 +22,4 @@def crosscompile_peach_go_sbot():subprocess.check_call(["git", "pull"], cwd=GO_SSB_DIR)# TODO: confirm that version number in the repo matches the version number we set for the package we are buildingJust added a github issue for this so we don't forget it https://github.com/peachcloud/peach-vps/issues/11
@mycognosist just pushed a commit fixing the capitalization and typo and will merge this now.
Will try to be more mindful and feel free to keep reminding me in future PRs, I'm happy to make docs more consistent.
@ -0,0 +47,4 @@render_template(src=src, dest=dest, template_vars={"version": version})# copy systemd service fileSERVICE_DIR = os.path.join(DEB_BUILD_DIR, 'lib/systemd/system')Ok awesome, thanks for checking! I figured it must work somehow, since you've already been using the script successfully. Nice to have learned a little extra about
os.path.join.