andfarm

s/bank account/credit card/ is probably what patio11 meant. No idea how correct that is, but it's somewhat more plausible.

Unless your host is incredibly dumb and doesn't have suexec enabled [1], CGI scripts run as their owner [2].

[1] And, if they don't, you should run away. Fast.

[2] The actual rules are a little more complex than that, but that's what it comes down to.

Note that this is only true if your host is running PHP using mod_php or similar, and they don't have safe_mode configured properly.

And significantly worse voice synthesis than I've heard elsewhere. Most of Apple's Macintalk 3 voices (which are over 15 years old now!) sounded better than this.

"Any contact with the chamber floor will result in an unsatisfactory mark on your official testing record, followed by death."

If the domains are in the standard TLDs and are obviously typosquatting, you can go after them using the UDRP. It's not cheap (low end is $1300), but you can go after multiple domains at once if they're all owned by the same defendant.

Correct on both.

Sadly, while just selecting an id is faster than selecting the whole row, it's still a very slow operation overall. Here's the results on an 8-million-row production table:

   mysql> select * from large_table order by rand() limit 1;
   <...>
   1 row in set (36.69 sec)
   
   mysql> select primary_key_column from large_table order by rand() limit 1;
   <...>
   1 row in set (7.33 sec)

Basically, ORDER BY RAND() forces a temporary table / filesort no matter what; selecting fewer columns decreases the size of the temporary table, but doesn't actually eliminate the problem.

The best way to select a random row from a MySQL table is using a trick I got from Mediawiki: create an indexed float column, set it to RAND() for each row, and select random rows using:

   SELECT * FROM table WHERE randnum > RAND() ORDER BY randnum LIMIT 1

This runs as an index range scan, making it basically instantaneous.

It's still pretty experimental. Getting the kernel client into a released kernel has been a step forward, but Ceph isn't ready for production yet. It's getting closer, though.

I think you mean js/revisions-js.php. I'm pretty sure what dvortr() is supposed to do there... it is pretty suspicious-looking, though!

(1) Right -- and, even if it is possible to recover the password, walking a non-tech-savvy customer through the process may not be a palatable option, either for Support or for the customer.

(2) I wish I knew. Not really our place to ask, though.

One or both of:

- They've forgotten the password, but it's still in the keychain (or equivalent) for their mail or FTP client, which will all stop working when they reset the password.

- The password is shared with other employees, and it might be difficult to notify them all of the new password.

Along with the PHBs, we've also got a lot of plain old non-tech-savvy customers who just want to run their [personal blog / small business homepage / church web page / etc], and don't know, nor want to learn, too much about computers. Requiring them to use semi-strong passwords for FTP and email logins is enough of a challenge; requiring them to change those passwords every time they forget them is often a real hassle.

That was me. Let me know if you've got any questions.

From the reports I've seen, the CPU was entirely fake -- it was an inert chunk of molded metal.

Customer writes in, asks "I forgot my [FTP/mail/panel/etc] password, what is it?". Changing the password isn't necessarily an option, as the password may be saved in their FTP/mail client, or on their web designer's computer, or whatnot.

We do not store control panel passwords "in the clear". They are stored as a hash and in a reversibly encrypted form; access to the plaintext passwords is heavily logged. We are considering removing it entirely -- the only reason we currently store panel passwords in any reversible format is because we frequently get emails from users who have forgotten their panel password and want us to email it to them.

Correct. If having user service passwords stored in our database bothers you, log into a shell account and change the password with "passwd". We'll pick up the new password hash on our next user config and store the password internally as "changedbypasswd".

You can also view MySQL user passwords by clicking on the username in the panel (https://panel.dreamhost.com/index.cgi?tree=goodies.mysql). This shouldn't be a big deal, though, as you have to store the passwords in the clear in config files anyway.