Linux, LDAP and the impossibility of handling editable PDFs

[Konrad Heuer]

On Mon, 1 Sep 2008, O. Hartmann wrote:

> Konrad Heuer wrote:
>> 
>> On Mon, 1 Sep 2008, O. Hartmann wrote:
>> 
>>> Several months ago I tried configuring the Linuxulator on several FreeBSD 
>>> 7.X boxes, most of them pure amd64 and pure 64 bit (as it is possible with 
>>> Intels pseudo 64 bit crap). The reason for that is simple. Having FreeBSD 
>>> (now 7.1-PRE) as my favorite OS on servers AND hybrid boxes (acting as 
>>> workstations AND small servers) makes life easy - I thought and was touhgt 
>>> wrong.
>>> Our administration sends a lot of PDFs around and as it is very usual, our 
>>> applications, forms and so on for scientific congresses etc. are all PDF 
>>> and subject to be edited. And here it comes that FreeBSD seems to be a 
>>> definite deadend!
>>> Using pdfedit is wrong, it can't show or edit any PDF we obtained so far. 
>>> Using 'pdftk' fails, it is not made to run in modern 64 bit environments 
>>> only when using FreeBSD (linux seems to have no problem, especially Ubuntu 
>>> does the thing). So, then I remembered myself about Linuxulator and tried 
>>> acrobatviewer - and failed. As in other professional environments we were 
>>> far away from using simple user management and therefore there is a LDAP 
>>> environment. And, funny, Linuxulator does not contact LDAP even if  I try 
>>> to configure it to use our LDAP environment. Digging around what flavor of 
>>> Linux FreeBSD installs (means: do al ot of work), reading about how to use 
>>> PAM and LDAP on Linux (means: doing again additional work in an 
>>> environment I try to avoid!) and at last no success, because something is 
>>> missing or the Linuxulator should use something for user authentication 
>>> and autorization it does not have and uses therefore the FreeBSD stuff and 
>>> then fails. Especially for the Acrobat weirdness (or call it software) 
>>> something like this occurs whenn attempting starting acrobat reader:
>>> 
>>> (acroread:18831): GLib-WARNING **: getpwuid_r(): failed due to unknown 
>>> user id (2001)
>>> 
>>> (acroread:18831): Gdk-WARNING **: shmget failed: error 12 (Cannot allocate 
>>> memory)
>>> 
>>> 
>>> If there is someone here running a 64 bit environment within a LDAP realm 
>>> and already got successfully running the Linux add ons as expected for 
>>> LDAP users, you are really welcome to give me some hints how to turn 
>>> around my frustration and thoughts about definitely leaving the FreeBSD 
>>> path ...
>> 
>> I use a simple workaround to make the Adobe reader (and some other Linux 
>> binaries) work - I simply added following entries to the crontab file of 
>> root:
>> 
>> 00 05  *  *  * /usr/bin/getent passwd | /usr/bin/sed '1,/nobody/d' > 
>> /usr/compat/linux/etc/passwd 2> /dev/null
>> 15 05  *  *  * /usr/bin/getent group > /usr/compat/linux/etc/group 2> 
>> /dev/null
>> 
>> Hope that helps a little bit ...
>
> Thank you very much, this works.
> But this seems to be a hack, unclean in my opinion. As I got responses 
> earlier of the year for a similar problem, Linuxulator should utilize lacking 
> facilities from FreeBSD host system - but obviously it doesn't, especially if 
> there are non-existent users. As I realized - and this puzzles me - there was 
> no passwd file in my configuration, so I guess the Linuxulator has to contact 
> the underlying FreeBSD infrastructure to get UIDs like root and others - but 
> this seems not to be the case.

I agree a little bit. When we used YP years ago it was possible to edit 
/usr/compat/linux/etc/yp.conf to make the Linux binaries contact the NIS 
service.

Making use of LDAP should work in an similar way. Of course my "solution" 
is a hack - but not the worst one. ;-)

Best regards

Konrad Heuer
GWDG, Am Fassberg, 37077 Goettingen, Germany, kheuer2 at gwdg.de