Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server

Только что открыл на 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 на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 09.02.08 14:14. Заголовок: Pasha пишет: Этой ф..

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

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

 Отправлено: 09.02.08 14:25. Заголовок: alkresin пишет: Дел..

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.

 Отправлено: 09.02.08 14:34. Заголовок: Петр пишет: К тому ..

Петр пишет:

цитата:

К тому же, на мой взгяд 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 строчки - и все работает так, как оно работало и раньше, но на новой платформе, с использованием преимуществ клиент-серверной схемы. А дальше, при наличии времени и желания он меняет свои программы, добавляя новые возможности.

 Отправлено: 09.02.08 15:06. Заголовок: alkresin пишет: Вно..

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

 Отправлено: 09.02.08 16:51. Заголовок: IF LETO_FILE("//..

цитата:

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 - файл, при этом, кстати, не пострадает.

Впрочем, здесь есть о чем подумать.

 Отправлено: 09.02.08 17:31. Заголовок: alkresin пишет: Так..

alkresin пишет:

цитата:

Так мы же, вроде, договорились, что файловые функции будут работать только при непустом DataPath - а при этом c:\ не прокатит.

Хорошо, вот это тоже не должно работать

DataPath=c:/test
IF LETO_FILE("//127.0.0.1:2812/../windows/*.*")

По сути файловые функции это и dbCreat, INDEX TO, COPY TO и т.п. - еще немного и Вы согласитесь со мной в
вопросе о DataPath и наличии letodb.ini

 Отправлено: 09.02.08 18:45. Заголовок: DataPath=c:/test IF ..

цитата:

DataPath=c:/test IF LETO_FILE("//127.0.0.1:2812/../windows/*.*")

Надо будет вставить что-то вроде
if At( "..",cPath) != 0
return ERROR
endif
Но это, кстати, не относится к вопросу об обязательности DataPath :)

 Отправлено: 09.02.08 19:00. Заголовок: Давайте определимся,..

цитата:

Давайте определимся, что в нашем случае есть БД - это конкретная таблица или каталог с логически связанными таблицами (+каталог с индексами конечно).

А зачем нам вообще вводить такую дополнительную сущность ? Что она дает разработчику, что она для него означает ?
Даже если вводить это дело опционально, надо объяснить, что получит программист от его использования.
Если это нужно для удобства разграничения прав ( чтоб на каждый файл не писать ), то это можно сделать на уровне серверного модуля ...

 Отправлено: 09.02.08 20:23. Заголовок: Разработчику БД може..

Разработчику БД может и ничего, кроме безопасности, а разработчика сервера (администратора) может от головной боли спасти

Ну это почти шутка.

Попробую, как смогу, обьяснить идею (по сути позаимствованную у больших РБД).
Вот если я знаю, что у меня БД - каталог, я могу создать в этом (?) каталоге таблицу которая содержит всю служебную информацию о содержимом каталога (БД). И мне не надо (серверу) проверять каждый раз есть ли, допустим, в базе данных таблица "разработчики" используя функцию 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)

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

Все - аргументы иссякли, красноречие тоже

 Отправлено: 10.02.08 13:50. Заголовок: Все это хорошо, я бы..

Все это хорошо, я бы добавил еще в 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-файл опции, разрешающие их - по умолчанию - запрет.

 Отправлено: 10.02.08 16:46. Заголовок: Отвечать буду не по ..

Отвечать буду не по порядку:

alkresin пишет:

цитата:

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

Незачем - если эта клиентская программа не изощренный Manager, позволяющий нам с комфортом админить БД удаленно - добавлять пользователей, менять их роли, менять структуру таблиц, создавать индексы, править stored proc и триггеры или прото смотреть, кто из пользователей сейчас работает, что делает, отключать кто не понравился или всех сразу (в случае плохого настоения или производственной необходимости).

цитата:

Такую master table, также, как и stored proc разных видов, можно организовать..

Можно.

цитата:

Сначала пусть просто запустит letodb.exe, посмотрит, как это работает в деле

Согласен. Кстати, здесь несколько возможных пользователей уже заявляли о своей готовности тестировать/использовать такой продукт. Я думаю, что было бы неплохо услышать их мнение, первые впечатления так сказать и, что особенно важно, что они ожидают увидеть в бл.будущем.

цитата:

Но говорить разработчику:

Пока никто ничего не говорил.
Ini файл придется все равно включать в поставку, пускай и с закомментированными строками, утилиту для проверки это ini файла придется писать (не скармливать же неизвестно, что работающему серверу) - это как в apache (учиться на чужом опыте не должно быть зазорно никому).
Создание и заполнение master и прочих служебных таблиц - это дело сервера и (или) admin tools. Про их открытие я уже писал - они сугубо для внутреннего пользования и их использование должно быть по возможности максимально скрыто от конечного пользователя.
Тоже относится к управлению правами - по умолчанию для сервера - все пользователи могут быть определены как anonymus.


alkresin пишет:

цитата:

Кстати, для полной защиты от файловых функций

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

 Отправлено: 10.02.08 17:53. Заголовок: Не мне Вам говорить,..

цитата:

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

Зачем каждый раз ? Один раз решить этот вопрос и поставить. Кстати, наверное, надо будет и leto_FOpen(), leto_FRead(), ... сделать.
Я не против того, чтобы сделать управление правами, его так или иначе надо будет делать ( опционально! :) ), просто в мои личные рабочие планы это пока не входит.

Я только что запостил кое-какие изменения, выработанные на основании нашей дискуссии.
Итак:
1) Файловые операции разрешены только при непустом значении DataPath и при EnableFileFunc = 1 в letodb.ini
2) Использование ../ в пути запрещено
3) Создание файлов данных и индексов с нестандартными расширениями разрешено только при наличии EnableAnyExt = 1 в letodb.ini
4) Logfile может быть только с расширением .log :)

Да, Петр, как мне вас назвать в Changelog'e ( я там вашу leto_scananddel() добавил ) ?

 Отправлено: 10.02.08 18:51. Заголовок: Обычно пишу P.Chorny..

Обычно пишу 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.

И может еще что-то менял у себя, вспомню напишу.

 Отправлено: 10.02.08 19:33. Заголовок: sourceforge - petr_c..

цитата:

sourceforge - petr_ch

Это запрос на добавление в список developer'ов :) ? Если да, то добавлю, конечно.

цитата:

Я понимаю, что возможно все это когда нибудь будет переписано на C (или не будет

Обязательно будет, и не только это.

 Отправлено: 10.02.08 19:42. Заголовок: alkresin пишет: Это..

alkresin пишет:

цитата:

Это запрос на добавление в список developer'ов :)

Да, пока управление правами никто не застолбил (опционально, конечно)

 Отправлено: 10.02.08 21:23. Заголовок: Добавил...

Добавил.

 Отправлено: 12.02.08 09:52. Заголовок: Петр, вы забыли в Ch..

Петр, вы забыли в Changelog запись занести и, желательно, на https://sourceforge.net/forum/forum.php?forum_id=779825

 Отправлено: 12.02.08 10:44. Заголовок: Спасибо, внес. err..

Спасибо, внес.

errorsys на С переводить будем?

 Отправлено: 12.02.08 11:18. Заголовок: errorsys на С перево..

цитата:

errorsys на С переводить будем?

А зачем ? Выигрыша в скорости это не даст.

 Отправлено: 12.02.08 11:44. Заголовок: Я собственно о WrLog..

Я собственно о WrLog - бы иметь общую функцию и для PRG и для C