Menu
▾
▴
bobs-devel
|
From: Jochen M. <j.m...@om...> - 2004-12-06 13:01:58
|
Hi Rene, Hi Joe, i am inplementing for a customer and I thinking about logging stuff what we talked about a couple of months ago. Mainly I want: 1. Have logging what has be updated and what failed. 2. Be sure that bobs is still running properly as I work with companies and then let things running and maybe get notified when something went wrong. I have a couple of hours of budget to do some stuff and I want to discuss it with you first to then put it in the cvs afterwards. At present I wrote a workaround (quite a quickhack) that writes a timestamp and checks that. (I have to figure out, how I did that and if it makes sense to the main version) Any ideas ? Jochen Metzger -- omatix.de internet services omatix training & solutions omatix onlineverlag Jochen Metzger j.m...@om... Telefon +49(30) 40301160 Fax +49(30) 78709296 -- Hosting für Ihr Business: http://hosting.omatix.de |
|
From: Joe Z. <joe...@za...> - 2004-12-06 17:35:09
|
Jochen Metzger wrote:
>Hi Rene,
>Hi Joe,
>
>i am inplementing for a customer and I thinking about logging stuff what
>we talked about a couple of months ago.
>
>Mainly I want:
>
>1. Have logging what has be updated and what failed.
>2. Be sure that bobs is still running properly
>
>as I work with companies and then let things running
>and maybe get notified when something went wrong.
>
>I have a couple of hours of budget to do some stuff
>and I want to discuss it with you first to then put
>it in the cvs afterwards.
>
>At present I wrote a workaround (quite a quickhack)
>that writes a timestamp and checks that.
>(I have to figure out, how I did that and if it makes
>sense to the main version)
>
>Any ideas ?
>
>Jochen Metzger
>
>
>
Have you got the latest version from cvs? It writes all output to
bobs.log and includes the timestamp. I get the output from cron every
day and I also run this cron command to give me a brief(er) listing:
head -n 1 /var/log/bobs.log; /bin/grep -E ': Starting backup|: wrote
|: total size is ' /var/log/bobs.log; tail -n 1 /var/log/bobs.log
It's helpful, but I was thinking of adding real error checking to the
backup scripts to say things like "successful backup of <server/share>"
or "backup failed for <server/share>", with optional email notification.
But I won't be getting to it anytime soon.
To know if bobs is not running would require a 2nd cron job to check
something, like the timestamp you write. I'm thinking that's what you
have in mind. That's not a bad idea for monitoring your customers system.
Joe
|
|
From: Joe Z. <jz...@co...> - 2005-01-17 06:40:24
|
Joe Zacky wrote: > Jochen Metzger wrote: > >> Hi Rene, >> Hi Joe, >> >> i am inplementing for a customer and I thinking about logging stuff what >> we talked about a couple of months ago. >> >> Mainly I want: >> >> 1. Have logging what has be updated and what failed. >> 2. Be sure that bobs is still running properly >> >> as I work with companies and then let things running >> and maybe get notified when something went wrong. >> >> I have a couple of hours of budget to do some stuff >> and I want to discuss it with you first to then put >> it in the cvs afterwards. >> >> At present I wrote a workaround (quite a quickhack) >> that writes a timestamp and checks that. >> (I have to figure out, how I did that and if it makes >> sense to the main version) >> >> Any ideas ? >> Jochen Metzger >> >> >> > It's helpful, but I was thinking of adding real error checking to the > backup scripts to say things like "successful backup of > <server/share>" or "backup failed for <server/share>", with optional > email notification. But I won't be getting to it anytime soon. > > Joe Circumstances have forced me to get to it soon. One of the file servers where I work hadn't been getting fully backed up since November and I didn't know about it until I was asked to restore a file. So I spent a couple days last week working on error checking and logging in bobs. Here's the short synopsis, I'll explain more in detail when I'm ready to check into cvs. I put all the commands for the various backups into bash script templates (rFastTemplates) that are created by class_backup.php. Some of the code from class_backup.php was moved to the templates. The templates include return code checking on all the commands (mount, rsync, umount, etc.) and a function to send an optional completion status email, i.e. "BACKUP FAILED for server/share with returncode xx" or "Successful backup of server/share". The "BACKUP FAILED..." and "Successful backup..." are also logged into bobs.log. If you don't want the optional email for each backup, you could still 'grep' the completion messages from the log. The templates make the code much cleaner and will allow easy customization of backups. For example, you can remove the '--verbose' from the rsync, if you want to. I'm planning to include a customized template directory that you can copy the template to and change it there. If a customized template exists, it will be used instead of the standard template. That will allow you to keep your customizations when re-installing or upgrading bobs. It's been working very well the past week. I get a short email after each backup, if it failed I take a look at bobs.log to see why. I've done the smb and rsync-ssh templates, still need to do the others. I'm also looking into some other errors I see in bobs.log, mostly having to do with stat() and is_dir() on very large files failing while building the indexes after the backup has run. It seems it's a libc or glibc problem, but I need to handle the failure properly in the script. This should at least address the first item you mentioned: to log what has been updated and what failed. I'm hoping to put what I've done so far into cvs this week. Not sure when I'll get to finish it, but I hope soon, I think it's an important improvement. |
|
From: Manfred R. <mre...@co...> - 2005-01-17 08:15:09
|
Am Montag, 17. Januar 2005 07:39 schrieb Joe Zacky: > > It's been working very well the past week. I get a short email after > each backup, if it failed I take a look at bobs.log to see why. I've > done the smb and rsync-ssh templates, still need to do the others. I'm > also looking into some other errors I see in bobs.log, mostly having to > do with stat() and is_dir() on very large files failing while building > the indexes after the backup has run. It seems it's a libc or glibc > problem, but I need to handle the failure properly in the script. > This is a problem of PHP. The PHP-Engine and all add-ons have to be compiled with the Option -D _FILE_OFFSET_BITS=64 . Without this option the stat member st_size (type off_t) has only 32 Bit. I did not know, if we can compile PHP with this option, because there are more changes needed (or the developers were very strong while using types). The glibc does support it very well. Manfred |
|
From: Joe Z. <joe...@za...> - 2005-01-17 18:34:29
|
Manfred Rebentisch wrote: >Am Montag, 17. Januar 2005 07:39 schrieb Joe Zacky: > > >>It's been working very well the past week. I get a short email after >>each backup, if it failed I take a look at bobs.log to see why. I've >>done the smb and rsync-ssh templates, still need to do the others. I'm >>also looking into some other errors I see in bobs.log, mostly having to >>do with stat() and is_dir() on very large files failing while building >>the indexes after the backup has run. It seems it's a libc or glibc >>problem, but I need to handle the failure properly in the script. >> >> >> > >This is a problem of PHP. The PHP-Engine and all add-ons have to be compiled >with the Option -D _FILE_OFFSET_BITS=64 . >Without this option the stat member st_size (type off_t) has only 32 Bit. > >I did not know, if we can compile PHP with this option, because there are more >changes needed (or the developers were very strong while using types). > >The glibc does support it very well. > >Manfred > > Thank you for that explanation, Manfred. My philosophy is to support the lowest. common denominator. In other words, it should work on a standard installation. So I'm going to see if I can simply handle that error in the php script and do some appropriate default action. For example, if it gets that error on an is_dir(), maybe I can just assume it's not a directory. I'll have to take a closer look at the script. Joe |
|
From: Joe Z. <joe...@za...> - 2005-01-26 00:19:46
|
Manfred Rebentisch wrote: >Am Montag, 17. Januar 2005 07:39 schrieb Joe Zacky: > > >>It's been working very well the past week. I get a short email after >>each backup, if it failed I take a look at bobs.log to see why. I've >>done the smb and rsync-ssh templates, still need to do the others. I'm >>also looking into some other errors I see in bobs.log, mostly having to >>do with stat() and is_dir() on very large files failing while building >>the indexes after the backup has run. It seems it's a libc or glibc >>problem, but I need to handle the failure properly in the script. >> >> >> > >This is a problem of PHP. The PHP-Engine and all add-ons have to be compiled >with the Option -D _FILE_OFFSET_BITS=64 . >Without this option the stat member st_size (type off_t) has only 32 Bit. > >I did not know, if we can compile PHP with this option, because there are more >changes needed (or the developers were very strong while using types). > >The glibc does support it very well. > >Manfred > > I'm not doubting you, nor do I pretend to understand anything about libc/glibc. This link is where I got my information. Please take a look at it. http://bugs.php.net/bug.php?id=27765 It won't change how I handle the error because whether it's a php or libc problem, the error has to be handled in the php script. I can't expect everyone that uses bobs to patch their libc and/or rebuild php. Joe |
|
From: Manfred R. <mre...@co...> - 2005-01-26 09:47:11
|
Am Mittwoch, 26. Januar 2005 01:19 schrieb Joe Zacky: > Manfred Rebentisch wrote: > > > >This is a problem of PHP. The PHP-Engine and all add-ons have to be > > compiled with the Option -D _FILE_OFFSET_BITS=64 . > >Without this option the stat member st_size (type off_t) has only 32 Bit. > > > >I did not know, if we can compile PHP with this option, because there are > > more changes needed (or the developers were very strong while using > > types). > > > >The glibc does support it very well. > > > >Manfred > > I'm not doubting you, nor do I pretend to understand anything about > libc/glibc. This link is where I got my information. Please take a look > at it. > > http://bugs.php.net/bug.php?id=27765 > > It won't change how I handle the error because whether it's a php or > libc problem, the error has to be handled in the php script. I can't > expect everyone that uses bobs to patch their libc and/or rebuild php. > > Joe Ok, I saw the error on a RedHat 7.3 Machine, never on the SLES 9 (SuSE Linux Enterprise Server 9). The older glibc may have this "error". It is hard to change the glibc... It is better to use a newer Linux. Manfred |
|
From: Jochen M. <j.m...@om...> - 2005-01-17 09:53:37
|
Hi Joe, congratulations. > > I'm hoping to put what I've done so far into cvs this week. Not sure > when I'll get to finish it, but I hope soon, I think it's an important > improvement. jepp, me too. |
|
From: Jochen M. <j.m...@om...> - 2005-01-26 10:43:02
|
Hi Joe, still there is another problem concerning compability. I installed the system on Suse 9.2 - Machine. Problem: There's no db3 or db4 support precompiled in php. So I had to recompile it. |
|
From: Joe Z. <joe...@za...> - 2005-01-26 17:04:02
|
Jochen Metzger wrote: >Hi Joe, > >still there is another problem concerning compability. >I installed the system on Suse 9.2 - Machine. > >Problem: There's no db3 or db4 support precompiled in >php. > >So I had to recompile it. > > > What type of database support is precompiled in php on Suse 9.2? Joe |
|
From: Jochen M. <j.m...@om...> - 2005-01-26 17:21:19
|
Hi Joe, I'll check ASAP. Cheers. Am Mi, 2005-01-26 um 18.04 schrieb Joe Zacky: > Jochen Metzger wrote: > > >Hi Joe, > > > >still there is another problem concerning compability. > >I installed the system on Suse 9.2 - Machine. > > > >Problem: There's no db3 or db4 support precompiled in > >php. > > > >So I had to recompile it. > > > > > > > What type of database support is precompiled in php on Suse 9.2? > > Joe > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel -- omatix.de internet services omatix training & solutions omatix onlineverlag Jochen Metzger j.m...@om... Telefon +49(30) 40301160 Fax +49(30) 78709296 -- Hosting für Ihr Business: http://hosting.omatix.de |
|
From: Joe Z. <joe...@za...> - 2005-01-26 17:36:25
|
Jochen Metzger wrote: >Hi Joe, > >I'll check ASAP. > > There's no hurry. I'm too busy to work on it this week anyway. |
|
From: Manfred R. <mre...@co...> - 2005-01-26 19:53:36
|
Am Mittwoch, 26. Januar 2005 18:04 schrieb Joe Zacky: > Jochen Metzger wrote: > >Hi Joe, > > > >still there is another problem concerning compability. > >I installed the system on Suse 9.2 - Machine. > > > >Problem: There's no db3 or db4 support precompiled in > >php. Use gdbm with SuSE. Manfred |
|
From: Jochen M. <j.m...@om...> - 2005-01-26 20:04:12
|
Hi Joe, > Use gdbm with SuSE. > would it be hard to implement that ? Cheers Jochen > Manfred > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel -- omatix.de internet services omatix training & solutions omatix onlineverlag Jochen Metzger j.m...@om... Telefon +49(30) 40301160 Fax +49(30) 78709296 -- Hosting für Ihr Business: http://hosting.omatix.de |
|
From: Manfred R. <mre...@co...> - 2005-01-26 20:45:55
|
Am Mittwoch, 26. Januar 2005 21:04 schrieb Jochen Metzger: > Hi Joe, > > > Use gdbm with SuSE. > > would it be hard to implement that ? > I do it to implement it with my version. With BOBS you have to make some important changes (see to the older messages of this list!). BOBS uses zero keys in the database and this is not allowed in the gdbm database. But the zero keys was not a good idea, so the change may be hard, but with sense. My version of BOBS is not ready for publishing, but if you want, you can have a look to the code in this actual state. Manfred |
|
From: Joe Z. <joe...@za...> - 2005-01-26 22:05:12
|
Manfred Rebentisch wrote: >Am Mittwoch, 26. Januar 2005 21:04 schrieb Jochen Metzger: > > >>Hi Joe, >> >> >> >>>Use gdbm with SuSE. >>> >>> >>would it be hard to implement that ? >> >> >> >I do it to implement it with my version. With BOBS you have to make some >important changes (see to the older messages of this list!). > >BOBS uses zero keys in the database and this is not allowed in the gdbm >database. But the zero keys was not a good idea, so the change may be hard, >but with sense. > >My version of BOBS is not ready for publishing, but if you want, you can have >a look to the code in this actual state. > >Manfred > > > I would be interested to see what changes you made to get gdbm to work. Joe |
|
From: Manfred R. <mre...@co...> - 2005-01-27 11:12:12
|
Am Mittwoch, 26. Januar 2005 23:05 schrieb Joe Zacky: > > I would be interested to see what changes you made to get gdbm to work. > > Joe I send you the code with private mail. Our first version you can see at https://bs0005.comparat.de/bs/index.php for demonstration. We make many, many changes and new parts. We only use rsync/ssh. On bs0005 is RedHat 7.3, but further we probably use SLES 9. Manfred |
|
From: Manfred R. <mre...@co...> - 2005-01-27 11:43:42
|
I forgot to tell: my php-version, originally based on BOBS, is a temporary version for me. I work on the next version, which is written 100% in C and runs as a daemon on the linux-server. In the first version it runs as a CGI-Daemon together with a webserver, but later it will run without an external webserver. One the important next step is a mini client for Windows-Computers to avoid the problems with rsync and ssh on the Windows side. Another important point, just in development, is the online backup of running databases. We start to do it with SQLBASE (GUPTA), mySQL and PostgreSQL. Manfred |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X