
Комментарии 3
Прикольно, но с "постоянной связью" могут быть проблемы на длительной дистанции, лучше использовать что-то готовое поддерживаемое по типу Yggdrasil (который можно в свою "локальную сеть" свести которая никак не торчит наружу)
И уже на базе готового строить свои скрипты работы с системой и командной строкой. И тогда можно обойтись без bash-скриптов, а использовать прямые cli-команды которые будут валидно отрабатывать на любой системе, так как изначально команды собраны под эту систему в бинарнике.
На сейчас я посмотрел - сертификаты, jwt и тд - изначально "минимальный запуск" сильно переусложнен как по мне.
В целом по коду - сделайте релизы, что бы была привязка по версиям. И перед релизом вычесать - например сейчас раздутые миграции можно схлопнуть в один файл так как это будет "первая версия" и обратной совместимости "нет".
В идеале вообще сделать нормально модульность и публиковать уже как в рамках "cli с поддержкой go-mod" что бы если кому-то реально заййдет ваш проект, он без форков и тд мог бы просто использувать куски вашего кода как модули что бы построить свою систему (например со своим GUI-интерфейсом)
По статье - не все вычитали, мелькает местами прямо явный нейротекст, который редачили но недоредачили.
В остальном же интересно, поставил звездочку репозиторию - растите и развивайтесь, такие продукты нужны и важны.
Привет, прочитал по Yggdrasil, очень прикольная штука, сам использую Tailscale для личного и рабочего пользования, они концептом похожи, но Yggdrasil явно функционально шире. Не подумал что в целом можно цепануть подобный сервис к этому проекту, возьму на заметку!
Cli команды тоже принял. В будущем подобное хочется, но на текущем этапе сильно усложнять проект не хотелось, поэтому пока что откладывали, надеюсь скоро дойдут руки.
По сертификатам, jwt и т.д. На старте я хотел запариться над безопасностью, мне хотелось выделиться не столько новой фичей, как подходом к безопасности. Понимаю что для self-hosted продукта первоочередная безопасность лежит на пользователе, который поднимает сервис, но я все равно хотел по максимуму закрыть безопасность со стороны кода, отсюда такой стек.
Принял.
Да, это мой первый опыт по написанию статьей. Я накидал большой черновик своих мыслей по поводу проекта и потом вместе с нейронкой оформлял все в пост, чтобы читалось в формате статей хабра, не скрываю это и надеюсь, что это не страшно :).
Спасибо большое за комментарий и идеи, обязательно возьму на заметку и будем работать!
для ygg есть удобная либа-оббертка https://github.com/voluminor/ratatoskr так как хоть он и написан на Go но является в первую очередь сетевым ядром и напрямую затягуть себе в проект нужны знания и танцы
За безопасность - ygg как раз шифрованый из края в край)) Хотя можно и свои авторизации поверх накрутить
По функционалу, cli и тд - делай модульно. Можно поэтапно. Сейчас в справке только общая команда что на вызов сохранит в указанном месте встроенный sh-файл а в будущем можно будет расширить что бы реально выполняло что делает. Но вообще как раз фишка Го с тем что параметром //build можно под разные системы одни и те же методы реализовывать очень крута для такого. Со стороны клиента одно и тоже, в коде тоже одни и те же методы, а по факту просто несколько файлов под разные системы
Кстати если уж заговорили за криптографию и оптимизации - можно так же CGO затянуть если есть реальные места которые он может ускорить. Например все "рабы" без CGO собраны, а у тебя мастер-нода для быстрой работы со всеми с CGO четко под платформу
Я написал свой self-hosted MDM для смешанного парка корпоративных устройств