[Slad] List of platform where SLAD probably runs? [u]

[Lukas Grunwald [c]]

Jan-Oliver Wagner wrote:
> Hi,
> 
> I would like to have a list of platforms where
> SLAD-2 1.0 will likely run (Distribution names and version,
> perhaps Kernel versions).

Due to static linking only two limitations are left.

1. The resulting ABI. If compiled e.g. on a current Gentoo Linux with
NPTL only support, it will only run on Kernel 2.6.5+/2.6.6+ (Linux ABI).
This can be checked with the "file" utility, e.g.
[~]> file /opt/slad/bin/sladd
/opt/slad/bin/sladd: setuid ELF 64-bit LSB executable, AMD x86-64,
version 1 (SYSV), for GNU/Linux 2.6.6, statically linked, for GNU/Linux
2.6.6, not stripped
indicates a minimal kernel version of 2.6.6. This limitation is imposed
by the toolchain, not SLAD itself, as threads are not used. Building on
as old a distribution as possible, e.g. Debian Stale, would broaden the
range of usable distributions. A reasonable assumption should be Kernel
2.4. Debian Sarge (3.1) e.g. is build for ABI 2.2.0, allowing even older
kernels.

2. The more difficult limitation is a result from the setuid/setgid
functions. As we do not use numeric uid/gid, we use getpwnam() and
getgrnam() to get the numeric values. This yields while compiling:
process.c:268: warning: Using 'getgrnam' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
rocess.c:266: warning: Using 'getpwnam' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
A small test has shown that a missing dynamic libc makes these calls
fail, which is a handled case. The result is that the started plugins
runs at uid/gid 0/0. Having the sladd run with a different glibc version
than it is build against may create problems, though. Still the
functions inside the dynamic libc are versioned and have not changed, so
I expect the same behaviour with an incompatible glibc version:

objdump -T /lib32/libc.so.6 | grep getgrnam
00087120 g    DF .text  000001b0  GLIBC_2.1.2 getgrnam_r
000f1b50 g    DF .text  00000058 (GLIBC_2.0)  getgrnam_r
00086910 g    DF .text  0000011c  GLIBC_2.0   getgrnam

for a 32bit glibc up to 2.3.6, which is the current version.

It seems safe to assume glibc 2.1.2 as the minimum level required,
though the release of 2.3 has been in 2002, and 2.3.4 (e.g. Debian
Sarge) is from January 2005.

All distributions which meet these requirements (kernel 2.2 or higher,
glibc 2.1.2 or higher) should work, kernel 2.4 and glibc 2.3.4 or higher
should be safe assumptions for a sladd build on Debian Sarge. Please
bear in mind that this discussion only is about the sladd executable and
doesn't necessarrily mean all plugins will work. These would have to be
tested separately.

Fast testing shows that the system Lukas chose for building sets the ABI
to 2.4.1, requireing this minimum kernel for the plugins. Additional
requirements may arise from scripted plugins, such as
perl/bash/python/whatever versions.

Regards,
Christian

> Does it already exist?
> If not, can you quickly hack up a list where chances
> are good that SLAD runs on?
> 
> Thanks
> 	Jan



-- 
Gruss
    Lukas Grunwald aka REG lg1
    
 http://www.dn-systems.de  mail: l.grunwald at dn-systems.de 
 DN-Systems Enterprise Internet Solutions GmbH
 Hornemannstr. 11 31137 Hildesheim, Germany     
 Tel. +49-5121-28989-0 Fax. +49-5121-28989-11 
 1110 Laguna Ave #4, Burlingame, CA 94010, USA
 Tel. +1-650-472-3194 Mob. +1-650-200-7889
 Handelsregister HRB-3213 Amtsgericht Hildesheim
 Geschäftsführer Lukas Grunwald