I am trying to read the syslog information by filebeat. I have my filebeat installed in docker. I get error message
ERROR [syslog] syslog/input.go:150 Error starting the servererrorlisten tcp 192.168.1.142:514: bind: cannot assign requested address
Here is the config file filebeat.yml:
filebeat.inputs:
- type: syslog
format: rfc5424
protocol.tcp:
host: "192.168.1.142:514"
#========================== Elasticsearch output ===============================
output.elasticsearch:
hosts: ["${ELASTICSEARCH_HOST}:9200"]
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}
#============================== Dashboards =====================================
setup.dashboards:
enabled: true
#============================== Kibana =========================================
setup.kibana:
host: "${KIBANA_HOST}:5601"
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}
#================================== General ===================================
name: test_pc_ecs_log
tags: ["syslog"]
Here is /etc/rsyslog.conf
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
I have checked the connection by and telnet are success:
netstat -4altunp | grep 514
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 1332/rsyslogd
udp 0 0 0.0.0.0:514 0.0.0.0:* 1332/rsyslogd
I am following the config example from input doc.
I would like to ask if anyone set up filebeat for syslog reading.
Thanks
I'm trying to deploy a horizontally scaling application consisting of multiple containers with a single reverse proxy in front to AWS ECS backed by EC2. For certain reasons I cannot use an Application Load Balancer, but want to use a Network Load Balancer that forwards all traffic on ports 80 and 443 to the reverse proxy container. I use AWS CDK to define the setup.
I am running into issues when trying to route traffic on both ports to the proxy. No matter what I do, all targets in the created target group point to port 80 on the container. I.e. I get a mapping of 80->80, 443->80 when I would like 80->80, 443->443.
My CDK code looks like this:
const proxyService = new ecs.Ec2Service(this, 'ProxyService', {
serviceName: 'proxy',
cluster,
taskDefinition: proxyTaskDefinition,
minHealthyPercent: 0,
desiredCount: 1,
securityGroups: [securityGroup],
cloudMapOptions: {
name: 'proxy',
cloudMapNamespace: cluster.defaultCloudMapNamespace
}
})
const loadbalancer = new lb.NetworkLoadBalancer(this, 'NetworkLoadBalancer', {
vpc,
internetFacing: true
})
new cdk.CfnOutput(this, 'LoadBalancerDnsName', {
value: loadbalancer.loadBalancerDnsName
})
loadbalancer.addListener('HTTPListener', {
port: 80
})
.addTargets('HTTPTarget', {
port: 80,
targets: [proxyService]
})
loadbalancer.addListener('HTTPSListener', {
port: 443,
})
.addTargets('HTTPSTarget', {
port: 443,
// the proxyService seems to always register itself at port 80
// by calling its attachToNetworkTargetGroup method
targets: [proxyService]
})
}
The Cloudformation generated for the Target Groups looks like this:
NetworkLoadBalancerHTTPListener792E96F1:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
DefaultActions:
- TargetGroupArn:
Ref: NetworkLoadBalancerHTTPListenerHTTPTargetGroupCEAF8C0F
Type: forward
LoadBalancerArn:
Ref: NetworkLoadBalancer8E753273
Port: 80
Protocol: TCP
Metadata:
aws:cdk:path: SplitClusterStack/NetworkLoadBalancer/HTTPListener/Resource
NetworkLoadBalancerHTTPListenerHTTPTargetGroupCEAF8C0F:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
Properties:
Protocol: TCP
TargetType: ip
VpcId:
Ref: VPCB9E5F0B4
Metadata:
aws:cdk:path: SplitClusterStack/NetworkLoadBalancer/HTTPListener/HTTPTargetGroup/Resource
NetworkLoadBalancerHTTPSListenerAF8F470A:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
DefaultActions:
- TargetGroupArn:
Ref: NetworkLoadBalancerHTTPSListenerHTTPSTargetGroup4BC6FF0B
Type: forward
LoadBalancerArn:
Ref: NetworkLoadBalancer8E753273
Port: 443
Protocol: TCP
Metadata:
aws:cdk:path: SplitClusterStack/NetworkLoadBalancer/HTTPSListener/Resource
NetworkLoadBalancerHTTPSListenerHTTPSTargetGroup4BC6FF0B:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
Properties:
Protocol: TCP
TargetType: ip
VpcId:
Ref: VPCB9E5F0B4
Metadata:
aws:cdk:path: SplitClusterStack/NetworkLoadBalancer/HTTPSListener/HTTPSTargetGroup/Resource
After deploying this, I can edit the created target groups in the web console to register a new target pointing to 443 on the same IP and deregister port 80 to get things working.
How can I create a Loadbalancer target that:
points to the ECS service
uses port 443
I'm happy to construct this myself of even add overrides if it helps me get this solved.
The ECS service exposes a loadBalancerTarget method that can be used for this:
loadbalancer.addListener('HTTPSListener', {
port: 443,
})
.addTargets('HTTPSTarget', {
port: 443,
targets: [proxyService.loadBalancerTarget({
containerPort: 443,
containerName: 'proxy'
})]
})
Today I upgraded a server from Ubuntu 16.04 to 18.04, this also included a jump from ejabberd 16.01 to 18.01. Now we got a problem connecting from the client (using strophe.js)
[info] <0.359.0>#ejabberd_listener:accept:302 (<0.876.0>) Accepted connection 127.0.0.1:60552 -> 127.0.0.1:8088
[error] <0.876.0>#ejabberd_bosh:start:133 Failed to start BOSH session: {error,{noproc,{gen_server,call,[ejabberd_c2s_sup,{start_child,[{xmpp_socket,{socket_state,ejabberd_bosh,{http_bind,<0.877.0>,{{9x,1xx,2xx,1xx},60552}},infinity,undefined,none,<0.877.0>}},[{receiver,<0.877.0>},{xml_socket,true}]]},infinity]}}}
[error] <0.877.0>#gen_server:call CRASH REPORT Process <0.877.0> with 0 neighbours exited with reason: no such process or port in call to gen_server:call(ejabberd_c2s_sup, {start_child,[{xmpp_socket,{socket_state,ejabberd_bosh,{http_bind,<0.877.0>,{{9x,1xx,2xx,1xx},60552}},...}},...]}, infinity) in p1_fsm:init_it/6 line 392
[error] <0.617.0>#gen_server:call Supervisor 'mod_bosh_chat3.myserver.com' had child undefined started with {ejabberd_bosh,start_link,undefined} at <0.877.0> exit with reason no such process or port in call to gen_server:call(ejabberd_c2s_sup, {start_child,[{xmpp_socket,{socket_state,ejabberd_bosh,{http_bind,<0.877.0>,{{9x,1xx,2xx,1xx},60552}},...}},...]}, infinity) in context child_terminated
I am aware that mod_http_bind is replaced by mod_bosh. Clients connect through apache proxy from port 80 to 8088. Requesting :80/http-bind/ will therefore be passed to :8088/bosh/
I also wiped the mnesia database completely, after the upgrade to make sure it was not corrupt or deprecated.
According to this question, I also checked that curl is enabled.
At loglevel debug, the mod_bosh module seems to be started:
[debug] <0.329.0>#gen_mod:start_module:193 loading mod_bosh at jabber.myserver.com
[debug] <0.329.0>#gen_mod:start_module:193 loading mod_push at jabber.myserver.com
[debug] <0.600.0> Supervisor ejabberd_gen_mod_sup started ejabberd_tmp_sup:start_link('mod_bosh_jabber.myserver.com', ejabberd_bosh) at pid <0.651.0>
This is my complete config:
loglevel: 5
log_rotate_size: 0
log_rotate_date: ""
log_rate_limit: 100
hosts:
- "localhost"
- "jabber.myserver.com"
- "chat3.myserver.com"
- "test-chat3.myserver.com"
define_macro:
'TLS_CIPHERS': "HIGH:!aNULL:!eNULL:!3DES:#STRENGTH"
'TLS_OPTIONS':
- "no_sslv3"
- "no_tlsv1"
- "cipher_server_preference"
- "no_compression"
c2s_ciphers: 'TLS_CIPHERS'
s2s_ciphers: 'TLS_CIPHERS'
c2s_protocol_options: 'TLS_OPTIONS'
s2s_protocol_options: 'TLS_OPTIONS'
listen:
-
port: 8088
ip: "127.0.0.1"
module: ejabberd_http
request_handlers:
"/bosh": mod_bosh
web_admin: true
tls: false
disable_sasl_mechanisms: "digest-md5"
s2s_use_starttls: false
auth_password_format: plain
auth_method: sql
sql_type: mysql
sql_server: "10.0.0.51"
sql_database: "databasename"
sql_username: "username"
sql_password: "secret-as-hell"
shaper:
normal: 1000
fast: 50000
max_fsm_queue: 10000
acl:
admin:
user:
- "": "localhost"
- "admin": "test-chat3.myserver.com"
- "admin": "chat3.myserver.com"
local:
user_regexp: ""
loopback:
ip:
- "127.0.0.0/8"
shaper_rules:
max_user_sessions: 10
max_user_offline_messages:
- 5000: admin
- 100
c2s_shaper:
- none: admin
- normal
s2s_shaper: fast
access_rules:
local:
- allow: local
c2s:
- deny: blocked
- allow
announce:
- allow: admin
configure:
- allow: admin
muc_create:
- allow: local
pubsub_createnode:
- allow: local
register:
- allow
trusted_network:
- allow: loopback
api_permissions:
"console commands":
from:
- ejabberd_ctl
who: all
what: "*"
"admin access":
who:
- access:
- allow:
- acl: loopback
- acl: admin
- oauth:
- scope: "ejabberd:admin"
- access:
- allow:
- acl: loopback
- acl: admin
what:
- "*"
- "!stop"
- "!start"
"public commands":
who:
- ip: "127.0.0.1/8"
what:
- "status"
- "connected_users_number"
language: "en"
acme:
contact: "mailto:example-admin#example.com"
ca_url: "https://acme-v01.api.letsencrypt.org"
modules:
mod_adhoc: {}
mod_admin_extra: {}
mod_announce: # recommends mod_adhoc
access: announce
mod_blocking: {} # requires mod_privacy
mod_caps: {}
mod_carboncopy: {}
mod_client_state: {}
mod_configure: {} # requires mod_adhoc
mod_disco: {}
mod_echo: {}
mod_irc: {}
mod_bosh: {}
mod_last: {}
mod_muc:
access:
- allow
access_admin:
- allow: admin
access_create: muc_create
access_persistent: muc_create
mod_muc_admin: {}
mod_offline:
access_max_user_messages: max_user_offline_messages
mod_ping: {}
mod_privacy: {}
mod_private: {}
mod_pubsub:
access_createnode: pubsub_createnode
ignore_pep_from_offline: true
last_item_cache: false
plugins:
- "flat"
- "hometree"
- "pep" # pep requires mod_caps
mod_push: {}
mod_push_keepalive: {}
mod_roster:
versioning: true
mod_shared_roster: {}
mod_stats: {}
mod_time: {}
mod_vcard:
search: false
mod_vcard_xupdate: {}
mod_version: {}
mod_stream_mgmt:
resend_on_timeout: if_offline
mod_s2s_dialback: {}
mod_http_api: {}
allow_contrib_modules: true
Any hints is greatly appreciated :-)
The problem in your configuration seems that you removed ejabberd_c2s listener. It is needed, and you can see it mentioned in the error message. So, the problem is solved by adding it, at least in my case, for example:
listen:
-
port: 5222
module: ejabberd_c2s
-
port: 8088
ip: "127.0.0.1"
module: ejabberd_http
request_handlers:
"/bosh": mod_bosh
web_admin: true
tls: false
Such a requirement is not mentioned in the ejabberd documentation, so I've added it now.
UPDATE: Forget everything below. Please see the answer from Badlop
Did a complete reinstall of ejabberd:
apt-get --purge autoremove ejabberd
(make sure /etc/ejabberd is empty)
apt-get update
apt-get upgrade
apt-get install ejabberd
Here the relevant parts of ejabberd.yml. I didn't change anything else:
hosts:
- "localhost"
- "chat3.myserver.com" <- the public domain
listen:
-
port: 5222
...
-
port: 5269
...
-
##port: 5280
port: 8088 <- use any port you like
ip: "127.0.0.1" <- listen only on localhost
module: ejabberd_http
request_handlers:
"/ws": ejabberd_http_ws
"/bosh": mod_bosh
"/api": mod_http_api
## "/pub/archive": mod_http_fileserver
web_admin: true
## register: true
## captcha: true
tls: false <- no need for tls on localhost
protocol_options: 'TLS_OPTIONS'
auth_method: sql
sql_type: mysql
sql_server: "server"
sql_database: "ejabberd_live"
sql_username: "ejabberd"
sql_password: "secret"
acl:
admin:
user:
- "": "localhost"
- "admin": "chat3.myserver.com"
And just if you are wondering about my proxy configuration in apache. These are the relevant lines of my chat3.myserver.com virtual host:
ProxyPass /http-bind/ http://127.0.0.1:8088/bosh
ProxyPassReverse /http-bind/ http://127.0.0.1:8088/bosh
ProxyPass /admin/ http://127.0.0.1:8088/admin/
ProxyPassReverse /admin/ http://127.0.0.1:8088/admin/
You will of cause also need to get the mysql database schema from here ... and so on...
I have no idea what caused the connection error. I guess the upgrade of ejabberd was somehow faulty. At least I am pretty sure that this was not a known bug. I crawled the internet for 4 hours without finding anything like it with this version of ejabberd (18.01). And also the error message - even under loglevel 5 - was extremely vague. If this had been a configuration error, I am sure the error messages would have been a lot more specific.
When i open in browser address http://127.0.0.1:5280/api/check_account
i get error
{"status":"error","code":32,"message":"AccessRules: Account does not have the right to perform the operation."}
Config:
port: 5280
ip: "127.0.0.1"
module: ejabberd_http
request_handlers:
"/websocket": ejabberd_http_ws
"/api": mod_http_api
register: true
web_admin: true
http_bind: true
captcha: false
api_permissions:
"API used from localhost allows all calls":
- who:
- ip: "127.0.0.1/8"
- what:
- "*"
- "!stop"
- "!start"
Make sure you are asking a POST request using this tow parameters: "user" and "host" . your navigator use a GET request and such request can't be handled since no operation is implemented on the API
POST /api/check_account
{
"user": "peter",
"host": "myserver.com"
}
Use tools like : PostMan or Fiddler to test Http Requests on your server
Read the docs here : https://docs.ejabberd.im/developer/ejabberd-api/admin-api/
I'm running ejabberd in Kubernetes using the following image: https://hub.docker.com/r/jprjr/ejabberd/
I've tried to test persistency by removing an account from Pidgin and adding it again. Pidgin does not load the previously added roster.
I tried Mnesia and Postgres. The Postgres database seems to be untouched by ejabberd but I don't get any erros in the logs either.
Any ideas, what could cause this behavior?
My configuration:
hosts: ["example.com"]
loglevel: 4
hide_sensitive_log_data: true
listen:
- port: 5222
module: ejabberd_c2s
access: c2s
shaper: c2s_shaper
zlib: true
starttls_required: true
starttls: true
certfile: "/etc/ejabberd/ejabberd.pem"
- port: 5269
module: ejabberd_s2s_in
shaper: s2s_shaper
max_stanza_size: 65536
s2s_use_starttls: true
s2s_certfile: "/etc/ejabberd/ejabberd.pem"
transport: tcp
auth_method: [ldap]
ldap_servers: ["ldap.example.com"]
ldap_port: 389
ldap_rootdn: "CN=ejabberd,OU=ServiceAccounts,DC=example,DC=com"
ldap_password: "*********"
ldap_base: "OU=User,DC=example,DC=com"
ldap_uids:
- "sAMAccountName": "%u"
ldap_filter: "(&(objectClass=user)(memberof=CN=ejabberdUsers,CN=Users,DC=example,DC=com))"
# tried with and w/o
# default_db: odbc
# sm_db_type: odbc
# odbc_type: pgsql
# odbc_server: "db.example.com"
# odbc_password: "********"
# odbc_port: 10051
shaper:
normal: 1000
fast: 50000
acl:
admin:
user:
"admin1": "example.com"
"admin2": "example.com"
access:
local:
local: allow
c2s:
blocked: deny
all: allow
ejabberd store roster persistently.
you need to enable mod_roster in ejabberd configuration file and database setting what you want for example
mod_roster:
db_type: odbc
it seems you are missing configuration for more detail of configuration check these links.
https://github.com/processone/ejabberd/blob/master/test/ejabberd_SUITE_data/ejabberd.yml
https://www.process-one.net/docs/ejabberd/guide_en.html