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: 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 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? These are not from the hobbit server installation. Is it possible that you'r hobbit server is crashing a lot? Each crash can create a core file.
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, The bare minimal is the etc directory. All the rest can be reconstructed from installation media. For history information, you also need the data directory.
What I do is duplicate a hobbit server, note down what I did, make a script to tar all config files and tada, I have my DR plan.
Stef
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.
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
Thanks! Josh
On 10/18/07, Hobbit User <hobbit at epperson.homelinux.net> 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.
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
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!
Yep, have those preferences as well. The offsite rsync server (actually a retired desktop with a couple of 130 gig drives) has tar-gzip jobs that create generational backups of the rsync tree, so I keep a week's worth that way. Could be more space frugal with find . -mtime -1, but would risk losing something I deleted by accident.
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 +%aSo 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
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> btCheers,
Martin The permissions are in an above message.
The problem has already been diagnosed and fixed, thanks for the additional information though!
On 10/19/07, Martin Flemming <martin.flemming at desy.de> 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> btCheers,
MartinTo 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
i didn't see this in the list of know issues page:
core file header read successfully Reading ld.so.1 Reading libresolv.so.2 Reading libsocket.so.1 Reading libnsl.so.1 Reading libc.so.1 program terminated by signal ABRT (Abort) 0xfee60717: __lwp_kill+0x0007: jae __lwp_kill+0x15 [ 0xfee60725, .+0xe ] Current function is bbh_item 466 p = strrchr(host->page->pagetitle, '/'); (dbx) where
[1] __lwp_kill(0x1, 0x6), at 0xfee60717 [2] _thr_kill(0x1, 0x6), at 0xfee5ded4 [3] raise(0x6), at 0xfee0ced3 [4] abort(0x8071c20, 0x0, 0x8046758, 0xfee4dd4f, 0x8046758, 0xfee4dd4f), at 0xfedf0969 [5] 0x80581fe(0xb, 0x0, 0x80467f0), at 0x80581fe [6] __sighndlr(0xb, 0x0, 0x80467f0, 0x80581d0), at 0xfee5fadf [7] call_user_handler(0xb, 0x0, 0x80467f0), at 0xfee560d3 [8] sigacthandler(0xb, 0x0, 0x80467f0, 0xf, 0x0, 0x0), at 0xfee56253 ---- called from signal handler with signal 11 (SIGSEGV) ------ =>[9] bbh_item(hostin = 0x80739a8, item = BBH_NET), line 466 in "loadhosts.c" [10] load_hostnames(bbhostsfn = (nil), extrainclude = 0x8046ddc "hobbitd_channel", fqdn = 134508012), line 112 in "loadhosts_file.c"
two cores so far, i don't understand the "fqdn = 134508012" portion of the error
All, getting an error on the compilation of today's download of 4.3 snapshot.
Platform: Solaris 10 X86. Sorry for the long post but I wanted to put out all the details to start with.
Step 1 - Configure completed successfully: MAKE=gmake ./configure.server
MAKE=gmake ./configure.server
Configuration script for Hobbit
This script asks a few questions and builds a Makefile to compile Hobbit
Checking your make-utility
Checking pre-requisites for building Hobbit
Checking for fping ...
Hobbit has a built-in ping utility (hobbitping)
However, it is not yet fully stable and therefore it
may be best to use the external fping utility instead.
I found fping in /usr/local/sbin/fping
Do you want to use it [Y/n] ?
y
Checking to see if '/usr/local/sbin/fping 127.0.0.1' works ...
127.0.0.1 is alive
OK, will use '/usr/local/sbin/fping' for ping tests
NOTE: If you are using an suid-root wrapper, make sure the 'hobbit'
user is also allowed to run fping without having to enterpasswords.
For 'sudo', add something like this to your 'sudoers' file:
hobbit: ALL=(ALL) NOPASSWD: /usr/local/sbin/fpingChecking for RRDtool ...
test-rrd.c: In function `main':
test-rrd.c:30: error: too few arguments to function `rrd_graph'
gmake: *** [test-compile] Error 1
Not RRDtool 1.0.x, checking for 1.2.x
Found RRDtool include files in /usr/local/rrdtool-1.2.19/include
Found RRDtool libraries in /usr/local/rrdtool-1.2.19/lib
Linking RRD with PNG library: -L/usr/lib -lpng
y
Checking for PCRE ...
Found PCRE include files in /usr/local/include
Found PCRE libraries in /usr/local/lib
Checking for OpenSSL ...
yFound OpenSSL include files in /usr/local/ssl/include
Found OpenSSL libraries in /usr/local/ssl/lib
Hobbit can use the OpenSSL library to test SSL-enabled services
like POP3S, IMAPS, NNTPS and TELNETS. If you have the OpenSSL
library installed, I recommend that you enable this.
Do you want to be able to test SSL-enabled services (y) ?
Checking for LDAP ...
test-ldap.c: In function `main':
test-ldap.c:16: warning: implicit declaration of function `ldap_init'
test-ldap.c:16: warning: assignment makes pointer from integer without a cast
Found LDAP include files in /usr/include
Found LDAP libraries in /usr/lib
Hobbit can use your OpenLDAP LDAP client library to test LDAP servers.
Do you want to be able to test LDAP servers (y) ?
Enable experimental support for LDAP/SSL (OpenLDAP 2.x only) (y) ?
y
Checking for Large File Support ...
ERROR: LFS support check failed for standard file support
Setting up for a Hobbit server
What userid will be running Hobbit [hobbit] ?
Found passwd entry for user hobbit:x:102:100::/export/home/hobbit:/bin/sh
Where do you want the Hobbit installation [/export/home/hobbit] ?
OK, will configure to use /export/home/hobbit as the Hobbit toplevel directory
What URL will you use for the Hobbit webpages [/hobbit] ?
Where to put the Hobbit CGI scripts [/export/home/hobbit/cgi-bin] ?
(Note: This is the filesystem directory - we will get to the URL shortly)
What is the URL for the Hobbit CGI directory [/hobbit-cgi] ?
(Note: This is the URL - NOT the filesystem directory)
********************** SECURITY NOTICE ****************************
If your Hobbit server is accessible by outsiders, then you should
restrict access to the CGI scripts that handle enable/disable of
hosts, and acknowledging of alerts. The easiest way to do this is
to put these in a separate CGI directory and require a password to
access them.
Even if your Hobbit server is on a secured, internal network, you
may want to have some operations (like disabling a host) be password-
protected - that lets you see who disabled or acknowledged an alert.
Where to put the Hobbit Administration CGI scripts [/export/home/hobbit/cgi-secure] ?
(Note: This is the filesystem directory - we will get to the URL shortly)
What is the URL for the Hobbit Administration CGI directory [/hobbit-seccgi] ?
(Note: This is the URL - NOT the filesystem directory)
** Note that you may need to modify your webserver configuration.
** After installing, see /export/home/hobbit/server/etc/hobbit-apache.conf for an example configuration.
To generate Hobbit availability reports, your webserver
must have write-access to a directory below the Hobbit
top-level directory. I can set this up if you tell me
what group-ID your webserver runs with. This is typically
'nobody' or 'apache' or 'www-data'
What group-ID does your webserver use [nobody] ?
Where to put the Hobbit logfiles [/var/log/hobbit] ?
What is the name of this host [solaris01] ?
What is the IP-address of this host [127.0.0.1] ?
192.168.0.182
Where should I install the Hobbit man-pages (/usr/local/man) ?
Using SunOS Makefile settings
Created Makefile with the necessary information to build Hobbit
Some defaults are used, so do look at the Makefile before continuing.
Configuration complete - now run gmake (GNU make) to build the tools
Step 2 - gmake fails. Gmake version info at the end...
gmake
MAKE="gmake" CC="/usr/local/bin/gcc" CFLAGS="-g -O2 -Wall -Wno-unused
-D_REENTRANT -DSunOS -I. -Ipwd/include -I/usr/local/include
" LDFLAGS="" pwd/build/genconfig.sh
Checking for socklen_t
Checking for snprintf
Checking for vsnprintf
Checking for rpc/rpcent.h
Checking for sys/select.h
Checking for u_int32_t typedef
Checking for PATH_MAX definition
Checking for SHUT_RD/WR/RDWR definitions
config.h created
CC="/usr/local/bin/gcc" CFLAGS="-g -O2 -Wall -Wno-unused -D_REENTRANT
-DSunOS -I. -Ipwd/include -I/usr/local/include" LDFLAGS=""
OSDEF="-DSunOS" RPATHOPT="" PCREINCDIR="-I/usr/local/include" SSLFLAGS="-DBBGEN_SSL" SSLINCDIR="-I/usr/local/ssl/include " SSLLIBS="
-L/usr/local/ssl/lib -lssl -lcrypto" NETLIBS="-lresolv -lsocket -lnsl" BBTOPDIR="/export/home/hobbit" BBLOGDIR="/var/log/hobbit" BBH
OSTNAME="solaris01" BBHOSTIP="192.168.0.182" BBHOSTOS="sunos" gmake -C lib all
gmake[1]: Entering directory `/tmp/4.3/snapshot/lib'
/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 -o test-endianness test-endianness.c
/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 osdefs.o osdefs.c
/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 acklog.o acklog.c
/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 availability.o availability.c
/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 calc.o calc.c
/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 cgi.o cgi.c
/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 cgiurls.o cgiurls.c
/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 clientlocal.o clientlocal.c
/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 color.o color.c
/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 digest.o digest.c
/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 encoding.o encoding.c
/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 -DBBTOPDIR=\"/export/home/hobbit\" -DBBLOGDIR=\"/var/log/hobbit\" -DBBHOSTNAME=\"solaris01\" -DBBHOSTIP=\"192.168.0.182\" -DBBH
OSTOS=\"sunos\" -DBUILD_HOME=\"/export/home/hobbit/server\" -c -o environ.o environ.c
/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 errormsg.o errormsg.c
/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 -I/usr/local/include -c -o eventlog.o eventlog.c
/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 files.o files.c
/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 -I/usr/local/include -c -o headfoot.o headfoot.c
/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 hobbitrrd.o hobbitrrd.c
hobbitrrd.c: In function `hobbit_graph_text':
hobbitrrd.c:287: warning: int format, time_t arg (arg 3)
hobbitrrd.c:287: warning: int format, time_t arg (arg 4)
/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 holidays.o holidays.c
/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 htmllog.o htmllog.c
/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 ipaccess.o ipaccess.c
/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 -I/usr/local/include -c -o loadalerts.o loadalerts.c
/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 loadhosts.o loadhosts.c
loadhosts.c: In function `bbh_find_item':
loadhosts.c:216: warning: return discards qualifiers from pointer target type
loadhosts.c: In function `bbh_item_id':
loadhosts.c:593: warning: return discards qualifiers from pointer target type
/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 loadnkconf.o loadnkconf.c
/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?
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?
you should check if there are any patches from sun for this file. (sorry I don't remember the name of the package).
otherwise try to save a copy of the two header files, and search through them at the first error hpow you could patch it manually.
you should also check with an older release of gcc if it's possible.
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?
Josh
On 10/19/07, Stef Coene <stef.coene at docum.org> 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 +%aSo 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
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
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 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
What are the permissions of /home/user/data/hist/allevents ?
A trace of the core dump will help with this. Follow the instructions in the "How to report bugs" section of the "Known problems" entry under the Help menu, then post the backtrace to the list.
Tom
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* <stef.coene at docum.org <mailto:stef.coene at docum.org>> 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 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
No it was not - just 444. I added write for the Hobbit user/group.
It's been 20m and the history.log has not said a thing. I believe it is fixed.
The grand total data size for the Hobbit user's home directory is 100M - uncompressed. This will be very easy to backup with either method.
Thanks a whole lot guys, greatly appreciate the help!
Josh
On 10/19/07, Iain Conochie <iain at shihad.org> 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* <stef.coene at docum.org <mailto:stef.coene at docum.org>> 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* filesin
> ~/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 thoughI
> 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 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
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
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?
Frank
Are you using "format=sms" ? ie?
HOST=somehost MAIL you at mobile.att.net 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?
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 you at mobile.att.net 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?
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
The "format=sms" alerts were actually too short for me, so I wrote a script that gives slightly more information. It's available for download from The Shire: http://www.trantor.org/theshire/doku.php/alerts
On 10/23/07, Frank Flynn <frank at declan.com> 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 you at mobile.att.net 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?
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
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:josh at imaginenetworksllc.com] Sent: Thursday, October 18, 2007 2:55 PM To: hobbit at hswn.dk 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: 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
I definitely brought up the wrong terminology, sorry about that! I don't need to get into man in the middle attacks or DNS changes between servers. Hours is something I am after. I just need to have the station back up before the end of the day.
Your 1a suggestion is excellent, very good idea! I'll look into that down the road when it is more mission critical, thanks! Your second suggestion, while absolutely ingenious, is going to be more of a hassle to keep updated then it will be a convenience (at least for my needs).
Over the last four hours the size of the directory went from 1023MB to 951MB. What is going on here?! I'm so confused =( Is it absolutely safe to delete the core files? I would like to see if they continue showing up when I'm sure that Hobbit has not been restarting.
Josh
On 10/18/07, Haertig, David F (Dave) <haertig at avaya.com> 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:josh at imaginenetworksllc.com] *Sent:* Thursday, October 18, 2007 2:55 PM *To:* hobbit at hswn.dk *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: 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
-- 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
participants (13)
-
frank＠declan.com
-
gumby3203＠gmail.com
-
haertig＠avaya.com
-
hobbit＠epperson.homelinux.net
-
iain＠shihad.org
-
jonescr＠cisco.com
-
josh＠imaginenetworksllc.com
-
km＠keithm.us
-
martin.flemming＠desy.de
-
pkc_mls＠yahoo.fr
-
sclark＠nyroc.rr.com
-
stef.coene＠docum.org
-
tomg＠mcclatchyinteractive.com