С необходимостью удобно и безопасно организовывать удалённую работу своих сотрудников бизнес столкнулся давно. Но если раньше эту задачу можно было регулярно откладывать и продолжать обдумывать, то сейчас времени уже нет: «удалёнка» – главный тренд весны 2020 во всём мире. В этом материале мы хотели бы поделиться своим опытом организации удалённой работы сотрудников, потому что плотно занимаемся этим вопросом уже почти 25 лет.

Удалённый формат работы абсолютно привычен для любого сотрудника Dell Technologies, и наши российские офисы в этом плане не являются исключением. Конкретно сегодня мы бы хотели сконцентрироваться на вариантах решения задачи с помощью имеющейся техники, то есть оперативных решениях без применения VDI, и развёртывании VDI в максимально короткие сроки. Под катом мы дадим развёрнутые ответы на четыре вопроса, которые наши действующие и потенциальные заказчики в последнее время задают чаще всего.

Хочу поделиться несколькими советами по настройке удаленного подключения к рабочим местам по RDP. Расскажу как проапгрейдить древний RPC-HTTP до UDP, похвалю и поругаю Windows 10 и AVC, разберу решение нескольких типичных проблем.

Считаем, что для подключения используется Remote Desktop Gateway (RDGW), а в качестве серверов выступают рабочие станции. Использовать RDGW очень удобно, потому что шлюз становится общей точкой входа для всех клиентов. Это дает возможность лучше контролировать доступ, вести учет подключений и их продолжительность. Даже если VPN позволяет подключиться к рабочим машинам напрямую — это не лучший вариант.

RDGW настраивается быстро, просто, а Let's Encrypt и win-acme легко решают проблему с доверенным сертификатом.

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

RPC-HTTP (плохо)
HTTP (лучше)
HTTP+UDP (отлично)

Под сервером будем понимать рабочую машину, под клиентом — домашнюю.
Первое, с чего стоит начать, это «плохо» превратить в «отлично».

Непрекращающийся хайп вокруг гигабитных скоростей Wi-Fi современных стандартов провоцирует инженеров прояснять эту тему понятным для всех образом.
Что пытаются натянуть за уши маркетологи? Что говорят инженеры? Где же истина?
Как всегда, где-то рядом. Какой пропускной способности ожидать в реальных условиях и почему – вы найдете ответ в этой статье. Если совсем нет времени читать, а хочется знать волшебную цифру – 75 Мбит/c на двухдиапазонную точку доступа, на всех. Кому интересны детали, читайте дальше.

ТЗ должно быть простым, понятным и проверяемым

Вы такое видели?

Каких только ТЗ я не встречал за 12 лет в этой теме. Классические пункты — это “бесшовный роуминг” и “устойчивое 100% покрытие всей площади”. Понятно, что все мы хотим прекрасной связи. Какими же словами описать то, что мы хотим, чтобы это можно было адекватно проверить?

Я поделюсь своими наработками на эту тему с надеждой, что инженеры интеграторов (которые часто и пишут эти ТЗ) или сами заказчики (в лице IT команды) возьмут на вооружение эти данные. Тогда в будущем мы все будем иметь дело с адекватными ТЗ, с которыми можно начинать работу быстро, а не вытягивать клещами нужную информацию, без которой хорошего Wi-Fi не построишь.

Как в значке Wi-Fi три изогнутых линии, основных пунктов тоже будет три.



Тем, кто так или иначе связан с Enterprise Wi-Fi и не только, будет интересно.

Введение

Пришла пора покупать СХД. Какую взять, кого слушать? Вендор А рассказывает про вендора B, а еще есть интегратор C, который рассказывает обратное и советует вендора D. В такой ситуации и у опытного архитектора по системам хранения голова пойдет кругом, особенно со всеми новыми вендорами и модными сегодня SDS и гиперконвергенцией.

Итак, как же во всем этом разобраться и не оказаться в дураках? Мы (AntonVirtual Антон Жбанков и korp Евгений Елизаров) попробуем об этом рассказать русским языком по белому.
Статья во многом перекликается, и фактически является расширением “Дизайна виртуализованного ЦОД” в плане выбора систем хранения данных и обзора технологий систем хранения. Мы кратко рассмотрим общую теорию, но рекомендуем ознакомиться и с указанной статьей.

Зачем

Часто можно наблюдать ситуацию как приходит новый человек на форум или в специализированный чатик, как например Storage Discussions и задает вопрос: “вот мне предлагают два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, что посоветуете”?

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

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

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

Если вы занимаетесь построением средних и крупных Wi-Fi сетей, где самое меньшее число точек доступа это несколько десятков, а на больших объектах оно может исчисляться сотнями и тысячами, вам нужны инструменты для планирования такой внушительной сети. От результатов планирования/проектирования будет зависеть работа Wi-Fi на протяжении жизненного цикла сети, а это, для нашей страны, порой около 10 лет.

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

Если вы ошибетесь (или перестрахуетесь) и заложите больше точек доступа, то заказчик сильно переплатит и проблемы, возможно, получит сразу, от избыточной интерференции (CCI и ACI), созданной своими же точками, ибо на ПНР инженер решил доверить настройку сети автоматике (RRM) и не проверил радиообследованием, как эта автоматика отработала. Сдадите ли вы вообще сеть в таком случае?

Как и во всех аспектах нашей жизни, в Wi-Fi сетях нужно стремиться к золотой середине. Точек доступа должно быть ровно столько, чтобы обеспечить решение поставленной в ТЗ задачи (ведь вы не поленились написать добротное ТЗ?). При этом хороший инженер обладает видением, которое позволяет объективно оценивать перспективу жизни сети и закладывать адекватный запас прочности.

В этой статье я поделюсь своим опытом построения Wi-Fi сетей и подробно расскажу об инструменте №1 который уже давно помогает мне решать самые трудные задачи. Этот инструмент Ekahau Pro 10, ранее известный как Ekahau Site Survey Pro. Если вам интересна тема Wi-Fi и вообще, добро пожаловать под кат!

<< До этого: Опорная сеть

Примерно семьдесят лет подряд у AT&T, материнской компании Bell System, почти не было конкурентов в области американских телекоммуникаций. Единственным хоть сколько-нибудь значительным из её соперников была General Telephone, позже ставшая известной, как GT&E, а потом просто GTE. Но при этом к середине XX века в её распоряжении было всего лишь два миллиона телефонных линий, то есть, не более 5% от общего рынка. Период доминирования AT&T – от джентльменского соглашения с правительством в 1913 году и до момента, когда то же самое правительство расчленило её в 1982 – примерно обозначает начало и конец странной политической эры в США; время, когда граждане были способны верить в доброжелательность и эффективность крупной бюрократической системы.

<< До этого: Многократное переизобретение

Введение

В начале 1970-х в компанию AT&T, огромную телекоммуникационную монополию США, пришёл Ларри Робертс с интересным предложением. В то время он был директором вычислительного подразделения управления перспективных исследовательских проектов (Advanced Research Projects Agency, ARPA), относительно молодой организации, действующей в рамках Министерства обороны, и занимавшейся долгосрочными исследованиями, оторванными от действительности. За прошедшие до этого момента пять лет Робертс курировал создание ARPANET, первой из достаточно важных компьютерных сетей, соединявшей компьютеры, расположенные в 25 различных местах по всей стране.

Сеть оказалась успешной, но её долгосрочное существование и вся связанная с этим бюрократия не попадала под полномочия ARPA. Робертс искал способ сбросить эту задачу на кого-то другого. И вот он связался с директорами AT&T, чтобы предложить им «ключи» от этой системы. Тщательно обдумав предложение, AT&T в итоге отказалась от него. Старшие инженеры и менеджеры компании считали, что фундаментальная технология ARPANET была непрактичной и нестабильной, и ей не было места в системе, спроектированной для предоставления надёжного и универсального сервиса.

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

Существует несколько вариантов решения данной задачи:

1. Использование единого пароля на всех компьютерах. Пароль может устанавливаться либо во время деплоя с помощью MDT или SCCM, либо с помощью предпочтений групповых политик после деплоя. Обычно при таком подходе пароль никогда не меняется, а значит рано или поздно утечет (при увольнении администратора или пользователь может подглядеть ввод пароля), при этом скомпрометированный пароль дает доступ ко всем ПК в организации.
2. Единоразовая установка уникального пароля на каждом ПК. Обычно происходит при деплое. Вариантов масса — начиная от ручной генерации случайного пароля и сохранении его в системе учета паролей (Keepass, OnePassword, Excel), заканчивая автоматической генерацией пароля по алгоритму известному администраторам, где входными данными является имя ПК. Зная алгоритм, администратор может на месте рассчитать пароль и авторизоваться на любом ПК. Минусы примерно аналогичны варианту 1: Уволенный администратор сохраняет возможность войти на любой ПК, зато при компрометации пароля пользователем он получает доступ только к одному ПК, а не ко всем сразу.
3. Использование системы, которая будет автоматически генерировать случайные пароли для каждого ПК и менять их по установленному расписанию. Минусы предыдущих вариантов тут исключены — скомпрометированный пароль будет изменен по расписанию, и уволенный администратор через некоторое время не сможет авторизоваться на ПК даже если и украдет действующую на момент увольнения базу паролей.

Одной из таких систем является LAPS, установку и настройку которой мы разберем в этой статье.

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

В этот раз все мануалы были на ELK5 или еще старше, а мне не очень хотелось ставить софтину пред-предыдущих версий. Мне хотелось взять софтину с наиболее перспективными сроками поддержки: желательно самое свежее из стабильного.

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

Итак, сегодня Mikrotik (RouterOS), Suricata 4.1, Elasticsearch+Filebeat+Kibana 6.5.

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

Дисклеймер

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

Предисловие

Сначала я просто хотел написать небольшую статью о том, как мы разносили базы по службам, но в ходе углубления в этот процесс мы добавляли всякие разные штуки (мониторинг служб, потом мониторинг пользователей внутри 1С, потом прикрутили заббикс, и, наконец, пришли к CI/CD на базе 1С). В итоге я понимаю что пихать это в одну статью будет слишком — решил разделить на несколько. Ну а название навеяно циклом статей "сети для самых маленьких", которые принесли мне много приятных минут и к которым я отсылаю всех, кто "хочет изучить сети". Итак, мы приступаем!

У нас было несколько фотографий основной печатной платы, видео из YouTube с осциллограммами напряжений на стоках мосфетов, комментарий на форуме с перечислением ёмкостей резонансных конденсаторов, а также несколько видеозаписей распаковок со съёмками процесса разогрева жала. Особое беспокойство вызывало видео с измерением пиковой потребляемой мощности при разогреве. Нет ничего более грустного, чем сгоревший свежекупленный на амазоне картридж стоимостью четыре тысячи рублей. Но… давайте начнём всё с начала.

Давным-давно, в далекой-далекой галактике…, стояла передо мной задача организовать подключение нового филиала к центральному офису. В филиале доступно было два сервера, и я думал, как было бы неплохо организовать из двух серверов отказоустойчивый кластер hyper-v. Однако времена были давние, еще до выхода 2012 сервера. Для организации кластера требуется внешнее хранилище и сделать отказоустойчивость из двух серверов было в принципе невозможно.

Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.

В предыдущей публикации я представил обзор истории инженерных конструкторов fischertechnik с 1965 по 2017 г. и сейчас, в соответствии с пожеланием читателей, выкладываю обзор конструкторского набора 524328 ROBOTICS TXT Discovery set.

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

В картонной коробке находятся механические детали, моторы, программируемый контроллер TXT, видеокамера, программное обеспечение ROBO Pro, инструкция по сборке и небольшая книжка в формате PDF с учебным материалом.

Дополнительно для работы с конструктором нам понадобится аккумуляторный набор 34969, в который входит NiMH аккумулятор и зарядное устройство.

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

И снова здравствуй, Хабр! Открываем цикл статей-фотоотчетов о строительстве нашего нового МЦОДа Модуль №3!



Начнем с отчета об установке ВРУ и щитов потребителей.

Achtung! Много дрянных фото под катом!

Disclaimer

Эта статья содержит некоторое количество программного кода, написанного на языке Python. Ввиду того, что автор статьи по профессии является сисадмином, но не программистом — стиль и качество этого кода, могут вызвать проявление неконтролируемых эмоций у профессионалов. Пожалуйста, немедленно прекратите чтение если вид неаккуратного или неоптимального кода может негативно сказаться на вашем психическом состоянии.

Постановка задачи

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

• RaspberryPi 3 model B
  
• Вебкамера Logitech C270
  
• Карта памяти Kingston microSDHC 16 Гб
• Некоторое количество проводов и адаптеров

Из всего перечисленного, было решено построить систему домашнего видео-наблюдения с функционалом оповещения о вторжении. В качестве платформы был выбран телеграм-бот. Бот имеет следующие преимущества перед другими возможными реализациями (веб, мобильное приложение):

• Не требуется установки дополнительного клиентского ПО
• Серверная часть может работать с приватным IP адресом через NAT, при этом предъявляются минимальные требования к подключению (вплоть до 3G модема)
• Большая часть инфраструктуры находится на стороне сервис-провайдера, который за меня решил вопросы авторизации, безопасности итп...

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

Относительно недавно наша компания организовала программу стажировки для молодых специалистов по направлениям:

1. Основы сетевых технологий (Cisco).
2. Серверное администрирование (Windows, Linux).
3. Технологии виртуализации и систем хранения данных (VMware, Microsoft Hyper-V).
4. Современные средства защиты информации (UTM, NGFW, Sandbox и т.д.).
5. Этичный хакинг (CEH) и Pentest.
6. Обработка машинных данных (Log management — Splunk, MaxPatrol SIEM)

Если взять сетевое направление, то в ходе практики, почти у всех начинающих сетевых инженеров или студентов данного направления возникает вопрос: “Что нужно знать сетевому инженеру? На чем сосредоточить силы?”. Я всегда начинал советовать какие-то темы и направления, затем понял, что было бы неплохо составить некий чек-лист, для молодых инженеров, чтобы у них был ясный вектор развития. Кроме того я попытаюсь дать ссылки на ресурсы, где эти навыки можно получить. Естественно универсального списка нет и все что я могу предложить это свое представление о необходимых навыках любого сетевого инженера. Данный список составлялся на основе личного опыта и отражает то, с чем чаще всего приходится сталкиваться в работе. Уверен, что у большинства есть свое мнение на счет обязательных навыков и скорее всего оно не совпадает с моим. Если вас заинтересовала данная тема, то добро пожаловать под кат…

Доброго времени суток, Хабр! Чуть больше года назад была анонсирована ALPHA версия популярной Open Source операционной системы для хранения данных FreeNAS.

На сегодняшний день вышеупомянутый продукт коллективного труда дорос аж до BETA2 и уже неспешно-стремительно движется к своему релизу. Если вам интересно, что же там «напридумывали» разработчики — добро пожаловать под кат.