Home Blog Page 629

Troubleshooting Tips for the 5 Most Common Linux Issues

Although Linux installs and operates as expected for most users, inevitably some users will run into problems. For my final article in The Queue column for the year, I thought it would be interesting to summarize the most common technical Linux issues people ran into in 2016. I posted the question to LinuxQuestions.org and on social media, and I analyzed LQ posting patterns. Here are the results.

1. Wifi drivers (especially Broadcom chips)

Generally speaking, wifi drivers—and Broadcom cards in particular—continue to be one of the most problematic technical issues facing Linux. There were hundreds of posts about this topic on LQ alone in 2016, and myriad more elsewhere.

Read more at OpenSource.com

Open Source Server Simplifies HTTPS, Security Certificates

Forget expired TLS certificates; the lightweight Caddy web server handles Let’s Encrypt certificates and redirects HTTP traffic by default. For administrators seeking an easier method to turn on HTTPS for their websites, there is Caddy, an open source web server that automatically sets up security certificates and serves sites over HTTPS by default.

Built on Go 1.7.4, Caddy is a lightweight web server that supports HTTP/2 out of the box and automatically integrates with any ACME-enabled certificate authority such as Let’s Encrypt. HTTP/2 is enabled by default when the site is served over HTTPS, and administrators using Caddy will never have to deal with expired TLS certificates for their websites, as Caddy handles the process of obtaining and deploying certificates.

Read more at InfoWorld

Linux Kernel 4.8 Reaches End of Life, Users Urged to Move to Linux 4.9 Series

After informing us about the availability of the Linux 4.8.16 kernel update a few days ago, Greg Kroah-Hartman announced earlier today the availability of a new maintenance update, which appears to be the last in the stable series.

It was bound to happen sooner or later, especially now that the Linux 4.9 kernel series has been officially declared stable and ready for deployment in production environments, so we’re sad to inform you that there won’t be any updates to the Linux 4.8 kernel branch. The last point release is now Linux kernel 4.8.17.

Read more at Softpedia

How to Secure MongoDB on Ubuntu or Debian or CentOS Linux Production server

MongoDB Ransomware attacks over 28000 databases server in last two days. MongoDB ransom attacks are in Wild. MongoDB is a free and open-source NoSQL document database server. It is used by web application for storing data on a public facing server. Securing MongoDB is critical. Crackers and hackers are accessing insecure MongoDB for stealing data and deleting data from unpatched or badly-configured databases. This guide explains how to protect and secure your MongoDB nosql server running on Linux operating system.

Read more at: nixCraft

VMware Joins Open-O to Pursue its Telco NFV Strategy

VMware joined the Open-O project today as a premier member. The open source project hosted by the Linux Foundation works to enable end-to-end service orchestration via network functions virtualization (NFV) over both software-defined networks (SDN) and legacy networks. 

As a premier member, VMware will participate in both the governing board, along with the technical steering and marketing committees. In 2016 VMware indicated it would put more focus on telco NFV. And it hired Gabriele Di Piazza as vice president of telco NFV products.

Read more at SDxCentral

Sweden’s Blockchain Land Registry to Begin Testing in March

A public-private effort in Sweden to record land titles on a blockchain is set to begin public testing this March.

Spearheaded by the Swedish National Land Survey and blockchain startup ChromaWay, the project was revealed in June to have support from consulting firm Kairos Future and telephone service provider Telia. Now, the project is moving ahead with the addition of two banks that specialize in mortgages, Landshypotek and SBAB, CoinDesk has learned.

ChromaWay CEO Henrik Hjelte said that the sandbox release would seek to test the platform from a business, legal and security perspective, while allowing the public to test the interface and back-end.

Read more at CoinDesk

Communities Over Code: How to Build a Successful Project by Joe Brockmeier, Red Hat

Joe Brockmeier has tips for how you can build community and attract more users – which in turn, will attract more developers, make life easier, and help ensure a long life for your project.

 

Essentials of OpenStack Administration Part 5: OpenStack Releases and Use Cases

Start exploring Essentials of OpenStack Administration by downloading the free sample chapter today. DOWNLOAD NOW

OpenStack has come a long way since 2010 when NASA approached Rackspace for a project. With 1,600 individual contributors to OpenStack and a six-month release cycle, there are a lot of changes and progress. This amount of change and progress is not without its drawbacks. In the Juno release, there were something like 10,000 bugs. In the next release, Kilo, there were 13,000 bugs. But as OpenStack is deployed in more environments, and more people are interested in it, the community grows both in users and developers.

In part 5 of our series from the Essentials of OpenStack Administration course sample chapter, we discuss the OpenStack project in more detail: its community of contributors, release cycle, and use cases. Download the full sample chapter now.

History of OpenStack

In 2010, Engineers at NASA approached some friends at Rackspace to build an open cloud for NASA and hopefully other government organizations as part of an Open Government initiative. At that time, there were only proprietary and expensive offerings available. Project Nebula was born. Rackspace was interested in moving their software toward open source and saw Nebula as a good place to begin.

Together they started working on something called Nova, known now as OpenStack Compute. At the time, Nova was the project that did everything. It did storage, and network, and virtual machines. Now, new projects have taken over some of those duties.

Since then, the number of projects has grown incredibly. If you go to the OpenStack.org website and look at the projects page, you’ll notice there are more than 35 different projects. Each project is made up of one or more services to the cloud. Each of the projects is developed separately.

Although NASA has stopped major work on OpenStack, a large and growing group of supporters still remains. Each component of OpenStack has a dedicated project. Each project has an official name, as well as a more well-known code-name. The project list has been growing with each release. Some projects are considered core, others are newer and in incubation stages. See a list of the current projects.

There are several distributions of OpenStack available as well, from large IT companies and start-ups alike. DevStack is a deployment of OpenStack available from the www.openstack.org website. It allows for easy testing of new features, but is not considered production-safe. Red Hat, Canonical, Mirantis and several other companies also provide their own deployment of OpenStack, similar to the many options to install Linux.

OpenStack Release Pattern

The first release of the project was code-named Austin, in October of 2010. Since then, a major release has been deployed every six months. There are code features and proposals that are evaluated every two months or so, as well as code sprints planned on a regular basis.

The quick release schedule and large number of developers working on code does not always lead to smooth transitions. The Kilo release was the first one to address an upgrade path, with its success yet to be known. In fact, there were approximately 10 percent more bugs in the Kilo release than the first Juno release.

OpenStack Use Cases

The ability to deploy and redeploy various instances allows for software development at the speed of the developer, without downtime waiting for IT to handle a ticket.

Testing can be easily done in parallel with various flavors, or system configurations, and operating system configurations. These choices are also within the reach of the end user to lessen interaction with the IT team.

Using both a Browser User Interface (BUI) or a command line, much of the common IT requests can be delegated to the users. The IT staff can focus on higher-level functions and problems instead of more common requests.

The flexibility of OpenStack through various software-defined layers allows for more options, instead of fewer, as has happened with server consolidation.

The next, and final, article in this series is a tutorial on installing DevStack, a simple way for developers to test-drive OpenStack.

The Essentials of OpenStack Administration course teaches you everything you need to know to create and manage private and public clouds with OpenStack. Download a sample chapter today!

Read the other articles in the series:

Essentials of OpenStack Administration Part 1: Cloud Fundamentals

Essentials of OpenStack Administration Part 2: The Problem With Conventional Data Centers

Essentials of OpenStack Administration Part 3: Existing Cloud Solutions

Essentials of OpenStack Administration Part 4: Cloud Design, Software-Defined Networking and Storage

Communities Over Code: How to Build a Successful Software Project

Healthy productive FOSS projects don’t just happen, but are built, and the secret ingredient is Community over code. Purpose and details are everything: If you build it will they come, and then how do you keep it going and growing? How do you set direction, attract and retain contributors, what do you do when there are conflicts, and especially conflicts with valuable contributors? Joe Brockmeier (Red Hat) shares a wealth of practical wisdom at LinuxCon North America.

We hear the word “community” bandied about all the time, and have this fuzzy notion that it’s a good thing, but what does it really mean? Brockmeier says, “I’ve worked with a number of different companies and projects…and they say, ‘Well, we want community.’ Great, what kind of community do you want? Who is important to you? What users matter to you? What developers matter to you? You need to know what success looks like. You need to know what your project goals are. These look different for different projects.”

What do you expect your community to do? “Some companies, for example, really don’t care that much about having a core contributor community outside their company, but they care deeply about having a lot of users. If you’re building a community to attract users, that’s not the same thing as building one to attract core contributors,” says Brockmeier.

Inclusion Is Key

Any software project, even a small one, requires dedicated contributors filling many roles beyond coding. You need code reviewers, documentation writers, bug finders, bug fixers, people who hang out on IRC and forums helping users, packagers, sysadmins, marketers, and perhaps artists and musicians. Attracting and retaining contributors really isn’t mysterious, just work. For example, having mentors to smooth the way for new contributors, recognizing all contributions from all contributors, and ensuring that all communications and decisions are open to all, and not just a small in-group. Brockmeier stresses inclusion: “My favorite with the Apache Software Foundation is if it didn’t happen on the mailing list, it didn’t happen. You don’t get to make decisions that affect the entire project in private and then just implement them.”

Recognition is essential: “You need to go out of your way to recognize contributions from people. It doesn’t matter whether it’s marketing, whether it somebody who’s on IRC every day answering user questions which is really important and usually not something the developers want to do. You need to make sure that you are recognizing all those people.”

Watch the complete talk (below) to learn about more key concepts including lazy consensus, code of conduct, setting measurable goals, governance, inclusion and diversity, and what to do about valuable but troublesome contributors. (Hint: no one is indispensible.)

LinuxCon videos

First 64-Bit and Enterprise OS Comes to Raspberry Pi 3

SUSE supports a lot of architectures and runs on everything from IBM mainframe to x86 machines, and more. With ARM’s push in the data center, it made even more sense for SUSE to work closely with ARM to support yet another platform.

When the Raspberry Pi 3 Model B was announced, SUSE engineers found that it runs on the Broadcom BCM2837 64-bit A53 ARM processor. A lot of work has already been completed on this processor for SUSE Linux Enterprise Server, so getting SLES or openSUSE to run on Raspberry Pi 3 Model B was only a matter of time.

During SUSECon 2016, SUSE announced SLES support for Raspberry Pi 3 Model B. Due to a close and somewhat complicated relationship (openSUSE is based on source code of SLES, whereas openSUSE is touted as the upstream of SLES) between SLES and openSUSE, the announcement also means that openSUSE will also be able to run on the same device.

I have installed and used all three distributions (SLES, openSUSE Leap, and openSUSE Tumbleweed) on Raspberry Pi, and I am pretty impressed with their performance. They all run flawlessly.

You can download openSUSE Leap, openSUSE Tumbleweed, and SLES from the following links. The good news is that SUSE is also offering a self-service subscription for SLES for a year.

Why care about ARM?

We all know that ARM is a powerhouse in the mobile and embedded space. Everything from Nexus XL to Apple Watch to iPad Pro run on ARM processors. What many of us don’t know is that ARM is moving into datacenters and the enterprise world with full force.

There is a lot of potential for ARM in enterprise, said Andrew Wafaa, an ARM engineer who mainly works on supporting SUSE on ARM in an interview. “If some people need a dense compute infrastructure, they don’t have much space within the data center. Traditionally, the biggest constraint within the data center is not floor space or rack space. It’s power and cooling. ARM moving from the mobile space into the enterprise space has a long history, a lot of experience, a lot of knowledge in the power envelope. We’re bringing a lot of that across to the enterprise space,” he said.

PayPal has deployed ARM 64 datacenter; OVH is running ARM-powered data centers; Google is considering ARM and so is Facebook.

Wafaa said that there’s a huge interest from the China region in ARM. High-performance computing is also a greenfield for ARM. One of the greatest advantages of ARM over traditional players is vendor lock-in. Any silicon vendor can license and create their own chips. And vendor lock-in, white boxes are a sensitive topic in the enterprise space as we move towards cloud. This essentially means there is going to be a huge demand for tech talent with experience in ARM.

But the Raspberry Pi is a DIY device

Raspberry Pis are not just for DIY anymore. These days companies like NEC are using Raspberry Pis in their huge displays for corporate customers. There are many web hosting providers that offer Raspberry Pi servers. There are many more such cases, but even if we don’t consider direct usage of Raspberry Pi in data centers, they are extremely valuable for sysadmins, DevOps, and developers. It can be expensive to get access to ARM-based servers and data centers (not Raspberry Pi ones), to test and develop applications.

“The Raspberry Pi is an exceptionally cheap platform for people to obtain,” said Wafaa. “It’s very easy to get hold of. In addition, there’s a large ecosystem around Raspberry Pi already. The fact that it’s low cost, it’s easy for people to obtain, they can run the same software platform that they have in their data center. They can check to see whether their software workload will run.”

Why SLES matters

SLES (and openSUSE) are the only 64-bit operating systems for Raspberry Pi. While there is no clear advantage in terms of memory limit, as Pi only comes with 1GB of RAM, the real benefit comes in terms of 64-bit computations. You are able to do more in a single transaction on a 64-bit OS in 64-bit instruction set as compared to a 32-bit task.

Richard Brown, chairman of the openSUSE board gave a very good example: “Just think of basic encryption, like SSH. There is a large amount of encryption going on behind SSH. In 32-bit what the CPU is having to do is quite often, do three or four different transactions to handle that initial handshake for SSH. In the 64-bit OS, it can do it in a lot less commands. Therefore, it does it a lot faster. That’s where you get this, somewhere between 15 to 20 percent improvement, straight out of performance on, even basic stuff.”

Currently, SLES is the only enterprise distribution that’s fully supported on Raspberry Pi. Wafaa said, “It has that pedigree of secure timely updates. It has that longevity. A default support lifecycle for SUSE Enterprises is 10 years. If you are developing for a home gateway where it’s a device that you don’t want to have to continuously fiddle with and check for the updates all the time, you want to know that you can fire it up, it’s secure. There’s all the security certifications, like FIPS, that are crucial from a security and validation perspective. That’s something that SUSE brings to the table, rather than using an open embedded-based or community-based distribution.”

Getting started with SLES

You can head over to SUSE’s download page and click SLES SP2 for Raspberry Pi. If you already have an account with SUSE, log into your account and download SLES SP2 image for Raspberry Pi 3. If you don’t have an account, then you can create one for free. Once you download the image, use the following command to write the image to a Micro SD card:


sudo xzcat <path_of_SLES_image.raw.xz> | sudo dd bs=4M of=<path_of_microsd_card> iflag=fullblock oflag=direct; sync

I downloaded SLES in the Downloads folder of my openSUSE system. Here is the command that I ran on my system, please change accordingly:

sudo xzcat /home/swapnil/Downloads/SLES-12-SP2-ARM-X11-raspberrypi3_aarch64.aarch64-2016.10.04-GM.raw.xz |
sudo dd bs=4M of=/dev/mmcblk0 iflag=fullblock oflag=direct; sync

Once the image is written to the card, insert the card into Raspberry Pi, plug in a monitor, keyboard and mouse, then power up the device. Once SLES is booted, go ahead and connect to the network and start using SLES on your system!

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