Re: [users@httpd] Authentication BEFORE proxying
Thanks Luca. Following worked. I was first asked the credentials, and only when they were correct, was I redirected to the proxied-url. ### Listen 2001 AuthType Basic AuthName "Restricted Content" AuthUserFile /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd Require valid-user ProxyPass http://127.0.0.1:2000/ ProxyPassReverse http://127.0.0.1:2000/ So, the issue of this email-trail is solved. Thanks a ton !!! I would love to have your assistance on the thread http://mail-archives.apache.org/mod_mbox/httpd-users/201704.mbox/browser, where I have posted the question in context of the solution provided by you. Thanks and Regards, Ajay On Sat, Apr 8, 2017 at 7:30 PM, Luca Toscano wrote: > Hi Ajay, > > 2017-04-08 8:23 GMT+02:00 Ajay Garg : > >> Hi All. >> >> If I setup the following in a virtual-host, >> >> >> >> Listen 9001 >> >> DocumentRoot /var/www/html >> >> >> AuthType Basic >> AuthName "Restricted Content" >> AuthUserFile /home/f5a6b457ba0d416cb4847bb3c4c6e6b6/.htpasswd >> Require valid-user >> >> >> ProxyPass / http://127.0.0.1:9000/ >> ProxyPassReverse / http://127.0.0.1:9000/ >> >> >> >> # >> >> >> and I type http://1.2.3.4:9001 in the browser, I get taken directly to >> the proxy-address, without the auth-dialog popping up. >> >> If however, I remove the "ProxyPass" and "ProxyPassReverse" directives, >> and I type the same http://1.2.3.4:9001 in the broswer, the auth-dialog >> pops up as expected. >> > > From what I can see in the config you are adding auth directives only to > the "/var/www/html" Directory context, and the proxying to the Virtual Host > one. > > More info about configuration sections: http://httpd.apache. > org/docs/current/sections.html > > >> Is there a way to first let the auth-dialog pop-up, and only if >> credentials are correct, to move to the proxy-address? >> > > I would try with a block containing ProxyPass/ProxyPassReverse > and Auth/Require directives. > > Hope that helps! > > Luca > > -- Regards, Ajay
[users@httpd] Re: ProxyPass and ProxyPassReverse not working for URLs other than /
Hi All. Following works perfect, http://1.2.3.4:2001 perfectly gets changed to the proxied-url http://1.2.3.4:2001/cgi-bin/webproc, and the proxied-site can be worked upon perfectly !! ### Listen 2001 AuthType Basic AuthName "Restricted Content" AuthUserFile /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd Require valid-user ProxyPass http://127.0.0.1:2000/ ProxyPassReverse http://127.0.0.1:2000/ However, if I try ### Listen 2001 AuthType Basic AuthName "Restricted Content" AuthUserFile /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd Require valid-user ProxyPass http://127.0.0.1:2000/ ProxyPassReverse http://127.0.0.1:2000/ and hit the url http://1.2.3.4:2001/2000, the url does get changed to http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained (with the text "The requested URL /cgi-bin/webproc was not found on this server." in Firefox). Any ideas how to do proper proxying for locations other than "/"? This is important, else we will have to open one-port-per-location, instead of using one-port for all locations. Will be grateful for help. Thanks and Regards, Ajay On Sat, Apr 8, 2017 at 10:41 AM, Ajay Garg wrote: > Hi All. > > > When I have the following configuration : > > # > > ProxyPass / http://127.0.0.1:9000/ > ProxyPassReverse / http://127.0.0.1:9000/ > > # > > and I type http://1.2.3.4 in the browser, the page is successfully > proxied to the forwarded port 9000, and the to-and-fro interaction is > perfect. > > > > However, if I use, > > # > > ProxyPass /9000/ http://127.0.0.1:9000/ > ProxyPassReverse /9000/ http://127.0.0.1:9000/ > > # > > and I type http://1.2.3.4/9000/ in the browser, it says the resource > cannot be found. > > > How can this be corrected? I am sure I am doing something wrong while > specifying the ProxyPass and ProxyPassReverse directives. > > > Thanks and Regards, > Ajay > -- Regards, Ajay
[users@httpd] Authentication BEFORE proxying
Hi All. If I setup the following in a virtual-host, Listen 9001 DocumentRoot /var/www/html AuthType Basic AuthName "Restricted Content" AuthUserFile /home/f5a6b457ba0d416cb4847bb3c4c6e6b6/.htpasswd Require valid-user ProxyPass / http://127.0.0.1:9000/ ProxyPassReverse / http://127.0.0.1:9000/ # and I type http://1.2.3.4:9001 in the browser, I get taken directly to the proxy-address, without the auth-dialog popping up. If however, I remove the "ProxyPass" and "ProxyPassReverse" directives, and I type the same http://1.2.3.4:9001 in the broswer, the auth-dialog pops up as expected. Is there a way to first let the auth-dialog pop-up, and only if credentials are correct, to move to the proxy-address? Looking forward to some help. Thanks and Regards, Ajay
[users@httpd] ProxyPass and ProxyPassReverse not working for URLs other than /
Hi All. When I have the following configuration : # ProxyPass / http://127.0.0.1:9000/ ProxyPassReverse / http://127.0.0.1:9000/ # and I type http://1.2.3.4 in the browser, the page is successfully proxied to the forwarded port 9000, and the to-and-fro interaction is perfect. However, if I use, # ProxyPass /9000/ http://127.0.0.1:9000/ ProxyPassReverse /9000/ http://127.0.0.1:9000/ # and I type http://1.2.3.4/9000/ in the browser, it says the resource cannot be found. How can this be corrected? I am sure I am doing something wrong while specifying the ProxyPass and ProxyPassReverse directives. Thanks and Regards, Ajay
Re: [users@httpd] Some basic (idiotic) queries regarding tunnelling-proxy
Just wondering if we could pass an already-opened-TCP-socket instance to the browser. Intention is just to prevent the socket-creation on the browser (instead passing the already connected socket to the broswer), and let the browser start over from there on. Do I make sense? On Fri, Mar 24, 2017 at 10:14 AM, Ajay Garg wrote: > Hi All. > > I could have the proxying to work perfectly, using the awesome > step-by-step link at https://devops.profitbricks.com/tutorials/configure- > apache-as-a-reverse-proxy-using-mod_proxy-on-ubuntu/. Whenever I opened a > URL of type http://Intermediatary/path/to/url in *Server*'s browser, the > contents of page http://HTTP-Server/path/to/url opened up. > > Still, this requires the *Intermediatary* to have a public static > IP-Address. > Can this be done away with? > > Will be grateful for any replies. > > > Thanks and Regards, > Ajay > > > On Wed, Mar 22, 2017 at 11:22 PM, Ajay Garg > wrote: > >> Hi Rainer. >> >> Thanks for the help. >> >> I did some more googling, and (if I am not wrong), it seems >> https://httpd.apache.org/docs/2.4/mod/mod_proxy_http.html almost fits in >> our needs. >> >> We run mod_proxy on the *Intermediatary*. >> The end-user then opens a browser in *Server*, types in the >> hostname://path of the *Intermediatary*, and the mod_proxy then proxies the >> HTTP-stuff bi-directionally between the *HTTP-Server* and *Server*. >> >> My only concern, is that this solution needs the *Intermediatary* to have >> a public static IP. >> Is there a way objective can be achieved without needing to provide a >> public static IP to *Intermediatary*? >> >> >> >> >> On Wed, Mar 22, 2017 at 8:26 PM, Rainer Canavan < >> rainer.cana...@sevenval.com> wrote: >> >>> > Now, we require something like opening an IFrame on the Server, and >>> provide >>> > virtual access to the HTTP-Server (via Intermediatary), something like >>> what >>> > Teamviewer does. We have the ability to modify to Server and >>> Intermediatary, >>> > but not HTTP-Server in the general case. >>> > >>> > It would be great to have a Teamviewer-like experience, providing >>> access of >>> > the HTTP-Server on the Server (via Intermediatary as the >>> tunnelling-proxy). >>> > We are running Linux-flavours on Server and Intermediatary. >>> >>> I don't understand what half of your statements may exactly mean, but >>> this doesn't appear to be an apache httpd related request. I think >>> the dynamic proxy option of most ssh clients (-D for openssh), used >>> as a SOCKS proxy in your browser may solve your problem. If that >>> doesn't help, some sort of VPN tunnel may be an alternative. >>> >>> rainer >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>> For additional commands, e-mail: users-h...@httpd.apache.org >>> >>> >> >> >> -- >> Regards, >> Ajay >> > > > > -- > Regards, > Ajay > -- Regards, Ajay
Re: [users@httpd] Some basic (idiotic) queries regarding tunnelling-proxy
Hi All. I could have the proxying to work perfectly, using the awesome step-by-step link at https://devops.profitbricks.com/tutorials/configure-apache-as-a-reverse-proxy-using-mod_proxy-on-ubuntu/. Whenever I opened a URL of type http://Intermediatary/path/to/url in *Server*'s browser, the contents of page http://HTTP-Server/path/to/url opened up. Still, this requires the *Intermediatary* to have a public static IP-Address. Can this be done away with? Will be grateful for any replies. Thanks and Regards, Ajay On Wed, Mar 22, 2017 at 11:22 PM, Ajay Garg wrote: > Hi Rainer. > > Thanks for the help. > > I did some more googling, and (if I am not wrong), it seems > https://httpd.apache.org/docs/2.4/mod/mod_proxy_http.html almost fits in > our needs. > > We run mod_proxy on the *Intermediatary*. > The end-user then opens a browser in *Server*, types in the > hostname://path of the *Intermediatary*, and the mod_proxy then proxies the > HTTP-stuff bi-directionally between the *HTTP-Server* and *Server*. > > My only concern, is that this solution needs the *Intermediatary* to have > a public static IP. > Is there a way objective can be achieved without needing to provide a > public static IP to *Intermediatary*? > > > > > On Wed, Mar 22, 2017 at 8:26 PM, Rainer Canavan < > rainer.cana...@sevenval.com> wrote: > >> > Now, we require something like opening an IFrame on the Server, and >> provide >> > virtual access to the HTTP-Server (via Intermediatary), something like >> what >> > Teamviewer does. We have the ability to modify to Server and >> Intermediatary, >> > but not HTTP-Server in the general case. >> > >> > It would be great to have a Teamviewer-like experience, providing >> access of >> > the HTTP-Server on the Server (via Intermediatary as the >> tunnelling-proxy). >> > We are running Linux-flavours on Server and Intermediatary. >> >> I don't understand what half of your statements may exactly mean, but >> this doesn't appear to be an apache httpd related request. I think >> the dynamic proxy option of most ssh clients (-D for openssh), used >> as a SOCKS proxy in your browser may solve your problem. If that >> doesn't help, some sort of VPN tunnel may be an alternative. >> >> rainer >> >> - >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >> > > > -- > Regards, > Ajay > -- Regards, Ajay
Re: [users@httpd] Some basic (idiotic) queries regarding tunnelling-proxy
Hi Rainer. Thanks for the help. I did some more googling, and (if I am not wrong), it seems https://httpd.apache.org/docs/2.4/mod/mod_proxy_http.html almost fits in our needs. We run mod_proxy on the *Intermediatary*. The end-user then opens a browser in *Server*, types in the hostname://path of the *Intermediatary*, and the mod_proxy then proxies the HTTP-stuff bi-directionally between the *HTTP-Server* and *Server*. My only concern, is that this solution needs the *Intermediatary* to have a public static IP. Is there a way objective can be achieved without needing to provide a public static IP to *Intermediatary*? On Wed, Mar 22, 2017 at 8:26 PM, Rainer Canavan wrote: > > Now, we require something like opening an IFrame on the Server, and > provide > > virtual access to the HTTP-Server (via Intermediatary), something like > what > > Teamviewer does. We have the ability to modify to Server and > Intermediatary, > > but not HTTP-Server in the general case. > > > > It would be great to have a Teamviewer-like experience, providing access > of > > the HTTP-Server on the Server (via Intermediatary as the > tunnelling-proxy). > > We are running Linux-flavours on Server and Intermediatary. > > I don't understand what half of your statements may exactly mean, but > this doesn't appear to be an apache httpd related request. I think > the dynamic proxy option of most ssh clients (-D for openssh), used > as a SOCKS proxy in your browser may solve your problem. If that > doesn't help, some sort of VPN tunnel may be an alternative. > > rainer > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > -- Regards, Ajay
[users@httpd] Some basic (idiotic) queries regarding tunnelling-proxy
Hi All. We have the following architecture :: Server <==> Intermediatary <==> HTTP-Server * Server and Intermediatary communicate over the internet as usual. * Intermediatary and HTTP-Server communicate over a local-interface. HTTP-Server is reachable at the Intermediatary, but the HTTP-Server is NOT publically-connected to the Server. Now, we require something like opening an IFrame on the Server, and provide virtual access to the HTTP-Server (via Intermediatary), something like what Teamviewer does. We have the ability to modify to Server and Intermediatary, but not HTTP-Server in the general case. It would be great to have a Teamviewer-like experience, providing access of the HTTP-Server on the Server (via Intermediatary as the tunnelling-proxy). We are running Linux-flavours on Server and Intermediatary. So, what would be the best way to go about fulfilling our requirements? Will be grateful for any replies. Thanks and Regards, Ajay
Re: [users@httpd] Query/Issue uploading file via HTTP POST/PUT using absolute basics
Thanks Eric for the lightning-fast reply :) That did it !! Thanks and Regards, Ajay ## LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so LoadModule dav_fs_module /usr/lib/apache2/modules/mod_dav_fs.so ## On Sun, Aug 9, 2015 at 10:47 PM, Eric Covener wrote: > On Sun, Aug 9, 2015 at 1:09 PM, Ajay Garg wrote: > > I have tried googling and tried whatever it threw us, but I am unable to > > make the file-upload work. > > We will be grateful if we could let be known where I am making the > mistake. > > > You need a plugin or script willing to do something with the resource > you PUT. Maybe mod_dav is enough. > > -- > Eric Covener > cove...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > -- Regards, Ajay
[users@httpd] Query/Issue uploading file via HTTP POST/PUT using absolute basics
Hi All.
We desire to set up file upload/download feature with a HTTP-Web-Server
where the client runs in an embedded-environment, and thus wish to achieve
this using the absolute basic primitives - socket programming (on the
client-side that is).
We have been able to achieve the download functionality.
For brevity, this is how we do it ::
##
*telnet localhost 80*
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
*GET /1/test_download_file.txt HTTP/1.0\r\n\r\n*
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2015 16:50:54 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Sun, 09 Aug 2015 16:50:23 GMT
ETag: "1d-51ce3aa4aa242"
Accept-Ranges: bytes
Content-Length: 29
Connection: close
Content-Type: text/plain
Testing download success !!!
Connection closed by foreign host.
##
We tested our code on a local HTTP-server, and the same code is serving us
well with the production HTTP-server.
When we try the same for file-uploading, this is what we get ::
##
*telnet localhost 80*
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
*PUT /1/test_upload_file.txt HTTP/1.0\r\n\r\n*
*Content-Length: 41234*
HTTP/1.1 405 Method Not Allowed
Date: Sun, 09 Aug 2015 16:58:38 GMT
Server: Apache/2.4.7 (Ubuntu)
Allow: GET,HEAD,POST,OPTIONS
Content-Length: 317
Connection: close
Content-Type: text/html; charset=iso-8859-1
405 Method Not Allowed
Method Not Allowed
The requested method PUT is not allowed for the URL
/1/test_upload_file.txt.
Apache/2.4.7 (Ubuntu) Server at 127.0.1.1 Port 80
Connection closed by foreign host.
##
Following is the Virtual-Host configuration ::
##
# The ServerName directive sets the request scheme, hostname and port
that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
AllowOverride All
Order Allow,Deny
Allow from all
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
##
Please note that in the test-environment, the http-server is running on
Ubuntu 14.04 on a 32-bit machine desktop.
(Just to re-iterate, the file-download works using the absolute basics, but
the file-upload does not).
I have tried googling and tried whatever it threw us, but I am unable to
make the file-upload work.
We will be grateful if we could let be known where I am making the mistake.
Looking forward to some help ...
Thanks and Regards,
Ajay
Re: [users@httpd] Query regarding "mod_rewrite" module when handling URLs, containing "POST" data
Ahh.. thanks !!! :)
More specifically, we wanted the re-directions to work only for
GET-requests.
So,
RewriteCond %{REQUEST_METHOD} GET
did the trick !!!
Thanks a ton for the prompt reply :)
On Wed, Sep 4, 2013 at 12:42 AM, Daniel Gruno wrote:
> On 09/03/2013 09:06 PM, Ajay Garg wrote:
> > Hi all.
> >
> > In our setup, we need to do conditional-redirects.
> > Till now, we were able to accomplish them, by using a smart combination
> > of "RewriteCond", "RewriteRule" and "QSA".
> >
> > However, we now face a situation, wherein we need to do re-directs, only
> > if the original-URL does not contain POST-variables/parameters (although
> > they may contain any number of GET-variables). Going through the
> > "mod_rewrite" documentation, I could not find any way to do
> > conditional-redirect, for URLs containing POST-variables/parameters.
> >
> >
> > Is it even possible to accomplish via HTTPD?
> > If yes, I will be grateful for pointers :)
> >
> >
> >
> > Thanks and Regards,
> > Ajay
> Here's a hint:
>
> RewriteCond %{REQUEST_METHOD} ^POST$
> RewriteRule ..
>
> With regards,
> Daniel.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
--
Regards,
Ajay
[users@httpd] Query regarding "mod_rewrite" module when handling URLs, containing "POST" data
Hi all. In our setup, we need to do conditional-redirects. Till now, we were able to accomplish them, by using a smart combination of "RewriteCond", "RewriteRule" and "QSA". However, we now face a situation, wherein we need to do re-directs, only if the original-URL does not contain POST-variables/parameters (although they may contain any number of GET-variables). Going through the "mod_rewrite" documentation, I could not find any way to do conditional-redirect, for URLs containing POST-variables/parameters. Is it even possible to accomplish via HTTPD? If yes, I will be grateful for pointers :) Thanks and Regards, Ajay
Re: [users@httpd] Queries regarding the feasibility of achieving a use-case with HTTPD
Thanks Pete for the reply. One question regarding the module at http://home.digithi.de/digithi/dev/mod_auth_cookie_mysql/ :: it says that "Additionally nobody can "hack" the system by manipulating the cookie values because they are only valid for one session". Does that mean that once the user exits the window, the user will be required to authenticate/login again? Or "one session" here means the time-until-which-user-explicitly-logs-out (which may run into days)? This question is very important for our use-case, because we intend to truly implement an "almost" Single-Sign-On (I say "almost", because the user shouldn't need to login, until the cookie expires, say in 30 days). Will be grateful for clearances :) On Sun, Aug 25, 2013 at 3:20 PM, Pete Houston wrote: > On Sat, Aug 24, 2013 at 04:44:46PM +0530, Ajay Garg wrote: > > Is the above workflow possible by merely using HTTPD, or some form of > > external proxy-software (like "squid") is required? > > Yes, this is possible with just httpd. > > > If it is indeed possible to achieve the above with just HTTPD, I will be > > grateful if you could let me know how to add redirections, so that > > any URL goes via the "login.php" in-between (of course, if the user has > > already authenticated once, he is taken directly to the URL). > > Do not use redirections - use the proper authnz mechanisms instead. > For a worked example of how to do it correctly see > http://home.digithi.de/digithi/dev/mod_auth_cookie_mysql/ > > Pete > -- > Openstrike - improving business through open source > http://www.openstrike.co.uk/ or call 01722 770036 / 07092 020107 > -- Regards, Ajay
[users@httpd] Re: Queries regarding the feasibility of achieving a use-case with HTTPD
Hi all. I could accomplish the first-part, using the "Redirect" directive in "/etc/httpd/conf/httpd.conf" as follows :: # Redirect permanent /alias1 http://www.servername.com/login/login.php Redirect permanent /alias2 http://www.servername.com/login/login.php Redirect permanent /alias3 http://www.servername.com/login/login.php ... ... Redirect permanent /aliasn http://www.servername.com/login/login.php # Thus, I will be grateful if someone could lend me a "trick", to have available the "original URL address" available in login.php, so that I can redirect to this "original URL address" after doing the authentication stuff. For example, using the above "first part solution", if a user enters a URL of type http://www.servername.com/alias2/deep/internal/url, then he will be nicely redirected (the first time) automatically to http://www.servername.com/login/login.php. Thereafter, we NEED the original-url (http://www.servername.com/alias2/deep/internal/url) in login.php, so that the user may finally be redirected (the second time) automatically to the desired URL, after the authentication-stuff is done. Looking forward to a reply, for the "second part of the mystery" :) On Sat, Aug 24, 2013 at 4:44 PM, Ajay Garg wrote: > Hi all. > > Let me first present the use-case :) > > > > === USE-CASE BEGIN === > > I have a number of directives (via the .conf > files), and each director has an alias for it. > So, my server can present different stuff, in accordance with the URLS > like :: > > http://127.0.0.1/alias1 > http://127.0.0.1/alias2 > ... > ... > http://127.0.0.1/aliasn > > > Now, I desire to add authentication, whenever any user visits any of these > directories/aliases/links, or any directories/aliases/llinks in their > sub-domains. > > > Thus, the ideal workflow desired is :: > > a) > User enters in the browser, a URL like " > http://127.0.0.1/alias1//deep/internal/url"; > > b) > He is AUTOMATICALLY re-directed to a login page, say " > http://127.0.0.1/login.php"; > > c) > User enters the credentials, and presses the "login" button > in login.php. > > d) > User is then AUTOMATICALLY taken to " > http://127.0.0.0.1/alias1/deep/internal/url"; > > e) > Thereafter, whenever the user enters into ANY URL (i.e. any > directory/alias, and not just "alias1"), he should be taken directly to the > url > (withot requiring to enter the credentials again). > > > > Thus, my queries are :: > > i) > Is the above workflow possible by merely using HTTPD, or some form of > external proxy-software (like "squid") is required? > > ii) > If it is indeed possible to achieve the above with just HTTPD, I will be > grateful if you could let me know how to add redirections, so that > any URL goes via the "login.php" in-between (of course, if the user has > already authenticated once, he is taken directly to the URL). > > > Note that I understand that to truly require only one-time authentication, > I will be required to set up "cookies". > > My major query here is, as to how can we setup redirections in HTTPD in > the way I have described (of course, if it is possible to do so, without > requiring > any external proxy-software) :) > > > -- > Regards, > Ajay > -- Regards, Ajay
[users@httpd] Queries regarding the feasibility of achieving a use-case with HTTPD
Hi all. Let me first present the use-case :) === USE-CASE BEGIN === I have a number of directives (via the .conf files), and each director has an alias for it. So, my server can present different stuff, in accordance with the URLS like :: http://127.0.0.1/alias1 http://127.0.0.1/alias2 ... ... http://127.0.0.1/aliasn Now, I desire to add authentication, whenever any user visits any of these directories/aliases/links, or any directories/aliases/llinks in their sub-domains. Thus, the ideal workflow desired is :: a) User enters in the browser, a URL like " http://127.0.0.1/alias1//deep/internal/url"; b) He is AUTOMATICALLY re-directed to a login page, say " http://127.0.0.1/login.php"; c) User enters the credentials, and presses the "login" button in login.php. d) User is then AUTOMATICALLY taken to " http://127.0.0.0.1/alias1/deep/internal/url"; e) Thereafter, whenever the user enters into ANY URL (i.e. any directory/alias, and not just "alias1"), he should be taken directly to the url (withot requiring to enter the credentials again). Thus, my queries are :: i) Is the above workflow possible by merely using HTTPD, or some form of external proxy-software (like "squid") is required? ii) If it is indeed possible to achieve the above with just HTTPD, I will be grateful if you could let me know how to add redirections, so that any URL goes via the "login.php" in-between (of course, if the user has already authenticated once, he is taken directly to the URL). Note that I understand that to truly require only one-time authentication, I will be required to set up "cookies". My major query here is, as to how can we setup redirections in HTTPD in the way I have described (of course, if it is possible to do so, without requiring any external proxy-software) :) -- Regards, Ajay
[users@httpd] Another "speed" question :)
Hi all. In part of ongoing investigations, i am evaluating the methods to setup the server side component of simple web-services, where there is a simple transfer of data. In this regard, I am considering the following two options :: a) Apache AXIS + SOAP b) Spache Tomcat + Servlets Which, in general, has a lower memory footprint, and consumes lesser resources in general? Will be grateful for ideas :) -- Regards, Ajay
Re: [users@httpd] Query regarding performance-differences, in using a "servlet" VS "PHP module"
On Fri, Aug 9, 2013 at 10:32 PM, Ajay Garg wrote: > Thanks Eric for the reply. > > So, is it possible to run PHP in Apache, with each client-request being > serviced in a different thread (and not a new-process-per-new-request)? > Because, it is a well known fact that a process is a much-higher > Sorry, I meant a "much-heavier (resource-consumption wise)" > entity than a thread. > > If not, Apache-Tomcat looks to be clear winner over PHP-in-Apache (please > correct me if I am wrong) :) > > Please, I must say at the outset that I am not in favour, or against any > technology, but just wish to gauge some inputs on Apache internals, from > the Apache experts :) > > > On Fri, Aug 9, 2013 at 9:57 PM, Eric Covener wrote: > >> On Fri, Aug 9, 2013 at 11:57 AM, Ajay Garg >> wrote: >> > Hi all. >> > >> > I was just doing some rudimentary research on what would be the best >> > solution to implement server-side operations of our webapp. >> > The "servlet" and "PHP" seem two widely used solutions. >> > >> > >> > However, there is one important thing that struck me. >> > >> > Looking at >> http://www.tutorialspoint.com/servlets/servlets-life-cycle.htm, >> > it states that every new client-request to a servlet, spawns a new >> thread. >> > On the other hand, looking at >> > http://php.net/manual/en/internals2.structure.lifecycle.php, it states >> that >> > the Apache module MIGHT map different requests to a single process >> (with the >> > CGI model DEFINITELY using the one-process-per-request implementation). >> > >> > Looking at the above, it seems that using Apache Tomcat to host a >> servlet, >> > is better than running a PHP module in Apache (as far as >> > resource-requirements are concerned at the server). >> > >> > Is my understanding correct? >> >> It's not a point of differentation. You can run either technology many >> different overlapping ways. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >> > > > -- > Regards, > Ajay > -- Regards, Ajay
Re: [users@httpd] Query regarding performance-differences, in using a "servlet" VS "PHP module"
Thanks Eric for the reply. So, is it possible to run PHP in Apache, with each client-request being serviced in a different thread (and not a new-process-per-new-request)? Because, it is a well known fact that a process is a much-higher entity than a thread. If not, Apache-Tomcat looks to be clear winner over PHP-in-Apache (please correct me if I am wrong) :) Please, I must say at the outset that I am not in favour, or against any technology, but just wish to gauge some inputs on Apache internals, from the Apache experts :) On Fri, Aug 9, 2013 at 9:57 PM, Eric Covener wrote: > On Fri, Aug 9, 2013 at 11:57 AM, Ajay Garg wrote: > > Hi all. > > > > I was just doing some rudimentary research on what would be the best > > solution to implement server-side operations of our webapp. > > The "servlet" and "PHP" seem two widely used solutions. > > > > > > However, there is one important thing that struck me. > > > > Looking at > http://www.tutorialspoint.com/servlets/servlets-life-cycle.htm, > > it states that every new client-request to a servlet, spawns a new > thread. > > On the other hand, looking at > > http://php.net/manual/en/internals2.structure.lifecycle.php, it states > that > > the Apache module MIGHT map different requests to a single process (with > the > > CGI model DEFINITELY using the one-process-per-request implementation). > > > > Looking at the above, it seems that using Apache Tomcat to host a > servlet, > > is better than running a PHP module in Apache (as far as > > resource-requirements are concerned at the server). > > > > Is my understanding correct? > > It's not a point of differentation. You can run either technology many > different overlapping ways. > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > -- Regards, Ajay
[users@httpd] Query regarding performance-differences, in using a "servlet" VS "PHP module"
Hi all. I was just doing some rudimentary research on what would be the best solution to implement server-side operations of our webapp. The "servlet" and "PHP" seem two widely used solutions. However, there is one important thing that struck me. Looking at http://www.tutorialspoint.com/servlets/servlets-life-cycle.htm, it states that every new client-request to a servlet, spawns a new thread. On the other hand, looking at http://php.net/manual/en/internals2.structure.lifecycle.php, it states that the Apache module MIGHT map different requests to a single process (with the CGI model DEFINITELY using the one-process-per-request implementation). Looking at the above, it seems that using Apache Tomcat to host a servlet, is better than running a PHP module in Apache (as far as resource-requirements are concerned at the server). Is my understanding correct? I will be grateful to any clearances on my doubts :) Regards, Ajay
Re: [users@httpd] HTTPD shutting down (gracefully), without any seemingly reason
On Mon, Jul 22, 2013 at 8:56 PM, Mike Rumph wrote:
> Hello Ajay,
>
> In the httpd.service file did you try changing the Service type to forking?
> -
> https://bugzilla.redhat.com/**show_bug.cgi?id=909703#c5<https://bugzilla.redhat.com/show_bug.cgi?id=909703#c5>
>
Mike,
That did it !
Thanks a ton !!! What would I have done without you .. :P :)
>
> Otherwise, here is a link that others have found useful for this problem:
> -
> http://www.yodi.sg/fix-httpd-**apache-wont-start-problem-in-**fedora-18/<http://www.yodi.sg/fix-httpd-apache-wont-start-problem-in-fedora-18/>
>
> Take care,
>
> Mike Rumph
>
>
> On 7/21/2013 8:56 PM, Ajay Garg wrote:
>
>> Hi all.
>>
>> I have been trying to run HTTPD with "mod_wsgi" since last some days on a
>> Fedora-18 ARM, and have been having issues.
>> Following is the latest one.
>>
>> When I start HTTPD, it dies immediately.
>> Following are the setup-files/logs.
>>
>>
>>
>> == /etc/httpd/conf/httpd.conf ==
>>
>> ##**##**
>> ##
>> WSGIRestrictEmbedded On
>> WSGIPythonOptimize 1
>>
>> LoadModule mpm_event_module modules/mod_mpm_event.so
>> LoadModule wsgi_module modules/mod_wsgi.so
>> LoadModule authz_core_module modules/mod_authz_core.so
>> LoadModule unixd_module modules/mod_unixd.so
>> LoadModule log_config_module modules/mod_log_config.so
>> LoadModule expires_module modules/mod_expires.so
>>
>> User apache
>> Group apache
>>
>>
>> ServerName localhost
>>
>> ErrorLog /var/www/sites/pathagar/logs/**error.log
>> CustomLog /var/www/sites/pathagar/logs/**access.log combined
>>
>> WSGIDaemonProcess pathagar processes=2 threads=3
>> stack-size=1048576 maximum-requests=500 inactivity-timeout=300
>> display-name=%{GROUP}
>> python-path=/var/www/sites/**pathagar/env/lib/python2.7/**site-packages
>> WSGIProcessGroup pathagar
>> WSGIScriptAlias / /var/www/sites/pathagar/src/**pathagar/wsgi.py
>>
>> Options -Indexes
>>
>> ExpiresActive On
>>
>> ExpiresByType image/jpg "access plus 2 hours"
>> ExpiresByType image/png "access plus 2 hours"
>>
>> ExpiresByType text/css "access plus 10 years"
>> ExpiresByType application/x-javascript "access plus 10 years"
>>
>>
>> WSGIProcessGroup pathagar
>> WSGIScriptReloading On
>>
>> Require all granted
>>
>>
>> Listen 80
>> ##**##**
>> ##
>>
>>
>>
>>
>>
>>
>> == /lib/systemd/system/httpd.**service ==
>>
>> ##**##**
>> ##
>> [Unit]
>> Description=The Apache HTTP Server
>> After=network.target remote-fs.target nss-lookup.target
>>
>> [Service]
>> Type=notify
>> EnvironmentFile=/etc/**sysconfig/httpd
>> #ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
>> ExecStart=/usr/sbin/httpd $OPTIONS -k start
>> ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
>> ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop
>> # We want systemd to give httpd some time to finish gracefully, but still
>> want
>> # it to kill httpd after TimeoutStopSec if something went wrong during the
>> # graceful stop. Normally, Systemd sends SIGTERM signal right after the
>> # ExecStop, which would kill httpd. We are sending useless SIGCONT here
>> to give
>> # httpd time to finish.
>> KillSignal=SIGCONT
>> PrivateTmp=true
>>
>> [Install]
>> WantedBy=multi-user.target
>> ##**##**
>> ##
>>
>>
>>
>>
>>
>> == Command/Output sequence ==
>>
>> ##**##**
>> ##
>> ~]$ sudo service httpd status
>> Redirecting to /bin/systemctl status httpd.service
>> httpd.service - The Apache HTTP Server
>> Loaded: loaded (/usr/lib/systemd/system/**httpd.service; disabled)
>> Active: inactive (dead)
>> CGroup: name=systemd:/system/httpd.**service
>>
>> Jul 22 03:39:19 dhcppc1 systemd[1]: Starting The Apache HTTP Server...
>> Jul 22 03:39:20 dhcppc1 httpd[900]: AH00558: httpd: Could not reliably
>> d
[users@httpd] HTTPD shutting down (gracefully), without any seemingly reason
Hi all.
I have been trying to run HTTPD with "mod_wsgi" since last some days on a
Fedora-18 ARM, and have been having issues.
Following is the latest one.
When I start HTTPD, it dies immediately.
Following are the setup-files/logs.
== /etc/httpd/conf/httpd.conf ==
##
WSGIRestrictEmbedded On
WSGIPythonOptimize 1
LoadModule mpm_event_module modules/mod_mpm_event.so
LoadModule wsgi_module modules/mod_wsgi.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
User apache
Group apache
ServerName localhost
ErrorLog /var/www/sites/pathagar/logs/error.log
CustomLog /var/www/sites/pathagar/logs/access.log combined
WSGIDaemonProcess pathagar processes=2 threads=3
stack-size=1048576 maximum-requests=500 inactivity-timeout=300
display-name=%{GROUP}
python-path=/var/www/sites/pathagar/env/lib/python2.7/site-packages
WSGIProcessGroup pathagar
WSGIScriptAlias / /var/www/sites/pathagar/src/pathagar/wsgi.py
Options -Indexes
ExpiresActive On
ExpiresByType image/jpg "access plus 2 hours"
ExpiresByType image/png "access plus 2 hours"
ExpiresByType text/css "access plus 10 years"
ExpiresByType application/x-javascript "access plus 10 years"
WSGIProcessGroup pathagar
WSGIScriptReloading On
Require all granted
Listen 80
##
== /lib/systemd/system/httpd.service ==
##
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
#ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecStart=/usr/sbin/httpd $OPTIONS -k start
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop
# We want systemd to give httpd some time to finish gracefully, but still
want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to
give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
##
== Command/Output sequence ==
##
~]$ sudo service httpd status
Redirecting to /bin/systemctl status httpd.service
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: inactive (dead)
CGroup: name=systemd:/system/httpd.service
Jul 22 03:39:19 dhcppc1 systemd[1]: Starting The Apache HTTP Server...
Jul 22 03:39:20 dhcppc1 httpd[900]: AH00558: httpd: Could not reliably
determine the server...sage
Jul 22 03:39:20 dhcppc1 httpd[902]: AH00558: httpd: Could not reliably
determine the server...sage
Jul 22 03:39:22 dhcppc1 systemd[1]: Started The Apache HTTP Server.
Jul 22 03:40:12 dhcppc1 systemd[1]: Starting The Apache HTTP Server...
Jul 22 03:40:13 dhcppc1 httpd[1076]: AH00558: httpd: Could not reliably
determine the serve...sage
Jul 22 03:40:13 dhcppc1 httpd[1078]: AH00558: httpd: Could not reliably
determine the serve...sage
Jul 22 03:40:15 dhcppc1 systemd[1]: Started The Apache HTTP Server.
##
== Error logs ==
##
[Fri Jul 19 11:49:41.185572 2013] [mpm_event:notice] [pid 5461:tid
1074651136] AH00489: Apache/2.4.4 (Fedora) mod_wsgi/3.4 Python/2.7.3
configured -- resuming normal operations
[Fri Jul 19 11:49:41.186377 2013] [core:notice] [pid 5461:tid 1074651136]
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Fri Jul 19 21:00:11.843443 2013] [mpm_event:notice] [pid 950:tid
1074184944] AH00489: Apache/2.4.4 (Fedora) mod_wsgi/3.4 Python/2.7.3
configured -- resuming normal operations
[Fri Jul 19 21:00:11.849983 2013] [core:notice] [pid 950:tid 1074184944]
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Fri Jul 19 21:04:15.458708 2013] [core:warn] [pid 1218:tid 1075474432]
AH00098: pid file /run/httpd/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?
[Fri Jul 19 21:04:15.463761 2013] [mpm_event:notice] [pid 1218:tid
1075474432] AH00489: Apache/2.4.4 (Fedora) mod_wsgi/3.4 Python/2.7.3
configured -- resuming normal operations
[Fri Jul 19 21:04:15.463987 2013] [core:notice] [pid 1218:tid 1075474432]
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Fri Jul 19 21:05:00.056912 2013]
Re: [users@httpd] "httpd" service timing-out
Thanks a ton Mike.
Replacing the "ExecStart" line, as per
https://bugzilla.redhat.com/show_bug.cgi?id=909703#c5 did the trick :)
Thanks again... a ton !!! :)
On Fri, Jul 19, 2013 at 7:38 PM, Mike Rumph wrote:
> Hello Ajay,
>
> Then in that case the following link is more applicable:
>
> - http://httpd.apache.org/docs/2.4/programs/apachectl.html
>
> Apparently, the apachectl script can operate in two different modes.
> Your environment appears to be set up only for the second.
> So for this you would need to use "apachectl restart" or "apachectl
> graceful".
>
> I also found this related bug report from RedHat:
>
> - https://bugzilla.redhat.com/show_bug.cgi?id=909703
>
> Take care,
>
> Mike
>
>
>
> On 7/18/2013 10:50 PM, Ajay Garg wrote:
>
> Mike,
>
> Running either of the above two scripts, I get
>
> """
> Passing arguments to httpd using apachectl is no longer suppored.
> You can only start/stop/restart httpd using this script.
> If you want to pass extra arguments to httpd, edit the
> /etc/sysconfig/httpd config file.
> """
>
>
> :(
>
>
> On Fri, Jul 19, 2013 at 4:40 AM, Mike Rumph wrote:
>
>> Hello Ajay,
>>
>> You could try using "apachectl -k restart" or "apachectl -k graceful".
>>
>> The following link has these and other options for restarting Apache
>> httpd:
>>
>> - http://httpd.apache.org/docs/2.4/stopping.html#hup
>>
>> Thanks,
>>
>> Mike Rumph
>>
>>
>>
>> On 7/18/2013 2:54 PM, Ajay Garg wrote:
>>
>>> Hi all.
>>>
>>> I have used httpd to good effect since many months (mainly using it
>>> for uploading/downloading files via WebDAV) on a Fedora-18 ARM
>>> machine, and it has always worked like a charm.
>>>
>>> Now, we are in the process of setting up a book-server, based on
>>> OPDS-spec, and WSGI.
>>> However, when we setup the "httpd.conf" and do a "sudo service httpd
>>> restart", the service times out :(
>>>
>>>
>>>
>>> Following are our setups ::
>>>
>>>
>>> == /etc/httpd/conf/httpd.conf ==
>>>
>>>
>>> ##
>>> WSGIRestrictEmbedded On
>>> WSGIPythonOptimize 1
>>>
>>> LoadModule mpm_event_module modules/mod_mpm_event.so
>>> LoadModule wsgi_module modules/mod_wsgi.so
>>> LoadModule authz_core_module modules/mod_authz_core.so
>>> LoadModule unixd_module modules/mod_unixd.so
>>> LoadModule log_config_module modules/mod_log_config.so
>>> LoadModule expires_module modules/mod_expires.so
>>>
>>> User apache
>>> Group apache
>>>
>>>
>>> ServerName localhost
>>>
>>> ErrorLog /var/www/sites/pathagar/logs/error.log
>>> CustomLog /var/www/sites/pathagar/logs/access.log combined
>>>
>>> WSGIDaemonProcess pathagar processes=2 threads=3
>>> stack-size=1048576 maximum-requests=500 inactivity-timeout=300
>>> display-name=%{GROUP}
>>> python-path=/var/www/sites/pathagar/env/lib/python2.7/site-packages
>>> WSGIProcessGroup pathagar
>>> WSGIScriptAlias / /var/www/sites/pathagar/src/pathagar/wsgi.py
>>>
>>> Options -Indexes
>>>
>>> ExpiresActive On
>>>
>>> ExpiresByType image/jpg "access plus 2 hours"
>>> ExpiresByType image/png "access plus 2 hours"
>>>
>>> ExpiresByType text/css "access plus 10 years"
>>> ExpiresByType application/x-javascript "access plus 10 years"
>>>
>>>
>>> WSGIProcessGroup pathagar
>>> WSGIScriptReloading On
>>>
>>> Require all granted
>>>
>>>
>>> Listen 80
>>>
>>> ##
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> == Command/Output sequence==
>>>
>>>
>>> ##
>>> [olpc@dhcppc1 ~]$ sudo service httpd restart
>>> Redirecting to /bin/systemctl restart httpd.service
>>> Job for httpd.service failed. See 'systemctl status httpd.service' and
>>> 'journalctl
Re: [users@httpd] "httpd" service timing-out
Hi Tom.
Only the following is seen in "/etc/httpd/logs/error_log" ::
#
[Fri Jul 19 11:49:41.185572 2013] [mpm_event:notice] [pid 5461:tid
1074651136] AH00489: Apache/2.4.4 (Fedora) mod_wsgi/3.4 Python/2.7.3
configured -- resuming normal operations
[Fri Jul 19 11:49:41.186377 2013] [core:notice] [pid 5461:tid 1074651136]
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
#
On Fri, Jul 19, 2013 at 3:02 PM, Tom Evans wrote:
> On Thu, Jul 18, 2013 at 10:54 PM, Ajay Garg
> wrote:
> > Hi all.
> >
> > I have used httpd to good effect since many months (mainly using it
> > for uploading/downloading files via WebDAV) on a Fedora-18 ARM
> > machine, and it has always worked like a charm.
> >
> > Now, we are in the process of setting up a book-server, based on
> > OPDS-spec, and WSGI.
> > However, when we setup the "httpd.conf" and do a "sudo service httpd
> > restart", the service times out :(
> >
> >
> >
> > Following are our setups ::
> >
> >
> > == /etc/httpd/conf/httpd.conf ==
> >
> >
> ##
> > WSGIRestrictEmbedded On
> > WSGIPythonOptimize 1
> >
> > LoadModule mpm_event_module modules/mod_mpm_event.so
> > LoadModule wsgi_module modules/mod_wsgi.so
> > LoadModule authz_core_module modules/mod_authz_core.so
> > LoadModule unixd_module modules/mod_unixd.so
> > LoadModule log_config_module modules/mod_log_config.so
> > LoadModule expires_module modules/mod_expires.so
> >
> > User apache
> > Group apache
> >
> >
> > ServerName localhost
> >
> > ErrorLog /var/www/sites/pathagar/logs/error.log
> > CustomLog /var/www/sites/pathagar/logs/access.log combined
> >
> > WSGIDaemonProcess pathagar processes=2 threads=3
> > stack-size=1048576 maximum-requests=500 inactivity-timeout=300
> > display-name=%{GROUP}
> > python-path=/var/www/sites/pathagar/env/lib/python2.7/site-packages
> > WSGIProcessGroup pathagar
> > WSGIScriptAlias / /var/www/sites/pathagar/src/pathagar/wsgi.py
> >
> > Options -Indexes
> >
> > ExpiresActive On
> >
> > ExpiresByType image/jpg "access plus 2 hours"
> > ExpiresByType image/png "access plus 2 hours"
> >
> > ExpiresByType text/css "access plus 10 years"
> > ExpiresByType application/x-javascript "access plus 10 years"
> >
> >
> > WSGIProcessGroup pathagar
> > WSGIScriptReloading On
> >
> > Require all granted
> >
> >
> > Listen 80
> >
> ##
> >
> >
> >
> >
> >
> >
> >
> > == Command/Output sequence==
> >
> >
> ##
> > [olpc@dhcppc1 ~]$ sudo service httpd restart
> > Redirecting to /bin/systemctl restart httpd.service
> > Job for httpd.service failed. See 'systemctl status httpd.service' and
> > 'journalctl -n' for details.
> >
> ##
> >
> >
> >
> >
> >
> > == /var/log/messages ==
> >
> >
> ##
> > Jul 18 21:25:14 xo-c5-b9-6c systemd[1]: Starting The Apache HTTP
> Server...
> > Jul 18 21:26:44 xo-c5-b9-6c systemd[1]: httpd.service operation timed
> > out. Terminating.
> > Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: httpd.service stopping timed
> > out (2). Killing.
> > Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: Failed to start The Apache HTTP
> Server.
> > Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: Unit httpd.service entered
> failed state
> >
> ##
> >
> >
> >
> >
> > Any ideas what is being done wrong?
> >
> > I will be grateful for some pointers :)
> >
>
> What does the apache error log say?
>
> Cheers
>
> Tom
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
--
Regards,
Ajay
Re: [users@httpd] "httpd" service timing-out
Mike,
Running either of the above two scripts, I get
"""
Passing arguments to httpd using apachectl is no longer suppored.
You can only start/stop/restart httpd using this script.
If you want to pass extra arguments to httpd, edit the
/etc/sysconfig/httpd config file.
"""
:(
On Fri, Jul 19, 2013 at 4:40 AM, Mike Rumph wrote:
> Hello Ajay,
>
> You could try using "apachectl -k restart" or "apachectl -k graceful".
>
> The following link has these and other options for restarting Apache httpd:
>
> -
> http://httpd.apache.org/docs/**2.4/stopping.html#hup<http://httpd.apache.org/docs/2.4/stopping.html#hup>
>
> Thanks,
>
> Mike Rumph
>
>
>
> On 7/18/2013 2:54 PM, Ajay Garg wrote:
>
>> Hi all.
>>
>> I have used httpd to good effect since many months (mainly using it
>> for uploading/downloading files via WebDAV) on a Fedora-18 ARM
>> machine, and it has always worked like a charm.
>>
>> Now, we are in the process of setting up a book-server, based on
>> OPDS-spec, and WSGI.
>> However, when we setup the "httpd.conf" and do a "sudo service httpd
>> restart", the service times out :(
>>
>>
>>
>> Following are our setups ::
>>
>>
>> == /etc/httpd/conf/httpd.conf ==
>>
>> ##**##**
>> ##
>> WSGIRestrictEmbedded On
>> WSGIPythonOptimize 1
>>
>> LoadModule mpm_event_module modules/mod_mpm_event.so
>> LoadModule wsgi_module modules/mod_wsgi.so
>> LoadModule authz_core_module modules/mod_authz_core.so
>> LoadModule unixd_module modules/mod_unixd.so
>> LoadModule log_config_module modules/mod_log_config.so
>> LoadModule expires_module modules/mod_expires.so
>>
>> User apache
>> Group apache
>>
>>
>> ServerName localhost
>>
>> ErrorLog /var/www/sites/pathagar/logs/**error.log
>> CustomLog /var/www/sites/pathagar/logs/**access.log combined
>>
>> WSGIDaemonProcess pathagar processes=2 threads=3
>> stack-size=1048576 maximum-requests=500 inactivity-timeout=300
>> display-name=%{GROUP}
>> python-path=/var/www/sites/**pathagar/env/lib/python2.7/**site-packages
>> WSGIProcessGroup pathagar
>> WSGIScriptAlias / /var/www/sites/pathagar/src/**pathagar/wsgi.py
>>
>> Options -Indexes
>>
>> ExpiresActive On
>>
>> ExpiresByType image/jpg "access plus 2 hours"
>> ExpiresByType image/png "access plus 2 hours"
>>
>> ExpiresByType text/css "access plus 10 years"
>> ExpiresByType application/x-javascript "access plus 10 years"
>>
>>
>> WSGIProcessGroup pathagar
>> WSGIScriptReloading On
>>
>> Require all granted
>>
>>
>> Listen 80
>> ##**##**
>> ##
>>
>>
>>
>>
>>
>>
>>
>> == Command/Output sequence==
>>
>> ##**##**
>> ##
>> [olpc@dhcppc1 ~]$ sudo service httpd restart
>> Redirecting to /bin/systemctl restart httpd.service
>> Job for httpd.service failed. See 'systemctl status httpd.service' and
>> 'journalctl -n' for details.
>> ##**##**
>> ##
>>
>>
>>
>>
>>
>> == /var/log/messages ==
>>
>> ##**##**
>> ##
>> Jul 18 21:25:14 xo-c5-b9-6c systemd[1]: Starting The Apache HTTP Server...
>> Jul 18 21:26:44 xo-c5-b9-6c systemd[1]: httpd.service operation timed
>> out. Terminating.
>> Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: httpd.service stopping timed
>> out (2). Killing.
>> Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: Failed to start The Apache HTTP
>> Server.
>> Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: Unit httpd.service entered failed
>> state
>> ##**##**
>> ##
>>
>>
>>
>>
>> Any ideas what is being done wrong?
>>
>> I will be grateful for some pointers :)
>>
>>
>>
>>
>> Regards,
>> Ajay
>>
>> --**--**-
>> To unsubscribe, e-mail:
>> users-unsubscribe@httpd.**apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>>
>>
>>
>
> --**--**-
> To unsubscribe, e-mail:
> users-unsubscribe@httpd.**apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
--
Regards,
Ajay
[users@httpd] "httpd" service timing-out
Hi all.
I have used httpd to good effect since many months (mainly using it
for uploading/downloading files via WebDAV) on a Fedora-18 ARM
machine, and it has always worked like a charm.
Now, we are in the process of setting up a book-server, based on
OPDS-spec, and WSGI.
However, when we setup the "httpd.conf" and do a "sudo service httpd
restart", the service times out :(
Following are our setups ::
== /etc/httpd/conf/httpd.conf ==
##
WSGIRestrictEmbedded On
WSGIPythonOptimize 1
LoadModule mpm_event_module modules/mod_mpm_event.so
LoadModule wsgi_module modules/mod_wsgi.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
User apache
Group apache
ServerName localhost
ErrorLog /var/www/sites/pathagar/logs/error.log
CustomLog /var/www/sites/pathagar/logs/access.log combined
WSGIDaemonProcess pathagar processes=2 threads=3
stack-size=1048576 maximum-requests=500 inactivity-timeout=300
display-name=%{GROUP}
python-path=/var/www/sites/pathagar/env/lib/python2.7/site-packages
WSGIProcessGroup pathagar
WSGIScriptAlias / /var/www/sites/pathagar/src/pathagar/wsgi.py
Options -Indexes
ExpiresActive On
ExpiresByType image/jpg "access plus 2 hours"
ExpiresByType image/png "access plus 2 hours"
ExpiresByType text/css "access plus 10 years"
ExpiresByType application/x-javascript "access plus 10 years"
WSGIProcessGroup pathagar
WSGIScriptReloading On
Require all granted
Listen 80
##
== Command/Output sequence==
##
[olpc@dhcppc1 ~]$ sudo service httpd restart
Redirecting to /bin/systemctl restart httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and
'journalctl -n' for details.
##
== /var/log/messages ==
##
Jul 18 21:25:14 xo-c5-b9-6c systemd[1]: Starting The Apache HTTP Server...
Jul 18 21:26:44 xo-c5-b9-6c systemd[1]: httpd.service operation timed
out. Terminating.
Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: httpd.service stopping timed
out (2). Killing.
Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: Failed to start The Apache HTTP Server.
Jul 18 21:28:14 xo-c5-b9-6c systemd[1]: Unit httpd.service entered failed state
##
Any ideas what is being done wrong?
I will be grateful for some pointers :)
Regards,
Ajay
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Recommended way to setup file-uploading, in a Webdav based share
Thanks a lot John, for the reply !! On Tue, Jul 2, 2013 at 2:27 PM, John Doe wrote: > > From: Ajay Garg > > > I have been using a running HTTPD-server, that serves files via WebDAV. > > Now, I need to add the ability for clients to upload files to the same > > WebDAV directory/virtualhost. > > Hum... webDAV is used mainly for its writable features. > For just serving files, you do not need it. > So, if you use webDAV clients, you should already be all set. > The webDAV clients should be able to write files on the server. I had already checked that the server-directory is writable, by uploading a file via a small client-side python utility :) However, my query is regarding what is the most recommended way to achieve this? :) In particular, is it possible to get the uploading done, using a web-browser as the only client-side utility? (as that will do away with any needs of deploying any "special" client-side utility). On some googling, I find that invoking a PHP-based-server-side-script from a HTML "Upload"-Form might do the job, but I am not sure if using PHP with "httpd" is recommended, as "mod_dav" already seems to do the server-side job. Just a few starting-pointers on how to accomplish an "exclusive server-side solution, using only a browser at the client" will be greatly helpful :) :) Thanks again for the reply John !! > > From: http://httpd.apache.org/docs/current/mod/mod_dav.html > "This > extension to the HTTP protocol allows creating, moving, > copying, and deleting resources and collections on a remote web > server." > > JD > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > Regards, Ajay - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Recommended way to setup file-uploading, in a Webdav based share
Hi all. I have been using a running HTTPD-server, that serves files via WebDAV. These files are then easily downloadable to any machines, which have the IP-Address of my running HTTPD server :) Now, I need to add the ability for clients to upload files to the same WebDAV directory/virtualhost. Nothing fancy, just an additional, simple, vanilla "Upload file to server" feature (preferably via the browser itself). What is the recommended way to do this? ( I ask this, because on some googling, I found quite a few ways in the literature * HTML form + client-side-script * HTML form + server-side-script, etc). The only constraint that I have is that I intend to use the Apache HTTPD-server. Thus, it will be nice to hear some opinions on what is the most simple, reliable, robust way to implement this feature. ) Will be grateful for some help from the experts :) Regards, Ajay - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Re: Problem in configuring "WebDAV" on Debian Squeeze
Hi all.
Managed to solve the issue :)
Initially, I had been loading ssl-module manually in
"/etc/apache2/sites-available/default". As a result, the condition check
"" was not passing in "/etc/apache2/ports.conf".
Now, I loaded the module via "a2enmod ssl"; thus causing the "" condition to be true throughout; which ultimately solved the
issue - it opened port 443 for listening (which was embedded in the
"" condition in "/etc/apache2/ports.conf").
Thanks and Regards,
Ajay
On Wed, Sep 5, 2012 at 5:14 PM, Ajay Garg wrote:
> Hi all.
>
> I have been able to setup WebDAV sharing on a server hosted on Fedora-14
> and Fedora-17.
> However, when I try to do the same on a Debian Squeeze, I am unsuccessful.
>
>
> Here is the relevant info that I think is important ::
>
>
> === SETUP ===
>
> *
> Debian Squeeze is installed as a VM, on a Fedora-14 Virtualbox.
>
> *
> Thus, Debian is the "Guest", while Fedora-14 is the "Host".
>
>
>
>
>
>
>
>
> === CONFIG FILE ON DEBIAN VM ===
>
> Following are the contents of "/etc/apache2/sites-available/default" ::
>
>
>
> #
>
> ServerAdmin webmaster@localhost
> ServerName ceibal.uy:80
> DocumentRoot /var/www/apache2-default/
>
> Options FollowSymLinks
> AllowOverride None
>
>
> Options Indexes FollowSymLinks MultiViews
> AllowOverride None
> Order allow,deny
> Allow from 192.168.4.0/22
>
>
> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
>
> AllowOverride None
> Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
> Order allow,deny
> Allow from 192.168.4.0/22
>
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
>
> # Possible values include: debug, info, notice, warn, error, crit,
> # alert, emerg.
> LogLevel warn
>
> CustomLog ${APACHE_LOG_DIR}/access.log combined
>
> Alias /doc/ "/usr/share/doc/"
>
> Options Indexes MultiViews FollowSymLinks
> AllowOverride None
> Order deny,allow
> Allow from 192.168.4.0/22
> Deny from all
> Allow from 127.0.0.0/255.0.0.0 ::1/128
>
>
>
>
>
> LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
> LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
>
>
> SSLEngine on
>
> DocumentRoot /var/www
>
> Options FollowSymLinks
> AllowOverride None
>
>
> Options Indexes FollowSymLinks MultiViews
> AllowOverride None
> Order allow,deny
> allow from all
>
>
> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
>
> AllowOverride None
> Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
> Order allow,deny
> Allow from all
>
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
>
> # Possible values include: debug, info, notice, warn, error, crit,
> # alert, emerg.
> LogLevel warn
>
> CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
>
> Alias /doc/ "/usr/share/doc/"
>
> Options Indexes MultiViews FollowSymLinks
> AllowOverride None
> Order deny,allow
> Deny from all
> Allow from 127.0.0.0/255.0.0.0 ::1/128
>
>
> # SSL Engine Switch:
> # Enable/Disable SSL for this virtual host.
> SSLEngine on
>
> # A self-signed (snakeoil) certificate can be created by installing
> # the ssl-cert package. See
> # /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
> # If both key and certificate are stored in the same file, only the
> # SSLCertificateFile directive is needed.
> SSLCertificateFile/root/ssl.crt
> SSLCertificateKeyFile /root/ssl.key
>
> # Server Certificate Chain:
> # Point SSLCertificateChainFile at a file containing the
> # concatenation of PEM encoded CA certificates which form the
> # certificate chain for the server certificate. Alternatively
> # the referenced file can be the same as SSLCertificateFile
> # when the CA certificates are directly appended to the server
> # certificate for convinience.
> #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
>
> # Certificate Authority (CA):
> # Set the CA certificate verification path where to find CA
> # certificates for client authentication or alternat
[users@httpd] Problem in configuring "WebDAV" on Debian Squeeze
Hi all.
I have been able to setup WebDAV sharing on a server hosted on Fedora-14
and Fedora-17.
However, when I try to do the same on a Debian Squeeze, I am unsuccessful.
Here is the relevant info that I think is important ::
=== SETUP ===
*
Debian Squeeze is installed as a VM, on a Fedora-14 Virtualbox.
*
Thus, Debian is the "Guest", while Fedora-14 is the "Host".
=== CONFIG FILE ON DEBIAN VM ===
Following are the contents of "/etc/apache2/sites-available/default" ::
#
ServerAdmin webmaster@localhost
ServerName ceibal.uy:80
DocumentRoot /var/www/apache2-default/
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from 192.168.4.0/22
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from 192.168.4.0/22
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
Alias /doc/ "/usr/share/doc/"
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Allow from 192.168.4.0/22
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
SSLEngine on
DocumentRoot /var/www
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
Alias /doc/ "/usr/share/doc/"
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile/root/ssl.crt
SSLCertificateKeyFile /root/ssl.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# Access Control:
# With SSLRequire you can do per-direc
Re: [users@httpd] httpd on Debian
Alex, this is the output, when I run the command "apache2ctl -S" on my Debian VM (guest machine), hosted on a Fedora-14 machine :: ### VirtualHost configuration: wildcard NameVirtualHosts and _default_ servers: *:443 127.0.1.1 (/etc/apache2/sites-enabled/000-default:48) *:80 is a NameVirtualHost default server ceibal.uy (/etc/apache2/sites-enabled/000-default:1) port 80 namevhost ceibal.uy(/etc/apache2/sites-enabled/000-default:1) port 80 namevhost biblioteca.ceibal.edu.uy(/etc/apache2/sites-enabled/001-biblioteca:3) ### So, what does this indicate? Is the WebDAV configured correctly at least? If yes, then I just need to figure out the remote access thing (i.e. accessing webdav shares from the host machine, Fedora-14, via firefox) :-) Thanks and Regards, Ajay On Wed, Sep 5, 2012 at 12:06 PM, Alex Bligh wrote: > > > --On 5 September 2012 11:57:00 +0530 Ajay Garg > wrote: > > Does that mean that the webdav is still not properly configured/started? >> Or it could be a false negative? >> > > It means nothing is listening on port 443 of your localhost address. > That does not preclude it listening on port 443 of your ethernet > address. > > Try > apache2ctl -S > > which will tell you the hosts apache think's it has configured, and > have a look at your logs. > > (httpd -S requires other stuff to be set up on Debian) > > -- > Alex Bligh >
Re: [users@httpd] httpd on Debian
Thanks Alex. I think that I configured the webdav correctly, since after a lot of huffs and puffs, I could get "/etc/init.d/apache2 restart" working correctly on the Debian server machine. But then, I tried (on the Debian webdav server machine) :: ## [ajay@localhost Effective C++]$ telnet telnet> open 127.0.0.1 443 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet> ## Does that mean that the webdav is still not properly configured/started? Or it could be a false negative? Anyways, I have been stuck at a pinging issue, so I am not anyways able to access the webdav share via firefox, as detailed at http://www.linuxquestions.org/questions/showthread.php?p=4772907#post4772907 Any further help will be gratefully appreciated :) Thanks and Regards, Ajay On Wed, Sep 5, 2012 at 12:31 AM, Alex Bligh wrote: > Any pointers as to how may I proceed? Should I simply copy the things >> from the Fedora-versions; or there is some basic difference in >> configurations on Debian? >> > > Essentially the Debian/Ubuntu setup is not to use a big long config > but to include the contents of directories. > > On Debian, you probably want to put everything into your > sites-available/my-site-name > file (create one if it isn't there) then do > a2ensite my-site-name > and > /etc/init.d/apache2 reload > > You may need to > a2dissite default > > The directives are all the same (it's just where they are that > differs). > > -- > Alex Bligh > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@httpd.**apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
[users@httpd] httpd on Debian
Hi all. I have successfully been setting up secure-webdav based shared on Fedora. However, when I try to do the same for Debian squeeze, I see the structure of files are very different. * The file "/etc/apache2/httpd.conf" is empty !! * The file "/etc/apache2/mods-available/ssl.conf" is also different; it has no "VirtualHost" definition, and no definitions for "SSLCertificateFile" and "SSLCertificateKeyFile". Any pointers as to how may I proceed? Should I simply copy the things from the Fedora-versions; or there is some basic difference in configurations on Debian? Will be grateful for some quicky pointers :) .. especially, the approach I should follow on Debian. Thanks and Regards, Ajay
Re: [users@httpd] Is it possible to start httpd, with reading the certificates of non-root user?
Sander, I was stupid; when I changed the paths of the key-file and the cert-file, I interchanged them (put the cert-path where the key was expected; and vice-versa). Sorry. Regards, Ajay On Tue, Sep 4, 2012 at 7:53 PM, Sander Temme wrote: > Ajay, > > Looks like OpenSSL is finding something in your key file it can't parse... > Windows line endings maybe? > > S. > > -- > Sander Temme > san...@temme.net > > Sent from my phone > > On Sep 4, 2012, at 1:26 AM, Ajay Garg wrote: > > > Hi all. > > > > I have a WebDAV share setup in the context of httpd; and things work > like a charm, when the key- and crt-file are in the context of "root" user > and "root" group. > > > > > > However, if I generate the key and crt files in the context of some > other user; modify the paths in "/etc/httpd/conf.d/ssl.conf", and try to > restart, I get the logs :: > > > > > ## > > [Tue Sep 04 13:48:40 2012] [error] Init: Unable to read server > certificate from file /home/ajay/test_folder/ssl.key > > [Tue Sep 04 13:48:40 2012] [error] SSL Library Error: 218529960 > error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag > > [Tue Sep 04 13:48:40 2012] [error] SSL Library Error: 218595386 > error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error > > > ## > > > > > > > > So, just wish to ask :: Am I doing something which is not possible (by > design) ? :) > > > > Will be grateful for a reply. > > > > > > Thanks and Regards, > > Ajay > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
[users@httpd] Re: Is it possible to start httpd, with reading the certificates of non-root user?
Never mind.. I am an idiot. Sorry for the bother. Regards, Ajay On Tue, Sep 4, 2012 at 1:56 PM, Ajay Garg wrote: > Hi all. > > I have a WebDAV share setup in the context of httpd; and things work like > a charm, when the key- and crt-file are in the context of "root" user and > "root" group. > > > However, if I generate the key and crt files in the context of some other > user; modify the paths in "/etc/httpd/conf.d/ssl.conf", and try to restart, > I get the logs :: > > > ## > [Tue Sep 04 13:48:40 2012] [error] Init: Unable to read server certificate > from file /home/ajay/test_folder/ssl.key > [Tue Sep 04 13:48:40 2012] [error] SSL Library Error: 218529960 > error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag > [Tue Sep 04 13:48:40 2012] [error] SSL Library Error: 218595386 > error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error > > ## > > > > So, just wish to ask :: Am I doing something which is not possible (by > design) ? :) > > Will be grateful for a reply. > > > Thanks and Regards, > Ajay > > >
[users@httpd] Is it possible to start httpd, with reading the certificates of non-root user?
Hi all. I have a WebDAV share setup in the context of httpd; and things work like a charm, when the key- and crt-file are in the context of "root" user and "root" group. However, if I generate the key and crt files in the context of some other user; modify the paths in "/etc/httpd/conf.d/ssl.conf", and try to restart, I get the logs :: ## [Tue Sep 04 13:48:40 2012] [error] Init: Unable to read server certificate from file /home/ajay/test_folder/ssl.key [Tue Sep 04 13:48:40 2012] [error] SSL Library Error: 218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag [Tue Sep 04 13:48:40 2012] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error ## So, just wish to ask :: Am I doing something which is not possible (by design) ? :) Will be grateful for a reply. Thanks and Regards, Ajay
[users@httpd] An interesting observation
Hi all. I have been doing some testing with uploading large files to a httpd-based WebDAV server, and I notice that while uploading large files, if the connection breaks midway and the file is not transmitted completely, the (incomplete) file is deleted from the server automatically after a few seconds. So, a) I hope this is a feature, and not an accident? :P b) Secondly, if it is in fact a feature, can we have a way so that any new incoming/outcoming connection links are refused, till the time the cleaning up of (the) incomplete file(s) is done? We don't want the user to have an inconsistent view of the server. Looking forward to a reply. Thanks and Regards, Ajay
[users@httpd] Selective access to uploading-to/downloading-from a WebDAV share
Hi all. Is it possible to have selective access to uploading-to/downloading-from a WebDAV share, running in context of httpd? That is, we want to implement a scenario, wherein some users have been granted only uploading access; some users only download access; and some both uploading-and-downloading access. Possible options that might work to the rescue are :: a) Having the WebDAV-share-directory password protected; and having DIFFERENT passwords for upload and download? b) Having role-based access, wherein the user-info of the user, is observed to see for upload/download access? c) A combination of the above? I will be grateful to listen back for any ideas. Thanks and Regards, Ajay
Re: [users@httpd] Re: Problems following symlinks in httpd-webdav
Hi Eric. No matter what I do, I am not able to see the symlinks, when accessing httpd-based WebDAV shares via either of the following :: a) gnome-nautilus. b) browser. That was the reason I asked as to whether anyone has ever used this feature. Thanks and Regards, Ajay On Sun, May 27, 2012 at 5:58 PM, Eric Covener wrote: > On Sun, May 27, 2012 at 8:08 AM, Ajay Garg wrote: > > Ping :) > > > > Just a minor query (please, don't treat me arrogant). > > > > Has anyone worked with "symlinks" feature in httpd-2.2.17-1.fc14.i686 ? > > If yes > > > You'll have better luck with a specific question. > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
[users@httpd] Problems following symlinks in httpd-webdav
Hi all. I managed to set up a httpd-based WebDAV share (both on HTTP and HTTPS) some time back, through selfless help from this mailing list. Thanks a ton !!! Now, all works fine, except that I am not able to follow symlinks, while accessing them via browser. (The symlinks work fine on the server workstation though). I have already tried doing "sudo setenforce 0", but to no avail. Kindly help me, as to what I am doing wrong. Looking forward to a reply. Regards, Ajay Please find attached the contents of my original httpd.conf (i.e. without trying to access symlinks), and the modified httpd.conf (i.e. with trying to access symlinks). == ORIGINAL === # # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See http://httpd.apache.org/docs/2.2/> for detailed information. # In particular, see # http://httpd.apache.org/docs/2.2/mod/directives.html> # for a discussion of each configuration directive. # # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server process as a # whole (the 'global environment'). # 2. Directives that define the parameters of the 'main' or 'default' server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. # 3. Settings for virtual hosts, which allow Web requests to be sent to # different IP addresses or hostnames and have them handled by the # same Apache server process. # # Configuration and logfile names: If the filenames you specify for many # of the server's control files begin with "/" (or "drive:/" for Win32), the # server will use that explicit path. If the filenames do *not* begin # with "/", the value of ServerRoot is prepended -- so "logs/foo.log" # with ServerRoot set to "/etc/httpd" will be interpreted by the # server as "/etc/httpd/logs/foo.log". # ### Section 1: Global Environment # # The directives in this section affect the overall operation of Apache, # such as the number of concurrent requests it can handle or where it # can find its configuration files. # # # Don't give away too much information about all the subcomponents # we are running. Comment out this line if you don't mind remote sites # finding out what major optional modules you are running ServerTokens OS # # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # # NOTE! If you intend to place this on an NFS (or otherwise network) # mounted filesystem then please read the LockFile documentation # (available at http://httpd.apache.org/docs/2.2/mod/mpm_common.html#lockfile>); # you will save yourself a lot of trouble. # # Do NOT add a slash at the end of the directory path. # ServerRoot "/etc/httpd" # # PidFile: The file in which the server should record its process # identification number when it starts. Note the PIDFILE variable in # /etc/sysconfig/httpd must be set appropriately if this location is # changed. # PidFile run/httpd.pid # # Timeout: The number of seconds before receives and sends time out. # Timeout 60 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. # KeepAlive Off # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 5 ## ## Server-Pool Size Regulation (MPM specific) ## # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves StartServers 8 MinSpareServers5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 # worker MPM # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connections # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: constant number of worker threads in each server process # MaxRequestsPerChild: maximum number of reques
[users@httpd] Re: Is it possible to add custom properties in WebDAV, on the server side?
My bad. I had set the permissions on the required webdav folder; but was testing (after a lot of failed attempts) with a hardcoded path. Now, trying "fopen" and "fclose" on files with webdav-files, and it works fine. Sorry, Thanks and Regards, Ajay On Tue, Apr 17, 2012 at 1:00 PM, Ajay Garg wrote: > Hi all. > > I added a "perror" log statement, and I found "Permission denied" log in > "/etc/httpd/logs/error_log". > > I then, ensured the following :: > > a) > The directory containing the file had permissions set to 0777. > > > b) > The file had permissions set to 0777. > > > c) > I checked each option in "System -> Administration -> SeLinux management > -> Boolean -> apache". > > > But I still face the exact same scenarios as before effecting the above > three changes. > > > Kindly help me, as to what else I may try out. Please. > > > Thanks and Regards, > Ajay > > > On Tue, Apr 17, 2012 at 1:59 AM, Ajay Garg wrote: > >> Hi all. >> >> I figured out that I will have to make changes in the file >> "modules/dav/fs/repos.c" in httpd's code, to add custom properties. >> I did manage to tweak around a bit, and things went fine. >> So far so good :) >> >> Now, what I really intend is to read a file (on the server side), and >> transmit the contents of the file as a (custom) webdav property to the >> clients. >> As a part of this, I intend to "fopen" a file, read the contents, and >> then "fclose" the file. >> >> But when I do a "fopen", followed by a "fclose", the server crashes, with >> the following "error_log" :: >> >> >> # >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25683 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25684 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25685 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25686 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25687 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25688 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25689 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:31 2012] [notice] child pid 25690 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:32 2012] [notice] child pid 25708 exit signal >> Segmentation fault (11) >> [Tue Apr 17 01:57:33 2012] [notice] child pid 25709 exit signal >> Segmentation fault (11) >> >> # >> >> >> I have specifically not put in more details, as random googling seemed to >> indicate that there might be some configuration that needs to be tweaked, >> to enable "fopen" on "httpd". >> >> Is that so? :| >> >> I will be really grateful for a reply, as it's been close to two days, >> since this is bugging me. >> >> >> >> Looking forward to a reply. >> >> >> Regards, >> Ajay >> >> On Sat, Apr 14, 2012 at 11:54 PM, Ajay Garg wrote: >> >>> Ping :) >>> >>> Regards, >>> Ajay >>> >>> >>> On Fri, Apr 13, 2012 at 3:19 PM, Ajay Garg wrote: >>> >>>> Hi all. >>>> >>>> I have a Fedora 14 machine. >>>> >>>> I have been able to setup a WebDAV share, in httpd's context, at the >>>> server side. >>>> Also, I am able to (successfully) access the WebDAV share, through >>>> gnome-nautilus, on the client side. >>>> >>>> I am wondering, if there is a way to add custom properties on the >>>> server side, which could then be retrieved by "PROPFIND" ? >>>> Currently, I get the following properties via PROPFIND per resource :: >>>> >>>> >>>> >>>> ## >>>> getlastmodified= Thu, 12 Apr 2012 08:17:13 GMT >>>> supportedlock= >>>> >>>> >>>> >>>> getetag= "80a30-1e2-4bd76fbb9e370" >>>> getcontentlength= 482 >>>> resourcetype= >>>> creationdate= 2012-04-12T08:17:13Z >>>> getcontenttype= text/plain >>>> lockdiscovery= >>>> Failed for: [(u'DAV:', u'displayname'), (u'DAV:', u'owner')] >>>> Not Found (404). >>>> >>>> ## >>>> >>>> >>>> Looking forward to a reply. >>>> >>>> >>>> Regards, >>>> Ajay >>>> >>> >>> >> >
[users@httpd] Re: Is it possible to add custom properties in WebDAV, on the server side?
Hi all. I added a "perror" log statement, and I found "Permission denied" log in "/etc/httpd/logs/error_log". I then, ensured the following :: a) The directory containing the file had permissions set to 0777. b) The file had permissions set to 0777. c) I checked each option in "System -> Administration -> SeLinux management -> Boolean -> apache". But I still face the exact same scenarios as before effecting the above three changes. Kindly help me, as to what else I may try out. Please. Thanks and Regards, Ajay On Tue, Apr 17, 2012 at 1:59 AM, Ajay Garg wrote: > Hi all. > > I figured out that I will have to make changes in the file > "modules/dav/fs/repos.c" in httpd's code, to add custom properties. > I did manage to tweak around a bit, and things went fine. > So far so good :) > > Now, what I really intend is to read a file (on the server side), and > transmit the contents of the file as a (custom) webdav property to the > clients. > As a part of this, I intend to "fopen" a file, read the contents, and then > "fclose" the file. > > But when I do a "fopen", followed by a "fclose", the server crashes, with > the following "error_log" :: > > > # > [Tue Apr 17 01:57:31 2012] [notice] child pid 25683 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25684 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25685 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25686 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25687 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25688 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25689 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:31 2012] [notice] child pid 25690 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:32 2012] [notice] child pid 25708 exit signal > Segmentation fault (11) > [Tue Apr 17 01:57:33 2012] [notice] child pid 25709 exit signal > Segmentation fault (11) > > # > > > I have specifically not put in more details, as random googling seemed to > indicate that there might be some configuration that needs to be tweaked, > to enable "fopen" on "httpd". > > Is that so? :| > > I will be really grateful for a reply, as it's been close to two days, > since this is bugging me. > > > > Looking forward to a reply. > > > Regards, > Ajay > > On Sat, Apr 14, 2012 at 11:54 PM, Ajay Garg wrote: > >> Ping :) >> >> Regards, >> Ajay >> >> >> On Fri, Apr 13, 2012 at 3:19 PM, Ajay Garg wrote: >> >>> Hi all. >>> >>> I have a Fedora 14 machine. >>> >>> I have been able to setup a WebDAV share, in httpd's context, at the >>> server side. >>> Also, I am able to (successfully) access the WebDAV share, through >>> gnome-nautilus, on the client side. >>> >>> I am wondering, if there is a way to add custom properties on the server >>> side, which could then be retrieved by "PROPFIND" ? >>> Currently, I get the following properties via PROPFIND per resource :: >>> >>> >>> >>> ## >>> getlastmodified= Thu, 12 Apr 2012 08:17:13 GMT >>> supportedlock= >>> >>> >>> >>> getetag= "80a30-1e2-4bd76fbb9e370" >>> getcontentlength= 482 >>> resourcetype= >>> creationdate= 2012-04-12T08:17:13Z >>> getcontenttype= text/plain >>> lockdiscovery= >>> Failed for: [(u'DAV:', u'displayname'), (u'DAV:', u'owner')] >>> Not Found (404). >>> >>> ## >>> >>> >>> Looking forward to a reply. >>> >>> >>> Regards, >>> Ajay >>> >> >> >
[users@httpd] Re: Is it possible to add custom properties in WebDAV, on the server side?
Hi all. I figured out that I will have to make changes in the file "modules/dav/fs/repos.c" in httpd's code, to add custom properties. I did manage to tweak around a bit, and things went fine. So far so good :) Now, what I really intend is to read a file (on the server side), and transmit the contents of the file as a (custom) webdav property to the clients. As a part of this, I intend to "fopen" a file, read the contents, and then "fclose" the file. But when I do a "fopen", followed by a "fclose", the server crashes, with the following "error_log" :: # [Tue Apr 17 01:57:31 2012] [notice] child pid 25683 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25684 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25685 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25686 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25687 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25688 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25689 exit signal Segmentation fault (11) [Tue Apr 17 01:57:31 2012] [notice] child pid 25690 exit signal Segmentation fault (11) [Tue Apr 17 01:57:32 2012] [notice] child pid 25708 exit signal Segmentation fault (11) [Tue Apr 17 01:57:33 2012] [notice] child pid 25709 exit signal Segmentation fault (11) # I have specifically not put in more details, as random googling seemed to indicate that there might be some configuration that needs to be tweaked, to enable "fopen" on "httpd". Is that so? :| I will be really grateful for a reply, as it's been close to two days, since this is bugging me. Looking forward to a reply. Regards, Ajay On Sat, Apr 14, 2012 at 11:54 PM, Ajay Garg wrote: > Ping :) > > Regards, > Ajay > > > On Fri, Apr 13, 2012 at 3:19 PM, Ajay Garg wrote: > >> Hi all. >> >> I have a Fedora 14 machine. >> >> I have been able to setup a WebDAV share, in httpd's context, at the >> server side. >> Also, I am able to (successfully) access the WebDAV share, through >> gnome-nautilus, on the client side. >> >> I am wondering, if there is a way to add custom properties on the server >> side, which could then be retrieved by "PROPFIND" ? >> Currently, I get the following properties via PROPFIND per resource :: >> >> >> >> ## >> getlastmodified= Thu, 12 Apr 2012 08:17:13 GMT >> supportedlock= >> >> >> >> getetag= "80a30-1e2-4bd76fbb9e370" >> getcontentlength= 482 >> resourcetype= >> creationdate= 2012-04-12T08:17:13Z >> getcontenttype= text/plain >> lockdiscovery= >> Failed for: [(u'DAV:', u'displayname'), (u'DAV:', u'owner')] >> Not Found (404). >> >> ## >> >> >> Looking forward to a reply. >> >> >> Regards, >> Ajay >> > >
[users@httpd] Re: Is it possible to add custom properties in WebDAV, on the server side?
Ping :) Regards, Ajay On Fri, Apr 13, 2012 at 3:19 PM, Ajay Garg wrote: > Hi all. > > I have a Fedora 14 machine. > > I have been able to setup a WebDAV share, in httpd's context, at the > server side. > Also, I am able to (successfully) access the WebDAV share, through > gnome-nautilus, on the client side. > > I am wondering, if there is a way to add custom properties on the server > side, which could then be retrieved by "PROPFIND" ? > Currently, I get the following properties via PROPFIND per resource :: > > > > ## > getlastmodified= Thu, 12 Apr 2012 08:17:13 GMT > supportedlock= > > > > getetag= "80a30-1e2-4bd76fbb9e370" > getcontentlength= 482 > resourcetype= > creationdate= 2012-04-12T08:17:13Z > getcontenttype= text/plain > lockdiscovery= > Failed for: [(u'DAV:', u'displayname'), (u'DAV:', u'owner')] > Not Found (404). > > ## > > > Looking forward to a reply. > > > Regards, > Ajay >
[users@httpd] Is it possible to add custom properties in WebDAV, on the server side?
Hi all. I have a Fedora 14 machine. I have been able to setup a WebDAV share, in httpd's context, at the server side. Also, I am able to (successfully) access the WebDAV share, through gnome-nautilus, on the client side. I am wondering, if there is a way to add custom properties on the server side, which could then be retrieved by "PROPFIND" ? Currently, I get the following properties via PROPFIND per resource :: ## getlastmodified= Thu, 12 Apr 2012 08:17:13 GMT supportedlock= getetag= "80a30-1e2-4bd76fbb9e370" getcontentlength= 482 resourcetype= creationdate= 2012-04-12T08:17:13Z getcontenttype= text/plain lockdiscovery= Failed for: [(u'DAV:', u'displayname'), (u'DAV:', u'owner')] Not Found (404). ## Looking forward to a reply. Regards, Ajay
Re: [users@httpd] How does client decrypt data in a HTTPS-based WebDAV transfer
Thanks Tom.. Ahh.. that makes it even more efficient; since the symmetric key is the only one required for encryption/decryption. Moreover, this symmetric key is only known to the client and the server. Thanks Thanks and Regards, Ajay On Mon, Mar 26, 2012 at 2:52 PM, Tom Evans wrote: > On Mon, Mar 26, 2012 at 10:12 AM, Ajay Garg > wrote: > > Thanks a ton Sander. > > > > So on session setup-phase, the server sends the public-key to the client > > (which would hardly be a bother, even if it is intercepted by a > > eavesdropper). This public key is then used to encrypt the data on the > > client, send over the wire, and decrypted by the server's private key. > > > > That explains the client-to-server-transfer. > > > > However, just one last confirmation regarding the > server-to-client-transfer. > > Is another set of public-private (session) keys pair created? (This would > > then explain the server-to-client transfer seamlessly, wherein the client > > would send the (session) public key to the server; server would encrypt > data > > using this (session) public key; send the data over the wire; and the > client > > would then decrypt data using the (session) private key). > > > > Thanks Sander. You have really been a darling in all the help ;-) > > > > Thanks and Regards, > > Ajay > > > > > > No, that is not how SSL works. A brief synopsis: > > http://stackoverflow.com/questions/188266/how-are-ssl-certificates-verified > > More information can be found by searching the internet for "how does SSL > work". > > Cheers > > Tom > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
Re: [users@httpd] How does client decrypt data in a HTTPS-based WebDAV transfer
Thanks a ton Sander. So on session setup-phase, the server sends the public-key to the client (which would hardly be a bother, even if it is intercepted by a eavesdropper). This public key is then used to encrypt the data on the client, send over the wire, and decrypted by the server's private key. That explains the client-to-server-transfer. However, just one last confirmation regarding the server-to-client-transfer. Is another set of public-private (session) keys pair created? (This would then explain the server-to-client transfer seamlessly, wherein the client would send the (session) public key to the server; server would encrypt data using this (session) public key; send the data over the wire; and the client would then decrypt data using the (session) private key). Thanks Sander. You have really been a darling in all the help ;-) Thanks and Regards, Ajay On Mon, Mar 26, 2012 at 11:03 AM, Sander Temme wrote: > Ajay, > On Mar 25, 2012, at 9:54 PM, Ajay Garg wrote: > > > Thanks Eric for the reply. > > > > Eric, but how is the shared secret comfigured? > > I do not remember configuring anything like this for the HTTPS-based > WebDAV server. > > As your DAV client and the server set up their SSL connection, they > exchange information that is used by either side to derive a set of session > encryption keys. This starts with a piece of random data generated by the > client, wrapped in the public key from the server's certificate, and sent > to the server. Since only the server has the corresponding private key, no > eavesdropper can intercept this piece of data, and no one but the server > and client have the proper input material to derive those session keys. > > Once the session keys are created, they are used by either side to sign, > encrypt, decrypt and verify the SSL records sent across the connection. > > So the only thing that is pre-arranged is the key/certificate on the > server, and the fact that the client trusts the server certificate (through > the CA certificate in the client's key store or CA bundle). > > Hope this helps, > > S. > > > Thanks and Regards, > > Ajay > > > > On Sun, Mar 25, 2012 at 11:39 PM, Eric Covener > wrote: > > > BUT, HOW IS THE CLIENT ABLE TO DECRYPT THE DATA? (I have been running > both > > > webdav server and client on the same machine; so it might very well > > > be the case that some info from "ssl.conf" and/or "httpd.conf" is > being used > > > at the client side. However, I am just guessing ... > > > > Under SSL, the client and server negotiate a shared secret used to > > encrypt/decrypt the data. > > > > They can set this up securely because the client starts this process > > with info encrypted with the servers public key. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > > For additional commands, e-mail: users-h...@httpd.apache.org > > > > > > > -- > scte...@apache.orghttp://www.temme.net/sander/ > PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A > > View my availability: http://tungle.me/sctemme > > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
Re: [users@httpd] How does client decrypt data in a HTTPS-based WebDAV transfer
Just to be more elaborate, all that has been configured (for security purposes) is :: ### SSLCertificateFile = /etc/ssl/certs/ssl.crt SSLCertificateKeyFile /etc/ssl/certs/ssl.key ### in "ssl.conf", and (i think) this is available only to the server. So, the data can be encrypted, but I am still clueless as to how is it decrypted at the client side. Regards, Ajay On Mon, Mar 26, 2012 at 10:24 AM, Ajay Garg wrote: > Thanks Eric for the reply. > > Eric, but how is the shared secret comfigured? > I do not remember configuring anything like this for the HTTPS-based > WebDAV server. > > Thanks and Regards, > Ajay > > > On Sun, Mar 25, 2012 at 11:39 PM, Eric Covener wrote: > >> > BUT, HOW IS THE CLIENT ABLE TO DECRYPT THE DATA? (I have been running >> both >> > webdav server and client on the same machine; so it might very well >> > be the case that some info from "ssl.conf" and/or "httpd.conf" is being >> used >> > at the client side. However, I am just guessing ... >> >> Under SSL, the client and server negotiate a shared secret used to >> encrypt/decrypt the data. >> >> They can set this up securely because the client starts this process >> with info encrypted with the servers public key. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >> >
Re: [users@httpd] How does client decrypt data in a HTTPS-based WebDAV transfer
Thanks Eric for the reply. Eric, but how is the shared secret comfigured? I do not remember configuring anything like this for the HTTPS-based WebDAV server. Thanks and Regards, Ajay On Sun, Mar 25, 2012 at 11:39 PM, Eric Covener wrote: > > BUT, HOW IS THE CLIENT ABLE TO DECRYPT THE DATA? (I have been running > both > > webdav server and client on the same machine; so it might very well > > be the case that some info from "ssl.conf" and/or "httpd.conf" is being > used > > at the client side. However, I am just guessing ... > > Under SSL, the client and server negotiate a shared secret used to > encrypt/decrypt the data. > > They can set this up securely because the client starts this process > with info encrypted with the servers public key. > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
[users@httpd] How does client decrypt data in a HTTPS-based WebDAV transfer
Hi all. I have managed to get a HTTPS-based WebDAV server up and running. However, I have a conceptual query (sorry if I sound an absolute idiot) :: ## When we configure "ssl.conf" and/or "httpd.conf", that information is available only to the HTTPS-based WebDAV server. Now, HTTPS means that the data is transferred over the wire in encrypted form. So, right, the server has the information necessary to encrypt the data. BUT, HOW IS THE CLIENT ABLE TO DECRYPT THE DATA? (I have been running both webdav server and client on the same machine; so it might very well be the case that some info from "ssl.conf" and/or "httpd.conf" is being used at the client side. However, I am just guessing ... ## Sorry, if this sounds too basic a query; but this would clear a lot of things in my head. Looking forward to a reply. Thanks and Regards, Ajay
Re: [users@httpd] RE: Suspicious URL:Re: [users@httpd] Problems in setting up a "HTTPS" based WebDAV server
Just to save anybody else's time, here are the steps I reverted/fixed, that got the HTTPS-based WebDAV server working :: a) removing "VirtualHost" definition altogether from "httpd.conf" b) removing "mod_ssl" loading in "httpd.conf" (as it is already loaded via "ssl.conf") c) adding the "webdav" directives in "ssl.conf" All credit to Sander. Thanks and Regards, Ajay On Sun, Mar 25, 2012 at 10:30 PM, Ajay Garg wrote: > Sander, > > SALUTE !!! > > After performing your suggested steps 1), 2) and 3), I am able to connect > to a HTTPS-based WebDAV server, as expected. > (In other words, yes, it was in fact, "ssl.conf" interference at its > worst). > > > Thanks, Thanks, Thanks .. (repeated infinite times :-) ) > > > Thanks and Regards, > Ajay > > > > On Sun, Mar 25, 2012 at 10:02 PM, Sander Temme wrote: > >> Ajay, >> >> Let's table the issue of certificates, and move on to getting your server >> started. You have a good key, and a good certificate. The fact that you >> can run openssl s_server with it proves that. >> >> What concerns me is that you have mod_ssl configuration language in your >> main configuration file. When you use the Red Hat supplied httpd >> configuration, it Includes everything in /etc/httpd/conf.d. >> >> Among the files in this directory is ssl.conf, which contains >> configuration language for a VirtualHost on port 443. With its own >> SSLCertificateFile, and its own SSLCertificateKeyFile. What if those >> configuration options are interfering with yours, and you end up using a >> mixture of the two? I'm actually not sure what would happen. >> >> Please try the following: >> >> 1) Comment out your VirtualHost definition at the bottom of httpd.conf >> 2) Find the SSLCertificateFile and SSLCertificateKeyFile parameters in >> conf.d/ssl.conf, and substitute your key and certificate file paths. >> 3) Stop and start your server. Does it start up now? Can you connect to >> it with a browser? >> >> S. >> >> >> On Mar 24, 2012, at 10:52 PM, Ajay Garg wrote: >> >> > Thanks a ton, Daniel. >> > >> > I think, you are the first one to hit the nail on the head :-) >> > Thanks again; I am obliged. >> > >> > Daniel, it seems that for generating certificates "class 2" >> identification is required (http://www.startssl.com/?app=34) >> > >> > Anyhow, since currently I am just in the development/testing phase, so >> what I just need is the feature working. >> > >> > Sorry if I may sound a bit too demanding, but I will be really grateful >> if you could let me now the appropriate commands to generate appropriate >> "SSLCertificateKeyFile" and "SSLCertificateFile", which will get the >> "connection to HTTPS WebDAV" server working (just about working locally). >> For production-based deployment, certificates can be generated on an >> official basis by my organisation. >> > >> > >> > Thanks and Regards, >> > Ajay >> > >> > On Sat, Mar 24, 2012 at 6:50 PM, Daniel Ruggeri >> wrote: >> > On 3/23/2012 11:47 PM, Ajay Garg wrote: >> > > I used the following command to generate the ".key" and ".crt" :: >> > > >> > > >> >> > > openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout >> > > ssl.key -out ssl.crt >> > > >> >> > > >> > > >> > > I will be grateful, if you could let me know the required command(s) >> > > to generate the "RSA Server Certificate", and the ".key" :-) >> > >> > You already have both (ssl.key is your private key and ssl.crt is your >> > certificate file). The key becomes SSLCertificateKeyFile and the cert >> > becomes SSLCertificateFile in your httpd.conf. Since you generated both >> > at the same time, they are sure to match. >> > >> > It's important to note that you now have what is called a self-signed >> > cert (its identity is only vouched for by itself) and practically every >> > client on the Internet will warn or refuse to connect to your server. >> > It's u
Re: [users@httpd] RE: Suspicious URL:Re: [users@httpd] Problems in setting up a "HTTPS" based WebDAV server
Sander, SALUTE !!! After performing your suggested steps 1), 2) and 3), I am able to connect to a HTTPS-based WebDAV server, as expected. (In other words, yes, it was in fact, "ssl.conf" interference at its worst). Thanks, Thanks, Thanks .. (repeated infinite times :-) ) Thanks and Regards, Ajay On Sun, Mar 25, 2012 at 10:02 PM, Sander Temme wrote: > Ajay, > > Let's table the issue of certificates, and move on to getting your server > started. You have a good key, and a good certificate. The fact that you > can run openssl s_server with it proves that. > > What concerns me is that you have mod_ssl configuration language in your > main configuration file. When you use the Red Hat supplied httpd > configuration, it Includes everything in /etc/httpd/conf.d. > > Among the files in this directory is ssl.conf, which contains > configuration language for a VirtualHost on port 443. With its own > SSLCertificateFile, and its own SSLCertificateKeyFile. What if those > configuration options are interfering with yours, and you end up using a > mixture of the two? I'm actually not sure what would happen. > > Please try the following: > > 1) Comment out your VirtualHost definition at the bottom of httpd.conf > 2) Find the SSLCertificateFile and SSLCertificateKeyFile parameters in > conf.d/ssl.conf, and substitute your key and certificate file paths. > 3) Stop and start your server. Does it start up now? Can you connect to > it with a browser? > > S. > > > On Mar 24, 2012, at 10:52 PM, Ajay Garg wrote: > > > Thanks a ton, Daniel. > > > > I think, you are the first one to hit the nail on the head :-) > > Thanks again; I am obliged. > > > > Daniel, it seems that for generating certificates "class 2" > identification is required (http://www.startssl.com/?app=34) > > > > Anyhow, since currently I am just in the development/testing phase, so > what I just need is the feature working. > > > > Sorry if I may sound a bit too demanding, but I will be really grateful > if you could let me now the appropriate commands to generate appropriate > "SSLCertificateKeyFile" and "SSLCertificateFile", which will get the > "connection to HTTPS WebDAV" server working (just about working locally). > For production-based deployment, certificates can be generated on an > official basis by my organisation. > > > > > > Thanks and Regards, > > Ajay > > > > On Sat, Mar 24, 2012 at 6:50 PM, Daniel Ruggeri > wrote: > > On 3/23/2012 11:47 PM, Ajay Garg wrote: > > > I used the following command to generate the ".key" and ".crt" :: > > > > > > > > > > openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout > > > ssl.key -out ssl.crt > > > > > > > > > > > > > I will be grateful, if you could let me know the required command(s) > > > to generate the "RSA Server Certificate", and the ".key" :-) > > > > You already have both (ssl.key is your private key and ssl.crt is your > > certificate file). The key becomes SSLCertificateKeyFile and the cert > > becomes SSLCertificateFile in your httpd.conf. Since you generated both > > at the same time, they are sure to match. > > > > It's important to note that you now have what is called a self-signed > > cert (its identity is only vouched for by itself) and practically every > > client on the Internet will warn or refuse to connect to your server. > > It's up to you to decide if that is a problem or not - if this is > > something you will only use privately, it's probably OK. > > > > To get past this, you need to generate a certificate signing request and > > send it to a reputable CA for signing. I believe > > http://www.startssl.com/ offers this service for free, but there a few > > other free ones out there. > > > > openssl req -out ssl.csr -key ssl.key -new > > > > (This generates ssl.csr which you can safely email to be signed) > > > > -- > > Daniel Ruggeri > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > > For additional commands, e-mail: users-h...@httpd.apache.org > > > > > > > -- > scte...@apache.orghttp://www.temme.net/sander/ > PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A > > View my availability: http://tungle.me/sctemme > > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
Re: [users@httpd] RE: Suspicious URL:Re: [users@httpd] Problems in setting up a "HTTPS" based WebDAV server
Thanks a ton, Daniel. I think, you are the first one to hit the nail on the head :-) Thanks again; I am obliged. Daniel, it seems that for generating certificates "class 2" identification is required (http://www.startssl.com/?app=34) Anyhow, since currently I am just in the development/testing phase, so what I just need is the feature working. Sorry if I may sound a bit too demanding, but I will be really grateful if you could let me now the appropriate commands to generate appropriate "SSLCertificateKeyFile" and "SSLCertificateFile", which will get the "connection to HTTPS WebDAV" server working (just about working locally). For production-based deployment, certificates can be generated on an official basis by my organisation. Thanks and Regards, Ajay On Sat, Mar 24, 2012 at 6:50 PM, Daniel Ruggeri wrote: > On 3/23/2012 11:47 PM, Ajay Garg wrote: > > I used the following command to generate the ".key" and ".crt" :: > > > > > > > openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout > > ssl.key -out ssl.crt > > > > > > > > > I will be grateful, if you could let me know the required command(s) > > to generate the "RSA Server Certificate", and the ".key" :-) > > You already have both (ssl.key is your private key and ssl.crt is your > certificate file). The key becomes SSLCertificateKeyFile and the cert > becomes SSLCertificateFile in your httpd.conf. Since you generated both > at the same time, they are sure to match. > > It's important to note that you now have what is called a self-signed > cert (its identity is only vouched for by itself) and practically every > client on the Internet will warn or refuse to connect to your server. > It's up to you to decide if that is a problem or not - if this is > something you will only use privately, it's probably OK. > > To get past this, you need to generate a certificate signing request and > send it to a reputable CA for signing. I believe > http://www.startssl.com/ offers this service for free, but there a few > other free ones out there. > > openssl req -out ssl.csr -key ssl.key -new > > (This generates ssl.csr which you can safely email to be signed) > > -- > Daniel Ruggeri > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
