I can use puppet to set up my apache httpd and add virtual hosts and load needed modules. I also know how to add custom configuration within a virtual host using the customconf-value but...
How do I configure in my pp-file to add my custom configuration in the main server config context? (I.e. outside of the virtual hosts)
I am using the standard apache module in puppet https://github.com/puppetlabs/puppetlabs-apache
I have read the documentation several times and also tried following the broken links to for example apache::mod documentation (to see if there is some similar value like customconf but... with no success).
How do I configure in my pp-file to add my custom configuration in the main server config context? (I.e. outside of the virtual hosts)
The reference documentation for the module is here: https://github.com/puppetlabs/puppetlabs-apache/blob/main/REFERENCE.md, or you can access it via the Forge here: https://forge.puppet.com/modules/puppetlabs/apache/reference.
Those document the plethora of parameters of the apache class, which expose a wide variety of Apache's configuration properties. You can manage most of the most common (and many of the less common) Apache configuration details by setting appropriate values for these class parameters.
They also document a plethora of classes that you can declare to adjust which modules are enabled, plus a native resource type (a2mod) and a defined-type wrapper apache::mod that you can use to configure modules that do not have a pre-built class.
And they document several public defined types that you can use to customize your configuration (including, but not limited to, vhosts). Of these, apache::custom_config is the most general, as it allows you to manage drop-in files containing more-or-less arbitrary Apache configuration.
Related
We have a multi-tenancy website. We are trying to use social share components where the url needs to be shared. Since we have a dispatcher configured, we are picking up the domain from a context aware configuration. How do we use different domains for environments based on run-modes
I have tried to use different ca-config folder for each environment but this is not ideal.
Sling context aware configurations don't work on run modes. For your current requirement you should be using Externalizer service which works basis sling maps, request origin and OSGI configs based on what method you choose.
https://helpx.adobe.com/in/experience-manager/6-3/sites/developing/using/externalizer.html
https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/reference-materials/javadoc/com/day/cq/commons/Externalizer.html
You can use Day CQ Link Externalizer which is available in the OSGI configurations, http://localhost:4502/system/console/configMgr.
It is an OSGI service that allows you to programmatic-ally transform a resource path into an external and absolute URL. You can configure this configuration for different run modes
You can also use a 2-step approach. 1st you create a Run-Mode dependent OSGi config. 2nd you use the built-in Override via OSGi configuration.
See here: https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-override.html#override-via-osgi-configuration
I have moqui running on system1 which is accessible using URL http://localhost:8080/Login.
Trying to access it from other system2 (in network) with URL replacing 'localhost' with the IP of first system; it shows the first (log-in) page, but afterwards, when submitting the pages from system2, the IP in URL automatically gets changed to 'localhost'. I have looked in to the book and also searched in framework code but couldn't find something related to this.
What could be the cause of this, is there any setting in app to fix this?
There are two parts to configuring hosts and ports for a webapp. One is is for the servlet container so it knows what to listen to and the other is in Moqui Framework itself so it knows what to use when generating URLs. It sounds like the issue you are having is with the second, with URL generation.
In your runtime Moqui XML Conf file there should be a webapp element somewhat like this one from the MoquiProductionConf.xml file:
<webapp name="webroot" http-port="" http-host=""
https-port="" https-host="" https-enabled="false"
content-prefix-secure="" content-prefix-standard="" cookie-domain="">
<root-screen host=".*" location="component://webroot/screen/webroot.xml"/>
</webapp>
When no #http-host/etc attribute is specified the values from the HttpServletRequest object will be used. These will vary depending on the settings of the servlet container you are using to deploy Moqui Framework.
To set it to something explicit you can use the http-host and if needed the https-host, http-port, and https-port attributes. For virtual host support the http-host and https-host attributes should be empty and the servlet container (and any proxy/etc in front of it) should be configured to pass through the hostname requested.
I am working on a product that runs Apache, and i'm trying to make the configuration more DRY — right now there are many different vhost configs that get loaded in different situations but are 90% identical, and this is very tedious to deal with when a change needs made. I don't think Apache is really designed with this kind of dynamic environment in mind, but w/e, here i am anyway.
So i've first turned to environment variables — i have a small boot-strap script that determines the necessary configuration and dumps variables into /etc/apache2/envvars (which is loaded by apache2ctl and similar on Ubuntu). This allows me to do things like this:
envvars:
export MYKEY='/path/to/mykey'
export MYCERT='/path/to/mycert'
export MYBUNDLE='/path/to/mybundle'
vhost config:
SSLCertificateKeyFile ${MYKEY}
SSLCertificateFile ${MYCERT}
SSLCACertificateFile ${MYBUNDLE}
This works fine, but only as long as MYKEY, &al., are non-empty variables referencing non-empty files. In some configurations, for example, no CA bundle is required, so i tried just pointing MYBUNDLE to /dev/null. Apache considers this a 'syntax error' because /dev/null is an empty file, and refuses to start.
My question: Is there any way i can dynamically disable/omit configuration directives in the Apache config (based on environment variables or a similar mechanism) without having to maintain separate files for each possible scenario?
Alternative question: Is there any way i can provide an empty value/certificate to this particular directive (SSLCACertificateFile) in a manner that Apache won't consider invalid?
Ubuntu 12.04.5
Apache 2.2.22
Looks like what you want is a management tool for your configuration.
Now I'm not sure how often you deploy but you probably could make a script that generates your templates for you?
If you have a greater need, maybe consider automation software and use some kind of template? I'm thinking something like chef (https://www.chef.io/) or puppet (http://puppetlabs.com/) or ... They all support template and you can provide value based on environment / server / moods for the different values.
I've tried to learn the JBoss Arquillian, by following the formal document and got confused about the configuration, the arquillian.xml. Since it is mentioned once here.
Even I also found that there is a specific configuration describes at the container adapters section. It does not cover all elements/properties, e.g. engine and its property list, defaultProtocol, extension and group.
I'm worried and wondered, if there is any further or full explanation for this configuration file or not. Could you please help to shed some light on this configuration?
There's no single page in the Arquillian Reference Guide that contains your answer. This is partly because of the modular and extensible nature of Arquillian - extension can have their own configuration elements and properties.
To start with, the properties for containers are in the Container Adapters Section. Every adapter has it's own page where the container configuration is detailed. For instance, JBoss AS 7 has it's own page for it's container configuration (see the Configuration section on the page), and so do other containers.
Usually, you wouldn't need to configure the protocol yourself, for the values are usually managed by Arquillian, and usually do not require any overrides to be provided via arquillian.xml. But if you need them, they're in the Protocols section and in the child pages.
A group is merely a collection of containers, to used in cases where the container does not support clustering by default. You merely need to list multiple container configurations in a group element, as shown here.
Extension configuration is typically found in the Extensions child-pages.
The defaultProtocol element does not have any page of it's own. It is used to override the protocol specified by a container adapter, for all tests. There are only a few cases where you would need to use this element, most notably when you need to use the Servlet protocol instead of the JMX protocol for JBoss AS 7 (because the Servlet protocol of Arquillian is a more widely used and tested protocol than the JMX one).
A typical use of defaultProtocol would look like:
<defaultProtocol type="Servlet 3.0" />
where the type is the name of the protocol - "Servlet 2.5" and "Servlet 3.0" are valid values. You may also need to add the protocol dependency to your classpath when you change the default protocol of the container.
I am working on a web application that allows users to upload attachments. These attachments are stored on a different drive than that of the web application. How can I create an alias (equivalent to Apache HTTP server's aliases) to this drive so that users can download these attachments?
Currently I am creating a context file and dumping it in CATALINA_HOME/conf/Catalina/localhost, but it gets randomly deleted every so often. The context file is named attachments.xml and the contents are shown below. I have also read about virtual hosts, but if I understand correctly, then a virtual host is not what I am looking for. I am using version 6.0.18 of Apache Tomcat.
attachments.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context docBase = "e:\uploads\attachments"
reloadable = "true"
crossContext = "true">
</Context>
I spent a lot more time researching this and found a solution that solves the random deletion of the context files. I found this excerpt on Apache's website under the host configuration section:
You can nest one or more Context
elements inside this Host element,
each representing a different web
application associated with this
virtual host.
The virtual hosts are stored in the server.xml file located at CATALINA_HOME\conf. Tomcat comes configured with localhost as the default host. So, if we add the contents of attachments.xml from the first post, we get the following:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Context path="/attachments"
docBase="e:\uploads\attachments"
reloadable="true"
crossContext="true" />
</Host>
This is as close as one can get to defining aliases similar to Apache's HTTP server, I think.
There are multiple options.
Use Apache as frontend, delegating to tomcat by mod_jk or mod_proxy
Provide a download servlet in your own application, serving the requested file
Make the directory that you want tomcat to deliver a web application
each has some drawbacks and some advantages. I strongly prefer the first solution for multiple reasons:
My main reasons apply to unixoid systems, which you are obviously not talking about: Only root can bind ports lower than 1024, e.g. 80. Therefor tomcat would need to run as root (I know that there are mechanics to allow users to bind to low ports, but I've never gotten to use them). Apache is usually started as root but drops these privileges as soon as port 80 is bound.
Apache is said to be a lot better in serving static resources than tomcat (I've never measured it, but find it hard to believe the contrary)
You obviously know how to create aliases in apache - it would be trivial to do so.
About the download servlet:
This way you'd have a servlet serving your static resources, which you might bind to the urls "/download/*" (e.g. in the application that also handles file uploads) You'd gain:
You need to configure the directory where your files are stored only once
If you need you might easily implement permission checks (e.g. login required for downloading)
You need to deploy only one completely selfcontained application.
The download servlet is trivial - find the file, set it's name and filetype in the output stream and stream it byte by byte, then close the output stream (be sure to handle attacking file names like "/download/../../../../etc/passwd" or "/download/C:/WINDOWS/someimportantfile.xxx"), e.g. by using the java.io.File constructor that gets the base directory as a separate parameter.
The third option has some severe drawbacks and opens you for attacks if you don't take special care of them:
Tomcat does not serve directories, but webapps. Therefor "E:/upload/attachments" would need at least a directory named "WEB-INF", containing "web.xml". Take care to not provide write access to this directory and file from the uploading web application. With this provision you might let tomcat serve the directory.
However: Configure the contained web.xml to not serve "*.jsp" as a jsp, otherwise tomcat would not just deliver jsp files but execute them. Imagine someone uploading "index.jsp" with <% System.exit(0); %> or more malicious content.
One additional thought: You don't need the extra crosscontext="true". This would imply that the webapplication that you deploy just to serve your files has access to other webapplications, e.g. is able to manage them or access their private data. Usually you don't need that at all, in the case of your question you definitely don't want that.
See the initial part of my newer question for ways to do this by editing the context.xml file
How do I add aliases to a Servlet Context in java?.
According to several people now, it is no longer necessary (2012: Tomcat 6 or 7) to use Apache for performance reasons over Tomcat for serving static content.