2023-01-30 16:27:06 +03:00
|
|
|
default: build
|
|
|
|
|
|
|
|
build:
|
|
|
|
# build early to catch syntax errors
|
|
|
|
CGO_ENABLED=0 go build
|
2023-07-22 15:02:05 +03:00
|
|
|
CGO_ENABLED=0 go vet ./...
|
2023-07-01 19:48:29 +03:00
|
|
|
CGO_ENABLED=0 go vet -tags integration
|
2023-01-30 16:27:06 +03:00
|
|
|
./gendoc.sh
|
|
|
|
(cd http && CGO_ENABLED=0 go run ../vendor/github.com/mjl-/sherpadoc/cmd/sherpadoc/*.go -adjust-function-names none Admin) >http/adminapi.json
|
|
|
|
(cd http && CGO_ENABLED=0 go run ../vendor/github.com/mjl-/sherpadoc/cmd/sherpadoc/*.go -adjust-function-names none Account) >http/accountapi.json
|
|
|
|
# build again, files above are embedded
|
|
|
|
CGO_ENABLED=0 go build
|
|
|
|
|
|
|
|
test:
|
|
|
|
CGO_ENABLED=0 go test -shuffle=on -coverprofile cover.out ./...
|
|
|
|
go tool cover -html=cover.out -o cover.html
|
|
|
|
|
|
|
|
test-race:
|
|
|
|
CGO_ENABLED=1 go test -race -shuffle=on -covermode atomic -coverprofile cover.out ./...
|
|
|
|
go tool cover -html=cover.out -o cover.html
|
|
|
|
|
2023-07-24 12:00:11 +03:00
|
|
|
# note: if testdata/upgradetest.mbox.gz exists, its messages will be imported
|
|
|
|
# during tests. helpful for performance/resource consumption tests.
|
add a "backup" subcommand to make consistent backups, and a "verifydata" subcommand to verify a backup before restoring, and add tests for future upgrades
the backup command will make consistent snapshots of all the database files. i
had been copying the db files before, and it usually works. but if the file is
modified during the backup, it is inconsistent and is likely to generate errors
when reading (can be at any moment in the future, when reading some db page).
"mox backup" opens the database file and writes out a copy in a transaction.
it also duplicates the message files.
before doing a restore, you could run "mox verifydata" on the to-be-restored
"data" directory. it check the database files, and compares the message files
with the database.
the new "gentestdata" subcommand generates a basic "data" directory, with a
queue and a few accounts. we will use it in the future along with "verifydata"
to test upgrades from old version to the latest version. both when going to the
next version, and when skipping several versions. the script test-upgrades.sh
executes these tests and doesn't do anything at the moment, because no releases
have this subcommand yet.
inspired by a failed upgrade attempt of a pre-release version.
2023-05-26 20:26:51 +03:00
|
|
|
test-upgrade:
|
2023-07-24 12:00:11 +03:00
|
|
|
nice ./test-upgrade.sh
|
add a "backup" subcommand to make consistent backups, and a "verifydata" subcommand to verify a backup before restoring, and add tests for future upgrades
the backup command will make consistent snapshots of all the database files. i
had been copying the db files before, and it usually works. but if the file is
modified during the backup, it is inconsistent and is likely to generate errors
when reading (can be at any moment in the future, when reading some db page).
"mox backup" opens the database file and writes out a copy in a transaction.
it also duplicates the message files.
before doing a restore, you could run "mox verifydata" on the to-be-restored
"data" directory. it check the database files, and compares the message files
with the database.
the new "gentestdata" subcommand generates a basic "data" directory, with a
queue and a few accounts. we will use it in the future along with "verifydata"
to test upgrades from old version to the latest version. both when going to the
next version, and when skipping several versions. the script test-upgrades.sh
executes these tests and doesn't do anything at the moment, because no releases
have this subcommand yet.
inspired by a failed upgrade attempt of a pre-release version.
2023-05-26 20:26:51 +03:00
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
check:
|
|
|
|
staticcheck ./...
|
|
|
|
staticcheck -tags integration
|
2023-07-22 15:02:05 +03:00
|
|
|
GOARCH=386 CGO_ENABLED=0 go vet ./...
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
# having "err" shadowed is common, best to not have others
|
|
|
|
check-shadow:
|
2023-02-05 18:28:44 +03:00
|
|
|
go vet -vettool=$$(which shadow) ./... 2>&1 | grep -v '"err"'
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
fuzz:
|
|
|
|
go test -fuzz FuzzParseSignature -fuzztime 5m ./dkim
|
|
|
|
go test -fuzz FuzzParseRecord -fuzztime 5m ./dkim
|
|
|
|
go test -fuzz . -fuzztime 5m ./dmarc
|
|
|
|
go test -fuzz . -fuzztime 5m ./dmarcrpt
|
|
|
|
go test -fuzz . -parallel 1 -fuzztime 5m ./imapserver
|
|
|
|
go test -fuzz . -parallel 1 -fuzztime 5m ./junk
|
|
|
|
go test -fuzz FuzzParseRecord -fuzztime 5m ./mtasts
|
|
|
|
go test -fuzz FuzzParsePolicy -fuzztime 5m ./mtasts
|
|
|
|
go test -fuzz . -parallel 1 -fuzztime 5m ./smtpserver
|
|
|
|
go test -fuzz . -fuzztime 5m ./spf
|
|
|
|
go test -fuzz FuzzParseRecord -fuzztime 5m ./tlsrpt
|
|
|
|
go test -fuzz FuzzParseMessage -fuzztime 5m ./tlsrpt
|
|
|
|
|
2023-07-24 00:32:02 +03:00
|
|
|
|
2023-06-04 21:38:10 +03:00
|
|
|
test-integration:
|
2023-07-24 00:32:02 +03:00
|
|
|
docker image build --pull -f Dockerfile -t mox_integration_moxmail .
|
|
|
|
docker image build --pull -f testdata/integration/Dockerfile.test -t mox_integration_test testdata/integration
|
|
|
|
-rm -rf testdata/integration/moxacmepebble/data
|
|
|
|
-rm -rf testdata/integration/moxmail2/data
|
|
|
|
-rm -f testdata/integration/tmp-pebble-ca.pem
|
|
|
|
MOX_UID=$$(id -u) docker-compose -f docker-compose-integration.yml run test
|
|
|
|
docker-compose -f docker-compose-integration.yml down --timeout 1
|
2023-06-04 21:38:10 +03:00
|
|
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
imaptest-build:
|
2023-06-04 21:38:10 +03:00
|
|
|
-docker-compose -f docker-compose-imaptest.yml build --no-cache --pull mox
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
imaptest-run:
|
|
|
|
-rm -r testdata/imaptest/data
|
|
|
|
mkdir testdata/imaptest/data
|
change mox to start as root, bind to network sockets, then drop to regular unprivileged mox user
makes it easier to run on bsd's, where you cannot (easily?) let non-root users
bind to ports <1024. starting as root also paves the way for future improvements
with privilege separation.
unfortunately, this requires changes to how you start mox. though mox will help
by automatically fix up dir/file permissions/ownership.
if you start mox from the systemd unit file, you should update it so it starts
as root and adds a few additional capabilities:
# first update the mox binary, then, as root:
./mox config printservice >mox.service
systemctl daemon-reload
systemctl restart mox
journalctl -f -u mox &
# you should see mox start up, with messages about fixing permissions on dirs/files.
if you used the recommended config/ and data/ directory, in a directory just for
mox, and with the mox user called "mox", this should be enough.
if you don't want mox to modify dir/file permissions, set "NoFixPermissions:
true" in mox.conf.
if you named the mox user something else than mox, e.g. "_mox", add "User: _mox"
to mox.conf.
if you created a shared service user as originally suggested, you may want to
get rid of that as it is no longer useful and may get in the way. e.g. if you
had /home/service/mox with a "service" user, that service user can no longer
access any files: only mox and root can.
this also adds scripts for building mox docker images for alpine-supported
platforms.
the "restart" subcommand has been removed. it wasn't all that useful and got in
the way.
and another change: when adding a domain while mtasts isn't enabled, don't add
the per-domain mtasts config, as it would cause failure to add the domain.
based on report from setting up mox on openbsd from mteege.
and based on issue #3. thanks for the feedback!
2023-02-27 14:19:55 +03:00
|
|
|
docker-compose -f docker-compose-imaptest.yml run --entrypoint /usr/local/bin/imaptest imaptest host=mox port=1143 user=mjl@mox.example pass=testtest mbox=imaptest.mbox
|
|
|
|
docker-compose -f docker-compose-imaptest.yml down
|
2023-01-30 16:27:06 +03:00
|
|
|
|
2023-06-04 21:38:10 +03:00
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
fmt:
|
|
|
|
go fmt ./...
|
|
|
|
gofmt -w -s *.go */*.go
|
|
|
|
|
|
|
|
jswatch:
|
|
|
|
inotifywait -m -e close_write http/admin.html http/account.html | xargs -n2 sh -c 'echo changed; ./checkhtmljs http/admin.html http/account.html'
|
|
|
|
|
|
|
|
jsinstall:
|
|
|
|
-mkdir -p node_modules/.bin
|
|
|
|
npm install jshint@2.13.2
|
|
|
|
|
|
|
|
docker:
|
change mox to start as root, bind to network sockets, then drop to regular unprivileged mox user
makes it easier to run on bsd's, where you cannot (easily?) let non-root users
bind to ports <1024. starting as root also paves the way for future improvements
with privilege separation.
unfortunately, this requires changes to how you start mox. though mox will help
by automatically fix up dir/file permissions/ownership.
if you start mox from the systemd unit file, you should update it so it starts
as root and adds a few additional capabilities:
# first update the mox binary, then, as root:
./mox config printservice >mox.service
systemctl daemon-reload
systemctl restart mox
journalctl -f -u mox &
# you should see mox start up, with messages about fixing permissions on dirs/files.
if you used the recommended config/ and data/ directory, in a directory just for
mox, and with the mox user called "mox", this should be enough.
if you don't want mox to modify dir/file permissions, set "NoFixPermissions:
true" in mox.conf.
if you named the mox user something else than mox, e.g. "_mox", add "User: _mox"
to mox.conf.
if you created a shared service user as originally suggested, you may want to
get rid of that as it is no longer useful and may get in the way. e.g. if you
had /home/service/mox with a "service" user, that service user can no longer
access any files: only mox and root can.
this also adds scripts for building mox docker images for alpine-supported
platforms.
the "restart" subcommand has been removed. it wasn't all that useful and got in
the way.
and another change: when adding a domain while mtasts isn't enabled, don't add
the per-domain mtasts config, as it would cause failure to add the domain.
based on report from setting up mox on openbsd from mteege.
and based on issue #3. thanks for the feedback!
2023-02-27 14:19:55 +03:00
|
|
|
docker build -t mox:dev .
|
|
|
|
|
|
|
|
docker-release:
|
|
|
|
./docker-release.sh
|