Xymon Mailing List Archive search

hobbit documentation and packaging projects

6 messages in this thread

list T.J. Yang · Tue, 24 May 2005 10:47:44 -0500 ·
Hi, there

In the long run (before I died ;), I plan to migrate my bb system monitoring environment to hobbit given its open-source license and availability of  cookit provides commercial support.

Following items that need to be done and I am willing to help on

1. Digitalize the hobbit compilation and packaging  process for different Unixen.
    So we don't need keep answering how to compile hobbit on ??? platform issues.

2. Set up a hobbit wiki page/book  (on mediawiki ?)
    I like mediawiki because there is a command line client in perl to
   automate the wikipage update.

3. Prepare the hobbit document in docbook format ?
    The docbook format is the final resting place of hobbit wiki.
    So we can generate pdf and rtf  easily.

I have experience on above three tasks, just need to hear a few voices to
tell me to jump on these tasks ;)

Seriouslly, please follow up this thead to let me know your comment.
Should I spend the efforts on these tasks ? Are you willing to help etc...


T.J. Yang
list Henrik Størner · Tue, 24 May 2005 22:38:02 +0200 ·
quoted from T.J. Yang
On Tue, May 24, 2005 at 10:47:44AM -0500, T.J. Yang wrote:
Following items that need to be done and I am willing to help on

1. Digitalize the hobbit compilation and packaging  process for different 
Unixen.
   So we don't need keep answering how to compile hobbit on ??? platform 
issues.
I may be biased, but I don't think there's been that many "silly"
questions about how to build Hobbit. Most of the cases that have been
real issues have been due to my failure to write truly portable code,
and they have been dealt with by fixing the code.

The few things that have been truly platform-specific - like the HP-UX
compiler bug that was brought up yesterday - is something that should
be documented.

Building "shrink-wrap" packages of Hobbit is something that I do for my
personal use (it's just the easiest way to install it on many systems).
And for the not-quite-so-experienced admin out there I think they are
really useful to get something up and running quickly and get off to a
good start with using Hobbit, instead of struggling for a couple of days
with the fine details of configure, make etc.  So there are Linux based 
packages in deb- and rpm-format. I know there are NetBSD packages of 
Hobbit available, and I wouldn't be surprised if someone was working on 
putting it into the FreeBSD "ports" collection.  But I also think that 
most of the die-hard sysadmins here actually prefer to build from source :-)
quoted from T.J. Yang

2. Set up a hobbit wiki page/book  (on mediawiki ?)
   I like mediawiki because there is a command line client in perl to
  automate the wikipage update.

3. Prepare the hobbit document in docbook format ?
   The docbook format is the final resting place of hobbit wiki.
   So we can generate pdf and rtf  easily.
I know there was/is a Wiki for BB. If you feel it would be useful for
Hobbit, go ahead - it's not a format I use very much. Probably just 
me being old-fashioned - e-mail and newsgroups are my preferred
communication methods.
quoted from T.J. Yang
Seriouslly, please follow up this thead to let me know your comment.
Should I spend the efforts on these tasks ? Are you willing to help etc...
I really appreciate your willingness to undertake some work on Hobbit,
especially with documentation which most programmers really try to
avoid. I do write documentation, but I may be an exception - it's simply
because when the documentation exists, I get more time to do the
interesting stuff (code) since I don't have to spend so much time
answering questions.

But before you embark on this, ask yourself: What problem will I solve
by doing this ? Setting up a Wiki is fine - but only if it gets used.
For that to happen, there must be stuff there that people want to read.
So what's missing today - is it the "beginners guide to monitoring your
network" ? Or a "How to monitor your datacenter and survive" guide ?
Or maybe a "Building graphs for your Boss" description?

I guess, what I'm trying to say is that you should narrow your focus
- at least to begin with. Then, when you have something going, you can
broaden the scope.


Henrik
list Vernon Everett · Wed, 25 May 2005 08:06:05 +0800 ·
I'm in. 
Never built any packages but I can find out how. (Used to work for Sun,
and still have a few contacts there)

I am keen on getting some (l)user documentation up and running.
It would be nice to have a "connect-the-dots" type of how-to and a more
extensive FAQ.
Anybody who has been on this list a while can probably help with the
FAQ. There has to be certain "How do I ....." questions that appear more
often than others.

Cheers
    V.
quoted from T.J. Yang

-----Original Message-----
From: T.J. Yang [mailto:user-8e841282cda5@xymon.invalid] 
Sent: Tuesday, 24 May 2005 11:48 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: [hobbit] hobbit documentation and packaging projects

Hi, there

In the long run (before I died ;), I plan to migrate my bb system
monitoring 
environment to hobbit given its open-source license and availability of

cookit provides commercial support.

Following items that need to be done and I am willing to help on

1. Digitalize the hobbit compilation and packaging  process for
different 
Unixen.
    So we don't need keep answering how to compile hobbit on ???
platform 
issues.

2. Set up a hobbit wiki page/book  (on mediawiki ?)
    I like mediawiki because there is a command line client in perl to
   automate the wikipage update.

3. Prepare the hobbit document in docbook format ?
    The docbook format is the final resting place of hobbit wiki.
    So we can generate pdf and rtf  easily.

I have experience on above three tasks, just need to hear a few voices
to
tell me to jump on these tasks ;)

Seriouslly, please follow up this thead to let me know your comment.
Should I spend the efforts on these tasks ? Are you willing to help
etc...


T.J. Yang


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

NOTICE: This message and any attachments are confidential and may contain copyright material 
of Australian Finance Group Limited or a third party. It is intended solely for the purpose of the 
addressee and any other named recipient. If you are not the intended recipient, any use, 
distribution, disclosure or copying of this message is strictly prohibited. The confidentiality attached
to this message is not waived or lost by reason of the mistaken transmission or delivery to any 
unintended party. If you have received this message in error, please notify the author immediately or 
contact Australian Finance Group on +61 8 9420 7888.
list T.J. Yang · Tue, 24 May 2005 19:46:34 -0500 ·
quoted from Henrik Størner
From: user-ce4a2c883f75@xymon.invalid (Henrik Stoerner)
Reply-To: user-ae9b8668bcde@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] hobbit documentation and packaging projects
Date: Tue, 24 May 2005 22:38:02 +0200

On Tue, May 24, 2005 at 10:47:44AM -0500, T.J. Yang wrote:
Following items that need to be done and I am willing to help on

1. Digitalize the hobbit compilation and packaging  process for 
different
Unixen.
   So we don't need keep answering how to compile hobbit on ??? platform
issues.
I may be biased, but I don't think there's been that many "silly"
questions about how to build Hobbit. Most of the cases that have been
real issues have been due to my failure to write truly portable code,
and they have been dealt with by fixing the code.
There are not many silly questions because I was not on this email list ;)
You alread answered one silly question regarding to hobbit/man has html 
version
of manpage.
quoted from Henrik Størner
The few things that have been truly platform-specific - like the HP-UX
compiler bug that was brought up yesterday - is something that should
be documented.
Even it is fully documented, it is still need to be read and typed by
my fat fingers.  My goal is to autmoated the process as much as possible.
quoted from Henrik Størner

Building "shrink-wrap" packages of Hobbit is something that I do for my
personal use (it's just the easiest way to install it on many systems).
And for the not-quite-so-experienced admin out there I think they are
really useful to get something up and running quickly and get off to a
good start with using Hobbit, instead of struggling for a couple of days
with the fine details of configure, make etc.  So there are Linux based
packages in deb- and rpm-format. I know there are NetBSD packages of
Hobbit available, and I wouldn't be surprised if someone was working on
putting it into the FreeBSD "ports" collection.  But I also think that
most of the die-hard sysadmins here actually prefer to build from source 

:-)
I am planning to deploy hobbit at work and we expect SMS(win32) type
of application on our Unix environment. for that to happen we need
to package server and client packges.

When this is done, the software,package build and package deployment
process will be automated just like our other applications.

I will release the package sources if hobbit community is interested.
anyone can build the hobbit package from source and customize
it at your pleasure.


For example, "gmake hobbit-4.0.3-clean;gmake hobbit-4.0.3" will
compile hobbit and its depended other software (ssl,ldap,pcre ...)
and then generate a rpm on rhlinux,a pkgadd on solaris and a depot
if run the above gmake command on hpux.
quoted from Henrik Størner

2. Set up a hobbit wiki page/book  (on mediawiki ?)
   I like mediawiki because there is a command line client in perl to
  automate the wikipage update.

3. Prepare the hobbit document in docbook format ?
   The docbook format is the final resting place of hobbit wiki.
   So we can generate pdf and rtf  easily.
I know there was/is a Wiki for BB. If you feel it would be useful for
Hobbit, go ahead - it's not a format I use very much. Probably just
me being old-fashioned - e-mail and newsgroups are my preferred
communication methods.
Seriouslly, please follow up this thead to let me know your comment.
Should I spend the efforts on these tasks ? Are you willing to help 
etc...
I really appreciate your willingness to undertake some work on Hobbit,
especially with documentation which most programmers really try to
avoid. I do write documentation, but I may be an exception - it's simply
because when the documentation exists, I get more time to do the
interesting stuff (code) since I don't have to spend so much time
answering questions.
I really appreciate your willingness to underake the work to make bb 
open-source
and alive again ;) Better yet, you fix the BB's performance and other 
issues.

For that I am willing to pick up the missing parts of work haven't done yet.
quoted from Henrik Størner

But before you embark on this, ask yourself: What problem will I solve
by doing this ? Setting up a Wiki is fine - but only if it gets used.
For that to happen, there must be stuff there that people want to read.
So what's missing today - is it the "beginners guide to monitoring your
network" ? Or a "How to monitor your datacenter and survive" guide ?
Or maybe a "Building graphs for your Boss" description?
Build it  and they will come.

http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit

Pardon the dust, it is created today and still fresh.
quoted from Henrik Størner
I guess, what I'm trying to say is that you should narrow your focus
- at least to begin with. Then, when you have something going, you can
broaden the scope.
Thanks for advice, I am taking notes.


tj
Henrik

list Vernon Everett · Wed, 25 May 2005 09:02:37 +0800 ·
Hi Henrik

A documentation project would serve multiple purposes.
1. By documenting something, you reinforce your own knowledge of what
you 
   document. (Something a few of us could use)
2. If it is used, it would leave you with more time for interesting
stuff
   like coding :) which will give you time to create an even better
product
   instead of wasting time answering e-mails from people like myself who

   didn't bother to RTFM properly. (See quotes below.)
3. It makes it easy for anybody - even junior sys-admins to implement
Hobbit
4. By making things really easy, you increase adoption. I have abandoned

   many tools in the past simply because they are too poorly documented
to
   be easily implemented. This will increase your user-base.
5. Right now, a mailing list and e-mail is easy to manage. But how many 
   sites out there run Hobbit? What happens to your coding time when
that 
   doubles? Triples? Increases tenfold? 

Don't get me wrong, I love the cosy feeling you get from a mailing list.
I also love ribbing the Microsoft guys in the office when I get e-mail
from the author of the product giving me assistance. I always tell them
"Let's see you do that with Micro$oft". :-) But like any other open
source product out there, to really grow, it needs better docs.
Where would Linux be if it weren't for those handy How-to docs?

Nobody is expecting you (Henrik) to do all the documentation. There are
plenty of us out there who have sufficient knowledge to contribute to a
documentation project, and even more who would benefit from it.

Documentation projects I see as being really useful.
1. Basic FAQ (Anybody can contribute to this, just by providing the Q)
2. Setting up your own tests (How-to)
3. Creating custom graphs (How-to)
4. Simple setup guide. Most users would be sys-admins, so we don't need
much 
   help there , but we all have areas of speciality and ignorance. As an

   example, I struggled to get the web pages right, but only I have
never 
   set up a web server before.
5. A detailed trouble-shooting guide. (Something most products don't
have)
   Most products have a good how-to, but nothing detailing what to do if

   something doesn't work, or goes wrong.
6. A list of bb scripts "converted" to work on hobbit. If you had to
modify 
   any bb scripts from deadcat to work correctly with Hobbit, what did
you 
   do, and why.
7. There's probably a hell of a lot more, but I have only had 2 double 
   espressos this morning, so I am still struggling to think properly.
(Time 
   for another 2)

A number of these can be explained by doing an RTFM on man pages for
Hobbit, LARRD, rrdtool etc. etc. and then trying to tie the knowledge
together.
However it would be a lot easier and more efficient to create a new doc,
detailing just the bits of each that we need to run Hobbit effectively

Cheers
    V

Motivational quotes for this project :-)

People do not cooperate under the division of labour because they love
or should love one another. They cooperate because this best serves
their own interests. Neither love nor charity nor any other sympathetic
sentiments but rightly understood selfishness is what originally
impelled man to adjust himself to the requirements of society, to
respect the rights and freedoms of his fellow men and to substitute
peaceful collaboration for enmity and conflict.
- Ludwig von Mises

It is not from the benevolence of the butcher, the brewer, or the baker,
that we expect our dinner, but from their regard to their own interest. 
- Adam Smith
quoted from T.J. Yang


-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] 
Sent: Wednesday, 25 May 2005 4:38 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] hobbit documentation and packaging projects

On Tue, May 24, 2005 at 10:47:44AM -0500, T.J. Yang wrote:
Following items that need to be done and I am willing to help on

1. Digitalize the hobbit compilation and packaging  process for
different 
Unixen.
   So we don't need keep answering how to compile hobbit on ???
platform 
issues.
I may be biased, but I don't think there's been that many "silly"
questions about how to build Hobbit. Most of the cases that have been
real issues have been due to my failure to write truly portable code,
and they have been dealt with by fixing the code.

The few things that have been truly platform-specific - like the HP-UX
compiler bug that was brought up yesterday - is something that should
be documented.

Building "shrink-wrap" packages of Hobbit is something that I do for my
personal use (it's just the easiest way to install it on many systems).
And for the not-quite-so-experienced admin out there I think they are
really useful to get something up and running quickly and get off to a
good start with using Hobbit, instead of struggling for a couple of days
with the fine details of configure, make etc.  So there are Linux based 
packages in deb- and rpm-format. I know there are NetBSD packages of 
Hobbit available, and I wouldn't be surprised if someone was working on 
putting it into the FreeBSD "ports" collection.  But I also think that 
most of the die-hard sysadmins here actually prefer to build from source

:-)
quoted from T.J. Yang

2. Set up a hobbit wiki page/book  (on mediawiki ?)
   I like mediawiki because there is a command line client in perl to
  automate the wikipage update.

3. Prepare the hobbit document in docbook format ?
   The docbook format is the final resting place of hobbit wiki.
   So we can generate pdf and rtf  easily.
I know there was/is a Wiki for BB. If you feel it would be useful for
Hobbit, go ahead - it's not a format I use very much. Probably just 
me being old-fashioned - e-mail and newsgroups are my preferred
communication methods.
Seriouslly, please follow up this thead to let me know your comment.
Should I spend the efforts on these tasks ? Are you willing to help
etc...
I really appreciate your willingness to undertake some work on Hobbit,
especially with documentation which most programmers really try to
avoid. I do write documentation, but I may be an exception - it's simply
because when the documentation exists, I get more time to do the
interesting stuff (code) since I don't have to spend so much time
answering questions.

But before you embark on this, ask yourself: What problem will I solve
by doing this ? Setting up a Wiki is fine - but only if it gets used.
For that to happen, there must be stuff there that people want to read.
So what's missing today - is it the "beginners guide to monitoring your
network" ? Or a "How to monitor your datacenter and survive" guide ?
Or maybe a "Building graphs for your Boss" description?

I guess, what I'm trying to say is that you should narrow your focus
- at least to begin with. Then, when you have something going, you can
broaden the scope.


Henrik


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

NOTICE: This message and any attachments are confidential and may contain copyright material 
of Australian Finance Group Limited or a third party. It is intended solely for the purpose of the 
addressee and any other named recipient. If you are not the intended recipient, any use, 
distribution, disclosure or copying of this message is strictly prohibited. The confidentiality attached
to this message is not waived or lost by reason of the mistaken transmission or delivery to any 
unintended party. If you have received this message in error, please notify the author immediately or 
contact Australian Finance Group on +61 8 9420 7888.
list T.J. Yang · Wed, 25 May 2005 22:52:44 -0500 ·
quoted from Vernon Everett
\
I really appreciate your willingness to undertake some work on Hobbit,
especially with documentation which most programmers really try to
avoid. I do write documentation, but I may be an exception - it's simply
because when the documentation exists, I get more time to do the
interesting stuff (code) since I don't have to spend so much time
answering questions.
I don't like to answer question also so I would rather put my efforts
on documentation and packaging to do it right.
quoted from Vernon Everett
But before you embark on this, ask yourself: What problem will I solve
by doing this ? Setting up a Wiki is fine - but only if it gets used.
For that to happen, there must be stuff there that people want to read.
So what's missing today - is it the "beginners guide to monitoring your
network" ? Or a "How to monitor your datacenter and survive" guide ?
Or maybe a "Building graphs for your Boss" description?

I guess, what I'm trying to say is that you should narrow your focus
- at least to begin with. Then, when you have something going, you can
broaden the scope.
I hope you are not disappointed about this 
http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit

Looks like I am using  top-down approach on this document to cover the big
area of this subject. In the hope that other can work on the area 
documentation of
they are interested in.

Can you comment on the 4.0.4 road map here, since you are the real code 
developer.
http://en.wikibooks.org/wiki/Sytem_Monitoring_with_Hobbit/Developer_Guide#Development_Road_Map

I printed out most of your *.c *.h and Makefiles today. I had a brief look 
to gain some understanding.

I also try to compile hobbitclient-0.3.tgz on linux and solars, but looks 
like the Makefile generated by ./configure is messed up at this line. Looks 
like 0.3 really reflect hobbitclient's age. But it is also
good that I can participate hobbitclient at its early age.

Problem in Makefile of hobbitclient-0.3
<snip>
hobbitc:        hobbitc.o conf_load.o conf_parse.o report.o osdep.o
        $(CC) -o $@ $(LIBS) $>
<snip>

Error logs
# gmake
cc -o hobbitc
cc: no input files
gmake: *** [hobbitc] Error 1
# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 1)
#