Рубрика: Reference materials

19.02.2022 Reference materials, Разработка

Установка NFS на Ubuntu Server 20.04 и подключение клиентов

Справочный материал о настройке NFS на сервере и подключении к нему виртуальных машин KVM.

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

На хосте устанавливается сервер NFS.

Настраиваем брандмауэр, чтобы открыть порт NFS-сервера 2049 для клиентов из виртуальной сети 192.168.122.0/24:

sudo ufw allow from 192.168.122.0./24 to any port nfs

Устанавливаем пакет NFS:

sudo apt update 
sudo apt install nfs-kernel-server

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

mkdir /home/pacs/dicomarchive

Для безопасности NFS преобразует любые операции root на клиенте в операции с учетными данными nobody:nogroup. В связи с этим, нам необходимо изменить владельца каталога для соответствия этим учетным данным.

sudo chown nobody:nogroup /home/pacs/dicomarchive

Открываем и редактируем файл /etc/exports:

sudo mcedit /etc/exports

Файл содержит комментарии, показывающие общую структуру каждой строки конфигурации. Синтаксис выглядит следующим образом:
directory_to_share client(share_option1,...,share_optionN)
Добавляем в него строчку:

/home/pacs/dicomarchive 192.168.122.0/24(rw,sync,no_root_squash,no_subtree_check)

Здесь /home/pacsadmin/dicomarchive - каталог, который мы "шарим" для всех виртуальных машин из сети 192.168.122.0/24 с такими опциями:
rw: эта опция дает клиенту доступ к чтению и записи на соответствующем томе. sync: эта опция принудительно заставляет NFS записывать изменения на диске, прежде чем отправлять ответ. В результате мы получаем более стабильную и согласованную среду, поскольку в ответе отражается фактическое состояние удаленного тома. Однако при этом снижается скорость операций с файлами. no_subtree_check: данная опция предотвращает проверку вложенного дерева, когда хост проверяет фактическую доступность файла в экспортированном дереве при каждом запросе. Это может вызвать много проблем в случае переименования файла, когда он открыт на клиентской системе. Проверку вложенного дерева в большинстве случаев лучше отключить. no_root_squash: по умолчанию NFS преобразует запросы удаленного пользователя root в запросы пользователя без привилегий на сервере. Это предназначено для обеспечения безопасности, чтобы пользователь root клиентской системы не мог использовать файловую систему хоста с правами root. Опция no_root_squash отключает такое поведение для определенных общих ресурсов.
После сохранения изменений закрываем файл и перезапускаем сервер:

sudo systemctl restart nfs-kernel-server

На клиентских машинах устанавливаем клиентский пакет NFS:

sudo apt install nfs-common

Создаем каталог для монтирования общего сетевого ресурса:

mkdir -p /home/dicom/archive

Монтируем:

sudo mount 192.168.122.1:/home/pacs/dicomarchive /home/dicom/archive

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

df -h

Для того, чтобы сетевой диск монтировался автоматически при запуске виртуальной машины, создаем на ней два файла (имена файлов = название каталога в который монтируется NFS-шара, где вместо слеша — дефис) с таким содержимым.

sudo mcedit /etc/systemd/system/home-dicom-archive.mount
[Unit] 
Description=NFS 
Requires=network-online.target 
After=network-online.service
 [Mount] 
Where=/home/dicom/archive 
What=192.168.122.1:/home/pacs/dicomarchive 
Type=nfs 
[Install] 
WantedBy=remote-fs.target
sudo mcedit /etc/systemd/system/home-dicom-archive.automount
[Unit] 
Description=NFS 
Requires=network-online.target 
After=network-online.service 
[Automount] 
Where=/home/dicom/archive 
[Install] 
WantedBy=remote-fs.target

Сохраняем файлы. Включаем автозапуск:

sudo systemctl daemon-reload 
sudo systemctl enable home-dicom-archive.automount 
sudo systemctl enable home-dicom-archive.mount

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

 

19.02.2022 Reference materials, Разработка

Установка сервера OpenVPN на Ubuntu Server 20.04 и подключение клиентов на Windows

Справочный материал по установке сервера OpenVPN на операционную систему Ubuntu Server 20.04
Настройка сети и брандмауэра
Здесь и далее предполагается, что на сервере установлен пакет коммандера mc с редактором mcedit.
 В первую очередь разрешим нашему серверу пересылку пакетов на уровне ядра:
sudo mcedit /etc/sysctl.conf

Находим и раскоментируем следующий параметр:

  net.ipv4.ip_forward=1

Снимок экрана 2022 02 19 16 52 25

Сохраняем изменения, закрываем редактор. Затем применяем сделанные изменения:

sudo sysctl -p

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

Перед тем, как мы перейдём к добавлению правил брандмауэра, необходимо указать политику по умолчанию, если это не было сделано ранее. Какие действия будут применяться к пакетам, если они не подпадают под созданные правила ufw. Все входящие пакеты будем отклонять:

sudo ufw default deny incoming

А все исходящие разрешим:

sudo ufw default allow outgoing

Разрешаем подключения к нашему серверу по протоколу SSH:

sudo ufw allow 22

или

sudo ufw allow OpenSSH

Далее разрешим входящие соединения на порт OpenVPN, в нашей конфигурации это будет стандартный порт 1194 и протокол udp:

sudo ufw allow 1194/udp

В параметрах UFW разрешим пересылку пакетов по умолчанию

sudo mcedit /etc/default/ufw

Заменим строчку DEFAULT_FORWAD_POLICY="DROP" на DEFAULT_FORWAD_POLICY="ACCEPT"

Добавим правила маскарадинга в таблицу NAT, чтобы клиенты могли выходит в интернет используя наш сервер как шлюз по умолчанию:

sudo mcedit /etc/ufw/before.rules

Добавим после последнего знака «#» таблицу nat и правила к нашей openvpn сети (имеющиеся правила НЕ УДАЛЯТЬ), вместо eth0 нужно подставить название вашей сетевой карты. узнать можно выполнив команду ip route | grep default

*nat

:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -s 10.188.0.0/24 -o enp0s3 -j MASQUERADE

COMMIT

Здесь 10.188.0.0/24 - адреса сети OpenVPN, которые мы зададим позже в файле конфигурации сервера, а enp0s3 - сетевой интерфейс нашего сервера, через который он общается с внешним миром.

Сохраняем и закрываем файл.

Запустим наш брандмауэр (возможно потребуется подтверждение запуска, нажать «y»):

sudo ufw enable

Настройка центра сертификации EasyRSA

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

sudo apt install openvpn easy-rsasudo mkdir /etc/openvpn/easy-rsasudo cp -R /usr/share/easy-rsa /etc/openvpn/

cd /etc/openvpn/easy-rsa/

Создадим файл с настройками переменных:

sudo cp vars.example vars

Раскоментируем значения переменных, при желании их можно изменить, но нельзя оставлять незаполненными:

sudo mcedit vars

Начнем с опции EASYRSA_DN, она предусматривает два режима: упрощенный cn_only, при котором сертификат содержит только CN (имя того, кому выдан сертификат) и традиционный org, при котором заполняются все реквизиты организации. Для OpenVPN можно использовать любой режим. Мы установим традиционный:

set_var EASYRSA_DN "org"

Удалите знак «#» у следующих ключей и измените значения на свои:

set_var EASYRSA_REQ_COUNTRY «UA»

set_var EASYRSA_REQ_PROVINCE «Kharkov Region»

set_var EASYRSA_REQ_CITY «Kharkov»

set_var EASYRSA_REQ_ORG «Copyleft Certificate Co»

set_var EASYRSA_REQ_EMAIL «admin@example.net»

set_var EASYRSA_REQ_OU «My Organizational Unit

Заметьте, что если вы оставили cn_only, то редактировать вышеуказанные опции не имеет смысла.

Параметр EASYRSA_KEY_SIZE указывает размер ключа, на сегодняшний день безопасным считается размер начиная с 2048, если вы ставите на первое место безопасность, то можете увеличить его до 3072 или 4096. Если криптографическая стойкость не играет роли, например, туннель будет использован для доступа в интернет и предполагается использование слабых устройств, то можно уменьшить размер ключа до 1024.

Опции EASYRSA_CA_EXPIRE и EASYRSA_CERT_EXPIRE задают срок действия корневого сертификата CA и сертификатов пользователей (сервера и клиентов), их значения установлены в днях как 3650 (10 лет) и 1080 (5 лет), опция EASYRSA_CERT_RENEW задает количество дней до истечения сертификата, когда становится доступным его продление, по умолчанию это 30 дней. При необходимости вы можете изменить эти значения.

Сохраните и закройте файл.

Инициализируем центр сертификации:

sudo ./easyrsa init-pki

sudo ./easyrsa build-ca nopass

sudo ./easyrsa gen-dh

sudo openvpn --genkey --secret /etc/openvpn/easy-rsa/pki/ta.key

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

sudo ./easyrsa gen-crl

Будет создан файл ./pki/crl.pem

Настройка серверной части OpenVPN
Для создания сертификатов, которые будут использоваться сервером надо выполнить команду:sudo ./easyrsa build-server-full server nopassСкопируем сертификаты сервера и центра сертификации и ключи в каталог нашего OpenVPN сервера:

sudo cp ./pki/ca.crt /etc/openvpn/ca.crt
sudo cp ./pki/dh.pem /etc/openvpn/dh.pem
sudo cp ./pki/crl.pem /etc/openvpn/crl.pem
sudo cp ./pki/ta.key /etc/openvpn/ta.key
sudo cp ./pki/issued/server.crt /etc/openvpn/server.crt
sudo cp ./pki/private/server.key /etc/openvpn/server.key

Создадим конфигурационный файл нашего OpenVPN сервера:

sudo zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | sudo tee /etc/openvpn/server.conf

Редактируем файл конфигурации:

sudo mcedit /etc/openvpn/server.conf

Здесь правим такие опции, указывая полный путь к сертификатам и ключам:

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret
dh /etc/openvpn/dh.pem

tls-auth /etc/openvpn/ta.key 0 # This file is secret

Задаём диапазон адресов для сети:

server 10.188.0.0 255.255.255.0

Убираем комментирование (точка с запятой) со строк и правим их при необходимости изменить пути:

topology subnet

client-to-client

client-config-dir /etc/openvpn/ccd

log /var/log/openvpn/openvpn.log

Если у на сервере присутствуют виртуальные машины, которые используют свою виртуальную сеть, например с адресами 192.168.122.0/24, то можно дать к ним доступ для клиентов ВПН-сети, прописав в конфигурации строку

push "route 192.168.122.0 255.255.255.0"

На этом настройки конфигурации закончены и можно запустить сервис OpenVPN:

sudo systemctl start  openvpn@server

Проверяем, что сервер запустился. Смотрим список сетевых интерфейсов:

ip a

В списке должен появиться интерфейс tun0 с адресом сервера 10.188.0.1:

Если что-то пошло не так, то смотрим лог /var/log/openvpn/openvpn.log или статус сервиса. Например, в случае, показанном ниже, сервер не запустился из-за отсутствия каталога /etc/openvpn/ccd, который был указан в конфигурации сервера, как каталог клиентских конфигураций:

sudo systemctl status openvpn@server

 

Снимок экрана 2022 02 19 18 24 07

Снимок экрана 2022 02 19 18 25 03

После устранения этого недостатка всё пошло:

Снимок экрана 2022 02 19 18 25 22
Снимок экрана 2022 02 19 18 25 45 

Снимок экрана 2022 02 19 18 26 03

Создание сертификатов клиентов

Нужно перейти в каталог /etc/openvpn/easy-rsa/

 cd /etc/openvpn/easy-rsa/

И выполнить команду:

sudo ./easyrsa build-client-full client_name nopass

Здесь client_name - имя сертификата и ключа клиента.

Если необходимо, чтобы клиент с именем client_name получал всегда статический адрес, например, 10.188.0.10, то в каталоге /etc/openvpn/ccd нужно создать файл с таким именем

sudo mcedit /etc/openvpn/ccd/client_name

В нем нужно прописать такую строку:

ifconfig-push 10.188.0.10 255.255.255.0

Это будет верно в случае, если ранее в конфигурационном файле сервера была раскомментирована строка topology subnet. Иначе вид строки должен быть таким:

ifconfig-push 10.188.0.10 10.188.0.9,

а диапазон присваиваемых адресов будет ограничен определенными сочетаниями пар адресов.

Для создания этой статьи использовались следующие материалы, спасибо их авторам:

https://komyounity.com/openvpn-ubuntu/

https://losst.ru/nastrojka-openvpn-v-ubuntu

https://losst.ru/nastrojka-ufw-ubuntu

 

 

 

 

 

02.11.2021 Reference materials, Разработка

Типы данных в DICOM

Представление значения (VR) элемента данных описывает тип данных и формат значений этого элемента данных. PS3.6 перечисляет VR каждого элемента данных по тегу элемента данных.

Значения с VR, состоящими из строк символов, за исключением случая пользовательского интерфейса VR, должны быть дополнены символами ПРОБЕЛА (20H, в наборе символов по умолчанию), когда это необходимо для достижения четной длины. Значения с VR пользовательского интерфейса должны быть дополнены одним конечным символом NULL (00H), когда это необходимо для достижения четной длины. Значения с VR, равным OB, должны быть дополнены одним конечным значением NULL-байта (00H), когда это необходимо для достижения четной длины.

Все новые VR, определенные в будущих версиях DICOM, должны иметь ту же структуру элементов данных, как определено в разделе 7.1.2, с зарезервированными байтами после VR и 32-битным целым числом без знака (т. е. в соответствии с форматом для VR, например OB или UT), и может разрешать или не разрешать неопределенную длину.

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

Тип Описание Набор символов Длина
AE

Application Entity

 Строка символов, идентифицирующая объект приложения, причем начальные и конечные пробелы (20H) не имеют значения. Значение, состоящее исключительно из пробелов, не должно использоваться. Набор символов по умолчанию, за исключением кода символа 5CH (обратная косая черта «\» в ISO-IR 6) и всех управляющих символов. максимум 16 байт
AS

Age String

 Строка символов одного из следующих форматов — nnnD, nnnW, nnnM, nnnY;  где nnn должно содержать количество дней для D, недель для W, месяцев для M или лет для Y.

Пример: «018M» будет обозначать возраст 18 месяцев.

 "0"-"9", "D", "W", "M", "Y"

 

 4 байта фиксировано
CS

Code String

 Строка символов, идентифицирующая контролируемую концепцию.  Ведущие или конечные пробелы (20H) не имеют значения.

В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов кавычек, представляющая пустое значение ключа.

 Символы верхнего регистра, «0»–«9», символ ПРОБЕЛ и подчеркивание «_» из набора символов по умолчанию.

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 максимум 16 байт

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
DA

Date

 Строка символов формата ГГГГММДД;  где ГГГГ содержит год, ММ содержит месяц, а ДД содержит день, интерпретируемый как дата григорианской календарной системы.
Пример:
«19930822» будет означать 22 августа 1993 года.ПримечаниеСтандарт ACR-NEMA 300 (предшественник DICOM) поддерживал строку символов формата ГГГГ.ММ.ДД для этого VR.  Использование этого формата не соответствует требованиям.
См. также DT VR в этой таблице.
Даты до 1582 года, например, используемые для датирования исторических или археологических предметов, интерпретируются как предварительные даты по григорианскому календарю, если не указано иное.В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧЕК, представляющая пустое значение ключа.		 «0»–«9» из репертуара персонажей по умолчанию.

В контексте запроса с сопоставлением диапазона (см. PS3.4) допускается использование символа «-», а для заполнения допускается завершающий символ ПРОБЕЛ.

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ..

 8 байт фиксировано

В контексте запроса с сопоставлением диапазона (см. PS3.4) длина составляет максимум 18 байт.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
DS

Decimal String

 Строка символов, представляющая либо число с фиксированной запятой, либо число с плавающей запятой.  Номер с фиксированной точкой должен содержать только символы 0–9 с необязательным начальным «+» или «-» и необязательным «.»  для обозначения десятичной точки.  Число с плавающей запятой должно передаваться, как определено в ANSI X3.9, с буквой «E» или «e», обозначающей начало показателя степени.  Десятичные строки могут быть дополнены пробелами в начале или в конце.  Встроенные пробелы не допускаются.

Примечание
Элементы данных с несколькими значениями, использующие этот VR, могут быть неправильно закодированы, если используется синтаксис передачи Explicit-VR и VL этого элемента данных превышает 65534 байта.
 "0"-"9", "+", "-", "Е", "е", "."  и символ ПРОБЕЛ из набора символов по умолчанию.

 

 максимум 16 байт

 
DT

Date Time

 Объединенная строка символов даты и времени в формате:

YYYYMMDDHHMMSS.FFFFFF&ZZXX

Компоненты этой строки (слева направо): ГГГГ = год, ММ = месяц, ДД = день, ЧЧ = час (диапазон «00» – «23»), ММ = минуты (диапазон «00» – «59»). ), СС = Секунда (диапазон «00» – «60»).

FFFFFF = Дробная секунда содержит дробную часть секунды размером до 1 миллионной секунды (диапазон «000000» — «999999»).

&ZZXX — необязательный суффикс для смещения от всемирного координированного времени (UTC), где & = «+» или «-», а ZZ = часы и XX = минуты смещения.

Год, месяц и день интерпретируются как дата системы григорианского календаря.

Используется 24-часовой формат времени.  Полночь должна обозначаться только цифрой «0000», поскольку «2400» нарушает часовой диапазон.

Компонент дробной секунды, если он присутствует, должен содержать от 1 до 6 цифр.  Если дробная секунда не указана, предыдущий "."  не должны быть включены.  Суффикс смещения, если он присутствует, должен содержать 4 цифры.  Строка может быть дополнена завершающими символами ПРОБЕЛ.  Ведущие и встроенные пробелы не допускаются.

Компонент, который опущен в строке, называется нулевым компонентом.  Завершающие нулевые компоненты Date Time указывают на то, что значение не соответствует точности этих компонентов.  Компонент YYYY не должен быть нулевым.  Неконечные нулевые компоненты запрещены.  Необязательный суффикс не считается компонентом.

Значение даты и времени без необязательного суффикса интерпретируется как находящееся в местном часовом поясе приложения, создающего элемент данных, если явно не указано в параметре «Смещение часового пояса от UTC» (0008,0201).

Смещения UTC рассчитываются как «местное время минус UTC».  Смещение значения даты и времени в формате UTC должно быть +0000.

В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧОК, представляющая пустое значение ключа.

Примечание

Диапазон смещения составляет от -1200 до +1400.  Смещение восточного стандартного времени США составляет -0500.  Смещение стандартного времени Японии составляет +0900.
Использование -0000 в качестве смещения для указания местного времени в RFC 2822 не допускается.
Значение даты и времени 195308 означает август 1953 года, а не конкретный день.  Значение даты и времени 19530827111300,0 означает 27 августа 1953 года, 11:13 утра с точностью до 1/10 секунды.
Второй компонент может иметь значение 60 только для дополнительной секунды.
Смещение может быть включено независимо от нулевых компонентов;  например, 2007-0500 является допустимым значением.

 "0"-"9", "+", "-", "." и символ ПРОБЕЛ из набора символов по умолчанию.

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 максимум 26 байт

В контексте запроса с сопоставлением диапазона (см. PS3.4) длина составляет максимум 54 байта.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
IS

Integer String

 Строка символов, представляющая целое число по основанию 10 (десятичное), должна содержать только символы 0–9 с необязательным начальным знаком «+» или «-».  Оно может быть дополнено начальными и/или конечными пробелами.  Встроенные пробелы не допускаются.

Представленное целое число n должно находиться в диапазоне:

-231<= n <= (231-1).

 «0»-»9», «+», «-» и символ ПРОБЕЛ из набора символов по умолчанию. максимум 12 байт
LO

Long String

 Строка символов, которая может быть дополнена начальными и/или конечными пробелами.  Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями в многозначных элементах данных.  В строке не должно быть управляющих символов, за исключением ESC. Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022]. Максимум 64 символа (см. примечание в разделе 6.2)
LT

Long Text

 Строка символов, которая может содержать один или несколько абзацев.  Он может содержать набор графических символов и управляющие символы, CR, LF, FF и ESC.  Он может быть дополнен конечными пробелами, которые можно игнорировать, но ведущие пробелы считаются значимыми.  Элементы данных с этим VR не должны быть многозначными, поэтому можно использовать код символа 5CH (обратная косая черта "\" в ISO-IR 6). Набор символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]). Максимум 10240 символов (см. примечание в разделе 6.2).
PN

Person Name

 Строка символов, закодированная с использованием пятикомпонентного соглашения.  Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями в многозначных элементах данных.  Строка может быть дополнена конечными пробелами.  Для использования человеком пять компонентов в порядке их появления: фамилия, имя, отчество, префикс имени, суффикс имени.

Примечание
HL7 запрещает ведущие пробелы внутри компонента;  DICOM допускает начальные и конечные пробелы и считает их незначительными.

Любой из пяти компонентов может быть пустой строкой.  Разделителем компонентов должен быть символ «^» (5EH).  Разделителей компонентов должно быть не более четырех, т. е. их не должно быть после последнего компонента, если присутствуют все компоненты.  Разделители необходимы для внутренних нулевых компонентов.  Завершающие нулевые компоненты и их разделители могут быть опущены.  В каждом компоненте разрешено несколько записей, которые кодируются как естественные текстовые строки в формате, предпочитаемом указанным лицом.

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

Эта группа из пяти компонентов называется группой компонентов «Имя человека».

Для написания названий идеографическими и фонетическими знаками допускается использовать до 3 групп компонентов (см. Приложение H, Приложение I и Приложение J).  Разделителем групп компонентов должен быть символ равенства "=" (3DH).  Разделителей групп компонентов должно быть не более двух, т. е. их не должно быть после последней группы компонентов, если присутствуют все группы компонентов.  Три группы компонентов в порядке их появления: алфавитное представление, идеографическое представление и фонетическое представление.

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

Точная семантика определена для каждой группы компонентов.  См. раздел 6.2.1.2.

Примеры и примечания см. в разделе 6.2.1.1.

 Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022].

 

 Максимум 64 символа на группу компонентов

 
SH

Short String

 Строка символов, которая может быть дополнена начальными и/или конечными пробелами.  Код символа 05CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями для многозначных элементов данных.  В строке не должно быть управляющих символов, кроме ESC. Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022]. максимум 16 символов
SQ

Sequence of Items

 Значение — это последовательность из нуля или более элементов, как определено в разделе 7.5. not applicable (see Section 7.5) not applicable (see Section 7.5)
ST

Short Text

 Строка символов, которая может содержать один или несколько абзацев.  Он может содержать набор графических символов и управляющие символы, CR, LF, FF и ESC.  Он может быть дополнен конечными пробелами, которые можно игнорировать, но ведущие пробелы считаются значимыми.  Элементы данных с этим VR не должны быть многозначными, поэтому можно использовать код символа 5CH (обратная косая черта "\" в ISO-IR 6). Набор символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]). максимум 1024 символа

 
TM

Time

 Строка символов формата HHMMSS.FFFFFF;  где HH содержит часы (диапазон «00» — «23»), MM содержит минуты (диапазон «00» — «59»), SS содержит секунды (диапазон «00» — «60»), а FFFFFF содержит дробную часть секунда, равная 1 миллионной секунды (диапазон «000000» — «999999»).  Используется 24-часовой формат времени.  Полночь должна обозначаться только цифрой «0000», поскольку «2400» нарушает часовой диапазон.  Строка может быть дополнена конечными пробелами.  Ведущие и встроенные пробелы не допускаются.

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

Компонент FFFFFF, если он присутствует, должен содержать от 1 до 6 цифр.  Если FFFFFF не указано, предыдущий "."  не должны быть включены.

Примеры:

«070907.0705» представляет собой время 7 часов 9 минут 7,0705 секунды.
«1010» представляет собой время 10 часов 10 минут.
«021» — недопустимое значение.Примечание
Стандарт ACR-NEMA 300 (предшественник DICOM) поддерживал строку символов формата HH:MM:SS.frac для этого VR.  Использование этого формата не соответствует требованиям.
См. также DT VR в этой таблице.
Компонент SS может иметь значение 60 только для дополнительной секунды.
В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧЕК, представляющая пустое значение ключа.

 "0–9, «.» и символ ПРОБЕЛ из набора символов по умолчанию.

В контексте запроса с сопоставлением диапазона (см. PS3.4) допускается использование символа «-».

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 максимум 14 байт

В контексте запроса с сопоставлением диапазона (см. PS3.4) длина составляет максимум 28 байт.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
UC

Unlimited Characters

 Строка символов, которая может иметь неограниченную длину и может быть дополнена конечными пробелами.  Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями в многозначных элементах данных.  В строке не должно быть управляющих символов, за исключением ESC. Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022]. 232-2 bytes maximum

 
UI

Unique Identifier (UID)

 Строка символов, содержащая UID, который используется для уникальной идентификации широкого спектра элементов.  UID представляет собой серию числовых компонентов, разделенных точкой "."  . Если поле значения, содержащее один или несколько UID, имеет длину нечетного числа байтов, поле значения должно быть дополнено одним конечным нулевым символом (00H), чтобы гарантировать, что поле значения имеет длину четное количество байтов.  Полную спецификацию и примеры см. в разделе 9 и приложении B. "0"-"9", "."  набора символов по умолчанию максимум 64 байта

 
UR

Universal Resource Identifier or Universal Resource Locator (URI/URL)

 Строка символов, идентифицирующая URI или URL-адрес, как определено в [RFC3986].  Ведущие пробелы не допускаются.  Конечные пробелы игнорируются.  Элементы данных с этим VR не должны быть многозначными.

В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧОК, представляющая пустое значение ключа.

Примечание
Допускаются как абсолютные, так и относительные URI.  Если URI является относительным, то он относится к базовому URI объекта, в котором он содержится, или к базовому URI в другом атрибуте, как указано в определении информационного объекта.
 Подмножество набора символов по умолчанию, необходимое для URI, как определено в разделе 2 IETF RFC3986, плюс символ пробела (20H), разрешенный только в качестве завершающего дополнения.

Примечание
Символ обратной косой черты (5CH) входит в число запрещенных в URI.
В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 232-2 bytes maximum.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
UT

Unlimited Text

 Строка символов, которая может содержать один или несколько абзацев.  Он может содержать набор графических символов и управляющие символы, CR, LF, FF и ESC.  Он может быть дополнен конечными пробелами, которые можно игнорировать, но ведущие пробелы считаются значимыми.  Элементы данных с этим VR не должны быть многозначными, поэтому можно использовать код символа 5CH (обратная косая черта "\" в ISO-IR 6). Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]). 232-2 bytes maximum

See Note 2

Набор данных dicom-файла (Data Set) представляет собой экземпляр информационного объекта реального мира. Набор данных состоит из элементов данных. Элементы данных содержат закодированные значения атрибутов этого объекта. Конкретное содержание и семантика этих атрибутов указаны в определениях информационных объектов (см. PS3.3).

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

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

Определены два типа элементов данных:

Стандартные элементы данных имеют четный номер группы, который не равен (0000, eeee), (0002, eeee), (0004, eeee) или (0006, eeee).

Элементы личных данных имеют нечетный номер группы, который не равен (0001, eeee), (0003, eeee), (0005, eeee), (0007, eeee) или (FFFF, eeee).

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

Неявные и явные элементы данных VR не должны сосуществовать в наборе данных и вложенных в него наборах данных (см. Раздел 7.5). Использует ли набор данных явный или неявный VR, помимо прочих характеристик, определяется согласованным синтаксисом передачи (см. Раздел 10 и Приложение А). VR не содержатся в элементах данных, когда используется синтаксис передачи по умолчанию DICOM (неявный синтаксис передачи с прямым порядком байтов DICOM).

Уникальные идентификаторы (UID) предоставляют возможность уникальной идентификации широкого спектра элементов. Они гарантируют уникальность в нескольких
страны, сайты, продавцы и оборудование. Различные классы объектов, экземпляры объектов и информационные объекты можно отличить друг от друга в рамках дискурса DICOM независимо от любого семантического контекста.

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

Схема идентификации UID основана на Идентификации объекта OSI (числовая форма) в соответствии со стандартом [ISO / IEC 8824]. Все уникальные идентификаторы, используемые в контексте стандарта DICOM, являются зарегистрированными значениями, как определено в [ISO / МЭК 9834-1] для обеспечения глобальной уникальности. Использование таких UID определено в различных частях стандарта DICOM.

Каждый UID состоит из двух частей: <org root> и <suffix>
Часть <org root> UID однозначно идентифицирует организацию (т.е. производителя, исследовательскую организацию, NEMA и т. д.) и состоит из ряда числовых компонентов, как определено в [ИСО / МЭК 8824]. Часть <суффикса> UID также состоит из ряда числовых компонентов и должна быть уникальной в рамках <корневого каталога org>. Это означает, что организация, указанная в <org root>, несет ответственность за гарантию уникальности <суффикса> путем предоставления политик регистрации. Эти политики должны гарантировать уникальность <суффикса> для всех идентификаторов UID, созданных этой организацией. В отличие от <org root>, который может быть общим для UID в организации, <суффикс> должен принимать разные уникальные значения между разными UID, которые идентифицируют разные объекты.

Правила кодирования DICOM UID определены следующим образом:
Каждый компонент UID является номером и должен состоять из одной или нескольких цифр. Первая цифра каждого компонента не должна быть нулевой, если компонент не является одной цифрой.
Регистрирующие органы могут распространять компоненты с незначительными начальными нулями. При кодировании начальные нули должны игнорироваться (то есть «00029» будет кодироваться как «29»).
Каждое числовое значение компонента должно быть закодировано с использованием символов 0-9 Базового набора G0 Международной справочной версии ISO 646: 1990 (набор символов DICOM по умолчанию).
Компоненты должны быть разделены знаком "." (2EH).
Если заканчивается на нечетной границе байта, за исключением случаев, когда используется для согласования сети (см. PS3.8), один завершающий NULL (00H), как символ заполнения, должен следовать за последним компонентом, чтобы выровнять UID по четной границе байта,
UID не должен превышать 64 символов.
"1.2.840.xxxxx.3.152.235.2.12.187636473"
\___________/ \______________________/
root                  .            Suffix

В этом примере корень:
1 идентифицирует ISO
2 идентифицирует тело члена ANSI
840 код страны конкретного органа-члена (США для ANSI)
xxxxx Идентифицирует конкретную организацию. (Назначается ANSI)

В этом примере первые два компонента суффикса относятся к идентификации устройства:
3 определенный производителем тип устройства
152 Серийный номер, определенный производителем
Остальные четыре компонента суффикса относятся к идентификации изображения:
235 номер исследования
2 номер серии
12 номер изображения
187636473 Кодированная дата и время получения изображения

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

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

Примечание
1. Например, в США ANSI назначает за плату идентификаторы организации для любой запрашивающей организации. Такой идентификатор может использоваться идентифицированной организацией в качестве корня, к которому он может добавить суффикс, состоящий из одного или нескольких компонентов. Указанная организация принимает на себя ответственность за правильную регистрацию этих суффиксов для обеспечения уникальности
2. Ниже приведены два типичных примера получения UID <org root>. Эти примеры не предназначены для иллюстрации всех возможных методов получения UID <org root>, см. [ИСО / МЭК 8824] и [ИСО / МЭК 9834-1] для получения полной спецификации.
Идентификаторы организации можно получить в различных органах-членах ISO (например, IBN в Бельгии, ANSI в США, AFNOR во Франции, BSI в Великобритании, DIN в Германии, COSIRA в Канаде). В первом примере показан случай <org root>, выданный органом-членом ISO (в данном примере ANSI в США).
<Org root> состоит из идентификатора ISO, идентификатора ветви тела участника, кода страны и идентификатора организации. Обратите внимание, что не требуется, чтобы реализация, использующая выданный ANSI <org root>, была сделана или находилась в США.
<Org root> состоит из следующих компонентов: 1.2.840.xxxxx
1 обозначает ISO
2 обозначает ветвь тела члена ISO
840 идентифицирует код страны конкретного органа-члена ISO (США для ANSI)
xxxxx идентифицирует конкретную организацию, зарегистрированную органом-членом ISO ANSI.
Во втором примере показан случай <org root>, выданный ISO (делегирован BSI) международной организации.
Он состоит из идентификатора ISO, идентификатора ветви международной организации и международного обозначения кода. Значение <org root> назначается международным органом регистрации, который может использоваться многими различными UID, определенными одной и той же международной организацией. <Org root> состоит из следующих компонентов:
1.3.yyyy

1 обозначает ISO
3 обозначает филиал международной организации
yyyy идентифицирует конкретную организацию, зарегистрированную международным регистрационным органом по обозначению кода (см.ISO 6523).
Примерные компоненты <суффикса> для уникальной идентификации изображения могут включать:
системный идентификатор
исследование, серия и номера изображений
изучение, серия и изображение даты и времени.

ISO 3166-1:

Украина — 804
Россия — 643
Великобритания — 826
Набор символов по умолчанию для символьных строк в DICOM - это базовый набор G0 международной справочной версии ISO 646: 1990 (ISO IR-6). Кроме того, поддерживаются управляющие символы LF, FF, CR, TAB и ESC. Эти управляющие символы являются подмножеством набора C0, определенного в ISO 646: 1990 и ISO 6429: 1990.
Байтовая кодировка набора символов по умолчанию показана в таблице E-1. Эта таблица может использоваться для получения как байтовых значений столбца / строки ISO, так и шестнадцатеричных значений для закодированных представлений

J.5 Представление значения имени человека на других языках с использованием Unicode

Имена людей на многих языках могут быть написаны локальным (не латинским) шрифтом, а также транслитерацией к латинскому шрифту (романизация). Информационные системы здравоохранения в этих средах могут поддерживать один или оба формата имен. Локальные сценарии могут быть закодированы с использованием Unicode в UTF-8.
Для целей обмена в DICOM существует три типичных использования групп компонентов имен, использующих Unicode в UTF-8:
1. Имена в латинском алфавите могут быть закодированы в первой (алфавитной) группе компонентов, а имена в локальном шрифте (алфавит, абугида или слоговый) в третьей (фонетической) группе компонентов (см. Таблицу 6.2-1). Вторая (идеографическая) группа компонентов является нулевой. Это предпочтительное использование для межфирменного или международного общения.
2. Если локальный сценарий исторически имеет однобайтовый набор символов, определенный для конкретного набора символов (0008 0005), т. Е. Кириллицы, арабского, греческого, иврита, тайского и различных версий латиницы, может использоваться только группа компонентов первого имени использоваться. Кодирование может быть в Unicode в UTF-8, как описано в этом Приложении, в качестве эквивалента для использования этого определенного однобайтового набора символов в группе компонентов первого имени (см. Примечание 1).
3. Имена в локальном скрипте могут быть закодированы в первой группе компонентов, а имена в латинском алфавите в третьей группе компонентов, оба кодируются в Unicode в UTF-8.
Примечание
1. Предыдущее издание DICOM требовало, чтобы группа компонентов имени использовала однобайтовый набор символов (см. PS3.5-2008). Юникод в UTF-8 теперь может использоваться в этой группе компонентов просто как кодировка другого набора символов, но с тем же самым прикладным использованием этой группы компонентов.
2. Информационные системы здравоохранения будут использовать конкретные сценарии в одной, двух или трех группах компонентов «Личное имя» в соответствии с местной политикой. Соответствующие прикладные программы DICOM, которые получают атрибуты имени, должны принимать несколько групп компонентов имени. Прикладная сущность, которая настраивается таким образом, чтобы разрешить использование локального сценария для имен в первой или третьей группе компонентов и сценария транслитерации в другой, будет поддерживать все эти типичные представления.
3. Транслитерация (из местного алфавита) может быть нелатинским шрифтом, например кириллицей. Применяются те же принципы, и имя с кириллицей может быть закодировано в первой группе компонентов, а локальный скрипт (который на самом деле может быть производным от латиницы) в третьей группе компонентов.

02.11.2021 Reference materials, Разработка

Проброс портов в виртуальную машину KVM. Назначение статического адреса в dhcp NAT KVM.

Часто приходится устанавливать виртуализацию на основе KVM на серверах и создавать правила для проброса портов в виртуальные машины, которые работают за NAT в виртуальной сети.

Честно говоря, впервые столкнувшись, не сразу понял, как это можно сделать. Решение нашёл здесь: https://bozza.ru/art-268.html. Спасибо  автору. Здесь выкладываю скрипт для справки себе в том виде, в котором я адаптировал его под свои нужды. Ну и может быть ещё кому-нибудь пригодится.

Смысл идеи состоит в том, чтобы включить правила переадресации портов в скрипт, который помещается в каталоге /etc/libvirt/hooks. Скрипты из этого каталога выполняются при запуске демона libvirtd. Поэтому после сохранения скрипта здесь его нужно перезапустить. В авторском варианте порты переадресуются с заданного адреса хоста на известный адрес виртуальной машины, назначенный либо вручную, либо dhcp KVM. Это не всегда удобно, т.к. я заранее не знаю, какой адрес будет дан хосту в каждом конкретном случае. Поэтому я переадресую порты с внешнего сетевого интерфейса сервера. В данном случае - bond0.

Собственно текст скрипта:

#!/bin/bash

## Название внешнего сетевого интерфейса хоста:

Host_lan=bond0

## Виртуалка с сервером dcm4chee-arc

Guest_name=dicompacs
Guest_ipaddr=192.168.122.10
Host_port=(  '8080' '8443' '8843' '11112' '2575'  )
Guest_port=( '8080' '8443' '8843' '11112' '2575'  )

length=$(( ${#Host_port[@]} - 1 ))
if [ "${1}" = "${Guest_name}" ]; then
   if [ "${2}" = "stopped" ] || [ "${2}" = "reconnect" ]; then
      for i in 'seq 0 $length'; do
        iptables -t nat -D PREROUTING -i ${Host_lan} -p tcp --dport ${Host_port[$i]} -j DNAT --to ${Guest_ipaddr}:${Guest_port[$i]}
        iptables -D FORWARD -d ${Guest_ipaddr}/32 -p tcp -m state --state NEW -m tcp --dport ${Guest_port[$i]} -j ACCEPT
      done
   fi
   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then
     for i in 'seq 0 $length'; do
       iptables -t nat -A PREROUTING -i ${Host_lan} -p tcp --dport ${Host_port[$i]} -j DNAT --to ${Guest_ipaddr}:${Guest_port[$i]}
       iptables -I FORWARD -d ${Guest_ipaddr}/32 -p tcp -m state --state NEW -m tcp --dport ${Guest_port[$i]} -j ACCEPT
    done
  fi
fi

## Виртуалка с samba-сервером

Guest_name=smbshara
Guest_ipaddr=192.168.122.20
Host_port=(  '139' '445' )
Guest_port=( '139' '445' )

length=$(( ${#Host_port[@]} - 1 ))
if [ "${1}" = "${Guest_name}" ]; then
   if [ "${2}" = "stopped" ] || [ "${2}" = "reconnect" ]; then
     for i in `seq 0 $length`; do
        iptables -t nat -D PREROUTING -i ${Host_lan} -p tcp --dport ${Host_port[$i]} -j DNAT --to ${Guest_ipaddr}:${Guest_port[$i]}
        iptables -D FORWARD -d ${Guest_ipaddr}/32 -p tcp -m state --state NEW -m tcp --dport ${Guest_port[$i]} -j ACCEPT
     done
   fi
   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then
     for i in `seq 0 $length`; do
        iptables -t nat -A PREROUTING -i ${Host_lan} -p tcp --dport ${Host_port[$i]} -j DNAT --to ${Guest_ipaddr}:${Guest_port[$i]}
        iptables -I FORWARD -d ${Guest_ipaddr}/32 -p tcp -m state --state NEW -m tcp --dport ${Guest_port[$i]} -j ACCEPT
     done
   fi
fi

Создаем файл /etc/libvirt/hooks/qemu, обычно у меня установлен Midnight Commander, поэтому у меня есть mcedit:

sudo mcedit /etc/libvirt/hooks/qemu

Копируем в него текст скрипта и сохраняем. Делаем его исполняемым:

sudo chmod 700 /etc/libvirt/hooks/qemu

И перезапускаем libvirtd:

systemctl restart libvirtd.service

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

Чтобы обеспечить постоянство адреса виртуальной машины, можно воспользоваться утилитой редактирования сети virsh net-edit. Если виртуалки находятся в сети default, то

virsh net-edit default

Будет открыт редактор, установленный по умолчанию, в котором необходимо указать имена виртуальных машин, mac-адреса их виртуальных сетевых адаптеров и назначаемый IP-адрес:

<dhcp>
  <range start='192.168.122.100' end='192.168.122.254'/>
  <host mac='52:54:00:59:c0:86' name='xraypacs' ip='192.168.122.10'/>
  <host mac='52:54:00:00:c4:f0' name='smbshara' ip='192.168.122.20'/>
</dhcp>

Сохраняем и перезапускаем сеть.

Всё.

Александр Кузнецов, 02.11.2021

 

 

11.04.2020 Reference materials, Разработка

Установка Docker на debian 10

Краткая справка по установке Docker на сервере debian 10. Ставил для последующей установки PACS-а на dcm4chee-arc версии 5.21

Сначала ставим пакеты для обеспечения необходимых зависимостей:

sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common

Скачиваем и добавляем ключ репозитория докера:

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -

Добавляем репозиторий, обновляемся и устанавливаем собственно:

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
sudo apt update
sudo apt-cache policy docker-ce
sudo apt install docker-ce

После установки демон должен запуститься автоматически.

Проконтролировать можно, посмотрев на вывод

sudo systemctl status docker

Должно быть примерно так:

● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-04-11 22:20:04 EEST; 11min ago
     Docs: https://docs.docker.com
 Main PID: 429 (dockerd)
    Tasks: 13
   Memory: 136.1M
   CGroup: /system.slice/docker.service
           └─429 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

апр 11 22:20:01 dockerPACS dockerd[429]: time="2020-04-11T22:20:01.109948723+03:00" level=warning msg="Your kernel does not support swap memory limit"
...

Дальше качаем образы, запускаем контейнеры.

(С) Александр Кузнецов, 10.04.2020

 

 

 

 

10.04.2020 Reference materials, Разработка

Запуск веб-вьювера oviyam2 в контейнере docker

Популярный веб-просмотрщик oviyam2 (http://oviyam.raster.in/index.html , https://sourceforge.net/projects/dcm4che/files/Oviyam/) очень легко интегрируется на сервер dcm4chee версий 2.хх. А вот "подружить" его с другими dicom-серверами бывает не так просто, как с упомянутым выше.

Хорошо что есть энтузиасты, которые совершенно бесплатно предлагают решения, которые вполне по силам воплотить даже начинающим администраторам. Вот и я, воспользовавшись готовым решением, лишь слегка его поправив, легко запустил oviyam2 и подключил его к dicom-серверам.

Установка проводилась на виртуальный сервер под управлением debian 10 с установленным docker-ce.

Кратко, как установить докер - по ссылке

Для начала скачал с гитхаба Dockerfile:

wget https://raw.githubusercontent.com/leonardoforti/oviyam/master/Dockerfile

Для тех, кто пока ещё не очень хорошо знает, что такое Dockerfile: это сценарий, по которому собирается образ для запуска в контейнере. Содержание файла изначально такое:

FROM tomcat:latest -

ENV ovi_ver 2.7.3

ENV iovi_ver 2.1

RUN apt-get install unzip

WORKDIR /ovitmp

ADD https://iweb.dl.sourceforge.net/project/dcm4che/Oviyam/${ovi_ver}/Oviyam-${ovi_ver}-bin.zip oviyam.zip

ADD https://iweb.dl.sourceforge.net/project/dcm4che/Oviyam/iOviyam%20${iovi_ver}/iOviyam-${iovi_ver}-bin.zip ioviyam.zip

RUN unzip oviyam.zip && unzip ioviyam.zip &&

cp /ovitmp/Oviyam-${ovi_ver}-bin/Oviyam-${ovi_ver}-bin/oviyam2.war /usr/local/tomcat/webapps/ROOT.war &&

cp /ovitmp/Oviyam-${ovi_ver}-bin/tomcat/*.jar /usr/local/tomcat/lib &&

cp /ovitmp/iOviyam-${iovi_ver}-bin/ioviyam2.war /usr/local/tomcat/webapps/ioviyam2.war

COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml

 

Что здесь "зашифровано"? Всё просто. Берётся образ последней версии tomcat и в него скачиваются и распаковываются приложения oviyam2 версии 2.7.3 и ioviyam версии 2.1.

А также копируется файл настроек tomcat-users.xml. Его тоже нужно скачать и отредактировать под себя:

wget https://raw.githubusercontent.com/leonardoforti/oviyam/master/tomcat-users.xml

У меня установлен mc, поэтому я пользуюсь его редактором, весьма удобным

mcedit tomcat-users.xml

<?xml version='1.0' encoding='utf-8'?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="admin"/>

  <role rolename="manager-gui"/>
  <user username="tomcat" password="cattom" roles="manager-gui, manager-script, manager-status, manager-jmx"/>
  <user username="admin" password="admin" roles="admin"/>
</tomcat-users>

Что нужно сделать? Нужно изменить пароль для админа и добавить свои логины/пароли для пользователей.

Например так:

<user username="user1" password="userpassword1" roles="manager-gui"/> - добавление пользователя user1 с паролем userpassword1, который может только лишь настроить под себя интерфейс для просмотра.

Таких пользователей можно добавить столько, сколько вам нужно.

Когда всё отредактировано и сохранено, запускаем сборку образа (ВНИМАНИЕ! Точка здесь - не конец предложения :), а указание на то, что докерфайл находится в текущем каталоге):

docker build -t oviyam2_7_3 .

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

docker run -it --network=dcm4chee_default --name oviyam2 -p 8181:8080 -p 1025:1025 -v /home/dcm4chee/oviyam:/usr/local/tomcat/work -d oviyam2_7_3:latest

Здесь предполагается, что сеть dcm4chee_default у вас уже определена для докера и запущена. Кроме того должен существовать и быть доступным для записи каталог, в котором будет размещена рабочая папка контейнера (здесь /home/dcm4chee/oviyam, у вас же может быть, естественно любая своя)

В браузере вьювер будет доступен по адресу:

http://IP-сервера:8181

Порт 8181 также можно изменить на любой, который вам нравится, но, естественно, не задействованный другими программами на этом сервере. Например 8080 у меня задействован для dcm4chee, поэтому я выбрал 8181.

Далее всё как обычно, заходим под админом, добавляем в конфигурации свои серверы и пользуемся 🙂

(С) Александр Кузнецов, 10.04.2020

 

 

 

 

 

 

Scroll to top