Linux Сервер диспетчеризации LKDSServer

  • Автор темы Автор темы Andi
  • Дата начала Дата начала
Список ключей нужно сделать с вертикальной прокруткой. Не хватает 17 дюймов чтобы выбрать ключ внизу списка.
 
Последнее редактирование модератором:
revit написал(а):
Список ключей нужно сделать с вертикальной прокруткой. Не хватает 17 дюймов чтобы выбрать ключ внизу списка.

Речь идёт о модуле LKDSServerCfg ?

Для Windows или для Linux ?
 
Да, не уточнил...
LKDSServerCfg Linux
Список ключей в меню "изменить ключ в ЛБ" в поле "ключ" уходит вниз экрана, а прокрутки нет , из-за чего не могу выбрать нужный ключ.
Запускается в WSL-Debian
 
Последнее редактирование модератором:
revit написал(а):
Да, не уточнил...
LKDSServerCfg Linux
Список ключей в меню "изменить ключ в ЛБ" в поле "ключ" уходит вниз экрана, а прокрутки нет , из-за чего не могу выбрать нужный ключ.
Запускается в WSL-Debian

В WSL есть проблема с показом выпадающих списков - этот список невозможно просмотреть полностью, если он не помещается на экране, например: WSL WSList.png

В Linux этот же список показывается по другому, например: Linux LinuxList.png

Программно это исправить невозможно.

Будущее за Linux.
 

Вложения

  • WSList.png
    WSList.png
    183.2 KB · Просмотры: 0
  • LinuxList.png
    LinuxList.png
    161.8 KB · Просмотры: 0
А можно сделать возможность изменения сортировки списка чтобы можно было просматривать по возрастанию алфавита или по убыванию чтобы найти нужный ключ?

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

Андрей Ефименко написал(а):
Будущее за Linux.
очень спорно...
 
Последнее редактирование модератором:
revit написал(а):
А можно сделать возможность изменения сортировки списка чтобы можно было просматривать по возрастанию алфавита или по убыванию чтобы найти нужный ключ?

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

очень спорно...

Не знаю как через WSL, но сортировака ключей работает, ползунок тоже не вызывает нареканий.
Всё работает из под Линукс.
 
Тимофей написал(а):
Не знаю как через WSL, но сортировака ключей работает, ползунок тоже не вызывает нареканий.
Всё работает из под Линукс.

Да я уже понял что вместо WSL надо полноценную виртуальную машину запускать
 
Добрый день!
Может я не разобрался, а есть ли на LKDSServer какой-то механизм замены ЛБ? То есть если по какому-то адресу происходит замена ЛБ, я его сначала добавляю через настройку сервера, а потом в SPult, то есть замену для каждого блока нужно делать в двух местах, это не очень удобно. В LKDSPro достаточно в одном месте поменять, так как адрес ЛБ не меняется.
Заранее благодарю за ответ!
 
Семен Федоров написал(а):
Добрый день!
Может я не разобрался, а есть ли на LKDSServer какой-то механизм замены ЛБ? То есть если по какому-то адресу происходит замена ЛБ, я его сначала добавляю через настройку сервера, а потом в SPult, то есть замену для каждого блока нужно делать в двух местах, это не очень удобно. В LKDSPro достаточно в одном месте поменять, так как адрес ЛБ не меняется.
Заранее благодарю за ответ!

Странный вопрос, просто меняешь в клиенте (LPult, SPult) ID и всё.
Если между собой менять, то в первом меняешь на ID случайный, чтобы не было сопадений.
 
Семен Федоров написал(а):
Добрый день!
Может я не разобрался, а есть ли на LKDSServer какой-то механизм замены ЛБ? То есть если по какому-то адресу происходит замена ЛБ, я его сначала добавляю через настройку сервера, а потом в SPult, то есть замену для каждого блока нужно делать в двух местах, это не очень удобно. В LKDSPro достаточно в одном месте поменять, так как адрес ЛБ не меняется.
Заранее благодарю за ответ!

В LKDSPro используется понятие "индекс ЛБ", который "скрывает" ID ЛБ, этот индекс указывается в географической структуре серверов LKDSDisp и LKDSDomain. Если в настройке LKDSPro изменить ID ЛБ для конкретного индекса ЛБ, то в географической структуре менять ничего не нужно.

Вероятно, речь идет о том, что при физической замене ЛБ на объекте, в списке ЛБ по прямым связям (в LKDSDomain и LKDSServer) нужно (если это нужно) внести вручную комментарий в ЛБ и вручную изменить ID ЛБ в географической структуре.

Можно доработать LKDSServerCfg, что бы в списке ЛБ7 был виден объект из географической структуре, на котором этот ЛБ7 установлен. Тогда необходимость комментария отпадает. И нужно будет только изменить ID в географической структуре.

Если я, конечно, правильно понял вопрос.
 
Андрей Ефименко написал(а):
Можно доработать LKDSServerCfg, что бы в списке ЛБ7 был виден объект из географической структуре, на котором этот ЛБ7 установлен. Тогда необходимость комментария отпадает. И нужно будет только изменить ID в географической структуре.


Хорошая идея

Андрей Ефименко написал(а):
Если я, конечно, правильно понял вопрос.


Абсолютно верно
 
Андрей Ефименко написал(а):
В LKDSPro используется понятие "индекс ЛБ", который "скрывает" ID ЛБ, этот индекс указывается в географической структуре серверов LKDSDisp и LKDSDomain. Если в настройке LKDSPro изменить ID ЛБ для конкретного индекса ЛБ, то в географической структуре менять ничего не нужно.

Вероятно, речь идет о том, что при физической замене ЛБ на объекте, в списке ЛБ по прямым связям (в LKDSDomain и LKDSServer) нужно (если это нужно) внести вручную комментарий в ЛБ и вручную изменить ID ЛБ в географической структуре.

Можно доработать LKDSServerCfg, что бы в списке ЛБ7 был виден объект из географической структуре, на котором этот ЛБ7 установлен. Тогда необходимость комментария отпадает. И нужно будет только изменить ID в географической структуре.

Если я, конечно, правильно понял вопрос.

Да, вот и получается же, что при установке нового ЛБ на существующий объект, мне надо сначала зайти в LKDSServerCfg добавить ЛБ в список ЛБ, а затем открыть SPult от Админа и там в географической структуре тоже поменять ID на новый
 
Семен Федоров написал(а):
Да, вот и получается же, что при установке нового ЛБ на существующий объект, мне надо сначала зайти в LKDSServerCfg добавить ЛБ в список ЛБ, а затем открыть SPult от Админа и там в географической структуре тоже поменять ID на новый

В LKDSServerCfg заходить не нужно.
ЛБ7 сам появится в списке. Нужно в связях ЛБ7 ввести связь с LKDSServer или LKDSDOmain.
 
И еще такой вопрос, существует ли способ синхронизировать 2 диспетчерских? В текущих реалиях хочется повысить отказоустойчивость, для чего планируется разместить 2 сервера на разных хостингах, один из них рабочий, второй резервный и в случае отказа одного сервера, просто подключиться к другому. Вопрос больше в том, как зеркалить изменения между серверами.
 
Андрей Ефименко написал(а):
В LKDSServerCfg заходить не нужно.
ЛБ7 сам появится в списке. Нужно в связях ЛБ7 ввести связь с LKDSServer или LKDSDOmain.

То есть, я правильно понимаю, что ЛБ в котором прописана прямая связь на сервер, пропишется сам, и ключ для него выберется из списка автоматически? Если так, то подгруженная информация из географии будет очень кстати!
А ЛБ подключенные через LKDSCloud придется вручную только добавлять?
 
Семен Федоров написал(а):
И еще такой вопрос, существует ли способ синхронизировать 2 диспетчерских? В текущих реалиях хочется повысить отказоустойчивость, для чего планируется разместить 2 сервера на разных хостингах, один из них рабочий, второй резервный и в случае отказа одного сервера, просто подключиться к другому. Вопрос больше в том, как зеркалить изменения между серверами.

Если основной сервер на Windows, а резервный на Linux, что что-то подобное делает MoveToLinux.


Семен Федоров написал(а):
То есть, я правильно понимаю, что ЛБ в котором прописана прямая связь на сервер, пропишется сам, и ключ для него выберется из списка автоматически? Если так, то подгруженная информация из географии будет очень кстати!

Да.

Семен Федоров написал(а):
А ЛБ подключенные через LKDSCloud придется вручную только добавлять?

Если связь с ЛБ через LKDSCloud или транзитом через другой сервер, то ЛБ в список ЛБ7 нужно добавлять вручную.
 
Андрей Ефименко написал(а):
Если основной сервер на Windows, а резервный на Linux, что что-то подобное делает MoveToLinux.

Рассматриваю держать 2 сервера на Linux, значительно удобнее администрировать.
 
Назад
Сверху