Pull to refresh

Comments 46

UFO just landed and posted this here

2) Опционально предлагается врезаться в материнскую плату к кнопкам power/reset и светодиодам storage/power через 4 мосфет ключа и резисторы. Сомневаюсь что существует универсальное решение по управлению питанием через usb при любых обстоятельствах и на произвольной ос

UFO just landed and posted this here
У меня есть антресольный безголовый сервер, на котором я ресет могу и сам нажать, без мосфетов, а вот в биосе поковыряться или безопасно перезагрузить в случае отвала сети − уже нет. Для меня такая схема была бы самое оно. И расходов меньше чем на 3000р.

Вот в дата-центр за тыщи км я бы такой девайс не повёз устанавливать, не спорю. Но это ещё не значит, что он совсем бесполезный.
Вы немножко путаете ip-kvm и IPMI =)
Готовые IP-KVM тоже не управляют питанием, они втыкаются только в video и usb (старые модели — в PS/2), совместно с ними используются умные розетки с управлением по сети, или ещё какие-то приблуды.
Вообще то готовые IP-KVM прекрасно управляют питанием сервера. У меня под контролем сейчас 3 разных, и все они могут послать сигнал на вкл./выкл. питания. Один правда сам тухнет при выключении питания сервера, хз, может его неправильно подключили. Но вот два других вполне тушат сервера полностью и остаются в сети, и корректно подают команду на включение. Это не доступ к серверной встроенной IPMI, это отдельная железка.
А как он его посылает-то?
IP-KVM обычно используют для того, чтобы его быстро перекидывали инженеры в ДЦ между машинами — ни о каком подключении к пинам материнки идти речи не может. С одним сервером проще ipmi воткнуть — дешевле выйдет с текущим рынком.
А подскажите, пожалуйста, модели IP-KVM, которые позволяют аппаратно управлять питанием? Интересно, как это реализовано.

Пока что я встречал IP-KVM, управляющие питанием программно. Да и то, только отключением сервера (и перезагрузкой). Если же сервер отключен, то через IP-KVM его никак не включать (я все еще говорю о тех, что использовал). Фактически, они отправляют ctrl-alt-del на сервер. Сами при этом они не выключаются, так как у одной такой железки 3 USB: один — на ввод, два — на питание. Подключив питание к двум разным устройствам решаем вопрос с отвалом IP-KVM во время перезагрузки сервера.

Я просто включение по нажатию на любую кнопу в bios ставил и все.
Если сервер не повис наглухо то вкл/выкл без проблем.

при чём тут ОС вообще?
при том что не врезавшись в аппаратное управление питанием — аппаратно ты им не поуправляешь, usb такого не позволяет. Управление программное — не будет универсальным как факт, и уж тем более не позволит управлять на любом этапе загрузки установленной ОС или биосе/uefi, мало ли что там и как, вдруг на ctrl+alt+del оно не реагирует. А уж как врезаться — дело твоё, автор проекта предлагает так, хочешь — используй какие то умные розетки
1) надо эмулировать HID, а это можно делать только через OTG-порт, который на малинке совмещён со входом питания,
3) в оригинальной статье есть ссылки на Амазон (переходники HDMI→CSI и HDMI→USB).

Малинку можно запитать через гребенку насколько я помню.

3) Нужен отдельный прибор — hdmi switch, предлагается вот такой. В оригинале статьи есть картинка. На странице проекта есть описание подключения и использования.
1) Чтобы мат.плата не стала источником для пая, ток может превысить допустимый отдельными портами. Питание действительно можно завести например в GPIO пая. Можно и в HOST порты пая, но это уже шиворот на выворот.
2) Параллельно подключается через опто твердотельные реле к кнопкам power/reset и светодиодам мат.платы.
3) В переводе упустили суть, в оригинале статьи речь про управление обычным KVM switch через его usb порт по его протоколу, что позволяет использовать 1 Pi-KVM для 4 машин.
В оригинальной статье речь идет об управлении отдельным компьютером, но для расширения возможностей действительно можно использовать дополнительный 4-х портовый HDMI-коммутатор.
Малина с SD картой без специально доработки (вся запись в tmpfs и readonly SD) с вероятностью 10-20% не оживет после незапланированного перестарта (питание пропало, например).
Не очень подходящий вариант для критических применнений.

на практике я бы сказал 50%
но вообще sd нафиг на мороз, usb бокс с любым хардом завалявшимся в столе решает половину проблем малины))

Там именно так и сделано. Карта рид-онли, переключается в режим записи для внесения изменений в настройки или обновлений.
Классная статья. Давно тоже появилась идея о DIY IP-KVM. Буду пробовать. Спасибо!
Я просто оставлю это здесь: github.com/mtlynch/tinypilot
У меня работает по такой схеме, хотя надо сказать, что картинка подтормаживает. Надо обновлять страницу, чтобы получить последнюю картинку. Но я использую, когда отваливается всё остальное.
Привет. Я автор проекта, который описан в статье) Штука, на которую вы ссылаетесь, появилась совсем недавно, имеет меньше фичей и использует мой софт — ustreamer — который я написал с нуля для передачи видео. Так что, возможно, вам стоит ознакомиться именно с Pi-KVM как с первоисточником этой технологии)
О, класс! Только я не увидел в инструкции как засунуть Pi-KVM на уже существующий распбиан — это вообще возможно? У меня малинка лежит в 2000км от меня и без никого, и работает с tinypilot.
Спасибо!
Вообще возможно, но на практике лучше накатить готовую ось — например, для эмуляции диска требуется отдельный раздел на sd-карте, который, как и корень, содержится в ридонли, пока явно не понадобится. Ось содержит пакетный реп (все обновляется естественным путем) и множество специфичных настроек — следствие большого количества фич.
Кстати, если выдастся возможность попробовать мое поделие, то сможете использовать VNC вместо браузера. Сейчас совместно с разработчиками TigerVNC я разрабатываю первую в мире открытую реализацию H.264-сжатия для VNC, и скоро она поедет в релиз. Протокол уже зарегистрировали в IANA, патчи готовы и ждут мержа.
То есть, это будет kvm-over-vnc? Звучит интересно, хотя это дополнительная софтина нужна на клиенте (у меня win клиент). С другой стороны, RealVNC Viewer у меня и так везде поставлен. Но заведётся ли с ним?

Я бы с Вами ещё насчёт эмуляции диска поговорил отдельно, мои попытки сделать эмуляцию остановились из-за скорости загрузки девайса. Хочу сделать аналог Zalman VE400 на малинке. Понимаю, что для KVM это не так важно, но всё равно спрошу — сколько у Вас на Zero [W] проходит от подключения до определения как внешний хард?
Это уже сейчас kvm-over-vnc, а с h264 это будет kvmd-over-vnc-не-жрущий-трафик :) Правда, RealVNC с ним не заведется, потому что RealVNC на самом деле не совсем VNC, он поддерживает только базовую авторизацию и видео без сжатия, а с открытыми общепринятыми стандартами не работает, только со своими проприетарными. Так что вам понадобится TigerVNC под винду.

С зерошкой так не получится. Она так медленно грузится, что USB вылетает в таймауте при соединении.
Не проблема. Там микросервисная архитектура. VNC реализован как прокси, который просто разворачивает протокол в вызовы HTTP API. Но, понятно, это писать надо)
Преимущество TigerVNC в том, что они уделяют должное внимание безопасности, но вот в плане скорости описание проекта «TigerVNC is a high-performance, platform-neutral implementation of VNC» конечно не имеет ничего общего с реальностью. Из всех реализаций VNC он наоборот самый медленный.
Если речь заходит о скорости, то тут правит так же открытый проект TightVNC. Пользуюсь им в локальной сети регулярно, отзывчивость как у коммерческих аналогов. Но вот с безопасностью у него плохо, наружу выставлять его нельзя. Мне кажется что раз TightVNC так быстр даже на своем старом протоколе, то с внедрением H.264 это была бы бомба.
Вы говорите про серверную часть, но она тут не играет никакой роли. В Pi-KVM свой собственный VNC-сервер, написанный мною с нуля. И, кажется, довольно быстрый)

Я рекомендую TigerVNC именно в качестве клиента, потому что он поддерживает наибольшее количество расширений протокола (типа передачи кейсимов клавиш, авторизации по юзеру-паролю и прочего). Кроме того, разрабы TigerVNC оказались более открытыми к диалогу по поводу внедрения H.264. Я написал серверную часть, составил спецификацию, мы обсудили ее и начали процесс внедрения в клиентскую часть.

Разработчик TightVNC не поддержал нашу инициативу. Хотя, как мне кажется, у него уже не останется выбора, потому что формат описан, принят в IANA и сейчас разработчик одного из мобильных VNC-клиентов тоже занялся его реализацией, так что клиента уже будет как минимум 2.

PS: Тут я, конечно, чувствую определенную гордость, так как мне удалось сдвинуть развитие VNC с мертвой точки в плане внедрения дифференциального кодирования :)
А почему не какой-нить VP9? Просто как я понимаю " licensing around H.264 is problematic enough" это действительно может быть проблемой в некоторых случаях, формат проприетарный.
Надеюсь стандарт описывает реализацию в общем виде, и можно будет разные видеокодеки использовать.
Аппаратное сжатие VP9 не так распространено как H264. Проблема лицензирования преувеличена, потому что оно не касается именно нашей сферы использования.
А что делать, если у сервера только VGA выход?
использовать связку USB-to-HDMI — - HDMI-to-USB?
Можно купить активный VGA-HDMI конвертер и использовать его.
Пробовали кучу (и брендовые типа avertv и кучу китайцев) — обплевались, не умеет оно множество специфичных для VGA разрешений в HDMI переводить, к примеру в текстовом режиме все коробочки ничего не могли.
Текстовый режим (720х400) схожая коробочка (по внешнему виду) тоже не могла.
Не исключено. Там могут быть другие внутренности. В любом случае, других способов пока нет. Для преобразования VGA сигнала в удобоваримую для пая форму нужен АЦП, а они либо плохие, либо дорогие.

Да, у меня через такую коробочку, например, тупо в биос зайти нельзя. Framebuffer консоль показывает, а биос — сразу No Signal, извините.

В описанном (обсуждаемым в комментариях) решениях есть возможность подменять модели/серийники подключенных монитора/клавиатуры/мыши на другие? Т.е. чтобы конечный ПК считал что к нему подключена определенная периферия (определенный монитор/клава/мышь)?
Есть планы перебазировать на Fedora/RHEL подобное? c Arch'ем в основе всё же сложнее следить за версиями итд, а подобие AUR'а в Fedora реализовано COPR'ом, то есть в теории ядро и кастомные пакеты можно на основе этого слепить. Пока 33я федора показала себя весьма стабильным решением на RPI4, а с RHEL будет больше входа в серверную среду, как раз где железная часть максимально востребована.

И насущный вопрос, что с CM4? ;)
Скорее пойдем на Raspbian, чтобы быть в мейнстриме и больше не сношать себе мозг. Плата на CM4 уже почти готова, тоже будем продавать.
mdevaev, а будет ли это работать при подключении к устройствам с поддержкой видеовывода (на Android и iOS) через OTG Адаптеры USB-C / Lightning / HDMI / USB3.0?
Есть отзывы по такому сценарию использования?
Было бы здорово иметь возможность удаленно настраивать смартфоны/планшеты.

Оч. крутой проэкт, спасибо!
Если честно, то не знаю. Я сам не пробовал, а мне не сообщали о таких экспериментах.
Sign up to leave a comment.