> Ok, so I've seen all the fussing concerning reading
> documentation. Some people clearly ignore
> documentation, and just come asking for help,
> expecting people to tell them everything step by
> step, and hold their hand the whole way. I'm not
> concerned with pointing those people to docs.sun.com.
I agree. The only problem is that we get the same questions over and over and
they could really be easily resolved by 'warming up the chair' a little bit.
I've got no problem sharing knowledge, but it's really not correct when you
spend your time 'doing your homework' and then someone else comes along and
asks you to hand over your work so that they could just copy it.
It would also seem that people are unaware that there is such a great wealth of
useful information on docs.sun.com.
What I'm doing here is trying to raise awareness along the lines of
[I]give a man a fish, feed him for a day, teach him how to fish, feed him for a
lifetime[/I].
> I'm a new person to Solaris, so please excuse me.
> I've grown up on linux/freebsd/beos/so forth, from
> the .99 pre days of linux and so on, back when there
> was very little documentation and also extremely few
> users to ask for help.
Well, to be just, BSD has some great documentation of high quality. My only
suggestion would be to make it more structured.
> Yet, having spent the last decade in the
> linux/freebsd/etc world, I've yet to have many simple
> (at least I think so) questions answered concerning
> *how* to do things the _right way_ in Solaris. I've
> hit freenode, docs.sun.com, etc, to no avail. Maybe
> I'm just a complete idiot when it comes to searching,
> but I don't even know what exactly I should be
> searching for!
That's a tough problem to overcome, to be sure. In my experience, the key is
understanding of concepts which make the foundation of UNIX, in this case
Solaris. Working with other SVR4/POSIX compliant UNIXes makes things really
start falling into perspective. One can then easily spot the principles of SVR4
and POSIX.
> One of the biggest problems I encountered when
> evaluating Solaris for a large datacenter deployment:
> I could not find a single person/could not find in
> the documentation exactly how I was supposed to go
> about adding software (such as apache 2/php5/etc, and
> I don't mean outdated versions. I realize there is
> the whole "use the version that's been tested 8
> bazillion times" mentality, but as I'm planning to
> use Solaris in an environment where sometimes new
> features are more important than 3 years of stability
> testing, I often need newer software than is provided
> with Solaris 10) to the system.
> I recieved a lot of "use blastwave" "use sunfreeware"
> responses, neither resource I care for (no offense to
> the projects, they just aren't my personal choice.)
I honestly can't say that I blame you.
[B]Sunfreeware[/B] is just plain BUSTED because Steve Christensen doesn't
really understand how to package software, to be more precise, [I]he does not
understand how to engineer software packages[/I].
Sun clearly states in their [B]Application Packaging Developer's Guide[/B] how
packages should be designed and what to watch out for, but apparently he either
didn't pay attention or he just blatantly disregarded it.
[B]Blastwave[/B] shows real promise. I commend Dennis, Phil and the rest of the
crew for a near herculean effort, and the guys are really starting to move in
the right direction with the stable quarterly releases (BTW, SGI has this
process perfected), but there's still a lot of engineering missing from
Blastwave packages. Blastwave seems to have a problem with insane/inconsistent
dependencies and quality control, plus they don't abide by the SVR4/POSIX
mandate as far as the FileSystem layout and third party unbundled software
mandate from Sun. This has been raised before.
So, what's a guy to do? If you're the kind of person that pays attention to
detail, then the only thing left is to start soaking up the [I]Application
Packaging Developer's Guide[/I] (again on docs.sun.com of course), and start
engineering your own packages. That includes getting the code to compile,
regression testing, packaging, then finally product testing and acceptance.
Problems start when the code is Linux-centric, and breaks on anything else,
Solaris included. Then the next problem is actually packaging the code, because
one has to actually do a `make install`, which of course causes the system to
become 'dirty'. There are some elegant solutions to this last dilemma, but
we'll revisit that below.
> I've hand compiled/built everything, including all
> dependancies required by them, simply because I
> couldn't find a solution. This creates a HUGE
> headache anytime there is a security update released
> for ANY of the software, I have to go download the
> updated source/patches/so forth, and rebuild
> EVERYTHING one by one, making sure I get it all
> installed properly without messing up this or that.
> Imagine trying to do this by hand on 100 systems, as
> you said, this is NOT the right way to go about
> things. It's painfully obvious.
Welcome to the world of system engineering!
Yes, you're quite right in your observation. But since you already observed
this, you're well on your way to truly mastering system administration and then
later on, system engineering.
The real problem is, [I]how do you convey this crucial concept to people who
have no experience running a data center?[/I] One usually argues that by only
one or a few machines that'll never be a problem. But, a lot of these people
tend to land sysadmin jobs down the road and do the same things they 'do at
home'.
Then we have the other group "well I'm just learning", but [I]you're learning
it wrong[I], then later on, you implement "what you've learned". But the
implementation turns out to be a hack, however the implementor is blissfully
unaware of any such fact. He just knows he's drowning in work every day, and
has now lost the time to step back and find out why he's drowning.
Needless to say, come quitting time, the next guy that comes along will step
right into quicksand.
> Maybe it's contained in the docs, and maybe you can
> tell me exactly where, but the major problem I have
> is simply finding what I need in them! The
> documentation is excellent, I have undoubtably found
> the answer to MANY of my own questions digging
> through them. However, there are very general/basic
> things concerning the usage of Solaris that I am just
> unable to effectively locate. Mostly concerning to
> the "right way" to do things. You're preaching the
> "right way" now, and while I can respect your
> insistance on doing things in a clean/structured way,
> I think you'd promote doing things the "Right Way" a
> lot more effectively if you simply drew up a nice
> "howto" on the "right way" of doing things, and
> posted a link whenever you felt the urge to lambast
> somebody for not knowing the "right way" of doing
> things. Generally, positive corrections are accepted
> over negative criticism.
In this case, 'the clean way' would be:
a) create a dedicated directory in /export, for example /export/scratch ("why
should I use /export, and not some other arbitrary mount point / directory?"
would be a good way to 'step back' and think about things. Perhaps a hint can
be gleaned from the documentation. "What is /export designed for?")
b) read and understand the "Application Packaging Developer's Guide". Make some
"test packages" with one or two files to learn how it works.
c) get the software to compile.
d) try to optimize the compilation:
"Improving Code Layout Can Improve Application Performance" by Darryl Grove
at
http://developers.sun.com/prodtech/cc/articles/codelayout.html
is simply great stuff packed with tons of useful information.
e) time to package. Write a generic package template which can be easily
edited. Building could be automated and simplified with `make`, which is an
ingenious tool. Any time invested in learning to use `make` is returned tenfold
or even hundredfold. Otherwise, just copy the "pkginfo" and other package
templates and edit them manually. This is probably the simplest thing to do at
the beginning while you're still learning.
Sooner or later you'll hit the `make install` part, which pollutes the
consistency of a system. How do you work around that? It turns out Solaris
already provides the facilities to do it. As it turns out, we can trick `make
install` with some clever and 'creative' use of lofs(7FS), the loopback virtual
FileSystem. (`man lofs` might do good at this point.)
So, let's create our sandbox in which to install:
mkdir -p /export/scratch/opt/php-5.0/ /export/scratch/etc/opt/php-5.0/
/export/scratch/var/opt/php-5.0/
The above [I]directory structure[/I] assumes one has compiled the software with
the right prefixes, for example
./configure --prefix=/opt/php-5.0/ --confdir=/etc/opt/php-5.0/
--datadir=/export/php-5.0/ --logdir=/var/opt/php-5.0/ && make
Notice how we're trying to adhere to SVR4/POSIX/Sun mandate in laying out our
directory structure?
To be really clean, we should have done something along the lines of:
/opt/SUNWphp/5.0/
/etc/opt/SUNWphp/5.0/
/var/opt/SUNWphp/5.0/
/var/opt/run/SUNWphp/5.0/
/export/SUNWphp/5.0/
or we could have also done:
/opt/SUNW/sbin/
/opt/SUNW/bin/
/opt/SUNW/share/man/
/opt/SUNW/...
/var/opt/SUNW/...
/etc/opt/SUNW/...
Where "SUNW" would have been replaced by the "stock symbol of the company". For
example, "Blastwave" uses "csw" (although it should really be "CSW").
Now that we have our directory structure, it's time for some magic:
mount -F lofs /export/scratch/opt /opt
mount -F lofs /export/scratch/var /var
mount -F lofs /export/scratch/etc /etc
make install
umount /export/scratch/opt
umount /export/scratch/var
umount /export/scratch/etc
Now look into /export/scratch/. `make` "magically" installed all the files
there. From this point on, it's a walk in the park to package the software, and
start testing the package...
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
