TurnKey Linux Virtual Appliance Library

Wordpress setup cannot write config file

Hi, I have run into a minor problem installing Wordpress to the LAMP app. Right near the beginning Wordpress will guide you through the creation of the config file if you haven't already created one. However, the TKL LAMP app doesn't allow WP to write that config file to the server, whereas most web hosts do.

What needs to be changed to allow this?

Thanks in advance!

Jeremy's picture

Why not use WordPress appliance?

But I guess you no doubt have your reasons.

So without knowing where the file needs to go I'm not really sure. My guess would be that WordPress (probably runnng under the webserver user www-data) doesn't have write permissions on the folder its trying to write to. Where the file/folder is will guide the best (and most secure) way to resolve this issue (assuming my guess re permissions is correct).

I'm happy to give you my 2c if you can provide a little more info.

Sorry for the delay, life took over…

I'm planning on testing integrating various other software with Wordpress and the best way to go about installing all of them - that's the reasoning behind not using the WP appliance.

I've managed to convince WP to write the config file by changing the permissions, as you suspected. I CHOWN'd them all to www-data and it worked. Guess I shouldn't have been SFTPing files using the root user.

So I tried to create a new user "test" and making them part of the www-data group, but that doesn't allow them to upload files using SFTP. I would really appreciate being told where I'm going wrong here.

Thanks!


Jeremy's picture

Personally I just use root and chown when done...

I find it easier to just do what you've done. Having said that, assuming you did something like

chown -R www-data:www-data /var/www

(chown folder and contents recursively to user www-data and group www-data) then the SFTP you tried should work.

Also the way you are doing it may be preferable for some reason, but generally intending to install additional software doesn't necessarily preclude you starting with another appliance whose functionality you want (eg WordPress appliance) as base.

Clunky

Yeah, that's what I did, it just seems clunky - not very "turnkey" you know?

Can any of the people who actually put this appliance together give some advice on exactly how you're supposed to create a user that can FTP files with the correct permissions and thus negate the need to CHOWN everything once you've transferred things?

Thanks again :)


Jeremy's picture

Ooops...

I just created a new user that was a member of the www-data group and SFTP upload (using Filezilla) to the /var/www-data folder worked fine so not sure why it's not working for you? I lie, turns out I was uploading to the home folder of the new user - doh! AFAIK it should work, although it obviously doesn't... Perhaps it's because the /var/www folder is the home folder for the www-data user and the www-data user is not allowed to log in (for security).

And if you're using TKL as a development base for your own custom appliance then surely one line of code doesn't count as clunky?!

So bottom line you may be able to work around this issue to do what you want, but it's so easy to just do it the other way that it seems like too much work. To me it seems like a much tidier solution to just do all your dev as root and chown the whole folder when you're finished.

Thanks :)

Thanks for looking at this, I really appreciate. I'm also glad you're getting the same issue as me.

I know you can work around it, but I didn't think that was the point of TKL? I mean I could go and get slackware and setup my own LAMP stack if I really felt like it. I quite happily concede that I've missed something obvious here, perhaps a bit of documentation or something like that, I don' t know, but I just don't see how this can be the intended default behaviour.

On every web host I've used you can just FTP files up and off you go - there's no requirement to fart around with the command line to set the correct permissions once you've finished uploading. Surely that must be the behaviour that the LAMP stack should follow? I'm open to good reasons for this not being the case as I don't know as much about either Linux or security as the TKL guys, but until I hear them I'm going to continue to search for a proper solution to this.

I'd still love to hear from someone who worked on the LAMP stack appliance regarding this issue. Is there somewhere I could officially log this as a bug?


Jeremy's picture

Ok I know what's happening

Permissions are set to 755 by default  which means owner: read/write/execute; group read only; other read only.

So adding a new user with the www-data group still won't acheive the behaviour you want (as we've discovered) unless you also allow write permissions for the www-data group (ie 775).

To do that you'll need to:

chmod -R 775 /var/www

I can't be 100% sure without testing but I think that you would find this to be the default Ubuntu 10.04 (basis of TKL v11.x) LAMP stack behaviour. Again, I can't be sure but I expect that you would also find that to be the default Slackware (or any other Linux) LAMP behaviour too. I imagine you'd also find that by default most (user installed) LAMP stacks won't even have (S)FTP support unless you explicitly install that too.

When I get a chance I may install a LAMP stack into a clean Ubuntu install to confirm this, and if so your argument would be with Ubuntu/Cannonical (or perhaps Apache/Linux in general?) rather than TKL (but as I said above by default a plain Ubuntu LAMP stack doesn't support (S)FTP log in anyway).

I strongly suspect that the reasoning behind this is security although we would need confirmation from someone more knowledgeable than me.

Whenever you have a computer setup there is always a tradeoff between security and convienience. That's just how it is, you can't have it both ways. So TKL isn't designed to be everything to everyone, it's just not possible. It's merely designed to be a reasonable default setup that will be more-or-less useful for newbs OOTB (with perhaps a very small amount of tweaking for some usage scenarios, such as yours) and/or a good starting point for more advanced developers. As such I don't think your comparison with a shared web hosting account is completely fair as they generally lean toward the end user useability side of the spectrum (at the expense of security - I can vouch for that having had a number of share hosted sites hacked through no fault of my own). In my mind this is further confirmed by the fact that all shared web hosts I've experienced allow FTP access (passwords transferred out in the open) - something that is not possible with TKL (without modification). I also think you would probably find if you read detailed WordPress install/setup docs that in a default LAMP stack, you will need to adjust some permissions on some folders for it to work as designed anyway (I can't vouch for WordPress but I have found this to be relatively common to many Web apps that I have installed on TKL LAMP). If you are used to using Windows (IIS or even WAMP) or shared hosting this may seem foreign to you as these have default configs that are geared more towards usability (at the expense of security).

Also TKL LAMP is so much more than a vanilla LAMP stack. TKL includes features such as Shell-in-a-box (Webshell), Webmin (Admin WebUI), phpMyAdmin (MySQL WebUI), SSH and SFTP access, TKLBAM (backup and migration) all OOTB. Besides being available in a range of formats supporting many popular virtual environments (including being able to launch to AWS via the Hub) and having customisation and development tools such as TKLPatch. This means that if you don't want to use SSH (or a local terminal) because you find it 'clunky' then you have the option of using the Webshell (SHH over https - although this too may seem 'clunky' to you) or Webmin to adjust permissions.

IMO considering the quality of the TKL product range, what it offers and the price tag attached (ie $0 goes to TKL for almost all usage scenarios) I think your complaint around typing a line or 2 of code is a little unreasonable. Although to be fair, I guess no harm in putting your opinion out there, and I don't mean to stifle your right to have one.

TBH in my ~3yrs of involvement in the TKL community; to the best of my knowledge, you are the first to (publicly) complain that TKL is too secure (had plenty of experienced devs complain that it's not secure enough). Don't mean to be condecending, just putting it out there. :)

Thank you!

Thank you for your time and effort on this. I really do appreciate it. I also really do appreciate the time, effort and expertise that has gone into all the TKL apps, not least the LAMP stack. 

I understand the basic trade offs between ease of use and security - I don't reuse passwords and only know a handful of my actual passwords, leaving a heavily encrypted password manager to handle the rest, and yes I know that has issues of its own, but that's the trade off I make for convenience.

Having said that, is it not considered a security issue to log in as root? SFTP files as root? From my admittedly limited experience with Linux, everything I've ever read boils down to "never use root".

However, I believe there are more people out there (designers learning a bit more of the development side) that would benenfit more from even a simple notice regarding default permissions as you have described above. Something on the LAMP stack page that says:

Coming from Shared Hosting or a Windows background?

In order to have a "standard FTP account" please create a new user with www-data group priviledges (2 minute guide) and change the permissions on your /var/www directory (2 minute guide). Now you SFTP to the LAMP stack appliance (2 minute guide) just as you are used to with your Windows or Shared Hosting servers.

I wouldn't mind betting there are several people in my position who have tried out the LAMP stack as a replacement for their dev environment and just given up because of the "broken" defaults or lack of information as to how to quickly and easily change it to what they're used to.

Even with making it "less secure" with these changes, I think it will be an overall win since people will beusing SFTP as you so rightly mention.

Eh, I guess I'm just so impressed with how slick the TKL stuff is in general (with Webmin, phpMyAdmin, SSH, SFTP all as standard), that it really feels clunky having to have use root for SFTP (which breaks the simple install of one of the most popular blog/CMSs) and then change the ownership (I know it's only one simple command) on the recently uploaded files.

Would still be great to get some input from someone intimately involved with the creation of the LAMP stack though.

I apologise if any of this comes across as ungrateful, I'm really, truly not. I am just trying to help make things better for other less experienced users like myself. Afterall, the hard-core can look out for themselves as they already have the knowledge they require ;)

P.S. I'm going to go and try what you suggested now Jed ;)


Jeremy's picture

Excellent feedback!

When you put it like that you make a very good argument! I like it! :) Hopefully the core devs consider this.

In the meantime the TKL documentation can be found here: http://www.turnkeylinux.org/docs and it's a wiki so feel free to add (and/or cut & paste) some info there.

I continue to encourage the core devs to have a dedicated wiki page for each appliance (with a link somewhere really obvious) and something like what you wrote there would work really well IMO.

Good luck and if you end up creating anything new or interesting, please share :)

I definitely second that call

I definitely second that call for an obviously linked wiki page per app. That would probably have solved my problems already ;)

Anyway, I tried your suggestions and while it worked initially, the built in WP plugin delete and install didn't work and started asking me for FTP details (don't exist) and as soon as I uploaded filles via SFTP (which I could now do) they defaulted to permissions that WP didn't like *sigh*.

So, further to this, I took your initial advice and downloaded the WP appliance. It works, huzzah! In a couple of minutes I had auto updated to WP 3.2.1 and updated all the plugins. But wait, all is not rosie… next step was to try and integrate vanillaforums.org heh. Riiiiiiight. I created a new user in the www-data group. Can't SFTP upload :/ Change permission on the /var/www folder. Can now upload. But I can't navigate to the directory I have just created /var/www/forum !

So basically I'm going to have to really take a proper, long hard look as to what is different between the LAMP and WP apps and then see if I can't fix both for this kind of usage pattern anyway. Am I really that dd in how I'm attempting to use these apps?

Thanks for the wiki links. I'll take a look and see if it helps any.


Jeremy's picture

I vaguely recall someone else having the WP FTP issues

But I don't recall if/how it was resolved. I just had a quick search of the forums and couldn't find much, from what I read it sounds as if those issues should've been fixed some time ago. Although some did mention that installing php-curl helped others solve some issues (but couldn't work out if it was relevant to your issues). Perhaps worth a try (although it may be a stab in the dark)?

apt-get update
apt-get install php5-curl

As for your new user, perhaps try setting the home directory as /var/www? I'm not sure what other implications that may have but it will mean that when the user first connects they will start at the /var/www folder, and you shouldn't then have any issues. You can use the -d switch to specify home directory, either do it when creating the user (useradd) or use the usermod command. Eg:

usermod -d /var/www username

If that still doesn't do the trick it may be more permission issues (user vs group). Not sure...

I know I've pushed my barrow plenty on this one, but I still think you're making it harder than it needs to be :p. Personally I'd use the root account, get it all working how you want then set up your non-root users for access/modification/update/etc.

[off topic] Going back to your comment on using the root account and security. The core devs have spoken on this issue and I can't recall exactly what they said, but basically it makes lots of sense to use non-root users on a desktop, end user system. But it makes a whole lot less sense in a server setup, especially when many/most commands/functions that you will running/using require root status anyway. You may have probably noticed that all services run under limited user accounts, so if something does get hacked the damage will be limited anyway. That is why it is important to use a good root password or for maximum security set a random root password and use keys to login to SSH. If you wish to have limited end users (as I'm assuming you want) then the way you are going is relevant, but personally I'd still use the root account for development - just makes life so much easier IMO.

Shared hosting

Interestingly enough, two different of my shared hosts use 644 for files and 755 for directories.

Useful for figuring out *nix file permissions if you're not 100%
http://catcode.com/teachmod/numeric2.html


Jeremy's picture

Neat link

Thanks for sharing.

I think those permissions are probably not unreasonable defaults. I don't know enough about the intricacies of shared hosting setup to comment too much more. All my Linux knowledge has come from trying to do stuff until it works. Often it's involved a process of mess with things til they're really broken then start again. :)

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account, used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <strike> <caption>

More information about formatting options

Leave this field empty. It's part of a security mechanism.
(Dear spammers: moderators are notified of all new posts. Spam is deleted immediately)