Re: [graylog2] Re: unable to receive syslog/tls from Cisco devices

[Jason Haar]

We got it working, so I thought I'd share the trick

Ended up the network guys had syslog/tls pointing at the IP address instead
of the hostname that is present in the cert. There is no way to disable
cert validation on Ciscos, so the Cisco was dropping the session due to the
name mismatch. Also it appears (on Cisco) you have to configure CRL for the
CA used to sign the graylog TLS cert. That sounds weird to me - but that's
what they did to make it work

logging enable
logging timestamp
logging buffer-size 8196
logging monitor debugging
logging buffered debugging
logging trap debugging
logging history debugging
logging asdm informational
logging queue 0
logging device-id hostname
logging host outside fqdn 6/portNUM secure
logging permit-hostdown
crypto ca trustpoint CA-who-signed-graylogCert
 enrollment terminal
 crl configure
  whatever goes here for your CA
crypto ca certificate chain CA-who-signed-graylogCert
 certificate ca xxx

This will then enable the Cisco to create a syslog/TLS session to the
graylog server, and then you'll have to add some extractors to actually
glean the information you want - the Cisco's are bad at that too.

But all working now :-)



-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/CAFChrgLjk0P6szsiJ9XdB6H3d%2B%2B1Rmi7hDvDu2pVRWNbJ%2Bmiag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Ideal multi-node VM setup on AWS

[wells]

The graylog size estimator recommends that I have 2 graylog servers, 3 
MongoDB instances, and 2 elasticsearch nodes.

First, I'm wondering how the extra MongoDB instance works with the 
graylog-ctl script. In the documentation, it only specifies how to set up a 
data node or a server node, not a MongoDB-only node.  Should I just set up 
3 server nodes with 3 MongoDB instances running, or is there a preferred 
way to separate the third MongoDB instance? 

Second, what instance type I should use for each? I was told in IRC a good 
size for the elasticsearch nodes is *m4.xlarge*. What about the server 
nodes? Certainly they use resources differently, so they can be different 
VM types. If there is an instance that only runs MongoDB (not in 
documentation), what VM size should that be?

I really appreciate any insight or help.

Best,
Wells

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/b3f0d716-794b-4fdf-a658-e496f87ea3c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] How do I set stopwords in server.conf

[Zhiyuan Lei]

I use elasticsearch_analyzer = standard in my graylog,and I have a message 
like this

2017-01-09 20:02:50,197 [x/x] - [(x,aa.bb,Y,645810f41483963370181610719839,1ms)]

Expected Behavior

expcected all terms like

Field terms:  xxx Y 645810f41483963370181610719839 1ms

the last comma should spit the last words.
Current Behavior

Field terms:  xxx Y 645810f41483963370181610719839,1ms

but last words 645810f41483963370181610719839,1ms was not splited.



maybe I can set stopwords to solve this problem, according 
this https://www.elastic.co/guide/en/elasticsearch/reference/2.3/analysis.html


does anyone have an idea?

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/fdd519af-595e-4cf0-975b-0fb794497ce4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] How do I set stopwords in server.conf

[Zhiyuan Lei]

I use elasticsearch_analyzer = standard in my graylog,and I have a message 
like this

2017-01-09 20:02:50,197 [x/x] - 
[(x,aa.bb,Y,645810f41483963370181610719839,1ms)]



## Expected Behavior



expcected all terms like


Field terms:  xxx Y 645810f41483963370181610719839 1ms


the last comma should spit the last words.

## Current Behavior



Field terms:  xxx Y 645810f41483963370181610719839,1ms


but last words `645810f41483963370181610719839,1ms` was not splited.
## Possible Solution



maybe I can set stopwords to solve this problem.

## Steps to Reproduce (for bugs)


1.
2.
3.
4.

## Context



## Your Environment


* Graylog Version:2.1.2
* Elasticsearch Version:2.3.0
* MongoDB Version:
* Operating System:
* Browser version:

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/701cfede-e100-4830-9ca1-f3100bcb9d9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [graylog2] problems connecting to the Graylog server with OVA

[victorfeng1973]

Resolved after enable ssl.

sudo graylog-ctl enforce-ssl
sudo graylog-ctl reconfigure

Here is the difference in nginx.conf before and after.
root@:/opt/graylog/conf/nginx# cat nginx.conf.orig
worker_processes  1;
daemon off;

events {
worker_connections  1024;
}

http {
include   /opt/graylog/conf/nginx/mime.types;
default_type  application/octet-stream;
log_formatgraylog_format  'nginx: $remote_addr - $remote_user 
[$time_local] "$request" $status $body_bytes_sent "$http_referer" 
"$http_user_agent" "$http_x_forwarded_for" 

Re: [graylog2] Re: Index rotation problem - "config not found"

[wells]

I see, thanks, that makes sense. I changed the servers anyway.

On Monday, January 9, 2017 at 2:52:42 PM UTC-5, Jochen Schalanda wrote:
>
> Hi Wells,
>
> On Monday, 9 January 2017 20:10:54 UTC+1, Wells Johnston wrote:
>>
>> I noticed that mistake and I thought I deleted that post! How are you 
>> still able to see it?
>>
>
> Each post on this Google Group is automatically sent out to the (email) 
> subscribers, see https://www.mail-archive.com/graylog2@googlegroups.com/ 
> for an independent mailing list archive of this group.
>
> If you delete a post, it's only deleted on the Google Groups web interface.
>
> Cheers,
> Jochen
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/096fe10b-fa3d-4c02-bdae-6d65839c71f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [graylog2] Re: Index rotation problem - "config not found"

[Jochen Schalanda]

Hi Wells,

On Monday, 9 January 2017 20:10:54 UTC+1, Wells Johnston wrote:
>
> I noticed that mistake and I thought I deleted that post! How are you 
> still able to see it?
>

Each post on this Google Group is automatically sent out to the (email) 
subscribers, see https://www.mail-archive.com/graylog2@googlegroups.com/ 
for an independent mailing list archive of this group.

If you delete a post, it's only deleted on the Google Groups web interface.

Cheers,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/6dd6490f-1890-4de1-a61c-437f24206ac0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: Index rotation problem - "config not found"

[wells]

I'm realizing now the mongo instance being wiped was part of a massive 
attack that happened a few days ago. This has been an eye-opening 
experience...lesson learned :(

Thank you for your help Jochen...

On Monday, January 9, 2017 at 1:26:07 PM UTC-5, Jochen Schalanda wrote:
>
> Hi,
>
> after seeing the IP address of your server in the first email (which by 
> the way was sent out to all subscribers of this Google Group), it looks 
> like you have (well, had) an unsecured MongoDB instance running which has 
> been wiped by a third party.
>
> $ mongo "${YOUR_IP_ADDRESS}:27017"
> MongoDB shell version v3.4.0
> connecting to: mongodb://${YOUR_IP_ADDRESS}:27017
> MongoDB server version: 3.2.5
> WARNING: shell and server versions do not match
> Server has startup warnings:
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] ** WARNING: 
> Insecure configuration, access control is not enabled and no --bind_ip has 
> been specified.
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] **  Read 
> and write access to data and configuration is unrestricted,
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] **  and 
> the server listens on all available network interfaces.
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: You 
> are running on a NUMA machine.
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **  We 
> suggest launching mongod like this to avoid performance problems:
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** 
>  numactl --interleave=all mongod [other options]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: 
> /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **We 
> suggest setting it to 'never'
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: 
> /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **We 
> suggest setting it to 'never'
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> > show dbs
> PLEASE_READ  0.000GB
> graylog  0.000GB
> > use PLEASE_READ
> switched to db PLEASE_READ
> > db.PLEASE_READ.find()
> { "_id" : ObjectId("58727dfa0c474c16c83c29a1"), "Info" : "Your DB is 
> Backed up at our servers, to restore send 0.1 BTC to the Bitcoin Address 
> then send an email with your server ip", "Bitcoin Address" : "xxx", "Email" 
> : "x...@example.com " }
> > use graylog
> switched to db graylog
> > show collections
> nodes
> notifications
> pipeline_processor_pipelines
> sessions
> users
> >
> bye
>
>
> I'm afraid your only chance is to restore a backup of the configuration, 
> which you hopefully have, and secure the MongoDB database properly.
>
> Please read 
> https://www.bleepingcomputer.com/news/security/mongodb-apocalypse-is-here-as-ransom-attacks-hit-10-000-servers/
>  
> and 
> https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data
>  
> to understand the issue at hand.
>
>
> Cheers,
> Jochen
>
> On Monday, 9 January 2017 19:15:17 UTC+1, Jochen Schalanda wrote:
>>
>> Hi Wells,
>>
>> what's the content of the cluster_config collection in MongoDB and 
>> specifically the document with "type" == 
>> "org.graylog2.indexer.management.IndexManagementConfig"?
>>
>> Example:
>>
>> $ mongo graylog
>> MongoDB shell version v3.4.0
>> connecting to: mongodb://127.0.0.1:27017/graylog
>> MongoDB server version: 3.4.0
>> > db.cluster_config.find({"type": 
>> "org.graylog2.indexer.management.IndexManagementConfig"}).pretty()
>> {
>> "_id" : ObjectId("566ff2a6d792d5a5bf0b3860"),
>> "type" : "org.graylog2.indexer.management.IndexManagementConfig",
>> "payload" : {
>> "rotation_strategy" : 
>> "org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy",
>> "retention_strategy" : 
>> "org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy"
>> },
>> "last_updated" : "2016-02-16T13:30:39.325Z",
>> "last_updated_by" : "cd03ee44-b2a7-4824-be16-bb7456149dbd"
>> }
>>
>>
>> Also check the documents with "type" == $rotation_strategy 
>> ("org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy" in 
>> this example) and $retention_strategy 
>> ("org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy" in 
>> this example).
>>
>> Cheers,
>> Jochen
>>
>> On Monday, 9 January 2017 19:05:18 UTC+1, we...@littlstar.com wrote:
>>>
>>> My graylog instance gave an error message suddenly a few days ago:
>>> No index management configuration found, not running index rotation! 
>>> Please fix your index rotation configuration!
>>>
>>> Going to the system/indices page 

Re: [graylog2] Re: Index rotation problem - "config not found"

[Wells Johnston]

I noticed that mistake and I thought I deleted that post! How are you still
able to see it?

Wiped by a third party?  What?? :|

On Mon, Jan 9, 2017 at 1:26 PM, Jochen Schalanda  wrote:

> Hi,
>
> after seeing the IP address of your server in the first email (which by
> the way was sent out to all subscribers of this Google Group), it looks
> like you have (well, had) an unsecured MongoDB instance running which has
> been wiped by a third party.
>
> $ mongo "${YOUR_IP_ADDRESS}:27017"
> MongoDB shell version v3.4.0
> connecting to: mongodb://${YOUR_IP_ADDRESS}:27017
> MongoDB server version: 3.2.5
> WARNING: shell and server versions do not match
> Server has startup warnings:
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] ** WARNING:
> Insecure configuration, access control is not enabled and no --bind_ip has
> been specified.
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] **  Read
> and write access to data and configuration is unrestricted,
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] **  and
> the server listens on all available network interfaces.
> 2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: You
> are running on a NUMA machine.
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **  We
> suggest launching mongod like this to avoid performance problems:
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **
>  numactl --interleave=all mongod [other options]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING:
> /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **We
> suggest setting it to 'never'
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING:
> /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **We
> suggest setting it to 'never'
> 2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> > show dbs
> PLEASE_READ  0.000GB
> graylog  0.000GB
> > use PLEASE_READ
> switched to db PLEASE_READ
> > db.PLEASE_READ.find()
> { "_id" : ObjectId("58727dfa0c474c16c83c29a1"), "Info" : "Your DB is
> Backed up at our servers, to restore send 0.1 BTC to the Bitcoin Address
> then send an email with your server ip", "Bitcoin Address" : "xxx", "Email"
> : "x...@example.com" }
> > use graylog
> switched to db graylog
> > show collections
> nodes
> notifications
> pipeline_processor_pipelines
> sessions
> users
> >
> bye
>
>
> I'm afraid your only chance is to restore a backup of the configuration,
> which you hopefully have, and secure the MongoDB database properly.
>
> Please read https://www.bleepingcomputer.com/news/
> security/mongodb-apocalypse-is-here-as-ransom-attacks-hit-10-000-servers/
> and https://www.mongodb.com/blog/post/how-to-avoid-a-
> malicious-attack-that-ransoms-your-data to understand the issue at hand.
>
>
> Cheers,
> Jochen
>
>
> On Monday, 9 January 2017 19:15:17 UTC+1, Jochen Schalanda wrote:
>>
>> Hi Wells,
>>
>> what's the content of the cluster_config collection in MongoDB and
>> specifically the document with "type" == "org.graylog2.indexer.manageme
>> nt.IndexManagementConfig"?
>>
>> Example:
>>
>> $ mongo graylog
>> MongoDB shell version v3.4.0
>> connecting to: mongodb://127.0.0.1:27017/graylog
>> MongoDB server version: 3.4.0
>> > db.cluster_config.find({"type": "org.graylog2.indexer.manageme
>> nt.IndexManagementConfig"}).pretty()
>> {
>> "_id" : ObjectId("566ff2a6d792d5a5bf0b3860"),
>> "type" : "org.graylog2.indexer.management.IndexManagementConfig",
>> "payload" : {
>> "rotation_strategy" : "org.graylog2.indexer.rotation
>> .strategies.TimeBasedRotationStrategy",
>> "retention_strategy" : "org.graylog2.indexer.retentio
>> n.strategies.DeletionRetentionStrategy"
>> },
>> "last_updated" : "2016-02-16T13:30:39.325Z",
>> "last_updated_by" : "cd03ee44-b2a7-4824-be16-bb7456149dbd"
>> }
>>
>>
>> Also check the documents with "type" == $rotation_strategy
>> ("org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy" in
>> this example) and $retention_strategy ("org.graylog2.indexer.retenti
>> on.strategies.DeletionRetentionStrategy" in this example).
>>
>> Cheers,
>> Jochen
>>
>> On Monday, 9 January 2017 19:05:18 UTC+1, we...@littlstar.com wrote:
>>>
>>> My graylog instance gave an error message suddenly a few days ago:
>>> No index management configuration found, not running index rotation!
>>> Please fix your index rotation configuration!
>>>
>>> Going to the system/indices page on the web ui, this error appeared
>>> twice:
>>> Could not retrieve retention config
>>> Fetching retention config 

[graylog2] Re: Index rotation problem - "config not found"

[Jochen Schalanda]

Hi,

after seeing the IP address of your server in the first email (which by the 
way was sent out to all subscribers of this Google Group), it looks like 
you have (well, had) an unsecured MongoDB instance running which has been 
wiped by a third party.

$ mongo "${YOUR_IP_ADDRESS}:27017"
MongoDB shell version v3.4.0
connecting to: mongodb://${YOUR_IP_ADDRESS}:27017
MongoDB server version: 3.2.5
WARNING: shell and server versions do not match
Server has startup warnings:
2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten]
2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] ** WARNING: 
Insecure configuration, access control is not enabled and no --bind_ip has 
been specified.
2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] **  Read 
and write access to data and configuration is unrestricted,
2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten] **  and the 
server listens on all available network interfaces.
2017-01-06T17:52:44.708-0500 I CONTROL  [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: You are 
running on a NUMA machine.
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **  We 
suggest launching mongod like this to avoid performance problems:
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** 
 numactl --interleave=all mongod [other options]
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: 
/sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **We 
suggest setting it to 'never'
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] ** WARNING: 
/sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten] **We 
suggest setting it to 'never'
2017-01-06T17:52:44.709-0500 I CONTROL  [initandlisten]
> show dbs
PLEASE_READ  0.000GB
graylog  0.000GB
> use PLEASE_READ
switched to db PLEASE_READ
> db.PLEASE_READ.find()
{ "_id" : ObjectId("58727dfa0c474c16c83c29a1"), "Info" : "Your DB is Backed 
up at our servers, to restore send 0.1 BTC to the Bitcoin Address then send 
an email with your server ip", "Bitcoin Address" : "xxx", "Email" : 
"x...@example.com" }
> use graylog
switched to db graylog
> show collections
nodes
notifications
pipeline_processor_pipelines
sessions
users
>
bye


I'm afraid your only chance is to restore a backup of the configuration, 
which you hopefully have, and secure the MongoDB database properly.

Please 
read 
https://www.bleepingcomputer.com/news/security/mongodb-apocalypse-is-here-as-ransom-attacks-hit-10-000-servers/
 
and 
https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data
 
to understand the issue at hand.


Cheers,
Jochen

On Monday, 9 January 2017 19:15:17 UTC+1, Jochen Schalanda wrote:
>
> Hi Wells,
>
> what's the content of the cluster_config collection in MongoDB and 
> specifically the document with "type" == 
> "org.graylog2.indexer.management.IndexManagementConfig"?
>
> Example:
>
> $ mongo graylog
> MongoDB shell version v3.4.0
> connecting to: mongodb://127.0.0.1:27017/graylog
> MongoDB server version: 3.4.0
> > db.cluster_config.find({"type": 
> "org.graylog2.indexer.management.IndexManagementConfig"}).pretty()
> {
> "_id" : ObjectId("566ff2a6d792d5a5bf0b3860"),
> "type" : "org.graylog2.indexer.management.IndexManagementConfig",
> "payload" : {
> "rotation_strategy" : 
> "org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy",
> "retention_strategy" : 
> "org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy"
> },
> "last_updated" : "2016-02-16T13:30:39.325Z",
> "last_updated_by" : "cd03ee44-b2a7-4824-be16-bb7456149dbd"
> }
>
>
> Also check the documents with "type" == $rotation_strategy 
> ("org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy" in 
> this example) and $retention_strategy 
> ("org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy" in 
> this example).
>
> Cheers,
> Jochen
>
> On Monday, 9 January 2017 19:05:18 UTC+1, we...@littlstar.com wrote:
>>
>> My graylog instance gave an error message suddenly a few days ago:
>> No index management configuration found, not running index rotation! 
>> Please fix your index rotation configuration!
>>
>> Going to the system/indices page on the web ui, this error appeared twice:
>> Could not retrieve retention config
>> Fetching retention config failed: Error: cannot GET http://> address>:9000/api/system/indices/retention/config 
>>  (500)
>>
>> When I tried to check/update the index rotation strategy with the "update 
>> configuration" button, it just left me with spinners, never loading any 
>> config. I then tried to find index rotation 

[graylog2] Re: Index rotation problem - "config not found"

[Jochen Schalanda]

Hi Wells,

what's the content of the cluster_config collection in MongoDB and 
specifically the document with "type" == 
"org.graylog2.indexer.management.IndexManagementConfig"?

Example:

$ mongo graylog
MongoDB shell version v3.4.0
connecting to: mongodb://127.0.0.1:27017/graylog
MongoDB server version: 3.4.0
> db.cluster_config.find({"type": 
"org.graylog2.indexer.management.IndexManagementConfig"}).pretty()
{
"_id" : ObjectId("566ff2a6d792d5a5bf0b3860"),
"type" : "org.graylog2.indexer.management.IndexManagementConfig",
"payload" : {
"rotation_strategy" : 
"org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy",
"retention_strategy" : 
"org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy"
},
"last_updated" : "2016-02-16T13:30:39.325Z",
"last_updated_by" : "cd03ee44-b2a7-4824-be16-bb7456149dbd"
}


Also check the documents with "type" == $rotation_strategy 
("org.graylog2.indexer.rotation.strategies.TimeBasedRotationStrategy" in 
this example) and $retention_strategy 
("org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy" in 
this example).

Cheers,
Jochen

On Monday, 9 January 2017 19:05:18 UTC+1, we...@littlstar.com wrote:
>
> My graylog instance gave an error message suddenly a few days ago:
> No index management configuration found, not running index rotation! 
> Please fix your index rotation configuration!
>
> Going to the system/indices page on the web ui, this error appeared twice:
> Could not retrieve retention config
> Fetching retention config failed: Error: cannot GET http:// address>:9000/api/system/indices/retention/config 
>  (500)
>
> When I tried to check/update the index rotation strategy with the "update 
> configuration" button, it just left me with spinners, never loading any 
> config. I then tried to find index rotation config files on the server:
>
>- /system/indices/rotation/config
>- /system/indices/retention/config
>
> But neither of those paths exist. I seem to have lost all inputs, streams, 
> dashboards etc. What happened here? What can I do?
>
> I am using graylog version 2.1, using the AWS VM setup with two nodes.
>
> Any help would be greatly appreciated.
>
> Best,
> Wells
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/c95806ca-1c9b-4f8f-9d55-e2d1c1cbf592%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Index rotation problem - "config not found"

[wells]

My graylog instance gave an error message suddenly a few days ago:
No index management configuration found, not running index rotation! Please 
fix your index rotation configuration!

Going to the system/indices page on the web ui, this error appeared twice:
Could not retrieve retention config
Fetching retention config failed: Error: cannot GET http://:9000/api/system/indices/retention/config 
 (500)

When I tried to check/update the index rotation strategy with the "update 
configuration" button, it just left me with spinners, never loading any 
config. I then tried to find index rotation config files on the server:

   - /system/indices/rotation/config
   - /system/indices/retention/config

But neither of those paths exist. I seem to have lost all inputs, streams, 
dashboards etc. What happened here? What can I do?

I am using graylog version 2.1, using the AWS VM setup with two nodes.

Any help would be greatly appreciated.

Best,
Wells

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/8f6c96fa-b339-44b2-9c57-40e9e0ab89f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Index rotation problem - "config not found"

[wells]

My graylog instance gave an error message suddenly a few days ago:
No index management configuration found, not running index rotation! Please 
fix your index rotation configuration!

Going to the system/indices page on the web ui, this error appeared twice:
Could not retrieve retention config
Fetching retention config failed: Error: cannot GET 
http://54.173.34.148:9000/api/system/indices/retention/config (500)

When I tried to check/update the index rotation strategy with the "update 
configuration" button, it just left me with spinners, never loading any 
config. I then tried to find index rotation config files on the server:

   - /system/indices/rotation/config
   - /system/indices/retention/config

But neither of those paths exist. I seem to have lost all inputs, streams, 
dashboards etc. What happened here? What can I do?

I am using graylog version 2.1, using the AWS VM setup with two nodes.

Any help would be greatly appreciated.

Best,
Wells

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/8c7ae7e7-384b-4e02-baa4-be1d32708b90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: API token different response

[Jochen Schalanda]

Hi Norbert,

On Monday, 9 January 2017 13:07:55 UTC+1, Norbert Kiss wrote:
>
> Unfortunately based on our security policy I can't share more that I did 
> it before, but now I show the full process.
>

In that case I can only tell you that the whole access token functionality 
works for me™.

As a last straw, make sure that the access token authentication provider is 
activated on the System / Authentication page.

Working example:

$ curl -i -u admin:admin -H 'Accept: application/json' -X POST 
'http://127.0.0.1:9000/api/users/admin/tokens/test-token?pretty=true'
HTTP/1.1 200 OK
X-Graylog-Node-ID: cd03ee44-b2a7-4824-be16-bb7456149dbd
Content-Type: application/json
Date: Mon, 09 Jan 2017 15:14:18 GMT
Content-Length: 141

{
  "name" : "test-token",
  "token" : "1o258cojhut0sjj9dqaogqfohkdpns85d5i840cu02913o3nn9ks",
  "last_access" : "1970-01-01T00:00:00.000Z"
} 

$ curl -i -u 1o258cojhut0sjj9dqaogqfohkdpns85d5i840cu02913o3nn9ks:token 
http://127.0.0.1:9000/api/system?pretty=true
HTTP/1.1 200 OK
X-Graylog-Node-ID: cd03ee44-b2a7-4824-be16-bb7456149dbd
X-Runtime-Microseconds: 36657
Content-Type: application/json
Date: Mon, 09 Jan 2017 15:15:02 GMT
Content-Length: 441

{
  "facility" : "graylog-server",
  "codename" : "Stiegl",
  "node_id" : "cd03ee44-b2a7-4824-be16-bb7456149dbd",
  "cluster_id" : "b1ce3a29-6845-4e00-bd8c-d4499dc9e95d",
  "version" : "2.2.0-rc.1-SNAPSHOT",
  "started_at" : "2017-01-09T15:13:27.589Z",
  "hostname" : "joschi-mbp15.lan",
  "lifecycle" : "running",
  "lb_status" : "alive",
  "timezone" : "Europe/Berlin",
  "operating_system" : "Mac OS X 10.12.2",
  "is_processing" : true
} 

$ curl -i -u admin:admin -H 'Accept: application/json' -X GET 
'http://127.0.0.1:9000/api/users/admin/tokens/?pretty=true'
HTTP/1.1 200 OK
X-Graylog-Node-ID: cd03ee44-b2a7-4824-be16-bb7456149dbd
Content-Type: application/json
Date: Mon, 09 Jan 2017 15:15:45 GMT
Content-Length: 319

{
  "tokens" : [ {
"name" : "test-1234",
"token" : "8oe6l5b0db378b0qfsufa1j9jr4bnlvng1m6o998rag8fcmusj1",
"last_access" : "2016-08-08T12:14:46.431Z"
  }, {
"name" : "test-token",
"token" : "1o258cojhut0sjj9dqaogqfohkdpns85d5i840cu02913o3nn9ks",
"last_access" : "2017-01-09T15:15:02.670Z"
  } ]
} 

$ curl -i -u admin:admin -H 'Accept: application/json' -X DELETE 
'http://127.0.0.1:9000/api/users/admin/tokens/1o258cojhut0sjj9dqaogqfohkdpns85d5i840cu02913o3nn9ks?pretty=true'
HTTP/1.1 204 No Content
X-Graylog-Node-ID: cd03ee44-b2a7-4824-be16-bb7456149dbd
Date: Mon, 09 Jan 2017 15:16:02 GMT

$ curl -i -u admin:admin -H 'Accept: application/json' -X GET 
'http://127.0.0.1:9000/api/users/admin/tokens/?pretty=true'
HTTP/1.1 200 OK
X-Graylog-Node-ID: cd03ee44-b2a7-4824-be16-bb7456149dbd
Content-Type: application/json
Date: Mon, 09 Jan 2017 15:16:05 GMT
Content-Length: 168

{
  "tokens" : [ {
"name" : "test-1234",
"token" : "8oe6l5b0db378b0qfsufa1j9jr4bnlvng1m6o998rag8fcmusj1",
"last_access" : "2016-08-08T12:14:46.431Z"
  } ]
}


Cheers,
Jochen 

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/1a47d43c-98bf-49f1-8afc-95ec77a73438%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: API token different response

[Norbert Kiss]

sorry, I forgot 1 thing, I can access with the token to the following URL:
IP:9000/api/system/cluster/stats/elasticsearch

2017. január 9., hétfő 13:07:55 UTC+1 időpontban Norbert Kiss a következőt 
írta:
>
> Hi
>
> Unfortunately based on our security policy I can't share more that I did 
> it before, but now I show the full process.
>
> Norbert
>
> [root@nagios-master ~]# curl -u root:XX -H 'Accept: application/json' -X 
> POST 'http://IP:9000/api/users/root/tokens/monitor?pretty=true' -i
> HTTP/1.1 200 OK
> X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
> Content-Type: application/json
> Date: Mon, 09 Jan 2017 12:01:47 GMT
> Content-Length: 138
>
> {
>   "name" : "monitor",
>   "token" : "1nju0tc889slbv1c86n798fdjdgrs4jl7dk3gnsk1uc807bcj64u",
>   "last_access" : "1970-01-01T00:00:00.000Z"
> }[root@nagios-master ~]#
> [root@nagios-master ~]# curl  http://IP:9000/api/system  -u 
> 1nju0tc889slbv1c86n798fdjdgrs4jl7dk3gnsk1uc807bcj64u:token  -i
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Basic realm="Graylog Server"
> X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
> X-Runtime-Microseconds: 364
> Date: Mon, 09 Jan 2017 12:02:16 GMT
> Content-Length: 0
>
> [root@nagios-master ~]# curl  http://IP:9000/api/system  -u root:XX  -i
> HTTP/1.1 200 OK
> X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
> X-Runtime-Microseconds: 1115
> Content-Type: application/json
> Date: Mon, 09 Jan 2017 12:02:33 GMT
> Content-Length: 402
>
> {"facility":"graylog-server","codename":"Smuttynose","node_id":"0ccf3479-4c38-401b-84a3-dbcfd4badcdb","cluster_id":"c43b5005-0262-4ac5-8afe-6ead71f1ae00","version":"2.1.2+50e449a","started_at":"2017-01-05T09:40:58.192Z","hostname":"XX","lifecycle":"running","lb_status":"alive","timezone":"Europe/Budapest","operating_system":"Linux
>  
> 3.10.0-514.2.2.el7.x86_64","is_processing":true}[root@nagios-master ~]#
> [root@nagios-master ~]# curl -u root:XX -H 'Accept: application/json' -X 
> GET 'http://IP:9000/api/users/root/tokens/?pretty=true' -i
> HTTP/1.1 200 OK
> X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
> Content-Type: application/json
> Date: Mon, 09 Jan 2017 12:02:56 GMT
> Content-Length: 318
>
> {
>   "tokens" : [ {
> "name" : "XX",
> "token" : "XX",
> "last_access" : "1970-01-01T00:00:00.000Z"
>   }, {
> "name" : "monitor",
> "token" : "1nju0tc889slbv1c86n798fdjdgrs4jl7dk3gnsk1uc807bcj64u",
> "last_access" : "1970-01-01T00:00:00.000Z"
>   } ]
> }[root@nagios-master ~]#
>
>
> 2017. január 9., hétfő 12:39:42 UTC+1 időpontban Jochen Schalanda a 
> következőt írta:
>>
>> Hi Norbert,
>>
>> see 
>> http://docs.graylog.org/en/2.1/pages/configuration/rest_api.html#creating-and-using-access-token
>>  
>> for instructions about using access tokens with the Graylog REST API.
>>
>> If, after reading the documentation carefully, you're still unable to 
>> make the access token work, please post your complete curl commands and do 
>> not obfuscate any data (except maybe the username and the password you're 
>> creating the token with).
>>
>> Cheers,
>> Jochen
>>
>> On Monday, 9 January 2017 12:03:45 UTC+1, Norbert Kiss wrote:
>>>
>>> Hi
>>>
>>> What I did wrong?
>>>
>>> I create a token, and if I try to use the token to get an url under 
>>> /api/system , I get Unauthorized back.
>>>
>>> Thanks,
>>>
>>> Norbert
>>>
>>>
>>> curl -u USER:PASS -H 'Accept: application/json' -X GET 
>>> 'http://IP:9000/api/users/USER/tokens?pretty=true'
>>> {
>>>   "tokens" : [ {
>>> "name" : "NAME",
>>> "token" : "TOKENID",
>>> "last_access" : "1970-01-01T00:00:00.000Z"
>>>   } ]
>>> }
>>>
>>> curl http://IP:9000/api/system -u TOKENID:token -i
>>> HTTP/1.1 401 Unauthorized
>>> WWW-Authenticate: Basic realm="Graylog Server"
>>> X-Graylog-Node-ID: XX
>>> X-Runtime-Microseconds: 490
>>> Date: Mon, 09 Jan 2017 10:58:23 GMT
>>> Content-Length: 0
>>>
>>>
>>> curl http://IP:9000/api/system -u USER:PASS -i
>>> HTTP/1.1 200 OK
>>> X-Graylog-Node-ID: XX
>>> X-Runtime-Microseconds: 244491
>>> Content-Type: application/json
>>> Date: Mon, 09 Jan 2017 10:58:40 GMT
>>> Content-Length: 402
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/12fd6591-214c-4258-9115-11db7d1a1a0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: API token different response

[Norbert Kiss]

Hi

Unfortunately based on our security policy I can't share more that I did it 
before, but now I show the full process.

Norbert

[root@nagios-master ~]# curl -u root:XX -H 'Accept: application/json' -X 
POST 'http://IP:9000/api/users/root/tokens/monitor?pretty=true' -i
HTTP/1.1 200 OK
X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
Content-Type: application/json
Date: Mon, 09 Jan 2017 12:01:47 GMT
Content-Length: 138

{
  "name" : "monitor",
  "token" : "1nju0tc889slbv1c86n798fdjdgrs4jl7dk3gnsk1uc807bcj64u",
  "last_access" : "1970-01-01T00:00:00.000Z"
}[root@nagios-master ~]#
[root@nagios-master ~]# curl  http://IP:9000/api/system  -u 
1nju0tc889slbv1c86n798fdjdgrs4jl7dk3gnsk1uc807bcj64u:token  -i
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Graylog Server"
X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
X-Runtime-Microseconds: 364
Date: Mon, 09 Jan 2017 12:02:16 GMT
Content-Length: 0

[root@nagios-master ~]# curl  http://IP:9000/api/system  -u root:XX  -i
HTTP/1.1 200 OK
X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
X-Runtime-Microseconds: 1115
Content-Type: application/json
Date: Mon, 09 Jan 2017 12:02:33 GMT
Content-Length: 402

{"facility":"graylog-server","codename":"Smuttynose","node_id":"0ccf3479-4c38-401b-84a3-dbcfd4badcdb","cluster_id":"c43b5005-0262-4ac5-8afe-6ead71f1ae00","version":"2.1.2+50e449a","started_at":"2017-01-05T09:40:58.192Z","hostname":"XX","lifecycle":"running","lb_status":"alive","timezone":"Europe/Budapest","operating_system":"Linux
 
3.10.0-514.2.2.el7.x86_64","is_processing":true}[root@nagios-master ~]#
[root@nagios-master ~]# curl -u root:XX -H 'Accept: application/json' -X 
GET 'http://IP:9000/api/users/root/tokens/?pretty=true' -i
HTTP/1.1 200 OK
X-Graylog-Node-ID: 0ccf3479-4c38-401b-84a3-dbcfd4badcdb
Content-Type: application/json
Date: Mon, 09 Jan 2017 12:02:56 GMT
Content-Length: 318

{
  "tokens" : [ {
"name" : "XX",
"token" : "XX",
"last_access" : "1970-01-01T00:00:00.000Z"
  }, {
"name" : "monitor",
"token" : "1nju0tc889slbv1c86n798fdjdgrs4jl7dk3gnsk1uc807bcj64u",
"last_access" : "1970-01-01T00:00:00.000Z"
  } ]
}[root@nagios-master ~]#


2017. január 9., hétfő 12:39:42 UTC+1 időpontban Jochen Schalanda a 
következőt írta:
>
> Hi Norbert,
>
> see 
> http://docs.graylog.org/en/2.1/pages/configuration/rest_api.html#creating-and-using-access-token
>  
> for instructions about using access tokens with the Graylog REST API.
>
> If, after reading the documentation carefully, you're still unable to make 
> the access token work, please post your complete curl commands and do not 
> obfuscate any data (except maybe the username and the password you're 
> creating the token with).
>
> Cheers,
> Jochen
>
> On Monday, 9 January 2017 12:03:45 UTC+1, Norbert Kiss wrote:
>>
>> Hi
>>
>> What I did wrong?
>>
>> I create a token, and if I try to use the token to get an url under 
>> /api/system , I get Unauthorized back.
>>
>> Thanks,
>>
>> Norbert
>>
>>
>> curl -u USER:PASS -H 'Accept: application/json' -X GET 
>> 'http://IP:9000/api/users/USER/tokens?pretty=true'
>> {
>>   "tokens" : [ {
>> "name" : "NAME",
>> "token" : "TOKENID",
>> "last_access" : "1970-01-01T00:00:00.000Z"
>>   } ]
>> }
>>
>> curl http://IP:9000/api/system -u TOKENID:token -i
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: Basic realm="Graylog Server"
>> X-Graylog-Node-ID: XX
>> X-Runtime-Microseconds: 490
>> Date: Mon, 09 Jan 2017 10:58:23 GMT
>> Content-Length: 0
>>
>>
>> curl http://IP:9000/api/system -u USER:PASS -i
>> HTTP/1.1 200 OK
>> X-Graylog-Node-ID: XX
>> X-Runtime-Microseconds: 244491
>> Content-Type: application/json
>> Date: Mon, 09 Jan 2017 10:58:40 GMT
>> Content-Length: 402
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/21b13aaf-bac4-469d-9704-6317ed1fb759%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: API token different response

[Jochen Schalanda]

Hi Norbert,

see 
http://docs.graylog.org/en/2.1/pages/configuration/rest_api.html#creating-and-using-access-token
 
for instructions about using access tokens with the Graylog REST API.

If, after reading the documentation carefully, you're still unable to make 
the access token work, please post your complete curl commands and do not 
obfuscate any data (except maybe the username and the password you're 
creating the token with).

Cheers,
Jochen

On Monday, 9 January 2017 12:03:45 UTC+1, Norbert Kiss wrote:
>
> Hi
>
> What I did wrong?
>
> I create a token, and if I try to use the token to get an url under 
> /api/system , I get Unauthorized back.
>
> Thanks,
>
> Norbert
>
>
> curl -u USER:PASS -H 'Accept: application/json' -X GET 
> 'http://IP:9000/api/users/USER/tokens?pretty=true'
> {
>   "tokens" : [ {
> "name" : "NAME",
> "token" : "TOKENID",
> "last_access" : "1970-01-01T00:00:00.000Z"
>   } ]
> }
>
> curl http://IP:9000/api/system -u TOKENID:token -i
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Basic realm="Graylog Server"
> X-Graylog-Node-ID: XX
> X-Runtime-Microseconds: 490
> Date: Mon, 09 Jan 2017 10:58:23 GMT
> Content-Length: 0
>
>
> curl http://IP:9000/api/system -u USER:PASS -i
> HTTP/1.1 200 OK
> X-Graylog-Node-ID: XX
> X-Runtime-Microseconds: 244491
> Content-Type: application/json
> Date: Mon, 09 Jan 2017 10:58:40 GMT
> Content-Length: 402
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/e0280d91-80f4-41e7-8547-da81f7ee4bb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [graylog2] Re: unable to receive syslog/tls from Cisco devices

[Jason Haar]

On Mon, Jan 9, 2017 at 9:20 PM, Jochen Schalanda  wrote:

> if you're using TLS client certificates


No - the cisco doesn't support that anyway. The java error says
"javax.net.ssl.SSLException: Received fatal alert: certificate_unknown",
and wireshark confirms the TLS alert comes from the *client* - not the
server. It seems to me the Cisco ASA doesn't trust the server cert or the
CA that signed it - but I'm not a Cisco engineer and apparently our ones
have never done this before and don't know any better either :-)

I was hoping someone on this list had been through the drama.

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/CAFChrgKDG5SqkiiS%2BPFzEG6m-%2Byre%3DdazZuH8%3Dufm%2B8LwLD54Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] API token different response

[Norbert Kiss]

Hi

What I did wrong?

I create a token, and if I try to use the token to get an url under /api/system 
, I get Unauthorized back.

Thanks,

Norbert


curl -u USER:PASS -H 'Accept: application/json' -X GET 
'http://IP:9000/api/users/USER/tokens?pretty=true'
{
  "tokens" : [ {
"name" : "NAME",
"token" : "TOKENID",
"last_access" : "1970-01-01T00:00:00.000Z"
  } ]
}

curl http://IP:9000/api/system -u TOKENID:token -i
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Graylog Server"
X-Graylog-Node-ID: XX
X-Runtime-Microseconds: 490
Date: Mon, 09 Jan 2017 10:58:23 GMT
Content-Length: 0


curl http://IP:9000/api/system -u USER:PASS -i
HTTP/1.1 200 OK
X-Graylog-Node-ID: XX
X-Runtime-Microseconds: 244491
Content-Type: application/json
Date: Mon, 09 Jan 2017 10:58:40 GMT
Content-Length: 402


-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/cffa4170-fe2f-4db9-804e-90bd419f840a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: mongodb down and settings lost

[Jochen Schalanda]

Hi Sven,

On Monday, 9 January 2017 11:23:01 UTC+1, Sven Lieckfeldt wrote:
>
> Any help would be appreciated to get my config back and running.
>

Many settings in MongoDB from Graylog 1.3.x are compatible with Graylog 2.x 
or will automatically be migrated.

Unless you have success recovering the damaged MongoDB database in a 
(near-) current state, you can try restoring the old backup from Graylog 
1.3.x and use it with Graylog 2.x.

Cheers,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/7cf58767-55b5-486d-b422-49eb5a0ca49c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: Graylog 2.1 SSO Plugin with Shibboleth

[Jochen Schalanda]

Hi Florent,

On Monday, 9 January 2017 11:24:21 UTC+1, Florent Delvaille wrote:
>
> Anybody has any news about this problematic?
>

You can subscribe to 
https://github.com/Graylog2/graylog-plugin-auth-sso/issues/17 to stay 
up-to-date about the progress on this issue.

Cheers,
Jochen 

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/5cb03dcf-80c2-4ea5-a651-a592cd3ec134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: Graylog 2.1 SSO Plugin with Shibboleth

[Florent Delvaille]

Hep,

Anybody has any news about this problematic?

Thx in advance.

Regards;

On Thursday, December 22, 2016 at 9:56:43 AM UTC+1, Florent Delvaille wrote:
>
> Hello all,
>
> I'm currently trying to use Graylog 2.1 with Shibboleth and SSO via our 
> ADFS, but I have issues and cannot find enough information to make it work. 
> So, let's try here :)
>
> I've correctly installed the sso-plugin (
> https://github.com/Graylog2/graylog-plugin-auth-sso).
> Also, I've installed shibboleth + configured ADFS correctly with 
> Metadata.xml and so on.
>
> Our AD expert confirms that the exchange made between Shibboleth and ADFS 
> is correct and works fine.
>
> I've change the Graylog authentication order, and set SSO as first.
>
> When I'm trying to log, I got a window asking for credentials (so it goes 
> to ADFS correctly), but then even if validated by ADFS, I always end into 
> normal graylog credentials window …
>
> ADFS will provide the following claims to Shibboleth:
> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn; 
> nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" 
> id="Remote-Upn" />
> http://schemas.xmlsoap.org/claims/commonname; 
> nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" 
> id="Remote-Name" />
>
> As you can see, I set the id to Remote-Upn and Remote-Name.
>
> I've also correctly configured Graylog (in web interface) to make sure to 
> use Remote-Upn and Remote-Name (
> http://docs.graylog.org/en/2.1/_images/sso_1.png)
>
> Please note that I'm using graylog with HTTPS, and use Apache as 
> reverse-proxy:
> 
> SSLEngine on
> SSLCertificateFile  "/etc/graylog/ssl/graylog.onprvp.fgov.be.cer"
> SSLCertificateKeyFile   "/etc/graylog/ssl/graylog.onprvp.fgov.be.key"
>
> ServerName graylog.onprvp.fgov.be
> ProxyRequests Off
> 
>   Order deny,allow
>   Allow from all
> 
>
> 
> RequestHeader set X-Graylog-Server-URL "
> https://graylog.onprvp.fgov.be/api/;
> RequestHeader set X-Remote-User %{Remote-Upn}s
> ShibRequestSetting requireSession 1
> AuthType shibboleth
> ShibExportAssertion Off
> Require valid-user
> ProxyPass http://127.0.0.1:9000/
> ProxyPassReverse http://127.0.0.1:9000/
> 
> CustomLog /var/log/httpd/proxy/graylog2/access_log combined
>
> 
>
>
> If somebody can provide me some help, it would be really nice :)
>
> Thanks in advance.
>
> Regards;
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/88407aeb-b2bc-4b49-83b9-a3fcf6042a41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] mongodb down and settings lost

[Sven Lieckfeldt]

Hi there,

over the holidays our graylog server crashed due to a full hdd. I've set 
indices by size and count, but for some reason that hasn't worked as 
expected. 
However graylog services were stopped over holidays and now I have trouble 
to recover it.
I removed indices via -XDELETE to get free space.
I tried to repair the mongodb graylog and local. But settings are lost. I 
only have a backup from October with Graylog Release 1.3. Unfortunately, 
even if I know it better, I didn't created a backup before I made the 
repair.
So that would be my recovery plan. But I've made many changes to the 
Dashboards and would prefer to recover it.

Any help would be appreciated to get my config back and running.

Thanks!

ubuntu@graylogserver:~$ sudo ls /var/opt/graylog/data/mongodb -lah
total 161M
drwxr-x--- 6 graylog graylog 4.0K Jan  9 09:23 .
drwxr-x--- 7 graylog graylog 4.0K Oct 28 14:17 ..
drwx-- 2 graylog graylog 4.0K Dec 26 04:05 diagnostic.data
drwxr-xr-x 2 rootroot4.0K Jan  9 09:17 graylog
-rw--- 1 rootroot 64M Jan  9 09:21 graylog.0
-rw--- 1 rootroot 16M Jan  9 09:21 graylog.ns
drwx-- 2 graylog graylog 4.0K Jan  9 09:23 journal
drwxr-xr-x 2 rootroot4.0K Jan  9 09:17 local
-rw--- 1 rootroot 64M Jan  9 09:21 local.0
-rw--- 1 rootroot 16M Jan  9 09:21 local.ns
-rwx-- 1 graylog graylog5 Jan  9 09:23 mongod.lock
-rw--- 1 graylog graylog   69 Sep 17  2015 storage.bson

ubuntu@graylogserver:~$ sudo graylog-ctl status
run: elasticsearch: (pid 6191) 13s; run: log: (pid 856) 2029s
run: etcd: (pid 6219) 13s; run: log: (pid 855) 2029s
run: graylog-server: (pid 6228) 13s; run: log: (pid 859) 2029s
down: mongodb: 1s, normally up, want up; run: log: (pid 857) 2029s
run: nginx: (pid 6275) 7s; run: log: (pid 858) 2029s


-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/79ea2bba-ff56-4c92-a543-8f0293967e4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: Graylog - Edit extractor - Slow

[Florent Delvaille]

Hello,

sorry for the delay.
We're using 2.0.2-1 in production.

But we've just installed on another DC, version 2.1.2-1, but we don't have 
any messages redirected to it at the  moment.

Is the version currently used in production contain the bug you're talking 
about ?

Thx.

Regards;

On Thursday, December 29, 2016 at 4:32:37 AM UTC+1, Drew Miranda wrote:
>
> What version are you running? I believe the was a bug with the gzip 
> compression used in the rest API output which has since been resolved in 
> the current version.

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/62135014-14bb-445c-ba66-77d6ccc616d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: unable to receive syslog/tls from Cisco devices

[Jochen Schalanda]

Hi Jason,

if you're using TLS client certificates (and client certificate 
verification), you either have to add the CA certificate or all the client 
certificates to the JVM's trust store, 
see 
http://docs.graylog.org/en/2.1/pages/configuration/https.html#adding-a-self-signed-certificate-to-the-jvm-trust-store
 
for a related entry in the Graylog documentation.

Cheers,
Jochen

On Monday, 9 January 2017 01:14:56 UTC+1, Jason Haar wrote:
>
> Hi there
>
> We have set up our first Cisco ASA (8.4) to send syslog (TLS) messages 
> through to graylog via
>
> logging host outside ip.add.ress TCP/ secure
>
> We already have some Unix systems using rsyslog successfully doing the 
> same thing, but the Cisco records aren't being accepted.
>
> A sniffer shows traffic coming in from the Cisco, but server.log reports 
> the following. That sounds like the Cisco attempted to handshake TLS and 
> then sent an alert to graylog stating the error was "certificate_unknown"? 
> That would make sense, but our network group have no idea how to make the 
> CA trusted. 
>
> Can someone point me at something they need to read to do this properly? 
>
> Thanks, Jason
>
>
>
> 2017-01-09T00:07:56.088Z ERROR [NettyTransport] Error in Input [Syslog 
> TCP/570cc00b9cdbc22f13f5cecd] (channel [id: 0x525ae1a4, /1.2.3.4:56720 => 
> /4.3.2.1:])
> javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
> at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[?:1.8.0_77]
> at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source) ~[?:1.8.0_77]
> at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source) ~[?:1.8.0_77]
> at sun.security.ssl.SSLEngineImpl.recvAlert(Unknown Source) ~[?:1.8.0_77]
> at sun.security.ssl.SSLEngineImpl.readRecord(Unknown Source) ~[?:1.8.0_77]
> at sun.security.ssl.SSLEngineImpl.readNetRecord(Unknown Source) 
> ~[?:1.8.0_77]
> at sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source) ~[?:1.8.0_77]
> at javax.net.ssl.SSLEngine.unwrap(Unknown Source) ~[?:1.8.0_77]
> at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1219) 
> ~[graylog.jar:?]
> at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:852) 
> ~[graylog.jar:?]
> at 
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425)
>  
> ~[graylog.jar:?]
> at 
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
>  
> ~[graylog.jar:?]
> at 
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
>  
> ~[graylog.jar:?]
> at 
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
>  
> [graylog.jar:?]
> at 
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
>  
> [graylog.jar:?]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) 
> [graylog.jar:?]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) 
> [graylog.jar:?]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) 
> [graylog.jar:?]
> at 
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
>  
> [graylog.jar:?]
> at 
> org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
>  
> [graylog.jar:?]
> at 
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
>  
> [graylog.jar:?]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) 
> [graylog.jar:?]
> at 
> org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
>  
> [graylog.jar:?]
> at 
> org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
>  
> [graylog.jar:?]
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  
> [graylog.jar:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> [?:1.8.0_77]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> [?:1.8.0_77]
> at java.lang.Thread.run(Unknown Source) [?:1.8.0_77]
>
>
> -- 
> Cheers
>
> Jason Haar
> Information Security Manager, Trimble Navigation Ltd.
> Phone: +1 408 481 8171
> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/841e97a0-459c-4e98-a1c8-20edbfb90068%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[graylog2] Re: Force use of IP address

[Jochen Schalanda]

Hi,

On Monday, 9 January 2017 00:45:33 UTC+1, lsch...@palatine.il.us wrote:
>
> I tried to specify the rest and web listening address, but no change.
>

How exactly did you do this? And how did you configure the OVA in general?


Cheers,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/7e1b1312-7a24-4c1f-996d-cd2ea632a79b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.