Note: Cisco only supports Red Hat and Ubuntu Linux distributions.
Step 1
Download the.gzinstall archive to the desktop.
Step 2
Extract the archive to the desktop of Ubuntu in the following folderanyconnect-linux64-…
Note:In the fileanyconnect-linux64-4.6.01103,the numbers after the dash are the version number (e.g., 4.6.01103) and will change as ITS updates the AnyConnect software package.
Step 3
Open a terminal window and navigate to the extracted folder in the terminal—for example,cd ~/Desktop/anyconnect-linux64-4.7.0.036/vpn
Step 4
Typesudo sh vpn_install.sh
Step 5
When prompted enter your root password then hit Return.
Step 6
Hit return and typeythen hitReturnagain. The installation should now start and walk you through the setup.
Any connect should now be installed and ready to use.
In
this tutorial we’ll cover the steps to install xRDP on your remote
CentOS 7 machine, and how to connect to it via Remote Desktop
Connection. We’ll also show you how to install and connect to different
Desktop Environments on your remote CentOS 7 machine.
xRDP is a a
free and open source Remote Desktop Protocol Server that allows other
operating systems, other than Windows, to provide a fully functional
remote desktop experience.
xRDP is fully compatible with rdesktop, FreeRDP and even Microsoft’s Remote Desktop Client.
Take
your pick from our KVM VPS that offer a generous amount of RAM at an
affordable price. We've got 5 plans for you to choose from, our smallest
featuring 2GB RAM at $6.99/mo.
Step 2 – Install Your Preferred Desktop Environment
Now we can install the desktop environment we’ll be using. In this guide we’ll try out XFCE, MATE, and GNOME.
If you’re looking for a lightweight and resource friendly solution, install XFCE.
NOTE: If you can’t connect via Remote Desktop Connection after you’ve installed the desktop environment, then open port 3389/tcp using the firewall-cmd command mentioned above.
1. Install XFCE Desktop Environment
XFCE
is one of the most lightweight desktop environments. It’s fast, low on
system resources, while still visually appealing. Additionally, it has a
very active community, so there are many customization options
available.
To do this, we’ll just have to install the GNOME Desktop package group, which will install all the packages required for the GUI installation.
$ sudo yum groupinstall "GNOME DESKTOP" -y
This may take a while. There were ~1000 packages installed on a minimal CentOS 7 installation.
Start the GUI
Although we installed the GNOME Desktop package group, the GUI will not be loaded by default on reboot.
We can check this by running:
$ systemctl get-default
Output:
multi-user.target
If our default target is multi-user.target, it means that the GUI will not be loaded. What we want is to set the default target to graphical.target.
To do this, run the following commands:
$ sudo systemctl set-default graphical.target
Output:
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target.
After which, run the following command to change to the GUI immediately:
$ sudo systemctl isolate graphical.target
That’s it. You can now connect via xRDP to your CentOS 7 machine using GNOME.
Here
is what GNOME 3 looks like, the first time you connect after
installing. Just follow the initial configuration steps to finish
setting up.
Uninstalling GNOME
To uninstall GNOME from your CentOS 7 machine, run the following commands:
Step 3 – Connect to Your Machine Using Remote Desktop Connection
With xRDP and your desktop environment installed, you can now connect from your local machine to the remote machine.
How you do this depends on your operating system.
Connect from Windows
To
connect to your server from Microsoft Windows, just search and launch
the Remote Desktop Connection application and input your hostname or IP:
If
this is your first time connecting, then you’ll receive some security
warnings. Assuming this is your server and it is secure then just go
ahead and confirm them.
Connect from Linux
To connect from a Linux machine, a great option for using remote desktop connection is Remmina.
Remmina is a wonderful free and open-source remote desktop client that
supports Remote Desktop Protocol, VNC, NX, XDMCP, SPICE and SSH
protocols.
To use Remmina to connect from Linux to your remote machine, just run Remmina after installing it, click the + in the top left corner and fill in your remote machine’s IP/Hostname, Username and Password.
If you’re running Debian/Ubuntu/CentOS/Fedora locally, you can install Remmina using the following commands:
You’ll notice we are also installing remmina-plugins-* because our main interest is installing the Remmina RDP plugin, as it may not be installed by default.
You can find more detailed installation instructions, and instructions for other distros on their website, here How to install Remmina – Remmina.
After launching the app for the first time, you’ll first want to create a new connection. To do this click on the + in the top left corner of the app window.
The essential information you need here is for PC Name, User name and Password.
Just fill in the info for the 3 mentioned fields as follows:
PC Name – The IP or Host name of your remote machine. Most likely you’ll want to use your IP. User name – The username you used when installing xRDP and the desktop environment on your remote machine. Either root or your sudo user. Password – Your CentOS user’s login password.
After which the connection should be saved and you should be able to start the connection to the remote machine.
For additional info and support, you can read the instructions for Remote Desktop on Mac on Microsoft’s Website.
Conclusion
Well
done. You’ve hopefully learned how to install xRDP on a CentOS 7
machine and use 3 different desktop environments over remote desktop
connection.
If you’ve encountered any issues when following this
tutorial, please feel free to let us know in the comments or by
contacting us.
For
the past few months, our team has been working on reducing the overall
latency of the TCP/IP stack. Solarflare’s OpenOnload based kernel bypass
gives a significant performance boost over the kernel. Using that, we
were able to achieve 1800ns UDP to TCP round trip with our application
in it but this wasn’t enough. After some research, we found out that
TCPDirect claims a further performance boost of around 300–350ns, so we
decided to test it out. Although there is a manual available for
TCPDirect, there isn’t any significant, easy to understand help
available to port conventional sockets to TCPdirect “zockets”.
After
a lot of exploration and experimentation, I have come out to a cheat
sheet to convert a conventional socket-based application to TCPDirect’s “zockets”.
Initial Setup
Initial Setup
To get started with TCPDirect, you have to do the following initializations
Add the required libraries.
Call zf_init(). Itinitializes the TCPDirect.
Set the optional properties of TCP/IP stack in the “Attr” structure
e.g buffer size or interface. This attribute will be used in the next
step and later on while initializing the zockets.
Allocate
the stack. One stack can handle a maximum of 64 zockets. If you want to
open more zockets you have to create more stacks.
Unlike
conventional UDP socket, which provides the leverage of sending and
receiving UDP packets through the same socket, you must have two
different zockets for sending and receiving in TCPDirect.
UDP Receive
UDP Receive
To set up a receive zocket, you need to perform the following steps.
Set up a UDP receive zocket using stack and attribute structures used in the initialization step.
Bind to the address you want to listen, here ai_local is addrinfo type structure.
Call zf_reactor_perform() to check if any packet is received.
Use zfur_zc_recv() to receive the packet, if the packet is available in the previous step.
As it is a zero-copy receive, free the sk-buff after utilizing the data.
UDP Send
UDP Send
To send a UDP packet, do the following steps
Set
up a UDP send zocket using stack and attribute structures used in the
initialization step. Give remote and local addresses in ai_local and ai_remote, which are addrinfo type structures.
Send packet using zfut_send_single().
TCP Send Receive
Unlike UDP, the same zocket can be used to send and receive packets.
Set up a TCP zocket using stack and attribute structures used in the initialization step.
Connect to the remote server using zft_connect, here ai_remote is addrinfo type structure.
Send a packet using zft_send_single().
Start listening to the port to receive packets.
Use zftl_accept() to check if a connection is accepted or not.
Frequently call zf-reactor_perform()
to check for any received event or packet. This is a very critical
function, as it also handles some non-user-visible events like sending
the ACK or retransmitting the packet.
Use zft_zc_rect() to receive a packet.
As it is a zero-copy receive, free the sk-buff after utilizing the data.
Final words
TCPDirect
APIs are a bit different from the kernel APIs but they can be easily
mapped. A small effort in changing them can result in a significant
performance boost of about 300–350ns in your latency-critical
application. Hopefully, this guide will be helpful to get you started
with TCPDirect.
Unpack the tar archive and change the current working directory
tar zxf gcc-7.3.0.tar.gz
cd gcc-7.3.0
Install bzip2 and run the ‘download_prerequisites’ script to download
some prerequisites needed by GCC. You have to run this from the top
level of the GCC source tree.
Once it is completed, run the following command to compile the source
code. It may take a few hours for the compilation to complete, so sit
back and relax.
Well, protobuf. Right? If you haven’t heard of it, please visit – https://developers.google.com/protocol-buffers/ and read it. It is pretty cool in terms network communication. Reduces size of your payload a lot.
Now, if you are like me trying to use .proto files with Visual
Studio, you might find it painful, to re-generate .cs files after your
.proto files are changed. And also make sure you could also right code
logic around those .cs classes generated, without any hassle. I kind,
came up with a solution to this for my cases. Sharing here, in case
anyone else finds it useful.
The Solution
Lets create our solution first. My solution name is ProtobufDemo. I will add few projects (will describe later), and it looks like this –
This is a very simple solution –
src contains all the source code
ProtobufDemo.Message we will have .proto
definition files here. I am a bit lazy and I really don’t going into
command line and run a command each time I am modifying something in my
definition file. I will use this project to auto generate the cs files from proto file.
ProtobufDemo.Message.Generated
is the project we will have our generated POCO classes and also any
additional logic that we might want to have for the message. For
example, validation and adding some on demand fields, etc.
The Example Domain (.proto)
Our domain is a plain and simple blog entry. With 3 fields –
Title
Content
Author
So, it looks like this –
//Blog.proto
syntax = "proto3";
option csharp_namespace = "ProtobufDemo.Message"; // the generated namespace for cs classes
message Blog {
string title = 1;
string content = 2;
string author = 3;
}
The Generated Domain (.cs)
Before we include the tools to generate the .cs classes, we need to fix few things. I have listed them bellow –
By default grpc.tools generates the files inside obj
folder in the same project. This causes sometimes troubles for MSbuild
system as something the build remnants stays there and causes double
reference error.
I am going to use the second project (ProtobufDemo.Message.Generated) to include those generated .cs files. This keeps both the projects and build system clean.
Add Required Tools
Lets add required nuget packages to our project, that will generate the .cs files from .proto files.
That will make sure every time we build project, it will convert any .proto file in this project to .cs .
Now, we need to control how that .cs file is being generated. As I
mentioned earlier the default location is obj folder, which is not quite
I want.
First, make sure the Build Action for your file is Protobuf. This option only appears after the nuget packages are installed.
You might need to reload the solution to have it enabled after installing the nuget package.
Modify Project file
Unfortunately, there is no shortcut for this. You have to modify the project file for ProtobufDemo.Message project to make sure the files are generated into correct locations. Since I am using the other project (ProfotbufDemo.Message.Generated) for including the .cs file, I will use the location for that project. Please use location that best suites your need.
This practically says to generate the file to that location.
Unfortunately, there is no shortcut to this, but luckily you only have
to it once per file.
Now, build and you will see files generated in proper location.
Enable Show All Files from solution explorer, you will be able to see the generated folder/files. Lets include the file into the project –
That is it. Now every time you modify your .proto file, you will have
your .cs auto generated and updated. No more extra works or commands to
run.
Adding Custom Property to Generated POCO
Well, that solves half the problem. The other half is what if I Want
to add some custom logic for the class or some custom validation or some
custom read-only property to keep a clean implementation.
You are lucky, cause the POCO classes generated by grpc tools are partial. All you have to do is match the namepace and classname
and you can have a very simple interface implementation and logic to
inject with. I will not go into details, but a typical web framework
with command handlers and controllers look like this –
The proto
syntax = "proto3";
option csharp_namespace = "ProtobufDemo.Message"; //match it in partial class
message Blog {
string title = 1;
string content = 2;
string author = 3;
}
namespace ProtobufDemo.Message
{
public partial class Blog : IDomain
{
public bool HasTitle()
{
return string.IsNullOrWhiteSpace(Title); //perfect use of shared property in partial class
}
}
}
Posted by lawnninja on Thu, 29 Aug 2019 14:14:58 +0200
Adding custom monitors to zabbix
By writing scripts to obtain various states of tcp, adding TCP status
template, triggers, graphics, the whole process of customizing
monitoring through scripts is realized.
Create a script to get the tcp status, as shown below
#!/bin/bash
#this script is used to get tcp and udp connetion status
#tcp status
metric=$1
tmp_file=/tmp/tcp_status.txt
/bin/netstat -an|awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}' > $tmp_file
case $metric in
closed)
output=$(awk '/CLOSED/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
listen)
output=$(awk '/LISTEN/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
synrecv)
output=$(awk '/SYN_RECV/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
synsent)
output=$(awk '/SYN_SENT/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
established)
output=$(awk '/ESTABLISHED/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
timewait)
output=$(awk '/TIME_WAIT/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
closing)
output=$(awk '/CLOSING/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
closewait)
output=$(awk '/CLOSE_WAIT/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
lastack)
output=$(awk '/LAST_ACK/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
finwait1)
output=$(awk '/FIN_WAIT1/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
finwait2)
output=$(awk '/FIN_WAIT2/{print $2}' $tmp_file)
if [ "$output" == "" ];then
echo 0
else
echo $output
fi
;;
*)
echo -e "\e[033mUsage: sh $0 [closed|closing|closewait|synrecv|synsent|finwait1|finwait2|listen|established|lastack|timewait]\e[0m"
esac
3. Configure zabbix_agent d.conf
To execute a custom script to get data, you need to open the
appropriate options in the configuration file. If you have started, you
can skip this step.
Note: The tcp.status here is the monitored item name, followed by $1 is the corresponding parameter.
For example, the state of closewait is tcp.status[closewait]
Test whether you can get customized monitoring data by zabbix_get on the server side
[root@localhost ~]# zabbix_get -s ip -p 10050 -k "tcp.status[listen]"
13
[root@localhost ~]# zabbix_get -s ip -p 10050 -k "tcp.status[listen]"
13
No problem with data
Note: This command is executed on the server side of zabbix, not on the agent side.
If there is no zabbix_get command, install zabbix_get
[root@localhost ~]# yum -y install zabbix-get
Loaded plug-in: fastest mirror
Loading mirror speeds from cached hostfile
* base: mirrors.aliyun.com
* epel: mirrors.aliyun.com
* extras: mirrors.aliyun.com
* updates: mirrors.aliyun.com
The package zabbix-get-4.0.12-1.el7.x86_64 is installed and is the latest version without any processing.
Defining custom templates
After the agent side configuration is completed, we need to create
the corresponding template on the zabbix server web. Other hosts can
apply the template to obtain custom data.
1. Creating Templates
Create a new template in Configuration -> Template ->.
The template name "TCP_CONN_STATUS" group is placed in Templates, and the configuration is shown below.
2. Create monitoring items
After creating the template, we should create the application set
first, but when creating the monitor item, we can create the application
set directly, so we skip the creation of the application set.
Find the newly created template in Configuration -> Template ->
TCP_CONN_STATUS -> Monitor Item -> Create Monitor Item
In the monitor item, we define the name TCP_CONN_LISTEN to monitor the
number of LISTENs in tcp. The key value is tcp.status[listen] defined in
our custom key, and then select the new application set TCP_CONN_STATUS
at the application set. Click Add, as shown in the following figure:
Create other tcp states such as TCP_CONN_CLOSED, TCP_CONN_FIN-WAIT-1,
TCP_CONN_LAST-ACK, TCP_CONN_SYN-RECV, TCP_CONN_TIME-WAIT and so on by
the above steps.
The final monitoring items are shown in the following figure:
3. Create triggers
Find the newly created template in Configuration -> Template ->
TCP_CONN_STATUS -> Trigger -> Create Trigger, as shown in the
following figure:
Create a trigger named Too Many Tcp Closewait, set the number of
closewaits to alarm, I set it to 500, the expression is
{TCP_CONN_STATUS: tcp. status [closed]. last ()}> 500, the specific
configuration is as follows:
The expression is added at that point. In the monitor item, select the
close wait monitor item and insert the result with > 500 clicks, as
shown in the following figure:
To complete a custom monitoring template definition here
5. Associated Host
Connect the template we just created to our host for the template to take effect
In Configuration -> Host -> Select the Host to Monitor -> Click
Template -> Select the Template we just created on the Link
Indicator, click Add -> Click Update, and the Template is added, as
shown in the following figure:
We can see the latest data generation in Detect -> Latest Data
-> Select the host that just added the template -> Select the
Application Set (TCP_CONN_STATUS), which shows that our template
configuration is successful, as shown in the following figure:
You can also select TCP_CONN_STATUS_Graph we created earlier in the
graph to see the graph generation, as shown in the following figure:
Little knowledge:
After we have created the template, we can choose to export the template to facilitate our sharing and reuse.
In Configuration -> Template -> Find the Template we created -> Check Template -> Click Export
Save the exported files and use them on other hosts. Note that the template and agent configurations should be consistent.
