I have two host alias in my directory structure that fail to properly register with g-wan. My folder structure is as follows:
/srv/gwan_linux64-bit/192.168.3.101_80/$dg.lcl
/srv/gwan_linux64-bit/192.168.3.101_80/$myapp
/srv/gwan_linux64-bit/192.168.3.101_80/#192.168.3.101
/srv/gwan_linux64-bit/192.168.3.101_80/#192.168.3.101:gwan.klickitat.lcl
/srv/gwan_linux64-bit/192.168.3.101_80/#192.168.3.101:test.lcl
When starting g-wan, I receive the error:
loading.........
* unresolved aliases: 2
From the sample server report in the default g-wan configuration:
Listeners 5 host(s): 192.168.3.101_80 Virtual: $dg.lcl
Root: #test.lcl Root: #gwan.klickitat.lcl Virtual: $myapp
Root: #192.168.3.101
As you can see, g-wan identifies the two root aliases as additional roots. G-wan only allows a single root host, so the two alias fail to function in the browser with a 404 error. Each of the hosts respond properly to ping, so they are accounted for by the dns. The virtual hosts and root host function as expected.
Thoughts?
Additional research:
I have corrected my posting error and simplified the presentation. I hope that you will find this to be concise.
My hosts file is as follows for all tests:
127.0.0.1 localhost.klickitat.lcl localhost
192.168.3.101 gwan.klickitat.lcl test.lcl
I implemented an example that is identical to your test with the exception that I used a different IP address to match my local subnet and I eliminated the virtual hosts, which do not impact my result in my testing.
The only changes to the default gwan configuration are as follows:
Changed the listener from 0.0.0.0_8080 to 192.168.3.101_8080
Changed the root host IP from #0.0.0.0 to #192.168.3.101
Added two host aliases #192.168.3.101:gwan.klickitat.lcl and
#192.168.3.101:test.lcl
This is my folder structure:
/srv/gwan_linux64-bit/192.168.3.101_8080
/srv/gwan_linux64-bit/192.168.3.101_8080/#192.168.3.101
/srv/gwan_linux64-bit/192.168.3.101_8080/#192.168.3.101:gwan.klickitat.lcl
/srv/gwan_linux64-bit/192.168.3.101_8080/#192.168.3.101:test.lcl
This is my result as reported by gwans included server report application:
3 host(s): 192.168.3.101_8080 Root: #test.lcl Root:
#gwan.klickitat.lcl Root: #192.168.3.101
Gwan does not recognize the aliases and I cannot access the aliased urls. My result is inconsistent with yours.
The rest of this post is intended only to illustrate that aliases are reported by gwan in alternate configurations in my environment, but with some inconsistencies in the expected outcome. I simply identify the folder structure and my result.
Alternate Config 1
/srv/gwan_linux64-bit/0.0.0.0_8080
/srv/gwan_linux64-bit/0.0.0.0_8080/#localhost
/srv/gwan_linux64-bit/0.0.0.0_8080/#localhost:gwan.klickitat.lcl
/srv/gwan_linux64-bit/0.0.0.0_8080/#localhost:test.lcl
Result:
3 host(s): 0.0.0.0_8080
Root: #localhost
Alias: 0.0.0.0:#gwan.klickitat.lcl
Alias: 0.0.0.0:#test.lcl
Alternate Config 2
/srv/gwan_linux64-bit/192.168.3.101_8080
/srv/gwan_linux64-bit/192.168.3.101_8080/#localhost
/srv/gwan_linux64-bit/192.168.3.101_8080/#localhost:gwan.klickitat.lcl
/srv/gwan_linux64-bit/192.168.3.101_8080/#localhost:test.lcl
Result:
3 host(s): 192.168.3.101_8080
Root: #localhost
Alias: 192.168.3.101:#gwan.klickitat.lcl
Alias: 192.168.3.101:#test.lcl
While the alternate configurations function, note that the aliases naming varies from the explicit naming in the folder structure. It appears that the listeners are being properly set up, but that there is some issue in how the host laiases are being generated. I'm happy to test further if you so desire.
Using G-WAN v4.18 I used the following structure without problem:
5 host(s): 192.168.2.8:8080
Root: #192.168.2.8
Alias: 192.168.2.8:#gwan.ch
Virtual: $trustleap.com
Alias: 192.168.2.8:#gwan.com
Virtual: $secure.gwan.ch
The hosts were defined on a LAN with /etc/hosts which is atomic (changes are immediately reflected).
As expected, they are all reachable from the Internet browser, and display the expected documents.
Note that unlike in your report, there's no such a thing like Root: #gwan.ch (the alias is reported as expected: Alias: 192.168.2.8:#gwan.com).
I suggest that (1) you make sure you are using v4.18 (today's latest release) and (2) test your configuration with /etc/hosts so you don't have possible DNS issues.
Related
I have different logs that are written to our moutend nfs share that i need to send to our syslog-server (graylog) they are located outside /var/log folder.
So i add some extra conf in /etc/rsyslog.d/
For this example i have two files with following config:
atlassian-application-confluence-log.conf
module(load="imfile")
module(load="imklog")
$MaxMessageSize 50k
global(workDirectory="/atlassian/test/confluence/logs")
# This is the main application log file
input(type="imfile"
File="/atlassian/test/confluence/logs/atlassian-confluence.log"
Tag="atlassian"
PersistStateInterval="200"
)
# This file contains entries related to the search index.
input(type="imfile"
File="/atlassian/test/confluence/logs/atlassian-confluence-index.log"
Tag="atlassian"
PersistStateInterval="200"
)
# Send to Graylog
action(type="omfwd" target="log-server-company.com" port="5140")
# if you want to keep a local copy of the logs.
action(type="omfile" File="/var/log/rsyslog.log" template="RSYSLOG_TraditionalFileFormat")
atlassian-application-jira-log.conf
module(load="imfile")
module(load="imklog")
$MaxMessageSize 50k
global(workDirectory="/atlassian/test/jira/log")
# Contains logging for most of Jira, including logs that aren’t specifically written elsewhere
input(type="imfile"
File="/atlassian/test/jira/log/atlassian-jira.log"
Tag="atlassian"
PersistStateInterval="200"
)
# Send to Graylog
action(type="omfwd" target="log-server-company.com" port="5140")
# if you want to keep a local copy of the logs.
action(type="omfile" File="/var/log/rsyslog.log" template="RSYSLOG_TraditionalFileFormat")
So to my problem.
When i check the Rsyslogd configuration with following command:
rsyslogd -N1 -f /etc/rsyslog.d/atlassian-application-confluence-log.conf
It says it is valid.
When i restart the rsyslog service i get the following errors:
module 'imfile' already in this config, cannot be added [v8.2102.0-10.el8 try https://www.rsyslog.com/e/2221 ]
module 'imklog' already in this config, cannot be added [v8.2102.0-10.el8 try https://www.rsyslog.com/e/2221 ]
error during parsing file /etc/rsyslog.d/atlassian-tomcat-confluence-log.conf, on or before line 6: parameter 'workdirectory' specified more than once - one instance is ignored. Fix config [v8.2102.0-10.el8 try https://www.rsyslog.com/e/2207]>
error during parsing file /etc/rsyslog.d/atlassian-tomcat-confluence-log.conf, on or before line 6: parameter 'workDirectory' not known -- typo in config file? [v8.2102.0-10.el8 try https://www.rsyslog.com/e/2207]
module 'imfile' already in this config, cannot be added [v8.2102.0-10.el8 try https://www.rsyslog.com/e/2221 ]
module 'imklog' already in this config, cannot be added [v8.2102.0-10.el8 try https://www.rsyslog.com/e/2221 ]
[origin software="rsyslogd" swVersion="8.2102.0-10.el8" x-pid="379288" x-info="https://www.rsyslog.com"] start
imjournal: journal files changed, reloading... [v8.2102.0-10.el8 try https://www.rsyslog.com/e/0 ]
How can i get rid of the warnings?
I have already tried to put the two modules in /etc/rsyslog.conf
I get following errors from that config:
parameter 'PersistStateInterval' not known
parameter 'Tag' not known
parameter 'File' not known
If there are multiple configuration files, they are processed in ascending sort order of the file name (numerically/alphabetically), See: $IncludeConfig.
Therefore you don't have to include any configuration parameters (modules, work directories, rulesets etc.) multiple times. You can include them once in the config which is loaded first.
The documentation in https://hydra.cc/docs/patterns/select_multiple_configs_from_config_group/ shows how to pick multiple configs from a Config Group and place them in a dictionary-like structure.
However, as mentioned in the very last paragraph there, "example uses an explicit nesting level inside each of the configs to prevent them stepping over one another".
For my use-case, this would prove extremely cumbersome and I would like to avoid it at all costs if possible.
Is there a way to achieve a similar result without resorting to explicitly adding the level in the individual configs? Thanks in advance :)
You can use a defaults-list #package keyword to achieve a similar result.
Let's assume you have changed the yaml files server/site/fb.yaml and server/site/google.yaml to not contain the "explicit nesting", so e.g. server/site/fb.yaml contains only the data domain: facebook.com.
You can achieve the same output as from the docs webpage using the following defaults list in server/apache.yaml`:
# Option 1: With a non-overridable defaults list
defaults:
- site/fb#site.fb
- site/google#site.google
# Option 2: With an overridable defaults list
defaults:
- site#site.fb: fb
- site#site.google: google
Either option 1 or option 2 above produces this output:
$ python my_app.py
server:
site:
fb:
domain: facebook.com
google:
domain: google.com
host: localhost
port: 443
The #package directive here could be any compound key that you want. For example, using the following defaults list:
# Option 1: With a non-overridable defaults list
defaults:
- site/fb#foo
- site/google#bar
# Option 2: With an overridable defaults list
defaults:
- site#foo: fb
- site#bar: google
We get this result:
$ python my_app.py
server:
foo:
domain: facebook.com
bar:
domain: google.com
host: localhost
port: 443
Using option 2 (an overridable defaults list) means you can override the given default option using the CLI:
$ python my_app.py server/site#server.foo=amazon
server:
foo:
domain: amazon.com
bar:
domain: google.com
host: localhost
port: 443
I have two Openwrt APs with dnsmasq on each ap. Lets call them DNS1 (main AP on 192.168.10.1) and DNS2 (dumb AP on 192.168.10.2). DNS1 is also the only DHCP server on my local network. I have stubby running on each instance to resolve external DNS requests on ports 5453. I have a couple of static dhcp hosts on DNS1 which I sync to DNS2 and they resolve fine. My problem is, I cannot get DNS2 to query DNS1 if it cannot resolve a local (lan) query. To clarify further: Since DNS1 is also handles DHCP, a new client (client1) will only get resolved by DNS1. Any client using DNS2 as its dns server/resolver will not be able to resolve client1 or client1.lan. I thought adding a 'server=/lan/192.168.10.1' would do the trick, but no luck. Here is my /etc/config/dhcp and autogenerated DNSMASQ.conf from DNS2:
config dnsmasq
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option quietdhcp '1'
option cachesize '4096'
option readethers '1'
option localise_queries '1'
option expandhosts '1'
option noresolv '1'
option rebind_protection '1'
option rebind_localhost '1'
option filterwin2k '1'
option domain 'lan'
option domainneeded '1'
list addnhosts '/adblock/custom'
list addnhosts '/adblock/dlhosts'
list addnhosts '/adblock/dlhosts-ipv6'
option local_ttl '300'
list server '/lan/192.168.10.1'
list server '127.0.0.1#5453'
# auto-generated config file from /etc/config/dhcp
conf-file=/etc/dnsmasq.conf
domain-needed
filterwin2k
no-resolv
localise-queries
read-ethers
enable-ubus=dnsmasq
expand-hosts
bind-dynamic
local-service
quiet-dhcp
cache-size=4096
domain=lan
server=/lan/192.168.10.1
server=127.0.0.1#5453
addn-hosts=/tmp/hosts
addn-hosts=/adblock/custom
addn-hosts=/adblock/dlhosts
addn-hosts=/adblock/dlhosts-ipv6
dhcp-leasefile=/tmp/dhcp.leases
local-ttl=300
stop-dns-rebind
rebind-localhost-ok
dhcp-broadcast=tag:needs-broadcast
conf-dir=/tmp/dnsmasq.d
user=dnsmasq
group=dnsmasq
dhcp-ignore-names=tag:dhcp_bogus_hostname
bogus-priv
conf-file=/usr/share/dnsmasq/rfc6761.conf
This is likely dnsmasq's rebind protection kicking in from stop-dns-rebind. Check your logs, if you see lines like this then that is your issue.
dnsmasq[3835]: possible DNS-rebind attack detected: hostname.lan
You want to add rebind-domain-ok=lan to your dnsmasq.conf. Your OpenWRT config should look like this:
config dnsmasq
list rebind_domain 'lan'
When pserve starts by default it runs the pyramid application in http://0.0.0.0:6543 however how can I changed it to http://0.0.0.0:6543/myapp
In the settings I can change the port but I haven't found elsewhere where to change the root path
In any WSGI application the environ['SCRIPT_NAME'] is very important here. It defines the root path for all urls in the app. The full path is environ['SCRIPT_NAME'] + environ['PATH_INFO']. Assuming you have done things properly in your app (for example request.route_url(..) will generate urls using this information) then you can simply remount your application elsewhere (the default SCRIPT_NAME is '') by instructing it that it should be something else.
There are a couple things you can do based on how you're deploying your application (if it's behind a proxy then things are slightly more complex). Let's assume you're just using a simple pyramid app hosted with waitress. You can move your app using the rutter[1] package which will match the /myapp/* path and send all requests to your app with the appropriate SCRIPT_NAME (myapp) and PATH_INFO.
The declarative config is the simplest for a pyramid app. Just install rutter and then update your INI file to mount your application at /myapp prefix:
[app:foo]
use = egg:myapp#main
[composite:main]
use = egg:rutter#urlmap
/myapp = foo
Note I renamed the app:main to app:foo because you can only have one wsgi component named main and we want it to be the composite.
[1] http://rutter.readthedocs.io/en/latest/#declarative-configuration-using-paste-deploy-ini-files
I'm installing a package from a module (Nginx in this specific case) and would like to include a configuration file from outside of the module, i.e. from a top level files directory parallel to the top level manifests directory. I don't see any way to source the file though without including it in a module or in my current Vagrant environment referring to the absolute local path.
Does Puppet allow for sourcing files from outside of modules as described in the documentation?
if I understand your question correctly, you can.
In your module a simple code like this
file { '/path/to/file':
ensure => present,
source => [
"puppet:///files/${fqdn}/path/to/file",
"puppet:///files/${hostgroup}/path/to/file",
"puppet:///files/${domain}/path/to/file",
"puppet:///files/global/path/to/file",
],
}
will do the job. The /path/to/file will be sourced using a file located in the "files" Puppet share.
(in the example above, it search in 4 different locations).
update maybe you're talking about a directory to store files which is not shared by Puppet fileserver (look at http://docs.puppetlabs.com/guides/file_serving.html), and in this case you can't i think, Vagrant or not, but you can add it to your Puppet fileserver to do it. I thinks it's the best (and maybe only) way to do it.
If you have a number of Vagrant VMs you can simply store files within your Vagrant project directory (containing your VagrantFile).
This directory is usually available to all VMs as /vagrant within the VM on creation.
If you want other directories on your computer to be available to your VMs just add the following to your VagrantFile
# see http://docs.vagrantup.com/v1/docs/config/vm/share_folder.html
config.vm.share_folder "v-packages", "/vagrant_packages", "../../dpkg"
Then to use the files within puppet you can simply treat them as local files to the VM
# bad example, bub basically use 'source => 'file:///vagrant/foo/bar'
file { '/opt/cassandra':
ensure => directory,
replace => true,
purge => true,
recurse => true,
source => 'file:///vagrant/conf/dist/apache-cassandra-1.2.0',
}
This is probably only wise to do if you only using local puppet manifests/modules.
Probably too late to help bennylope, but for others who happen across this question, as I did before figuring it out for myself ...
Include stuff like this in your Vagrantfile ...
GUEST_PROVISIONER_CONFDIR = "/example/destination/path"
HOST_PROVISIONER_CONFDIR = "/example/source/path"
config.vm.synced_folder HOST_PROVISIONER_CONFIDIR, GUEST_PROVISIONER_CONFDIR
puppet.options = "--fileserverconfig='#{GUEST_PROVISIONER_CONFDIR}/fileserver.conf'"
Then make sure /example/source/path contains the referenced fileserver.conf file. It should look something like ...
[foo]
path /example/destination/path
allow *
Now, assuming example-file.txt exists in /example/source/path, the following will work in your manifests:
source => "puppet:///foo/example-file.txt",
See:
Puppet configuration reference entry for fileserverconfig
Serving Files From Custom Mount Points