Re: virtualbox
thanks for the tip on doing that. will try if i find vurtualbox failing me or i get tried of it's problems. On Sunday 16 November 2008 08:16:44 Roger Searle wrote: > Try an uninstall via "sudo vmware-uninstall.pl" first, then reinstall. > Worked fine for me on HH, both 32 and 64 bit. > > Cheers, > Roger > > Steve Holdoway wrote: > > On Sat, 15 Nov 2008 22:56:16 +1300 > > > > dave <[EMAIL PROTECTED]> wrote: > >> Got vm server 2.0 > >> > >> Version OS i'm running is 8.04.1 - Kubuntu > >> Kernel version i'm running is Linux 2.6.24-21-generic #1 SMP Tue Oct 21 > >> 23:43:45 UTC 2008 i686 GNU/Linux > > > > I'm using the same kernel (ubuntu), but 64 bit. > > > >> ran install script entered through questions (defaults taken) > >> got to point of running config.pl script. > >> meg popped up saying no Vmons available and the kernel was generated > >> with gcc-4.2.3 and i had 4.2.4 and some others checked apt-get nothing > >> for 4.2.3. > > > > I hate it when kernel and compiler version get out of step like this, but > > you can't blame vmware for that! However, using gcc 4.2.4 generates > > modules that work fine, so just override the defaults at that point. > > > >> from looking at Adapt i believe i have the header kernels for 2.6.24-21 > >> also > > > > yes, you need the kernel headers to recompile the vmware modules. > > > >> downloaded any-any patch for server 2.0 re ran scripts again bombed out > >> same message. > > > > You don't need that, just the latest ( 122956 ) version of vmware server. > > > >> found a script that did things for you so ran that it removed 2.0 and > >> installed 1.6XXX again up popped same msg about no vmons. > >> > >> I had downloaded the any-any patch as well!! > > > > hth, > > > > Steve
Re: virtualbox
On Sunday 16 November 2008 06:57:12 Steve Holdoway wrote: > On Sat, 15 Nov 2008 22:56:16 +1300 > > dave <[EMAIL PROTECTED]> wrote: > > Got vm server 2.0 > > > > Version OS i'm running is 8.04.1 - Kubuntu > > Kernel version i'm running is Linux 2.6.24-21-generic #1 SMP Tue Oct 21 > > 23:43:45 UTC 2008 i686 GNU/Linux > > I'm using the same kernel (ubuntu), but 64 bit. > > > ran install script entered through questions (defaults taken) > > got to point of running config.pl script. > > meg popped up saying no Vmons available and the kernel was generated with > > gcc-4.2.3 and i had 4.2.4 and some others checked apt-get nothing for > > 4.2.3. > > I hate it when kernel and compiler version get out of step like this, but > you can't blame vmware for that! However, using gcc 4.2.4 generates modules > that work fine, so just override the defaults at that point. > > > from looking at Adapt i believe i have the header kernels for 2.6.24-21 > > also > > yes, you need the kernel headers to recompile the vmware modules. > > > downloaded any-any patch for server 2.0 re ran scripts again bombed out > > same message. > > You don't need that, just the latest ( 122956 ) version of vmware server. this is what i've downloaded VMware-server-2.0.0-122956.i386.tar.gz might give this ago if i find too many more glitches with virtualbox because i've got WinXP & Kubuntu 8.10 loaded as virtual OSes now. thanks for the thoughts. dave > > > found a script that did things for you so ran that it removed 2.0 and > > installed 1.6XXX again up popped same msg about no vmons. > > > > I had downloaded the any-any patch as well!! > > hth, > > Steve
Re: Backup options
On Nov 17, 2008, at 12:02, Roy Britten wrote: Anyone care to comment on rdiff-backup's ease of use (backing up *and* recovery), robustness, and the like? I've used rdiff-backup extensively for years now and have found it extremely handy. Since it allows you to step back in time it is more robust than a simple rsync which might copy after some bad event happened on the source. (Before it existed the best we could do was a collection of linked rotating rsync'ed copies on the destination. rdiff-backup is much less hassle, and provides more compact storage in its reverse-diff scheme.) Restoring a single file/directory is trivial, since the destination looks like a copy of the current source. rdiff-backup can store file metadata in a separate file if the destination doesn't provide all the file system semantics that the source does, which opens up some cross-platform backup options. I also use rdiff-backup's encrypting cousin Duplicity to back up some virtual hosts to Amazon's S3. Handy if you don't completely trust the destination server and/or want to take advantage of the built in S3 support. -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/crew/jwt/ Mailman IRC irc://irc.freenode.net/#mailman
Re: Backup options
Hi, Thanks Roger for your vote (in bold) of support. Which reminds me: A paper backup is actually quite good. yes - just print out your addressbook in your email program and send the printout offsite. True, a bit tedious to copy into the next email program, but it has a certain KISS principle about it.. Derek. On Mon, 17 Nov 2008, Roger Searle wrote: I'd like to do one of those "+1" responses to the 2 points mentioned by Derek, however given it's importance, I'll do: +2. bold, larger font, upper case etc. I practice what is preached at work but can't claim the same at home - with regards to the frequency with which I test those backups. Plus, since that backup goes about a metre away, if my house burns down, I'm stuffed... And don't be like me and think it can't / won't happen to you - it's only because I woke up extra early one Sunday morning earlier in the year that my house didn't. Still, not enough to get me checking my ability to restore fully and keep copies off-site! Perhaps I'll read this when I get home and actually do something. Cheers, Roger Derek Smithies wrote: Hi, Backup is the thing that everyone says you have to do, but few do it right. The key part of doing backups is the sentence: There are two times to test the quality of your backup a)before disaster hits b)after disaster hits. To test your backup - you need to run this scenario and see what happens: 1)the machine you have regularly backed up has now disappeared completely. 2)you need to recover your data to a second machine 3)does the data recover correctly to a second machine, and can the second machine now be used instead of the first machine? The key thing - can you recover to a different machine? I know one person (not me) who at their business backed up every day. It was a novel 4 machine. Then things died, and they could only get a novel 5 machine. The backup would not recover to a novel 5 machine. So he had to completely install and setup a novel 4 machine, recover the backup, and proceed. As you can imagine - this was a longer than hoped for process. It did not make for many happy campers. Derek. On Mon, 17 Nov 2008, Roy Britten wrote: I'm setting up a backup regime (database dump and file structure) from a server in the states. rsync seems a sensible tool, and I have a little experience with it. I've just come across rdiff-backup. It sounds useful, but I'd like to hear some war stories from folks who have used it before I go wandering into unknown territory. Anyone care to comment on rdiff-backup's ease of use (backing up *and* recovery), robustness, and the like? Thanks, Roy. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] ph +64 3 365 6485 Web: http://www.indranet-technologies.com/
Re: Backup options
I'd like to do one of those "+1" responses to the 2 points mentioned by Derek, however given it's importance, I'll do: +2. bold, larger font, upper case etc. I practice what is preached at work but can't claim the same at home - with regards to the frequency with which I test those backups. Plus, since that backup goes about a metre away, if my house burns down, I'm stuffed... And don't be like me and think it can't / won't happen to you - it's only because I woke up extra early one Sunday morning earlier in the year that my house didn't. Still, not enough to get me checking my ability to restore fully and keep copies off-site! Perhaps I'll read this when I get home and actually do something. Cheers, Roger Derek Smithies wrote: Hi, Backup is the thing that everyone says you have to do, but few do it right. The key part of doing backups is the sentence: There are two times to test the quality of your backup a)before disaster hits b)after disaster hits. To test your backup - you need to run this scenario and see what happens: 1)the machine you have regularly backed up has now disappeared completely. 2)you need to recover your data to a second machine 3)does the data recover correctly to a second machine, and can the second machine now be used instead of the first machine? The key thing - can you recover to a different machine? I know one person (not me) who at their business backed up every day. It was a novel 4 machine. Then things died, and they could only get a novel 5 machine. The backup would not recover to a novel 5 machine. So he had to completely install and setup a novel 4 machine, recover the backup, and proceed. As you can imagine - this was a longer than hoped for process. It did not make for many happy campers. Derek. On Mon, 17 Nov 2008, Roy Britten wrote: I'm setting up a backup regime (database dump and file structure) from a server in the states. rsync seems a sensible tool, and I have a little experience with it. I've just come across rdiff-backup. It sounds useful, but I'd like to hear some war stories from folks who have used it before I go wandering into unknown territory. Anyone care to comment on rdiff-backup's ease of use (backing up *and* recovery), robustness, and the like? Thanks, Roy.
Re: Backup options
Hi, Backup is the thing that everyone says you have to do, but few do it right. The key part of doing backups is the sentence: There are two times to test the quality of your backup a)before disaster hits b)after disaster hits. To test your backup - you need to run this scenario and see what happens: 1)the machine you have regularly backed up has now disappeared completely. 2)you need to recover your data to a second machine 3)does the data recover correctly to a second machine, and can the second machine now be used instead of the first machine? The key thing - can you recover to a different machine? I know one person (not me) who at their business backed up every day. It was a novel 4 machine. Then things died, and they could only get a novel 5 machine. The backup would not recover to a novel 5 machine. So he had to completely install and setup a novel 4 machine, recover the backup, and proceed. As you can imagine - this was a longer than hoped for process. It did not make for many happy campers. Derek. On Mon, 17 Nov 2008, Roy Britten wrote: I'm setting up a backup regime (database dump and file structure) from a server in the states. rsync seems a sensible tool, and I have a little experience with it. I've just come across rdiff-backup. It sounds useful, but I'd like to hear some war stories from folks who have used it before I go wandering into unknown territory. Anyone care to comment on rdiff-backup's ease of use (backing up *and* recovery), robustness, and the like? Thanks, Roy. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] ph +64 3 365 6485 Web: http://www.indranet-technologies.com/
Re: Backup options
On Mon, 17 Nov 2008 12:02:32 +1300 Roy Britten <[EMAIL PROTECTED]> wrote: > I'm setting up a backup regime (database dump and file structure) from > a server in the states. rsync seems a sensible tool, and I have a > little experience with it. I've just come across rdiff-backup. It > sounds useful, but I'd like to hear some war stories from folks who > have used it before I go wandering into unknown territory. > > Anyone care to comment on rdiff-backup's ease of use (backing up *and* > recovery), robustness, and the like? > > Thanks, > Roy. I just set up an automagic off-site backup for an os-commerce site I did the back end work for, and used the simplest approach I could think of. It's a 2 stage backup: first to a dedicated directory ( I use /backup, and *EXCLUDE* this from the archive generation ), and then offsite. I do this because the primary use for a backup is *NOT* disaster recovery, but to restore a file accidentally deleted by manual intervention. ( I also use tar in verbose mode, and save the output to a separate file that can be used to search for said file before lumbering through the archive ). The core to getting it offsite is... -- 8< -- cd $ArchiveDir $Echo "Database Backup" | $Nail -r [EMAIL PROTECTED] -s "client database backup for $DateStamp" -a databases.$DateStamp.sql.zip $MailRecipient # Sunday = day 0 if [ ! "$DayOfWeek" ] then $Split -a 1 -b 15m $Website.$DateStamp.zip $Website.$DateStamp.zip. for Chunk in $Website.$DateStamp.zip.? do $Echo "Weekly Website Backup part $Chunk" | $Nail -r [EMAIL PROTECTED] -s "client website backup for week commencing $DateStamp Part $Chunk" -a $Chunk $M ailRecipient done fi -- 8< -- Requires a cli based mail client that can support attachments - I've used nail. You also need to chunk the file up into sub-20MB chunks for gmail. Every $ above is a link to the full path of ( and I even used zip to keep the client happy! ). As you can tell, a) the server's in the states and there's no bandwidth costs; and b) I'm a firm believer in KISS. There's very little that can go wrong with this, and even if it does, no existing data is corrupted. The only other simple option for database backups is to replicate: usually very little overhead ( commands are just run twice ). MySQL 5.x and PostgreSQL/slony are pretty good solutions. hth, Steve -- Steve Holdoway <[EMAIL PROTECTED]>
Backup options
I'm setting up a backup regime (database dump and file structure) from a server in the states. rsync seems a sensible tool, and I have a little experience with it. I've just come across rdiff-backup. It sounds useful, but I'd like to hear some war stories from folks who have used it before I go wandering into unknown territory. Anyone care to comment on rdiff-backup's ease of use (backing up *and* recovery), robustness, and the like? Thanks, Roy.
Re: Newest Penguinista
2008/11/15 yuri <[EMAIL PROTECTED]>: > On 2008-11-15 at 14:53 the newest Penguinista arrived: > > Marijke Aroha Anne de Groot > 3.47kg (don't ask about lbs and Ozes - ~$ man units) > > Mother and baby are both happy. > I reckon she'll probably chose kwrite over both vi and emacs. > She definitely looks like a kde user. She'll get over it. Congratulations to all involved! Good health to Marijke and reasonable quantities of sleep for you. Roy.
Re: wiki error uploading files
On Mon, Nov 17, 2008 at 7:07 AM, Roger Searle <[EMAIL PROTECTED]> wrote: > Is it broken? or disabled? or am I bringing up the whole "future of the > clug wiki" discussion? Currently semi-broken, as the server does not have permission to write to the upload directory. I don't intend to change this in the short-term, as I'm in the middle of sorting out the "future of the wiki" and it doesn't involve it staying on the current server :-) Send me the file directly (i.e. don't just reply to the list) and I'll put it there manually. -jim
wiki error uploading files
Hi, I'm trying to figure out how to upload files to the wiki - slides from last week's presentation. It's an OpenOffice odp file and I get: Only files with the extension 7z, avi, bmp, bz2, c, cfg, diff, doc, gif, h, ini, jpeg, jpg, kmz, mp3, patch, pdf, png, ppt, rar, tar, tar.gz, txt, xls, zip are allowed. OK then... Attempts to upload a ppt version results in ERROR uploading 'vmware_server2.ppt': Uploading failed. Is it broken? or disabled? or am I bringing up the whole "future of the clug wiki" discussion? Cheers, Roger
