Особенности использования HASP-ключей для лицензий 1С
В комментариях к вчерашней заметке были упомянуты аппаратные ключи HASP, к которым также можно привязывать программные лицензии. Но использование аппаратных ключей имеет свои особенности.
Начнем с плюсов: лицензия на HASP не привязана к оборудованию и может использоваться по сети как однопользовательская (т.е. без ограничений количества сеансов).
👉 На этом плюсы закончились, дальше идут особенности и подводные камни.
Если ПК теряет связь с менеджером лицензий HASP License Manager, а сервер или компонента веб-сервера продолжают видеть ключ, то они начнут раздавать те же лицензии как многопользовательские, т.е. по одной на сеанс.
Нужно ли говорить, что в таком режиме лицензии могут совершенно неожиданно закончиться.
Привязанный к HASP ключ программной лицензии требует наличия на ключе HASP хотя бы одной свободной лицензии для проверки ключа. В противном случае проверка не будет пройдена и ключ будет считаться на обнаруженным.
При наличии нескольких ключей одной серии их нужно разместить на разных ПК.
Но это еще не все, без дополнительной настройки оба менеджера будут работать с одинаковыми именами и если клиент первым найдет менеджер ключа, на котором нет свободной лицензии, то он не будет искать второй ключ, он сообщит что нет свободных лицензий или получит многопользовательскую лицензию с сервера или веб-сервера.
И наконец, аппаратный ключ не виден в терминальной сессии, поэтому если вы используете терминальный сервер, то ключ придется разместить на другом узле сети и использовать как сетевой.
Кроме того, аппаратный ключ можно сломать, потерять, он может выйти из строя. При этом, в отличии от программной лицензии, не будет восстановлен пока вы не предоставите фирме 1С сам ключ или то, что от него осталось и они смогут убедиться что это именно тот ключ.
В комментариях к вчерашней заметке были упомянуты аппаратные ключи HASP, к которым также можно привязывать программные лицензии. Но использование аппаратных ключей имеет свои особенности.
Начнем с плюсов: лицензия на HASP не привязана к оборудованию и может использоваться по сети как однопользовательская (т.е. без ограничений количества сеансов).
👉 На этом плюсы закончились, дальше идут особенности и подводные камни.
Если ПК теряет связь с менеджером лицензий HASP License Manager, а сервер или компонента веб-сервера продолжают видеть ключ, то они начнут раздавать те же лицензии как многопользовательские, т.е. по одной на сеанс.
Нужно ли говорить, что в таком режиме лицензии могут совершенно неожиданно закончиться.
Привязанный к HASP ключ программной лицензии требует наличия на ключе HASP хотя бы одной свободной лицензии для проверки ключа. В противном случае проверка не будет пройдена и ключ будет считаться на обнаруженным.
При наличии нескольких ключей одной серии их нужно разместить на разных ПК.
Но это еще не все, без дополнительной настройки оба менеджера будут работать с одинаковыми именами и если клиент первым найдет менеджер ключа, на котором нет свободной лицензии, то он не будет искать второй ключ, он сообщит что нет свободных лицензий или получит многопользовательскую лицензию с сервера или веб-сервера.
И наконец, аппаратный ключ не виден в терминальной сессии, поэтому если вы используете терминальный сервер, то ключ придется разместить на другом узле сети и использовать как сетевой.
Кроме того, аппаратный ключ можно сломать, потерять, он может выйти из строя. При этом, в отличии от программной лицензии, не будет восстановлен пока вы не предоставите фирме 1С сам ключ или то, что от него осталось и они смогут убедиться что это именно тот ключ.
👍19🤣7🤷♂2
День потерять – за час долететь
На днях столкнулись с очередным проектом, где все с самого начала сделали не так.
Ну как «не так», вроде бы все так, если брать с технической точки зрения, но абсолютно не так с точки зрения взаимодействия системы и пользователя.
К сожалению, это очень часто встречающаяся ошибка. Причем грешат ей не только начинающие, но и опытные специалисты.
Причин тут много, с одной стороны, это профессиональная деформация, которая рассматривает систему с точки зрения логики и подразумевает такое же поведение у ее пользователя, что в корне неверно.
С другой, отсутствие понимания процесса взаимодействия пользователя с системой, а также объективных и субъективных причин, влияющих на это взаимодействие.
По первому вопросу всегда нужно исходить из того, что, если где-то что-то можно перепутать – пользователь обязательно это перепутает. Даже если запутаться там решительно негде. А еще лучше сделать так, чтобы путать было нечего.
Просто уберите из поля зрения пользователя все лишнее, вообще. Чем меньше доступных ему действий – тем лучше. И это касается не только разработки, но и администрирования.
Не думайте, что если пользователь найдет в сети папку «Для обмена ОЧИЩАЕТСЯ АВТОМАТИЧЕСКИ», то название как-то его остановит от размещения в ней своих файлов. Нет, он с радостью их там разместит, а потом вы еще и окажетесь виноватым в том, что результаты его труда пропали.
Это все, конечно, смешно, но до поры до времени. Мы не даром привели пример с папкой, которая очищается автоматически.
В одной из организаций один наш коллега практически чуть не вылетел с работы за такой фокус. Дело в том, что один «одаренный» пользователь сохранил туда очень важный комплект документов на тендер, который, естественно, пропал.
И отмазы, что пользователь «тупой» не прокатили, так как руководство задало резонный вопрос: «А почему у тебя, дорогой друг, в системе вообще такое возможно? Ладно, пользователь дурак, но ты же умный?»
Поэтому, планируя ту часть системы, которая будет стоять лицом к пользователю всегда имеем в виду тот момент, что логики там нет и не ожидается. Поэтому надо максимально сократить возможности для «самореализации» пользователей. Они могут быть дураками, но спрос будет все равно с умного, того кто эту систему создал.
Второй вопрос еще интереснее. Цель бизнеса – зарабатывать деньги, но никак не делать технически правильно. Если «технически правильно» мешает работе бизнес-процессов, то такое «технически правильно» никому не нужно и потребуется либо искать другие решения, либо уступить свое место тем, кто умеет и рыбку съесть и на карусели покататься.
Поэтому, прежде чем что-то планировать и внедрять нужно просто сходить в цех, на склад, постоять за прилавком магазина и посмотреть, как фактически идет работа и что действительно нужно, а что только мешает.
Именно непонимание реальных рабочих процессов приводит к появлению решений вроде-бы технически правильных, но к использованию по прямому назначению непригодных.
Либо условно-пригодных, которые работают, но до поры до времени. После чего могут сильно удивить, в т.ч. и по независящим от вас причинам.
В качестве подобного, плохого кейса можно рассматривать розничный магазин, завязанный на центральную базу, неважно как, через RDP, VPN, Web и т.д. и т.п.
Пьяный экскаваторщик дядя Вася оборвал оптику – и финиш, продажи стали. А если это произойдет около центрального офиса – станет вся сеть магазинов.
А дальше вопрос будет такой: «Ладно мы – дураки, мы в этих ваших IT ничего не понимаем, но ты то понимал, что такое может быть?»
И в целом руководство будет право, они не обязаны понимать тонкости технических решений, для этого они нанимают специально обученных людей и платят им деньги.
Поэтому, прежде чем решать любую задачу, даже простую на вид, следует подробно рассмотреть ее с указанных позиций и продумать все возможные варианты, что позволит избежать в дальнейшем негативных последствий.
Лучше день потерять, но потом за час долететь.
На днях столкнулись с очередным проектом, где все с самого начала сделали не так.
Ну как «не так», вроде бы все так, если брать с технической точки зрения, но абсолютно не так с точки зрения взаимодействия системы и пользователя.
К сожалению, это очень часто встречающаяся ошибка. Причем грешат ей не только начинающие, но и опытные специалисты.
Причин тут много, с одной стороны, это профессиональная деформация, которая рассматривает систему с точки зрения логики и подразумевает такое же поведение у ее пользователя, что в корне неверно.
С другой, отсутствие понимания процесса взаимодействия пользователя с системой, а также объективных и субъективных причин, влияющих на это взаимодействие.
По первому вопросу всегда нужно исходить из того, что, если где-то что-то можно перепутать – пользователь обязательно это перепутает. Даже если запутаться там решительно негде. А еще лучше сделать так, чтобы путать было нечего.
Просто уберите из поля зрения пользователя все лишнее, вообще. Чем меньше доступных ему действий – тем лучше. И это касается не только разработки, но и администрирования.
Не думайте, что если пользователь найдет в сети папку «Для обмена ОЧИЩАЕТСЯ АВТОМАТИЧЕСКИ», то название как-то его остановит от размещения в ней своих файлов. Нет, он с радостью их там разместит, а потом вы еще и окажетесь виноватым в том, что результаты его труда пропали.
Это все, конечно, смешно, но до поры до времени. Мы не даром привели пример с папкой, которая очищается автоматически.
В одной из организаций один наш коллега практически чуть не вылетел с работы за такой фокус. Дело в том, что один «одаренный» пользователь сохранил туда очень важный комплект документов на тендер, который, естественно, пропал.
И отмазы, что пользователь «тупой» не прокатили, так как руководство задало резонный вопрос: «А почему у тебя, дорогой друг, в системе вообще такое возможно? Ладно, пользователь дурак, но ты же умный?»
Поэтому, планируя ту часть системы, которая будет стоять лицом к пользователю всегда имеем в виду тот момент, что логики там нет и не ожидается. Поэтому надо максимально сократить возможности для «самореализации» пользователей. Они могут быть дураками, но спрос будет все равно с умного, того кто эту систему создал.
Второй вопрос еще интереснее. Цель бизнеса – зарабатывать деньги, но никак не делать технически правильно. Если «технически правильно» мешает работе бизнес-процессов, то такое «технически правильно» никому не нужно и потребуется либо искать другие решения, либо уступить свое место тем, кто умеет и рыбку съесть и на карусели покататься.
Поэтому, прежде чем что-то планировать и внедрять нужно просто сходить в цех, на склад, постоять за прилавком магазина и посмотреть, как фактически идет работа и что действительно нужно, а что только мешает.
Именно непонимание реальных рабочих процессов приводит к появлению решений вроде-бы технически правильных, но к использованию по прямому назначению непригодных.
Либо условно-пригодных, которые работают, но до поры до времени. После чего могут сильно удивить, в т.ч. и по независящим от вас причинам.
В качестве подобного, плохого кейса можно рассматривать розничный магазин, завязанный на центральную базу, неважно как, через RDP, VPN, Web и т.д. и т.п.
Пьяный экскаваторщик дядя Вася оборвал оптику – и финиш, продажи стали. А если это произойдет около центрального офиса – станет вся сеть магазинов.
А дальше вопрос будет такой: «Ладно мы – дураки, мы в этих ваших IT ничего не понимаем, но ты то понимал, что такое может быть?»
И в целом руководство будет право, они не обязаны понимать тонкости технических решений, для этого они нанимают специально обученных людей и платят им деньги.
Поэтому, прежде чем решать любую задачу, даже простую на вид, следует подробно рассмотреть ее с указанных позиций и продумать все возможные варианты, что позволит избежать в дальнейшем негативных последствий.
Лучше день потерять, но потом за час долететь.
👏28👍14🤡3❤1
Учитываете ли вы при внедрении решений вопросы взаимодействия с пользователями и особенности бизнес-процессов?
Anonymous Poll
46%
Да, всегда.
17%
Да, иногда.
16%
Когда как.
3%
Обычно нет.
4%
Нет, это не мои проблемы
3%
Проблемы вроде и не мои, но пострадал я
12%
Ничего не понятно, но очень интересно
За одного битого, двух небитых дают
Эту заметку прислал мне один мой коллега с Урала и попросил опубликовать на правах анонимности, ее тема как раз перекликается с нашей последней публикацией и отражает особенности взаимоотношения IT и бизнеса. На наш взгляд интересно и поучительно.
Далее повествование от лица коллеги, имена и места действия изменены.
В то время я был относительно молод, 30 с небольшим лет, работал на заводе системным администратором. Зарплата была не то, чтобы высокая, но более-менее стабильная, работы было особо не много, плюс разные плюшки в виде соцпакета, отпусков и т.п.
Жена как раз была в декрете и поэтому синица в руках была всяко лучше журавля, хотя временами приходилось серьезно затягивать пояса.
И вот как-то вечером на районе я встретил своего одноклассника Сашу, друзьями мы особо не были, но несколько лет просидели за одной партой. Саша звезд с неба не хватал, занимался стройкой и ремонтом, а теперь с компаньонами открыл бизнес.
У них было несколько строительных магазинчиков, типа все по мелочи у дома, которые как раз находились в его управлении и торговая база за городом, где занимались его компаньоны.
В общем предложил он мне подработку, надо было автоматизировать его магазины и настроить там учет и все такое. Ну а я в свободное от работы время баловался программированием на 1С, брал всякие заказы на фрилансе, ну и на работе по мелочи писал там отчеты и обработки всякие.
Ну в общем понеслась, задач было много, задачи были интересные, платил Саша нормально и скоро с этого проекта я начал получать примерно еще одну зарплату. Жить стало сразу веселей.
Но при этом я допустил ряд серьезных ошибок, которые аукнулись мне в дальнейшем.
Первое: я работал для Саши как для себя, вникал, замечал, подмечал, отмечал и дорабатывал, чтобы сделать работу сотрудников проще и быстрее. Но все это я особо не фиксировал и не афишировал, да и никто с меня не спрашивал. Всех все устраивало, деньги платились.
Второе: я не вел работу с обращениями, проблемы решались в телефонном режиме или по удаленке, нигде не фиксировались, а за это все я брал фиксированную сумму в месяц с каждой торговой точки.
А потом от магазинов я плавно перешел к автоматизации базы его компаньонов, что наложилось на строительный бум в нашем регионе и достаточно бурный рост бизнеса.
Задачи стали более разнообразные и интересные, подопечных у меня прибавилось раза в три и тут начались проблемы.
То, что работало на небольшой сети, где все друг друга знали с масштабированием, работать перестало.
Эту заметку прислал мне один мой коллега с Урала и попросил опубликовать на правах анонимности, ее тема как раз перекликается с нашей последней публикацией и отражает особенности взаимоотношения IT и бизнеса. На наш взгляд интересно и поучительно.
Далее повествование от лица коллеги, имена и места действия изменены.
В то время я был относительно молод, 30 с небольшим лет, работал на заводе системным администратором. Зарплата была не то, чтобы высокая, но более-менее стабильная, работы было особо не много, плюс разные плюшки в виде соцпакета, отпусков и т.п.
Жена как раз была в декрете и поэтому синица в руках была всяко лучше журавля, хотя временами приходилось серьезно затягивать пояса.
И вот как-то вечером на районе я встретил своего одноклассника Сашу, друзьями мы особо не были, но несколько лет просидели за одной партой. Саша звезд с неба не хватал, занимался стройкой и ремонтом, а теперь с компаньонами открыл бизнес.
У них было несколько строительных магазинчиков, типа все по мелочи у дома, которые как раз находились в его управлении и торговая база за городом, где занимались его компаньоны.
В общем предложил он мне подработку, надо было автоматизировать его магазины и настроить там учет и все такое. Ну а я в свободное от работы время баловался программированием на 1С, брал всякие заказы на фрилансе, ну и на работе по мелочи писал там отчеты и обработки всякие.
Ну в общем понеслась, задач было много, задачи были интересные, платил Саша нормально и скоро с этого проекта я начал получать примерно еще одну зарплату. Жить стало сразу веселей.
Но при этом я допустил ряд серьезных ошибок, которые аукнулись мне в дальнейшем.
Первое: я работал для Саши как для себя, вникал, замечал, подмечал, отмечал и дорабатывал, чтобы сделать работу сотрудников проще и быстрее. Но все это я особо не фиксировал и не афишировал, да и никто с меня не спрашивал. Всех все устраивало, деньги платились.
Второе: я не вел работу с обращениями, проблемы решались в телефонном режиме или по удаленке, нигде не фиксировались, а за это все я брал фиксированную сумму в месяц с каждой торговой точки.
А потом от магазинов я плавно перешел к автоматизации базы его компаньонов, что наложилось на строительный бум в нашем регионе и достаточно бурный рост бизнеса.
Задачи стали более разнообразные и интересные, подопечных у меня прибавилось раза в три и тут начались проблемы.
То, что работало на небольшой сети, где все друг друга знали с масштабированием, работать перестало.
👍10❤2
Проблемы стали расти как снежный ком и перестали купироваться на нижнем уровне, а пошли вверх на руководство. То же самое и с программой. Не секрет, что УТ 11 довольно своеобразная конфигурация и после ТиС 9.7 которая там стояла до этого недовольство пользователей было весьма ожидаемо.
А так как контора стала бурно расти, то стали там появляться новые люди, которые меня видели в первый раз и предложили пригласить на аудит сторонних специалистов.
В качестве такого светла нашелся ведущий преподаватель местного УЦ 1С, весь обвешанный сертификатами по самое не балуйся.
В целом разнес он меня в пух и прах. Мол все это не по методикам, конфигурацию тупо изуродовали и т.д. и т.п. Мол для чего это и зачем? А я сидел и молчал и мотивированно ответить мне было нечем…
К счастью, собственники бизнеса оказались ребятами хоть и простыми, но не дебилами и предложили проверить все это на практике. Мол берем два компьютера, на один ставим «изуродованную» программу, а на вторую чистую, но настроенную по методике «светила».
«Светило» плавно съехало с темы, мол не царское это дело и оба стенда готовил я сам. Результат тоже был ожидаем. Вердикт был в мою пользу, мол косяки есть, не без того, но в штатной вообще жопа, мы там очереди соберем как в мавзолей и остальное делать месяц будем.
А когда мы вышли «покурить» с Сашей, то я упрекнул его, мол чего он сидел молчал пока меня ссаной тряпкой по морде возили? Это, кстати, было очень обидно, ведь столько было сделано и делал как для себя.
На что Саша резонно мне заявил, что он не молчал, а слушал. И то, что я делал «как для себя» и не даже ставил их в известность – это очень плохо. Во-первых, они не имели реального представления о том, что было в программе изначально, а что добавлено.
Во-вторых, я не владелец бизнеса и смотрю со своей колокольни. Но все, что я могу потерять – это определенную сумму дохода в месяц, остальные издержки будет нести бизнес, т.е. он.
«Ты же не будешь кормить моих детей и платить зарплату моим сотрудникам?» - спросил он и мне нечего было возразить.
Поэтому все идеи, проблемы, доработки и т.д. все идут через верх, санкционируются руководством и после этого идут вниз.
Кроме всего прочего данный подход позволяет руководству контролировать эффективность тех или иных доработок и их использование персоналом.
И теперь на вопрос: «А тут у нас… Это… Того…»
Сразу следует ответ: «А вам для этого неделю назад кнопку сделали и отправили всем инструкции»
Что гораздо лучше того, когда сотрудники докладывают начальству про то, что программа снова не работает. А начальство начинает косо смотреть на того, кто ее «изуродовал».
Но это было не самое главное, основной косяк мне вменили за то, что вовремя не довел до руководства истинное состояние дел на низах.
Пока все это замыкалось на уровне линейных сотрудников и меня у руководства было ложное предположение что особых проблем и нет. Ни с сотрудниками, ни с программой, ни с рабочими процессами.
И когда это при росте и расширении выплеснулось наружу, это был как ушат холодной воды и оправдываться пришлось уже мне.
Теперь все обращения тщательно фиксируются, систематизируются и каждый месяц предоставляются собственникам с собственными моими выводами и пожеланиями.
И да, теперь все обращения оплачиваются, и я не боюсь их обсуждать с cсобственниками. Потому что там, где имеет место человеческий фактор – там идут в ход материальные методы мотивации. Там, где это можно решить технически – решаем доработками.
Но что я в целом вынес из этой истории и понял, что все, что вы делаете для бизнеса, будь то работодатель или сторонний клиент, все должно учитываться, документироваться, доводиться наверх и согласовываться.
Чтобы там, наверху, тоже была полная картина и не получилось, как у меня, когда бизнесу внезапно открылся весь пласт проблем, но крайним при этом оказался я, так как замкнул это все на себя и своевременно никого не уведомил.
А так как контора стала бурно расти, то стали там появляться новые люди, которые меня видели в первый раз и предложили пригласить на аудит сторонних специалистов.
В качестве такого светла нашелся ведущий преподаватель местного УЦ 1С, весь обвешанный сертификатами по самое не балуйся.
В целом разнес он меня в пух и прах. Мол все это не по методикам, конфигурацию тупо изуродовали и т.д. и т.п. Мол для чего это и зачем? А я сидел и молчал и мотивированно ответить мне было нечем…
К счастью, собственники бизнеса оказались ребятами хоть и простыми, но не дебилами и предложили проверить все это на практике. Мол берем два компьютера, на один ставим «изуродованную» программу, а на вторую чистую, но настроенную по методике «светила».
«Светило» плавно съехало с темы, мол не царское это дело и оба стенда готовил я сам. Результат тоже был ожидаем. Вердикт был в мою пользу, мол косяки есть, не без того, но в штатной вообще жопа, мы там очереди соберем как в мавзолей и остальное делать месяц будем.
А когда мы вышли «покурить» с Сашей, то я упрекнул его, мол чего он сидел молчал пока меня ссаной тряпкой по морде возили? Это, кстати, было очень обидно, ведь столько было сделано и делал как для себя.
На что Саша резонно мне заявил, что он не молчал, а слушал. И то, что я делал «как для себя» и не даже ставил их в известность – это очень плохо. Во-первых, они не имели реального представления о том, что было в программе изначально, а что добавлено.
Во-вторых, я не владелец бизнеса и смотрю со своей колокольни. Но все, что я могу потерять – это определенную сумму дохода в месяц, остальные издержки будет нести бизнес, т.е. он.
«Ты же не будешь кормить моих детей и платить зарплату моим сотрудникам?» - спросил он и мне нечего было возразить.
Поэтому все идеи, проблемы, доработки и т.д. все идут через верх, санкционируются руководством и после этого идут вниз.
Кроме всего прочего данный подход позволяет руководству контролировать эффективность тех или иных доработок и их использование персоналом.
И теперь на вопрос: «А тут у нас… Это… Того…»
Сразу следует ответ: «А вам для этого неделю назад кнопку сделали и отправили всем инструкции»
Что гораздо лучше того, когда сотрудники докладывают начальству про то, что программа снова не работает. А начальство начинает косо смотреть на того, кто ее «изуродовал».
Но это было не самое главное, основной косяк мне вменили за то, что вовремя не довел до руководства истинное состояние дел на низах.
Пока все это замыкалось на уровне линейных сотрудников и меня у руководства было ложное предположение что особых проблем и нет. Ни с сотрудниками, ни с программой, ни с рабочими процессами.
И когда это при росте и расширении выплеснулось наружу, это был как ушат холодной воды и оправдываться пришлось уже мне.
Теперь все обращения тщательно фиксируются, систематизируются и каждый месяц предоставляются собственникам с собственными моими выводами и пожеланиями.
И да, теперь все обращения оплачиваются, и я не боюсь их обсуждать с cсобственниками. Потому что там, где имеет место человеческий фактор – там идут в ход материальные методы мотивации. Там, где это можно решить технически – решаем доработками.
Но что я в целом вынес из этой истории и понял, что все, что вы делаете для бизнеса, будь то работодатель или сторонний клиент, все должно учитываться, документироваться, доводиться наверх и согласовываться.
Чтобы там, наверху, тоже была полная картина и не получилось, как у меня, когда бизнесу внезапно открылся весь пласт проблем, но крайним при этом оказался я, так как замкнул это все на себя и своевременно никого не уведомил.
💯51👍35❤3
Полное удаление или переустановка Яндекс.Диска
Задачка вроде бы простая, но, как и везде, обнаружились свои тонкости, возможно, не только мне будет полезно.
У одного из заказчиков на неделе сломался Яндекс.Диск, причем в нескольких местах. Симптомы: Яндекс.Диск не выходит из состояния синхронизации, отмечая таким образом все файлы и папки и постепенно занимает 100% процессорного времени.
При этом другие клиенты на этом же аккаунте работают нормально, смена аккаунта на больном ПК тоже не помогает.
В таком случае логично выполнить переустановку приложения, но увы, эти попытки не увенчались успехом. А так как на Яндекс.Диск были завязаны рабочие процессы, то пришлось разбираться.
Как выяснилось, Яндекс относится к процессу удаления собственного ПО формально, фактически только исключив его из автозагрузки и убрав ярлыки, да и то делает через раз.
А навело нас на эту мысль то, что на одном из ПК после «удаления» и перезагрузки Яндекс.Диск запустился и потребовал учетные данные, а после их ввода успешно заработал, точнее снова повис на синхронизации.
Как выяснилось, при удалении Яндекс.Диска полностью сохраняется содержимое папок:
В первой живут настройки и логи, во второй сам Яндекс.Диск, который прекрасно запускается оттуда даже после «удаления».
Поэтому для полного удаления или переустановки эти директории следует удалить. Также еще советуем удалить скрытую директорию
В папке с синхронизируемыми файлами. После того как вы все удалили можете перезагрузить ПК и заново установить Яндекс.Диск.
Данный рецепт проверили на нескольких ПК и везде смогли добиться положительного результата. И более странно то, что поддержка, в которую также обращались, его не посоветовала, а прислала стандартные рекомендации переустановить, перезагрузить, поставить обновления или проверить на вирусы.
Задачка вроде бы простая, но, как и везде, обнаружились свои тонкости, возможно, не только мне будет полезно.
У одного из заказчиков на неделе сломался Яндекс.Диск, причем в нескольких местах. Симптомы: Яндекс.Диск не выходит из состояния синхронизации, отмечая таким образом все файлы и папки и постепенно занимает 100% процессорного времени.
При этом другие клиенты на этом же аккаунте работают нормально, смена аккаунта на больном ПК тоже не помогает.
В таком случае логично выполнить переустановку приложения, но увы, эти попытки не увенчались успехом. А так как на Яндекс.Диск были завязаны рабочие процессы, то пришлось разбираться.
Как выяснилось, Яндекс относится к процессу удаления собственного ПО формально, фактически только исключив его из автозагрузки и убрав ярлыки, да и то делает через раз.
А навело нас на эту мысль то, что на одном из ПК после «удаления» и перезагрузки Яндекс.Диск запустился и потребовал учетные данные, а после их ввода успешно заработал, точнее снова повис на синхронизации.
Как выяснилось, при удалении Яндекс.Диска полностью сохраняется содержимое папок:
AppData\Local\YandexAppData\Roaming\Yandex
В первой живут настройки и логи, во второй сам Яндекс.Диск, который прекрасно запускается оттуда даже после «удаления».
Поэтому для полного удаления или переустановки эти директории следует удалить. Также еще советуем удалить скрытую директорию
.syncВ папке с синхронизируемыми файлами. После того как вы все удалили можете перезагрузить ПК и заново установить Яндекс.Диск.
Данный рецепт проверили на нескольких ПК и везде смогли добиться положительного результата. И более странно то, что поддержка, в которую также обращались, его не посоветовала, а прислала стандартные рекомендации переустановить, перезагрузить, поставить обновления или проверить на вирусы.
👍44🤔5🤬1
Использование Routing Rules в роутерах Mikrotik
На днях один коллега спросил, как эффективнее всего заблокировать доступ к определенным ресурсам через основного провайдера если неожиданно отключится VPN.
Вопрос не праздный, так как при работе с зарубежными сервисами блокирующих пользователей из РФ таким образом можно выдать свое истинное положение и получить блокировку аккаунта.
Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.
Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.
Правила Routing Rules начнут работать уже после того, как решение о маршрутизации будет принято.
Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).
По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.
В процессе поиска маршрута роутер ищет маршрут с самой узкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.
Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.
Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.
Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию –
Поэтому, если мы не хотим, чтобы при обрыве VPN-соединения пакет уходил через основного провайдера, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило
В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.
Но это далеко не все. В качестве критериев мы можем использовать также адреса источника и назначения, а также интерфейс.
В действиях нам также доступны
Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.
Но выбирая тот или иной способ надо всегда руководствоваться здравым смыслом и общей читабельностью правил, так как для других ваших коллег фильтрация на уровне таблиц маршрутизации может оказаться в диковинку.
На днях один коллега спросил, как эффективнее всего заблокировать доступ к определенным ресурсам через основного провайдера если неожиданно отключится VPN.
Вопрос не праздный, так как при работе с зарубежными сервисами блокирующих пользователей из РФ таким образом можно выдать свое истинное положение и получить блокировку аккаунта.
Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.
Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.
Правила Routing Rules начнут работать уже после того, как решение о маршрутизации будет принято.
Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).
По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.
В процессе поиска маршрута роутер ищет маршрут с самой узкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.
Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.
Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.
Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию –
lookup – поиск. И если маршрут не будет найден в собственной таблице, он будет продолжен в основной. Поэтому, если мы не хотим, чтобы при обрыве VPN-соединения пакет уходил через основного провайдера, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило
lookup-only-in-table.В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.
Но это далеко не все. В качестве критериев мы можем использовать также адреса источника и назначения, а также интерфейс.
В действиях нам также доступны
drop, который молча блокирует пакет и unreachable, который отравит ICMP-ответ с сообщением о недоступности узла назначения.Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.
Но выбирая тот или иной способ надо всегда руководствоваться здравым смыслом и общей читабельностью правил, так как для других ваших коллег фильтрация на уровне таблиц маршрутизации может оказаться в диковинку.
👍29
Используете ли вы Routing Rules в Mikrotik
Anonymous Poll
24%
Да
31%
Нет
19%
Нет, но теперь буду
27%
Ничего не понятно, но очень интересно
🎓 Освойте востребованную IT-профессию за счёт государства и начните зарабатывать сразу после обучения!
Открыт набор на бесплатное онлайн-обучение от ТГУ по самым трендовым IT профессиям 2023 года.
*ТГУ входит в 100 сильнейших вузов мира и Топ-5 России.
Узнайте подробнее про IT-программы и подайте заявку:
https://tglink.io/ca491633177f
На выбор есть много разных программ: от 1С-разработчика до оператора беспилотных аппаратов – выбирать только вам.
Обучение с проектом «Содействие занятости» это:
🔸 Полностью бесплатное обучение
🔸 Более 65 000 выпускников, 75% из которых трудоустроены
🔸 Онлайн формат — учитесь из любого места по 2–3 часа в день в удобное для вас время
🔸 Документ об образовании — подтвердит ваши навыки и компетенции
🔸 Помощь с трудоустройством после обучения
Количество мест на бесплатное обучение ограничено, спешите подать заявку.
Реклама. ООО "АДИ ГРУПП". ИНН 7017283529. erid: LjN8Kbyha
Открыт набор на бесплатное онлайн-обучение от ТГУ по самым трендовым IT профессиям 2023 года.
*ТГУ входит в 100 сильнейших вузов мира и Топ-5 России.
Узнайте подробнее про IT-программы и подайте заявку:
https://tglink.io/ca491633177f
На выбор есть много разных программ: от 1С-разработчика до оператора беспилотных аппаратов – выбирать только вам.
Обучение с проектом «Содействие занятости» это:
🔸 Полностью бесплатное обучение
🔸 Более 65 000 выпускников, 75% из которых трудоустроены
🔸 Онлайн формат — учитесь из любого места по 2–3 часа в день в удобное для вас время
🔸 Документ об образовании — подтвердит ваши навыки и компетенции
🔸 Помощь с трудоустройством после обучения
Количество мест на бесплатное обучение ограничено, спешите подать заявку.
Реклама. ООО "АДИ ГРУПП". ИНН 7017283529. erid: LjN8Kbyha
👍1
Продолжаем тему маршрутизации, а так как день сегодня выходной, то не будем поднимать сложных тем, а зададим простой, но интересный вопрос.
Почему OpenVPN при указании шлюза в VPN-сети (опция
Для чего это сделано и что это дает?
Почему OpenVPN при указании шлюза в VPN-сети (опция
redirect-gateway) вместо нулевого маршрута добавляет два:0.0.0.0/1 via ovpn
128.0.0.1/1 via ovpn
Для чего это сделано и что это дает?
👍3
Данный набор маршрутов
Final Results
5%
Оптимизирует прохождение трафика
2%
Улучшает пропускную способность
36%
Сохраняет у клиента нулевой маршрут
13%
Блокирует утечку трафика через основного провайдера
20%
Препятствует переопределению нулевого маршрута
5%
Помогает маскировать VPN-подключение
19%
Нет ни одного правильного ответа
Вернемся к утренней задаче, не смотря на ее простоту правильно ответили всего 20%.
Правильный ответ: препятствует переопределению нулевого маршрута
Почему так? Давайте разбираться. Пример таблицы маршрутов с активным OpenVPN соединением показан на рисунке ниже.
Сразу же в очередной раз вспоминаем, как идет поиск маршрута в таблице:
1️⃣ Сначала ищется маршрут к узлу назначения с самой узкой маской
2️⃣Затем определяется интерфейс выхода среди непосредственно присоединенных сетей, который позволяет достичь указанного в маршруте шлюза.
Если к одному узлу назначения ведут несколько маршрутов с одинаковой шириной маски, то выбирается маршрут с лучшей метрикой .
Теперь давайте смотреть: прежде всего обратим внимание на маршрут
Затем у нас есть два маршрута к непосредственно присоединенным сетям
Остальной трафик не попадает ни под один из указанных выше маршрутов и поиск для него продолжается дальше.
В результате будет найдет один из двух маршрутов
А так как маска
Потому что даже если мы не будем делить маршруты на два диапазона и пропишем еще один нулевой, то в системе появится два нулевых маршрута с разными шлюзами и разными метриками. Но использоваться будет тот, чья метрика меньше.
Основной недостаток такого подхода – это переопределение нулевого маршрута другим подключением. Например, вы присоединили 4G модем, переподключились к другой беспроводной сети или подключили еще один VPN.
Как минимум это потребует переподключения OpenVPN, а в иных случаях ручного переопределения приоритетов маршрутов.
Чтобы избежать подобных ситуаций OpenVPN использует два маршрута с более узкой маской вместо одного нулевого, в этом случае даже при переопределении нулевого маршрута в системе трафик пользователя все равно будет уходить в VPN-туннель.
Правильный ответ: препятствует переопределению нулевого маршрута
Почему так? Давайте разбираться. Пример таблицы маршрутов с активным OpenVPN соединением показан на рисунке ниже.
Сразу же в очередной раз вспоминаем, как идет поиск маршрута в таблице:
1️⃣ Сначала ищется маршрут к узлу назначения с самой узкой маской
2️⃣Затем определяется интерфейс выхода среди непосредственно присоединенных сетей, который позволяет достичь указанного в маршруте шлюза.
Если к одному узлу назначения ведут несколько маршрутов с одинаковой шириной маски, то выбирается маршрут с лучшей метрикой .
Теперь давайте смотреть: прежде всего обратим внимание на маршрут
xx.xx.254.75/32 который указывает на сам OpenVPN сервер через основной шлюз. Так как это наиболее узкая из всех возможных масок, то поиск маршрута на этом прекращается и пакет к серверу уходит через основное подключение.Затем у нас есть два маршрута к непосредственно присоединенным сетям
10.8.0.0/24 и 192.168.0.0/24. Эти маршруты обеспечат правильное направление пакетов для локальной сети и внутренней сети VPN.Остальной трафик не попадает ни под один из указанных выше маршрутов и поиск для него продолжается дальше.
В результате будет найдет один из двух маршрутов
0.0.0.0/1 или 128.0.0.0/1, которые делят пополам все доступное адресное пространство. И по совокупности представляют собой нулевой маршрут, куда будет уходить весь трафик, для которого не будет найдено отдельного маршрута.А так как маска
/1 уже маски /0, то поиск никогда не дойдет до маршрута 0.0.0.0/0, поэтому ответ «сохраняет для клиента нулевой маршрут» неверен.Потому что даже если мы не будем делить маршруты на два диапазона и пропишем еще один нулевой, то в системе появится два нулевых маршрута с разными шлюзами и разными метриками. Но использоваться будет тот, чья метрика меньше.
Основной недостаток такого подхода – это переопределение нулевого маршрута другим подключением. Например, вы присоединили 4G модем, переподключились к другой беспроводной сети или подключили еще один VPN.
Как минимум это потребует переподключения OpenVPN, а в иных случаях ручного переопределения приоритетов маршрутов.
Чтобы избежать подобных ситуаций OpenVPN использует два маршрута с более узкой маской вместо одного нулевого, в этом случае даже при переопределении нулевого маршрута в системе трафик пользователя все равно будет уходить в VPN-туннель.
👍37
Не так давно было у нас сообщение об опасной системе охлаждения для SSD, крепеж которой на резиночках дает 100% гарантию того, что эти резиночки в течении года лопнут: https://yangx.top/interface31/1687
Несмотря на это данные наборы продаются не только на Али, но и в отечественной рознице, да еще и с гарантией.
Хотя здесь же не сильно дороже можно купить абсолютно безопасный радиатор с нормальным креплением и к тому же куда более эффективный.
В среднем минус 7-8 градусов на ровном месте. Все остальные части системы остались без изменений. Диски XPG GAMMIX S5 разных серий, на разных контроллерах.
Несмотря на это данные наборы продаются не только на Али, но и в отечественной рознице, да еще и с гарантией.
Хотя здесь же не сильно дороже можно купить абсолютно безопасный радиатор с нормальным креплением и к тому же куда более эффективный.
В среднем минус 7-8 градусов на ровном месте. Все остальные части системы остались без изменений. Диски XPG GAMMIX S5 разных серий, на разных контроллерах.
👍3
Какой радиатор наиболее эффективный?
Final Results
3%
Полностью алюминиевый
22%
Полностью медный
12%
Медный сердечник и алюминиевые пластины
1%
Алюминиевый сердечник и медные пластины
5%
Тепловая трубка и алюминиевые пластины
40%
Тепловая трубка и медные пластины
18%
Ничего не понятно, но очень интересно
👍5
Медь или алюминий?
Во вчерашнем вопросе об эффективности различных материалов для радиаторов большинство читателей ответили неправильно, посчитав лучшим материалом медь.
Чтобы понять почему это не так обратимся к школьному курсу физики, а именно вспомним некоторые параметры вещества, непосредственно влияющие на свойства радиаторов.
Начнем с теплопроводности, так как именно этот параметр чаше всего приводят в качестве аргумента.
Теплопроводность – это свойство вещества передавать энергию от более нагретых участков к менее нагретым. Измеряется она в Вт/(м·К), но нас сейчас будут меньше всего волновать абсолютные цифры, гораздо важнее соотношения.
Теплопроводность меди - 401 Вт/(м·К), алюминия 202-236 Вт/(м·К). Это говорит о том, что медный радиатор равномерно прогреется в два раза быстрее алюминиевого, в целом это хорошо, так как мы быстрее заберем тепло от объекта охлаждения.
Но забрать мы его забрали, дальше что? Очевидно, что радиатор нагреется. Как сильно? А вот здесь играет роль совсем другая характеристика вещества – теплоемкость.
Теплоемкость – это количество тепловой энергии, поглощаемой (выделяемой) веществом при нагреве (охлаждении) его на один градус. В нашем случае удобно пользоваться удельной теплоемкостью, которая отражает количество теплоты на градус применительно к массе тела.
Удельная теплоемкость измеряется в Дж/(кг·К) и составляет для меди 385 Дж/(кг·К), а алюминия – 897 Дж/(кг·К), т.е. теплоемкость алюминия выше в 2,3 раза чем теплоемкость меди.
О чем это говорит? О том, что медный радиатор нагреется в 2,3 раза сильнее, чем алюминиевый той же массы.
Таким образом алюминий является более эффективным материалом для отведения тепловой энергии, так как он позволяет поглощать большее количество тепловой энергии при меньшем нагреве, чем медь.
Но при этом алюминий обладает меньшей теплопроводностью, значит хуже будет справляться с задачей быстро отвести тепло от объекта охлаждения, при этом с задачей поглощения энергии он будет справляться лучше.
К этому вопросу мы уже вернемся. А пока продолжим разбираться с тем, куда же пойдет тепловая энергия, накопленная радиатором. А пойдет она в окружающую среду в процессе теплообмена более горячего радиатора и менее горячего воздуха.
Эффективность теплообмена зависит от площади излучения тепловой энергии и разности температур радиатора и окружающей среды. Таким образом из радиаторов одной и той же массы будет эффективнее тот, который имеет большую площадь излучения.
А насколько эффективнее будут отводить тепло наши материалы? Здесь снова работает теплоемкость, только в обратную сторону. При охлаждении на один градус алюминий отдаст в 2,3 раза больше энергии чем медь.
Таким образом медь будет быстро нагреваться, но медленно охлаждаться и для эффективной работы такого радиатора нам понадобится более высокая разность температур между радиатором и окружающей средой или дополнительные меры по принудительному увеличению теплообмена (обдув).
Есть еще один немаловажный аспект. Плотность меди составляет 8900 кг/м3, а плотность алюминия 2700 кг/м3, т.е. при одних и тех же физических размерах медный радиатор будет в 3,2 раза тяжелее, но в 2,3 раза менее эффективен.
В реальном мире для обеспечения эффективности радиаторов сочетают сильные стороны разных материалов, которые взаимовыгодно подчеркивают друг друга.
Медный сердечник или тепловая трубка обладают высокой теплопроводностью и позволяют быстро отводить тепло от объекта охлаждения. Их теплоемкость при этом не играет решающей роли, их задача избежать ситуации, когда объект охлаждения уже горячий, а радиатор еще холодный.
А алюминиевый радиатор позволяет, благодаря высокой теплоемкости, принять большое количество тепла и эффективно передать его во внешнюю среду.
Таким образом наиболее эффективным будет алюминиевый радиатор с тепловой трубкой, а за ним будет идти алюминиевый радиатор с медным сердечником.
Во вчерашнем вопросе об эффективности различных материалов для радиаторов большинство читателей ответили неправильно, посчитав лучшим материалом медь.
Чтобы понять почему это не так обратимся к школьному курсу физики, а именно вспомним некоторые параметры вещества, непосредственно влияющие на свойства радиаторов.
Начнем с теплопроводности, так как именно этот параметр чаше всего приводят в качестве аргумента.
Теплопроводность – это свойство вещества передавать энергию от более нагретых участков к менее нагретым. Измеряется она в Вт/(м·К), но нас сейчас будут меньше всего волновать абсолютные цифры, гораздо важнее соотношения.
Теплопроводность меди - 401 Вт/(м·К), алюминия 202-236 Вт/(м·К). Это говорит о том, что медный радиатор равномерно прогреется в два раза быстрее алюминиевого, в целом это хорошо, так как мы быстрее заберем тепло от объекта охлаждения.
Но забрать мы его забрали, дальше что? Очевидно, что радиатор нагреется. Как сильно? А вот здесь играет роль совсем другая характеристика вещества – теплоемкость.
Теплоемкость – это количество тепловой энергии, поглощаемой (выделяемой) веществом при нагреве (охлаждении) его на один градус. В нашем случае удобно пользоваться удельной теплоемкостью, которая отражает количество теплоты на градус применительно к массе тела.
Удельная теплоемкость измеряется в Дж/(кг·К) и составляет для меди 385 Дж/(кг·К), а алюминия – 897 Дж/(кг·К), т.е. теплоемкость алюминия выше в 2,3 раза чем теплоемкость меди.
О чем это говорит? О том, что медный радиатор нагреется в 2,3 раза сильнее, чем алюминиевый той же массы.
Таким образом алюминий является более эффективным материалом для отведения тепловой энергии, так как он позволяет поглощать большее количество тепловой энергии при меньшем нагреве, чем медь.
Но при этом алюминий обладает меньшей теплопроводностью, значит хуже будет справляться с задачей быстро отвести тепло от объекта охлаждения, при этом с задачей поглощения энергии он будет справляться лучше.
К этому вопросу мы уже вернемся. А пока продолжим разбираться с тем, куда же пойдет тепловая энергия, накопленная радиатором. А пойдет она в окружающую среду в процессе теплообмена более горячего радиатора и менее горячего воздуха.
Эффективность теплообмена зависит от площади излучения тепловой энергии и разности температур радиатора и окружающей среды. Таким образом из радиаторов одной и той же массы будет эффективнее тот, который имеет большую площадь излучения.
А насколько эффективнее будут отводить тепло наши материалы? Здесь снова работает теплоемкость, только в обратную сторону. При охлаждении на один градус алюминий отдаст в 2,3 раза больше энергии чем медь.
Таким образом медь будет быстро нагреваться, но медленно охлаждаться и для эффективной работы такого радиатора нам понадобится более высокая разность температур между радиатором и окружающей средой или дополнительные меры по принудительному увеличению теплообмена (обдув).
Есть еще один немаловажный аспект. Плотность меди составляет 8900 кг/м3, а плотность алюминия 2700 кг/м3, т.е. при одних и тех же физических размерах медный радиатор будет в 3,2 раза тяжелее, но в 2,3 раза менее эффективен.
В реальном мире для обеспечения эффективности радиаторов сочетают сильные стороны разных материалов, которые взаимовыгодно подчеркивают друг друга.
Медный сердечник или тепловая трубка обладают высокой теплопроводностью и позволяют быстро отводить тепло от объекта охлаждения. Их теплоемкость при этом не играет решающей роли, их задача избежать ситуации, когда объект охлаждения уже горячий, а радиатор еще холодный.
А алюминиевый радиатор позволяет, благодаря высокой теплоемкости, принять большое количество тепла и эффективно передать его во внешнюю среду.
Таким образом наиболее эффективным будет алюминиевый радиатор с тепловой трубкой, а за ним будет идти алюминиевый радиатор с медным сердечником.
👍33🔥19🤔2❤1😁1
🎓 Освойте одну из самых востребованных IT-специальностей на рынке труда и получите помощь с трудоустройством!
Станьте участником федерального проекта "Содействие занятости" - цель которого помочь гражданам бесплатно освоить новую или сменить действующую профессию.
Открыт набор на бесплатное онлайн-обучение от ТГУ по программе: "1C разработчик".
*ТГУ входит в 100 сильнейших вузов мира и Топ-5 России.
Узнайте подробнее и подайте заявку:
https://tglink.io/a58d7fb21410
Обучение с проектом «Содействие занятости» это:
🔸 Полностью бесплатное онлайн-обучение
🔸 Более 65 000 выпускников, 75% из которых трудоустроены
🔸 Обучение по 2–3 часа в день в удобное для вас время;
🔸 Документ об образовании — подтвердит ваши навыки и компетенции;
🔸 Помощь с трудоустройством после обучения.
Количество мест на бесплатное обучение ограничено, спешите подать заявку.
Реклама. ООО "АДИ ГРУПП". ИНН 7017283529. erid: LjN8KVBjN
Станьте участником федерального проекта "Содействие занятости" - цель которого помочь гражданам бесплатно освоить новую или сменить действующую профессию.
Открыт набор на бесплатное онлайн-обучение от ТГУ по программе: "1C разработчик".
*ТГУ входит в 100 сильнейших вузов мира и Топ-5 России.
Узнайте подробнее и подайте заявку:
https://tglink.io/a58d7fb21410
Обучение с проектом «Содействие занятости» это:
🔸 Полностью бесплатное онлайн-обучение
🔸 Более 65 000 выпускников, 75% из которых трудоустроены
🔸 Обучение по 2–3 часа в день в удобное для вас время;
🔸 Документ об образовании — подтвердит ваши навыки и компетенции;
🔸 Помощь с трудоустройством после обучения.
Количество мест на бесплатное обучение ограничено, спешите подать заявку.
Реклама. ООО "АДИ ГРУПП". ИНН 7017283529. erid: LjN8KVBjN
👍3
Установка и настройка Рутокен VPN Community Edition
Как показывает практика, коллеги, особенно начинающие, очень любят всякие обертки над VPN-серверами: веб-интерфейсы, скрипты, мобильные приложения и т.д. и т.п.
Поэтому довольно странно, что практически никто не знает о Рутокен VPN Community Edition, потому что, с одной стороны, это классический OpenVPN, а с другой - все что так любят во внешних обертках. Включая портал самообслуживания.
На наш взгляд продукт незаслуженно получает мало внимания. Подробнее в нашей статье:
https://interface31.ru/tech_it/2022/10/ustanovka-i-nastroyka-rutoken-vpn-community-edition.html
Как показывает практика, коллеги, особенно начинающие, очень любят всякие обертки над VPN-серверами: веб-интерфейсы, скрипты, мобильные приложения и т.д. и т.п.
Поэтому довольно странно, что практически никто не знает о Рутокен VPN Community Edition, потому что, с одной стороны, это классический OpenVPN, а с другой - все что так любят во внешних обертках. Включая портал самообслуживания.
На наш взгляд продукт незаслуженно получает мало внимания. Подробнее в нашей статье:
https://interface31.ru/tech_it/2022/10/ustanovka-i-nastroyka-rutoken-vpn-community-edition.html
👍15🤮4
Я и Рутокен VPN Community Edition
Anonymous Poll
1%
Знаю, использую
14%
Знаю, не использую
8%
Не знал, буду использовать
22%
Не знал, не буду использовать
8%
Не использую подобные оболочки вообще
6%
Не приемлю по религиозным причинам
18%
Хорошая шутка, товарищ майор
24%
Ничего не понятно, но очень интересно
😁4
IT Elements, конференция про сети и инфраструктуру ― базовые элементы, которые создают надежный ИТ-фундамент компании.
22-23 ноября на IT Elements будет 1000 экспертов, 50 спикеров, 20 кейсов, 20 демо, выставка ИТ-решений, обмен отраслевым опытом и нетворкинг.
Среди тем:
▪️White Box и сетевые фабрики. Дискуссия с экспертами Яндекса, Ростелеком-ЦОД, Edgecore Networks, RuTube
▪️Chaos Engineering. Управляемый краш-тест вашей инфраструктуры. Кирилл Пономарев, инженер, Райффайзен банк
▪️Есть ли в России SD-WAN? Дискуссия с экспертами Bi.Zone и Kaspersky
▪️Non-legacy monitoring: построение системы мониторинга предприятия на основе IAC и ITAM практик. Герасим Панченко, руководитель группы эксплуатации и мониторинга, БИОКАД
▪️Эволюция инструментов автоматизации. Алексей Крылов, DevOps Competence Lead, Сбер
▪️Что с отечественной разработкой ПО на сетевое оборудование? QTECH
✅ Регистрация
Реклама. АО "ИНФОСИСТЕМЫ ДЖЕТ". ИНН 7729058675. erid: LjN8KRqyr
22-23 ноября на IT Elements будет 1000 экспертов, 50 спикеров, 20 кейсов, 20 демо, выставка ИТ-решений, обмен отраслевым опытом и нетворкинг.
Среди тем:
▪️White Box и сетевые фабрики. Дискуссия с экспертами Яндекса, Ростелеком-ЦОД, Edgecore Networks, RuTube
▪️Chaos Engineering. Управляемый краш-тест вашей инфраструктуры. Кирилл Пономарев, инженер, Райффайзен банк
▪️Есть ли в России SD-WAN? Дискуссия с экспертами Bi.Zone и Kaspersky
▪️Non-legacy monitoring: построение системы мониторинга предприятия на основе IAC и ITAM практик. Герасим Панченко, руководитель группы эксплуатации и мониторинга, БИОКАД
▪️Эволюция инструментов автоматизации. Алексей Крылов, DevOps Competence Lead, Сбер
▪️Что с отечественной разработкой ПО на сетевое оборудование? QTECH
✅ Регистрация
Реклама. АО "ИНФОСИСТЕМЫ ДЖЕТ". ИНН 7729058675. erid: LjN8KRqyr
❤2👍1