Save 
Join IIUG
 for   
 

Informix News
18 Nov 13 - ZDNet - Top 20 mobile skills in demand... Read
09 Sep 13 - telecompaper - Shaspa and Tatung have shown a new smart home platform at Ifa in Berlin. Powered by the IBM Informix software... Read
06 Sep 13 - IBM data magazine - Mission Accomplished - Miami, Florida will be the backdrop for the 2014 IIUG Informix Conference... Read
01 Feb 13 - IBM Data Magazine - Are your database backups safe? Lester Knutsen (IBM Champion) writes about database back up safety using "archecker"... Read
14 Nov 12 - IBM - IBM's Big Data For Smart Grid Goes Live In Texas... Read
3 Oct 12 - The Financial - IBM and TransWorks Collaborate to Help Louisiana-Pacific Corporation Achieve Supply Chain Efficiency... Read
28 Aug 12 - techCLOUD9 - Splunk kicks up a SaaS Storm... Read
10 Aug 12 - businessCLOUD9 - Is this the other half of Cloud monitoring?... Read
3 Aug 12 - IBM data management - Supercharging the data warehouse while keeping costs down IBM Informix Warehouse Accelerator (IWA) delivers superior performance for in-memory analytics processing... Read
2 Aug 12 - channelbiz - Oninit Group launches Pay Per Pulse cloud-based service... Read
28 May 12 - Bloor - David Norfolk on the recent Informix benchmark "pretty impressive results"... Read
23 May 12 - DBTA - Informix Genero: A Way to Modernize Informix 4GL Applications... Read
9 Apr 12 - Mastering Data Management - Upping the Informix Ante: Advanced Data Tools... Read
22 Mar 12 - developerWorks - Optimizing Informix database access... Read
14 Mar 12 - BernieSpang.com - International Informix User Group set to meet in San Diego... Read
1 Mar 12 - IBM Data Management - IIUG Heads West for 2012 - Get ready for sun and sand in San Diego... Read
1 Mar 12 - IBM Data Management - Running Informix on Solid-State Drives.Speed Up Database Access... Read
26 Feb 12 - BernieSpan.com - Better results, lower cost for a broad set of new IBM clients and partners... Read
24 Feb 12 - developerWorks - Informix Warehouse Accelerator: Continuous Acceleration during Data Refresh... Read
6 Feb 12 - PRLOG - Informix port delivers unlimited database scalability for popular SaaS application ... Read
2 Feb 12 - developerWorks - Loading data with the IBM Informix TimeSeries Plug-in for Data Studio... Read
1 Feb 12 - developerWorks - 100 Tech Tips, #47: Log-in to Fix Central... Read
13 Jan 12 - MC Press online - Informix Dynamic Server Entices New Users with Free Production Edition ... Read
11 Jan 12 - Computerworld - Ecologic Analytics and Landis+Gyr -- Suitors Decide to Tie the Knot... Read
9 Jan 12 - planetIDS.com - DNS impact on Informix / Impacto do DNS no Informix... Read
8 Sep 11 - TMCnet.com - IBM Offers Database Solution to Enable Smart Meter Data Capture... Read
1 Aug 11 - IBM Data Management Magazine - IIUG user view: Happy 10th anniversary to IBM and Informix... Read
8 Jul 11 - Database Trends and Applications - Managing Time Series Data with Informix... Read
31 May 11 - Smart Grid - The meter data management pitfall utilities are overlooking... Read
27 May 11 - IBM Data Management Magazine - IIUG user view: Big data, big time ( Series data, warehouse acceleration, and 4GLs )... Read
16 May 11 - Business Wire - HiT Software Announces DBMoto for Enterprise Integration, Adds Informix. Log-based Change Data Capture... Read
21 Mar 11 - Yahoo! Finance - IBM and Cable&Wireless Worldwide Announce UK Smart Energy Cloud... Read
14 Mar 11 - MarketWatch - Fuzzy Logix and IBM Unveil In-Database Analytics for IBM Informix... Read
11 Mar 11 - InvestorPlace - It's Time to Give IBM Props: How many tech stocks are up 53% since the dot-com boom?... Read
9 Mar 11 - DBTA - Database Administration and the Goal of Diminishing Downtime... Read
2 Feb 11 - DBTAs - Informix 11.7 Flexible Grid Provides a Different Way of Looking at Database Servers... Read
27 Jan 11 - exactsolutions - Exact to Add Informix Support to Database Replay, SQL Monitoring Solutions... Read
25 Jan 11 - PR Newswire - Bank of China in the UK Works With IBM to Become a Smarter, Greener Bank... Read
12 Oct 10 - Database Trends and Applications - Informix 11.7: The Beginning of the Next Decade of IBM Informix... Read
20 Sep 10 - planetIDS.com - ITG analyst paper: Cost/Benefit case for IBM Informix as compared to Microsoft SQL Server... Read
20 Jul 10 - IBM Announcements - IBM Informix Choice Edition V11.50 helps deploy low-cost scalable and reliable solutions for Apple Macintosh and Microsoft Windows... Read
20 Jul 10 - IBM Announcements - Software withdrawal: Elite Support for Informix Ultimate-C Edition... Read
24 May 10 - eWeek Europe - IBM Supplies Database Tech For EU Smart Grid... Read
23 May 10 - SiliconIndia - IBM's smart metering system allows wise use of energy... Read
21 May 10 - CNET - IBM to help people monitor energy use... Read
20 May 10 - ebiz - IBM Teams With Hildebrand To Bring Smart Metering To Homes Across Britain... Read
19 May 10 - The New Blog Times - Misurare il consumo energetico: DEHEMS è pronto... Read
19 May 10 - ZDNet - IBM software in your home? Pact enables five-city smart meter pilot in Europe... Read
17 March 10 - ZDNet (blog) David Morgenstern - TCO: New research finds Macs in the enterprise easier, cheaper to manage than... Read
17 March 2010 - Virtualization Review - ...key components of Big Blue's platform to the commercial cloud such as its WebSphere suite of application ser vers and its DB2 and Informix databases... Read
10 February 2010 - The Wall Street Journal - International Business Machines is expanding an initiative to win over students and professors on its products. How do they lure the college crowd?... Read


End of Support Dates

IIUG on Facebook IIUG on Twitter

RSS Feed: IIUG Forum: Open Admin Tool

More IIUG RSS Feeds

Classics is a forum to discuss all aspects of Informix classic tools including Standard Engine (SE), Online 5, 4GL, D4GL, ESQL, ISQL and others.


URL: http://www.iiug.org/rss/classics.rss

Below is the latest content available from this feed:

PYTHON 3.2 AND ABOVE INTERFACE WITH INFORMIX -....
Posted by: munirspn@yahoo.com (Munir Abdul....) - Wed, 02 May 2018 22:34:59 EDT
sir,



It would be my pleasure to get the information of Python and Informix Database

Interface / requirement for do Data Analytics on Repository available.



Thanks in anticipation



Regards



Munir Abdul AnsariJoint Director(IT)

Government of India, Ministry of Home

AffairsE-mail:munirspn@yahoo.com(Personal)









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4765]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: david@smooth1.co.uk (david@smooth1.co.uk) - Thu, 19 Apr 2018 14:53:37 EDT
The contents of /proc/self/loginuid IS inherited by child processes, that is

the idea with login id.



The setuid program needs to launch the ESQL/C program, not the shell script.



Currently you have:



shell-->setuid launcher



+->ESQL/C program



what you need is



shell->setuid launcher->ESQL/C program.



A little setuid C progam with an exec at the end...over to Fernando!



Regards,

David.



> On 19 April 2018 at 18:17 RICHARD SPITZ <richard.spitz@med.uni-muenchen.de>

wrote:

>

>

> > In the meantime, I'm thinking about a crude workaround: A little

> > setuid program that reads /proc/self/loginuid. When that yields

> > "4294967295" (= -1), it will write the result of getuid() into

> > that file. When I include that into the shell script just before

> > the ESQL/C program is executed, I hope the loginuid will be inherited

>

> This was, of course, a silly idea. Changing the content of

/proc/self/loginuid

> does not have any effect on child processes.

>

> Looks like i'm stuck here. I'd have to write a pam-enabled program launcher

> that can be configured to use pam_loginuid.so to set the value of

> /proc/self/loginuid, but that's beyond my capability.

>

>

>



>

>









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4764]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Thu, 19 Apr 2018 13:17:54 EDT
> In the meantime, I'm thinking about a crude workaround: A little

> setuid program that reads /proc/self/loginuid. When that yields

> "4294967295" (= -1), it will write the result of getuid() into

> that file. When I include that into the shell script just before

> the ESQL/C program is executed, I hope the loginuid will be inherited



This was, of course, a silly idea. Changing the content of /proc/self/loginuid

does not have any effect on child processes.



Looks like i'm stuck here. I'd have to write a pam-enabled program launcher

that can be configured to use pam_loginuid.so to set the value of

/proc/self/loginuid, but that's beyond my capability.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4763]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Thu, 19 Apr 2018 10:21:11 EDT
Good news. The issue has many formal implications....

The idea behind /proc/self/loginuid is to track the original (really

authenticated user) who launched the program.

Eventually in this scenario if everything was perfect, it would be

"informix". But if it contained that, ESQL/C would think the home of the

user would be ~informix. (it's looking for the informix.rc and other

connectivity files....)

That would be very wrong.



This is actually a very interesting topic.... very little to do with

Informix though :)

Some products like Guardium Data Encryption or IBM Multi-Cloud Data

Encryption which encrypt data and only decrypt it for authorized users have

to handle this same issue to prevent root from impersonating (su) the users

and thereby access the encrypted data. They do that with kernel modules

that somehow (among many other things) track the creation of processes to

understand the real user identity...



Regards and good luck.



On Thu, Apr 19, 2018 at 2:32 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> Fernando,

>

> you're spot on! I used gdb to trace what's going on around the opening of

> /proc/self/loginuid, here is the result:

>

> #0 0x00007ffff7bced10 in read () from /lib64/libpthread.so.0

> #1 0x00007ffff6cc8b8a in ?? () from /lib64/libnss_sss.so.2

> #2 0x00007ffff6cc9215 in ?? () from /lib64/libnss_sss.so.2

> #3 0x00007ffff6cc9437 in ?? () from /lib64/libnss_sss.so.2

> #4 0x00007ffff6cca0ec in _nss_sss_getpwuid_r () from

> /lib64/libnss_sss.so.2

> #5 0x00007ffff719b4dc in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6

> #6 0x00007ffff71fde98 in __getlogin_r_loginuid () from /lib64/libc.so.6

> #7 0x00007ffff71fdb95 in getlogin () from /lib64/libc.so.6

> #8 0x0000000000465389 in ifx_getlogin ()

> #9 0x00000000004657ab in ggethomepath ()

> #10 0x0000000000464528 in greadenv ()

> #11 0x00000000004647c3 in init_getenv ()

> #12 0x000000000046480f in idx_ggetenv ()

> #13 0x000000000046d50f in _sqdbgsetup ()

> #14 0x00000000004686e3 in ostcb_alloc ()

> #15 0x000000000046871a in CheckOsInit ()

> #16 0x000000000046879c in getoserr ()

> #17 0x000000000040743a in CheckGlobInit ()

> #18 0x00000000004049e7 in sqli_db_open ()

> #19 0x0000000000403b09 in main ()

>

> Just as I was about to start writing my own getlogin() test program, I

> read

> your last post and used your code instead. BTW, I had to add "exit (0)" as

> last line to make it run with SPL "SYSTEM". The first calls to my test SPL

> ran

> very fast (maybe some kind of caching involved), but then I increased the

> debuglevel and could exactly reproduce the delay:

>

> Track before

> Track after

> Time before is: 2018:04:19 13:53:44.448

> Time After is: 2018:04:19 13:53:50.488

> Login is: (null)

>

> Will try to open a support case with SuSE. In the meantime, I'm thinking

> about

> a crude workaround: A little setuid program that reads

> /proc/self/loginuid.

> When that yields "4294967295" (= -1), it will write the result of getuid()

> into that file. When I include that into the shell script just before the

> ESQL/C program is executed, I hope the loginuid will be inherited and my

> problem will be solved for the time being. Will keep you informed.

>

> Thanks again, you were VERY helpful indeed!

>

> Regards, Richard

>

> Thank you very much

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4762]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Thu, 19 Apr 2018 08:32:49 EDT
Fernando,



you're spot on! I used gdb to trace what's going on around the opening of

/proc/self/loginuid, here is the result:



#0 0x00007ffff7bced10 in read () from /lib64/libpthread.so.0

#1 0x00007ffff6cc8b8a in ?? () from /lib64/libnss_sss.so.2

#2 0x00007ffff6cc9215 in ?? () from /lib64/libnss_sss.so.2

#3 0x00007ffff6cc9437 in ?? () from /lib64/libnss_sss.so.2

#4 0x00007ffff6cca0ec in _nss_sss_getpwuid_r () from /lib64/libnss_sss.so.2

#5 0x00007ffff719b4dc in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6

#6 0x00007ffff71fde98 in __getlogin_r_loginuid () from /lib64/libc.so.6

#7 0x00007ffff71fdb95 in getlogin () from /lib64/libc.so.6

#8 0x0000000000465389 in ifx_getlogin ()

#9 0x00000000004657ab in ggethomepath ()

#10 0x0000000000464528 in greadenv ()

#11 0x00000000004647c3 in init_getenv ()

#12 0x000000000046480f in idx_ggetenv ()

#13 0x000000000046d50f in _sqdbgsetup ()

#14 0x00000000004686e3 in ostcb_alloc ()

#15 0x000000000046871a in CheckOsInit ()

#16 0x000000000046879c in getoserr ()

#17 0x000000000040743a in CheckGlobInit ()

#18 0x00000000004049e7 in sqli_db_open ()

#19 0x0000000000403b09 in main ()



Just as I was about to start writing my own getlogin() test program, I read

your last post and used your code instead. BTW, I had to add "exit (0)" as

last line to make it run with SPL "SYSTEM". The first calls to my test SPL ran

very fast (maybe some kind of caching involved), but then I increased the

debuglevel and could exactly reproduce the delay:



Track before

Track after

Time before is: 2018:04:19 13:53:44.448

Time After is: 2018:04:19 13:53:50.488

Login is: (null)



Will try to open a support case with SuSE. In the meantime, I'm thinking about

a crude workaround: A little setuid program that reads /proc/self/loginuid.

When that yields "4294967295" (= -1), it will write the result of getuid()

into that file. When I include that into the shell script just before the

ESQL/C program is executed, I hope the loginuid will be inherited and my

problem will be solved for the time being. Will keep you informed.



Thanks again, you were VERY helpful indeed!



Regards, Richard



Thank you very much









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4761]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 18:47:48 EDT
Please replace my previus test case with this one:



#include <unistd.h>

#include <time.h>

#include <stdio.h>

#include <sys/types.h>

#include <math.h>



int main()

{



char buffer[26];



int millisec;



struct tm* tm_info;



struct timeval tv_a, tv_b;



gettimeofday(&tv_b, NULL);



printf("Track before\n");



char *mylogin = getlogin();



printf("Track after\n");



gettimeofday(&tv_a, NULL);



millisec = lrint(tv_b.tv_usec/1000.0); // Round to nearest millisec



if (millisec>=1000) {



//Allow for rounding up to nearest second



millisec -=1000;



tv_b.tv_sec++;



}



tm_info = localtime(&tv_b.tv_sec);



strftime(buffer, 26, "%Y:%m:%d %H:%M:%S", tm_info);



printf("Time before is: %s.%03d\n", buffer, millisec);



millisec = lrint(tv_a.tv_usec/1000.0); // Round to nearest millisec



if (millisec>=1000) {



//Allow for rounding up to nearest second



millisec -=1000;



tv_a.tv_sec++;



}



tm_info = localtime(&tv_a.tv_sec);



strftime(buffer, 26, "%Y:%m:%d %H:%M:%S", tm_info);



printf("Time After is: %s.%03d\n", buffer, millisec);



printf("Login is: %s\n",mylogin);

}



I expect it to work fast on a logged in SHELL and slow on a daemon launched

process.

The problem is probably inside the "getlogin()" POSIX function.

I believe Informix calls getlogin while trying to get the home of the user.



You should try to understand why your system takes time to run getlogin(),

either with your OS provider or with your AD integration software provider

(if different from the OS).

To me it doen't sound good idea to get data from a "-1" user id.



I think if there is no data in /proc/self/logiuid then it should

immediately return NULL (no user associated with a terminal login):



man getlogin:



DESCRIPTION



getlogin() returns a pointer to a string containing the name of

the user logged in on the controlling terminal of the process, or a NULL

pointer if this information cannot be deterÔÇÉ



mined. The string is statically allocated and might be overwritten

on subsequent calls to this function or to cuserid().



Regards.



On Wed, Apr 18, 2018 at 6:33 PM, Fernando Nunes <domusonline@gmail.com>

wrote:



> On Wed, Apr 18, 2018 at 6:17 PM, RICHARD SPITZ <

> richard.spitz@med.uni-muenchen.de> wrote:

>

> > Fernando,

> >

> > thank you very much for your detailed response. I had written a comment

> in

> > your blog article because that had been the most profound and helpful

> info

> > I

> > had found about configuring IDS with PAM support.

> >

> > > ESQL/C will most probably (that's what I'd like to test/debug) need

> > > to get the user ID *before* trying to connect to IDS. And that's

> > > where it's taking time.

> >

> > Exactly. I think I had written before in this thread that the delay

> occurs

> > before the database connection is established. What's puzzling me is the

> > way

> > ESQL/C does this: First it goes through all the "pain" of reading

> > /proc/self/loginuid and trying to verify that uid via the mechanisms

> > defined

> > in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and

> > causes

> > the delay), and then it uses getuid() anyway to continue happily

> > everafter.

> >

> > > That probably means that the LDAP integration software you're

> > > using "hijacks" some internal functions/libraries...

> >

> > Well, I'm using a perfectly standard and well documented mechanism for

> > that:

> > sssd. This is nothing fancy and is integrated into current versions of

> > GLIBC,

> > that is also why PAM is not even needed to connect to IDS as an LDAP

> user.

> >

> > > When you say "interactive" may I assume you opened an SSH/telnet

> > > to the server using the user name of the user? Or have you done an

> > su/sudo?

> >

> > Interactive means that I am in a normal user shell (opened via

> SSH/PuTTY)

> > on

> > the Linux machine Hosting IDS and executing the shell script that is

> > normally

> > invoked by the SPL.

> >

> > > Assuming you did that directly the login process is going through

> > > the authentication and creates the "session context" that makes the

> > > calls run fast

> >

> > The login process sets /proc/self/loginuid for the shell, which is

> > inherited

> > by the program or shell script I'm starting.

> >

> > > This is not being set when a daemon (Informix) changes a process

> > > identity which is what the SYSTEM SPL instruction triggers.

> >

> > Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so

> is

> > designed to set /proc/self/loginuid. That (pseudo) file is writable only

> > for

> > root, otherwise it would be trivial to write the correct uid to it but

> of

> > course a huge security issue.

> >

> > > 1- Understand why the process takes time after trying to get that

> > > info from the file. Is it calling a daemon for cache, talking to

> > > the LDAP server, etc?. And how can that time be reduced?

> >

> > As written before, the problem is that ESQL/C is trying the UID of "-1"

> > (read

> > from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

> > unsuccessful. That UID can not be found in any local cache, that's why a

> > query

> > to the AD servers is done which is of course also unsuccessful. All of

> > this

> > takes time, a query with a correct UID takes only milliseconds.

> >

> > > 2- Check the use of the pam_loginuid in your system.

> >

> > That's what I've been doing all along. Is there a mechanism to make IDS

> > (and

> > other "daemons", like Apache) use that module when invoking subshells or

> > processes?

> >

> > > I suppose the delay is also noticeable when you do the login.

> >

> > No, a valid user login works instantly, no noticeable delay.

> >

> > > 1- Can you change the ESQL/C to CONNECT with a specific user?

> > > Maybe in that case it doesn't need to get the UID?

> >

> > Tried both implicit and explicit connections, no difference in

> behaviour.

> >

> > > 2- You probably can reproduce this by scheduling the process in the

> > > crontab.

> >

> > crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is

> > set

> > to the correct UID. I already verified that by scheduling the ESQL/C

> > program

> > in cron.

> >

> > > 3- On many ocassions this weird delays are caused by issues in reverse

> > > lookups (IP to names).

> >

> > No problem there, I can assure you.

> >

> > > I honestly don't know (strace should help) what ESQL/C calls when it

> > > starts....

> >

> > I can send you a complete strace output, but I already mentioned the

> > relevant

> > parts in this thread.

> >

> > > I'm sure Jonathan Leffler would be able to provide some more

> > > info on this, but I haven't seen him here for a while.

> >

> > Honestly, I had hoped that he might read this...

> >

> > > Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> > > That's a consequence on a system call and your system

> configuration....

> >

> > Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

> > program itself reads /proc/self/loginuid, and that ONLY happens if the

> > program

> > establishes a database connection somewhere later in the program. I

> wrote

> > a

> > dummy ESQL/C program that doesn't open a database connection, and this

> > dummy

> > program doesn't read /proc/self/loginuid and does no user verification

> at

> > all.

> >

> > Regards, Richard

> >

> >

> No. I understand you got that from strace. And I didn't mean that the

> ESQL/C process does not read the file.

> What I mean is that ESQL/C only calls "standard" POSIX functions. And this

> functions in your system (Linux + kernel version + configuration +

> whatever) trigger those operations.

> We would need to understand what call triggers that and if there's a way

> to

> workaround it.

> I thought, apprently wrongly, that it was the call to getuid which I

> confirmed happens on an ESQL/C process. That's why I sent you a test case

> with that call.

> A possible way to try to find that would be to run the ESQL/C program in a

> debugger and set a couple of breakpoints in OS functions close to the

> sequence where it has delays.

> When the program stops and returns control to the debugger try to run a

> "where" and see what's in there. An example with getuid():

>

> castelo@stardust.onlinedomus.net:informix-> gdb ./test.exe

> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1

> Copyright (C) 2013 Free Software Foundation, Inc.

> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.

> html

> >

> This is free software: you are free to change and redistribute it.

> There is NO WARRANTY, to the extent permitted by law. Type "show copying"

> and "show warranty" for details.

> This GDB was configured as "x86_64-redhat-linux-gnu".

> For bug reporting instructions, please see:

> <http://www.gnu.org/software/gdb/bugs/>...

> Reading symbols from /tmp/test.exe...(no debugging symbols found)...done.

> (gdb) break getuid

> Function "getuid" not defined.

> Make breakpoint pending on future shared library load? (y or [n]) y

> Breakpoint 1 (getuid) pending.

> (gdb) run

> Starting program: /tmp/./test.exe

> [Thread debugging using libthread_db enabled]

> Using host libthread_db library "/lib64/libthread_db.so.1".

>

> Breakpoint 1, 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> Missing separate debuginfos, use: debuginfo-install

> glibc-2.17-196.el7_4.2.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64

> (gdb) where

> #0 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> #1 0x00007ffff79597e7 in cmInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #2 0x00007ffff7950ddf in asfInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #3 0x00007ffff795196b in ASF_Call () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #4 0x00007ffff7b99a88 in asf_init () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #5 0x00007ffff7b9ce0d in sqli_connect_open () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #6 0x0000000000400916 in main ()

> (gdb)

>

> In this case the "CONNECT/DATABASE" statement triggers several calls in

> the

> Informix LIBS and then we jump into the getuid().

> You may need to go over several attempts if you can only set the

> breakpoint

> to common functions like "open()"...

>

> Once we find the POSIX function which is causing the sequence that causes

> the delays we may have a shot of reconfigure something to solve it.

> getuid() for example is necessary to get the user id under which we

> run....

>

> Regards.

>

> >

> >

>



>

> >

> >

> >

> >

>

> --

> Fernando Nunes

> Portugal

>

> http://informix-technology.blogspot.com

> My email works... but I don't check it frequently...

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4760]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: david@smooth1.co.uk (david@smooth1.co.uk) - Wed, 18 Apr 2018 14:52:51 EDT
Use dtrace to get the stack for open() calls, optionally when the filename is

the loginuid file.



ALso get the stack for getuid calls.



https://www.joyent.com/blog/bruning-questions-debugging



Regards,

David.



> On 18 April 2018 at 17:33 Fernando Nunes <domusonline@gmail.com> wrote:

>

>

> On Wed, Apr 18, 2018 at 6:17 PM, RICHARD SPITZ <

> richard.spitz@med.uni-muenchen.de> wrote:

>

> > Fernando,

> >

> > thank you very much for your detailed response. I had written a comment in

> > your blog article because that had been the most profound and helpful info

> > I

> > had found about configuring IDS with PAM support.

> >

> > > ESQL/C will most probably (that's what I'd like to test/debug) need

> > > to get the user ID *before* trying to connect to IDS. And that's

> > > where it's taking time.

> >

> > Exactly. I think I had written before in this thread that the delay occurs

> > before the database connection is established. What's puzzling me is the

> > way

> > ESQL/C does this: First it goes through all the "pain" of reading

> > /proc/self/loginuid and trying to verify that uid via the mechanisms

> > defined

> > in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and

> > causes

> > the delay), and then it uses getuid() anyway to continue happily

> > everafter.

> >

> > > That probably means that the LDAP integration software you're

> > > using "hijacks" some internal functions/libraries...

> >

> > Well, I'm using a perfectly standard and well documented mechanism for

> > that:

> > sssd. This is nothing fancy and is integrated into current versions of

> > GLIBC,

> > that is also why PAM is not even needed to connect to IDS as an LDAP user.

> >

> > > When you say "interactive" may I assume you opened an SSH/telnet

> > > to the server using the user name of the user? Or have you done an

> > su/sudo?

> >

> > Interactive means that I am in a normal user shell (opened via SSH/PuTTY)

> > on

> > the Linux machine Hosting IDS and executing the shell script that is

> > normally

> > invoked by the SPL.

> >

> > > Assuming you did that directly the login process is going through

> > > the authentication and creates the "session context" that makes the

> > > calls run fast

> >

> > The login process sets /proc/self/loginuid for the shell, which is

> > inherited

> > by the program or shell script I'm starting.

> >

> > > This is not being set when a daemon (Informix) changes a process

> > > identity which is what the SYSTEM SPL instruction triggers.

> >

> > Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so is

> > designed to set /proc/self/loginuid. That (pseudo) file is writable only

> > for

> > root, otherwise it would be trivial to write the correct uid to it but of

> > course a huge security issue.

> >

> > > 1- Understand why the process takes time after trying to get that

> > > info from the file. Is it calling a daemon for cache, talking to

> > > the LDAP server, etc?. And how can that time be reduced?

> >

> > As written before, the problem is that ESQL/C is trying the UID of "-1"

> > (read

> > from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

> > unsuccessful. That UID can not be found in any local cache, that's why a

> > query

> > to the AD servers is done which is of course also unsuccessful. All of

> > this

> > takes time, a query with a correct UID takes only milliseconds.

> >

> > > 2- Check the use of the pam_loginuid in your system.

> >

> > That's what I've been doing all along. Is there a mechanism to make IDS

> > (and

> > other "daemons", like Apache) use that module when invoking subshells or

> > processes?

> >

> > > I suppose the delay is also noticeable when you do the login.

> >

> > No, a valid user login works instantly, no noticeable delay.

> >

> > > 1- Can you change the ESQL/C to CONNECT with a specific user?

> > > Maybe in that case it doesn't need to get the UID?

> >

> > Tried both implicit and explicit connections, no difference in behaviour.

> >

> > > 2- You probably can reproduce this by scheduling the process in the

> > > crontab.

> >

> > crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is

> > set

> > to the correct UID. I already verified that by scheduling the ESQL/C

> > program

> > in cron.

> >

> > > 3- On many ocassions this weird delays are caused by issues in reverse

> > > lookups (IP to names).

> >

> > No problem there, I can assure you.

> >

> > > I honestly don't know (strace should help) what ESQL/C calls when it

> > > starts....

> >

> > I can send you a complete strace output, but I already mentioned the

> > relevant

> > parts in this thread.

> >

> > > I'm sure Jonathan Leffler would be able to provide some more

> > > info on this, but I haven't seen him here for a while.

> >

> > Honestly, I had hoped that he might read this...

> >

> > > Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> > > That's a consequence on a system call and your system configuration....

> >

> > Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

> > program itself reads /proc/self/loginuid, and that ONLY happens if the

> > program

> > establishes a database connection somewhere later in the program. I wrote

> > a

> > dummy ESQL/C program that doesn't open a database connection, and this

> > dummy

> > program doesn't read /proc/self/loginuid and does no user verification at

> > all.

> >

> > Regards, Richard

> >

> >

> No. I understand you got that from strace. And I didn't mean that the

> ESQL/C process does not read the file.

> What I mean is that ESQL/C only calls "standard" POSIX functions. And this

> functions in your system (Linux + kernel version + configuration +

> whatever) trigger those operations.

> We would need to understand what call triggers that and if there's a way to

> workaround it.

> I thought, apprently wrongly, that it was the call to getuid which I

> confirmed happens on an ESQL/C process. That's why I sent you a test case

> with that call.

> A possible way to try to find that would be to run the ESQL/C program in a

> debugger and set a couple of breakpoints in OS functions close to the

> sequence where it has delays.

> When the program stops and returns control to the debugger try to run a

> "where" and see what's in there. An example with getuid():

>

> castelo@stardust.onlinedomus.net:informix-> gdb ./test.exe

> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1

> Copyright (C) 2013 Free Software Foundation, Inc.

> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

> >

> This is free software: you are free to change and redistribute it.

> There is NO WARRANTY, to the extent permitted by law. Type "show copying"

> and "show warranty" for details.

> This GDB was configured as "x86_64-redhat-linux-gnu".

> For bug reporting instructions, please see:

> <http://www.gnu.org/software/gdb/bugs/>...

> Reading symbols from /tmp/test.exe...(no debugging symbols found)...done.

> (gdb) break getuid

> Function "getuid" not defined.

> Make breakpoint pending on future shared library load? (y or [n]) y

> Breakpoint 1 (getuid) pending.

> (gdb) run

> Starting program: /tmp/./test.exe

> [Thread debugging using libthread_db enabled]

> Using host libthread_db library "/lib64/libthread_db.so.1".

>

> Breakpoint 1, 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> Missing separate debuginfos, use: debuginfo-install

> glibc-2.17-196.el7_4.2.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64

> (gdb) where

> #0 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> #1 0x00007ffff79597e7 in cmInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #2 0x00007ffff7950ddf in asfInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #3 0x00007ffff795196b in ASF_Call () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #4 0x00007ffff7b99a88 in asf_init () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #5 0x00007ffff7b9ce0d in sqli_connect_open () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #6 0x0000000000400916 in main ()

> (gdb)

>

> In this case the "CONNECT/DATABASE" statement triggers several calls in the

> Informix LIBS and then we jump into the getuid().

> You may need to go over several attempts if you can only set the breakpoint

> to common functions like "open()"...

>

> Once we find the POSIX function which is causing the sequence that causes

> the delays we may have a shot of reconfigure something to solve it.

> getuid() for example is necessary to get the user id under which we run....

>

> Regards.

>

> >

> >

>



> >

> >

> >

> >

>

> --

> Fernando Nunes

> Portugal

>

> http://informix-technology.blogspot.com

> My email works... but I don't check it frequently...

>

>

>



>

>









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4759]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 12:39:21 EDT
Yes. So that clears out any Informix authentication issues or configuration

details (you already mentioned that).

The problem clearly is that when a daemon starts a process nothing in the

system configuration forces the entry in the /proc/self/loginuid. However

when a certain (to be determined) POSIX function is called by the process

the system seems to be "dumb enough" to follow the search process on the

various "stacks" using an invalid (-1/NULL) user id.... ah... the wonders

of free and open systems :)



Regards.



On Wed, Apr 18, 2018 at 6:20 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> To clarify:

>

> The common denominator in both questions (here and on stackoverflow) is an

> ESQL/C program launched by a "daemon". Here the daemon is IDS launching

> the

> program via the SPL "SYSTEM" command, there the daemon is Apache launching

> (another) ESQL/C program via CGI.

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4758]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 12:33:53 EDT
On Wed, Apr 18, 2018 at 6:17 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> Fernando,

>

> thank you very much for your detailed response. I had written a comment in

> your blog article because that had been the most profound and helpful info

> I

> had found about configuring IDS with PAM support.

>

> > ESQL/C will most probably (that's what I'd like to test/debug) need

> > to get the user ID *before* trying to connect to IDS. And that's

> > where it's taking time.

>

> Exactly. I think I had written before in this thread that the delay occurs

> before the database connection is established. What's puzzling me is the

> way

> ESQL/C does this: First it goes through all the "pain" of reading

> /proc/self/loginuid and trying to verify that uid via the mechanisms

> defined

> in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and

> causes

> the delay), and then it uses getuid() anyway to continue happily

> everafter.

>

> > That probably means that the LDAP integration software you're

> > using "hijacks" some internal functions/libraries...

>

> Well, I'm using a perfectly standard and well documented mechanism for

> that:

> sssd. This is nothing fancy and is integrated into current versions of

> GLIBC,

> that is also why PAM is not even needed to connect to IDS as an LDAP user.

>

> > When you say "interactive" may I assume you opened an SSH/telnet

> > to the server using the user name of the user? Or have you done an

> su/sudo?

>

> Interactive means that I am in a normal user shell (opened via SSH/PuTTY)

> on

> the Linux machine Hosting IDS and executing the shell script that is

> normally

> invoked by the SPL.

>

> > Assuming you did that directly the login process is going through

> > the authentication and creates the "session context" that makes the

> > calls run fast

>

> The login process sets /proc/self/loginuid for the shell, which is

> inherited

> by the program or shell script I'm starting.

>

> > This is not being set when a daemon (Informix) changes a process

> > identity which is what the SYSTEM SPL instruction triggers.

>

> Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so is

> designed to set /proc/self/loginuid. That (pseudo) file is writable only

> for

> root, otherwise it would be trivial to write the correct uid to it but of

> course a huge security issue.

>

> > 1- Understand why the process takes time after trying to get that

> > info from the file. Is it calling a daemon for cache, talking to

> > the LDAP server, etc?. And how can that time be reduced?

>

> As written before, the problem is that ESQL/C is trying the UID of "-1"

> (read

> from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

> unsuccessful. That UID can not be found in any local cache, that's why a

> query

> to the AD servers is done which is of course also unsuccessful. All of

> this

> takes time, a query with a correct UID takes only milliseconds.

>

> > 2- Check the use of the pam_loginuid in your system.

>

> That's what I've been doing all along. Is there a mechanism to make IDS

> (and

> other "daemons", like Apache) use that module when invoking subshells or

> processes?

>

> > I suppose the delay is also noticeable when you do the login.

>

> No, a valid user login works instantly, no noticeable delay.

>

> > 1- Can you change the ESQL/C to CONNECT with a specific user?

> > Maybe in that case it doesn't need to get the UID?

>

> Tried both implicit and explicit connections, no difference in behaviour.

>

> > 2- You probably can reproduce this by scheduling the process in the

> > crontab.

>

> crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is

> set

> to the correct UID. I already verified that by scheduling the ESQL/C

> program

> in cron.

>

> > 3- On many ocassions this weird delays are caused by issues in reverse

> > lookups (IP to names).

>

> No problem there, I can assure you.

>

> > I honestly don't know (strace should help) what ESQL/C calls when it

> > starts....

>

> I can send you a complete strace output, but I already mentioned the

> relevant

> parts in this thread.

>

> > I'm sure Jonathan Leffler would be able to provide some more

> > info on this, but I haven't seen him here for a while.

>

> Honestly, I had hoped that he might read this...

>

> > Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> > That's a consequence on a system call and your system configuration....

>

> Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

> program itself reads /proc/self/loginuid, and that ONLY happens if the

> program

> establishes a database connection somewhere later in the program. I wrote

> a

> dummy ESQL/C program that doesn't open a database connection, and this

> dummy

> program doesn't read /proc/self/loginuid and does no user verification at

> all.

>

> Regards, Richard

>

>

No. I understand you got that from strace. And I didn't mean that the

ESQL/C process does not read the file.

What I mean is that ESQL/C only calls "standard" POSIX functions. And this

functions in your system (Linux + kernel version + configuration +

whatever) trigger those operations.

We would need to understand what call triggers that and if there's a way to

workaround it.

I thought, apprently wrongly, that it was the call to getuid which I

confirmed happens on an ESQL/C process. That's why I sent you a test case

with that call.

A possible way to try to find that would be to run the ESQL/C program in a

debugger and set a couple of breakpoints in OS functions close to the

sequence where it has delays.

When the program stops and returns control to the debugger try to run a

"where" and see what's in there. An example with getuid():



castelo@stardust.onlinedomus.net:informix-> gdb ./test.exe

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /tmp/test.exe...(no debugging symbols found)...done.

(gdb) break getuid

Function "getuid" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (getuid) pending.

(gdb) run

Starting program: /tmp/./test.exe

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".



Breakpoint 1, 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

Missing separate debuginfos, use: debuginfo-install

glibc-2.17-196.el7_4.2.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64

(gdb) where

#0 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

#1 0x00007ffff79597e7 in cmInit () from

/opt/informix/csdk410fc7w1/lib/libifasf.so

#2 0x00007ffff7950ddf in asfInit () from

/opt/informix/csdk410fc7w1/lib/libifasf.so

#3 0x00007ffff795196b in ASF_Call () from

/opt/informix/csdk410fc7w1/lib/libifasf.so

#4 0x00007ffff7b99a88 in asf_init () from

/opt/informix/csdk410fc7w1/lib/esql/libifsql.so

#5 0x00007ffff7b9ce0d in sqli_connect_open () from

/opt/informix/csdk410fc7w1/lib/esql/libifsql.so

#6 0x0000000000400916 in main ()

(gdb)



In this case the "CONNECT/DATABASE" statement triggers several calls in the

Informix LIBS and then we jump into the getuid().

You may need to go over several attempts if you can only set the breakpoint

to common functions like "open()"...



Once we find the POSIX function which is causing the sequence that causes

the delays we may have a shot of reconfigure something to solve it.

getuid() for example is necessary to get the user id under which we run....



Regards.



>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4757]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Wed, 18 Apr 2018 12:20:51 EDT
To clarify:



The common denominator in both questions (here and on stackoverflow) is an

ESQL/C program launched by a "daemon". Here the daemon is IDS launching the

program via the SPL "SYSTEM" command, there the daemon is Apache launching

(another) ESQL/C program via CGI.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4756]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Wed, 18 Apr 2018 12:17:11 EDT
Fernando,



thank you very much for your detailed response. I had written a comment in

your blog article because that had been the most profound and helpful info I

had found about configuring IDS with PAM support.



> ESQL/C will most probably (that's what I'd like to test/debug) need

> to get the user ID *before* trying to connect to IDS. And that's

> where it's taking time.



Exactly. I think I had written before in this thread that the delay occurs

before the database connection is established. What's puzzling me is the way

ESQL/C does this: First it goes through all the "pain" of reading

/proc/self/loginuid and trying to verify that uid via the mechanisms defined

in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and causes

the delay), and then it uses getuid() anyway to continue happily everafter.



> That probably means that the LDAP integration software you're

> using "hijacks" some internal functions/libraries...



Well, I'm using a perfectly standard and well documented mechanism for that:

sssd. This is nothing fancy and is integrated into current versions of GLIBC,

that is also why PAM is not even needed to connect to IDS as an LDAP user.



> When you say "interactive" may I assume you opened an SSH/telnet

> to the server using the user name of the user? Or have you done an su/sudo?



Interactive means that I am in a normal user shell (opened via SSH/PuTTY) on

the Linux machine Hosting IDS and executing the shell script that is normally

invoked by the SPL.



> Assuming you did that directly the login process is going through

> the authentication and creates the "session context" that makes the

> calls run fast



The login process sets /proc/self/loginuid for the shell, which is inherited

by the program or shell script I'm starting.



> This is not being set when a daemon (Informix) changes a process

> identity which is what the SYSTEM SPL instruction triggers.



Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so is

designed to set /proc/self/loginuid. That (pseudo) file is writable only for

root, otherwise it would be trivial to write the correct uid to it but of

course a huge security issue.



> 1- Understand why the process takes time after trying to get that

> info from the file. Is it calling a daemon for cache, talking to

> the LDAP server, etc?. And how can that time be reduced?



As written before, the problem is that ESQL/C is trying the UID of "-1" (read

from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

unsuccessful. That UID can not be found in any local cache, that's why a query

to the AD servers is done which is of course also unsuccessful. All of this

takes time, a query with a correct UID takes only milliseconds.



> 2- Check the use of the pam_loginuid in your system.



That's what I've been doing all along. Is there a mechanism to make IDS (and

other "daemons", like Apache) use that module when invoking subshells or

processes?



> I suppose the delay is also noticeable when you do the login.



No, a valid user login works instantly, no noticeable delay.



> 1- Can you change the ESQL/C to CONNECT with a specific user?

> Maybe in that case it doesn't need to get the UID?



Tried both implicit and explicit connections, no difference in behaviour.



> 2- You probably can reproduce this by scheduling the process in the

> crontab.



crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is set

to the correct UID. I already verified that by scheduling the ESQL/C program

in cron.



> 3- On many ocassions this weird delays are caused by issues in reverse

> lookups (IP to names).



No problem there, I can assure you.



> I honestly don't know (strace should help) what ESQL/C calls when it

> starts....



I can send you a complete strace output, but I already mentioned the relevant

parts in this thread.



> I'm sure Jonathan Leffler would be able to provide some more

> info on this, but I haven't seen him here for a while.



Honestly, I had hoped that he might read this...



> Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> That's a consequence on a system call and your system configuration....



Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

program itself reads /proc/self/loginuid, and that ONLY happens if the program

establishes a database connection somewhere later in the program. I wrote a

dummy ESQL/C program that doesn't open a database connection, and this dummy

program doesn't read /proc/self/loginuid and does no user verification at all.



Regards, Richard









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4755]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 11:50:26 EDT
Considering this:



https://stackoverflow.com/questions/49877098/apache-cgi-loginuid



Can you clarify if the process is being launched by Informix server, Apache

server or both?



Thanks.



On Wed, Apr 18, 2018 at 5:29 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> The SYSTEM command within SPL calls a shell script which in turn invokes

> strace with the ESQL/C program. I tried different shells within the

> script:

> bash (default), ksh and csh, with no difference whatsoever.

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4754]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Wed, 18 Apr 2018 11:29:14 EDT
The SYSTEM command within SPL calls a shell script which in turn invokes

strace with the ESQL/C program. I tried different shells within the script:

bash (default), ksh and csh, with no difference whatsoever.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4753]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 06:15:25 EDT
Roger,



I've been reading this thread with interest, but I haven't been able to try

to setup any tests which I think I'd need in order to provide some more

relevant info,

Meanwhile I noticed your comment on my blog... so I think It's better to

keep the discussion in a single place (here).



I think you're approaching this the wrong way. You're connecting the

problem with PAM, and I think it has nothing to do with PAM, although it is

probably caused by changes on the system that were done because of PAM.

(I suppose it would be hard to write a more confusing sentence...)



ESQL/C will most probably (that's what I'd like to test/debug) need to get

the user ID *before* trying to connect to IDS. And that's where it's taking

time. Not on the database server authentication. That's why I state it's

not related to PAM authentication. But I assume that in order to configure

PAM you changed your system to recognize the AD/LDAP users as local

users.... That probably means that the LDAP integration software you're

using "hijacks" some internal functions/libraries...



You stated:



Interactive:

open("/proc/self/loginuid", O_RDONLY) = 3

read(3, "1004", 12) = 4

close(3) = 0



Non-interactive:

open("/proc/self/loginuid", O_RDONLY) = 3

read(3, "4294967295", 12) = 10

close(3)



When you say "interactive" may I assume you opened an SSH/telnet to the

server using the user name of the user? Or have you done an su/sudo?

Assuming you did that directly the login process is going through the

authentication and creates the "session context" that makes the calls run

fast



From this thread:





https://stackoverflow.com/questions/22914627/some-uids-in-proc-pid-loginuid-are-strange



sounds like the file /proc/self/loginuid is created/populated by a PAM

module used by the system during a normal login (ssh/telnet etc.)

This is not being set when a daemon (Informix) changes a process identity

which is what the SYSTEM SPL instruction triggers.



I'd say you have to follow one of two routes (note that this is really a

sysadmin issue, not a database issue):



1- Understand why the process takes time after trying to get that info from

the file. Is it calling a daemon for cache, talking to the LDAP server,

etc?. And how can that time be reduced?



2- Check the use of the pam_loginuid in your system. A few links that may

help, but this was just a very quick search:



https://stackoverflow.com/questions/41894621/why-pam-loginuid-module-fails-on-writing-to-proc-self-loginuid-with-eperm



https://unix.stackexchange.com/questions/146138/loginuid-should-be-allowed-to-change-or-not-mutable-or-not

http://www.linux-pam.org/Linux-PAM-html/sag-pam_loginuid.html



Sorry for not being more helpful, but this is really a problem on what your

system needs to do, when a process tries to understand the user under which

it's running. I suppose the delay is also noticeable when you do the login.



Some other thoughts....



1- Can you change the ESQL/C to CONNECT with a specific user? Maybe in that

case it doesn't need to get the UID? But this is a wild guess

2- You probably can reproduce this by scheduling the process in the

crontab. This may help to show your fellows sysadmins that the problem is

not related to Informix. If that's the case it may change their attitude

(if it's not correct now)

3- On many ocassions this weird delays are caused by issues in reverse

lookups (IP to names). Try to make sure that the server, the LDAP server

and any other server involved is able to reverse lookup the IP addresses of

the involved servers "fast"



I honestly don't know (strace should help) what ESQL/C calls when it

starts.... I'm sure Jonathan Leffler would be able to provide some more

info on this, but I haven't seen him here for a while. You can try to put

the question on stackoverflow as he currently monitors it and has been very

responsive. That could help the sysadmins to improve the times and

understand the issue. Note that in noway ESQL/C directly accesses the

/proc/self/loginuid. That's a consequence on a system call and your system

configuration....



Regards.



On Mon, Apr 16, 2018 at 12:35 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> Here's an update for anyone who's interested, although no solution yet.

>

> It indeed seems to be a user authentication issue. The ESQL/C programs

> read

> the login uid from /proc/self/loginuid, and the results differ depending

> on

> the program being run interactively from the shell or not:

>

> Interactive:

> open("/proc/self/loginuid", O_RDONLY) = 3

> read(3, "1004", 12) = 4

> close(3) = 0

>

> Non-interactive:

> open("/proc/self/loginuid", O_RDONLY) = 3

> read(3, "4294967295", 12) = 10

> close(3)

>

> "4294967295" is effectively "-1", which is normal since the process was

> not

> called from a login shell. Since this uid is not found in /etc/passwd, the

> program switches to sss for user authentication, where of course this uid

> is

> also not found. Next "getuid()" is called, which then returns the correct

> uid

> the program is running under, and everything is running smoothly from then

> on.

>

> I'm currently waiting for our sysadmins to setup a virtual test server for

> me

> where I can play with different configurations for IDS, PAM etc. Will keep

> you

> posted.

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4752]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: 4GL Source Control - Linux
Posted by: david@smooth1.co.uk (david@smooth1.co.uk) - Tue, 17 Apr 2018 20:14:01 EDT
RCS or Git.



Otherwise https://en.wikipedia.org/wiki/Comparison_of_version_control_software



Regards,

David.



> On 17 April 2018 at 23:50 ERIC ROWELL <erowell@gmail.com> wrote:

>

>

> Would love to know what Source Control and Release Management tools the

> community is using on Linux with or without Informix 4GL.

>

> We are moving from AIX to Linux and are still using RCS with custom

scripting.

>

> Eric

>

>

>



>

>









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4751]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

4GL Source Control - Linux
Posted by: erowell@gmail.com (ERIC ROWELL) - Tue, 17 Apr 2018 18:50:40 EDT
Would love to know what Source Control and Release Management tools the

community is using on Linux with or without Informix 4GL.



We are moving from AIX to Linux and are still using RCS with custom scripting.



Eric









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4750]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

RE: ESQL/C Programs take very long time to start u
Posted by: paul@oninit.com (Paul Watson) - Tue, 17 Apr 2018 10:19:50 EDT
Does the shell that system uses make any difference ?



-----Original Message-----

From: classics-bounces@iiug.org [mailto:classics-bounces@iiug.org] On Behalf

Of RICHARD SPITZ

Sent: Monday, April 16, 2018 5:36 AM

To: classics@iiug.org

Subject: Re: ESQL/C Programs take very long time to start u [4748]



Here's an update for anyone who's interested, although no solution yet.



It indeed seems to be a user authentication issue. The ESQL/C programs read

the login uid from /proc/self/loginuid, and the results differ depending on

the program being run interactively from the shell or not:



Interactive:

open("/proc/self/loginuid", O_RDONLY) = 3

read(3, "1004", 12) = 4

close(3) = 0



Non-interactive:

open("/proc/self/loginuid", O_RDONLY) = 3

read(3, "4294967295", 12) = 10

close(3)



"4294967295" is effectively "-1", which is normal since the process was not

called from a login shell. Since this uid is not found in /etc/passwd, the

program switches to sss for user authentication, where of course this uid is



also not found. Next "getuid()" is called, which then returns the correct

uid

the program is running under, and everything is running smoothly from then

on.



I'm currently waiting for our sysadmins to setup a virtual test server for

me

where I can play with different configurations for IDS, PAM etc. Will keep

you

posted.



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

***











* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4749]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Mon, 16 Apr 2018 06:35:56 EDT
Here's an update for anyone who's interested, although no solution yet.



It indeed seems to be a user authentication issue. The ESQL/C programs read

the login uid from /proc/self/loginuid, and the results differ depending on

the program being run interactively from the shell or not:



Interactive:

open("/proc/self/loginuid", O_RDONLY) = 3

read(3, "1004", 12) = 4

close(3) = 0



Non-interactive:

open("/proc/self/loginuid", O_RDONLY) = 3

read(3, "4294967295", 12) = 10

close(3)



"4294967295" is effectively "-1", which is normal since the process was not

called from a login shell. Since this uid is not found in /etc/passwd, the

program switches to sss for user authentication, where of course this uid is

also not found. Next "getuid()" is called, which then returns the correct uid

the program is running under, and everything is running smoothly from then on.



I'm currently waiting for our sysadmins to setup a virtual test server for me

where I can play with different configurations for IDS, PAM etc. Will keep you

posted.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4748]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Informix Genero
Posted by: krishnan.iyer@spicaindia.com (KRISHNAN IYER) - Mon, 16 Apr 2018 04:30:06 EDT
Hi,



We are Based in Pune- India, and are planning to convert few legacy

Applications to Genero.



Any consultant based in and around Pune, who can help us to migrate can , by

reply back with details..



Thanks in Advance,



Krishnan









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4747]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to....
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Thu, 29 Mar 2018 08:27:23 EDT
Yes, I have done this. Besides, the environment is shown in the first line of

the strace output as part of the "execve" command line.



There is of course a huge delta, but as written before, I included the whole

environment from the working shell into the script calling the ESQL/C program

so the environment was the same, and still there was no difference in

performance.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4746]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Yes, I have done this. Besides, the environment is shown in the first line of

the strace output as part of the "execve" command line.



There is of course a huge delta, but as written before, I included the whole

environment from the working shell into the script calling the ESQL/C program

so the environment was the same, and still there was no difference in

performance.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4746]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

 
Subscribe to this feed
You can subscribe to this RSS feed in a number of ways, including the following:

Drag the orange RSS button into your News Reader

Drag the URL of the RSS feed into your News Reader

Cut and paste the URL of the RSS feed into your News Readerv