Перейти к содержанию
Форум русской поддержки продукции Synology

hafis

Пользователи
  • Активность

    180
  • Зарегистрирован

  • Посещение

Репутация

0 Neutral

Информация о hafis

  • Звание
    Активный участник
  1. Здравствуйте, коллеги! Имеется: Дистанционно расположенный компьютер под управлением Win7 (комп за несколько тыс. км, доступа к нему нет) С него делается периодически резервная копия средствами Active Backup for Business, тип источника: "системный том" Актив бэкап работает на DS412+, (Virtual Machine Manager для легкой беспроблемной конвертации с архива в виртуальную машину на нем запущен быть не может) Задача: поднять всё, "как есть" с данного актуального архива в виртуальной машине на VDS или в виртуальной машине на выделенном сервере, с hyper-v. То есть, конвертировать а
  2. Если Вы - владелец домена, то в DNS-записях для этого домена просто прописываете IP вашего NAS, вместо сервера у провайдера. Это абсолютно штатная процедура при "переезде" серверов с одного размещения на другое. Такой опыт есть. Но, в моем случае был выделенный белый IP. В роутере прописывается проброс портов, необходимых для работы почтовых служб (25, 443, и т.п.). В DNS-записях домена этот IP является значением для MX-записей. Но, впоследствии эта практика была прекращена. А почта перемещена на нормальный сервис VDS, который по сегодняшним временам стоит недорого. Потому
  3. Ну, до недавнего времени коробчонка с душой вела себя прилично. несмотря на то, что я регулярно обновлялся. Когда NAS доступен, то в веб-морде загрузка памяти не больше половины имеющегося. И свободного места на массиве еще пара терабайт. Никаких проблем с коробкой до недавнего времени не было. Да и не так много пакетов в него загружено. В моем случае, фактически, работает только Active backup и старенький Cloudstation server. И да, отлучение NASa от интернета путем физического выдергивания IP-шнурка - бешеную пляску дисков не прекращает. Получается, это не обмен данными с внешни
  4. Итак, повторилась ситуация, описанная в стартовом посте про мой NAS. Та же история: бесконечно (cутки уже) стрекочет дисками, SMB отвалилась. В панель управления DSM иногда пускает, но диспетчер задач вызвать уже не удается. В общем, симптомы заболевания "бешенством самозанятости" - все те же, как описаны в старте топика. Попытался зайти по ssh. А вот хрен! Putty дает ввести логин, но после ввода пароля вывешивает транспарант: "Remote side unexpectedly closed network connection" bitvise тоже многословно сообщает, что, ssh сессия прервана с ошибкой. connection, дружище, lo
  5. kucher, конечно, тут никаких противопоставлений, понятно, что мы сейчас просто гипотезами обмениваемся, в надежде понять возможные процессы, получившиеся настолько возбужденными.
  6. Drive Server я на этот NAS не ставил. Cloudstation server - установлен и используется. Но, ранее за ним я таких отвязных финтифлясов - не наблюдал. Обычно он шебуршит что-то там, тихой сапой в фоновом режиме, и не отсвечивает. Из пакетов, активно работающих с файлами, установлено: -- Cloud Station server -- Active Backup for Business (последнее успешное задание выполнено три дня назад, а далее пакет тупо ничего не смог сделать) -- Universal Search (но, индексируемых папок там не настроено) -- Hyper Backup (но, все дестинейшины для него были физически отключены) Подозр
  7. DS412+ 3 диска RAID5, BTFS DSM 6.2.3 Очень активно и безпрерывно стрекочет дисками. Как минимум сутки, а может больше. При этом пользовательские сервисы: файловый сервер, сервер cloudstation, web-сервер - недоступны. Доступа по SMB нет. Сервисы (cloudstation, etc) фактически не функционируют. Даже простенький сайтик маленький быстрый, размещенный на NAS - и тот не отзывается. С большим трудом, не с первого раза, зашел через браузер в панель управления. При этом страничка в браузере грузится прям несколько минут. Видно, что аппарат занят чем-то своим, очень интимным, но то
  8. В обозримой локальной окрестности нет линукса. Только виндус. Доступа с внешнего мира тоже нет (серый IP). А MC под виндус не умеет Shell Чем возможно просмотреть ситуацию более подробно из под винды в локалке?
  9. В пополнение к предыдущему: Это домашний NAS, использовался как файлопомойка и для бэкапов настольного Мака. (в папку backup***) Никаких там докеров, хренокеров, LUN for iSCSI и проч - не делалось. Да и не умеет 413j шибких сложностей. До этого "раздел 1" жил на 212j, Там как раз и заполнился полностью. Что послужило причиной миграции на 413j и последующим разборкам "а что там хранится-то?" Вот этот, неизвестный никому, и не принадлежащий никаким общим папкам терабайт данных появился еще при жизни двух дисков в 212j. Такие, вот, странные дела. "Что это было, Хол
  10. Имеем DS 413J Изначально был на нем один дисковый массив, (2 диска по 3 ТБ). Который постепенно заполнился. Назовем его "раздел 1" Решили расширить систему хранения, вытащив из загашника еще пару дисков по 2 ТБ. Поскольку Синололжи умеет расширяться только на дисках не меньшего размера, решили это сделать таким образом: 1. Создаем второй пул хранения и второй раздел (назовем его "раздел 2"). 2. Перенесем на "раздел 2" все общие папки. 3. Грохнем "раздел 1", диски по 3 ТБ освободятся 4. Проведем ребилдинг второго пула хранения, добавляя к нему освободившиеся диски.
  11. демон с рутовыми правами, самостоятельно живущий внутри Синололжи абсолютно вне контроля пользователя Синолоджи - это конечно не дыра, а только предпосылка к ней. Зная, что такие предпосылки уже имеются, пользователь может выстроить определенную стратегию в отношении своей информации. Ну или, беззаботно отмахнуться, однако уж с полным осознанием ситуации. В этом - суть и смысл и того и этого обсуждения. А отнюдь не в том, чтобы всем тут думать: "как противозаконно использовать этого демона - еще не придумали, поэтому потенциальных опасностей тут нет никаких вообще". Мне каж
  12. Какие-то смешные ставки для компании. Наверное, не сильно уверены в багоотсутствии в своих продуктах А если серьезно, то агенство по подбору персонала может заявить: "Мы выплатим премию, если Вы сформируете ситуацию, когда уборщица Вас обворует, и Вы при этом поймаете ее за руку". Но лично я предпочитаю заранее понимать, что такая уборщица в принципе потенциально может воровать. Технически имеет необходимые навыки, умения и возможности. И, просто принять сие к во-внимание, запуская козла в огород работницу к себе домой. Даже если она в штатном своем поведении ведет себя прилично.
  13. То, что некий демон с рутовыми правами живет в Синолоджи независимо от воли админа и хозяина экземпляра Синолоджи - как бы не оспаривается? Далее мнения тогда в обсуждении разделились на два лагеря: (1) Демон всегда добрый и послушный. То есть, потенциальна дыра безопасности всегда останется потенциальной. (2) Дырочка с этим демоном с высокими правами может выйти из под контроля, поскольку никто кроме разработчиков не знает что там напрограммировали. И, Вы - в том числе не знаете. И? далее применяется тезис, который тут уже был озвучен: "паранойя и инфобез идут рука об руку и это нормал
  14. Шифровальщик SynoLocker, насколько понимаю, проходил совершенно мимо паролей в DSM. И, вполне успешно шифровал Синолоджи. Это показывает, что перебора пароля может и не быть. (ремарка, конечно, не Вам, а только входящим в тему безопасности Синолоджи). Кроме того, в Синолоджи есть очевидно ослабленные места в отношении паролирования. В частности, в механизме расшаривания ссылок, когда демон, работающий под рутовым паролем, в определенных условиях отдает любому встречному-поперечному информацию, в том числе и с папок, к которым изначально нет прав доступа пользователей без паролей. По
×
×
  • Создать...