3,250
edits
Changes
Jump to navigation
Jump to search
Line 11:
Line 11: − {{#smeversion: wordpress }} Line 25:
Line 24: + + + + + + + + + + + + Line 186:
Line 197: − + − − The following needs to be added the file /etc/fail2ban/jail.conf. − − <pre>[wordpress-hard] − enabled = true − filter = wordpress-hard − logpath = /var/log/messages − maxretry = 3 − action = smeserver-iptables[port="80,443",protocol=tcp,bantime=1800] − backend = polling − [wordpress-soft]+ − enabled = true+ − filter = wordpress-soft+ − logpath = /var/log/messages+ − action = smeserver-iptables[port="80,443",protocol=tcp,bantime=1800]+ − backend = polling</pre>+ + + + + + Line 237:
Line 243: + Line 242:
Line 249: − + Line 248:
Line 255: − +
→Version
{{#smeversion: smeserver-wordpress }}
{{#smeversion: smeserver-wordpress }}
===Description===
===Description===
yum install --enablerepo=smecontribs smeserver-wordpress
yum install --enablerepo=smecontribs smeserver-wordpress
====SME10====
The SME10 version has been recast to download the latest version of WordPress from the Wordpress website while installing on SME10, and does not need a support rpm containing the Wordpress php code.
Consequently the Wordpress site can be upgraded in place manually or automatically, rather than by an RPM update. There is no need for any further signal-event as the install itself makes sure that all files etc are up to date.
If you remove the smeserver-wordpress rpm, then the current parameter file and wordpress code will be deleted, but the corresponding database will not be deleted. If you want to delete it then you should use the phpmyadmin contrib.
If you re-install after a remove, without deleting the database then the old website will be re-instated, and the version of Wordpress installed will be the latest. However you will loose any templates and plugins that you might have installed on top of the standard install. These can be re-installed of course.
====SME9====
If installation shows a blank page, then refer the fix at https://bugs.contribs.org/show_bug.cgi?id=10735#c10.
If installation shows a blank page, then refer the fix at https://bugs.contribs.org/show_bug.cgi?id=10735#c10.
==== Fail2Ban ====
==== Fail2Ban ====
Fail2Ban is a contrib that blocks IP addresses involved in brute force logon attempts and such. See [[Fail2ban]]. In order to make Fail2Ban work with WordPress, the user "holck" posted the following code in thread https://forums.contribs.org/index.php/topic,53711.msg279902.html in the SME 9 Contribs forum. Holck notes that the standard jail for WordPress appears to work, but does not block the offending IP addresses.
Fail2Ban is a contrib that blocks IP addresses involved in brute force logon attempts and such. First you need to add the fail2ban plugin inside wordpress. Then see [[Fail2ban]] wiki page for initial setup of fail2ban. Then you simply need to enable the jail for wordpress by using the server-manager fail2ban page. Basically there will be 3 jails for wordpress, one soft (auth error) and one hard ( blocked user attempt to login) and one for xmlrpc attacks. Refer [https://forums.contribs.org/index.php/topic,53711.msg279902.html original post]
If you want more tweak you can change few options using command line. Note that by defualt they are not set in the db and will use fail2ban respective default value, which you could also set globally. Values presented are only for the purpose of example. WPH prefix is for wordpress-hard, WPS for wordpress-soft and WPX for wordpress-xmlrpc
* db configuration setprop fail2ban WPHbantime 5000
* db configuration setprop fail2ban WPSbantime 1000
* db configuration setprop fail2ban WPXbantime 10000
* db configuration setprop fail2ban WPHfindtime 800
* db configuration setprop fail2ban WPSfindtime 800
* db configuration setprop fail2ban WPXfindtime 800
* db configuration setprop fail2ban WPHmaxretry 1
* db configuration setprop fail2ban WPSmaxretry 3
* db configuration setprop fail2ban WPXmaxretry 2
then you will need a signal-event fail2ban-update
===Backup of Wordpress===
===Backup of Wordpress===
rm -rf /usr/share/wordpress
rm -rf /usr/share/wordpress
config delete wordpress
config delete wordpress
db accounts delete wordpress
signal-event console-save
signal-event console-save
These instructions assume you have installed this contrib as described on this page and that you understand how to use Wordpress. If you have done anything else these instructions are not for you.
These instructions assume you have installed this contrib as described on this page and that you understand how to use Wordpress. If you have done anything else these instructions are not for you.
The Wordpress files are installed to /usr/share/wordpress by the wordpress contrib. The main configuration file wp-config.php in this location is a symlink to /etc/wordpress/wp-config.php. The template for the wp-config.php file is located at /etc/e-smith/templates/etc/wordpress/wp-config.php and creates the /etc/wordpress/wp-config.php file. After completing these steps, you will not be able to use the wordpress events or information in the configuration database to regenerate your site's wp-config.php file. You will have to manually modify the wp-config.php file to suit your needs.
The Wordpress files are installed to <tt>/usr/share/wordpress</tt> by the wordpress contrib. The main configuration file '''wp-config.php''' in this location is a symlink to <tt>/etc/wordpress/wp-config.php</tt>. The template for the ''wp-config.php'' file is located at <tt>/etc/e-smith/templates/etc/wordpress/wp-config.php</tt> and creates the /etc/wordpress/wp-config.php file. After completing these steps, you will not be able to use the wordpress events or information in the configuration database to regenerate your site's wp-config.php file. You will have to manually modify the ''wp-config.php'' file to suit your needs.
Follow the steps at [[Wordpress_Multisite|Wordpress Multisite]] with the exception of steps A4, A5, and A7.
Follow the steps at [[Wordpress_Multisite|Wordpress Multisite]] with the exception of steps A4, A5, and A7.
A4 step: If you are moving an existing install, the database and user already exist. Backup the Wordpress database using phpmyadmin ([[PHPMyAdmin]]) and get the database user and password from /etc/wordpress/wp-config.php.
A4 step: If you are moving an existing install, the database and user already exist. Backup the Wordpress database using phpmyadmin ([[PHPMyAdmin]]) and get the database user and password from /etc/wordpress/wp-config.php.
A5 step: You are going to be using an existing installation so use midnight commander (mc at the terminal) to copy the files from /usr/share/wordpress/ to the ibay directory. Once copied, navigate to the ibay directory and delete the symlink for wp-config.php. Copy wp-config.php from /etc/wordpress to the ibay directory. You should now have all of the wordpress base, config file, plugins, and content located in the new ibay you created.
A5 step: You are going to be using an existing installation so use midnight commander (mc at the terminal) to copy the files from <tt>/usr/share/wordpress/</tt> to the ibay directory. Once copied, navigate to the ibay directory and delete the symlink for wp-config.php. Copy wp-config.php from /etc/wordpress to the ibay directory. You should now have all of the wordpress base, config file, plugins, and content located in the new ibay you created.
Edit the wp-config.php file and find the line that references the definition of ABSPATH. Edit the directory to match your ibay location. The default entry created by the contrib is:
Edit the wp-config.php file and find the line that references the definition of ABSPATH. Edit the directory to match your ibay location. The default entry created by the contrib is: