SuSe 10.1 and filePro 5.0.14D4

[Brian K. White]

----- Original Message ----- 
From: "Nancy Palmquist" <nlp at vss3.com>
To: "Kenneth Brody" <kenbrody at bestweb.net>
Cc: "filePro List" <filepro-list at lists.celestial.com>
Sent: Tuesday, July 18, 2006 2:58 PM
Subject: Re: SuSe 10.1 and filePro 5.0.14D4


> Kenneth Brody wrote:
>> Quoting Fairlight (Tue, 18 Jul 2006 13:06:39 -0400):
>>
>>
>>>This public service announcement was brought to you by Kenneth Brody:
>>>
>>>>The script has been fixed since the 5.0.14 release.  (Can someone
>>>>please verify that the latest 5.6 has the fix in it?)
>>>
>>>No offense, but you're lead developer the company releasing it and can't
>>>tell?
>>
>>
>> Okay, so I took the lazy way out.  :-)
>>
>> The Linux masters are made at a different office, by a different
>> person, on a system I don't normally access.  Yes, I could have
>> asked him directly, but I was already typing my reply to Nancy.
>>
>>
>>>>The problem is that chown will reset the setuid bit.  This is for
>>>>security reasons, to prevent the setuid bit from applying to the
>>>>new uid, and is probably documented on the chown man page.
>>>
>>>There's another reason it could possibly fail.  Could be installing to
>>>an NFS partition with nosuid set.  Not as likely, but still possible.
>>
>>
>> According to the documentation on chown (the program, not the system
>> call), the behavior depends on how the O/S handles the system call,
>> as it is not a behavior that is built in to the chown program itself.
>>
>> And does the nosuid flag mean that the setuid bit cannot be set, or
>> does it mean that it is to be ignored?
>>
>
> I verified the behavior of chown on SuSe Linux 10.1. It will unset the 
> suid bit.  All I did to fix it was swap and chown /chmod commands so the 
> chown always happened first.
>
> Then all worked great.  In fact, I only found 2 I had to change, I think.
>
> No it is not writing to a NFS file structure.  Just a normal installation. 
> Trying to test an install on my new SuSe 10.1 started me down this road.
>
> I still have no good solution for the graphic display.  If I use windows 
> to telnet to the SuSe the graphics in filePro are just fine.  If I use 
> SCOUnix to telnet, I get the strange graphics.  (Anzio worked fine also.)
>
> The LANG is set to English.  UTF-8 encoding is unchecked.
>
> Telnet from windows, TERM defaults to ansi.
>
> telnet from SCO Unix, TERM defaults to scoansi.  This will not work, even 
> if I change it to ansi, xterm, scoansi-new.
>
> Tried them all.
>
> I can use this and telnet from Windows when it bugs me too much.
>
> I tried the SuSe console to see what was displayed there.
>
> TERM=linux.  The graphics are all invisible except the vertical with the 
> right line (key 4 in filePro graphics).
>
> It sure looks weird.  I tried different termcaps provided with filepro 
> Linux stuff (5.0), but something is not good.

We have approximately 300 or so users using scoansi emulation (using 
Facetwin) on two different SUSE 10.0 boxes with no emulation problems.
I just tried from a real sco console and I see the graphics characters are 
not right but otherwise the terminal is fully and correctly functional.
Colors are right, F-keys and arrow/page/end/home keys work etc...
I backed out of the telnet and ran "mapchan -n" on sco, and telnetted back 
in to linux and then everything was perfect.

Personally I just don't bother with the consoles any more.
It would be nice if everything worked perfect everywhere, but really it's 
not worth the time to deal with odd cases like this and reconcile them 
without breaking the terminal emulators.

In the case of telnetting across disparate platforms, it's like the doctors 
advice "don't do that".
That is, do not expect terminal emulation to be any good when you do that.
Use terminal emulators configured to emulate the native console of the 
target box,
or stay within the same platform any time the emulation matters.

Otherwise, become a lot more knowledgeable about terminal operation in 
general so you can fix it up and make it work on the spot every time you 
connect anywhere.

For example, that mapchan -n fix above was not a simple "do that and it'll 
fix yours too" thing. It may. But really it was only correct for me in this 
case, because:
* the "scoansi" entry in the fp/termcap on the remote linux box is designed 
to expect 8 bit data and assumes the terminal is using a CP437 character set
* my telnet client & server handle 8-bit data
* the sco console understands 8-bit data
* the remote linux box has unicode disabled
* LANG=en_US or C (it's en_US in this case)
* in yast I told the LANG setting to apply to root also
* the native character set on the sco box (the result of "mapchan -n") is 
CP437
* surely I forget at least a thing or two more that could possibly affect 
this...

It may fix you too though because many of your details do just happen to be 
the same in this case, since I have specifically suse 10.0 and filepro and 
sco open server.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!