пробовал со всеми настройками сжатия и качества, опять-таки проблема с виртуалками из VirtualBox-а , плюс опять-таки, плавность и отзывчивость ниже чем у x2go и намного ниже, чем у виндового рдп.
Да на рабочих станциях не проблема настроить все. Мне , к слову, больше нравится xfreerdp консольный, там больше настроек, чем в ремине, работает шустрее.
Ну мы не против заплатить, правда не совсем понимаю при чем тут системы виртуализации. У нас железный выделенный сервер, нужно обеспечить к нему удаленный доступ с визуалкой. В качестве виртуализации используем VitualBox, под него куча наработок и менять его бы не очень хотелось.
Но несколько хуже, чем x2go и заметно хуже, чем rdp Windows Server 2016. Разница реально огромная если интернет не выделенка и работать приходится с сервером в другой стране. Плюс странные баги с VirtualBox и непонятная работа сессий.
Вот такая картина при выводе xev :
*********** Numlock On:
KeyPress event, serial 37, synthetic NO, window 0x2400001,
root 0xa1, subw 0x0, time 16027649, (81,130), root:(952,588),
state 0x10, keycode 84 (keysym 0xffb5, KP_5), same_screen YES,
XLookupString gives 1 bytes: (35) "5"
XmbLookupString gives 1 bytes: (35) "5"
XFilterEvent returns: False
KeyRelease event, serial 37, synthetic NO, window 0x2400001,
root 0xa1, subw 0x0, time 16027809, (81,130), root:(952,588),
state 0x10, keycode 84 (keysym 0xffb5, KP_5), same_screen YES,
XLookupString gives 1 bytes: (35) "5"
XFilterEvent returns: False
*********** Numlock Off:
KeyPress event, serial 37, synthetic NO, window 0x2400001,
root 0xa1, subw 0x2400002, time 16053489, (67,35), root:(938,493),
state 0x0, keycode 84 (keysym 0xff9d, KP_Begin), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 37, synthetic NO, window 0x2400001,
root 0xa1, subw 0x2400002, time 16053585, (67,35), root:(938,493),
state 0x0, keycode 84 (keysym 0xff9d, KP_Begin), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Различия есть по keysum KP_Begin - отпущен, KP_5 - нажат.
Событие же я вешаю именно на KP_Begin
xmodmap -e "keysym KP_Begin = F3"
однако работает оно с игнором Numlock, т.е. срабатывает и со включенным и с выключенным.
Я же писал, что пробовал через mc.keymap, это вполне логично, но там нету обозначения для Num5 с выключенным капслоком. Соответственно непонятно не могу назначить нужную мне кнопку на просмотр файлов.
Назар Мокринский: Спасибо, почитаю. Просто совершенно не понимаю причины, почему каким-то образом нельзя организовать папки таким образом, как я хочу, потому и предполагаю, что подобная опция должна быть в докере. А то что мне нужно/не нужно, дак пути неисповедимы. :) Да и не всегда дело именно в дисковом пространстве. Может кто-то любит банальный порядок , а наличие хреновой тучи папок с хэшевыми названиями в одной папке просто раздражает. Этот как вариант.
Интересно, а какую реакцию вы ждете, если ответ не в тему. О том , что к контейнеру можно цепануть локальную папку это понятно. Вопрос был об организации ИМЕННО папки /var/lib/docker, чтобы разложить в подкаталоги из этой папки отдельно, для каждого контейнера, а не все одной кучей.
Например не так , как сейчас:
/var/lib/docker/xxx111
/var/lib/docker/xxx222
/var/lib/docker/yyy111
/var/lib/docker/xxx111
....
/var/lib/docker/zzz111
а так:
/var/lib/docker/xxx/111..333
/var/lib/docker/yyy/111..333
...
/var/lib/docker/zzz/111
где xxx yyy zzz - хэши контейнеров, 111,222,333 - дифы aufs для каждого контейнера.
Из открытого это понятно, я говорил о том, что из закрытого можно получить открытый! Отсюда мне не подходит вариант шифрования открытым ключом. Вроде ниже я нашел правильное решение с подписью закрытым ключом и проверкой открытым.
Ну подписывать хэши или сами файлы тут не суть сейчас важно, это понятно. Вопрос как правильно это сделать, чтобы файл на сервер мог положить только я и только созданный мной, а апдейтер должен понимать, что он создан именно мной. Тогда даже в случае взлома сервера, злоумышленник ничего не сделает, т.к. он не сможет создать файла (допустим с хэшами), который примет апдейтер как валидный.
Правильно , закрытый будет использоваться для расшифровки, но он будет встроен в апдейтер, т.е. считай он в руках злоумышленника, вместе с сгенерированным из него открытым. А значит взломав сервер, они смогут подменить обновления.
А что по поводу того, чтобы шифровать закрытым ключом, а в апдейтер зашить открытый. Ведь в моей схеме это решение будет работать так, как я хочу, верно?
А по поводу восстановления открытого ключа из закрытого , вот в мануале для ssh-keygen есть опция
-y This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.
Или я не правильно понимаю и открытый ключ просто хранится в закрытом и таким образом извлекается, а не генерится из закрытого?
Спасибо, ваши замечания по поводу проверки легитимности сайта важны, они , однако в случае взлома самого сервера и подмены самих файлов это не спасет, апдейтер вед подключится к легитимному серверу. А вот нужно, чтобы он понял, что файлы , которые он качает, чужие. Что-то вроде того, как организованы репозитарии linux.
Защищаем сами обновления, а не трафик. Т.е. если в файл на сервере зашить трояна, его получат и , соответственно, запустят все наши клиенты, масштаб трагедии сложно описать. Вот нужно этого избежать любой ценой, чтобы даже в случае взлома сервера обновлений, это никак не отразилось на наших клиентах.