WordPress.org

1. Denis de Bernardy
   Member
   Posted 3 years ago #
   

   Westi and I are into the new core plugin, Health Check. We're seeking additional test ideas.

   The current set of tests are the following:

   http://plugins.trac.wordpress.org/browser/health-check/branches/alpha/hc-tests/php-configuration.php

   I've a few database tests planned, and Peter has a few more on his todo list:

   http://plugins.trac.wordpress.org/browser/health-check/branches/alpha/hc-tests/writing-tests.txt

   If you've a grudge against additional php parameters, or if you're aware of topics that are related to server niggles and that could qualify as test worthy, please speak out.

   PS: someone please make this thread sticky for a couple of days.

2. Denis de Bernardy
   Member
   Posted 3 years ago #
   

   adding IRC suggestions here for reference:

   - cj: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers

   - beaulebens: better to use core PHP JSON stuff, but WP has compat to deal with it

3. cjcollier
   Member
   Posted 3 years ago #
   

   X-FORWARDED-FOR: '<? echo $_SERVER['HTTP_X_FORWARDED_FOR']; ?>'

4. Denis de Bernardy
   Member
   Posted 3 years ago #
   

   idea from aaron:

   "can a user get a list of what IS on their server (PHP version/installed modues/settings, MySQL version, etc) and copy/paste to send it to someone? (or even just enter an E-Mail address and click send)"

5. Denis de Bernardy
   Member
   Posted 3 years ago #
   

   of interest on the x-forwarded-for thingy:

   http://core.trac.wordpress.org/ticket/9235

6. idealien
   Member
   Posted 3 years ago #
   

   I have run into a number of issues related to permissions on folders. It's mostly related to plugins and 775 / 777 on wp-content/uploads and the ability to create files and sub-folders within. More recently since switching to a Plesk based VPS environment.

   If there is anything about the user / method that creates the directories / permissions for them that can be shown?

7. Aaron D. Campbell
   Member
   Posted 3 years ago #
   

   Denis: Thanks for posting that for me. It would be useful for plugins that end up requiring a higher PHP or MySQL version than the health check plugin recommends, as well as for plugins that need something like GD or ImageMagick, etc. I could simply have the user install health check and post the output in the support forums, etc.

8. Peter Westwood
   WordPress Lead Developer
   Posted 3 years ago #
   

   Listing everything that is/isn't available / installed isn't really the point of the health-check plugin.

   I would rather keep the plugin focused on checking the configuration and health of the install for now.

9. Aaron D. Campbell
   Member
   Posted 3 years ago #
   

   It might make more sense in a separate plugin, but it would definitely be something nice to have.

10. Robert Chapin
    Member
    Posted 3 years ago #
    

    Here's what comes to mind first.

    PHP Health

    Check the GD library.

    Check for the Suhosin extension. (This can screw up all sorts of things)

    Send test e-mails and catch errors.

    WordPress Health

    CRC all core files to find malware.

    Scan .htaccess for cloaked redirects.

    Scan posts table for obfuscated script injections.

    Scan term_relationships for orphaned objects.

11. Andrea Rennick
    Customer Care at Copyblogger Media and Studiopress
    Posted 3 years ago #
    

    I know you said you didn't want to check for *everything* but mod_rewrite should be there.

    Pretty permalinks won't work without it, and if someone in 3.0 goes to add more blogs using the subfolder format, they won't work either.

12. Peter Westwood
    WordPress Lead Developer
    Posted 3 years ago #
    

    Check the GD library.
    Check for the Suhosin extension. (This can screw up all sorts of things)
    Send test e-mails and catch errors.

    These sound good. It would nice to be able to detect specific configurations of Suhosin which cause issues if that is possible as it can easily be configured in a compatible way (much like mod_security can)

    CRC all core files to find malware.
    Scan .htaccess for cloaked redirects.
    Scan posts table for obfuscated script injections.
    Scan term_relationships for orphaned objects.

    The first three sound like things that the Exploit Scanner plugin should do more than the Health Check plugin.

    Is the fourth one a common issue - what is the cause and the consequence?

13. Peter Westwood
    WordPress Lead Developer
    Posted 3 years ago #
    

    I know you said you didn't want to check for *everything* but mod_rewrite should be there.

    I believe Denis has added that already :-)

14. Robert Chapin
    Member
    Posted 3 years ago #
    

    These sound good. It would nice to be able to detect specific configurations of Suhosin which cause issues if that is possible as it can easily be configured in a compatible way (much like mod_security can)

    I had a lot of experience with this at the XMB project. More than 50% of the time, the webmaster is not able to configure Suhosin because that option has been disabled at the server level. From a development perspective, the configurations that will conflict with the application are almost impossible to predict. In other words, if suhosin.post.max_vars is set to 50, how do you predict the location or magnitude of any conflict in WordPress? Given the nature of the extension, we decided diagnosing it was counterproductive, and instructed webmasters to have Suhosin uninstalled if they wanted tech support for server errors.

    Is the fourth one a common issue - what is the cause and the consequence?

    Yes I believe WordPress fails to delete relationships for custom taxonomies before version 2.9. Consequently, there could be a lot of garbage floating around in that table. Not sure if the upgrader actually checks for that?

15. Robert Chapin
    Member
    Posted 3 years ago #
    

    see also http://core.trac.wordpress.org/ticket/10821

16. Denis de Bernardy
    Member
    Posted 3 years ago #
    

    GD, JSON, mod_rewrite, IP address - done

    I also added a check that suggests using the latest and greatest for each of Apache, PHP and MySQL.
    http://plugins.trac.wordpress.org/browser/health-check/branches/alpha/hc-tests/

    For the email check, it seems like a good idea, but who do we send it to? The user himself? If we rely on mail()'s return value, I suspect the test won't be as reliable as it should be.

    @aaron and westi: I like the idea of adding a checkbox near the run tests button, as in "send me the results by email". it's simple enough to implement, not intrusive at all, and it could be useful when delivering support.

    @Idealien: there is, yes. I added a check for safe_mode and another for open_basedir. When either or both are raised, it frequently means you can't create folders.

    @miqrogroove: if you've a potential patch to check for the stuff from Suhosin that causes problems, please send it by email.

    re the lost terms, I think it should be fixed in WP directly. in the upgrader for instance.

17. Robert Chapin
    Member
    Posted 3 years ago #
    

    if (extension_loaded('suhosin')) echo 'u fail it';

18. Denis de Bernardy
    Member
    Posted 3 years ago #
    

    @miqrogroove: That's a bit too harsh imo. I've been using the extension for years without a hiccup. We'd be much better off nailing down which aspects of suhosin cause problems, and raise the appropriate notices.

    (The same would apply to mod_security, but I'm not aware of any means to detect the latter's settings from PHP.)

19. TobiasBg
    Member
    Posted 3 years ago #
    

    Hi,

    Suhosin installed sometimes is an issue for users of my plugin WP-Table Reloaded.
    I have a lot of textareas on one screen (basically cells of a table), which are named as a two-dimensional array ( $table[$row][$column] basically).
    Obviously, for a larger number of cells, some limit seems to be reached in Suhosin, so that all cells above the limit are simply thrown away.

    Related threads are, e.g.
    http://wordpress.org/support/topic/306452?replies=6
    http://wordpress.org/support/topic/289836?replies=9

    So, some sort of Suhosin recognition/advice would be really cool in the Health Check plugin.

    Thanks
    Tobias

20. Robert Chapin
    Member
    Posted 3 years ago #
    

    We'd be much better off nailing down which aspects of suhosin cause problems

    Go for it. I think it's a lost cause. The unfortunate reality is that Suhosin is designed to run in debug mode; a fact most hostmasters ignore during RTFM. It is designed to break PHP applications, with tweak-out exceptions made per install.

    Amusing change log entry:

    2009.08.15: Version 0.9.29
    Increased default length and count limit for POST variables (for people not reading docu)

21. Denis de Bernardy
    Member
    Posted 3 years ago #
    

    k... there's a neat list over here:

    http://www.hardened-php.net/suhosin/configuration.html

    In my case the only ones that are set, are the suhosin.log.* variables. Their value is empty in each case. I can easily picture stuff like suhosin.get.* or suhosin.post.* causing trouble. That would seem a lot more targeted...

22. Denis de Bernardy
    Member
    Posted 3 years ago #
    

    suhosin tests added. mod_rewrite tests improved.

    email is still on the todo list, pending ideas on how to test it without sending emails all over the place.

    filosofo is looking into adding cron tests.

23. @mercime
    Volunteer Moderator
    Posted 3 years ago #
    

    Not sure if this is within the scope since most checks I read were re webserver checks. But might I also suggest some user level checks which can break a new or existing installation and make it "sick" and "feverish"

    1) Check on "health" of WP installs set up the "easy way" via Fantastico or other scipts
    - When some of these installs use the auto-upgrade from dashboard "reminder", more often than not, you'll find them in this forum complaining about "buggy" new WordPress version and incomplete upgrades, etc etc etc. What can go wrong when they enable the multisite feature in WP 3.0? Maybe a lot :-)

    2) Check if all WordPress files and folders have been uploaded
    - so basic yet many times I've seen some new installation problems or upgrading problems resolved in this forum as well as in MU forums when users follow volunteer instructions to reupload WP/WPMU files and folders.
    - e.g. Gallery2 installation had this step where the admin was given a checklist whether G2 files were missing or folder/s CHMOD incorrectly. Since WP prides itself in 5-minute installs, perhaps an outside script? I don't know, you're the devs :-)

    Just my 2cents. Thank you for the Health plugin.

24. hakre
    Member
    Posted 3 years ago #
    

    suhosin: I would test for it and suggest to use it. But not to say that it's a must, only that there is a check for it. It's not an aim of the plugin or this thread to value that a certain component is a must imho.

    file system access: Direct access is best for wordpress, so I would do a check if that works (the PHP-scripts owner is the same user executing the file in the HTTPD/FCGI environment. Next to this the PHP-scripts owner must be the user that is actually transfereing files to the server wether be it via FTP or preferable SFTP.).

    other tests: I've compiled a wordpress technical installation checklist you can go through and consider the one or other thing to test for.

25. Robert Chapin
    Member
    Posted 3 years ago #
    

    It would be smart to check if the PHP error log file is exposed in either the root or wp-admin locations, since WordPress doesn't supply the "Deny from all" configuration.

    It's also a good idea to have script execution disabled for the uploads directory, although that might go over the head of most webmasters.

26. hakre
    Member
    Posted 3 years ago #
    

    Good hint with the uploads directory, some of the exploits are using that directory for their payload scripts.

27. Denis de Bernardy
    Member
    Posted 3 years ago #
    

    I'm not 100% how to test that, though. Patch welcome. ;-)

    D.

28. Robert Chapin
    Member
    Posted 3 years ago #
    

    Here's one that came across my desk today:

    Make sure mysql.connect_timeout is less than 30. PHP installs with a default of 60, which is hugely stupid.

Topic Closed

This topic has been closed to new replies.