Do you have plans to upgrade to IDS 11?
maybe oninit does not have suid bits set or is not owned by root??
eq
-rwsr-sr-- 1 root informix
Superboer.
Permissions on oninit are correct.
I know IDS9 is on the way out, and we're certifying IDS 11.5 right
now, but that's still going to be several months out.
Thanks,
Nate
You have .rhosts or hosts.equiv set up? AFAIK they are needed with ssh to.
Regards
Reinhard
> _______________________________________________
> Informix-list mailing list
> Inform...@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
-----Original Message-----
From: informix-l...@iiug.org
[mailto:informix-l...@iiug.org] On Behalf Of nat...@kc.rr.com
Reinhard
These files are not set up on the functioning production server. I
tried adding a hosts.equiv on the test server, but it didn't get rid
of the error.
Thanks,
Nate
It's a TCP/IP connection.
-Nate
If I read correctly, the issue only happens from a Windows server.
- Can you try a JDBC connection for example (with Squirrel SQL or similar, from
the same server?
- How is your "Host Information" settings for password on that server?
- Can you try a clean install of CSDK on another PC?
- Aren't you using SSH keys to connect?
- Can you try a connection using dbaccess from another host (explicitly
"connect", not the implicit one through trusted relation)?
- and finally, did you open a PMR? I was chatting with a colleague about a
similar issue... just wondering if it's the same situation
If IDS isn't broken, it really didn't match the password that it received with
the one on your system... oserr = 0 would imply that no error occurred in the
process...
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
Have you ever run "finderr"?
> Does Informix track and log login attempts? You should be able to track
> and see how far you got in to the login process.
> One more thing that might help... is the -952 error being generated by
> the server itself or the client trying to connect?
It surely is the client... Then it sends the info into the server, so that it
can save it in the online.log :)
> My gut tells me that you may be hitting some form of a firewall issue.
> You may want to turn off (temporary) the fire wall on your pc and your
> development server. (I'm going to assume that you're behind a corporate
> firewall and that both your PC and Server have a low risk of attack for
> the short time...
Unless you know about some bug that messes error codes real bad, please tell
your gut to read the error codes...
Those files are used for "implicit" connections. Not for explicit (using
password) connections.
>
> Unless you know about some bug that messes error codes real bad, please tell
> your gut to read the error codes...
>
Well sparky,
Funny you should pop your fuzzy little head up...
I happened to be experiencing a similar issue with Java, JSTL and JSPs
when trying to connect to an IDS 10.x instance.
I'm not going to bore you with what those components are,. but what
I'm finding out in the error file is that the user name is coming
across as us...@machine.domain.com and not just user. This could be
causing Informix to barf on the authentication and then failing.
Unfortunately for moi, the error was masked because the glassfish app
server was reporting that there was a null string conversion in the
exception process and since the jdbc connection is abstracted, I had
no way of finding out the issue.
Now I know and I'm looking at not using the Informix native jdbc
driver but trying to use the informix jdbc driver that ships with the
Sun Web Server.
So yeah, you can look at the online.log and see what is being sent
over the wire and getting rejected.
While the online.log doesn't show you the password that was sent, the
fact that I'm seeing us...@macine.domain.com explains why
authentication bombs out.
Now boy wonder, why don't you tell us why Informix 9 and 10 are doing
this? Or rather why the CSDK (odbc for the OP and jdbc for moi) is
doing this?
And you should never, ever use them except in a very controlled
environment. Hosts.equiv that is. NEVER EVER USE .rhosts, or
ALLOW .rhosts ON YOUR SYSTEMS. But then again, you're probably too
young to know who Morris was or who his father was.... ;-)
(Sort of like never pointing a gun at someone unless its loaded and
you intend to pull the trigger if necessary.)
As usual, we're getting completely off-topic... but...
You don't need to be hanging on a tree to know who/what the "missing link"
was... As such, people younger than you surely have heard about or have read
about the internet worm... and precisely because of that, I went digging...
As it happens very often, you're confusing .rhosts/hosts.equiv with the
services that use them. If you care about a safe environment than turn off the
services... the files per si are just that... files.
The worm used the r* commands to spread inside the networks, and
sendmail/finger to spread across networks. It actually took advantage of a
buffer overflow issue in sendmail/finger... it become so well know, probably
because it was the first one to spread in such a large scale... not because it
does anything special (at the time it might have been, but today it's just a
trivial attack).
In short: you can use the files for Informix, if your r* services are not
running. Also, Informix does allow configuration options in order to look for
only one of the files or both.
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
Informix (at least recent versions) include the hostname (or IP address if it's
not able to revere dns). This is useful for debug purposes. On older versions,
only the username was shown which could be a PITA to solve, because you simply
didn't know from where the connection was attempted.
> So yeah, you can look at the online.log and see what is being sent
> over the wire and getting rejected.
> While the online.log doesn't show you the password that was sent, the
> fact that I'm seeing us...@macine.domain.com explains why
> authentication bombs out.
No, it does not explain. You should post your situation and the error code
you're getting, and the full online.log message.
You could also truss your msc (or adm?) virtual processor... it may reveal
something interesting
> Now boy wonder, why don't you tell us why Informix 9 and 10 are doing
> this? Or rather why the CSDK (odbc for the OP and jdbc for moi) is
> doing this?
I'm not a "wonder", nor a "boy". But if you care to wait for the answers to my
questions we may get closer. If we don't, as usual, a PMR could help.
Regards,
Doug Lawry
<nat...@kc.rr.com> wrote in message
news:db2447cc-3a95-4c0a...@j38g2000yqa.googlegroups.com...
Yes... in older versions. should be fixed...
Regards
what happens if you do the same using dbaccess
eq ssh to the machine
start dbaccess choose the connect option choose your network
informixserver
supply user and passwd
could be an os issue??? sorry just guessing
Superboer.
Hello Ian,
because i have had dozens of problems like the above where someone got
rid of root or suid.
why don't you test this on your testbox, you will see.
it could very well be -951 what is returned.....
On 27 mrt, 15:22, Ian Michael Gumby <im_gu...@hotmail.com> wrote:
> Superboer,
>
> If that were true, then how could he log in using same password and id when physically on the box?
> (Assuming that he is using the same user id and password.)
>
> With respect to the install, if he did the same process in production as in development, then his 'sticky bits' would have been set.
>
> Of course one question comes to mind. If he's on the same machine, is he connecting via TCP/IP sockets or shared memory?
> If he's not using TCP/IP for the connection, then I wonder if there's a firewall or something blocking the connection and he's timing out?
>
>
>
> > From: superbo...@t-online.de
> > Subject: Re: -952 Authentication Error on Solaris 10
> > Date: Fri, 27 Mar 2009 03:44:03 -0700
> > To: informix-l...@iiug.org
>
> > Hello Nate,
>
> > maybe oninit does not have suid bits set or is not owned by root??
> > eq
>
> > -rwsr-sr-- 1 root informix
>
> > Superboer.
>
> > On 27 mrt, 00:53, wcottishpoet <drybur...@yahoo.com> wrote:
> > > No idea what the problem is but IDS 9.40 will not be supported by IBM
> > > after next month
>
> > > Do you have plans to upgrade to IDS 11?
>
> > _______________________________________________
> > Informix-list mailing list
> > Informix-l...@iiug.org
> >http://www.iiug.org/mailman/listinfo/informix-list
>
> _________________________________________________________________
> Express your personality in color! Preview and select themes for Hotmail®.http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TX...
I was thinking along the lines of a firewall issue.
Assuming that the production box and the development box are similar
machines in terms of OS and set up, if one box works and one box
fails, then it could be a configuration issue. That could mean
firewall, IDS setup, or user admin setup. If they're using some form
of single sign-on that's on both machines (yp?), then it makes a tcp/
ip filter issue more likely. However, the weird thing is that in
order to get a -952 issue, its a server generated issue. So maybe its
a configuration issue in ODBC? Like the password isn't coming across
ok or that the user doesn't have connect privileges with the specified
db? (And that could be it.)
So what's different between the two boxes?
-G
well may be testing dbaccess on the local box using user and passwd to
connect may
rule that out???
wait and see
Superboer.
> order to get a -952 issue, its a server generated issue. So maybe its
> a configuration issue in ODBC? Like the password isn't coming across
> ok or that the user doesn't have connect privileges with the specified
> db? (And that could be it.)
If the user doesn't have connect privileges, then the error is different.
IDS first goes through the authentication process (making sure you're the one
you're saying), and then checks the privileges. Each situation has a different
set of errors.
Some versions had an issue with passwords longer than 8 characters. I think
this was specific to Solaris. It's easy to check if anybody thinks that this
maybe the issue (you can change the password, if it's longer than 8 chars, for
testing purposes).
Regards.
I never did figure out what the root cause of the problem was. We
ended up restoring an OS backup from prod to test, and after restoring
a Level 0 backup to the test DB server everything started working.
Thanks for all the suggestions.
-Nate
Ok. That's one way to take care of it. ;-)