You are not logged in.
Just finished my wiki writeup about my setup and how i got it rolling.
Lighttpd for both ssl and non-ssl
Enjoy. 8)
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Great wiki. It was very easy to follow and now I have a great setup.
One thing I'm wondering about though is using perl with fastcgi (right now I just run perl through regular cgi). I read the lighttpd docs and it says I need to install the perlfcgi module from cpan. I went to that site and found the module, but not quite sure what to do next or how to integrate it with lighttpd. Any advice or good documentation links?
Thanks,
Alex
Offline
unfortunately I don't. Definately let me know if you make progress on this, as I would like information on setting up other fastcgi mechanisms. I want to setup ruby as fastcgi too.
If I come across some additional info, I will probably make an offshoot wiki page on setting up additional fastcgi scenarios.
Thanks for the positive feed back too. 8)
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Haven't had a chance to play with fcgi stuff yet, but I did make another discovery you might find interesting.
I was browsing the lighttpd docs and I found a way to run both ssl and non-ssl stuff using only one daemon. I noticed when I followed your wiki that you mention "Lighttpd can only service either ssl or non-ssl at one time."
The way to have both in one is documented here: http://www.lighttpd.net/documentation/ssl.html
Basically you add this code to your lighttpd.conf:
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
ssl.pemfile = "server.pem"
server.name = "www.example.org"
server.document-root = "/home/lighttpd/html/"
}
I edited the above code to coincide with your wiki. It basically listens on all interfaces for a connection to port 443 and serves up content found in server.document-root via ssl. However, you can't use it with name based virtual hosting as the docs mention.
As SSL and named-based virtual hosting can not work together you have to use IP-based virtual hosting if you want to run multiple SSL-servers with one lighttpd.
And (to make things a bit more confusing) I believe you can still use simple name based virtual hosting for regular connections. All this in one daemon! Yes I am falling in love with this thing too
If this is the limitation you were talking about in the wiki, the code above should simplify the install even more. Anyway, keep up the good work... I'm hoping to gain some insight into fast cgi and perl soon. World domination is close, i can taste it :twisted:
Offline
hmmm. interesting. I am not sure if I like having two daemons seperately handling the ssl and non-ssl connections or not.
It will take some chin scratching to see which way I prefer..
thanks for the good info though..feel free to make addendums to the wiki doc. it is a wiki after all. *wink*
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
it does indeed seem to work quite well.
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
ssl.pemfile = "/home/lighttpd/ssl/server.pem"
accesslog.filename = "/var/log/lighttpd/access-ssl.log"
server.document-root = "/home/lighttpd/ssl/html"
}
You can even use seperate logfiles for the ssl server and the non-ssl server, I will keep the error logs unified, but I wanted to break out the access logs. Which is one thing I was afraid would be lost in the singe daemon setup. Very cool....
I will update my howto (add an alternate methodology), as well as my package, to reflect this simpler setup. If people want to break off a seperate daemon, then they still can.
EDIT: Hmmm. I wonder if seperate mod_auth sections can be used in the SERVER blocks...
*starts to test things out*
Seperate processes is probably more secure. You can load different modules for each process, instead of being tied to having the same modules for both. Something to think about. Still, for the simple, and for most setups, it is the way to go..
lol..nothing like talking myself in circles.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I don't think there is a "best" way to do this. There are some advantages (like module seperation) to the 2 process setup. The big disadvantage with two daemons for me was having 2 config files to keep track of (but that may be a good thing for others).
For my setup I have a couple of vhosts running normally, but when they go ssl it takes them to a common direcotry that has tools like phpMyAdmin so that they have a secure connection for that. It works out very well, I just had to use this config:
$SERVER["socket"] == "0.0.0.0:80" {
simple-vhost.server-root = "/home/lighttpd/domains/"
simple-vhost.default-host = "default.website.com"
simple-vhost.document-root = "/public_html/"
}
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
ssl.pemfile = "/home/lighttpd/server.pem"
server.name = "default.website.com"
server.document-root = "/home/lighttpd/ssl_html"
}
The best part is that lighttpd is flexible enough to work either way. Btw, you mentioned that your package of lighttpd contains stuff specific to the two daemon setup... I haven't noticed anything, what were you refering to?
Offline
Just a few minor adjustments to the config file. I added a commented out section showing the simple ssl setup you mentioned above.
I also applied a patch I made to fix a problem I was having with ssl. It was rewriting a request for a url without a trailing slash, to http.
ie. https://some/url
was being rewritten to http://some/url/
It seems to be working now after the patch..I updated my package in my repo with the fix. Hopefully it makes it upstream for the next lighty version.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I've also tried this lighttpd pack. Seems nice but I am confused about some things.
I would like to make the server to run two sites at ports 80 and 8080. Site at port 8080 is a developement site and I would like to make it visible to localhost only and sometimes to some specific outside addresses - for showing it or testing it. Site at port 80 should also be visible to two addresses only: localhost and another one.
In Apache I was used to make different access rights to directories like this:
<VirtualHost *:8080>
DocumentRoot /home/site1/php
ServerName test
</VirtualHost>
<Directory /home/site1/php>
order deny,allow
deny from all
allow from 127.0.0.1
#allow from another address
</Directory>
How would I get the same effect in lighttpd? I tried using this code:
$SERVER["socket"] == "127.0.0.1:8080" {
server.document-root = "/home/site1/php/"
$HTTP["host"] !~ "^($|(127.0.0.1|athena))" {
url.access-deny = ( "" )
}
}
athena is the localhost name
but this seems to block stuff (like images) from the other socket, too (running on port 80). How could I make that $HTTP["host"] to only match with the stuff at port 8080?
Offline
in 1.3.13, I don't believe you can nest matches like that. Version 1.4 is supposed to allow nesting like that. I sent a request to the mailing list for AND matching, and was told that the forthcoming nesting would solve it (and it will indeed).
In the meantime, it might be easier for you to think about your setup. Maybe it would be easier to run two daemons..one serving the development stuff, and the other serving the "production" stuff. That might be easier to setup too.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Thanks! Running two daemons was the solution for me.
Offline
there is a lighttpd package in extra these days. And spawn-php is in /etc/rc.d/
there is a configuration portion of that file in /etc/conf.d too.
My how to is a bit dated.
Be warned though, the recent arch package uses user nobody for lighttpd, something I disagree with personally, but which you might have no problems with.
I will probably start making my own package again as a result, as the devs dont seem to agree with my opinion on the matter.
*shrug*
oh well, thank god for ABS.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I will probably start making my own package again as a result, as the devs dont seem to agree with my opinion on the matter.
*shrug*
cactus, I see your point. Just lets discuss things here, as this place is a bit better populated than the bugtracker. My idea behind nobody is that it suffices the needs of most users, power users have their own setup anyway, with maybe even more than just one additional user. So your problem are the files I set to nobody:nobody in the PKGBUILD script.
What about the following:
/etc/lighttpd.conf
/etc/conf.d/spawn-php
/etc/conf.d/lighttpd
are backuped anyway, I think some user have them on NOUpgrade in pacman.conf. I could introduce some post_install-magic to set permissions on the /home/lighttpd/* files provided in the package to the user:group set in /etc/lighttpd.conf
But this would bug every user who doesn't have lighttpd.conf on NoUpgrade because post_install will have to look in /etc/lighttpd.conf which will be replaced by the new one while the old one become a.pacsave file.
I hesitate to introduce too many groups/users since it becomes hard to custoumize for power users if the package take you by the hand too much.
-neri
Offline
let me try out the newest changes to the package. I will see how things shake out before I provide further opinion on the matter.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline