openshift installation error on centos 7 - openshift

I have install the openshift in centos 7.
Installed the prerequisite and then installing the openshift via this command.
atomic-openshift-installer install
getting this error.. Please guide how to solve the same.
[WARNING]: Could not match supplied host pattern, ignoring: oo_lb_to_config
There was a problem fetching the required information. Please see /tmp/ansible.log for details.
tail -f /tmp/ansible.log
2018-07-21 12:36:47,139 p=23956 u=root | skipping: [10.142.0.2]
2018-07-21 12:36:47,160 p=23956 u=root | TASK [openshift_version : Set openshift_version for rpm installation] ************************************************************************************
2018-07-21 12:36:47,209 p=23956 u=root | included: /usr/share/ansible/openshift-ansible/roles/openshift_version/tasks/check_available_rpms.yml for 10.142.0.2
2018-07-21 12:36:47,233 p=23956 u=root | TASK [openshift_version : Get available origin version] **************************************************************************************************
2018-07-21 12:36:47,767 p=23956 u=root | fatal: [10.142.0.2]: FAILED! => {"changed": false, "module_stderr": "Shared connection to 10.142.0.2 closed.\r\n", "module_stdout": "Traceback (most recen
t call last):\r\n File \"/tmp/ansible_aWcbKG/ansible_module_repoquery.py\", line 642, in \r\n main()\r\n File \"/tmp/ansible_aWcbKG/ansible_module_repoquery.py\", line 632, in main\r\
n rval = Repoquery.run_ansible(module.params, module.check_mode)\r\n File \"/tmp/ansible_aWcbKG/ansible_module_repoquery.py\", line 588, in run_ansible\r\n results = repoquery.repoquery()\r
\n File \"/tmp/ansible_aWcbKG/ansible_module_repoquery.py\", line 547, in repoquery\r\n rval = self._repoquery_cmd(repoquery_cmd, True, 'raw')\r\n File \"/tmp/ansible_aWcbKG/ansible_module_re
poquery.py\", line 385, in _repoquery_cmd\r\n returncode, stdout, stderr = _run(cmds)\r\n File \"/tmp/ansible_aWcbKG/ansible_module_repoquery.py\", line 356, in _run\r\n stderr=subprocess.P
IPE)\r\n File \"/usr/lib64/python2.7/subprocess.py\", line 711, in init\r\n errread, errwrite)\r\n File \"/usr/lib64/python2.7/subprocess.py\", line 1327, in _execute_child\r\n raise c
hild_exception\r\nOSError: [Errno 2] No such file or directory\r\n", "msg": "MODULE FAILURE", "rc": 1}
2018-07-21 12:36:47,770 p=23956 u=root | PLAY RECAP ***********************************************************************************************************************************************
2018-07-21 12:36:47,770 p=23956 u=root | 10.142.0.2 : ok=24 changed=2 unreachable=0 failed=1
2018-07-21 12:36:47,770 p=23956 u=root | localhost : ok=12 changed=0 unreachable=0 failed=0
2018-07-21 12:36:47,770 p=23956 u=root | INSTALLER STATUS *****************************************************************************************************************************************

You can ignore this warning:
[WARNING]: Could not match supplied host pattern, ignoring: oo_lb_to_config
There was a problem fetching the required information. Please see
/tmp/ansible.log for details.
All this is saying is that you have not defined a load balancer (haproxy). So your DNS needs to point to the masters or your are installing an haproxy manually.
tail -f /tmp/ansible.log
2018-07-21 12:36:47,139 p=23956 u=root | skipping: [10.142.0.2] 2018-07-21 12:36:47,160 p=23956 u=root | TASK [openshift_version : Set openshift_version for rpm installation] ************************************************************************************
2018-07-21 12:36:47,209 p=23956 u=root | included: /usr/share/ansible/openshift-ansible/roles/openshift_version/tasks/check_available_rpms.yml for 10.142.0.2 2018-07-21 12:36:47,233 p=23956 u=root | TASK [openshift_version : Get available origin version] **************************************************************************************************
I had a similiar problem. It was due to an inconsistent setup of all of the nodes, having different versions of the rpms. But I have the feeling that this isn't going on here.
Try running the ansible-playbooks with the -vvvv option (the advanced install). This may help you find what the issue is.

Related

Error on PM2 - type.slice is not a function

I'm using PM2 version 5.1.2 with the app in cluster mode. Getting this error and pm2 keeps restarting with the same error.
Seems like it has something to do with the cluster mode, but I couldn't find a solution.
PM2 | ===============================================================================
PM2 | --- PM2 global error caught ---------------------------------------------------
PM2 | Time : Tue Dec 21 2021 13:45:52 GMT+0000 (Coordinated Universal Time)
PM2 | type.slice is not a function
PM2 | TypeError: type.slice is not a function
PM2 | at EventEmitter.emit (/usr/lib/node_modules/pm2/node_modules/eventemitter2/lib/eventemitter2.js:343:77)
PM2 | at Worker.cluMessage (/usr/lib/node_modules/pm2/lib/God/ClusterMode.js:65:24)
PM2 | at Worker.emit (events.js:412:35)
PM2 | at Worker.emit (domain.js:537:15)
PM2 | at ChildProcess.<anonymous> (internal/cluster/worker.js:33:12)
PM2 | at ChildProcess.emit (events.js:400:28)
PM2 | at ChildProcess.emit (domain.js:537:15)
PM2 | at emit (internal/child_process.js:912:12)
PM2 | at processTicksAndRejections (internal/process/task_queues.js:83:21)
PM2 | ===============================================================================
PM2 | [PM2] Resurrecting PM2
PM2 config:
--- Daemon -------------------------------------------------
pm2d version : 5.1.2
node version : 14.18.2
node path : /usr/bin/pm2
argv : /usr/bin/node,/usr/lib/node_modules/pm2/lib/Daemon.js
argv0 : node
user : marcos
uid : 1001
gid : 1002
uptime : 0min
===============================================================================
--- CLI ----------------------------------------------------
local pm2 : 5.1.2
node version : 14.18.2
node path : /usr/bin/pm2
argv : /usr/bin/node,/usr/bin/pm2,report
argv0 : node
user : marcos
uid : 1001
gid : 1002
===============================================================================
--- System info --------------------------------------------
arch : x64
platform : linux
type : Linux
cpus : Intel(R) Xeon(R) CPU # 2.20GHz
cpus nb : 2
freemem : 6384754688
totalmem : 8340885504
home : /home/marcos
===============================================================================

Thingsboard: Fails to read valid JSON payload when timestamp is in ISO 8601 format

I send this valid JSON to TB CE edition, and it fails reading it.
mosquitto_pub -d -q 1 -h “192.168.0.108” -t “device/sck/ybuers/readings” -i xxxxx -m
{"ts":"2021-11-08T16:17Z","value1":"99","value2":"24"}
If I send: (just changing the ts format to UNIX style)
mosquitto_pub -d -q 1 -h “192.168.0.108” -t “device/sck/ybuers/readings” -i xxxxx -m
{"ts":"12345678910","value1":"99","value2":"24"}
it works.
Is this a BIG limitation of the platform? or am I missing something basic?
I'm working with TB CE v3.3.1, on Windows.
I paste the error from /var/log/thingsboard below.
Thank you!
2021-11-09 15:25:23,583 [nioEventLoopGroup-4-2] INFO o.t.s.t.mqtt.MqttTransportHandler - [d13716f2-1a55-4056-93c8-11b81bc7794b] Processing connect msg for client: ybuers!
2021-11-09 15:25:23,583 [nioEventLoopGroup-4-2] INFO o.t.s.t.mqtt.MqttTransportHandler - [d13716f2-1a55-4056-93c8-11b81bc7794b] Processing connect msg for client with user name: null!
2021-11-09 15:25:23,639 [DefaultTransportService-28-60] INFO o.t.s.t.mqtt.MqttTransportHandler - [d13716f2-1a55-4056-93c8-11b81bc7794b] Client connected!
2021-11-09 15:25:23,644 [nioEventLoopGroup-4-2] WARN o.t.s.t.mqtt.MqttTransportHandler - [d13716f2-1a55-4056-93c8-11b81bc7794b] **Failed to process publish msg [device/sck/ybuers/readings][1]**
org.thingsboard.server.common.transport.adaptor.AdaptorException: com.google.gson.JsonSyntaxException: **com.google.gson.stream.MalformedJsonException: Unterminated object at line 1 column 18 path $.t**
at org.thingsboard.server.transport.mqtt.adaptors.JsonMqttAdaptor.convertToPostTelemetry(JsonMqttAdaptor.java:67)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.processDevicePublish(MqttTransportHandler.java:343)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.processPublish(MqttTransportHandler.java:298)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.processRegularSessionMsg(MqttTransportHandler.java:255)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.lambda$processMsgQueue$0(MqttTransportHandler.java:249)
at org.thingsboard.server.transport.mqtt.session.DeviceSessionCtx.tryProcessQueuedMsgs(DeviceSessionCtx.java:181)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.processMsgQueue(MqttTransportHandler.java:249)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.enqueueRegularSessionMsg(MqttTransportHandler.java:241)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.processMqttMsg(MqttTransportHandler.java:183)
at org.thingsboard.server.transport.mqtt.MqttTransportHandler.channelRead(MqttTransportHandler.java:156)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Unterminated object at line 1 column 18 path $.t
at com.google.gson.internal.Streams.parse(Streams.java:60)
at com.google.gson.JsonParser.parse(JsonParser.java:84)
at com.google.gson.JsonParser.parse(JsonParser.java:59)
at com.google.gson.JsonParser.parse(JsonParser.java:45)
at org.thingsboard.server.transport.mqtt.adaptors.JsonMqttAdaptor.convertToPostTelemetry(JsonMqttAdaptor.java:65)
... 30 common frames omitted
Caused by: com.google.gson.stream.MalformedJsonException: Unterminated object at line 1 column 18 path $.t
at com.google.gson.stream.JsonReader.syntaxError(JsonReader.java:1567)
at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:495)
at com.google.gson.stream.JsonReader.hasNext(JsonReader.java:418)
at com.google.gson.internal.bind.TypeAdapters$29.read(TypeAdapters.java:742)
at com.google.gson.internal.bind.TypeAdapters$29.read(TypeAdapters.java:718)
at com.google.gson.internal.Streams.parse(Streams.java:48)
... 34 common frames omitted
2021-11-09 15:25:23,645 [nioEventLoopGroup-4-2] INFO o.t.s.t.mqtt.MqttTransportHandler - [d13716f2-1a55-4056-93c8-11b81bc7794b] Closing current session due to invalid publish msg [device/sck/ybuers/readings][1]
2021-11-09 15:25:23,646 [nioEventLoopGroup-4-2] INFO o.t.s.t.mqtt.MqttTransportHandler - [d13716f2-1a55-4056-93c8-11b81bc7794b] Client disconnected!
2021-11-09 15:25:23,664 [nioEventLoopGroup-4-1] INFO o.t.s.t.mqtt.MqttTransportHandler - [f03fba50-a2be-4c2f-a301-a48c79d6baaf] Client disconnected!
If you're using windows to execute that cmd, try using windows format quotes.
"{\"ts\":\"12345678910\",\"value1\":\"99\",\"value2\":\"24\"}"

ContextBroker subscriptions Error

I've updated cygnus from version 0.13 to 1.7.0 by installing NGSI following this tutorial:
https://github.com/telefonicaid/fiware-cygnus/tree/master/cygnus-ngsi
Error the subscription
[
{
"id": "59d38a92dbaa1e477aef9c00",
"description": "A subscription to get info about pruebas",
"status": "failed",
"subject": {
"entities": [
{
"id": "pruebas",
"type": "pruebas"
}
],
"condition": {
"attrs": [
"pressure"
]
}
},
"notification": {
"timesSent": 2,
"lastNotification": "2017-10-03T13:03:43.00Z",
"attrs": [
"temperature",
"pressure"
],
"attrsFormat": "legacy",
"http": {
"url": "http://localhost:5050/notify"
},
"lastFailure": "2017-10-03T13:03:43.00Z"
}
}
]
viewing the contextBroker log gives the following:
$pp[328]:notificationError | msg=Raising alarm NotificationError http://localhost:5050/notify: (curl_easy_perform failed: Couldn't connect to server)
I have contextBroker on the same machine as cygnus so I have already tried to change the notify ip for the server and for localhost and it does not work for any of it.
with version 0.13 if it works with localhost.
What could be the problem?
It does not even come to cygnus configuration files because it can not access from the contextBroker.
Greetings and thank you.
EDIT1:
I am tested with the fiwareLab machines and removing cygnus 0.13 that comes pre installed with YUM REMOVE CYGNUS. Then I installed 1.7 with YUM INSTALL CYGNUS-NGSI and installed two packages ngsi and common.
Restarting the service with service cygnus restart indicates the following:
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
cygnus-ngsi x86_64 1.7.1-0.g9df0d4d fiware 74 M
Installing for dependencies:
cygnus-common x86_64 1.7.1-0.g9df0d4d fiware 128 M
Transaction Summary
================================================================================
Install 2 Package(s)
Total size: 202 M
Installed size: 223 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
[INFO] Creating cygnus user
Installing : cygnus-common-1.7.1-0.g9df0d4d.x86_64 1/2
[INFO] Creating log directory
Done
Installing : cygnus-ngsi-1.7.1-0.g9df0d4d.x86_64 2/2
Verifying : cygnus-common-1.7.1-0.g9df0d4d.x86_64 1/2
Verifying : cygnus-ngsi-1.7.1-0.g9df0d4d.x86_64 2/2
Installed:
cygnus-ngsi.x86_64 0:1.7.1-0.g9df0d4d
Dependency Installed:
cygnus-common.x86_64 0:1.7.1-0.g9df0d4d
Complete!
[centos#centos6 cygnus]$ sudo service cygnus restart
There aren't any instance of Cygnus running [ OK ]
Starting Cygnus 1... [ OK ]
When I try on my server I do the same steps but when doing the service cygnus restart has two cygnus the 1 and 2 not as in vuesta machine that only has one and therefore indicates that the port 8081 is already in use.
Dependencias resueltas
============================================================================================================================================================================
Paquete Arquitectura Versión Repositorio Tamaño
============================================================================================================================================================================
Instalando:
cygnus-ngsi x86_64 1.7.1-0.g9df0d4d fiware 74 M
Instalando para las dependencias:
cygnus-common x86_64 1.7.1-0.g9df0d4d fiware 128 M
Resumen de la transacción
============================================================================================================================================================================
Instalar 2 Paquete(s)
Tamaño total de la descarga: 202 M
Tamaño instalado: 223 M
Está de acuerdo [s/N]:s
Descargando paquetes:
(1/2): cygnus-common_hadoopcore_1.2.1-1.7.1-0.g9df0d4d.x86_64.rpm | 128 MB 00:14
(2/2): cygnus-ngsi-1.7.1-0.g9df0d4d.x86_64.rpm | 74 MB 00:07
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 8.9 MB/s | 202 MB 00:22
Ejecutando el rpm_check_debug
Ejecutando prueba de transacción
La prueba de transacción ha sido exitosa
Ejecutando transacción
[INFO] Creating cygnus user
Instalando : cygnus-common-1.7.1-0.g9df0d4d.x86_64 1/2
[INFO] Creating log directory
Done
Instalando : cygnus-ngsi-1.7.1-0.g9df0d4d.x86_64 2/2
Verifying : cygnus-common-1.7.1-0.g9df0d4d.x86_64 1/2
Verifying : cygnus-ngsi-1.7.1-0.g9df0d4d.x86_64 2/2
Instalado:
cygnus-ngsi.x86_64 0:1.7.1-0.g9df0d4d
Dependencia(s) instalada(s):
cygnus-common.x86_64 0:1.7.1-0.g9df0d4d
¡Listo!
[root#UAL-IoF2020 conf]# ls
agent_1.conf agent_ngsi.conf.template cygnus_instance_2.conf grouping_rules_2.conf krb5_login.conf README-cygnus-common.md
agent_3.conf cartodb_keys.conf.template cygnus_instance.conf.template grouping_rules.conf.template log4j.properties README-cygnus-ngsi.md
agent.conf.template cygnus_instance_1.conf flume-env.sh.template krb5.conf.template name_mappings.conf.template
[root#UAL-IoF2020 conf]# service cygnus restart
There aren't any instance of Cygnus running [ OK ]
Starting Cygnus 1... [ OK ]
Starting Cygnus 2... [ OK ]
[root#UAL-IoF2020 conf]#
Is it possible that this is the problem and that is not recognizing my NGSI and this occupying the 8081 the common? or is this normal?
Log cygnus :
time=2017-10-03T21:51:09.326Z | lvl=INFO | corr= | trans= | srv= | subsrv= | comp=cygnusagent | op=main | msg=com.telefonica.iot.cygnus.nodes.CygnusApplication[301] : Starting a Jetty server listening on 0.0.0.0:8081 (Management Interface)
time=2017-10-03T21:51:09.381Z | lvl=WARN | corr= | trans= | srv= | subsrv= | comp=cygnusagent | op=warn | msg=org.mortbay.log.Slf4jLog[76] : failed SelectChannelConnector#0.0.0.0:8081: java.net.BindException: La dirección ya se está usando
time=2017-10-03T21:51:09.381Z | lvl=WARN | corr= | trans= | srv= | subsrv= | comp=cygnusagent | op=warn | msg=org.mortbay.log.Slf4jLog[76] : failed Server#52992ace: java.net.BindException: La dirección ya se está usando
time=2017-10-03T21:51:09.381Z | lvl=FATAL | corr= | trans= | srv= | subsrv= | comp=cygnusagent | op=run | msg=com.telefonica.iot.cygnus.http.JettyServer[90] : Fatal error running the Management Interface. Details=La dirección ya se está usando
EDIT2
I have already solved the problem of two cygnus, had two agent_1 and agent_2 created. I have deleted one of them and already performing service cygnus restart appears only one cygnus. We are getting better.
But I still have the same problem with the subscriptions:
The contextBroker log indicates:
 
msg = Raising alarm NotificationError http: // localhost: 5050 / notify: (curl_easy_perform failed: could not connect to server)
When I try:
[root # UAL-IoF2020 conf] # netstat -np | grep 5050
I do not think anything.
When I launch this:
[root # UAL-IoF2020 conf] # netstat -np | grep 1026
tcp 0 0 150.XXX.XXX.XXX:1026 XXX.XXX.XXX.XXX:50348 ESTABLISHED 5169 / contextBroker
I am trying to launch a Test of your page.
./notification-json-simple.sh http: // localhost: 5050 / notify myservice myservicepath
and gives me the following error:
[root # UAL-IoF2020 ngsi-examples] # ./notification-json-simple.sh http: // localhost: 5050 / notify myservice myservicepath
* About to connect () to localhost port 5050 (# 0)
* Trying :: 1 ... Connection refused
* Trying 127.0.0.1 ... Connection refused
* could not connect to host
* Closing connection # 0
curl: (7) could not connect to host
It gives the impression that in the 5050 I have nothing listening.
Any clue what that might be?
cygnus-ngsi.sources = http-source
cygnus-ngsi.sinks = mysql-sink
cygnus-ngsi.channels = mysql-channel
#=============================================
# source configuration
# channel name where to write the notification events
cygnus-ngsi.sources.http-source.channels = mysql-channel
# source class, must not be changed
cygnus-ngsi.sources.http-source.type = org.apache.flume.source.http.HTTPSource
# listening port the Flume source will use for receiving incoming notifications
cygnus-ngsi.sources.http-source.port = 5050
# Flume handler that will parse the notifications, must not be changed
cygnus-ngsi.sources.http-source.handler = com.telefonica.iot.cygnus.handlers.NGSIRestHandler
# URL target
cygnus-ngsi.sources.http-source.handler.notification_target = /notify
# default service (service semantic depends on the persistence sink)
cygnus-ngsi.sources.http-source.handler.default_service = default
# default service path (service path semantic depends on the persistence sink)
cygnus-ngsi.sources.http-source.handler.default_service_path = /
# source interceptors, do not change
cygnus-ngsi.sources.http-source.interceptors = ts gi
# TimestampInterceptor, do not change
cygnus-ngsi.sources.http-source.interceptors.ts.type = timestamp
# GroupingInterceptor, do not change
cygnus-ngsi.sources.http-source.interceptors.gi.type = com.telefonica.iot.cygnus.interceptors.NGSIGroupingInterceptor$Builder
# Grouping rules for the GroupingInterceptor, put the right absolute path to the file if necessary
# see the doc/design/interceptors document for more details
cygnus-ngsi.sources.http-source.interceptors.gi.grouping_rules_conf_file = /usr/cygnus/conf/grouping_rules.conf
Do I have to install cygnus-common manual?
Reading the documentation (https://github.com/telefonicaid/fiware-cygnus/tree/master/cygnus-ngsi) it's wrote:
Cygnus NGSI is based on Apache Flume, which is used through cygnus-common and which Cygnus NGSI depends on.
I think you need to install cygnus-common.
I have already solved the problem.
It was in the configuration file of cygnus_instance_1.conf, you had to rename the cygnusagent agent by cygnus-ngsi.
For installation, I have simply followed these steps.
Install ContextBroker.
Install MongoDB (for contextBroker to
work).
Install cygnus-ngsi, this in turn installed automatically
cygnus-common.
Copy the agent_ngsi.conf.template and rename it with
agent_1.conf
Copy the cygnus_instance.conf.template to cygnus_instance_1.conf
Rename the agent from cygnus_instance_1.conf to cygnus-ngsi and the configuration file created above (agent_1.conf)
All this has been with Yum Install, with RPM, I have not had to install apache flume or anything, this way it does everything automatically.
I hope this helps and thanks.
The last error log you have posted is the key: there is another running process listening on TCP/5050 port. Most probably, a previous run of Cygnus not stopped/killed properly.

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!

Cygnus not presisting data on MySql database

So i have read all the documentation and followed the tutorial on MySQL persistence but i can't still presist any kind of data on MySQL database.
Even though i'm puting the presistence mode = row it doesn't create any database nor table.
What am i doing wrong?
My Subscription:
python2.7 SetSubscription.py bustest4 http://localhost:5050/notify
Output:
* Asking to http://localhost:1026/v1/subscribeContext
* Headers: {'Fiware-Service': 'fiwaretestapi', 'content-type': 'application/json ', 'accept': 'application/json', 'X-Auth-Token': 'NULL'}
* Sending PAYLOAD:
{
"reference": "http://localhost:5050/notify",
"throttling": "PT5S",
"entities": [
{
"type": "",
"id": "bustest4",
"isPattern": "false"
}
],
"attributes": [
"temperature"
],
"duration": "P1M",
"notifyConditions": [
{
"condValues": [
"temperature"
],
"type": "ONCHANGE"
}
]
}
...
* Status Code: 200
{
"subscribeResponse" : {
"subscriptionId" : "5567332298add18cc3e183ac",
"duration" : "P1M",
"throttling" : "PT5S"
}
}
My agent_a1.conf:
#=============================================
# source configuration
# channel name where to write the notification events
cygnusagent.sources.http-source.channels = hdfs-channel mysql-channel ckan-channel
# source class, must not be changed
cygnusagent.sources.http-source.type = org.apache.flume.source.http.HTTPSource
# listening port the Flume source will use for receiving incoming notifications
cygnusagent.sources.http-source.port = 5050
# Flume handler that will parse the notifications, must not be changed
cygnusagent.sources.http-source.handler = es.tid.fiware.fiwareconnectors.cygnus.handlers.OrionRestHandler
# URL target
cygnusagent.sources.http-source.handler.notification_target = /notify
# Default service (service semantic depends on the persistence sink)
cygnusagent.sources.http-source.handler.default_service = fiwaretestapi
# Default service path (service path semantic depends on the persistence sink)
cygnusagent.sources.http-source.handler.default_service_path = /
# Number of channel re-injection retries before a Flume event is definitely discarded (-1 means infinite retries)
cygnusagent.sources.http-source.handler.events_ttl = 10
# Source interceptors, do not change
cygnusagent.sources.http-source.interceptors = ts de
# Timestamp interceptor, do not change
cygnusagent.sources.http-source.interceptors.ts.type = timestamp
# Destination extractor interceptor, do not change
cygnusagent.sources.http-source.interceptors.de.type = es.tid.fiware.fiwareconnectors.cygnus.interceptors.DestinationExtractor$Builder
# Matching table for the destination extractor interceptor, put the right absolute path to the file if necessary
# See the doc/design/interceptors document for more details
cygnusagent.sources.http-source.interceptors.de.matching_table = /usr/cygnus/conf/matching_table.conf
# ============================================
# OrionMySQLSink configuration
# channel name from where to read notification events
cygnusagent.sinks.mysql-sink.channel = mysql-channel
# sink class, must not be changed
cygnusagent.sinks.mysql-sink.type = es.tid.fiware.fiwareconnectors.cygnus.sinks.OrionMySQLSink
# the FQDN/IP address where the MySQL server runs
cygnusagent.sinks.mysql-sink.mysql_host = localhost
# the port where the MySQL server listes for incomming connections
cygnusagent.sinks.mysql-sink.mysql_port = 3306
# a valid user in the MySQL server
cygnusagent.sinks.mysql-sink.mysql_username = root
# password for the user above
cygnusagent.sinks.mysql-sink.mysql_password = ***********
# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.mysql-sink.attr_persistence = row
#=============================================
# mysql-channel configuration
# channel type (must not be changed)
cygnusagent.channels.mysql-channel.type = memory
# capacity of the channel
cygnusagent.channels.mysql-channel.capacity = 1000
# amount of bytes that can be sent per transaction
cygnusagent.channels.mysql-channel.transactionCapacity = 100
My cygnus_instance_c1.conf:
# Who to run cygnus as. Note that you may need to use root if you want
# to run cygnus in a privileged port (<1024)
CYGNUS_USER=root
# Where is the config folder
CONFIG_FOLDER=/usr/cygnus/conf
# Which is the config file
CONFIG_FILE=/usr/cygnus/conf/agent_a1.conf
# Name of the agent. The name of the agent is not trivial, since it is the base for the Flume parameters
# naming conventions, e.g. it appears in .sources.http-source.channels=...
AGENT_NAME=cygnususer
# Name of the logfile located at /var/log/cygnus. It is important to put the extension '.log' in order to the log rotation works properly
LOGFILE_NAME=cygnus.log
# Administration port. Must be unique per instance
ADMIN_PORT=8081
My cygnus.log:
Info: Sourcing environment configuration script /usr/cygnus/conf/flume-env.sh
Warning: JAVA_HOME is not set!
+ exec /usr/bin/java -Xmx20m -Dflume.log.file=cygnus.log -cp '/usr/cygnus/conf:/usr/cygnus/lib/*:/usr/cygnus/plugins.d/cygnus/lib/*:/usr/cygnus/plugins.d/cygnus/libext/*' -Djava.library.path= es.tid.fiware.fiwareconnectors.cygnus.nodes.CygnusApplication -p 8081 -f /usr/cygnus/conf/agent_a1.conf -n root
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/cygnus/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/cygnus/plugins.d/cygnus/lib/cygnus-0.7.1-jar-with-dependencies.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
EDIT:
So after some changes i got the log file to work and i found out that the 8081 port was already in use. Can you explain me what the ADMIN_PORT is used for, what port is it recommended to be?
LOG FILE:
02 Jun 2015 05:16:40,680 INFO [conf-file-poller-0] (org.apache.flume.node.PollingPropertiesFileConfigurationProvider$FileWatcherRunnable.run:133) - Reloading configuration file:/usr/cygnus/conf/agent_a1.conf
02 Jun 2015 05:16:40,685 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,686 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,686 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:930) - Added sinks: mysql-sink Agent: cygnusagent
02 Jun 2015 05:16:40,686 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,687 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,687 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,687 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,687 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration$AgentConfiguration.addProperty:1016) - Processing:mysql-sink
02 Jun 2015 05:16:40,692 INFO [conf-file-poller-0] (org.apache.flume.conf.FlumeConfiguration.validateConfiguration:140) - Post-validation flume configuration contains configuration for agents: [cygnusagent]
02 Jun 2015 05:16:40,692 WARN [conf-file-poller-0] (org.apache.flume.node.AbstractConfigurationProvider.getConfiguration:138) - No configuration found for this host:root
02 Jun 2015 05:16:40,693 INFO [conf-file-poller-0] (org.apache.flume.node.Application.stopAllComponents:101) - Shutting down configuration: { sourceRunners:{} sinkRunners:{} channels:{} }
02 Jun 2015 05:16:40,693 INFO [conf-file-poller-0] (org.apache.flume.node.Application.startAllComponents:138) - Starting new configuration:{ sourceRunners:{} sinkRunners:{} channels:{} }
02 Jun 2015 05:16:40,694 INFO [conf-file-poller-0] (es.tid.fiware.fiwareconnectors.cygnus.nodes.CygnusApplication.startManagementInterface:85) - Starting a Jetty server listening on port 8081 (Management Interface)
02 Jun 2015 05:16:40,695 INFO [conf-file-poller-0] (org.apache.flume.node.Application.stopAllComponents:101) - Shutting down configuration: { sourceRunners:{} sinkRunners:{} channels:{} }
02 Jun 2015 05:16:40,695 INFO [conf-file-poller-0] (org.apache.flume.node.Application.startAllComponents:138) - Starting new configuration:{ sourceRunners:{} sinkRunners:{} channels:{} }
02 Jun 2015 05:16:40,695 INFO [conf-file-poller-0] (es.tid.fiware.fiwareconnectors.cygnus.nodes.CygnusApplication.startManagementInterface:85) - Starting a Jetty server listening on port 8081 (Management Interface)
02 Jun 2015 05:16:40,696 INFO [Thread-26] (org.mortbay.log.Slf4jLog.info:67) - jetty-6.1.26
02 Jun 2015 05:16:40,704 WARN [Thread-26] (org.mortbay.log.Slf4jLog.warn:76) - failed SocketConnector#0.0.0.0:8081: java.net.BindException: Address already in use
02 Jun 2015 05:16:40,704 WARN [Thread-26] (org.mortbay.log.Slf4jLog.warn:76) - failed Server#4f1b95f: java.net.BindException: Address already in use
02 Jun 2015 05:16:40,704 FATAL [Thread-26] (es.tid.fiware.fiwareconnectors.cygnus.http.JettyServer.run:63) - Fatal error running the Management Interface. Details=Address already in use
02 Jun 2015 05:16:40,705 INFO [Thread-27] (org.mortbay.log.Slf4jLog.info:67) - jetty-6.1.26
02 Jun 2015 05:16:40,709 WARN [Thread-27] (org.mortbay.log.Slf4jLog.warn:76) - failed SocketConnector#0.0.0.0:8081: java.net.BindException: Address already in use
02 Jun 2015 05:16:40,709 WARN [Thread-27] (org.mortbay.log.Slf4jLog.warn:76) - failed Server#ed4c222: java.net.BindException: Address already in use
02 Jun 2015 05:16:40,709 FATAL [Thread-27] (es.tid.fiware.fiwareconnectors.cygnus.http.JettyServer.run:63) - Fatal error running the Management Interface. Details=Address already in use
EDIT 2:
My script that updates entity on Context Broker:
BASE_URL = 'http://localhost:1026'
UPDATE_URL = BASE_URL+'/ngsi10/updateContext'
HEADERS = {
'Content-Type': 'application/json',
'Accept': 'application/json',
'Fiware-Service' : 'fiwaretestapi',
'Fiware-ServicePath': '/'
}
UPDATE_EXAMPLE = {
"contextElements": [
{
"type": "",
"isPattern": "false",
"id": "bustest4",
"attributes": [
{
"name": "temperature",
"type": "int",
"value": "99"
}
]
}
],
"updateAction": "APPEND"
}
def post(url, data):
""""""
req = urllib2.Request(url, data, HEADERS)
f = urllib2.urlopen(req)
result = json.loads(f.read())
f.close()
return result
if __name__ == "__main__":
print post(UPDATE_URL, json.dumps(UPDATE_EXAMPLE))
EDIT3:
Even though i set the admin port to be 8085 on the cygnus agent configuration it tries to bind to the 8081, is that normal?
Here are the logs from the cygnus:
time=2015-06-12T05:56:39.820EDT | lvl=INFO | trans= | function=start | comp=Cygnu s | msg=org.apache.flume.instrumentation.MonitoredCounterGroup[94] : Component ty pe: CHANNEL, name: mysql-channel started
time=2015-06-12T05:56:39.821EDT | lvl=INFO | trans= | function=startAllComponents | comp=Cygnus | msg=org.apache.flume.node.Application[173] : Starting Sink mysql -sink
time=2015-06-12T05:56:39.821EDT | lvl=INFO | trans= | function=startAllComponents | comp=Cygnus | msg=org.apache.flume.node.Application[184] : Starting Source htt p-source
time=2015-06-12T05:56:39.821EDT | lvl=INFO | trans= | function=startManagementInt erface | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.nodes.CygnusAppl ication[85] : Starting a Jetty server listening on port 8081 (Management Interfac e)
time=2015-06-12T05:56:39.822EDT | lvl=INFO | trans= | function=start | comp=Cygnu s | msg=es.tid.fiware.fiwareconnectors.cygnus.sinks.OrionMySQLSink[151] : [mysql- sink] Startup completed
time=2015-06-12T05:56:39.823EDT | lvl=INFO | trans= | function=info | comp=Cygnus | msg=org.mortbay.log.Slf4jLog[67] : jetty-6.1.26
time=2015-06-12T05:56:39.824EDT | lvl=INFO | trans= | function=info | comp=Cygnus | msg=org.mortbay.log.Slf4jLog[67] : jetty-6.1.26
time=2015-06-12T05:56:39.825EDT | lvl=INFO | trans= | function=info | comp=Cygnus | msg=org.mortbay.log.Slf4jLog[67] : Started SocketConnector#0.0.0.0:5050
time=2015-06-12T05:56:39.825EDT | lvl=INFO | trans= | function=start | comp=Cygnu s | msg=org.apache.flume.instrumentation.MonitoredCounterGroup[94] : Component ty pe: SOURCE, name: http-source started
time=2015-06-12T05:56:39.827EDT | lvl=WARN | trans= | function=warn | comp=Cygnus | msg=org.mortbay.log.Slf4jLog[76] : failed SocketConnector#0.0.0.0:8081: java.n et.BindException: Address already in use
time=2015-06-12T05:56:39.827EDT | lvl=WARN | trans= | function=warn | comp=Cygnus | msg=org.mortbay.log.Slf4jLog[76] : failed Server#1c9c5521: java.net.BindExcept ion: Address already in use
time=2015-06-12T05:56:39.827EDT | lvl=FATAL | trans= | function=run | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.http.JettyServer[63] : Fatal error r unning the Management Interface. Details=Address already in use
Log when i make a subscription:
time=2015-06-12T06:03:56.529EDT | lvl=INFO | trans=1434103313-190-0000000000 | fu nction=getEvents | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.handle rs.OrionRestHandler[153] : Starting transaction (1434103313-190-0000000000)
time=2015-06-12T06:03:56.535EDT | lvl=INFO | trans=1434103313-190-0000000000 | fu nction=getEvents | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.handle rs.OrionRestHandler[239] : Received data ({ "subscriptionId" : "557aae8c98add18c c3e183b6", "originator" : "localhost", "contextResponses" : [ { "contex tElement" : { "type" : "thing", "isPattern" : "false", "id" : "autocarro1", "attributes" : [ { "name" : "temperatu re", "type" : "int", "value" : "95", "metadatas" : [ { "name" : "TimeInstant", "type" : "ISO8601", "value" : "2015-06-03T09:17:44.046583Z" } ] } ] }, "statusCode" : { "code" : "200", "reasonPhrase" : "OK" } } ]})
time=2015-06-12T06:03:56.540EDT | lvl=INFO | trans=1434103313-190-0000000000 | fu nction=getEvents | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.handle rs.OrionRestHandler[261] : Event put in the channel (id=1983722072, ttl=10)
time=2015-06-12T06:03:56.724EDT | lvl=INFO | trans=1434103313-190-0000000000 | fu nction=process | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.sinks.Or ionSink[126] : Event got from the channel (id=1983722072, headers={timestamp=1434 103436542, content-type=application/json, transactionId=1434103313-190-0000000000 , fiware-service=fiwaretestapi, fiware-servicepath=, ttl=10, destination=autocarr o1_thing}, bodyLength=657)
time=2015-06-12T06:03:57.260EDT | lvl=INFO | trans=1434103313-190-0000000000 | fu nction=persist | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.sinks.Or ionMySQLSink[227] : [mysql-sink] Persisting data at OrionMySQLSink. Database: fiw aretestapi, Table: autocarro1_thing, Data: 1434103436,2015-06-12T06:03:56.542,aut ocarro1,thing,temperature,thing,95,[{"name":"TimeInstant","type":"ISO8601","value ":"2015-06-03T09:17:44.046583Z"}]
time=2015-06-12T06:03:57.270EDT | lvl=INFO | trans=1434103313-190-0000000000 | fu nction=process | comp=Cygnus | msg=es.tid.fiware.fiwareconnectors.cygnus.sinks.Or ionSink[187] : Finishing transaction (1434103313-190-0000000000)
As I can see in the log, most probably Cygnus is running but not starting any Flume component (any source, channel or sink). This is due to some configuration errors.
Regarding agent_a1.conf file:
It is missing the list of sources, channels and sinks:
cygnusagent.sources = http-source
cygnusagent.sinks = mysql-sink
cygnusagent.channels = mysql-channel
cygnusagent.sources.http-source.channels value should be mysql-channel
Regarding cygnus_instance_c1.conf:
AGENT_NAME value must be cygnusagent
Which version have you installed? Are you reunning Cygnus as a service or as an standalone process?
In adition, you could try to start Cygnus in DEBUG mode? Simply edit the /usr/cygnus/conf/log4j.properties file.
Do the proposed changes and see how the log evolves! :)
EDIT 1
Such a "fatal error" is not so fatal. It was a bug appearing in Cygnus 0.7.1, currently fixed. Anyway, even in 0.7.1 it did not affect the normal behaviour of Cygnus since the management port is only used for retrieving the version, nothing important.
Did you try to send some update context to Orion in order a notification is received by Cygnus? Even by simulating the notification? Please, see the Cygnus Quick Start Guide for an example about how to make such a simulation.
EDIT 2
Cygnus packages names es.tid.fiware.fiwareconnectors.cygnus... were replaced by com.telefonica.iot.cygnus... from release 0.8.0 (or maybe 0.9.0).