Has anyone here configured an EC2 instance to work with fuse & s3fs. I'm using an Ubuntu Karmic 9.10 EC2 instance.
I tried mounting my sites/default/files directory through s3fs with allow other specified in fstab: seemed to be working well.
...until I cleared the Drupal caches. Then I got the horrifying, "The selected file /tmp/filebQm6Ek could not be uploaded, because the destination is not properly configured."
I've tried everything to make tmp writable by Drupal, but no chmod or chown has worked for me.
I have also tried mounting the drive in the mnt directory and then mapping the sites/default/files directory with a symlink, didn't make things better. Also used sticky bits to keep permissions intact and chown to www-data group and chmod to 777. To no avail. Even with the tmp directory fully writable, Drupal doesn't think it is.
I've tried launching fresh instances a couple times, but it starts up again the moment when /sites/default/files is mounted. If anyone has been through this before, it would be awesome if you could tell me what's going wrong!
Best,
Joseph
Comments
Disable File Deletion
Long story short, how I got this to work was to make file_delete do nothing.
....I'm back to square one
When I first installed fuse, I started off with the tmp and files directories in the same bucket. Which seemed to work fine, for a few seconds, when the files started to randomly disappear from the s3 account. It didn't work before because I tried recreating Drupal's exact file system structure with S3fs, outside of the mount directory. When I checked the Amazon S3 account, I noticed however that this wasn't happening inside the bucket; the files rather were all being created at root, hence the disappearing act.
Seems s3fs really prefers the mnt directory. Now I'm using the mnt directory to house both. Back to the basics seems to be working. Guess Drupal's file system likes to stay in under one roof.
Well, it's only been a few moments since I've gotten a caches clear message unaccompanied by any error messages. But hopefully it'll stay that way.
File Delete
Hi Mike,
You think it'll still persist, the file deletion thing. If so, I'd be glad to disable it. It says 9 functions call it, so you must have done more than commented it out :)
Have it return true at the
Have it return true at the top of the function.
Also use these other patches
http://drupal.org/node/755586#comment-3047402
http://drupal.org/node/818818
http://drupal.org/node/721400
Thanks
These'll come in handy, gotta start working on getting all css & javascript to s3.
Well so far the only problem I've had is...
I had to symlink the files directory because it was prepending an extra slash for the images since it was at /mnt.
So I restored it to sites/default/files. There's probably another way to solve it. But it's working so far.
Symlink is how to do it
Symlink is how to do it
File Conveyor
My recommendation is to avoid s3fs completely and use File Conveyor. This is a standalone program written by Wim Leers and in my experience works very well. It uses kernel hooks to determine when files are updated or changed and can directly replicate them up to S3.
http://fileconveyor.org/
The other reason this is ESPECIALLY cool is because the Drupal CDN module can use file conveyor to make decisions as to which files are stored locally and which ones are on the CDN, and then dynamically rewrite the URLs as they are served to the users. I played with s3fs for a long time and gave up in favor of this method.
On a side note, the CDN patches to Drupal core are now in pressflow as of the latest version, so this should be plug-and-play to get your content hosted on S3.
multi server File Conveyor
Have you been able to get it working with multiple web heads?
Multi heads
In short, not yet. Perhaps we can get Wim to chime in on this as well.
I'm using it strictly to serve static content from a CDN. So yes there would need to be an underlying solution to replicate between multiple web nodes. After a lot of reading my plan is to roll with a glusterfs under the hood for server-to-server file replication. There are some interesting deployment methods people have talked about in this group and elsewhere that avoid some of the performance penalties.
Same question
Glad to hear it's working out for you. I really did like the active file monitoring of file conveyor.
I need it to work for load balanced environment though.
Joseph
Hey guys, I have some
Hey guys,
I have some questions for you:
Is the performance affected by fileconveyor?
I'm putting the files directly to CDN in hook_nodeapi when you create/edit a node with images, flash or videos.
Do you think this approach is less performant than fileconveyor or an automatically sync folder->bucket?
Is there a way to put also the aggregated .css and .js on CDN?
How would you do that?
I know it would work with fileconveyor, other ways?
Thanks,
Ionut
My experience
We originally used file_conveyer and had it updating our 3 load balanced production servers .. however it required that we had one master (for the database updates)... and two slaves... so if the master server went down so did our upload ability, and the master did of course do down... so this solution wasn't for us (besides an rsync seems a better idea now).
Anyway... We are moving to S3FS via Fuse (hence my arrival here) and we can mount the bucket, read and write to it as root... but Drupal did not like it... from Settings>file uploads, I could see Drupal complaining that the files folder didnt exist, even though we had it symlinked and it all seemed fine from the shell.
So although I've not tested it yet, this is a nice tip on how I found the cause...
By su'ing a shell as www-data ("su -s /bin/bash www-data" to be precise).. I was not able to browse to the s3 mount via our symlinked site folder nor by going to /mnt/s3/file ... this proves that www-data cannot see the files folder because it does not have permissions to see the bucket, even though it has permissions on the files folder within the bucket.
FYI> The mount is owned by root and its group is root, perms are owner rwx and group read, I myself cannot chmod/chgrp the mount itself (even as root) as it's past my 'nix skills. The files folder within the bucket has root owner and www-data group, both with rwx...
Tomorrow I'll get sysadmin to look at the perms and update here.