Comments 84
- rdesktop фактически мёртв, почему он, а не xfreerdp?
- Как всё это поддерживать и обновлять?
Мне кажется, лучше было положить на флешку ядро и минимальный initramfs, а корень монтировать по сети.
Да, Вы правы. Rdesktop откровенно стар, просто я с ним давно, и знаю его грабли.
Если надо заменить на другой — в принципе, меняем раздел 2.9 на другой софт:
и содержимое скрипта runrdp будет чуть другое — вызываем не rdesktop а xfreerdp, с другими параметрами.
Я больше хотел донести до аудитории автоматику переподключения.
Касательно сетевого развертывания — тоже хороший вопрос. Я когда-то пытался идти именно по такому пути (плюс даже сетевой загрузки ядра), еще лет 10 тому назад (не с rpi, разумеется). Это требует дополнительной инфраструктуры — надо донастроить DHCP-сервер, развернуть сетевой корень, и т.п. Все это периодически сбоит и сношает мозг.
А еще клиенты-неттопы докупаются по несколько штук в разное время, у них разные видеодрова (особенно досаждали патченные интеловские, которые вытесняли ванильные), и общий корень им заходит плохо.
Поэтому я пришел к такой схеме, как наиболее экономически целесообразной, и дешевой как для меня, так и для заказчиков.
А еще представляете, насколько бы выросла статья, если сюда воткнуть нюансы сетевой загрузки? Я чего-то и так переборщил.
Что касается обновлять и сопровождать (воровато озираюсь), то, я сейчас, конечно, посягаю на догму, но зачем обновлять и что там сопровождать?
Из порядка 50 станций (опять таки не на RPi, я про прошлые годы), которые ставил лично я, либо склонированные сисадминами у клиентов из моих образов, ни к одной не потребовалось возвращаться. Из них уже 70% выведены из эксплуатации по причине отпадания необходимости, а на некоторых из тех, что выжили, до сих пор Debian etch и lenny.
Если надо менять логин и узел подключения часто, наверное, разумным компромиссом было бы в скрипте runrdp подставлять эти параметры, выдергивая их dhclient-ом по DHCP.
Если надо заменить на другой — в принципе, меняем раздел 2.9 на другой софт:
apt-get install freerdp-x11и содержимое скрипта runrdp будет чуть другое — вызываем не rdesktop а xfreerdp, с другими параметрами.
Я больше хотел донести до аудитории автоматику переподключения.
Касательно сетевого развертывания — тоже хороший вопрос. Я когда-то пытался идти именно по такому пути (плюс даже сетевой загрузки ядра), еще лет 10 тому назад (не с rpi, разумеется). Это требует дополнительной инфраструктуры — надо донастроить DHCP-сервер, развернуть сетевой корень, и т.п. Все это периодически сбоит и сношает мозг.
А еще клиенты-неттопы докупаются по несколько штук в разное время, у них разные видеодрова (особенно досаждали патченные интеловские, которые вытесняли ванильные), и общий корень им заходит плохо.
Поэтому я пришел к такой схеме, как наиболее экономически целесообразной, и дешевой как для меня, так и для заказчиков.
А еще представляете, насколько бы выросла статья, если сюда воткнуть нюансы сетевой загрузки? Я чего-то и так переборщил.
Что касается обновлять и сопровождать (воровато озираюсь), то, я сейчас, конечно, посягаю на догму, но зачем обновлять и что там сопровождать?
Из порядка 50 станций (опять таки не на RPi, я про прошлые годы), которые ставил лично я, либо склонированные сисадминами у клиентов из моих образов, ни к одной не потребовалось возвращаться. Из них уже 70% выведены из эксплуатации по причине отпадания необходимости, а на некоторых из тех, что выжили, до сих пор Debian etch и lenny.
Если надо менять логин и узел подключения часто, наверное, разумным компромиссом было бы в скрипте runrdp подставлять эти параметры, выдергивая их dhclient-ом по DHCP.
А у нас малина собрана на Yocto, U-Boot и dtb на флешке, остальное грузится по tftp и работает из памяти. Системный образ с freerdp около 16Мб весит. Обновлять просто.
А сколько клиентов всего используется? Одна организация?
Одна, сотни тонких клиентов.
… и, наверное, однотипное железо.
Идеальный вариант как раз для сетевого развертывания, все значимо упрощает.
В последние годы время у меня была выборка примерно из десятка организаций по 3-10 разношерстных железяк разных лет, плюс сисадмины штатные — 1 чел на организацию, ребята после вуза, за 20 тыс/мес. Провинция ж…
Они — птички, им это сложно. Не вложить в них такие знания, которые требует кучи смежных технологий. Поэтому приходится лепить вот так…
Идеальный вариант как раз для сетевого развертывания, все значимо упрощает.
В последние годы время у меня была выборка примерно из десятка организаций по 3-10 разношерстных железяк разных лет, плюс сисадмины штатные — 1 чел на организацию, ребята после вуза, за 20 тыс/мес. Провинция ж…
Они — птички, им это сложно. Не вложить в них такие знания, которые требует кучи смежных технологий. Поэтому приходится лепить вот так…
Почему малина а не дешевые аналоги(апельсинка и т.д.)?
К моменту, когда меня пригласили, заказчиком куплены были уже именно такие.
В принципе, сама автоматика не привязана к архитектуре, статья подойдет и для Orange. Экономически, естественно, лучше ваши варианты.
На днях хочу себе заказать апельсинку для опытов, но пока в стадии выбора модели.
Мне (для другой задачи) нужна SATA на PCI-E, а на ту модель Orange, где это есть, люди жалуются.
В принципе, сама автоматика не привязана к архитектуре, статья подойдет и для Orange. Экономически, естественно, лучше ваши варианты.
На днях хочу себе заказать апельсинку для опытов, но пока в стадии выбора модели.
Мне (для другой задачи) нужна SATA на PCI-E, а на ту модель Orange, где это есть, люди жалуются.
Orange Pi PC или PC2 — выброшенные попусту деньги.
Не покупайте. Драйверов нет, ОС нет. Ничего нет. Тогда уж посоветую Rock64.
А по теме тонкого клиента — где-то я такое уже видел, а вот: www.ncomputing.com
Тонкие клиенты из RPI3.
Не покупайте. Драйверов нет, ОС нет. Ничего нет. Тогда уж посоветую Rock64.
А по теме тонкого клиента — где-то я такое уже видел, а вот: www.ncomputing.com
Тонкие клиенты из RPI3.
Там у них всё серьезно. Форк freerdp с отрисовкой через правильное место, fbturbo патченый, свои плагины к gstreamer. В итоге, RDP работает практически идеально, ничего не тормозит и MMR FHD контент воспроизводит. Только денюшку надо им занести.
Драйверов нет, ОС нет. Ничего нет.
opi pc и иже с ними, с памятейкой >=1gb уже давным-давно (года эдак два) юзабельны, а в armbian, штатно и вполне сносно с ними работающей,
по крайней мере запись логов в zram работает из коробки.
Разочарую. Не подойдёт. Я пробовал сделать клиент RDesktop на базе апельсинки. Даже видео снял. Увы, тормозит со страшной силой — даже звук нормально не пробрасывается, хрипит. Делал на базе готового образа Lubuntu.
Если вспомню, куда заливал видео, дам пруф.
Если вспомню, куда заливал видео, дам пруф.
Малинка истоптана сообществом вдоль и поперек, а вот у остальных есть периодические проблемы с поддержкой. Если делать, чтобы было просто и с минимумом заморочек (автор даже кнопку питания не стал выводить) малинка лучший вариант.
Почему бы не запускать xfreerdp через systemd явно передавая пользователя?
Что-то типа следующих шагов:
1. Отдельный пользователь с минимальными правами
2. Настройка сети/дисков через systemd-target
3. Автологин для tty
4. systemd-user-unit для автостарта RDP-клиента.
5. systemd-user-unit для сервисов монтирования дисков/звука/etc
Возможно сделать отдельный target для старта системы для доступа к tty под другим пользователем.
Что-то типа следующих шагов:
1. Отдельный пользователь с минимальными правами
2. Настройка сети/дисков через systemd-target
3. Автологин для tty
4. systemd-user-unit для автостарта RDP-клиента.
5. systemd-user-unit для сервисов монтирования дисков/звука/etc
Возможно сделать отдельный target для старта системы для доступа к tty под другим пользователем.
Хм. Наверное потому, что с момента, как я эту автоматику сделал, в голове так и остался sysvinit. Плюс еще я не сисадмин, по сути, а так, дилетант, знающий много что горизонтально, но не в деталях, и в systemd особенно не вникал.
Вообще, Ваш план выглядит заманчиво и технологично, но это целая новая статья.
Вообще, Ваш план выглядит заманчиво и технологично, но это целая новая статья.
Идеально, да!
Если лень, есть wtware.ru winterminal.com — не бесплатно).
Закатал на флешку дистрибутив Бубунты с LTSP сервером. С неё (зашифрованной)грузится сервер,16ГБ достаточно. 5 компьютеров дешевых моноблоков с вынутыми винчестерами. Грузятся по PXE. На рабочих столах Remmina. Профит.Минимум танцев с бубном.
Сделали так же с разницей в том что наши клиенты грузились по PXE по сети, в них не было дисков вообще. Один образ не всех, tmpfs под каталог пользователя на старте. Но написать я хотел не про это. Написать я хотел про то, что делал я колл-центр, в котором компьютеры просто «стояли» если за ними не сидели операторы. То есть стояла такая себе комната в 40 всегда включённых станций и сменные операторы приходили-уходили, иногда их было 10 (ночью) иногда 40. Так вот «вечный» рдп, переподключающийся к логину после тайм-аута без ввода пользователя-пароля (каждую минуту) с сорока компьютеров клал сервер за два дня. у ссаной винды просто вытекала память от бесконечных подключений к логину по сорок раз в минуту. слов приличных нет это охарактеризовать. пришлось сделать бинарник показывающий .bmp на весь экран и выходящий по нажатию любой кнопки, и сунуть его в тот же цикл что и xfreerdp, перед ним. получилось даже корпоративненько, если на .bmp влепить лого организации.
А зачем весь этот геморрой, если есть WTWare?
Например чтобы меньше потратить денег?
Разработчик WTWare ничем не ограничивает функционал пробной версии и никого не принуждает к покупке лицензии — у меня уже пятый год в школе целый компьютерный класс крутится с надписью «только для тестирования». А так, были бы средства — купил бы лицензии обязательно, как сказано ниже, прекрасная оперативная техподдержка на форуме и прочие приятности избавляют от описанного в данной статье геморроя :-)
Стоимость лицензии по максималке 1000 рублей за лицензию, если 10 и более, то цена капитально снижается, вменяемая техподдержка и толковый форум. Думаю, это стоит затрат. И да, я делал малинку с WtWare, работает очень даже недурственно.
иксы можно выбросить, freerdp умеет напрямую работать с фреймбуфером
Не факт, что это ускорит freerdp. Возможно даже замедлит.
Дело в том, что графические изображения бывают двух типов: bitmap и pixmap. К битмапам процессор имеет непосредственный доступ, так как они в системной памяти. В вот пиксмап — это объект графического контроллера. Процессор к нему не имеет прямого быстрого доступа, но зато графический контроллер имеет очень быстрый доступ.
x11 freerdp оперирует тайлами — плитками 64x64. При создании такой плитки в freerdp создается pixmap — объект GPU. Эти пиксмапы закачиваются в память GPU один раз при создании, но потом могут быть многократно переиспользованы при рендеренге десктопа.
То есть таскаешь окно по экрану — а изображение бэкгроунда уже в памяти GPU в виде пиксмапов.
Можете конечно возразить, что у распбери нет такого деления на память CPU и память GPU, но увы — там так же как и в настоящих компютерах есть деление. Причем CPU писать в память GPU очень не быстро и не просто.
Дело в том, что графические изображения бывают двух типов: bitmap и pixmap. К битмапам процессор имеет непосредственный доступ, так как они в системной памяти. В вот пиксмап — это объект графического контроллера. Процессор к нему не имеет прямого быстрого доступа, но зато графический контроллер имеет очень быстрый доступ.
x11 freerdp оперирует тайлами — плитками 64x64. При создании такой плитки в freerdp создается pixmap — объект GPU. Эти пиксмапы закачиваются в память GPU один раз при создании, но потом могут быть многократно переиспользованы при рендеренге десктопа.
То есть таскаешь окно по экрану — а изображение бэкгроунда уже в памяти GPU в виде пиксмапов.
Можете конечно возразить, что у распбери нет такого деления на память CPU и память GPU, но увы — там так же как и в настоящих компютерах есть деление. Причем CPU писать в память GPU очень не быстро и не просто.
Два года назад текущая версия не умела, разработчики писали что-то типа если вам надо, то исправляйте — код открыт.
github.com/FreeRDP/FreeRDP/issues/3866#issuecomment-286352842
github.com/FreeRDP/FreeRDP/issues/3866#issuecomment-286352842
О, супер, самое подробное описание, которое я только видел.
Несколько замечаний.
- Клонировать образ — плохо. Лучше сделать сразу нужный базовый образ. Я уж не говорю, что айдишники машинки при клонировании не меняются, что потом не позволяет эффективно пользоваться ssh с проверкой подлинности хоста.
- Для локалей там в дистрибутиве все сломано. Проверьте locale -a после своих действий. Если все ок, то поздравляю — по умолчанию при настройке через штатный настройщик распберри там дичь.
- Пробовали для удаленной настройки vnc? По крайней мере для киосков это сильно удобнее, чем подключаться по ссш
- Ntp настраивали? Если нет, то очень плохо. И, да, из коробки его вроде нет
- Скринсейвер не отключали? Как-то пропустил этот момент
Касательно 1, согласен, но, ИМХО, в большинстве случаев можно пренебречь.
2. Все получилось нормально, хотя я в это не верил. Где-то полгода назад у меня тоже были проблемы с локалью, я даже отказывался от руссификации вообще. Сейчас все прошло гладко.
3. Я не очень знаю, как прикрутить VNC таким образом, чтобы позволял администрировать и консоль и видеть иксы, в одном сеансе. Если подскажете, буду признателен.
4, 5. Спасибо за напоминание. Учел в статье.
с NTP все просто
2. Все получилось нормально, хотя я в это не верил. Где-то полгода назад у меня тоже были проблемы с локалью, я даже отказывался от руссификации вообще. Сейчас все прошло гладко.
3. Я не очень знаю, как прикрутить VNC таким образом, чтобы позволял администрировать и консоль и видеть иксы, в одном сеансе. Если подскажете, буду признателен.
4, 5. Спасибо за напоминание. Учел в статье.
с NTP все просто
# apt-get install ntpdate
# echo "0 * * * * root ntpdate pool.ntp.org" > /etc/cron.d/ntp
- И консоль, и иксы? Я тоже не знаю ) можес обсудить идеи. Vnc устанавливал через raspi-config.
Ntp — а чего не systemd-timesyncd или как он там называется? Только нужно учесть, что дата-время должны быть хотя бы раз установлены верные, иначе оно не стекается из-за большой разницы (это просто гениально(((()
Бгг, вчера тестировал, ntpdate спокойно с 01 января 2019 перевел на актуальную.
Про фокус с расхождением я уже даже успел забыть, именно из за него раньше использовал ntpdate, по крайней мере, вместо ntpd.
Про фокус с расхождением я уже даже успел забыть, именно из за него раньше использовал ntpdate, по крайней мере, вместо ntpd.
Утилиты синхронизации времени используют системный вызов adjtime, позволяющий выставить время более точно, но имеющий ограничение на размер delta. Для ntpdate можно выбрать метод корректировки времени при помощи параметров командной строки:
-b
Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time.
а чем скринсейвер помешал? уже давно иксы умеют монитору слать сигнал sleep, а не просто картинку показывать
В бытность использовал thinstation с загрузкой по pxe. Смущало неудобство управления… конфиги вручную править под станции. Потом был ponix. Тоже pxe. уже с интерфейсом управления конфигами станций. Потом был wtware с image over http. Да, локальная загрузка это конечно хорошо, но если подключение к rdp не работает без наличия сети, загрузочный образ в 1 мб можно стянуть по той же сети и есть удобство централизованного управления то зачем бубны ради бубна?
Да, это хороший подход, когда оборудование однородное и проверенное, экземпляров много, а сам работаешь в штате. Я тоже такое поднимал. Особенно мне нравится получение параметров через DHCP, когда, фактически, из конфига DHCP сервера можно было в одном месте поменять хосты и пользователей.
Но в основном приходилось работать дендрофекальным методом, когда оборудование (какое придется) уже куплено, полимеры просраны, штатный сисадмин посажен на кол, а запуститься надо вчера. Оплата почасовая, но при демонстрации результата, а заниматься этими изысканиями впустую за свой счет — значит остаться голодным.
Я что только не перебрал в поиске хорошего универсального решения, включая thinstation и др. У них реально плохо с универсальностью, а мне еще в вопросах opensource-сборок патологически не везет: они не заводятся, заводятся но глючат, плюются уникальнейшими логами, которые не гуглятся, и вообще хамски себя ведут. А я еще и не профильный сисадмин, к тому же.
Вокруг тех же 2010-х все эти сборки у меня поднимались только с устаревшим железом, на которое были дрова, а в 11-15 годах вообще пошли неттопы с невнятными intel-овскими видеокартами, дрова к которым приходилось скачивать непонятно где, и компилировать вместо штатных (кстати их 64-битных версий не было даже под Windows, а уж какой трешак под линукс издали — пошатнешься)
Либо подходили штатные, но не с последней версии дистрибутива. Чуть ли не каждому устройству приходилось лично кланяться, чтобы заставить работать. Усложнить это все еще загрузкой через сеть, и потратить время на генерацию компактных образов? Привязать разные образы к мак-адресам? Централизованно управлять аж 5-ю станциями?? Пффф, дешевле было купить флешку на 4 Гб, воткнуть толстый линукс с тонким клиентом туда и примотать скотчем.
С однородными и предсказуемыми RPi, конечно, экономический предел сетевого развертывания будет выше, но я, как-то, по инерции не подумал.
Но в основном приходилось работать дендрофекальным методом, когда оборудование (какое придется) уже куплено, полимеры просраны, штатный сисадмин посажен на кол, а запуститься надо вчера. Оплата почасовая, но при демонстрации результата, а заниматься этими изысканиями впустую за свой счет — значит остаться голодным.
Я что только не перебрал в поиске хорошего универсального решения, включая thinstation и др. У них реально плохо с универсальностью, а мне еще в вопросах opensource-сборок патологически не везет: они не заводятся, заводятся но глючат, плюются уникальнейшими логами, которые не гуглятся, и вообще хамски себя ведут. А я еще и не профильный сисадмин, к тому же.
Вокруг тех же 2010-х все эти сборки у меня поднимались только с устаревшим железом, на которое были дрова, а в 11-15 годах вообще пошли неттопы с невнятными intel-овскими видеокартами, дрова к которым приходилось скачивать непонятно где, и компилировать вместо штатных (кстати их 64-битных версий не было даже под Windows, а уж какой трешак под линукс издали — пошатнешься)
Либо подходили штатные, но не с последней версии дистрибутива. Чуть ли не каждому устройству приходилось лично кланяться, чтобы заставить работать. Усложнить это все еще загрузкой через сеть, и потратить время на генерацию компактных образов? Привязать разные образы к мак-адресам? Централизованно управлять аж 5-ю станциями?? Пффф, дешевле было купить флешку на 4 Гб, воткнуть толстый линукс с тонким клиентом туда и примотать скотчем.
С однородными и предсказуемыми RPi, конечно, экономический предел сетевого развертывания будет выше, но я, как-то, по инерции не подумал.
Коллеги, спасибо за отзывы и советы, доработал статью с учетом. Также добавил образ готовой настроенной сборки для загрузки (см. раздел 6.Б).
Использовали еще первые версии малинки для данной цели — работают до сих пор. Не слишком парились по поводу выноса часто записываемых разделов. При настройке использовали такой проект rpitc.blogspot.com а также базовый образ.
UFO just landed and posted this here
dd if=/dev/sda of=/dev/sdb bs=32M
Только не на том сервере, на котором надо было, а на том, на котором подсматривал конфиги, войдя, по привычке, тоже под root-ом. Запутался в SSH-сеансах, RDP-окнах и еще мозг ели по телефону, а хосты назывались одинаково.
Это из личного опыта. В принципе, страшного ничего не случилось. Почти.
Да и не научило ничему… Как совали голым, так и будем © анекдот
Только не на том сервере, на котором надо было, а на том, на котором подсматривал конфиги, войдя, по привычке, тоже под root-ом. Запутался в SSH-сеансах, RDP-окнах и еще мозг ели по телефону, а хосты назывались одинаково.
Это из личного опыта. В принципе, страшного ничего не случилось. Почти.
Да и не научило ничему… Как совали голым, так и будем © анекдот
UFO just landed and posted this here
Ну, в данном случае предполагается, что я должен был работать под рутом на настраиваемом оборудовании, а под обычным пользователем (не применяя sudo, кроме как вычитать недоступные конфиги) на эталонном. Символы доллара и решетки будут напоминать, откуда и куда пихать, да и деструктивная команда не запустится.
Это неплохая схема.
А так, если sudo использовать всегда, то, ИМХО, это все равно, что всегда использовать рут.
Это неплохая схема.
А так, если sudo использовать всегда, то, ИМХО, это все равно, что всегда использовать рут.
UFO just landed and posted this here
Под рутом сидеть нехорошо, потому что по ошибке можно нагородить дел. С судо тоже можно, но вероятность чуть снижается. Как в перчатках работать: вроде, неудобно, но без них опасность выше. Однако это же рекомендация: если нужно много чего настроить, то можно и sudo -i сказать. Главное, чтобы в привычку не вошло.
Кроме того, часто подразумевается, что не стоит логиниться под рутом. Руту вообще полезно иметь звёздочку вместо пароля — чтобы исключить вход под ним в систему вообще.
Что-то вы сами с собой разговариваете.
Гм, перечитал, да, так и получилось. Чего-то я устал, похоже, за день. Мысли — скакуны, а бумага двумерна, так сложно выразить все понятно и системно.
Давайте сформулирую мысль так.
1. Я тоже не понимаю этот тезис неоэнтерпрайзистов насчет постоянной работы под sudo, и чем оно более безопасно — мне неизвестно. Прежде всего, безопасно от кого/чего?
2. Но то, что постоянно не надо работать под root-контекстом без прямой необходимости — мне понятно, даже на личном опыте, пример из которого я привел.
3. Это также можно скрестить с бесспорно полезными указаниями по безопасности не разрешать прямой вход в SSH под рутом. А большинство серверов админятся таки по SSH.
4. Из чего я для себя сделал вывод, что оптимально так: когда мне нужен root — я должен работать под рутовским шеллом, а когда не нужен, работать под обычным юзером.
5. Для достижения оного с учетом п. 3, заходить можно под юзером, а sudo bash, когда надо повыситься надолго, вполне себе вариант. Где надо, я повышусь, где нет — останусь под юзером.
6. Все равно я так не делаю. Жизнь ничему не научила. Работаю везде под рутом. SSH под рутом открываю в реальный интернет. На что я рассчитываю? А, ладно. Вся страна такая.
UFO just landed and posted this here
Ну, например, смотрите. Простой аргумент — когда у вас вход под рутом и пароль знают более двух человек, то как определить какой из них заходил (и, например, накосячил)? sudo В ЯВНОМ виде оставляет следы КТО повышал свои привилегии. Да, вы можете возразить, что в auth.log можно увидеть ключ того, кто вошел под рутом… но такое себе...
так на тру сайтах только так и пишут: вот вам сто команд, запускать только под sudo, а то сразу от рута небезопасно :(
это как рекомендации для винды не работать под админом, суть та же. только мы ж не работаем, а настраиваем)
Отпишусь про свой велосипед.
1) xfreerdp, скомпиленный из github, в стандартных репозиториях старая версия без поддержки rfx/gfx и кодеков сжатия.
2) В скрипте, перед подключением к серверу проверяется связь с сервером, и через dialog выводится сообщение, о том что нет связи или кабеля.
3) Далее подглядел у втваре функционал вывода информации при наведении мышки в нижний правый угол.
4) ещё на клиентах запускается vnc для техподдержки, тк использовать виндовые оснастки помощи юзеру это боль. В параметрах запуска vnc ещё можно указать запуск xeye, чтобы пользователь видел, что за ним подглядывают.
1) xfreerdp, скомпиленный из github, в стандартных репозиториях старая версия без поддержки rfx/gfx и кодеков сжатия.
2) В скрипте, перед подключением к серверу проверяется связь с сервером, и через dialog выводится сообщение, о том что нет связи или кабеля.
rdp.sh
#!/bin/sh
SERVER=ts01
#magic!
#The first expression removes XVESA= and everything before. The second one removes the next space and everything after.
res=$(cat /proc/cmdline | sed -e 's/^.*XVESA=//' -e 's/ .*$//')
#should be now like 1280x1024x16
res=$(xdpyinfo |grep dimension |awk '/dimensions/{print $2}')
SCR_X=$(echo $res |awk -F'[x]' '{print $1}')
SCR_Y=$(echo $res |awk -F'[x]' '{print $2}')
PROGRAM=xfreerdp
PARAMS="/cert-ignore -sec-nla /smartcard:A /multimedia:sys:alsa /w:$SCR_X /h:$SCR_Y +fonts /d: /u: /bpp:32"
while true; do
$PROGRAM $PARAMS /v:$SERVER >> /tmp/rdp.log 2>&1
DATA=$(date +%F-%H-%M)
if eval "sudo ping -c 2 $SERVER"
then
echo "$DATA | TERMSRV OK"
else
echo "$DATA | TERMSRV no connect, testing linkup"
ifconfig |grep "UP BROADCAST RUNNING"
if [ $? != 1 ]
then
echo "$DATA | TERMSRV no connected,run dialog">>/tmp/log-testc0nn
dialog --title "PING ERROR" --pause "Нет связи с сервером $SERVER" 22 70 10
else
echo "$DATA | Linkup testing pass, cable not connected">>/tmp/log-testc0nn
dialog --title "NO CABLE" --pause "Сетевой кабель не подключен!" 22 70 10
fi
clear
fi
done3) Далее подглядел у втваре функционал вывода информации при наведении мышки в нижний правый угол.
mouse.sh
#!/bin/sh
while true; do
# eval $(xdotool getmouselocation --shell)
# echo X=$X Y=$Y
#magic!
#The first expression removes XVESA= and everything before. The second one removes the next space and everything after.
res=$(cat /proc/cmdline | sed -e 's/^.*XVESA=//' -e 's/ .*$//')
#should be now like 1280x1024x16
res=$(xdpyinfo |grep dimension |awk '/dimensions/{print $2}')
SCR_X=$(echo $res |awk -F'[x]' '{print $1}')
SCR_Y=$(echo $res |awk -F'[x]' '{print $2}')
X=$(xdotool getmouselocation| awk -F'[: ]' '{print $2}')
Y=$(xdotool getmouselocation| awk -F'[: ]' '{print $4}')
dx=$(( $SCR_X - $X))
dy=$(( $SCR_Y - $Y))
echo screen $SCR_X x $SCR_Y mouse: $X $Y diff $dx $dy
if [ $dx -lt 10 ] && [ $dy -lt 10 ]
then
echo rrrr
conky -c /opt/conkyrc &
P=$!
echo $P
sleep 10
kill $P
else
sleep 1
fi
doneconkyrc
double_buffer yes
alignment bottom_right
background no
border_width 1
cpu_avg_samples 2
default_color white
default_outline_color white
default_shade_color white
draw_borders no
draw_graph_borders yes
draw_outline no
draw_shades no
use_xft yes
xftfont DejaVu Sans Mono:size=12
gap_x 5
gap_y 5
minimum_size 5 5
net_avg_samples 2
no_buffers yes
out_to_console no
out_to_stderr no
extra_newline no
own_window yes
own_window_class Conky
#own_window_type desktop
own_window_type normal
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
#own_window_transparent yes
stippled_borders 0
update_interval 10.0
uppercase no
use_spacer none
show_graph_scale no
show_graph_range no
TEXT
$nodename
${color grey}Uptime: $uptime
Address:$color ${addr eth0} ${color grey}
#Wi-Fi:$color ${addr eth0} ${color grey}
${exec grep -v "^#" /opt/rdp.sh |grep SERVER=}4) ещё на клиентах запускается vnc для техподдержки, тк использовать виндовые оснастки помощи юзеру это боль. В параметрах запуска vnc ещё можно указать запуск xeye, чтобы пользователь видел, что за ним подглядывают.
.xsession
x11vnc -forever >/dev/null &
/opt/mouse.sh > /dev/null 2>&1 &
aterm -geometry 218x72 -bg black -fg grey -e /opt/rdp.sh
/opt/mouse.sh > /dev/null 2>&1 &
aterm -geometry 218x72 -bg black -fg grey -e /opt/rdp.sh
x11vnc -forever >/dev/null &
не надо так запускать. Никогда. Хотите нормально? Либо через настройки графической среды (lightdm), либо через отдельный юнит файл для vnc (по крайней мере сразу сможете мониторить его состояние и не перезапускать целиком все, если он сдохнет — мы же в 2019....)
Если честно, не до конца понял, чем мне поможет отдельный юнит файл.
В оригинале, кстати, было так
Запускается из пользователя, перезапускается вместе с иксами по ctrl+alt+backspace.
Пароль на внц не стоит осознанно, поэтому не указан конфиг.
В моей конфигурации вообще не было никакого графического менеджера.
И вообще была вот такая крамола:
В оригинале, кстати, было так
x11vnc -forever -afteraccept "xeyes -geometry 100x50+1820+1000 -distance &" -gone "pkill xeyes" >/dev/null &Запускается из пользователя, перезапускается вместе с иксами по ctrl+alt+backspace.
Пароль на внц не стоит осознанно, поэтому не указан конфиг.
В моей конфигурации вообще не было никакого графического менеджера.
И вообще была вот такая крамола:
.bashrc
if [ $(tty) == "/dev/tty1" ]; then
python /home/pi/card_monitor.py &
while true; do startx ; echo "Again [$?]..."; done
fi
card_monitor.py
#!/usr/bin/env python
from __future__ import print_function
import os.path
from time import sleep
from smartcard.CardMonitoring import CardMonitor, CardObserver
from smartcard.util import toHexString
# a simple card observer that prints inserted/removed cards
class PrintObserver(CardObserver):
"""A simple card observer that is notified
when cards are inserted/removed from the system and
prints the list of cards
"""
def update(self, observable, actions):
(addedcards, removedcards) = actions
for card in addedcards:
print("+Inserted: ", toHexString(card.atr))
for card in removedcards:
print("-Removed: ", toHexString(card.atr))
if os.path.isfile("/boot/sc_removed.sh"):
os.system("/boot/sc_removed.sh")
if __name__ == '__main__':
print("Insert or remove a smartcard in the system.")
print("")
cardmonitor = CardMonitor()
cardobserver = PrintObserver()
cardmonitor.addObserver(cardobserver)
while 1:
sleep(60)
# don't forget to remove observer, or the
# monitor will poll forever...
cardmonitor.deleteObserver(cardobserver)sc_removed.sh
/boot/sc_removed.sh
#!/bin/bash
killall xfreerdpКак минимум тем, что не нужно делать & (запуск в фоне). Пускай менеджер служб этим заведует.
Не говорю уже о том, что можно строить цепочки — нет сети — vnc не стартует и не пытается жрать лишние ресурсы. Плюс логирование, мониторинг и пр. пр. пр.
Я уж не говорю о когнитивной нагрузке — при прочих равных ковыряться в чужих баш-скриптах времен SysV init гораздо более противно, чем в юнит файлах. Да, сложность при этом никуда не девается — она переносится на другой уровень. Но это и позволяет делать более интересные и надежныен штуки.
Неужели никак не докрутить до монтирования файловой системы в read-only, а всего изменяемого — в tmpfs? Тогда и выключать можно как хочешь и когда хочешь.
Почему не докрутить — даже, кажется, штатно в армбиане есть — overlayroot называется.
Хуже, если надо синхронизировать изменения обратно — у меня, когда экспериментировал с pine64, не вышло перемонтировать r/o раздел в r/w из скрипта (только из консоли). Ну и штатного механизма синхронизации, кажется, так и нет.
Хуже, если надо синхронизировать изменения обратно — у меня, когда экспериментировал с pine64, не вышло перемонтировать r/o раздел в r/w из скрипта (только из консоли). Ну и штатного механизма синхронизации, кажется, так и нет.
Читал статью и плакал. Автор — в начале увлекательного пути, и потому спешу поделиться одним важным моментом, который нужно всегда иметь в виду, занимаясь "терминализацией" и тонкими клиентами. Тем более, когда используются открытые решения.
Имея за плечами огромный опыт построения и эксплуатации терминального доступа (начиная с WS2003 и каналов связи 128Кбит/сек и заканчивая RemoteApp на WS2019), утверждаю, что каким бы "точеным" RDP-клиентом вы не пользовались, настройка каналов связи была и остается необходимым и обязательным условием комфортной работы.
QoS: CBWFQ/LLQ и Shaping — наше все. Без контроля сетевого трафика невозможно добиться нормальной работы удаленного доступа. Ведь при этом еще остается трафик печати, IP-телефонии и обычного файлового гонялы. Неприятно, когда бухгалтер в RDP сессии с "желтой программой" получит тыкву из-за того, что секретарь в такой же RDP сессии отчаянно листает PDF-ы с отсканированными договорами.
В любом случае, спасибо автору за минуты ностальгии и еще раз – удачи и успехов!
Вопрос, а Вы как-то при этом мониторите качество RDP-сессий?
Обязательно да: по стонам в раскаленный телефон, пешеходам с криками "все тормозит!" и заявкам в HelpDesk.
А если серьезно, то сейчас практически уже нет. По общей нагрузке на канал принимаем оперативное решение по «прижиманию» не-RDP трафика, перенаправлению оного на альтернативный (он же резервный) канал и т.п.
По опыту могу сказать, что в 1-Мбитный настроенный канал легко помещаются 20+ RDP-сессий без проблем. Заторы начинаются, когда все пользователи одновременно начинают рассматривать себя на фотографиях с очередного корпоратива. "Справедливая очередь" начинает хором их дропать, но почему-то в такие "кризисные" моменты понимание происходящего у пользователей возрастает на порядок.
У нас главная жалоба — даже не тормоза, а "разрывы" (ДЦ далеко, канал вроде бы стабильный, но...) и происходит это не постоянно, а наплывами.
Хочется научиться мерять именно разрывы сессий и хранить их где-то в исторических данных, хотя бы и в виде графика Zabbix и потом искать корреляцию (она не связана или не всегда связана с загрузкой канала)
Заторы начинаются, когда все пользователи одновременно начинают рассматривать себя на фотографиях с очередного корпоратива.
Временно переподключайте их по черному списку на 8 битную глубину цвета.
Чертежи смотреть хватит, 1с тоже работать будет, а эстетического удовольствия от просмотра фото не получится (злодейский хохот).
Есть рожденный сумрачным германским гением проект openthinclient.org.
Вот он очень похож на эталон систем управления тонкими клиентами.
Он даже у меня проработал полгода. Но они потом очень сильно переделали дистрибутив, и так как я не настоящий линуксоид, мне поднять его под Hyper-V не удалось.
К тому-же у Мелкософта произошло очередное обострение безопасности, и XfreeRDP перестал коннектиться к фермам RDP.
Работало это на HP-шных тонких клиентах. Причем добрые НР-шники тоже раздают софт для управления тонкими клиентами, но выпиливают поддержку старого оборудования. Хотя сами железяки могли бы еще работать и работать.
Так что, если у кого-то хватит задора приручить эту штуку и научить других — почет и уважуха.
Вот он очень похож на эталон систем управления тонкими клиентами.
Он даже у меня проработал полгода. Но они потом очень сильно переделали дистрибутив, и так как я не настоящий линуксоид, мне поднять его под Hyper-V не удалось.
К тому-же у Мелкософта произошло очередное обострение безопасности, и XfreeRDP перестал коннектиться к фермам RDP.
Работало это на HP-шных тонких клиентах. Причем добрые НР-шники тоже раздают софт для управления тонкими клиентами, но выпиливают поддержку старого оборудования. Хотя сами железяки могли бы еще работать и работать.
Так что, если у кого-то хватит задора приручить эту штуку и научить других — почет и уважуха.
Если Вы планируете далее продавать свое решение, то Вам необходимо будет «упаковать» все в виде законченного продукта, например вот так https://habr.com/ru/post/476686/
Так же в новых версиях raspberry cm3 используется eMMC память вместо SD. С SD картами у пользователей raspberry бывают проблемы.
Так же в новых версиях raspberry cm3 используется eMMC память вместо SD. С SD картами у пользователей raspberry бывают проблемы.
Понимаю, что некропостинг, но статья актуальная, может кому то пригодится.
По поводу выключения — доработать для пункта 4.6 скрипт и будет счастье:
По поводу выключения — доработать для пункта 4.6 скрипт и будет счастье:
#!/bin/sh
setxkbmap -option terminate:ctrl_alt_bksp # Завершение сеанса по Ctrl-Alt-BkSpace
setterm -blank 0 -cursor off # Отключим скринсейвер
xsetroot -solid gray # Установим серый фон подложки экрана
gxmessage 'Вернуться к работе?' \
-buttons 'Cancel:1,Поработать:2,Выключить:3'
case $? in
2)
./runrdp
;;
3)
sudo shutdown -h now
;;
esac
Apache Guacamole™ (лучше в контейнере)
Sign up to leave a comment.
Сборка тонкого клиента RDP на базе Raspberry Pi