In comp.unix.solaris Karen Hill <karen_hill22@yahoo.com> wrote:

> When an auditor has to sign off on it, "learn to live with it" is not a
> very good solution when dealing with Sarb-Ox.

Actually, it's a VERY good solution to dealing with auditors, SOX or
otherwise. Risk is the cost of doing business. If you can't accept some
risk, then you shouldn't be doing business. The proper role of seecurity,
SOX, and any other auditors are to quantify and reduce risk, not to pretend
to eliminate it.

On Tue, 5 Sep 2006, Tim Bradshaw wrote:

> Rich Teer wrote:
>
> > That's one valid way of doing it, but wasteful of memory resources
> > if drivers for devices one rarely (if ever) uses are compiled in.
>
> I can imagine circumstances where the driver wasn't even on the system
> at compile time (whenever that was). I'm not sure I've done this, but
> I can easily imagine something like (on Solaris):
>
> pkgadd <package-with-driver-for-device>
> ... add device, cfgadm, load driver etc ...
>
> I certainly don't see why that should not work - Solaris is an
> enormously dynamic OS.

Right; and I think that that is a pro for Solaris.

Or, to put it another way: I don't want to have to recompile (or
relink) my kernel just because I've added a new device.

--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

On Tue, 5 Sep 2006, jKILLSPAM.schipper@math.uu.nl wrote:

> Nice. Not necessarily useful, but thoroughly nice.

Heh, I take it you've not done much enterprise class computing. :-)

In an environment where downtime is not only inconvenient, it is
also extremely expensive, hot swappable CPUs are not only useful,
they're almost a requirement.

The thought of incurring hundreds of thousands of dollars of costs
due to downtime "just" to replace a CPU is not very paletable in
those enterprise environments. The same also applies for upgrades:
the ability to add CPU/memory resources to a running system can also
save huge amounts of cash.

--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

In article <1157454798.377582.214950@b28g2000cwb.googlegroups .com>,
"Tim Bradshaw" <tfb+google@tfeb.org> wrote:

> jKILLSPAM.schipper@math.uu.nl wrote:
>
> > In comp.unix.bsd.openbsd.misc Rich Teer <rich.teer@rite-group.com> wrote:
>
> > > Provided it's supported by the HW, Solaris DOES support hotswapping
> > > CPUs...
> >
> > Nice. Not necessarily useful, but thoroughly nice.
> >
>
> As should be clear from some other followups: actually it's *terribly*
> useful. As (yet another) example, big Sun machines can be divided into
> `domains' which are partitions of the hardware of the machine, on each
> of which a separate Solaris instance runs. It can often be useful to
> move CPUs (really, to move system boards, which contain several CPUs
> and some memory) between domains, thus adding resources to one while
> removing it from another. And for the applications these machines
> typically run, you generally want to do this without bouncing either
> donor or recipient domain because people will run around screaming and
> turning pink if you do.
>
> --tim

Solaris _almost_ had this a couple years ago. Don't know about now with
the newer machines and Solaris 10. A former manager, a died in the wool
SUN advocate/fanboy, complained every time a new release of Solaris came
out because he hated having to reboot after a hardware change. The
hardware he had (E6800, bunches of E4500, that generation) all required
downtime to add SCSI interfaces, disks, memory, even replacing a SCSI
tape. He longed for the day when the HW support person would _call him_
and tell him there was a problem that required repair and when did he
want to schedule it and no it would not require downtime, just quiet
time. The only reason the EMC frame was in the datacenter as long as it
was was because this was how they did their service.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Begin <slrnefr1gc.315.pakrat@vm01.raleigh.neotoma.org>
On 2006-09-05, pakrat@localhost.private.neotoma.org
<pakrat@localhost.private.neotoma.org> wrote:
>
> IBM seems to be tossing money into such work with Linux/Xen.
> Intel and AMD seem to be tossing money into hardware to make this easier
> to accomplish with their CPUs.

Which for IBM is a bit ironic, IMO...


> At current moment IBM does not make any non-blade pSeries systems that
> are not capable of such partitioning.

.... and this is why. Not to mention BIG iron.


> Expect used lower end partitionable pSiers hardware to start
> trickling out to in the know hobbyists within 2.5 years.

For some reason ibm kit is more prone to being asked unreasonably much
for, even second hand. Plus, at least here, last time I looked, parts
and stuff are much more of a pain to get than for, say, suns or even
sgis. (Again, second hand.) But maybe that just proves I live out in the
boonies, or shows me a total cheapskate, who knows.


> Used IBM xSeries hardware capable of the same should be appearing shortly
> as well (Granted, the hardware that will appear first are some serious
> turds).

Since reinventing wheels badly and without all the useful features, then
reintroducing those as bolt-ons badged ``upgrades'', is just about the
peecee's life story, that doesn't surprise me.

The xSeries I got to babysit weren't ideal, eg. their BIOSes could use
some serious improvements so they'd waste less of my time, but boy did
they have pretty lights inside. *This*<--- part is broken, here, look.
Sometimes IBM does get (some) things right. :-)


Still, since this world isn't ideal, it's better with xen than without.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 5 Sep 2006 23:21:58 GMT in <4m6f4mF4qmatU1@individual.net> jpd <read_the_sig@do.not.spam.it.invalid> wrote:
> Begin <slrnefr1gc.315.pakrat@vm01.raleigh.neotoma.org>
> On 2006-09-05, pakrat@localhost.private.neotoma.org
><pakrat@localhost.private.neotoma.org> wrote:
>>
>> IBM seems to be tossing money into such work with Linux/Xen.
>> Intel and AMD seem to be tossing money into hardware to make this easier
>> to accomplish with their CPUs.
>
> Which for IBM is a bit ironic, IMO...

Anyone that thinks that IBM has a unified direction has had a case
of cranial rectal inversion ATLEAST since the 5150 was released.
Now that IBM is largely services and works for hire, things are even
more schizophrenic.
>
>
>> At current moment IBM does not make any non-blade pSeries systems that
>> are not capable of such partitioning.
>
> ... and this is why. Not to mention BIG iron.

I presently deal with pSeries big, middle, and small iron.
I'm more impressed with partitioning with VIO on the middle and small iron
than on the big iron. I could be jaded because it requires significantly
fewer people in the meeting for a firmware upgrade, or memory replacement
on the small and medium iron.
And we won't go into power and physical structure requirements for big iron.
There's just someone wrong when they start offering liquid cooled chiller
doors for the boxes. Doubly wrong if you saw the sales spike when s/390
went CMOS and could be air cooled.
>
>
>> Expect used lower end partitionable pSiers hardware to start
>> trickling out to in the know hobbyists within 2.5 years.
>
> For some reason ibm kit is more prone to being asked unreasonably much
> for, even second hand. Plus, at least here, last time I looked, parts
> and stuff are much more of a pain to get than for, say, suns or even
> sgis. (Again, second hand.) But maybe that just proves I live out in the
> boonies, or shows me a total cheapskate, who knows.

Is SGI even in business anymore? For some reason cheap SGI hardware
makes me think of the cheap miniscribe harddrives that flooded the used
market back in the 90s.
As for SUN hardware... I've seen a lot of it. I've seen most of it with
fried onboard ethernet, dieing CPUs, bad memory, dieing power supplies....
>
> The xSeries I got to babysit weren't ideal, eg. their BIOSes could use
> some serious improvements so they'd waste less of my time, but boy did
> they have pretty lights inside. *This*<--- part is broken, here, look.
> Sometimes IBM does get (some) things right. :-)

Unless IBM outsources the design and manufacturing of the xSeries
box and it doens't have light path diagnostics.


--
Chris Dukes
< elfick> willg: you can't use dell to beat people, it wouldn't stand up
to the strain... much like attacking a tank with a wiffle bat

In comp.unix.bsd.openbsd.misc pakrat@localhost.private.neotoma.org wrote:
> On 05 Sep 2006 13:40:01 GMT in <44fd7e30$0$65767$dbd45001@news.wanadoo.nl> jKILLSPAM.schipper@math.uu.nl <jKILLSPAM.schipper@math.uu.nl> wrote:
>> In comp.unix.bsd.openbsd.misc Tim Bradshaw <tfb+google@tfeb.org> wrote:
>>> jKILLSPAM.schipper@math.uu.nl wrote:
>>>> In comp.unix.bsd.openbsd.misc Rich Teer <rich.teer@rite-group.com> wrote:
>> What you describe would most likely be taken care of using per-process
>> limits, priorities, jails (chroot, systrace, or whatever happens to
>> work), separating stuff onto multiple servers, and adding in various
>> forms of redundancy (which can be very easy or very difficult;
>
> Jails suffer from the problem that non-technical people don't understand
> them.
> They can follow "We're going to split this big machine into thinking its
> lots of little ones," after they dust off some of their mainframe guys.

OpenBSD isn't for non-technical people. This is made quite clear by
developers and quite a few of their users alike; while this has given
the OpenBSD community a (sometimes, well-deserved) reputation for being
rude and arrogant, it has also lead to OpenBSD remaining a system that
would rather be correct than popular.

>> redundantly serving static web pages is trivial, synchronizing databases
>> is not easy, especially when you want to get some performance out of it
>> too, and I'm not aware of any way to get redundant mail storage, even
>> though this should not be too difficult in theory).
>
> *cough* Bloated Chokes^W^WLotus Notes *cough*.
> (So they advertise, so IT claims. I've found that mail is unavailable an
> order of magnitude more frequently when they implement it).

You are right, I forgot all about Lotus. Not that I'm very inclined to
try it, given the many bad stories I hear...

>> However, when push comes to shove, Solaris and OpenBSD have different
>> target markets. For instance, I am very happy with the way OpenBSD
>> handles a couple of mostly idle servers and a firewall on the ancient
>> hardware my students' association has available; running Solaris on
>> these would be possible [1], especially with OpenSolaris, but it
>> wouldn't be my first choice even if I wasn't already familiar with
>> OpenBSD.
>
> Let's put it another way. Solaris and OpenSolaris have marketing budgets
> that can get you a free lunch a couple times a year ;-)

Only when your budget is sufficient that such lunches would not be felt
in the first place. Said students' association's budget is pitiful.

Finally, Sun isn't all that 'open' - while a lot has changed for the
better, I find OpenBSD's much more ideological stance charming.

>> Plus, OpenBSD's reputation for security is well-deserved. This is not to
>> say that Solaris scores all that badly, but from the cursory look at
>> security sites I've had, it's not quite as good.
>> Linux, though, sucks. When your maximum uptime is two weeks because you
>> can't go longer without having to recompile a new kernel, something is
>> wrong.
>
> You're mistaking gentoo users with enterprise Linux offerings.
> I'll give you a hint. Some major routing parts of US telecomm now run
> on Linux. Those systems (stock PCs, except for the 48VDC power supplies)
> will be rebooted only for the next major software release or power event.
> If you want to do the gentoo thing with OpenBSD, you're perfectly free
> to play with snapshots or grab HEAD from CVS and upgrade as frequently
> as you like.

Yes, I do mostly run -current. Not on production servers, though.

That does not change the fact that a more-or-less standard Linux
install, especially one which makes use of modern, neat features
(especially the 2.6 kernel, it seems, though things have gotten better),
needs a new kernel quite frequently, IME.

Looking at a list like Securityfocus', I can see quite a few
vulnerabilities that would not concern us, but there are also quite a
few that could cause at least a nasty DoS.

This is not to say that Linux *can't* be stable, (quite) secure, and
reliable for long stretches of time - but I find that getting a
comparable result is easier for me on OpenBSD.

Also, my opinion here is a little colored by the fact that I finally
jumped ship (converted the last system) about the time people were
questioning the viability of the 2.6 line, precisely because of the fact
that, for a short time, new vulnerabilities did indeed come out about
twice per month, if not more.

Joachim

In comp.unix.bsd.openbsd.misc Rich Teer <rich.teer@rite-group.com> wrote:
> On Tue, 5 Sep 2006, jKILLSPAM.schipper@math.uu.nl wrote:
>> Nice. Not necessarily useful, but thoroughly nice.
>
> Heh, I take it you've not done much enterprise class computing. :-)
>
> In an environment where downtime is not only inconvenient, it is
> also extremely expensive, hot swappable CPUs are not only useful,
> they're almost a requirement.
>
> The thought of incurring hundreds of thousands of dollars of costs
> due to downtime "just" to replace a CPU is not very paletable in
> those enterprise environments. The same also applies for upgrades:
> the ability to add CPU/memory resources to a running system can also
> save huge amounts of cash.

You are very right. Then again, I strive hard to not earn my money doing
this [1], and that pretty much precludes getting my hands on a big
enough budget to do this kind of thing.

For what I _do_ do, OpenBSD is very well suited; and let's not forget
that OpenBSD has several places, even in a big enterprise, where it
would be very welcome; it's capacities as a firewall cannot be
underestimated, and it's excellent security track record is helpful in
many positions.

Running it on big iron probably isn't the smartest move one could make,
though.

Joachim

[1] Frankly, I find other things more challenging and eventually, more
fulfilling. Like maths and, in a different way, politics.

Begin <slrneftlpp.51g.pakrat@vm01.raleigh.neotoma.org>
On 2006-09-06, pakrat@localhost.private.neotoma.org
<pakrat@localhost.private.neotoma.org> wrote:
> On 5 Sep 2006 23:21:58 GMT in <4m6f4mF4qmatU1@individual.net>
> jpd <read_the_sig@do.not.spam.it.invalid> wrote:
>> Begin <slrnefr1gc.315.pakrat@vm01.raleigh.neotoma.org>
>> On 2006-09-05, pakrat@localhost.private.neotoma.org
>><pakrat@localhost.private.neotoma.org> wrote:
>>>
>>> IBM seems to be tossing money into such work with Linux/Xen.
>>> Intel and AMD seem to be tossing money into hardware to make this easier
>>> to accomplish with their CPUs.
>>
>> Which for IBM is a bit ironic, IMO...
>
> Anyone that thinks that IBM has a unified direction has had a case
> of cranial rectal inversion ATLEAST since the 5150 was released.
> Now that IBM is largely services and works for hire, things are even
> more schizophrenic.

Not that they never made a mistake. Not making up their minds about
placement of the 615[01], for example. Or the VM cruft in there. Nice
experiment, but back then a bit premature.


>>> At current moment IBM does not make any non-blade pSeries systems that
>>> are not capable of such partitioning.
>>
>> ... and this is why. Not to mention BIG iron.
>
> I presently deal with pSeries big, middle, and small iron.
> I'm more impressed with partitioning with VIO on the middle and small iron
> than on the big iron. I could be jaded because it requires significantly
> fewer people in the meeting for a firmware upgrade, or memory replacement
> on the small and medium iron.
> And we won't go into power and physical structure requirements for big iron.

I'll go with jaded. I fully agree that smaller and simpler does have its
upsides, but reinventing badly instead of engineering the feature so
it'll work in a smaller box too, could use improvements. 'Sides, the big
stuff still tends to get features first and also because of that needs
to guard against teething problems more heavily.


> There's just someone wrong when they start offering liquid cooled chiller
> doors for the boxes. Doubly wrong if you saw the sales spike when s/390
> went CMOS and could be air cooled.

Then again, some people seem to think their peecee isn't worth a thing
if it doesn't have liquid cooled CPUs AND GPUs AND cooling fans on
the memory sticks. AND a bunch of otherwise useless lights stuffed in
improbable places. AND... well, you get the picture.

Liked the e10k casemod though.


> Unless IBM outsources the design and manufacturing of the xSeries
> box and it doens't have light path diagnostics.

Could just as well've gotten a dell then. Oh well.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

pakrat@localhost.private.neotoma.org wrote:

> Jails suffer from the problem that non-technical people don't understand
> them.
> They can follow "We're going to split this big machine into thinking its
> lots of little ones," after they dust off some of their mainframe guys.

They also don't do the same thing as domains. Domains are real
physical (well, nearly physical) divisions of the system. Domains can
run different OS major releases, and frequently do. I see no reason
why two domains on a box should not run entirely different OSs. A
domain can crash without another domain even knowing. Zones (which are
more than jails, but the nearest equivalent) all share the same OS
image with all that implies: they are much more efficient in terms of
resources, but the divisions between them are much thinner, and you
can't do the completely-different-OS trick.

> *cough* Bloated Chokes^W^WLotus Notes *cough*.
> (So they advertise, so IT claims. I've found that mail is unavailable an
> order of magnitude more frequently when they implement it).

All the places I've been the solution to HA mail is a cluster sharing
some ultra-reliable (they hope) SAN storage.

--tim