952 Error with Redhat 6.2 (2.2.14-5.0) and IDS 7.30.UC10
Chris Elliott got error -952 (incorrect user password for remote host) connecting to IDS 7.30.UC10 on Red Hat 6.2, and saw oninit owned by root. Sergey E. Volkov said oninit does seteuid and that 7.30 on Linux had shadow password problems, advising DES rather than MD5 in /etc/shadow. Sergey Turin said the engine can start as informix or root depending on rc scripts. No confirmed fix.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
I recently installed informix IDS 7.30.UC10 on Linux 6.2 with cooked space.
When I attempt to connect from a client or from dbaccess as informix I get
a "-952 Incorrect user password for remote host" error.
Everything seems to be fine with the database itself. I loaded the stores7
demo and can run select statements against its tables as expected.
1. I have a small bit of experience with informix on AIX and remember the
oninit processes being owned by Informix. When launching the DB server as
informix under Linux, I noticed the oninit processes are all owned by root.
Is this normal and would this explain the 952 error?
Any help or direction to an FAQ would be greatly appreciated.
Thanks.
On startup oninit make 'seteuid' system call ( setting effective user id )
and change effective user id from informix to root.
I not know for sure, but I heard that 7.30 on Linux not works correct with
a 'shadow passwords' faculty.
Chris Elliott <celliott@nexgeninc.com> ''''' '
''''''''':78vH5.271$ea5.112058@den-news1.rmi.net...
> I recently installed informix IDS 7.30.UC10 on Linux 6.2 with cooked
space.
> When I attempt to connect from a client or from dbaccess as informix I
get
> a "-952 Incorrect user password for remote host" error.
>
> Everything seems to be fine with the database itself. I loaded the
stores7
> demo and can run select statements against its tables as expected.
>
> 1. I have a small bit of experience with informix on AIX and remember the
> oninit processes being owned by Informix. When launching the DB server as
> informix under Linux, I noticed the oninit processes are all owned by
root.
> Is this normal and would this explain the 952 error?
>
> Any help or direction to an FAQ would be greatly appreciated.
>
> Thanks.
>
>
> I not know for sure, but I heard that 7.30 on Linux not works correct
with
> a 'shadow passwords' faculty.
One simple note: Do not use MD5 crypting in /etc/shadow use DES and all must
to be ok!
Sergey E. Volkov <sve@raiden.bancorp.ru> ''''' '
''''''''':8sm5l0$ea11@www.informix.com...
> On startup oninit make 'seteuid' system call ( setting effective user id )
> and change effective user id from informix to root.
> I not know for sure, but I heard that 7.30 on Linux not works correct
with
> a 'shadow passwords' faculty.
>
>
> Chris Elliott <celliott@nexgeninc.com> ''''' '
> ''''''''':78vH5.271$ea5.112058@den-news1.rmi.net...
> > I recently installed informix IDS 7.30.UC10 on Linux 6.2 with cooked
> space.
> > When I attempt to connect from a client or from dbaccess as informix I
> get
> > a "-952 Incorrect user password for remote host" error.
> >
> > Everything seems to be fine with the database itself. I loaded the
> stores7
> > demo and can run select statements against its tables as expected.
> >
> > 1. I have a small bit of experience with informix on AIX and remember
the
> > oninit processes being owned by Informix. When launching the DB server
as
> > informix under Linux, I noticed the oninit processes are all owned by
> root.
> > Is this normal and would this explain the 952 error?
> >
> > Any help or direction to an FAQ would be greatly appreciated.
> >
> > Thanks.
> >
> >
>
>
Hi Chris,
> oninit processes being owned by Informix. When launching the DB server as
> informix under Linux, I noticed the oninit processes are all owned by
root.
> Is this normal and would this explain the 952 error?
IDS engine can be started either as informix and as root. It depends on your
rc* scripts.
With 7.30 on RH 5.2, the owner of oninit processes was user informix.
Hope this helps,
Sergey