У вас нет, у DevOps-ов(и иногда сетевиков, хотя по мне использовать Ansible для настройки коммутаторов - извращение) есть.
Говорю как сисадмин крупного университета и небольшого Интернет-провайдера. И да, Ansible я перестал использовать - перекатился на SaltStack.
Или будете мне рассказывать что настраивать пачки однотипных Linux-виртуалок(подготавливать виртуалки и передавать в смежные отделы - тоже часть моих обязанностей) проще руками, вместо системы конфигурирования? Особенно после справедливых хвалебных виршей в сторону GPO?
По поводу идите в чиновники - насмешили. Мои soft-скиллы еще хуже ваших.
>Зачем системному администратору разработка на C/Python/Java?
Затем же, зачем и философия - для расширения кругозора. Плюс тот же Ansible если приходится глубоко копать(например писать/дописывать модуль) то знания языка программирования, на котором он написан, пригодится. А это, ВНЕЗАПНО, Python.
Не думали рассмотреть seafile? Там как раз только обмен файлами.
А если не требуется функционал расшаривания части файлов другим пользователям - то можно вообще обойтись syncthing
Говорю как человек, который пользуется как Nextcloud и syncthing, просто в Nextcloud у меня кроме файлов еще напихано всякого(контакты, сервер вещания музыки для DSub и т.д.), поэтому мигрировать мне как-то не с руки. А syncthing использую для p2p-обмена где Nextcloud будет слишком жирно ставить(да и неумение консольного nextcloud-клиента работать в качестве демона тоже раздражает)
УМВР, причем как с .env (глобально для всех контейнеров), так и с переопределенными для конкретных контейнеров env_file(дополнительные опции вдобавок к глобальным из .env) [root@nms librenms]# docker -v Docker version 26.1.4, build 5650f9b
Это сравнение велосипеда(Proxmox) и автобуса(Openstack). Велосипед проще если надо одного человека перевести из точки A в точку B(небольшой кластер). Но если между A и B большое расстояние или надо везти больше одного человека(нагрузка), то выбор очевиден.
Что не отменяет факта, что велосипед может быть маленьким, но относительно ухоженным(фич мало в Proxmox относительно Openstack, но они работают хорошо), а автобус - двухэтажным но в грязи по самую маковку(фич много, но их качество описано в статье)
P.S. Имел небольшой опыт работы с уже развернутым другими людьми Openstack. А также разворачивал сам. Личные впечатления +/- согласуются с посылом статьи: документация не очень, а степень готовности того или иноно компонента OpenStack нельзя понять пока не развернешь и не попробуешь его.
MeshCentral хорош для централизованного управления пачкой компов через агенты, сам использую на работе, нравится. RustDesk это всё же про другое - это аналог TeamViewer и прочего для эпизодической помощи рандомным людям.
Хотя так-то есть MeshCentral Assistant, но я его честно говоря не пробовал в таком ключе - у нас MeshCentral крутится в изолированной от Интернета сети, а иногда рулить надо бывает как раз машинами, которые к этой сети не подключены, зато Интернет на них есть.
Как по мне лучше брать проприетарный продукт, который вендор не бросит внезапно
А как вы собираетесь это понять, что не бросит внезапно или не сменит политику лицензирования так, что многие побегут от такого вендора куда угодно(привет Broadcom)?
Прошу прощения, если чем-то лично вас задел, но я просто не очень понимаю откуда взялась такая идея что этот проект - не очередной распил вида "догоним и перегоним". А вся подача новости именно на это и указывает - минимум конкретики, максимум надувания щек.
В saltstack к слову можно настроить рассылку алертов если применение конфигов завершилось неудачей
>У нас нет объема работы для Ansible
У вас нет, у DevOps-ов(и иногда сетевиков, хотя по мне использовать Ansible для настройки коммутаторов - извращение) есть.
Говорю как сисадмин крупного университета и небольшого Интернет-провайдера. И да, Ansible я перестал использовать - перекатился на SaltStack.
Или будете мне рассказывать что настраивать пачки однотипных Linux-виртуалок(подготавливать виртуалки и передавать в смежные отделы - тоже часть моих обязанностей) проще руками, вместо системы конфигурирования? Особенно после справедливых хвалебных виршей в сторону GPO?
По поводу идите в чиновники - насмешили. Мои soft-скиллы еще хуже ваших.
>Зачем системному администратору разработка на C/Python/Java?
Затем же, зачем и философия - для расширения кругозора. Плюс тот же Ansible если приходится глубоко копать(например писать/дописывать модуль) то знания языка программирования, на котором он написан, пригодится. А это, ВНЕЗАПНО, Python.
Не думали рассмотреть seafile? Там как раз только обмен файлами.
А если не требуется функционал расшаривания части файлов другим пользователям - то можно вообще обойтись syncthing
Говорю как человек, который пользуется как Nextcloud и syncthing, просто в Nextcloud у меня кроме файлов еще напихано всякого(контакты, сервер вещания музыки для DSub и т.д.), поэтому мигрировать мне как-то не с руки. А syncthing использую для p2p-обмена где Nextcloud будет слишком жирно ставить(да и неумение консольного nextcloud-клиента работать в качестве демона тоже раздражает)
Это и в десятке так было начиная с какой-то версии(точно есть в 10 LTSC 2021, за другие не скажу)
Согласно статье 55 это все можно отменить, если кто надо сильно захочет
Скорее всего проблема в том, что флэшка не резиновая, а новая мажорная версия распухла. Но от этого не менее печально это конечно...
УМВР, причем как с .env (глобально для всех контейнеров), так и с переопределенными для конкретных контейнеров env_file(дополнительные опции вдобавок к глобальным из .env)
[root@nms librenms]# docker -vDocker version 26.1.4, build 5650f9b
Собственно compose-файл - слегка переделанный из репозитария https://github.com/librenms/docker
Так под капотом обоих ваших браузеров итак Хром! С Firefox зайдите(или user agent смените)
Вот кстати плюсую, Firefox на десктопе у меня тоже выбрасывает часто эту ошибку
>SpaceVM
>приятная в обслуживании
Простите, но нет. Я бы очень хотел написать развернутый ответ про качество SpaceVM и Veil, но к сожалению не могу - там почти не будет цензурных слов
Это сравнение велосипеда(Proxmox) и автобуса(Openstack). Велосипед проще если надо одного человека перевести из точки A в точку B(небольшой кластер). Но если между A и B большое расстояние или надо везти больше одного человека(нагрузка), то выбор очевиден.
Что не отменяет факта, что велосипед может быть маленьким, но относительно ухоженным(фич мало в Proxmox относительно Openstack, но они работают хорошо), а автобус - двухэтажным но в грязи по самую маковку(фич много, но их качество описано в статье)
P.S. Имел небольшой опыт работы с уже развернутым другими людьми Openstack. А также разворачивал сам. Личные впечатления +/- согласуются с посылом статьи: документация не очень, а степень готовности того или иноно компонента OpenStack нельзя понять пока не развернешь и не попробуешь его.
MeshCentral хорош для централизованного управления пачкой компов через агенты, сам использую на работе, нравится.
RustDesk это всё же про другое - это аналог TeamViewer и прочего для эпизодической помощи рандомным людям.
Хотя так-то есть MeshCentral Assistant, но я его честно говоря не пробовал в таком ключе - у нас MeshCentral крутится в изолированной от Интернета сети, а иногда рулить надо бывает как раз машинами, которые к этой сети не подключены, зато Интернет на них есть.
Как по мне лучше брать проприетарный продукт, который вендор не бросит внезапноА как вы собираетесь это понять, что не бросит внезапно или не сменит политику лицензирования так, что многие побегут от такого вендора куда угодно(привет Broadcom)?
Вот-вот, фонд то ты перенесешь, а люди останутся. И на них БУДУТ продолжать давить. Тут другой глобус нужен, как минимум...
Это канал Выживалово, там чувак на серьезных щах угарает над всяким
Точно? Беглый гуглинг подсказывает, что как раз таки умеет
Прошу прощения, если чем-то лично вас задел, но я просто не очень понимаю откуда взялась такая идея что этот проект - не очередной распил вида "догоним и перегоним". А вся подача новости именно на это и указывает - минимум конкретики, максимум надувания щек.
А у вас прям есть гарантии что эту ДПС будет строить не очередной васян? Вот другие системы, по вашему мнению, "васянские", а тут будет иначе?