Fiware error: Access-Control-Allow-Origin - fiware

I'm making a call to the contextBroker and it gives me this error.
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access. The response had HTTP status code 405.
From postman or from freeboard I do not get any of this.
getContextBroker(){
console.log("Consumimos el servicio getContextBroker");
let headers = new Headers ({'Accept': 'application/json', 'Fiware-Service': 'x', 'Fiware-ServicePath': '/x', 'Access-Control-Allow-Origin': '*'});
let options = new RequestOptions ({headers : headers});
return this._http.get(this.urlcontextBrokers, {headers : headers}).map(res => res.json());
}
}
how can I solve that?
I've tried adding: 'Access-Control-Allow-Origin': '*'
But it still does not work
EDIT:
ps ax | grep contextBroker:
862 pts/4 S+ 0:00 grep contextBroker
3792 ? Ssl 27:35 /usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/run/contextBroker/contextBroker.pid -dbhost localhost -db orion -multiservice -logAppend
version:
{
"orion": {
"version": "1.7.0",
"uptime": "12 d, 18 h, 24 m, 20 s",
"git_hash": "e544780eb64a4a2557c1f51dde070b8d82b86c49",
"compile_time": "Wed Feb 8 13:30:24 CET 2017",
"compiled_by": "fermin",
"compiled_in": "centollo"
}
}
EDIT02
Hello, as I said, I do not want to use the cors, I have eliminated that from the header in such a way:
   getContextBroker () {
     console.log ("We consume the getContextBroker service");
     let headers = new Headers ({'Accept': 'application / json', 'Fiware-Service': 'IoFAlmeria', 'Fiware-ServicePath': '/ ARMpalmerillas'});
     let options = new RequestOptions ({headers: headers});
     return this._http.get (this.urlcontextBrokers, {headers: headers}). map (res => res.json ());
   }
}
and I keep giving the same error:
OPTIONS http: // XXX: 1026 / v2 / entities / 405 (Method Not Allowed)
Failed to load http: // XXX: 1026 / v2 / entities /: Response to preflight request does not pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http: // localhost: 4200' is therefore not allowed access. The response had HTTP status code 405.
it has to be the problem of the fiware API since I have designed one with nodejs and I have no problem changing the URL
Update:
Limpiando repositorios:base epel extras fiware mongodb-org-3.2
: mysql-connectors-community mysql-tools-community
: mysql57-community nodesource updates
Limpiando todo
Cleaning up list of fastest mirrors
[root#UAL-IoF2020 ~]# yum install contextBroker
Complementos cargados:fastestmirror, refresh-packagekit, security
Configurando el proceso de instalación
Determining fastest mirrors
epel/metalink | 25 kB 00:00
* base: ftp.uma.es
* epel: ftp.uma.es
* extras: ftp.uma.es
* updates: ftp.uma.es
base | 3.7 kB 00:00
base/primary_db | 4.7 MB 00:00
epel | 4.7 kB 00:00
epel/primary_db | 6.0 MB 00:00
extras | 3.4 kB 00:00
extras/primary_db | 29 kB 00:00
fiware | 951 B 00:00
fiware/primary | 45 kB 00:00
mongodb-org-3.2 | 2.5 kB 00:00
mongodb-org-3.2/primary_db | 78 kB 00:00
mysql-connectors-community | 2.5 kB 00:00
mysql-connectors-community/primary_db | 18 kB 00:00
mysql-tools-community | 2.5 kB 00:00
mysql-tools-community/primary_db | 38 kB 00:00
mysql57-community | 2.5 kB 00:00
mysql57-community/primary_db | 139 kB 00:00
nodesource | 2.5 kB 00:00
nodesource/primary_db | 51 kB 00:00
updates | 3.4 kB 00:00
updates/primary_db | 6.4 MB 00:00
El paquete contextBroker-1.7.0-1.x86_64 ya se encuentra instalado con su versión más reciente
Nada para hacer

CORS requests are only supported by Orion Context Broker version 1.10 and above.
As #JoseManuelCantera has pointed out, you do not need to add any CORS specific headers to your request, those are handled by your client (browser, Postman etc.)
You need to:
Upgrade your version to 1.10
Start Orion in CORS mode
You can start Orion in CORS mode for any origin (Orion will accept CORS requests from any origin) as below:
contextBroker -corsOrigin __ALL
Please take a look at the CORS documentation for Orion for more information.
UPDATE
Please allow me to shortly explain CORS pre-flight logic. If your request is not a simple request, your browser will do a pre-flight request prior to yours with the OPTIONS method. If Orion is not started in CORS mode, you will always get method not allowed as a response to your non-simple requests.
So what is the problem, why are you getting different results with different clients? Postman (curl etc.) does exactly what you want it to do and sends the requests as you have configured. It does not check if the request you are sending should be pre-flighted or not.
On the other hand, your browser does check your request and do a pre-flight if necessary. You have no control over this other than modifying your request.
The Javascript framework you are working with is probably adding a header to the request rendering it a "non-simple" request. For example: X-Requested-With. Please see this question.
My suggestion is to take a look at the details of the request your browser sends (headers, methods etc.) and see what makes it a non-simple request. Then do the necessary changes on your js code to make sure your request falls within the scope of simple requests.
Having said that, you will need to upgrade your Orion version eventually since for example, a DELETE request is never going to be treated as a simple request when sent over a browser.

I think you need to upgrade to version 1.10 so that you can use CORS.
You do not need to add any header ;) and actually the Access-Control-Allow-Origing header is sent in the server response not by the client request

Related

Setup Quart server with HTTP/2

I am trying to setup a Quart server to play with HTTP/2. I have been trying to go through the minimal documentation at:
https://gitlab.com/pgjones/quart
Where I have:
$ cat app.py
from quart import Quart, render_template, websocket
app = Quart(__name__)
#app.route("/")
async def hello():
return await render_template("index.html")
#app.route("/api")
async def json():
return {"hello": "world"}
#app.websocket("/ws")
async def ws():
while True:
await websocket.send("hello")
await websocket.send_json({"hello": "world"})
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5001)
Some basic check:
$ curl -I --http2 http://acme.corp:5001
HTTP/1.1 101
date: Tue, 02 Mar 2021 10:05:12 GMT
server: hypercorn-h11
connection: upgrade
upgrade: h2c
HTTP/2 200
content-type: text/html; charset=utf-8
content-length: 0
date: Tue, 02 Mar 2021 10:05:12 GMT
server: hypercorn-h2
Looking at the output
$ python3 app.py
* Serving Quart app 'app'
* Environment: production
* Please use an ASGI server (e.g. Hypercorn) directly in production
* Debug mode: False
* Running on http://0.0.0.0:5001 (CTRL + C to quit)
[2021-03-02 11:01:49,083] Running on http://0.0.0.0:5001 (CTRL + C to quit)
[2021-03-02 11:01:53,011] 10.221.0.114:53637 GET / 1.1 200 0 5817
[2021-03-02 11:01:53,255] 10.221.0.114:53637 GET /favicon.ico 1.1 404 103 1348
Here is what I see, when I load the index.html page from chrome:
What am I missing to get http/2 from chrome ?
Locally you are upgrading an insecure HTTP 1.1 request to an insecure HTTP 2 request. This works with Quart and curl, but browsers including chrome do not support insecure (unencrypted) HTTP/2. For it to work in chrome I create a self signed certificate, passing the certfile and keyfile options to the run and accept the warning chrome offers when visiting the site. An example exists here.

Autoscaling Deployment with custom metrics on Openshift 1.5.0

Is there any possibility to autoscale deployment with Openshift Origin 1.5.0 (kubernetes 1.5.2) and use custom metrics for this purpose?
Kubernetes documentation states that autoscaling with custom metrics are being supported from version 1.2. It looks true, just because Openshift horizontal pod autoscaler (HPA) tries to gain some metrics and calculate desired metrics. But my configuration fails to succeed to perform this. Guys, please help me with finding what I am doing wrong with this.
So, what happens:
I have set up a metrics as it is recommended in Origin latest docs (all steps are passed): https://docs.openshift.org/latest/install_config/cluster_metrics.html;
I have an app, which is being deployed with Deployment kind object;
this app exposes custom metrics with http json endpoint;
custom metrics are being collected and stored - this is shown in Openshift origin UI in Metrics tab of corresponding pod;
after I create HPA - some warning about collecting custom metrics appear, it writes something like 'Failed collecting custom metrics, did not recieve metrics for any ready pods';
I create HPA with API version 1 and include an annotation alpha/target.custom-metrics.podautoscaler.kubernetes.io: '{"items":[{"name":"requests_count", "value": "10"}]}';
if I request a deployed heapster app through master-proxy, I receive something like this
{
"metadata": {},
"items": [
{
"metadata": {
"name": "resty-1722683747-kmbw0",
"namespace": "availability-demo",
"creationTimestamp": "2017-05-24T09:50:24Z"
},
"timestamp": "2017-05-24T09:50:00Z",
"window": "1m0s",
"containers": [
{
"name": "resty",
"usage": {
"cpu": "0",
"memory": "2372Ki"
}
}
]
}
]
}
as you can see, there is really no custom metrics, and my custom metrics is named requests_count.
What steps should I take to succeed in implementing custom metrics autoscaling?
Screenshot with custom metrics being collected and exposed via Openshift Console UI
UPDATE:
In openshift master log warning looks like this:
I0524 10:17:47.537985 1 panics.go:76GET /apis/extensions/v1beta1/namespaces/availability-demo/deployments/resty/scale: (3.379724ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.543354 1 panics.go:76] GET /api/v1/proxy/namespaces/openshift-infra/services/https:heapster:/apis/metrics/v1alpha1/namespaces/availability-demo/pods?labelSelector=app%3Dresty: (4.830135ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.553255 1 panics.go:76] GET /api/v1/namespaces/availability-demo/pods?labelSelector=app%3Dresty: (8.864864ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.559909 1 panics.go:76] GET /api/v1/namespaces/availability-demo/pods?labelSelector=app%3Dresty: (5.725342ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.560977 1 panics.go:76] PATCH /api/v1/namespaces/availability-demo/events/resty.14c14bbf8b89534c: (6.385846ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.565418 1 panics.go:76] GET /api/v1/proxy/namespaces/openshift-infra/services/https:heapster:/api/v1/model/namespaces/availability-demo/pod-list/resty-1722683747-kmbw0/metrics/custom/requests_count?start=2017-05-24T10%3A12%3A47Z: (5.015336ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.569843 1 panics.go:76] GET /api/v1/namespaces/availability-demo/pods?labelSelector=app%3Dresty: (4.040029ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.575530 1 panics.go:76] PUT /apis/autoscaling/v1/namespaces/availability-demo/horizontalpodautoscalers/resty/status: (4.894835ms) 200 [[openshift/v1.5.2+43a9be4 (linux/amd64) kubernetes/43a9be4 system:serviceaccount:openshift-infra:hpa-controller] 10.105.8.81:33945]
I0524 10:17:47.575856 1 horizontal.go:438] Successfully updated status for resty
W0524 10:17:47.575890 1 horizontal.go:104] Failed to reconcile resty: failed to compute desired number of replicas based on Custom Metrics for Deployment/availability-demo/resty: failed to get custom metric value: did not recieve metrics for any ready pods
UPDATE: Found what request HPA issues to heapster through proxy to gather custom metrics. This requests always return empty metrics array:
GET /api/v1/proxy/namespaces/openshift-infra/services/https:heapster:/api/v1/model/namespaces/availability-demo/pod-list/availability-example-1694583826-55hqh/metrics/custom/requests_count?start=2017-05-25T13%3A14%3A24Z HTTP/1.1
Host: kubernetes-master:8443
Authorization: Bearer hpa-agent-token
And it returns
{"items":[{"metrics":[],"latestTimestamp":"0001-01-01T00:00:00Z"}]}
UPDATE: It turns out, that HPA requests heapster through proxy, and heapster - in its turn - request "summary" kubernetes api. Then the question is - why kubernetes "summary" api does not answer with metrics for above mentioned request, though the metrics exist?
Might be a wild guess but I had the issue myself on a self made cluster, the 2 things I ran into were token issues where certificate of my HA master setup was not set-up correctly and another issue was regarding my kubedns. Not sure if this is applicable for openshitf.

DKIM hmailserver and NameCheap Setup

I've been trying to setup my hmailserver with DKIM.
I was following this guide -> https://www.hmailserver.com/forum/viewtopic.php?t=29402
And I created my keys with this site -> https://www.port25.com/dkim-wizard/
Domain name: linnabary.us
DomainKey Selector: dkim
Key size: 1024
I created a pem file;
-----BEGIN RSA PRIVATE KEY-----
<key>
-----END RSA PRIVATE KEY-----
Saved it and loaded it into hmailserver
When I set this up on NameCheap I selected TXT Record, set my host as #, and put this line in, minus key of course;
v=DKIM1; k=rsa; p=<KEY>
Now when I test with -> http://www.isnotspam.com
It says my DKIM key is as follows;
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result: invalid
ID(s) verified: header.From=admin#linnabary.us
Selector=
domain=
DomainKeys DNS Record=._domainkey.
I was wondering if I am making any obvious errors in my record.
Edit;
The email contains the following line;
dkim-signature: v=1; a=rsa-sha256; d=linnabary.us; s=dkim;
This is what the setup looks like on NameCheap;
And here is the next test email from ;
This message is an automatic response from isNOTspam's authentication verifier service. The service allows email senders to perform a simple check of various sender authentication mechanisms. It is provided free of charge, in the hope that it is useful to the email community. While it is not officially supported, we welcome any feedback you may have at .
Thank you for using isNOTspam.
The isNOTspam team
==========================================================
Summary of Results
==========================================================
SPF Check : pass
Sender-ID Check : pass
DKIM Check : invalid
SpamAssassin Check : ham (non-spam)
==========================================================
Details:
==========================================================
HELO hostname: [69.61.241.46]
Source IP: 69.61.241.46
mail-from: admin#linnabary.us
Anonymous To: ins-a64wsfm3#isnotspam.com
---------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result: pass
ID(s) verified: smtp.mail=admin#linnabary.us
DNS record(s):
linnabary.us. 1799 IN TXT "v=spf1 a mx ip4:69.61.241.46 ~all"
----------------------------------------------------------
Sender-ID check details:
----------------------------------------------------------
Result: pass
ID(s) verified: smtp.mail=admin#linnabary.us
DNS record(s):
linnabary.us. 1799 IN TXT "v=spf1 a mx ip4:69.61.241.46 ~all"
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result: invalid
ID(s) verified: header.From=admin#linnabary.us
Selector=
domain=
DomainKeys DNS Record=._domainkey.
----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin 3.4.1 (2015-04-28)
Result: ham (non-spam) (04.6points, 10.0 required)
pts rule name description
---- ---------------------- -------------------------------
* 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
* [score: 1.0000]
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
* 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Spam-Status: Yes, hits=4.6 required=-20.0 tests=BAYES_99,BAYES_999,
DKIM_SIGNED,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,T_DKIM_INVALID autolearn=no
autolearn_force=no version=3.4.0
X-Spam-Score: 4.6
To learn more about the terms used in the SpamAssassin report, please search
here: http://wiki.apache.org/spamassassin/
==========================================================
Explanation of the possible results (adapted from
draft-kucherawy-sender-auth-header-04.txt):
==========================================================
"pass"
the message passed the authentication test.
"fail"
the message failed the authentication test.
"softfail"
the message failed the authentication test, and the authentication
method has either an explicit or implicit policy which doesn't require
successful authentication of all messages from that domain.
"neutral"
the authentication method completed without errors, but was unable
to reach either a positive or a negative result about the message.
"temperror"
a temporary (recoverable) error occurred attempting to authenticate
the sender; either the process couldn't be completed locally, or
there was a temporary failure retrieving data required for the
authentication. A later retry may produce a more final result.
"permerror"
a permanent (unrecoverable) error occurred attempting to
authenticate the sender; either the process couldn't be completed
locally, or there was a permanent failure retrieving data required
for the authentication.
==========================================================
Original Email
==========================================================
From admin#linnabary.us Wed Apr 12 17:41:22 2017
Return-path: <admin#linnabary.us>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on isnotspam.com
X-Spam-Flag: YES
X-Spam-Level: ****
X-Spam-Report:
* 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
* [score: 1.0000]
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
* 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Spam-Status: Yes, hits=4.6 required=-20.0 tests=BAYES_99,BAYES_999,
DKIM_SIGNED,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,T_DKIM_INVALID autolearn=no
autolearn_force=no version=3.4.0
Envelope-to: ins-a64wsfm3#isnotspam.com
Delivery-date: Wed, 12 Apr 2017 17:41:22 +0000
Received: from [69.61.241.46] (helo=linnabary.us)
by localhost.localdomain with esmtp (Exim 4.84_2)
(envelope-from <admin#linnabary.us>)
id 1cyMGg-0007x2-1Q
for ins-a64wsfm3#isnotspam.com; Wed, 12 Apr 2017 17:41:22 +0000
dkim-signature: v=1; a=rsa-sha256; d=linnabary.us; s=dkim;
c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=Ns4aRUgWUtil4fiVnvitgeV+q1K/smEYtRGN497S5Ew=;
b=Nc2Kzrzas0QqMpWM4fnF5o5wLWlWYFxlGlAipe+85H9cwGgc4hvEKUj1UvgB6I2VHUbJ0OGN/sJO9tjWgwlGypaUuW7Q8x/iI0UtC6cn7X6ZLHT+K6A2A6MdoyR1NF4xxvqPadcmcQwnrY0Tth4ycydpQMlBCZS30sc1qUjUrN0=
Received: from [192.168.1.12] (Aurora [192.168.1.12])
by linnabary.us with ESMTPA
; Wed, 12 Apr 2017 13:41:28 -0400
To: ins-a64wsfm3#isnotspam.com
From: Admin <admin#linnabary.us>
Subject: Welcome to Linnabary
Message-ID: <8e8be6cd-6354-aeb9-b577-2b0efc25a1a1#linnabary.us>
Date: Wed, 12 Apr 2017 13:41:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-DKIM-Status: invalid (pubkey_unavailable)
I honestly have no idea what I should put in here in order to protect
myself from filters, so I'm just making it up as I go.
- Tad
The Host value for your TXT entry should just be dkim._domainkey. Currently your domain key is located at: dkim._domainkey.linnabary.us.linnabary.us, so you're not supposed to add the domain here.
That's why the response to the test email says X-DKIM-Status: invalid (pubkey_unavailable) - the public key can't be found where it is supposed to be.

Upgrading K8S cluster from v1.2.0 to v1.3.0

I have 1 master and 4 minions all running on version 1.2.0. I am planning to upgrade them to 1.3.0. I want this done with minimal downtime.
So I did the following on one minion.
systemctl stop kubelet
yum update kubernetes-1.3.0-0.3.git86dc49a.el7
systemctl start kubelet
Once I bring up the service, i see the following ERROR.
Mar 28 20:36:55 csdp-e2e-kubernetes-minion-6 kubelet[9902]: E0328 20:36:55.215614 9902 kubelet.go:1222] Unable to register node "172.29.240.169" with API server: the body of the request was in an unknown format - accepted media types include: application/json, application/yaml
Mar 28 20:36:55 csdp-e2e-kubernetes-minion-6 kubelet[9902]: E0328 20:36:55.217612 9902 event.go:198] Server rejected event '&api.Event{TypeMeta:unversioned.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:api.ObjectMeta{Name:"172.29.240.169.14b01ded8fb2d07b", GenerateName:"", Namespace:"default", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:unversioned.Time{Time:time.Time{sec:0, nsec:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*unversioned.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]api.OwnerReference(nil), Finalizers:[]string(nil)}, InvolvedObject:api.ObjectReference{Kind:"Node", Namespace:"", Name:"172.29.240.169", UID:"172.29.240.169", APIVersion:"", ResourceVersion:"", FieldPath:""}, Reason:"NodeHasSufficientDisk", Message:"Node 172.29.240.169 status is now: NodeHasSufficientDisk", Source:api.EventSource{Component:"kubelet", Host:"172.29.240.169"}, FirstTimestamp:unversioned.Time{Time:time.Time{sec:63626321182, nsec:814949499, loc:(*time.Location)(0x4c8a780)}}, LastTimestamp:unversioned.Time{Time:time.Time{sec:63626330215, nsec:213372890, loc:(*time.Location)(0x4c8a780)}}, Count:1278, Type:"Normal"}': 'the body of the request was in an unknown format - accepted media types include: application/json, application/yaml' (will not retry!)
Mar 28 20:36:55 csdp-e2e-kubernetes-minion-6 kubelet[9902]: E0328 20:36:55.246100 9902 event.go:198] Server rejected event '&api.Event{TypeMeta:unversioned.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:api.ObjectMeta{Name:"172.29.240.169.14b01ded8fb2fc88", GenerateName:"", Namespace:"default", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:unversioned.Time{Time:time.Time{sec:0, nsec:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*unversioned.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]api.OwnerReference(nil), Finalizers:[]string(nil)}, InvolvedObject:api.ObjectReference{Kind:"Node", Namespace:"", Name:"172.29.240.169", UID:"172.29.240.169", APIVersion:"", ResourceVersion:"", FieldPath:""}, Reason:"NodeHasSufficientMemory", Message:"Node 172.29.240.169 status is now: NodeHasSufficientMemory", Source:api.EventSource{Component:"kubelet", Host:"172.29.240.169"}, FirstTimestamp:unversioned.Time{Time:time.Time{sec:63626321182, nsec:814960776, loc:(*time.Location)(0x4c8a780)}}, LastTimestamp:unversioned.Time{Time:time.Time{sec:63626330215, nsec:213381138, loc:(*time.Location)(0x4c8a780)}}, Count:1278, Type:"Normal"}': 'the body of the request was in an unknown format - accepted media types include: application/json, application/yaml' (will not retry!)
Is v1.2.0 incompatible with v1.3.0 ?
Seems like the issue is with JSON incompatibility ? application/json, application/yaml
From master standpoint ::
[root#kubernetes-master ~]# kubectl get nodes
NAME STATUS AGE
172.29.219.105 Ready 3h
172.29.240.146 Ready 3h
172.29.240.168 Ready 3h
172.29.240.169 NotReady 3h
The node that I upgraded is in NotReady state.
As per the documentation you must upgrade your master components (kube-scheduler, kube-apiserver and kube-controller-manager) before your node components (kubelet, kube-proxy).
https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/

Encrypting Nagios report mails with GnuPG fails with empty mails, why?

I am trying to crytp using gpg2 the mails sent by Nagios3. For that, I have create this custom command on /etc/nagios3/commands.cfg :
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
Some points:
The e-mail is sent but it is "empty":
Sep 19 14:35:25 tutu nagios3: Finished daemonizing... (New PID=4313)
Sep 19 14:36:15 tutu nagios3: SERVICE ALERT:
tete_vm;HTTP;OK;HARD;4;HTTP OK: HTTP/1.1 200 OK - 347 bytes in 0.441
second response time Sep 19 14:36:15 tutu nagios3: SERVICE
NOTIFICATION: tata;tete_vm;HTTP;OK;notify-service-by-email;HTTP OK:
HTTP/1.1 200 OK - 347 bytes in 0.441 second response time
The command:
/usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$</code>
works very well on command line
I have tested this command:
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com >> /tmp/toto.txt
The file /tmp/toto.txt is created but "empty".
So, it seems to be a problem using /usr/bin/gpg2 on this file, but I cannot find why!
The most common mistake when encrypting from within services using GnuPG is that the recipient's key was imported by another (system) user than the one the service is running under, for example imported by root, but the service runs as nagios.
GnuPG maintains per-user "GnuPG home directories" (usually ~/.gnupg) with per-user keyrings in them. If you imported as root, other service accounts don't know anything about the keys in there.
The first step for debugging the issue would be to redirect gpg's stderr to a file, so you can read the error message by adding 2>>/tmp/gpg-error.log to the GnuPG call:
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com 2>>/tmp/gpg-error.log | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
If the issue is something like "key not found" or similar, you've got two possibilities to resolve the issue:
Import to the service's user account. Switch to the service's user, and import the key again.
Hard-code the GnuPG home directory to somewhere else using the --homedir [directory] option, for example in a place you also store your Nagios plugins.
Be aware of using appropriate, restrictive permissions. GnuPG is very picky if other users than the owner are allowed to read the files!