Tag Archives: hosting

How to Install and Use Flatpak on Linux | Linux.com


The landscape of applications is quickly changing. Many platforms are migrating to containerized applications… and with good cause. An application wrapped in a bundled container is easier to install, includes all the necessary dependencies, doesn’t directly affect the hosting platform libraries, automatically updates (in some cases), and (in most cases) is more secure than a standard application. Another benefit of these containerized applications is that they are universal (i.e., such an application would install on Ubuntu Linux or Fedora Linux, without having to convert a .deb package to an .rpm).

As of now, there are two main universal package systems: Snap and Flatpak. Both function in similar fashion, but one is found by default on Ubuntu-based systems (Snap) and one on Fedora-based systems (Flatpak). It should come as no surprise that both can be installed on either type of system. So if you want to run Snaps on Fedora, you can. If you want to run Flatpak on Ubuntu, you can.

I will walk you through the process of installing and using Flatpak on Ubuntu 18.04. If your platform of choice is Fedora (or a Fedora derivative), you can skip the installation process.

Installation

The first thing to do is install Flatpak. The process is simple. Open up a terminal window and follow these steps:

  1. Add the necessary repository with the command sudo add-apt-repository ppa:alexlarsson/flatpak.

  2. Update apt with the command sudo apt update.

  3. Install Flatpak with the command sudo apt install flatpak.

  4. Install Flatpak support for GNOME Software with the command sudo apt install gnome-software-plugin-flatpak.

  5. Reboot your system.

Usage

I’ll first show you how to install a Flatpak package from the command line, and then via the GUI. Let’s say you want to install the Spotify desktop client via Flatpak. To do this, you must first instruct Flatpak to retrieve the necessary app. The Spotify Flatpak (along with others) is hosted on Flathub. The first thing we’re going to do is add the Flathub remote repository with the following command:

sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Now you can install any Flatpak app found on Flathub. For example, to install Spotify, the command would be:

sudo flatpak install flathub com.spotify.Client

To find out the exact command for each install, you only have to visit the app’s page on Flathub and the installation command is listed beneath the description.

Running a Flatpak-installed app is a bit different than a standard app (at least from the command line). Head back to the terminal window and issue the command:

flatpak run com.spotify.Client

Of course, after you’ve re-started your machine (upon installing the GNOME Software Support), those apps should appear in your desktop menu, making it unnecessary to start them from the command line.

To uninstall a Flatpak from the command line, you would go back to the terminal and issue the command:

sudo flatpak uninstall NAME

where NAME is the name of the app to remove. In our Spotify case, that would be:

sudo flatpak uninstall com.spotify.Client

Now we want to update our Flatpak apps. To do this, first list all of your installed Flatpak apps by issuing the command:

flatpak list

Now that we have our list of apps (Figure 1), we can update with the command sudo flatpak update NAME (where NAME is the name of our app to update).

So if we want to update GIMP, we’d issue the command:

sudo flatpak update org.gimp.GIMP

If there are any updates to be applied, they’’ll be taken care of. If there are no updates to be applied, nothing will be reported.

Installing from GNOME Software

Let’s make this even easier. Since we installed GNOME Software support for flatpak, we don’t actually have to bother with the command line. Don’t be mistaken, unlike Snap support, you won’t actually find Flatpak apps listed within GNOME Software (even though we’ve installed Software support). Instead, you’ll find support through the web browser.

Let me show you. Point your browser to Flathub.

Let’s say you want to install Slack via Flatpak. Go to the Slack Flathub page and then click on the INSTALL button. Since we installed GNOME Software support, the standard browser dialog window will appear with an included option to open the file via Software Install (Figure 2).

 

This action will then open GNOME Software (or, in the case of Ubuntu, Ubuntu Software), where you can click the Install button (Figure 3) to complete the process.

Once the installation completes, you can then either click the Launch button, or close GNOME Software and launch the application from the desktop menu (in the case of GNOME, the Dash).

After you’ve installed a Flatpak app via GNOME Software, it can also be removed from the same system (so there’s still not need to go through the command line).

What about KDE?

If you prefer using the KDE desktop environment, you’re in luck. If you issue the command sudo apt install plasma-discover-flatpak-backend, it’ll install Flatpak support for the KDE app store, Discover. Once you’ve added Flatpak support, you then need to add a repository. Open Discover and then click on Settings. In the settings window, you’ll now see a Flatpak listing (Figure 4).

Click on the Flatpak drop-down and then click Add Flathub. Click on the Applications tab (in the left navigation) and you can then search for (and install) any applications found on Flathub (Figure 5).

Easy Flatpak management

And that’s the gist of using Flatpak. These universal packages can be used on most Linux distributions and can even be managed via the GUI on some desktop environments. I highly recommend you give Flatpak a try. With the combination of standard installation, Flatpak, and Snaps, you’ll find software management on Linux has become incredibly easy.

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

How to Run Your Own Git Server | Linux.com


Manage your code on your own server by running a bare, basic Git server or via the GitLab GUI tool.

Learn how to set up your own Git server in this tutorial from our archives.

Git is a versioning system developed by Linus Torvalds, that is used by millions of users around the globe. Companies like GitHub offer code hosting services based on Git. According to reports, GitHub, a code hosting site, is the world’s largest code hosting service. The company claims that there are 9.2M people collaborating right now across 21.8M repositories on GitHub. Big companies are now moving to GitHub. Even Google, the search engine giant, is shutting it’s own Google Code and moving to GitHub.

Run your own Git server

GitHub is a great service, however there are some limitations and restrictions, especially if you are an individual or a small player. One of the limitations of GitHub is that the free service doesn’t allow private hosting of the code. You have to pay a monthly fee of $7 to host 5 private repositories, and the expenses go up with more repos.

In cases like these or when you want more control, the best path is to run Git on your own server. Not only do you save costs, you also have more control over your server. In most cases a majority of advanced Linux users already have their own servers and pushing Git on those servers is like ‘free as in beer’.

In this tutorial we are going to talk about two methods of managing your code on your own server. One is running a bare, basic Git server and and the second one is via a GUI tool called GitLab. For this tutorial I used a fully patched Ubuntu 14.04 LTS server running on a VPS.

Install Git on your server

In this tutorial we are considering a use-case where we have a remote server and a local server and we will work between these machines. For the sake of simplicity we will call them remote-server and local-server.

First, install Git on both machines. You can install Git from the packages already available via the repos or your distros, or you can do it manually. In this article we will use the simpler method:

sudo apt-get install git-core

Then add a user for Git.

sudo useradd git
passwd git

In order to ease access to the server let’s set-up a password-less ssh login. First create ssh keys on your local machine:

ssh-keygen -t rsa

It will ask you to provide the location for storing the key, just hit Enter to use the default location. The second question will be to provide it with a pass phrase which will be needed to access the remote server. It generates two keys – a public key and a private key. Note down the location of the public key which you will need in the next step.

Now you have to copy these keys to the server so that the two machines can talk to each other. Run the following command on your local machine:

cat ~/.ssh/id_rsa.pub | ssh git@remote-server "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Now ssh into the server and create a project directory for Git. You can use the desired path for the repo.

git@server:~ $ mkdir -p /home/swapnil/project-1.git

Then change to this directory:

cd /home/swapnil/project-1.git

Then create an empty repo:

git init --bare
Initialized empty Git repository in /home/swapnil/project-1.git

We now need to create a Git repo on the local machine.

mkdir -p /home/swapnil/git/project

And change to this directory:

cd /home/swapnil/git/project

Now create the files that you need for the project in this directory. Stay in this directory and initiate git:

git init 
Initialized empty Git repository in /home/swapnil/git/project

Now add files to the repo:

git add .

Now every time you add a file or make changes you have to run the add command above. You also need to write a commit message with every change in a file. The commit message basically tells what changes were made.

git commit -m "message" -a
[master (root-commit) 57331ee] message
 2 files changed, 2 insertions(+)
 create mode 100644 GoT.txt
 create mode 100644 writing.txt

In this case I had a file called GoT (Game of Thrones review) and I made some changes, so when I ran the command it specified that changes were made to the file. In the above command ‘-a’ option means commits for all files in the repo. If you made changes to only one you can specify the name of that file instead of using ‘-a’.

An example:

git commit -m "message" GoT.txt
[master e517b10] message
 1 file changed, 1 insertion(+)

Until now we have been working on the local server. Now we have to push these changes to the server so the work is accessible over the Internet and you can collaborate with other team members.

git remote add origin ssh://git@remote-server/repo-<wbr< a="">>path-on-server..git

Now you can push or pull changes between the server and local machine using the ‘push’ or ‘pull’ option:

git push origin master

If there are other team members who want to work with the project they need to clone the repo on the server to their local machine:

git clone git@remote-server:/home/swapnil/project.git

Here /home/swapnil/project.git is the project path on the remote server, exchange the values for your own server.

Then change directory on the local machine (exchange project with the name of project on your server):

cd /project

Now they can edit files, write commit change messages and then push them to the server:

git commit -m 'corrections in GoT.txt story' -a
And then push changes:
git push origin master

I assume this is enough for a new user to get started with Git on their own servers. If you are looking for some GUI tools to manage changes on local machines, you can use GUI tools such as QGit or GitK for Linux.

QGit

Using GitLab

This was a pure command line solution for project owner and collaborator. It’s certainly not as easy as using GitHub. Unfortunately, while GitHub is the world’s largest code hosting service; its own software is not available for others to use. It’s not open source so you can’t grab the source code and compile your own GitHub. Unlike WordPress or Drupal you can’t download GitHub and run it on your own servers.

As usual in the open source world there is no end to the options. GitLab is a nifty project which does exactly that. It’s an open source project which allows users to run a project management system similar to GitHub on their own servers.

You can use GitLab to run a service similar to GitHub for your team members or your company. You can use GitLab to work on private projects before releasing them for public contributions.

GitLab employs the traditional Open Source business model. They have two products: free of cost open source software, which users can install on their own servers, and a hosted service similar to GitHub.

The downloadable version has two editions – the free of cost community edition and the paid enterprise edition. The enterprise edition is based on the community edition but comes with additional features targeted at enterprise customers. It’s more or less similar to what WordPress.org or WordPress.com offer.

The community edition is highly scalable and can support 25,000 users on a single server or cluster. Some of the features of GitLab include: Git repository management, code reviews, issue tracking, activity feeds, and wikis. It comes with GitLab CI for continuous integration and delivery.

Many VPS providers such as Digital Ocean offer GitLab droplets for users. If you want to run it on your own server, you can install it manually. GitLab offers an Omnibus package for different operating systems. Before we install GitLab, you may want to configure an SMTP email server so that GitLab can push emails as and when needed. They recommend Postfix. So, install Postfix on your server:

sudo apt-get install postfix

During installation of Postfix it will ask you some questions; don’t skip them. If you did miss it you can always re-configure it using this command:

sudo dpkg-reconfigure postfix

When you run this command choose “Internet Site” and provide the email ID for the domain which will be used by Gitlab.

In my case I provided it with:

This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 

Use Tab and create a username for postfix. The Next page will ask you to provide a destination for mail.

In the rest of the steps, use the default options. Once Postfix is installed and configured, let’s move on to install GitLab.

Download the packages using wget (replace the download link with the latest packages from here) :

wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.9.4-omnibus.1-1_amd64.deb

Then install the package:

sudo dpkg -i gitlab_7.9.4-omnibus.1-1_amd64.deb

Now it’s time to configure and start GitLabs.

sudo gitlab-ctl reconfigure

You now need to configure the domain name in the configuration file so you can access GitLab. Open the file.

nano /etc/gitlab/gitlab.rb

In this file edit the ‘external_url’ and give the server domain. Save the file and then open the newly created GitLab site from a web browser.

GitLab 1

By default it creates ‘root’ as the system admin and uses ‘5iveL!fe’ as the password. Log into the GitLab site and then change the password.

GitLab 2

Once the password is changed, log into the site and start managing your project.

GitLab manage project page

GitLab is overflowing with features and options. I will borrow popular lines from the movie, The Matrix: “Unfortunately, no one can be told what all GitLab can do. You have to try it for yourself.”

A New CentOS » Linux Magazine


CentOS Release Manager, Karanbir Singh announced the release of CentOS Linux 7 1804, which is based on Red Hat Enterprise Linux (RHEL) 7.5.

CentOS is a community-maintained clone of RHEL, and it is targeted at users who want the functionality of RHEL without the need for Red Hat support. As a result, CentOS is extremely popular among web hosting providers that need thousands of virtual machine to run websites.

As CentOS emerged as a serious threat to RHEL, Red Hat moved swiftly to acquire the project. Many CentOS maintainers joined Red Hat. Since then, CentOS has maintained a measure of independence and continues to be available for free of cost.

Although CentOS is seen as downstream of RHEL, in some cases it also works as an upstream source. “ Developers and end users looking at inspecting and contributing patches to the CentOS Linux distro will find the code hosted at git.centos.org far simpler to work against,” wrote Singh.

Users are urged to upgrade to the latest version of CentOS. “This release supersedes all previously released content for CentOS Linux 7, and therefore we highly encourage all users to upgrade their machines. Information on different upgrade strategies and how to handle stale content is included in the Release Notes,” said Singh.

The system upgrade can be performed with these commands:

$ sudo yum clean all

$ sudo yum upgrade

$ sudo systemctl reboot

Download CentOS at the official download page.



Source link

Cloud Foundry for Developers: The cf Command | Linux.com


In this series, we are previewing the Cloud Foundry for Developers training course to help you better understand what Cloud Foundry is and how to use it.  So far, we’ve covered:

Part 1: Introduction

Part 2: Definitions

Part 3: Architecture

For more details, you can download the sample chapter here

The Cloud Foundry command-line interface (cf CLI) is your primary tool for interacting with your Cloud Foundry instances: manage apps, view logs, run health checks, manage buildpacks, manage users, and manage plugins. Today, we will learn how to install the tool and run commands. You’ll need a Cloud Foundry instance; see How Can I Try Out Cloud Foundry? to learn about some hosting providers to try, some of them free.

Installing cf

Install the cf CLI by following the instructions at Installing the cf CLI. Verify that it installed correctly by checking the version:

$ cf --version  
cf version 6.30.0

Localization

The cf CLI supports localization. The default language setting is en-US. To change it follow the directions at Installing the cf CLI: Localize. This controls the language only for the cf CLI, and does not affect your system settings.

Getting Started with the cf CLI

The cf CLI has an inbuilt help system. cf --help displays the main help menu, and you can get help on specific commands with cf [command name] --help, for example:

$ cf login --help

Logging In

The first step to interacting with a Cloud Foundry instance, also called a target, is to log in. You are logging into an API endpoint, using this syntax: cf login api.cloudfoundry.system.domain. It will always have the api prefix.

For example, to log into Pivotal Web Services located at run.pivotal.io, your target is api.run.pivotal.io.

Orgs And Spaces

When you log in, you are asked to target an org and a space. If there is only one org and one space these become your default targets. When there are multiple orgs and spaces then you must specify the ones you want.

cf target displays your current API endpoint, user, org and space.

cf orgs prints a list of orgs that you can access.

cf target -o org switches to a different org.

cf spaces prints a list of spaces that you can access.

cf target -s space switches to a different space.

Correct cf CLI Version

It is possible for multiple Cloud Foundry targets to run different versions, so you should verify that your CLI version works with your current target. Use the cf curl command to determine version information.

All Cloud Foundry targets expose an info endpoint, which prints the release name, build number, description, and various endpoints. Run cf curl /v2/info to see this information, and look for the "min_cli_version". The version you installed should be equal to or newer than the "min_cli_version".

Debugging Connection Issues

The CF_TRACE environment variable prints API request diagnostics, showing your login API, cf CLI version, API version, and lot of other useful information. First set the environment variable, then run the cf target command:

$ export CF_TRACE=true
$ cf target

Unset it with export CF_TRACE=false. Or you can use it per command by prepending your commands:

$ CF_TRACE=true cf target

Now that you know the basics of using cf CLI, come back for the fifth and final blog to learn how to create and push a simple app.

The information in this series is based on the Cloud Foundry for Developers (LFD232) training course from Cloud Foundry and The Linux Foundation. You can download a sample chapter from the course here.

Protect Your Websites with Let’s Encrypt | Linux.com


Back in the bad old days, setting up basic HTTPS with a certificate authority cost as much as several hundred dollars per year, and the process was difficult and error-prone to set up. Now we have Let’s Encrypt for free, and the whole thing takes just a few minutes.

Why Encrypt?

Why encrypt your sites? Because unencrypted HTTP sessions are wide open to multiple abuses:

Internet service providers lead the code-injecting offenders. How to foil their nefarious desires? Your best defense is HTTPS. Let’s review how HTTPS works.

Chain of Trust

You could set up asymmetric encryption between your site and everyone who is allowed to access it. This is very strong protection: GPG (GNU Privacy Guard, see How to Encrypt Email in Linux), and OpenSSH are common tools for asymmetric encryption. These rely on public-private key pairs. You can freely share public keys, while your private keys must be protected and never shared. The public key encrypts, and the private key decrypts.

This is a multi-step process that does not scale for random web-surfing, however, because it requires exchanging public keys before establishing a session, and you have to generate and manage key pairs. An HTTPS session automates public key distribution, and sensitive sites, such as shopping and banking, are verified by a third-party certificate authority (CA) such as Comodo, Verisign, or Thawte.

When you visit an HTTPS site, it provides a digital certificate to your web browser. This certificate verifies that your session is strongly encrypted and supplies information about the site, such as organization’s name, the organization that issued the certificate, and the name of the certificate authority. You can see all of this information, and the digital certificate, by clicking on the little padlock in your web browser’s address bar (Figure 1).

The major web browsers, including Opera, Firefox, Chromium, and Chrome, all rely on the certificate authority to verify the authenticity of the site’s digital certificate. The little padlock gives the status at a glance; green = strong SSL encryption and verified identity. Web browsers also warn you about malicious sites, sites with incorrectly configured SSL certificates, and they treat self-signed certificates as untrusted.

So how do web browsers know who to trust? Browsers include a root store, a batch of root certificates, which are stored in /usr/share/ca-certificates/mozilla/. Site certificates are verified against your root store. Your root store is maintained by your package manager, just like any other software on your Linux system. On Ubuntu, they are supplied by the ca-certificates package. The root store itself is maintained by Mozilla for Linux.

As you can see, it takes a complex infrastructure to make all of this work. If you perform any sensitive online transactions, such as shopping or banking, you are trusting a whole lot of unknown people to protect you.

Encryption Everywhere

Let’s Encrypt is a global certificate authority, similar to the commercial CAs. Let’s Encrypt was founded by the non-profit Internet Security Research Group (ISRG) to make it easier to secure Websites. I don’t consider it sufficient for shopping and banking sites, for reasons which I will get to shortly, but it’s great for securing blogs, news, and informational sites that don’t have financial transactions.

There are at least three ways to use Let’s Encrypt. The best way is with the Certbot client, which is maintained by the Electronic Frontier Foundation (EFF). This requires shell access to your site.

If you are on shared hosting then you probably don’t have shell access. The easiest method in this case is using a host that supports Let’s Encrypt.

If your host does not support Let’s Encrypt, but supports custom certificates, then you can create and upload your certificate manually with Certbot. It’s a complex process, so you’ll want to study the documentation thoroughly.

When you have installed your certificate use SSL Server Test to test your site.

Let’s Encrypt digital certificates are good for 90 days. When you install Certbot it should also install a cron job for automatic renewal, and it includes a command to test that the automatic renewal works. You may use your existing private key or certificate signing request (CSR), and it supports wildcard certificates.

Limitations

Let’s Encrypt has some limitations: it performs only domain validation, that is, it issues a certificate to whoever controls the domain. This is basic SSL. It does not support Organization Validation (OV) or Extended Validation (EV) because it is not possible to automate identity validation. I would not trust a banking or shopping site that uses Let’s Encrypt– let ’em spend the bucks for a complete package that includes identity validation.

As a free-of-cost service run by a non-profit organization there is no commercial support, but only documentation and community support, both of which are quite good.

The Internet is full of malice. Everything should be encrypted. Start with Let’s Encrypt to protect your site visitors.

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