SEO

Now that Solaris is migrating the init
scripts to "services",
I am wondering if they are
an improvement.

UNIX originally was characterized as simple and elegant.

Services seem like neither.

Are services an improvement? I suppose it might turn out
to be useful to centralize the administration of
startup processes.

Anybody using this in production?

..

<greek_philosophizer@hotmail.com> wrote in message
news:1115748268.863774.68400@f14g2000cwb.googlegro ups.com...
> Now that Solaris is migrating the init
> scripts to "services",
> I am wondering if they are
> an improvement.
>
> UNIX originally was characterized as simple and elegant.
>
> Services seem like neither.
>
> Are services an improvement? I suppose it might turn out
> to be useful to centralize the administration of
> startup processes.
>
> Anybody using this in production?
>
> .
>

Right off the bat after installing solaris 10 the first thing I noticed was
the insanly fast boot time, because services can now run in parrallel, boot
time has increased greatly.

SMF makes overall system management a breeze enable/disabling services is
such a snap, prior to solaris 10 trying to figure out the right combination
of services and what depencies they were link with was a bit tedious.

Its just a matter of time before more and more Unix and Unix like OS's adopt
a service management type facility, if you've used SUSE they already bundle
a tool that kind of handles disabling and start of services for you that
tool is called YAST and ask anyone who has to manage SUSE servers YAST makes
administation alot simpler.

I see this no different that what package managers did for Operating systems
a few years back.
Let SMF grow on you, you will love it.

--
Rodrick R. Brown
Unix Systems Administrator
rodrick.brown[@]gmail.com

--
RB

greek_philosophizer@hotmail.com sez:
> Now that Solaris is migrating the init
> scripts to "services",
> I am wondering if they are
> an improvement.
>
> UNIX originally was characterized as simple and elegant.

If by "simple and elegant" you're referring to /etc/rc.boot script,
then no, services are definitely not an improvement over a single
monolithic shell script.


....I suppose it might turn out
> to be useful to centralize the administration of
> startup processes.

Yeah, apparently it kinda did, when they tried it all those years ago.

Dima
--
.... with the exception of January and February 1900, all Microsoft application
libraries counted dates the same way.
-- An Interview with Joel Spolsky of JoelonSoftware

Dimitri Maziuk wrote:
> greek_philosophizer@hotmail.com sez:

>>Now that Solaris is migrating the init
>>scripts to "services",
>>I am wondering if they are
>>an improvement.
>>
>>UNIX originally was characterized as simple and elegant.

> If by "simple and elegant" you're referring to /etc/rc.boot script,
> then no, services are definitely not an improvement over a single
> monolithic shell script.

I agree that just a monolithic shell script is simple at first, but what
happens when you try to maintain it? What happens when you have 100
hosts and you want to disable some service on all of them? With a
single rc.boot (and rc.local), you've got a complicated text-editing
task, whereas with a system where every service is a separate shell
script (or is modular in some fashion), it's a million times easier
to automate this.

To put it more succinctly, what is the /etc/rc.boot equivalent of
"cd /etc/rc2.d && mv S74xntpd disable_S74xntpd"? The answer is that
in some special cases there is a way to easily disable a service
started by /etc/rc.boot (such as renaming its config file so it
doesn't find it), but in the general case, it's much more of a pain.

By the way, AIX has had something like this for about 10 years:
"startsrc" to start a subsystem, "stopsrc" to stop one, "lssrc"
to list them, etc. For example, "startsrc -s lpd" starts up lpd.

- Logan

In comp.unix.solaris Dimitri Maziuk <dima@127.0.0.1> wrote:
> greek_philosophizer@hotmail.com sez:
>> Now that Solaris is migrating the init
>> scripts to "services",
>> I am wondering if they are
>> an improvement.
>>
>> UNIX originally was characterized as simple and elegant.

> If by "simple and elegant" you're referring to /etc/rc.boot script,
> then no, services are definitely not an improvement over a single
> monolithic shell script.

Depends on your metric...

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Seems kinda M$ window-ish to me.

my 2 cents.

In comp.unix.solaris kirkgbr@yahoo.com wrote:
> Seems kinda M$ window-ish to me.
>
> my 2 cents.

Overpriced, for a statement that bald. :-)

But I understand the feeling. One of the core features of Unix has always
been "everything in plaintext, wherever possible." Seeing the horrible
disaster that was the Windows Registry and similarly the AIX ODM (which I
understand is at least usable now), convinced me even more that this was a
good and necessary thing.

However, the SMF model provides a new layer of functionality that wouldn't
be possible with the old /etc/init.d scripts. The dependency trees, the
parallelism, and the inherent fault tolerance are huge benefits--necessary
to make an OS as reliable as the hardware we're getting these days.

I'm curious about what happens when the repository gets trashed. With
text files, you can edit them by hand. What will we do to repair the
system in this case? (BESIDES backups, of course!)

Colin

Logan Shaw sez:
> Dimitri Maziuk wrote:
>> greek_philosophizer@hotmail.com sez:
>
>>>Now that Solaris is migrating the init
>>>scripts to "services",
>>>I am wondering if they are
>>>an improvement.
>>>
>>>UNIX originally was characterized as simple and elegant.
>
>> If by "simple and elegant" you're referring to /etc/rc.boot script,
>> then no, services are definitely not an improvement over a single
>> monolithic shell script.
>
> I agree that just a monolithic shell script is simple at first, but what
> happens when you try to maintain it?

You missed the X-sarcasm tags.
HTH

Dima
--
True courage comes from steadying yourself and forcing yourself to ssh into the
fscking thing yet again and not admitting that it doesn't care what it's done
to your life. -- "Hidden among the nodes" by ADB

"Colin B." <cbigam@somewhereelse.nucleus.com> wrote in message
news:428129e5@news.nucleus.com...
> But I understand the feeling. One of the core features of Unix has always
> been "everything in plaintext, wherever possible." Seeing the horrible
> disaster that was the Windows Registry and similarly the AIX ODM (which I
> understand is at least usable now), convinced me even more that this was a
> good and necessary thing.

Isn't SMF actually based on XML description files? (Correct me if I'm
wrong).

XML *is* just plain text. With the advantage that it is a structured
document so it's easy to understand and manage by both a human and a
machine.

--
Andrea Sansottera

"Andrea Sansottera" <andrea.sansottera@fastwebnet.it> writes:
> Isn't SMF actually based on XML description files? (Correct me if I'm
> wrong).

Yes. But the repository itself isn't documented. You have to
interact with it using the svcadm/svccfg tools.

> XML *is* just plain text. With the advantage that it is a structured
> document so it's easy to understand and manage by both a human and a
> machine.

True, but unless it's actually documented as something you can rely on
in a man page, you shouldn't be modifying arbitrary things in the
system or building tools that rely on how those things work. They can
change incompatibly at any time, including in patches, and without
warning.

Only the things documented for use are supported as administrative
interfaces.

--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677