I am new to the Envoy proxy. I am trying to understand the filters basic config for "http_connection_manager"
I have this code :
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"#type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
codec_type: auto
stat_prefix: ingress_http
I need help in understanding what is the meeting of :
name: envoy.filters.network.http_connection_manager --- ( I think it is an inbuild HTTP filter of some kind)
"#type":type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager --- (I have no idea, what is this )
I tried to understand it from official docs and also read some medium posts, some youtube videos, but still, I have not able to decode the meaning of these lines.
If somebody has an answer, I will be grateful. even any resource, post or video link, or any kind of info is also appreciated, please share those if possible. thanks
The name field indicates the common name of the extension you want to turn on. They typically have enough information in the name to give you a little bit of a handle on what they do and where in the toolchain they are.
envoy means this is packaged straight with envoy. Not a 3rd party extension
filters means this is a filter extension. Envoy does also support other types of extensions, though filters is probably the most common.
network means this is a network filter. This operates at the TCP level. You'll also commonly see http here for filters that operate on HTTP requests.
http_connection_manager the specific filter. This is the HTTP connection manager, which does basically what it says: handles all the HTTP connections. Without this you don't get HTTP route handling, header manipulation, virtual hosts, etc. full features
The type is indicating the exact spec of the protobuf config that will be sent to the filter to initialize it and trigger behavior. It's a bit opaque, just know that each filter has a v2 and a v3 set of configuration options available. For any given filter, the envoy docs do link to their typed config. E.g. the kafka broker page and the direct proto definition
Related
I tried posting this on ask.openstack but it has been stuck in the moderator for 5 days now. I thought I'd try here.
I was trying to debug a Nova issue and wanted to decode the SSL / TLS packets being exchanged using Wireshark. Part of the changes I was making was setting Nova up to use SSL / TLS and I wanted to be sure that part of it I had set correctly. I eventually figure out my issues from the various log files but I'm somewhat assuming that being able to watch the network traffic may help in some very difficult cases.
The exchange uses TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at one point. According to this security stackexchannge question, there is a "pre-master secret" or various other terms. I've wrestled with this before in a previous life doing IPSec. Usually you can set debug in the application and it will spew out the secret into the log file. I tried "debug = true" under Default in nova.conf and got lots of debug but no secret. There was two items that looked interesting that were reported as **** in the log: keystone_authtoken.memcache_secret_key and neutron.metadata_proxy_shared_secret. I wasn't sure if those were the secrets I was looking for or not. In this case, I'm looking at the nova-api traffic going to port 8774.
Also, since all of openstack is Python and uses the same "request" and "certifi" packages, it may be possible to generalize this to all of the openstack components.
nova --version report 9.1.1
I'm configuring the keystone (as SP) for federation, and I have a question about the setup shibboleth [1]. I need edit the shibboleth2.xml file, and add the SP entity ID:
<ApplicationDefaults entityID="http://mysp.example.com/shibboleth">
In my case, would be:
<ApplicationDefaults entityID="http://10.7.49.47:5000/shibboleth">
I don't know if this is the right value. When I try access 10.7.49.47:5000/v3/OS-FEDERATION/identity_providers/myidp/protocols/mapped/auth, I receive the error:
Unable to locate metadata for 'http://10.7.49.47:5000/shibboleth'
I want understand better how the shibboleth work with keystone, and how get this Keystone SP entityID. I don't know if I need configure something to make '/shibboleth' works.
I need get this entityID to configure my IdP SimpleSamlPHP, and add the SP there [2].
[1] https://docs.openstack.org/developer/keystone/federation/shibboleth.html
[2] https://simplesamlphp.org/docs/1.5/simplesamlphp-idp#section_5
One I recommend you use HTTPS to connect with shibboleth. If it is you case then ignore.
Two entityId do not need to match with your host or IP. So if you want you can ignore port from entityId. You can use any string for that matter.
Now answer to your question, see my this answer to see steps to integrate shibooleth. Though this is java application steps but it is mostly done in apache http so it is relevant to anybody.
See the step 3 from that post, that is where your apache server knows that this location to protect.
P.S. The path your application listens is /Shibboleth.sso/ not /shibboleth
I'm trying to get all the names of the queues for activeMQ in java, I found couple topics here and here about that and people suggested using DestinationSource which I wasn't able to import in Eclipse when I was writing the code. I tried:
import org.apache.activemq.advisory.DestinationSource;
I'm using java 1.7 and latest activemq version 5.14.1. Any ideas if destinationsource is still supported or not?
Thanks,
The easiest way to get a handle on this information is by using Jolokia, which is installed by default. To do this, use an HTTP client to issue a GET request to one of the following URIs:
http://localhost:8161/api/jolokia/search/*:destinationType=Queue,*
http://localhost:8161/api/jolokia/search/*:destinationType=Topic,*
You will need to pass in the JMX username and password (default: admin/admin) as part of the HTTP request. The system will respond with something along the lines of:
{
"request" : {
"mbean" : "*:destinationType=Queue,*",
"type" : "search"
},
"status" : 200,
"timestamp" : 1478615354,
"value" : [
"org.apache.activemq:brokerName=localhost,destinationName=systemX.bar,destinationType=Queue,type=Broker",
"org.apache.activemq:brokerName=localhost,destinationName=systemX.foo,destinationType=Queue,type=Broker",
"org.apache.activemq:brokerName=localhost,destinationName=ActiveMQ.DLQ,destinationType=Queue,type=Broker"
]
}
The above shows the queues systemX.foo, systemX.bar, ActiveMQ.DLQ. Here's an example of using the curl command for this:
curl -u admin http://localhost:8161/api/jolokia/search/*:destinationType=Queue,* && echo ""
For a good explanation of how to use the Jolokia APIs, refer to the documentation.
The feature is still supported in the ActiveMQ project, with the caveat that it may not always work based on comments already given here. If you have advisory support enabled on the Broker then it should provide you with some insight into the destinations that exist, although JMX would give you more management of said destinations.
There's unit tests that show the DestinationSource feature which you can refer to. You need to put the 'activemq-client' jar in the class path so perhaps your IDE project isn't configured properly.
I am using Apache Jackrabbit Webdav library for svn checkin operation.
I am using MAKActivity method to start the transaction.
But I dont know how to add commit message. Following is the code
RandomStringGenerator rsg = new RandomStringGenerator(32);
String random = rsg.nextString();
String url = getRepoAddress() + "!svn/act/" + random;
MkActivityMethod activityMethod = null;
try
{
activityMethod = new MkActivityMethod(url);
client.executeMethod(activityMethod);
}
catch(Exception e)
{
e.printStackTrace();
}
This code executes successfully but I dont unserstand how to write log message in this.
Any help will be appreciable.
First of all I'd suggest that you not reinvent the wheel that's already been done twice now and instead using a library that knows Subversion's DAV based protocol. Note that while Subversion is mostly WebDAV and DeltaV compatible, it does have non-standard extensions.
To that end I'd point you to JavaHL or SVNKit. JavaHL comes with Subversion and uses JNI to access the Subversion libraries. SVNKit is an independent Java only implementation and includes a couple different interfaces, including one that is JavaHL compatible. If the use of the native libraries by JavaHL doesn't present a problem for you I'd recommend this since you'll have the benefit of using the same libraries as nearly every Subversion client.
If however your goal is to understand how Subversion implements the protocol on top of WebDAV and DeltaV then perhaps you want to just use a generic WebDAV and DeltaV client library to help. I'd recommend that you refer to these documents that describe how WebDAV and DeltaV are implemented within Subversion.
One thing you might want to understand is that as of Subversion 1.7 we support what we refer to as HTTPv2. HTTPv2 varies somewhat from the DeltaV standard in particular. Instead of using MKACTIVITY to start a transaction on the server we use a POST. Which has a body with a syntax something like this:
(create-txn)
or
( create-txn-with-props (PROPNAME PROPVAL [PROPNAME PROPVAL ...])
The older style which you must use with MKACTIVITY (and can use with the POST if you use create-txn instead of create-txn-with-props) is to use a PROPPATCH on the transaction or the working baseline URL.
The working baseline URL is used with MKACTIVITY and the transaction URL is used with the POST.
When using MKACTIVITY you have to use a PROPFIND on the root URL to get the version-controlled-configuration. Then do a CHECKOUT against the URL you received in response to that PROPFIND providing the activity-set href as the URL you used with MKACTIVITY. You'll get the working baseline URL back as the Location header from the CHECKOUT request. Which you can then use to issue a PROPPATCH to apply the revision properties.
When using POST, you get the transaction stub from the headers in the OPTIONS request response, the transaction name from the SVN-Txn-Name header in the response to the POST, and execute a PROPPATCH against the $transaction_stub/$transaction_name URL.
Probably the best ways to figure all this out is to setup a Subversion server and do some commits while running Subversion through a debugging proxy server such as Charles. You can force the traffic through the proxy on the svn command line with these options --config-option servers:global:http-proxy-port=8888 --config-option servers:global:http-proxy-host=127.0.0.1. If you want to see the old protocol you can include SVNAdvertiseV2Protocol off in your http configuration.
In order to support the broadest range of Subversion servers you need to implement the HTTPv1 protocol, which has more round trips and is more difficult to implement. If you want to only implement HTTPv2 you'll be limited to supporting Subversion servers newer than 1.7. In order to use HTTPv2 with maximum compatibility you'll have to detect the presence from the OPTIONS response.
As you can see it gets rather complicated so it's really not worth trying to write your own client if all you want to do is implement some basic functionality.
So you are trying to do a SVN commit using WebDAV via the SVNAutoversioning on directive?
http://svnbook.red-bean.com/en/1.7/svn.webdav.autoversioning.html
AFAIK, the spec does not allow you to provide a commit message and the server will always create one for you. Perhaps you want to look at the SVNKit library if you are trying to create SVN transactions via Java.
http://svnkit.com
I setup ActiveMQ 5.8.0 on a Windows 2003 virtual server for development purposes. I understand that there is suppose to be a REST interface for reading from and writing to queues and such. But, I can't seem to track down how to do it exactly. Port 8161 can be used to access the admin console, but every URL I try from Firefox Poster returns a 404. I tried URLs like these:
http://localhost:8161/queues <-- 404
http://localhost:61616/queues <-- some default message
http://localhost:61616/queue/inbox <-- same default message
http://localhost:8161/queue/inbox <-- 404
The documentation mentions mapping a URI to the servlet, but I'm not sure how or if I need to do this. The /demo feature is disabled by default, which is fine by me. How do I enable REST for my queues? Thanks!
As /demo is disabled, it been moved to /api
http://localhost:8161/api/message/
this is the path for all REST operations