Re: [Refdb-users] Build Debian bin pkg from Ubunt scr pkg

[Stefan S. <ste...@ya...>]

Hallo!

Markus Hoenicka writes:

> As mentioned in my reply to Torsten, the server could be modified to
> start but return error messages to each client request as long as the
> main database has not been created.

Good solution!

> >  - After the binary installation I started the "refdb-init" script as root.  To execute this script successfully I had to make two minor modifications (Torsten already notes difficulties concerning this script in the README.Debian file of the package.)
> >
> >  -- I had the change the value of MYREFDBCTL to "/etc/init.d/refdb"
> >
> >  -- I had to execute: "/usr/sbin/refdbd" as root and change the ownership of the "/var/lib/refdb/db" hierarchy afterwards.
> >
> 
> I guess this amount of porting is acceptable for a binary package. I
> assume that Debian packages use the same sort of patch collections as
> BSD ports do to cope with the idiosyncrasies of these OSes.

As Torsten writes he will handle the first point in the Ubuntu source package. The first half of the second point should - from my point of view - also be handled by Torsten, by removing a patch from the Ubuntu source package.  Still I wonder how the second half of the second point is handled for other installations.  If "/usr/sbin/refdbd" sets-up the "refdb" database as "root", the refdb-file will be owned by root (sqlite(3) case).  Then of course the "refdbd"-server can only write to the "refdb"-database if it executes as root (because the permissions are set to 644).  As Torsten notes a server that executes as "root" is a possible security breach.  Hence - at least in the Ubuntu/Debian installatin of the refDB software the "refdb"-server executes as user "refdb".

As I understand, in the original refdb-init script the "refdbd"-servers is startd by the "refdbctl" script, which is not used in the Ubuntu/Debian installation.  It seems to me that according to this scripts the "refdb"-server executes as "root".  Then of course there are no access problems, but possible security problems if the server gets corrupted.  Maybe this should be changed upstream; but maybe it is handled differently anyway and I am not aware of it.


>> After fiddling with the refdb-init script I have to questions concerning this script:
>>
>>  - I do not understand why in the call to refdbd contains the -e flag set to 0 AND the -L flag set.  Shouldn't the -e flag be set to 2 in this case or the -L flag be left out?  But maybe this means falling back to stderr if the file is not accessible, which is not exactly what the manual says.
>>
> 
> Which version of RefDB do you use? Actually, I can't find the -L flag
> being used with refdbd in the current svn revision of refdb-init.in

I inspected the source tree _after_ building the binary packages.  This led me to the false belief that I was reading the refdb-init in its upstream version, when I actually read it in its version patched by the Ubuntu source package.  Sorry for that.

>> - In the refdb-init.in file most of the path-names (for example the
>>      path-name to the database-directory) are made configurable in the
>>      build-process, but this is not the case for the
>>      example-configuration files.  In the way the software is
>>      currently setup there should not arise any inconsistencies.
>>      Nevertheless a cleaner solution seems to me to make the
>>      example-configuration files configurable in the build-process and
>>      to let the refdb-init script read these values from the selected
>>      configuration file.
> 
> I'm not sure whether I can follow you here. The example config files
> are built from input files. All refdbdrc example config files are
> built from the same source refdbdrc. Which variables in particular are
> not adjusted properly? I may have missed something which happens to
> work on FreeBSD but not on other OSes.

In the refdb-init script you check whether a reference database of the name the user inputs already exist.  In the case of an sqlite(3) database the pertaining line of code reads as follows:

ls <db_path>/$referencedb_name 2>/dev/null \
		&& echo "Reference database exists and I'm not going to fiddle with it. Do you want to pick a different name [y/n]?" && input=$(confirm)

What I meant is that if the administrator changed the "dbpath" entry in the "refdbdrc.sqlite(3).example" file before executing the "refdb-init" script this test would not make sense.  On the one hand this is obviously not the way you intended the administrator to proceed and it may sound like a contrived example.  On the other hand setting such data only in one place, the "etc/refdbdrc" (which gets transformed into the "refdbdrc.sqlite(3).example" file) and always reading it from this source is a principle worth adhering to, because it leads to more robust code.

Kind regards

Stefan