landergate

Одно из софтовых решений, работающих на любом гипервизоре (включая VirtualBox и другие предложенные):
CPU Killer: www.cpukiller.com

Он создавался как раз для этих целей. =)

Можно создать отдельную таблицу для дат, добавляя туда эти даты в любом количестве по одной на строку, привязывая их к конкретному ID детали из первой таблицы.

Просто так от сообщения не избавится. Если страница в HTTPS - то и весь подгружаемый контент ожидается в HTTPS.

Можно построить свой прокси-ретранслятор с HTTPS, получая аудио поток через него, например на nginx.
Недостатки:

1. stream.site1.ru будет видеть все подключения ваших пользователей к аудио-потоку с IP вашего прокси.
   
2. Теоретически это может слегка увеличить время ожидания потока, но это один из единственных обходных путей за неимением доступа к stream.site1.ru.
   

Своя группа security-исследователей, ускоряющая внедрение патчей безопасности.

Можно ли закрыть от индексации robots?

Можно, это хорошая идея. Оставить только корень, а дубли индексировать запретить.

Или лучше все таки поставить редирект?

Для SEO значения не имеет. В обоих случаях дублирующие страницы пропадут из поиска.
Это может быть полезно для пользователей и их закладок, чтобы они перемещались с index.php и index на корень сайта, заходя по старым ссылкам вручную.

Только убедитесь, что сам сайт не использует index в качестве URL на важных операциях. Например MediaWiki по умолчанию строит все ссылки и операции от index.php. Если на нём будет стоять редирект, то любая операция будет скидывать пользователя в корень.
Гипотетически, впрочем, это ничего не сломает, ведь запрос всё-равно доедет до index, просто с другим URL.

Но у меня что то не получается поставить редирект с site.ru/index!

Это можно сделать средствами веб-сервера.

Например для nginx:

server {
    server_name yoursite.ru;

    .......................
    .......................

    location /index {
        return 301 https://yoursite.ru/;
    }
}

Для поисковика важно объявить код 301 (Moved Permanently), тогда он перестанет индексировать эти ссылки, считая, что они все навсегда переехали в корень.

Автоматизированных сервисов для этого нет.
Есть два ручных пути:

1. Найти себя в сети через поисковики по email. На тех сайтах, где ваш профиль расшарен вплоть до почты, вы себя найдёте.
   
2. Найти письма в своём ящике со словами "Registration", "Регистрация", "подтвержден*", "verification", и зайдите в профили найденных сервисов, чтобы поменять почту на другую.
   

Возможно в сети вашего предприятия есть проблемы с безопасностью (некомпетентность или ошибка при настройке прав доступа), из-за которой возможностью несанкционированного подключения к другим сотрудникам располагает не только IT-отдел.

Можно попробовать откладывать вот так:

* * * * * /var/www/somescript.sh
* * * * * ( sleep 30 ; /var/www/somescript.sh )

Пока база открыта, вы можете сделать File->Change Master Key...
Знать пароль не обязательно. =)

Яндекс.Почта предназначена только для общения между живыми людьми. Это их политика.
У неё есть суточные ограничения на отправку: https://yandex.com/support/mail/spam/sending-limits.xml
(они отличаются между Яндекс.Почтой и Яндекс.Почтой для домена).

А для рассылок предусмотрены специализирующиеся на этом сервисы:
https://mailgun.com/
https://sendgrid.com/
mailchimp.com
https://aws.amazon.com/ru/ses/
https://pechkin-mail.ru/
(и другие)

Все они сравнительно недорогие. У некоторых из них есть бесплатный порог, но обычно он в пределах 10 000 писем в месяц.

Можно сразу для людей его делать?

Можно. =)

Попробуйте добавить будущее доменное имя в C:\Windows\system32\drivers\etc\hosts, указав его на адрес, на котором сейчас происходит доработка (видимо, 127.0.0.1?), чтобы Вы могли сразу входить в Wordpress по этому домену ещё до миграции на хостинг.
Сменить домен в самом Wordpress можно в Settings->General, а там "Site Address (URL)" и "WordPress Address (URL)".

можно ли будет на время убрать его из базы поисковиков, чтобы они не могли его найти? Вдруг что-то допиливать прийдется.

Разместите в корне Вашего сайта файл robots.txt с таким содержанием:

User-agent: *
Disallow: /

Если сделать это сразу, то поисковики даже не начнут индексирование.
Когда будете готовы - robots.txt можно будет удалить, а лучше перенастроить его под те разделы сайта, которые вам нужно будет индексировать. В сети есть много примеров под WP.

социальные плагины

Они показывают и обрабатывают данные с соц.сетей, а не с Вашего сайта, так что не имеет значения, когда их подключать.

комментарии, лайки, голосования

Будут отображаться независимо от того, под каким доменом работает WordPress, так что не имеет значения, когда их подключать.

репосты в соц. сети

Если сайт сразу будет работать по URL планируемого домена, то отправленные в соц.сети репосты заранее будут ссылаться на правильный адрес.

защиту сацта

Akismet? Wordpress инициирует подключение к нему от себя, поэтому не имеет значения, откуда оно происходит. Лишь бы ключ к их сервису был актуальным.

HWiNFO (freeware)
www.hwinfo.com