20 марта ИТ руководители ADV Group, Сталепромышленная компания и M1Cloud поделятся практическим опытом построения индивидуальных решений облачной ИТ-инфраструктуры.
На вебинаре спикеры поделятся опытом кастомизации облака под особые требования ИТ и бизнеса в сфере:
- производительности вычислительных ресурсов
- сетевой связанности
- информационной безопасности
- отказоустойчивых DR-решений
- мониторинга и др.
Приглашаем на вебинар всех, кто отвечает за ИТ-инфраструктуру и рассматривает индивидуальные облачные решения.
Участие бесплатное.
Посмотреть программу и зарегистрироваться
Реклама. ООО "СТЕК ГРУПП". ИНН 7729739360.
На вебинаре спикеры поделятся опытом кастомизации облака под особые требования ИТ и бизнеса в сфере:
- производительности вычислительных ресурсов
- сетевой связанности
- информационной безопасности
- отказоустойчивых DR-решений
- мониторинга и др.
Приглашаем на вебинар всех, кто отвечает за ИТ-инфраструктуру и рассматривает индивидуальные облачные решения.
Участие бесплатное.
Посмотреть программу и зарегистрироваться
Реклама. ООО "СТЕК ГРУПП". ИНН 7729739360.
👍2
Обновление ОС Альт Сервер 10.2 и Альт Рабочая станция 10.2
Буквально на днях, 13 марта компания Базальт СПО выпустила сообщение о выходе новых версий своих основных продуктов Альт Сервер и Альт Рабочая станция, которые получили очередное обновления в рамках платформы 10.
Для Рабочей станции изменений не много, самым важным из них является профиль для установки на btrfs с подтомами для поддержки timeshift.
Также добавлен репозиторий для установки Р7-Офис.
А вот для Альт Сервер изменений гораздо больше, разработчики проанализировали основные сценарии использования и подготовили новый набор профилей при установке, теперь доступны:
▫️Офисный сервер
▫️Сервер Samba-DC (контроллер домена Active Directory)
▫️Домашний сервер
▫️Минимальная установка.
Для роли Домашнего сервера автоматически устанавливается графическая оболочка MATE.
Также оптимизирована работа с сетью и улучшена поддержка оборудования, в том числе и в среде восстановления.
Но самое важное изменение коснулось лицензионной политики:
1.5. Настоящим договором не предусмотрено предоставление прав на использование дистрибутива в качестве хоста виртуализации. При необходимости использовать данную функцию, нужно приобрести лицензию на «Альт Виртуализация».
Хост виртуализации — сервер, предоставляющий сервис доступа к виртуальным машинам и/или контейнерам.
При нарушении данного условия ООО «Базальт СПО» не оказывает техническую поддержку ДИСТРИБУТИВА, а лицензионный договор на такой ДИСТРИБУТИВ считается незаключенным, если иное не указано в письменном соглашении сторон.
Таким образом легальной возможности использовать сборку Proxmox от Альта на базе Альт Сервер больше нет. Хотя все еще остается возможность использовать для этого Стартовый набор (Starterkit), но в этом случае про Реестр и техподдержку можно сразу забыть.
При этом лицензия не допускает разночтений, хотя на некоторых ресурсах пишут, что мол можно установить, но не будет поддержки, потому как четко указано, что при нарушении п. 1.5 лицензионное соглашение считается незаключенным, что лишает вас права легально использовать такой экземпляр ОС.
Буквально на днях, 13 марта компания Базальт СПО выпустила сообщение о выходе новых версий своих основных продуктов Альт Сервер и Альт Рабочая станция, которые получили очередное обновления в рамках платформы 10.
Для Рабочей станции изменений не много, самым важным из них является профиль для установки на btrfs с подтомами для поддержки timeshift.
Также добавлен репозиторий для установки Р7-Офис.
А вот для Альт Сервер изменений гораздо больше, разработчики проанализировали основные сценарии использования и подготовили новый набор профилей при установке, теперь доступны:
▫️Офисный сервер
▫️Сервер Samba-DC (контроллер домена Active Directory)
▫️Домашний сервер
▫️Минимальная установка.
Для роли Домашнего сервера автоматически устанавливается графическая оболочка MATE.
Также оптимизирована работа с сетью и улучшена поддержка оборудования, в том числе и в среде восстановления.
Но самое важное изменение коснулось лицензионной политики:
1.5. Настоящим договором не предусмотрено предоставление прав на использование дистрибутива в качестве хоста виртуализации. При необходимости использовать данную функцию, нужно приобрести лицензию на «Альт Виртуализация».
Хост виртуализации — сервер, предоставляющий сервис доступа к виртуальным машинам и/или контейнерам.
При нарушении данного условия ООО «Базальт СПО» не оказывает техническую поддержку ДИСТРИБУТИВА, а лицензионный договор на такой ДИСТРИБУТИВ считается незаключенным, если иное не указано в письменном соглашении сторон.
Таким образом легальной возможности использовать сборку Proxmox от Альта на базе Альт Сервер больше нет. Хотя все еще остается возможность использовать для этого Стартовый набор (Starterkit), но в этом случае про Реестр и техподдержку можно сразу забыть.
При этом лицензия не допускает разночтений, хотя на некоторых ресурсах пишут, что мол можно установить, но не будет поддержки, потому как четко указано, что при нарушении п. 1.5 лицензионное соглашение считается незаключенным, что лишает вас права легально использовать такой экземпляр ОС.
👍9🤔6❤1
Облака – говорили они. Microsoft, Amazon и Google прекращают доступ к облачным сервисам с 20 марта
Microsoft отправила российским компаниям письмо о том, что c 20 марта 2024 года закроет доступ к своим облачным продуктам. Информацию о письме подтвердили в ГК Softline, а также сообщили о получении аналогичной информации и от Amazon.
В связи с этим ГК Softline предупреждает о возможных функциональных ограничениях в работе облачных продуктов и сервисов Microsoft, Amazon и Google
Поспешим успокоить, речь пока не идет об обычных облачных решениях, а касается в первую очередь программного обеспечения для управления или проектирования (включая облачные решения) в связи с новыми санкциями ЕС.
У Microsoft это, например, Power BI и Dynamics CRM, при этом формулировка в направленных письмах носит размытый характер: включая, но не ограничиваясь.
Но мы бы не советовали расслабляться, если вы используете западные облачные сервисы, то совершенно не лишним будет сделать резервные копии размещенных там данных, а также продумать возможный переезд на отечественные аналоги или собственные вычислительные мощности.
Microsoft отправила российским компаниям письмо о том, что c 20 марта 2024 года закроет доступ к своим облачным продуктам. Информацию о письме подтвердили в ГК Softline, а также сообщили о получении аналогичной информации и от Amazon.
В связи с этим ГК Softline предупреждает о возможных функциональных ограничениях в работе облачных продуктов и сервисов Microsoft, Amazon и Google
Поспешим успокоить, речь пока не идет об обычных облачных решениях, а касается в первую очередь программного обеспечения для управления или проектирования (включая облачные решения) в связи с новыми санкциями ЕС.
У Microsoft это, например, Power BI и Dynamics CRM, при этом формулировка в направленных письмах носит размытый характер: включая, но не ограничиваясь.
Но мы бы не советовали расслабляться, если вы используете западные облачные сервисы, то совершенно не лишним будет сделать резервные копии размещенных там данных, а также продумать возможный переезд на отечественные аналоги или собственные вычислительные мощности.
🤣25👍13🔥7🤯3
Каких поставщиков облачных решений вы используете?
Anonymous Poll
12%
В основном зарубежных
15%
В основном отечественных
4%
Примерно пополам
19%
В основном собственные сервисы
3%
Переходим на отечественные
4%
Переходим на собственные
0%
Свой вариант ответа (в комментариях)
7%
Ничего не понятно, но очень интересно
35%
Не используем облака вообще
erid: LjN8KXuRA
Как эффективно разделять приложения на микросервисы?
🔥 Расскажет Евгений Непомнящий — разработчик в IT Sense.
Встречаемся на бесплатном практическом уроке от OTUS, где вы вместе с опытным экспертом:
- рассмотрите принципы функциональной декомпозиции;
- научитесь выделять отдельные компоненты приложения;
- погрузитесь в методику EventStorming;
- изучите подход API First Design;
- узнаете, как разрабатывать API.
Встречаемся 19 марта в 20:00 мск в рамках курса «Software Architect». Доступна рассрочка на обучение!
👉 Зарегистрируйтесь, чтобы посетить бесплатный урок и получить запись.
Как эффективно разделять приложения на микросервисы?
🔥 Расскажет Евгений Непомнящий — разработчик в IT Sense.
Встречаемся на бесплатном практическом уроке от OTUS, где вы вместе с опытным экспертом:
- рассмотрите принципы функциональной декомпозиции;
- научитесь выделять отдельные компоненты приложения;
- погрузитесь в методику EventStorming;
- изучите подход API First Design;
- узнаете, как разрабатывать API.
Встречаемся 19 марта в 20:00 мск в рамках курса «Software Architect». Доступна рассрочка на обучение!
👉 Зарегистрируйтесь, чтобы посетить бесплатный урок и получить запись.
Особенности использования аппаратных ключей HASP для 1С:Предприятие
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.111.10, 192.168.111.11
NH_SERVER_NAME = HASP_LM1, HASP_LM2
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
👍22
Программные и аппаратные лицензии 1С, сходства и различия.
Комментарии к предыдущей заметке показали, что многие читатели не до конца представляют все различия между двумя типами лицензий и подвержены многим предрассудкам и заблуждениям.
Начнем с того, что в основе лицензионной политики 1С, как это ни странно, лежит ЛИЦЕНЗИЯ.
Лицензия может быть однопользовательской, которая позволяет запускать неограниченное число сеансов 1С на одном ПК. Точнее в рамках одной пользовательской сессии, поэтому они так и называются – однопользовательские.
А для терминального сервера вам понадобится по одной однопользовательской лицензии на каждый сеанс пользователя.
Важно понимать, что однопользовательскую лицензию получает сам компьютер и неважно как он это делает.
Второй вид лицензий – многопользовательские, их выдает исключительно сервер и/или веб-сервер по одной на каждый активный сеанс.
При этом что в том, что в другом случае никакого значения тип лицензии (аппаратный или программный) не играет. Важны только сами лицензии.
Сами же лицензии могут быть аппаратными или программными. Начнем с последних.
Лицензии данного типа могут быть однопользовательские (на 1 рабочее место), комбинированные (5, 10 и 20 лицензий) и многопользовательские (от 50 лицензий и более).
Однопользовательская лицензия привязывается к ПК и позволяет запускать там неограниченное число сеансов. При смене ПК либо оборудования к которому привязывается лицензия потребуется повторная активация.
Комбинированные лицензии мы можем активировать как однопользовательские, тогда на каждом ПК используем отдельный пин, либо как многопользовательские, активировав сразу все количество на сервере. Совмещение режимов в рамках одной лицензии не допускается.
Однопользовательская лицензия на 1 рабочее место также может быть активирована на сервере и тогда она будет использоваться как многопользовательская. Все активированные на сервере комплекты лицензий суммируются.
Аппаратные лицензии привязываются к HASP ключу. Однопользовательский ключ (фиолетовый) позволяет использовать единственную лицензию только локально, вы не сможете добавить ее на терминальный сервер или сервер 1С как многопользовательскую.
По свойствам она ничем не отличается от программной однопользовательской, позволяя запускать неограниченное число сеансов на одном ПК.
Многопользовательские сетевые ключи (красные) ни в коем случае не следует путать с многопользовательскими лицензиями. Лицензии там комбинированного типа и могут одновременно использоваться в обоих режимах.
А далее все зависит от того, каким образом эта лицензия будет выдана. Для раздачи лицензий по сети предназначена служба HASP License Manager.
Если лицензию от службы HASP LM получает непосредственно ПК, то такая лицензия используется как однопользовательская.
Если же лицензию выдает сервер и/или веб-сервер с локально установленного сетевого ключа или полученную через службу HASP LM, то она используется как многопользовательская.
Таким образом аппаратные лицензии не дают никакого выигрыша по числу лицензии или сеансов, так как решающее значение имеет только количество лицензий.
К плюсам аппаратных лицензий можно отнести привязку к ключу, а не к компьютеру, что позволяет более просто менять оборудование.
Минусы – более высокие требования к сети и потенциально возможные ситуации резкого исчерпания лицензий в том случае, если компьютер перестал видеть HASP LM и начал получать лицензии с сервера.
При наличии более одного сетевого ключа начинаются сложности с их размещением и поиском, при этом крайне желательно на каждом ПК явно прописать адреса служб HASP LM, в противном случае при ряде условий если компьютер первым находит ключ не содержащий свободных лицензий, то дальнейший поиск ключей не будет продолжен.
Также аппаратный ключ невозможно восстановить при утере. При выходе из строя или физическом повреждении восстановление возможно только при возврате неисправного ключа.
Для восстановления программной лицензии достаточно регистрационной анкеты.
Комментарии к предыдущей заметке показали, что многие читатели не до конца представляют все различия между двумя типами лицензий и подвержены многим предрассудкам и заблуждениям.
Начнем с того, что в основе лицензионной политики 1С, как это ни странно, лежит ЛИЦЕНЗИЯ.
Лицензия может быть однопользовательской, которая позволяет запускать неограниченное число сеансов 1С на одном ПК. Точнее в рамках одной пользовательской сессии, поэтому они так и называются – однопользовательские.
А для терминального сервера вам понадобится по одной однопользовательской лицензии на каждый сеанс пользователя.
Важно понимать, что однопользовательскую лицензию получает сам компьютер и неважно как он это делает.
Второй вид лицензий – многопользовательские, их выдает исключительно сервер и/или веб-сервер по одной на каждый активный сеанс.
При этом что в том, что в другом случае никакого значения тип лицензии (аппаратный или программный) не играет. Важны только сами лицензии.
Сами же лицензии могут быть аппаратными или программными. Начнем с последних.
Лицензии данного типа могут быть однопользовательские (на 1 рабочее место), комбинированные (5, 10 и 20 лицензий) и многопользовательские (от 50 лицензий и более).
Однопользовательская лицензия привязывается к ПК и позволяет запускать там неограниченное число сеансов. При смене ПК либо оборудования к которому привязывается лицензия потребуется повторная активация.
Комбинированные лицензии мы можем активировать как однопользовательские, тогда на каждом ПК используем отдельный пин, либо как многопользовательские, активировав сразу все количество на сервере. Совмещение режимов в рамках одной лицензии не допускается.
Однопользовательская лицензия на 1 рабочее место также может быть активирована на сервере и тогда она будет использоваться как многопользовательская. Все активированные на сервере комплекты лицензий суммируются.
Аппаратные лицензии привязываются к HASP ключу. Однопользовательский ключ (фиолетовый) позволяет использовать единственную лицензию только локально, вы не сможете добавить ее на терминальный сервер или сервер 1С как многопользовательскую.
По свойствам она ничем не отличается от программной однопользовательской, позволяя запускать неограниченное число сеансов на одном ПК.
Многопользовательские сетевые ключи (красные) ни в коем случае не следует путать с многопользовательскими лицензиями. Лицензии там комбинированного типа и могут одновременно использоваться в обоих режимах.
А далее все зависит от того, каким образом эта лицензия будет выдана. Для раздачи лицензий по сети предназначена служба HASP License Manager.
Если лицензию от службы HASP LM получает непосредственно ПК, то такая лицензия используется как однопользовательская.
Если же лицензию выдает сервер и/или веб-сервер с локально установленного сетевого ключа или полученную через службу HASP LM, то она используется как многопользовательская.
Таким образом аппаратные лицензии не дают никакого выигрыша по числу лицензии или сеансов, так как решающее значение имеет только количество лицензий.
К плюсам аппаратных лицензий можно отнести привязку к ключу, а не к компьютеру, что позволяет более просто менять оборудование.
Минусы – более высокие требования к сети и потенциально возможные ситуации резкого исчерпания лицензий в том случае, если компьютер перестал видеть HASP LM и начал получать лицензии с сервера.
При наличии более одного сетевого ключа начинаются сложности с их размещением и поиском, при этом крайне желательно на каждом ПК явно прописать адреса служб HASP LM, в противном случае при ряде условий если компьютер первым находит ключ не содержащий свободных лицензий, то дальнейший поиск ключей не будет продолжен.
Также аппаратный ключ невозможно восстановить при утере. При выходе из строя или физическом повреждении восстановление возможно только при возврате неисправного ключа.
Для восстановления программной лицензии достаточно регистрационной анкеты.
👍33❤3🤮1
Порядок получения лицензий 1С:Предприятия клиентским приложением
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
UseHwLicenses=0 в конфигурационном файле 1cestart.cfg, который отключит поиск лицензий на аппаратных ключах.
👍28🤮1
Порядок получения лицензий 1С:Предприятия веб-клиентом
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
👍15🤮2👀2
Какой тип клиента 1С вы предпочитаете использовать? Можно выбрать несколько вариантов
Anonymous Poll
42%
Тонкий клиент на клиенстком ПК
29%
Тонкий клиент на терминальном сервере
13%
Толстый клиент (для устаревших конфигураций) на клиентском ПК
16%
Толстый клиент (для устаревших конфигураций) на терминальном сервере
22%
Тонкий клиент через веб-сервер
10%
Веб-клиент
19%
Ничего не понятно, но очень интересно
👍6🤮5
Мимикрия
Столкнулся я не так давно с жесткими дисками некой китайской компании BaseTech. Требовалась стопка чего-то недорогого и небольшого по объему.
Как раз для этих задач китайцы в самый раз. Китайские SSD давно не вызывают ни удивления, ни каких-то особых опасений. Обычные бюджетные диски со стандартными характеристиками.
Но китайцы не были бы китайцами, если бы не стремились казаться, а не быть. Возможно, на китайском рынке это и работает, но на нашем вызывает только улыбку.
Сам по себе BaseTech A400 особых ассоциаций не вызвал, ну мало ли, просто совпадение с одной из самых популярных бюджетных моделей.
Но когда я зашел на сайт посмотреть, что это вообще за производитель и что еще производит, то был крайне удивлен моделью BaseTech 970 EVO PLUS, явной отсылкой к одному из лидеров рынка.
Поиском также нашлась ныне отсутствующая в продаже модель BaseTech MX 500 и пазл полностью сложился. Непонятно только зачем вся эта мимикрия…
Столкнулся я не так давно с жесткими дисками некой китайской компании BaseTech. Требовалась стопка чего-то недорогого и небольшого по объему.
Как раз для этих задач китайцы в самый раз. Китайские SSD давно не вызывают ни удивления, ни каких-то особых опасений. Обычные бюджетные диски со стандартными характеристиками.
Но китайцы не были бы китайцами, если бы не стремились казаться, а не быть. Возможно, на китайском рынке это и работает, но на нашем вызывает только улыбку.
Сам по себе BaseTech A400 особых ассоциаций не вызвал, ну мало ли, просто совпадение с одной из самых популярных бюджетных моделей.
Но когда я зашел на сайт посмотреть, что это вообще за производитель и что еще производит, то был крайне удивлен моделью BaseTech 970 EVO PLUS, явной отсылкой к одному из лидеров рынка.
Поиском также нашлась ныне отсутствующая в продаже модель BaseTech MX 500 и пазл полностью сложился. Непонятно только зачем вся эта мимикрия…
😁17
Предсказуемые имена сетевых интерфейсов systemd
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
👍43👀2
Какую схему назначения имен вы предпочитаете?
Anonymous Poll
7%
Только ethX
23%
Если возможно, то ethX
4%
Предсказуемые имена, хотя это неудобно
10%
Предсказуемые имена, это удобно
34%
Мне все равно, работаю с любой схемой
3%
Сам назначаю имена интерфейсам
2%
Использовать systemd не позволяет религия
17%
Ничего не понятно, но очень интересно
👍9🌭1
Полный список блокировки программных продуктов от Microsoft
По сообщению Softline Microsoft заблокирует доступ к следующим программным продуктам на территории России:
▫️для управления бизнес-процессами BizTalk Server;
▫️для корпоративного учёта Dynamics 365, Dynamics AX, Dynamics NAV;
▫️для автоматизации Power Automate, PowerShell, AKS Edge Essentials;
▫️для бизнес-анализа Power BI и управления проектами Project;
▫️для управления ИТ-средой System Center;
▫️для совместной работы SharePoint, Office SharePoint Server, Duet Microsoft/SAP;
▫️для МСП Small Business Server Essentials;
▫️для мониторинга сервисов Systems Center Operations Manager;
▫️для сотрудников Viva, Glint;
▫️для планирования ресурсов предприятия Dynamic;
▫️для управления конечными точками Intune;
▫️для управления цифровой идентификацией Forefront Identity Manager, Forefront TMG, Forefront UAG;
▫️для разработки конструктор приложений Power Apps, создатель диалоговых инструментов Power Virtual Agent;
▫️для разработки форм ввода данных InfoPath;
▫️для разработчиков и дизайнеров Expression Studio;
▫️для разработки форм ввода данных InfoPath, Office InfoPath Forms Server;
платформу для построения приложений Xamarin;
▫️графический редактор Office Visio;
▫️Excel, Microsoft 365, Microsoft Teams;
▫️хранилища OneDrive;
▫️облачной платформе Azure;
▫️комплекта из решений Azure Stack, Azure DevOps Server, Azure HPC, Azure Private 5G Core и Azure Stack HCI;
▫️издательской системы Publisher;
▫️ПО для работы с базами данных на СУБД Access и SQL Server;
▫️Microsoft Data Access Components (комплекс ПО, обеспечивающий единую структуру для доступа к различным источникам данных на Windows);
▫️инструменту управления продажами LinkedIn Sales Navigator;
▫️комплекту для разработки ПО для проигрывателя Windows Media;
▫️ИИ-помощнику Copilot;
▫️к продукту для создания систем e-commerce Commerce Server
Также будет ограничен корпоративный доступ к среде разработки программ Visual Studio, к Visual C++ и Visual Studio Code.
Напоминаем, блокировка вступает в силу 20 марта, т.е. уже завтра.
По сообщению Softline Microsoft заблокирует доступ к следующим программным продуктам на территории России:
▫️для управления бизнес-процессами BizTalk Server;
▫️для корпоративного учёта Dynamics 365, Dynamics AX, Dynamics NAV;
▫️для автоматизации Power Automate, PowerShell, AKS Edge Essentials;
▫️для бизнес-анализа Power BI и управления проектами Project;
▫️для управления ИТ-средой System Center;
▫️для совместной работы SharePoint, Office SharePoint Server, Duet Microsoft/SAP;
▫️для МСП Small Business Server Essentials;
▫️для мониторинга сервисов Systems Center Operations Manager;
▫️для сотрудников Viva, Glint;
▫️для планирования ресурсов предприятия Dynamic;
▫️для управления конечными точками Intune;
▫️для управления цифровой идентификацией Forefront Identity Manager, Forefront TMG, Forefront UAG;
▫️для разработки конструктор приложений Power Apps, создатель диалоговых инструментов Power Virtual Agent;
▫️для разработки форм ввода данных InfoPath;
▫️для разработчиков и дизайнеров Expression Studio;
▫️для разработки форм ввода данных InfoPath, Office InfoPath Forms Server;
платформу для построения приложений Xamarin;
▫️графический редактор Office Visio;
▫️Excel, Microsoft 365, Microsoft Teams;
▫️хранилища OneDrive;
▫️облачной платформе Azure;
▫️комплекта из решений Azure Stack, Azure DevOps Server, Azure HPC, Azure Private 5G Core и Azure Stack HCI;
▫️издательской системы Publisher;
▫️ПО для работы с базами данных на СУБД Access и SQL Server;
▫️Microsoft Data Access Components (комплекс ПО, обеспечивающий единую структуру для доступа к различным источникам данных на Windows);
▫️инструменту управления продажами LinkedIn Sales Navigator;
▫️комплекту для разработки ПО для проигрывателя Windows Media;
▫️ИИ-помощнику Copilot;
▫️к продукту для создания систем e-commerce Commerce Server
Также будет ограничен корпоративный доступ к среде разработки программ Visual Studio, к Visual C++ и Visual Studio Code.
Напоминаем, блокировка вступает в силу 20 марта, т.е. уже завтра.
🤡32👍22🤬18😁3🤯3
Устанавливаем OpenVPN в LXC-контейнер
Контейнеры LXC пользуются заслуженной популярностью и широко используются в системе виртуализации Proxmox.
Однако если вы попытаетесь развернуть в контейнере не менее популярный OpenVPN, то у вас ничего не получится.
Но не стоит отчаиваться, решение есть, и оно простое. Только совсем не очевидное. Поэтому мы и решили после очередного вопроса написать эту заметку.
Открываем на хосте виртуализации
Сохраняем изменения, запускаем контейнер и спокойно устанавливаем в него OpenVPN как обычно, или запускаем уже установленный.
Контейнеры LXC пользуются заслуженной популярностью и широко используются в системе виртуализации Proxmox.
Однако если вы попытаетесь развернуть в контейнере не менее популярный OpenVPN, то у вас ничего не получится.
Но не стоит отчаиваться, решение есть, и оно простое. Только совсем не очевидное. Поэтому мы и решили после очередного вопроса написать эту заметку.
Открываем на хосте виртуализации
/etc/pve/lxc/ctid.conf, где ctid.conf – конфигурационный файл нужного контейнера и добавляем в него следующие две строки:lxc.mount.entry: /dev/net dev/net none bind,create=dir
lxc.cgroup2.devices.allow: c 10:200 rwm
Сохраняем изменения, запускаем контейнер и спокойно устанавливаем в него OpenVPN как обычно, или запускаем уже установленный.
👍37🤯4❤1
Привет!
Это команда Концепт-Разработка. Мы занимаемся развитием и внедрением продуктов в сфере больших данных, корпоративных хранилищ данных, BI и систем управления данными. У себя в канале развиваем сообщество бизнес и системных аналитиков, разработчиков и data-инженеров.
+ Актуальные вакансии;
+ Интересные разработки;
+ Проекты федеральных заказчиков;
+ Новости индустрии и многое другое.
Подписывайся на канал, мы будем рады и экспертам, и начинающим специалистам!
Реклама. ООО "КОНЦЕПТ РАЗРАБОТКА". ИНН 7703471165. erid: LjN8K5jJN
Это команда Концепт-Разработка. Мы занимаемся развитием и внедрением продуктов в сфере больших данных, корпоративных хранилищ данных, BI и систем управления данными. У себя в канале развиваем сообщество бизнес и системных аналитиков, разработчиков и data-инженеров.
+ Актуальные вакансии;
+ Интересные разработки;
+ Проекты федеральных заказчиков;
+ Новости индустрии и многое другое.
Подписывайся на канал, мы будем рады и экспертам, и начинающим специалистам!
Реклама. ООО "КОНЦЕПТ РАЗРАБОТКА". ИНН 7703471165. erid: LjN8K5jJN
🤮4👍3
Установка KMS сервера активации Microsoft на базе vlmcsd
Непростые времена требуют непростых решений. На фоне грядущей блокировки большого количества продуктов Microsoft крупные интеграторы предлагают превентивные решения по защите корпоративных KMS-серверов.
Для систем попроще также есть альтернатива – пакет vlmcsd эмулирующий KMS-сервер и позволяющий активировать продукты Microsoft.
Напомним, мы крайне негативно относимся к использованию нелицензионного ПО, данный материал ни в коем случае не призывает и не поощряет его использование.
Приведенное решение полностью базируется на открытом ПО и не преследует цели нарушения норм действующего законодательства и правил лицензирования ПО.
При этом мы не просто рассказываем, как установить пакет vlmcsd, но и помогаем собрать его правильно, чтобы после установки не пришлось дорабатывать инсталляцию напильником.
Читаем и внедряем: https://interface31.ru/tech_it/2022/10/ustanovka-kms-servera-aktivacii-microsoft-na-baze-vlmcsd-v-debian-ili-ubuntu.html
Непростые времена требуют непростых решений. На фоне грядущей блокировки большого количества продуктов Microsoft крупные интеграторы предлагают превентивные решения по защите корпоративных KMS-серверов.
Для систем попроще также есть альтернатива – пакет vlmcsd эмулирующий KMS-сервер и позволяющий активировать продукты Microsoft.
Напомним, мы крайне негативно относимся к использованию нелицензионного ПО, данный материал ни в коем случае не призывает и не поощряет его использование.
Приведенное решение полностью базируется на открытом ПО и не преследует цели нарушения норм действующего законодательства и правил лицензирования ПО.
При этом мы не просто рассказываем, как установить пакет vlmcsd, но и помогаем собрать его правильно, чтобы после установки не пришлось дорабатывать инсталляцию напильником.
Читаем и внедряем: https://interface31.ru/tech_it/2022/10/ustanovka-kms-servera-aktivacii-microsoft-na-baze-vlmcsd-v-debian-ili-ubuntu.html
👍51🤡5❤3🔥3
Вместе уютно собираемся по вечерам каждый у себя дома и учимся верстать сайты с нуля. В комплекте приятная музыка, тёмная тема и добрейшее сообщество неопытных верстальщиков, которые вообще-то огого и всем ещё покажут.
Всё это будет на бесплатном марафоне по HTML и СSS «ночной кружок по вёрстке», который пройдёт с 20 по 25 марта.
За 6 дней вы:
— Изучите основы веб-технологий и попробуете себя в роли фронтенд-разработчика;
— Напишете в тренажёрах свои первые строчки кода и увидите как изменяется страница сайта в реальном времени;
— Поймёте нравится ли вам веб-разработка.
Кстати, а ещё мы разыграем курс по HTML и СSS среди участников марафона.
Вступить в кружок.
Всё это будет на бесплатном марафоне по HTML и СSS «ночной кружок по вёрстке», который пройдёт с 20 по 25 марта.
За 6 дней вы:
— Изучите основы веб-технологий и попробуете себя в роли фронтенд-разработчика;
— Напишете в тренажёрах свои первые строчки кода и увидите как изменяется страница сайта в реальном времени;
— Поймёте нравится ли вам веб-разработка.
Кстати, а ещё мы разыграем курс по HTML и СSS среди участников марафона.
Вступить в кружок.
❤1👎1