Home Blog Page 451

How to Set Up Easy Remote Desktop Access in Linux

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.

Figure 1: Enable Sharing in Fedora 26.

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).

Figure 2: Enabling the necessary VNC ports through the firewall.

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.

Figure 3: The remmina main window.

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.

Figure 4: Accepting a request to share out the desktop on Fedora 26.

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).

Figure 5: Enabling desktop sharing on Kubuntu, via krfb.

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.

Containerd Brings More Container Runtime Options for Kubernetes

container runtime is software that executes containers and manages container images on a node. Today, the most widely known container runtime is Docker, but there are other container runtimes in the ecosystem, such as rktcontainerd, and lxd. Docker is by far the most common container runtime used in production Kubernetes environments, but Docker’s smaller offspring, containerd, may prove to be a better option. This post describes using containerd with Kubernetes.



Kubernetes 1.5 introduced an internal plugin API named Container Runtime Interface (CRI) to provide easy access to different container runtimes. CRI enables Kubernetes to use a variety of container runtimes without the need to recompile. In theory, Kubernetes could use any container runtime that implements CRI to manage pods, containers and container images.

Read more at Kubernetes Blog

Practical Functional Programming

The following is reformatted from a presentation I gave at LinkedIn last year. The presentation attempted to explain functional programming without using concepts like “monads” or “immutability” or “side effects”. Instead it focuses on how thinking about composition can make you a better programmer, regardless of what language you use.

40years ago, on October 17th, 1977, the Turing Award was presented to John Backus for his contribution to the design of high-level programming systems, most notably the Fortran programming language. All Turing Award winners are given the opportunity to present a lecture on a topic of their choice during the year in which they receive the award. As the creator of the Fortran programming language, one may have expected Backus to lecture on the benefits of Fortran and future developments in the language. Instead, he gave a lecture entitled Can programming be liberated from the Von Neumann style? in which he criticized some of the mainstream languages of the day, including Fortran, for their shortcomings. He also proposed an alternative: a functional style of programming.

Read more at HackerNoon

Sysadmin 101: Automation

This is the second in a series of articles on systems administrator fundamentals. These days, DevOps has made even the job title “systems administrator” seem a bit archaic, much like the “systems analyst” title it replaced. These DevOps positions are rather different from sysadmin jobs in the past. They have a much larger emphasis on software development far beyond basic shell scripting, and as a result, they often are filled by people with software development backgrounds without much prior sysadmin experience. In the past, a sysadmin would enter the role at a junior level and be mentored by a senior sysadmin on the team, but in many cases currently, companies go quite a while with cloud outsourcing before their first DevOps hire. As a result, the DevOps engineer might be thrust into the role at a junior level with no mentor around apart from search engines and Stack Overflow posts.

In this series, I’m going to expound on some of the lessons I’ve learned through the years that might be obvious to longtime sysadmins but may be news to someone just coming into this position.

Read more at Linux Journal

Prometheus 2.0 Arrives with a Speedy New Local Storage Engine

Improved local storage is at the heart of the new release of Prometheus 2.0, according to Fabian Reinartz, a CoreOS software engineer and a core developer of the Prometheus monitoring system.

With distributed system coordination software such as Kubernetes and Mesos, monitored environments have become increasingly more dynamic, Reinartz pointed out in a blog post. The motioning software needed its own dedicated storage to ensure responsiveness in these dynamic environments.

Though Prometheus 1.6 introduced auto-tuning capabilities, the team has been working on a more performant time-series database. “It’s just way more reliable and faster. Ideally, you don’t want to have to reconfigure all the time, so Prometheus just responds to change in demands, so there are way fewer knobs to turn for the people running it,” Reinartz said in an interview.

Read more at The New Stack

Testing IPv6 Networking in KVM: Part 2

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).

Figure 1: Create a network.

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).

Figure 2: Copy the “Combined/CID” address into the Network field.

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.

Figure 3: Enable DHCPv6.

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.)

Testing

What does ifconfig tell us?

$ ifconfig
ens3: flags=4163 UP,BROADCAST,RUNNING,MULTICAST  mtu 1500
 inet 192.168.30.207  netmask 255.255.255.0  
   broadcast 192.168.30.255
 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.

Cloud Foundry: Focusing on Flexibility and Choice for a Cloud-Native World

For some organizations working outside of technology hubs such as Silicon Valley, there is a vast shortage of developer talent to choose from. As a result, many have taken a proactive learning approach to help bring their developers up-to-speed with the demands of today’s cloud-native software platforms.

Cloud Foundry is evolving its technology to benefit these users’ goals, explained Cloud Foundry Executive Director Abby Kearns, in this live-streamed episode of The New Stack Makers podcast recorded at Cloud Foundry Summit Europe last month.

“For each of these companies that are becoming software companies, they’re trying to find out, where do they find that talent?” Kearns said, adding that, “We’re seeing a lot of companies invest in training and re-training people, teaching them to be cloud-native developers and I think that is the most fascinating piece of all this.”

Read more at The New Stack

Kubernetes by the Numbers: 10 Compelling Stats

How quickly has Kubernetes’ popularity soared? By most accounts, very quickly. Earlier this year, Cloud Native Computing Foundation executive director Dan Kohn penned a blog post that dug into that claim. People regularly tout Kubernetes as one of the highest velocity projects ever in open source history: Does the data back it up?

As Kohn found, there may not be a single definitive metric, but they all point in the same conclusion: “You can pick your preferred statistic, such as that Kubernetes is in the top 0.00006% of the projects on GitHub,” Kohn wrote. “I prefer to just think of it as one of the fastest moving projects in the history of open source.”

You can find plenty of numbers that illuminate Kubernetes’ path to becoming one of the most popular container orchestration tools, as well as other important characteristics of the platform. We rounded up some of the best for your consideration – and your potential use in making the case for Kubernetes in your organization.

Read more at Enterprisers Project

Why Senior Devs Write Dumb Code and How to Spot a Junior From A Mile Away

One of my all time favorite quotes is from Brian Goetz, a smart dude in the Java world who is one of the authors of Java Concurrency in Practice, among other things. The quote appears in an interview that Oracle published under the title, “Write Dumb Code”. Goetz was asked how to write code that performs well. Here is what he had to say:

Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles.

The rest of the ~1000 words is devoted to explaining why trying to optimize code and trying to be clever is a common programmer mistake 

Read more at HackerNoon

Small Tools for Managing HPC: It’s the Little Things

The HPC world has some amazing “big” tools that help administrators monitor their systems and keep them running, such as the Ganglia and Nagios cluster monitoring systems. Although they are extremely useful, sometimes it is the smaller tools that can help debug a user problem or find system issues.

ldd

The introduction of sharable objects, or “dynamic libraries,” has allowed for smaller binaries, less “skew” across binaries, and a reduction in memory usage, among other things. Users, myself included, tend to forget that when code is compiled, we only see the size of the binary itself, not the “shared” objects.

For example, the following simple Hello World program, called test1, uses the PGI compilers (16.10).

Read more at ADMIN Magazine