-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I tryed to setup the bbwin client to also log maped drives. At the manual of bbwin is written, I just need to set "true" the

~ <!-- If true, the agent will check remote drives --> ~ <setting name="remote" value="false" />

entry at the bbwin.cfg. But I cannot see any maped drives from my windows server.

Did I something wrong or forget something at the configuration?

Thanks for your help!

Maik

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHl9Fjr4r+EhimPOURAq3aAJ0WgWraqLyA5l+1x9sbSYx6LJNBgQCgl3+A UKimqCp9pf99bW8FHNL3Kl8= =Pax9 -----END PGP SIGNATURE-----

On Thursday 24 January 2008, Rob MacGregor wrote:

Remember that drives are mapped on a per-user basis. So, to see mapped drives you'll need to have them mapped as the user that's running bbwin.

The exception to that, at least under win2003, is to setup a drive mapping via the "Scheduled Tasks". Under Scheduled Tasks, set the job to run as System without a password and to run at startup. This will create a Disconnected Drive mapping, that any logged on user can access. When users access this drive, their credentials are used, not the local system account.

I had to write a simple vbscript to perform the drive mapping.. needed a 60 second sleep command before drive mapping. Seems that sometimes, system startup is abit too soon to make drive mappings, hence the sleep.

There are some known issue with mapping to a samba share, haven't fully figured that out yet.

Just figured this tidbit of information may be of use to others. It took me some time to figure it out. One of my legacy apps does use UNC, and hence why this was needed.

Hi,

On Wed, Jan 23, 2008 at 04:09:35PM -0700, Charles Jones wrote:

One of the things that I brought up was the need to get Hobbit included into popular Linux distributions. [...]

Ack. BSD ports (especially FreeBSD, but also NetBSD and OpenBSD) and MacOS X packages are also important. There seem to be some FreeBSD ports ready at [1], but according to FreshPorts[2], they're not (yet) officially in the FreeBSD ports collection.

[1] http://people.freebsd.org/~dinoex/ports/ [2] http://www.freshports.org/

We will at least have a look at them, since we also have to monitor some FreeBSD servers.

What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.

That being said, I was stunned today to see someone (Axel Beckert) mention that they found Hobbit as a Debian package!

Hehe. The official Debian packages are btw. based on Henrik's, just with different menus (CSS instead of JS) and non-animated icons as default skin.

I have recently done a search and could not find it as part of any distros.

Well, as I wrote, the hobbit packages came to Debian only several weeks ago. I really noticed them _because_ they were new packages. The aptitude package manager always shows you new packages separately...

I'm working (together with the Debian maintainer) on getting hobbit also run and packaged for Debian GNU/kFreeBSD, too. One of my coworkers also managed to install the Debian packages also run on Ubuntu, so I would expect that the Debian packages will find there way into Ubuntu and derivatives.

I will be grabbing those packages to examine them as I'm itching to see what the "apt and lib plugins" are :)

Those two plugins are really cool:

The apt plugin gets red on not yet installed security updates and yellow on not yet installed other updates or if there hasn't been looked for updates for more than a few days.

The libs plugin may be helpful also for other distros: It checks if there are processes running linked to library files which have been updated after the start of the process. A really useful plugin!

All that being said, I'm probably getting close to the "too long didn't read" limit on this post,

Good posts can be as long as they need to be. ;-)

1. Getting Hobbit added to major linux distributions (apparently someone has already made it happen for Debian: http://packages.debian.org/hobbit).
   Whoever did this, please let us know so we can thank you!

Christoph Berg <myon at debian.org> packaged it -- as far as I know as part of his job. Myon, do you read this list? ;-)

(If not, I'll point him to the archives. :-)

2. Moving away from "legacy" filenames and variables. While in many ways compatible with BigBrother, Hobbit is a totally standalone, different, and superior product.

I can back this only partially.

Of course those bb* filenames are probably very irritating for hobbit beginners who just don't now BB or BigSister (never tried it btw.)...

OTOH I'm very happy that Hobbit is backwards compatible in many ways so that it's easy to migrate away from BB. I think this backwards compatibility is quite important for the success of hobbit and should be kept.

We should phase out the bb-* config files and have them become hobbit-* files, perhaps retaining symlinks so that any existing user-made scripts that might have the names hard-coded will still work).

Same counts for variables like especially BBHOME resp. HOBBITHOME.

3. Encryption of Hobbit data transmissions. I get this seemingly every time that I am explaining Hobbit..."is the data encrypted?" When I say no its *gasp!* "But it is sending sensitive information, process lists, logfile entries...over the network!".

Full Ack!

Of course there are user-end ways of handling this including using ssh to tunnel the port 1984 traffic, but this is hard to manage

I made it work today for all my private hosts (as announced in my last mail). stunnel was setup easily:

+----------------+ +----------------+ | Client | | Server | +----------------+ +----------------+ | hobbit-client | | hobbit | | v | | ^ | | localhost:1984 | | localhost:1984 | | v | | ^ | | stunnel ------ Port 1983 ------> stunnel | +----------------+ +----------------+

I couldn't resist using port 1983 for it, although I'm not sure if the idea "before 1984" can be fitted onto the novel or scenarios. :-)

I could also have taken port 2008, but that would only work for Germans[3].

[3] http://www.vorratsdatenspeicherung.de/?lang=en

and doesn't scale well.

Haven't used it in the big scale at work yet, so I can't say anything about that.

But there's another problem with all those wrapping and tunneling solutions: All messages appear to being sent from localhost. A hobbit internal SSL would help here, too.

I would suggest a "simple" (heh its always simple to the person who doesn't have to code it eh?) implementation of libssl to encrypt the port 1984 traffic. That would make a lot of folks (Infosec, Managment, Sysadmins) happy

Ack, but be warned that (at least AFAIK) if you want to link GNU GPL licensed software with OpenSSL, you do need the explicit allowance of the OpenSSL authors. But in general I'm one of those sysadmins who would be happy. :-)

4. Maybe a new website?

Would help, yes. Doesn't need to be fancy, just informative. Read only or webbased access to the source code repository also would be fine. The one at SF seems to be out of date.

On Thu, Jan 24, 2008 at 07:50:11AM +0100, Henrik Stoerner wrote:

...

2. Moving away from "legacy" filenames and variables.

The bb-hosts file is about the only one left. My intention has been to keep that name until Hobbit moved away from the file format in bb-hosts; something which I've been wanting to do for a while. The bb-hosts format is getting rather overloaded, and I really don't like the way it mixes the host configuration with the web page layout definitions. So this is going to change sometime.

Ah, ok. I don't know how many potential switch BB installations are out there. But if there is quite a bunch of, a converting helper wouldn't be bad.

BB (and hobbit) really has a few nice advantages over Nagios (which is probably the most popular free Monitoring system), so there must be a few out there.

Well, I'm really curios about the number of installations. Google helps a little bit:

A search for the title string of a default BB server[4] has about 152 hits, although not all are really BB installation, but OTOH there may be people like us who block search engines out of their BB via robots.txt and others who changed the templates so the title is different. So I would guess that there are probably still a few hundred BB installations out there.

[4] http://www.google.com/search?q=allintitle:%22Big+Brother+-+Status%22

OTOH the same search for hobbit[4] gives already 84 hits, with some paleoanthropology in between.

[5] http://www.google.com/search?q=allintitle:%22Hobbit+-+Status%22

The same kind of search for Nagios[6] counts about 44600 hits, but since the product name isn't in the title and adding them also only looks in the title for it, this number is probably way off.

[6] http://www.google.com/search?q=allintitle:%22Current+Network+-+Status%22

There are two other more recent competitors: Pandora FMS[7] and Zenoss[8], but if you search for the text on Pandora FMS' login page[9], you only get one single hit: Their demo site[10].

[7] http://pandora.sourceforge.net/ [8] http://www.zenoss.com/ [9] http://www.google.com/search?q=%22Welcome+to+Pandora+FMS+Web+Console%22 [10] http://artica.homelinux.com/pandora/

And Zenoss doesn't seem to have a public demo, so counting that way doesn't work since I don't know for what to search.

...

3. Encryption of Hobbit data transmissions. I get this seemingly every time that I am explaining Hobbit..."is the data encrypted?" When I say no its *gasp!* "But it is sending sensitive information, process lists, logfile entries...over the network!".

Yeah ... well, I should add some SSL support to the protocol.

A STARTTLS command as with many other protocols would be cool, so no new port would be needed. (OTOH, it makes debugging less easier...)

	Mit freundlichem Gruss, Axel Beckert

-- Axel Beckert <beckert at phys.ethz.ch> support: +41 44 633 2668 IT Support Group, HPR E 86.1 voice: +41 44 633 4189 Departement Physik, ETH Zurich fax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/

On Thu, Jan 24, 2008 at 08:34:01PM +0100, Axel Beckert wrote:

...

What about Windows? As far as I heard, the only current Windows

client

...

for hobbit is BBWin.

Correct. I've been contacted by a fellow who was interesting in doing a Windows port of the Hobbit server. I've encouraged him to look into it, but also made it clear that I cannot help with Windows programming.

...

First, thankyou Henrik for such a great product.

A Windows port of Hobbit Server would be fantastic for us. We are almost purely a Windows shop and it's just not going to change. I settled on BB purely because it was the only one I found that had a Windows port, did what we wanted (at the time) and we could run it free under the BTF licence. I discovered Hobbit purely by accident fairly recently. It gave enough advantages (mainly ongoing support and development) that the "main" server is now a Hobbit/Ubuntu/VMWare Virtual Server running on one of the Windows boxes. This is our only Linux install. I chose Ubuntu because of it reputation for ease of use for us non Linux people. The clients are still BB though I have started to modify our custom scripts to enable us to use BBWin. I will be using BB for a long time because I have 7 sites non of them could really be called a main site. Each site has it own BB server and is stand alone forwarding the information to the Hobbit server. Since Hobbit cant forward and display at the same time I cant use it. The capability to run another virtual machine is also questionable at some sites.

The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.

I know this is almost heresy for those whose professional lives have been heavily devoted to open source and Linux but it is the reality for us and I'm sure we are not alone.

Kind Regards Graeme

Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.

Hobbit doesn't have a problem forwarding and displaying at the same time. Just run bbproxy and make one of the forwarding addresses another port on the same machine, set hobbitd to listen on that port.

Thanks, Larry Barber

On Jan 24, 2008 10:10 PM, Joe Sloan <joe at tmsusa.com> wrote:

Shea, Graeme A wrote:

...

I know this is almost heresy for those whose professional lives have been heavily devoted to open source and Linux but it is the reality for us and I'm sure we are not alone.

meh. windoze. I don't understand the hype, I just really don't.

At any rate, I understand that there is some sort of monitoring program for microsoft windows, called "mom", have you looked into it?

Regards,

Joe

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

On Fri, Jan 25, 2008 at 11:18:37AM +1100, Shea, Graeme A wrote:

A Windows port of Hobbit Server would be fantastic for us. [...] The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.

There is a VMware image on the Hobbit sourceforge page. I suppose it could easily be enhanced so the Hobbit configuration file directory was exported as a Windows fileshare, then you can edit the config files with notepad.exe <yuk...>

Regards, Henrik

On Wed, Jan 30, 2008 at 07:48:49AM -0500, s_aiello at comcast.net wrote:

Henrik Stoerner wrote:

...

Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.

I took a look at this a bit. The hardest part about this as I see it, would be pulling information from multiple data sources. For report data I could use bb commands (hobbitdxboard, or others), but then I would need to parse the server's bb-host file for page layouting. Which isn't a huge problem, just adds complication.

This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea. I would much rather have all of the webpage layout stuff moved somewhere separate, so you can generate multiple different sets of webpages from the same monitoring data. So there would be one XML file describing how the webpages are laid out, which hosts goes on what pages etc - and another XML file you get from the hobbitdxboard command that fills in the current data on those pages.

Regards, Henrik

Damian Conway in "Perl Best Practices" (published by O'Reilly) says "Don't use XML as your configuration file format. It may be human-readable, but it's almost never human-comprehensible, and the ratio of mark-up to content is vastly too high." He goes on to argue that configuration files should use a format that is much more like what Henrik has implemented in the non-Big-Brother-legacy-format, and suggests several CPAN modules that Perl programmers can use to parse these formats in their programs.

I fully agree with this notion -- let's keep Hobbit "XML-free"!

GLH

-----Original Message----- From: s_aiello at comcast.net [mailto:s_aiello at comcast.net] Sent: Wednesday, January 30, 2008 9:06 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit

On Wednesday 30 January 2008, Henrik Stoerner wrote:

On Wed, Jan 30, 2008 at 07:48:49AM -0500, s_aiello at comcast.net wrote:

...

Henrik Stoerner wrote:

...

Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.

I took a look at this a bit. The hardest part about this as I see it, would be pulling information from multiple data sources. For report data I could use bb commands (hobbitdxboard, or others), but then I would need to parse the server's bb-host file for page layouting. Which isn't a huge problem, just adds complication.

This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea. I would much rather have all of the webpage layout stuff moved somewhere separate, so you can generate multiple different sets of webpages from the same monitoring data. So there would be one XML file describing how the webpages are laid out, which hosts goes on what pages etc - and another XML file you get from the hobbitdxboard command that fills in the current data on those pages.

The only reason I would assume the need to continue to use the bb-host file as the source of layout, is because the Hobbit alert & threshold 'PAGE=' specifications do. Thats why I mentioned that I thought you had stateted the need to move away from the bb-hosts config file. GUI Layout seems to be an integral part of Hobbit (i.e. alert & threshold definitions based on layout). And again, I am not a huge fan of XML, but it seems that it would be a good option to migrate toward (from bb-hosts). That way if people did want to write a new GUI for Hobbit it would not be difficult. It would also be possible to add new fields, without affecting core Hobbit functionality. i.e. writing a version of BBMap for hobbit.

But again, I remember in a previous post your (and other maillist members) reluctance to use XML for any configuration. So it almost seems like a catch22. So as I see it, ideally need a layout config that:

1. Simple to define layout.
2. Open to custom field definiton additions.
3. Open to allow for 3rd party GUI development.
4. Doesn't break core hobbit functionality.

I maybe stating the obvious, just figure I would flush out my thoughts. ~Steve

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

don't know, where the relation is to the subject

but anyhow

http://www.blastwave.org/packages.php/hobbit_client

cheers, martin

On Wed, 30 Jan 2008, Snyder, Howard wrote:

All,

Does anyone have a script that will install all necessary files for a Solaris 10 client?

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

Can I assume that the srcdir needs to have the following:

Hobbit Gcc

Anything else?

Thank you, Howard Snyder hs3082 at att.com
SR Network Control Engineer Network Services 404-531-5325 This email, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Cingular Wireless and its Affiliates. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 404.531.5325 and permanently delete the original and any copy thereof. For login requests and password resets, you will need to open a request on the "My Logins" website:

https://nslogins.edc.cingular.net/login.cfm?CFID=13246&CFTOKEN=41726264

For OSS problems: DL-MNOC-OSS Adjunct DL-MNOC-OSS Siemens DL-MNOC-OSS Nortel DL-MNOC-OSS Nokia DL-MNOC-OSS Lucent DL-MNOC-OSS Ericsson

-----Original Message----- From: Galen Johnson [mailto:Galen.Johnson at sas.com] Sent: Wednesday, January 30, 2008 1:07 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit

#!/bin/sh cd <srcdir> ./configure && make && make install

=G=

-----Original Message----- From: Snyder, Howard [mailto:HS3082 at att.com] Sent: Wednesday, January 30, 2008 12:47 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit

All,

Does anyone have a script that will install all necessary files for a Solaris 10 client?

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

On Wednesday 30 January 2008, Hubbard, Greg L wrote:

Damian Conway in "Perl Best Practices" (published by O'Reilly) says "Don't use XML as your configuration file format. It may be human-readable, but it's almost never human-comprehensible, and the ratio of mark-up to content is vastly too high." He goes on to argue that configuration files should use a format that is much more like what Henrik has implemented in the non-Big-Brother-legacy-format, and suggests several CPAN modules that Perl programmers can use to parse these formats in their programs.

I fully agree with this notion -- let's keep Hobbit "XML-free"! I recently used the ini format. Very easy to read and change. There is also a nice perl module to process the files. I'm sure there are C libraries as well.

Stef

On Wednesday 30 January 2008 23:43:06 Henrik Stoerner wrote:

On Wed, Jan 30, 2008 at 10:06:09AM -0500, s_aiello at comcast.net wrote:

...

On Wednesday 30 January 2008, Henrik Stoerner wrote:

...

This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea.

The only reason I would assume the need to continue to use the bb-host file as the source of layout, is because the Hobbit alert & threshold 'PAGE=' specifications do.

Correct, but the PAGE setting for alerts and client-thresholds does not have to be obtained from bb-hosts ... It is really just a way to classify a group of hosts as having "something" in common, and this can easily be done in a different configuration file format.

Off the top of my head, it might even make sense to turn this entire concept upside-down: Instead of using a layout-definition to group hosts together in the alert/client config, we could use a *host* classification to define which hosts should be put on a given webpage.

Well, in my opinion, it is more important to be able to group hosts by configuration, rather than by layout, but maybe it would be better not to enforce a static layout.

For example, which servers you want to worry about changes (e.g. when you're on standby you may want to see everything, when you're not you may just want to look at specific servers), differs between different people. So, while a default layout is fine, I would like an interface that allows the user to save some layout profiles.

However, monitoring configuration has to be split from layout, must be extensible enough, and bindings created for common languages used for extensions, so that configuration for any extension can be done easily and consistently.

Grouping and/or inheritance must be consistent between configuration types. At present, you can group thresholds easily, and alerts easily (but independently of thresholds), but client-side configuration (e.g. log files to monitor) you can't.

So, something flexible enough to allow test configuration to inherit from one group, client configuration to inherit from another group, thresholds to inherit from another group, and can be overridden on a per-host per-test bases would be nice ... but hopefully not that flexible that we get to the Nagios situation.

...

And again, I am not a huge fan of XML, but it seems that it would be a good option to migrate toward (from bb-hosts). That way if people did want to write a new GUI for Hobbit it would not be difficult. It would also be possible to add new fields, without affecting core Hobbit functionality. i.e. writing a version of BBMap for hobbit.

But again, I remember in a previous post your (and other maillist members) reluctance to use XML for any configuration. So it almost seems like a catch22.

Well, I never said it would be easy :-) You are right, there are inherent conflicts between the different goals here. I am not a big fan for of XML configuration files (Hobbit doesn't have any, because I haven't bothered to go find a decent XML parsing library), but is IS a de-facto standard and there are lots of tools for handling such files.

Yes, it is a de-facto standard for information transfer between different applications, but as a user-interface it is very poor ...

But I'd still like to weigh the pros and cons of using XML. Right now, I am not convinced.

...

So as I see it, ideally need a layout config that:

1. Simple to define layout.
2. Open to custom field definiton additions.
3. Open to allow for 3rd party GUI development.

These 3 I agree with.

...

4. Doesn't break core hobbit functionality.

This is something we can control ourselves. So don't let that stop you.

IMHO, some of the things relating to "core functionality" may need to be broken to be improved. For example, some Nagios fans complain all the time that the TCP checks aren't comprehensive enough (and writing new extensions that e.g. check pop3 with a user account and confirm that the mailbox list can be retrieved, for multiple virtual ISPs where the pop3 services run on different ports on the backend servers is impossible because there's no sane way to configure them).

Well, those are my thoughts so far on configuration.

Regards, Buchan

Our windows users have shown a fondness for nedit. It's apparently more like notepad (I've never actually used it) and it's completely gui based...I prefer vim but then I've been a unix admin for about 15 years.

=G=

-----Original Message----- From: Shea, Graeme A [mailto:Shea.Graeme.A at edumail.vic.gov.au] Sent: Wed 1/30/2008 6:16 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit

Thanks for the reply, I did check out the image but (from memory) the HD was very small and there was no GUI and not much else. Being a newbie and coming from windows a GUI and GUI based text editor was important. I realize for an experienced Linux sysadmin they are superfluous but pretty much essential for me.

Yes sharing the folder and using a windows machine to edit the files is ugly and fraught with danger in not getting the LF/CR bit right. Any GUI text editor I have tried meets the criteria of "easy to use". Sorry VI whilst very powerful doesn't (IMHO).

Regards Graeme

-----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, 30 January 2008 10:17 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit

On Fri, Jan 25, 2008 at 11:18:37AM +1100, Shea, Graeme A wrote:

A Windows port of Hobbit Server would be fantastic for us. [...] The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.

There is a VMware image on the Hobbit sourceforge page. I suppose it could easily be enhanced so the Hobbit configuration file directory was exported as a Windows fileshare, then you can edit the config files with notepad.exe <yuk...>

Regards, Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

Josh Luthman wrote:

I love VIM myself, though I have to admit sometimes it's easier to use notepad.

If you're familiar with MS Edit then you should have no problems with nano or pico. I've been noticing these two are being phased out, but you should still be able to get one or the other.

Would it be nice if you could edit the configs via the web interface (a simple text editor)?

-Charles

I have a copy at home. I have no problem making it available on The Shire but at that point it should be considered a fork. I need to go see what Henrik is doing with 4.3 to see how many of the Admin Tools are no longer relevant as well.

=G=

From: Josh Luthman [mailto:josh at imaginenetworksllc.com] Sent: Friday, February 01, 2008 12:22 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit

If someone still has the "Admin Tools" archive you can use that to modify the bb-hosts. There are a few people around here that modify bb-hosts via the web interface due to not having SSH access. This is the adminscripts_edit_files.sh script.

Josh On 2/1/08, Charles Jones <jonescr at cisco.com<mailto:jonescr at cisco.com>> wrote: Josh Luthman wrote:

I love VIM myself, though I have to admit sometimes it's easier to use notepad.

If you're familiar with MS Edit then you should have no problems with nano or pico. I've been noticing these two are being phased out, but you should still be able to get one or the other.

Would it be nice if you could edit the configs via the web interface (a simple text editor)?

-Charles

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>

-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373

Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer

On Thu, 7 Feb 2008, Wayne Gemmell wrote:

On Thursday 31 January 2008 08:08:21 Josh Luthman wrote:

...

If you're familiar with MS Edit then you should have no problems with nano or pico.  I've been noticing these two are being phased out, but you should still be able to get one or the other.

Phased out? What are they being replaced with?

Emacs! ;-)

Ulric

VIM - http://www.vim.org/

On Feb 7, 2008 6:32 AM, Stewart L <stewartl42 at gmail.com> wrote:

vi

sorry... someone had to... :-)

Stew

On Feb 7, 2008 3:52 AM, Ulric Eriksson <ulric at siag.nu> wrote:

...

On Thu, 7 Feb 2008, Wayne Gemmell wrote:

...

On Thursday 31 January 2008 08:08:21 Josh Luthman wrote:

...

...

If you're familiar with MS Edit then you should have no problems with nano or pico. I've been noticing these two are being phased out, but you should still be able to get one or the other.

...

Phased out? What are they being replaced with?

Emacs! ;-)

Ulric

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

-- Stewart

The revolution will not be televised. The revolution will be no re-run brothers; The revolution will be live.

--

Richard Wachter General Unix Geek rich at richwachter.com <>< Precariously perched on the precipice of another day . . .

Hi,

On Thu, Jan 24, 2008 at 11:06:50PM +0100, Henrik Stoerner wrote:

...

What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.

Correct. I've been contacted by a fellow who was interesting in doing a Windows port of the Hobbit server. I've encouraged him to look into it, but also made it clear that I cannot help with Windows programming.

Ok. For us, a working Windows XP and Vista client is important, but there seem to be a few around.

...

coworkers also managed to install the Debian packages also run on Ubuntu, so I would expect that the Debian packages will find there way into Ubuntu and derivatives.

I believe the Ubuntu folks have picked up the Debian package for inclusion into the next release, "Hardy" 2008.04. https://launchpad.net/ubuntu/hardy/+source/hobbit

Yeah, the package version number looks a lot like the original Debian package. Cool!

...

Ack, but be warned that (at least AFAIK) if you want to link GNU GPL licensed software with OpenSSL, you do need the explicit allowance of the OpenSSL authors.

Actually, it's the other way around. If you look at the Hobbit README, it says this:

  Hobbit is Open Source software, made available under the
  GNU General Public License (GPL) version 2, with the explicit
  exemption that linking with the OpenSSL libraries is permitted.

Ok, forgot, that you already use OpenSSL for the HTTPS and other SSL-using tests. :-)

That last sentence is copied almost verbatim from the OpenSSL FAQ http://www.openssl.org/support/faq.html#LEGAL2:

  2. Can I use OpenSSL with GPL software ?

  If you develop open source software that uses OpenSSL, you may 
  find it useful to choose an other license than the GPL, or state 
  explicitly that "This program is released under the GPL with the 
  additional exemption that compiling, linking, and/or using 
  OpenSSL is allowed."

Ok, I really remembered it the other way 'round. Thanks for clarification! :-)

[Statistics]

So Nagios is still ahead of Hobbit, but I am actually quite pleased that Hobbit has a 5% market share :-)

Ack!

For Debian and Ubuntu, there are the popcon (popularity contest) statistics:

http://qa.debian.org/popcon.php?package=hobbit http://qa.debian.org/popcon.php?package=hobbit-client http://qa.debian.org/popcon.php?package=hobbit-plugins

I haven't found any per-package statistics page for Ubuntu, but you can easily extract the relevant data from what is offered on the website:

GET http://popcon.ubuntu.com/by_inst.gz | zcat | egrep '^#rank|hobbit' #rank name inst vote old recent no-files (maintainer) 34301 hobbit 8 4 4 0 0 (Unknown) 35099 hobbit-client 7 3 4 0 0 (Unknown) 53687 hobbit-plugins 1 0 0 0 1 (Unknown)

GET http://popcon.debian.org/by_inst.gz | zcat | egrep '^#rank|hobbit' #rank name inst vote old recent no-files (maintainer) 16769 hobbit-client 70 62 3 5 0 (Christoph Berg) 21642 hobbit 33 31 1 0 1 (Christoph Berg) 23141 hobbit-plugins 26 1 0 0 25 (Christoph Berg) 83984 wmaker-hobbit-.-theme 1 0 0 0 1 (Not in sid)

So you have about 70 client and 33 server installations on Debian (of which probably 4 servers and about 20 clients and plugin packages and are ours :-) and 7 in Ubuntu.

Interestingly there are more Ubuntu hobbit servers than clients although at least in Debian the hobbit server depends on the hobbit client and can be installed without. Strange. Maybe some not official packages.

Well, I guess the Debian hobbit-client statistics will shoot up when we start deploying the hobbit client to our about 170 Debian workstations and a bunch of servers. :-) Currently one of my coworkers is preparing the new hobbit server...

...

A STARTTLS command as with many other protocols would be cool, so no new port would be needed. (OTOH, it makes debugging less easier...)

No, STARTTLS is the "right" way of doing it, and the one I have been looking at.

Perfect! :-)

	Kind regards, Axel Beckert

-- Axel Beckert <beckert at phys.ethz.ch> support: +41 44 633 2668 IT Support Group, HPR E 86.1 voice: +41 44 633 4189 Departement Physik, ETH Zurich fax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/

Maybe a silly question, but how many people are developing the core hobbit?

Also, has anyone "released" a hobbit central?

Tim

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

On 1/25/08 10:20 AM, "Henrik Stoerner" <henrik at hswn.dk> wrote:

On Fri, Jan 25, 2008 at 08:18:54AM -0600, Tim Rotunda wrote:

...

Maybe a silly question, but how many people are developing the core hobbit?

One - me. Is this by choice or just no one has offered to contribute?

...

Also, has anyone "released" a hobbit central?

Don't think so ...

To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.

I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.

Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

I too have been victim of the rampant recreation of scp. It makes things very irritating to work with. If you've used Windows as a desktop and things slow down it has a similar feel to it - nice and laggy.

I like the idea of SSL, good one Charles =)

On 1/25/08, Charles Jones <jonescr at cisco.com> wrote:

I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:

• How many ssh sessions can you run at the same time without spiking the load on the hobbit server?
• What happens when an ssh session hangs (could hang the hobbit server, or make the poll cycle take too long)

You do know about the "pulldata" option? It allows the Hobbit server to do a "pull" instead of waiting for client "push". This works fairly well, and I am using it in a production environment. I can see how it would not scale to well either though, for a really large number of hosts.

To picture the scalability, imagine a server that only has to receive updates from hobbit clients. All it has to do is listen on port 1984, and using relatively little CPU it can probably handle a constant flow of client updates.

Now imagine a server that has to go and fetch the client data itself. There is a LOT more overhead and processing involved in launching an outgoing ssh connection, running a remote client data-gathering command, waiting for the output, etc. Imagine 2000 of those firing off every 5 minutes. How many simultaneous ssh sessions can your server handle? I've seen a server brought to its knees by a script that ran amok and was doing 50 simulataneous scp commands :) Some time saving is done by using msgcache (no waiting for the data-gathering), but there is still the overhead of ssh itself, and having key-based ssh ability could be deemed a security risk (anyone who hacks into the hobbit server could then ssh to all of your client machines without a password).

A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.

In the meantime, definitely check out the pulldata+msgcache option, as it sounds like it will do what you want.

-Charles

Tim Rotunda wrote:

...

To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.

I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373

Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer

Hobbit User in Richmond wrote:

On Fri, January 25, 2008 14:43, Charles Jones wrote:

...

I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:

I don't recall Henrik advocating this as a Good Thing. In fact, I suggested building the ssh capability into Hobbit a while back, and he explained why it was not the Right Thing to Do.

I think I worded what I said wrong..I meant to say that Henriks stance "was that using ssh does not scale". Sorry for the confusion!

...

A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.

Sounds rather like what Henrik said he'd pursue at some point in future, when he demurred on the ssh-integration suggestion. In lieu of it, I generally have the Hobbit server push an ssh-based port forward for tcp 1984 to each client with such a need and let the clients happily report to localhost. High port, doesn't have to be a privileged user, and you can limit the user via .ssh/authorized_keys. Autossh makes it persistent. You have the tunnel overhead, but not the constant setup/teardown of the connection. Just another way to skin the cat, has its trade-offs too.

Yeah I think he has planned to implement SSL, just hasn't gotten around to it, and since he is the only coder, we have to wait...or do we? If someone out there is good at C++, why not help Henrik out and do some of the coding for him? I've had the fact that Hobbit "only has one coder/author" raised as a red flag when I was advocating Hobbit...people ask what will happen if Henrik leaves the scene for any reason.

Larry Barber wrote:

<i>people ask what will happen if Henrik leaves the scene for any reason.</i>

Henrik's code is very clean, any competent C programmer should be able to maintain it.

Agreed. Along that line, people should be able to help him out too (unless he doesn't want it) :)

-Charles

On Fri, Jan 25, 2008 at 03:06:20PM -0600, T.J. Yang wrote:

...

Yeah I think he has planned to implement SSL, just hasn't gotten around to it, and since he is the only coder, we have to wait...or do we? If

I think SSL encrypted channel has higher priority over snmp query (which is also good). for some reason henrik is implementing snmp feature now.

Features have a tendency to get implemented in the sequence that a developer needs them. I really don't need SSL-encrypted Hobbit traffic, but I do need the SNMP support.

If someone else needs the SSL stuff badly, try implementing it and send it to me for inclusion.

...

of the coding for him? I've had the fact that Hobbit "only has one coder/author" raised as a red flag when I was advocating Hobbit...people ask what will happen if Henrik leaves the scene for any reason.

When reading the hobbit source code, there are other names (for patching/bug fixing) in there also.

The only reason for my leaving the project would be an untimely accident. But that can happen, and the only guarantee I can give you is that the source code will always be available so someone else can take over if I am no longer around.

Looks like Henrik prefer current one-man project approach. more developers more communication efforts needed. It will add another burden to him(with a full time job), I think.

Coordination certainly is easier on one-man projects.

Realistically, Hobbit has grown to a size where there is too much to do for one person. So I wouldn't mind som help with the coding - I just haven't seen anyone step forward yet who is willing to take over part of that effort. Also, it would have to be someone whom I trust to be competent at what they're doing, and who is willing to maintain their code.

(It's not quite true that there are no other developers. Etienne does a very fine job of handling all of the Windows client code in BBWin - had he not been around, Hobbit would have a serious problem in handling Windows-based systems. This is an excellent example of how a specific module can be implemented separately).

This is a classic problem with Open Source software, by the way.

Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.

Regards, Henrik

On 1/25/08 1:43 PM, "Charles Jones" <jonescr at cisco.com> wrote:

I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:

• How many ssh sessions can you run at the same time without spiking the load on the hobbit server? The latest revision is threaded. The thread count is a parameter and is easily changed. If I remember correctly, we had 11 threads finishing all the nodes in under 90 seconds. Also, going to a threaded architecture brought cpu util from 80% to 5%. I was astonished. So we figured you could have 100's of threads running on the HP rx1600 single socket node we were using for hobbit.

• What happens when an ssh session hangs (could hang the hobbit server, or make the poll cycle take too long) Since there were many threads, a hung thread would hardly be noticed if it weren't for the purple that node would turn.

You do know about the "pulldata" option? It allows the Hobbit server to do a "pull" instead of waiting for client "push". This works fairly well, and I am using it in a production environment. I can see how it would not scale to well either though, for a really large number of hosts.

To picture the scalability, imagine a server that only has to receive updates from hobbit clients. All it has to do is listen on port 1984, and using relatively little CPU it can probably handle a constant flow of client updates.

Now imagine a server that has to go and fetch the client data itself. There is a LOT more overhead and processing involved in launching an outgoing ssh connection, running a remote client data-gathering command, waiting for the output, etc. Imagine 2000 of those firing off every 5 minutes. How many simultaneous ssh sessions can your server handle? I've seen a server brought to its knees by a script that ran amok and was doing 50 simulataneous scp commands :) Some time saving is done by using msgcache (no waiting for the data-gathering), but there is still the overhead of ssh itself, and having key-based ssh ability could be deemed a security risk (anyone who hacks into the hobbit server could then ssh to all of your client machines without a password). I don't know how you secure your servers, but nobody is getting into my hobbit/hobcen servers with out authorization. Believe it or not, there are ways to prevent unauthorized access. The caveat here is that I don't put mine on a public IP. :-)

A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.

In the meantime, definitely check out the pulldata+msgcache option, as it sounds like it will do what you want. I have not looked at the option you note, however, there are times where deploying clients is not an option. I suspect that is why bb-central was born and why I developed hobcen. Like I said, it started as a shell script, morphed into a C application and then a POSIX-threaded C application. This was all based on shared ssh keys, but after coming from a stint in a DC with 60,000+ nodes on 3 acres of raised floor, I learned very quickly how to use ssh pw auth for batch communications that is fast. :-)

We all have issues to resolve and like UNIX, there are 10 different ways to solve any one of them.

Cheers,

Tim

-Charles

Tim Rotunda wrote:

...

To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.

I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

Thanks for the info.

I can think of a myriad of reasons why clients aren¹t allowed on remote nodes, but in the case that spawned hobcen, it was because the boss said no.

I wrote the hobcen script in early 06 and the p-threaded app came along in mid 06. I was a busy IT Manager back then so it was a get it done and move on kinda thing. I just checked and it is still in production at this time.

After 20 years, I gave up on politics so I could hold onto my technical skills. As it turns out, a 40 hour work week is pretty dang nice. So I thought I would drop the group a note and see what kind of interest there is. Nothing has been submitted as yet.

Cheers,

Tim

On 1/25/08 3:35 PM, "Charles Jones" <jonescr at cisco.com> wrote:

Tim Rotunda wrote:

...

I have not looked at the option you note, however, there are times where deploying clients is not an option. I suspect that is why bb-central was born and why I developed hobcen. Like I said, it started as a shell script, morphed into a C application and then a POSIX-threaded C application. This was all based on shared ssh keys, but after coming from a stint in a DC with 60,000+ nodes on 3 acres of raised floor, I learned very quickly how to use ssh pw auth for batch communications that is fast. :-)

We all have issues to resolve and like UNIX, there are 10 different ways to solve any one of them.

The pulldata option was added some time ago. You use the keyword in bb-hosts for the hosts you want to pull client data from instead of waiting for a push:

---man page snippet--- pulldata[=[IP][:port]] This option is recognized by the hobbitfetch(8) utility, and causes it to poll the host for client data. The optional IP-address and port-number can be used if the client-side msgcache(8) daemon is listening on a non-standard IP-address or port-number.

As noted it also requires activating the "msgcache" option in the clients clientlaunch.cfg. Basically what happens is the client reports the client-data to "itself", a buffer of sorts, which the Hobbit client then comes along and grabs.

You may find it useful except in the cases you mention where the installation of a client is not possible at all, although I'm not sure why you would be able to run all the commands that the normal client runs, but yet not able to run the normal client?

This is the first I have heard of hobcen...It sounds like it could be useful for some folks until Henrik provides a better solution. Have you submitted it to TheShire?

-Charles

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

David Gilmore a écrit :

Why not use BBWIN? I have it running on several XP systems and a few Vista. Sure it is XML only, but once you right one config, it is practically cut and paste for the rest.

Hi

with BBwin 0.10, you can even use the centralized mode of Hobbit (the author of BBwin provides patches for 4.2.0 and the snapshot) :

"Using BBWin with Hobbit Centralized mode

To use the centralized hobbit mode of BBWin, you have to follow the following steps : You should use at least BBWin 0.10 or upper

  With Hobbit stable release (4.2)

* Get the hobbit stable release on Hobbit download webpage
  <http://www.hswn.dk/hobbitsw/>
* Apply the all-in-one patch <http://www.hswn.dk/hobbitsw/patches/>
* Get the bbwin patch for hobbit
  <http://bbwin.sourceforge.net/download/bbwin_4.2.patch>
* Apply the bbwin patch using GNU patch. "cd" to the hobbit-4.2.0
  directory, then run "patch -p0 <bbwin_4.2.patch".
* Build and install hobbit as usual"

--

Frédéric Mangeant

Steria EDC Sophia Antipolis

Hi Ulric,

On Fri, Jan 25, 2008 at 09:05:00AM +0100, Ulric Eriksson wrote:

...

What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.

Mr Big: http://mrbig.365-24.se/

As far as I know, there are no Hobbit-specific Windows clients. There are three clients that I know of: the original Big Brother client, BBwin and Mr Big. These all use the Big Brother protocol.

Thanks for the information, we'll have a look at that one, too.

	Kind regards, Axel Beckert

-- Axel Beckert <beckert at phys.ethz.ch> support: +41 44 633 2668 IT Support Group, HPR E 86.1 voice: +41 44 633 4189 Departement Physik, ETH Zurich fax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/

No one is advocating eliminating the capability of being able to compile from source, far from it.

We wish to, hopefully, add to the user base by including Hobbit in major distributions like SLES, RHEL and others.

Hubbard, Greg L wrote:

A lot of Hobbit users are using Linux-based packages. Some of us use "commercial" systems, so we have to compile from source. I think Hobbit would be hobbled if it were to become a Linux-oriented package, which could happen if it were to start depending on a lot of extras that are not easy to port to other operating systems. People use Hobbit for all sorts of reasons, and in all sorts of environments.

GLH

-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008

The thing I see packages being beneficial is if there are a lot of users that need an "easier" installation. If it costs more support time to make packages then to drill down the problems with compiling then I could see a reason to make packages and update them.

Pretty sure it is understood the source isn't disappearing among everyone here. I'm sure it will be a cold day in hell when that happens ;)

On 1/24/08, Rich Smrcina <rsmrcina at wi.rr.com> wrote:

No one is advocating eliminating the capability of being able to compile from source, far from it.

We wish to, hopefully, add to the user base by including Hobbit in major distributions like SLES, RHEL and others.

Hubbard, Greg L wrote:

...

A lot of Hobbit users are using Linux-based packages. Some of us use "commercial" systems, so we have to compile from source. I think Hobbit would be hobbled if it were to become a Linux-oriented package, which could happen if it were to start depending on a lot of extras that are not easy to port to other operating systems. People use Hobbit for all sorts of reasons, and in all sorts of environments.

GLH

-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373

Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer