All I've got round to in the world of networking computers is the two-box senario!
I use a patch Cat6 cable which I happened to buy in the store and connect this to the LAN ports of my DT and laptop - and they can see each other with it.
Cross-over cable?
It's not at all necessary to find a "cross-over" cable these days (which wires the send to receive and receive to send) as modern Ethernet adapters have the MDI/MDIX function which can detect the send/receive wires. see here
http://askubuntu.com/questions/59906/... http://forums.speedguide.net/...
Sharing the internet connection from one box to another
If you use that pesty firestarter, you'll need to configure it slightly! (if not remove it becaue its obsolute now
On the internet-able box, A:
--->Network settings: Local network connected device: Ethernet eth0
----->check enable internet sharing
----->uncheck the DHCP
On the shared-to box, B: turn off the firewall
Then it's easy as using Network Manager (or Wicd, which I think is better)..
- box A: make a new wired connection and in Edit > IPv4 select "Shared to other computers"
- plugin the patch cable on both
- box B: select the wired connection and Edit > IPv4 select "Automatic (DHCP)"
And you might need to stop firewall (in firestarter) and restart it after box B is connected to box A!
Sharing files with nfs
Nfs is a fast networking agent that uses less resources and could give faster data transfer rates than samba (so I hear). It's also easy to configure.
first install what you need with
sudo apt install nfs-kernel-server nfs-common
First of all, each box will need new wired connections made, and using Network manager is pretty easy.
- box A - IPv4 - select manual and add new: address 10.0.0.1, netmask 255.255.255.0, gateway leave blank
- box B - IPv4 - select manual and add new: address 10.0.0.2, netmask 255.255.255.0, gateway leave blank
This case, box A is the server and B is the client that will access files on A. (use 192.168.0.x if you like)
For the connection to work I had to disconnect A from the internet, and at times, stop firestarter until B could mount the files on A.
Test that B is connected to A with
ping 10.0.0.2
and you should start getting replies if connected
Now box A, the server, must export those directories that it will share with its clients - specifying directories, clients who can access what and with what restrictions.
this is done by adding a line for each file system to export in box A's /etc/exports file, e.g.
/home/jim 10.0.0.2(rw,sync,no_subtree_check)
/media/pics 10.0.0.2(rw,sync,no_subtree_check)
So box A will share /home/jim and /media/pics with the client of IP address 10.0.0.2, with read-write permissions and some other options.
No spaces allowed between the client IP and (rw) !
After those lines have been made and eye-balled for accuracy, nfs is started (or restarted if those export lines were changed) with:
sudo /etc/init.d/nfs-kernel-server restart
then on the client box, B, you must mount the exported directories from the server - either all together or any individually, like
sudo mount 10.0.0.1:/ ~/Shared
or
sudo mount host-name:/ ~/Shared
will mount all exported dir's here
this will mount only exported /home/jim
sudo mount 10.0.0.1:/home/jim ~/Shared
After that, if the mount was successful (watch out for firestarter) you can browse and copy over files with total ease.
Male sure to unmount the shares before disconnecting the network! In my case, when the network was disconnected before unmount 10.0.0.1:/ was issued, ranger froze itself.
Other options in /etc/export
squash_root - this prevents a client having root access on server (this is default)
no_squash_root allows root permissions to a client, eg for backing-up of root files
fstab entries
to make these server exports permanent every time the box is turned on, they need entries in /etc/fstab, like
10.0.0.1:/home/jim ~/Shared/jim nfs rw 0 0
10.0.0.1:/media/pics ~/Shared/jim-pics nfs rw 0 0
then, if you mount 10.0.0.1:/ the mount point will be used from fstab, along with options - unless options are given on the command line which can over-ride those in fstab.
mount 10.0.0.1:/
mount 10.0.0.1:/ -o ro
overrides the rw option in fstab
exporting symlinks?
if a file system with links is exported, but the file system containing the target files of those links is not, then the client will see the links but will not be able to navigate to the referred directories and files!
Then those links will be relevant to (point to files on) the client's file system, unless the files system with referred files was exported.
It would be nice to symlink lots of directories on the server box into a single exported location, but all the links become useless without their referred files exported as well, and may even cause confusion if the client has similar files that the links will point to!
nfs through a firewall
as nfs creates random ports it is hard for a firewall to allow the right ones - until they are made static.
see my page on firewall