From: Rasmus Plewe (rplewe_at_suse.de)
Date: Fri Mar 23 2007 - 19:57:07 CET
Date: Fri, 23 Mar 2007 19:57:07 +0100 From: Rasmus Plewe <rplewe@suse.de> Message-ID: <20070323185707.GA27937@coredump.suse.de> Subject: Re: [suse-sles-e] SLES10 sux (== /bin/su) - broken??
On Fri, Mar 23, 2007 at 11:09:05AM -0700, Alexei_Roudnev wrote:
>
> Not a desktop, just an installation:
> - you slogin -X or sux as a root
> - run standard scripts (having x11 context, but your desktop on your desk is
> not a root, of course)
> - root starts scripts which can su or sux to the system users (such as mysql
> or oracle) to do a job.
>
> Nothing is wrong in such scenario and nothing is unsecure.
Except that it does not work, you mean.
> You can't use ssh to start command in X11 mode, and it is what is required
> in many cases (esp. with Oracle).
Why not? I can.
> On the other hand, 90% of oracle installation tasks (creating directories,
> configuring disks and so on) is doing as a root,
> so you can't just login as an oracle (which dont exists when you login, btw)
> and then su root on demand.
I'm no Oracle expert, far from it. Having worked with environments that
sound similar to what you describe from a procedural point of view (HSM,
not DB), I used to log in as my user (rplewe) on my desktop, started an
xterm with a blue background in which I did an "ssh -Y root@remotehost",
and then another xterm with a red background in which I did an
"ssh -Y oracle@remotehost" (with 'oracle' being some other system
service user). Worked for me[0].
> And it is only single example of SLES9 / SLES10 incompatibility and, worst,
> undocumented changes.
I can't remember anyone claiming that SLES10 was a drop-in replacement
for SLES9. New system, and thus "mostly binary compatible" or so. That's
not really a surprise.
We try to document everything that is of significance, but you can't
document every detail going from one system version to another. And yes,
of course we might have missed one or two changes of relevance to a
wider user base that we should have had documented. That's why we
advise against blindly updating a productive system. Do heavy testing of
your environment first, so you're not surprised by unexpected behaviour.
That goes for SLES9->SLES10 as well as for RH4->RH5 or even upgrading to
a service pack. There's no way around that, if your deployment requires
responsible administration.
Regards,
Rasmus
[0] There are workarounds if root is not allowed to remotely connect via
ssh (ssh to a user, then ssh root@localhost). There are no
workarounds if the server does not accept ssh connections at all, in
which case you should start wondering in what hostile environment
you place your valuable server, that you daren't risk ssh
connections even from some local subnet.
-- Rasmus Plewe --- Linux Beta Test Coordinator SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg tel.: +49-911-74053-644 fax: +49-911-74053-483 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Fri Mar 23 2007 - 22:00:54 CET