I have scenario in describing a stack in sceptre where I have to append an already known port number to the hostname/ip that I can get from the resolver like this:
LdapServerURL: !stack_output_external some-stack::Host
I wish to have the "LdapServerURL" be intepreted or have a value like this:-
Host:389
where 389 is the known port.
Unfortunately that isn't supported at the moment.
could you add the port to the output, as URLs can contain ports.
Failing that i wrote something once to solve this: https://github.com/cloudreach/sceptre_combine_resolvers, It's designed for sceptre v2, but if you copy the sceptre_combine_resolvers.py into resolvers in your repo it should work
Related
I am looking at the stackstorm docker-compose file, and within it almost all containers have a line dns_search: . According to docker-compose documentation, dns_search is for the purpose of configuring search domains.
I am used to seeing this in context of transparently adding a domain to unqualified short domains. For example if I add dns_search: mydomain.com, I would expect "host1" to transparently resolve as "host1.mydomain.com".
I have never seen this set as a single dot . before. What is the effect/purpose of doing this configuration?
I'm posting the answer from the Stackstorm Git project issue see comment/"dns_search: .". Paraphrasing: it was useful in old versions of Docker before 2017, before the ndots configuration was available. Nowadays that configuration has no impact, and in fact has been removed from the stackstorm docker-compose file.
I believe this is because all domain names end in . under the hood, but browsers and other software abstracts this out.
For example. under the hood www.google.com is actually www.google.com.
So, in the docker-compose file, this would essentially be saying "Find me any domain"
A bit more detail on why there's an extra dot, if you're interested:
Domain name resolution is heirachical, reading right to left, with each block, separated by a ., being a step in the process. A DNS resolver will first find a source of ., which will be able to return the address for a resolver for the next block, until it reaches the final block, where it returns the full DNS record.
Extending EdwardTeach's answer:
#ytjohn effectively said they did in the past because putting dns_search: . configures the DNS search domains to be only . instead of inheriting the host ones. I can't confirm that because I didn't test it.
Now, I tested what docker-compose does today, and in a container, cat /etc/resolve.conf returns:
nameserver 127.0.0.11
options ndots:0
Where options ndots:0 is (from resolv.conf docs):
ndots:n
Sets a threshold for the number of dots which must
appear in a name given to res_query(3) (see
resolver(3)) before an initial absolute query will
be made. The default for n is 1, meaning that if
there are any dots in a name, the name will be
tried first as an absolute name before any search
list elements are appended to it. The value for
this option is silently capped to 15.
With ndots:0, all domains will be attempted using the absolute name first, only then using the search list.
How I came to this conclusion
The Github comment:
If you don't set this dns_search: ., then whatever the host has in search in their /etc/resolv.conf will get put into your container's /etc/resolv.conf.
This doesn't happen. My host has search domain[0]: broadband (macOS command: scutil --dns), and in docker containers, it doesn't show broadband (linux command: cat /etc/resolv.conf). Instead, it says options ndots:0
dns_search docs:
dns defines custom DNS search domains to set on container network interface configuration. Can be a single value or a list.
What is a DNS search domain?
It is the DNS service used to resolve hostnames that are not fully qualified, e.g. hostname will try hostname.example.com then hostname.website.com if your search domains list was example.com, website.com. More information on https://superuser.com/a/184366
In another repo (crossdock), their dockerfile had the comment:
`dns_search: . # Ensures unified DNS config.`
This is kind of a weird complicated question.
Context:
I have a bunch of docker containers that need to be routed to from haproxy dynamically. They are each running on different ports on the machine, and are stored in environment variables like this:
a=9873
b=9874
c=9875
These are available to the haproxy server. The request path that comes in will be in the form like this example:
/api/a/action
From that, the taks is as follows:
The /api needs to be removed from the path.
The /a refers to the service, so the environment variable for a needs to be retrieved to get the port of the server
The request needs to be routed to localhost:9873/a/action where the port, 9873, is the environment variable that is the value from the path in the beginning (after removing /api) and then the path is simply appended onto the request (which is the /a/action that remains after removing the /api.
My current config looks like this:
backend api
reqrep ^([^\ ]*\ /)api[/]?(.*) \1\2
server api_server localhost:9871
All this config is doing is removing the /api from the path of the request and sending it to a static port, 9871. *I need this port to be the value held by the environment variable of the same name as the first element in the path (the /a above) and the rest (passing the remaining path) is already working.*
I also would like to be able to get the environment variable of the name prefix_a, where the path will have the name /a, but I need to prepend one common prefix prefix_ to get the environment variable. This can be a separate question or search though, unless it's simple to just put that into the solution.
Please let me know if I can clarify or give more information that might help solve the problem.
(I've done a heck a lot of googling. Here are some related urls but not quite the answer I need:
https://gist.github.com/meineerde/8bea63e64fc47f9a67c0
Dynamic routing to backend based on context path in HAProxy
How can I set up HAProxy to a backend based on a value in the url?
Haproxy route and rewrite based on URI path
haproxy: get the host name
https://serverfault.com/questions/818937/haproxy-is-giving-me-problems-with-regex-replace-is-this-a-bug-or-am-i-doing-so
https://serverfault.com/questions/668025/how-to-use-environment-variable-in-haproxy
http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#7.2
How do I set a dynamic variable in HAProxy?
use environment variables in haproxy
I am trying to script an openam deployment using ssoadm, and want to know what will be the fastest and fool proof way to get the attribute names for ssoadm?
Right now, i login to the console and "view html source" for the attribute i am interested in, and use that via ssoadm. But, this approach is time consuming, plus with openam13 the attribute names are not available in the source.
Are you interested in any configuration or service in particular?
For most configurations and services (such as datastores, auth modules, server properties, etc...) there is an ssoadm command that will give you the current values from where you can grab the property names and use the in your script.
For example if you have a Datastore called OpenDJ in your top-level realm you can get the current configuration values using the following command:
ssoadm show-datastore -u amadmin -f /tmp/amadmin.pwd -e / -m OpenDJ
Typically it's just a matter of finding the right ssoadm command. Another option will be to look at the service definition. All these definitions are kept in xml format in your configuration store inside ou=Services.
Hope this helps.
I think the easiest approach is probably to look up the service XML files. At the time of the configuration, the service XML files are all copied over to ~/<OPENAM_HOME>/config/xml folder, so normally you can just try to grep for certain strings (like dynamic), but even then that may not work well.
If you know what service you are dealing with, then things get a bit easier. Are you trying to change an Authentication configuration? It must be defined in amAuth.xml then. The service name to be used for the ssoadm command is defined in the <Service> element under the "name" attribute. The service attribute names are defined under <AttributeSchema> elements with "name" attribute.
Yet another alternative would be to just read the documentation as most of the property names are already documented:
http://openam.forgerock.org/doc/bootstrap/admin-guide/index.html#auth-core-realm-attributes
I am trying to start a google compute engine (GCE) instance with a pre-configured FQDN. We are intending to run an application that is licensed based on the contents of /etc/hosts.
I am starting the instances using the Google Cloud SDK utility - gcloud.
I have tried setting the "hostname" key using the metadata option like so:
gcloud compute instances create mynode (standard opts) --metadata hostname=mynode.example.com
Whenever I log into the developer console, under computer, instances, I can see hostname under "Custom metadata". This appears to be a new, custome key - it has no impact on what:
http://metadata.google.internal/computeMetadata/v1/instance/hostname
returns.
I have also tried setting "instance/hostname" like the below, which causes a parsing error when using gcloud.
--metadata instance/hostname=mynode.example.com
I have successfully used the startup scripts functionality of the metadata server to run a startup script that parses the new, internal IP address of the newly created instance, updated /etc/hosts. This appears to work but doesn't feel "like the google way".
Can I configure the FQDN (specifically, a domain name, as the instance name is always the hostname) of an instance, during instance creation, using the metaserver functionality?
try this:
Go to your GCE >> VM instances panel.
stop your gce instance.
clic on the instance name.
Edit your instance, adding this values on Custom metadata fields:
Key field: hostname / Value field: your.server.hostname
Key field: startup-script / Value field: sudo -s hostnamectl set-hostname your.server.hostname
setup-example-image.png
Finally, start your instance and test with a hostnamectl command.
regards!
According to this article 'hostname' is part of the default metadata entries that provide information about your instance and it is NOT possible to manually edit any of the default metadata pairs. You can also take a look at this video from the Google Team. Within the first few minutes it is mentioned that you cannot modify default metadata pairs. As such, it does not seem like you can specify the hostname upon instance creation other than through the use of a start-up script like you've done already. It is also worth mentioning that the hostname you've specified will get deleted and auto-synced by the metadata server upon reboot unless you're using a start-up script or something that would modify it every time.
If what you're currently doing works for what you're trying to accomplish, it might be the only workaround to your scenario.
Here is a patch for /usr/share/google/set-hostname to set FQDN to GCE instance.
https://gist.github.com/yuki-takeichi/3080521322f0f1d159ea6a343e2323e6
Before you use this patch, you must set your desired FQDN in your instance's metadata by specifying hostname key.
Hostname is set each time instance's IP address is renewed by dhclient. set-hostname is just a hook script which dhclient executes and serves new IP address and internal hostame to, and modifies /etc/hosts. This patch changes the source of hostname by querying instance's metadata from metadata server.
The original set-hostname script is here:
https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google_config/bin/set_hostname.
Use this patch at your own risk.
When creating a VM, you can specify a custom FQDN hostname as an optional parameter. This feature is currently in Beta.
$ gcloud beta compute instances create INSTANCE_NAME --hostname example.hostname
This should work across OSes, and eliminate the need for workaround scripts.
More info in the docs.
-- Sirui (Product Manager, Google Compute Engine)
I've looked throughout this site to find answered questions and found a few things that work but with a couple solutions combined. This thread seems the place to answer.
1) echo example.com > /etc/hostname
2) add -- 127.0.1.1 example.com in /etc/hosts
3) add -- hostnamectl set-hostname
example.com -- command to /etc/rc.local script
4) uncomment /etc/dhcp/dhclient.conf line:
supersede domain-name "example.com";
5) profit.... Seems to stick after each reboot
(Note example.com is your domain name: fqdndomain.com - yourfqdndomain.org)
Also note this is for Ubuntu or Debian. Other Unix May slightly vary. I've tested this on Ubuntu 16.04
Always on the wording NOT possible to manually edit any of the default metadata pairs, how about the instant level default metadata "/scheduling"? we could set them manually as mentioned in this article
I am working on extending net-snmp to write a subagent with agentX.
Now I use the example codes from net-snmp, and compiled to a subagent.
Below is the codes I get from:
http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_MIB_Module
And I succeed to perform snmpget and snmpset to my subagent using agentX.
My questions:
I think the subagent and master agent are listening on a port, how can I find which port they are listening? I have been told the default port is 705, but when I use "netstat", I can't find any process listening on port 705.
How to change the listening port of subagent? Do I need to change in the example code to set the port?
By default, actually, on "anything but windows" the default is to listen to a unix socket located at /var/agentx/master.
You can change the listening address using the API suggested by the other poster, or even using the snmpd.conf configuration file:
agentXSocket tcp:localhost:705
When you create a subagent, it'll read your FOO.conf file where FOO is what you passed to init_snmp("FOO");
The problem is solved:
http://www.net-snmp.org/wiki/index.php/FAQ%3aAgent_12
By adding
netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID,
NETSNMP_DS_AGENT_X_SOCKET, "tcp:localhost:705");
in the example codes before the 'init_agent' call.
Thanks!
You need to change the snmpd.conf file
master agentx
AgentXSocket tcp:X.X.X.X:705
And in your agentx code write down these lines before init_agent()
netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_X_SOCKET, "tcp:X.X.X.X:705");