>хотя вроде и пробудить может но не точно
Может, хотя автору стоит покопаться в настройках и проверить s power states и как wol с ними взаимодействует в конкретно его случае, в частности пробуждение/включение от pci(e) устройств
Про проводки - это либо что-то совсем старое, либо связано только со включением из холодного состояния (S5), и я просто не в курсе; из остальных режимов pci(e) точно может пробуждать без всяких лишних проводков, если это включено, конечно же
Для автора:
Тут, всё-таки, надо понимать, что у вас есть несколько уровней включения/пробуждения. Магический пакет - это замечательно, но компьютер ещё должен мочь пробуждаться от того устройства, на которое этот магический пакет приходит, а связана эта способность с интерфейсом, через которое это устройство подключается к компьютеру. Кроме того, надо учитывать power states. Обычно это всё очевидно из доступных настроек bios/uefi.
number09, я не знаю вашей ситуации, поэтому смоделирую ситуацию (на самом деле опишу свою), которая могла бы вызывать вашу потребность:
Есть группа файлов, принадлежащая к одному проекту и не подлежащая изменению, или подлежащая крайне редкому изменению после завершения проекта. При этом пользователи могут обращаться к завершённым проектам время от времени и случайно вносить изменения в файлы этого проекта, что крайне нежелательно.
Решение: переносить из плоскости чисто технической в административную - например, делать группу файлов уже завершённого проекта доступной только на чтение, без возможности записи; или делать архивную копию этой конкретной группы файлов после завершения этого конкретного проекта.
Подумайте в административном направлении, если не удаётся решить вашу задачу технически.
number09, ну тот же стандартный майкрософтовский VSS хранит до 512 теневых копий. Да, не совсем тем путём, что вам надо, но это разве мало? А если кто-то на каком-то этапе всё-таки испортит содержимое файла - вы будете вручную отсматривать все его 512 копий? Для предотвращения таких ситуаций обычно делается еженедельная/ежемесячная/ежегодная полная копия, и хранится N недель/месяцев/лет
Ну, начнём с того, что S/N накопителя - это одно (его вообще можно сменить без перепрошивки?), VolumeID - совсем другое, не имеющее никакого отношения к первому. Какая цель действа то?
res2001,
>видимо они передаются при подключении клиента
Конечно, само собой. Открытый ключ клиента точно передается, закрытый может использоваться для подписи челленжа - стандартная история - но конкретику надо смотреть отдельно в этом моменте.
>Пока соединения нет - не знает, но в процессе подключения клиента - уже знает.
А, окей, мы просто друг друга не поняли. Разумеется, я имел в виду в "холодном" состоянии.
res2001, про список отзыва я написал просто в самом начале первым же ответом.
Ты же писал про синхронизацию клиентских ключей - а она просто не нужна, ни в отношении открытых, ни в отношении закрытых.
>но в жизни часто это не так.
Ага, но это только то, что касается наших гос. УЦ - в жизни. В реальной. А в онлайновой, так сказать, все вполне соответствует чаще, чем не соответствует.
res2001, читай внимательно что тебе пишут, а писал я тебе про ovpn-сервер, а не про PKI. Центру сертификации необходимо знать, какие сертификаты им выпущены. Тому, что лишь проверяет подпись центра сертификации - в данном случае это OVPN сервер - этого знать не нужно.
И нет ни малейшего смысла тащить PKI вместе с CA, его закрытым ключом, и списком сертификатов им выпущенных, на второй сервер.
Что касается OSCP - не обязательно. В свойствах сертификата указываются точки распространения списка отзывов (CDP), и разные реализации PKI могут уметь (а могут не уметь) выгружать CRL полностью через них, причем вариации протоколов ограничены только возможностями PKI - хоть самба, хоть http, хоть нфс - что умеет, в общем. А сам OSCP не про списки отзывов как таковые, в общем то.
OVPN-сервер ничего не знает о клиентских ключах, и знать не должен. Знает только PKI. OVPN серверу надо знать только сертификат CA и список отзыва, но не клиентские ключи и сертификаты.
iCpu, лучше к драйверам присмотритесь, в том числе кардридера. Аппаратная неисправность кардридера едва ли может влиять на I/O операции других накопителей, а ошибки драйвера могут, причём не обязательно драйвера кардридера.
Владимир Юрченков,
щито, простите?
Я не знаю какую имплементацию OVPN и PKI вместе с ним вы используете; в стандартизированной терминологии, оторванной от конкретных реализаций - я расписал как что и зачем. Если в используемом вами PKI вместо CRL есть некие index-файлы с некими R метками - мне об этом ничего неизвестно.
В норме CRL должны быть подписаны закрытым ключом CA точно так же, как и выпускаемые этим CA сертификаты. Но может в случае OVPN в той реализации, которую вы используете, будет достаточно простого списка - не знаю.
Во-первых, что ты называешь ждущим режимом?
Во-вторых, включение/отключение монитора обычно не триггерит кхм, "звук". Скорее поверю, что случайным или не очень образом засыпают/просыпаются usb-порты
dumasti, он у вас может от группы рута работать, а не от пользователя, а на каталоге может не стоять разрешений для группы. Разбирайтесь с правами доступа в общем.
tempick, ну, наверное, но не со стандартными виндовыми api. Electron какой-нибудь так умеет, наверное, но тут я на самом деле не разбираюсь. В любом случае, так или иначе зависит это от приложения. В случае винды, по крайней мере. Что там с иксами - без понятия.
VasyaID, ну конечно всегда есть вероятность ошибки, но практика работы с конечными пользователями подсказывает, что в данном случае эта вероятность очень невелика :))
VasyaID, да в целом понятно о чём он говорит и без уточнений. Просто практика работы с конечными пользователями подсказывает. Другой вопрос, что совсем уж элементарного решения нет, а не элементарное уже расписали в ответах.
Может, хотя автору стоит покопаться в настройках и проверить s power states и как wol с ними взаимодействует в конкретно его случае, в частности пробуждение/включение от pci(e) устройств
Про проводки - это либо что-то совсем старое, либо связано только со включением из холодного состояния (S5), и я просто не в курсе; из остальных режимов pci(e) точно может пробуждать без всяких лишних проводков, если это включено, конечно же
Для автора:
Тут, всё-таки, надо понимать, что у вас есть несколько уровней включения/пробуждения. Магический пакет - это замечательно, но компьютер ещё должен мочь пробуждаться от того устройства, на которое этот магический пакет приходит, а связана эта способность с интерфейсом, через которое это устройство подключается к компьютеру. Кроме того, надо учитывать power states. Обычно это всё очевидно из доступных настроек bios/uefi.