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

Миграция без простоев в защищенное облако РТК-ЦОД Переход в облако РТК-ЦОД — это гарантированная безопасность и надежность для вашего бизнеса. Почему выбирают нас? ✅ Соответствие стандартам безопасности: ФЗ-152, PCI DSS и др. ✅ Большое количество облачных сервисов под любые задачи. ✅ Экспертная поддержка на всех этапах миграции от нашей команды. ✅Геораспределенная сеть собственных дата-центров уровня TIER III. Начните с нами — легко и без рисков: — Бесплатная миграция: быстро и безопасно перенесем вашу инфраструктуру в облако. — 30 дней бесплатно: тестируйте наши сервисы с полным доступом ко всем возможностям. — Выделенный архитектор поддержки и технический менеджер при заказе от 1000 CPU. Оставьте заявку на www.cloud.rt.ru Узнать больше #реклама 16+ cloud.rt.ru О рекламодателе

​​Проверять нужно не только бекапы Третьего дня с одним нашим заказчиком произошла поучительная история. Обособленное подразделение в области. Классическая схема Proxmox VE + Proxmox Backup Server, связка, проверенная временем, ну что может пойти не так? Оказывается, очень даже может. Местный коллега все проверил, настроил уведомления на почту, убедился, что бекап делается корректно и разворачивается без ошибок, после чего со спокойной совестью занялся другими делами. А дальше все пошло не так. Бухгалтер, групповой обработкой сделала не совсем то, точнее совсем не то и восстанавливать руками весь второй квартал (полтора месяца) ей как-то не хотелось, поэтому она попросила админа достать базу из резервной копии, тем более что копии бухгалтерии делались каждые два часа. Какое же было удивление, когда наш коллега обнаружил, что последняя копия была создана вечером 14 мая. Как так? Почему? Где уведомления? Вопросов было больше, чем ответов. Причину нашли быстро, система после очередного копирования не удалила снимок и дальнейшее резервное копирование стало невозможно. Почему не удалила? В тот день отключали электричество, а бесперебойник не вытянул. Тут все понятно, бывает. Основной вопрос, который волновал как нас, так и нашего коллегу – почему не было уведомлений. Хотя в этом случае Proxmox должен регулярно сообщать о неудачном резервном копировании. Ответ на него нашелся быстро – все письма лежали в папке Спам Яндекс Почты. Причин тому может быть множество, соверменные почтовые системы используют самые различные алгоритмы. Но есть и «отягчающие обстоятельства». Офис расположен на первом этаже обычного жилого дома, и провайдер подключил интернет как «на квартиру», по тарифам для физических лиц. Выгодно? Да. Но есть и подводные камни, IP-адрес в таком случае тоже присваивается из пула для физических лиц, а все такие пулы по умолчанию стоят в черных списках, так как по негласной договоренности в таких сетях почтовых серверов быть не должно. Плюс почтовый сервер у нас тоже не настоящий, ни обратной зоны, ни ресурсных записей. А тут еще и адрес из домашнего пула. Вот Яндекс и не стал морочиться, отправив все сообщения в Спам. А они, как и положено, старательно отсылались. Коллега получил неприятный разговор с руководством, а бухгалтер сидит и думает, что ей проще: исправить документы с начала квартала или заново вбить все с 14 числа. Поэтому проверять надо не только бекапы, но и уведомления, триггеры и все с этим связанное. А также не забывать про регулярное изучение папки Спам и стараться использовать более одного канала оповещения.

Замена сбойного диска в массивах ZFS ZFS все чаще применяется в системах хранения Linux благодаря своим широким возможностям и отличной надежности. Но очень часто пользователи не имеют практических навыков работы с этой файловой системой, отдавая работу с ней на откуп вышестоящим системам, например, системе виртуализации Proxmox. Первые сложности начинаются когда пользователь сталкивается с необходимостью обслуживания ZFS и не находит для этого графических инструментов. Одна из таких задач - это замена сбойного диска в массиве, задача серьезная и ответственная, но в тоже время простая. В этой статье мы расскажем как это сделать. https://interface31.ru/tech_it/2024/08/zamena-sboynogo-diska-v-massivah-zfs.html

IT-школа Университета Иннополис. Бесплатный мастер-класс Онлайн-урок от ведущего ИТ ВУЗа страны для учеников 6-11 классов. 👍Бесплатно! ✅Научим основам программирования на языке Python. ✅Объясним, как создавать движущиеся объекты на экране и делать их интерактивными. ✅На практике отработаем полученные знания. ⚡Ваш ребёнок за один час самостоятельно создаст мини-анимацию по мотивам известного мультфильма «Вверх» и сможет использовать полученные знания в дальнейшем! Помогите ребёнку получить полезные навыки. Регистрируйтесь! Узнать больше #реклама 16+ progmatica.innopolis.university О рекламодателе

Хардлинки и симлинки, любой Linux-админ знает о них с детства. А как насчет Windows? Там тоже все это есть. Берем и используем! https://interface31.ru/tech_it/2022/05/rabotaem-s-zhestkimi-i-simvolicheskimi-ssylkami-v-windows.html

​​Что такое QUIC и HTTP/3 Вчера, в новой статье мы рассказали, как включить поддержку QUIC и HTTP/3 в веб-сервере Angie. Но далеко не все знают для чего и зачем это нужно. Начнем с того, что обычный HTTP давно уже перестал быть текстовым протоколом и передает самые различные данные и количество их от день ото дня растет. Современный сайт – это не просто страничка с текстом и картинками, а полноценное веб-приложение. И протокол TCP начал играть сдерживающую роль. Как мы все знаем, TCP – протокол с подтверждением доставки, если этого не случилось, то он будет посылать данные повторно. Ну это же не плохо? А это как посмотреть. Если к качеству связи нет претензий, то все работает хорошо, а если нет, то начинаются проблемы. Все данные прикладных протоколов, работающих поверх TCP, разбиваются на сегменты и помещаются в буфер отправки. Если сегмент доставлен получателю, то он удаляется из буфера и уступает место другому, если же нет, то он отправляется повторно. Таким образом мы можем получить ситуацию, когда сервер многократно отправляет одни и те же сегменты блокируя тем самым отправку других. Это называется проблемой блокировки очереди. Изначально, протокол HTTP и вовсе подразумевал отдельное соединение для каждого запроса, т.е. если на страничке есть десяток картинок, скриптов, стилей и иных элементов, то на каждое из них открывалось отдельное TCP-соединение. Это серьезно снижало производительность протокола, так как значительное время и ресурсы тратились на установление соединения, а не передачу данных. С шифрования ситуация стала еще хуже, так как добавились накладные расходы на согласование параметров шифрования и установление защищенного соединения. Многие эти проблемы были решены компанией Google в протоколе SPDY на базе которого впоследствии был создан HTTP/2. Хотя стандарт и не подразумевает обязательного шифрования фактическое использование HTTP/2 возможно только поверх TLS (TLS 1.2 и выше). В новом протоколе были решены многие проблемы производительности, в частности введена конвейеризация запросов и мультиплексирование их в одно TCP-соединение, это позволило значительно сократить накладные расходы и увеличить скорость работы протокола. Но проблема блокировки начала очереди никуда не делась и решить эту проблему можно было только сменой протокола транспортного уровня. И тут снова подсуетилась компания Google, разработав новый протокол QUIC, который использует в качестве транспорта UDP. Так как UDP не гарантирует доставку, то никакой блокировки начала очереди не может быть в принципе. Также UDP использует простую модель передачи без установления соединения, что также положительно влияет на производительность. При этом вопросы целостности данных и контроля доставки берет на себя протокол QUIC. Также QUIC сразу интегрирован с криптографией и требует для своей работы не ниже TLS 1.3. Также QUIC умеет повторно использовать текущее соединение даже при переподключении клиента на другой канал связи, что важно для мобильных пользователей. Точно также, как и в случае с HTTP/2 протокол QUIC лег в основу HTTP/3 и начинает постепенное распространение в сети интернет. Это не значит, что нужно прямо сейчас бежать добавлять поддержку HTTP/3 рабочим серверам. Но на новых установках при наличии возможности включить поддержку HTTP/3 это сделать желательно.

​​Что такое QUIC и HTTP/3 Вчера, в новой статье мы рассказали, как включить поддержку QUIC и HTTP/3 в веб-сервере Angie. Но далеко не все знают для чего и зачем это нужно. Начнем с того, что обычный HTTP давно уже перестал быть текстовым протоколом и передает самые различные данные и количество их от день ото дня растет. Современный сайт – это не просто страничка с текстом и картинками, а полноценное веб-приложение. И протокол TCP начал играть сдерживающую роль. Как мы все знаем, TCP – протокол с подтверждением доставки, если этого не случилось, то он будет посылать данные повторно. Ну это же не плохо? А это как посмотреть. Если к качеству связи нет претензий, то все работает хорошо, а если нет, то начинаются проблемы. Все данные прикладных протоколов, работающих поверх TCP, разбиваются на сегменты и помещаются в буфер отправки. Если сегмент доставлен получателю, то он удаляется из буфера и уступает место другому, если же нет, то он отправляется повторно. Таким образом мы можем получить ситуацию, когда сервер многократно отправляет одни и те же сегменты блокируя тем самым отправку других. Это называется проблемой блокировки очереди. Изначально, протокол HTTP и вовсе подразумевал отдельное соединение для каждого запроса, т.е. если на страничке есть десяток картинок, скриптов, стилей и иных элементов, то на каждое из них открывалось отдельное TCP-соединение. Это серьезно снижало производительность протокола, так как значительное время и ресурсы тратились на установление соединения, а не передачу данных. С шифрования ситуация стала еще хуже, так как добавились накладные расходы на согласование параметров шифрования и установление защищенного соединения. Многие эти проблемы были решены компанией Google в протоколе SPDY на базе которого впоследствии был создан HTTP/2. Хотя стандарт и не подразумевает обязательного шифрования фактическое использование HTTP/2 возможно только поверх TLS (TLS 1.2 и выше). В новом протоколе были решены многие проблемы производительности, в частности введена конвейеризация запросов и мультиплексирование их в одно TCP-соединение, это позволило значительно сократить накладные расходы и увеличить скорость работы протокола. Но проблема блокировки начала очереди никуда не делась и решить эту проблему можно было только сменой протокола транспортного уровня. И тут снова подсуетилась компания Google, разработав новый протокол QUIC, который использует в качестве транспорта UDP. Так как UDP не гарантирует доставку, то никакой блокировки начала очереди не может быть в принципе. Также UDP использует простую модель передачи без установления соединения, что также положительно влияет на производительность. При этом вопросы целостности данных и контроля доставки берет на себя протокол QUIC. Также QUIC сразу интегрирован с криптографией и требует для своей работы не ниже TLS 1.3. Также QUIC умеет повторно использовать текущее соединение даже при переподключении клиента на другой канал связи, что важно для мобильных пользователей. Точно также, как и в случае с HTTP/2 протокол QUIC лег в основу HTTP/3 и начинает постепенное распространение в сети интернет. Это не значит, что нужно прямо сейчас бежать добавлять поддержку HTTP/3 рабочим серверам. Но на новых установках при наличии возможности включить поддержку HTTP/3 это сделать желательно. В прошлой заметке мы рассказали, как включить поддержку QUIC и HTTP/3 в популярном веб-сервере NGINX. Но далеко не все знают для чего и зачем это нужно. Начнем с того, что обычный HTTP давно уже перестал быть текстовым протоколом и передает самые различные данные и количество их от день ото дня растет. Современный сайт – это не просто страничка с текстом и картинками, а полноценное веб-приложение. И протокол TCP начал играть сдерживающую роль. Как мы все знаем, TCP – протокол с подтверждением доставки, если этого не случилось, то он будет посылать данные повторно.

​​Ну это же не плохо? А это как посмотреть. Если к качеству связи нет претензий, то все работает хорошо, а если нет, то начинаются проблемы. Все данные прикладных протоколов, работающих поверх TCP, разбиваются на сегменты и помещаются в буфер отправки. Если сегмент доставлен получателю, то он удаляется из буфера и уступает место другому, если же нет, то он отправляется повторно. Таким образом мы можем получить ситуацию, когда сервер многократно отправляет одни и те же сегменты блокируя тем самым отправку других. Это называется проблемой блокировки очереди. Изначально, протокол HTTP и вовсе подразумевал отдельное соединение для каждого запроса, т.е. если на страничке есть десяток картинок, скриптов, стилей и иных элементов, то на каждое из них открывалось отдельное TCP-соединение. Это серьезно снижало производительность протокола, так как значительное время и ресурсы тратились на установление соединения, а не передачу данных. С шифрования ситуация стала еще хуже, так как добавились накладные расходы на согласование параметров шифрования и установление защищенного соединения. Многие эти проблемы были решены компанией Google в протоколе SPDY на базе которого впоследствии был создан HTTP/2. Хотя стандарт и не подразумевает обязательного шифрования фактическое использование HTTP/2 возможно только поверх TLS (TLS 1.2 и выше). В новом протоколе были решены многие проблемы производительности, в частности введена конвейеризация запросов и мультиплексирование их в одно TCP-соединение, это позволило значительно сократить накладные расходы и увеличить скорость работы протокола. Но проблема блокировки начала очереди никуда не делась и решить эту проблему можно было только сменой протокола транспортного уровня. И тут снова подсуетилась компания Google, разработав новый протокол QUIC, который использует в качестве транспорта UDP. Так как UDP не гарантирует доставку, то никакой блокировки начала очереди не может быть в принципе. Также UDP использует простую модель передачи без установления соединения, что также положительно влияет на производительность. При этом вопросы целостности данных и контроля доставки берет на себя протокол QUIC. Также QUIC сразу интегрирован с криптографией и требует для своей работы не ниже TLS 1.3. Также QUIC умеет повторно использовать текущее соединение даже при переподключении клиента на другой канал связи, что важно для мобильных пользователей. Точно также, как и в случае с HTTP/2 протокол QUIC лег в основу HTTP/3 и начинает постепенное распространение в сети интернет. Это не значит, что нужно прямо сейчас бежать добавлять поддержку HTTP/3 рабочим серверам. Но на новых установках при наличии возможности включить поддержку HTTP/3 это сделать желательно.

Методичка: как сделать онлайн-встречи эффективнее Надоело ждать коллег, которые постоянно забывают о встречах, а отсутствие повестки и потерянные договоренности мешают нормально работать? Команда МТС Линк собрала на 37 страницах полезные материалы, чек-листы и кейсы, которые помогают компаниям проводить эффективные совещания в онлайне с помощью сервиса Встречи. Из методички узнаете: - Как создать постоянную ссылку и подключаться на встречи в 2 клика, - Как делать заметки и работать с файлами, не переживая за качество связи и безопасность данных. - Как облегчает жизнь ИИ, который расшифровывает созвоны в текст и автоматически отправляет расшифровку на почту. Еще в методичке описаны 7 способов оценки текущей эффективности ваших онлайн-встреч. Получить гайд можно бесплатно на сайте. Скачать #реклама 16+ mts-link.ru О рекламодателе

​​Вектор развития В комментариях развернулась активная дискуссия на тему развития сотрудника и развития инфраструктуры предприятия. Многие ставят между этими понятиями знак равенства, хотя это совсем не так. Мы уже много раз писали на эту тему, поэтому не будем повторяться, но акцентируем внимание на ключевых тезисах. Сотрудник <> Бизнес (как бы иногда бизнесу и не хотелось продвинуть иную мысль). Бизнес занимается зарабатыванием денег, в чем его основной интерес. Сотрудник продает свое время и квалификацию за деньги – и никак иначе. А как по-другому? Бизнес его содержать в случае чего будет? Ага, держите карман шире. Поэтому интересы у сотрудника и бизнеса разные, в чем-то они совпадают, в чем-то расходятся. И это нормально. Не нормально, когда одна из сторон начинает путать собственные интересы с интересами контрагента, ни к чему хорошему это не приводит. Начнем с интересов бизнеса. Основной интерес- это получение прибыли. Прибыль – основа стабильной работы и развития предприятия. Падение прибыли приводит к экономии, в том числи и на ФОТ, сокращению рабочих мест и т.д. и т.п. В этом плане интересы сотрудника и бизнеса совпадают, сотрудник также заинтересован в нормальном функционировании бизнеса, иначе он потеряет в деньгах и, возможно, лишится рабочего места. Бизнес также заинтересован в удержании сотрудников, особенно тех, кого нельзя просто заменить с улицы. Но этот момент нужно понимать правильно, бизнес – не благотворительность. Если на линейную должность на улице стоит очередь – то и оклад там будет по нижней планке и выжимать будут все соки. А вот если это ключевой квалифицированный сотрудник, на которого завязаны многие важные бизнес-процессы, то подход будет совершенно иной. Потому что у бизнеса здесь прямой интерес, совпадающий с интересом сотрудника. Но вернемся к нашим баранам. IT – это такая сфера, которая никогда не стоит на месте и если мы хотим быть актуальными на рынке труда – то нужно постоянно развиваться. Никому не нужен сотрудник или подрядчик, который владеет технологиями десятилетней давности, пусть даже и в совершенстве. Поэтому интерес сотрудника развиваться вполне естественен и понятен. И еще ему хочется совместить приятное с полезным, а именно развиваться в рамках собственного предприятия за его счет и на его ресурсах. Но нужно ли это бизнесу? Есть заблуждение, что если бизнес не внедряет современные технологии, то он не развивается (в плане информационной инфраструктуры), но это не так. Бизнес тоже может развивать свою IT-инфраструктуру, только совсем не туда, куда смотрит сотрудник. Вместо современных технологий может внедрятся отказоустойчивость, кластеризация и прочие сложные и специфичные вещи, которые сотруднику не интересны. Ну не видит он куда их можно применить за воротами именно этого работодателя и кому продать их на рынке труда. А бизнесу, в свою очередь, не нужны все эти модные докеры, куберы и прочие современные технологии, у него другие задачи и потребности. В результате возникает расхождение интересов, вектор развития предприятия не совпадает с вектором развития сотрудника и это нормально. Для примера возьмем известную сеть Красное и Белое, информационная система у них до сих пор построена на устаревшей платформе 1С:Предприятие 7.7. Можно ли при этом сказать, что инфраструктура компании не развивается? Нет, нельзя, потому что они развиваются, внедряют современные технологии, ту же маркировку и прочее. Т.е. движутся собственным курсом к собственным целям и достаточно успешно. Но это курс бизнеса, который не совпадает с курсом сотрудника. Кому нужен в 2025 году специалист по «клюшкам» (жаргонное название 1Сv77)? Никому. Да, отнесутся с уважением, мол «монстр», но не более, на рынке труда спроса на таких специалистов нет. Какой выбор у сотрудника? А выбор невелик, либо связать свою карьеру именно с этой компанией и развиваться в общем направлении, понимая, что за забором перспектив нет, или начать движение по собственному вектору, приобретая знания и навыки, востребованные современным рынком.

Если тебе ближе дебаг мыслей ночью, чем сон — попробуй кубик сна deep. Усыпляет за 8 минут, не кодит, не шумит и не думает о тасках. Только качественный сон, даже если нет на него времени.  Просто включить, просто спать и просто ни о чём не думать! Минус: утром не хочется разбивать будильник.  А если у вас проблемы со сном, эксперты кубика сна deep определят их и найдут решение.  Реклама. Кузнецова А.М. ИНН 503227944098.

Настраиваем веб-сервер Angie + PHP + MySQL с сертификатами Let's Encrypt и поддержкой HTTP/3 Angie - форк известного веб-сервера nginx, созданный его бывшими разработчиками и преследующий цель стать лучшим nginx чем сам nginx и это не преувеличение. Начавшись как обычный проект импортозамещения Angie сегодня не только предоставляет все возможности nginx, но и предоставляет ряд новых функций и возможностей. А для пользователей, которым просто нужен веб-сервер Angie может предложить достаточно большой выбор готовых модулей в репозитории, это очень важное преимущество, так как в nginx для добавления тех или иных модулей вам потребуется самостоятельно пересобрать продукт. https://interface31.ru/tech_it/2025/05/nastraivaem-web-server-angie-php-mysql-lets-encrypt-http3.html

Освойте профессию Системный аналитик с нуля за 7 месяцев Освойте высокооплачиваемую IT-профессию без программирования. Выдаём диплом, помогаем с трудоустройством. Excel, BPMN, UML, Python, SQL, API Преимущества обучения в Академии Eduson: 🎓 22 реальных бизнес-кейса 🎓 официальный государственный диплом 🎓 рассрочка 0% на 24 мес. 🎓 бессрочный доступ к лекциям и материалам, которые регулярно обновляются 🎓 личный куратор с Вами на связи Начните обучаться онлайн и получать доход уже во время обучения! Получить скидку #реклама 16+ mrqz.me О рекламодателе

​​Что такое хорошо и что такое плохо В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации. В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту. Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо. Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо. Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны. Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны. Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями. Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались. Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее: - Ну это крутые пацаны из High Load рекомендуют? - А у тебя высокая нагрузка? - Нет, но… Или: - Ну это защита от сетевых атак… - Тебя кто-то атакует? - Нет, но… Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы. Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту. Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами. И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора». И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем. Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно. Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу. Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами. Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо. При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто. Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз. Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.

🚀 Стань JAVA-разработчиком с зарплатой от 130 000 ₽ Без предоплат. Без рассрочек. Ты платишь только после трудоустройства. Все риски на нас. Что ты получишь: ✔️ Актуальный стек: Java Core → Spring → Kafka → Docker и др. (только то, что реально нужно в работе). ✔️ Менторы из топовых IT-компаний — правят код, разбирают ошибки и готовят к собеседованиям. ✔️ Материалы подготовки к собеседованиям — собраны на основе 200+ реальных собеседований за последние 2 года. ✔️ Оплата — 17% от зарплаты (20 платежей, только за отработанные месяцы). Если не устроился — платить не нужно. Наши результаты: 🔥 Средняя зарплата выпускников — 200 000+ ₽ на руки. 🛡 Гарантия от 130 000 ₽ — иначе мы не возьмем ни копейки. Что нужно от тебя: ✅ Сдать тестовое задание. ✅ Уделять обучению от 20 часов в неделю. ✅ Сдавать модули в срок — иначе отчисляем (без поблажек). 👉 Узнай подробности и начни карьеру в IT! #реклама О рекламодателе

Настраиваем онлайн-радио на Icecast 2 и Ices с SSL защитой и сертификатами Let's Encrypt Современные технологии открывают нам достаточно широкие перспективы, особенно это касается мультимедийной составляющей. Сегодня собственным онлайн-вещанием никого не удивишь, более того оно становится просто обыденностью. Хотите удаленно слушать собственную музыкальную коллекцию? Или вам нужно организовать централизованную трансляцию в сети магазинов? Во всех этих случаях вас выручит создание собственного сервера онлайн-вещания. В данной статье мы рассмотрим, как сделать это при помощи бесплатного пакета Icecast 2 и организуем SSL-защиту при помощи сертификатов Let's Encrypt. ✅ Читать статью

Работа в IT: лучшие проекты на SkillStaff! Ищешь пространство для творческого роста и новые вызовы в карьере? ✅ SkillStaff – это платформа для IT-специалистов, маркетологов и дизайнеров, которые стремятся найти идеальную работу. Мы предлагаем тебе возможность работать на интересных проектах и развивать свои навыки 👍 🗒 Регистрация на SkillStaff открывает тебе доступ к сообществу профессионалов, стремящихся к развитию. 👌 Мы поможем тебе находить проекты, которые соответствуют твоим знаниям и интересам. Не упусти возможность развивать свою карьеру! Присоединяйтесь к SkillStaff прямо сейчас! Перейти на сайт #реклама skillstaff.ru О рекламодателе

Отключаем автоматический вход пользователя в 1С:Предприятие 8.3.26 и старше В платформе 1С:Предприятие, начиная с выпуска 8.3.26 добавили возможность автоматического входа под последним успешно вошедшим пользователем. Функция в чем-то удобная, особенно если на рабочем месте работает единственный пользователь. Но реализация как всегда… Если пользователь установит флажок Запомнить, то на этом рабочем месте 1С начнет автоматически заходить в эту базу под последним успешно вошедшим пользователем и нет никакого простого способа изменить это поведение. Это вводит в ступор не только пользователей, но и администраторов. Вплоть до того, что они просто сносят платформу и устанавливают заново, зачастую с нулевым результатом. Однако все достаточно просто, чтобы вернуть выбор пользователя в параметры запуска информационной базы нужно добавить ключ:

/ResetSavedAuth

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

IT- джун — это уже не билет в будущее, а точка входа на пересдачу? Рынок стал умнее: джуна теперь не спасает знание одного фреймворка. Нужны гибкие навыки, понимание что ты делаешь — а не просто как. Всё чаще спрашивают: «Ты умеешь думать как бизнес?» — а не только «Ты писал на Go?» Документирование процессов — не занудство, а скилл, который резко поднимает тебя над остальными джунами. Хочешь понимать, зачем ты пишешь фичу — а не просто «по ТЗ»? 📍 Приходи на вебинар «Описание бизнес-процессов» @iFellowLessonsBot 🔎 Разберёмся: что такое бизнес-процессы и зачем их вообще описывать; как фиксировать процессы — в тексте и на схемах; покажем живые примеры и фейлы, которых лучше не повторять. Перейди — и прокачай скилл, который выделит тебя среди джунов @iFellowLessonsBot 🎯 Для: начинающих IT-специалистов, которым важно расти не только по синьору, но и по смыслу Реклама. ООО "НИКТО". ИНН 9723224707. erid: 2W5zFG6F912

​​Самоподписанные сертификаты. Мифы и реальность Вокруг самоподписанных сертификатов каких только мифов не собрано. Если не вдаваться в подробности, то все они сводятся к тому, что самоподписанный сертификат не безопасен и не предоставляет надежного шифрования. И ставить его в продакшен – ну такое… Но стоит начать задавать уточняющие вопросы как выясняется, что редко кто может толком пояснить чем же небезопасен самоподписанный сертификат и что в нем такого ненадежного. Начнем с того, что надежность шифрования не зависит от сертификата, сертификат нужен нам для формирования ключей шифрования, а надежность шифрования зависит от применяемого набора шифров. Мы вполне можем использовать «настоящий» сертификат и слабые шифры и это будет менее надежно, чем самоподписанный сертификат и сильные шифры. Так в чем же тогда проблема? В доверии. Вся инфраструктура открытых ключей (PKI) строится на вопросе доверия, ключевым звеном в вопросе доверия является удостоверяющий центр (CA), которому мы однозначно доверяем. После того, как мы поместим корневой сертификат CA в хранилище доверенных корневых сертификатов мы можем проверить любой выданный этим удостоверяющим центром сертификат и убедиться в том, что он действителен. Также мы можем проверить сертификат на отзыв, при помощи все того же удостоверяющего центра. Если нам нужно выпускать собственные сертификаты, то мы можем создать собственный CA и распространив его корневой сертификат внутри своей инфраструктуры обеспечим доверительные отношения к любым выпущенным им сертификатам. Корневой сертификат удостоверяющего центра не является секретным, но перед его установкой нам следует убедиться, что мы устанавливаем именно тот сертификат, который нам нужен. Для этого нужно сравнить цифровой отпечаток с предоставленным вам по надежным каналам владельцем сертификата или с опубликованным в официальном источнике. А теперь перейдем к самоподписанным сертификатам. При его создании не используется никакой удостоверяющий центр и сертификат подписывает себя самостоятельно собственной сигнатурой. Таким образом мы не можем проверить действительность сертификата и установить с ним доверительные отношения. Нам остается только поверить или проверить его цифровой отпечаток запросив его у владельца сертификата. Вариант «поверить» на практике выливается в постоянное игнорирование предупреждения о доверии сертификату, что притупляет бдительность и дает прекрасную возможность осуществить атаку MitM, перехватив трафик и предоставив поддельный сертификат. Все равно его никто не проверяет. Вариант «проверить» также связан с определенными сложностями, вам нужно получить от владельца сертификата по заслуживающему доверию каналу его цифровой отпечаток и сравнить его с тем, который предоставляет удаленный узел. Хорошо, проверили и убедились, что это действительно реальный сертификат узла, но не будем же мы это делать каждый раз? Не будем, чтобы избежать постоянного предупреждения такой сертификат также нужно добавить в хранилище корневых доверенных сертификатов. Подводя итог, скажем следующее, самоподписанные сертификаты ничем не отличаются от любых других и их использование не несет никаких технических угроз безопасности. Основная проблема самоподписанного сертификата – это вопрос доверия, точнее крайняя сложность в установлении доверительных отношений, если только вы сами не являетесь стороной выпустившей такой сертификат. Кроме того, такой сертификат нельзя отозвать, нет, вы можете выпустить новый самоподписанный сертификат, но старый останется действительным до конца срока действия, что может привести к нежелательным последствиям в случае его компрометации. Так можно ли использовать такие сертификаты? Можно, если вы представляете все сопутствующие проблемы и риски и готовы их решать. Но лучше все таки создать собственный удостоверяющий центр и выпускать сертификаты с его помощью, что позволит вам более гибко управлять процессом и уменьшит количество потенциально опасных ситуаций связанных с доверием.