Форум » LetoDB, HbNetio. » Leto DB Server » Ответить
Leto DB Server
alkresin: Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :). Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :). Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально. Преимущества по сравнению с обычным файл-сервером: 1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит. 2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера. 3) значительное уменьшение сетевого траффика. 4) Должен быть, по идее, выигрыш в скорости. 5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ). 6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
Петр: Pasha пишет: Этой функции можно было бы передавать еще используемый rdd на сервере: dbfcdx/dbfntx/etc Возможно лучше OPEN DATABASE base CONNECTION cn VIA "RDDCDX" Pasha пишет: Какие будут предложения по безопасности ? Давать права на опасные операции на каталоги БД или отдельно на таблицы/индексы ? Давайте определимся, что в нашем случае есть БД - это конкретная таблица или каталог с логически связанными таблицами (+каталог с индексами конечно). Мне кажется, что каталог. Свойства БД мы можем хранить в letodb.ini [SERVER] AllowIP=127.0.0.1;169.128.0.9 AllowAnonymus=TRUE [DATABASE] DBName=base DBPatch=c:\mybase\data DBPatchIndex=c:\mybase\indexes DBCPAGE=RU866 AllowIP=127.0.0.1;169.128.0.9 AllowAnonymus=FALSE При установлении соеденения мы проверяем есть ли у данного пользователя право на подключение к серверу. Сначала проверим на допустимость IP, потом анонимно ли соединение, если анонимно - то позволены ли такие подключения, если именное подключение то проверим допустимость имени и пароля, не подключен ли уже такой пользователь pwd.ini [USER] UserName=master UserPWD=mypwd UserGROUP=ADMINISTRATORS [USER] UserName=user1 UserPWD=myusrpwd UserGROUP=USERS Если все хорошо регистрируем на сервере connection и возвращаем его хендл Потом при выполнении любой операции по хендлу connection определяем пользователя и его права ( в зависимости от того в какую группу мы его включили ) и выполняем или нет - выставляем NO_ACCESS или SERVER_BUSY Это так схема, все технические детали можно будет согласовать после принятия такой схемы, или искать новую
Петр: alkresin пишет: Дело хорошее, но надо еще подумать :) Извините, это я просто забыл об этом, нужно кое-что просто подправить. Схема в xHb уже устоявшаяся. 6-й параметр там уже давно, и связан с тем как xHarbour обрабатывает строку с одного символа. Я сталкивался с этим когда писал wrapper для unrar.dll. Вот этот код if( pArray != NULL ) { if( (PFCode = RARProcessFile(hArcData, (hb_arrayScan(pArray, pValue, NULL, NULL, #ifdef __XHARBOUR__ FALSE, #endif FALSE) > 0) ? Operation : RAR_SKIP, pszDst, NULL)) != 0 ) { OutProcessFileError( PFCode, HeaderData.FileName ); fResult = FALSE; break; } } одинаково хорошо работает и со старой версией xHb (конкретно тестировалось на 0.99.5, 0.99.7 ) и с 1.0. и CVS. Ну и соответственно с Harbour.
alkresin: Петр пишет: К тому же, на мой взгяд DataPath в letodb.ini не может быть опциональным, как и IndexPath. И leto_file() должна быть привязана к DataPath/IndexPath Вопрос о DataPath и о наличии letodb.ini я бы все же предпочел оставить на усмотрение администратора. А вот все файловые функции, включая File(), действительно, надо разрешать только при непустом DataPath, а erase/rename - только для файлов с раширениями .dbf,.fpt,... Вносить какие-то уязвимости на сервер мы не имеем права. Но код все равно придется переделывать, добавлять же нужно REQUEST LETO RDDSETDEFAULT( "LETO" ) Это стандартная вставка для каждого RDD. почему не добавить еще и CREATE CONNECTION cn USER "user" PASSWORD "password" ... Чтобы не вынуждать человека делать то, что ему, может, и не нужно. В значительной части случаев люди переделывают уже существующие программные комплексы под новую платформу, сервер, RDD и в их программах, скорее всего, уже есть какие-то средства авторизации, зачем же заставлять их использовать другие вместо/или дополнительно к своим ? Я представляю себе весь процесс перехода на новый RDD так: сначала человек просто ставит сервер, перекомпилирует свои программы, добавив туда 2 строчки - и все работает так, как оно работало и раньше, но на новой платформе, с использованием преимуществ клиент-серверной схемы. А дальше, при наличии времени и желания он меняет свои программы, добавляя новые возможности.
Петр: alkresin пишет: Вносить какие-то уязвимости на сервер мы не имеем права. Согласен IF LETO_FILE("//127.0.0.1:2812/c:/windows/*.*") dbCreate( "//127.0.0.1:2812/c:/windows/system.ini", aStruct ) ENDIF Кстати, первую уязвимость вашего сервера, показали Вы, Александр: Log=letodb.ini
alkresin: IF LETO_FILE("//127.0.0.1:2812/c:/windows/*.*") dbCreate( "//127.0.0.1:2812/c:/windows/system.ini", aStruct ) ENDIF Так мы же, вроде, договорились, что файловые функции будут работать только при непустом DataPath - а при этом c:\ не прокатит. Кстати, первую уязвимость вашего сервера, показали Вы, Александр: Log=letodb.ini :) ini - файл, при этом, кстати, не пострадает. Впрочем, здесь есть о чем подумать.
Петр: alkresin пишет: Так мы же, вроде, договорились, что файловые функции будут работать только при непустом DataPath - а при этом c:\ не прокатит. Хорошо, вот это тоже не должно работать DataPath=c:/test IF LETO_FILE("//127.0.0.1:2812/../windows/*.*") По сути файловые функции это и dbCreat, INDEX TO, COPY TO и т.п. - еще немного и Вы согласитесь со мной в вопросе о DataPath и наличии letodb.ini
alkresin: DataPath=c:/test IF LETO_FILE("//127.0.0.1:2812/../windows/*.*") Надо будет вставить что-то вроде if At( "..",cPath) != 0 return ERROR endif Но это, кстати, не относится к вопросу об обязательности DataPath :)
alkresin: Давайте определимся, что в нашем случае есть БД - это конкретная таблица или каталог с логически связанными таблицами (+каталог с индексами конечно). А зачем нам вообще вводить такую дополнительную сущность ? Что она дает разработчику, что она для него означает ? Даже если вводить это дело опционально, надо объяснить, что получит программист от его использования. Если это нужно для удобства разграничения прав ( чтоб на каждый файл не писать ), то это можно сделать на уровне серверного модуля ...
Петр: Разработчику БД может и ничего, кроме безопасности, а разработчика сервера (администратора) может от головной боли спасти Ну это почти шутка. Попробую, как смогу, обьяснить идею (по сути позаимствованную у больших РБД). Вот если я знаю, что у меня БД - каталог, я могу создать в этом (?) каталоге таблицу которая содержит всю служебную информацию о содержимом каталога (БД). И мне не надо (серверу) проверять каждый раз есть ли, допустим, в базе данных таблица "разработчики" используя функцию File - достаточно произвести поиск в таблице "мастер" ( да тот самый SELECT name FROM master WHERE obj_name == "разработчики" AND obj_type == TABLE, который в той или иной форме допускают все РБД). Тоже самое относится к блокировкам (Р.Спенс "Кто владеет моей блокировкой" ) К тому же, не знаю как-кто, а я привык обычно размещать таблицы в одной папке, а даже если не так, то кто мешает нам в той же таблице мастер создать запись obj_name obj_type obj_shared obj_attached obj_location ------------------------------------------------------------------------------------------------- продажи table no no %DATAPATH% клиенты table no yes d:\clients\clients.dbf или даже со временем клиенты table no yes //192.168.0.25:2042/clients.dbf Можна организовывать словари таблиц и много чего другого, что на ум придет. Восстанавливать структуру такой таблицы автоматически тоже можно будет, достаточно лищь сохранять информацию о структуре таблиц и индексных файлов, типе RDD. Если позже захочется поиграться с SQL, то тоже будет намного легче, имея такую служебную информацию. Кроме того, раз речь выше шла о stored proc и triggers, то хочу напомнить, что используя Harbour (библиотеку compiler) эти самые процедуры можно будет организовывать без hrb и следовательно обращения к дисковой системе. Менять их удаленно и перекомпилировать на лету (естественно после того как решить все вопросы связанные с авторизацией). Или даже используя hrb (или задекларированные когда-то разработчиками Harbour библиотеки hrb - если их создадут, или создать самим - я думаю это не самое трудное задание) - информацию о них тоже нужно где-то хранить (размещение, контрольную сумму, желательно версию P_CODE) В краткосрочной перспективе. действительно, это может и не дать ничего существенного, но если этим заняться "всерьез и надолго" (хотя бы на год) .. Все - аргументы иссякли, красноречие тоже
alkresin: Все это хорошо, я бы добавил еще в master table возможность сослаться на курсор из какой-нибудь доступной SQL DBMS. Но: 1) Такую master table, также, как и stored proc разных видов, можно организовать, и не пользуясь концепцией database - и тут прилагаем бритву Оккама :). 2) Я все еще не вижу, зачем клиентской программе знать о существовании такого внутреннего разделения данных на сервере на databases и открывать эти databases. Сервер, если databases определены и master tables, управление правами и т.д сделаны на их уровне, может сам определить, к какой database относится открываемая таблица и выполнить соответствующие действия. Я - противник того, чтобы заставлять людей делать то, что им не нужно. Сначала пусть просто запустит letodb.exe, посмотрит, как это работает в деле, не заморачиваясь содержимым ini-файла. Чуть позже, если сочтет это нужным, добавит letodb.ini с DataPath. Потом, может, решит ( а может и нет ), что лучше использовать средства авторизации и определения прав, предлагаемые сервером, и активизирует там эти средства. Может, ему понравится идея master-table, и он активизирует и эту возможность. И так же - с databases, и со всем, что мы здесь придумаем. Но говорить разработчику: вот тебе letodb, чтобы использовать ее, ты должен разбить свои данные на databases, описать все это в ini-файле, создать и заполнить для каждой database master-table и дополнительные файлы системы управления правами, ... Да еще открывать эти databases, без которых ты прекрасно жил до того, в своей программе. Я - против. Кстати, для полной защиты от файловых функций предлагаю добавить в ini-файл опции, разрешающие их - по умолчанию - запрет.
Петр: Отвечать буду не по порядку: alkresin пишет: Я все еще не вижу, зачем клиентской программе знать о существовании такого внутреннего разделения данных на сервере на databases и открывать эти databases. Незачем - если эта клиентская программа не изощренный Manager, позволяющий нам с комфортом админить БД удаленно - добавлять пользователей, менять их роли, менять структуру таблиц, создавать индексы, править stored proc и триггеры или прото смотреть, кто из пользователей сейчас работает, что делает, отключать кто не понравился или всех сразу (в случае плохого настоения или производственной необходимости). Такую master table, также, как и stored proc разных видов, можно организовать.. Можно. Сначала пусть просто запустит letodb.exe, посмотрит, как это работает в деле Согласен. Кстати, здесь несколько возможных пользователей уже заявляли о своей готовности тестировать/использовать такой продукт. Я думаю, что было бы неплохо услышать их мнение, первые впечатления так сказать и, что особенно важно, что они ожидают увидеть в бл.будущем. Но говорить разработчику: Пока никто ничего не говорил. Ini файл придется все равно включать в поставку, пускай и с закомментированными строками, утилиту для проверки это ini файла придется писать (не скармливать же неизвестно, что работающему серверу) - это как в apache (учиться на чужом опыте не должно быть зазорно никому). Создание и заполнение master и прочих служебных таблиц - это дело сервера и (или) admin tools. Про их открытие я уже писал - они сугубо для внутреннего пользования и их использование должно быть по возможности максимально скрыто от конечного пользователя. Тоже относится к управлению правами - по умолчанию для сервера - все пользователи могут быть определены как anonymus. alkresin пишет: Кстати, для полной защиты от файловых функций Не мне Вам говорить, но любая более менее серьезная клипперная программа использует файловые функции - и что каждый раз ходить к серверу - ini править (удаленное да и просто управление правами не реализовано ).
alkresin: Не мне Вам говорить, но любая более менее серьезная клипперная программа использует файловые функции - и что каждый раз ходить к серверу - ini править (удаленное да и просто управление правами не реализовано Зачем каждый раз ? Один раз решить этот вопрос и поставить. Кстати, наверное, надо будет и leto_FOpen(), leto_FRead(), ... сделать. Я не против того, чтобы сделать управление правами, его так или иначе надо будет делать ( опционально! :) ), просто в мои личные рабочие планы это пока не входит. Я только что запостил кое-какие изменения, выработанные на основании нашей дискуссии. Итак: 1) Файловые операции разрешены только при непустом значении DataPath и при EnableFileFunc = 1 в letodb.ini 2) Использование ../ в пути запрещено 3) Создание файлов данных и индексов с нестандартными расширениями разрешено только при наличии EnableAnyExt = 1 в letodb.ini 4) Logfile может быть только с расширением .log :) Да, Петр, как мне вас назвать в Changelog'e ( я там вашу leto_scananddel() добавил ) ?
Петр: Обычно пишу P.Chornyj <myorg63@mail.ru> sourceforge - petr_ch Александр, у меня есть еще несколько мелких замечаний по реализации aSock := hb_ipAccept( Socket ) nOperations ++ IF hb_ipErrorCode() == 0 oSock := HSUser():New( aSock/*[1]*/ ) //oSock:cAddr := aSock[2] //oSock:nPort := aSock[3] Как Вы видите я перенес у себя инициализацию полей cAddr, nPort в метод New - мне кажется так оно быстрее вертеться будет, исходя из мого понимания реализации ООП в Harbour, возможно я и ошибаюсь. Сл., возможно Request ; ABS,; ALLTRIM,; надо вынести в отдельный ch по типу hbexternal.ch также я заменил IF cItem == "skip" cReply := hs_skip( oUser,Substr(cCommand,nPos1+1) ) ELSEIF cItem == "seek" cReply := hs_seek( oUser,Substr(cCommand,nPos1+1) ) на nItem := AScan( aCommand, cItem ) SWITCH nItem CASE 1 cReply := hs_skip( oUser,Substr(cCommand,nPos1+1) ) EXIT никакого существенного выиграша это не дает, наверное из-за AScan, но xHarbour не позволяет использовать CASE "skip" , Я понимаю, что возможно все это когда нибудь будет переписано на C (или не будет ), но все же хочу завтра переписать GetCmdItem и потестировать. Сл. очень часто используется Ltrim(Str( Для таких случаев xHb в Str имеет четвертый параметр <lTrim> - This parameter defaults to .F. (false). When .T. (true) is passed, the returned string has no leading spaces. И может еще что-то менял у себя, вспомню напишу.
alkresin: sourceforge - petr_ch Это запрос на добавление в список developer'ов :) ? Если да, то добавлю, конечно. Я понимаю, что возможно все это когда нибудь будет переписано на C (или не будет Обязательно будет, и не только это.
Петр: alkresin пишет: Это запрос на добавление в список developer'ов :) Да, пока управление правами никто не застолбил (опционально, конечно)
alkresin: Добавил.
alkresin: Петр, вы забыли в Changelog запись занести и, желательно, на https://sourceforge.net/forum/forum.php?forum_id=779825
Петр: Спасибо, внес. errorsys на С переводить будем?
alkresin: errorsys на С переводить будем? А зачем ? Выигрыша в скорости это не даст.
Петр: Я собственно о WrLog - бы иметь общую функцию и для PRG и для C
полная версия страницы