Rsync is a fast and extraordinarily versatile file copying tool. It can copy locally, to/from another host over any remote shell, or to/from a remote rsync daemon. It offers a large number of options that control every aspect of its behavior and permit very flexible specification of the set of files to be copied. It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination. Rsync is widely used for backups and mirroring and as an improved copy command for everyday use.
Rsync finds files that need to be transferred using a lqquick checkrq algorithm (by default) that looks for files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as requested by options) are made on the destination file directly when the quick check indicates that the file’s data does not need to be updated.
While tar over ssh is ideal for making remote copies of parts of a filesystem, rsync is even better suited for keeping the filesystem in sync between two machines. Typically, tar is used for the initial copy, and rsync is used to pick up whatever has changed since the last copy. This is because tar tends to be faster than rsync when none of the destination files exist, but rsync is much faster than tar when there are only a few differences between the two filesystems.
To run an rsync over ssh, pass it the -e switch, like this:
Notice the trailing / on the file spec from the source side On the source specification, a trailing / tells rsync to copy the contents of the directory, but not the directory itself. To include the directory as the top level of whatever is being copied, leave off the /:
By default, rsync will only copy files and directories, but not remove them from the destination copy when they are removed from the source. To keep the copies exact, include the — delete flag:
If you run a command like this in cron, leave off the v switch. This will keep the output quiet (unless rsync has a problem running, in which case you’ll receive an email with the error output).
Using ssh as your transport for rsync traffic has the advantage of encrypting the data over the network and also takes advantage of any trust relationships you already have established using ssh client keys. For keeping large, complex directory structures in sync between two machines (especially when there are only a few differences between them), rsync is a very handy (and fast) tool to have at your disposal.
A patch fixes the frequent freezing at the Bay Trail has become known low-cost processors, the Celeron series on Linux. The SoCs are installed in cheap notebooks and other cheap hardware.
Bay Trail SoCs are known to be critical in Linux. This ranges from installation problems to crashes every minute. Intel knows the problem. It stands in an errata under the abbreviation VLP52 and is classified as No Fix , so Intel does not fix it .
Affected by the freeze, which usually occurs a few minutes after booting the system, are SoCs such as J1900, Celeron N2840, Celeron N2940, Atom Z3736F and Pentium N3540. The error that caused the crash was initially suspected in the GPU, but then localized in the power management of the chip and is described in a Bugzilla bug report. The problems only occur with many users if a graphical user interface is used.
The problem occurs when the system enters sleep mode C-State 6 (C6) after an interrupt service routine (ISR) is started but before it is terminated and the program continues at the interrupted location. A previously used workaround was to set the processor to C state 1 by passing the intel_idle.max_cstate = 1 parameter to the kernel . However, this leads to increased energy consumption and thus to shorter battery life.
The patch from Wolfgang M. Reimer disables only the C-States 6 and activates the C7-Core-States at the same time . This preserves the energy-saving options. The workaround introduced in mid-July was tested by many users and showed almost all the convincing results. However, some users also report that the problems with kernel 4.7 no longer occur even without the patch on their hardware.
patch (c6off+c7on.sh):
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#!/bin/sh
#title: c6off+c7on.sh
#description: Disables all C6 and enables all C7 core states for Baytrail CPUs
#author: Wolfgang Reimer <linuxball (at) gmail.com>
#date: 2016014
#version: 1.0
#usage: sudo <path>/c6off+c7on.sh
#notes: Intended as test script to verify whether erratum VLP52 (see
# [1]) is the root cause for kernel bug 109051 (see [2]). In order
# for this to work you must _NOT_ use boot parameter
SSH is the most popular and secure method for managing Linux servers remotely. One of the challenges with remote server management is connection speeds, especially when it comes to session creation between the remote and local machines.
There are several bottlenecks to this process, one scenario is when you are connecting to a remote server for the first time; it normally takes a few seconds to establish a session. However, when you try to start multiple connections in succession, this causes an overhead (combination of excess or indirect computation time, memory, bandwidth, or other related resources to carry out the operation).
In this article, we will share four useful tips on how to speed up remote SSH connections in Linux.
1.Use Compression option in SSH
From the ssh man page (type man ssh to see the whole thing):
1
2
3
4
5
6
7
8
-CRequests compression of all data(including stdin,stdout,
compression algorithm isthe same used by gzip(1),andthe
“level”can be controlled by the CompressionLevel option forpro-
tocol version1.Compression isdesirable on modem lines and
other slow connections,but will only slow down things on fast
networks.The defaultvalue can be set onahost-by-host basis
inthe configuration files;see the Compression option.
1
ssh-Cusername@example.com
2.Force SSH Connection Over IPV4
OpenSSH supports both IPv4/IP6, but at times IPv6 connections tend to be slower. So you can consider forcing ssh connections over IPv4 only, using the syntax below:
1
# ssh -4 username@example.com
Alternatively, use the AddressFamily (specifies the address family to use when connecting) directive in your ssh configuration file (global configuration) or ~/.ssh/config (user specific file).
The accepted values are “any”, “inet” for IPv4 only, or “inet6”.
AddressFamily inet
3. Reuse SSH Connection
An ssh client program is used to establish connections to an sshd daemon accepting remote connections. You can reuse an already-established connection when creating a new ssh session and this can significantly speed up subsequent sessions.
You can enable this in your ~/.ssh/config file.
ControlMaster auto ControlPath /home/akhil/.ssh/sockets/ssh_mux_%x_%p_%r ControlPersist yes
openssh doesn’t support %x(ip address in control paths), use my repo instead
using ip address is recommended so that even if you connect using different hostnames it uses same socket ( very useful when using ansible , pdsh )
4. Use Specific SSH Authentication Method
Another way of speeding up ssh connections is to use a given authentication method for all ssh connections, and here we recommend configuring ssh passwordless login using ssh keygen in 5 easy steps.
Once that is done, use the PreferredAuthentications directive, within ssh_config files (global or user specific) above. This directive defines the order in which the client should try authentication methods (you can specify a command separated list to use more than one method).
PreferredAuthentications=publickey
If you prefer password authentication which is deemed unsecure, use this.
By default, sshd daemon looks up the remote host name, and also checks that the resolved host name for the remote IP address maps back to the very same IP address. This can result into delays in connection establishment or session creation.
The UseDNS directive controls the above functionality; to disable it, search and uncomment it in the /etc/ssh/sshd_config file. If it’s not set, add it with the value no.
ELK stack is also known as the Elastic stack, consists of Elasticsearch, Logstash, and Kibana. It helps you to have all of your logs stored in one place and analyze the issues by correlating the events at a particular time.
Sentinl – Sentinl extends Siren Investigate and Kibana with Alerting and Reporting functionality to monitor, notify and report on data series changes using standard queries, programmable validators and a variety of configurable actions – Think of it as a free an independent “Watcher” which also has scheduled “Reporting” capabilities (PNG/PDFs snapshots).
SENTINL is also designed to simplify the process of creating and managing alerts and reports in Siren Investigate/Kibana 6.xvia its native App Interface, or by using native watcher tools in Kibana 6.x+.
Beats – Installed on client machines, send logs to Logstash through beats protocol.
Environment
To have a full-featured ELK stack, we would need two machines to test the collection of logs.
ELK Stack
1
2
3
Operating system:CentOS7Minimal
IP Address:192.168.1.10
HostName:server.lintel.local
Filebeat
1
2
3
Operating System:CentOS7Minimal
IP Address:192.168.1.20
HostName:client.lintel.local
Prerequisites
Install Java
Since Elasticsearch is based on Java, make sure you have either OpenJDK or Oracle JDK is installed on your machine.
Elasticsearch is an open source search engine, offers a real-time distributed search and analytics with the RESTful web interface. Elasticsearch stores all the data are sent by the Logstash and displays through the web interface (Kibana) on users request.
Install Elasticsearch.
1
yum install-yelasticsearch
Configure Elasticsearch to start during system startup.
1
2
3
systemctl daemon-reload
systemctl enable elasticsearch
systemctl start elasticsearch
Use CURL to check whether the Elasticsearch is responding to the queries or not.
1
curl-XGET http://localhost:9200
Output:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
"name":"1DwGO86",
"cluster_name":"elasticsearch",
"cluster_uuid":"xboS_6K5Q2OO1XA-QJ9GIQ",
"version":{
"number":"6.4.0",
"build_flavor":"default",
"build_type":"rpm",
"build_hash":"595516e",
"build_date":"2018-08-17T23:18:47.308994Z",
"build_snapshot":false,
"lucene_version":"7.4.0",
"minimum_wire_compatibility_version":"5.6.0",
"minimum_index_compatibility_version":"5.0.0"
},
"tagline":"You Know, for Search"
}
Install Logstash
Logstash is an open source tool for managing events and logs, it collects the logs, parse them and store them on Elasticsearch for searching. Over 160+ plugins are available for Logstash which provides the capability of processing the different type of events with no extra work.
Install the Logstash package.
1
yum-yinstall logstash
Create SSL certificate (Optional)
Filebeat (Logstash Forwarder) are normally installed on client servers, and they use SSL certificate to validate the identity of Logstash server for secure communication.
Create SSL certificate either with the hostname or IP SAN.
(Hostname FQDN)
If you use the Logstash server hostname in the beats (forwarder) configuration, make sure you have A record for Logstash server and also ensure that client machine can resolve the hostname of the Logstash server.
Go to the OpenSSL directory.
1
cd/etc/pki/tls/
Now, create the SSL certificate. Replace green one with the hostname of your real Logstash server.
Logstash configuration can be found in /etc/logstash/conf.d/. Logstash configuration file consists of three sections input, filter, and the output. All three sections can be found either in a single file or separate files end with .conf.
I recommend you to use a single file for placing input, filter and output sections.
1
vi/etc/logstash/conf.d/logstash.conf
In the first section, we will put an entry for input configuration. The following configuration sets Logstash to listen on port 5044 for incoming logs from the beats (forwarder) that sit on client machines.
Also, add the SSL certificate details in the input section for secure communication – Optional.
1
2
3
4
5
6
7
8
9
10
11
12
input{
beats{
port=>5044
# Set to False if you do not use SSL
ssl=>true
<strong># Delete below linesif you do not use SSL</strong>
In the filter section. We will use Grok to parse the logs ahead of sending it to Elasticsearch. The following grok filter will look for the syslog labeled logs and tries to parse them to make a structured index.
1
2
3
4
5
6
7
8
9
10
11
12
filter{
if[type]=="syslog"{
grok{
match=>{"message"=>"%{SYSLOGLINE}"}
}
date{
match=>["timestamp","MMM d HH:mm:ss","MMM dd HH:mm:ss"]
}
}
}
For more filter patterns, take a look at grokdebugger page.
In the output section, we will define the location where the logs to get stored; obviously, it should be Elasticsearch.
1
2
3
4
5
6
7
8
9
output{
elasticsearch{
hosts=>localhost
index=>"%{[@metadata][beat]}-%{+YYYY.MM.dd}"
}
stdout{
codec=>rubydebug
}
}
Now start and enable the Logstash service.
1
2
systemctl start logstash
systemctl enable logstash
You can troubleshoot any issues by looking at Logstash logs.
1
cat/var/log/logstash/logstash-plain.log
Install & Configure Kibana
Kibana provides visualization of logs stored on the Elasticsearch. Install the Kibana using the following command.
By default, Kibana listens on localhost which means you can not access Kibana interface from external machines. To allow it, edit the below line with your machine IP.
1
server.host:"<strong>192.168.1.10</strong>"
Uncomment the following line and update it with the Elasticsearch instance URL. In my case, it is localhost.
Now, install Filebeat using the following command.
1
yum-yinstall filebeat
Set up a host entry on the client machine in case your environment does not have DNS server.
1
vi/etc/hosts
Make an host entry like below on the client machine.
1
192.168.1.10server.lintel.local server
Filebeat (beats) uses SSL certificate for validating Logstash server identity, so copy the logstash-forwarder.crt from the Logstash server to the client.
Skip this step, in case you are not using SSL in Logstash.
Filebeat configuration file is in YAML format, which means indentation is very important. Make sure you use the same number of spaces used in the guide.
Open up the filebeat configuration file.
1
vi/etc/filebeat/filebeat.yml
On top, you would see the prospectors section. Here, you need to specify which logs should be sent to Logstash and how they should be handled. Each prospector starts with – character.
For testing purpose, we will configure filebeat to send /var/log/messages to Logstash server. To do that, modify the existing prospector under paths section.
Comment out the – /var/log/*.log to avoid sending all .log files present in that directory to Logstash.
1
2
3
4
5
6
7
8
9
10
11
12
13
filebeat.inputs:
-type:<strong>log</strong>
<strong># Change to true to enable this input configuration.</strong>
enabled:<strong>true</strong>
<strong># Paths that should be crawled and fetched.</strong>
paths:
<strong>-/var/log/messages
</strong># - /var/log/*.log
...
Comment out the section output.elasticsearch: as we are not going to store logs directly to Elasticsearch.
Now, find the line output.logstash and modify the entries like below. This section defines filebeat to send logs to Logstash server server.lintel.local on port 5044 and mention the path where the copied SSL certificate is placed
Replace server.lintel.local with IP address in case if you are using IP SAN.
