FreeBSD client/Linux client under FreeBSD

[mhornyak]

I attempted to use the Linux client under the FreeBSD Linux emulation layer. I am almost successful; the Retrospect server can see the client. However, no volumes show up. Has anyone else attempted this? If so, in what configuration did you get it to work (which release of FreeBSD, Linux_base, etc.)?

 

 

 

Aside from this: I'd like to see a semi-official FreeBSD version of the Retrospect client. Is this forthcoming? I assume not much more than a recompile is required...

 

 

 

Matt

[mhornyak]

I figured out how to get the Linux client running under FreeBSD's Linux emulation.

 

 

 

I'm running FreeBSD-RELEASE 4.3.

 

 

 

You'll need the Linux emulation environment; see the FreeBSD handbook for how to install it. Use linux_base-6 (from /usr/ports/emulation/) instead of linux_base as later versions of the package fail. Version 7 did not work for me.

 

 

 

Create a Linux-formatted mtab file in /usr/compat/linux/etc/ based on /etc/fstab. I altered fstab to appear as a Linux mtab would; for example, I replaced references to ufs with ext2. I also removed filesystems I don't want to back up.

 

 

 

This allows Retrospect to see the Linux filesystem FreeBSD creates for the Linux emulation layer; unfortunately, this does not include all the files on your machine -- it's mostly comprised of the /usr/compat/linux directory masquerading as /.

 

 

 

We then need to expose the rest of the filesystem to Retrospect. It can see directories in / which have no corresponding directory in /usr/compat/linux, so I created an alternate mountpoint in / called /backup. Under /backup I created mountpoints for each directory in / (bin, etc, usr...). Next I used the null filesystem to mount the directories I want to back up on these new mountpoints. For example,

 

 

 

mount_null -o ro /bin/ /backup/bin

 

 

 

mounts /bin/ as /backup/bin. I repeated this for each directory in /backup.

 

 

 

That's it... all files are visible in the preview window, and were downloaded by the backup server during a test backup I just ran.

 

 

 

I'd like to see a recompiled FreeBSD client, but this isn't too bad...

 

 

 

Matt

[keen]

 

Folks,

 

Has there been any update to this? I'm looking closely at purchasing retrospect for our mixed windows (00/XP) / mac (X, 9) / FreeBSD environment, to replace amanda.

 

..but the above mentioned workarounds for the Linux client are a bit much, for 20+ FreeBSD servers, and a few more workstations. That's a lot of additional maintenance when something changes.

 

Dantz, do you plan to offer a FreeBSD 4.x compatable version of the client? Our office has used retrospect since at least '96 for some things, and I'd love to use it to unify our backup systems. (..that is to say, I have a laptop w/ retrospect client that claims it was last backed up sometime in '96..)

 

I can possibly offer a temporary development platform for this purpose, if needed.

[kai]

I've talked to Dantz at the Cebit in germany and no, a FreeBSD-client is not planned yet. The effort to give support for this client would be to much...

 

I'm doing the backup of my NetBSD-Client now via NFS-Share. I've created an NFS-Share at the root-directory mounting logged-in-users to root. Access is only allowed to the Fileserver with Retrospect on it. There you can mount a Network-Volume that you may include into your backup process...

[ramstadt]

I would also like to see a FreeBSD client. Is there any possibility that Dantz could release just the client source for the Linux version? If so, there are many developers that would be willing to port it to FreeBSD, NetBSD and others. FreeBSD is extremely popular in the server world and good backup software is hard to find.

[evaldas]

Hi,

 

Anybody had success in running Linux client under FreeBSD 5 ?

 

I run it here simply by execing "retroclient -daemon", it starts listening on UDP 497, and Retrospect server sees it, but is unable to activate it. I suspect "retrocpl -on" should be run before because the client is running, but not enabled ? But I don't see java on FreeBSD 5, yet, so no way to execute retrocpl.. Any ideas ?

[natew]

Hi

 

What happens when you try to activate it? Do you get an error? You only need Java to run the GUI.

 

I know abosultely nothing about BSD... Could the problem with logging into the client be related to glib? If you get the links to glib wrong on a solaris machine you will be able to see the client but log in will fail.

 

Thanks

Nate

[evaldas]

Hello,

 

Ok, thanks, it's not the java

 

After some further testings on FreeBSD 5 and FreeBSD 4 (both using the same linux_base-6 port, actually results are the same using linux_base-7 and linux_base-8) :

 

It works fine on FreeBSD 4 (FreeBSD 4.9-RELEASE), here is how retroclient.log starts :

 

1088148473: SopsLoad: Handle 4 open

1088148473: SopsLoad: Handle 4 closed

1088148473: SopsSave: Handle 4 open

1088148473: SopsSave: Handle 4 closed

1088148473: SopsSave: Handle 0 open

1088148473: SopsSave: Handle 0 closed

1088148473: ServiceInstall: allocating memory for Builtin

1088148473: ServiceInstall: allocating memory for RfsCountdown

1088148473: ServiceInstall: allocating memory for RfsDownload

1088148473: SThreadSpawn: starting thread 1026

1088148473: netDoAccept: Releasing thread for NetDoShutdownTest()

1088148473: NetDoShutdownTest: shutdown test passed

1088148473: netDoAccept: socket 0 shutdown

1088148473: sThreadExit: exiting thread 1026

1088148473: SThreadSpawn: starting thread 2051

1088148473: netCheckNewInterfaces: Handle 0 open

1088148473: netCheckNewInterfaces: found new address 172.16.255.12:0

1088148473: NetAddInterface: adding ip: 172.16.255.12:0 to list

1088148473: IPNSStart: starting thread iplud

1088148473: SThreadSpawn: starting thread 3074

1088148473: iplud: interface for socket 4 open

1088148473: NetSockAdd: adding socket 4 to interface 1

1088148473: iplud: bound to address 0.0.0.0

1088148473: ipludAddMembership: adding membership for 0.0.0.0

1088148473: ipnsBroadcast: Handle 6 open

1088148473: iplud: got 196 bytes from 172.16.255.12:1060

 

Output from "netstat -na|grep 497":

 

tcp4 0 0 127.0.0.1.497 *.* LISTEN

tcp4 0 0 172.16.255.12.497 *.* LISTEN

udp4 0 0 *.497 *.*

 

Output from "retrocpl":

 

Version 6.5.108

back up according to normal schedule

currently on

readonly is off

exclude is off

0 connections, 0 authenticated

=============================================

 

Now, on FreeBSD 5 (FreeBSD 5.2.1-RELEASE-p1) etroclient.log starts :

 

1088149113: SopsLoad: Handle 4 open

1088149113: SopsLoad: Handle 4 closed

1088149113: SopsSave: Handle 0 open

1088149113: SopsSave: Handle 0 closed

1088149113: ServiceInstall: allocating memory for Builtin

1088149113: ServiceInstall: allocating memory for RfsCountdown

1088149113: ServiceInstall: allocating memory for RfsDownload

1088149113: SThreadSpawn: starting thread 1026

1088149113: netDoAccept: Releasing thread for NetDoShutdownTest()

1088149113: NetDoShutdownTest: shutdown test passed

1088149113: netDoAccept: socket 0 shutdown

1088149113: SThreadSpawn: starting thread 2051

1088149113: netCheckNewInterfaces: Handle 4 open

1088149113: netCheckNewInterfaces: found new address 172.16.255.10:0

1088149113: NetAddInterface: adding ip: 172.16.255.10:0 to list

1088149113: IPNSStart: starting thread iplud

1088149113: sThreadExit: exiting thread 1026

1088149113: SThreadSpawn: starting thread 3076

1088149113: iplud: interface for socket 0 open

1088149113: NetSockAdd: adding socket 0 to interface 1

1088149113: iplud: bound to address 0.0.0.0

1088149113: ipludAddMembership: adding membership for 0.0.0.0

1088149113: ipnsBroadcast: Handle 6 open

1088149113: iplud: got 196 bytes from 172.16.255.10:55208

 

Output from "netstat -na|grep 497":

 

udp4 0 0 *.497 *.*

 

and output from "retrocpl":

 

Retrospect client is not running

 

which looks normal as retroclient is not listening on localhost:TCP:497 . I guess in FreeBSD 5 there are some changes in a way socket opens are done, or retroclient is trying to do it in a way FreeBSD does not understand, maybe some more debug info could help, but how to activate it ? Anyway the point is, retroclient fails to open TCP port on FreeBSD 5 at the moment.

 

Regards,

Evaldas

[evaldas]

Hi again, forgot about the libs - verified, all libs are in place (retroclient 6.5):

 

ldd retroclient

retroclient:

libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x28086000)

libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x28089000)

libpthread.so.0 => /lib/libpthread.so.0 (0x280ab000)

libc.so.6 => /lib/libc.so.6 (0x280be000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2806f000)

 

Also, killing retroclient process on FreeBSD 5, leaves zombie processes:

 

root 0 0.0 0.0 0 0 ?? ZW - 0:00.00 (retroclient)

root 0 0.0 0.0 0 0 ?? ZW - 0:00.00 (retroclient)

root 0 0.0 0.0 0 0 ?? ZW - 0:00.00 (retroclient)

 

Thanks,

Evaldas

[phillipkh]

You can fix the zombie processes under FreeBSD 5.2.1-STABLE by patching 2 kernel files. The problem with zombie processes with some threaded applications running under the Linux compatibility layer I think are already fixed with the FreeBSD -CURRENT branch, but I can't readily test that since my production box runs -STABLE instead of -CURRENT.

 

I don't know the exact specifics of the problem, but I think that some threaded apps running under the Linux compatability layer don't get reaped by init correctly since the semantics for handling SIGCHLD between between various UNIX platforms is not well standardized IMHO.

 

This is also an issue with other apps, and you can read up on that here in more depth:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=bausg0%2416c5%241%40FreeBSD.csie.NCTU.edu.tw&rnum=13

 

Here are the kernel files that you can try patching. It seems to work good on the FreeBSD box that I run Retrospect on. This is running 5.2.1 stable patched up to -p9 through cvsup:

 

 

/usr/src/sys/kern/sys_process.c

Code:

---

--- sys_process.c.orig Wed Jul 28 14:30:23 2004

+++ sys_process.c Wed Jul 28 18:29:16 2004

@@ -566,6 +566,7 @@

p->p_oppid = 0;

 

/* should we send SIGCHLD? */

+ p->p_sigparent = SIGCHLD;

}

 

sendsig:

---

 

 

/usr/src/sys/kern/kern_exit.c

Code:

---

--- kern_exit.c.orig Wed Jul 28 14:30:11 2004

+++ kern_exit.c Wed Jul 28 18:29:27 2004

@@ -458,6 +458,7 @@

pp = p->p_pptr;

PROC_UNLOCK(pp);

proc_reparent(p, initproc);

+ p->p_sigparent = SIGCHLD;

PROC_LOCK(p->p_pptr);

/*

* If this was the last child of our parent, notify

---

[tomgig]

deleted content

[natew]

Hi Tom

 

We certainly hear you and are exploring alternatives.

 

Releasing an unsupported client is a double edged sword. An experienced user like yourself will understand the risk involved with using unsupported software. Other users, especially people not familiar with open source software or Linux/BSD, are less likely to understand that risk.

 

When we release a client it is done so with the understanding that Dantz stands behind a full system restore of the client machine. For the moment we are keeping it that way...

 

Nate @ Dantz

[tomgig]

 

deleted content

[natew]

Hi

 

Sad to say I don't have the details for you. Any new client support would likely be a part of a new version of Retrospect.

 

I will pass on your coments for sure. You may also want to post your request in the feature request section of this forum.

 

Thanks

Nate

[mkucenski]

I too would love it if Dantz would support FreeBSD.

 

Anyway, can someone who has gotten this working in Linux compatibility mode on FreeBSD help me out?

 

I installed the client and it starts fine, but when I try to add the client from my MacOSX server it say no clients found. If I hit the 'Test' button and type the IP address of the FreeBSD server, it shows a valid backup client. Unfortunately, (and this really chaps my ass DANTZ) they put a 'Add by Address' button that I can't use because I'm not running an advanced license.

 

So the question is how can I get the server to discover the FreeBSD client? Any suggestions? I checked my firewall and I'm not getting any blocked hits. The FreeBSD server is multihomed is there something I need to do differently to bind to a different address?

 

Thanks,

-Matt

[mkucenski]

Trying to track this down some more and I'm wondering if I am running into a router/firewall problem. My server is and Internet router/firewall using natd/ipfw. I'm wondering if the multicast packets are somehow getting wrongly diverted out to the Internet rather than remaining on the local subnet by the firewall. This would result in the client never receiving the discovery packets and thus no client found.

 

Any ipfw experts have any suggestions?

 

Thanks,

-Matt