Menu
▾
▴
bobs-devel — Developer mailing list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(37) |
Aug
(13) |
Sep
(33) |
Oct
(37) |
Nov
(1) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(7) |
Mar
(34) |
Apr
(41) |
May
(20) |
Jun
(13) |
Jul
(2) |
Aug
(20) |
Sep
(13) |
Oct
(8) |
Nov
(15) |
Dec
(32) |
| 2004 |
Jan
(65) |
Feb
(20) |
Mar
(29) |
Apr
(27) |
May
(37) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(18) |
| 2005 |
Jan
(18) |
Feb
(3) |
Mar
|
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(23) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rene R. <re...@gr...> - 2004-03-16 11:35:10
|
On Tue, 2004-03-16 at 04:36, Joe Zacky wrote:
> I have a plan to make bobs support both db3 and db4 in php. I'd like to
> run it by anyone who cares to comment.
>
> 1) During the ./configure phase (./configure also runs during rpm
> install) see whether db3 or db4 is supported. Set a variable in
> inc/config.php: $sys_conf["dbhandler"] would be either "db3" or "db4".
>
> 2) add a function get_db_handler() to class_config.php.
>
> 3) include class_config.php in any files that use dba_open() and use a
> variable loaded from get_db_handler() for the third parameter (db
> handler) in dba_open().
>
> A php upgrade from db3 to db4 would require re-installing bobs or just
> changing db3 to db4 in config.php.
>
> Any comments are welcome.
>
> Joe Zacky
>
I'm not too happy about this solution. It will come back to bite us. I
would really prefer a runtime php solution.
Something like:
if php >= 4.3.0
use dba_handlers() to determine available handlers
else
try to open a db4 database.
$db = dba_open("/tmp/randname", "c", "db4")
if it returns FALSE try a db3 database and check the return value.
whichever return something other than false gets the job. This would
also be easier to expand to db5 or the likes in the future.
The reason I'm not happy about the ./configure solution is that some
users _will_ upgrade their systems at some point, and they will most
likely not reinstall bobs and we will have tell them what to do every
time. I see no point in pushing a solution that will lead to problems
for the users and more support questions for us.
Having this check run every time a backup is run or a user accesses the
system (log in and creates a session) is not a problem since the
additional server load is minimal.
I hope you are on top again. Being sick is no fun :(
Cheers
Rene
|
|
From: Jochen M. <ml...@om...> - 2004-03-16 08:01:57
|
Hi Joe, sounds great. Am Di, 2004-03-16 um 04.36 schrieb Joe Zacky: > I have a plan to make bobs support both db3 and db4 in php. I'd like to > run it by anyone who cares to comment. > What are actually the fortunes about it? Cheers Jochen |
|
From: Joe Z. <jz...@co...> - 2004-03-16 03:36:37
|
I have a plan to make bobs support both db3 and db4 in php. I'd like to run it by anyone who cares to comment. 1) During the ./configure phase (./configure also runs during rpm install) see whether db3 or db4 is supported. Set a variable in inc/config.php: $sys_conf["dbhandler"] would be either "db3" or "db4". 2) add a function get_db_handler() to class_config.php. 3) include class_config.php in any files that use dba_open() and use a variable loaded from get_db_handler() for the third parameter (db handler) in dba_open(). A php upgrade from db3 to db4 would require re-installing bobs or just changing db3 to db4 in config.php. Any comments are welcome. Joe Zacky |
|
From: Rene R. <re...@gr...> - 2004-03-15 13:05:16
|
On Sun, 2004-03-14 at 20:26, Joe Zacky wrote: > Hank Hampel wrote: > > >Hi Joe! > > > >I don't know if you already got my bug report from Source Forge, so I > >thought I'd also contact you directly. Unfortunately I saw the > >"Patches" Link to late so I submitted my bug report and patch under > >"Bugs". > > > >However, here we go: > >Incorrect filesize written to DB > > > >When doing a fresh install of bobs 0.6.1 every file you > >backup has a gigantic > >filesize when it is written to the DB (over 1GB for > >every file). > > > >This is caused by an off-by-one error when the results > >of arrStat are entered into the database. > > > >See my patch file below for a correction of this little > >but very serious bug - because you can't do restores on > >small filesystems with this bug in place. > > > > > >Best regards, Hank > > > > Thanks for spotting it. I've fixed it and committed it to cvs. Cheers Rene |
|
From: Hank H. <hh...@ne...> - 2004-03-15 10:43:42
|
Hi Joe, hi everybody! On (040314), Joe Zacky wrote: > >This is caused by an off-by-one error when the results > >of arrStat are entered into the database. > Thanks for the patch Hank. Sorry I took so long to respond, I've been=20 > down with the flu. I haven't verified this problem yet because I'm=20 No problem, hope you're flu is gone by now! I wanted this bug fixed as soon as possible and it was rather clear to me that it could only be an off-by-one as the values entered into the DB pretty much looked like unix timestamps. The only real problem was locating the file where the off-by-one happend to be. > working on another bug right now. The bobs developers monitor the=20 Then I good luck in hunting it down! ;-) > bobs-devel mailing list, so I'm submitting this patch there. Ok. I hope the patch and the description of the bug are all you need to verify the problem and my solution for it. After backing up with this patch in place you should be able to note the difference in the filesizes immediately. Best regards, Hank --=20 NetTeam GmbH, Zur Degensm=FChle 3, DE-53347 Alfter/Impekoven http://www.netteam.de/impressum.php |
|
From: Joe Z. <jz...@co...> - 2004-03-14 22:35:42
|
I'm playing around with making 'cmdloop' start as a service. There are problems on some systems they way cmdloop is invoked from check_loop. Instead of putting check_loop in /etc/crontab I'd create a file in /etc/init.d/ to handle the start/stop/status of cmdloop. This would allow cmdloop to be controlled with 'chkconfig', 'service' and 'ntsysv'. Since I only have access to redhat systems I don't know what is standard for services on MAC OS X, FreeBSD, etc. Do these systems have: o The chkconfig command? o The 'service' command? o The file /etc/rc.d/init.d/functions? o The /var/run directory? If any of you with non-redhat systems could answer these questions I'd greatly appreciate it. Thanks, Joe Zacky |
|
From: Joe Z. <jz...@co...> - 2004-03-14 19:26:49
|
Hank Hampel wrote: >Hi Joe! > >I don't know if you already got my bug report from Source Forge, so I >thought I'd also contact you directly. Unfortunately I saw the >"Patches" Link to late so I submitted my bug report and patch under >"Bugs". > >However, here we go: >Incorrect filesize written to DB > >When doing a fresh install of bobs 0.6.1 every file you >backup has a gigantic >filesize when it is written to the DB (over 1GB for >every file). > >This is caused by an off-by-one error when the results >of arrStat are entered into the database. > >See my patch file below for a correction of this little >but very serious bug - because you can't do restores on >small filesystems with this bug in place. > > >Best regards, Hank > > > >------------------------------------------------------------------------ > >Index: backup_create_databases.php >=================================================================== >RCS file: /home/cvs/3rdparty/bobs/inc/templates/backup_create_databases.php,v >retrieving revision 1.1.1.1 >retrieving revision 1.3 >diff -u -r1.1.1.1 -r1.3 >--- backup_create_databases.php 8 Mar 2004 16:59:21 -0000 1.1.1.1 >+++ backup_create_databases.php 9 Mar 2004 14:13:34 -0000 1.3 >@@ -59,8 +59,8 @@ > dba_insert ($num, $filedate, $this->id); > } > // insert filesize >- // filesize in bytes is at position 8 >- $filesize = $arrStat[8]; >+ // filesize in bytes is at position 8 this is array index 7 >+ $filesize = $arrStat[7]; > $num = $range+3; > dba_insert ($num, $filesize, $this->id); > //increment the range > > Thanks for the patch Hank. Sorry I took so long to respond, I've been down with the flu. I haven't verified this problem yet because I'm working on another bug right now. The bobs developers monitor the bobs-devel mailing list, so I'm submitting this patch there. Thanks again, Joe Zacky |
|
From: Joe Z. <jz...@co...> - 2004-02-29 00:52:52
|
Corey Baldwin wrote: >This entire email also largely assumes that I know what I'm > >talking about in regards to backup solutions. I am basing this > >on a full backup being done repetitively at a specified time > >period. I understand that incremental backups will effectively > >do the same thing, but I think that a full backup done on an > >occasional is a necessary evil. If I am basing this email on > >any ignorance, please enlighten me....:) > The strategy of full backups followed by incremental backups is appropriate when backing up to tape or other media. The bobs backup is more like mirroring. A full mirror of the current files is in the 'current' directory. All the prior changes are in the 'incremental' directory. So all the current files plus all the prior changes are there. There is no point in scheduling full backups because the 'current' directory IS a full backup. If you want to have a rotation of full backups for some reason then I suggest doing a full backup to tape weekly or monthly. It will be redundant but it's good for peace of mind. Or you could copy the 'current' directory to another location weekly or monthly - that would be your rotation of full backups. Hope that helps. Joe Zacky |
|
From: Rene R. <re...@gr...> - 2004-02-13 22:20:33
|
> >> > >> > >Wouldn't it be better to only remove the files we know we installed. And > >the try to "rmdir dirname" for each dir we created. That will fail if > >there are files in the dirs we didn't create. I think that is the sanest > >way of doing this. > > > > > That's what 'make uninstall' does. I added the special 'make > uninstall-all' mostly for testing. I use it if I want to remove bobs AND > all the configuration and backup data. > > Joe Sorry. I didn't spot the "-all" in "make uninstall-all". My bad. Cheers Rene |
|
From: Joe Z. <jz...@co...> - 2004-02-13 21:32:21
|
Rene Rask wrote: >On Thu, 2004-02-12 at 21:27, Joe Zacky wrote: > > >>Rene Rask wrote: >> >> >>>These are some notes on my install of bobs 0.6.1 on a new server. >>> >>>- I could't configure bobs to be placed in "/var/www/html". I manually >>>moved the files from "/var/www/html/bobs" and edited the config.php >>>file. >>> >>> >>That's correct. Whatever directory you request, it adds /bobs to the end >>of the path. I figure that's safer to put it in a separate directory >>because I don't want to uninstall something that wasn't installed. If >>you run 'make uninstall-all' it will 'rm -rf' the entire bobs directory. >> >> >Wouldn't it be better to only remove the files we know we installed. And >the try to "rmdir dirname" for each dir we created. That will fail if >there are files in the dirs we didn't create. I think that is the sanest >way of doing this. > > That's what 'make uninstall' does. I added the special 'make uninstall-all' mostly for testing. I use it if I want to remove bobs AND all the configuration and backup data. Joe |
|
From: Rene R. <re...@gr...> - 2004-02-13 16:55:48
|
On Thu, 2004-02-12 at 21:27, Joe Zacky wrote:
> Rene Rask wrote:
>
> >These are some notes on my install of bobs 0.6.1 on a new server.
> >
> >- I could't configure bobs to be placed in "/var/www/html". I manually
> >moved the files from "/var/www/html/bobs" and edited the config.php
> >file.
> >
> >
> That's correct. Whatever directory you request, it adds /bobs to the end
> of the path. I figure that's safer to put it in a separate directory
> because I don't want to uninstall something that wasn't installed. If
> you run 'make uninstall-all' it will 'rm -rf' the entire bobs directory.
>
Wouldn't it be better to only remove the files we know we installed. And
the try to "rmdir dirname" for each dir we created. That will fail if
there are files in the dirs we didn't create. I think that is the sanest
way of doing this.
> >- I tried to check the remote server I just configured with systemcheck
> >in the admin interface. This gave me an error about systemcheck.php not
> >being found. I changed a line in admin.php to fix this:
> >header("Location: http://" . $_SERVER['HTTP_HOST'] . "/" . $bobsdir .
> >"systemcheck.php?server=$server&share=$share");
> >
> >
> >
> FIXME: (note to self)
> Were you connecting to bobs web interface from another machine? That
> would make sense because I've only tested it from the computer I have
> bobs installed on.
>
I usually run my servers without X and at times without any connections
expect power and network. The sometimes I develop on the local computer,
but not always.
> >
> >- The systemcheck gives the following errors:
> >
> >Attempting to mount for restore method type "nfs" using this command:
> >mount -t nfs "workshopserver:/workshop/project"
> >"/mnt/tera/bobsdata/current/process/mounts/workshopserver/project" FAIL
> >Mount failed with this message:
> >mount: mount point
> >/mnt/tera/bobsdata/current/process/mounts/workshopserver/project does
> >not exist
> >
> >I thought this was fixed already? Is there a patch somewhere that hasn't
> >been applied?
> >Anyway. I created the dirs and systemcheck performs as expected. :-)
> >
> >
> FIXME:
> I see it was only half fixed. It would have worked if nfs was also the
> backup method. I need to add the 'create directories if they don't
> exist" routine in the "restore method" check also.
>
Ok, that is good.
> >- And of course the db4 instead of db3 problem. I can't find a clever
> >way to detect this with php. The php function that does this only works
> >if you are using a quite new version of php. I still aim for php 4.0.6
> >as a compatibility target.
> >
> >
> This is also on my "todo" list. There must be an easy solution.
>
> >Cheers
> >-Rene
> >
> >
> Thanks for the valuable feedback. I'm going on vacation next week so
> I'll take a look at these bugs when I get back.
>
> Joe
>
Have a nice vacation :)
Cheers
Rene
|
|
From: Joe Z. <jz...@co...> - 2004-02-12 20:29:39
|
Rene Rask wrote:
>These are some notes on my install of bobs 0.6.1 on a new server.
>
>- I could't configure bobs to be placed in "/var/www/html". I manually
>moved the files from "/var/www/html/bobs" and edited the config.php
>file.
>
>
That's correct. Whatever directory you request, it adds /bobs to the end
of the path. I figure that's safer to put it in a separate directory
because I don't want to uninstall something that wasn't installed. If
you run 'make uninstall-all' it will 'rm -rf' the entire bobs directory.
>- I tried to check the remote server I just configured with systemcheck
>in the admin interface. This gave me an error about systemcheck.php not
>being found. I changed a line in admin.php to fix this:
>header("Location: http://" . $_SERVER['HTTP_HOST'] . "/" . $bobsdir .
>"systemcheck.php?server=$server&share=$share");
>
>
>
FIXME: (note to self)
Were you connecting to bobs web interface from another machine? That
would make sense because I've only tested it from the computer I have
bobs installed on.
>
>- The systemcheck gives the following errors:
>
>Attempting to mount for restore method type "nfs" using this command:
>mount -t nfs "workshopserver:/workshop/project"
>"/mnt/tera/bobsdata/current/process/mounts/workshopserver/project" FAIL
>Mount failed with this message:
>mount: mount point
>/mnt/tera/bobsdata/current/process/mounts/workshopserver/project does
>not exist
>
>I thought this was fixed already? Is there a patch somewhere that hasn't
>been applied?
>Anyway. I created the dirs and systemcheck performs as expected. :-)
>
>
FIXME:
I see it was only half fixed. It would have worked if nfs was also the
backup method. I need to add the 'create directories if they don't
exist" routine in the "restore method" check also.
>- And of course the db4 instead of db3 problem. I can't find a clever
>way to detect this with php. The php function that does this only works
>if you are using a quite new version of php. I still aim for php 4.0.6
>as a compatibility target.
>
>
This is also on my "todo" list. There must be an easy solution.
>Cheers
>-Rene
>
>
Thanks for the valuable feedback. I'm going on vacation next week so
I'll take a look at these bugs when I get back.
Joe
|
|
From: James W. B. <jbe...@mi...> - 2004-02-12 15:12:09
|
Roger. James Rene Rask wrote: >Yes, I know. The problem is modifying bobs to use that format instead. >That requires code changes since bobs is dependent on the format to work >properly. > >I'm not going to work on it anytime soon, but feel free to submit >patches that make this change. > >Cheers >Rene > > > > > >On Thu, 2004-02-12 at 14:40, James W. Beauchamp wrote: > > >>Rene: >>Thanks for the explanation. So could this be solved by simply modifying >>the extender on the file to be: >>somefile.ext.YYYYMMDDHHMMSS >> >>so just adding the hour, minute, second as part of the extension. This >>would then make the filename unique when its saved. >> >>James >> >> >>Rene Rask wrote: >> >> >> >>>On Mon, 2004-02-09 at 20:11, James W. Beauchamp wrote: >>> >>> >>> >>> >>>>Hi all: >>>>I have a question concerning how frequently BOBS can run a backup. Is >>>>there anything wrong with me moving the backup.php file from the >>>>crond.d/backup.daily to backup.hourly? I'm looking to get more frequent >>>>backups to some files other than just daily. >>>> >>>>Any thoughts on pitfalls this may cause? >>>> >>>> >>>> >>>> >>>/ >>>It shouldn't cause problems if your backups can be done in less than an >>>hour. If it takes longer then the command queue would just grow and >>>grow. >>>It may impact on the interactive performance of the bobs user interface. >>>This will not give you multiple backups of the same file on any given >>>day. It will be backed up several times a day (if modified that >>>frequently) and stored in "incremental" backups as eg. >>>"somefile.ext.2004035". >>>Bobs finest level of time awareness is one day. This is due to tagging >>>the files with and extension which is like this: >>>filename + "year" + "day of year" >>>which looks like: "filename.2004035" >>> >>>I hope this answers your question. >>> >>>Cheers >>>Rene >>> >>> >>> >>>------------------------------------------------------- >>>The SF.Net email is sponsored by EclipseCon 2004 >>>Premiere Conference on Open Tools Development and Integration >>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>>http://www.eclipsecon.org/osdn >>>_______________________________________________ >>>Bobs-devel mailing list >>>Bob...@li... >>>https://lists.sourceforge.net/lists/listinfo/bobs-devel >>> >>> >>> >>> >>> >>------------------------------------------------------- >>SF.Net is sponsored by: Speed Start Your Linux Apps Now. >>Build and deploy apps & Web services for Linux with >>a free DVD software kit from IBM. Click Now! >>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >>_______________________________________________ >>Bobs-devel mailing list >>Bob...@li... >>https://lists.sourceforge.net/lists/listinfo/bobs-devel >> >> > > > >------------------------------------------------------- >SF.Net is sponsored by: Speed Start Your Linux Apps Now. >Build and deploy apps & Web services for Linux with >a free DVD software kit from IBM. Click Now! >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene R. <re...@gr...> - 2004-02-12 15:07:08
|
Yes, I know. The problem is modifying bobs to use that format instead. That requires code changes since bobs is dependent on the format to work properly. I'm not going to work on it anytime soon, but feel free to submit patches that make this change. Cheers Rene On Thu, 2004-02-12 at 14:40, James W. Beauchamp wrote: > Rene: > Thanks for the explanation. So could this be solved by simply modifying > the extender on the file to be: > somefile.ext.YYYYMMDDHHMMSS > > so just adding the hour, minute, second as part of the extension. This > would then make the filename unique when its saved. > > James > > > Rene Rask wrote: > > >On Mon, 2004-02-09 at 20:11, James W. Beauchamp wrote: > > > > > >>Hi all: > >>I have a question concerning how frequently BOBS can run a backup. Is > >>there anything wrong with me moving the backup.php file from the > >>crond.d/backup.daily to backup.hourly? I'm looking to get more frequent > >>backups to some files other than just daily. > >> > >>Any thoughts on pitfalls this may cause? > >> > >> > >/ > >It shouldn't cause problems if your backups can be done in less than an > >hour. If it takes longer then the command queue would just grow and > >grow. > >It may impact on the interactive performance of the bobs user interface. > >This will not give you multiple backups of the same file on any given > >day. It will be backed up several times a day (if modified that > >frequently) and stored in "incremental" backups as eg. > >"somefile.ext.2004035". > >Bobs finest level of time awareness is one day. This is due to tagging > >the files with and extension which is like this: > >filename + "year" + "day of year" > >which looks like: "filename.2004035" > > > >I hope this answers your question. > > > >Cheers > >Rene > > > > > > > >------------------------------------------------------- > >The SF.Net email is sponsored by EclipseCon 2004 > >Premiere Conference on Open Tools Development and Integration > >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >http://www.eclipsecon.org/osdn > >_______________________________________________ > >Bobs-devel mailing list > >Bob...@li... > >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: James W. B. <jbe...@mi...> - 2004-02-12 13:39:07
|
Rene: Thanks for the explanation. So could this be solved by simply modifying the extender on the file to be: somefile.ext.YYYYMMDDHHMMSS so just adding the hour, minute, second as part of the extension. This would then make the filename unique when its saved. James Rene Rask wrote: >On Mon, 2004-02-09 at 20:11, James W. Beauchamp wrote: > > >>Hi all: >>I have a question concerning how frequently BOBS can run a backup. Is >>there anything wrong with me moving the backup.php file from the >>crond.d/backup.daily to backup.hourly? I'm looking to get more frequent >>backups to some files other than just daily. >> >>Any thoughts on pitfalls this may cause? >> >> >/ >It shouldn't cause problems if your backups can be done in less than an >hour. If it takes longer then the command queue would just grow and >grow. >It may impact on the interactive performance of the bobs user interface. >This will not give you multiple backups of the same file on any given >day. It will be backed up several times a day (if modified that >frequently) and stored in "incremental" backups as eg. >"somefile.ext.2004035". >Bobs finest level of time awareness is one day. This is due to tagging >the files with and extension which is like this: >filename + "year" + "day of year" >which looks like: "filename.2004035" > >I hope this answers your question. > >Cheers >Rene > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene R. <re...@gr...> - 2004-02-11 11:31:12
|
These are some notes on my install of bobs 0.6.1 on a new server.
- I could't configure bobs to be placed in "/var/www/html". I manually
moved the files from "/var/www/html/bobs" and edited the config.php
file.
- I tried to check the remote server I just configured with systemcheck
in the admin interface. This gave me an error about systemcheck.php not
being found. I changed a line in admin.php to fix this:
header("Location: http://" . $_SERVER['HTTP_HOST'] . "/" . $bobsdir .
"systemcheck.php?server=$server&share=$share");
- The systemcheck gives the following errors:
Attempting to mount for restore method type "nfs" using this command:
mount -t nfs "workshopserver:/workshop/project"
"/mnt/tera/bobsdata/current/process/mounts/workshopserver/project" FAIL
Mount failed with this message:
mount: mount point
/mnt/tera/bobsdata/current/process/mounts/workshopserver/project does
not exist
I thought this was fixed already? Is there a patch somewhere that hasn't
been applied?
Anyway. I created the dirs and systemcheck performs as expected. :-)
- And of course the db4 instead of db3 problem. I can't find a clever
way to detect this with php. The php function that does this only works
if you are using a quite new version of php. I still aim for php 4.0.6
as a compatibility target.
Cheers
-Rene
|
|
From: Rene R. <re...@gr...> - 2004-02-11 10:21:49
|
On Mon, 2004-02-09 at 20:11, James W. Beauchamp wrote: > Hi all: > I have a question concerning how frequently BOBS can run a backup. Is > there anything wrong with me moving the backup.php file from the > crond.d/backup.daily to backup.hourly? I'm looking to get more frequent > backups to some files other than just daily. > > Any thoughts on pitfalls this may cause? / It shouldn't cause problems if your backups can be done in less than an hour. If it takes longer then the command queue would just grow and grow. It may impact on the interactive performance of the bobs user interface. This will not give you multiple backups of the same file on any given day. It will be backed up several times a day (if modified that frequently) and stored in "incremental" backups as eg. "somefile.ext.2004035". Bobs finest level of time awareness is one day. This is due to tagging the files with and extension which is like this: filename + "year" + "day of year" which looks like: "filename.2004035" I hope this answers your question. Cheers Rene |
|
From: Rene R. <re...@gr...> - 2004-02-10 05:36:57
|
> Release 0.6.1 of bobs is now available at > http://sourceforge.net/projects/bobs/ > > Joe Zacky > Great! I was going to update the freshmeat.net entry but "The SourceForge.net Website is currently down for maintenance." again ..... Grrr... I get that so often that its getting on my nerves. Well.. I finally got a new server for running bobs and was planning on putting 0.6.1 with some version of rsync ssh (restore method) on it. Guess I'll wait a while. Cheers Rene |
|
From: James W. B. <jbe...@mi...> - 2004-02-10 03:30:37
|
Hi all: I have a question concerning how frequently BOBS can run a backup. Is there anything wrong with me moving the backup.php file from the crond.d/backup.daily to backup.hourly? I'm looking to get more frequent backups to some files other than just daily. Any thoughts on pitfalls this may cause? James |
|
From: Joe Z. <jz...@co...> - 2004-02-08 20:38:17
|
mar...@nt... wrote: >I have recently started playing with bobs. Great product, bringing togeather the idea of rsync backup with a nice interface. > >Anyway, I was thinking that you could have a seperate image hard linked to current cld restore. You could then boot using root over nfs off of the restore image on your server, be back up straight away and rebuild your system while you carried on using the it. > >All you need to do is have a seperate grub.conf line pointing to the network share and a compatible kernel. You should also have this on a boot cd incase you lose your boot partition. You also need a different fstab on the restore image with the network address of the restore image. Other than that though both images can be identicle using very little extra disk space, > >Problems? I can think of two network bandwidth may make the system unusable while restoring and you may not want to boot from the current image (although thats just a matter of moving the hard links). > >So what do people think. I have certainly net booted off of my backup image successfully, but before I get too involved. I wondered what others thought. Am I onto something here or am I missing the obvious. It wouldnt be the first time :). > >Mark > > Very interesting idea. Let's see if I understand. You'd have to setup bobs to backup the entire partition(s), at least the root (/) partition. You share the bobs "current" directory via nfs. You configure a grub option on the machine being backed up that points to the nfs shared "current" to boot from. I don't know how you'd do this in grub, root=?what?. I didn't know you could boot from an nfs share. How would that look in grub.conf? or I guess that's just something that goes into /etc/fstab. You'd have a separate /boot partition and another copy of the /boot partition and grub on CD? Quite an interesting backup strategy. It has the possibility to get you up and running very quickly. I'd love to see the /etc/fstab and grub.conf and any other pertinent configuration for a system you have set up this way so I can understand how to "net boot". Joe |
|
From: <mar...@nt...> - 2004-02-08 19:09:41
|
I have recently started playing with bobs. Great product, bringing togeather the idea of rsync backup with a nice interface. Anyway, I was thinking that you could have a seperate image hard linked to current cld restore. You could then boot using root over nfs off of the restore image on your server, be back up straight away and rebuild your system while you carried on using the it. All you need to do is have a seperate grub.conf line pointing to the network share and a compatible kernel. You should also have this on a boot cd incase you lose your boot partition. You also need a different fstab on the restore image with the network address of the restore image. Other than that though both images can be identicle using very little extra disk space, Problems? I can think of two network bandwidth may make the system unusable while restoring and you may not want to boot from the current image (although thats just a matter of moving the hard links). So what do people think. I have certainly net booted off of my backup image successfully, but before I get too involved. I wondered what others thought. Am I onto something here or am I missing the obvious. It wouldnt be the first time :). Mark |
|
From: Jochen M. <j.m...@om...> - 2004-02-08 18:20:44
|
That is cool Cheers Jochen Metzger Am So, 2004-02-08 um 02.05 schrieb Joe Zacky: > Release 0.6.1 of bobs is now available at > http://sourceforge.net/projects/bobs/ > > Joe Zacky > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel -- omatix.de internet services omatix solutions & trainings omatix onlineverlag Jochen Metzger j.m...@om... Telefon +49(30) 78709298 Fax +49(30) 78709296 |
|
From: Joe Z. <jz...@co...> - 2004-02-08 01:06:01
|
Release 0.6.1 of bobs is now available at http://sourceforge.net/projects/bobs/ Joe Zacky |
|
From: bishop <bi...@pl...> - 2004-02-05 05:28:08
|
Joe Zacky wrote: > bishop wrote: > >> http://cvs.sourceforge.net/viewcvs.py/bobs/bobs/bobs.spec?view=markup >> >> Joe, >> >> I've been looking over the SPEC file again, in cvs. The link's up >> there. I'm growing a bit less confident that it'll rebuild, however: >> >>> %defattr(-, %{HTTPDUSER}, root) >> >> The first thing that caught my eye is that bit of code about 10 lines >> from the bottom. On my stock RH9 box, %{HTTPDUSER} isn't defined. >> >>> Patch0: config.patch >>> Patch1: backup.patch >>> Patch2: check_loop.patch >> >> These files, referenced in the SPEC, are also missing. > > > Take a look at Makefile.am. It sets the HTTPDUSER variable and creates > the patches as part of the 'make rpm'. You can create the patches by > running './configure; make dist'. Whot? You're trying to set an RPM %variable from within a compilation process? I will have to see how this works out! > I admit I did some unconventional things because I had to 1) modify > /etc/crontab 2) determine the user httpd is running under so I could > chown the directories and 3) put things in various odd directories. > Much of it could have been done easier with an install script, but I > wanted to learn the 'make' process and tried to stick to it and use it's > defaults as much as possible. 1) you need to drop a file into /etc/cron.d/ . Modifying the /etc/crontab under modern linuxes is too risky compared to the easy alternative. 2) That's always a tricky one. I've found it's easiest to set the package name and binary owner per-distro. There are nifty tricks to help you do this, and really crafty macros can even deal with the stoopid renaming of the package from apache to httpd from rh8-9. It's not the best solution overall, but it's the only one guaranteed to work that I've ever seen. > The patches are there because 'make rpm' was putting the temporary rpm > "build" directory names in the variables. It's ugly but there it is. I'm > sure there's a cleaner way. Hmm. I'm hoping we can package as-is, with minor patches (in cvs but ignored in build/install) that set some sane preferences. I'll poke at it a bit tonight, if I get time,a nd see if I can come up with something usable, an idea I can maybe sell ya on. >> Finally, is there any way I can convince you and Rene to drop the use >> of 'pre' versioning? It's a real bit of hacking to work around in >> packaging, and, thanks to epoch: pain, the kind of gift that keeps on >> giving. > > What do you mean by 'pre' versioning? You mean putting 'pre' as part of > the package name? Is epoch software? You won't have a hard time > convincing me to drop it. Oh, nothing too special. It's like this: Version comparison for packaging is usually pretty smart: it knows that 1.1.2 is an upgrade to 1.1, and it knows that 1.4 is newer than 1.2. The problem is when a version is like 1.3.8pre2: the alpha sort (strcmp()) completely screws up the ordering, and thinks that 1.3.8pre2, 1.3.8b and similar names are actually NEWER than version 1.3.8. Now, we know it's not. We can use this 'epoch' value in RPMs to get around non-trivial naming like this: the epoch is like a master-number, one that's always more significant than release number or version number. It's just annoying to do because it has to be incremented by hand and can't be figured out by clever grovelling of the source tarball, that's all. versions like 1.3.99.4 are preferred over 1.4pre4, at least for version comparisons. But that's about it. Lemme go generate the patchfiles, see what they're doing, and see if I can't devise some hokey method that will let a guy rpm-ta or -ts a tarball, and make everything all add up like it should. No guarantees, but I could be lucky. - bish |
|
From: Joe Z. <jz...@co...> - 2004-02-05 04:16:14
|
bishop wrote: > http://cvs.sourceforge.net/viewcvs.py/bobs/bobs/bobs.spec?view=markup > > Joe, > > I've been looking over the SPEC file again, in cvs. The link's up > there. I'm growing a bit less confident that it'll rebuild, however: > >> %defattr(-, %{HTTPDUSER}, root) > > > The first thing that caught my eye is that bit of code about 10 lines > from the bottom. On my stock RH9 box, %{HTTPDUSER} isn't defined. > >> Patch0: config.patch >> Patch1: backup.patch >> Patch2: check_loop.patch > > > These files, referenced in the SPEC, are also missing. Take a look at Makefile.am. It sets the HTTPDUSER variable and creates the patches as part of the 'make rpm'. You can create the patches by running './configure; make dist'. I admit I did some unconventional things because I had to 1) modify /etc/crontab 2) determine the user httpd is running under so I could chown the directories and 3) put things in various odd directories. Much of it could have been done easier with an install script, but I wanted to learn the 'make' process and tried to stick to it and use it's defaults as much as possible. The patches are there because 'make rpm' was putting the temporary rpm "build" directory names in the variables. It's ugly but there it is. I'm sure there's a cleaner way. > > Finally, is there any way I can convince you and Rene to drop the use > of 'pre' versioning? It's a real bit of hacking to work around in > packaging, and, thanks to epoch: pain, the kind of gift that keeps on > giving. > > - bish What do you mean by 'pre' versioning? You mean putting 'pre' as part of the package name? Is epoch software? You won't have a hard time convincing me to drop it. Joe |
2 messages has been excluded from this view by a project administrator.
