| View previous topic :: View next topic |
| Author |
Message |
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
 Posted: Wed Apr 06, 2005 6:45 am Post subject: Howto: Compiling By Proxy... |
 |
|
Compiling By Proxy: Building Packages for a Slow Computer on a Fast One.
NOTE THAT THIS HOWTO IS CURRENTLY A "BETA"! For the sake of consistency, I would like to know that this works for at least a few other people, before considering it l33t. So consider this doc experimental. Use at your own risk.
Greetings,
Do you have a paper weight, a.k.a. a dinosaur, a.k.a. an old computer that is slower than dirt... and you want to use Gentoo on in (e.g. maybe for a router, or a web server for developement purposes)? But, you don't want to wait literally days to compile apps at a time? If you already have Gentoo installed on a newer (and hopefully, considerably faster!) computer, I have a trick that just might help. 
The purpose of this Howto is to explain how you can configure a new computer to safely compile binary packages for a legacy (or old) computer, and install them on the legacy computer over your network. This will save a HUGE amount of time, as the vast majority of your time doing emerges is sucked up by the compile time. One the other hand, installing a prebuilt package is relatively quick, even on dated hardware.
This setup can also be used to compile kernels... but see below for some important details on this.
Note, this howto assumes:
1) You have a faster computer, with plenty of RAM, a good processor speed, and at least a few Gigs of free space.
2) You have a legacy computer, which at the very least meets the minimum requirements to actually run Gentoo.
3) They have compatible architectures. Both are x86? you are good to go. amd64 and x86? that's my setup. x86 and something else... err you will want to check the docs for the fruity arch.
4) They are networked together... I figure this one was obvious. I'm using IP/ethernet.
5) You have an existing install on the Paper Weight. However, if you are doing a clean install, no problem! These instructions can be adapted to that situation... and in fact, you could theoretically cut down on install time by using prebuilt packages for some things. (My advice on this: start from a stage 3 tarball... you can always recompile everything after the fact.)
Caveats:
A) If the computers are actually quite similar in terms of performance, doing distributed compiles would better suit your needs. See the Gentoo doc here: distcc
B) For consistency, this Howto requires multiple emerges. Meaning for the love of Pete! do the community a favor and set up a local rsync mirror (link).  We'll talk about this a bit later, but go to that thread to see how to set it up, specifically.
(Note that neither of the above caveats will be supported here.)
C) There are actually many ways to skin this cat. This HowTo is based on how i set this up myself... however if you see any steps you think you can skip, or else you can do something different that would be better for your setup, go ahead and deviate from this Howto!
1. Preparing the new, fast computer. We need to set aside some disk space on the newer computer. We will be using this to set up a parody environment... I'll explain the meaning of that in a bit. If you have free, unpartitioned space on your hard drive, set up a new partition and format it. 2-5GB seems to be a decent, though you could cheat and get less. I suggest it be the same size as the hardrive on the older computer, if it is 5GB or less.
1a. Create your mount point. I use /mnt/g32. Use whatever is preferable for you:
1b. Mount it and put it in your fstab:
| Code: | | # mount /dev/hda5 /mnt/g32 |
| Code: | # nano -w fstab
...
/dev/hda5 reiserfs noatime,notail 0 1 |
1c. Alternative. If instead you don't have unpartitioned space or else don't care to use it for this purpose, just set up a folder on your system. Preferably, put it in a place you can remember.
1c. For this howto, I will use Network File System (NFS). As you will see, it is like Samba or Windows networking, except it is Linux (Unix?), so by default it is better in every single way.  We need to do a few things to get set up for NFS:
1c(i). Go to the kernel folder, and prepare to recompile the kernel:
| Code: | # cd /usr/src/linux
# make menuconfig |
1c(ii). These are the settings you need to get set:
| Code: | File Systems -->
Network File Systems -->
<*> NFS file system support
...
<*> NFS server support
[*] Provide NFSv3 server support |
1c(iii). Recompile and install ye olde kernel!
| Code: | | # make && make modules_install && make install |
1c(iv). Install the NFS stuff:
1c(v). Reboot.
2. Preparing the legacy computer. Note that if you are doing a clean install, this is a good time to start that process.  Otherwise, we also have to configure this computer for NFS.
2a. Run menuconfig on the old computer.
| Code: | # cd /usr/src/linux
# make menuconfig |
2b. Set the NFS options:
| Code: | File Systems -->
Network File Systems -->
<*> NFS file system support
[*] Provide NFSv3 client support |
Important note: notice how this is different form the above. We are setting it up so your supercharged PC is the NFS server and your dinosaur PC is the client. We could, of course, set them both up as clients and computers, but for our purposes that is unnecessary (and if security is an issue, then the less of a vulnerability footprint you have, the better).
2c. emerge nfs-utils. If all goes well, this is the last thing you'll ever have to compile on this computer.
2d. Reboot.
3. Install Gentoo... again. For the new computer, we are going to... umm... install Gentoo. "Huh?" you might be thinking. You already have Gentoo installed. Well I'm glad you asked.
You see, what we don't want to do is moobar your portage tree on your fast computer. More than likely, you have a lot of bells and whistles, X, and one of the beefier window environments installed, and that might be a bit much for a computer that was made with Windows 95/98 in mind  (or please don't tell me... DOS???). Hence, we sacrifice a bit of disk space (but these days, big disks are inexpensive, so what's a few more gigs?), adding an additional install of Gentoo which will act as a "parody install." I call it a parody install because it when we are done it should be almost exactly the same as the install of Gentoo on the dinosaur. It's only purpose, however, is to just sit there, take up disk space, and compile our packages when we need it.
If you still have doubt, let me put it this way: so long as you don't do something too stupid, you will keep portage trees separate so you don't moobar your fast PC, the legacy PC, or both. That is especially important if they are significantly different in archtecture (even if it's a matter of Pentium 4 vs. Pentiom 2). As a bonus, the parody will act as a backup, meaning that if your legacy install gets b0rked or compromised, you can just reboot using the LiveCD, wipe it, set up network, copy everything over... grab lunch, and reboot.
3a. Remember on your fast PC, you either set up a new partition, or you set up a folder in an easy to remember place. Let's go there:
3b. Just like a regular installation, download the appropriate stage tarball and portage snapshot. Then untar them per Gentoo instructions.
3c. copy over your resolv.conf file:
| Code: | | # cp /etc/resolv.conf /mnt/g32/resolv.conf |
3d. chroot into the new environment:
| Code: | | # chroot /mnt/g32 /bin/bash |
For amd64 users setting up an x86 install, this is a bit different:
| Code: | | # linux32 chroot /mnt/g32 /bin/bash |
3e. Don't forget to update the env:
| Code: | | # env-update && source /etc/profile |
3f. In your chroot environment, add this to your make.conf:
| Code: | | FEATURES="buildpkg" |
This feature will make it so a package is created every time you emerge something on this computer. This is equivalent to typing "emerge --buildpkg foo" for every package you want. However, we set the feature so you don't have to remember the --buildpkg (-b) flag every time.
Also, this is a good opportunity to set up the make.conf file as you would like. For instance, go ahead and add the CFLAG optimizations and USE flags you want to use.
3g. From here, continue the installation process using your prefered method. For reference, the Gentoo instructions for x86 are here:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml
At this point, some things are optional. For instance, you don't need to configure your fstab on this machine since in theory we will only be chrooting (is that a word?) into that install. However, it is still recommended that you set it up the same as on the legacy box: if Gentoo on the legacy PC ever gets whalloped, you can do a quick restore from the parody with minimal fuss.
3h. For consistency, it might be a good idea to emerge --sync both the legacy computer and the parody install. (Now or something before this step would be a great time to set up the rsync mirror per the instructions in the linked howto above. My recommmendation is to set it up either on a third computer or on the legacy computer. that way, we avoid the philosophical paradox of trying to emerge --sync one portage from a daemon on the same computer using the same network interface )
3i. If you didn't during the parody installation, you should re-emerge everything, so all the packages you might need will be available.
Grab dinner, as this will take a while.
3j. Emerge all the extra packages you use or plan to use on the legacy box. The point here is to get the parody install to look, feel, and taste like what you have (or plan to have) installed on the old PC. Don't worry if you can't remember everything you need emerged... if you miss something we can address that in a moment.
4. Configure NFS. We installed NFS; we reconfigured our kernels for NFS. Now, let us put it to work. (information on Network File System can be found in the Gentoo Wiki here: http://gentoo-wiki.com/index.php?title=HOWTO_Share_Directories_via_NFS).
4a. On the fast computer (not in the chroot, in your actual install), edit "exports," the file used by NFS:
| Code: | | # nano -w /etc/exports |
4b. Add lines similar to these:
| Code: | /mnt/g32/usr/portage/packages 192.168.1.0/255.255.255.0(async,ro)
/mnt/g32/boot 192.168.1.0/255.255.255.0(async,ro) |
Basically, each folder represents a file we want to share from your fast computer to your slow computer. Each line starts with the directory location of the share, then you have the IP of the computer or network you want it to be shared to (in my case, my LAN is 192.168.1.* with a subnet mask of 255.255.255.0). Finally, we set our options: the main thing we are interested in is read only vs. read write priveledges. I have no reason for my old PC to write to either directories, so i set them to "ro," read only.
The reason why ./boot is being shared has to do with transfering the kernel over; I'll explain in a moment.
4c. Start up the NFS daemon:
| Code: | | /etc/init.d/nfs start |
And while we are add it, we might was well add it to boot:
| Code: | | rc-update add nfs default |
4d. Create relevant mount points on the Legacy computer:
| Code: | # mkdir /mnt/packages
# mkdir /mnt/boot |
4e. Mount the shares. We can just use the "mount" command just like mounting any filesystem. If the IP of the new computer was 192.168.1.100, for instance, then:
| Code: | # mount -t nfs 192.168.1.100:/mnt/g32/usr/portage/packages /mnt/packages
# mount -t nfs 192.168.1.100:/mnt/g32/boot /mnt/boot |
4f. You can also add these to your fstab; however before you do this, you should first set up your fast computer with a static IP, or else use a host name and configure your network so that that computer always has the same host name, regarless of the IP.
| Code: | # nano -w /etc/fstab
192.168.1.100:/mnt/g32/usr/portage/packages /mnt/packages nfs ro 0 0
192.168.1.100:/mnt/g32/boot /mnt/boot nfs ro 0 0 |
5. Let's get cooking! We are almost done. Now there are some miscellanious things we ought to do.
5a. On the lagacy box, add this line to your make.conf:
| Code: | | PKGDIR=/mnt/packages |
Note that it would be a bad idea to add this to your make.conf on the parody install... that would just cause... umm... shear craziness to ensue. So, this is probably the only thing i would recommend you NOT make the same on both installs.
5b. Now, we need to verify that all is well in the world (*chuckle chuckle*). An easy way is to doing a pretend emerge on the legacy computer:
| Code: | | # emerge --pretend --update --emptytree --usepkgonly world |
The staccato version of this is below.
| Code: | | # emerge -pueK world |
What this will do is tell us what would happen if the dinosaur tried to install everything, using only packages. Since it's allowed to use prebuilt packages only, this will cause emerge to barf out errors if it could not perform this correctly. So, we can verify that (1) the legacy computer is finding the packages share, and (2) whether there are any missing packages we need to build. It will report what packages are missing, so you can simply emerge them in the parody and try again.
5c. If there is nothing wrong let's put out setup to work! On the paper weight computer:
| Code: | | # emerge -ueK world |
Now, have you tried emerging everything at a time on this computer? Remember it taking literally days? Unless this is an extremely slow computer, it should only take a few hours! very cool 
5d. While you can compile the kernel on the legacy box itself (it will take quite some time, as you already have found), from now on we can compile it on the parody install, and then we transfer it over. My recommendation on this is as follows:
5d(i). Get into menuconfig on the parody install.
5d(ii). Modules present themselves an unusual problem on this setup. To make things simplier, compile everything in as part of the kernel (that is, instead of having any "M's" in there, replace them all with "*'s"). Don't forget the NFS settings.
5d(iii). Compile it.
| Code: | | # make && make install |
5d(iv). Copy everything over. On the legacy box:
| Code: | | # cp /mnt/boot/* /boot |
5d(v). Configure grub. the "make install" command saved the kernel as "vmlinuz-..." in the /boot directory. "vmlinuz" is a link to the current kernel that is always updated to the newest compiled kernel, so you can just put that in your grub.conf. (i'd also add "vmlinuz.old" in grub.conf as well, as a backup kernel). And then, have grub write to the boot record.
And now we are done... you can reboot to verify that the new kernel loads. And whenever you get the urge to update the legacy box, just chroot into the parody install, run "emerge -uDN world" (those flags are the same as --update --deep --newuse), and then do an "emerge -uDNK world" on the legacy box. Don't forget the K flag (--usepkgonly), so you only emerge from the packages you prebuilt.
Appendix
-- Please be sure to let me know in this thread if this works for you, or if you have any suggestions, or if you need help on anything.
Updates:
4/7/04: Revised the instructions to note when the local rsync mirror can be set up, so people don't have to break the rules by emerge --sync'ing twice at the same time.
Last edited by Sheepdogj15 on Thu Apr 07, 2005 8:41 pm; edited 1 time in total |
|
| Back to top |
|
 |
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Thu Apr 07, 2005 8:39 pm Post subject: |
|
|
i just added a quick update. i moved the recommendation on when to rsync up to 3h or sooner, that way the Howto isn't advising anyone to break portage netiquette.
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Tue Apr 12, 2005 6:26 am Post subject: |
|
|
| Awesome job Sheepdogj1! I think you did a pretty good job of summing up what we have here: https://forums.gentoo.org/viewtopic-t-316033-highlight-.html and adding to it. I'm linking to the older thread in case someone needs information about getting the older laptop off the ground. |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Tue Apr 12, 2005 6:54 am Post subject: |
|
|
thank you
i figured i found a way to get an old computer running quickly, and decided to share in case others find it useful.
wasn't Golgo 13 an old NES game?
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Tue Apr 12, 2005 7:04 pm Post subject: |
|
|
| Actually yes, but the game was an adaption of a comic book / anime character. |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
|
| Back to top |
|
|
palatin
Tux's lil' helper
Joined: 20 Oct 2004
Posts: 113
Location: Paris
|
| Posted: Wed Apr 13, 2005 7:09 am Post subject: |
|
|
I did something a bit like this some time ago. Unfortunately, I didn't have the legacy computer anywhere near. The trick was to tar the fake install instead of building pre-compiled packages.
In order to setup the legacy computer, I just had to boot on a livecd, detar the setup and adapt a few files (resolv.conf, fstab...).
Correct me if I am wrong, I suspect the 2 CPUs should have somewhat a few compatibilities in their set of instructions, unless you set generic compilation flags : you can't possibly produce optimised compilation for your legacy computer (say AMD K6) if your fast computer can't handle the march=k6 flag. Anyway, I doubt it's a critical problem with old hardware.
_________________
fumo~ |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Wed Apr 13, 2005 8:49 am Post subject: |
|
|
that's probably true enough. i didn't have optimization in mind here. my own legacy computer is a Cyrix PR200, so optimization pretty much involved using march=i686 and a few extras... which my other computer seems to have done well with it, so far.
(i don't think you are going to get break neck speeds from dated hardware anyways, so IMHO it is probably moot. though, i can see the justification if you have specific use for the old computer)
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
Mark_
n00b
Joined: 11 Apr 2005
Posts: 4
|
| Posted: Wed Apr 13, 2005 10:00 am Post subject: |
|
|
| I did this the easy way... I put the old computer's hard drive into the new computer and targetted the install and kernel to the older platform. Once the install finished I just put the hard drive back in the other computer. Took me a few hours (AXP1700) vs a few days (Celeron300). |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Wed Apr 13, 2005 4:56 pm Post subject: |
|
|
| Mark_, you could do this, but it's more difficult when we're talking about a laptop and a desktop. Yes, generic compile flags are a must. As long as there's an Internet connection nfs instead of tar is a viable solution. The link to another thread has a link to some pretty useful floppy disks that allow for Internet connections and nfs shares. |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Wed Apr 13, 2005 9:14 pm Post subject: |
|
|
| Mark_ wrote: | | I did this the easy way... I put the old computer's hard drive into the new computer and targetted the install and kernel to the older platform. Once the install finished I just put the hard drive back in the other computer. Took me a few hours (AXP1700) vs a few days (Celeron300). |
dang, why didn't i think of that?
as Golgo pointed out, this won't work for everyone. plus the NFS method is good for updates (which will be important for me, since the old computer will hopefully be a router when i'm done, and i really want to make sure updates don't take longer than overnight.)
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Wed Apr 13, 2005 9:51 pm Post subject: |
|
|
Sheepdogj15, I have a different idea for updates. If it's a live, working system why not try rsync? Someone with more experienced than me would know if rsync is good for this or not.
Last edited by golgo13 on Thu Apr 14, 2005 4:13 am; edited 1 time in total |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Wed Apr 13, 2005 11:18 pm Post subject: |
|
|
my understanding is that rsync deals with keeping one's portage tree up to date, not in the packaging of apps in and of itself. it would still rely on your system to do the compiling, which means a lot of time with an old computer.
however, i have heard of services out there which provide you precompiled packages for Gentoo. i have not taken the time to check that out, personally.
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Thu Apr 14, 2005 3:03 am Post subject: |
|
|
I meant that you chroot and update a whole system then rsync it over to the older, slower computer. rsync isn't just for portage, portage is actually using rsync. From freshmeat: | Quote: | | rsync is a replacement for rcp (and scp) that has many more features. It uses the "rsync algorithm" which provides a very fast method for remote files into sync. It does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand. |
|
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Thu Apr 14, 2005 3:35 am Post subject: |
|
|
hmm, i did not know that.
i don't know very much about rsync, but if configured right it sounds like it would work. most people have 100Mb ethernet. even those that don't, if it only tranfers files that change then it sounds reasonable.
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Thu Apr 14, 2005 4:02 am Post subject: |
|
|
On the other hand, rsync does tend to eat a lot of RAM and CPU cycles even on the client side, so it may be suboptimal compared to NFS...
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Thu Apr 14, 2005 4:05 am Post subject: |
|
|
something like this would work from the command line on the old laptop: | Code: |
rsync --verbose --progress --stats --compress --rsh=/usr/bin/ssh \
--recursive --times --perms --links --delete \
--exclude "*bak" --exclude "*~" \
/* 192.168.XXX:/home/user/nameOfFolderToSyncWithRoot |
I just don't know if it's safe to rsync everything from / on up. If anyone knows please post. |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Thu Apr 14, 2005 4:07 am Post subject: |
|
|
/dev may cause some trouble. I assume rsync is smart enough to recreate device nodes, but recreating them on the client side may be undesirable when using udev, for example.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Thu Apr 14, 2005 4:10 am Post subject: |
|
|
| so maybe adding an would work? |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Thu Apr 14, 2005 4:17 am Post subject: |
|
|
Well, yes, but that would assume that udev / devfsd will create any and all required device nodes on the client side, which at least in my case never actually happened (there seem to be some nodes that need to be created statically). It's somewhat of a catch-22 situation. But it's worth giving it a shot without skipping /dev, as long as /etc/conf.d/rc on the client side has RC_DEVICE_TARBALL set to "yes".
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Thu Apr 14, 2005 4:32 am Post subject: |
|
|
| I can't say that I understand. I'm pretty new to all this myself. Are you saying that after everything is installed and I'm trying to update the system rsync might have problems with udev / devfsd ? |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Thu Apr 14, 2005 4:36 am Post subject: |
|
|
May being the keyword. And it's unlikely it will cause major problems. The way I see it, if you let rsync copy over the device nodes from the remote system, it will try to create them in /dev on the client, unliking the nodes udev / devfsd create on the fly and creating real nodes on the file system. How this would actually affect the system I'm not sure since I currently don't have a throwaway system around (the playground machine is hard at work) - but it's something worth considering, I think.
Nothing that would break stuff badly though. Someone could conceivably just test your method, including /dev, and see what happens .
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
golgo13
Apprentice
Joined: 24 Nov 2004
Posts: 158
|
| Posted: Thu Apr 14, 2005 4:49 am Post subject: |
|
|
| I've already tried this and I did get a few errors but everything seemed to work out fine... that is until my pcmcia card slots stopped working. I pulled the hard drive and put it in another laptop and everything worked fine there so I'm pretty sure it's the pcmcia slots and not the multiple rsync sessions that did it. I'm actually going to build up another system from scratch and see if the slots work again. Then I'll know for sure. |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Thu Apr 14, 2005 4:55 am Post subject: |
|
|
hmm... next weekend i should have some spare time (not this weekend, the other one after that). i'll play with it, and maybe incorporate it into the Howto if it works well.
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
Sheepdogj15
Guru
Joined: 07 Jan 2005
Posts: 430
Location: Backyard
|
| Posted: Wed Apr 20, 2005 3:15 am Post subject: |
|
|
hey Golgo. would the rsync method require the server side to be configured a special way?
[edit] Nevermind. i figured it out.
now, to test this puppy out....
_________________
Sheepdog
Why Risk It? | Samba Howto |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
