Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Wordpress plugins on buster

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
chance2105
Posts: 113
Joined: 2007-04-25 03:21
Location: Oklahoma, USA

Wordpress plugins on buster

#1 Post by chance2105 »

I've recently been tinkering with Wordpress on Buster. Performed the install, everything went smoothly, until I tried to update plugins.

It seems that Debian's setup has permissions by default such that Wordpress can't modify any of it's own directory structure (a good thing), but if you want to update plugins and themes, you need to manually copy where they belong in wp-content (vs having them linked to the associated debian package versions) and update their permissions to be editable.

So far so good.

The problem is, the only way it seems you can update those plugins is if you configure Wordpress to update the files on the local filesystem. I'm trying to stay away from that, where everything that Wordpress needs is read-only, and updating everything through FTPS instead.

So, in attempt to get that up and working, I:
- configured vsftpd, with a new user
- updated permissions on everything under wp-content to give access to a new user for ftps, while leaving everything read-only for wordpress

Wordpress can't seem to find the plugin or themes directories this way.

With vsftpd verbose logging, you can see where Wordpress is able to login to vsftpd with the correct configured user; it enumerates each directory, changes into it, then backs out doing nothing.

When I log into that ftp account using the user I configured, I have correct permissions to descend into, write new files, in these directories with no issue at all.

So, just curious if anyone has managed to get the automatic plugin update to work in Wordpress.

kedaha
Posts: 3521
Joined: 2008-05-24 12:26
Has thanked: 33 times
Been thanked: 77 times

Re: Wordpress plugins on buster

#2 Post by kedaha »

chance2105 wrote:I've recently been tinkering with Wordpress on Buster. Performed the install, everything went smoothly, until I tried to update plugins.
I've also been tinkering with Wordpress, but in testing, but it's much the same. There are only a few default themes and a couple of plugins, namely wordpress-shibboleth and wordpress-xrds-simple, which are, of course, updated from the official repository by using apt.
chance2105 wrote:It seems that Debian's setup has permissions by default such that Wordpress can't modify any of it's own directory structure (a good thing)[ ...]
Absolutely. In my wordpress installation I have disabled all update notifications emanating from upstream.
chance2105 wrote: [... ],but if you want to update plugins and themes, you need to manually copy where they belong in wp-content (vs having them linked to the associated debian package versions) and update their permissions to be editable.
Manually installing and updating upstream themes and plugins is too laborious.
chance2105 wrote:The problem is, the only way it seems you can update those plugins is if you configure Wordpress to update the files on the local filesystem. I'm trying to stay away from that, where everything that Wordpress needs is read-only, and updating everything through FTPS instead.
Yes, that is the right approach.
The easy way to do this, to quote the README:

Code: Select all

$ zcat /usr/share/doc/wordpress/README.Debian.gz
If despite all this, you can't get the plugin upgrade feature to work, you
can try to add the following parameter to your configuration file:

Code: Select all

define( 'FS_METHOD', 'direct' );
But I was not satisfied with using the above parameter.
chance2105 wrote:So, in attempt to get that up and working, I:
- configured vsftpd, with a new user
- updated permissions on everything under wp-content to give access to a new user for ftps, while leaving everything read-only for wordpress

Wordpress can't seem to find the plugin or themes directories this way.
You have, I think, got everything right except perhaps a file permission or two.
chance2105 wrote:So, just curious if anyone has managed to get the automatic plugin update to work in Wordpress.
Yes, I have, I have got it working in the way you describe in a testing installation. The file permissions will be exactly the same for Buster. I notice that the themes and plugins from wordpress now work automatically, without having to enter the ftp user credentials on the wordpress site. However, in a multisite configuration, I think it advisable to disable that so that only the administrator could install additional themes and plugins.

Code: Select all

$ cd /var/lib/wordpress/wp-content/ && ls -l
total 32
-rw-r--r-- 1 www-data www-data    28 Jan  8  2012 index.php
drwxr-xr-x 5 www-data www-data 12288 May  9 12:48 languages
drwxr-xr-x 4 www-data www-data  4096 May 11 00:55 plugins
drwxr-xr-x 4 www-data www-data  4096 Jun  4 00:10 themes
drwxr-xr-x 2 www-data www-data  4096 May 12 15:50 upgrade
drwxr-xr-x 3 www-data www-data  4096 May  9 21:14 uploads
I set the file permissions for wp-content as follows:

Code: Select all

$ cd /var/lib/wordpress && ls -l
total 4
drwxr-xr-x 7 www-data www-data 4096 Jun  4 00:10 wp-content
For reference: cat /etc/vsftpd.conf
(substituting "example.tld" for the actual domain).

Code: Select all

# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
#
# Run standalone?  vsftpd can run either from an inetd or as a standalone
# daemon started from an initscript.
listen=NO
#
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
listen_ipv6=YES
#
# Allow anonymous FTP? (Disabled by default).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# If enabled, vsftpd will display directory listings with the time
# in  your  local  time  zone.  The default is to display GMT. The
# times returned by the MDTM FTP command are also affected by this
# option.
use_localtime=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
#xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
# You may restrict local users to their home directories.  See the FAQ for
# the possible risks in this before using chroot_local_user or
# chroot_list_enable below.
#user_sub_token=$USER
#local_root=/home/$USER/ftp
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
#chroot_local_user=YES
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd.chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# Customization
#
# Some of vsftpd's settings don't fit the filesystem layout by
# default.
#
# This option should be the name of a directory which is empty.  Also, the
# directory should not be writable by the ftp user. This directory is used
# as a secure chroot() jail at times vsftpd does not require filesystem
# access.
#@secure_chroot_dir=/var/run/vsftpd/empty
#
# This string is the name of the PAM service vsftpd will use.
pam_service_name=vsftpd
#
# This option specifies the location of the RSA certificate to use for SSL
# encrypted connections.
#rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
# This option specifies the location of the RSA certificate to use for SSL
# encrypted connections.
rsa_cert_file=/etc/letsencrypt/live/example.tld/fullchain.pem
rsa_private_key_file=/etc/letsencrypt/live/example.tld/privkey.pem
ssl_enable=YES
allow_anon_ssl=NO
# Options to force all communications over SSL - why would you want to
# allow clear these days? Comment them out if you don't want to force
# SSL though
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

require_ssl_reuse=NO
ssl_ciphers=HIGH
pasv_min_port=40000

pasv_max_port=41000
userlist_enable=YES
userlist_file=/etc/vsftpd.userlist
userlist_deny=NO
#
# Uncomment this to indicate that vsftpd use a utf8 filesystem.
#utf8_filesystem=YES
DebianStable

Code: Select all

$ vrms

No non-free or contrib packages installed on debian!  rms would be proud.

User avatar
JudgeDredd
Posts: 11
Joined: 2020-09-20 06:33

Re: Wordpress plugins on buster

#3 Post by JudgeDredd »

Can I please hop in, a kind of desperate semi-beginner here. My at-home-hosted Debian Bullseye Wordpress site simply won't show any images no matter what I do. On dashboard, site health screen says it's all fine, permissions are OK, everything is writable... but no images visible in media, posts, themes, on site, nowhere. Sqared 'places' are there, but no image content. How come? Screenshots:

https://postimg.cc/BX2rzYTR

https://postimg.cc/gw5w72dz

Please help. Thanks.

arochester
Emeritus
Emeritus
Posts: 2435
Joined: 2010-12-07 19:55
Has thanked: 14 times
Been thanked: 54 times

Re: Wordpress plugins on buster

#4 Post by arochester »

Please don't just "hop in" here. Don't just stick your problem on the end of somebody else's thread - you should start your own thread. Preferably with a "Subject" which is more descriptive of your problem

User avatar
JudgeDredd
Posts: 11
Joined: 2020-09-20 06:33

Re: Wordpress plugins on buster

#5 Post by JudgeDredd »

I'm sorry, I thought it's similar theme (I even used some advice previously posted here). OK I'll start new topic.

chance2105
Posts: 113
Joined: 2007-04-25 03:21
Location: Oklahoma, USA

Re: Wordpress plugins on buster

#6 Post by chance2105 »

After much consternation and looking into other blogging options, the solution I settled on is the following:

- Use Debian's packaged version of Wordpress and plugin (including Akismet);
- Use minimal plugins. Right now that only includes a theme that I purchased.
- Update to Bullseye

This has been a godsend. Wordpress + Akismet appear to be supported by security support, so I don't have to worry about that at all. The only thing I have to worry about is the theme.

It has made for a rather sublime experience with Wordpress. I wish I had just accepted this from the get-go.

I never sorted out what was wrong with the permissions, and in fact, I don't think there was any problem at all from a Unix permissions standpoint. I could login with the FTPS user and update plugins manually, just not through the Wordpress admin interface using FTPS. I completely gave up on that.

Options I tried before settling on this:
- Using Debian but installing Wordpress from scratch
- Several different static site generators

You're going to be updating the operating system anyway, why worry about the constant plugin churn you get with a manual Wordpress install? This seems to really be the best way to use Wordpress. The plugin churn goes away. Just minimize your use of plugins, and use Debian's security updates.

Post Reply