Яндекс диск как служба windows server — Ваш верный помощник с OS Windows

Если кто-то делает/сделает лучше и «пушистее» — рассказывайте, делитесь, да воздастся вам по делам вашим. В общем welcome anytime! Моя задача была чтобы быстро и чтоб работало.

Пару слов про Яндекс Диск ( ЯД 🙂 ) — проект это коммерческий с бесплатной составляющей в виде заманухи. Да, здорово, что ЯД есть. Никто не ворчит, но истинные мотивы проекта понимать надо: продавать. Делать бесплатные расширенные «плюшки» в программе никто не собирался. Основные моменты:

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

Получается для синхронизации файлов, пользователь должен быть все время залогинен в системе. Это не очень безопасно, куда хуже, что это ужасно неудобно. Нужно все время следить чтобы блокировать систему, а не выходить из нее.

Сначала полностью подготавливаете ЯД к работе. Скачиваете, устанавливаете, вводите регистрационные данные, назначаете нужную папку, проверяете синхронизацию и завершаете программу.

Затем скачиваете nssm, распаковываете, переносите в Program Files. Файл будет исполняться из того места, где он лежит, поэтому сразу переносим по месту. Мои комментарии относительно ЯД’а:

Запускаете командную строку от имени Администратора, переходите в каталог скачанной nssm;
Пишете nssm install YaDisk;
Указываете путь C:\Users\имя_пользователя\AppData\Roaming\Yandex\YandexDisk\YandexDisk.exe;

Закладка Details, вбиваете Display name:

Закладка Log on as, вбиваете имя и пароль пользователя, для которого установлена программа:

У меня пользователь с правами Администратора, настроить под обычного пользователя можно. Мне это не нужно. Еще есть закладка, где можно выбрать используемые ядра процессора. Разумная вещь.

Нажимаете Install service:

Заходите в Сервисы, находите YaDisk, нажимаете Запустить:

Запускаете Диспетчер задач, переходите к Процессам. Наша служба «как пирожок» двухслойная:

Первая часть это запуск nssm и скрипта, вторая — ЯД’а.

При этом графически нигде ЯД не светится. Это очень хорошо, а синхронизация работает. Чтобы проверить нужно открыть ЯД в браузере и папку ЯД’а на компьютере, создавать/удалять и смотреть как в другой папке синхронно появляется/удаляется.

Запуск ЯД’а через ярлык программы стартует отдельный процесс с графической оболочкой. Вместе с нашим сервисом получается два одинаковых процесса, возможно отличающихся параметрами запуска:

Насколько конфликтует или нет не проверял, синхронизация по прежнему работает. Лично я графической оболочкой буду пользоваться редко-редко, может быть для каких-то настроек, не более того. Вот в общем-то и всё. Осталось отключить запуск графической оболочки при входе пользователя.

Справедливости ради нужно поблагодарить человека, давшего наводку (прошу не путать с «на водку») на nssm, я лишь адаптировал к Яндекс Диску. Однако уверен 100%, что моя заметка будет полезна многим.

Добавление от 06.04.2016

Удаляем значок ЯД’а из Моего компьютера, так как щелчок на этом значке запускает графическую оболочку — HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\ удаляем раздел {19170A69-A883-40D5-AF97-F6DC41495F15}

Со временем номер может измениться. Не буду отслеживать этот момент.

Добавление от 22.05.2016

Сегодня увидел, что Яндекс Диск не синхронизируется. Служба работает.. Стал припоминать, вспомнил что менял пароль от ящика. Это важный момент. При смене пароля, нужно запустить программу ЯД’а и вбить новый пароль. Когда ЯД работает в фоновом режиме про это легко забыть.

Источник

Все способы:

Сетевой диск Яндекс
- Шаг 1: Добавление нового элемента в сетевое окружение
- Шаг 2: Подключение сетевого диска
- Ошибка «Неправильное имя папки»
Вопросы и ответы: 35

Как известно, Яндекс Диск хранит Ваши файлы не только на своем сервере, но и в специальной папке на ПК. Это не всегда удобно, поскольку место, занимаемое файлами, может быть достаточно большим. В этой статье мы поговорим о том, как иметь доступ к диску без хранения документов на ПК.

Сетевой диск Яндекс

Специально для тех пользователей, которые не желают держать огромную папку на своем системном диске, в Яндекс Диске включена поддержка технологии WebDAV, которая позволяет подключаться к сервису, как к обычной папке или диску. Давайте по шагам разберем, как воспользоваться данной возможностью.

Шаг 1: Добавление нового элемента в сетевое окружение

Этот шаг будет описан для того, чтобы избежать некоторых проблем при подключении сетевого диска. Его можно пропустить и сразу перейти ко второму.

Итак, переходим в папку «Компьютер» и нажимаем на кнопку «Подключить сетевой диск» и в открывшемся окне переходим по ссылке, указанной на скриншоте.

Картинка с сайта: lumpics.ru
В следующем окне жмем «Далее».

Картинка с сайта: lumpics.ru

Снова «Далее».

Картинка с сайта: lumpics.ru
Затем вводим адрес. Для Яндекса он имеет такой вид:
https://webdav.yandex.ru

Нажимаем «Далее».

Картинка с сайта: lumpics.ru
Дальше необходимо дать имя новому сетевому размещению и снова нажать «Далее».

Картинка с сайта: lumpics.ru

Поскольку мы уже создавали данное сетевое размещение, запрос имени пользователя и пароля был пропущен «Мастером», у вас же этот запрос обязательно появится.

Картинка с сайта: lumpics.ru

Если планируется пользоваться несколькими аккаунтами, ни в коем случае не ставьте галку напротив «Запомнить учетные данные», иначе подключиться к другому аккаунту без танцев с бубном не получится.
Если хотим сразу по завершении процесса открыть папку, оставляем галку в чекбоксе и нажимаем «Готово».

Картинка с сайта: lumpics.ru
В Проводнике откроется папка с вашим Яндекс Диском. Обратите внимание, какой у нее адрес. Этой папки на компьютере не существует, все файлы лежат на сервере.

Картинка с сайта: lumpics.ru

Вот так выглядит размещение в папке «Компьютер».

Картинка с сайта: lumpics.ru

В общем-то Яндекс Диском уже можно пользоваться, но нам нужен именно сетевой диск, поэтому давайте его подключим.

Шаг 2: Подключение сетевого диска

Снова переходим в папку «Компьютер» и нажимаем кнопку «Подключить сетевой диск». В появившемся окне, в поле «Папка» указываем тот же адрес, что и для сетевого размещения (https://webdav.yandex.ru) и жмем «Готово».

Картинка с сайта: lumpics.ru
Сетевой диск появится в папке «Компьютер» и будет функционировать, как обычный каталог.

Картинка с сайта: lumpics.ru

Ошибка «Неправильное имя папки»

В некоторых случаях система при вводе стандартного адреса может выдать ошибку «Неправильное имя папки», которая говорит о невозможности доступа к защищенным ресурсам SSL (HTTPS). Решается проблема двумя способами. Первый — вместо адреса

https://webdav.yandex.ru

указать

http://webdav.yandex.ru

Второй — поправить параметр в системном реестре.

Нажимаем на лупу возле кнопки «Пуск» и в поисковом поле пишем «реестр». Переходим к приложению.

Картинка с сайта: lumpics.ru
Идем в ветку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

Дважды кликаем по ключу

BasicAuthLevel

Меняем значение на «2» (без кавычек) и жмем ОК.

Картинка с сайта: lumpics.ru
Перезагружаем компьютер. После выполнения приведенных выше действий проблема должна исчезнуть.

Теперь вы знаете, как просто подключить Яндекс Диск как сетевой диск стандартными средствами Windows.

Наша группа в TelegramПолезные советы и помощь

Источник

Время на прочтение5 мин

Количество просмотров51K

На прошлой неделе Яндекс.Диску исполнился год, и за этот год сервисом успели воспользоваться уже больше 8 000 000 пользователей.

А сейчас мы продолжаем рассказывать о том, сколько усилий понадобилось, чтобы всё это стало возможным. Недавно мы писали о том, как и почему команда Яндекс.Диска выбрала WebDAV для синхронизации десктоп-клиентов с сервером и начала работу над прототипом клиента Яндекс.Диска. Сегодня, как и обещали, — о том, как всё работает с серверной стороны.

Для правильной синхронизации нужно не только уметь заливать файлы, но и реанимировать заливку в случае прерванного соединения, а также научить клиент учитывать изменения в файлах.

Очевидно, что в случае, когда соединение с сервером прерывается, а потом восстанавливается, клиент должен уметь дозаливать файл на него. Есть два параметра, которые необходимо учитывать в таком случае: имя файла и его размер. Но для нас их недостаточно — с хранилищем одновременно могут работать несколько клиентов и файл может обновляться конкурентно. Поэтому понадобилось добавить ещё один параметр.

На тот момент мы уже начали разработку модуля синхронизации, который в процессе работы считал md5-хэш содержимого файла. И мы решили воспользоваться им как уточняющим параметром. Во-первых, клиент всегда имел эту информацию и, используя md5-хэш, мы не увеличивали нагрузку на него. Во-вторых, он лучше любого параметра, не зависящего от содержимого файла, — он даёт возможность проверять идентичность отправленного и полученного файла.

Перед отправкой файла на сервер клиент считает хэш. Дальше он заливает файл методом PUT, сообщая серверу этот хэш в HTTP-заголовке Etag. При получении такого запроса сервер сохраняет размер заливаемого файла и его md5 в специальную таблицу незавершённых заливок. В случае нормальной заливки всего содержимого на сервере вычислется md5 полученного файла и сравнивается с полученным от клиента — при их совпадениях файл принят верно и его можно сохранять.

В случае проблем с соединением — если оно было закрыто или при длительном таймауте — на сервере необходимо было сохранить в таблице реально принятый размер и залогировать в access.log неудачно завершённый запрос. Мы использовали в качестве фреймворка веб-сервера mochiweb и в процессе обработки проблем с обрывами соединений встретились с его особенностями. На любые ошибки библиотека реагировала вызовом ‘exit(normal)`, что означает «тихое» завершение процесса. Это нормально, если перед нами стоит nginx для логирования запросов и если при подобном завершении соединения ничего делать не надо. Конечно, можно перехватить такое исключение. Но понять, какая именно из возможных проблем случилась, мы в таком случае можем разве что по наличию известных функций в стектрейсе. Нормальным этот метод не назовёшь, поэтому пришлось править библиотеку на предмет выдачи более вменяемых ошибок.

При обрыве соединения клиент не может полагаться на информацию о том, какое количество байт отправляемого файла реально попало на сервер. Поэтому нам пришлось сделать ещё одну доработку протокола — мы расширили метод HEAD, с помощью которого клиент запрашивает эту информацию, передавая серверу путь куда заливался файл, его размер и md5. Сервер ищет незавершённые закачки пользователя с такими же параметрами и отвечает клиенту, сколько реально закачано. После этого клиент должен возобновить закачку с указанного сервером места с помощью специального запроса — нового расширения метода PUT.

Кроме просто докачки файлов, мы захотели накладывать бинарные патчи файлов — дельта-обновления, — так, как это делается в rsync, но минимизируя нагрузку от этих операций на сервере. Мы разбиваем файл на блоки, по которым считаются быстрые и стойкие сигнатуры. Метод вычисления быстрых сигнатур — rolling checksum — мы позаимствовали из rsync. Сигнатуры блоков используются для поиска совпадающих частей файла, которые пересылать по сети не требуется. Комбинацию из размера блока, сигнатур и md5-файла мы называем дайджестом файла. Для того чтобы клиент смог определить, какие части обновлённого файла ему необходимо скачать или отправить на сервер, ему необходимо получить дайджест файла, хранящегося на сервере. Для этого опять пришлось расширить протокол — на этот раз методом получения дайджеста.

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

Для начала мы попробовали считать дайджесты во время стриминга файлов в Erlang. Казалось, это уменьшит накладные расходы: порция данных уже лежит в памяти и передать её в модуль расчёта дайджеста выглядело дешёвым решением. К сожалению, из-за специфики работы с памятью в Erlang, это оказалось не так: данные копировались в драйвер, считавший хэши, промежуточные результаты копировались обратно в процесс-обработчик, а затем всё опять отправлялось в драйвер. Это оказалось чересчур ресурсоёмким. Разрабатывать специализиованный драйвер, который хранил бы всё промежуточное состояние внутри и не передавал бы его обратно в Erlang, не хотелось. Альтернативным решением стало складывать файл на диск как обычно, а дайджест считать после полного получения файла отдельной программой, написанной на C и запускаемой из Erlang как порт. Мы использовали этот подход и сократили время на расчёт дайджеста в 10 раз.

Для дельта-обновлений на сервере был расширен стандартный метод PUT, который принимает бинарный дифф и накладывает его на исходный файл. В таком диффе определены лишь две команды: скопировать часть исходного файла и вставить часть, пришедшую от клиента. Сервер занимается лишь простыми операциями, а весь тяжёлый анализ изменений в файлах находится на стороне клиента.

На самом деле, файлы на Диск загружают зелёные человечки

Для случаев, когда файл обновился на сервере, применяется тот же алгоритм поиска одинаковых частей. Клиенту могут потребоваться и несколько частей одного файла, поэтому мы поддержали запросы с указанием множества Range-ей, когда ответ приходит в виде multipart/byteranges, чтобы снизить количество обращений к метаданным файла.

Ещё один метод, который нужен для синхронизации — получить диффы дерева файлов, чтобы клиент мог определить, какие файлы успели обновиться на сервере. Эта задача отличается от обычного версионирования, поэтому методы, предлагаемые стандартом, нам не подошли, и пришлось ещё раз расширить протокол. Когда клиент хочет обновить файлы, он вызывает этот новый метод, указывая идентификатор имеющейся у него синхронизированной версии. А сервер отвечает идентификатором последней версии и списком изменений, произошедших в файловой структуре (не в самих файлах) с момента последнего обновления. Для этого мы храним историю всех изменений в файловой структуре для каждого пользователя.

Пожалуй, за исключением некоторых мелочей, это всё, чем занимается WebDAV-сервер в Яндекс.Диске. Мы довольны тем, что выбрали именно этот протокол. С одной стороны, он практически «из коробки» отвечал нашим нуждам и не требовал существенных доработок, а с другой — благодаря нему с Яндекс.Диском легко интегрировать многие утилиты и приложения.

Источник

Серверный бэкап MS Server 2019. Облачный бэкап — боль моя.

☑

Гений 1С

гуру

26.02.23

✎

13:39

Подскажите, как настроить бэкап MS Server 2019.

Понятно, что можно локально.

Но нужно еще и в облако.

А тут проблемы. Яндекс диск не работает кроме как через свое приложение, которое не очень хорошо работает как сервис.

Думалю мэйл ру из той же песни.

Есть облака, нормально работающие через веб-дав или какие-то готовые решения?

26.02.23

✎

13:59

(0) Не совался бы ты не в свою стезю

Сидел бы, печатные формы курочил и себестоимость в УТ 11 под УТ 10 переписывал

26.02.23

✎

13:59

А то потом и Яндекс не пашет и скуль не умеет, а на самом деле просто у кого-то ручки из жопки

Garykom

гуру

26.02.23

✎

14:03

Злопчинский

26.02.23

✎