I pretend to do stuff with Linux.
@Pete-S said in I need this script to email the log it generates:
OK, I understand. Thanks.
Also, I wasn't trying to be abrasive. I kind of worded that strongly. I just don't like Bash much. I find it annoying, so I'd rather use something else unless it's a really simple thing.
@Pete-S said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
@Pete-S said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
@JaredBusch said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
Another plus for an API is that snmp is commonly blocked from providers and only enabled with some kind of request.
Also if you want to integrate any other notification (text, telegram notification, slack, etc) it would be trivial to add with this approach.
Not saying API is the best way, but it definitely has advantages.
I have not had time to look at what you posted yet but I plan on it thank you
Yeah no problem. It's really simple so it could be optimized quite a bit with maybe like 30 mins of work.
Wouldn't just using
curldo the job equally well of sending the message to mailgun?Yep. If you really like handling errors and responses in shell scripting it's fine. Unless you use it on Windows where cURL is not really cURL.
I'm not doing raw API calls with the example above. That's using their Go package which simplifies a lot of the API information.
OK, I understand. Thanks.
How is it with the maintenance with APIs like this? I mean when you compile something and have to support it over time, it's just like being a package maintainer. If they change the API or their Go package or perhaps OS or Go version, you'd have to recompile and redistribute it to every machine. Or is this something that would only happen very seldom like every two years or something like that?
I haven't seen it happen much where they would break the API often. If they were to do a big API change like that you'd likely have a good bit of notice. The packages for Go are versioned in the modules, so you can pin them to limit changes.
Looks like Mailgun is currently on /v3 of their API but some endpoints still use /v1 or /v2. The package would handle that for you since it's maintained by them.
One more advantage specifically with Go, is that you can containerize this easily. This could be done in a scratch container which has 0 dependencies. Then you could just run this with Docker/podman/whatever and easily keep the container up to date across all of your systems. I'm sure Jared wouldn't be doing that here, just a side note.
@Pete-S said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
@JaredBusch said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
Another plus for an API is that snmp is commonly blocked from providers and only enabled with some kind of request.
Also if you want to integrate any other notification (text, telegram notification, slack, etc) it would be trivial to add with this approach.
Not saying API is the best way, but it definitely has advantages.
I have not had time to look at what you posted yet but I plan on it thank you
Yeah no problem. It's really simple so it could be optimized quite a bit with maybe like 30 mins of work.
Wouldn't just using
curldo the job equally well of sending the message to mailgun?
Yep. If you really like handling errors and responses in shell scripting it's fine. Unless you use it on Windows where cURL is not really cURL.
I'm not doing raw API calls with the example above. That's using their Go package which simplifies a lot of the API information.
@JaredBusch said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
Another plus for an API is that snmp is commonly blocked from providers and only enabled with some kind of request.
Also if you want to integrate any other notification (text, telegram notification, slack, etc) it would be trivial to add with this approach.
Not saying API is the best way, but it definitely has advantages.
I have not had time to look at what you posted yet but I plan on it thank you
Yeah no problem. It's really simple so it could be optimized quite a bit with maybe like 30 mins of work.
Another plus for an API is that snmp is commonly blocked from providers and only enabled with some kind of request.
Also if you want to integrate any other notification (text, telegram notification, slack, etc) it would be trivial to add with this approach.
Not saying API is the best way, but it definitely has advantages.
@Pete-S said in I need this script to email the log it generates:
@stacksofplates said in I need this script to email the log it generates:
you could use mailgun. I just wrote this tiny app that will send the contents of a file.
I lazily take the first argument as the file with the contents you want to send. Just have env vars for the recipient address, your api key and domain (or hard code them). You could take flags and whatever, but this was free and I'm lazy.
There is one problem with the api approach I think.
I believe tht if you use postfix to deliver the message over SMTP it will put the message in postfix' queue. So if for some reason the mail can't be delivered at that particular time, for instance because the firewall is being rebooted or there is a problem with the mailservice, it will try again later. Using the API you will just a timeout error and that was it.I'm not a mailgun user but I assume they have a SMTP relay as well?
In any case since we like zoho, I intend to try the new Zoho TransMail service. They only send transactional mail, not marketing, and I think it was $2.5 or something like that per 10K emails. They have both api and SMTP.
That's no different than postfix. It would be pretty trivial to add a retry block for a timeout condition. Postfix has it built in, you'd need the 5 lines of code here or whatever would be needed. And this will work on literally any system that the binary can be compiled for:
you could use mailgun. I just wrote this tiny app that will send the contents of a file.
package main
import (
"context"
"fmt"
"github.com/mailgun/mailgun-go/v3"
"io/ioutil"
"os"
"time"
)
func main() {
mg := mailgun.NewMailgun(os.Getenv("DOMAIN"), os.Getenv("API_KEY"))
data, err := ioutil.ReadFile(os.Args[1])
if err != nil {
fmt.Println(err)
}
m := mg.NewMessage(
"[email protected]",
"Test Log",
string(data),
os.Getenv("SEND_ADDRESS"),
)
ctx, cancel := context.WithTimeout(context.Background(), time.Second*10)
defer cancel()
_, id, err := mg.Send(ctx, m)
if err != nil {
fmt.Println(err)
}
fmt.Println(id)
}
I lazily take the first argument as the file with the contents you want to send. Just have env vars for the recipient address, your api key and domain (or hard code them). You could take flags and whatever, but this was free and I'm lazy.
@marcinozga said in YAML terminology and Ansible:
And why would you care about terminology? Do you intend on teaching Ansible? It's the end result that matters, whether your playbook or role does what you want it to do, not whether you know the terminology or not. I've been using Ansible for some years, and honestly this is the first time I run into someone mentioning "dictionary".
I've been using it since around 1.8 and I'm not sure how you haven't heard the term dictionary.
They reference it in the YAML basics of their docs: https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
Prometheus works well. It has a lot of exporters for different types of data. Grafana has a lot of prebuilt dashboards for common metrics also.
@Pete-S said in Obtaining hardware from terminated remote employee:
@stacksofplates said in Obtaining hardware from terminated remote employee:
@Pete-S said in Obtaining hardware from terminated remote employee:
@StorageNinja said in Obtaining hardware from terminated remote employee:
@JaredBusch said in Obtaining hardware from terminated remote employee:
Hardware is not worth the fucking time to get back.
If the company thinks wasting man hours on that is a good idea the company is insane
While I largely agree, our R&D laptops are ~2-3K a pop. (fully max spec' MPB or XPS with onsite repair agreements).
I did hear we have started on the Mac's using DEP, so the device will auto-enroll in MDM even if the device is wiped.
https://support.apple.com/en-us/HT204142Makes no sense developing on a laptop IMHO - unless you're talking about another kind of R&D in another field.
On our team we remote into development servers and all development and testing is run there. Which means the computer you're actually sitting in front of just needs to be able to run a browser, rdp, ssh etc. So any machine suitable for general office work would get the job done. So no 2-3K laptops needed for development, even if that is not the primary reason. I kind of assumed everyone worked that way but haven't actually given it much thought until now.
I haven't really seen anyone do this other than CAD work. Everywhere I've been it's local development, possibly using Eclipse Che or Coder or something for a remote IDE but still local.
VSCode and JetBrains tools allow you to include your development environment in a container. So when you open the project it will open inside of a container with all of the dependencies included. That's the best workflow ive seen so far.
I believe you and find it very interesting. Wov. If that's how most people work, I'm just blown away. I assumed everyone was remote and had full on development and test environments at their disposal.
They usually do have full dev/test environments but it's all containerized. So it's trivial to run that locally. Then when you are satisfied with local results push to your branch and have it auto build/deploy against the actual dev/test environments with something like Flux/Argo. This is still remote, GitOps is all about remote workflows.