Tag Archives: hosting

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.

GitHub Announces Open Source Friday Program » Linux Magazine


After Linux, Git is the second major contribution of Linus Torvalds. Git has become a global phenomenon with GitHub, the planet’s largest repository of open source projects. Even Microsoft has moved the source code of Windows to a private GitHub repository. Companies like Google have shut down their own code-hosting platforms and moved their code to GitHub.

GitHub is now becoming active in “promoting” the open source development model. The company has announced celebrating every Friday as Open Source Day.

Mike McQuaid, a senior software engineer at GitHub wrote in a blog post, “Open source software powers the internet. Anyone using a computer uses open source, either directly or indirectly. Although it has become the industry standard, getting involved isn’t always straightforward.”

McQuaid disclosed that the company has been running a program internally for the last three years in which they encourage employees to work on some open source project every fourth Friday of the month. Now, they are opening up the program for anyone to get involved with open source.

“Open Source Friday isn’t limited to individuals. Your team, department, or company can take part, too. Contributing to the software you already use isn’t altruistic – it’s an investment in the tools your company relies on. And you can always start small: spend two hours every Friday working on an open source project relevant to your business,” wrote McQuaid.

Source: https://opensourcefriday.com/

Blog Post: http://mikemcquaid.com/



Source link