Nuts for Jericho

Posted by daniel on Wednesday, May 23 2007 @ 05:53 AM CEST
Views: 3,391

If there is something that I've always liked is the pressure that some united guys on the Internet can do.

For those of you who don't know, CBS decided not to continue the drama series Jericho with a new season, leaving the viewers with an unfinished ending.

Jericho is a post-nuclear attack drama series, based on a small town in Kansas called Jericho, in how such a small town can survive the radiation, the lack of electricity, communications, et cetera. It was really a refreshingly different series.

One of the reasons why Jericho has had such low ratings is because CBS sliced the series in half, with a pause of about 3 months.

What is amazing is the popular response to the cancellation of the series: it has been featured in several front page digg articles, starting from online petitions (over 68000 signatures now), and ending up in a massive sending of nuts to the CBS, as a symbol of the last words of the main character.

After the amount of mails, and nuts, i guess, received at CBS, the CBS President, Nina Tassler, issued a statement saying they were working in a solution to provide a closure for the series.

Anyway, if you like the series, sign the petition, or send some nuts. If you haven't seen it, you can get it from the iTunes Store. There's even a site called Jericho Lives where they keep track of all the petitions.

Post a comment

Comments (5) Trackbacks (1)

Configuring an NFS Server

Posted by daniel on Tuesday, May 15 2007 @ 05:41 PM CEST
Views: 4,773

NFS (Network File System) is a protocol that allows to export a filesystem to other remote machines, where it can be mounted like a local disk. While Samba is probably better for domestic use (more available clients, printer sharing), NFS is better for sharing partitions across servers. Actually, you will find NFS easier to configure than Samba, and if you don't need to share printers, and your computers are Unix based (Mac or Linux, basically), I think it's better than Samba even for domestic use.

First of all, we need to install portmap if it's not installed already (if you have a window manager, such as GNOME, it will be already installed).
europa:~# apt-get install portmap

The next step is checking whether it accepts connections other than from 127.0.0.1. To do so, we have to check /etc/default/portmap, commenting the following line if it exists:
#OPTIONS="-i 127.0.0.1"

Later on, we will firewall portmap. Now, we can restart the service as usual.

europa:~# /etc/init.d/portmap restart
Stopping portmap daemon....
Starting portmap daemon....

The following command will install both NFS server and client in deb-based systems:
europa:~# apt-get install nfs-kernel-server nfs-common

Once installed, we need to provide the NFS server with the shares we want. The file we need to edit is /etc/exports. Here's an example:

/home/user 192.168.1.3(rw,sync,no_subtree_check)
/directory_to_export 192.168.1.2(ro,sync,no_subtree_check) 192.168.1.5(rw,sync,no_subtree_check)

The first line will export the directory /home/user, allowing access to 192.168.1.3, with read and write permissions.
The second line will export the directory /directory_to_export, allowing read only access to 192.168.1.2 and read and write access to 192.168.1.5.

Once we have configured our exports, we need to run exportfs to update the configuration:
europa:~# exportfs -a

Mounting a share from a client (supposing our server is 192.168.1.1, and that we are connecting to /home/user) is as easy as:
scherie:~# mount -t nfs 192.168.1.1:/home/user /mnt/home

Or we can add it to /etc/fstab as a regular partition:
192.168.1.1:/home/user /mnt/home nfs defaults 0 0

The last we should do is reject access to portmap and the NFS server (even if nobody will be able to export a directory since they are not on the exports file).

This will allow localhost and 192.168.1.2 to connect to portmap, and reject everyone else. You can obviously use a range in the source to allow an entire LAN.

europa:~# iptables -t filter -A INPUT -s 127.0.0.1 -p tcp -m tcp --dport 111 -j ACCEPT
europa:~# iptables -t filter -A INPUT -s 127.0.0.1 -p udp -m udp --dport 111 -j ACCEPT
europa:~# iptables -t filter -A INPUT -s 192.168.1.2 -p tcp m tcp --dport 111 -j ACCEPT
europa:~# iptables -t filter -A INPUT -s 192.168.1.2 -p udp -m udp --dport 111 -j ACCEPT
europa:~# iptables -t filter -A INPUT -p tcp -m tcp --dport 111 -j REJECT --reject-with icmp-port-unreachable
europa:~# iptables -t filter -A INPUT -p udp -m udp --dport 111 -j REJECT --reject-with icmp-port-unreachable

This will do the same thing with the NFS server.

europa:~# iptables -t filter -A INPUT -s 127.0.0.1 -p tcp -m tcp --dport 2049 -j ACCEPT
europa:~# iptables -t filter -A INPUT -s 127.0.0.1 -p udp -m udp --dport 2049 j ACCEPT
europa:~# iptables -t filter -A INPUT -s 192.168.1.2 -p tcp m tcp --dport 2049 -j ACCEPT
europa:~# iptables -t filter -A INPUT -s 192.168.1.2 -p udp -m udp --dport 2049 -j ACCEPT
europa:~# iptables -t filter -A INPUT -p tcp -m tcp --dport 2049 -j REJECT --reject-with icmp-port-unreachable
europa:~# iptables -t filter -A INPUT -p udp -m udp --dport 2049 -j REJECT --reject-with icmp-port-unreachable

Post a comment

Comments (0) Trackbacks (0)

Paris: Monet and L'Atelier de Joël Robuchon

Posted by daniel on Thursday, May 03 2007 @ 03:34 PM CEST
Views: 4,307

So I was in Paris a couple of weeks ago. Apart from some nice walking (see the Jardin des Tuileries below) and some museum visiting, I went to one of the nicest restaurants in Paris, which is L'Atelier de Joël Robuchon.

L'Atelier de Joël Robuchon, is apparently the 13th best restaurant in the world, better for instance than Alain Ducasse's in the Plaza Athenee, which is certainly more expensive.

One of the most surprising things when you enter is the disposition of the tables. Everyone is seated around the central block (where the kitchen is), in a bar-style way. The price you may expect to pay is around 100 euro, let the waiter recommend you (or get the Sole if they have it), and get a nice glass of wine.

By the way, I completely recommend (if you like Monet) - and I'm pretty sure you've already been to the Musée d'Orsay - to go to the Musée Marmottan Monet. It's quite a small museum in the 16th arrondisement (2, Rue Louis-Boilly), and a bit far from the usual museum places, but it's worth it (La Muette metro station is the nearest one, or 10 euro for a taxi from the Champs Elysées). They have one of the most important collections of Monet, including a series of Nymphéas.

Post a comment

Comments (7) Trackbacks (0)

del.icio.us: Paris: Monet and L'Atelier de Joël Robuchon

digg: Paris: Monet and L'Atelier de Joël Robuchon

Testing Coda, the all new editor for Mac

Posted by daniel on Tuesday, April 24 2007 @ 05:37 PM CEST
Views: 3,594

Everybody is talking about the new editor-ftp-sftp-client for Mac, named Coda, and developed by Panic, the guys behind Transmit.

I have downloaded a trial version and I've been testing it for a while.

As they say in their web page: [before Coda] "We’d have our text editor open, with Transmit open to save files to the server. We’d be previewing in Safari, running queries in Terminal, using a CSS editor, and reading references on the web."

Coda combines a text editor (TextMate style), with a visual CSS editor, a preview function, a FTP/SFTP client that automatically uploads files when saved, and a terminal tab (local or remote), with a beautiful UI.

In my opinion the idea is really good, but there are some things that as a Rails developer, do not work as good as expected, and I am comparing it to TextMate, which is the editor I use right now.

For instance, the preview function won't work, because, obviously .rhtml files are not recognized, and so, the source code appears when using the preview function.

When developing in Rails, Coda should detect it, and automatically point the WebKit based navigator to http://localhost:3000/controllerN/actionM when editing actionM.rhtml. That would be perfect.

The automatic FTP/SFTP client is quite useless for Rails (provided you don't need to test your application in a remote server), as usually, you will do the previews in a local mongrel server.

The CSS Editor is actually quite cool, and it seems to work well, as is the Terminal tab, which is useful as well.

The Books tab is a good idea too, particularly if they add more "books" in the future (currently HTML, CSS and PHP), but I'm not sure I would use it a lot. Still seems faster to google the function you're searching for.

There is an auto completion feature in the editor (for Rails too), and completes for example, remote_form_tag as you type, but that's it. It doesn't show you the attributes, like :update, :url, etc. It doesn't complete models, classes, or any other functions such as find or new either.

Reading back the post, it seems too critical, but it's not what I meant it to be. It's just some suggestions to make a really good editor a perfect editor.

At a $79 price tag, I'd say buy it if you don't develop in Rails. Stick with TextMate (€39) instead, but check out the evolution of Coda.

Post a comment

Comments (2) Trackbacks (0)

del.icio.us: Testing Coda, the all new editor for Mac

digg: Testing Coda, the all new editor for Mac

Pearls before breakfast

Posted by daniel on Tuesday, April 10 2007 @ 03:50 PM CEST
Views: 2,628

Joshua Bell, one of the world's greatest violinists, decides to get his million-dollar Stradivarius and play in a metro station in Washington D.C. for about 45 minutes, like many other musicians who play in the streets, to see whether someone will recognise him and how many people will actually stop to listen. The entire performance was recorded by a camera, and the video is posted in the article.

He decides not to play popular pieces that might draw interest by its familiarity. However, some of the masterpieces he performs are written by Bach, Schubert and Jules Massenet.

About 1,000 people pass by, and only three people actually stop to listen, with one person recognising him. Honestly, I think what is particularly sad is the fact that the great mass of the people are not interested in classical music anymore, preferring all kinds of so-called popular music. Before you say, that can only happen in America, I am pretty sure that in Europe such an experiment will have the same results. Put a rock star or a nobody-who-is-on-tv on a metro station and you will have to send the police to be able to get the famous guy out of there.

One of the best articles I have read for some time.

The Washington Post: Pearls before breakfast (via Digg)

Post a comment

Comments (0) Trackbacks (0)

Windows Vista, or allowing Vista to test my computer

Posted by daniel on Friday, March 23 2007 @ 12:00 AM CET
Views: 3,915

As many of you may be aware, I am a Mac user. Luckily, I don't need to use Windows in a daily basis, but I am not a Mac zealot, and while I almost never use Windows, I don't feel the urge to criticize Microsoft products just for the sake of mocking them.

So, I have been testing Windows Vista lately, using Parallels under Mac. I'll start by saying that the performance of Vista under Parallels (with 512Megs of RAM associated to it) is quite astonishing, and it even works better than XP. I have to say, though, that the main task I run on Windows is Internet Explorer, to see how a new web design looks and (almost everytime) patch it for IE, so the load is quite low.

As a mere curiosity, Windows thinks I have a Core Duo at 2GHz running at 7GHz, which is probably due to the fact it's running under Parallels, but curious anyway. Way to go, Intel!

One of the things that most people are complaining about Vista is the famous Cancel or Allow dialog, as in the You're having a sad realization, cancel or allow? ad by Apple. I must say that is completely true. I got 4 (yes, FOUR) Cancel or Allow dialogs when I installed the Parallels Tools, but the most hilarious one was in Internet Explorer, when I right-clicked and chose View Source Code. I mean, for Notepad? What harm may poor Notepad cause?

That's why I ask myself if you are using Vista or you are letting Vista use your computer. You never know.
As for the overall design, I must say it's not that bad. For instance, the Explorer has been redesigned, resembling MacOS X Finder. All windows have this Mac-alike brushed style.

The Start menu features a new design too, particularly the list of programs. Surprisingly, the Power button at the bottom-right side of the start menu does not power off the computer. That is the suspend button. To power off your computer you must click on the arrow at the right of the lock button, and choose Shut down from a menu. That is tricky.

When you click on All Programs, the Windows default programs and the standard start menu show up in a different way. The folders in the start menu can be expanded and collapsed.

And this is how it looks under Mac, using the Coherence mode in Parallels. Using Coherence, you can have both Mac and Windows applications in Finder, without having to cycle between Mac and Windows desktops. On the screenshot you can see the Dock and the Windows bar, interacting with both. There is an iTunes and an iTerm instance opened, and an Internet Explorer window. Click on the image for a full resolution screenshot.

Post a comment

Comments (0) Trackbacks (0)

del.icio.us: Windows Vista, or allowing Vista to test my computer

digg: Windows Vista, or allowing Vista to test my computer

Benchmarking Rails enabled Web Servers

Posted by daniel on Saturday, March 10 2007 @ 01:01 AM CET
Views: 4,103

Following the article Running Rails applications: Choosing a server where I compared the different combinations server/dispatcher available for Rails, I have done a small benchmark to see what server actually performs better.

The servers I have tested are: Apache2 + Dynamic mod_fastcgi, Apache2 + mod_fcgid, Apache + Static mod_fastcgi and Lighttpd 1.4 + mod_fastcgi. The benchmark was performed using ab (Apache Benchmark), in a machine in the same LAN as the server (an old Pentium-4 with 512Mb of RAM), running first 100 requests with a concurrency level of 10 (ab -c 10 -n 100), and then, 500 requests with a concurrency level of 50 (ab -c 50 -n 100).

Configuration used:

Apache2 + Dynamic mod_fastcgi:

<IfModule mod_fastcgi.c>
  AddHandler fastcgi-script .fcgi
  FastCgiConfig -minProcesses 2 -maxProcesses 4
</IfModule>

Apache2 + mod_fcgid:

<IfModule mod_fcgid.c>
  AddHandler fcgid-script .fcgi
  SocketPath /var/lib/apache2/fcgid/sock
  IPCConnectTimeout 20
</IfModule>

Apache2 + Static mod_fastcgi

<IfModule mod_fastcgi.c>
  AddHandler fastcgi-script .fcgi
  FastCgiServer /path/to/dispatch.fcgi -processes 4
</IfModule>

Lighttpd + mod_fastcgi

server.modules   += ( "mod_rewrite", "mod_redirect", "mod_fastcgi" )

fastcgi.server    = (
        #Start a FastCGI server for Rails
        ".fcgi" => 
        ( "rails" => 
                (
                "bin-path" => "/path/to/dispatch.fcgi",
                "min-procs" => 2,
                "max-procs" => 4,
                "socket" => "/tmp/rails.fastcgi"
                )
        )
)

Apache 2.2 + Dynamic mod_fastcgi (min-processes 2)

100 requests; Concurrency level: 10

Document Length:        4558 bytes

Concurrency Level:      10
Time taken for tests:   13.951477 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      488300 bytes
HTML transferred:       455800 bytes
Requests per second:    7.17 [#/sec] (mean)
Time per request:       1395.148 [ms] (mean)
Time per request:       139.515 [ms] (mean, across all concurrent requests)
Transfer rate:          34.12 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   2.1      0      10
Processing:  1139 1342 425.6   1182    3056
Waiting:     1139 1342 425.1   1181    3053
Total:       1139 1343 427.4   1182    3056

Percentage of the requests served within a certain time (ms)
  50%   1182
  66%   1262
  75%   1281
  80%   1286
  90%   2006
  95%   2683
  98%   2962
  99%   3056
 100%   3056 (longest request)

500 requests; Concurrency level: 50

Document Length:        4558 bytes

Concurrency Level:      50
Time taken for tests:   73.904226 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      2441500 bytes
HTML transferred:       2279000 bytes
Requests per second:    6.77 [#/sec] (mean)
Time per request:       7390.423 [ms] (mean)
Time per request:       147.808 [ms] (mean, across all concurrent requests)
Transfer rate:          32.26 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       2
Processing:   121 7142 4947.1   5644   25456
Waiting:      121 7142 4947.1   5644   25455
Total:        123 7142 4947.3   5644   25457

Percentage of the requests served within a certain time (ms)
  50%   5644
  66%   6027
  75%   6468
  80%   6615
  90%  19164
  95%  21813
  98%  22193
  99%  22493
 100%  25457 (longest request)

Apache 2.2 + mod_fcgid

100 requests; Concurrency level: 10

Document Length:        4558 bytes

Concurrency Level:      10
Time taken for tests:   11.987351 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      488800 bytes
HTML transferred:       455800 bytes
Requests per second:    8.34 [#/sec] (mean)
Time per request:       1198.735 [ms] (mean)
Time per request:       119.874 [ms] (mean, across all concurrent requests)
Transfer rate:          39.79 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   36 119.8      0     493
Processing:   179 1124 603.8   1048    3094
Waiting:        0 1115 610.1   1048    3094
Total:        198 1161 622.0   1048    3094

Percentage of the requests served within a certain time (ms)
  50%   1048
  66%   1280
  75%   1652
  80%   1731
  90%   2082
  95%   2506
  98%   2663
  99%   3094
 100%   3094 (longest request)

500 requests; Concurrency level: 50

Document Length:        4558 bytes

Concurrency Level:      50
Time taken for tests:   77.213299 seconds
Complete requests:      500
Failed requests:        18
   (Connect: 0, Length: 18, Exceptions: 0)
Write errors:           0
Non-2xx responses:      18
Total transferred:      2361938 bytes
HTML transferred:       2198180 bytes
Requests per second:    6.48 [#/sec] (mean)
Time per request:       7721.330 [ms] (mean)
Time per request:       154.427 [ms] (mean, across all concurrent requests)
Transfer rate:          29.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   98 317.2      0    1203
Processing:   140 6214 15936.0    950   76018
Waiting:      133 6210 15935.9    946   76017
Total:        140 6313 16175.8    973   77211

Percentage of the requests served within a certain time (ms)
  50%    973
  66%   1377
  75%   1827
  80%   1985
  90%  20811
  95%  61097
  98%  63166
  99%  70184
 100%  77211 (longest request)

Apache 2.2 + Static mod_fastcgi (processes 4)

100 requests; Concurrency level: 10

Document Length:        4558 bytes

Concurrency Level:      10
Time taken for tests:   10.954809 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Non-2xx responses:      100
Total transferred:      488300 bytes
HTML transferred:       455800 bytes
Requests per second:    9.13 [#/sec] (mean)
Time per request:       1095.481 [ms] (mean)
Time per request:       109.548 [ms] (mean, across all concurrent requests)
Transfer rate:          39.02 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  250 293.3     86     996
Processing:    85  809 845.6    679    6093
Waiting:        0  734 857.3    615    6092
Total:        422 1059 837.3    919    6093

Percentage of the requests served within a certain time (ms)
  50%    919
  66%   1039
  75%   1039
  80%   1081
  90%   1172
  95%   2755
  98%   5405
  99%   6093
 100%   6093 (longest request)

500 requests; Concurrency level: 50

Document Length:        4558 bytes

Concurrency Level:      50
Time taken for tests:   60.694702 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      2441500 bytes
HTML transferred:       2279000 bytes
Requests per second:    8.24 [#/sec] (mean)
Time per request:       6069.470 [ms] (mean)
Time per request:       121.389 [ms] (mean, across all concurrent requests)
Transfer rate:          39.28 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       2
Processing:   240 5789 1069.7   5993    7837
Waiting:      240 5789 1069.8   5993    7837
Total:        242 5789 1069.3   5993    7837

Percentage of the requests served within a certain time (ms)
  50%   5993
  66%   6129
  75%   6231
  80%   6277
  90%   6400
  95%   6508
  98%   6678
  99%   6972
 100%   7837 (longest request)

Lighttpd 1.4 + mod_fastcgi (min-procs 2; max-procs 4)

100 requests; Concurrency level: 10

Server Software:        lighttpd/1.4.13
Document Length:        4558 bytes

Concurrency Level:      10
Time taken for tests:   11.976793 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      481100 bytes
HTML transferred:       455800 bytes
Requests per second:    8.35 [#/sec] (mean)
Time per request:       1197.679 [ms] (mean)
Time per request:       119.768 [ms] (mean, across all concurrent requests)
Transfer rate:          39.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   183 1160 657.1   1020    2889
Waiting:      174 1040 670.8    874    2735
Total:        183 1160 657.1   1020    2889

Percentage of the requests served within a certain time (ms)
  50%   1020
  66%   1234
  75%   1658
  80%   1830
  90%   2108
  95%   2561
  98%   2833
  99%   2889
 100%   2889 (longest request)

500 requests; Concurrency level: 50

Server Software:        lighttpd/1.4.13
Document Length:        4558 bytes

Concurrency Level:      50
Time taken for tests:   62.138366 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      2405500 bytes
HTML transferred:       2279000 bytes
Requests per second:    8.05 [#/sec] (mean)
Time per request:       6213.837 [ms] (mean)
Time per request:       124.277 [ms] (mean, across all concurrent requests)
Transfer rate:          37.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  170 547.2      0    2068
Processing:   105 5755 1372.4   6227    6909
Waiting:        5 5686 1383.7   6201    6682
Total:       2074 5926 955.5   6228    6928

Percentage of the requests served within a certain time (ms)
  50%   6228
  66%   6285
  75%   6325
  80%   6411
  90%   6468
  95%   6485
  98%   6528
  99%   6542
 100%   6928 (longest request)

Conclusion

As we may already be expecting, the worst performer is Apache2 + Dynamic mod_fastcgi.

Apache2 + mod_fcgid is performing surprisingly bad with a lot of stress. However, the performance could probably be better changing some of the configuration parameters.

Either Apache 2 + Static mod_fastcgi or Lighttpd + mod_fastcgi is the way to go, the latter performing a little better. My recommendation: use Lighttpd whenever possible. If you need to use Apache2, set mod_fastcgi in static mode.

Post a comment

Comments (1) Trackbacks (0)

del.icio.us: Benchmarking Rails enabled Web Servers

digg: Benchmarking Rails enabled Web Servers

Forwarding downloads from the dispatcher to the web server

Posted by daniel on Friday, March 09 2007 @ 02:59 AM CET
Views: 7,160

If you have a Rails application which requires for the users to be able to download files, either because you authenticate them, or because you need some pre-processing before serving the file, you will probably use send_file or send_data to send them from your action.

This works quite well when the files are small and/or you do not have too many concurrent requests. If the latter happens, you will end up using too many resources (i.e. too many dispatchers), thus using more RAM, and eventually, swapping too much.

The solution I'm bringing to you today, is something I have recently started using in in.solit.us. Basically, this method will use the X-Sendfile header to forward the download requests to your web server (either Lighty or Apache2).

This feature is already supported by default in Lighty. You may want to take a look at the following article in Lighttpd's blog: mod_proxy_core got X-Sendfile Support.

Setting this up in Apache2 is not so easy, and requires using mod_xsendfile, written by Nils Maier, licensed under the Apache License.

First of all, we need to compile mod_xsendfile for our Apache installation.

Download the module from mod_xsendfile page:
persefone:~# wget http://celebnamer.celebworld.ws/stuff/mod_xsendfile/mod_xsendfile.c

You will need apxs2 for this, so if executing apxs2 gives you a command not found, you will need to install the Apache development headers.

If you are using the default Apache2-MPM-Prefork issue the following command:
persefone:~# apt-get install apache2-prefork-dev

Otherwise (MPM-Worker) install the threaded development headers,
persefone:~# apt-get install apache2-threaded-dev

At this point, you can compile the module using the following command. A line in httpd.conf enabling the module will be automatically added.
persefone:~# apxs2 -cia mod_xsendfile.c
...
[activating module `xsendfile' in /etc/apache2/httpd.conf]

You need to activate now the module for the directory you want to use it. You can do it either in /etc/apache2/sites-enabled/ or in an .htaccess file in the directory.

If we wanted to enable /var/www/downloadable_files/, we will need the following:
 <Directory /var/www/downloadable_files>
     ...
     XSendFile on
     XSendFileAllowAbove on (If set to ON, the module will allow to send files above the specified directory).
 </Directory>

Now, the Rails goodies:

#Check if file exists and maybe authenticate?
 if File::exist? "#{@path}/#{@archive.url}" 
     #send_file("#{@path}/#{@archive.url}",
     #                  :filename => @archive.original_name)   
 
     #The code below equals the send_file function above.
     response.headers['Content-Type'] = "application/force-download"
     response.headers['Content-Disposition'] = "attachment; filename=\"#{@archive.original_name}\""
     response.headers["X-Sendfile"] = "#{@path}/#{@archive.url}"
     response.headers['Content-length'] = @archive.length
     render :nothing => true        
 end

The code explains for itself. In Content-Disposition we will set under filename the name we want the file to appear to the user who downloads it, and we have to supply the X-Sendfile header with the path+name of the file.

The last command (render :nothing => true) tells Rails not to render anything. If Rails renders something, Apache2 will not get the X-Sendfile request.

Post a comment

Comments (186) Trackbacks (0)

del.icio.us: Forwarding downloads from the dispatcher to the web server

digg: Forwarding downloads from the dispatcher to the web server

Improving Apple Mail performance

Posted by daniel on Friday, March 02 2007 @ 04:01 PM CET
Views: 4,557

If you regularly use Apple Mail as I do, and you have thousands of mails stored, you will notice that mails may take a few seconds to load, particularly old ones. In my case, I have around four thousand mails, with a envelope database of about 8Mo.

There is a solution (found via Hawk Wings) which involves a bit of Terminal usage that will boost your Apple Mail, and it will reduce the used diskspace as well. The speediness was noticeable in my case, and diskspace was reduced at about 5Mo.

First of all, quit Mail, open a Terminal, and change the directory to Library/Mail:

daniel:~ daniel$ cd Library/Mail

Then, open the Mail sqlite3 database issuing the following command:

daniel:~/Library/Mail daniel$ sqlite3 Envelope Index

Rebuild the subjects database and exit:

SQLite version 3.1.3
Enter ".help" for instructions
sqlite> vacuum subjects;
sqlite> .quit

You may open Mail now and see if it has improved the performance for you.

For those of you afraid of deleting your mails, here is what the vacuum command does: http://www.sqlite.org/lang_vacuum.html

Post a comment

Comments (1) Trackbacks (0)

del.icio.us: Improving Apple Mail performance

How to Backup your Mac

Posted by daniel on Wednesday, February 14 2007 @ 05:02 AM CET
Views: 2,984

So I got this fancy new LaCie Firewire external HD this week, with the purpose (among other things) of using it as a Backup drive.

Maybe the easiest way to do so is to fire up Disk Utility (under /Applications/Utilities), and copy your entire disk to a partition in the Firewire disk.

The process is really easy. Select the external drive from the sidebar, choose the Restore tab, drop Macintosh HD from the sidebar to the Source textarea, and drop in the same way your Backup partition into Destination.

Click the Restore button and the operation will start.
If your drive crashes in the future, you can reverse the operation and you will have an exact copy.

This method has an advantage, and that is you can use the Firewire Disk (not an USB disk) to boot your system.

The obvious disadvantage is that you can not make incremental backups. Every time you want to update your backup, you will have to start over again.

The second option is using some third-party software that manages the backup. Carbon Copy Cloner (free) or SuperDuper ($27.95) are good examples. The latter is probably better, and more flexible.

Anyway, I didn't want to pay anything, and I was not really convinced by Carbon Copy Cloner and provided that MacOS has rsync, I decided to use it.

As you will see, it is fairly easy to use rsync to create a backup, but if you don't feel comfortable around the Terminal, you have a GUI frontend for rsync called RsyncX.

Actually, the only directory I want to backup is the /Users directory, and particularly my /Users/daniel home directory, so this is the command I will issue, copying the contents to the Backup/ directory in my Firewire drive:

macbookpro:~ daniel$ rsync --verbose --archive --delete /Users/daniel/ /Volumes/Firewire/Backup/
building file list ...
...
sent 39373754756 bytes received 1004680 bytes 14805324.10 bytes/sec
total size is 39365457061 speedup is 1.00

The explanation of the options used follow:

--archive is equivalent to -rlptgoD, which means Recursive, copy symLinks, preserve Permissions, preserve Times, preserve Group, preserve Owner, preserve Devices

--delete will delete the files in the backup that do not exist in the source (maybe you should think if you want this)

--verbose outputs the files that are being copied. Nice for the first time, but remove it afterwards.

The next time you execute rsync, it will almost always be done in less than 5 minutes, as it synchronizes the data, and will only copy new or modified files.

You can even copy the whole drive with this method if you want. The only thing you need to remember is to precede the command with sudo if you are copying files outside your home directory.

Now, let's automate this process using crontab. Open a Terminal, type crontab -e and write the following (this example will execute the backup everyday at 2:00am):
0 2 * * * rsync --archive --delete /Users/daniel/ /Volumes/Firewire/Backup/

Or this, will run the backup each 15th of every month at 1:00am:
0 2 15 * * rsync --archive --delete /Users/daniel/ /Volumes/Firewire/Backup/

Post a comment

Comments (0) Trackbacks (0)

First | Previous | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Next | Last

Search

About

newton.gra2.com is a blog about technology, opinion and random thoughts written by Daniel Alvarez, a computer engineer currently living in Zurich, Switzerland.