Какой класс протоколов маршрутизации выбрать в underlay сети ЦОД — EGP vs IGP? 

Узнайте на бесплатном практическом уроке от OTUS, где вы вместе с опытным экспертом:

1. разберетесь с основами underlay сети ЦОД
2. сравните модный EGP и классический IGP
3. рассмотрите различные варианты маршрутизации в underlay сети ЦОД на практике

Вебинар будет полезен для всех, кто интересуется компьютерными сетями, действующих специалистов по маршрутизации и коммутации и сетевых инженеров ЦОД.

Занятие пройдёт 10 апреля в 20:00 мск и будет приурочено к старту курса «Дизайн сетей ЦОД».

Доступна рассрочка на обучение!

Пройдите короткий тест прямо сейчас, чтобы занять место на открытом уроке и получить запись:  https://clck.ru/39s9MF  

​​Как скачать DEB-пакет со всеми зависимостями

Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.

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

Все скачанные пакеты система размещает в каталоге /var/cache/apt/archives и там, кроме интересующих нас пакетов могут быть и разные другие, поэтому перед скачиванием нужно будет очистить кеш пакетов.

apt clean

После чего перейдем к скачиванию:

 

apt reinstall --download-only package_name

Почему именно reinstall? Потому что install будет работать только для неустановленных пакетов, а если пакет уже установлен в системе, то она сообщит об этом и не будет производить установку (в нашем случае скачивание, а reinstall скачает пакеты в любом случае.

Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:

dpkg --add-architecture i386
apt update

После чего точно также делаем:

apt reinstall --download-only package_name:i386

После чего переходим в /var/cache/apt/archives и копируем скачанные пакеты на любой съемный носитель и может передать их любым удобным способом в нужную систему для установки.

​​Зависимости DEB-пакетов

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

Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является dpkg, именно он занимается распаковкой и установкой пакетов. Упрощенно говоря, установка пакета состоит из двух этапов: распаковки и настройки.

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

Если в процессе настройки dpkg обнаруживает неудовлетворенные зависимости, то он прекращает настройку и пакет остается распакованным, но не настроенным, мы можем попытаться удовлетворить зависимости и заново попытаться настроить пакет.

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

Посмотреть зависимости можно командой:

apt-cache depends package_name

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

▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.

▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.

▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.

▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.

▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.

▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.

▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.

▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.

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

Зависимости типов рекомендует и предлагает предназначены для пользователя. При этом нужно помнить, что не всегда такие зависимости могут быть перечислены в пакете и их наличие следует искать в документации. Хороший пример – пакет шрифтов MS для 1С:Предприятие, их нет в зависимостях пакетов и продукт прекрасно работает без них, но страдает внешний вид текста.

Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.

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

IT-управленцы, не вздумайте начинать проекты, пока этого не узнаете!

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

Вы получите пошаговый план снижения связанности IT-контура, чтобы:

💻 Контролировать и управлять нагрузкой на IT-системы

💻 Легко менять/дорабатывать одни системы без доработки других

💻 Избавиться от единой точки отказа

💻 Внедрять изменения небольшими этапами, но с ощутимым результатом

Вебинар 12 апреля проведут наши друзья KT.Team.👇

Команда разрабатывает и интегрирует IT-решения для крупных клиентов уже 11 лет и входит в ТОП 100 IT-компаний России (по версии Tagline и RUWARD).

ЗАРЕГИСТРИРОВАТЬСЯ БЕСПЛАТНО

​​Версии PowerShell

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

На сегодняшний день существуют две версии PowerShell:

🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1

🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.

Windows PowerShell имеет следующие выпуски:

▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709

В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.

PowerShell Core имеет следующие выпуски:

▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell

▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.

PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.

Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.

Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.

​​Обновление Windows PowerShell

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

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

Для примера мы возьмем Windows Server 2008 R2, который хоть и снят с поддержки, но местами еще продолжает использоваться. Нам же он интересен как наиболее старая система и если у нас на ней все получится, то получится и на более новых.

Прежде всего узнаем текущую версию командой

host

В нашем случае мы получили вполне ожидаемое:

Version: 2.0

Поэтому начнем, прежде всего идем сюда https://www.microsoft.com/en-us/download/details.aspx?id=54616 и скачиваем Windows Management Framework 5.1 для вашей ОС.

Заглянув в системные требования уточняем, что нам также потребуется .NET Framework 4.5 или выше, качаем подходящую версию со страницы https://dotnet.microsoft.com/en-us/download/dotnet-framework, при этом также учитываем совместимость версии .NET с вашей системой, в данном случае мы скачали .NET Framework 4.5.2

Начинаем установку с обновления .NET Framework, после чего перезагружаем компьютер.

Теперь можно установить Windows Management Framework 5.1, после чего потребуется выполнить перезагрузку еще раз.

После чего еще раз проверяем версию Windows PowerShell и убеждаемся, что у нас стоит последняя актуальная версия.

Данную операцию мы рекомендуем выполнить на всех поддерживаемых системах чтобы привести среду Windows PowerShell к единой версии и избежать ошибок и неоднозначного поведения ваших PS-скриптов.

Присоединяйтесь к нашему бесплатному курсу и начните увлекательное путешествие в мир Java!

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

🎓 Чему вы научитесь:
— Создавать программы с использованием основных конструкций языка.
 — Разделять код на методы для повторного использования.
 — Анализировать ошибки в коде с использованием отладочной печати.

💼 Включено в курс:
29 уроков (видео и/или текст), 35 упражнений в тренажере, 95 проверочных тестов + дополнительные материалы.

Вы с нами?😉

Настройка файлового сервера ksmbd на платформе Debian / Ubuntu

Долгое время для организации файлового сервера, работающего по протоколу SMB, в Linux не было альтернативы Samba, но с недавних пор ситуация изменилась.

Начиная с ядра 5.15 в Linux появился новый модуль ядра - ksmbd - реализующий функции SMB-сервера. В отличии от Samba, которая имеет кроме файлового сервера широкий набор дополнительных функций, ksmbd, наоборот, только файловый сервер, простой и нетребовательный к ресурсам.

https://interface31.ru/tech_it/2023/06/nastroyka-faylovogo-servera-ksmbd-na-platforme-debian-ubuntu.html

​​Что такое PowerShell и чем он отличается от своих аналогов

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

Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.

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

Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.

К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.

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

Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.

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

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

Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.

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

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

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

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

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

Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.

Добавьте в свое портфолио кейс по решению задачи с микросервисной архитектурой бесплатно и всего за пару часов

На практическом уроке «Масштабируемая архитектура для систем обработки платежей».

На вебинаре:
- рассмотрим решение задачи по построению масштабируемой отказоустойчивой системы обработки платежей;
- обсудим применения шардирования, паттерна Saga, двухфазного коммита и выбор уровня изоляции транзакций;
- получим описание верхнеуровневой архитектуры.

Занятие пройдёт 24 апреля в 20:00 мск в рамках курса «Microservice Architecture». Доступна рассрочка на обучение!

👉 Чтобы посетить открытый урок, зарегистрируйтесь: https://otus.pw/VyJ7N/?erid=LjN8KBj18

​​И снова про алиасы в PowerShell

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

PowerShell предлагает большой набор встроенных алиасов, про них мы подробно писали в нашей заметке: https://t.iss.one/interface31/1767

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

Это как раз решает проблему многословности PowerShell при интерактивном использовании.

Можно ли создавать и применять в проде свои алиасы? Можно и даже нужно, если использовать их по назначению, а именно для интерактивной работы в консоли. Созданные алиасы без проблем можно выгружать и загружать на другой машине, для этого следует использовать команды Export-Alias и Import-Alias.

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

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

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

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

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

​​Что такое объектное хранилище S3 и в чем его основные особенности.

S3 (Simple Storage Service) – объектное хранилище и одноименное API доступа разработанное компанией Amazon и в настоящее время широко используемое многими облачными провайдерами, также существуют решения для создания собственных S3 хранилищ.

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

Начнем с того, что S3 – это не файловое хранилище, а объектное. Что это значит? А это значит, что мы можем хранить в нем не только файлы, а вообще любые двоичные данные, в любом формате.

Ведь что такое файл? Это именованная область на диске для хранения неких данных. В зависимости от типа хранимых данных используются разные форматы файлов, но это только один из частных случаев их, данных, размещения, хотя и самый привычный.

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

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

Для работы со всем этим используется протокол HTTP(S) и специальное S3 API, что серьезно упрощает работу с объектами на программном уровне. Вам не нужны клиенты, поддержка протоколов и файловых систем, просто нужно отправить запрос по HTTP и получить или разместить данные.

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

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

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

Для удобства пользователя S3 хранилище позволяют создавать псевдоиерархические структуры, т.н. контейнеры (бакеты, bucket), но на самом деле они являются всего лишь префиксами ключа и не создают никаких дополнительных сущностей в системе хранения.

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

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

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

Хотите освоить Scala? Начните с простого Web-сервиса на ZIO: zio-http + zio + quill

Приходите на бесплатный практический урок от OTUS. Спикер Алексей Воронец — руководитель разработки  в «NAUMEN».

💯 На примере построения простого веб-сервиса с REST API разберем основные компоненты (пути, бизнес логика, доступ к данным, документация) и посмотрим, как это можно реализовать в экосистеме ZIO.

Занятие пройдёт 22 апреля в 20:00 мск в рамках курса «Scala-разработчик». Доступна рассрочка на обучение!

Регистрируйтесь прямо сейчас, чтобы посетить бесплатный урок и получить запись: https://otus.pw/pJWG/?erid=LjN8KEUtW

​​День космонавтики

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

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

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

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

Да, до этого в космос летали животные, но для человека это был старт в неизвестность. И вот, 12 апреля 1961 года с космодрома Байконур был запущен космический корабль Восток-1, который выполнил один оборот вокруг земли и приземлился в Саратовской области.

Точнее приземлился не сам корабль, а первый космонавт Юрий Гагарин, который катапультировался из корабля на высоте 7 км и спускался отдельно на парашюте. Всего на орбите Юрий Алексеевич провел 108 минут.

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

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

А еще весь мир запомнил его бессмертное «Поехали!»

С днем космонавтики!