[Pkg-firebird-general] Issues firebird 1.5.2

Damyan Ivanov divanov@creditreform.bg
Wed, 26 Jan 2005 17:35:33 +0200


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9EF4A898E9990AB6FAF879C6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Remco Seesink wrote on 25.01.2005 17:26:
>>firebird2 (1.5.2-0mentors1) unstable; urgency=low
>>.
>> * New upstream release
>> * Upload to mentors.debian.net
>
> This is fine on mentors, but don't forget to remove this entry and
> mentor versions if you prepare the final version so the changelog is
> clean and complete.

"clean" == version is 1.5.2-1, no "upload to mentors.debian.net"
"complete" == ?

>> * Fixed short description to please lintian
>
> I couldn't make out what you changed exactly here.

My fault, capitalization of first word in short description is not
preffered to be lowercase. Note taken, entry fixed

>> * libfoo.so->libfoo.so.1.5.2 moved to -dev to please lintian
>
> I didn't find it in the -dev package.
My mistake.

> Also, ibaccess (which is not
> packaged in debian) uses the old library symlink libgds.so.0 and stopped
> working when I installed the classic version of the library. Super still
> works.
>
> I think a library (symlink) should not be in a -dev package, but in the
> lib package. It would be unexpected that you would need to install a
> -dev package for a library instead of lib package. But I don't
> understand why lintian would disagree, so I might be completly wrong
> here.

I am in a fog too, so I toke the time to read chapter 8 of the policy.
It says:

(excerpts from section 8.1)
The package should install the shared libraries under their normal
names. For example, the libgdbm3 package should install libgdbm.so.3.0.0
as /usr/lib/libgdbm.so.3.0.0.

The run-time library package should include the symbolic link that
ldconfig would create for the shared libraries. For example, the
libgdbm3 package should include a symbolic link from
/usr/lib/libgdbm.so.3 to libgdbm.so.3.0.0. This is needed so that the
dynamic linker (for example ld.so or ld-linux.so.*) can find the library
between the time that dpkg installs it and the time that ldconfig is run
in the postinst script.

(excerpts from section 8.4)
The development package should contain a symlink for the associated
shared library without a version number. For example, the libgdbm-dev
package should include a symlink from /usr/lib/libgdbm.so to
libgdbm.so.3.0.0. This symlink is needed by the linker (ld) when
compiling packages, as it will only look for libgdbm.so when compiling
dynamically.

So we need libfbclient.so.1.5 -> libfbclient.so.1.5.2 in libfbclient2
and libfbclient.so -> libfbclient.so.1.5.2 in libfbclient2-dev

I am not sure if we need libfbclient.so.1 -> libfbclient.so.1.5.2 in
libfbclient2.

Changing this accordingly.

>> * Add mysenf in Uploaders
>
> Small type and welcome in the team.
>
> One other thing I noticed today is that the classic server is started
> through inetd. Is this new behaviour?

I think not. superserver starts from init.d, and classic - from inetd.

 > I am not so sure this is a good
> idea.

I am not sure what your concerns are. Pick one :-)
1) leave it as is
2) when adding the line in inetd.conf to make it commented (disabled)
3) move it to xinetd, with an option add it disabled

some debconf magic may be used to ask user whether server should be enabled.

 > It also gave me several problems when trying to deinstall te
> classic server. It complained the process was still running and hence
> couldn't deinstall.

were you connected to a database? ibaccess/ibwebadmin are possible
connection holders that will keep a server process running.

> And another issue which we should work out is the setting of the sysdba
> password. According to policy this should be done through debconf. It
> also shouldn't echo the actual password. I think the easiest solution is
> to take the password question out of the installer and into the
> documentation. After that I could look into this to produce a debconf
> patch.

Yes, it is irritating to be asked every time for a sysdba password.
moreover after I installed it the first time (and set custom sysdba
password) the postinst ever complained that changing the sysdba password
failed (whic is natural, since gsec can't connect with the default
password anymore)

> This is what I additionally discovered so far.
Thank you very much for your review.

There is an additional problem, discovered lately. You are subscribed to
firebird-devel, so probably noticed it too. Somebody said that
fb_lock_mgr creates semaphores with 0666 rights, opening gate to a local
DOS attack.
As far as I understand, the official statement (Jim Starkey) is "Do not
allow untrusted users on the machine", but this does not make any sense
to me.

So my proposal is to make semaphore 0660 firebird:firebird and to state
in the README.Debian that direct database connection is not supported
and the preffered method is via loopback interface, i.e.
localhost:/path/to/db.gdb.

This seems a little drastic at first glance, but the current situation
is not much better: if using mixed user direct access, then fb_lock_mgr
must be set SUID root so it can send signals to any users' processes (it
is not in debian packages and for a reason). The workaround to this is
to never use direct database access and always via loopback
(localhost:/...).

Thoughts?


I am a bit stuck and will uppload updated source package later this week.


dam
--
Damyan Ivanov          0x9725F63B         Creditreform Bulgaria
divanov@creditreform.bg             http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993           fax: +359(2)920-0994
mobile: +359-88-856-6067      ICQ: 3028500      Y!M: dam3028500

--------------enig9EF4A898E9990AB6FAF879C6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB97jHHqjlqpcl9jsRAmufAKCky3nlCRzfNWuT/gckkHCrT+gqHgCfXPIF
Uz4S+7B1AgrZhC2ufSksITI=
=FHpe
-----END PGP SIGNATURE-----

--------------enig9EF4A898E9990AB6FAF879C6--