Tag Archives: linux

Linux Kernel 4.14 Released » Linux Magazine

Linus Torvalds, the creator of Linux, announced the release of Linux kernel 4.14 on November 12, 2017. The release was due earlier but was delayed due to an AppArmor patch that caused regression. Torvalds lashed out at a Canonical developer who found AppArmor regression but said that it was not a big deal.

Torvalds responded and said, “As far as the kernel is concerned, a regression is THE KERNEL NOT GIVING THE SAME END RESULT WITH THE SAME USER SPACE. The regression was in the kernel. You trying to shift the regressions somewhere else is bogus SHIT. And seriously, it’s the kind of garbage that makes me think your opinion and your code cannot be relied on. If you are not willing to admit that your commit 651e28c5537a (“apparmor: add base infrastructure for socket mediation”) caused a regression, then honestly, I don’t want to get commits from you.”

Torvalds chose to delay the release instead of letting the regression go through.

Linux kernel 4.14 is expected to be the next LTS version. Greg Kroah-Hartman, the maintainer of the stable branch of the Linux kernel said, “So, here it is officially, 4.14 should be the next LTS kernel that I’ll be supporting with stable kernel patch backports for at least two years, unless it really is a horrid release and has major problems. If so, I reserve the right to pick a different kernel, but odds are, given just how well our development cycle has been going, that shouldn’t be a problem (although I guess I just doomed it now…)

Some of the major highlights of the release include built-in HDMI CEC support for Raspberry Pi that allows users to control their Pi powered devices via a single controller. There are significant performance improvements of KVM, Xen, andHyper-V. The release also improves EFI support making it more secure and reliable.

Source link

How to Set Up Easy Remote Desktop Access in Linux | Linux.com

Linux is a remarkably flexible operating system. One of the easiest means of understanding that is when you see that, given a task, there are always multiple paths to success. This is perfectly illustrated when you find the need to display a remote desktop on a local machine. You could go with RDP, VNC, SSH, or even a third-party option. Generally speaking, your desktop will determine the route you take, but some options are far easier than others. Once you understand how streamlined modern desktops have made this task, your remote administration of Linux desktops and servers (with GUIs) becomes much simplified.

As I mentioned, how you do this will depend upon your distribution. In this article, I’ll cover how this can be done between Ubuntu Desktop 18.04 and Fedora 26 and Fedora 26 to Kubuntu. The big issue you will come across is that some desktops simply don’t work well with this technology. For example, as it stands, Wayland has yet to find its way to supporting VNC. The same thing holds true with the Elementary OS desktop. So I’ll demonstrate connecting to Fedora 26 from Ubuntu 18.04 and then from Fedora 26 to Kubuntu 17.10. I’ll be using the tools remmina, krfb, and the GNOME built-in tools.

From Ubuntu to Fedora

With the latest release of Fedora 26, using the default GNOME desktop, setting up a remote connection is fairly straightforward (because everything is installed by default). The first thing you must do is enable sharing. If you open up the GNOME Dash and type sharing, you’ll see the Sharing option appear, which allows you to open the tool. When the window opens, click the ON/OFF slider to the ON position and then click Screen Sharing. In the resulting window (Figure 1), click the checkbox for Allow connections to control the screen.

You can also enable the access options for New connections must ask for access and requiring a password. I highly recommend, at a bare minimum, that you enable the option for New connections must ask for access. That way, when someone attempts to gain access to your remote desktop, the connection will not be made until it is approved. Once these options have been taken care of, you can close out that window.

Out of the box, Fedora must have the necessary port opened in the firewall, so this remote connection can work. Go back to the GNOME Dash and type firewall. When the firewall icon appears, click on it, and enter your admin password. In the resulting window, click on Services and scroll down until you see vnc-server (Figure 2).

Click to enable vnc-server and then, when prompted, type your admin password. Access to the VNC port is now enabled.

Head over to the Ubuntu machine. We need to install the remmina application (which is one of the better remote client applications). Because the version in the standard repository contains a few bugs, we’ll install the most recent version with the following steps:

  1. Add the necessary repository with the command sudo apt-add-repository ppa:remmina-ppa-team/remmina-next

  2. Update the apt sources with the command sudo apt update

  3. Install the software with the command sudo apt-get install remmina remmina-plugin-rdp remmina-plugin-gnome libfreerdp-plugins-standard

From the desktop menu, type remmina and open the newly installed software. In the address window (Figure 3), select VNC from the drop-down, enter the IP address of the Fedora machine, and hit Enter on the keyboard.

Once you hit Enter on the keyboard, the Fedora desktop notification will pop up. Hover over that notification and click Accept (Figure 4). The connection will be made and whoever is on the Ubuntu machine can control your Fedora desktop.

From Fedora to Kubuntu

Now we’re going to connect from Fedora to Kubuntu. Because we’re going to use the same client (remmina), we need to install it on Fedora. To do this, open up a terminal window and issue the command sudo dnf install remmina.

With that installed, we now have to add the necessary piece of software on the Kubuntu desktop. The application in question is krfb and can be installed with the command sudo apt install krfb. Once that is installed, you can open the KDE menu and type krfb. Click on the resulting entry and then, in the new window, click the checkbox associated with Enable Desktop Sharing (Figure 5).

The krfb tool also gives you the necessary IP address as well as the password to use in order to gain access from the client. If you don’t like the given password, it can be changed by clicking the associated edit button.

At this point, your KDE desktop is ready to share. Head over to Fedora, open the GNOME Dash, type remmina and click the icon to open the software. Select VNC from the drop-down, type the IP address of the Kubuntu machine, and hit enter. You will be prompted for the krfb password. Type that and click OK. Back on the Kubuntu desktop, you’ll be asked to accept the connection. Once accepted, the Kubuntu desktop will appear on the Fedora. You’re ready to work.

Simple remote desktop connection

And that’s all there is to it. Yes, there are plenty of other ways to enable these types of connections (and some desktops don’t make the process nearly as easy). Fortunately, modern desktop distributions do include everything necessary to make remote connections incredibly simple. If your particular desktop of choice doesn’t include the tools to make this easy, you’re looking at installing one of the many VNC servers available for Linux (such as vino, TigerVNC, or tightvnc). Going the standard VNC server route might not be as user-friendly as the methods I’ve explained here, but, once set up, it is equally reliable.

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

4 Ways to Watch or Monitor Log Files in Real Time | Linux.com

How can I see the content of a log file in real time in Linux? Well there are a lot of utilities out there that can help a user to output the content of a file while the file is changing or continuously updating. Some of the most known and heavily used utility to display a file content in real time in Linux is the tail command (manage files effectively).

1. tail Command – Monitor Logs in Real Time

As said, tail command is the most common solution to display a log file in real time. However, the command to display the file has two versions, as illustrated in the below examples.

In the first example the command tail needs the -f argument to follow the content of a file.

Read more at Tecmint


Click Here!

Testing IPv6 Networking in KVM: Part 2 | Linux.com

When last we met, in Testing IPv6 Networking in KVM: Part 1, we learned about IPv6 private addressing. Today, we’re going to use KVM to create networks for testing IPv6 to our heart’s content.

Should you desire a refresh in using KVM, see Creating Virtual Machines in KVM: Part 1 and Creating Virtual Machines in KVM: Part 2 – Networking.

Creating Networks in KVM

You need at least two virtual machines in KVM. Of course, you may create as many as you like. My little setup has Fedora, Ubuntu, and openSUSE. To create a new IPv6 network, open Edit > Connection Details > Virtual Networks in the main Virtual Machine Manager window. Click on the button with the green cross on the bottom left to create a new network (Figure 1).

Give your new network a name, then click the Forward button. You may opt to not create an IPv4 network if you wish. When you create a new IPv4 network the Virtual Machine Manager will not let you create a duplicate network, or one with an invalid address. On my host Ubuntu system a valid address is highlighted in green, and an invalid address is highlighted in a tasteful rosy hue. On my openSUSE machine there are no colored highlights. Enable DHCP or not, and create a static route or not, then move on to the next window.

Check “Enable IPv6 network address space definition” and enter your private address range. You may use any IPv6 address class you wish, being careful, of course, to not allow your experiments to leak out of your network. We shall use the nice IPv6 unique local addresses (ULA), and use the online address generator at Simple DNS Plus to create our network address. Copy the “Combined/CID” address into the Network field (Figure 2).

Virtual Machine Manager thinks my address is not valid, as evidenced by the rose highlight. Can it be right? Let us use ipv6calc to check:

$ ipv6calc -qi fd7d:844d:3e17:f3ae::/64
Address type: unicast, unique-local-unicast, iid, iid-local
Registry for address: reserved(RFC4193#3.1)
Address type has SLA: f3ae
Interface identifier: 0000:0000:0000:0000
Interface identifier is probably manual set

ipv6calc thinks it’s fine. Just for fun, change one of the numbers to something invalid, like the letter g, and try it again. (Asking “What if…?” and trial and error is the awesomest way to learn.)

Let us carry on and enable DHCPv6 (Figure 3). You can accept the default values, or set your own.

We shall skip creating a default route definition and move on to the next screen, where we shall enable “Isolated Virtual Network” and “Enable IPv6 internal routing/networking”.

VM Network Selection

Now you can configure your virtual machines to use your new network. Open your VMs, and then click the “i” button at the top left to open its “Show virtual hardware details” screen. In the “Add Hardware” column click on the NIC button to open the network selector, and select your nice new IPv6 network. Click Apply, and then reboot. (Or use your favorite method for restarting networking, or renewing your DHCP lease.)


What does ifconfig tell us?

$ ifconfig
ens3: flags=4163 UP,BROADCAST,RUNNING,MULTICAST  mtu 1500
 inet  netmask  
 inet6 fd7d:844d:3e17:f3ae::6314  
   prefixlen 128  scopeid 0x0
 inet6 fe80::4821:5ecb:e4b4:d5fc  
   prefixlen 64  scopeid 0x20

And there is our nice new ULA, fd7d:844d:3e17:f3ae::6314, and the auto-generated link-local address that is always present. Let’s have some ping fun, pinging another VM on the network:

vm1 ~$ ping6 -c2 fd7d:844d:3e17:f3ae::2c9f
PING fd7d:844d:3e17:f3ae::2c9f(fd7d:844d:3e17:f3ae::2c9f) 56 data bytes
64 bytes from fd7d:844d:3e17:f3ae::2c9f: icmp_seq=1 ttl=64 time=0.635 ms
64 bytes from fd7d:844d:3e17:f3ae::2c9f: icmp_seq=2 ttl=64 time=0.365 ms

vm2 ~$ ping6 -c2 fd7d:844d:3e17:f3ae:a:b:c:6314
PING fd7d:844d:3e17:f3ae:a:b:c:6314(fd7d:844d:3e17:f3ae:a:b:c:6314) 56 data bytes
64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=1 ttl=64 time=0.744 ms
64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=2 ttl=64 time=0.364 ms

When you’re struggling to understand subnetting, this gives you a fast, easy way to try different addresses and see whether they work. You can assign multiple IP addresses to a single interface and then ping them to see what happens. In a ULA, the interface, or host, portion of the IP address is the last four quads, so you can do anything to those and still be in the same subnet, which in this example is f3ae. This example changes only the interface ID on one of my VMs, to show how you really can do whatever you want with those four quads:

vm1 ~$ sudo /sbin/ip -6 addr add fd7d:844d:3e17:f3ae:a:b:c:6314  dev ens3

vm2 ~$ ping6 -c2 fd7d:844d:3e17:f3ae:a:b:c:6314
PING fd7d:844d:3e17:f3ae:a:b:c:6314(fd7d:844d:3e17:f3ae:a:b:c:6314) 56 data bytes
64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=1 ttl=64 time=0.744 ms
64 bytes from fd7d:844d:3e17:f3ae:a:b:c:6314: icmp_seq=2 ttl=64 time=0.364 ms

Now try it with a different subnet, which in this example is f4ae instead of f3ae:

$ ping6 -c2 fd7d:844d:3e17:f4ae:a:b:c:6314
PING fd7d:844d:3e17:f4ae:a:b:c:6314(fd7d:844d:3e17:f4ae:a:b:c:6314) 56 data bytes
From fd7d:844d:3e17:f3ae::1 icmp_seq=1 Destination unreachable: No route
From fd7d:844d:3e17:f3ae::1 icmp_seq=2 Destination unreachable: No route

This is also a great time to practice routing, which we will do in a future installment along with setting up auto-addressing without DHCP.

Install Let’s Encrypt and Secure Nginx with SSL/TLS in Debian 9 | Linux.com

This tutorial will show you how to install and secure a Nginx web server on Debian 9 with a TLS certificate issued for free by the Let’s Encrypt Certificate Authority. Furthermore, we will configure automatic renewal of Lets’ Encrypt TLS certificates using a cron job before the certificates expire.

TLS, also known as Transport Layer Security, is a network protocol that uses SSL certificates to encrypt the network traffic which flows between a server and a client, or between a web server, such as Nginx server, and a browser. All data exchanged in between these two entities is secured and the connection cannot be decrypted even if it is intercepted using a technique such as by a man in the middle attack or packet sniffing. The certbot package software is the official client utility provided by Let’s Encrypt CA that can be used in the process of generating and downloading free Let’s Encrypt certificates in Debian.

Read more at HowToForge

Click Here!