Login
Menu

Daily ArchivesAugust 24, 2014

Home / Blog

Rsync

rsync is a file synchronization and file transfer program for Unix-like systems that minimizes network data transfer by using a form ofdelta encoding called the rsync algorithm. rsync can compress the data transferred further using zlib compression, and SSH orstunnel can be used to encrypt the transfer.

rsync is typically used to synchronize files and directories between two different systems, one local and one remote. For example, if the command rsync local-file user@remote-host:remote-file is run, rsync will use SSH to connect as user to remote-host.[4] Once connected, it will invoke another copy of rsync on the remote host, and then the two programs will talk to each other over the connection, working together to determine what parts of the file are already on the remote host and don’t need to be transferred over the connection.

rsync can also operate in daemon mode, where it listens by default on TCP port 873, serving files in the native rsync protocol (using the “rsync://” syntax).

It is released under the GNU General Public License version 3 and is widely used.

Uses

rsync originated as a replacement for rcp and scp. As such, it has a similar syntax to its parent programs.[11] Like its predecessors, it requires the specification of a source and of a destination; either of them may be remote, but not both. Because of the flexibility, speed and scriptability of rsync, it has become a standard Linux utility, included in all popular Linux distributions. It has been ported to Windows (via Cygwin, Grsync or SFU) and Mac OS.

Generic syntax:

rsync [OPTION] … SRC [SRC] … [USER@]HOST:DEST
rsync [OPTION] … [USER@]HOST:SRC [DEST]

…where SRC is the file or directory (or a list of multiple files and directories) to copy from, and DEST represents the file or directory to copy to. (Square brackets indicate optional parameters.)

rsync can synchronize Unix clients to a central Unix server using rsync/ssh and standard Unix accounts. It can be used in desktop environments, for example to efficiently synchronize files with a backup copy on an external hard drive. A scheduling utility such as cron can carry out tasks such as automated encrypted rsync-based mirroring between multiple hosts and a central server.

Examples

A command line to mirror FreeBSD might look like:

 % rsync -avz --delete ftp4.de.FreeBSD.org::FreeBSD/ /pub/FreeBSD/

The Apache HTTP Server supports only rsync for updating mirrors.

rsync -avz --delete --safe-links rsync.apache.org::apache-dist /path/to/mirror

The preferred (and simplest) way to mirror the PuTTY website to the current directory is to use rsync.

rsync -auH rsync://rsync.chiark.greenend.org.uk/ftp/users/sgtatham/putty-website-mirror/ .[15]

A way to mimic the capabilities of Time Machine (Mac OS) – see also tym.

#date=`date "+%Y-%m-%dT%H:%M:%S"`
date=`date "+%FT%T"`
rsync -aP --link-dest=$HOME/Backups/current /path/to/important_files $HOME/Backups/back-$date
ln -nfs $HOME/Backups/back-$date $HOME/Backups/current

Shadow Password

Shadow Passwords

In environments with multiple users, it is very important to use shadow passwords provided by the shadow-utils package to enhance the security of system authentication files. For this reason, the installation program enables shadow passwords by default.
The following is a list of the advantages shadow passwords have over the traditional way of storing passwords on UNIX-based systems:
  • Shadow passwords improve system security by moving encrypted password hashes from the world-readable /etc/passwd file to /etc/shadow, which is readable only by the root user.
  • Shadow passwords store information about password aging.
  • Shadow passwords allow the /etc/login.defs file to enforce security policies.
Most utilities provided by the shadow-utils package work properly whether or not shadow passwords are enabled. However, since password aging information is stored exclusively in the /etc/shadow file, any commands which create or modify password aging information do not work. The following is a list of utilities and commands that do not work without first enabling shadow passwords:
  • The chage utility.
  • The gpasswd utility.
  • The usermod command with the -e or -f option.
  • The useradd command with the -e or -f option.

User And Group Management

 Introduction to Users and Groups

While users can be either people (meaning accounts tied to physical users) or accounts which exist for specific applications to use, groups are logical expressions of organization, tying users together for a common purpose. Users within a group can read, write, or execute files owned by that group.
Each user is associated with a unique numerical identification number called a user ID (UID). Likewise, each group is associated with a group ID (GID). A user who creates a file is also the owner and group owner of that file. The file is assigned separate read, write, and execute permissions for the owner, the group, and everyone else. The file owner can be changed only by root, and access permissions can be changed by both the root user and file owner.
Additionally, Red Hat Enterprise Linux supports access control lists (ACLs) for files and directories which allow permissions for specific users outside of the owner to be set. For more information about this feature, refer to the Access Control Lists chapter of the Storage Administration Guide.

User Private Groups

Red Hat Enterprise Linux uses a user private group (UPG) scheme, which makes UNIX groups easier to manage. A user private group is created whenever a new user is added to the system. It has the same name as the user for which it was created and that user is the only member of the user private group.
User private groups make it safe to set default permissions for a newly created file or directory, allowing both the user and the group of that user to make modifications to the file or directory.
The setting which determines what permissions are applied to a newly created file or directory is called a umask and is configured in the /etc/bashrc file. Traditionally on UNIX systems, the umask is set to 022, which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, including members of the creator’s group, are not allowed to make any modifications. However, under the UPG scheme, this “group protection” is not necessary since every user has their own private group.