Backing up hobbit 🔗 link

On Thursday 18 October 2007, Josh Luthman wrote:

I am trying to create a backup of hobbit so in case the box is stolen,
blown up, disappear, vanishes into thin air or even the boogey monster
steals it, I can recover with a secondary box in a matter of minutes -
hours at most.

What I had done with BB was simply backup the entire user's home directory.
I had this done every single morning.  Each gzipped tar was a mere 15 megs.

When I do a du -shc /home/user it reaches 1021M and in
/home/user/server/bin/ du -shc core* I see 860M.  What are these core*
files?

Does anyone have any suggestions on what to backup?  I don't have the
luxury of using tapes or another machine on the same LAN, so I am
transporting this data over the Internet.  While bandwidth is not a
concern, I'd much rather not have to transport a gigabyte every morning =)

Thanks in advance,

On Thu, October 18, 2007 16:54, Josh Luthman wrote:

Does anyone have any suggestions on what to backup?  I don't have the
luxury of using tapes or another machine on the same LAN, so I am
transporting this data over the Internet.  While bandwidth is not a
concern, I'd much rather not have to transport a gigabyte every morning
=)

On 10/18/07, Hobbit User <user-24d6f8323faa@xymon.invalid> wrote:

On Thu, October 18, 2007 16:54, Josh Luthman wrote:

Does anyone have any suggestions on what to backup?  I don't have the
luxury of using tapes or another machine on the same LAN, so I am
transporting this data over the Internet.  While bandwidth is not a
concern, I'd much rather not have to transport a gigabyte every morning
=)

I have a lot of other configuration data on the hobbit server, relevant to
Continuity of Operations issues, so my backup requirements are broader.  I
just push the entire contents of the box offsite every night using rsync
over ssh with a public/private key setup.  rsync is very intelligent about
what needs to be pushed, and the transfer is usually well under a gig.

-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

On Thu, October 18, 2007 17:58, Josh Luthman wrote:

"Hobbit User" - I could use rsync and it would make backups though I
normally don't use rsync as I like to have daily backups, in case I make
a mistake on Monday, the backup is done Tuesday and I catch it on
Wednesday - I can revert to Sunday with daily backups.  Rsync could have
backed up my problem making it useless in this scenario!  I have a
scripts that backup necessary components (like databases) and then
finally tar with gzip compression and then SCP the file to a remote data
center (I also use public keys to automate this).  I have found this
works very well in my situation and has saved my life in the case of a
MySQL database crash!

From: Josh Luthman [mailto:user-4c45a83f15cb@xymon.invalid] 
Sent: Thursday, October 18, 2007 2:55 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: [hobbit] Backing up hobbit


I am trying to create a backup of hobbit so in case the box is stolen,
blown up, disappear, vanishes into thin air or even the boogey monster
steals it, I can recover with a secondary box in a matter of minutes -
hours at most. 

What I had done with BB was simply backup the entire user's home
directory.  I had this done every single morning.  Each gzipped tar was
a mere 15 megs.

When I do a du -shc /home/user it reaches 1021M and in
/home/user/server/bin/ du -shc core* I see 860M.  What are these core*
files? 

Does anyone have any suggestions on what to backup?  I don't have the
luxury of using tapes or another machine on the same LAN, so I am
transporting this data over the Internet.  While bandwidth is not a
concern, I'd much rather not have to transport a gigabyte every morning
=) 

Thanks in advance,
Josh

-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

On 10/18/07, Haertig, David F (Dave) <user-68874b735d77@xymon.invalid> wrote:

 If you want recovery within minutes you probably won't get by with a
backup/restore scenerio.  Hours possibly, but not minutes.  You of course
still need to backup things even if you choose one of the suggestions below.

(1)
If you have a second server, clone your current Hobbit server to it
and keep it up to date regularly with rsync.  Simplest, but not necessarily
the best, would be a manual failover where you start up all processes
manually.  You would need to handle the move of the webserver.  You could
twiddle with DNS for that, but I've never seen that work well.  You have DNS
propogation delays and you have Windows clients that try to "help" you by
caching previous DNS lookups.  I would instead recommend an IP takeover
using ARP poisoning ("poisoning" sounds bad, so maybe that's not the best
word to use for this, but it's the same technique used by those on The Dark
Side).  A decent short description of this is:
http://www.onlamp.com/pub/a/onlamp/2003/04/03/linuxhacks.html

(1a)
It would be fairly simple just leave Hobbit running 100%, and also the
webserver, on both machines.  The secondary machine could have a blank
hobbit-alerts.cfg file that gets overwritten with the real file upon
failover (so you won't get duplicate notifications).  All Hobbit clients
should be configured to send all data to both servers all the time.

(2)
If you don't have two machines to work with and you still want speedy
recoveries, I'd look into making a portable Hobbit bootable CD.  Start with
Knoppix, Slax, or one of the other Linux LiveCDs and modify it to include
your Hobbit installation on the CD.  At least in theory, you could then
hijack some poor coworker's PC, boot it with your Hobbit/Linux LiveCD, and
have a functional Hobbit.  You wouldn't have your history available but
that's probably acceptable during a quick recovery scenerio.  You would also
need to update that LiveCD whenever you make significant changes to Hobbit.
You could do the same IP takeover as above with ARP poisoning to make it
semi-tranparent.  Running off the LiveCD would be the short term quick fix
... after getting that up and running you'd quickly move your efforts to
recovering your real Hobbit server from the backups that you had.

I have not implemented the above myself.  I am just starting to look into
that.  The above are some ideas that I'm considering implementing myself.

*From:* Josh Luthman [mailto:user-4c45a83f15cb@xymon.invalid]
*Sent:* Thursday, October 18, 2007 2:55 PM
*To:* user-ae9b8668bcde@xymon.invalid
*Subject:* [hobbit] Backing up hobbit

I am trying to create a backup of hobbit so in case the box is stolen,
blown up, disappear, vanishes into thin air or even the boogey monster
steals it, I can recover with a secondary box in a matter of minutes - hours
at most.

What I had done with BB was simply backup the entire user's home
directory.  I had this done every single morning.  Each gzipped tar was a
mere 15 megs.

When I do a du -shc /home/user it reaches 1021M and in
/home/user/server/bin/ du -shc core* I see 860M.  What are these core*
files?

Does anyone have any suggestions on what to backup?  I don't have the
luxury of using tapes or another machine on the same LAN, so I am
transporting this data over the Internet.  While bandwidth is not a concern,
I'd much rather not have to transport a gigabyte every morning =)

Thanks in advance,
Josh

--
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

On Thursday 18 October 2007, Josh Luthman wrote:

I've only had Hobbit running since last Monday.  I have restarted it twice
to ensure that my configurations would take place (things like changing the
WWW hostname).  I last restarted it yesterday and it has been running since
yesterday, so I know if it is restarting it takes more then a day.  I have
40787 total core* files in ~/server and 569364 total core* files in
~/server/bin - couldn't possibly have restarted that many times!

Stef - If you have two Hobbit servers and duplicate your actions, why do
you note your actions?  My original plan was to tar the home directory of
the hobbit user, but as

"Hobbit User" - I could use rsync and it would make backups though I
normally don't use rsync as I like to have daily backups, in case I make a
mistake on Monday, the backup is done Tuesday and I catch it on Wednesday -
I can revert to Sunday with daily backups.  Rsync could have backed up my
problem making it useless in this scenario!  I have a scripts that backup
necessary components (like databases) and then finally tar with gzip
compression and then SCP the file to a remote data center (I also use
public keys to automate this).  I have found this works very well in my
situation and has saved my life in the case of a MySQL database crash!

Would it be safe for me to delete these core files and start working on
this task from this day forward?  What can I use to read these core files? I noticed they're not text files so I assume there is some bb utility to
read them.  With the exception of these core* files, I would expect Hobbit
to peak at 200MB which I could do in a ~3 minutes

On Fri, 19 Oct 2007, Stef Coene wrote:

Would it be safe for me to delete these core files and start working on
this task from this day forward?  What can I use to read these core files? > I noticed they're not text files so I assume there is some bb utility to
read them.  With the exception of these core* files, I would expect Hobbit
to peak at 200MB which I could do in a ~3 minutes

You can delete the core files, but you should also try to find out why the are created.  If you use rsync, you can exclude these core files from being rsync'd

On 10/19/07, Stef Coene <user-dbffe946c0f4@xymon.invalid> wrote:

On Thursday 18 October 2007, Josh Luthman wrote:

I've only had Hobbit running since last Monday.  I have restarted it
twice
to ensure that my configurations would take place (things like changing
the
WWW hostname).  I last restarted it yesterday and it has been running
since
yesterday, so I know if it is restarting it takes more then a day.  I
have
40787 total core* files in ~/server and 569364 total core* files in
~/server/bin - couldn't possibly have restarted that many times!

Look at the timestamps of these files.  Each crash can create a core
file.  So
each visit to the hobbit site, every poll hobbit does, every rrd update
can
create a crash and a core file.  I never had a crash/core file, but in
theory
it can.
We also use vmware so if a hobbit server goes down, I copy the vmware
guest
that I use to deploy new installations, copy over the etc directory, goes
to
the custumer, pick a computer/desktop/laptop/server, install vmware player
and hobbit is running again.

Stef - If you have two Hobbit servers and duplicate your actions, why do
you note your actions?  My original plan was to tar the home directory
of
the hobbit user, but as

I don't have 2 hobbit servers, but more then 20 located for our customers.
The bare mimal I need for re-creating the same setup is the contents of
etc
and some extra information I collected during the installation (hostname,
network settings, ...).

"Hobbit User" - I could use rsync and it would make backups though I
normally don't use rsync as I like to have daily backups, in case I make
a
mistake on Monday, the backup is done Tuesday and I catch it on

Wednesday -

I can revert to Sunday with daily backups.  Rsync could have backed up
my
problem making it useless in this scenario!  I have a scripts that
backup
necessary components (like databases) and then finally tar with gzip
compression and then SCP the file to a remote data center (I also use
public keys to automate this).  I have found this works very well in my
situation and has saved my life in the case of a MySQL database crash!

You don't have to rsync everything in the same way.  If you look at the
hobbit
server data, the stuff in the data directory takes op 99% of the disk
space.
And that stuff can be rsync'd and overwritten daily.  For the server
installation, you can also use rsync but do something like this:
rsync -Auhv --delete ~hobbit/server/ <remote>:/backup/hobbit/server-`date
+%a`
So every day of the week you will have a new directory so you have a
history
of 7 days.

Would it be safe for me to delete these core files and start working on
this task from this day forward?  What can I use to read these core
files?
I noticed they're not text files so I assume there is some bb utility to
read them.  With the exception of these core* files, I would expect

Hobbit

to peak at 200MB which I could do in a ~3 minutes

You can delete the core files, but you should also try to find out why the
are
created.  If you use rsync, you can exclude these core files from being
rsync'd


Stef

-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

Josh Luthman wrote:

For now I deleted the core* files and within a few minutes the server/bin
dir started filling up with the core* files.  I user-18e74e9d22fa@xymon.invalid and I
see 25165 lines that look like:

2007-10-18 17:39:05 Cannot open the all-events file
'/home/user/data/hist/allevents'
2007-10-18 17:39:05 Worker process died with exit code 139, terminating

Josh Luthman wrote:

Stef,

Thanks for the suggestions!  I'll keep these in mind when it comes 
time to creating my backups.

For now I deleted the core* files and within a few minutes the 

2007-10-18 17:39:05 Cannot open the all-events file '/home/user/data/hist/allevents'
2007-10-18 17:39:05 Worker process died with exit code 139, terminating
  
The log is filled with this pair of lines, over and over (though I 
don't know why the number of lines is odd).  What should this 
allevents file contain?

Josh

On 10/19/07, *Stef Coene* <user-dbffe946c0f4@xymon.invalid 
<mailto:user-dbffe946c0f4@xymon.invalid>> wrote:

    On Thursday 18 October 2007, Josh Luthman wrote:

I've only had Hobbit running since last Monday.  I have
    restarted it twice
to ensure that my configurations would take place (things like
    changing the
WWW hostname).  I last restarted it yesterday and it has been
    running since
yesterday, so I know if it is restarting it takes more then a
    day.  I have
40787 total core* files in ~/server and 569364 total core* files in
~/server/bin - couldn't possibly have restarted that many times!

    Look at the timestamps of these files.  Each crash can create a
    core file.  So
    each visit to the hobbit site, every poll hobbit does, every rrd
    update can
    create a crash and a core file.  I never had a crash/core file,
    but in theory
    it can.
    We also use vmware so if a hobbit server goes down, I copy the
    vmware guest
    that I use to deploy new installations, copy over the etc
    directory, goes to
    the custumer, pick a computer/desktop/laptop/server, install
    vmware player
    and hobbit is running again.

Stef - If you have two Hobbit servers and duplicate your
    actions, why do
you note your actions?  My original plan was to tar the home
    directory of
the hobbit user, but as

    I don't have 2 hobbit servers, but more then 20 located for our
    customers.
    The bare mimal I need for re-creating the same setup is the
    contents of etc
    and some extra information I collected during the installation
    (hostname,
    network settings, ...).

"Hobbit User" - I could use rsync and it would make backups though I
normally don't use rsync as I like to have daily backups, in
    case I make a
mistake on Monday, the backup is done Tuesday and I catch it on

    Wednesday -

I can revert to Sunday with daily backups.  Rsync could have
    backed up my
problem making it useless in this scenario!  I have a scripts
    that backup
necessary components (like databases) and then finally tar with
    gzip
compression and then SCP the file to a remote data center (I
    also use
public keys to automate this).  I have found this works very
    well in my
situation and has saved my life in the case of a MySQL database
    crash!

    You don't have to rsync everything in the same way.  If you look
    at the hobbit
    server data, the stuff in the data directory takes op 99% of the
    disk space.
    And that stuff can be rsync'd and overwritten daily.  For the server
    installation, you can also use rsync but do something like this:
    rsync -Auhv --delete ~hobbit/server/
    <remote>:/backup/hobbit/server-`date +%a`
    So every day of the week you will have a new directory so you have
    a history
    of 7 days.

Would it be safe for me to delete these core files and start
    working on
this task from this day forward?  What can I use to read these
    core files?
I noticed they're not text files so I assume there is some bb
    utility to
read them.  With the exception of these core* files, I would
    expect Hobbit
to peak at 200MB which I could do in a ~3 minutes

    You can delete the core files, but you should also try to find out
    why the are
    created.  If you use rsync, you can exclude these core files from
    being
    rsync'd


    Stef


-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

On 10/19/07, Iain Conochie <user-c784e16a5170@xymon.invalid> wrote:

Josh Luthman wrote:

Stef,

Thanks for the suggestions!  I'll keep these in mind when it comes
time to creating my backups.

For now I deleted the core* files and within a few minutes the
server/bin dir started filling up with the core* files.  I looked at
history.log and I see 25165 lines that look like:

2007-10-18 17:39:05 Cannot open the all-events file

'/home/user/data/hist/allevents'

2007-10-18 17:39:05 Worker process died with exit code 139, terminating

The log is filled with this pair of lines, over and over (though I
don't know why the number of lines is odd).  What should this
allevents file contain?

This file contains a list of all event changes, i.e. when a test changes
colour. It is the basic history file.

Is it writable by your hobbit user?

Iain

Josh

On 10/19/07, *Stef Coene* <user-dbffe946c0f4@xymon.invalid
<mailto:user-dbffe946c0f4@xymon.invalid>> wrote:

    On Thursday 18 October 2007, Josh Luthman wrote:

I've only had Hobbit running since last Monday.  I have
    restarted it twice
to ensure that my configurations would take place (things like
    changing the
WWW hostname).  I last restarted it yesterday and it has been
    running since
yesterday, so I know if it is restarting it takes more then a
    day.  I have
40787 total core* files in ~/server and 569364 total core* files
in
~/server/bin - couldn't possibly have restarted that many times!

    Look at the timestamps of these files.  Each crash can create a
    core file.  So
    each visit to the hobbit site, every poll hobbit does, every rrd
    update can
    create a crash and a core file.  I never had a crash/core file,
    but in theory
    it can.
    We also use vmware so if a hobbit server goes down, I copy the
    vmware guest
    that I use to deploy new installations, copy over the etc
    directory, goes to
    the custumer, pick a computer/desktop/laptop/server, install
    vmware player
    and hobbit is running again.

Stef - If you have two Hobbit servers and duplicate your
    actions, why do
you note your actions?  My original plan was to tar the home
    directory of
the hobbit user, but as

    I don't have 2 hobbit servers, but more then 20 located for our
    customers.
    The bare mimal I need for re-creating the same setup is the
    contents of etc
    and some extra information I collected during the installation
    (hostname,
    network settings, ...).

"Hobbit User" - I could use rsync and it would make backups though

I

normally don't use rsync as I like to have daily backups, in
    case I make a
mistake on Monday, the backup is done Tuesday and I catch it on

    Wednesday -

I can revert to Sunday with daily backups.  Rsync could have
    backed up my
problem making it useless in this scenario!  I have a scripts
    that backup
necessary components (like databases) and then finally tar with
    gzip
compression and then SCP the file to a remote data center (I
    also use
public keys to automate this).  I have found this works very
    well in my
situation and has saved my life in the case of a MySQL database
    crash!

    You don't have to rsync everything in the same way.  If you look
    at the hobbit
    server data, the stuff in the data directory takes op 99% of the
    disk space.
    And that stuff can be rsync'd and overwritten daily.  For the server
    installation, you can also use rsync but do something like this:
    rsync -Auhv --delete ~hobbit/server/
    <remote>:/backup/hobbit/server-`date +%a`
    So every day of the week you will have a new directory so you have
    a history
    of 7 days.

Would it be safe for me to delete these core files and start
    working on
this task from this day forward?  What can I use to read these
    core files?
I noticed they're not text files so I assume there is some bb
    utility to
read them.  With the exception of these core* files, I would
    expect Hobbit
to peak at 200MB which I could do in a ~3 minutes

    You can delete the core files, but you should also try to find out
    why the are
    created.  If you use rsync, you can exclude these core files from
    being
    rsync'd


    Stef


--
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

On 10/19/07, Martin Flemming <user-f286aaa49a76@xymon.invalid> wrote:

On Fri, 19 Oct 2007, Stef Coene wrote:

Would it be safe for me to delete these core files and start working
on
this task from this day forward?  What can I use to read these core
files?
I noticed they're not text files so I assume there is some bb utility
to
read them.  With the exception of these core* files, I would expect

Hobbit

to peak at 200MB which I could do in a ~3 minutes

You can delete the core files, but you should also try to find out why
the are
created.  If you use rsync, you can exclude these core files from being
rsync'd

.. and you can check "why they crashed" with

http://www.hswn.dk/hobbit/help/known-issues.html#bugreport

# If one of the Hobbit tools crashes and leaves a core-file (usually in
the ~hobbit/server/tmp/ directory), please use the gdb tool to pinpoint
where the crash occurred:

    * Login as the Hobbit user
    * $ cd ~/server
      $ gdb bin/PROGRAMFILE tmp/COREFILE
      then at the gdb> prompt, execute the command
      gdb> bt


Cheers,

       Martin

-- 
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

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

Frank Flynn wrote:

Hi Everyone,

So I've got Hobbit all set up and working just fine.  Now when a server times out it will send email to my cell phone (a regular email to the phone number @ att.net).  But the text is too long for one SMS and because of the way ATT's gateway works I will get 3 messages on a RED and 6 when it goes GREEN.

Is there a way to shorten the message for the phones?  Ideally I'd like the message to be short for the phone but long for true emails but I can live with everyone getting the short message.

Any ideas?

Meserole, Keith W. a écrit :

All, getting an error on the compilation of today’s download of 4.3 
snapshot.

/usr/local/bin/gcc -g -O2 -Wall -Wno-unused -D_REENTRANT -DSunOS -I. 
-I/tmp/4.3/snapshot/include -I/usr/local/include -I. -I../incl

ude -c -o locator.o locator.c

In file included from /usr/include/sys/signal.h:34,

from /usr/include/signal.h:26,

from locator.c:36:

/usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"

/usr/include/sys/siginfo.h:292: error: parse error before '}' token

/usr/include/sys/siginfo.h:294: error: parse error before '}' token

/usr/include/sys/siginfo.h:390: error: parse error before "ctid_t"

/usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'

/usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'

/usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'

/usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'

/usr/include/sys/siginfo.h:404: error: conflicting types for `__file'

/usr/include/sys/siginfo.h:273: error: previous declaration of `__file'

/usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'

/usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'

/usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'

/usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'

/usr/include/sys/siginfo.h:426: error: parse error before '}' token

/usr/include/sys/siginfo.h:428: error: parse error before '}' token

/usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t"

/usr/include/sys/siginfo.h:437: error: parse error before '}' token

In file included from /usr/include/signal.h:26,

from locator.c:36:

/usr/include/sys/signal.h:85: error: parse error before "siginfo_t"

In file included from locator.c:36:

/usr/include/signal.h:111: error: parse error before "siginfo_t"

/usr/include/signal.h:113: error: parse error before "siginfo_t"

gmake[1]: *** [locator.o] Error 1

gmake[1]: Leaving directory `/tmp/4.3/snapshot/lib'

gmake: *** [lib-build] Error 2

Gmake information

# which gmake

/usr/sfw/bin/gmake

# gmake -v

GNU Make 3.80

Copyright (C) 2002 Free Software Foundation, Inc.

Any thoughts?

On Oct 22, 2007, at 12:02 PM, Charles Jones wrote:

Are you using "format=sms" ?  ie?

HOST=somehost
MAIL user-4fd5a8861f4c@xymon.invalid format=sms

I use cingular/att and when using SMS format hobbit alerts I only  get a subject and a single line of text, so I suspect you are  getting the full normal alerts, which can be quite lengthy,  especially for "proc"

-Charles

Frank Flynn wrote:

Hi Everyone,

So I've got Hobbit all set up and working just fine.  Now when a  server times out it will send email to my cell phone (a regular  email to the phone number @ att.net).  But the text is too long  for one SMS and because of the way ATT's gateway works I will get  3 messages on a RED and 6 when it goes GREEN.

Is there a way to shorten the message for the phones?  Ideally I'd  like the message to be short for the phone but long for true  emails but I can live with everyone getting the short message.

Any ideas?

On 10/23/07, Frank Flynn <user-32aefea160e6@xymon.invalid> wrote:

Ah - I thought that was only if you had a special SMS script (in the
docs it is used with a special script - it doesn't say it has to be
used that way it's just an example).  I'll use it that way.

Thanks,
Frank


On Oct 22, 2007, at 12:02 PM, Charles Jones wrote:

Are you using "format=sms" ?  ie?

HOST=somehost
MAIL user-4fd5a8861f4c@xymon.invalid format=sms

I use cingular/att and when using SMS format hobbit alerts I only
get a subject and a single line of text, so I suspect you are
getting the full normal alerts, which can be quite lengthy,
especially for "proc"

-Charles

Frank Flynn wrote:

Hi Everyone,

So I've got Hobbit all set up and working just fine.  Now when a
server times out it will send email to my cell phone (a regular
email to the phone number @ att.net).  But the text is too long
for one SMS and because of the way ATT's gateway works I will get
3 messages on a RED and 6 when it goes GREEN.

Is there a way to shorten the message for the phones?  Ideally I'd
like the message to be short for the phone but long for true
emails but I can live with everyone getting the short message.

Any ideas?