I have installed gerrit on my centos server, but I have a problem with the authentication. I would like to give authentication privileges for the centos users in a given group. Basically, every user in the gerrit group should have the possibility to log in with its password.
But, when I access the gerrit link, there is a redirect to gerrit:8081/login when I get the following message:
The HTTP server did not provide the username in the Authorization
header when it forwarded the request to Gerrit Code Review.
If the HTTP server is Apache HTTPd, check the proxy configuration
includes an authorization directive with the proper location, ensuring
it ends with '/':
Do you have any hints why this doesn't work?
The VirtualHost part of the /etc/httpd/conf/httpd.conf file looks something like this:
<VirtualHost gerrit:8081>
ServerName gerrit
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<Location "/login/">
AuthType Basic
AuthName "Gerrit Code Review"
AuthBasicProvider file
AuthUserFile /etc/passwd
Require valid-user
</Location>
AllowEncodedSlashes On
ProxyPass /r http://localhost:8081/r nocanon
</VirtualHost>
And the gerrit.config file:
[gerrit]
basePath = /repos
canonicalWebUrl = http://freshattitude.eu:8081/
[database]
type = mysql
hostname = localhost
database = gerrit
username = gerrit
[auth]
type = HTTP
emailFormat = {0}#example.com
[sendemail]
smtpServer = localhost
smtpUser = root
[container]
user = gerrit
javaHome = /usr/java/jdk1.7.0_25/jre
[sshd]
listenAddress = *:29418
[httpd]
listenUrl = http://*:8081/
[cache]
directory = cache
You made some mistakes. On the one hand, you have to set in gerrit.config
httpd.listenUrl = proxy-http://127.0.0.1:8081/
so that Gerrit knows about the proxy in front of it.
Furthermore, your Apache vhost has to listen to a different port (at least when both services run on the same server). In fact, I'm wondering how you've been able to start both at the same time ;-)
So set an apache vhost up for port 80, not for port 8081. Then users will connect to http://freshattitude.eu/.
Finally, again in gerrit.config, you have to fix your canonicalWebUrl and remove the :8081, as because of you're using a proxy, this is how you tell to Gerrit what its URL towards the outside world is.
I think you should go through Gerrit docs on reverse proxy config once.
Afterwards you will end up with Gerrit listening only on localhost port 8081 and apache listening to port 80 (sure, you might want to use SSL, then use the proxy-https variant in gerrit.config).
This is the configuration which runs and help you https://groups.google.com/forum/?hl=en#!topic/repo-discuss/qwQxy_izXzo
Thanks & Regards,
Alok Thaker
As far as I know Gerrit requires the authentication details to be provided in the request header when using HTTP authentication. So, when using this anonymous access is not possible.
Because of this I changed the Location "/login/" to Location "/", then authentication is always done before going to Gerrit. That it works and I can live with it.
This might actually be some regression bug that crept in somewhere but that how I have it working.
Related
I'm trying to set up a reverse proxy to a Node.Js Express web server. Basically I'm trying to redirect any traffic coming to mywebsite.com and have httpd redirect them to node.js app endpoints. So if I would do mywebsite.com/test then it would run the /test function in my node app.
I'm running on EC2 (Amazon Linux 2 AMI)
My backend is at:
/home/ec2-user/mywebsite/mywebsite_backend/dist
I'm running the with pm2, which is a monitoring software for node.
Here's the configuration to /etc/httpd/conf.d/mywebsite.com.conf
<VirtualHost *:80>
ServerName mywebsite.com
ServerAlias www.mywebsite.com
ProxyPreserveHost On
ProxyPass /home/ec2-user/mywebsite/mywebsite_backend/dist http://localhost:8055/
ProxyPassReverse /home/ec2-user/mywebsite/mywebsite_backend/dist http://localhost:8055/
ErrorLog /etc/httpd/conf.d/error.log
CustomLog /etc/httpd/conf.d/custom.log combined
DocumentRoot /home/ec2-user/mywebsite/mywebsite_backend/dist
</VirtualHost>
When I try to open: https://mywebsite.com from a browser I get apache testpage.
When I try https: https://mywebsite.com/test' I get "Not Found". I'm guessing that this is because there's no :443 virtualhost?
When I try http aka non-secure: http://mywebsite.com I get "Forbidden".
Edit1: It seems that Apache is by default looking in /var/www/html. I added a index.html page there and now I can see it when visiting mywebsite.com.
Edit2:
When doing curl http://localhost:8055/test on the server the response is:
curl: (52) Empty reply from server
When doing curl https://localhost:8055/test on the server the response is:
curl: (60) SSL: no alternative certificate subject name matches target
host name 'localhost' More details here:
https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could
not establish a secure connection to it. To learn more about this
situation and how to fix it, please visit the web page mentioned
above.
I've made the SSL certificates for my express server with Let's encrypt and I'm pointing to the generated files in my code and it works locally, but it seems I have a problem with SSL with apache?
Edit3:
curl -k http://localhost:8055/test
Does not work.
I've tried now pingin my node app with
curl -k https://localhost:8055/test
It works.
Edit4: Looking at the error logs /etc/httpd/conf.d/error.log it seems that there are permission problems with the code being in /home directory. I will move it to /var/www/html/
I need to perform the following configuration on my Apache server, version 2.4, with CentOS system.
The instructions I received are as follows:
Configuring Another Web Server to Serve the Files If another web
server is using port 80 on the same server as Centova Cast, you will
need to use this method.
This method depends upon your knowledge of the other web server you
are using; you must be familiar enough with your web server of choice
to configure it appropriately. Centova Technologies cannot provide
support or assistance with any changes to your web server's
configuration.
To allow "Let's Encrypt" to validate your domain ownership, you must
configure your web server such that any requests for files under the
following URI (replacing example.com with your own domain name):
http://example.com/.well-known/acme-challenge/ ...are configured to
serve files from the following directory:
/usr/local/centovacast/etc/ssl/acme-challenges/ So for example, if you
create a file called
/usr/local/centovacast/etc/ssl/acme-challenges/test.txt, you should be
able to visit http://example.com/.well-known/acme-challenge/test.txt
in your browser and see the contents of the test.txt file.
A few example configurations are provided below. Please note, however,
that differences in your web server configuration may require
additional settings not mentioned here.
Example apache:
Alias /.well-known/acme-challenge /usr/local/centovacast/etc/ssl/acme-challenges
<Directory /usr/local/centovacast/etc/ssl/acme-challenges>
Options None
AllowOverride None
Apache 2.x
<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
</IfModule>
Apache 2.4
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
</Directory>
I've tried everything and I can't get it to work, how should the correct configuration be done?
My configuration file is located at: /etc/httpd/conf/httpd.conf
I am using laravel5.5 and I'm implementing the wild card dns giving each user their own sub-domain.
In my implementation, I am working on a laptop with windows 10 and a laragon server.
On laragon I setup like this
<VirtualHost *:80>
DocumentRoot "C:/laragon/www/tindahan/public/"
ServerName tindahan.local
ServerAlias *.tindahan.local
<Directory "C:/laragon/www/tindahan/public/">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
and on the host file
127.0.0.1 tindahan.local
127.0.0.1 fil.tindahan.local
127.0.0.1 liz.tindahan.local
On the route
Route::get('/', function () {
$url = parse_url(url()->current());
$domain = explode('.', $url['host']);
$subdomain = $domain[0];
dd($subdomain);
});
So when visiting the fil.tindahan.local or liz.tindahan.local, I got the result
fil and Liz
but if I visit joseph.tindahan.local I got this error
This site can’t be reached
I need to create another sub-domain on the host to make it work.
The question is, how can do it automatically?
when I enter any names as a sub-domain it should be automatically created so that I never do it manually?
As far as I know, the error will resolved in network layer, not from application layer (in this case laravel).
I think you need your own local DNS-Server.
I've used dnsmasq in Linux (ubuntu) and it worked fine.
steps:
apt install dnsmasq
open /etc/dnsmasq.conf with an editor.
add address=/your_domain.loc/127.0.0.1 (it's just an example so you'll need change domain and ip probably).
run sudo systemctl restart dnsmasq to restart the service.
Well, you can test any url from your_domain.loc in your browser and you will not get that error ;)
goodluck
I have an environment where the JBOSS server sits on a linux machine and it's services accessed via Apache server running there.
I am not able access the JBOSS console as "http://:/console"
What changes apparently will I have to make in "httpd.conf" to access this url from outside.
The safer way of accessing your JBoss console is through an ssh tunnel.
Execute locally
ssh -L 7990:localhost:9990 username#your.jboss.server -N
and enjoy your remote server's console on your local machine on port 7990.
Opening console port on your web server is also a solution, but less secure one.
Try with:
<Location /console>
ProxyPass http://localhost:9990
ProxyPassReverseCookiePath / /console/
ProxyPassReverseCookieDomain localhost <YOUR PUBLIC IP ADDRESS>
</Location>
<Location /console/>
ProxyPassReverse /
</Location>
ProxyPreserveHost On
The thing with the ProxyPassand ProxyPassReverse directives is that it preserves the domain so you can handle cookies as is on JBoss side without any problems, and that sessions are tracked correctly.
The ProxyPassReverseCookiePath directive rewrites the path string in Set-Cookie headers. If the beginning of the cookie path matches internal-path, the cookie path will be replaced with public-path. And ProxyPassReverseCookieDomain rewrites the domain string in Set-Cookie headers.
See more:
apache httpd JBoss AS 7 admin console proxy
Apache Module mod_proxy
I have configured Sonar webserver to have all of the requests to go through Microsoft IIS server.
It was confirmed to work fine with requests via http protocol.
However, once the https was enabled, after successful login, Sonar webapp is trying to redirect to non-https url, causing it to timeout. If I then go and change the url to go to https, it shows as authenticated and continues to work as normal.
The same issue happens when you trying to logout - instead of redirecting to https page, it goes out to http.
What needs to be done to make Sonar post-login action to use the same protocol via which the login page was requested originally?
sonar.properties has:
sonar.web.host: 127.0.0.1
sonar.web.port: 9000
sonar.web.context: /sonar
IIS plugin has:
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:80"/>
<VirtualHost Name="*:9443"/>
<VirtualHost Name="*:443"/>
<VirtualHost Name="*:9000"/>
</VirtualHostGroup>
<ServerGroup Name="sonar_group">
<Server Name="sonar_server">
<Transport Hostname="127.0.0.1" Port="9000" Protocol="http"/>
</Server>
</ServerGroup>
<UriGroup Name="sonar_host_URIs">
<Uri Name="/sonar*"/>
</UriGroup>
<Route ServerGroup="sonar_group" UriGroup="sonar_host_URIs" VirtualHostGroup="default_host"/>
Thanks.
In the web UI (while logged in as an admin user), go to Settings -> General and make sure the URL listed under Server Base URL starts with "https". This can also be set in the server's sonar.properties file using sonar.core.serverBaseURL
This is a well-known issue with the Ruby stack, and requires tweaking the web-server config -- not that of Sonar. On Apache you'd have to do the following, Im sure the pointers in the ticket will also lead you to a solution for IIS:
RequestHeader set X_FORWARDED_PROTO "https"