So today, I happen to be looking at wikis for two small to mid-sized public proojects (MoinMoin and DokuWiki look like frontrunners right now — any suggestions?) Recently, I’ve also looked at blog and CMS software, and a host of other web apps. It’s as if these people have learned nothing about good software practices over the last 20 years.
Warning: Rant Ahead
So how many of you have been here before? You download WebApp X. It tells you to cd to your DocumentRoot and unzip/untar it there. At this point, most of them will tell you to chmod -R 777 the install directory. Some of the better ones, such as WordPress, will tell you to chmod it 777, or if that makes you nervous, to instead chown it to the user that your webserver runs as.
It is at this point that you realize that the Java-based programs ship with their own webserver that takes 2 minutes to load and uses 2GB of RAM, while the PHP-based programs want you to give them 32MB RAM per process, and probably modify your global PHP settings in a way that breaks some other PHP web app you’re already using.
As if that isn’t enough to scare you off, generally speaking, config files — including passwords to databases — are stored in the same directory, along with .htaccess files. Many of these programs are also downloading and updating plugins over the Internet, usually without any kind of cryptographic authentication, and overwriting their own program files in the process.
Oh, and this is a class of app that is notorious for security problems to start with, and makes your server known to billions of people via search engines.
Absolutely no opportunity for trouble here, of course! That sentence was dripping with sarcasm, in case you didn’t get it.
It also makes it almost impossible for people such as Debian maintainers to package up some webapps (such as just about every single one that uses Ruby on Rails) because there is just no sane way to make it behave with respect to the Filesystem Hierarchy Standard.
I’d love to see web app developers do a few simple things:
- Separate code from data
- Separate code from configuration
- Separate all of the above from the DocumentRoot to the greatest extent possible
I realize that some of this is purportedly to make things easier to install when you have FTP access only. But to me it seems just really poor design. I’ve written webapps, and it’s not that hard to do this part right.
Plus, doing the above right means that I no longer have to do something like use git on my WordPress installations because it’s too much of a hassle to apply security and plugin updates on all three separate ones otherwise.
I think both the “please chmod to” disease and the “please use gems/eggs/CPAN” disease stem from the same problem: people used to an utter lack of decent package management and thus succumbing to NIH.
Hi John.. as a wiki option, I’d be interested to know what you think of Zwiki.
Have you considered ikiwiki (ikiwiki.info) ?
ikiwiki is as stupid as it gets. the /etc/ikiwiki requirement cannot be got away with. that means shared webhosting is completely out.
The rest of CPAN requirements notwithstanding, the issue of creating a bunch of totally incomprehensible files; means there is “more than way” that the user will decide never to fix/debug or contribute to the project.
ikiwiki will live till the current author is alive !
Dokuwiki is fantastic!
Try ikiwiki.info. It’s sane software.
One of the big reasons for web apps stinking is a combination of most web hosts stinking (all customers on a server running PHP as www-data or nobody can mean that chmod 777 is the only way to write files), near-impossibility to get some customers to move to saner web hosts and webmasters-that-know-better not refusing those customers because we don’t think we can afford to.
Oh and I’d try ikiwiki too :)
my webdev attempts in python (webpy, django) consists exactly of FHS-compliant/packageable/in-python-tree modules.
php gets the fair share of bad points because while you could do (hack?) the above, it was designed to be like html… i.e static equiv dynamic… which is just plain wrong, and the whole of php feels just like that in so many areas I just can’t trust it, nor myself because it makes things so hard that I’m bound to make a mistake at some point.
at least the framework (cakephp) I used for php webdev specifically mentions to chmod/chown only its tmp dir, used for some caching, and also mentions you could put both its core files (and then app-specific ones) outside the www tree.
I found that a nice touch.
Let me second or third the suggestion of looking at ikiwiki for things
like blogs, particularly if you are working with version control.
Thanks for the suggestions, everyone. I’m going to be operating a wiki whose target audience is non-geeks (railroad passengers), so things like pretty themes, WYSIWYG editor, etc. are important. I haven’t looked at either ikiwiki or zwiki yet, though I thought that at least ikiwiki lacked the WYSIWYG editor.
Sounds like our requirements. We settled on the free open source edition of DekiWiki. We came close to going with Google Sites but turned away from that for other reasons.
Forum software is also very problematic on shared hosting. The one I used recommended 777 for installation directory. I of course was aware that 666 allowed write access for everyone, so I removed all these, in addition to chmod the config file with database login to my user only. It worked pretty well until some data I spotted some javascript being injected with NoScript in Firefox. The problem was that the forum software had chmod’ed files in cache/upload to 666.
I wrote about this problem on the forum’s support forum, but instantly got attacked by putting the blame squarely on my webhost. In the end though, both my web-host ended up adding suphp and the forum software patching up the chmod usage in their code.
Why should my rails app on my mac comply to your shittard filesystem standard? why should you care at all what it looks like under its toplevel directory?
This has nothing to do with random apps complying with a filesystem standard as distributed. It has everything to do with them being written so poorly that it is impossible to deploy them in a sane way, such as a way that complies with the FHS as an example.
Totaly agree! And also get rid of all dependencies.
Anyone tried to install trac on your server?
It’s a dependency-chain like no other.
1. Install python
2. Install easyinstall(which requires setuptool)
3. ….
…
135. Install Trac
-This is where the configuration starts :p
Seriously, if your program requires a tool called easyinstall it’s by definition NOT easy.
I feel your pain…
There is untapped resources in providing easy-to-install software for the benefit of pure system administration while still providing sanity to the rot.
If you feel adventurous, try something a bit different, e.g. Nanoki, a simple, elegant wiki engine implemented in Lua.
Online demo:
http://svr225.stepx.com:3388/nanoki
Nice rant, however I must point something out:
“It also makes it almost impossible for people such as Debian maintainers to package up some webapps (such as just about every single one that uses Ruby on Rails) because there is just no sane way to make it behave with respect to the Filesystem Hierarchy Standard.”
The Filesystem Hierarchy Standard sucks.
The whole LSB extends the FHS. Guess how much it will suck.
The idea that the FHS will at ANY TIME IN HISTORY make things EASIER is an illusion. People must realize it. Debian is lazy. They stick to the FHS and will never change it. So they split packages in order to fine-tune what a user wants, BUT THE USER IS FOREVER FORCED TO REMAIN IN THE FHS because anything else will not be supported by Debian. What does the splitting of packages give you as a user?
Nothing.
Oh, except a headache.
And I agree, webapps do quite suck. I think the separation between webapps and normal apps should go away.
Um, I’m pretty sure Rails does all three things you mentioned. The config files are in the config directory, and the rails code is not contained in the webroot. What exactly are you taking issue with?
How can I avoid putting the database config file in the document root for any PHP application ?
I couldn’t agree more on the chmod 777 aspect. I guess it’s to avoid dealing with millions of people not understanding the intricacies of file management, but should they be hosting webapps in the first place?
Maybe what we need are web services that only host specific applications on domains. For example, instead of getting a shared hosting account for beginner wordpress users, maybe they could just get a wordpress hosting account. Then they wouldn’t need to install it, or maintain the security. Much like using wordpress.com but with their own domains.
Webapps stink so bad because people who know better spend more time bitching in their weblogs than they do teaching n00bs or submitting patches.
Are you sure?
I’ve submitted patches to Redmine (a Ruby on Rails app), I wrote PyGopherd (a multprotocol web/app server with plugins handled in a sane way) from scratch. Or did you miss the part where I mentioned that I’ve written web apps too?
Something tells me that a patch to remove the mention of chmod 777 from WordPress would not be accepted.
Use ASP.NET, try Umbraco for an easy to install CMS. PHP stinks…
You brought up some really good points. Many of them however, are not the fault of web developers, but instead are the fault of history. If I write an open source application that I want to be widely adopted, I have to revert to bad practices such as requiring chmods (to allow writing files), and putting private files under document root (for those FTP-only web hosts that only give you access to the document root — that is, most of them). It is a trade-off an open source publisher must make to make the application usable to a wide audience.
History has created an open source web stack that is ill-suited for deploying web application packages. The web server and application sever layers could use a lot of improvement. Try to direct your energies there. Many an open source web developer would be grateful.
You probably do have a point on PHP putting too much in the document root. But there’s nothing inherent in the rest of the stack that mandates that, or even in PHP that mandates a lot of it. Good point on those web hosts, though.
i kind of had the impression that he was talking about web apps in general..
oh, wait…
The chmod 777 issue can be avoided on professionally set up webservers. If the web server is running with mpm_perchild or PHP using (F)CGI/suexec, it’s less of an issue.
Separating out the code into distributed directories (FHS) is not always possible due to the common PHP-with-HTML intermingling. Though, there are a few applications where it’s easy to accomplish. I’ve seen one of those Debian packages making sense actually.
But, can you provide a shining example of how you’d package a web app? Seen a good one lately?
(Personally I think it’s yet more troublesome that everyone clinches to SQL string concatenation, instead of using prepared statements.)
I would agree whole-heartedly. I think that web applications can be much improved if they worked right out of the box… like most system applications do. They need to have installer that works with minimal headaches, little or no configuration changes, and (literally) no external dependencies.
“At this point, most of them will tell you to chmod -R 777 the install directory”
This is why no one uses Linux.
My mistake… I just realized it’s less of an issue just so long as the web server is running with mpm_perchild or PHP using (F)CGI/suexec.
Welcome to my world. Try not to look at the rubbish strewn everywhere.
My estimation is that systems designed to run inside VMs will eventually edge out systems which have to run on shared hosting.
The problem is that the entry barrier for web development is pretty low. This means (relatively) stupid developers can also be productive and ‘get something done’. Stupid developers = stinky code. There you have it.
Hi,
To all the posters expressing frustration trying to get Dokuwiki, Trac, etc. going, you may want to give BitNami a try (http://bitnami.org). It is free, we try our best to make the installation of the apps painless (to the point of including and configuring Apache, MySQL, etc. as part of the install) and to keep them secure
I have recently found Hatta – http://hatta.sheep.art.pl/ – to be quite nice for a small, simple wiki.
It does not have a “graphical” editor, though – but I like its simplicity and featureset (clean URLs, backed by Mercurial, clean HTML/CSS that is easy to modify).
The author is really quick to update/respond to bug-reports etc.