Just after the install of the Context Broker I've tried to test it creating a new entity as described in the session Entity Creation of https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide, but I'm getting a "connection reset by peer" error.
The log doesn't seem say anything, even I raised the level of traces with -t 0-255 option.
Aditional info:
$ contextBroker --version
0.14.0
$ ps aux | grep context
/usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/log/contextBroker/contextBroker.pid -dbhost localhost -db orion -t 0-255
The issue was fixed updating the Context Broker to a newer version, in my case to version 0.14.1, which can be found here: http://repositories.testbed.fi-ware.org/repo/rpm/x86_64/.
I can't say exactly what was wrong, since after updating everything was working fine.
Related
VS code often starts listening on a random high port on all interfaces.
$ lsb_release -d
Description: Ubuntu 22.04 LTS
$ code --version
1.67.2
c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5
x64
$ sudo ss -ltpn | grep code
LISTEN 0 511 *:33333 *:* users:(("code",pid=75602,fd=52))
In VS code developer tools console:
CRITI Extension 'ms-vsliveshare.vsliveshare' wants API proposal 'notebookDocumentEvents' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check 'vscode.d.ts') or was abandoned.
log.ts:313
ERR UnboundLocalError: local variable 'start_index' referenced before assignment: Error: UnboundLocalError: local variable 'start_index' referenced before assignment
at /home/user/.vscode/extensions/ms-python.python-2022.8.0/out/client/extension.js:2:2107873
at /home/user/.vscode/extensions/ms-python.python-2022.8.0/out/client/extension.js:2:2108167
at Immediate.<anonymous> (/home/user/.vscode/extensions/ms-python.python-2022.8.0/out/client/extension.js:2:2108529)
at processImmediate (node:internal/timers:464:21)
log.ts:313
ERR Error: File not found
at g.handleSetInputError (vscode-file://vscode….main.js:2701:95592)
at async g.setInput (vscode-file://vscode….main.js:2701:94832)
at async doSetInput (vscode-file://vscode…p.main.js:2699:6429)
at async doOpenEditor (vscode-file://vscode…p.main.js:2699:4791)
at async d.openEditor (vscode-file://vscode…p.main.js:2699:3783)
at async vscode-file://vscode….main.js:2906:16950
at async bi.openAnything (vscode-file://vscode….main.js:2712:17542)
I have not been able to reproduce whenever the Microsoft Python extension (Python
v2022.8.0) was disabled, so it might be related to that. There is an error in the console related to ms-python, but I do not immediately see how it would lead to a port being opened, especially not on 0.0.0.0.
The following shows nothing:
$ sudo tcpdump -i any port 33333
The question is what causes this port to be opened (and how to avoid this).
In the process explorer of VS code it shows that the process that opened the port is 'extensionHost'.
I want to visualise my data base and tried using SchemaSpy, but I can't connect to the data base. It's a mysql data base, running on my computer, accessible under localhost and I called SchemaSpy with the following command:
java -jar schemaspy-6.0.0.jar -t mysql -dp postgresql-42.2.7.jar -db <name> -host <host> -p <port> -s <name> -u <user> -p <password> -o ./output/
I downloaded postgresql-42.2.7.jar as a driver and set the respective parameter in the call. I also tried not setting a driver at all, but it didn't change the output.
I get the following error message after trying to run SchemaSpy:
SchemaSpy generates an HTML representation of a database schema's relationships.
SchemaSpy comes with ABSOLUTELY NO WARRANTY.
SchemaSpy is free software and can be redistributed under the conditions of LGPL version 3 or later.
http://www.gnu.org/licenses/
INFO - Starting Main v6.0.0 on ####### with PID 10774 (/path/to/file started by ##### in /path/to/file)
INFO - The following profiles are active: default
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils$1 (jar:file:/path/to/file/schemaspy-6.0.0.jar!/BOOT-INF/lib/spring-core-4.3.13.RELEASE.jar!/) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of org.springframework.cglib.core.ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
INFO - Found configuration file: schemaspy.properties
INFO - Started Main in 1.397 seconds (JVM running for 1.944)
INFO - Starting schema analysis
WARN - Connection Failure
I also tried setting the --illegal-access=warn parameter, but no changes.
Does anyone know what problem might be?
Thanks a lot!
I am trying to publish messages from rsyslog to kafka on a remote machine using omkafka module.
My omkafka action is configured as:
if $HOSTNAME == 'localhost' then {
action(type="omkafka"
name="log_kafka"
broker="192.168.100.50:9092"
topic="rsyslog_kafka"
errorfile="/var/log/omkafka/log_kafka_failures.log"
template="hostipFormat"<br/>
)
}
My kafka instance is running fine and I am able to publish data using kafka-producer.bat file from another windows machine.
But when I start my rsyslog service, I get following error:
Feb 17 16:42:01 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.24.0" x-pid="1764" x-info="http://www.rsyslog.com"] start
Feb 17 16:42:05 localhost rsyslogd: omkafka: kafka message 192.168.100.50:9092/bootstrap: Failed to connect to broker at 192.168.100.50:9092: Permission denied [v8.24.0 try http://www.rsyslog.com/e/2422 ]
Feb 17 16:42:05 localhost rsyslogd: omkafka: kafka message 1/1 brokers are down [v8.24.0 try http://www.rsyslog.com/e/2422 ]
Feb 17 16:42:05 localhost rsyslogd: omkafka: kafka message 192.168.100.50:9092/bootstrap: Failed to connect to broker at 192.168.100.50:9092: Permission denied [v8.24.0 try http://www.rsyslog.com/e/2422 ]
Feb 17 16:42:05 localhost rsyslogd: omkafka: kafka message 1/1 brokers are down [v8.24.0 try http://www.rsyslog.com/e/2422 ]
I am not sure whether this is related to omkafka or librdkafka.
Need help.
I had the same issue. Instead of disabling SELinux and thus opening yourself up to a world of hurt. I used audit2why which tells you exactly why something is being denied in their avc denials. It is helpful as well in that it can tell you just what you need to do to fix the problem.
Audit2why reads /var/log/audit/audit.log and then tells you why something is being denied, and sometimes can tell you what you need to do to fix an issue. In my case it was
type=AVC msg=audit(1492149030.280:296487): avc: denied { name_connect } for pid=2277 comm=72733A6D61696E20513A526567 dest=9092 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
Was caused by:
The boolean nis_enabled was set incorrectly.
Description:
Allow nis to enabled
Allow access by executing:
# setsebool -P nis_enabled 1
The final commented line there is exactly what needs to be typed to allow this to execute, and it can be done without disabling proper security controls. After sudo setsebool -P nis_enabled 1 was executed I restarted rsyslog and kafka was able to consume my messages just fine.
I got the reason of this issue. It happened because of SELINUX in centos. Once I disabled the SELINUX service, the configuration is working fine.
Definitely this is related to SELinux, but because disabling SELinux is not best choice I correct problem whit this:
sudo semanage port -d -t unreserved_port_t -p tcp 9092
sudo semanage port -a -t http_port_t -p tcp 9092
And the restart syslogd.
I'm trying to deploy contextBroker using the command /etc/init.d/contextBroker and I get the following error:
Starting...
contextBroker is stopped
Starting contextBroker... su: user orion does not exist
cat: /var/log/contextBroker/contextBroker.pid: No such file or directory
pidfile not found [FAILED]
Using the following command I can start contextBroker:
/usr/bin/contextBroker -port 10026 -logDir /var/log/contextBroker
-pidpath /var/log/contextBroker/contextBroker.pid -dbhost localhost -db orion
Which could be the cause of the problem?
There was a bug in the Orion RPM fixed in 0.16.0 that causes the removal of the "orion" user when updating the RPM package. The "orion" user is the one used by default by the /etc/init.d/contextBroker script, thus causing the error message su: user orion does not exist.
Note that although the bug has been fixed in 0.16.0, updating from 0.15.0 (for instance) to 0.16.0 will be problematic, as the version being updated (0.15.0) is still "buggy". Updating from 0.16.0 to any newer version (e.g. upcoming 0.17.0) should work without problem.
Fortunatelly, the problem has an easy solution: instead of updating the package, remove it and install again, typically with:
yum remove contextBroker
yum install contextBroker
I'm using python. I did a yum install memcached followed by a easy_install python-memcached
I used the simple test program from the Help(memcache). When I wasn't getting the proper answers I threw in some print statements:
[~/test]$ cat m2.py
import memcache
mc = memcache.Client(['127.0.0.1:11211'], debug=0)
x = mc.set("some_key", "Some value")
print 'Just set a key and value into the cache (suposedly)'
value = mc.get("some_key")
print 'Just retrieved that value from the cache using the key'
print 'X %s' % x
print 'Value %s' % value
[~/test]$ python m2.py
Just set a key and value into the cache (suposedly)
Just retrieved that value from the cache using the key
X 0
Value None
[~/test]$
The question now is, what have I failed to do in my installation? It appears to be working from an API perspective but it fails to put anything into the memcache share area.
I'm using a virtualbox vm running centos
[~]# cat /proc/version
Linux version 2.6.32-358.6.2.el6.i686 (mockbuild#c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Thu May 16 18:12:13 UTC 2013
Is there a daemon that is supposed to be running? I don't see an obvious named one when I do a ps.
I tried to get pylibmc installed on my vm but was unable to find a working installation so for now will see if I can get the above stuff working first.
I discovered if i ran straight from the python console GUI i get a bit more output if I set debug=1
>>> mc = memcache.Client(['127.0.0.1:11211'], debug=1)
>>> mc.stats
{}
>>> mc.set('test','value')
MemCached: MemCache: inet:127.0.0.1:11211: connect: Connection refused. Marking dead.
0
>>> mc.get('test')
MemCached: MemCache: inet:127.0.0.1:11211: connect: Connection refused. Marking dead.
When I try to use per the example telnet to connect to the port i get a connection refused:
[root#~]# telnet 127.0.0.1 11211
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
[root#~]#
I tried the instructions I found on the net for configuring telnet so localhost wouldn't be disabled:
vi /etc/xinetd.d/telnet
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}
And then ran the commands to restart the service(s):
service iptables stop
service xinetd stop
service iptables start
service xinetd start
service iptables stop
I ran with both cases (iptables started and stopped) but it has no effect. So I am out of ideas. What do I need to do to make it so the PORT will be allowed? if that is the problem?
Or is there a memcached service that needs to be running that needs to open up the port ?
well this is what it took to get it working: ( a series of manual steps )
1) su -
cd /var/run
mkdir memcached # this was missing
In the memcached file I added "-l 127.0.0.1" to the OPTIONS statement. It's apparently a listen option. Do this for steps 2 & 3. I'm not certain which file is actually used at runtime.
2) cd /etc/sysconfig
cp memcached memcached.old
vi memcached
3) cd /etc/init.d
cp memcached memcached.old
vi memcached
4) Try some commands to see if the server starts now
/etc/init.d/memcached start
/etc/init.d/memcached status
/etc/init.d/memcached stop
/etc/init.d/memcached restart
I tried opening a browser, but it never seemed to actually display anything so I don't really know how valid this approach is. I'm not running apache or anything like this so perhaps its not relevant to my cause. Perhaps I would have to supply a ?key=blah or something.
5) http://127.0.0.1:11211
6) Now it should be ready to go. If one runs the test shown with the following it should work. At least it did for me. doing the help(memcache) will display a simple program. just paste that in and it should work just fine.
[~]$ python
>>> import memcache
>>> help(memcache)