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

Сочи, 2-ух уровневая, ремонт, вид на море, ипотека от 2% Мечтаете о квартире у моря, но цены и необходимость делать ремонт пугают💰? Да, выбор и ремонт требует времени и денег . Но не отказывайтесь от мечты! В ЖК Фестивальный готовые квартиры с ремонтом, скидкой до 20% и ипотекой от 2%😊. ✨ Из окон видно море, до которого всего 10 минут, на территории школа, сад, магазины и даже бассейн 👍! ✅ Оставь телефон чтобы узнать цену! Узнать цену Изучите все условия кредита (займа) на сайте в соответствующем разделе. Оценивайте свои финансовые возможности и риски. Финансовые услуги оказывает: ПАО Сбербанк. #реклама festivalniy.estatesochi.com О рекламодателе

Токены как хранилища ключевой информации В обсуждении возникли некоторые вопросы по токенам, поэтому произведем краткий ликбез, чтобы внести ясность в этот вопрос. Многие не понимают функции токена как носителя ключевой информации и чем он принципиально отличается от других вариантов хранения, например, флешки, реестра или директории на диске. 🔹 Начнем с самого простого – пассивного носителя ключевой информации, его характерный представитель – Rutoken Lite. Это очень дешевый и массовый токен, все что он предоставляет – это защищенный контейнер для ключевой информации с защитой его пин-кодом. никаких криптографических операций такой токен самостоятельно выполнять не может. Для этого используется внешний программный криптопровайдер, наиболее известный – КриптоПро. Генерация закрытого ключа подписи в таком случае производится снаружи токена, после чего он записывается в защищенное хранилище, для криптографических операций ключ кратковременно извлекается в оперативную память. В чем тогда выгода от такого токена? В том, что для доступа к защищенному хранилищу и закрытому ключу в нем требуется дополнительное ПО – программный криптопровайдер. Просто так получить доступ к ключу и скопировать его не получится. Что касается флешки, реестра, директории – то скопировать ключ может любой, кто имеет доступ к файловой системе или ветви реестра, что создает широкий спектр угроз при несанкционированном доступе к ПК, вирусном заражении и т.д. и т.п. Можно ли извлечь подпись с такого токена? Можно, с помощью того же программного криптопровайдера. Это штатная возможность, мы можем скопировать контейнер с ключевой информацией на другой токен, флешку, в реестр. Такая подпись называется экспортируемой. Но мы можем изменить такое поведение и установить для ключевого контейнера признак неэкспортируемого, это стандартный признак подписи выдаваемой ФНС России. Но неэкспортируемый не обозначает неизвлекаемый. Данный признак только указывает программному криптопровайдеру что экспорт данного ключевого контейнера запрещен. Но используя техническое ПО мы можем без особых проблем выполнить экспорт такого контейнера. Противопоставить этому реально нечего, так как возможность извлечения подписи является обязательной функцией данного типа токенов. 🔹 Для надежной защиты подписи следует использовать неизвлекаемые контейнеры на активных носителях ключевой информации. Такие токены содержат в своем составе специальный чип, выполняющий криптографические операции прямо внутри токена. Закрытый ключ никогда не покидает такие устройства. Также действующие инструкции прямо запрещают для таких токенов внешнюю генерацию закрытого ключа (это технически возможно). Дополнительный плюс таких токенов – они не требуют программного криптопровайдера. Типичный пример активного токена - Рутокен ЭЦП 3.0. Расположенные на таких носителях ключи являются неизвлекаемыми (не путайте с неэкспортируемыми). Они делятся на два вида: ▫️ PKCS#11 – международный стандарт неизвлекаемых подписей, широко поддерживается всеми видами ПО. ▫️ ФКН (функциональный ключевой носитель) – отечественный стандарт, более современный чем PKCS#11 и по многим параметрам его превосходит. Но есть одна сложность. Поддержка таких токенов должна быть обеспечена со стороны прикладного ПО, в то время как с пассивными носителями это отдается на откуп программного криптопровайдера. Но в любом случае даже самый простой токен обеспечивает гораздо более безопасное обращение с электронной подписью, нежели иные способы ее хранения.

Профессиональные дроны Каргат — Российского производства Мониторинг / Охота и Поиск Каргат М10 / Каргат М15 / Каргат О10 Дроны для мониторинга территорий, объектов и инфраструктуры. Компактный дрон, помещается в рюкзак. Доставка до 10кг Каргат Д15 / Каргат Д17/ Каргат Д18 Грузовые беспилотные платформы для доставки оборудования, материалов и специализированных грузов в труднодоступные и удалённые районы. Спецзадачи Каргат С10 / Каргат С15 / Каргат С17 / Каргат С18 Поддержка специализированных модулей: сеткомёт, осветительное устройство, наземная станция мойки, устройство пожаротушения, фото-видео съёмка для киностудий. Агросектор Каргат А18 Агродрон для обработки сельскохозяйственных участков и локальных территорий. Обеспечивают равномерное распыление жидкостей и стабильную работу на малых и средних площадях. Узнать больше #реклама О рекламодателе

Let's Encrypt представила короткоживущие сертификаты и сертификаты для IP-адресов В начале января Let's Encrypt представила короткоживущие сертификаты со сроком действия 160 часов (чуть более 6 дней). Использование таких сертификатов позволяет существенно повысить безопасность и не требует использования механизмов отзыва. Теперь, при компрометации сертификата окно уязвимостей автоматически закроется по истечении 160 часов его выпуска, что более надежно, чем механизм отзыва, так как последний требует проверки со стороны клиента, которой может и не быть. Такие сертификаты прежде всего удобны для тестовых и динамических сред, где этот процесс полностью автоматизирован. Ввод короткоживущих сертификатов в качестве основных пока не планируется, хотя Let's Encrypt объявил о сокращении времени жизни сертификатов в ближайшие годы с 90 до 45 дней. Одновременно представлены и сертификаты для IP-адресов, которые могут быть только короткоживущими. Это позволит закрыть вопрос с TLS многочисленным администраторам VPN-серверов и аналогичных сетевых систем, которые не используют в своей работе доменные имена. Получить короткоживущие сертификаты или сертификаты для IP можно с помощью последних версий ACME-клиента, мы рассмотрим процесс для Certbot. Напоминаем, что официальный пакет распространяется для Linux через Snap. ✅ Ниже инструкция для DEB-based систем. Прежде всего удалим certbot из репозитория (если установлен):

apt remove certbot
apt autoremove

Если у вас еще не установлен Snap, установим его:

apt install snapd

Установим Certbot:

snap install --classic certbot

Создадим символическую ссылку на бинарный файл утилиты:

ln -s /snap/bin/certbot /usr/bin/certbot

Все, можем пользоваться. Для получения короткоживущих сертификатов нам нужно указать профиль shortlived, это можно сделать двумя способами.

--preferred-profile shortlived

Данная опция указывает Certbot на то, что профиль shortlived является предпочтительным, но если получение такого сертификата невозможна, то будет выпущен классический сертификат на 90 дней.

--required-profile shortlived

В этом случае Cetrtbot будет требовать использования shortlived профиля и если получить короткоживущий сертификат не удастся, то процесс завершится с ошибкой. Полный пример команды может быть таким:

certbot certonly --apache --required-profile shortlived

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

Утильсбор вырос. Что делать? Рассказываем Авто свыше 160 л.с. подорожали. Но есть решение! 5+ лет возим машины из Японии, Кореи, Китая. В канале — актуальные новости и лайфхаки. Подписывайся! Подписаться #реклама О рекламодателе

Наташ, ты спишь? Мы там все уронили и мониторинг твой не сработал… Мониторинг – тема сложная, гораздо сложнее чем кажется на первый взгляд и главное в ней правильно настроить объект мониторинга, чтобы получать нужное и не получать ненужное. А еще хуже, когда мы мониторим вообще не то, что надо. В результате о случившемся нас оповестит не мониторинг, а разгневанные пользователи. На днях обновляли 1С:Предприятие в одной подопечной организации и местный админ попросил что-нибудь простое и современное для мониторинга доступности основных сервисов, чтобы просто видеть, что живо, а что упало. Показали ему Uptime Kuma, понравилось, запустили. Он пошел добавлять узлы, а мы принялись за свою работу, а потом все-таки заглянули посмотреть, что он там сделал и сильно удивились. В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел. После чего мы предложили ему сесть и подумать, что именно будет контролировать такой монитор? Чтобы активировать мыслительный процесс мы предложили перейти по этой ссылке и полюбоваться на стандартную заглушку IIS/Apache. Да, такой монитор покажет нам жив ли веб-сервер в принципе, но никакого контроля над опубликованными на нем сервисах у нас не будет. В данном случае хуже будет только Ping, хотя и так многие делают, а потом сильно удивляются, когда их будят рано утром. А вот здесь самое время подумать, что именно нам нужно мониторить. Веб-сервер? Его статус в вакууме нам не даст никакой полезной информации. Веб-приложения? Именно, вот именно их состояние нам и интересно. Мы вполне можем получить ситуацию, когда веб-сервер работает нормально, а веб-приложение или сайт вдруг начали выдавать коды 4хх или 5хх и наша задача узнать об этом своевременно, а не тогда, когда найдут и разбудят. Поэтому добавляем в мониторинг не один узел, а три, по количеству опубликованных веб-сервисов (понятно, что у вас может быть любое количество) и теперь мы будем видеть состояние каждого из них в отдельности. Теперь вы можете своевременно реагировать на происходящее и четко понимать, что и с кем случилось. Этот подход следует применять для любых систем мониторинга и сервисов. Помните, что нас интересует не состояние узла, а работоспособность развернутых на нем сервисов, поэтому мониторить нам нужно именно их, а потом уже все остальное. Кстати, состоянием узла тоже пренебрегать не стоит. Особенно если есть возможность настраивать зависимости. Скажем в Zabbix вы можете настроить зависимости триггеров сервисов от состояния узла и если он полностью выключен, то Zabbix не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети. Но первичны у нас именно сервисы, помните об этом!

Алтайские Машиностроительные Заводы АЛМАЗ Один из крупнейших производителей почвообрабатывающей техники и запасных частей в России. Заводы «АЛМАЗ» — это современный, динамично развивающийся производственный комплекс с прогрессивным подходом к проектированию и производству, организации сбыта и продвижению. Дилерская сеть «АЛМАЗА» насчитывает более 200 ведущих агроснабженческих компаний в регионах России и странах СНГ. Ассортимент заводов «АЛМАЗ» включает свыше 70 моделей почвообрабатывающей и посевной техники и более 390 наименований запасных частей. Подписаться #реклама О рекламодателе

Настройка Wi-Fi роуминг в Windows Не так давно ко мне обратился хороший знакомый, который по моему совету развернул дома беспроводную меш-сеть на основе Xiaomi AX3000T и был доволен всем, кроме одного момента. На балконе, где прекрасно принимали интернет и телефон, и планшет ноутбук почему-то работал через пень колоду. Точнее то работал, то не работал, показывая слабый уровень сигнала, что, однако опровергалось как сетевыми сканерами, так и другими беспроводными устройствами. Знакомый стал подозревать что дело не в сети, а в ноутбуке и оказался прав. Дело в том, что в операционной системе Windows роуминг Wi-Fi по умолчанию выключен. Это значит, что, зацепившись раз за одну точку устройство будет висеть на ней до последнего, игнорируя находящиеся рядом точки той же сети с более сильным сигналом. Как и для чего так было сделано – загадка. Но такое поведение легко исправить, открываем состояние беспроводного подключения и нажимаем Свойства беспроводной сети и в открывшемся окне устанавливаем флаг Искать другие беспроводные сети при подключении к этой сети. Также это можно сделать через консоль, сначала получим список беспроводных профилей:

netsh wlan show profiles

Затем проверим свойства выбранного профиля указав его имя:

netsh wlan show profiles MyWi_Fi

В данном случае нас интересует параметр Автопереключение. И, наконец, установим требуемое значение:

netsh wlan set profileparameter name= MyWi_Fi autoswitch=Yes

Также рекомендуем заглянуть в параметры драйвера беспроводного адаптера и поискать там опцию Roaming Aggressiveness или Roaming Sensitivity, но ее наличие зависит от модели адаптера и установленного драйвера. С его помощью можно задать агрессивность политики переключения сетей. Например, у Intel можно установить пять значений от низкой, до высокой, по умолчанию выбирается средняя. После чего ваше устройство под управлением Windows также начнет переключаться между точками доступа для обеспечения максимального качества сигнала. А данная ситуация еще раз показывает, что роуминг в беспроводных сетях – это выбор клиента и только клиента. Вы можете создать совершенную беспроводную сеть, с отличным покрытием, с поддержкой всех современных технологий и протоколов. Купить столь же современное клиентское железо… Но если клиент не хочет или не умеет переключаться – вы его никак не заставите. Разве что попробуете отключить на умной точке доступа в надежде, что он все таки переключится на точку с более сильным уровнем сигнала.

Снегоходный шлем MOTEQ в MOTOPITER MOTEQ: ваш теплый и надежный шлем для снегохода! Отличный обзор, стильный дизайн. Низкие цены. Скидки. Доставка по России. Покупайте сейчас! 👍 Новый MOTEQ SubZero - это легкий снегоходный шлем модуляр с двойным стеклом с электроподогревом, встроенным солнцезащитным визором и улучшенной видимостью! Электроподогрев визора предотвращает запотевание и обледенение, что улучшает обзор и увеличивает длительность поездки, а откидная фронтальная часть создает дополнительный комфорт при эксплуатации. Узнать цену #реклама motopiter.ru О рекламодателе

Про Docker, секреты и рекомендации «ведущих собаководов» После вчерашней публикации про сервер Joplin в Docker мы получили ряд критических отзывов, что мол все неправильно и небезопасно, а также ссылки на умные статьи, где рассказывалось как делать не надо и как делать надо. Мы полностью со всем согласны, любые правила – это концентрированный опыт предшественников и возникли они не на ровном месте. Но у любого правила есть контекст, т.е. условия, при котором его следует применять. Хороший пример – инструкция к лекарству, там может быть указано, что для профилактики используйте одну дозу, для лечения – другую, а в некоторых случаях допустимо разово принять двойную дозу. Но если мы начнем принимать двойную дозу для профилактики, то никакой пользы у нас не выйдет, только вред. Точно также и с правилами, применять их тоже нужно с оглядкой на контекст применения, иначе может оказаться, что вместо пользы мы успешно решаем несуществующие проблемы, которые сами себе и создали. Теперь что касается Docker и секретов. Мы не будем сильно углубляться в предмет, кто в теме – тот в курсе, а коснемся его в общих чертах, понятных большинству новичков и администраторов. Итак, когда мы говорим Docker, понимая его «взрослое» и серьезное применение, то мы держим в уме CI/CD, инфраструктура как код и т.д. и т.п. Это большие команды, распределенные хранилища, версионирование, автоматическая сборка и тестирование и т.д. и т.п. И если мы явно пропишем секреты в .env (переменных окружения) или compose-файле, то они попадут в коммиты и историю Git, будут доступны при инспекции контейнера или чтении его окружения, осядут в логах, дампах, кешах. Короче, появляется множество возможностей для их утечки. На самых разных этапах. Самая грубая, но довольно часто встречающаяся ошибка – это коммит такого файла в публичный репозиторий. Также секреты могут узнать разработчики, тестировщики и разные прочие подрядчики, которым это по штату совсем не положено. Чтобы этого избежать, даже на уровне Docker Compose (а мы сильно углубляться не будем) есть возможность монтировать такие ресурсы как отдельную сущность – secrets. По факту это тот же самый текстовый файл с паролем, ключ, сертификат и т.д. в отдельной папке проекта. Но его не видно через переменные окружения, инспекцию, дампы, логи. В compose-файле мы просто указываем путь к секрету. Это позволяет использовать один и тот же compose-файл на разных нодах с разными секретами, причем не раскрывая их перед разработчиками (они вообще могут не знать ни одного). Но давайте спустимся с сияющих вершин DevOps в нашу реальность. Когда у нас нет ни разработки, ни автоматической доставки и развертывания, а есть простая потребность запустить у себя токенизированное приложение. И здесь на первое место выходит локальная безопасность. Если вы единственный администратор этой ноды, то вам все равно, можно ли прочитать секреты из переменных окружения контейнера и где именно они хранятся локально. Вы в любом случае их прочитаете, да и это не имеет особого смысла, так как именно вы их туда и записывали. А если кто-то кроме вас получил доступ к вашей ноде, то спешим вас огорчить, у вас нарисовались проблемы гораздо более серьезные, нежели «неправильное» хранение секретов в Docker. Если брать аудиторию нашего канала, то его большинство составляют именно администраторы, которые не преследуют задачи разработки и непрерывной доставки. Им просто нужно запустить и эксплуатировать докеризированное приложение. И в этом случае с точки зрения безопасности абсолютно все равно где именно вы прописали свои секреты. Самый простой путь – это .env и ничего страшного в этом нет. Все равно его кроме вас никто не видит и не читает. При грамотной организации доступа к ноде и приложениям это будет вполне безопасно и не потребует усложнения системы и дополнительных накладных расходов. Ну а ежели у вас другие сценарии, то рекомендации «ведущих собаководов» - ваша настольная книга.

В школе не объяснили — дома расхлёбываете? ⚡ Учитель идёт дальше по программе. Тема не понята — отставание растёт. Ребёнок начинает бояться уроков. TooTun AI разбирает каждую тему столько раз, сколько нужно ребёнку. 👍 Разберите сложную тему вместе Попробовать #реклама 16+ О рекламодателе

Удаленно настраивать брандмауэр – это к дальней дороге? Данная «народная примета» возникла не на пустом месте и в целом правильно отражает реальность. Одно неверное движение, ошибка, опечатка и вы остаетесь без связи с удаленным узлом и хорошо если есть окольные пути. Но не все так плохо, если знаешь где упасть, то можно и не только соломки подстелить. Для работ по изменению настроек брандмауэра мы используем простые скрипты, которые если что-то пойдет не так просто сбросят его конфигурацию. Создадим в укромном месте, например в /root, скрипт flush.sh и добавим в него следующее содержимое. ▫️Для iptables:

#!/bin/bash
iptables-save > /root/iptables_backup.bak

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
iptables -t raw -F

iptables -X

▫️Для nftables:

#!/bin/bash
nft list ruleset > /root/nftables_backup.nft

nft flush ruleset

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

apt install at

Сделаем скрипт исполняемым:

chmod +x /root/ flush.sh

И перед выполнением работ настроим отложенный запуск:

at now + 15 minutes -f /root/flush.sh

Теперь через 15 минут, даже при обрыве сессии, планировщик выполнит наш скрипт и сбросит состояние брандмауэра. Какой временной промежуток выбрать решаете вы сами, в зависимости от задач и потребностей. Но общий смысл ясен – если что-то пошло не так, и вы потеряли управление, то скрипт сработает и удалит все изменения. Если же все работает нормально, и вы окончательно убедились в этом (не забудьте отключиться и снова подключиться), то просто удаляем отложенное задание. Для этого сначала узнаем его идентификатор командой:

atq

А затем удаляем командой:

atrm <ID_задания>

Главное – не забыть это сделать, иначе ваш узел останется полностью без брандмауэра.

Появился мощный инструмент для прохождения собеседований — Sobes Copilot. Это нейросеть, которая подсказывает ответы прямо во время интервью, анализируя разговор в реальном времени. Copilot работает незаметно в Zoom, Google Meet, Teams и других платформах. Поддерживает русский язык, не виден при демонстрации экрана и помогает держать уверенный темп диалога, даже если вопрос сложный или неожиданный. Дополнительно Sobes Copilot делает пост-анализ собеседования: разбирает диалог после созвона, подсвечивает сильные и слабые моменты, удачные формулировки и зоны роста. Это позволяет понять, что сработало, а что стоит улучшить перед следующим интервью. Если хотите проходить собесы спокойнее и увереннее — изучите возможности сервиса по ссылке. Это действительно меняет игру. 🎁 Промокод: SOBES26 — даёт 10% скидки на старт.

Настраиваем TLS защиту собственного сервера Joplin Вчера мы рассказали (https://t.me/interface31/5557), как быстро установить собственный сервер заметок Joplin при помощи Docker, но у него есть один недостаток – он работает по незащищенному протоколу HTTP и публично публиковать такие сервисы категорически не рекомендуется. Как быть? Ничего сложного, технически Joplin Server – обычное веб-приложение, а следовательно все наши вопросы решит установленный перед ним обратный прокси и поддержкой HTTPS. Вариантов тут великое множество, если у вас уже есть подобная инфраструктура, то имеет смысл рассматривать ее. Если же нет, то будем обходиться собственными силами и желательно сделать это максимально просто. Исходя из этого мы решили использовать веб-сервер Caddy, почему именно его, а не NGINX/ Angie? Потому что Caddy предельно прост и вы это сами скоро увидите. Так как мы уже используем Docker, то нет смысла разделять разные службы по разным местам, проще объединить их все в один compose-файл, что обеспечит проекту отличную управляемость и переносимость. Поехали. Мы дадим инструкцию с нуля, если вы уже развернули Joplin-сервер, то часть шагов можно пропустить, но даже если вы их выполните ничего страшного и деструктивного не случится. Создаем папку проекта и compose-файл в ней:

mkdir -p /opt/joplin
nano /opt/joplin/docker-compose.yml

Приводим его содержимое к следующему виду:

services:
  db:
    image: postgres:17
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: always
    environment:
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_USER: joplin-user
      POSTGRES_DB: joplindb

  app:
    image: joplin/server:latest
    container_name: joplin-server
    depends_on:
      - db
    restart: always
    environment:
      APP_PORT: 8080
      APP_BASE_URL: https://joplin.example.com
      DB_CLIENT: pg
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_DATABASE: joplindb
      POSTGRES_USER: joplin-user
      POSTGRES_PORT: 5432
      POSTGRES_HOST: db

  caddy:
    image: caddy:2
    restart: always
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - ./data/caddy:/data
      - ./config/caddy:/config

Что изменилось в нем, кроме добавления секции caddy? Мы убрали проброс портов для контейнера Joplin, теперь он полностью изолирован во внутренней сети. Также обратите внимание на APP_BASE_URL, теперь там https://joplin.example.com, т.е. явно указан протокол – HTTPS и отсутствует внутренний порт, потому что именно так мы будем обращаться к серверу через обратный прокси. Следующим шагом следует создать конфигурационный файл для Caddy:

mkdir -p /opt/joplin/caddy
nano /opt/joplin/caddy/Caddyfile

После чего внесем в него следующее содержимое:

joplin.example.com {
    reverse_proxy app:8080
}

И всё? И всё! Этим и хорош Caddy, не нужно ничего расписывать, он сам по умолчанию получит для указанного домена сертификаты Let’s Encrypt и настроит максимально надежное современное шифрование. Сохраняем конфигурационный файл и запускаем проект:

docker compose up -d

Теперь открываем указанный в APP_BASE_URL адрес и убеждаемся, что наш сервер работает по защищенному протоколу с сертификатом Let’s Encrypt и максимальным уровнем шифрования.

Познакомьтесь с каналом Tech Debunker. Там тесты, а не распаковки. Тестируют дешевые и дорогие гаджеты, аккумуляторы, инструменты и много всего прочего. Собирают большие таблицы с результатами. Разоблачают фейки и подделки. Некоторые интересные публикации с канала: • ноутбук с несуществующей памятью • фейковый планшет • поддельная зарядка Xiaomi 67W • поддельная флэшка Borofone • пауэрбанки с кирпичами внутри • опасный аккумулятор для инструмента • свежие тесты зарядок • свежие тесты пауэрбанков Подписывайтесь! Впереди много интересного. #реклама О рекламодателе

Покорение новой вершины закончилось в баре: история проекта Blackcomb История проекта Blackcomb остается самой большой авантюрой фирмы Microsoft, закончившейся столь же большим провалом. Но именно благодаря этому проекту мы получили современное состояние операционной системы Windows, хотя история могла пойти по совсем другому пути. Но позвольте, а причем тут бар и горные вершины? Обо всем по порядку. Вся эта история начинается с проекта Whistler, в котором разработчики объединили две ветви разрабатывающихся операционных систем на основе ядра Windows NT - Neptune и Odyssey. Так появилась Windows XP, одна из самых популярных операционных систем и решение объединить пользовательскую и корпоративную ветви систем оказалось в итоге правильным. А кодовое имя проекта было взято по имени горы и одноименного горнолыжного курорта Whistler, где любили кататься на лыжах сотрудники Microsoft. После удачи с Windows XP разработчики явно поверили в себя и выкатили на следующую ОС весьма амбициозные планы – практически полный переход на .NET, новую систему драйверов, новый интерфейс и новую файловую систему WinFS, которая должна была стать больше СУБД, чем традиционной файловой системой. Кодовое имя для новой системы было выбрано достаточно просто, но со вкусом – Blackcomb, вторая вершина на том же горнолыжном курорте, что подчеркивало преемственность ОС и символичность – покоряем одну вершину за другой. Но, как всегда, что-то пошло не так. Оно бы и ничего, всякое бывает, но все эти амбициозные новшества уже были с большой помпой прорекламированы и отказываться от них было теперь не с руки. Поэтому было решено сделать небольшую передышку на трудном пути и выпустить промежуточную ОС, которая займет место Windows XP и сделает пользователей на шаг ближе к Blackcomb. Для нового проекта выбрали тоже символичное имя – Longhorn, в честь бара Longhorn Saloon, расположенного между горами Whistler и Blackcomb на том же курорте. Про то, насколько любили посещать это заведение сотрудники Microsoft история умалчивает. Но и разработка Longhorn шла с большими пробуксовками и в конце концов разработчики поняли, что дальше так жить нельзя, в итоге в 2004 году была выполнена «перезагрузка» проекта. По факту же все что успели сделать за три года было выброшено, за основу взят код Windows Server 2003, поставлены реальные и достижимые цели, и работа пошла в гораздо более продуктивном ключе. Но ни о какой революции речи уже не шло. В результате обновленный Longhorn вышел в 2007 году как Windows Vista и стал одним из самых больших провалов в истории Microsoft. Нет, сама Vista технически была очень неплохой и достаточно передовой системой. Но маркетинг и неверное рыночное позиционирование, вкупе с серьезным занижением системных требований сделали свое дело – Vista провалилась. При этом Blackcomb оставался приоритетной целью, но с провалившейся Vista нужно было что-то делать и так возник еще один промежуточный проект – Vienna, который изначально планировался как небольшое обновление Vista, но провал последней только подстегнул работы по нему. В результате через два года Vienna вышла на рынок под именем Windows 7 и повторила успех Windows XP, став для многих культовой ОС. К тому времени уже стало понятно, что Blackcomb не имеет реальной фактической реализации и превратился по факту в «список хотелок». Поэтому он некоторое время все еще оставался некой «приоритетной вершиной», но чем дальше, тем все более абстрактной «вершиной», пока окончательно не растаяла в тумане. Таким образом амбициозного покорения не состоялось, а развитие Windows пошло совершенно другим путем и то, что вместо горного пика мы получили бар в долине – тоже достаточно символично. На фото обе вершины и долина с баром Longhorn Saloon между ними.

Проектные менеджеры бывают разными: одни тушат пожары горящих дедлайнов, другие строят систему. К какому типу относитесь вы? Центр бизнес-образования НИУ ВШЭ — Пермь предлагает прокачать навыки проектного менеджмента на курсе «Управление проектами». ✓ Практико-ориентированный интенсив — 120 академических часов, шесть подробных модулей с практикой, кейсами и деловыми играми. ✓ Онлайн-формат: занятия проходят 1 раз в неделю — вечером в среду. ✓ Курс построен на международных стандартах PMI (PMBoK 7). ✓ Подходит новичкам, опытным ПМ, руководителям и предпринимателям. ✓ Преподаватели — действующие эксперты в сфере проектного менеджмента. Расскажем, как: — запускать и обосновывать проекты, — работать с рисками и бюджетом, — управлять командой и заинтересованными сторонами. Мы подготовили тест, который позволит определить пробелы в знаниях и навыках. Его, как и подробности о курсе, ищите на нашем сайте. #реклама О рекламодателе

Устанавливаем собственный Joplin-сервер Jolpin – кроссплатформенное приложение с открытым исходным кодом для ведения базы заметок, является хорошей альтернативой Evernote. Для совместной работы приложение предлагает большое количество способов синхронизации, одним из которых является использование собственного сервера. Официально Joplin Server предусматривает использование Docker, других способов установки не предусмотрено. Для хранения базы заметок предлагается использовать PostgreSQL. В итоге у вас получится два контейнера: один для сервера Joplin, второй для СУБД. Для установки создадим отдельный каталог, например, /opt/joplin и разместим там файл docker-compose.yml со следующим содержимым:

services:
  db:
    image: postgres:17
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    restart: always
    environment:
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_USER: joplin-user
      POSTGRES_DB: joplindb

  app:
    image: joplin/server:latest
    container_name: joplin-server
    depends_on:
      - db
    ports:
      - "8080:8080"
    restart: always
    environment:
      APP_PORT: 8080
      APP_BASE_URL: http://joplin.example.com:8080
      DB_CLIENT: pg
      POSTGRES_PASSWORD: MyPa$$worD
      POSTGRES_DATABASE: joplindb
      POSTGRES_USER: joplin-user
      POSTGRES_PORT: 5432
      POSTGRES_HOST: db

Он достаточно прост и в особых комментариях не нуждается. Отдельно стоит обратить внимание только на APP_BASE_URL – укажите там именно тот адрес, по которому вы будете реально обращаться к серверу, если вы укажете joplin.example.com, а обращаться будете, скажем, как 192.168.1.100 – то ничего работать не будет. Сохраняем файл и запускаем:

docker compose up -d

После чего просто переходим по указанному в конфигурации URL. При первом входе обязательно установите надежный пароль администратора. Сам Joplin Server – приложение предельно простое, даже примитивное, особо смотреть и настраивать здесь нечего. Рекомендуем сразу перейти в раздел Users и создать нужное количество пользователей, под встроенным администратором работать разработчики категорически не рекомендуют, плюс у него нет реальной почты, и вы не сможете воспользоваться функцией восстановления пароля или получать уведомления. Также еще можно заглянуть в раздел Tasks – там перечислены регламентные задания для обслуживания сервера, их расписание и статус. После чего можно скачивать клиент и переходить к настройке синхронизации. Синхронизация при подключении нового клиента производится в обе стороны, т.е. все локальные заметки будут добавлены на сервер, а все удаленные будут скачаны на клиент. Это удобно, если у вас есть две независимые базы, скажем на компьютере и телефоне и вы хотите их объединить и использовать совместно. Для других сценариев полезно будет заглянуть в Расширенные настройки синхронизации. Опция Перегрузка локальных данных в цель синхронизации пригодится вам если вы хотите полностью заменить данные на сервере локальной копией. Скажем, после экспериментов или при восстановлении резервной копии. Вторая опция Удалить локальные данные и перегрузить данные с цели синхронизации понадобится вам гораздо чаще. Рекомендуем использовать ее для подключение нового чистого клиента, в противном случае на сервер у вас будут синхронизированы стандартные заметки по умолчанию или вам потребуется предварительно удалить их руками.

Школа китайского языка OneWord Открывается новый набор учеников! ✨ ✅ Занятия онлайн и офлайн ✅ Индивидуально или в мини-группах до 6 человек. На уроках говорим, слушаем, смеёмся над тонами (а потом уже не смеёмся 😊) и шаг за шагом начинаем понимать китайский по-настоящему. Если давно хотел начать — вот твой знак ❤️ Пиши нам, и мы поможем подобрать формат и уровень. А чтобы познакомиться поближе — первое занятие бесплатно! Записывайся на пробный урок или пиши нам в Telegram Записаться онлайн #реклама 16+ one-word.ru О рекламодателе

RouterOS long-term 7.20.7 – наконец то дождались! Новый год порадовал нас выходом первой long-term версии RouterOS 7. В линейке Mikrotik канал long-term не имеет четко обозначенных сроков поддержки, но это самый стабильный и консервативный канал с достаточно редким выпуском мажорных версий. Это означает появление некоторого островка стабильности, среза операционной системы, на котором разработчики сказали: «Стоп, хватит, система в таком виде готова, оставляем так». Именно с появлением long-term можно серьезно рассматривать переход на RouterOS 7 в продуктивных средах, опираясь на long-term как опорную точку. Нет, оно можно было и до этого, но тогда каждый новый релиз был лотереей, вы никогда не знали, что он принесет нового, удалит или поменяет старого. А менялось там много и часто. Мы пробовали писать статьи по RouterOS 7, но написав парочку отказались от этой затеи, так как тексты переделывать приходилось бы через релиз-два. Теперь ситуация изменилась. Да, система продолжит развиваться и выкатывать новые изменения в канале stable, но параллельно с ним у нас будет стабильный срез - long-term, на который мы можем ориентироваться как на некоторый эталон, по крайней мере до выхода следующего long-term. А также можно быть уверенным, что многое из того, что вошло в первый long-term релиз с нами надолго и именно в таком виде мы будем видеть и воспринимать RouterOS в ближайшее время. Особенно это касается тех частей системы, которые с начала ее выпуска активно изменялись.