mfidelman

Sure does sound like something intermittent on the server or network side. Maybe one server in the Jetpack server pool, or something funny in the load leveler? Sure would be a good idea for someone to pour through the logs.

Jeremy… The problem was repeatable, then it went away, with no changes on my end. And since, the problem manifested as a server-generated 400 (bad request) error, our systems were talking. Perhaps you can take a look at the server log for failed registration attempts from either 207.154.13.52 (the vhost) or 207.154.13.48 (the primary address of the box). Perhaps you can tell something from the log entry.

Well… I was about to upload a few more tests, but… this morning, everything seems to be working. I just registered.

I’m guessing there was something at the server end that was mis-behaving. Last nit, I installed a brand new copy of WP 3.5.1 and Jetpack 2.1.1 (both the latest) under Debian Lenny (oldstable). No other plug-ins except Akismet (no problem registering), and Debug Bar, with WP_DEBUG set to true.

Repeatedly, I got an error from wp-includes/class-http.php, line 921, indicating, not just
register_http_request_failed.
Could not open handle for fopen() to https://jetpack.wordpress.com/jetpack.register/1/
but also HTTP/1.1 400 Bad Request

I.e., my site was sending a transaction, the Jetpack server was receivign it, but it didn’t like the contents. So either, something was generating a bad transaction on my end, or something wasn’t behaving properly on the server. I’m guessing from this morning’s success that the problem was on the server.

So.. I guess this is resolved. Whatever you guys did on the server side – thanks!

Taking this public… results from compatibility test (which looks like everything is working).
TEST: Integer Tests
Array
(
[$value = “d0000000”;] => (string) d0000000
[$value = hexdec( $value );] => (double) 3489660928
[$value = abs( $value );] => (double) 3489660928
[$min = 0;] => (integer) 0
[$max = 61;] => (integer) 61
[4294967295 + 1] => (double) 4294967296
[$value / (4294967295 + 1)] => (double) 0.8125
[$max – $min + 1] => (integer) 62
[($max – $min + 1) * ($value / (4294967295 + 1))] => (double) 50.375
[$out = $min + (($max – $min + 1) * ($value / (4294967295 + 1)));] => (double) 50.375
[$out = intval( $out );] => (integer) 50
[$out = abs( $out );] => (integer) 50
)

TEST: wp_generate_password()
Array
(
[0] => 1 -> 1:V
[1] => 5 -> 5:8Krz7
[2] => 10 -> 10:W53o87yyPY
[3] => 16 -> 16:E2bn7UaMOaXgELav
[4] => 32 -> 32:vrhng8E1oVyyxzOyKgFEJJxwcSypoMVg
[5] => 32 -> 32:Jx4jFxNP9jNZlveNxkv6weqdRMow78jo
[random_password] => abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
[steps] => Array
(
[0] => 16 -> q
[1] => 16 -> q
[2] => 1 -> b
[3] => 0 -> a
[4] => 59 -> 7
[5] => 40 -> O
[6] => 35 -> J
[7] => 2 -> c
[8] => 24 -> y
[9] => 61 -> 9
[10] => 50 -> Y
[11] => 20 -> u
[12] => 1 -> b
[13] => 0 -> a
[14] => 46 -> U
[15] => 41 -> P
[16] => 20 -> u
[17] => 39 -> N
[18] => 39 -> N
[19] => 0 -> a
[20] => 5 -> f
[21] => 10 -> k
[22] => 44 -> S
[23] => 1 -> b
[24] => 9 -> j
[25] => 37 -> L
[26] => 31 -> F
[27] => 23 -> x
[28] => 10 -> k
[29] => 34 -> I
[30] => 15 -> p
[31] => 23 -> x
)

[ReflectionFunction] =>
/**
* Generates a random password drawn from the defined set of characters.
*
* @since 2.5
*
* @param int $length The length of password to generate
* @param bool $special_chars Whether to include standard special characters. Default true.
* @param bool $extra_special_chars Whether to include other special characters. Used when
* generating secret keys and salts. Default false.
* @return string The random password
**/
Function [ <user> function wp_generate_password ] {
@@ /var/notes/notes/wp-includes/pluggable.php 1485 – 1499

– Parameters [3] {
Parameter #0 [ <optional> $length = 12 ]
Parameter #1 [ <optional> $special_chars = true ]
Parameter #2 [ <optional> $extra_special_chars = false ]
}
}

)

TEST: wp_rand()
Array
(
[0] => ’90d0eecf1fa91468a3f5c67b39264f678db24b3cc7e9ca09e67ef043f5070492af194921fb73fabaf19570678360f19b’
[1] => 35:b91f06387607591fabaf37bf129491fa2940705f340fe76e90ac9e7cc3b42bd876f46293b76c5f3a86419af1
[2] => 7:b91f06387607591fabaf37bf129491fa2940705f340fe76e90ac9e7cc3b42bd876f46293b76c5f3a
[3] => 39:b91f06387607591fabaf37bf129491fa2940705f340fe76e90ac9e7cc3b42bd876f46293
[4] => 13:b91f06387607591fabaf37bf129491fa2940705f340fe76e90ac9e7cc3b42bd8
[5] => 34:b91f06387607591fabaf37bf129491fa2940705f340fe76e90ac9e7c
[6] => 48:b91f06387607591fabaf37bf129491fa2940705f340fe76e
[7] => 55:b91f06387607591fabaf37bf129491fa2940705f
[8] => 59:b91f06387607591fabaf37bf129491fa
[9] => 42:b91f06387607591fabaf37bf
[10] => 60:b91f06387607591f
[11] => 58:b91f0638
[12] => 31:
[13] => 33:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca13c18dcce755c22aea63907f82a6081060be1dd7d540851e
[14] => 54:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca13c18dcce755c22aea63907f82a6081060be1dd7
[15] => 30:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca13c18dcce755c22aea63907f82a60810
[16] => 0:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca13c18dcce755c22aea63907f
[17] => 59:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca13c18dcce755c22a
[18] => 39:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca13c18dcc
[19] => 49:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48db1202ca
[20] => 41:77e083dd0524fc33ea3183728a2caa6b38d6550cb4ae1d48
[MIN] => 0
[MAX] => 60
[ReflectionFunction] =>
/**
* Generates a random number
*
* @since 2.6.2
*
* @param int $min Lower limit for the generated number
* @param int $max Upper limit for the generated number
* @return int A random number between min and max
*/
Function [ <user> function wp_rand ] {
@@ /var/notes/notes/wp-includes/pluggable.php 1512 – 1546

– Parameters [2] {
Parameter #0 [ <optional> $min = 0 ]
Parameter #1 [ <optional> $max = 0 ]
}
}

)

TEST: HTTP Connection
Array
(
[headers] => Array
(
[server] => nginx
[date] => Wed, 30 Jan 2013 16:43:03 GMT
[content-type] => text/plain;charset=utf-8
[connection] => close
[vary] => Cookie
[x-pingback] => https://jetpack.wordpress.com/xmlrpc.php
[expires] => Wed, 11 Jan 1984 05:00:00 GMT
[cache-control] => no-cache, must-revalidate, max-age=60
[pragma] => no-cache
[x-hacker] => Jetpack Test
)

[body] => OK
[response] => Array
(
[code] => 200
[message] => OK
)

[cookies] => Array
(
)

[filename] =>
)

TEST: HTTPS Connection
Array
(
[headers] => Array
(
[server] => nginx
[date] => Wed, 30 Jan 2013 16:43:04 GMT
[content-type] => text/plain;charset=utf-8
[connection] => close
[vary] => Cookie
[x-pingback] => https://jetpack.wordpress.com/xmlrpc.php
[expires] => Wed, 11 Jan 1984 05:00:00 GMT
[cache-control] => no-cache, must-revalidate, max-age=60
[pragma] => no-cache
[x-hacker] => Jetpack Test
)

[body] => OK
[response] => Array
(
[code] => 200
[message] => OK
)

[cookies] => Array
(
)

[filename] =>
)

TEST: Self Connection
Array
(
[headers] => Array
(
[date] => Wed, 30 Jan 2013 16:43:04 GMT
[server] => Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 PHP/5.2.6-1+lenny13 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
[x-powered-by] => PHP/5.2.6-1+lenny13
[vary] => Accept-Encoding
[content-length] => 42
[connection] => close
[content-type] => text/plain
)

[body] => XML-RPC server accepts POST requests only.
[response] => Array
(
[code] => 200
[message] => OK
)

[cookies] => Array
(
)

[filename] =>
)

Jeremy, Thanks for the quick reply. Just sent the results. (FYI: Some of us have shell access to our servers – downloading plug-ins to the desktop, then uploading them seems like a silly step – the control panel really should have an “install from URL” and/or “install from local file” option. ??

Ok, did some googling, found a number of answers, but the simplest is to do something like:
/var/site1/wordpress/<docroot>
/wp-config.php
/var/site2/wordpress/<docroot>
/wp-config.php

Ah yes, the simple answers are best.

Ok, just found what I did, but still need an answer.

This particular machine has only a single wordpress site, with docroot at
/var/wp_site
and wp-config.php at
/var/wp-config.php (moved up a level after a hacker exploit a while back)

ok, now I want to add a new site, with docroot at
/var/2nd_wp_site
well… where do I put the 2nd wp_config.php, so it’s outside the tree, but wordpress still find it???

Likewise ??

Cheers!

Well, I guess I disagree with you. WordPress is essentially a web service – it lives “inside” a web server, rather than standing alone. As such, configuration of the environment is part of installation and should be documented.

Personally, I consider this a serious detractor from what is otherwise a very nice piece of software. Given that it’s free and open source, complaining without contributing puts me on shaky ground, but I consider it a reasonable piece of input to those who write documentation.

As examples of people who DON’T consider it apples and oranges, I’ll point to:

Mailman (list manager, depends on underling mail system, and on web server) – install documentation includes sections on:
– setting up your web server (including lines to add to Apache config files)
– setting up your mail server (with specific instructions for integration with Postfix, Exim, Sendmail, Qmail)
– setting up cron jobs

Sympa (another list manager, depends on database manager as well as the above) – install documentation includes sections on:
– prerequisites
— system requirements
— installing perl and CPAN modules
— creating a Unix user
— creating the database
– compilation and installation
– robot aliases (for mail)
– web setup, including
— alternatives (cgi, cgi+suexec, fcgi, dedicated server, notes for specific linux distributions)
— detailed instructions for installing the fastcgi version,
including a specific virtual hosts file
— specific instructions for setting up under nginx and lighttpd
– setting up log files (syslog configuration)
– note that the included install script (as well as the various packaged versions) does a lot of this (e.g., checks for and installs perl modules, startup/shutdown scripts, cron jobs)

Among CMS’s:
– MediaWiki has pretty detailed instructions, along with scripts that do a lot of the Apache setup
– Plone has very detailed Apache configuration documentation (a little out of date, and a separate article rather than part of the main documentation – still, it includes details of getting both virtual hosts running, and configuring SSL)
– Drupal has some information, but hard to find
– WordPress and Joomla have rather poor installation documentation by comparison

Sketchy documentation is understandable, and to a degree excusable. But defending it is another thing entirely.

Thanks! Looks very helpful.

Re. “no reason why it would be part of the WordPress installation documentation:”

– when installing software that runs under a web server, part of installation IS a matter of pre-requisites and server configuration

– I’ve installed an awful lot of packages that include both instructions on “how to configure under [apache|tomcat|….]” as well as, in many cases, files to drop into /etc/apache2/sites-enabled — and installers will typically drop files into various places under /etc — the WordPress “5-minute” install is pretty limited when compared to, say “apt-get install mysql”

Seems like a gap to me.

I’ve been hit by this too. Looks like about 5 days ago the machine at 95.65.31.32 started hitting my site,

first it tried to do a post to //rdbc9.php

a couple of days later it did a get on counter.php (which somehow got inserted into the top level of our wordpress site

at that point it started doing posts on /

a couple of days later, those posts translated into mail getting dropped into our outgoing postfix queue

somewhere in the middle, lots of files in wp-content/themes got changed to compromised code

currently have the site offline, backup up and checking content, getting ready to wipe and rebuild the site from scratch

Umm… HAVE upgraded (see initial post), still happening. I AM my hosting provider.

Doesn’t find anything. Whatever is doing this seems to be POSTING something to / , and it ends up passed to postfix/pickup. After turning off the site for a while, the attacker seems to have gone away. If it comes back, I’ve turned on Apache’s DumpIOInput module to capture the post data – but right now, I have no further insight into what’s going on, other than that there is a vulnerability of some sort.

Turns out I had to do a chown -R <web_server_owner>.<web_server_owner> on the entire directory tree where my site lives. Then things worked fine.

Note: I found this out by googling, and found the answer on a random blog posting. Really needs to be in the documentation.

Found the problem. Turns out that the options>misc. dialogue TELLS you that uploads default to wp-content/uploads, but unless you actually type that in the box and hit “save,” what gets saved into the database does not include wp-content/uploads in the URL.

Type it in the box, hit “save,” and everything works.

A real pain to track it down though – had to inspect a lot of uncommented code, and dig into the database.

Sigh….