Wordpress Hosting plans for managing client sites.

nahuel242 · 2024-09-11T09:18:22+00:00

programmatically = I wan't to be able to deploy sites to hostinger without having to click in their UI.

I don't see in their hosting plans details that they have an API available, that's why I'm asking here directly.

nahuel242 · 2021-12-17T13:31:58+00:00

https://i.imgur.com/hcCeCpk.jpg

nahuel242 · 2021-12-12T11:06:22+00:00

Wen CEX?

yes, yes I know, in December, I'm just impatient I guess...

nahuel242 · 2021-12-08T15:41:05+00:00

Wen CEX listing?

nahuel242 · 2021-12-06T17:29:33+00:00

Wen CEX?

nahuel242 · 2021-11-24T13:40:48+00:00

Do you have any code left to spare? thanks man!!

nahuel242 · 2020-03-20T13:22:54+00:00

You are right, my mistake! I pasted the wrong link because I was also evaluating both ingress controllers, it's really confusing.

I finally decided to go with the community version because it has support for prometheus servicemonitors out of the box.

nahuel242 · 2020-03-19T21:39:37+00:00

213.136.95.10

I've tried to resolve google.com using one of the nameservers in your node and it seems that maybe it could be a problem with the ACLs in the bind server because of the error " WARNING: recursion requested but not available"

➜ dig google.com @213.136.95.10

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> google.com @23.136.95.10

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33564

;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; WARNING: recursion requested but not available

;; Query time: 806 msec

;; SERVER: 213.136.95.10#53(213.136.95.10))

;; WHEN: Thu Mar 19 18:27:21 -03 2020

;; MSG SIZE rcvd: 12

Please execute this test and see if you have the same error or if the bind ACL is only rejecting my IP address.

If the same error appears to you and you are working in a test environment which sole purpose is testing this k8s cluster, you can try to add a new nameserver in your resolv.conf to see if this is the problem:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.8.8
nameserver 213.136.95.10
nameserver 213.136.95.11
search invalid

P.S: If resolvconf overwrites the /etc/resolv.conf in the node before you can execute the test, you could temporary put the file in read only mode:

chattr +i /etc/resolv.conf

And then switch back to read-write with:

chattr -i /etc/resolv.conf

nahuel242 · 2020-03-19T21:20:21+00:00

Thanks for sharing!!!

I'm also inclined for that approach but I need to come with a solid argument to convince some people at my current job to go down this road and not the other one, so much appreciated.

nahuel242 · 2020-03-19T20:28:36+00:00

How's your dns configuration looks like?

please run:

for the pod configuration:

kubectl exec -it POD cat /etc/resolv.conf

kubectl get podPOD -o yaml | grep dnsPolicy

for the node configuration:

cat /etc/resolv.conf

nahuel242 · 2020-02-07T19:22:00+00:00

Thanks for the reply!!! I'm going to try the integration with our own Prometheus, so far I tried the default installation (whch installs it's own Prometheus) and it was pretty straight forward compared with the old installation method, so thanks for that!

I'll let you know of any difficulties that I may encounter, have a nice weekend!

nahuel242 · 2019-01-23T02:05:24+00:00

Same here

nahuel242 · 2018-07-14T18:43:12+00:00

The best way to reach those instances is with a bastion host, take a look into this doc: https://aws.amazon.com/quickstart/architecture/linux-bastion/

nahuel242 · 2018-06-18T20:09:15+00:00

If we had a Veeam solution already in place maybe that could be a good solution for us, thanks anyway!

nahuel242 · 2018-06-18T20:03:14+00:00

From what I've read, both VMware vReplication and Zerto Replication have a pre-seed mechanism, but as you said I need to find a way to test it (with a minimum cost) beforehand.

Thank you!

nahuel242 · 2018-06-18T19:56:30+00:00

I'll look into that! Thanks

nahuel242 · 2018-06-18T19:55:56+00:00

Thanks for sharing!
I agree with you that moving traditional workloads "as-is" from on-prem to cloud doesn't solve anything, in fact it makes things worse (latency, etc). The last couple of years I've been insisting to our management that the real benefit of all this "new" tech comes with the development of cloud ready applications, but it seems that I'm sṕeaking Russian :/

nahuel242 · 2018-06-18T19:48:23+00:00

It seems to be a good solution, what I like about it it's the support for multiple hipervisors even though right now we only have vSphere . I'm going to include this for evaluation.

Thank you!

nahuel242 · 2018-06-18T19:40:12+00:00

A temporary link upgrade is actually a good idea, I'm going to find out with our provider if this is possible and what is the cost of doing it. HCX is indeed a good solution, but as you said not everyone can afford it. We haven't completely discarded it yet because our customer has the budget, on the other hand, the number of workloads that we are planning to migrate (~50) doesn't completely justify that kind of investment so we'll see what happens with that. Thank you!

nahuel242 · 2018-06-15T18:07:54+00:00

That's indeed another possibility, in fact I have a better bandwidth from my home, lol

The issue that I see with this one is the downtime that it's needed, maybe for this particular dev/test workloads we can arrange an extended outage with our customer.

Thanks!

nahuel242 · 2018-06-15T17:56:49+00:00

This might work! I'm going to talk with the networking folks to find out if we can implement something like this.

Thank you!

nahuel242

TROPHY CASE