I've been trying so hard to resolve this myself over the last week or so but I'm banging my head against a brick wall now!
Long story short, I'm getting a CORS error and I've been trying to fix the issue using the add_header 'Access-Control-Allow-Origin' '*' always; command in every place I can think of and with commas and single quotes in various places. My nginx install is a mainline release 1.15.3 on CentOS 7.
I soon figured that this module must be installed by default and adding the above line to the location / {} block in default.conf should be fine. I then added the extension to Firefox to make sure it worked (as a temp measure) and found that I got a 500 error. So now (not sure why) I have the extension disabled and the above line added to the default.conf file and I'm still getting the 500 error - which is good in a way! Now I want to install the -more- module to get over the 500 error I am now getting, as to my understanding the basic header module cannot deal with 500 errors.
My biggest problem at the moment is not being able to add this module to my nginx install. Looking online I see instructions for recompiling nginx with the module using the ./configure command (./configure --prefix=/opt/nginx --add-module=/path/to/headers-more-nginx-module) but I have no configure file in my nginx root directory (which is actually etc/nginx). I have no idea how to handle this really and could do with some advice please.
I did run nginx -V to list the modules that where supposedly installed with my instance of nginx but there was no mention of any header module so my assumption of the basic module being installed out of the box could also be wrong.
I have a local env that is not automatically decompressing deflated files. The staging server and the production server seem to be doing it automatically (because the code we have up there is working fine) but on my local machine the request body is still compressed. I had some success using:
gzinflate()
but I would rather find a solution where my local set up is just closer to the production set up (and don't have to change the code all that much).
p.s. this is a wordpress set up.
K I figured it out. Turns out the issue was that I had just updated my local env to php 7 and enabled x-debug. When doing this I also needed to install something for SOAP and CURL requests (if someone would like to explain further I would be appreciative). Here is the command I had to run:
sudo apt-get install php-soap php-curl
I am writing a very basic RPM that does nothing more then drop off a simple GUI onto a system. It require nginx, drop some code into it's html directory, and drops a conf file into it's conf.d directory. Most of the time this will likely be run on a VM or fresh box with little else installed.
While testing my RPM I noticed that the nginx that it installs fails out of the box. The problem is that it's default.conf directory uses IPV6 address instead of IPV4 and the machine does not have an IPV6 address set, I gaurentee none of the machines this code is installed on will ever have IPV6 set.
The fix is very simple, but my question is about good protocol. I'm guessing it would usually be considered wrong to have my RPM modifying the default.conf of the nginx file to fix the line causing the exception, but at the same time if I don't my RPM will not function out of the box without someone manually making a tweak to the configuration files. How 'wrong' is it to overwrite the default files if I'm mostly confident that I'll be installed on machines that don't have iPV6 addresses?
I'd check if you can drop something in conf.d to override the bad settings.
Otherwise...
Your %post can modify it with something like sed. Then put a flag there indicating you did, so your %postun can try to clean up afterwards.
I'm trying to serve a stock jenkins installation (on Amazon Linux AMI) thru myjenkinsinstance:8080/jenkins (rather than myjenkinsinstance:8080), and then proxy this with e.g. Nginx (over HTTP).
This question has been 'answered' before, but the solution doesn't seem to be relevant anymore.
#admins I would prefer to comment on that thread (specifically this 'answer'), rather than opening a duplicate, but I am not allowed to, per my 'reputation' score (as my comment would not be a solution at all, but further request for help).
From the closest thing to an answer I've seen:
Go to Jenkins Home Directory ( I have mine in C:\Jenkins)
Edit jenkins.xml
Add this --prefix=/jenkins to the end of the argument as show below and restart the jenkins service ALL worked OK for me !
Example : <arguments>-Xrs-Xmx256mDhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080 --prefix=/jenkins</arguments>
Open Url http://localhost:8080/jenkins this should bring up the home page of jenkins
there is no 'jenkins.xml' in the $JENKINS_HOME directory, but there is a config.xml
there is no <arguments/> entry in the config.xml
there seems to be no other configuration for the initial installation
There's also a 'Jenkins Location > Jenkins URL' setting in the "Configure System" settings (myjenkinsinstance/configure), but modifying this seems to have no noticeable affect.
The end goal would be to automate this installation via e.g. CloudFormation (as part of the EC2's UserData).
Any suggestions would be greatly appreciated.
On your linux system, you need to find the jenkins default config file located at
/etc/default/jenkins
and then add the following arguments according to your requirements. This is a rough idea.
JENKINS_ARGS="--webroot=/var/cache/jenkins/war --prefix=/jenkins
--httpPort=$HTTP_PORT --ajp13Port=$AJP_PORT"
This should work most likely. If it doesnt, pls update your answer with the current arguments present. This works fine for Debian/Ubuntu.
Also you are running jenkins on your windows machine or linux?
So my 'solution' was to use sed and insert some lines into /etc/nginx/nginx.conf and /etc/init.d/jenkins.
e.g.
sed -i '/^ location \/ {/aproxy_pass http://127.0.0.1:8080/;' /etc/nginx/nginx.conf
sed -i '/^PARAMS=/ s/"$/ --prefix=\/jenkins"/' /etc/init.d/jenkins
I highly doubt this is anything near a 'best practice', but it seems to work for now (what happens were I to update with yum... I'm not sure, but the plan is to back the instance with an Elastic Filesystem, which hopefully will allow us to consider the jenkins instance ephemeral, anyway).
How do I configure sbt to use a proxy?
For example, my build definition needs to connect to GitHub, specifying connection parameters for http.proxy, http.proxyPort, user, and password.
How would I pass in these settings to sbt?
Is there an easy way to switch between proxy/no-proxy settings for when I work from home?
sbt respects the usual environment variables for http proxy settings:
export JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyHost=yourserver -Dhttp.proxyPort=8080 -Dhttp.proxyUser=username -Dhttp.proxyPassword=password"
(That's of course, assuming Unix (Linux/OSX etc). On windows you could just set the same environment variable (%JAVA_OPTS%) as usual in the Windows way.)
Then run sbt as usual:
sbt
Switching between proxy/no-proxy should be a matter of setting up a little script that you can 'slurp' in whenever you need it.
Gotchas
Don't include "http://" in the yourserver value
Don't include the port in the yourserver value
You probably also want to include https.proxyHost and https.proxyPort since a lot of stuff works over https
If your proxy requires authentication, don't even bother trying unless it just uses Basic Authentication as SBT doesn't support anything else. Also always beware clear texting credentials into environment variables! Be sure to remove the commands from your .bash_history using a text editing method that won't create trace files (technically you should shred or srm the entire file). If you are on Windows, don't worry about it, your security is already messed up you can't do any more harm.
sbt works in a fairly standard way comparing to the way other JVM-based projects are usually configured.
sbt is in fact two "subsystems" - the launcher and the core. It's usually xsbt.boot.Boot that gets executed before the core starts up with the features we all know (and some even like).
It's therefore a matter of how you execute sbt that says how you could set up a proxy for HTTP, HTTPS and FTP network traffic.
The following is the entire list of the available properties that can be set for any Java application, sbt including, that instruct the Java API to route communication through a proxy:
http_proxy
http_proxy_user
http_proxy_pass
http.proxyHost
http.proxyPort
http.proxyUser
http.proxyPassword
Replace http above with https and ftp to get the list of the properties for the services.
Some sbt scripts use JAVA_OPTS to set up the proxy settings with -Dhttp.proxyHost and -Dhttp.proxyPort amongst the others (listed above). See Java Networking and Proxies.
Some scripts come with their own way of setting up proxy configuration using the SBT_OPTS property, .sbtopts or (only on Windows) %SBT_HOME%\conf\sbtconfig.txt. You can use them to specifically set sbt to use proxies while the other JVM-based applications are not affected at all.
From the sbt command line tool:
# jvm options and output control
JAVA_OPTS environment variable, if unset uses "$java_opts"
SBT_OPTS environment variable, if unset uses "$default_sbt_opts"
.sbtopts if this file exists in the current directory, it is
prepended to the runner args
/etc/sbt/sbtopts if this file exists, it is prepended to the runner args
-Dkey=val pass -Dkey=val directly to the java runtime
-J-X pass option -X directly to the java runtime
(-J is stripped)
-S-X add -X to sbt's scalacOptions (-S is stripped)
And here comes an excerpt from sbt.bat:
#REM Envioronment:
#REM JAVA_HOME - location of a JDK home dir (mandatory)
#REM SBT_OPTS - JVM options (optional)
#REM Configuration:
#REM sbtconfig.txt found in the SBT_HOME.
Be careful with sbtconfig.txt that just works on Windows only. When you use cygwin the file is not consulted and you will have to resort to using the other approaches.
I'm using sbt with the following script:
$JAVA_HOME/bin/java $SBT_OPTS -jar /Users/jacek/.ivy2/local/org.scala-sbt/sbt-launch/$SBT_LAUNCHER_VERSION-SNAPSHOT/jars/sbt-launch.jar "$#"
The point of the script is to use the latest version of sbt built from the sources (that's why I'm using /Users/jacek/.ivy2/local/org.scala-sbt/sbt-launch/$SBT_LAUNCHER_VERSION-SNAPSHOT/jars/sbt-launch.jar) with $SBT_OPTS property as a means of passing JVM properties to the JVM sbt uses.
The script above lets me to set proxy on command line on MacOS X as follows:
SBT_OPTS="-Dhttp.proxyHost=proxyhost -Dhttp.proxyPort=9999" sbt
As you can see, there are many approaches to set proxy for sbt that all pretty much boil down to set a proxy for the JVM sbt uses.
In windows environment simply add following line in the sbt/sbtconfig.txt
-Dhttp.proxyHost=PROXYHOST
-Dhttp.proxyPort=PROXYPORT
-Dhttp.proxyUser=USERNAME
-Dhttp.proxyPassword=XXXX
or the Https equivalent (thanks to comments)
-Dhttps.proxyHost=PROXYHOST
-Dhttps.proxyPort=PROXYPORT
-Dhttps.proxyUser=USERNAME
-Dhttps.proxyPassword=XXXX
I used (this is a unix environment) :
export SBT_OPTS="$SBT_OPTS -Dhttp.proxyHost=myproxy-Dhttp.proxyPort=myport"
This did not work for my setup :
export JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyHost=myproxy-Dhttp.proxyPort=myport"
In sbt.sh file :
JAVA_OPTS environment variable, if unset uses "$java_opts"
SBT_OPTS environment variable, if unset uses "$default_sbt_opts"
But apparently SBT_OPTS is used instead of JAVA_OPTS
For Windows users, enter the following command :
set JAVA_OPTS=-Dhttp.proxySet=true -Dhttp.proxyHost=[Your Proxy server] -Dhttp.proxyPort=8080
To provide one answer that will work for all Windows-users:
Add the following to your sbtconfig.txt (C:\Program Files (x86)\sbt\conf)
-Dhttp.proxyHost=XXXXXXX -Dhttp.proxyPort=YYYY -Dhttp.proxySet=true -Dhttps.proxyHost=XXXXXXX -Dhttps.proxyPort=YYYY -Dhttps.proxySet=true
Replace both XXXXXXX with your proxyHost, and both YYYY with your proxyPort.
If you get the error "Could not find or load main class" you need to set your JAVA_HOME:
set JAVA_HOME=C:\Progra~1\Java\jdkxxxxxx
When on 64-bit windows, use:
Progra~1 = 'Program Files'
Progra~2 = 'Program Files(x86)'
Add both http and https configuration:
export JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyHost=yourserver -Dhttp.proxyPort=8080 -Dhttp.proxyUser=username -Dhttp.proxyPassword=password"
export JAVA_OPTS="$JAVA_OPTS -Dhttps.proxyHost=yourserver -Dhttps.proxyPort=8080 -Dhttps.proxyUser=username -Dhttps.proxyPassword=password"
(https config is must, since many urls referred by the sbt libraries are https)
In fact, I even had an extra setting 'http.proxySet' to 'true' in both configuration entries.
When I added the proxy info to the %JAVA_OPTS%, I got an error "-Dhttp.proxyHost=yourserver was unexpected at this time". I put the proxy info in %SBT_OPTS% and it worked.
Using
sbt -Dhttp.proxyHost=yourServer-Dhttps.proxyHost=yourServer -Dhttp.proxyPort=yourPort -Dhttps.proxyPort=yourPort
works in Ubuntu 15.10 x86_64 x86_64 GNU/Linux.
Replace yourServer by the proper address without the http:// nor https:// prefixes in Dhttp and Dhttps, respectively. Remember to avoid the quotation marks. No usr/pass included in the code-line, to include that just add -Dhttp.proxyUser=usr -Dhttp.proxyPassword=pass with the same typing criteria. Thanks #Jacek Laskowski!.
Cheers
I found an item on the FAQ section of Lightbend Activator useful. I am using Activator, which in turn uses SBT, so not sure if this helps users with just SBT, but if you use Activator, like me, and are behind a proxy, follow the instructions in the "Behind A Proxy" section of the FAQ:
https://www.lightbend.com/activator/docs
Just in case the content disappears, here's a copy-paste:
When running activator behind a proxy, some additional configuration
is needed. First, open the activator configuration file, found in your
user home directory under ~/.activator/activatorconfig.txt. Note that
this file may not exist. Add the following lines (one option per
line):
-Dhttp.proxyHost=PUT YOUR PROXY HOST HERE
-Dhttp.proxyPort=PUT YOUR PROXY PORT HERE
-Dhttp.nonProxyHosts="localhost|127.0.0.1"
-Dhttps.proxyHost=PUT YOUR HTTPS PROXY HOST HERE
-Dhttps.proxyPort=PUT YOUR HTTPS PROXY PORT HERE
-Dhttps.nonProxyHosts="localhost|127.0.0.1"
SBT use both HTTP/HTTPS/SFTP/SSH and other kind of connections to a repository. so when behind a proxy, these protocols should be available.
In most simple cases on Windows, you just need to pass proxy parameters options to JVM, like:
java -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=8080
That will do.
But if not, there are few things you should be aware of:
whether if you are making a HTTPS connection to the repository.
whether sever certificates been imported to jre cacerts
whether your proxy would replace your server certificates
to solve first, you should pass https proxy parameter to jvm, like:
java -Dhttps.proxyHost=myproxy -Dhttps.proxyPort=8080 -Djavax.net.ssl.trustStore=${TRUST_STORE_PATH}
to solve the second, you should import the ca. there are a lot of tips.
to solve the third, you maybe could considering using a authentication proxy.
to Simplify the config of SBT, it provide sbtconfig.txt and sbtops in the conf directory, look into it.
Reference:
http://www.scala-sbt.org/0.13/docs/Setup-Notes.html
http://www.scala-sbt.org/1.0/docs/Publishing.html
On Mac OS X / El Capitan you can set java environment variables:
$launchctl setenv _JAVA_OPTIONS "-Dhttp.proxyHost=192.168.1.54 -Dhttp.proxyPort=9999"
I found that starting IntelliJ IDEA from terminal let me connect and download over the internet. To start from terminal, type in:
$ idea
Try providing the proxy details as parameters
sbt compile -Dhttps.proxyHost=localhost -Dhttps.proxyPort=port -Dhttp.proxyHost=localhost -Dhttp.proxyPort=port
If that is not working then try with JAVA_OPTS
(non windows)
export JAVA_OPTS = "-Dhttps.proxyHost=localhost -Dhttps.proxyPort=port -Dhttp.proxyHost=localhost -Dhttp.proxyPort=port"
sbt compile
or
(windows)
set JAVA_OPTS = "-Dhttps.proxyHost=localhost -Dhttps.proxyPort=port -Dhttp.proxyHost=localhost -Dhttp.proxyPort=port"
sbt compile
if nothing works then set SBT_OPTS
(non windows)
export SBT_OPTS = "-Dhttps.proxyHost=localhost -Dhttps.proxyPort=port -Dhttp.proxyHost=localhost -Dhttp.proxyPort=port"'
sbt compile
or
(windows)
set SBT_OPTS = "-Dhttps.proxyHost=localhost -Dhttps.proxyPort=port -Dhttp.proxyHost=localhost -Dhttp.proxyPort=port"
sbt compile
If you are using a Proxy which requires authentication, I have a solution for you :)
As #Faiz explained above, SBT has a very hard time handling proxy requiring authentication. The solution is to bypass this authentication, if you cannot turn off your proxy on demand (corporate proxy for example).
To do so, I suggest you use a squid proxy, and configure it with your username and password to access your corporate proxy. See : https://doc.ubuntu-fr.org/squid
Then, you can set JAVA_OPTS or SBT_OPTS environment variables so that SBT connects to your own local squid proxy instead of your corporate proxy :
export JAVA_OPTS = "-Dhttps.proxyHost=localhost -Dhttps.proxyPort=3128 -Dhttp.proxyHost=localhost -Dhttp.proxyPort=3128"
(just c/c this in your bashrc without modifying anything and it should work fine).
The trick is that Squid Proxy does not require any authentication, and acts as an intermediate between SBT and your other proxy.
If you have troubles in applying this advise, please let me know.
Regards,
Edgar
For those still landing on this thread trying to find where/how to configure HTTP proxy in IntelliJ, here's how I managed to get it to work for me. I hope this helps!
(Note: specify your network username and password in the corresponding boxes):-