-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows #13
Comments
There are two stoppers for Windows:
What would you suggest to use on Windows instead of these Unix commands? The My thoughts are that probably we need either Cygwin or native Powershell + SMTP delivery configuration. |
And the third stopper is logs. We send them to stderr and they're picked with systemd. Not sure if that will work with Windows, probably we need to direct them to the Event Log. |
Hm, okay. Seems like the shell checks could be done somewhat like this: package main
import(
"fmt"
"os/exec"
)
func main(){
c := exec.Command("cmd", "/C", "del", "D:\\a.txt")
if err := c.Run(); err != nil {
fmt.Println("Error: ", err)
}
} (From here: http://stackoverflow.com/a/13013520/700471) So you could check for a Windows OS and use On the mailings, there's a number of ways of doing that from the command-line on Windows, as you say involving PowerShell in some cases other 3rd-party tools. I'd be tempted to pull in gophermail or some similar Go package to just hit the server directly. This would be reasonable, right? For logs, there's NSSM which allows you to set up any binary as a service on Windows, and handles redirecting stdout and stderr to log files, including log rotation. Not sure if that fits the bill for you or not. |
|
As for gophermail. It seems like the standard library is OK for our needs. |
I'm not sure what we should do with the environment variables configuration on Windows. That is: it's common for Unix systems to set up env. variables for a daemon, but I don't know if that's common on Windows. Or on Windows the way to go is to create a |
What makes you want to avoid gophermail? If I were going to write the code, I'd definitely rather use that than the std lib. I'm mostly OSX and Linux. My recent experience with Windows has been compiling binaries in Go and then using NSSM to turn them into a service. (Apparently it is hellish to add all of the hooks that are needed on a program to make it into a legitimate windows service, so NSSM shortcuts that for you.) NSSM lets you specify arguments and environment variables, but I don't know the true "Windows way". |
Yes, logging is pretty trivial. What benefits does gophermail provide over the stdlib? |
Sorry, I think I was thinking of gomail but, in any case, it's just API differences. Would you rather do this-ish with gomail: m := gomail.NewMessage()
m.SetHeader("From", "alex@example.com")
m.SetHeader("To", "bob@example.com", "cora@example.com")
m.SetAddressHeader("Cc", "dan@example.com", "Dan")
m.SetHeader("Subject", "Hello!")
m.SetBody("text/html", "Hello <b>Bob</b> and <i>Cora</i>!")
m.Attach("/home/Alex/lolcat.jpg")
d := gomail.NewDialer("smtp.example.com", 587, "user", "123456")
// Send the email to Bob, Cora and Dan.
if err := d.DialAndSend(m); err != nil {
panic(err)
} Or this-ish with stdlib: func send(body string) {
from := "...@gmail.com"
pass := "..."
to := "foobarbazz@mailinator.com"
msg := "From: " + from + "\n" +
"To: " + to + "\n" +
"Subject: Hello there\n\n" +
body
err := smtp.SendMail("smtp.gmail.com:587",
smtp.PlainAuth("", from, pass, "smtp.gmail.com"),
from, []string{to}, []byte(msg))
if err != nil {
log.Printf("smtp error: %s", err)
return
}
} Honestly, now that I look at it, stdlib is probably fine because we don't exactly need HTML bodies, attachments and these sorts of things. |
One note is that if you email within Go it is more flexible (you don't need a local postfix install, you can use whatever mail server is available) but you also need to take auth into account in terms of configuration. Username & pass, PlainAuth or potentially something else. I have an implementation of LoginAuth (such as for an Exchange server) which I can contribute. I feel like this might overall increase the complexity of the default configuration, but not sure of a better way to make it work on Windows without requiring the implementor to write a custom notification plugin. |
Now the only thing left is the actual SMTP code. I did some experiments and would like to stick with the env. variables as for configuration. If you want to contribute the SMTP code, I will review it. Or will write it myself, but that's not going to be very fast. |
Great progress! Agreed on the env. variables. I will try to write the SMTP code today or tomorrow. To be clear, this will become the default for mail-sending from jsonmon, correct? We can probably provide a sample |
I would like not to break old configurations. But if the default will be sending to Leaving the We should also default the sender to user.Username (without domain) to keep the maximum compatibility (CLI invocation does this automatically). And I think that's it. |
I have a question (I don't use Windows myself). |
recently tested myself and found one more problem with Windows (besides SMTP), it affects non-English language packs. let's take both Event Log and terminal output look like: also it seems like Event Log needs more work (like proper event IDs or multiline handling). |
This seems like pretty much exactly what I need: highly configurable, super-lightweight alerting system written in Go.
Do you know how much effort it would take to get this thing working on Windows?
The text was updated successfully, but these errors were encountered: