sshfs
I just found out about sshfs yesterday. Saved me some headache.
Don’t even know why I haven’t done this earlier. If you have some sort of testing environment on a remote server it’s so nice to be able to poke around using gedit rather then vi:m or nano. Well, usually I would just write a small bash-snippet which basically would call scp and update my files. Now I can just click Ctrl+s from my favorite text-editor and they’ll get updated.
I even wrote a stupid python script which does the mounting, unmounting. It depends on Fabric. Just because I was poking around with Fabric at the time of figuring out the sshfs thing.
from fabric.api import local
mntpoint='remote/'
def mount():
local('mkdir -p '+mntpoint)
local('sshfs -p <port> -C -o transform_symlinks -o Cipher="arcfour" <user>@<host>: '+mntpoint)
def unmount():
local('fusermount -u '+mntpoint)
local('rm -R '+mntpoint)
The Cipher part is to speed up SSH, which other wise can feel kind of laggy. Make sure you have fuse enabled(# modprobe fuse) and run $ fab mount/unmount to mount or unmount.
nginx+LAMP
I’ve been stuck in ssh, apache conf files and /etc/init.d/apache2 reloads for the last couple of days. It’s a daunting task to get it right, and of course cheerfully rewarding when it finally works.
My plan was to create a testing environment for a web-site I’ll be working. The current site is located on a shared host so I wasn’t able to fully isolate and install a setup I would be comfortable with, since the production site and a few others where all on the same host aswell.
After an morning of banging my head against an old python interpreter on the shared host I signed up for a small VPS slice over at Linode.com’s London-server. It’s a small fee to pay to be freed of the restrictive nature of an shared host, totally worth it.
The dark side of the moon is obviously that you are stuck on your own. Thankfully Linode had a dozen guides to getting you started on the server config part. My plan was to have a Django-enabled server, including git and other helpful tools part of my development cycle. I wanted something flexible where I can test different ideas and setup’s which may be more suitable for my employer, then their current LAMP stack. Their current webpage is serving a 20GB lot of media-files through an apache server. And I’ve noticed the latency on their webpage when looking at static content. It looks to me as if they could win a lot by using a lighter setup as a front-end dispatcher(ehh, proxy), so I was keen on getting nginx up running as well.
I’m happy to say that I finally got a basic setup running. It’s mostly out-of-the-box configured, but I’ve tweaked it slightly for my Linode’s resources and played around with different strategies. Here’s a short list of the setup.
- I’m running Ubuntu 8.04.4 LTS. Playing it safe. Tested arch linux first, but found it to be not suitable.
- On top of this I have two server’s running. Here’s a short trace-route:
- Request to hostname gets translated to IP-address and redirected to IP.
- nginx server is listening on port 80 on IP, dispatching the requests to different places and services on the server based on domain name and sub-domain name. A request to test.http://<domain name> will be served by the nginx server, while a request to http://django.<domain name> will be sent to a different port which apache is listening on.
- Apache server is setup to be listening on port 8080, 8070, 8060 etc. one for each vhost served by the server. I have configured one to be using the mod_wsgi, enabling effective use of django, and one just as a plain old dynamic content apache-thing.
As an example I can post the nginx conf for the django-configured domain.
# Listen for <host name>
server {
listen <ip-address>:80;
server_name <host name>;
access_log /home/<directory>/logs/nginx_access.log;
error_log /home/<directory>/logs/nginx_error.log;
location / {
proxy_pass http://<ip-address>:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
location /media/ {
root /home/<directory>/media;
}
}
Additionally this gives me the opportunity to say serve some requests directly with nginx and dynamic content with apache on the same domain. I could eventually do something like this; filter all static file request and serve them directly and send the dynamic content request by proxy to apache.
location ^~ /(images|css|js) {
root /home/www/www.domainname.org/media/;
access_log /var/log/nginx/d-a.direct.log ;
}
#
# Proxy all remaining content to Apache
#
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
....
Getting my head around sys-admin things really is a learning full experience. Worth trying out.
the browser thing
I’ve been a Firefox user since they changed their name to Firefox from Mozilla.
Never liked Opera. It always felt kind of bloated. In recent times, though, I have switched over to Chromium. It is quicker and slowly gaining a nice resource base of plugins. As far as web development goes, chromium doesn’t cut it. FireFTP + Web Developer Tools + Firbug is such a strong and useful combination. You can do all the web development from within the browser. I use gedit or geany together with FireFTP to edit desired files, live on the server. Beats using vi:m over ssh, and is faster then locale editing + ftp upload(well, it’s what I’m doing, but I don’t need to worry about it).
consolekit login
Harald Ringvold asked me about this last Thursday, “How do you get access to administrative rights in the GUI admin-apps, as a normal user, in GNOME”. Well, I didn’t have an answer, but had a feeling it had something to do with PolicyKit, which was wrong. Later that day Harald e-mailed me the solution; “login with ConsoleKit”.
I don’t use login managers so I set ck-launch-session in my .xinitrc file.
$ exec ck-launch-session gnome-session