Максим Гришин

Возможно, memcached на VDS наружу торчит, и кто-то устроил из вашего VDS memcached-амплификатор. Таки проверьте, не торчит ли чего лишнего наружу, а если торчит, перекрывайте хотя бы файрволлом.

Таки нельзя. Proxmox при изменении настроек USB-проброса требует остановки процесса обработчика ВМ для перечитывания маппингов, как следствие, ВМ нужно не просто перезагрузить, а выключить и потом включить. Впрочем, можно пробросить в машину порт USB вместо конкретного устройства, тогда подключение-отключение устройства в этом порту USB будет добираться до гостевой ОС, и она уже будет обрабатывать событие так, как если бы этот порт был её собственным. https://pve.proxmox.com/wiki/USB_Devices_in_Virtua... тут есть инструкция как забросить порт в ВМ.

0. Настроить на свитче promiscuous port, воткнуть его в сетевой адаптер компа, запустить wireshark, слушать на этом порту.
1. Запустить камеру, проверить, что вообще поднялся впн.
2. Оторвать аплинк от свитча (лишив камеру доступа в интернет), перезагрузить камеру, выждать 10 минут, подключить аплинк обратно, выждать ещё 10 минут, проверить статус VPN на камере.

А как GRUB достанет данные с веб-сервера, когда у него нет ещё сетевой карты, настроек DNS и обработчика HTTPS handshake? TFTP-сервер ещё вариант, в этом случае вам потребуется отдавать образ, который будет тянуть ядро и образ файловой системы с него, читать про реализацию PXE (она, кстати, нативная на сетевой карте, так что это немного не GRUB). А вообще GRUB как таковой не умеет работать с не-локальными источниками данных. То есть никак.

А разве вам в php-скрипте неизвестен конкретный логин, или это некий отдельный скрипт рассылки? Если рассылка, то правильно именно отправлять по одному письму за раз, каждое оформляя под конкретного $username.

Не "кешировать", а "хэшировать", причем с солью. Могло бы иметь смысл, если бы это хэширование применялось поверх незащищенного канала. Отправка необработанных данных (пароля текстом) по SSL/TLS не даст возможности перехватить и расшифровать трафик (за разумное время) сидящему на канале передачи данных, поэтому можно не заморачиваться на защиту именно передаваемого текста на уровне L7, если на L4 соединение защищено сильной криптографией.

Запросто. Тут на хабре попадалось устройство "USB killer", реально выжигающее порты и электронику внутри (при большой неудаче - до процессора достать может ИМХО) высоковольтными разрядами по шине данных. И таки да, особо одаренные сервисмэны могут такой и поприменять. Нужно (было?) логировать, в каком состоянии ушел системник, что в нем было исправно, т.е. если тот порт, на который указал их спец, был исправен на момент сдачи в ремонт, имеет место деструктивное воздействие в СЦ, и за это их можно попробовать нагнуть. Иначе по обстановке.

ИМХО просто пять вольт на шину данных USB-порт не сожгут, тем более процессор, но выключить хаб такой пробой может.

Отказаться. Мало ли какого генеза эти пятна, может, расползаться будут. Тем более ноут б/у.

1) Нельзя. VMware умеет один диск назначить только одной ВМ. Golden Image - это всего лишь шаблон ВМ с установленными обновлениями, ПО и последующей очисткой временных файлов, из которого клонируются ВМ для нормальной работы (VDI как вариант, там ВМ временная и удаляется после завершения работы с ней пользователя). Возможно, удастся сэкономить место на хранилище, если включить на нем дедупликацию для дисков с операционной системой, но это не гарантировано, плюс будут проблемы по производительности в случае обновления ВМ без дополнительного диска avhd (т.е. без снапшота) - в этом случае постоянно будут кластеры, которые будут выходить из дедуплицированного состояния, и место на хранилище начнет заполняться, на это в общем случае хранилище будет реагировать медленнее, чем в ситуации без дедупликации.
2) Thin provision диски будут расти как обычно, thick provision не потеряют в производительности, но они сразу занимают максимальный размер, ещё при создании.
3) Неприменимо. Если разговор о Golden Image, он обновляется как обычная отдельная ВМ с последующим экспортом обратно в шаблон.
4) Неприменимо - придется сравнивать диски от разных ВМ, а у них первичный образ диска будет не один. То есть будет доступна только конфигурация с 10 отдельными дисками.
5) Туда же.

Данные по VMware ESXi 6.0 и моему опыту работы с ним. Если 6.5 что-то изменил, буду рад узнать.

Здесь нарушен принцип L из SOLID-списка, функции hunt() должны принимать Animal на вход, и обрабатывать любой Animal (своим образом, но любой). А так, для объединения не связанных между собой классов правильно использовать интерфейсы - если оно требуется, т.е. нужно сделать типа var hunters:array of Hunter. (PHP вроде бы интерфейсы не умеет - тогда проверяйте через if ($animal is Wolf){...}) А если не нужно - реализуйте независимые пары классов.

Передавать - почтой, наиболее проработанный вариант ИМХО, и один из самых доступных для организации. Хранить общие пароли - где-то в базе с доступом по персональным кредам. Идеально, наверное, не делать общих паролей вообще, но обычно требуется, чтобы УЗ в какой-либо службе жила дольше любой персональной УЗ (вроде, скажем, УЗ администратора почтовой системы в Интернете, или админ-доступ на веб-хостинг), значит, где-то надо их хранить.

Мессенджеры как средство передачи паролей - технически вариант, если полностью подконтрольны, или в наличии end-to-end шифрование. Остальное - однажды утечет, и хорошо если утечет позже истечения срока действия.

PS: те, кто постят пароли на публичных сайтах, где гость или робот их может прочесть - ССЗБ.

Вообще, это частный случай задачи о рюкзаке, и одним запросом SQL заведомо не решается.

Скопируй архив на C: вначале, потом открывай. По поводу "заражения" - проверь носитель, где сейчас лежит архив, особенно если это другой компьютер, запросто может быть, что на нем вирус.

Zabbix для работы запускает процессы на системе, а "стандартный хостинг" - это веб-хостинг, т.е. не предусматривает установку в систему стороннего кода. То есть нет, нельзя поставить заббикс. Но можно поставить только веб-консоль от заббикса, если сам сервер будет с него доступен, при конфигурации подключения к серверу заббикса изменяются только файлы данных и PHP-кода, которые веб-хостеры позволяют устанавливать.

Поднимаете именованный инстанс с таким же именем, как у старого сервера, на Server02, переносите базу туда, переименовываете сервер в Server01. Иначе только править конфиги клиентов.

Кто-то взломал чей-то веб-хостинг и через него брутит вашу сеть. Стандартная (теперь) ситуация. Настройте блокировку атакующих узлов по таким логам, и будет вам (временное) щщастье.

Эти два - поровну с точки зрения отказоустойчивости, если считать экстремумы, но 0+1 хуже с точки зрения её восстановления. Если в RAID10 вылетит диск, то при ребилде высокая нагрузка будет только на одном диске - его паре, а в RAID0+1 нагрузка ляжет на все диски сразу. А при работе на конфигурации, потерявшей отказоустойчивость, в RAID0+1 задействована только половина дисков, поэтому следующий вылет любого диска под нагрузкой положит вам рейд. У RAID10 задействованными остаются все диски, которые в строю, при этом нагрузка на них не изменяется от того, что один диск в какой-то паре помер. Поэтому RAID0+1 хуже, чем RAID10.

Вообще с точки зрения отказоустойчивости лучше JBOD с erasure coding N+X, где Х можно задавать в довольно широких пределах, но это уже не чистый RAID.