Re: Win32 client (was: Re: Amanda GUI)
[...]
But in the testing so far, we're finding some odd results:
* The actual program that the Win32 client uses to do the backups
appears to be an NT port of tar. But trying to restore a file
made from that backup on a FreeBSD system generates a message saying
that the file does not look like a tar archive.
Sure... It's a Win32 tar archive...
A tar archive includes: data of the file and data related to the file: name, rights...
And rights are completely different between *nix and Windows...
Take your tar on a Windows box and untar it: it will be successful.
Also, ls showed each directory twice -- once as a directory; once as
a regular file.
Which ls? In amrecover?
* Trying to use the amrestore on the Win32 side, the ls command
doesn't seem to work.
amrestore or amrecover? amrestore just dd's out the tape and, if you want, make a grep
on the output. There's no ls...
At some point, I would like my employer to contribute some resources
toward making this version of the amanda client solid enough to install
from the directions and run. This may include paying someone to
implement selfcheck, for example, as well as other parts of the Win32
client that need attention. Speaking only for myself, I would be less
interested in a GUI for any of this, but that's just me.
When I tested the Win32 client, I needed a selfcheck. This was for production systems,
not workstations (so you may find my solution not useful). My selfcheck was something
like:
int main() {
return 0;
}
---
Jean-Christian SIMONETTIemail: [EMAIL PROTECTED]
SysAdmin Wanadoo Portails phone: (+33)493004911
Sophia Antipolis, France
---
Re: Win32 client (was: Re: Amanda GUI)
On Wed, Nov 05, 2003 at 10:26:37AM +0100, JC Simonetti wrote:
[...]
But in the testing so far, we're finding some odd results:
* The actual program that the Win32 client uses to do the backups
appears to be an NT port of tar. But trying to restore a file
made from that backup on a FreeBSD system generates a message saying
that the file does not look like a tar archive.
Sure... It's a Win32 tar archive...
I wasn't aware that the Win32 environment was sufficiently special
that tar archives were unportable between that and normal (UNIX)
environments.
A tar archive includes: data of the file and data related to the file: name,
rights... And rights are completely different between *nix and Windows...
OK; I'll take your word for it.
Take your tar on a Windows box and untar it: it will be successful.
Well, I suppose it might be, if it were small enough to fit in the
available space on the Windows box, and if someone who had a clue about
the Windows environment (i.e., not me) did it. But it's a (Win32) tar
archive for the entire C: drive.
Also, ls showed each directory twice -- once as a directory; once as
a regular file.
Which ls? In amrecover?
Yes.
* Trying to use the amrestore on the Win32 side, the ls command
doesn't seem to work.
amrestore or amrecover? amrestore just dd's out the tape and, if you want, make a
grep on the output. There's no ls...
Right; sorry: I screwed up. I meant amrecover.
At some point, I would like my employer to contribute some resources
toward making this version of the amanda client solid enough to install
from the directions and run. This may include paying someone to
implement selfcheck, for example, as well as other parts of the Win32
client that need attention. Speaking only for myself, I would be less
interested in a GUI for any of this, but that's just me.
When I tested the Win32 client, I needed a selfcheck. This was for production
systems, not workstations (so you may find my solution not useful). My selfcheck was
something like:
int main() {
return 0;
}
That's fine (and resembles /usr/src/usr.bin/true/true.c, without
the BSD copyright that the version I use has), but I have no Win32
development environment. At the rate things are going, we're looking
for some help in doing some work in such an environment so we can
create executables that will actually work; I have no reason to
believe that a physical presence here (in Fremont, California) is
especially necessary.
Thanks,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Re: Win32 client (was: Re: Amanda GUI)
On Wed, 5 Nov 2003 04:52:33 -0800
David Wolfskill [EMAIL PROTECTED] wrote:
On Wed, Nov 05, 2003 at 10:26:37AM +0100, JC Simonetti wrote:
[...]
But in the testing so far, we're finding some odd results:
* The actual program that the Win32 client uses to do the backups
appears to be an NT port of tar. But trying to restore a file
made from that backup on a FreeBSD system generates a message saying
that the file does not look like a tar archive.
Sure... It's a Win32 tar archive...
I wasn't aware that the Win32 environment was sufficiently special
that tar archives were unportable between that and normal (UNIX)
environments.
It's the reason of the existence of the WinTar software :)
A tar archive includes: data of the file and data related to the file: name,
rights... And rights are completely different between *nix and Windows...
OK; I'll take your word for it.
Take your tar on a Windows box and untar it: it will be successful.
Well, I suppose it might be, if it were small enough to fit in the
available space on the Windows box, and if someone who had a clue about
the Windows environment (i.e., not me) did it. But it's a (Win32) tar
archive for the entire C: drive.
Whoops... Try a smaller tar to make your tests...
Also, ls showed each directory twice -- once as a directory; once as
a regular file.
Which ls? In amrecover?
Yes.
* Trying to use the amrestore on the Win32 side, the ls command
doesn't seem to work.
amrestore or amrecover? amrestore just dd's out the tape and, if you want, make a
grep on the output. There's no ls...
Right; sorry: I screwed up. I meant amrecover.
I did not use amrecover for my restorations, but just amrestore. Why? Because in my
backup architecture, I d not want to restore to data directly on the client but I
restore them on the backup server then push them on the client.
And as WinTar and GnuTar are different, I was just able to extract the dd image from
the tape with amrestore and push these data on the Win32 server, and over there untar
them.
But I was backing up small data, something les than 5 Gb, so I was able to have on my
Windows box the tar and the untar data simultaneously, right :)
At some point, I would like my employer to contribute some resources
toward making this version of the amanda client solid enough to install
from the directions and run. This may include paying someone to
implement selfcheck, for example, as well as other parts of the Win32
client that need attention. Speaking only for myself, I would be less
interested in a GUI for any of this, but that's just me.
When I tested the Win32 client, I needed a selfcheck. This was for production
systems, not workstations (so you may find my solution not useful). My selfcheck
was something like:
int main() {
return 0;
}
That's fine (and resembles /usr/src/usr.bin/true/true.c, without
the BSD copyright that the version I use has), but I have no Win32
development environment. At the rate things are going, we're looking
for some help in doing some work in such an environment so we can
create executables that will actually work; I have no reason to
believe that a physical presence here (in Fremont, California) is
especially necessary.
Concerning development on Win32 architectures, you have Dev-C++
(http://sourceforge.net/projects/dev-cpp/) : a free software IDE compiler under
Windows.
Personally I don't like the Win32 client since it is based on a CVS snapshot of Amanda
from august 2001 : so old isn't it?!
Maybe a future development of this client should only be libraries to interface the
*nix version of Amanda under Win32, maybe real libraries or patches to apply on the
sources, but something that would be generic and not applied on a particular version
and just on this version.
The 2 other solutions are :
1. Samba backup using smbclient on the Linux Amanda server: simple but you do not
backup NT file rights (well... see some messages above in the mailing-list, someone
sent a little script to backup the rights)
2. Cygwin and the Amanda source code: very functional but you have to install a Linux
emulator on your Windows box... I don't like the idea (what would you say if I told
you that you have to install a Windows emulator on your BSD to backup your BSD?)
Re: Win32 client (was: Re: Amanda GUI)
On Wed, Nov 05, 2003 at 02:36:46PM +0100, JC Simonetti wrote: The 2 other solutions are : ... 2. Cygwin and the Amanda source code: very functional but you have to install a Linux emulator on your Windows box... I don't like the idea (what would you say if I told you that you have to install a Windows emulator on your BSD to backup your BSD?) In addition to cygwin, which has a large overhead, the same project has another package called, I think, mingw. Unlike cygwin, which requires a cygwin dll to be on the system, and is GPL'ed, mingw compiles are standalone and can be used to generate non-GPL'ed executables (I think I'm correct there, net lawyers will complain if I'm not :) I've not, but I wonder if anyone has tried to get a set of amanda client executables built under mingw and using the previously mentioned tarNT? BTW, the mingw package would be another way to build the selfcheck/true executable without a full IDE. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Win32 client (was: Re: Amanda GUI)
On Wed, Nov 05, 2003 at 02:36:46PM +0100, JC Simonetti wrote: On Wed, 5 Nov 2003 04:52:33 -0800 David Wolfskill [EMAIL PROTECTED] wrote: I wasn't aware that the Win32 environment was sufficiently special that tar archives were unportable between that and normal (UNIX) environments. It's the reason of the existence of the WinTar software :) Oh. I had (perhaps naively) thought that it was merely a win32/NT/...? port of a more standard tar Well, I suppose it might be, if it were small enough to fit in the available space on the Windows box, and if someone who had a clue about the Windows environment (i.e., not me) did it. But it's a (Win32) tar archive for the entire C: drive. Whoops... Try a smaller tar to make your tests... Well, I suppose any sub-tree would be somewhat smaller, but I have no idea how Microsoft spells du. I did not use amrecover for my restorations, but just amrestore. Why? Because in my backup architecture, I d not want to restore to data directly on the client but I restore them on the backup server then push them on the client. And as WinTar and GnuTar are different, I was just able to extract the dd image from the tape with amrestore and push these data on the Win32 server, and over there untar them. But I was backing up small data, something les than 5 Gb, so I was able to have on my Windows box the tar and the untar data simultaneously, right :) Ah. Well, nearly anything that is done around here involving a Microsoft platform will need to be done by someone other than me: they seem to be remarkably unreliable around me. (They probably know what I think of them) Concerning development on Win32 architectures, you have Dev-C++ (http://sourceforge.net/projects/dev-cpp/) : a free software IDE compiler under Windows. Well, for whoever does the development, that might be useful; thanks. Personally I don't like the Win32 client since it is based on a CVS snapshot of Amanda from august 2001 : so old isn't it?! Understood. I believe that my employer would be willing to pay someone to re-do that work, with a more recent version of the source. Maybe a future development of this client should only be libraries to interface the *nix version of Amanda under Win32, maybe real libraries or patches to apply on the sources, but something that would be generic and not applied on a particular version and just on this version. Maybe in the longer term; for now, we just want something that actually works. The 2 other solutions are : 1. Samba backup using smbclient on the Linux Amanda server: simple but you do not backup NT file rights (well... see some messages above in the mailing-list, someone sent a little script to backup the rights) Yes, I know of this. However, in our environment, it is not an acceptable approach. 2. Cygwin and the Amanda source code: very functional but you have to install a Linux emulator on your Windows box... I don't like the idea (what would you say if I told you that you have to install a Windows emulator on your BSD to backup your BSD?) Right; I expect that Cygwin will be involved, but only for development. We are trying to minimize the impact on clients' machines. Thanks again, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Win32 client (was: Re: Amanda GUI)
[...] In addition to cygwin, which has a large overhead, the same project has another package called, I think, mingw. Unlike cygwin, which requires a cygwin dll to be on the system, and is GPL'ed, mingw compiles are standalone and can be used to generate non-GPL'ed executables (I think I'm correct there, net lawyers will complain if I'm not :) I've not, but I wonder if anyone has tried to get a set of amanda client executables built under mingw and using the previously mentioned tarNT? BTW, the mingw package would be another way to build the selfcheck/true executable without a full IDE. Amanda Win32 Sourceforge project IS based on a mingw solution.
Re: Win32 client (was: Re: Amanda GUI)
On Wed, Nov 05, 2003 at 05:58:14PM +0100, JC Simonetti wrote: [...] In addition to cygwin, which has a large overhead, the same project has another package called, I think, mingw. Unlike cygwin, which requires a cygwin dll to be on the system, and is GPL'ed, mingw compiles are standalone and can be used to generate non-GPL'ed executables (I think I'm correct there, net lawyers will complain if I'm not :) I've not, but I wonder if anyone has tried to get a set of amanda client executables built under mingw and using the previously mentioned tarNT? BTW, the mingw package would be another way to build the selfcheck/true executable without a full IDE. Amanda Win32 Sourceforge project IS based on a mingw solution. Ahh, nevermind :) -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Win32 client (was: Re: Amanda GUI)
If not, it is possible that my employer would be willing to pay someone to bring it sufficiently up-to-date that it actually works. (Since the backup image is created OK, we are expecting that this ought not be a huge amount of work for someone with a reasonable ability willingness to develop in/for the win32 environment.) It would be Nice(tm) if, aas an additional result, it would be possible to do an amrecover from the UNIX side against a backup created in the win32 side and have a reasonable expectation that some arbitrary set of the files could be restored. It's actually rather much a pain, although this is someone who's primarily a unix geek talking who only has marginal experience in the MS world. (and most of it under win 3.1). This is assuming you don't want to break the unix-philosophy driving much of amanda's design. I've actually gotten everything to build in client-src natively under Windows (using visual studio .NET and a few hacked up Makefiles, no configure), but not actually working. I think all that's really left is getting the event driver working and figuring out how to interact with some backup program, although each time I get someting working, I've found something else that needs attention. Unfortunately, things like select() don't work the same way under Windows as they do under Unix (you can't select on a file descriptor, only sockets, for example). For the software required to backup, it would be nice if amanda stored things in the microsoft tape format used by the backup program that ships with the NT Track, that is: http://www.layton-graphics.com/mtf/MTF_100a.PDF I don't think backup can dump to stdout. However, in theory this would allow for bare-metal restores if you have the dump image. I haven't really considered amrecover yet, figuring that in a pinch someone could use microsoft's backup utility over samba to a big disk on the unix side if something was generating dump imaages in MTF. Also, for people just wanting to get at files in the backups without having to touch NT: http://www.layton-graphics.com/mtf/ would mitigate that (I think; I've never tried it). Certainly WinTar (or whatever) would be another reasoable alternative. all of my work was against the 2.5.0 track. (top of the cvs repository) which has significantly different innards for the clients, but should theoretically be compatible with 2.4 servers. (never tried). I was avoiding all the glue packages lke cygwin or mingw for at least the client portion to try to simplify the world for would-be users. I've touched this maybe a few hours recently (it still builds) but not with any significance since last March or so. One of these days, I'll get back to it. -Todd
Re: Win32 client (was: Re: Amanda GUI)
On Tue, Nov 04, 2003 at 09:35:24AM -0800, David Wolfskill wrote: [Re: win32 amanda client from sourceforge) But in the testing so far, we're finding some odd results: * Trying to use the amrestore on the Win32 side, the ls command doesn't seem to work. At some point, I would like my employer to contribute some resources toward making this version of the amanda client solid enough to install from the directions and run. This may include paying someone to implement selfcheck, for example, as well as other parts of the Win32 client that need attention. Speaking only for myself, I would be less interested in a GUI for any of this, but that's just me. Has anyone got amrecover for a file backed up via the win32 client to actually work? If so, how? If not, it is possible that my employer would be willing to pay someone to bring it sufficiently up-to-date that it actually works. (Since the backup image is created OK, we are expecting that this ought not be a huge amount of work for someone with a reasonable ability willingness to develop in/for the win32 environment.) It would be Nice(tm) if, aas an additional result, it would be possible to do an amrecover from the UNIX side against a backup created in the win32 side and have a reasonable expectation that some arbitrary set of the files could be restored. [I note that I was given a pointer to star, which may well help with the latter task, but does nothing, as far as I know, for restoring files in the win32 environment.] Thanks, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Win32 Backup?
Anthony A. D. Talltree wrote: I've never had to do this, but an approach that I'd probably persue would be to use Symmantec/Norton Ghost to create occasional disk images that would get xferred via Samba to a *ix filesystem. I'd try real hard to keep important data off of the M$ machine's local disks. One way I have done it is to use MS's backup program to backup to a samba share on a freebsd box. MS backup will happily backup to a samba share. Then I just backup all that stuff using amanda. I've used MS backup on XP Pro and w2kpro this way and it works pretty well for my needs. -- Michael Perry | Do or do not. There is no try. -Master Yoda [EMAIL PROTECTED] | http://www.lnxpowered.org
Re: Win32 Backup?
I've had weird stuff happen to me when writing across samba mounts -- the files would quietly disappear under the Nethood pseudo-directory, eating up disk space while being inaccessible. Associating the mounts with drive letters seems to avoid this.
Re: Win32 Backup?
One way I have done it is to use MS's backup program to backup to a samba share on a freebsd box. MS backup will happily backup to a samba share. Then I just backup all that stuff using amanda. beware of backing up via NT Backup to a samba share, always verify the contents of the file. I ran into a problem wher it appeared to be backing up just fine, and created a huge BKF file, but it was full of zeros and unusable... Steve
Re: Win32 Backup?
Steve Loughran [EMAIL PROTECTED] wrote: One way I have done it is to use MS's backup program to backup to a samba share on a freebsd box. MS backup will happily backup to a samba share. Then I just backup all that stuff using amanda. beware of backing up via NT Backup to a samba share, always verify the contents of the file. I ran into a problem wher it appeared to be backing up just fine, and created a huge BKF file, but it was full of zeros and unusable... I've been using ntbackup to files on samba share for a number of weeks now, haven't seen any problems. I do have the verify flag on. Perhaps it's the samba version or config, or maybe networking issues? Just a thought. I did have to alter my original schedule/dump type in ntbackup. I was getting tape overruns due to that fact that amanda has no control of the w2k boxes schedule/dump type. It would be very cool if some smart win programmer could write wrappers for ntbackup.exe so that amanda could control it directly. Also, I copy over the ntbackup log files at the end of the script. Seems it can only have 10 log files at a time. Ntbackup in w2k is pretty useful. Although Veritas did write it for them. -- toby bluhm philips medical systems, it support, mr development, cleveland ohio [EMAIL PROTECTED] 440-483-5323
Re: Win32 Backup?
I've used Amanda before in a Unix-only shop, but now am interested in backing up Win32 clients. I see Amanda.Org still seems to hold the official line of use smbclient to backup Win32 clients, but there's a port of Amanda client to Win32 at http://sourceforge.net/projects/amanda-win32 which appears to have about 5-15 downloads daily for the last week or two. I can't tell you much, but I can tell that the official 2.4.4 version supports the cygwin environment. There have been a number of messages on this recently -- search the archives. Okay, I searched the archives. There is some conjecture that the Win32 client is not too recent, but there doesn't seem to be anything concrete. Someone else said the 'sbmclient' method gives problems when the user setup to do the backups on the Win32 client don't have permissions to back up the machine. Cygwin method requires first installing Cygwin on every client, right? smbclient method requires only creating a user on every client. So unless every Win32 client has Cygwin installed... would it be safe to say that The One Right Way to do Win32 backups is: - Setup a local administrator on the client (say, amanda) - Use smbclient at the server to backup - Don't use the Win32 client at SourceForge (it's out-of-date) ? -- pv
Re: Win32 Backup?
I've never had to do this, but an approach that I'd probably persue would be to use Symmantec/Norton Ghost to create occasional disk images that would get xferred via Samba to a *ix filesystem. I'd try real hard to keep important data off of the M$ machine's local disks.
Re: Win32 Backup?
On 4 Mar 2003 at 10:54am, philo vivero wrote I've used Amanda before in a Unix-only shop, but now am interested in backing up Win32 clients. I see Amanda.Org still seems to hold the official line of use smbclient to backup Win32 clients, but there's a port of Amanda client to Win32 at http://sourceforge.net/projects/amanda-win32 which appears to have about 5-15 downloads daily for the last week or two. What can you tell me about the Win32 port of Amanda client software? Is it appropriate for backing up a heterogenous Win'95, Win'98, Win'XP, Win'2K network? What are the 'gotchas'? I can't tell you much, but I can tell that the official 2.4.4 version supports the cygwin environment. There have been a number of messages on this recently -- search the archives. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: win32
On Thu 19 Sep 02 16:32, Christophe Kalt wrote: Also, it seems that it would be much less work to actually port the existing (UNIX) amanda source (at least or at most?;) the client parts. Having a separate project really doesn't seem right. Erm... ever tried to port code from Unix to Windows? Ever wonder why there is so little Opensource Windows code? ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: win32
Brian, Tried that, but there is alot of UNIXism in amanda. I did go the cygwin route a couple of years ago. It kind of worked. I am currently rewriting the whole client side in perl. To get it to work you just have to download ActiveState perl and my script, that's it. I am also looking at using this perl code to backup UNIX/Linux plus any other type of systems (ie. OSX) that supports perl. Should have some code for people to look at early next week. Jim On Thu 19 Sep 02 16:32, Christophe Kalt wrote: Also, it seems that it would be much less work to actually port the existing (UNIX) amanda source (at least or at most?;) the client parts. Having a separate project really doesn't seem right. Erm... ever tried to port code from Unix to Windows? Ever wonder why there is so little Opensource Windows code? ..Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
Re: win32
On Sep 19, Brian Jonnes wrote: | On Thu 19 Sep 02 16:32, Christophe Kalt wrote: | Also, it seems that it would be much less work to actually | port the existing (UNIX) amanda source (at least or at most?;) | the client parts. Having a separate project really doesn't | seem right. | | Erm... ever tried to port code from Unix to Windows? yes, i've done it a few times, and have maintained programs that could be compiled natively on either platform. Depending on what the application is/does and how it was written, it isn't hard at all. this doesn't say anything about how feasible this would be for amanda, i haven't looked at the code this closely.
Re: win32
I tried for days to get it to work, NO luck. I decided to rewrite the amandad in perl (doesn't need any external programs other than Perl and a few modules). I currently have a VERY alpha version of this working here. I should be ready to release 0.02 next week. Is anyone interested? Jim On Wed, 11 Sep 2002, Galen Johnson wrote: Hello gang, A while back I had sent a request regarding backing up windows machines without having to deal with samba. Someone had responded with the win32 Amanda client on sourceforge. I have looked it up and it seems like it'll do what I want. However, it hasn't been touched in 18 months. Is anyone currently using this with Amanda 2.4.3.b4? I downloaded this package but have been unable to get it to work - anyone using it successfully? *** Qmail-Scanner Envelope Details Begin *** X-Qmail-Scanner-Mail-From: [EMAIL PROTECTED] via maat.reeusda.gov X-Qmail-Scanner-Rcpt-To: [EMAIL PROTECTED] X-Qmail-Scanner: 1.12 (hbedv: 2.0.3/vdf=6.14.0.3 Clear:. Processed in 0.266484 secs) *** Qmail-Scanner Envelope Details End ***
Re: win32
If it handles exclusions, hell yes. My users are a lot of analysis engineers and I need to be able to exclude some HUGE interim files made during analasys processing. Jim Buttafuoco wrote: [EMAIL PROTECTED]"> I tried for days to get it to work, NO luck. I decided to rewrite the amandad in perl (doesn't need any external programs other than Perl and a few modules). I currently have a VERY alpha version of this working here. I should be ready to release 0.02 next week. Is anyone interested?Jim On Wed, 11 Sep 2002, Galen Johnson wrote: Hello gang,A while back I had sent a request regarding backing up windows machines without having to deal with samba. Someone had responded with the win32 Amanda client on sourceforge. I have looked it up and it seems like it'll do what I want. However, it hasn't been touched in 18 months. Is anyone currently using this with Amanda 2.4.3.b4? I downloaded this package but have been unable to get it to work - anyone using it successfully?*** Qmail-Scanner Envelope Details Begin ***X-Qmail-Scanner-Mail-From: "[EMAIL PROTECTED]" via maat.reeusda.govX-Qmail-Scanner-Rcpt-To: "[EMAIL PROTECTED]"X-Qmail-Scanner: 1.12 (hbedv: 2.0.3/vdf=6.14.0.3 Clear:. Processed in 0.266484 secs)*** Qmail-Scanner Envelope Details End ***
Re: win32
On Sep 18, JC Simonetti wrote: | If someone is interested in going through the development | of this client, we might start the development again... But | I cannot do it alone, I do not have enough time. What i don't understand is why noone's actually looked at writing a native port of amandad or why NTTAR is used rather than ntbackup or some other native tool. (I don't believe NTTAR will work for everything, for instance MS Exchange..) IMO, the samba hack is a nasty kludge, and totally inappropriate for a lot of things as it doesn't handle extended attributes (such as ACLs). The amanda-win32 looked promising, but nothing's been happening with it for a long time as people have mentioned. And it is based on the PW32 SF project which is in the same state of abandonment as amanda-win32, so you're actually looking at 2 projects to maintain, not just one. Also, it seems that it would be much less work to actually port the existing (UNIX) amanda source (at least or at most?;) the client parts. Having a separate project really doesn't seem right.
Re: win32
On Tue, 17 Sep 2002 15:58:26 -0400
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
--- In [EMAIL PROTECTED], JC Simonetti [EMAIL PROTECTED] wrote:
snip
Well... You're right, I got the actual state of the Sourceforge
project and did not touch to anything to the sources. Everything goes
well.
For your bugs :
1. selfcheck bug is not a bug, it's just that selfcheck is not
provided in the Win32 version. If you are suck with the amcheck
errors, do the same thing as me : selfcheck.c : int main() {return
0;}, and if you are lazy compiling such a thing, I've attached it
here.
2. sendsize crash ? Well... Er... Er... Er... Where ??? I've had
some problems with sendsize, but it corrected itself with the
-udp=10080 -no-exit parameters to the amandad.exe program. I did not
examine precisely the source code but the -no-exit seems to be very
important...
What I've done with this project? Well... Just got it from
Sourceforge and installed it on W2K boxes: what I've done is installed
it as a WinNT service. I am running it with an Amanda 2.4.3b2 server
on a Linux box, and no errors reported yet (1,5 Go backed up every
night). Not checked with omre recent versions.
--
Jean-Christian SIMONETTI email: [EMAIL PROTECTED]
SysAdmin Wanadoo Portails phone: (+33)493004911
Sophia Antipolis, France
--
Are you SURE there are no errors? I tested this yesterday. It
appears that sendbackup only logs the errors tothe debug file in
/tmp/amanda. Also, each sendbackup process overwrites this file.
It also appears that this doesn`t support excludes. Amandad reports
the standard exclude list path, but I couldn,t get it to work.
You previously mentioned that amanda maps the archive bit to the UNIX
execute bit. It is actually the win32 tar that does this. I believe
Samba also doed this to help preserve the Windows permissions.
This appears to be early alpha quality software, not ready for
production. Unfortunately, it also appears to be abandoned :-(
Bruce Osborne
I am sure there are no errors. I am currently backing up 6 servers for a total amount
of 2 Go, everything goes perfectly well.
Concerning the exludes, it is written that this feature does not work from now on.
Concerning the NT rights, Samba does NOT preserve them. Samba backs up the bits from
the files, and if their names are in US-ASCII (whoops, I'm french, don't forget the
accentuated characters) the names are also backed up (I've got problems with special
characters translation and no recover possible for some files, due to their names that
had been changed.
And as for the general quality, I think you're right when you speak about alpha
quality. But when I see the smbtar feature, I prefer an alpha quality that works (I
managed to make it work in my environment) rather than a solution that tells me
everyday ? ERRDOS - ERRbadshare opening remote file \EF\EFinfo2.SDC (\EF\) and that
I am not sure to be able to recover the data I am backing up...
The actual version of Win32 Amanda is yet in development version (not even in unstable
mode, to speak Debian-like). But I prefer this solution, as I managed to make it work,
rather than the smbtar I couldn't make it work correctly.
If someone is interested in going through the development of this client, we might
start the development again... But I cannot do it alone, I do not have enough time.
Re: win32
--- In [EMAIL PROTECTED], JC Simonetti [EMAIL PROTECTED] wrote:
snip
Well... You're right, I got the actual state of the Sourceforge
project and did not touch to anything to the sources. Everything goes
well.
For your bugs :
1. selfcheck bug is not a bug, it's just that selfcheck is not
provided in the Win32 version. If you are suck with the amcheck
errors, do the same thing as me : selfcheck.c : int main() {return
0;}, and if you are lazy compiling such a thing, I've attached it
here.
2. sendsize crash ? Well... Er... Er... Er... Where ??? I've had
some problems with sendsize, but it corrected itself with the
-udp=10080 -no-exit parameters to the amandad.exe program. I did not
examine precisely the source code but the -no-exit seems to be very
important...
What I've done with this project? Well... Just got it from
Sourceforge and installed it on W2K boxes: what I've done is installed
it as a WinNT service. I am running it with an Amanda 2.4.3b2 server
on a Linux box, and no errors reported yet (1,5 Go backed up every
night). Not checked with omre recent versions.
--
Jean-Christian SIMONETTI email: [EMAIL PROTECTED]
SysAdmin Wanadoo Portails phone: (+33)493004911
Sophia Antipolis, France
--
Are you SURE there are no errors? I tested this yesterday. It
appears that sendbackup only logs the errors tothe debug file in
/tmp/amanda. Also, each sendbackup process overwrites this file.
It also appears that this doesn`t support excludes. Amandad reports
the standard exclude list path, but I couldn,t get it to work.
You previously mentioned that amanda maps the archive bit to the UNIX
execute bit. It is actually the win32 tar that does this. I believe
Samba also doed this to help preserve the Windows permissions.
This appears to be early alpha quality software, not ready for
production. Unfortunately, it also appears to be abandoned :-(
Bruce Osborne
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: win32
On Thu, 12 Sep 2002 12:23:25 -0400
Galen Johnson [EMAIL PROTECTED] wrote:
JC Simonetti wrote:
amrecover is possible. You extract the tarball archive on your backup server and
upload it to the Windows box, and there you untar it with the WinTar provided with
Win32 Amanda (different of course from the GNU tar, due to NT file rights...).
amrestore is possible, but I don't like the ability of the client to log in as root
without password on the backup server, so I tested the solution but did not put it in
production. amrestore is also helped by a GUI written in Python (need to install a
Python interpreter on your Windows box, easy way but not so easy to automatically
deploy).
Have you, or will you, put the changes out for others?
Will be done. See my previous mail ;)
Can I assume from what you've been saying that you've actually gotten
the amanda-win32 project from sourceforce to compile properly? What
about the selfcheck bug? Or sendsize crashes that were reported? these
questions assume you are using amanda-win32. I've tried contacting the
current maintainer with no success. All the source files are about 18
months old and CVS hasn't been touched in as long.
Also, what version of amanda have you gotten it to work with? There was
a previous response from someone who couldn't get it to work on the more
recent code.
=G=
Well... You're right, I got the actual state of the Sourceforge project and did not
touch to anything to the sources. Everything goes well.
For your bugs :
1. selfcheck bug is not a bug, it's just that selfcheck is not provided in the Win32
version. If you are suck with the amcheck errors, do the same thing as me :
selfcheck.c : int main() {return 0;}, and if you are lazy compiling such a thing,
I've attached it here.
2. sendsize crash ? Well... Er... Er... Er... Where ??? I've had some problems with
sendsize, but it corrected itself with the -udp=10080 -no-exit parameters to the
amandad.exe program. I did not examine precisely the source code but the -no-exit
seems to be very important...
What I've done with this project? Well... Just got it from Sourceforge and installed
it on W2K boxes: what I've done is installed it as a WinNT service. I am running it
with an Amanda 2.4.3b2 server on a Linux box, and no errors reported yet (1,5 Go
backed up every night). Not checked with omre recent versions.
--
Jean-Christian SIMONETTI email: [EMAIL PROTECTED]
SysAdmin Wanadoo Portails phone: (+33)493004911
Sophia Antipolis, France
--
attachment: selfcheck.exe
Re: win32
On Wed, 11 Sep 2002 12:02:09 -0400 (EDT) Samuel Nicolary [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002, Galen Johnson wrote: Hello gang, A while back I had sent a request regarding backing up windows machines without having to deal with samba. Someone had responded with the win32 Amanda client on sourceforge. I have looked it up and it seems like it'll do what I want. However, it hasn't been touched in 18 months. Is anyone currently using this with Amanda 2.4.3.b4? I downloaded this package but have been unable to get it to work - anyone using it successfully? Well... I was a bit tricky but I managed to make this work with Amanda 2.4.3b2 and W2K clients (not NT4). The major problems in fact were to transform this slight piece of code into a W2K Service (to make it work even if you have not an Administrator account always opened) (quite a bit tricky to to find information at Microsoft's). Another problem was due to the Windows flag archive that seems to be read by Amanda exactly like the Unix executable flag. Now I am backuping some W2K servers, in production. Everything goes well :) -- Jean-Christian SIMONETTI email: [EMAIL PROTECTED] SysAdmin Wanadoo Portails phone: (+33)493004911 Sophia Antipolis, France --
Re: win32
Care to share what you went through? I remember there's an exe you have to run to turn any program into a service (anyserv.exe?) as I've had to do it for a perl script before. Would be nice to get it all under the same backup system. On 9/12/02 2:35 AM, JC Simonetti [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002 12:02:09 -0400 (EDT) Samuel Nicolary [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002, Galen Johnson wrote: Hello gang, A while back I had sent a request regarding backing up windows machines without having to deal with samba. Someone had responded with the win32 Amanda client on sourceforge. I have looked it up and it seems like it'll do what I want. However, it hasn't been touched in 18 months. Is anyone currently using this with Amanda 2.4.3.b4? I downloaded this package but have been unable to get it to work - anyone using it successfully? Well... I was a bit tricky but I managed to make this work with Amanda 2.4.3b2 and W2K clients (not NT4). The major problems in fact were to transform this slight piece of code into a W2K Service (to make it work even if you have not an Administrator account always opened) (quite a bit tricky to to find information at Microsoft's). Another problem was due to the Windows flag archive that seems to be read by Amanda exactly like the Unix executable flag. Now I am backuping some W2K servers, in production. Everything goes well :) -- Jean-Christian SIMONETTI email: [EMAIL PROTECTED] SysAdmin Wanadoo Portails phone: (+33)493004911 Sophia Antipolis, France --
Re: win32
On Thu, Sep 12, 2002 at 09:35:57AM +0200, JC Simonetti wrote: On Wed, 11 Sep 2002 12:02:09 -0400 (EDT) Samuel Nicolary [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002, Galen Johnson wrote: I downloaded this package but have been unable to get it to work - anyone using it successfully? Well... I was a bit tricky but I managed to make this work with Amanda 2.4.3b2 and W2K clients (not NT4). The major problems in fact were to transform this slight piece of code into a W2K Service (to make it work even if you have not an Administrator account always opened) (quite a bit tricky to to find information at Microsoft's). Another problem was due to the Windows flag archive that seems to be read by Amanda exactly like the Unix executable flag. Now I am backuping some W2K servers, in production. Everything goes well :) Important follow-ups: Can you also amrecover/amrestore? Have you, or will you, put the changes out for others? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: win32
I'll post here a little howto as soon as I find time. Don't hesitate to remind me of that if I forget. (one week could be a correct timeout for me I think if I have not too any problems...) On Thu, 12 Sep 2002 09:01:18 -0500 Tony Shadwick [EMAIL PROTECTED] wrote: Care to share what you went through? I remember there's an exe you have to run to turn any program into a service (anyserv.exe?) as I've had to do it for a perl script before. Would be nice to get it all under the same backup system. On 9/12/02 2:35 AM, JC Simonetti [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002 12:02:09 -0400 (EDT) Samuel Nicolary [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002, Galen Johnson wrote: Hello gang, A while back I had sent a request regarding backing up windows machines without having to deal with samba. Someone had responded with the win32 Amanda client on sourceforge. I have looked it up and it seems like it'll do what I want. However, it hasn't been touched in 18 months. Is anyone currently using this with Amanda 2.4.3.b4? I downloaded this package but have been unable to get it to work - anyone using it successfully? Well... I was a bit tricky but I managed to make this work with Amanda 2.4.3b2 and W2K clients (not NT4). The major problems in fact were to transform this slight piece of code into a W2K Service (to make it work even if you have not an Administrator account always opened) (quite a bit tricky to to find information at Microsoft's). Another problem was due to the Windows flag archive that seems to be read by Amanda exactly like the Unix executable flag. Now I am backuping some W2K servers, in production. Everything goes well :) -- Jean-Christian SIMONETTI email: [EMAIL PROTECTED] SysAdmin Wanadoo Portails phone: (+33)493004911 Sophia Antipolis, France --
Re: win32
On Thu, 12 Sep 2002 11:16:11 -0400 Jon LaBadie [EMAIL PROTECTED] wrote: On Thu, Sep 12, 2002 at 09:35:57AM +0200, JC Simonetti wrote: On Wed, 11 Sep 2002 12:02:09 -0400 (EDT) Samuel Nicolary [EMAIL PROTECTED] wrote: On Wed, 11 Sep 2002, Galen Johnson wrote: I downloaded this package but have been unable to get it to work - anyone using it successfully? Well... I was a bit tricky but I managed to make this work with Amanda 2.4.3b2 and W2K clients (not NT4). The major problems in fact were to transform this slight piece of code into a W2K Service (to make it work even if you have not an Administrator account always opened) (quite a bit tricky to to find information at Microsoft's). Another problem was due to the Windows flag archive that seems to be read by Amanda exactly like the Unix executable flag. Now I am backuping some W2K servers, in production. Everything goes well :) Important follow-ups: Can you also amrecover/amrestore? amrecover is possible. You extract the tarball archive on your backup server and upload it to the Windows box, and there you untar it with the WinTar provided with Win32 Amanda (different of course from the GNU tar, due to NT file rights...). amrestore is possible, but I don't like the ability of the client to log in as root without password on the backup server, so I tested the solution but did not put it in production. amrestore is also helped by a GUI written in Python (need to install a Python interpreter on your Windows box, easy way but not so easy to automatically deploy). Have you, or will you, put the changes out for others? Will be done. See my previous mail ;)
Re: win32
JC Simonetti wrote: amrecover is possible. You extract the tarball archive on your backup server and upload it to the Windows box, and there you untar it with the WinTar provided with Win32 Amanda (different of course from the GNU tar, due to NT file rights...). amrestore is possible, but I don't like the ability of the client to log in as root without password on the backup server, so I tested the solution but did not put it in production. amrestore is also helped by a GUI written in Python (need to install a Python interpreter on your Windows box, easy way but not so easy to automatically deploy). Have you, or will you, put the changes out for others? Will be done. See my previous mail ;) Can I assume from what you've been saying that you've actually gotten the amanda-win32 project from sourceforce to compile properly? What about the selfcheck bug? Or sendsize crashes that were reported? these questions assume you are using amanda-win32. I've tried contacting the current maintainer with no success. All the source files are about 18 months old and CVS hasn't been touched in as long. Also, what version of amanda have you gotten it to work with? There was a previous response from someone who couldn't get it to work on the more recent code. =G=
Re: win32
On Wed, 11 Sep 2002, Galen Johnson wrote: Hello gang, A while back I had sent a request regarding backing up windows machines without having to deal with samba. Someone had responded with the win32 Amanda client on sourceforge. I have looked it up and it seems like it'll do what I want. However, it hasn't been touched in 18 months. Is anyone currently using this with Amanda 2.4.3.b4? I downloaded this package but have been unable to get it to work - anyone using it successfully?
Re: Win32 client setup
Wayne Richards wrote: I've got the Win32 client setup and running in a console window on an NT box running NT4.0 SP6a. It works well. I've also setup amanda as a service according to the instructions. However, the service does not start. It hangs for a while and then gives an error: Error 2186: The service is not responding to the control function. Now, I went to the MS support site and found the 2186 error. The solution given was to upgrade to the most current SP. So I checked my machine and it had SP6a, but there was a hotfix that wasn't loaded (Q246009), so I loaded it and restarted the system. The service is to run under the user 'amanda' as a local user with administrative rights including the right to 'login as a service'. It's setup as a 'Manual' service so it does not try to start at boot, even though that's what I would prefer. The server is a Sun E3000 and has no problem backing up the NT box when the client is running in the foreground in a console window or command window. Has anyone had any luck with the Win32 client as a service? I found the client at: http://sourceforge.net/projects/amanda-win32/ Yes, I've been using it for several weeks. It seems it's a bit buggy though. I've had it refuse to work on two machines until I rebooted. Then it works for awhile, but eventually does the same thing a few days later, and I need to reboot again. I've also had one of the machines refuse to work (Dr Watson errors) until I deinstalled Python and WxPython, which are necessary for the client's amrestore; weird. I have my service running using the system account, with interact with the desktop left unchecked. I would try this first. I also have my service starting up automatically at bootup. Also, don't forget to edit the registry settings of the service to point to the correct path of the amanda installation. -Kurt
Re: Win32 client setup
Jon LaBadie wrote: I did not feel the installation instructions were too clear. Maybe I have not found the correct ones. Pointers? This is very true; I had to fiddle a bit to make it work. Here's what I did: -download the amanda-clients-bin latest zip file and unzip it -make a folder usr in one of your drives -move the amanda folder into it; path to binaries should be \usr\amanda\bin and so forth -copy pw32.8.dll from the bin folder to libexec and sbin folders -copy \usr\amanda\share\amanda-win32-clients\.amandahosts to \usr\amanda\etc\amanda\ -add your amanda master to the \usr\amanda\etc\amanda\.amandahosts -start your amanda test: run \usr\amanda\libexec\rc.amandad.bat (an empty dos window should pop up) -add entries to the amanda master's disklist; use the form hostname /mnt_drive letter dump-type, one for each disk on each nt host; my disklist entry for my nt host looks like gandalf /mnt_c user-tar, etc -run amcheck on the master, make sure you see the server connecting on the nt host; you should see its name show up in the window on the nt machine that rc.amandad.bat opened -if the test was successful, close rc.amandad.bat and install \usr\amanda\libexec\amandad.exe as a service named amandad (use srvany.exe from the nt resource kit for this); service should be a system account and start up automatically -suggested registry entries for the amandad service are in \usr\amanda\share\amanda\amandad.reg; double click on this file to install its keys -make sure the drive letter and path in the registry's hklm/system/ccs/services/amandad/parameters key matches where amandad.exe is actually installed -start up the amandad service Two questions, does the W32 client anticipate the cygwin package is installed on the M$ box? Though I did not see it stated, I got that impression. Cygwin is not necessary. Second, I came across a page describing environment variables that need be set. Something about the PW32 environment (Posix Win 32??). Are these set on the unix amanda server or on the client when started from the service routines? I didn't set any environment variables on the NT machine.
