Development setup

[bunyevacz]

@andris9

This is not a bugreport, rather a request for some info about your development setup. So feel free to close it, and sorry for spaming the issue list. (dunno where is appropriate to ask you questions:)

So I would like to dive a bit deeper into wildduck sourcecode and I do not know what is your setup when you are developping and playing around.

What I use right now is I have a production system in a kvm machine. It was created with the setup scripts, and I update it as I document in the wiki.

When I modify/fix/play around something I do it in the production server via ssh and vim. And I play around during late night and weekend (even for the dns bug, which was a real roadblocker for me/us). And when I update, git tells me what I modified, and I delete my modification and update to git.

But I would like to develop somehow the attachment forwarding feature. And at home on my laptop I can not create a smtp server with public fix ip address to test it out (maybe I shouldn't create anyway). I don't know what do you use for mongodb look around.

So would you mind to describe what is your development setup, and how you write code? Do you have a testlab set up, and somehow CD (continous delivery) to it? I know you are on macbook (from a screenshot). I'm on linux laptop and I use atom to view sourcecode, and I use vim on commandline.

[andris9]

I do most of the development in localhost. I use wildduck.email server as the test server, I push changes to it using git push (this is why the setup script sets up all components as git repositories and also creates the update hook scripts).

You should be able to run WildDuck in any VPS provider (I usually use Ubuntu 16 from OVH as it is fairly cheap), then run the setup script. Once everything is set up copy your ssh key to /home/deploy/.ssh/authorized_keys and then in your local machine where you have wildduck git repository add the dev server as an additional remote repo (you can find all the repo paths from the $MAILDOMAIN-nameserver.txt file)

$ git clone [email protected]:nodemailer/wildduck.git
$ cd wildduck
$ git remote add dev [email protected]:/var/opt/wildduck.git

(obviously change example.com to your actual VPS domain name)

Next make your changes, then commit and push

$ git add .
$ git commit -m "some changes"
$ git push dev master

The last line pushes your commited changes to the test server where the update hook runs that checks out repo files to the application folder and restarts wildduck service, so in few seconds the server should run your latest code.

Exactly the same setup applies to wildduck-webmail, haraka-plugin-wildduck etc. You need to have the original repo (or your fork) cloned from Github, then add development server as an additional remote and the push code changes to it with git push

[bunyevacz]

and how do you test your code on localhost? Ie. how you fake some email events (email sending) without actually sending email?

[andris9]

If you want to receive new emails, then the easiest way would be to send one from console using this script. Replace wildduck.email and port 25 with your localhost settings (eg. host:localhost port:2525). The script then connects to your test MX server and tries to send an email to it.

If you want to send and receive emails locally from wildduck-webmail interface, then use "localtest.me" as your address domain and make sure that your local test MX is listening on port 25. "localtest.me" resolves to 127.0.0.1, so your emails should be delivered to 127.0.0.1:25

[LoganHeinzelman]

I just get permission errors when i try what you suggested @andris9

[bhanuc]

I just get permission errors when i try what you suggested @andris9

You must be trying to run the mx port on 25, listening on anything below 1000 requires sudo in linux. Also, if anyone else is trying this out- the updated localport is 2424 (Also visible in the init logs)

Also in the test script - I had to add
lmtp: true to the nodemailer createtransport config as well to get the local script working.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 15 days with no activity.