TGViewer
Channel Public Channel
Записки IT специалиста

Записки IT специалиста

@interface31

IT-канал, просто о сложном
https://interface31.ru

Купить рекламу:
https://telega.in/c/interface31
Subscribers
8.99K
Photos
2.4K
Videos
39
Links
2.4K

Showing posts older than #6339 · Back to latest

Older Posts 16 shown
Post #6337 2.85K
Не прошло и полгода…

Совсем не неожиданно, а очень даже наоборот, второй ведущий почтовый Mail.ru прекратил поддержку сторонних почтовых клиентов на бесплатных тарифах. В веб-интерфейсе с почтой можно по-прежнему работать без ограничений.

При этом совсем недавно на аналогичный шаг пошел Яндекс, о чем мы совсем недавно писали: https://t.me/interface31/6266

Какие варианты? Да никаких, достаем кошелек и оплачиваем. Ну или начинаем увлекательный квест под названием «сам себе почтовый хостер», что тоже не самый лучший вариант.
  • 🤣 16
  • 🤬 5
  • 😁 3
Post #6335 2.47K
Атомарность – будущее Linux

Этот вопрос волнует многих, и пользователей и, тем более, администраторов. Давайте попробуем разобраться в чем преимущество атомарности.

Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…

Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.

Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.

И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.

Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.

Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.

Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…

Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.

А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.

Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.

А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.

Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.

В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.

Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…

А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.

Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
  • 👍 23
  • 🤔 7
  • 👎 3
  • ❤ 1
  • 🤮 1
Post #6333 2.38K
Пакетный ад сложных проектов с зависимостями

Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.

Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.

Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.

Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.

Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.

Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.

Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.

Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».

Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.

Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.

Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.

Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.

И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.

А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».

При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.

В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.

Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.

После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
  • 👍 16
  • ❤ 4
  • 👎 3
  • 🤣 2
Post #6331 2.5K
Почему пакетная система Linux скорее всего доживает последние дни

Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы.

Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива.

Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду.

Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А.

Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать.

Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива.

В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего.

Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки.

Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может.

Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему.

А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы.

И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника.

В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере.

Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах.

При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте.

И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения.

А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
  • 🤔 22
  • 👍 13
  • 🤡 8
  • ❤ 7
  • 👀 2
Post #6329 3.13K
Не было печали – апдейтов накачали

В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.

Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.

Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.

Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
  • 🔥 24
  • 😱 17
  • 😢 4
  • 👀 1
Post #6327 2.65K
Маразм крепчал, еноты пели. Серия номер следующая

На прошлой неделе, без лишнего шума и пыли наши законодатели приняли законопроект № 1069392-8 о внесении изменений в КоАП РФ. Дополнив его, между прочим, новой статьей:

«Статья 13.55. Неисполнение обязанности по проведению авторизации пользователей сети «Интернет» при предоставлении доступа к информации
Неисполнение владельцем сайта и (или) страницы сайта в сети «Интернет … прошедшим авторизацию, обязанности проводить ее в отношении пользователей сети «Интернет», находящихся на территории Российской Федерации, одним из способов, предусмотренных Федеральным законом от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации», в случае, если такая обязанность предусмотрена указанным Федеральным законом


И санкции от 10 000 и до 700 000 рублей, в зависимости кто, что и когда. А нормы, на которые ссылается статья относятся к Федеральный закон от 27.07.2006 N 149-ФЗ "Об информации, информационных технологиях и о защите информации", который в части п.10 ст.8 требует:

10. Владелец сайта и (или) страницы сайта в сети «Интернет… в случае, если доступ к информации, размещенной на его сайте и (или) странице сайта в сети «Интернет» … предоставляется пользователям, прошедшим авторизацию, обязан проводить ее в отношении пользователей, находящихся на территории Российской Федерации, одним из следующих способов:


А способов там немного: номер телефона, ЕСИА, ЕСИА + биометрия и:

с использованием иной информационной системы, обеспечивающей авторизацию пользователей … владельцем которой является гражданин Российской Федерации, не имеющий гражданства другого государства, или российское юридическое лицо.


Мы опустим тот момент, что закон технически неграмотный и путает аутентификацию и авторизацию. А то, что он абсолютно размытый и резиновый. Да, у нас явно отсекаются зарубежные OAuth-провайдеры и прочие зарубежные системы (Телеграм, Discord и т.д.), но и появляется огромное серое поле.

Вот у меня аутентификация через логин и пароль, а для этого я запрашиваю электронную почту. Является ли использованием пользователем зарубежной почты нарушением? С одной стороны, про почту там ничего не сказано, но и владельцем ее не является гражданин РФ или российское юрлицо.

Любой владелец информационного сайта, не завязанный непосредственно на необходимость как-то идентифицировать пользователей, просто уберет или резко сократит возможности аутентификации до безопасных.

А сегодня у нас в РФ остался только один OAuth-провайдер, который позволяет подключить свой ресурс физическим лицам без дополнительной заморочки – это Яндекс.

Все остальные, включая VK, работают только с юридическими лицами и после длительной юридической процедуры регистраций и согласований.

И даже если владелец ресурса имеет такую возможность, он сто раз подумает, а оно ему надо? Сегодня ты там засветился, а завтра утомишься сдавать отчеты и станешь объектом проверок. Проще выключить все нафиг.

Ну так давайте уйдем в зарубежные/международные зоны и пусть попробуют предъявить. Но это плохая политика, если только ваш сайт действительно не международный. Выявив нарушения и не обнаружив владельца РКН просто добавит ваш сайт в выгрузку и заблокирует к нему доступ.

И вы потеряете большую часть трафика, после чего существование подобного ресурса будет лишено смысла.

Поэтому сегодня отечественные ресурсы оказались между молотом и наковальней, особенно это касается ресурсов информационных. Прямой конвертации пользователей в прибыль тут нет, а риски и издержки растут с каждым днем.

И многим будет проще просто взять и прикрыть это, ставшее опасным хобби, нежели пытаться и дальше лавировать между струями дождя.
  • 🤷‍♂ 18
  • 😢 10
  • 🔥 8
  • 😁 5
  • ❤ 3
Post #6326 2.63K
Теперь у нас только так и никак иначе 😢
Просьба отнестись с пониманием...
  • 👌 20
  • 👀 10
  • 🫡 8
  • 😁 5
  • 🤡 4
Post #6324 2.83K

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • 🔥 7
  • 👎 2
  • 🤝 2
  • 👏 1
  • 👌 1
Post #6317 2.74K
Правильный ответ на вопрос: в чем особенность диапазонов IP 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24

Данные диапазоны отличаются тем, что предназначены для использования в документации и примерах, когда нужно показать белый IP-адрес. Выделение данных диапазонов регламентируется RFC 5735, и они носят наименования TEST-NET-1, TEST-NET-2 и TEST-NET-3.

Как и диапазоны серых сетей данные адреса не маршрутизируются в сети интернет, также их не следует использовать во внутренних сетях.

Раз уж мы коснулись примеров и документации, то будет уместно вспомнить еще и RFC 2606 который регламентирует выделение доменных зон и имен для тех же самых целей.

Так в качестве примеров и использования в документации зарезервированы следующие домены верхнего уровня:

.test
.example
.invalid
.localhost


При этом следует помнить, что домен .localhost традиционно разрешается в IP-адрес петлевого интерфейса 127.0.0.1 и любое иное его использование будет конфликтовать с реально используемым сценарием.

Для документации рекомендуется использовать домен .example, а домен .test для тестирования и лабораторных сред. Основное назначение домена .invalid – это создание имен, которые очевидно являются недействительными, в тех случаях, когда есть такая явная необходимость.

Также для использования в примерах, когда нужно явно указать некоторое доменное имя зарезервированы домены:

example.com
example.net
example.org

Только эти три и никакие иные. Особенно это касается русскоязычной части сети, где для примеров любят использовать иные имена, которые не являются зарезервированными.

Но если сильно хочется русскоязычный домен, то можно использовать для примеров и документации домен верхнего уровня .испытание (xn--80akhbyknj4f).

Никакие иные адреса и доменные имена в примерах и документации использоваться не должны, особенно если они являются действительными и принадлежат иным владельцам, либо же могут быть выданы или зарегистрированы.
  • 👍 30
  • 🤮 4
  • ❤ 2
  • 👎 1
  • 👀 1
Post #6316 2.61K
Обновляем Proxmox Backup Server с версии 3 до 4

Каждый раз после выхода новой версии Debian обновляется вся линейка Proxmox, которая основана на этом дистрибутиве. Так после выхода Debian 13 была выпущена новая версия Proxmox Backup Server 4. Время обновления каждый сам выбирает самостоятельно, но мы специально подготовили для вас материал на основе официальной документации и собственного опыта как это сделать максимально удобно и безболезненно.

✅ Читать далее: https://interface31.ru/post/obnovlyaem-proxmox-backup-server-s-versii-3-do-4/
  • 👍 30
Post #6314 2.59K

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • 🤔 9
  • 🤮 8
  • ❤ 4
  • 👍 2
Post #6312 2.47K
Настраиваем скачивание обновлений APT через внешний прокси-сервер

История для наших дней типичная – у заказчика перестали нормально обновляться сервера Linux и если с доступом к репозиториям Debian или Ubuntu проблем не было, то вот с репозиториями Proxmox или Zabbix – ну просто беда.

Проблема не глобальная, с других площадок все нормально работало, провайдер на контакт не шел, рассказывая, что он сам ничего не блокирует и мы со своими претензиями пришли не по адресу.

Ну решение такого вопроса сегодня знает даже воспитанник детского сада – известное слово из трех букв. Но самое очевидное решение не всегда самое оптимальное.

Потому что решение проблемы таким путем требует инфраструктурных решений – развертывания сервера, клиента, настройки выборочной маршрутизации, хотя задача стоит предельно простая – качать обновления APT.

Но если подумать, то найдется другой способ, простой и изящный – поднять прокси-сервер, через который APT умеет работать из коробки. К этому добавим, что классический SOCKS5 не является массовым средством ходить туда, не надо куда и массовых блокировок внутри по нему нет.

Плюс все это очень быстро и просто разворачивается в любом месте. На сервере создаем новую папку проекта и размещаем там docker-compose.yml:

services:
dante:
image: n00b1k/dante:1.0.3
container_name: dante
restart: unless-stopped
ports:
- "1080:1080"
volumes:
- ./danted.conf:/etc/danted.conf:ro


И danted.conf:

logoutput: stdout

internal: 0.0.0.0 port=1080
external: eth0

user.privileged: root
user.unprivileged: nobody

clientmethod: none
socksmethod: none

client pass {
from: 203.0.113.92/32 to: 0.0.0.0/0
log: connect disconnect error
}

socks pass {
from: 203.0.113.92/32 to: 0.0.0.0/0
command: bind connect udpassociate
log: connect disconnect error
}


Где 203.0.113.92 – адрес вашей площадки и только ей разрешено использовать проски-сервер.

Запускам стек и у нас все готово, а дальше на целевом севере выполняем две команды:

echo 'Acquire::http::Proxy "socks5h://proxy.example.com:1080";' > /etc/apt/apt.conf.d/80proxy
echo 'Acquire::https::Proxy "socks5h://proxy.example.com:1080";' >> /etc/apt/apt.conf.d/80proxy


После чего сразу запускаем обновление APT и оно пойдет уже через наш прокси сервер. При этом мы настоятельно рекомендуем использовать в этой настройке именно FQDN,а не IP-адрес.

Это дает гибкость и переносимость. Сам прокси не содержит данных и для его переноса достаточно скопировать на новый узел всего два конфигурационных файла.
  • 👍 22
  • ❤ 4
  • 🤮 2
Post #6310 2.34K
  • 👎 2
  • 👍 1
Post #6309 2.19K
И больше никогда так не делай! Нам приключения не нужны!

Очередные длинные праздники – это повод отдохнуть, а вовсе не то, о чем многие из вас сейчас подумали. Хотя желание поработать в выходные и праздничные дни возникает часто.

Мотивация тут проста и понятна – большинства сотрудников на рабочем месте нет, никто не мешает. Но это же самое обстоятельство может сыграть и против вас. Потому что на рабочем месте нет ни только ваших сотрудников, но и всех других – партнеров, поддержки и т.д. и т.п.

И если вдруг что-то пошло не так – вы окажетесь у разбитого корыта и помощи оказать вам будет некому.

А сегодня вспомнилась одна история, которая произошла как раз в эти самые дни. Один молодой и резкий товарищ решил обновить 1С в небольшой сети розничных магазинов. 1С доработанная, мы протестировали обновление и передали заказчику для развертывания.

Ну что тут может пойти не так? А вот решительно все. Если обновление не содержит технических ошибок, то это не значит, что ошибок не содержит сама учетная система, которые после применения обновления себя проявят.

В этот раз именно так все и вышло. После обеда нам позвонил их директор и попросил принять участие в веселом квесте: на магазинах лезут какие-то ошибки, продавцы психуют, покупатели нервничают, собираются очереди.

К проблеме, кроме нашего героя уже оказался подключен практически весь коллектив фирмы, включая высшее руководство.

Как оказалось, в некоторых карточках товаров были не заполнены или заполнены неправильно некоторые реквизиты, которые до обновления не проверялись, а теперь, в связи с грядущими изменениями законодательства стали нужны, о чем система и сообщала при каждом добавлении товара в чек, заставляя выбирать нужное значение руками.

В общем разобрались и быстро исправили, но выходной день практически всего коллектива был безнадежно испорчен, многим пришлось даже экстренно возвращаться обратно в город с дач и прочих загородных мест отдыха.

В последствии, на оглашении оргвыводу тому самому молодому именно это и поставили на вид, потому что приключения никому не нужны, а вносить изменения перед или на выходных, даже не очень длинных – это верный способ их получить.
  • 👍 15
  • 👌 4
  • ❤ 2
  • 🤮 2
  • 😁 1
Post #6303 2.79K
Vikunja – менеджер задач с открытым исходным кодом
 
В современном мире без управления задачами обойтись сложно, особенно если у вас в работе более одного проекта. Поэтому менеджеры задач довольно востребованный тип программного обеспечения.
 
Если вы не хотите приобретать еще одну подписку или вообще хотите посмотреть, как данный тип ПО впишется в ваш рабочий процесс и что вам вообще от него надо, то можно развернуть на собственных мощностях Vikunja.
 
Установить его очень просто, на официальной страничке выбираете нужный набор ПО, и он генерирует вам готовые конфигурационные файлы. Например, для использования совместно с PostgreSQL вы можете использовать такой docker-compose.yml:
 
services:
  vikunja:
    image: vikunja/vikunja:2.3.0
    environment:
      VIKUNJA_SERVICE_PUBLICURL: http://<your-server-ip>:3456/
      VIKUNJA_SERVICE_SECRET: 8ea9b4dd84
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_PASSWORD: changeme
      VIKUNJA_DATABASE_TYPE: postgres
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
    ports:
      - 3456:3456
    volumes:
      - ./files:/app/vikunja/files
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped
  db:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: changeme
      POSTGRES_USER: vikunja
    volumes:
      - ./db:/var/lib/postgresql
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U $$POSTGRES_USER"]
      interval: 2s
      start_period: 30s

 
Перед запуском создайте в папке проекта директории и установите на них права:
 
mkdir files db
chown 1000 files db

 
Понятно, что выставлять в интернет его в таком виде без обратного прокси нельзя, но для посмотреть можно и так.
 
Теперь переходим по адресу http://<your-server-ip>:3456, регистрируемся и смотрим. Все что нужно для работы тут есть. Вы можете создавать проекты любой степени вложенности и размещать в них задачи, сами задачи могут иметь логические связи друг с другом и зависимости.
 
При этом одни задачи могут блокировать другие, что важно, так как сразу позволяет видеть ошибки в планировании и грамотно перераспределять нагрузку в случае изменения сроков.
 
А для этого тут есть то, что редко где встречается в бесплатных версиях коммерческих продуктов – диаграмма Ганта, если вы ведете сложный проект с этапами и зависимостями, то без него никак.
 
Также есть канбан, если вы предпочитаете работать по этой схеме, хотя никто не мешает вам одновременно применять несколько методов.
 
На первый взгляд выглядит совсем неплохо, и мы быстро накидали в ней нечто похожее на правду.
 
Но есть и ряд особенностей и недоработок. Самая существенная из них – нельзя одновременно вывести на один экран несколько проектов, общий список дел вы можете увидеть только на обзорной странице.
 
И ладно бы это касалось только независимых проектов, но это в полной мере относится и ко вложенным, что сильно затрудняет планирование и распределение рабочих ресурсов.
 
Командная работа тоже построена своеобразно. Вы можете создать команду и попросить пользователей присоединиться к ней, задав каждому свою роль. Создатель команды является ее администратором.
 
Но вы не можете просто так назначить произвольную задачу участнику команды пока вы не поделитесь с ним проектом целиком, что неудобно, если участником команды является внешний подрядчик и вы не хотите раскрывать ему всю внутреннюю кухню.
 
В целом продукт производит приятное впечатление, пользоваться можно, но однозначно рекомендовать его мы не можем, недоработки тоже достаточно серьезные и могут существенно затруднить процесс планирования.
 
Хотя если вы не пользовались раньше менеджерами задач, то Vikunja будет неплохим вариантов для знакомства, во всяком случае вы сможете быстро понять как данное ПО будет работать с вашими процессами и какие инструменты и функции вам нужны, а какие не очень.
  • 👍 17
  • 🤔 4
  • ❤ 1
  • 😁 1
  • 👀 1
Post #6301 2.45K
Evolution free tier от Cloud.ru существенно похудел
 
Еще в марте 2024 мы писали про бесплатное предложение от Cloud.ru (https://t.me/interface31/2227)  основной ценностью которого была бесплатная виртуальная машина с очень неплохими характеристиками.
 
Единственный момент – в предложение не входил выделенный IP-адрес и его нужно приобретать отдельно, за 149 руб/мес., что вызвало тогда волну критики. Хотя, будем честны, настоящего Free tier ни у кого практически нет.
 
Здесь же вы получали неплохой VPS по цене всего 149 руб. без существенных ограничений в параметрах и скрытых подводных камней.
 
Да, по первым порам платформа Evolution не отличалась стабильностью, а техподдержка оставляла желать лучшего и об этом мы тоже писали. Однако ситуация медленно, но, верно, исправлялась.
 
И вот теперь там подумали и решили, что с халявой пора завязывать и без лишнего шума и пыли виртуалку из доступных бесплатных ресурсов убрали. Хотя само предложение Free tier осталось, но теперь это интересно разве что как демо версия некоторых сервисов.
 
Так что кто не успел – тот опоздал, а иметь бесплатный сервер для личных, учебных или тестовых нужд в отечественном облаке по нынешним временам – совсем не лишнее.
  • 👍 6
  • 😢 5
  • ❤ 3
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →