In this article, we are looking at SSHFS, the Secure Shell Filesystem. We can use it to mount a remote filesystem using the SSH Protocol. So the information flowing between the two systems is completely encrypted. SSHFS is a client based application, so beside the SSH server, there is nothing to installed on the remote server to use it. FUSE is a linux kernel module that allow non-privilege user to mount their own filesystem without the help of any kernel code. One of the interesting feature of SSHFS is that you can securely mount a filesystem over the internet, this is impossible with Samba and not very secure with NFS. If you like more information on SSHFS, you can visit the SSHFS homepage and the Wiki of the SSHFS package. There is also a YouTube video that show how to use SSHFS on a Fedora system. For those interested in a windows version of sshfs, there is a free version available at the Dokan site, you need to install the Dokan Library first, then install SSHFS. I have done some simple test with it and I didn’t had any problem.
Installing fuse and fuse-sshfs
FUSE and FUSE-SSHFS use the ssh protocol, so SSH needs to be installed on our client system. The only required package on the remote system, is “openssh” (may work with other version of ssh). The package FUSE and FUSE-SSHFS don’t need to be install on the remote system, only on the local server. The first thing we need to do is to get the latest version the “fuse” at this page and “fuse-sshfs” packages from this page and install them on our local system. The package “fuse” is now part of the RedHat/Centos 5.4, but you still need to get “fuse-sshfs” cause it isn’t included. Should the other site be unresponsive, you can download the rpm from Linternux site.
# ls -l
total 296
-rw-rw-r-- 1 jacques jacques 255149 Sep 6 13:15 fuse-2.7.3-1.el5.rf.i386.rpm
-rw-rw-r-- 1 jacques jacques 43203 Sep 6 13:15 fuse-sshfs-1.9-1.el5.rf.i386.rpm
# rpm -ivh fuse*
warning: fuse-2.7.3-1.el5.rf.i386.rpm: Header V3 DSA signature: NOKEY, key ID 6b8d79e6
Preparing... ########################################### [100%]
1:fuse ########################################### [ 50%]
2:fuse-sshfs ########################################### [100%]
#
As a system administrator, we must ensure that time synchronization is working at all time. Time synchronization have been proven to be helpful when we try to trace a chain of events that occurs on multiple servers or when trying to synchronize time sensitive-transactions. In this article, we will setup one NTP (Network Time Protocol) server running on RedHat/Centos 5, but it could be applied to the major Linux distribution. As always, I have tried to make the article to be used a reference source, so that we can come back when ever you will play with the NTP tools.
The configuration have been done on my Linux server at home (gumby – 192.168.1.101). We will setup a NTP that will synchronize with NTP servers on the internet and it will answer NTP query on my internal network (192.168.1.0/24). This will allow desktop or laptop to synchronize with this NTP server.
Brief history of NTP
The NTP protocol was born on the Unix operating system around the 1980′s and have been initiated by Dave L. Mills. Currently there are two versions of NTP that can be used intermixed, the version 3 is very stable and it run on a number of operating systems. The version 4 have some enhancements and better support for the latest operating systems. There is also a simplified version of NTP called SNTP (Simple Network Time Protocol RFC2030), but it provides a reduced precision due to a simpler algorithms. Some earlier version of NTP included some programs starting with xntp (like xntpd), with version 4 the naming convention were changed and now all the ntp programs included with package, start with ntp. For more information you can consult the NTP home page.
Functionality overview
NTP use a hierarchical time synchronization structure. The hierarchical level of the time synchronization are called stratum. At the top of this hierarchy, there is a daemon that provide the most accuracy. Atomic clock are stratum zero, it is by far the most accurate method of keeping time with a precision of less than a second lost every 100 million years. All NTP time server devices are referred to as stratum 1 devices. This is because they are on the next level (strata) down from an atomic clock (a stratum 0 device). Devices that a NTP time server synchronises are known as stratum 2 devices and these too can distribute their time signal to other devices which become stratum 3 and so on.
In large organization, they should be at least one or two NTP servers that synchronize with time server on the internet NTP servers (probably located in the DMZ). Some NTP servers located in the corporate network, could then synchronize their time with the NTP servers located in the DMZ and be used as corporate NTP servers. This will ensure that all the clients have the same date and time. Before continuing, I would like to state that the NTP protocol use UDP port 123. To be able to synchronize with its trusted time servers and to respond to client query the firewall configuration must allow UDP traffic to destination port 123.
Read more…
Checking our network card current setting
There are two commands that we can use to check our current network card setting. The first command is “mii-tool”, it has been around almost since the beginning of Linux and will be depreciated in the future version of Linux. If we don’t specify any parameter to the “mii-tool” command, we will get one line of information per network card. It will display the current speed of the network card, the duplex mode it’s using and if you have a link or not. If we don’t have a link up (no link) and it is suppose to be, I suggest to verify that your cable is connected to the server and that the port on the network switch is activate. If this is the case, you may want to try another network cable and see if the link come up.
# mii-tool
eth0: 100 Mbit, full duplex, link ok
eth1: 100 Mbit, full duplex, no link
#
If we add the verbose parameter (-v), we will get some additional information about each network card.
# mii-tool -v
eth0: 100 Mbit, full duplex, link ok
product info: vendor 00:aa:00, model 50 rev 0
basic mode: 100 Mbit, full duplex
basic status: link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
eth1: 100 Mbit, full duplex, no link
product info: vendor 00:10:18, model 23 rev 6
basic mode: 100 Mbit, full duplex
basic status: no link
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
#
I would suggest using the “ethtool” command instead of the depreciated “mii-tool”. The “mii-tool” may not work with some of the newer network card and may be excluded from future version of RedHat/Centos/Fedora. With the “ethtool” command, we need to specify the name of the interface that we want to see the current state. In all of our example, we will use the interface “eth0″.
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
#
Recent Comments