SSHFS как облачная флешка и почему WebDav не торт

SSH стал основным способом работы с удаленными машинами как на Linux, так и windows. Тем острее встал вопрос о необходимости доступа к файлам на удаленной машине.
Тем у кого есть облачные сервисы от keenetic, можно не читать, там всё сделано грамотно и доходчиво, достаточно только настроить и пользоваться.

Мне же удовольствие keenetic недоступно финансово, поэтому я реализую более простое решение.

SSHFS это виртуальная файловая система, которая позволяет представить любой ssh-ресурс в качестве папки в Linux или сетевого диска в Windows.

Для организации такого диска лучше использовать специальную утилиту, позволяющую удобно настроить и в один клик подключать сетевые диски по протоколу ssh.

Чтобы скачать эту утилиту, нужно перейти по ссылке https://github.com/evsar3/sshfs-win-manager

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

Чтобы добавить ваш ресурс, необходимо нажать кнопку «add connection».
Откроется окно настройки подключения:

Здесь в поле NAME необходимо указать имя ресурса, так он будет отображаться в системе Windows/
В поле IP/HOST требуется указать ip-адрес машины, либо доменное имя удаленного ПК. Если подключение выполняется по локальной сети и настроен локальный DNS, то сетевое имя будет host.local или host.yourdomain.local. host это имя машины.
В поле PORT необходимо указать «порт» на котором «слушает» удаленный ssh. Если удаленный компьютер находится за NAT (роутер, шлюз), то на роутере необходимо выполнить «проброс» портов. В локальной домашней сети ничего делать не нужно.
В поле USER необходимо ввести имя пользователя.
Поле AUTHENTICATION METHOD предлагает один из трёх способов авторизации на удаленной машине. Пароль, пароль, сохраняемый в программе, пароль, спрашиваемый при каждом подключении, или по открытому ключу. Какой способ авторизации использовать, выбирать читателю.

В поле PATH должен быть указан полный путь к папке на удаленном ресурсе. У каждого пользователя он будет свой, если удаленная машина разрешает, то можно подключиться и к корневому каталогу «/»
Поле DRIVE LETTER снабжено выпадающем списком и предлагает назначить любую не занятую букву как локальному диску.

После ввода данных требуется сохранить параметры.
Данное окно закроется и останется главное окно программы:

…в котором необходимо нажать на кнопку «подключить» (смотри картинку выше).
Если всё нормально, то ресурс будет подключен, а в проводнике отобразится новый диск, как локальный:

В Linux ничего устанавливать обычно не требуется, любой ресурс SSH подключается из файлового менеджера методом «подключиться к серверу», система всё сделает самостоятельно.

Плюсы такого способа:

  1. Отсутствуют системные ограничения на размер файла. Это значит, что вы можете делать бэкапы по зашифрованному каналу без ограничений на размер файла.
  2. Подключенный ресурс работает как локальный диск и его можно использовать напрямую.
  3. Нет прослоек в виде веб-серверов типа Apache2 или IIS.
  4. Не требуется SSL сертификат, соединение зашифровано.
  5. Одинаково хорошо работает как в Windows, так и в Linux.

Минусы:

  1. Возможные ограничения на работу протокола SSH провайдером, если вы работаете с удаленным ресурсом через Интернет. В этом случае требуются меры для маскировки трафика под https.
  2. Возможно снижение скорости обмена данными на узких каналах из-за шифрования.
  3. SSH хоть и хорошая вещь, но не панацея, существуют известные уязвимости серверной части, поэтому при работе через Интернет необходимы индивидуальные средства защиты от вторжений.
  4. Требуется достаточно глубокое знание и грамотная организация сети.

А почему не WebDav?

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

  1. Сложность настройки сервера. Для того, чтобы настроить сервер на работу с WebDav требуется использовать IIS на Windows и любой web-сервер на Linux-системах. Требуется доменное имя и SSL-сертификат. На 2025 год у нас практически не осталось клиентов, которые бы не требовали TLS-шифрования http — трафика. И подключиться к webdav-ресурсу без шифрования в 2025 году будет проблемой.
  2. Встроенные ограничения на размер файла в операционных системах. В Linux на трафик по протоколу WebDav действует ограничение в 2 Гб на один файл. Причем я не смог выяснить можно ли снять это ограничение. Но раз keenetic — производитель сетевого оборудования смогли снять это ограничение, значит способы есть и они закрыты коммерческими лицензиями, и именно поэтому нет вразумительных ответов на запросы, связанные с ограничением. А такие решения, как Nextcloud вносят больше проблем при работе по WebDav, чем пользы.
    В Windows ограничения изменяются разными методами. Полностью не снимаются, но их можно отодвинуть.
    Что я такого большого перекачиваю в одном файле? Не ваше дело.
  3. Сложность с доступом к ресурсу по WebDav с разных устройств. Я на себе испытал эту проблему. Проводник Windows, любые файловые менеджеры Linux и Андроид по-разному ведут себя с одним и тем же webdav ресурсом. И нет единого способа подключиться к одному ресурсу. Поэтому на данный момент webdav мной практически не используется.

Вместо вывода.

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

Что применять, выбирать Вам.

Почему греется северный мост на SuperMicro X8DTL-i

С серверной платой SM X8DTL-i я познакомился в 2020 году и мониторя датчики я обнаружил, что северный мост это платы сильно греется (71 градус по Цельсию).

Причина в сильной нагрузке на ЦП, когда включена графическая подсистема в ОС Linux. Если отключить GUI, то температура моста не превышает 45 градусов.
Точно такая же проблема возникает, если в PCI-Ex16 (по факту это PCI-Ex8 в слоте x16) установить видеокарту и включить GUI, в этом случае мост греется до 71 градуса, но в итоге температура стабилизируется.
С Windows тоже самое, пробовал имеющиеся у меня дистрибутивы серверной винды на триальном периоде, северный мост также сильно греется. Плюс (точнее это минус винды) мне не нравится, как винда гоняет жесткий диск. После многих лет, попробовал вместо линукса windows. Мои Хитачи никогда не были так жестоко изнасилованы.
Решение проблемы следующее. Если подразумевается работа с GUI и RDP, то на радиатор северного моста следует установить вентилятор размером 50*50, желательно оборотистый. Это увеличит интенсивность обдува радиатора и теплоотвод. И поможет снизить тепловую нагрузку на северный мост до 41 градуса (проверено на настольной сборке с данной платой).

Конечно же подразумевается корпус ATX. Для стоечного исполнения должно хватать проточной вентиляции корпуса.

Сейчас обнаружил, что в моем стоечном сервере греется серверный мост, при этом отключены GUI и XRDP. Температура держится на уровне 82-83 градуса. При максимуме 90. Это довольно много. Здесь вероятно требуется ревизия термоинтерфейса и возможно, замена термопасты, либо термопрокладки, смотря что используется в этой системе. Ну и вентилятор 50 мм также стоит установить.

Немного о правах в Linux

Разграничение доступа

Linux это среда выполнения и инструмент для организации хранения файлов. Системных и пользовательских.

Права разделяются как минимум на две категории:

  1. Доступ к файлам и каталогам для пользователей.
  2. Доступ к файлам и каталогам для программ.

В самом простом случае, в ОС Linux присутствует как минимум один пользователь. Он и пользователь, и администратор компьютера. По умолчанию его зовут root и когда он создает файлы, то они наследуют принадлежность к пользователю root, а также набор прав доступа к этим файлам. И никто, кроме root изначально не имеет доступа к этим файлам.

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

Поскольку в системе Linux на каждый файл назначены свои права доступа, а также тот факт, что в Linux любой объект это файл, следовательно, к этому файлу должно быть право доступа у пользователя. Если у нас пользователь root запускает программу, то этой программе передаются права пользователя root и эта программа также будет иметь права доступа к файлу, которому назначены права пользователя root. В классическом Linux пользователь root имеет монопольный доступ ко всем объектам системы, даже к тем, которым назначены права других пользователей. Он имеет право менять права доступа к файлам, назначать произвольную группу и произвольных пользователей. Поэтому в чистом виде рассматривать пользователя root не имеет смысла. Например в Alt Linux по умолчанию действует трехуровненвая система прав доступа:

  1. Пользователи.
  2. Неполный root.
  3. Root.

В классическом Debian действует двухуровневая и полуторная система прав:

  1. Пользователь.
  2. root.

Полуторная система:

  1. Пользователь.
  2. Sudouser — реализация полуторной системы, когда пользователю передаются root права. Она довольно гибкая и можно установить пользователю необходимый уровень доступа.

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

Визуально, систему прав доступа можно показать так:

На картинке выше показано, что файл setup-nextcloud.php принадлежит пользователю aleksey, группе aleksey и права 0644. Это восьмеричная форма записи прав доступа.
я пока не рассматриваю первый разряд, число которого 0. Но число 6 это разрешение чтения и записи файла для пользователя, 4 это право только на чтение пользователям, входящим в группу aleksey, 4 это право на чтение файла остальным пользователям.
более подробно права доступа описаны в следующей таблице:

Восьмеричная записьЧеловекопонятнаяПрава на файлПрава на каталог
0нет правнет прав
1—xвыполнениечтение файлов и их свойств
2-w-записьнет прав
3-wxзапись и выполнениевсё, кроме чтения списка файлов
4r—чтениечтение имен файлов
5r-xчтение и выполнениечтение имен файлов
6rw-чтение и записьчтение имен файлов и запись файлов в каталог
7rwxполный доступполный доступ к каталогу

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

Группы пользователей

Группы пользователей появились неслучайно. Даже в пределах одной системы и одного компьютера невозможно обойтись всего двумя пользователями. По крайней мере в Linux. Хотя в Windows ситуация не отличается. И очень часто некоторые процессы должны запускаться от имени фиктивного пользователя и не должны выходит за пределы своих компетенций. Например большинство веб-служб имеют пользователя www-data и полномочия этого пользователя ограничены группой www-data. Если конкретного пользователя добавить в группу www-data, то этот пользователь будет иметь доступ к тем файлам, к которым имеют права доступа пользователи группы www-data. То-есть может быть владелец aleksey:www-data, где www-data — группа пользователей. Тогда права на файлы и каталоги должны устанавливаться вторым битом (070) например.

Почему? Вхождение пользователей в группы определяет компетенции конкретного пользователя.

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

По философии Linux, у простого пользователя должен быть ограниченный набор прав доступа к системе. По классике. В голом linux у пользователя изначально вовсе нет никаких прав, кроме как для работы в «домашней» папке. Ему запрещено всё, в том числе работа с флешками, cd/dvd, настройка сети, времени, да и вообще, всего, чего не должен касаться пользователь. За него должен всё настроить администратор.

Почему бы не дать эти привилегии пользователю? Ведь по большей мере пользователь устанавливает Linux для себя, чтобы работать на своем ПК.

Здесь философия проста: пользователю что не разрешено, то запрещено.

Продолжение следует

Микрорассказ

На остановке Симоняка. Автобус, ждет, когда леди лет 55 добежит до автобуса, та на бегу докуривает цигарку (другим словом просто не описать), успевает бросить окурок в урну, забежать в закрывающиеся двери, приложить карточку к валидатору и с раскрытым смартфоном плюхается на первое свободное место. (С)

Добавляем носитель c данными в nextcloud не используя консоль (кроме xfs)

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

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

У меня в сервере стоит один жесткий диск, который не включен в fstab и работает факультативно. То-есть когда я к нему обращусь. Он поделен на разделы, там есть и ext4, и xfs. На данный момент с xfs у меня решения не нашлось. Его можно подключить лишь используя командную строку или включить в загрузку через fstab.

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

Чтобы не использовать терминал, который ненавидит большинство доморощенных админов, будем использовать webmin. Хотя это тоже костыль, хотелось бы иметь возможность управлять дисками прямо из NextCloud. Проблема линукса в том, что до минимального уровня автоматизации настройки после установки ему ещё очень далеко. Когда придёт время, я постараюсь улучшить автоматизацию.

Итак, откроем наш webmin и зайдём в раздел «Оборудование» > «Разделы на локальных дисках»:

На картинке выше мы видим список устройств, подключенных к домашнему серверу, нас интересует устройство SATA B. Чтобы его выбрать, просто кликнем по данному устройству:

На картинке выше видно, для чего задействованы те или иные разделы. Они расположены под своими номерами. Нас интересует графа «Используется для». Здесь видно, что раздел 6 используется как swap, а раздел 7 имеет файловую систему XFS и подключен к системе, как /H.

Для понимания происходящего, я сделал так, чтобы обозначение разделов, было похожим на то, как представляют себе их пользователи windows, то-есть диск C — диск Z. Для меня лично это не имеет никакого значения, но так принято у «оконщиков».

Кликнем на разделе 5:

Есть косяк в том, что мы не видим на этой странице информации о типе раздела, поэтому помним, что до этого момента этот раздел имел ФС ext4.
Обратим внимание на поле «Монтировать раздел на:»
Здесь необходимо вписать адрес для монтирования и типа файловой системы, что опять же является серьёзной недоработкой, точка монтирования должна создаваться в процессе, а в нашем случае нужно прибегать к файловому менеджеру, с помощью которого я создам точку монтирования «/E» и скопирую этот адрес в поле, как на картинке:

И затем требуется нажать кнопку «Монтировать раздел на:»
После выполнения данной операции откроется страница опций монтирования:

Поскольку мне не надо, чтобы этот раздел монтировался при загрузке, я установил соответствующий флаг, как на картинке выше. Если необходимо сохранить возможность монтирования при загрузке, для таких разделов я предпочитаю использовать cron с соответствующим заданием, а не fstab, почему, потом напишу.
После этого я нажимаю «Создать».
Если ошибок не возникло, то откроется список подмонтированных разделов, в том числе технических:

А также их статус в системе и параметры, автомонтирование или нет.
Теперь необходимо проверить и настроить права доступа. Связано это с тем, что мы подключили раздел ext4, на котором есть данные и эти данные не будут видны в Nextcloud, если не будет выполнено два условия:
1. У пользователя, от имени которого работает Nextcloud должен быть доступ к каталогу, который теперь доступен в системе, как /E.
2. Установить права доступа на каталог, к которому нужно предоставить доступ NextCloud.
Сам же NextCloud чаще всего работает от системного пользователя www-data, проверять это обычному пользователю не требуется.
В Webmin есть встроенный файловый менеджер, через который мы можем назначить права доступа практически к любому каталогу или файлу в системе:

Заходим в файловый менеджер и выбираем наш диск по адресу /E, как на рисунке выше.

Здесь мы видим, что подключенный раздел имеет организацию файлов, как в Linux. И действительно, у меня на этом разделе архивная файловая система, про которую я уже даже забыл :). И кстати, поэтому над ней можно поиздеваться, ибо уже не жалко. Однако, я назначу права доступа на конкретную папку, а именно на свой домашний каталог ибо там у меня остались файлы, которые может быть ещё даже пригодятся. Переходим в /home/user
затем:
Нажимаем «выбрать все» ;

и в меню «инструменты» выбираем пункт «смена владельца»

Откроется окошко:

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

Теперь переходим к подключению в Nextcloud.
В этой облачной системе, чтобы подключить локальные ресурсы нужно зайти через учетную запись администратора. Я разделяю полномочия учетных записей администратора и других пользователей, поэтому захожу в административную учетную запись.
Затем, захожу в параметры сервера и выбираю пункт «внешнее хранилище»
затем добавляю новый раздел, доступный по адресу, который я указал выше:

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

При наличии прав www-data у пользователя будет возможность распоряжаться файлами в соответствии с назначенными правами. Поэтому если не получаются операции удаления файлов, то это значит, что пользователю www-data разрешено только чтение данных файлов и каталогов. Это очень важно, потому что Nextcloud имеет право на распоряжение файлами только от того имени пользователя, от которого запущен его процесс.
Также обязательно следует различать пользователя системы, на которой работает Nextcloud и пользователя самого Nextcloud.
Многие пользователи Windows, которые пытаются организовать сервер на Nextcloud плохо понимают и плохо разбираются в правах доступа и понимании пользователя. В их понимании пользователь облака, пользователь-администратор и пользователь системы хоста это одно и тоже.
Пока всё.

Метро для данных

Я уже создавал пример туннелирования данных для XRDP. Настало время упростить способ подключения и выполнять его нужно из операционной системы windows 10. Для Linux я напишу отдельную статью, потому что принцип схожий, но всё равно там это делается иначе.

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

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

Поэтому откроем любой текстовый редактор (например geany) и запишем следующие строки:

start %windir%\system32\mstsc.exe -- запускает клиент RDP на локальном компьютере
@ssh -L PORT_LOC:192.168.55.1:PORT_REM_NAT -p PORT_SSH username@rem_hostname -N -- запускает соединение по ssh и пробрасывает туннель от удаленного ПК на локальный порт.

Далее будет достаточно ввести адрес localhost:PORT, где PORT=PORT_LOC.
PORT_REM_NAT — порт, на котором RDP слушает за NAT в удаленной сети.
Таким образом не требуется пробрасывать дополнительный порт, чтобы установить соединение по RDP, достаточно будет подключения по SSH на порт PORT_SSH, если он был изменён.
Параметр -N используется для того, чтобы ssh сессия работала в фоне.
Окно CMD можно будет свернуть.
Всё.

Решение с XRDP

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

Для начала как обычно, пришлось убрать доступ к RDP за NAT.
Открываем файл /etc/xrdp/xrdp.ini
и прописываем директиву port=tcp://locIP:PORT
например port=tcp://192.168.55.1:6458
С этого момента xrdp будет работать только в локальную сеть. Проброс портов через NAT не даст возможности подключиться к ПК по RDP, зато можно физически связать удаленную машину с локальной используя туннель SSH:
мне нужно было подключиться из Windows, поэтому в качестве клиента можно использовать putty, правда туннель придется настраивать каждый раз заново, однако в конце статьи я привел решение, которое позволит создавать туннель не прибегая к putty:

после запуска и установки соединения, нужно будет настроить RDP на подключение по адресу localhost:12345, где localhost это компьютер, с которого мы подключаемся, а 12345 это порт, на который мы это будем делать:

Если всё верно настроено, то после нажатия «Подключить» откроется окно логина в XRDP (в моём случае подключение идёт к ПК на Debian 12):

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

Чтобы не использовать Putty, можно использовать команду для CMD/PowerShell, поскольку ssh сейчас можно доустановить в Windows не прибегая к сложным манипуляциям.
Синтаксис команды будет таким:

ssh -L 12345:192.168.55.1:4556 -p PORT usver@remotehostname

где PORT это номер порта, на котором слушает удаленный ssh сервер, если он перенастроен на альтернативный.
Ах да, очень важно знать имя хоста, либо IP адрес, находящийся за NAT.
К слову, в моём случае это костыль, так как комп, имея две сетевые карты, в моем случае сам выполняет роль маршрутизатора, одной дыркой подключенный в LAN, а другой в WAN, поэтому всё так сложно. Из-за проблем с роутером и отсутствием возможности пока что купить хороший роутер, приходится применять такие дикие решения, однако они, как ни странно, работают.

Один день сервера в сети

Регулярно просматриваю логи сервера и по большей мере они содержат информацию о работе брандмауэра и некоторых служб, которые «смотрят» в сеть.

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

Так, в один прекрасный день я стал наблюдать, что нагрузка на сеть возросла. Я сразу полез в журнал и увидел, что мой DNS сервер стал сходить с ума. У меня был включен кэш для того, чтобы использовать свой DNS извне в качестве альтернативного и я считал, что иметь такую штуку полезно. Однако, я ошибался. Когда bind стал ругаться, что кэш ограничен 100 записями типа TXT на одно доменное имя, я понял, что на мой адрес пошла «атака усиления» DNS. Подробнее об этом можно прочитать здесь и здесь.

Проблема бинтов (bind)

Однажды в логах я увидел это:
database: error: error adding ‘shine-prices.ru/TXT’ in ‘./IN’ (cache): too many records (must not exceed 100)
Это немного отличается от описанного на страницах, ссылки на которые я привёл выше. Но суть похожая. Bind отказывается кешировать указанные записи (и это правильно) и помимо этого генерирует повышенный трафик, что было заметно в программе сетевого мониторинга iptraf.
Решением было отключить кеширование и резолв любых доменных доменных имен, кроме своего собственного.
Однако, эта операция потребовала создания списка доверенных клиентов, которыми не являются внешние адреса, а также выходящие за пределы локальной сети.
Это выглядит примерно (потому что на самом деле сильно иначе) так:
$bind$/named.conf.options

options {
****************
recursion yes;
allow-recursion {192.168.x.0/24;};
allow-query {any;}
allow-query-cahe {разрешено;};
};

После этого логи очистились и DNS снизил нагрузку на сеть.

Проблема c webmin

Хорошая админка, но сразу после установки дырявая и требует входа через открытый порт. Если раньше такое поведение админа было нормальным, когда он выводит сетевые службы на альтернативные порты, то сейчас это перестало быть преградой. Сетевые сканеры очень хорошо находят всё что открыто, даже если оно не мелькает, и проверяют возможность подключения через любую открытую «дырку».
Так, на веб-сервере наибольшую опасность представляет служба администрирования баз данных. С ней работают и CMS, и некоторые локальные службы, для которых база данных является наиболее предпочтительным посредником. По факту для подключения требуется лишь физический канал, а если что-то открыто, значит уже «провода» соединены правильно.
Ну, это было мне пинком, чтобы убрать админку за NAT и проксировать запросы. Плюс, ужесточил требования по аутентификации.

XRDP. Новая цель — служба удаленного рабочего стола.

Sep 03 08:19:23 xrdp[348554]: [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file: [/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem]
Sep 03 08:19:23 xrdp[348554]: [ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied
Sep 03 08:19:23 xrdp[348554]: [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
Sep 03 08:19:23 xrdp[348554]: [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_sec_incoming: xrdp_mcs_incoming failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] libxrdp_force_read: header read error

Как видно, какая-то тварь пыталась долбиться на сервер xrdp причем в логе есть строчка:
Sep ***** xrdp[*****]: [INFO ] Socket 12: AF_INET6 connection received from ::ffff:194.180.49.104 port 49591
То-есть попытка законнектиться через INET6. Пока не понимаю, как это возможно, потому что у меня отключена адресация IPV6, но видимо это возможно. Поэтому временно отключил службу и закрыл открытый порт. Но картинка не радужная вот в каком смысле. Когда у тебя обычный роутер, он может не вести журнал на достаточном уровне. Когда у тебя шлюз, то логирование позволяет увидеть, насколько бурная в сети «жизнь».

Сварочное дело, мысли.

Очень странное ощущение, когда реальность оказывается совсем не такой, какой я её представлял. Итак, сварка. Обычная электродуговая, ручная. Я думал, что присадочная роль электрода вторична. Оказалось, что методики и ГОСТы ставят присадочную роль на второе место.

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

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

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

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

Предпосылки строительства поездов

Внимание! Первая публикация здесь. Дальнейшие только автором и с указанием авторства.

Автор статьи: Харькин А. В. Год публикации: 2025.

Уже несколько лет я занимаюсь испытаниями компонентов тягового подвижного состава в одной из компаний, компетенцией которой является преобразовательная техника, но не только она. Мне удалось прикоснуться к тяговым инверторам, которые ныне работают в «Иволгах», тяговым накопителям, которыми оборудуют новые поезда московского метрополитена, а также к некоторым экспериментальным устройствам, призванным сделать воздух в пассажирских терминалах чище и свежее.
Я наверное неправильно выразился, когда написал, что «не только она», у нас любая техника преобразует энергию в энергию. То-есть электрическую энергию в механическую, механическую в электрическую, электрическую в энергию химических связей и обратно. Даже реле это своего рода преобразователь. Поэтому я уточню, что у нас очень широкие компетенции.

Кто я такой?

Являясь инженером путей сообщения в области локомотивного хозяйства, я имею представление о том — зачем, почему и как происходит внедрение нового ТПС.
Здесь мне хочется сделать ремарку.
Что такое «новый подвижной состав»? У многих обывателей представление о поездах держится на уровне понимания «паровоз-вагон, расписание-вокзал»
Конец ремарки.
Однако, современные требования к качеству, скорости и объему перевозок (и грузовых, и пассажирских) приводят к научно-техническим изысканиям и попыткам сдвинуть неповоротливую систему эксплуатации подвижного состава, а также создание условий, которые уменьшили бы необходимость применения тепловозов на пассажирских станциях для проведения маневров.
От тепловозов в принципе нельзя отказаться, потому что это гарантия отказоустойчивости инфраструктуры, а также культура эксплуатации, закрепленная в принципах, о которых не напишут в популярной литературе.
Столица России — город Москва, включила в свою транспортную сеть участки, находящиеся в ведомстве РЖД. Это потребовало создания электропоездов с асинхронными тяговыми двигателями, которые были бы лишены недостатков, присущих двигателям постоянного тока, уменьшили бы количество коммутационной аппаратуры, а также сократили бы потребность в её обслуживании с целью уменьшения количества разбираемых для ревизии и ремонта узлов, поагрегатный ремонт, или ремонт с использованием подменного фонда агрегатов.
В то время, как на сеть РЖД в разных регионах России стали поступать электропоезда ЭС1, ЭС2, ЭС2Г, именуемые «Ласточками», государству необходим был собственный, независимый от иностранных разработок проект. Таким образом Москва разместила заказ на электропоезда «ИВолга» — ЭГ2Тв, которые впредь стал строить Тверской вагоностроительный завод, а конструкцию разработал ТМХ. Это был важный этап успешного внедрения собственных разработок, которая позволила создать десятки тысяч рабочих мест, не только на самом ТВЗ, но и в связанных с ним компаний-производств компонентов. А помимо этого мы получили гигантский опыт в разработке тяговых инверторов и других, не связанных с ними компонентов.

Сама по себе идея применения асинхронных тяговых двигателей не нова, исследования в этой области активно велись в прошлом, ведутся и в настоящем. И даже были созданы серийные типы ПС с асинхронным приводом, например электропоезда серии 81-720 — «Яуза», часть которых была с тиристорно-импульсным управлением ДПТ, часть с асинхронным приводом и даже были попытки создать электропоезда с вентильными двигателями постоянного тока, но достоверной информации по этим разработкам на данный момент у Автора нет, поэтому ограничусь только тем, что это всё слухи.

Что происходит сейчас
Если в простом случае классическая схема является «натуральной» и подчиняется линейному закону регулирования, основанного на законе Ома, где тяговые двигатели управляются путем изменения напряжения на щётках ДПТ, то плавное управление АТД происходит путём изменения частоты переменного напряжения и это накладывает серьёзные трудности при разработке таких систем. А под понятием «всё работает» сотни часов исследований, мелких и крупных неудач.
Асинхронный привод для тягового подвижного состава это полностью синтезированная система. Здесь тяговый инвертор и двигатель это единая система, как патрон и винтовка.

В начале 21 века Торжокский завод построил прототип современной «Иволги» — ЭТ2А, которая регулярно виднелась на деповских путях Санкт-Петербурга-Балтийского (ТЧ-15), но дальше испытаний дело не дошло, прототипы часто не доходят дальше опытной эксплуатации ввиду слабой надёжности и первоначальной сложности оборудования, к тому же подвижной состав железных дорог требует сертификации, а когда строишь неизвестно что, то и сертифицировать его вряд ли удастся без значительных изменений в конструкцию.
Сейчас на дворе 2025 год и у нас есть «Сапсаны» и «Ласточки» от Сименса, «Финисты» — наследие Сименса от УрВЗ, «Иволги» от ТВЗ и ЭТ4А от Торжокского завода. И самое приятное, что асинхронные электрички работают не только на столичных и курортных узлах, но и практически на всей сети железных дорог России, медленно, но верно вытесняя коллекторные «жужжалки». А метрополитены Москвы, Санкт-Петербурга и Казани уже более 10 лет успешно эксплуатируют поезда метро с АТД. И на очереди Новосибирский метрополитен. Это приятно, потому что попробуйте прокатиться в этих электричках. Скорость 160 км/ч, а ты и не чувствуешь. Не трясёт, не бросает. Однако это всё цель. А средство нужно создать. И нужно учитывать, что чем лучше конструкция, тем она дороже и тем хуже поддается ремонту.

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

  1. Поезда дальнего следования: это междугородние и международные поезда;
  2. Пригородное сообщение.
  3. Городское сообщение.

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

  1. Трудовые обязанности. Требуют мобильности сотрудников предприятий и не только в часы начал и окончаний смен.
  2. Культурный фонд города. Это массовая культура и спорт.
  3. Статус транзитного пункта. Порождает спрос на транспорт для смены направлений. Смена вокзала, аэропорта, смена вида транспорта. Санкт-Петербург, Москва являются транзитными городами, поскольку здесь есть необходимость в подвязках между видами транспорта.
  4. Туристический интерес.

Все эти пункты могут пересекаться так или иначе, но на этих «столпах» формируется потребность в массовых перевозках. Не все 100 тысяч населения будут пользоваться общественным транспортом, имея автомобили и другие средства мобильности, или не имея потребности в транспорте вовсе.

И самое главное — мы должны определить потребность в транспорте не столько в средстве для извлечения прибыли, сколько для обеспечения потребности населения в транспорте. Сам по себе пассажирский транспорт вероятно будет убыточным, потому что есть факторы, такие как неизбежное старение, износ и подчиненность закону жизненного цикла изделия. Затраты на разработку, сертификацию, ремонт, меры по обеспечению безопасности технической, безопасности пассажиров, они могут превышать эксплуатационные затраты и не покрываться выручкой за один статический учётный период. Даже во время поездки любой поезд обслуживается как минимум одной (чаще несколькими) локомотивной бригадой, диспетчерами разных назначений, дежурными по станциям, путейцами, которые ремонтируют пути.

Потребность это патрон, и вокруг неё мы должны строить любую систему. Нет потребности — нет системы.

Продолжение следует…