nick soph's picture

Hi

Was hoping to find a turnkey soloution for using developing a wordpress site using a local server and installed the Turnkey Wordpress appliance using the newest ISO to find that in order to install Themes or update Wordpress or its plugins I needed to a bit more than I was expecting and am currently capable of.

Reading around this sites forums it seems that it is necessary to install Proftpd and change a set of permissions  (and possibly make a user ?)

I wonder if anybody has been through this process and is willing to list the steps needed - including the linux commands - to get a standard Turnkey Wordpress install up and working so as to be able to update Wordpress and install Themes from the Wordpress interface.

Best wishes

nick soph 

Forum: 
Jeremy Davis's picture

I could be wrong but I wouldn't think that it should require much...

Personally I would just give ownership of the whole WordPress folder to the webserver account (www-data). Like many things though, making life more convienient is a trade off (often increasing security reduces user friendliness and/or usability). For security best practice only the folders that require write access by the webserver should be owned by the webserver (because if your webserver has write access everywhere and your server is compromised it makes it easier to hack your WordPress install) but for ease of use giving the webserver ownership should resolve all your issues...

So try this (from the commandline - either locally, via SSH or Webshell):

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

And you should be good to go...

nick soph's picture

Thanks Jeremy

Security wont be an issue as it is being used soley as a dev platform and I expect your answer will do some of what I was after but I unless Im missing something Ive still to install Proftpd and looking at some of the other replies installing Proftpd seems not to be straight forward as it wont install using the Webmin interface which will only update if Webmin itself is updated.

If anybody has been through the process and can give me at least an outline of all the steps necessary to be able to get to the point where all Wordpress functions are available I would really appreciate it.

Thanks again

nick 

Windows 10 64bit with HyperV - learning Javascript slowly

Jeremy Davis's picture

Surely you wouldn't need that for standard WordPress...?! I have heard of people who don't want to change permissions using vsftpd or Proftpd to allow updates, themes etc to be installed via WP Admin UI but AFAIK the permissions tweak should mean you can do all that from within WP (without installing additional software...

If you intend some other use for FTP then you do realise that TKL has OpenSSH installed OOTB which provides SFTP don't you...?

nick soph's picture

Hi Jed

Followed your instructions and - great it works just as I wanted.

Many Thanks

Nick

Windows 10 64bit with HyperV - learning Javascript slowly

Jeremy Davis's picture

As I said in my post above to make life easier (and not install an FTP server) you will need to grant permission to the webserver user to your WordPress install. From the commandline do it like this:

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

I have just tested it with a clean install of TKL v13.0 WordPress appliance and initially (with no changes) it asks for FTP details. After changing the ownership (as above) it worked fine (WP and all the plugins...)

Jeremy Davis's picture

And it seems that it is not an uncommon problem with WP, although it usually seems to occur on WP on shared hosting. I think your issues are to do with some config somewhere that has come with the backup because it seems that the problem can occur when PHP is upgraded (on shared hosting) and I guess migrating your site to a new TKL version (which has a later version of PHP included) is in effect a similar thing.

From my reading there are a few possible resolutions but as a non-WP user, I'm not really sure what the best way to go would be, perhaps first thing is to check your php.ini file (something like /etc/php/apache2/php.ini IIRC) and make sure that the line "allow_url_fopen = on;" exists and is not commented out. If you change that I think you'll need to restart the webserver (service apache2 restart IIRC).

If that's a no go, then I suggest you do a bit of googling yourself and see what you can find. Worst case scenario you could even try posting on the WP suppot forums. Keep in mind that TKL v13 is based on Debian Wheezy (and TKL v12.x was based on Debian Squeeze). If you get lost I'm happy to try to help you (if I can) but it'd be great if you could post the links/instructions that you are struggling with..

Also if you find a resolution, if you could post back that'd be great, as other TKL users may well find themselves in the same situation and be looking for a fix. Thanks

Jeremy Davis's picture

How about trying just restoring the database and /var/www/wordpress folder to a clean instance and see how that goes... That's what I'd do before I decided to just do it all manually...

Keyturns's picture

I confirm I had the same issue with WP plugin updates as CJ describes (getting challenged for FTP credentials) with a fresh install TKL 13.0 (turnkey-wordpress-13.0-wheezy-amd64), and the command below resolved my issue also as CJ described:

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

 

The error details from the WP Admin interface were not clear making this a bit of a head scratcher for a sec.

 

 

Jeremy Davis's picture

I noted this issue on the TKL Issue Tracker. I have tracked down the specific folder that needs permissions changed. It's /var/www/wordpress/wp-content and have since issued a pull request to resolve it in future versions...

Let's wait and see what the core devs think! :)

Tom Henderson's picture

Three basic problems:

1) the permissions are wrong and wp php config is wrong as noted above

2) the firewall needs to have ports 20 and 21 opened so an actual ftp or sftp app can be used for WordPress Updates---> which needs sftp or ftp to work and exist in the first place

3) there is no working ftp client, so installing vsftpd is needed--- or whatever choice that you want to make.

Spent five hours debugging this.

 

Tom

Jeremy Davis's picture

But to clarify; technically this is not a bug, but a security feature. With the permissions set as they are, even if your webserver (or WordPress itself) is compromised, a remote attacker can not maliciously alter the WordPress install itself. So it was set like this by intention. Security is often a trade off against user-friendliness. Seeing as WordPress is so popular it is often targeted and so it seemed like a reasonable position to take. FWIW the TKL WP has been setup like this since it's first release in 2009.

Having said that, TurnKey's popularity has grown and considering the number of frustrated users we have decided to change the default setting. This does reduce the level of security, but we figure that the trade-off of less frustrated users (like you) wasting their time it is a fair trade-off to make. As such, you'll be pleased to hear that as of the next TKL release (v13.1 - currently being worked on) this default has been changed to accommodate an easier in-place WP upgrade.

To address your individual points:

1) As has been mentioned there is a simple workaround above. Although the workaround posted on the TKL tracker on GitHub (here) is probably preferable.

2) The firewall has port 22 open already and SFTP is enabled (and listening on it). Port 22 is the default SFTP port (port 20 is default FTP port and 21 is default FTPS port - note FTPS is different to SFTP).

3) With the adjustments noted in point 1 (above) there is no need for an additional FTP/FTPS server. As we try to make the TKL servers as lean and light weight as possible we do not include anything more than what is required.

So I'm really sorry to hear that you wasted 5 hours on this, but I hope that you can understand where we come from and as I say, the default config will be adjusted to make it easier in the future.

And thanks for persevering and using TurnKey. Hopefully your ride is easier from here on in.

Tom Henderson's picture

SFTP doesn't work in the ISO as downloaded. I stopped fooling with it and brought in vsftpd-- knowing that it works. You can't do updates out from the initially booted ISO. Wordpress's options, either type of ftp, don't work. You can't bring into production or even development a Wordpress release that needs updating. Things break upstream if you do. So the release was dead in the water.

And they couldn't have worked for reason #1, the workaround you cite, which works-- but weakens security as well. It was slapdash. I'll have the exact permissions and ownership worked out. But there's a QA step here that was missing as no one brought the release through initial steps needed to make this appliance working and secure from an ISO boot. This is my criticism.

I made it work, and I can do this, but a large number of your potential clients don't understand how to do this, will fail, and you're not served them well.

You've also no automated process that allows TKLBAM to restore a destroyed or inop appliance. My own fat fingers destroyed my website and my need to restore it, as little used as it was, meant I decided to forego the steps to restore it from AWS and just build a new one. Little did I suspect as I read the email you sent regarding lack of support for pre-Debian Wheezy that I'd run into this problem, which didn't exist in the last version of the TKL Wordpress appliance-- or at least I didn't uncover it.

Tom, ExtremeLabs

 

Jeremy Davis's picture

TBH I didn't realise that updating via SFTP was an option - only FTP or FTPS (you probably know already but for other casual readers: SFTP is SSH tunneled FTP; FTPS is FTP over SSL). You post prompted me to do a little investigation and I found this plugin. Is that what you tried to use to update via SFTP?

Also in response to your post; personally I think that statement "the release was dead in the water" is overly harsh. There are thousands of TurnKey WordPress sites running currently and the number of complaints is only a very small fraction of that. Perhaps for your purposes/usage scenario that may be the case but I don't think that it is fair to portray it as the blanket reality.

Having said that, I have acknowledged, the current config is definitely not optimal (we consider it a bug). I also acknowledge that the permissions posted within this thread are also sub-optimal. But you'll notice that in a couple of posts I have referenced the bug on the GitHub TurnKey Issue Tracker (here it is again). You'll note that that there it details the specific permissions required (i.e the wp-content directory) rather than taking ownership of the whole /var/www/wordpress tree.

I know that it is still not optimal security wise, but I thought that it was a reasonable balance. If you have or know of an even better permission/ownership config (or any other WP config for that matter) then please work with us and let us know ASAP as the change listed there (on GitHub) has been applied to the appliance source and will be included in the upcoming release. If it can be done better we'd like to know so we can make the new release the best balance between usability and security.

Perhaps we should revert the permission changes and include the SFTP update plugin and leave the WP directory tree owned by root? That might be preferable to the changes that I made to permissions?

FWIW the code that builds the WP appliance (with TKLDev) is on GitHub here. The script that specifically does most of the heavy lifting (i.e. install & config inc setting permissions) is here.

I'm not quite sure what you mean by "You've also no automated process that allows TKLBAM to restore a destroyed or inop appliance.". Are you suggesting that there should be a way to automatically restore a backup on launch of a new appliance?

Assuming you are, FWIW If you are hosting on AWS via the TurnKey Hub you can launch a new appliance with your TKLBAM backup pre-integrated (it restores your backup after installing and applying security updates). Although it would be quite cool if there were an inithook that asks if you want to restore a backup (after you've added your Hub API key) on firstboot of a fresh appliance. Is that what you meant? If so I think that's an awesome idea! In fact I've added it as a 'feature request'.

TBH I'm surprised that the earlier versions didn't have this same issue because AFAIK the build code was the same for previous versions, just this one includes a newer version of WP off the bat.

Also I just wanted to say that I'm sorry if I seem (or did seem in my previous posts) ungrateful for your feedback. I guess I can be a little defensive of TKL because I have put so much of myself into it (although FWIW I work for TurnKey now - apologies on the shameless self promotion) that sometimes I react out of defensiveness when I feel like someone is giving unfairly harsh criticism. But I can safely say that I speak for all of us here at TurnKey that TKL really does appreciate feedback and (constructive) criticism even if we don't always have the resources to implement it straight away.

So I again apologise that you have found it so painful and that you wasted your time trying to get it to work the way you wanted.

But let's work together to make TurnKey the best! After all that is the superpower of free open source! Users such as yourself that have skills and knowledge, can contribute back to make each new release so much better than the one before.

Jeremy Davis's picture

Wow, you're right re v12.1 being able to update OOTB. I was pretty sure that the code was the same, however I just tested it and it updated fine. Having a bit of a closer look, it looks like the default permissions though, are www-data:www-data for the /var/www/wordpress tree. So obviously the core devs tightened up those permissions for the v13.0 appliance but obviously didn't test the update mechanism. TBH I can see how this would happen, as at the time of build, the code installed the latest version of WP so there would be no way to easily test it (unless it purposefully installed an old version to test the update mechanism). Still I acknowledge that your criticism is fair and bugfixed appliances need to be released quicker (don't worry we have been discussing this behind the scenes).

Also whilst the tweak to the WP conf file is the best way to go, it seems that by default (even without it) WP will try the 'direct' update method initially. But if that fails (as it did; due to the permissions) then it falls back to FTP/FTPS (which also fails due to no FTP/FTPS server. Once that happens it won't retry the 'direct' update method unless you manually configure the WP conf file to use it.

So FWIW you don't need FTP or FTPS to do updates, you just need to add a line to the WP config file. The v12.x appliance did not have FTP or FTPS, and the bug I linked to (on GitHub) tells you the change that needs to be made to the WP config to make it work without FTP/FTPS. I have tested this and it works consistently for me.

As for your 20 steps to restore to a new server, I'm not sure why it is that painful for you. By default the WP TKLBAM profile is blank, but inherits from core so your whole WP dir (inc plugins etc) should be backed up. When you restore it should just copy across everything as is and you should be good to go (I say should as I haven't actually tested it myself, but that is the intended behaviour). So it should be a case of:

  1. on your old server: run
    tklbam-backup
  2. launch new server, inc TKL Hub API key (handled automagically if you launch via the Hub)
  3. on your new server: run
    tklbam-restore <BACKUPID>
  4. done!

One final FWIW; the appliance bugs/feature requests are all on the TurnKey Issue Tracker (on GitHub). They are all tagged by appliance and any that have workarounds are also tagged as such. Perhaps we need to put more info about that on the Help page to make it clearer? Confusion can occur I guess though when bug fix code has been committed (thus the issue is closed) but before the new appliance is released (i.e. the bug is not visible unless you look at closed bugs and it opens to 'open' bugs by default).

So beyond better QA testing (which I agree we need to do) and faster bugfixed releases (which I also agree with), what other things could we do to make the info more easily available? Is providing more info on the help page (link above) enough, or do we need to do something else (instead or as well as)? If so what do you suggest?

Jeremy Davis's picture

You'll need to endure a paragraph or too of 'discussion'! :)

Because the only way to make it really easy is to reduce the level of security for your whole server. Obviously that has implications so we don't want you doing that unless you know what the potential costs are. The flipside is that without updates WordPress itself is likely to become vulnerable (although the chance of the attacker being able to take over your whole OS is highly unlikely due to the choices we have made). So we try to find a middle line...

To allow upgrade of plugins and themes you can follow the instruction here. However that still won't allow major updates. To ensure that the system uses the 'direct download' method make sure that you adjust the wp-config.php file (as included on GitHub). To allow WP upgrades to complete you will need to allow the webserver account to own the whole WordPress directory tree; like this:

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

After the update has completed I suggest that you change ownership back; like this (it should still allow you to install and upgrade plugins and themes but not major updates to WP itself).

chown -R root:root /var/www/wordpress
chown -R www-data:www-data /var/www/wordpress/wp-content
Jeremy Davis's picture

TBH that doesn't give me much to work with. While I wrote that email this morning I did it on a live instance that I launched on AWS so I know that it works...

In a nutshell I changed ownership and adjusted the config file. I then ran the updates from within WordPress. So if it didn't work for you I need to know how you did it so we can get to the bottom of why it didn't work...

Jeremy Davis's picture

Essentially the WordPress appliance is just LAMP with WordPress pre-installed (with a few minor tweaks). SO that's all good... Whatever works best for you.

Obviously it's your server so set it up however you feel comfortable, however just keep in mind that any new service/software you add and/or ports you open to the world - the larger the potential target your server becomes for security breaches. I don't mean to scare you with my tinfoil hat or anything; just making sure you have an understanding of the consequences of the choices you are making...! :)

All the ways to connect to your server are documented here. The obvious way to allow Windows Explorer integration would be Windows Filesharing (i.e. SMB/CIFS via Samba). However I would strongly recommend against using that! SMB/CIFS is not a secure protocol and was only ever designed to be used within a LAN or over a VPN. Traffic is not encrypted and could be easily intercepted as it was never designed to be used over the internet. Besides, considering that you struggled with the WordPress fix I think that installing and configuring Samba will be a nightmare!

SFTP would be the best way to go IMO but unfortunately Windows Explorer doesn't currently support integration with SFTP (as Mac and Linux file managers do). AFAIK there are third party Windows File Managers that do but I can't recommend any and I suspect that you will need to pay for a decent one. So that leaves a couple of options that are probably not quite as polished as you might like although should still achieve what you want. I'd go for either a third party Explorer plugin like Swish (allows Win Explorer to connect to SFTP but it considered 'alpha' software - I've never tested it) or a standalone app like WinSSHFS (which provides SSHFS (via SFTP) which Win Explorer can then use - it's abandonware but I've used it successfully on Win7).

Jeremy Davis's picture

I must admit that I got the impression that you were pretty newb from your previous posts. My apologies if you felt like I was treating you like an idiot...

Glad to hear that TurnKey is providing you value, even if there were a few issues when you first got started... As a web site dev using WP perhaps you would have some insight and/or opinion on how best to configure a production WP server to create the best balance of convenience and security? just posted a (non-complete) list of possible approaches lower down this thread... Actually maybe we should start a new thread specifically on the question of the best preconfig setup...?

Also FWIW Notepad++ has an FTP (which IIRC includes SFTP) plugin so it can edit remote files as if they were local (and auto uploads them on save).

OnePressTech's picture

Hi Jeremy,

I'm always interested in learning new techniques and am quite security concious. I'm a curious fellow though so I tend to always want to dig a little deeper.

What is the extra security value of locking down the wordpress folder? If someone has cracked your apache webserver does it really matter!

Not challenging the practice...just curious as to what additional protection this provides for the loss of convenience :-)

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

Essentially the benefit is that if Apache (and/or WordPress and/or anything running under the Apache user account) are compromised, then the damage that can be done to your server is minimised. Files and directories owned by root (e.g. the WordPress root directory) can't be modified by the Apache user (www-data).

I guess where this all becomes a bit contentious is that with it locked down, it is harder for 'newbs' to upgrade their WordPress install. And if they are running an old/outdated WordPress then the risk of their site being hacked becomes greater...

I have considered whether it might be useful (or not) to have permission setting scripts (for all appliances - at least the LAMP based type ones anyway) that could tighten and relax permissions as relevant. It may be a nice way to go, but it's something else that might go wrong and something else to be maintained...

Obviously if a nasty gets root access the game is up regardless...

Considering the feedback of the more locked down v13.0 release, we will be relaxing permissions somewhat for v13.1. Currently the plan is for themes and plugins to be installable by default. However I have recently become aware of suphp and need to do a little more research but that seems to be a common solution to permissions issues such as we are having here...

As you know Tim, we are always happy for feedback/counterpoints/whatever so feel free to challenge the practice if you want! :) Obviously Alon and Liraz get the final say in what gets released but I can be quite influential if I can provide a good case! :)

OnePressTech's picture

Thanks Jeremy, as always for a thoughtful answer...it just didn't answer the question :-)

I'll rephrase my question...

If your apache webserver is compromised then I would expect the hacker has pretty comprehensive access to the server wouldn't they? Wouldn't an apache compromise be a root account compromise? If so then they have full access to everything. So what is the point of the extra lockdown of the wp directory?

It seems to me that we have a protected outer door (apache) and a protected inner door (wp). Anyone who can crack the outer door is unlikely to be slowed down by the inner door wouldn't they.

Not challenging the practice...just looking to understand it better before I embrace it :-)

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

Apache runs as www-data - a limited user account. Well actually technically it first starts under root (so as to use reserved ports 80 & 443), but then instantly spawns child processes that run under the limited user account of www-data. It is these limited www-data owned processes that access the filesystem and serve the web content available via a web browser.

In the current WordPress server, the www-data user has read only access to the whole /var/www tree (actually it has read only access to most of the filesystem) but only read/write access to /var/www/wordpress/wp-content. The WordPress files themselves are owned by root so the Apache (or any other process running under the www-data user) cannot alter them in any way, shape or form.

As an additional precaution, the www-data user account does not allow local login. So the only attack vector (not withstanding Webmin, Webshell, phpMyAdmin and SSH) is via http/https provided by Apache. As Apache's write access is limited to just /var/www/wordpress/wp-content the amount of damage that a compromised Apache could do (assuming no privilege escalation bugs) is severely limited.

So in short; no, a compromised Apache does not grant the hacker root access. To gain root level access you'd need to log in as root (brute force password crack, etc), compromise a process that was running as root or exploit a privilege escalation bug such as those found is bash relatively recently.

Having WordPress locked down in the way that it is/was essentially protects against some (but not necessarily all) as yet unknown/undiscovered Apache security bugs and to a lesser degree some WordPress security bugs too.

Did I answer it that time? :)

OnePressTech's picture

I'm always learning something from you Jeremy :-)

The reason for my double-check is that Wordpress hardening recommendations are primarily limited to a recommeded protection level of 755 for directories and 644 for files.

http://codex.wordpress.org/Hardening_WordPress

What I now recognise, after your explanation, is that this Wordpress article does not actually spell out the details of the file ownership split between the user (owner of the website) and the web server (facilitator of the website). The article describes what file protection level to use but is rather oblique in describing who should have what permitted control over which directories and files. It lists some but not all.

When I get conflicting recommendations I like to double-check...don't mind me :-)

 

Cheers,

Tim (Managing Director - OnePressTech)

OnePressTech's picture

Thanks for the suPHP reference. Commonly used by VPS hosters to isolated multiple users on the same machine it is not clear that the benefits would outway the performance impact when operating a single owner appliance. I found a reasonable summary here of the options...

http://error.co.de/

It doesn't sound like suPHP would be a good addidtion to the TKLX default Apache configuration.

 

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

My effort was well rewarded! :) I helped you scratch your curious itch and you have well repaid me by doing some research! I had come across it but TBH was not totally clear on actually what it did and how (I got the basic idea, just not the detail). With your input it becomes clearer and I am inclined to agree that perhaps it is not a great fit...

Having said that we are still left with the quandary of the best way to go forward. A summary of the options as I see them (not necessarily comprehensive):

  • Grant www-data ownership to whole WP dir tree
  • Lock it right down but provide a script to loosen (and perhaps a cron job to retighten?)
  • Install a third party cli tool such as wp-cli (somewhat like drush for Drupal) and recommend it's usage for updating WP
  • Install a FTP server and preconfigure WP to use FTP for update (and either create a new www-data group member that can use it; or use root - although root may introduce new permissions issues...?)
OnePressTech's picture

I would lean towards option 2 in your list though would need to consider further whether that should be script or Wordpress plug-in. For User simplicity making it a hooked transparent feature of the Wordpress update request would be ideal but there are potential side-effects. Some Wordpress plug-ins that perform augmentation functions sometimes look to see if a function has already been hooked and will not operate. S2Member for example detects if you hook the WP email and greys out its WP email enhancements. If we hook the update request it is possible that we will collide with another mainstream plug-in. Would need to check.

The other item that will need to be considered is Wordpress auto-update for minor releases (enabled by default). We would need to review the mechanism for triggering the auto-update and apply the same hook logic.

Now that I have a handle on the options and pros & cons I'll mull it over and re-post to this thread sometime next week with a considered suggestion based on your well summarised list of options.

Is there any ETA on TKLS 13.1 in case we want to get this into the 13.1 release?

 

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

I like that idea... But TBH that is out of my league (I'm a sys admin - not a programmer). I'm sure if I spent enough time I could do something but I think my time is better spent elsewhere.

As for v13.1 - at this stage that has somewhat stalled... Alon and Liraz are madly working on some important stuff behind the scenes and so everything (inc v13.1 & v14) have been pushed back :( We have discussed doing an incremental release (i.e. just updating the most heavily used appliances) but no firm decision has been made. If we were to do an incremental release then I would imagine that WP would be part of that (as one of our most popular appliances).

It would be awesome to have this included in v13.1. As per above though, there is no great rush as such... And even if there were, if we knew something was in the pipline and we could agree on a deadline then there could be some flex on release date...

My modification to wordpress/wp-content ownership (to make installing/updating plugins and themes easy) was merged, but at the time I thought that essentially solved the problem. In retrospect I should have known that it wouldn't... And FWIW I got 'in trouble' for doing a bug fix and an update within the same pull request... I won't do that again! :)

So once all this became apparent to me, I (sort of) swallowed my pride and reopened the initial bug. I think that while my 'fix' sort of worked it is really a middle ground that doesn't quite achieve any of the aims... So either we need to open it up and make it easy to auto update, or we need to lock it down and somehow make it easy to work around the lockdown... I like your thoughts and will wait in anticipation to see what you come up with... :)

James's picture

Hi,

I am new to linux and planning to deploy a Wordpress appliance soon for use as a personal blog. I am just looking for an update on the expected timing of the release of v13.1? If you are expecting to release it in the fairly near future I would prefer to wait and until then to deploy it, rather than doing it now and then updating.

Regarding the options that have been discussed around the security settings for the appliance. As someone who has very little experience with linux, I would prefer the appliance to be setup more securely to give me more confidence that my server is secure. A mechanism that allowed you to easily switch between less secure mode, for updating, and more secure mode for normal use, seems like it would be the ideal setup.

I appreciate all the time and effort that everyone involved in this project has put into it to make using these appliances straight forward for us less experience users.

 

Jeremy Davis's picture

Yes v13.1 is LONG overdue...! But unfortunately we still do not have an ETA on the maintenance release.

I would recommend that you push ahead and install now. FWIW migration is relatively painless (using TKLBAM) although I personally probably wouldn't bother doing that for a maintenance release (despite the planned improvements).

FWIW what improvements to implement is still not clear so your input is useful! :)

Also the links provided in this comment may be of value to you.

James's picture

Thanks for your reply Jeremy.

Jeremy Davis's picture

But having said that I agree that it is better to lock it down!

I would recommend that you have a look on the WordPress docs, particularly the File Permissions section on the Hardening WordPress page. There is also a page on changing permissions which might be handy. For reference, on a TurnKey appliance the user you normally log in as (at the commandline) is 'root' and the webserver user/group is www-data.

You will find plenty of other advice/suggestions on hardening WordPress on the WP doc page I link to above, plus also via google.

OnePressTech's picture

You can create an Apache webdav to mount /var/

http://httpd.apache.org/docs/2.2/mod/mod_dav.html

You will need to ensure SSL and /or other security strategies are in use.

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

I have been meaning to comment on this post, plus more importantly add it to the 'list of many ways to work with your TKL server' doc (aka "How to admin and/or edit/upload files to TKL appliances"). Finally got there...!

I do think though that the doc page needs a much catcher title! :)

OnePressTech's picture

Hi Frank,

See above discussion...the default TKLX WordPress configuration doesn't support WordPress auto-update. For security they have locked down the WordPress folder to have a user / group of no-one / nobody. For WordPress auto-update to work the owner and group need to be set to the web server owner / group which would be www-data / www-data.

You can run the following instructions at the Linux command line at the www directory level:

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

NOTE: Jeremy (above) recommends re-locking down the ownership of all but the wp-content folder. I recommend leaving this as www-data / www-data since WordPress has now mandated auto-updates of security releases which would not be applied if the web server does not have the ability to update WordPress files.

Cheers,

Tim (Managing Director - OnePressTech)

OnePressTech's picture

Hi Frank,

My apologies. I did read your post but somehow missed that you had already tried this. I'll claim a senior's moment :-)

I just did an AWS install of the v14 WordPress appliance, ran into this WordPress 4.4 upgrade problem, changed the owner to www-data:www-data from the Wordpress folder down including the WordPress folder, changed the folders to 755 and the files to 644....and the WordPress 4.4 upgrade went through without a problem.

Can you double-check the following:

- WordPress folder is set to www-data:www-data and not just its children

- Run the following commands at the www level to ensure consistent permissions

sudo find . -type f -exec chmod 644 {} \;

sudo find . -type d -exec chmod 755 {} \;

Cheers,

Tim (Managing Director - OnePressTech)

OnePressTech's picture

Glad you got it working Frank. I had noticed when I was looking through some of the files in the default WordPress VM that at least one of the folder settings was 2775 which I have never seen before. Something to look into at some point. But, for now, we have success :-)

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

We relaxed the permissions on what appeared to be the specific files a little in v14.0, but this issue still occurred. I then tried relaxing them a little more (for more specific locations) but the issue still returned.

So at this point I think that for v14.1 we need to just bite the bullet and do as you mention (chown & chmod /var/www/wordpress etc). The WordPress appliance is one of our most popular and these ongoing issues are frustrating for everyone...

PS Tim - I'd be interested in your thoughts on the changes we are looking at for v14.1 here.

Add new comment