IMHO.WS

IMHO.WS (http://www.imho.ws/index.php)
-   Пингвинятник (ОС *NIX) (http://www.imho.ws/forumdisplay.php?f=76)
-   -   Клиент терминального сервера. (http://www.imho.ws/showthread.php?t=110964)

Volt 10.11.2006 10:20

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

rserg 11.11.2006 00:22

Можна
с юникс машин доступаешся на свой терминальный сервер через rdesktop
далее делаеш образы тех всех своих контрольных дискет.
а дальше в виртуальний флопик суеш образы(етому правда сотрудников придетса научить :) )
прога для деланья образов FloppyImage занимает ~200к
для вируального флопика Virtual FD Control Panel ~200k
если нормально настроить то должно работать :) (если клиент-банк жестко не спрашивает а: или в: а позволяет указать дисковод)
у меня правда все со своих доступались, но думаю что на одной машине тоже можно провернуть ето.

Volt 21.11.2006 11:54

Пока не получается :(
В общем, клиент-банк использует утилиту PGP для работы с ключами. Она берет путь к ключу из переменной окружения, которая устанавливается через autoexec.nt
Я попробовал так: подключаться командой
rdesktop -r disk:floppy=/mnt/floppy server
А потом подключать диск \\tsclient\floppy как сетевой.
Самое интересно, что один клиент настроить получилось, а вот с другими - проблема: не может найти файл по пути A:\keyfile. Я уже ничего не понимаю. Может, кто сталкивался?

rserg 21.11.2006 17:19

чего-то непонял я - ты чтоли каждому флопик по сети монтируеш??
(насколько я понял, каждий сидит за своим компом с линуксом и дискетой, а клиент банк на сервере и ты монтируеш дискету по сети для клиент банка, и таким образом что-то полумается)
клиент банк точно хочет диск а: и никакой другой(одному на а: , второму на m:, третьему на n:, )??
а в чем проблема варианта с образами которые хранятся на сервере??

Volt 22.11.2006 13:04

Да не хотелось бы все хранить на сервере...
Хотя, если ничего другого не остается, то почему бы и нет. Дело в другом. Ему надо указать путь к ключевому файлу, путь может быть абсолютно любой, но, как я понял, он должен быть один для всех. Короче, он прописывается в файле c:\windows\system32\autoexec.nt

rserg 22.11.2006 14:04

ну а типа как-то так обойти в файл c:\windows\system32\autoexec.nt
прописать для того кейфайла типа N:\keyfile
а всем юзерам в автозагрузку докинуть скрипт с монтированием их шар, например
для одного юзера net use N: \\PC1\floppy
для второго net use N: \\PC2\floppy (ну или как ты там назвеш те шары это непринципиально)
может так попробовать его обойти??

Volt 22.11.2006 15:20

Вот так я уже пробовал, работает. Просто не хотелось лишний раз расшаривать ключ от клиент-банка. Если бы прокатило подключение \\tsclient\floppy (tsclient - это не имя компьютера), было бы супер. Но, похоже, не получается :(

rserg 22.11.2006 16:33

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

Volt 30.11.2006 10:20

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

rserg 01.12.2006 13:55

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

Volt 01.12.2006 16:25

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


Часовой пояс GMT +4, время: 00:08.

Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.